Project

General

Profile

Bug #2770

[ffmpeg] cannot install on i686/openrc

Drag0nFly - over 2 years ago - . Updated over 2 years ago.

Status:
not-a-bug
Priority:
broken
Assignee:
-
% Done:

0%


Description

See attachment.


Files

blah.txt (5.78 KB) blah.txt Drag0nFly, 2020-05-07 06:18 PM
pacman-ffmpeg-debug-log.txt (33.7 KB) pacman-ffmpeg-debug-log.txt bill-auger, 2020-05-09 03:08 AM

History

#1

Updated by Drag0nFly over 2 years ago

The reason this bug report did not have any proper description is due to the error message "Sorry, that post has too many non-dictionary words. Consider putting long command-line outputs and URLs into a file and attaching it with the 'Browse' button below." (regardless of how short the description was!)

The actual report is in the attachment, which the system registered twice.

#2

Updated by freemor over 2 years ago

  • Status changed from unconfirmed to confirmed

pactree shows that it stems from gnutls
which pulls in p11-kit
which pulls in systemd

And that is looking at the libre version of ffmpeg I'm working on (to remove CUDA). it is in [libre-testing] so if anyone more versed in systemd/openrc wants to hop on
it's probably best to start from there.

#3

Updated by bill-auger over 2 years ago

that looks like the same reason why 'base-devel' can not be
installed on an openrc system - we have not gooten to the root
of it yet - im going to link these together for now

https://labs.parabola.nu/issues/2638

#4

Updated by bill-auger over 2 years ago

  • Related to Bug #2638: [systemd] remove from base-devel group added
#5

Updated by bill-auger over 2 years ago

  • File deleted (blah.txt)
#6

Updated by Megver83 over 2 years ago

please don't get confused. The short answer is that Arch Linux 32 sucks (the base for our i686 pkgs)

long answer: if gnutls installs p11-kit, install it! but from [nonsystemd]. Now, the problem is that as Arch i686 is too crappy (many broken dependencies, delayed updates, strange versioning) p11-kit has a higher pkgrel than it's [nonsystemd] counterpart, so pacman believes that the [extra] version is the update (which depends on systemd)

that looks like the same reason why 'base-devel' can not be
installed on an openrc system - we have not gooten to the root
of it yet - im going to link these together for now

Not really, the reason for that is that base-devel has systemd, not because of a dependency, like in this case. Now, p11-kit is indirectly needed there, but by installing the [nonsystemd] version that can be easily solved.

#7

Updated by Megver83 over 2 years ago

  • Priority changed from bug to broken
  • Subject changed from Installation of ffmpeg (4.2.2-6.0) breaks system due to incorrect systemd dependencies to [i686][nonsystemd][openrc] Installation of ffmpeg (4.2.2-6.0) breaks system due to indirect systemd dependency
#8

Updated by eschwartz over 2 years ago

Megver,

The pacman software will attempt to install a dependency package from the first repository which provides it, without regard for which repository has a "newer" version.

If the dependency is a virtual package instead of a package name, then the user will be prompted to select one, but the default selection (e.g. with --noconfirm) is again, the one from the first repository (and within that repository, alphanumeric order should win).

Unless there is some sort of version pinning going on and the nonsystemd version simply doesn't satisfy the requirements there is no reason this shouldn't work...

Drag0nFly,

Try installing ffmpeg with the pacman --debug flag, and post the full error log.

#9

Updated by Drag0nFly over 2 years ago

Providing the --debug output from “pacman -S ffmpeg”

attached file: pacman-ffmpeg-debug-log.txt

#10

Updated by Drag0nFly over 2 years ago

