Makes that urpmi-6.40.3

Source RPM: urpmi => urpmi-6.40.3

Note for qa testers, you can use
urpmi.update Core
urpmi --media "Core Updates Testing" urpmi gurpmi

to install just these two packages from testing.

I'll be testing i586 shortly.

CC: (none) => davidwhodgins

Testing complete on i586 for the srpm
urpmi-6.40.3-1.mga1.src.rpm

I restored my Mageia 1 test install using an image that contains
a clean kde+gnome+lxdm install + updates, installed the updats
testing urpmi and gurpmi packages, then used mgaapplet-cauldron
from bug 5065 to start the upgrade to Cauldron, and let it run
until after urpmi restarted, and it started installing the bulk
of distro upgrade.

testing x86_64

Complete testing on i586 environment and everything work after 3 hours upgrade.

CC: (none) => pham182b

On a minimal installation, without a DE gurpmi fails with..

Gtk-WARNING **: cannot open display: at /usr/bin/gurpmi line 29

gurpmi only works inside an running DE. Even after installing task-gnome, running drakx11 and rebooting it didn't failed with the same message until I started gnome and ran it in a terminal.

s/didn't failed/failed/

That's unrelated to this update

Agreed that this is not a regression but it is missing dependencies Thierry.

Trying to reproduce the problem..

I've noticed that it stalls. It's probably down to the mirror but it doesn't seem to get going again. I have to use ctrl-c to kill it and restart the process.

It sits at 0% of any particular package waiting for the download to start, which never does. It doesn't seem to timeout and restart the download, or possibly does and I didn't leave it long enough, but I did leave it for a good while.

After downloading 67 packages and updating gurpmi it gives a message that the computer should be restarted for glibc but clicking Ok then carries on anyway.

# rpm -q gurpmi
gurpmi-6.40.1-1.mga1

# urpmi.removemedia -a

# urpmi.addmedia --distrib ftp://ftp.linuxcabal.org/pub/mirrors/Mageia/distrib/cauldron/x86_64

restarting urpmi                                                              
*** This build of Gtk2 was compiled with gtk+ 2.24.8, but is currently running with 2.24.4, which is too old.  We'll continue, but expect problems!
urpmi was restarted, and the list of priority packages did not change

I've not been able to reproduce the failure in the existing package beyond noticing this message and the request to reboot. I've tried several times now with gnome and lxde DE's. It also stalled during the upgrade process downloading 767 packages.

I'll try the update candidate

# rpm -q gurpmi
gurpmi-6.40.3-1.mga1

No difference noticed.

It did not complete the upgrade due to stalling, it didn't get very far at all.

After 9-10 minutes it continued but failed after a few seconds saying it was missing the package that it had failed on. It asked if I wanted to try and continue anyway and saying No exited gurpmi.

The error in terminal when it continued was..

... retrieving failed: curl: (56) Recv failure: Connection reset by peer

I took some screenshots to show what I mean.

Created attachment 1856 [details]
Shows gurpmi stalled soon after it started.

Created attachment 1857 [details]
Shows the failure after it restarted 10 mins later.

That's totally related to the changes.
What's more your screenshot show that you're using linuxcabal which is quite slow and unreliable for 2 weeks

Trying with a different mirror it still stalls.

...retrieving failed: curl: (28) connect() timed out!

It seems not to handle curl connection errors very well.

I'm just attempting to find problems, that is the whole point of QA isn't it??

We may as well not bother otherwise.

This mirror is a 10Gb ftp://ftp.fi.muni.cz

I will not bother with further testing and allow somebody else to 'Ok' it for you.

Currently, I've not been able to reproduce the problem and not noticed any difference with the update candidate.

I have found several 'unrelated' issues though.

Claire, For the test are you starting with a Mageia 1 install without
updates testing enabled?

Are you using the mgaapplet-cauldron from bug 5065?

I've now done i586 upgrades using this for kde, gnome, and lxde installs.

Yes to without updates testing Dave. I was using # gurpmi --auto-select

I've tried it with gnome/lxde and with existing/candidate installed. Started from a bare bones minimal installation and used drakx11 and urpmi task-lxde or task-gnome. I haven't tried with kde though but after spending 5 hours on it, and apparently wasting my time (comment 9 & comment 15), I've been unable to reproduce the error you found.

Apart from that though, it doesn't actually work anyway.

The bug only shows up when using gurpmi to upgrade from Mageia 1
to cauldron.  The only change is adding requires to ensure all
needed packages get installed from cauldron, before urpmi restarts.

Thats right Dave yeah. It doesn't show up for me though x86_64. It installs 60 odd packages and restarts with or without the update candidate.

