1.8.11-2 is already in Arch Stable now, but somehow hasn’t made it into Manjaro Unstable yet.
only in stable and testing
pacman -Si iptables-nft
Repository : core
Name : iptables-nft
Version : 1:1.8.11-1
...
Repository : extra
Name : iptables-nft
Version : 1:1.8.11-2
Architecture : x86_64
since this ? https://forum.manjaro.org/t/iptables-nft-1-8-11-1-has-a-bug-that-breaks-docker/176530
Are you sure?
Not sure why there’s a discrepancy…
❯ mbn info iptables-nft | grep 'Branch\|Version'
Branch : archlinux
Version : 1:1.8.11-2
Branch : unstable
Version : 1:1.8.11-2
Branch : testing
Version : 1:1.8.11-1
Branch : stable
Version : 1:1.8.11-1
yes, mbn (as pacman) use the first repo found and after ignore if same package name. Online tool override (not ignore), or repo order is not good ? TODO open issue ? @cfinnberg
LANG=en sudo pacman -S iptables-nft
resolving dependencies...
looking for conflicting packages...
:: iptables-nft-1:1.8.11-1 and iptables-1:1.8.11-1 are in conflict.
# default is first repo in pacman.conf, but we can force a repo
LANG=en sudo pacman -S extra/iptables-nft
resolving dependencies...
looking for conflicting packages...
:: iptables-nft-1:1.8.11-2 and iptables-1:1.8.11-1
a few days ago, I made a personal fork at mbn (ignore also second entry)
LANG=en mbc info iptables-nft --ia
stable
Name: iptables-nft
Version: 1:1.8.11-1
Date: 25-03-19 16:53
testing
Name: iptables-nft
Version: 1:1.8.11-1
Date: 25-03-19 16:53
unstable
Name: iptables-nft
Version: 1:1.8.11-2
Date: 25-03-22 18:58
archlinux
Name: iptables-nft
Version: 1:1.8.11-2
Date: 25-03-22 18:58
WARNING!
# ignore duplicate : iptables-nft (stable.extra)
# ignore duplicate : iptables-nft (testing.extra)
Package: iptables-nft (core repository)
Utility: This package provides iptables, ip6tables, arptables, and ebtables using the nftables backend. Essentially, it's a compatibility layer that allows you to use the familiar iptables commands and syntax while leveraging the more modern and efficient nftables framework in the background. This allows for a smoother transition from iptables to nftables.
Iptables itself is not a direct application but a command-line utility for configuring the Linux kernel's built-in firewall, netfilter. It provides a powerful and flexible way to manage network traffic by defining rules to allow, deny, or modify packets based on various criteria such as source/destination IP address, port, protocol, and more. It's a fundamental tool for network security and routing on Linux systems, now implemented with nftables as the backend.
iptables-nft is found on two different repos: core and extra, what is wrong as far as I understand. It should be only in one of those.
The package is in Arch’s core repo, so I think the newer version should be moved from extra to core (and delete the older one ofc).
CC: @Yochanan
Edit: And yes, my web application was not prepared to find the same package on two different repos of the same branch.
1 Like
Oops. Will correct that shortly.
2 Likes
Hi, could someone update/fast-track spotify-player? See Branch compare for Manjaro
Due to updates on spotify’s side, the application broke over two months ago. Fixes for that have only been released with 0.21.x, which has been available since Sep 1th. See also: Release v0.21.0 · aome510/spotify-player · GitHub
Since this does not happen for the first time, i would recommend my personal favourite from AUR - AUR (en) - spotify (currently spotify 1:1.2.74.477-2) which seems to be actively maintained.
Branch compare shows spotify-player 0.21.1-1 available from testing and unstable branches
This is not helpful for me. I don’t want to switch to testing/unstable just because of a single package (I’d rather compile from source, which is what I did). I also don’t want to switch to the proprietary official software.
I’d argue that fast tracking a package which is currently unusable is a better choice, since everyone profits from it. Especially considering that the fixed version has been available for nearly two months in arch packages.
1 Like
AUR (en) - spotify-player-full-git
Package Base: spotify-player-full-git Description: A TUI spotify player. Upstream URL: GitHub - aome510/spotify-player: A Spotify player in the terminal with full feature parity
Release v0.21.1 · aome510/spotify-player · GitHub
Full Changelog: v0.21.0…v0.21.1
Obviously. This is indeed, quite strange advice.
I fully agree, since the whole point of branches is to test something before sending it to everybody. But if something is not working at all in stable, there is nothing to test. It is just not available in stable, but available in testing/unstable. This collides with the whole branch and versioning idea IMHO.
I had the same discussion with @Yochanan several months ago. The answer was, the policy is to fast track security related stuff. I can understand the argument since the more packages are fast tracked the more manual work for him. At some point it will become very time consuming. Still my argument above for totally not working packages is also valid.
@nikgnomic the problem with third party players is, they are unstable. I have tested at least 5 of them. They all use one of two libraries as backend, one of which is deprecated (like in the package you are proposing). Still, the whole chain of tricks to mask a player as a speaker only works sometimes. And is very fragile and hard to debug. I had the problem for example, if the backend service starts before internet connection is available, it failed. And as a result the first 5 minutes after start the alternative player was not working. And there were many many other peculiarities. At the end of the day, it is a proprietary software and most of the alternative stuff is developed with reverse engineering and can never work perfect.
So for the time being, the reliable solution is either to unpack the debian “native” version (which is electron a.k.a. embedded web site) or just use the web version in the browser.
The before mentioned from @7tvd package which is the only one in the repos does just that if i remember correctly. In a similar way like the aur package mentioned by me. Except that the aur package takes another 400MB in the opt directory.
@7tvd this particular aur package is safe in term of libraries to use on a stable branch. Just be sure to follow the general rules - always do a full update first from the repos, and then update the aur spotify with yay for example. You can check for updates with yay -Qua and update with yay -Sua (install with yay -S spotify and be careful to select the right package).
1 Like
@omano Did you even read what I wrote in the comment you replied to. I said that I don’t want to install the proprietary official package. I also already found a successful workaround. My comment was made mostly in the hope that an update will help others too.
1 Like
Would it be possible to have runc package 1.3.3+ backported to stable? There are some vulnerabilities addressed: oss-sec: runc container breakouts via procfs writes: CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881