btw-Not sure why the /var/lib/pacman/sync/*db.sig files are missing, but regular updates do not have any issues.

#11

Updated by eschwartz over 2 years ago

.sig files are allowed to be missing, since the default siglevel for arch is:

- packages require signing
- databases do not require signing, but if signatures are found, they are validated

As for your issue, it seems libpulse, part of the dependency tree, depends on the name "systemd" for the /usr/bin/systemctl binary, and uses that binary in the post_install scriptlet.

The first repository which contains a package literally named "systemd" wins. Using a package called "notsystemd" would work if it was preinstalled before installing ffmpeg, though.

#12

Updated by bill-auger over 2 years ago

i could not help noticing all those 'HoldPkg' and 'IgnorePkg' - you should use those very rarely and cautiously - that can also lead to dependency problems - normally, 'pacman' and 'glibc' are
the only 'HoldPkg' entries

regarding ffmpeg, i just upgraded my i686 and x86_64 openrc systems and had no conflicts - i did not have nonprism enabled though - maybe something in nonprism is causing the conflict - or maybe it is those held and ignored packages

as it appears that both megver and eli have concluded that there is no obvious problem; and i can not reproduce it, im going to set this back to non-confirmed

#13

Updated by bill-auger over 2 years ago

  • Subject changed from [ffmpeg] blocks upgrading i686/openrc system to [ffmpeg] cannot install on i686/openrc
#14

Updated by bill-auger over 2 years ago

  • Related to deleted (Bug #2638: [systemd] remove from base-devel group)
#15

Updated by bill-auger over 2 years ago

  • Status changed from confirmed to info needed
#16

Updated by bill-auger over 2 years ago

Drag0nFly -

can you check that you have no systemd packages installed now

$ pacman -Qsq systemd

and is there any problem synchronizing the system?

$ pacman -Syyuu
#17

Updated by Drag0nFly over 2 years ago

A regular system upgrade works fine (sorry, I thought I already mentioned this in the ticket). The issue is (so far) only with ffmpeg.

# pacman -Syu
:: Synchronizing package databases...
 nonprism                                                                                             25.6 KiB   332 KiB/s 00:00 [##############################################################################] 100%
 nonsystemd                                                                                           25.8 KiB  0.00   B/s 00:00 [##############################################################################] 100%
 libre                                                                                               334.0 KiB  1369 KiB/s 00:00 [##############################################################################] 100%
 core                                                                                                122.8 KiB  12.0 MiB/s 00:00 [##############################################################################] 100%
 extra                                                                                              1679.2 KiB  4.97 MiB/s 00:00 [##############################################################################] 100%
 community                                                                                             4.4 MiB  5.57 MiB/s 00:01 [##############################################################################] 100%
 pcr                                                                                                 497.6 KiB  4.42 MiB/s 00:00 [##############################################################################] 100%
:: Starting full system upgrade...
warning: eudev: ignoring package downgrade (3.2.9-15 => 3.2.9-1)
warning: eudev-libudev: ignoring package downgrade (3.2.9-15 => 3.2.9-1)
resolving dependencies...
looking for conflicting packages...

Packages (56) archlinux-keyring-20200422-1.0  argon2-20190702-3.0  bind-tools-9.16.2-1.0  binutils-2.34-2.1  ca-certificates-mozilla-3.52-1.0  cmake-3.17.2-1.0  coreutils-8.32-1.4  curl-7.70.0-1.0
              dhcpcd-9.0.2-1.0  dnsmasq-2.81-3.0  fish-3.1.1-1.0  freetds-1.1.33-1.0  gawk-5.1.0-1.0  gettext-0.20.2-1.2  glib2-2.64.2-1.1  glib2-docs-2.64.2-1.1  gobject-introspection-1.64.1-2.3
              gobject-introspection-runtime-1.64.1-2.3  gssproxy-0.8.3-1.0  iana-etc-20200428-1.0  jansson-2.12-2.0  keybase-5.4.2-1.0  libidn-1.35-2.1  libmicrohttpd-0.9.70-2.0  libtool-2.4.6+42+gb88cebd5-12.0
              libxslt-1.1.34-2.1  linux-libre-5.6.7-1  llvm-libs-10.0.0-1.0  lm_sensors-3.6.0-1.7  lmdb-0.9.25-1.0  mailcap-2.1.49-1.0  mlocate-0.26.git.20170220-3.0  oniguruma-6.9.5-1.0  pkgconf-1.6.3-4.0
              python-cffi-1.14.0-2.1  python-configargparse-1.2.3-1.0  python-cryptography-2.9.2-1.0  python-distro-1.5.0-1.0  python-docutils-0.16-1.0  python-dulwich-0.19.16-1.0
              python-importlib-metadata-1.5.2-1.0  python-sphinx-3.0.3-1.0  python-urllib3-1.25.9-1.1  python-zope-interface-5.1.0-1.0  python2-2.7.18-1.0  s-nail-14.9.19-1.0  shared-mime-info-1.15+43+gd23e9fa-2.0
              shorewall-5.2.4.4-1.0  shorewall-core-5.2.4.4-1.0  texinfo-6.7-3.0  tzdata-2020a-1.0  vim-8.2.0510-2.0  vim-runtime-8.2.0510-2.0  which-2.21-5.2  xorgproto-2020.1-1.0  your-freedom-20200502-1

Total Download Size:   162.08 MiB
Total Installed Size:  564.93 MiB
Net Upgrade Size:       10.55 MiB

:: Proceed with installation? [Y/n]

There is the systemd-libs-dummy package existing on the system. Not sure which repo provides it as the info is not in '-Qi';

# pacman -Qsq systemd
libelogind
opensysusers
opentmpfiles
systemd-libs-dummy
your-initfreedom

I removed everything in HoldPkg and ran the ffmpeg installatation again (not sure why this would cause a difference), but it behaved the same.

The only packages in IgnorePkg are eudev and eudev-libudev, and that is specifically due to Parabola not having the '--enable-rule-generator' configure option set, which
breaks the interface renaming.

Interestingly, p11-kit is already installed and at the newest version. Reinstalling it does not trigger a similar conflict: And the same error appears when trying to install ffmpeg after p11-kit has been reinstalled;


root@dragonfly /h/m/.maildir# pacman -S ffmpeg
resolving dependencies...
looking for conflicting packages...
:: systemd and openrc are in conflict (systemd-tools). Remove openrc? [y/N]
Interrupt signal received

#18

Updated by Megver83 over 2 years ago

I know how pacman works, then maybe Drag0nFly installed p11-kit from [core] first, which has, as of now, pkgrel=4.0, while [nonsystemd] is pkgrel=4.nonsystemd1

$ vercmp 0.23.20-4.nonsystemd1 0.23.20-4.0
-1

which makes pacman believe that [core] is the latest version, ignoring [nonsystemd]

however, if the pkgrel was the same as Arch (which Arch ARM follows) then [nonsystemd] would be considered as an update:

$ vercmp 0.23.20-4.nonsystemd1 0.23.20-4
1

Which is a problem that once I talked about in the mailing list, because some [libre] packages are considered as downgrades when migrating from Arch 32, but that's not a problem since users are encouraged to do `pacman -Syuu` when migrating

#19

Updated by Megver83 over 2 years ago

There is the systemd-libs-dummy package existing on the system. Not sure which repo provides it as the info is not in '-Qi';

the systemd-*-dummy packages were deprecated a long time ago, now elogind and libelogind provide systemd and systemd-libs, remove them and install elogind

#20

Updated by Drag0nFly over 2 years ago

libelogind was already installed. Not sure why this didn't trigger a conflict with the old systemd-libs-dummy package though.

I removed the systemd-dummy (the official name for it;), and it appears to have cleared-up the brokenness –

# pacman -S elogind libelogind
warning: libelogind-241.3-1 is up to date -- reinstalling
....

# pacman -Q|grep systemd
dbus 1.12.16-5.nonsystemd1
filesystem 2019.10-1.par1.nonsystemd1
libp11-kit 0.23.20-4.nonsystemd1
libutil-linux 2.35.1-1.nonsystemd1
mkinitcpio 27-3.nonsystemd1
p11-kit 0.23.20-4.nonsystemd1
systemd-libs-dummy 1:1-1
util-linux 2.35.1-1.nonsystemd1

# pacman -R systemd-libs-dummy
....

# pacman -S ffmpeg
....

Also, the p11-kit is from the nonsystemd repo, "Packages (1) p11-kit-0.23.20-4.nonsystemd1"

#21

Updated by Drag0nFly over 2 years ago

I'd like to voice my thanks for the fast replies; if only my bug reports for OpenRC was this swift.

And as a sidenote regarding ArchLinux32 brokenness, it has worked very well for me on this system so far - and I really do appreciate that Parabola supports 32-bit, so that this CPU is not
going to waste (an Atom N270). It has had none of the speculative exec vulnerabilities which other Intel CPUs were susceptible to (great plus for a fw if you ask me)

#22

Updated by bill-auger over 2 years ago

  • Status changed from info needed to not-a-bug

Also available in: Atom PDF