gurpmi ignores errors with the downloading process which causes distribution upgrades to fail. This should be a release blocker. Eg: ... retrieving failed: curl: (28) connect() timed out! ... retrieving failed: curl: (56) Recv failure: Connection reset by peer Screenshots at attachment 1856 [details] and attachment 1857 [details]
It doesn't. When curl finished, gurpmi sees that some packages are missing. And again you're using a mirror that is buggy since a couple weeks. Why mirrorlist weren't used?
CC: (none) => thierry.vignaud
Why *should* mirrorlist be used? The proper place to have given that information would have been on bug 5104 where it was first raised, instead of the aloof and non informative response you did give, twice. And again, this was tested on 4 different mirrors and not once did it manage to complete without error. Thierry you seem extremely resistant to addressing problems found in QA. Do you feel it is beneath you? The last update for urpmi, you didn't even assign for validation. Even you must be able to see that stalling for 10 minutes, barely 1 minute into an upgrade and then giving a cryptic failure message that files are missing do you want to try anyway, is not good. Even if it does eventually catch them - assuming it gets that far. Personally if during what is still a risky operation to perform I was told multiple times that it had failed but I could try and go an on wait and see what happens - it might work, it might not - I would not bother and would install something else where proper QA was performed and devs wanted their feedback! After this fiasco I've been considering doing so.
Given me feeling being quite alone fixing bug in drakxtools, installer & urpmi, I feel this quite unfair. As for the last update, this is one of my first updates and I followed what the wiki said. As for this particular issue, all the proofs you showed me involved a know broken mirror. As for other mirrors, since you didn't provided any error message, I can only guess you hit packages that were updated. Quite a lot of packages are being updated since a couple days, so can hit mirrors where not all packages match the offered package list. As for *mirrorlist*, well this is what mgaaplet will use when performing live upgrade, not picking a random mirror. So you're not actually testing what users will do, because you manually remove mga1 / add mga2 media. So no an update that fixes a know critical issue should not be blocked b/c people are not testing what end users will. What you should do is: 1) ask https://releases.mageia.org/api/a/testing-i586 to be filled with mga2 in order to be able to use mgaapplet --testing 2) run mgaapplet --testing
or run "mgaapplet-upgrade-helper --new_distro_version=2" which is what mgaaplet would eventually run
I've requested the web server to be fixed so that people can actually test mgaapplet --testing. See bug #5135
As far as I am concerned, this bug report is invalid. We do check whether the downloader program succeeded or not and we report back that we were not able to download some packages as your screenshot show. Disappearing packages are a transient cauldron issue that can not happen on a released since: - we never remove packages from */release - we never remove outdated updates What's more, for real live upgrade, we use mirrorlists which prevent a bad mirror to destroy the live upgrade experience. For cauldron, if the first try failed, we update media and try again (x3).
Status: NEW => RESOLVEDResolution: (none) => INVALID
You do know that, for the most part, there are only 2 of us performing QA on all mga1 updates, including bug fixes and security updates? I get that you don't want to fix this. That doesn't mean that it is not a problem though. It is certainly not invalid, nor has it got anything to do with mgaapplet. This is a problem with gurpmi, which is what we were testing. # gurpmi --auto-select I would offer to assist you if I were able to. The only way I can help right now though is to perform QA, which is what I am attempting to do. I have spent countless hours doing so since updates started to be pushed for mga1. When I'm not doing that I do work for the doc team. You are not alone in being busy so I understand where you are coming from. This has now taken two days of testing, to the detriment of others, which is unsustainable. It is not good QA to ignore problems though, is it? I generally use linuxcabal for QA because it is tier1. It updates from rsync every 30 minutes. Belnet syncs from distrib-coffee which is often unreliable and slow. Whatever was the problem with linuxcabal has been resolved for several days. The problem is not whether or not a mirror causes the error, that is bound to happen from time to time whichever mirror is used, the problem is that errors are unhandled. Mirrorlist always chooses belnet for me, I tried with belnet, distrib-coffee, linuxcabal, a 10gb cz mirror and one in Brazil. It was exactly the same with each of them, the mirror in use is not relevant. It also failed downloading the packages to update itself before it restarts, in the same way.
(In reply to comment #7) Again you don't read what I wrote. > It is certainly not invalid, It is. You wrote "Gurpmi ignores connection errors causing distribution upgrades to fail". It doesn't ignore them. It detected the curl failure and open a popup about it. > nor has it got anything to do with mgaapplet. This is > a problem with gurpmi, which is what we were testing. No, what we are testing is distro live upgrade, which for most end users will be offered via mgaaplet. From stable mirrors, not from mirrors where packages disappear. gurpmi/urpmi/rpmdrake all uses the same code that works reliably and stop the upgrade when a mirror fails. > # gurpmi --auto-select > I generally use linuxcabal for QA because it is tier1. Again you don't read what I wrote. It is no more. It's slow and unreliable for 2 weeks. I used to use it for a year. I've stopped using it > It updates from rsync every 30 minutes. Indeed it was doing so. Until 2 weeks ago. Every time I checked for the last two weeks, it's now way outdated to I just restested now and it provides eg for mga1 updates_testing two sets of metainfo symlinks. eg: ftp.LinuxCabal.org:/pub/mirrors/Mageia/distrib/1/x86_64/media/core/updates_testing/media_info Also its speed has quite regressed since 2 weeks ago. Even http://mirrors.mageia.org/ lists it as 100Mb instead of as 1Gb up to until 2 weeks ago. > The problem is not whether or not a mirror causes the error, that is bound to > happen from time to time whichever mirror is used, the problem is that errors > are unhandled. No they are. Curl/wget/aria2 failed to download some packages. Gurpmi saw it and warned you. It didn't told you 'curl failed to download X, Y, Z'. It just told you that "X, Y & Z are not available". You have yet to show an unhandled issue. > Mirrorlist always chooses belnet for me, I tried with belnet, > distrib-coffee, linuxcabal, a 10gb cz mirror and one in Brazil. It was exactly > the same with each of them, the mirror in use is not relevant. It also failed > downloading the packages to update itself before it restarts, in the same way. Again, this is due to cauldron being upgraded and thus packages can disappear from mirrors between the moment we fetch the package list (update media) and the moment we download (GNOME3 being landed). Again, packages _CANNOT_ disappear from released stable distros. Last but not least what users will get is not manually picking a mirror from a set of mirror syncing a target which deletes packages with curl but mgaapplet set up new media as mirrorlist, picking whatever available mirrors are available at the time, mirrors who sync media where packages are not deleted, with aria2 swithching between mirrors if one fails. Mgaapplet (really its helper) will even update media and retry upgrade in case of failure. So you are not doing QA on what 99.99% of users will use but what 0.01% of experienced users. Can we agree we that if QA team is small, it's better to test what end users will eventually see?
I don't intend to pick apart what you've written and analyse it down to the sentence, that is counter productive. QA is ongoing on 'the upgrade process'. That is too wide a definition for testing gurpmi though. I opened this bug specifically in relation to gurpmi, not 'the upgrade process'. Linuxcabal is irrelevant. You are confusing the two. Updated packages for Mageia 1 undergo QA. It is as simple as that. The updated packages themselves are tested. When you propose an update candidate, it is just a package, or group of packages as part of an srpm. It is the packages that are validated and pushed to updates. As such, gurpmi is completely unrelated to mirrors, aria2, mgaonline, the applet or whatever else you are thinking it involves. It has nothing to do with packages disappearing. It is simply gurpmi! When gurpmi is performing an upgrade, it DOES NOT react in any direct way to issues with the download. When a person types 'gurpmi --auto-select' and an error occurs with the download (the reason why is completely irrelevant) then gurpmi does not recognise curl has errored. It does not open a popup about it. The download problem leads to missing dependencies which it then fails on. That is the limit and scope of this bug. I don't know how much clearer I can be on the QA validation process. There is a QA wiki page which might explain it better for you. https://wiki.mageia.org/en/QA_process_for_validating_updates I'm adding Anne to CC, she may be able to explain it better than I can.
CC: (none) => ennael1
(In reply to comment #9) > When a person types 'gurpmi --auto-select' and an error occurs with the > download (the reason why is completely irrelevant) then gurpmi does not > recognise curl has errored. It does not open a popup about it. The download > problem leads to missing dependencies which it then fails on. This is bogus. It did see curl fails. _YOU_ even attach the screenshot showing it: https://bugs.mageia.org/attachment.cgi?id=1857 When urpmi/gurpmi/rpmdrake install packages, it splits them into transactions. For each transaction, it first try to download packages, then to install them. If it can download the packages, urpmi prints this message, gurpmi or rpmdrake shows it in a dialog: "installation failed, some packages are missing" There's nothing special in gurpmi, it's calling urpmi code. If it didn't see the error, it would not say "some packages are missing. Just read urpmi code if you don't believe me: urpm::get_pkgs::download_packages_of_distant_media($urpm, (...) ask_retry => sub { <offer to retry on error> ); if (@error_sources) { my @bad = grep { $_->[1] eq 'bad' } @error_sources; my @missing = grep { $_->[1] eq 'missing' } @error_sources; if (@missing) { push @msgs, N("Installation failed, some files are missing:\n%s", join("\n", map { " $_->[0]" } @missing)) . "\n" . N("You may need to update your urpmi database."); } if (@bad) { push @msgs, N("Installation failed, bad rpms:\n%s", That's what rpmdrake/gurpmi/urpmi do for years, there's nothing new. Download fails, we popup "installation failed, some packages are missing". You even see it since you attached the screenshot. We detect the error and we handle it. We cannot do anything magic when download fails.
Claire, My understanding of Thierry's point of view, is that the most likely reason curl was failing, was that gurpmi selected the list of rpm packages to get, and while it was getting them, some of the packages were removed from the mirror, as updates were being pushed. The problem wasn't caused by which mirror was being used, but the timing of the tests. My tests all went smoothly, because I was testing while most of Europe is asleep. Once Mageia 2 is released, the problem of packages being removed will disappear too. That's why Thierry doesn't see a need to change the way gurpmi works. Please step back a bit, and keep in mind everyone is working hard to make this a good release.
CC: (none) => davidwhodgins
My tests were spread across two days so I really doubt that is the reason. Perhaps the message should be clearer but to tell the truth I have completely lost interest in this now and will take no further part. Do what you like with it.
updating GNOME to final release begin on 25th and finished (as in last updated p package) this morning, that is it spread across more than 2 days. And there were other core packages that got updated too.