Bug 31752

Thanks, Chris,

Is there more information in  /root/drakx/report.bug* that was created during the upgrade? Maybe a line before the line with "'script' failed for pulseaudio-client-config"?

Giuseppe, would you like to take this bug?

CC: (none) => ghibomgx, marja11
Status: NEW => NEEDINFO
Summary: pulse-client-config has a failing script during mageia upgrade => pulseaudio-client-config has a failing script during mageia upgrade, which halts automatic upgrade

Thanks for feedback. So, in ddebug.log, there is only one line concerning the issue:

* urpmi error: ERROR: 'script' failed for pulseaudio-client-config-16.1-14.mga9.x86_64

But searching for "pulseaudio-client-config" in ddebug.log, these messages may be also relevant:

* p11-kit not installed, %post(pulseaudio-client-config-16.1-14.mga9.x86_64) scriptlet failed, exit status 1

* chkconfig not installed, %post(pulseaudio-client-config-16.1-14.mga9.x86_64) scriptlet failed, exit status 1

* iputils not installed, %post(pulseaudio-client-config-16.1-14.mga9.x86_64) scriptlet failed, exit status 1

* espeak not installed, %post(pulseaudio-client-config-16.1-14.mga9.x86_64) scriptlet failed, exit status 1

* kernel-firmware-nonfree not installed, %post(pulseaudio-client-config-16.1-14.mga9.x86_64) scriptlet failed, exit status 1



In install.log, I can also find:

%post(pulseaudio-client-config-16.1-14.mga9.x86_64) scriptlet failed, exit status 1
pulseaudio-client-config-16.1-14.mga9.x86_64

So, the post script is indeed failing!

Thanks, Chris,

So this is all about missing packages that are needed for the %post script, which I don't understand because you were performing a net install and espeak, chkconfig, p11-kit and iputils weren't updated in 2023, yet, so they weren't in the midst of getting replaced by a newer version on your mirror.

kernel-firmware-nonfree was updated Tue 04 Apr 2023 05:10:16 PM CEST, but that's shortly _after_ you filed this bug report. If all clocks in our infra are in sync, then that update can't have created your problem, either.

So we need to find out why they weren't installed.

Do you mind compressing and attaching your ddebug.log?

CC'ing the mageia tools maintainers and the iso builders. They're better at reading logs than me and I'm currently often without internet access.

CC: (none) => isobuild, mageiatools
Summary: pulseaudio-client-config has a failing script during mageia upgrade, which halts automatic upgrade => pulseaudio-client-config has a failing %post script during mageia upgrade (missing packages), which halts automatic upgrade

We need to figure out what exactly is failing; the post-install script of pulseaudio-client-config is this:

/usr/sbin/update-alternatives \
  --install /etc/sound/profiles/current soundprofile /etc/sound/profiles/pulse 20

ccp -i -d --set NoOrphans --oldfile /etc/pulse/client.conf --newfile /etc/pulse/client.conf.rpmnew


While the post-uninstall script is:

if [ ! -f /etc/sound/profiles/pulse/profile.conf ]; then
  /usr/sbin/update-alternatives --remove soundprofile /etc/sound/profiles/pulse
fi

We might try to execute manually and see what happens.

These scripts seem to work fine on a mga9 system, installing and uninstalling and installing pulseaudio-client-config is ok.

The failure certainly occurs only between mga8 pulse audio config files and the mga9 packages. Well, we have been suffering from these upgrade bugs since mga1 :(

I am unable to reproduce this, suggesting it's system-specific and/or depends on the exact order in which the package updates are installed.

CC: (none) => mageia

(In reply to Chris Denice from comment #5)

> These scripts seem to work fine on a mga9 system, installing and
> uninstalling and installing pulseaudio-client-config is ok.
> 
> The failure certainly occurs only between mga8 pulse audio config files and
> the mga9 packages. Well, we have been suffering from these upgrade bugs
> since mga1 :(

The post-uninstall script of mga8's pulseaudio-client-config, it's the same as the one reported above, unless there are problems with update-alternatives remove.

Chris
Do you know whether this is still an issue?
Martin's comment 6 is not to be taken lightly.
Noting for Errata in case other people hit it during upgrade.

Assigning to you, ghibo; no point in leaving it with Bugsquad. You can close it if you want.

Keywords: (none) => FOR_ERRATA9
Assignee: bugsquad => ghibomgx

Yes, I cannot tell if this is still relevant, I've already updated all two mga8 machines to Cauldron. But, this occurred on both of them.
Let's keep it needinfo I would say.