Bug 8157 - bugfix request: downloading all rpms option in mgaonline (for upgrade)
Summary: bugfix request: downloading all rpms option in mgaonline (for upgrade)
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 2
Hardware: All Linux
Priority: release_blocker major
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords:
: 8595 (view as bug list)
Depends on: 6061 9744
Blocks: 8016
  Show dependency treegraph
 
Reported: 2012-11-19 20:43 CET by Manuel Hiebel
Modified: 2013-05-16 01:24 CEST (History)
9 users (show)

See Also:
Source RPM: mgaonline
CVE:
Status comment:


Attachments

Description Manuel Hiebel 2012-11-19 20:43:55 CET
+++ This bug was initially created as a clone of Bug #6083 +++

Description of problem:
1.From an updated 1, click on upgrade, ask to download all before install.
2.Then select where to download, I choose my home downloads directory.
3. Click "next", it fails saying the owner of the directory is not good.

End of the log :
....
webkit-1.8.1-1.mga2.x86_64
webkit1.0-1.8.1-1.mga2.x86_64
(118 paquetages, 279 Mo)
=> ok(auto)
Vidage du répertoire /var/cache/urpmi/partial et de /var/cache/urpmi/rpms
propriétaire invalide pour le répertoire /home/jose/Téléchargements
unlocking rpm database
unlocking urpmi database

was fixed with:
http://svnweb.mageia.org/soft?view=revision&revision=5737
http://svnweb.mageia.org/soft?view=revision&revision=5741
but seems it was not yet backported

thanks
Manuel Hiebel 2012-11-19 20:44:58 CET

Assignee: bugsquad => thierry.vignaud
Summary: backport request, bugfix for download all rpm option in mgaonline => backport request: bugfix, downloading all rpms option in mgaonline

Manuel Hiebel 2013-01-04 18:08:10 CET

Priority: Normal => release_blocker

Comment 1 Manuel Hiebel 2013-01-04 18:08:23 CET
*** Bug 8595 has been marked as a duplicate of this bug. ***

CC: (none) => info

Manuel Hiebel 2013-02-14 17:45:20 CET

Summary: backport request: bugfix, downloading all rpms option in mgaonline => bugfix request: downloading all rpms option in mgaonline (for upgrade)

Comment 2 Manuel Hiebel 2013-03-13 21:47:57 CET
it would be better to have that before may and with patch from bug 6061 too

Depends on: (none) => 6061

Comment 3 Marja Van Waes 2013-04-05 14:01:42 CEST
cc'ing QA and docteam (because Trish asked docteam to review 
https://wiki.mageia.org/en/Mageia_2_Release_Notes#Upgrading_from_Mageia_1 for upgrading from Mageia 2 to 3 and without help from at least QA team, docteam won't manage to correctly update the text)

CC: (none) => doc-bugs, marja11, qa-bugs

Comment 4 AL13N 2013-04-23 13:18:31 CEST
if this isn't gonna get fixed, maybe we can just update errata and drop priority

CC: (none) => alien

Comment 5 Dave Hodgins 2013-04-23 20:01:01 CEST
I think an errata entry stating that if you choose to download all of the
packages, before upgrade, the directory used must be owned by root.

CC: (none) => davidwhodgins

Comment 6 Manuel Hiebel 2013-04-23 21:39:00 CEST
well I copy same text in release notes from mga2 to mga3, but as we have already a fix..
Comment 7 AL13N 2013-05-02 20:02:25 CEST
did this fix work?
Comment 8 Sander Lepik 2013-05-10 09:12:03 CEST
I see that the commit adds error message, but I think it's not even translated. So we probably can't backport it anyway. Correct me if I'm missing something.

CC: (none) => sander.lepik

Comment 9 Colin Guthrie 2013-05-14 11:08:04 CEST
FWIW, the commit http://svnweb.mageia.org/soft?view=revision&revision=5741 is wrong. That does does not check that it is "owned by root" as the commit message says, it checks that it is writable by the current user.

In the context of when that code is run, the "user" will be unprivileged. The default folder is /var/cache/urpmi and as a result, the user cannot write and the test fails.

I fixed that issue here:
http://svnweb.mageia.org/soft/mgaonline/trunk/mgaapplet?r1=8092&r2=8223

This checks that the folder is owned by root. Of course the user may not be able to access all folders owned by root, (due to directory permissions) so this is a bit of a strange place to do the selection and the test, but such is life.

CC: (none) => mageia

Comment 10 Colin Guthrie 2013-05-14 11:26:04 CEST
So looking at the code in rpmdrake open_db.pm, the option will ONLY be shown for Cauldron -> mgaN upgrades. It will NOT be shown for mgaN -> mgaN+1 upgrades.

This seems wrong to me - shouldn't the option always be present? Perhaps someone just forgot to remove some testing code before release?
Comment 11 Colin Guthrie 2013-05-14 11:28:39 CEST
Just out of curiosity, can anyone else on this bug report even select the option to download all? Looking at the comments above it seems so, but in both my experience and looking at the code, I cannot see how this is possible. AFAICT, the option just isn't presented unless the current install is cauldron... can someone clarify?

I think the fix here is just to remove the the is_download_all_enabled() check.
Comment 12 Manuel Hiebel 2013-05-14 19:19:34 CEST
hum indeed with the last mgaonline from testing, the running mgaapplet --testing
I got nothing regarding folder before downloading first perl packages (then I stopped it here)

seems also mga-prepare-upgrade was not installed, I will check in a vm if I have time
Comment 13 Colin Guthrie 2013-05-14 19:24:03 CEST
(In reply to Manuel Hiebel from comment #12)
> hum indeed with the last mgaonline from testing, the running mgaapplet
> --testing
> I got nothing regarding folder before downloading first perl packages (then
> I stopped it here)

The code looks pretty clear, it should only give you the option if you are going from a devel system (e.g. /etc/product.id has "branch=Devel" in it).

So if you've seen it before, perhaps you were on a devel release rather than an official one?

You should be able to hack your product.id appropriately.

> seems also mga-prepare-upgrade was not installed, I will check in a vm if I
> have time

If you pass --testing, it has the effect of making the ensure_is_installed() calls No Ops. You simply cannot use --testing with mgaonline if you want it to actually do stuff. Just put TEST_DISTRO_UPGRADE=YES in /etc/sysconfig/mgaapplet and let it run as normal to do distro upgrade tests.
Comment 14 Manuel Hiebel 2013-05-14 19:27:37 CEST
(In reply to Colin Guthrie from comment #13)
> (In reply to Manuel Hiebel from comment #12)
> > hum indeed with the last mgaonline from testing, the running mgaapplet
> > --testing
> > I got nothing regarding folder before downloading first perl packages (then
> > I stopped it here)
> 
> The code looks pretty clear, it should only give you the option if you are
> going from a devel system (e.g. /etc/product.id has "branch=Devel" in it).
> 
> So if you've seen it before, perhaps you were on a devel release rather than
> an official one?
> 
> You should be able to hack your product.id appropriately.

Arf this was always working, it also added cauldron mirrors 

$ cat /etc/product.id
vendor=Mageia.Org,distribution=Mageia,type=Basic,version=2,branch=Official,release=1,arch=x86_64,product=Default

(In reply to Colin Guthrie from comment #13)
> > seems also mga-prepare-upgrade was not installed, I will check in a vm if I
> > have time
> 
> If you pass --testing, it has the effect of making the ensure_is_installed()
> calls No Ops. You simply cannot use --testing with mgaonline if you want it
> to actually do stuff. Just put TEST_DISTRO_UPGRADE=YES in
> /etc/sysconfig/mgaapplet and let it run as normal to do distro upgrade tests.

ok didn't know will try
Comment 15 Colin Guthrie 2013-05-14 19:35:01 CEST
(In reply to Manuel Hiebel from comment #14)
> (In reply to Colin Guthrie from comment #13)
> > (In reply to Manuel Hiebel from comment #12)
> > > hum indeed with the last mgaonline from testing, the running mgaapplet
> > > --testing
> > > I got nothing regarding folder before downloading first perl packages (then
> > > I stopped it here)
> > 
> > The code looks pretty clear, it should only give you the option if you are
> > going from a devel system (e.g. /etc/product.id has "branch=Devel" in it).
> > 
> > So if you've seen it before, perhaps you were on a devel release rather than
> > an official one?
> > 
> > You should be able to hack your product.id appropriately.
> 
> Arf this was always working, it also added cauldron mirrors 

Well all I can tell you is what the code says:

The elements are only added to the form if the function "is_download_all_enabled()" returns true:
http://svnweb.mageia.org/soft/mgaonline/trunk/mgaapplet?revision=8223&view=markup#l417

The function is_download_all_enabled() is just a passthrough to is_it_a_devel_distro():
http://svnweb.mageia.org/soft/mgaonline/trunk/mgaapplet?revision=8223&view=markup#l386

And is_it_a_devel_distro() is defined as:
http://svnweb.mageia.org/soft/rpmdrake/trunk/Rpmdrake/open_db.pm?revision=3875&view=markup#l119

This is the code flow, and that's how it works.

Perhaps this bug was introduced here:
http://svnweb.mageia.org/soft?view=revision&revision=3432

When the is_download_all_enabled() check was changed? 

As I've stated before both in bugs and on the ML, I'm pretty sure we should just drop that whole check and always enable the option!
Comment 16 Manuel Hiebel 2013-05-14 21:22:08 CEST
(In reply to Colin Guthrie from comment #11)
> Just out of curiosity, can anyone else on this bug report even select the
> option to download all? Looking at the comments above it seems so, but in
> both my experience and looking at the code, I cannot see how this is
> possible. AFAICT, the option just isn't presented unless the current install
> is cauldron... can someone clarify?
> 
> I think the fix here is just to remove the the is_download_all_enabled()
> check.

Same situation as you it directly download the rpm without asking anymore, or you wanted a test with the mgaonlive from core ?
Comment 17 Colin Guthrie 2013-05-14 21:30:51 CEST
That's fine, thank you. I just thought I was going insane as it didn't make sense to me that anyone on mga2 could see this box! but then I guess that's what this whole bugfix is about. I think I'll take an exec decision here and just nuke the function is_download_all_enabled() and then backport that fix to my testing package. 

If it's wrong I'll be judged and mocked later but I have thick skin ;)
Comment 18 Colin Guthrie 2013-05-14 22:11:04 CEST
OK, this option should now be available in the latest testing mgaonline in mga2 updates_testing.
Comment 19 Manuel Hiebel 2013-05-15 00:47:13 CEST
(In reply to Colin Guthrie from comment #18)
> OK, this option should now be available in the latest testing mgaonline in
> mga2 updates_testing.

yep it's now here, but I still get "invalid owner for directory /media/data/upgrade" chown as manu, if I change it to root it works

http://svnweb.mageia.org/soft/rpm/urpmi/trunk/urpm.pm?view=markup#l195


But even with patching with http://svnweb.mageia.org/soft?view=revision&revision=5737 and http://svnweb.mageia.org/soft?view=revision&revision=5741 it's same, but regarding code, it's seems to only add a warning popup (what I see) 
which could be enough. Maybe also add one line explanation how to change the owner in the popup ?

then maybe i18n could check string, I saw also one not translated on your new part (before the install of the prepare rpm)
Comment 20 Colin Guthrie 2013-05-15 21:03:07 CEST
Gah, I actually forgot all about the patches this bug actually mentions!!!

I've now backported http://svnweb.mageia.org/soft?view=revision&revision=5741 as requested. I did not backport the urpm change as I instead took a bunch of other patches I added to mgaonline trunk which subsequently removed that code because it's (as far as I can tell) incorrect.

The urpmi check_dir() call checks to see if the folder is writeable by the current user, NOT that it is owned by root. This has the effect of immediately erroring out with the default value of /usr/cache/urpmi. With my patches this is avoided.

Fingers crossed this is a good version for you :)
Comment 21 Manuel Hiebel 2013-05-16 00:57:46 CEST
indeed this is even better than before so all is ok for me, many thanks.

I don't know, do you have already a updates request bug ?

Source RPM: mgaonline,urpmi => mgaonline

Comment 22 Colin Guthrie 2013-05-16 01:19:50 CEST
Well there is a bug to track about pushing new mgaonline to mga2 in the form of bug #9744 It's not strictly speaking an upgrade request yet tho'. We will likely push at the same time as mageia 3 is ready the old version won't "see" Mageia 3 until mgaonline is updated anyway so users won't get to use the non-updated version :)

There is still the problem of i18n tho'....
Comment 23 Manuel Hiebel 2013-05-16 01:24:54 CEST
and yes 
we can ping i18n in the other

Status: NEW => RESOLVED
Depends on: (none) => 9744
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.