Project

General

Profile

Bug #3204

Unable to perform system upgrade due to unresolved dependencies

doolio - about 2 years ago - . Updated about 2 years ago.

Status:
fixed
Priority:
bug
Assignee:
% Done:

0%


Description

Trying to perform an i686 system update I observe the following errors:

warning: mkinitcpio: local (30-2.0) is newer than libre (30-2.parabola2)
resolving dependencies...
warning: cannot resolve "libx264.so=163-32", a dependency of "ffmpeg" 
:: The following package cannot be upgraded due to unresolved dependencies:
      ffmpeg

:: Do you want to skip the above package for this upgrade? [y/N] y
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing libvpx (1.11.0-2.0) breaks dependency 'libvpx.so=6-32' required by ffmpeg
:: installing x264 (3:0.164.r3081.19856cc-2.2) breaks dependency 'libx264.so=161-32' required by ffmpeg

Files

History

#1

Updated by bill-auger about 2 years ago

  • Status changed from unconfirmed to forwarded upstream

thanks for noticing - the problem exists in arch32; so there is nothing we can do about it for now, other than avoiding the new ffmpeg

# pacman -Syu --ignore=ffmpeg

or simply wait until the arch32 team fixes it

upstream BR:
https://bugs.archlinux32.org/index.php?do=details&task_id=244

#2

Updated by bill-auger about 2 years ago

  • Assignee set to bill-auger
#3

Updated by bill-auger about 2 years ago

  • Status changed from forwarded upstream to fixed

fixed upstream - parabola has the change now

#4

Updated by doolio about 2 years ago

Thanks for looking into this so quickly Bill. However, this update(ffmpeg 2:5.0-5.0) would break dependencies required by mpv namely:

libavcodec.so=58-32
libavdevice.so=58-32
libavfilter.so=7-32
libavformat.so=58-32
libavutil.so=56-32
libswresample.so=3-32
libswscale.so=5-32

I have mpv 1:0.34.1-2.1 currently installed. Would you prefer I open a separate bug report?

#5

Updated by bill-auger about 2 years ago

are you sure there is a conflict? - did you try? - i just ran through this for the arch32 BR, and mpv works fine on my parabola i686 system today

that is because those are "sodeps" - installing mpv pulled in ffmpeg4.4, because it provides those sodeps; and mpv works as expected for me

mplayer and possibly a few others may still have conflicts - the arch32 team is rebuilding those now

#6

Updated by doolio about 2 years ago

Actually, it seems https://labs.parabola.nu/issues/3191 already covers it.

#7

Updated by doolio about 2 years ago

are you sure there is a conflict?

Well, pacman is failing on my end to even prepare the transaction because of these dependency errors.

#8

Updated by bill-auger about 2 years ago

#3191 is not the same issue - that issue existed last month for x86_64 for a different reason; and was fixed - this one only affects i686, and is relatively new

can you show me the output of pacman -Syu?

#9

Updated by doolio about 2 years ago

can you post the output of pacman?

See attached jpeg. Excuse this format. As you will see I'm trying to update via a chroot as I'm unable to currently access my fully encrypted system (see support request I raised on the forums). In terms of the mkinitcpio error I note the newer version my system has is different to that in libre and in core. Pacman believes it is newer than that in libre hence the error but doesn't update to that on core which is even be newer. Is that because core is refreshed after libre on my machine?

Thanks for your time.

#10

Updated by bill-auger about 2 years ago

the liveISOs are not designed to be upgraded - there is no normal reason to run `pacman -Syu` on a liveISO system

if you want to run mpv on the LiveISO, install mpv only - do not upgrade the system first

# pacman -S mpv ffmpeg4.4

this is a relatively minor problem - if your computer can not boot normally, that is far more important problem to fix - this one will probably fix itself in a few days - i did not quite understand the mkinitcpio problem, as you described it - which is that bug report?

#11

Updated by doolio about 2 years ago

No, I'm not upgrading the ISO but my machine via chrooting into it.

#12

Updated by bill-auger about 2 years ago

according to that screenshot, you are running a parabola LiveISO, and running the command `pacman -Syyu` - the effect of that command is to upgrade the live system

to repair your installed system, using a LiveISO, you would use the pacstrap command from the LiveISO, or to chroot into the installed system using arch-chroot - that screenshot gives no indication that you have chrooted into another system, or that you have another system mounted

#13

Updated by doolio about 2 years ago

Excuse my ignorance I don't often have to use a chroot. But I mounted my installed system to /mnt of the LiveISO, then used arch-chroot as you suggest before running that pacman command. Should the command prompt be different after using arch-chroot? All that changed for me was the working directory indicated in the prompt changed from ~ (or /root of the LiveISO) to / (the root of my installed system). Is this a mistake on my part?

#14

Updated by bill-auger about 2 years ago

no mistake - the prompt should change - the prompt inside
the chroot would definitely not have '@parabolaiso'

you could verify also, by checking (with pacman -Qs) if some
package is installed, which is not installed on the ISO (with
a CLI ISO, that could be any GUI program)

for example:

# pacman -Qs iceweasel

#15

Updated by doolio about 2 years ago

If I execute,

# pacman -Qs icecat

(trying icecat as I don't have iceweasel installed) before entering the chroot I get the following error:

warning: database file for 'isorepo' does not exist (use '-Sy' to download)

the chroot would definitely not have '@parabolaiso'

It seems too for me. It only changed as I described before. If I mount my system to /mnt and then enter the chroot with:

# arch-chroot /mnt

And then the same pacman command above I get the following:

local/icecat 78.7.0_pre-1
    GNU Icecat - a libre standalone web browser based on Mozilla Firefox ESR

Similarly, inside the chroot if I try to execute the following command

# systemctl status

I get the following error:

Running in chroot, ignoring command 'status'

Outside, the chroot the same command executes as expected.

#16

Updated by doolio about 2 years ago

i did not quite understand the mkinitcpio problem, as you described it - which is that bug report?

I will raise a separate BR on it.

#17

Updated by bill-auger about 2 years ago

ok so inside the chroot, you have icecat installed, and outside the chroot, icecat is not installed - also systemd does not work inside the chroot, but it works outside - that is all exactly what is expected

#18

Updated by doolio about 2 years ago

Thanks for confirming.

Also available in: Atom PDF