In the process of testing though I found that it is either missing dependencies or a check for an X environment and an error message. It has to be run inside a terminal in an X environment and fails with a cryptic message without it. A test for X and meaningful error message would be a good solution or adding the necessary requires.

It also stalls and fails whenever there is any issue with the download process which, during an upgrade, is a substantial process. 

It stalled and failed every single time for me, not only during the upgrade process but also in the process of downloading priority packages before it restarts to begin the upgrade process. Checked with various mirrors. It doesn't handle curl errors at all from what I can tell.

It also gives or rather doesn't suppress a warning requesting a reboot when glibc is installed, it carries on anyway when the warning is accepted without rebooting.

(In reply to comment #22)
> Thats right Dave yeah. It doesn't show up for me though x86_64. It installs 60
> odd packages and restarts with or without the update candidate.

I'm very surprised that it would work without the update
candidate.

> In the process of testing though I found that it is either missing dependencies
> or a check for an X environment and an error message. It has to be run inside a
> terminal in an X environment and fails with a cryptic message without it. A
> test for X and meaningful error message would be a good solution or adding the
> necessary requires.

$ rpm -q -i gurpmi|grep Summary
Summary     : User mode rpm GUI install

Most gui programs behave the same way.

> It also stalls and fails whenever there is any issue with the download process
> which, during an upgrade, is a substantial process. 
> 
> It stalled and failed every single time for me, not only during the upgrade
> process but also in the process of downloading priority packages before it
> restarts to begin the upgrade process. Checked with various mirrors. It doesn't
> handle curl errors at all from what I can tell.

Ouch.  That would get frustrating very quickly.  But, I don't think
that's a regression.  Would you mind opening a new bug report on
gurpmi and validating this one, as without this update, the
mgaapplet-cauldron will not work (at least on i586), even for
people who are not having mirror problems.

> It also gives or rather doesn't suppress a warning requesting a reboot when
> glibc is installed, it carries on anyway when the warning is accepted without
> rebooting.

I agree that's something that should be looked at. Possibly the warning
message about the need for a good internet connection, to also warn about the need to ignore messages "should reboot for ...", or something
to that affect.  Again though, that would be a new bug report about
mgaonline, not urpmi/gurpmi.

(In reply to comment #23)
> (In reply to comment #22)
> > Thats right Dave yeah. It doesn't show up for me though x86_64. It installs 60
> > odd packages and restarts with or without the update candidate.
> 
> I'm very surprised that it would work without the update
> candidate.


You are absolutely right Dave! I have double checked my method this morning, I have been using urpmi-6.40.3-1 with gurpmi-6.40.1-1 so gurpmi was restarting without error. I apologise for the confusion.

# rpm -qa | grep urpmi
gurpmi-6.40.1-1.mga1
urpmi-6.40.1-1.mga1

installing
perl-Gtk2-1.242.0-2.mga2.x86_64.rpm
perl-Glib-1.251.0-2.mga2.x86_64.rpm
created transaction for installing on / (remove=0, install=0, upgrade=62)
removing upgraded package perl-Gtk2-1.230.0-5.mga1.x86_64
removing upgraded package perl-Glib-1.230.0-8.mga1.x86_64

restarting urpmi                                                              
urpmi was restarted, and the list of priority packages did change: rpm,perl-URPM,perl-MDV-Distribconf,urpmi,meta-task,glibc,aria2,gurpmi vs rpm,perl-URPM,perl-MDV-Distribconf,urpmi,meta-task,glibc,aria2,gurpmi,perl-Glib,perl-Gtk2

/usr/bin/perl: symbol lookup error: /usr/lib/../lib64/libgdk-x11-2.0.so.0: undefined symbol: _XGetRequest


So I can reproduce the initial bug.


I am not sure we should be validating something which consistently fails at the one thing it is supposed to do, but I'll create separate bugs for the other bugs as there is obviously no interest in addressing them here. We have fallen foul of doing this in the past and I don't think it is a good way of working so I am loath to do so.

bug 5125 and bug 5126 created.

I'll go ahead and validate this one as Claire testing does
show that the bug exists and is fixed in x86-64.

Could someone from the sysadmin team push the srpm
urpmi-6.40.3-1.mga1.src.rpm
from Core Updates Testing to Core Updates.

Advisory.  This update to gurpmi fixes a problem that would
prevent upgrading from Mageia 1 to Mageia 2.

Sorry, Really validating this time.

Could someone from the sysadmin team push the srpm
urpmi-6.40.3-1.mga1.src.rpm
from Core Updates Testing to Core Updates.

Advisory.  This update to gurpmi fixes a problem that would
prevent upgrading from Mageia 1 to Mageia 2.

https://bugs.mageia.org/show_bug.cgi?id=5104

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

done

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