Thank you Thierry for this update.

If the Advisory is committed and the update ready to push, it should not be with BugSquad. But where? qa-bugs?

I don't think this has not assigned to or tested by QA yet, so I'm removing the validation keyword. 

If the advisory has not yet been uploaded to SVN, then the "advisory" keyword should be removed, as well.

Mid Air collision!

Great minds, Lewis, great minds...

(Typo above: My first sentence was supposed to be: "I don't think this has been assigned...")

err... mgaapplet already told me that rpm-4.18.2-1.mga9 was available as update. If it's still in Updates Testing, why has it been listed? I didn't check if it was still in Updates Testing; I blindly trusted it.

(In reply to Frédéric "LpSolit" Buclin from comment #4)
> err... mgaapplet already told me that rpm-4.18.2-1.mga9 was available as
> update. If it's still in Updates Testing, why has it been listed? I didn't
> check if it was still in Updates Testing; I blindly trusted it.

Is in updates testing, check what repositories are enabled

Changing SRPM to current src.rpm see https://bugs.mageia.org/show_bug.cgi?id=28674#c15

Source RPM: rpm-4.18.2-1.mga9 => rpm-4.18.0-7.mga9.src.rpm

I don't know if I do the right thing to assign to qa

Tested on Mageia 9 x86_64

Update to testing packages without issues

Sign a package
Build one of my packages with rpmbuild 
Uninstall and install one package

If it is necessary to do other test, please tell me

A curious side effect
Before the update was enough, bm -lp to just unpack sources
After the update I need to add --nodeps because without it ask for the buildrequires

$ rpm -q rpm
rpm-4.18.0-7.mga9


# urpmi --auto-update
medium "QA Testing (64-bit)" is up-to-date
medium "Core Release (distrib1)" is up-to-date
medium "Core Updates (distrib3)" is up-to-date
medium "Nonfree Release (distrib11)" is up-to-date
medium "Nonfree Updates (distrib13)" is up-to-date
medium "Tainted Release (distrib21)" is up-to-date
medium "Tainted Updates (distrib23)" is up-to-date
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "QA Testing (64-bit)")
  lib64rpm9                      4.18.2       1.mga9        x86_64  
  python3-rpm                    4.18.2       1.mga9        x86_64  
  rpm                            4.18.2       1.mga9        x86_64  
  rpm-plugin-syslog              4.18.2       1.mga9        x86_64  
  rpm-plugin-systemd-inhibit     4.18.2       1.mga9        x86_64  
9.8KB of disk space will be freed.
931KB of packages will be retrieved.
Proceed with the installation of the 5 packages? (Y/n) y


installing python3-rpm-4.18.2-1.mga9.x86_64.rpm rpm-4.18.2-1.mga9.x86_64.rpm rpm-plugin-systemd-inhibit-4.18.2-1.mga9.x86_64.rpm rpm-plugin-syslog-4.18.2-1.mga9.x86_64.rpm lib64rpm9-4.18.2-1.mga9.x86_64.rpm from //home/work/qa-testing/x86_64
Preparing...                     ##################
      1/5: lib64rpm9             ##################
      2/5: rpm-plugin-systemd-inhibit
                                 ##################
      3/5: rpm-plugin-syslog     ##################
      4/5: rpm                   ##################
      5/5: python3-rpm           ##################
      1/5: removing python3-rpm-1:4.18.0-7.mga9.x86_64
                                 ##################
      2/5: removing rpm-1:4.18.0-7.mga9.x86_64
                                 ##################
      3/5: removing rpm-plugin-syslog-1:4.18.0-7.mga9.x86_64
                                 ##################
      4/5: removing rpm-plugin-systemd-inhibit-1:4.18.0-7.mga9.x86_64
                                 ##################
      5/5: removing lib64rpm9-1:4.18.0-7.mga9.x86_64
                                 ##################
restarting urpmi
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "QA Testing (64-bit)")
  lib64rpmbuild9                 4.18.2       1.mga9        x86_64  
  lib64rpmsign9                  4.18.2       1.mga9        x86_64  
0B of additional disk space will be used.
107KB of packages will be retrieved.
Proceed with the installation of the 2 packages? (Y/n) y


installing lib64rpmbuild9-4.18.2-1.mga9.x86_64.rpm lib64rpmsign9-4.18.2-1.mga9.x86_64.rpm from //home/work/qa-testing/x86_64
Preparing...                     ##################
      1/2: lib64rpmsign9         ##################
      2/2: lib64rpmbuild9        ##################
      1/2: removing lib64rpmsign9-1:4.18.0-7.mga9.x86_64
                                 ##################
      2/2: removing lib64rpmbuild9-1:4.18.0-7.mga9.x86_64
                                 ##################
$ rpm -q rpm
rpm-4.18.2-1.mga9

clean update.

CC: (none) => westel

This is probably not for this bug, but noting:

I used rpmdrake to select the firefox testing updates, and it automatically selected rpm and friend saying they need be updared first.  But when running, it seem to update firefox first, and all in one transaction.  So either the message or the action of drakrpm is wrong.

CC: (none) => fri

(In reply to Morgan Leijström from comment #10)
> This is probably not for this bug, but noting:
> 
> I used rpmdrake to select the firefox testing updates, and it automatically
> selected rpm and friend saying they need be updared first.  But when
> running, it seem to update firefox first, and all in one transaction.  So
> either the message or the action of drakrpm is wrong.

Confirmed but as you say that is other bug

(In reply to katnatek from comment #8)
> A curious side effect
> Before the update was enough, bm -lp to just unpack sources
> After the update I need to add --nodeps because without it ask for the
> buildrequires

I downgrade to confirm both behaviors

My installation experience was the same as comment 9.

After the update I went to drakrpm, and installed three arcade-style games. Closed it, played one of the games, so the install was successful.

(In reply to katnatek from comment #7)
> I don't know if I do the right thing to assign to qa
> 
> Tested on Mageia 9 x86_64
> 
> Update to testing packages without issues
> 
> Sign a package
> Build one of my packages with rpmbuild 
> Uninstall and install one package
> 
> If it is necessary to do other test, please tell me

If you look at bug 28674, you'll see that I validated another rpm update after a single test, but TMB removed it, saying that because it's such a basic package, there should be more testers on a wide variety of systems, and there should be i586 tests, as well. 

In the previous bug, the most important test was to install and remove packages, because that is what most users will do with it.

The librpm9-4.18.2-1.mga9.i586.rpm package was omitted from the list of i586 packages in comment 0. It is there in updates_testing - it was just left off the list in the comment.

Mga9-32 Xfce on Foolishness, my Dell Inspiron 5100, P4, Radeon RV200 graphics, using the desktop kernel.

No installation issues, once I included librpm9 on the list of packages in qarepo. 

After updating, I again used qarepo to download the packages for the pending update to Firefox, and then used urpmi --auto-update to update them - without issues.

Then I used urpmi to install a game called Powermanga, plus dependencies. I played the game a loittle, then used urpme to remove it, followed by urpme --auto-orphans to remove the now-unneeded dependencies. Again, no issues.

Looks OK on this system.

Tested on Mageia 9 i586 lxqt

Before the update

bm -lp 

extract the source without ask for buildrequires

Update to testing packages without issues

Sign a package
Build one of my packages with rpmbuild 
Uninstall and install one package

bm -lp

Now ask for buildrequires so the behaviour is consistent on both arches

To get the desired result now I have to run

bm -lp --nodeps

As additional test in my x86_64 since the time from comment#12 I keep the testing packages in my system some updates were installed without issue and I install and remove packages without issues

(In reply to Thomas Andrews from comment #15)
> The librpm9-4.18.2-1.mga9.i586.rpm package was omitted from the list of i586
> packages in comment 0. It is there in updates_testing - it was just left off
> the list in the comment.

Thanks for the warning I just tick the "add deps" box in QA Repo

Like some others noted, it installed with some other testing objects.

I installed the sign and api docs.

It seems to work as expected.

(In reply to Morgan Leijström from comment #10)
> This is probably not for this bug, but noting:
> 
> I used rpmdrake to select the firefox testing updates, and it automatically
> selected rpm and friend saying they need be updared first.  But when
> running, it seem to update firefox first, and all in one transaction.  So
> either the message or the action of drakrpm is wrong.

So to clarify, this isn't a bug.

rpm, like some other basesystem packages like perl, glibc, meta-task, etc., are handled as prerequisites for urpmi / rpmdrake.

If there is an update available for them, it must be installed first. Then, other non-critical packages are offered to update in a second batch.

You must have seen this behavior over the issues in MageiaUpdate, where it often provides a first batch of updates like rpm and/or glibc, then reloads urpmi, and offers the rest of non basesystem packages.

Here those of you testing firefox or other update candidates must have had the testing repo enabled, so rpm was found as an available (thus mandatory) update, and installed first.

----

Tested the rpm update candidate, it installed cleanly on Mageia 9 x86_64.

I used it successfully to install godot and gamemode update candidates.

CC: (none) => rverschelde

(In reply to Rémi Verschelde from comment #20)
> (In reply to Morgan Leijström from comment #10)

> Here those of you testing firefox or other update candidates must have had
> the testing repo enabled, so rpm was found as an available (thus mandatory)
> update, 

Yes and so far working as expected. 

> and installed first.

The bogus behaviour now observed is that rpm did *not get installed first*, but in the same transaction as firefox.

(In reply to Morgan Leijström from comment #21)
> (In reply to Rémi Verschelde from comment #20)
> > (In reply to Morgan Leijström from comment #10)
> 
> > Here those of you testing firefox or other update candidates must have had
> > the testing repo enabled, so rpm was found as an available (thus mandatory)
> > update, 
> 
> Yes and so far working as expected. 
> 
> > and installed first.
> 
> The bogus behaviour now observed is that rpm did *not get installed first*,
> but in the same transaction as firefox.

This sounds to me like a bug in drakrpm rather than in rpm itself. Possibly, I suppose, in the version of rpm that is being replaced, since that was the one in effect during the update.

Behavior confirmed, and with testing repos disabled (except for qa-testing).

I set up a situation where a user would have rpm updates pending, but decided to install something using MCC (drakrpm) first. Using qarepo to get the packages from this bug, I ran drakrpm from the command line, and told it to install 2048-qt, a puzzle game. I got the message that rpm, etc needed to be installed first, and that rpmdrake would restart afterward. 

But, this is what shows in the terminal during that transaction:

retrieving rpm files from medium "Core Release (distrib1)"...
    https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/9/x86_64/media/core/release/2048-qt-0.1.6-8.mga9.x86_64.rpm
retrieved   2048-qt-0.1.6-8.mga9.x86_64.rpm
...retrieving done
installing //home/tom/qa-testing/x86_64/rpm-plugin-systemd-inhibit-4.18.2-1.mga9.x86_64.rpm
//home/tom/qa-testing/x86_64/lib64rpm9-4.18.2-1.mga9.x86_64.rpm
//home/tom/qa-testing/x86_64/python3-rpm-4.18.2-1.mga9.x86_64.rpm
//home/tom/qa-testing/x86_64/rpm-4.18.2-1.mga9.x86_64.rpm
//home/tom/qa-testing/x86_64/rpm-plugin-ima-4.18.2-1.mga9.x86_64.rpm
//home/tom/qa-testing/x86_64/rpm-plugin-syslog-4.18.2-1.mga9.x86_64.rpm
/var/cache/urpmi/rpms/2048-qt-0.1.6-8.mga9.x86_64.rpm
starting installing packages
created transaction for installing on / (remove=0, install=0, upgrade=7)
removing installed rpms (2048-qt-0.1.6-8.mga9.x86_64.rpm) from /var/cache/urpmi/rpms                         
unlocking urpmi database

As you can see, the rpm packages were indeed installed first, and 2048-qt was installed as part of the same transaction.

Once the transaction was finished, drakrpm was restarted as promised, but as indicated 2048-qt had been installed.

As suggested in comment 22, I believe this is a drakrpm bug, not one of rpm. But, if I'm wrong and it IS a rpm bug, it's a bug of the old rpm, and if still present, not a new regression. Therefore it should not hold this update back.

I consider we can set the OKs, feel free to remove them if not is so

Whiteboard: (none) => MGA9-64-OK MGA9-32-OK

Unless the other packages in the first transaction have requires on the newer
version of rpm, as does happen when they use features only available or changed
in the new version of rpm, the order of packages in the first transaction should
not matter.

(In reply to Dave Hodgins from comment #25)
> Unless the other packages in the first transaction have requires on the newer
> version of rpm, as does happen when they use features only available or
> changed
> in the new version of rpm, the order of packages in the first transaction
> should
> not matter.

Then that is why I just remember MCC restart when a new urpmi version is in the updates

Validating.

Keywords: (none) => validated_update

(In reply to Thomas Andrews from comment #2)

> If the advisory has not yet been uploaded to SVN, then the "advisory"
> keyword should be removed, as well.

It didn't exist, yet, but has just been added

CC: (none) => marja11

yep, works well here. mga9-64.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2023-0144.html

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