This is a bug report to follow mdkonline import, cleaning and adapt to Mageia. Thierry will do the cleaning part and adapt code for Mageia Romain will manage server side.
Target Milestone: --- => Mageia 1
Reminding the scope of this tool: * checking, notifying of and listing available packages updates; * checking, notifying of available system upgrade; * triggering update or upgrade process on user request. Uses: * releases API, publishing available system releases * mirrors API, publishing available mirrors This was used at Mandriva before, we're changing a few bits: * mirrors API: - now at http://mirrors.mageia.org/api/{name}.{version}.i586.list (http://mirrors.mageia.org/api/mageia.cauldron.i586.list for cauldron, http://mirrors.mageia.org/api/mageia.1.i586.list for first stable release) - contents format & semantics don't change * releases API: - now at http://releases.mageia.org/api/a/{arch}?product={name}.{version} and should be called with the current system name and version as in: http://releases.mageia.org/api/a/i586?product=mageia.1 - contents format & semantics don't change so far, but we could maybe simplify a bit (there are some constraints that we don't have anymore)
(FWIW, if possible, drop the mdk/mga from the name altogether and pick a generic name, this makes for easier adaptation by e.g. other distros (forks).. ).
Yep. But finding a new name is somehow a curse too. The "online" suffix here is to be dropped as well, it's nowhere significant/related to the task of this module (checking, notifying, listing update/upgrade options and asking for action). At an extreme extent, we should maybe even see if splitting the software packages updates and system upgrade checks shouldn't be two separate modules. Suggestions: softwareupdate, swupdate, checkupdate, grow, growth, newupdates, whatsupsys (like that one)
How about update-auto-checker?
CC: (none) => davidwhodgins
make it short please :)
systemupdater ?
CC: (none) => sfietkonstantin
the release api does not seems to work for x86_64 arch.
CC: (none) => balcaen.john
Any update on that ? Romain, Thierry ?
(In reply to comment #7) > the release api does not seems to work for x86_64 arch. Fixed it seems. (In reply to comment #8) > Any update on that ? Romain, Thierry ? It's ready server-side (modulo maybe we should add there existing Mandriva 2010.x releases info? I don't know, it depends on the use case). No news client-side. Thierry?
name suggestion: updateD/updated where last d stands for daemon or longer: update-daemon, update-notifier
CC: (none) => sander.lepik
(In reply to comment #9) > No news client-side. Thierry? Sorry, I need to git-svn-dcommit all my changes tonight. A few remarks though: For compatibility, it would have maybe been better to keep the same type of URI as mdv so that only the vendor has to changed Aka we do not include anymore the product type nor the ".list" suffix in the URI eg: "https://api.mandriva.com/distributions/$extra_path$type.$product_id->{arch}.list?product=$product_id->{product}" vs: "http://releases.mageia.org/api/a/$extra_path$product_id->{arch}?product=$product_id->{product}" Dunno if we'll have several products (maybe some flash image to dump?). Also we may consider using https like used to do back at mdv...
I pushed initial client into Mageia
Could you please import it in soft/ also ?
i just imported it in soft/
CC: (none) => dmorganec
just saw. The point is we cannot test it for now as we need to tag release repos as updates. Anybody to do this ?
CC: (none) => misc
There seems to be a problem. The red icon (and the notification) appear indicating that updates are available, and when I select "Install updates", the icon turns to orange and the pop-up says checking for updates. However, instead of launching mageiaupdate it simply returns to displaying the red icon. "urpmi --auto-update --update" shows a list of packages available for update How I tested: Disabled online sources Set up Beta1 iso as a source Installed task-xfce-minimal Re-enabled online sources, tagged as update sources and installed mgaonline. Re-booted There is also no GUI in drakconf for setting updates frequency. Is this a separate package?
One additional point. Mageiaupdate does launch properly from within drakconf and displays the list of updates. (I have not installed these updates, so that I can test any newer version of mgaonline.)
One more thought: as it is quite visible tool, how are translations managed (I assume there will be some modifications? E.g. by now one can see there "Mageia Powerpack" and other nonsense phrases)? Will there be an exception to the freeze?
Regarding the GUI: mgaapplet-config does run from a terminal, it just fails to appear in drakconf. (The references to powerpack and restricted have been removed in the English version.)
Well, at least POT (http://svnweb.mageia.org/soft/mgaonline/trunk/po/mdkonline.pot?revision=1310&view=markup) still includes such references and also source (http://svnweb.mageia.org/soft/mgaonline/trunk/mgaonline.pm?revision=1310&view=markup), though it seems POT is just taken over not regenerated, as seen by references to the source (mdkonline.pm versus mgaonline.pm).
CC: (none) => bald
I think that I probably should have said that the references to powerpack and restricted to do not appear, because I'm obviously not running a powerpack version :)
fixed typo and it's working ok now. Needs strong tests for upgrade from Mandriva. Needs to add Mandriva releases on server side
Confirmed that it's working fine now. (There is still no link to mgaapplet-config in drakconf, but that's not critical.) To test the distro-upgrade feature is it sufficient to install mgaonline on a Mandriva 2010.1 system? Am I correct in understanding that we need to wait for server side changes before trying this test?
(Not a new package request any more). (In reply to comment #23) > Confirmed that it's working fine now. (There is still no link to > mgaapplet-config in drakconf, but that's not critical.) > Fixed in SVN.
Component: New RPM package request => RPM Packages
BTW, if we want to support older mdv releases, we would need to support %mdkversion in our BS... else mgaonline will require too new urpmi
(In reply to comment #25) > BTW, if we want to support older mdv releases, we would need to support > %mdkversion in our BS... > else mgaonline will require too new urpmi Why ?
CC: (none) => boklm
(In reply to comment #11) > > Also we may consider using https like used to do back at mdv... https is now available on releases.mageia.org
(In reply to comment #22) > fixed typo and it's working ok now. Needs strong tests for upgrade from > Mandriva. Needs to add Mandriva releases on server side Done: https://releases.mageia.org/api/a/i586?product=mageia.1 (In reply to comment #27) > (In reply to comment #11) > > > > Also we may consider using https like used to do back at mdv... > > https is now available on releases.mageia.org For the record, we need to know why it was published over HTTPS (ensuring the document was really published by a known certificate belonging to MDV? or else?).
Well, I'm very sorry to ask again somehow OT question but as I see there is at least 7 fuzzy strings now in translation file (I looked just at my language, Estonian http://svnweb.mageia.org/soft/mgaonline/trunk/po/et.po?revision=1333&view=markup ). So should we de-fuzzy them now (what means the freeze is extended temporarily at least for this package) and are these corrections included in the release then or would mgaonline appear just partially translated anyway? In any case it should be noticed in i18n list, too.
(In reply to comment #28) > For the record, we need to know why it was published over HTTPS (ensuring the > document was really published by a known certificate belonging to MDV? or > else?). It was done by cfergeau on September 1 2009 (20 months ago): "use https to grab mirrorlist from api.mandriva.com" http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/mdkonline/trunk/mdkapplet?r1=258569&r2=259833&sortby=date He also enabled the strict-certificate-check option btw (which is a nono as it's enabled by default in urpmi, probably just to be bullet proof against any API change) which makes sure curl/aria2/wget checks the CA. It was then released by alefebvre on Sept 8 2009 in 2.77.5.
CC: (none) => cfergeau
(In reply to comment #26) > > BTW, if we want to support older mdv releases, we would need to support > > %mdkversion in our BS... > > else mgaonline will require too new urpmi > > Why ? MDV wanted to enable new features in older releases (extended support, detection of & upgrade to newer releases, ...). Each of those older release had a different perl-URPM/urpmi (some did shared the same branch) (b/c pixel greatly improved urpmi by this time): - 2008.1: urpmi-4.10.14 (4.10 branch) - 2008.1: urpmi-5.19.x (5.19 branch) - 2009.0: urpmi-6.14.X (6.14 branch) - 2009.1: urpmi-6.25.x (6.25 branch) - 2010.0: urpmi-6.32 (HEAD of that time) In order to do so, pixel & me had to fix some packages in order to fix some known issues and to have the same foundations for mdkonline: - urpmi/gurpmi (for fixes) - drakxtools (for fixes) - rpmdrake (for gurpmi.addmedia & update API) - libdrakx-net (for network connection detection) See eg: http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/rpm/urpmi/branches/4.10.14/NEWS?view=log http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/rpm/urpmi/branches/5.19/NEWS?view=log http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/rpm/urpmi/branches/6.14/NEWS?view=log BTW, b/c of that mdkonline also: - do not use some perl-5.10-icisms (thus have warnings with new perl, see eg bug #1273) - checks the release for which drakx API to use - disables some stuff on 2008.0 (missing GUIes APIs) Thus, mdkonline require a new enough working urpmi/rpmdrake/drakxtools-backend/drakx-net in both Cauldron and each supported release. See http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/mdkonline/current/SPECS/mdkonline.spec?revision=666399&view=markup , especially the lines 16 to 57 While we do not have support for %mdkverssion, we can only support upgrading from mdv2010.0+ (that is 2010.0, 2010.1 & 2010.2), aka nothing older than september 2009. I would be happy to clean mdkonline for checks for 2008.0, warnings with new perl & the like but I'd rather be honest about the (im)possibility to support older mdv releases. Maybe we just don't care about those, but I don't think that's my call.
(In reply to comment #30) > It was done by cfergeau on September 1 2009 (20 months ago): > "use https to grab mirrorlist from api.mandriva.com" > http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/mdkonline/trunk/mdkapplet?r1=258569&r2=259833&sortby=date And I'm pretty sure all the people who could have ordered that are here: romain, anne (but Frederic)
(In reply to comment #31) > Thus, mdkonline require a new enough working > urpmi/rpmdrake/drakxtools-backend/drakx-net in both Cauldron and each supported > release. > See > http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/mdkonline/current/SPECS/mdkonline.spec?revision=666399&view=markup > , especially the lines 16 to 57 > > While we do not have support for %mdkverssion, we can only support upgrading > from mdv2010.0+ (that is 2010.0, 2010.1 & 2010.2), aka nothing older than > september 2009. Could we replace tests like : %if %mdkversion < 200910 with something like : %if %{?mdkversion}%{!?mdkversion:201020} < 200910 ?
(In reply to comment #31) > I would be happy to clean mdkonline for checks for 2008.0, warnings with new > perl & the like but I'd rather be honest about the (im)possibility to support > older mdv releases. > Maybe we just don't care about those, but I don't think that's my call. Migration/upgrade path is only provided for 2010.1 and 2010.2. So you should be able to drop everything that is related to older releases (if that's secure enough). (In reply to comment #32) > And I'm pretty sure all the people who could have ordered that are here: > romain, anne (but Frederic) "Ordered" is a big word for that :-) Anyway. The only reason I can remember of is to be sure that a client doesn't accept as valid an answer that does not come from a certified, known server (hence the SSL certificate - but is it checked really? one problem at a time, so let's leave this for another bug)
Yep only 2010.1 and 2010.2 are supported for upgrade. So we can go on on this and clean sources. Thierry can you do it please ? Would be nice to have something working by friday so that we have time to test
Well, why not wait after Mageia 1 release? It's safer... WDYT?Simpsons.S22E21.avi
(In reply to comment #36) > Well, why not wait after Mageia 1 release? > It's safer... WDYT?Simpsons.S22E21.avi why not indeed. Does it work in current state? I mean upgrade ?
Romain: could you add support for --testing on the server side? It means having not only 'http://mirrors.mageia.org/api/FOOBAR' but also 'http://mirrors.mageia.org/api/testing-FOOBAR' This enables to support "mgaapplet --testing" like in MDV. To Nicolas Vigier: Also, mirrors.mageia.org still doesn't support https whereas the installer uses to rely on https
mirrors.mageia.org is now available in https, with http redirected to https.
(In reply to comment #38) * https://releases.mageia.org/api/a/testing-i586 * https://releases.mageia.org/api/a/testing-x86_64 (coming in a few minutes)
(In reply to comment #39) > mirrors.mageia.org is now available in https, with http redirected to https. I reverted the redirection to https, as https is not supported in stage1. And having both http and https is not possible with our current config, so there is no https for now.
I will take a look for http and https, that should just requires some change to puppet manifests.
CC: (none) => marcello.anni
Looks like it's working, I'll make drakx's stage2 (and thus rpmdrake) switch back to https.
(In reply to comment #43) > Looks like it's working, I'll make drakx's stage2 (and thus rpmdrake) > switch back to https. mirrors.mageia.org is not working in https at the moment.
I have a idea, what about doing a reverse proxy on https to http ( or the reverse ) ? This would be ok with the issue of FastCgiServer working only for 1 vhost ? ( reverse proxy like we did for forums on alamut ).
I just tested : - install mgaonline and lauch it - a few after, updates avalaible notified, click on notify link -> nothing happens BUG! - click on RED icon, it works like in Mandriva -> OK So I just see a last bug with notify link in KDE at least not working.
CC: (none) => lists.jjorge
(In reply to comment #37) > Does it work in current state? I mean upgrade ? It didn't for me. It failed - could not find a mirror in MIRRORLIST Running mgaapplet-upgrade-helper --new_distro_version=1 in a terminal, I see cached mirror list uses an old format, invalidating it URPMI_ADDMEDIA_REASON reason=upgrade getting mirror list from https://api.mandriva.com/mirrors/basic.1.i586.list?reason=upgrade Error: mirror list not found What I did was install mgaonline on an up-to-date mdv 2010.1 and re-boot. Is there something more required? It is obviously using the wrong url to get the mirrorlist.
I see that there's a new version of mgaonline on it's way. I'll test it when it reaches the mirrors.
(In reply to comment #47) > It didn't for me. It failed - could not find a mirror in MIRRORLIST > > Running mgaapplet-upgrade-helper --new_distro_version=1 in a terminal, I see > > cached mirror list uses an old format, invalidating it > URPMI_ADDMEDIA_REASON reason=upgrade > getting mirror list from > https://api.mandriva.com/mirrors/basic.1.i586.list?reason=upgrade > Error: mirror list not found Humm, that's because mdv is running its own urpmi where urpm::mirrors::_mandriva_mirrorlist() hardcoded api.mdv.com URL. We should have used a config file for that years ago (but obviosly we failed to forsight a fork...) We can either: - offer a new urpmi with mgaonline for upgrading mdv to mga - patch urpm/mirrors.pm in %post (dirty trick...) WDYT?
CC: (none) => mageia
no possibility to monkeypatch urpm::mirrors, or just a new module placed before in PERL5LIB ? I have more uglier idea, like touching to dns ( /etc/hosts ) to redirect for our server.
I didn't dare suggest that last one :-) (needs for cleaning after...) I think the first idea (live patching) might be the simpler: %post perl -pi -e '$_ = "http://mirrors.mageia.org/api/mageia.\$product_version.\$arch.list" if m!https://api.mandriva.com/mirrors/!' /usr/lib/perl5/vendor_perl/5.*/urpm/mirrors.pm
Live patching of urpm::mirrors looks a bit cleaner. You can get a look at any patch-oem.pl file, or at draklive-install to have an idea of how packages functions can be overriden.
This is offtopic since this is not mgaonline which will use the patched module but other programs (urpmi*)
Just push a new mgaonline, it'll do live patching
The applet still fails of course, since Mageia 1 does not yet exist. Running from a terminal, it does use the correct url to attempt to get the mirrorlist. Using cauldron as the target new_distro_version the upgrade does begin. It is now downloading. I'll report back when it is completed. For future reference, what is the correct designation of the new_distro_version to use when running the upgrade-helper from a terminal, "1" or "stable1"? (There's an empty directory on the mirrors named stable1.) One minor point, since I have a powerpack installation, the applet began by inviting me to add the restricted repo's, presumably because ./MgaOnline/mgaonline is empty. If possible, it might be better to create ./MgaOnline/mgaonline with the line DO_NOT_ASK_FOR_RESTRICTED=true entered by default.
try mgaapplet --testing
The upgrade completed and I re-booted into Mageia. urpmi --auto-update reports that packages are up to date. The limited testing that I've had time to do indicates that the distro-upgrade has been successful.
(In reply to comment #56) > try mgaapplet --testing Thanks. I hadn't thought of that. The system that I used for testing was a "throw-away" that I created for this purpose. I can create another if more testing is required - and I'll keep the --testing option in mind.
Created attachment 459 [details] choose Free / Powerpack
Oups looks like my comment did not appear. On previous screenshot we should remove this step about Free vs Powerpack choice. btw I still have that pb about MIRRORLIST
I think this should have been added here rather than a separate bug :- https://bugs.mageia.org/show_bug.cgi?id=1408
CC: (none) => zen25000
*** Bug 886 has been marked as a duplicate of this bug. ***
CC: (none) => dglent
Guys, 2 days left. Can we check all this is working well now?
I have a testvm for that, so let me summarize : - i install mgaonline rpm ( from where ? ) on mandriva, by rebuilding the srpm from cauldron - I run mgaapplet --testing and that's all ?
you should have a about new mageia. Then just follow what is asked there
I tested on a 2010.0, and all I have is : "this version is no longer maintened", followed by "here is what you can do to fix this : ( ) do not ask me anymore" "[next]" and nothing happen once I click next.
Restarting the applet seemed to solve the issue however, I know have the popup with upgrade choice.
The link "more information about this release" should go to the release note, I think ( it goes to mageia.org right now )
I still see the popup with free/powerpack, and it should indeed be removed, and I also see a error message "cannot find a mirror from the list mirrorlist". Mgaonline complain about some unknow option on the command line ( "nocheck" ). The upgrade didn't start at all.
(In reply to comment #68) > The link "more information about this release" should go to the release note, I > think ( it goes to mageia.org right now ) Will go to the product release page, but still looking for the right URL for that.
Also, choosing Powerpack lead to a question about subscription to mandriva. I think this is not what we want.
Nothing has changed from what I reported in comment 55. It first asks to add restricted repo's, presumably because I have a powerpack installation. I do not see the dialogue offering to upgrade to powerpack perhaps because, since I refused the restricted repo's, the line DO_NOT_ASK_FOR_RESTRICTED=true has now been added to ./MgaOnline/mgaonline. It looks for a mirror at the correct url, but can't find a mirror - is there one for it to find? getting mirror list from http://mirrors.mageia.org/api/mageia.1.i586.list?reason=upgrade retrieved mageia.1.i586.list?reason=upgrade found geolocalisation IE 53.33 -5.75 from timezone Europe/Dublin Fatal: Could not find a mirror from mirrorlist $MIRRORLIST
So, after more debugging, the issue is that update fail because mirrors do not give proper answer for the url http://mirrors.mageia.org/api/mageia.1.i586.list?various_options, and it doesn't answer because the distribution is not released. ( ie, there is no mageia 1 mirror to give )
After forcing it to use a copy of a fake mirrors list, pointing to cauldron, this seems to work. However, it do not seems to be very fast, and the ui disappeared. I see aria2 doing some stuff in the background using ps.
It failed, aria2 was not able to cope with rsync://distrib-coffee, it seems. I try again, hoping it work now.
Ok, it seems that on 2010.0, gurpmi.addmedia --distrib --mirrorlist '$MIRRORLIST' is unable to get media.cfg, I tested with another mirror ( in cae the problem is on d-c side, and it change nothing ). I test with aria2 removed.
After "urpme aria2", it work fine. The vm is being upgraded at the moment.
Depends on: (none) => 1432
Upgade failed, see new bug 1432. The upgrade continue with urpmi --auto-update fine so far.
Created attachment 472 [details] untested patch to disable the powerpack dialog Here is a patch that should disable the dialog for powerpack. I didn't test however, just took a look at the code.
I replaced mandriva-release-powerpack with mandria-release-free and I now see the offer to upgrade to powerpack. I haven't tested Michael's patch - patching perl files is beyond my (very limited) abilities.
(In reply to comment #73) > So, after more debugging, the issue is that update fail because mirrors do not > give proper answer for the url > http://mirrors.mageia.org/api/mageia.1.i586.list?various_options, and it The right URL would be http://mirrors.mageia.org/api/1.i586.list?various_options
The upgrade failed due to not enough disk space. It seems that the system was installed with 4g, and this is not enough for a upgrade ( which mean that there is some rpm bloating the installation ).
(In reply to comment #82) > The upgrade failed due to not enough disk space. It seems that the system was > installed with 4g, and this is not enough for a upgrade ( which mean that there > is some rpm bloating the installation ). Was texlive-texmf installed? It takes ~600MB when installed. And it gets installed w/o no obvious reason. Tested yesterday with RC dvd, choosed LXDE desktop, texlive-texmf got installed and after reboot i was able to remove it. Nothing depends on it, but it takes 300MB on dvd and 600MB on disk, when you use internet it's almost 1GB wasted disk space during upgrade.
I did manage to apply the patch to mgaapplet-upgrade-helper and I no longer see the dialogue offering the upgrade to powerpack. If I switch back to powerpack release and reboot, then the bogus offer to add restricted repo's still appears. Perhaps mgaapplet-add-media-helper needs to be removed from mgaonline or disabled in some way.
That's not texlive. I didn't investigate much, the keyboard of the vm seems messed up ( but this is not caused by the upgrade ), and without {} | and others, my script-fu is weak.
Just push new mgaonline for those fixes
the pb i have with mgaonline is that he tells me that the maintenance is over on my mandriva instead of telling me that mageia 1 is ready and that i can update the distribution.
which should be fixed with new .27 release
(In reply to comment #81) > (In reply to comment #73) > > So, after more debugging, the issue is that update fail because mirrors do not > > give proper answer for the url > > http://mirrors.mageia.org/api/mageia.1.i586.list?various_options, and it > > The right URL would be > http://mirrors.mageia.org/api/1.i586.list?various_options NO, this is wrong. this url is broken, it mixes both i586 and x86_64 in the same list and is missing version and arch info, so it completely breaks mgaonline and urpmi. What's more, it introduces and url mismatch compared to urpmi/rpmdrake/stage1/stage2/ ... and will be overwritten by rpm when urpmi gets installed/updated... So I have reverted the url change in mgaonline-2.77.27-2.mga1 An other thing I noticed in mgaonline spec is that it builds with: make PREFIX=$RPM_BUILD_ROOT MANDRIVA_VERSION=%{mandriva_release} install and building that on mageia, %{mandriva_release} evalutes to 1. I wonder if that messes up something... Will check more tomorrow, when I test upgrades.
CC: (none) => tmb
Testing the .27.2 release 1. On a powerpack system, the bogus invitation to add restricted repo's no longer appears. 2. On a Free system, I still get the dialogue inviting me to upgrade to powerpack. 3. I am not sure if it's using the correct url to get the mirror list or not: getting mirror list from http://mirrors.mageia.org/api/mageia.1.i586.list?reason=upgrade retrieved mageia.1.i586.list?reason=upgrade found geolocalisation IE 53.33 -5.75 from timezone Europe/Dublin Fatal: Could not find a mirror from mirrorlist $MIRRORLIST I got identical results with .27.1.
(In reply to comment #89) > (In reply to comment #81) > > The right URL would be > > http://mirrors.mageia.org/api/1.i586.list?various_options > > NO, this is wrong. this url is broken, it mixes both i586 and x86_64 in the > same list and is missing version and arch info, so it completely breaks > mgaonline and urpmi. This URL is right - that's the format expected. What gets published by it is something else, and indeed, mixes 32/64. Not good. > and building that on mageia, %{mandriva_release} evalutes to 1. > I wonder if that messes up something... Why? That's the version number. (In reply to comment #90) > 3. I am not sure if it's using the correct url to get the mirror list or not: > > getting mirror list from > http://mirrors.mageia.org/api/mageia.1.i586.list?reason=upgrade > retrieved mageia.1.i586.list?reason=upgrade > found geolocalisation IE 53.33 -5.75 from timezone Europe/Dublin > Fatal: Could not find a mirror from mirrorlist $MIRRORLIST Sure, this URL does not work. The URL format to query is: mirrors/api/{version}.{arch}.list?reason={reason} so it's, in our case, mirrors/api/1.i586.list?reason=upgrade or mirrors/api/1.x86_64.list?reason=update depending on the situation.
(In reply to comment #91) > (In reply to comment #89) > > (In reply to comment #81) > > > The right URL would be > > > http://mirrors.mageia.org/api/1.i586.list?various_options > > > > NO, this is wrong. this url is broken, it mixes both i586 and x86_64 in the > > same list and is missing version and arch info, so it completely breaks > > mgaonline and urpmi. > > This URL is right - that's the format expected. What gets published by it is > something else, and indeed, mixes 32/64. Not good. > But we are in _release_freeze_ and mirrors.mageia.org/api is part of the freeze so you cant change it at this point. as already stated, stage1/2 and urpmi tools have http://mirrors.mageia.org/api/mageia.{version}.{arch}.list hardcoded, so mgaonline need to follow > > (In reply to comment #90) > > 3. I am not sure if it's using the correct url to get the mirror list or not: > > > > getting mirror list from > > http://mirrors.mageia.org/api/mageia.1.i586.list?reason=upgrade > > retrieved mageia.1.i586.list?reason=upgrade > > found geolocalisation IE 53.33 -5.75 from timezone Europe/Dublin > > Fatal: Could not find a mirror from mirrorlist $MIRRORLIST > > Sure, this URL does not work. > So fix it to respond properly then! -- Thomas
Depends on: (none) => 1458
(In reply to comment #92) > > This URL is right - that's the format expected. What gets published by it is > > something else, and indeed, mixes 32/64. Not good. > > But we are in _release_freeze_ > > and mirrors.mageia.org/api is part of the freeze so you cant change it at this > point. Services such as this one don't have the same life cycle as the shipped distribution so we can fix those at any time. > as already stated, stage1/2 and urpmi tools have > http://mirrors.mageia.org/api/mageia.{version}.{arch}.list hardcoded, so > mgaonline need to follow And no one realized that these URL just don't work at all at this point? so we need more testing. So we will fix that by symlinking/duplicating this server-side but this will need to be fixed in later releases. As for actually fixing it, this involves two things: * answering the /api/mageia.1.i586.list path (see bug 1458) * sorting i586 from x86_64 (see bug 1457)
Depends on: (none) => 1457
api server is now fixed for http://mirrors.mageia.org/api/mageia.1.x86_64.list http://mirrors.mageia.org/api/mageia.1.i586.list It currently only shows two servers and we have faked it so version 1 points to cauldron in the above url lists, but it should now be possible to test mgaonline-2.77.27-2.mga1
It now downloads the hdlists, but fails with: "Unable to add medium, errors reported: unable to import pubkey file of "Core Updates" unable to import pubkey file of "Core Updates Debug" unable to import pubkey file of "Nonfree Updates" unable to import pubkey file of "Nonfree Updates Debug" unable to import pubkey file of "Tainted Updates" unable to import pubkey file of "Tainted Updates Debug" and finally: "Failure when adding medium" This could be similar to the problem that was encountered on mdv, when an attempt was made to offer an automatic upgrade from cooker to stable. (IIRC pubkeys are not automatically imported when sources are changed.) In case it's forgotten, the patch mentioned in comment 79 (or something equivalent) needs to be committed to SVN (or wherever these things are done) to prevent the display of the offer to upgrade to powerpack. The patch seemed to work when I applied it locally.
(In reply to comment #95) > It now downloads the hdlists, but fails with: > > "Unable to add medium, errors reported: > > unable to import pubkey file of "Core Updates" > unable to import pubkey file of "Core Updates Debug" > unable to import pubkey file of "Nonfree Updates" > unable to import pubkey file of "Nonfree Updates Debug" > unable to import pubkey file of "Tainted Updates" > unable to import pubkey file of "Tainted Updates Debug" > > and finally: > > "Failure when adding medium" > > This could be similar to the problem that was encountered on mdv, when an > attempt was made to offer an automatic upgrade from cooker to stable. (IIRC > pubkeys are not automatically imported when sources are changed.) > Nope, just checked... the pubkey is actually missing on the mirrors for those medias... I'll fix it > In case it's forgotten, the patch mentioned in comment 79 (or something > equivalent) needs to be committed to SVN (or wherever these things are done) to > prevent the display of the offer to upgrade to powerpack. The patch seemed to > work when I applied it locally. I'll verify it here too, and apply it after if it works for me too..
(In reply to comment #96) > > > > This could be similar to the problem that was encountered on mdv, when an > > attempt was made to offer an automatic upgrade from cooker to stable. (IIRC > > pubkeys are not automatically imported when sources are changed.) > > > > > Nope, just checked... > the pubkey is actually missing on the mirrors for those medias... > I'll fix it > > I just realised that myself and was about to post a comment. You beat me to it.
pubkeys are fixed on primary mirrors a few hours ago, and should show up on mirrors as soon as they sync And patch in comment 79 works to silence stuff about powerpack But then we hit a problem. mgaonline reads version from host, so it will suggest 2010.1 or 2010.2 to the mageia api server: http://mirrors.mageia.org/api/mageia.2010.2.x86_64.list?reason=upgrade but we only have versions cauldron and 1 (obviously) so either we add check for 2010.1 / 2010.2 in mgaonline and replace it with 1 before polling mageia api Other way to fix is on mageia api server, with symlinks from *.2010.1/2.* to 1
Never mind... it works if it starts from mgaapplet. it was only when started manually it got wrong version I'll submit a fixed mgaonline in a little while
A fixed mgaonline-2.77.28-1.mga1 is now uploaded and should be available on mirrors soon. It's also available here: http://bcd.mageia.org/mgaonline-2.77.28-1.mga1.noarch.rpm
Testing 28-1 I just let it run to completion. It appears to have worked fine - I have a usable Mageia system. It's too late in the day to do anything further. If I have time I'll do a bit more checking of this system, probably not before Monday.
Tested here on 2010.1 with KDE and GNOME installed. No problem, upgrade went smoothly
Closing as fixed as it's confirmed that both i586 and x86_64 upgrades work.
Status: NEW => RESOLVEDResolution: (none) => FIXED
CC: boklm => (none)