Created attachment 5811 [details]
report.bug.xz

ddebug.log was a bit big but verified report.bug contained the error so here is report.bug.xz

# rpm -qa | grep SDL
lib64SDL1.2_0-1.2.15-15.mga5
lib64SDL_sound1.0_1-1.0.3-16.mga5
lib64SDL_gfx14-2.0.24-3.mga4
lib64SDL_gfx15-2.0.25-4.mga5

I hadn't previously noticed this, but I also got this with one VM that I upgraded with urpmi rather than the installer, and it was again on the ncl-common package for me.  I'll mark Bug 14979 as a duplicate of this.

Assignee: bugsquad => thierry.vignaud
CC: (none) => luigiwalser
Hardware: x86_64 => All
Source RPM: (none) => urpmi-8.03-1.mga5.src.rpm

*** Bug 14979 has been marked as a duplicate of this bug. ***

The urpmi message reveals a real error.
We've an issue when rpm calls the 'error' callback where we fails to identify the right package.
It's one of that transaction that fails.
The package really needs to be fixed...

Assignee: thierry.vignaud => bugsquad
Source RPM: urpmi-8.03-1.mga5.src.rpm => (none)

(In reply to Thierry Vignaud from comment #5)
> The urpmi message reveals a real error.
> We've an issue when rpm calls the 'error' callback where we fails to
> identify the right package.
> It's one of that transaction that fails.
> The package really needs to be fixed...

What package needs to be fixed?  The one it's reporting is totally bogus.  It wasn't installed at all (so it wasn't part of the transaction).

Also, regardless of whether there's a package with a script that's failing (I always figured there was), the fact that the package is being misidentified is still a bug, either in urpmi or rpm.

(In reply to David Walser from comment #6)
> (In reply to Thierry Vignaud from comment #5)
> > The urpmi message reveals a real error.
> > We've an issue when rpm calls the 'error' callback where we fails to
> > identify the right package.
> > It's one of that transaction that fails.
> > The package really needs to be fixed...
> 
> What package needs to be fixed?  The one it's reporting is totally bogus. 
> It wasn't installed at all (so it wasn't part of the transaction).

OK, so I believe the package is adwaita-icon-theme.  It appears nearby above the ERROR message about ncl-common on all three machines I saw this issue on.  That would be Bug 14971.

As for the misidentification of the package, since rpm doesn't know anything about hdlists such that it could pull a package name and version that's not part of the transaction out of thin air, wouldn't urpmi *have* to be the culprit?

Claire, I think you may have attached the report.bug from the wrong machine, as the error isn't in that log you attached.  However, in the one you pasted in Comment 0, I also see adwaita-icon-theme, so I think we've at least identified the package with the failing scriptlet.

This bug however is about the misidentification of the package.  I don't see how anything other than urpmi could be responsible for that.

Source RPM: (none) => urpmi-8.03-1.mga5.src.rpm

Oops. Sorry. It was in ddebug.log and report.bug but not the report.bug.xz which just seems to show the mga4 install. The upgrade is long gone but I'll do it again tomorrow.

Thierry removed himself from the bug some time ago btw but I agree with you about urpmi. I can't see how it could be anything else. An off by one error or similar.

Thierry is still CC'd, so hopefully he'll have a look into the issue.  It certainly makes it more difficult for us to debug these scriptlet issues as we test on our way to mga5.

(In reply to claire robinson from comment #10)
> 
> Thierry removed himself from the bug some time ago btw but I agree with you
> about urpmi. I can't see how it could be anything else. An off by one error
> or similar.


If you look how package install works, urpmi is a hdlist reader  / rpm work feeder...

it passes a list of rpms to rpm for install, and reads the feedback it gets from rpm ... so the "off-by-one" can wery much be rpm not tracking the error vs package properly...

I'll see if I can reproduce it so we can get input from Panu about it...

But why would urpmi be feeding to rpm the name of a package that it is not installing?

The real issue is that rpmlib offers us to register whatever key we want for packages we're installing/upgrading.
Urpmi pass the package index (which is basically a number incremented from 0 when reading packages from synthesis, so its depends on its place in a given synthesis file and of the order of media in /etc/urpmi/media.cfg)

but when rpm removes a package, rpmlib blindly passes the package header.
urpmi tries to interprint the header pointer as an integer index, which often results in "0" and thus it warn about the first package in $urpm->{depslist}

Ran into same issue with Mageia5 beta3 upgrade with classical iso (64bits)

"Une erreur est survenue

ERROR 'script' failed for thunderbird-uk 31.04.0-1.mga5.noarch"

though thunderbird was not installed on Mageia4 from which I upgraded.

After OKing this message, installation process completed and MGA5x64 upgrade was functionnal.

CC: (none) => olchal

Until there is a fix, you'll need to look in /root/drakx/ddebug.log and find the rpm transaction which caused the script failed message. Search for that message.

The preceding transaction, usually around 8 rpms has one with a failing script. Previously identified adwaita-icon-theme but that was beta 2, several weeks ago.

Priority: Normal => release_blocker

Created attachment 5854 [details]
/root/drakx/ddebug.log


Here in attachment I put ddebug.log as Claire pointed I could find what caused the error.

I can only see one in line 13231 :
* urpmi error: ERROR: 'script' failed for thunderbird-uk-31.4.0-1.mga5.noarch: 
* workaround bug in rpmlib by removing /mnt/var/lib/rpm/__db*
* opening rpmdb (root=/mnt, write=1)

which is the same than message error I got when upgrading.

Comment on attachment 5854 [details]
/root/drakx/ddebug.log

And just a few lines above that, you can see that it's adwaita-icon-theme.  I wouldn't have expected anything else.

commit 521de2161bd4dad784d8a9b4add9ad6e83e269ba
Author: Pascal Terjan <pterjan@...>
Date:   Thu Feb 5 22:45:58 2015 +0000

    Don't give a wrong package name when it is unknown in a callback (mga#15032)
---
 Commit Link:
   http://gitweb.mageia.org/software/rpm/urpmi/commit/?id=521de2161bd4dad784d8a9b4add9ad6e83e269ba

I commited a first "fix" to get rid of the wrong package name by not giving one when we don't know it.
Not very helpful but at list not misleading.

'unknown' would be better for the package name I think

(In reply to Thierry Vignaud from comment #21)
> 'unknown' would be better for the package name I think

Just change it then :)

CC: (none) => pterjan

This cannot be a release blocker.
On one hand there's a packaging issue and on the other hand we cannot identify the bogus packages in urpmi when the error callback is called about a package that is being uninstalled.

For the former, /root/drakx/install.log should help pinpoint the bogus package.

Priority: release_blocker => Normal

The packaging issue is Bug 14971 and will hopefully be fixed soon with an update to the mga4 package.

This bug is about RPM giving the wrong package name, and if it's not a release blocker, it at least should be high priority, as it will make it practically impossible to get good bug reports if there are any other upgrade issues, so we won't be able to fix any others (hopefully there aren't any more).

Priority: Normal => High

commit b0cd1853933d8c68610c9e173721525c6a17e8ce
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Mon Feb 23 10:58:56 2015 +0100

    callbacks now get pkg name instead of just pkg id
    
    thus fixing unknown package name on erases (mga#15032)
---
 Commit Link:
   http://gitweb.mageia.org/software/rpm/perl-URPM/commit/?id=b0cd1853933d8c68610c9e173721525c6a17e8ce

commit 3d9a2bcd451b1e0f0ee9b6afe93d01c16c37a124
Author: unknown <ex.thierry.vignaud@...>
Date:   Mon Feb 23 10:54:37 2015 +0100

    always display the right package name on errors
    
    fixes mga#15032 and also simplify...
    needs URPM >= 5.04
---
 Commit Link:
   http://gitweb.mageia.org/software/rpm/urpmi/commit/?id=3d9a2bcd451b1e0f0ee9b6afe93d01c16c37a124

Closing

Status: NEW => RESOLVED
Resolution: (none) => FIXED

urpmi segfault with perl-URPM-5.04 and urpmi-8.04 .
Thomas has restored perl-URPM-5.03-1.mga5 and urpmi-8.03-1.mga5 on the mirrors (cf. -dev ML).

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

I fixed the segfault in perl-URPM-5.05

Closing

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED