Created attachment 4064 [details]
urpmi.cfg after adding mga3 online media

LC_ALL=C urpmi.addmedia --distrib ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/3/x86_64

Nicolas, this seems to be related to the buildsystem updates you pushed efter mga3 Before cauldron reopened...

It also  have added all 32bit medias to 64bit media.cfg on already released trees that were supposed to be static.

CC: (none) => tmb
Assignee: bugsquad => boklm

I just done an installation from DVD i586.
I added the repositories after the restart.
Some repositories were enabled by default which I consider that there should not:
NonFree Backports (all)
Nonfree Release Debug
Nonfree Release Sources
Nonfree Updates Debug
Nonfree Updates Sources
Nonfree Updates Testing
Nonfree Updates Testing Debug

backports are also sorted before Release

Papoteur

CC: (none) => yves.brungard_mageia

>Some repositories were enabled by default which I consider that there should not
this was already fixed: bug 10254

Looking more carefully at differences between mga1 media.cfg (original format) and mga 2, 3 or cauldron media.cfg (new format recently changed), the media order isn't the only change.
There are changes in the format of each entry in 2 key names:
media_type -> media_types   (probably origin of bug 10254)
hdlist -> hdlists

CCing tv, as media.cfg format and urpmi/drakrpm code should be sync. These changes could trigger bug elsewhere (perhaps in mga2 too).

CC: (none) => thierry.vignaud

and be careful, classical installer iso uses the original format for media.cfg;hdlist in the singular, luckily media_type isn't used.

CC: (none) => ennael1

yep, the media.cfg change was unitentional, boklm is working on reverting it to proper state

(In reply to Thomas Backlund from comment #7)
> yep, the media.cfg change was unitentional, boklm is working on reverting it
> to proper state

if media_type -> media_types is reverted
- urpmi svn rev. 8361 must be reverted accordingly, and a new update released
http://svnweb.mageia.org/soft?view=revision&revision=8361
- new mga3 isos shouldn't use urpmi-7.27.2-1

Oops, I already reverted media_type -> media_types.

I now updated it again to include both media_types and media_type, until a new urpmi update is released.

And what about bloating x86_64 media.cfg with all 32bit medias?

and the media sorting is still a mess.

This is why having static files in svn for things that dont (and shouldn't) change instead of dynamic generation...

not to mention it made a mess of mga2 media.cfg too...

Created attachment 4071 [details]
urpmi.cfg after install using Mageia 3.1 dual-cd

Online repos were added by selecting a mirror after formatting filesystems.
Online media was added again, when checking for updates.
Order is a complete mess.

CC: (none) => davidwhodgins

after last media.cfg update (currenly mirroring out), it shows:
$ grep "name" /mnt/data/Linux/Mageia/3/x86_64/media/media_info/media.cfg
name=Core Release
name=Core Release Debug
name=Core Release Sources
name=Core 32bit Release
name=Core Updates
name=Core Updates Debug
name=Core Updates Sources
name=Core 32bit Updates
name=Core Updates Testing
name=Core Updates Testing Debug
name=Core Updates Testing Sources
name=Core 32bit Updates Testing
name=Core Backports
name=Core Backports Debug
name=Core Backports Sources
name=Core 32bit Backports
name=Core Backports Testing
name=Core Backports Testing Debug
name=Core Backports Testing Sources
name=Core 32bit Backports Testing
name=Nonfree Release
name=Nonfree Release Debug
name=Nonfree Release Sources
name=Nonfree 32bit Release
name=Nonfree Updates
name=Nonfree Updates Debug
name=Nonfree Updates Sources
name=Nonfree 32bit Updates
name=Nonfree Updates Testing
name=Nonfree Updates Testing Debug
name=Nonfree Updates Testing Sources
name=Nonfree 32bit Updates Testing
name=Nonfree Backports
name=Nonfree Backports Debug
name=Nonfree Backports Sources
name=Nonfree 32bit Backports
name=Nonfree Backports Testing
name=Nonfree Backports Testing Debug
name=Nonfree Backports Testing Sources
name=Nonfree 32bit Backports Testing
name=Tainted Release
name=Tainted Release Debug
name=Tainted Release Sources
name=Tainted 32bit Release
name=Tainted Updates
name=Tainted Updates Debug
name=Tainted Updates Sources
name=Tainted 32bit Updates
name=Tainted Updates Testing
name=Tainted Updates Testing Debug
name=Tainted Updates Testing Sources
name=Tainted 32bit Updates Testing
name=Tainted Backports
name=Tainted Backports Debug
name=Tainted Backports Sources
name=Tainted 32bit Backports
name=Tainted Backports Testing
name=Tainted Backports Testing Debug
name=Tainted Backports Testing Sources
name=Tainted 32bit Backports Testing


So it's a little bit better, but still 32bit medias makes a mess all over...

(In reply to Thomas Backlund from comment #10)
> And what about bloating x86_64 media.cfg with all 32bit medias?

What are the 32bit medias that shouldn't be in x86_64 media.cfg ?

> 
> and the media sorting is still a mess.

media sorting should be fixed now.

> 
> This is why having static files in svn for things that dont (and shouldn't)
> change instead of dynamic generation...

This allows adding a new version or new repo automatically, and should be useful also for installing a test buildsystem. And shouldn't be a problem if done correctly. Problem was that I committed the changes and applied them too quickly to reopen cauldron without taking enough time to review the changes to media.cfg :/

> 
> not to mention it made a mess of mga2 media.cfg too...

I can revert to static version for mga2 media.cfg. Some backups of the files are in /root/backup-20130523.

Created attachment 4072 [details]
report.bug.gz

(In reply to Nicolas Vigier from comment #13)
> (In reply to Thomas Backlund from comment #10)
> > And what about bloating x86_64 media.cfg with all 32bit medias?
> 
> What are the 32bit medias that shouldn't be in x86_64 media.cfg ?
> 

Well,  normally we have only added 32bit core on x86_64...
I do know some people want us to add them all making it easier for
people running 32bit nonfree/tainted stuff...

> > 
> > and the media sorting is still a mess.
> 
> media sorting should be fixed now.
> 

almost, as shown in c12....
> > 
> > This is why having static files in svn for things that dont (and shouldn't)
> > change instead of dynamic generation...
> 
> This allows adding a new version or new repo automatically, and should be
> useful also for installing a test buildsystem. And shouldn't be a problem if
> done correctly. Problem was that I committed the changes and applied them
> too quickly to reopen cauldron without taking enough time to review the
> changes to media.cfg :/
> 

Yeah, I understand the idea, but it should not change media.cfg on an already released media...

> > 
> > not to mention it made a mess of mga2 media.cfg too...
> 
> I can revert to static version for mga2 media.cfg. Some backups of the files
> are in /root/backup-20130523.

Either that, or fix the code to do media.cfg on repo bases, so changing stuff in cauldron does not mirror down to stable releases....

While testing the i586 3.1 dvd iso, I noticed
that when adding the online media, at the start
of the install, even though nonfree release
from the iso was selected, the nonfree release,
and updates from the added repo wasn't added.

While I could have manually selected them at
that point, I think they should be preselected.

Leaving them as is, after reboot, I have ...
urpmq --list-media active
Core Release
Nonfree Release
Core Release2
Core Updates
Core Release3
Core Updates2
Nonfree Release3
Nonfree Updates2

So the nonfree release and updates were enabled,
when the second full set of repos were added,
when checking for updates, but not when adding
the media before installing updates.

Ok,so reading this and the releated issues, here is the mess:

1. Mageia 3 urpmi was ok at release time.
2. then media.cfg was altered on mga2/mga3 as a side effect of BS updates.
3. now we got reports of urpmi adding too much medias (#10254)
4. tv fixed it, and we released MGAA-2013-0022.
5. now it was realized stage2 and urpmi on isos was "broken"
6. new isos are being done for urpmi and product.id ...

But this BR shows we have more breakages.

So I think the correct fixes to get out of this mess is:

1. revert media.cfg to mga3 release state.
2. revert/fix #10254 fix / MGAA-2013-0022
3. remove stage2 build from updates_testing and frozen iso tree.
4. only release new classical isos with the original urpmi and fixed product.id

That way we dont have to respin new live isos and do QA on them, only the traditional ones

anne, tv... any thoughts on this ?

media.cfg on mga3 now sorted...

It still has:
- both "media_type" and "media_types"
- all 32bit medias listed at end of list


for now I left all 32bit medias in that list as that has been a longstanding request (IIRC there is also a bugreport about it), but do we want it ?

Did I say I hate you :-(?
What's worse for me is I knew it worked fine previously but I doubted when I compared media.cfg with older releases.

We've messed several times for this release, I think we should document more things (like Warly did when he left mdv).

I just pushed urpmi.

Hate away ...

There is many things to improve for next releases like making sure next RC is actually an RC, being stricter about what we allow to happend when we do version and release freeze, feature implementation and so on...

but back to the on-topic issue...

I've submitted a new stage2 build to the mirrors to pick up the 7.27.3 urpmi, as I think it's still important for the new classical installer as it has the:

o ensure priority updates are installed in a single transaction

fix on it which I think can still be important ...

and ennael can add the fixed urpmi *7.27.3* to repo before respinning the isos one last time.

Then after urpmi 7.27.3 is validated and pushed to updates, we drop the "media_types" line in media.cfg 

And after new mga3 isos are released, we wait a few days or a week, then remove
the redirection of releases.mageia.org/api/* for cauldron to mga3 tree that was
put in place to minimize the wrong product.id damage.

does that sound like a good plan ?

I think so. As say by email you can just delete the updates_testing/*stage2* use he core/release one.

I don't know whether to mention this here or create a new bug for it.

The latest classic i586 DVD from today is still adding medias twice during install. Once with a specific mirror when choosing to add medias before package installation and again from mirrorlist when checking for updates towards the end of installation.

Combined with the cdrom itself it actually ends up with 3 sets of medias for Core Release & Nonfree release.

I'll add the log file.

Created attachment 4080 [details]
report.bug.xz classic dvd i586 from 30th may

Created attachment 4081 [details]
urpmq-dump-config.txt classic dvd i586 from 30th may

urpmq --dump-config > urpmq-dump-config.txt

Taken after installation i586 classic dvd from 30th May

media.cfg is fixed for mga2

for mga3, order of media is fixed, but there still are some regressions:
- on x86_64, 'updates_for' keys are missing for "Core 32bit Updates", "Nonfree 32bit Updates" and "Tainted 32bit Updates", thus these media are enabled but not flagged as 'update' media. This is a major regression that must be fixed.

- hdlist -> hdlists was not reverted; hdlist key name is still in the plural.

- on x86_64, debug media are not available for 32bit media (not consistent with 64bit media, previously we had only 32 bit for core including debug media), but I'm not sure that we should add them, as we already have lots of media.

Whiteboard: MGA2TOO => (none)

Indeed. I'll fix up the media.cfg on x86_64

Created attachment 4082 [details]
Compressed ddebug.log

Note: I manually enabled nonfree release2, and nonfree updates.

Created attachment 4094 [details]
Compressed ddebug.log

Using the Mageia-3-i586-DVD from Sun Jun 2 22:66:25 CEST 2013, there are
still 3 problems that only affect installations done with online media
added at the beginning of the installation.

Nonfree Release from the media is pre-selected, but Nonfree Release2 and
Nonfree Updates from the online media is not pre-selected.

Artwork is not shown during package installation, unless the "No details"
button is pressed.

After the summary screen, by default the install will check for updates,
and while doing so, will add a second set of online media.

If the Nonfree Release2 and Nonfree Updates are manually selected, after
reboot, everything looks good, except for having two full sets of online
repos.

this one was fixed (media.cfg), (32bit are still added too but as it seems that nobody was offend)

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