As is currently being discussed in #anaconda, changing lorax may not be entirely sufficient. Live media creation will probably still fail as it does not use the lorax-generated environment.

I guess I'll file a new bug for that.

Filed https://bugzilla.redhat.com/show_bug.cgi?id=1312951 for the live media case.

The glibc team is working to put out an ASAP update that would use a slightly tweaked set of rpm dependencies to ensure glibc-all-lanpacks is pulled in by default in more cases.

Does Anaconda actually need *all* the locales?

https://github.com/rhinstaller/anaconda/pull/531 should make things behave a bit better on the anaconda side.

(In reply to Carlos O'Donell from comment #4)
> Does Anaconda actually need *all* the locales?

Are you saying we should pick and choose which locale data and languages we actually need? That sounds super annoying.

This isn't just about language. The locale chosen by the user affects the behavior of several aspects of the install, like text direction and time display, so yeah, it'd be nice to have all of them.

I'm guessing that in theory anaconda only needs the locales relevant to the languages it offers. However, as David says, I think trying to make the dependency that specific would be difficult in practice (the anaconda language support list, IIRC, is actually dynamically generated based on the translation status in Zanata).

If there's going to be some sort of 'all the remotely sane langpacks' virtual package or something, that would probably work for anaconda in practice? But it's hard to be sure how to answer your question.

(In reply to Adam Williamson from comment #6)
> I'm guessing that in theory anaconda only needs the locales relevant to the
> languages it offers. However, as David says, I think trying to make the
> dependency that specific would be difficult in practice (the anaconda
> language support list, IIRC, is actually dynamically generated based on the
> translation status in Zanata).
> 
> If there's going to be some sort of 'all the remotely sane langpacks'
> virtual package or something, that would probably work for anaconda in
> practice? But it's hard to be sure how to answer your question.

You answered my question. The `glibc-all-langpacks` is the virtual "provide everything and the kitchen sink", and that's what Anaconda should use. It provides all the locales in a minimized form.

With glibc-2.23.90-3.fc25 and glibc-2.23.1-5.fc24 we have now fixed
the issue in several important ways.

See:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WXOOUGA3YCB2O4O77JGLSJZ25BS4RFK5/

You should now always get glibc-all-langpacks by default.

(In reply to Carlos O'Donell from comment #8)
> With glibc-2.23.90-3.fc25 and glibc-2.23.1-5.fc24 we have now fixed
> the issue in several important ways.
> 
> See:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> message/WXOOUGA3YCB2O4O77JGLSJZ25BS4RFK5/
> 
> You should now always get glibc-all-langpacks by default.

When this bugfix be applied for Rawhide ISO image?

Bodhi is not enabled for F24 ATM, so the next F24 and Rawhide composes that happen should include it (in fact they may have happened since Carlos posted his comment)...

current Rawhide and Branched nightlies are still hitting this, so I don't think the changes to the glibc package help the anaconda environment case. bcl, could you please do F24 and Rawhide builds of lorax so we can get past this bug? until this is fixed we really can't tell what all else is still broken in F24/Rawhide with the compose process changes and so on, because all our tests blow up right away. thanks!

(In reply to Adam Williamson from comment #11)
> current Rawhide and Branched nightlies are still hitting this, so I don't
> think the changes to the glibc package help the anaconda environment case.
> bcl, could you please do F24 and Rawhide builds of lorax so we can get past
> this bug? until this is fixed we really can't tell what all else is still
> broken in F24/Rawhide with the compose process changes and so on, because
> all our tests blow up right away. thanks!

The changes to f24 and f25 make it a requirement to install glibc with a langpack. The default langpack the dependency solver will use is glibc-all-langpacks because of the suggestion in glibc package.

Could you please verify you actually have glibc-2.23.90-3.fc25 or glibc-2.23.1-5.fc24? Until those two packages enter your builds you'll have problems.

Is there any way I reproduce this on my end to make sure we didn't miss anything?

I built lorax with the glibc-all-langpacks fix last night. So depending on timing of compose vs. build it may have used the old lorax. Check the compose logs to see if the new package was included.

MMMMMMMMM THIS HUMBLE PIE IS DELICIOUS

that'll teach me not to click on thumbnails. turns out the openQA tests for 2016-03-02 weren't failing on the anaconda bug, they were failing because they couldn't find the ISO, and they couldn't find the ISO because some idiot monkey forgot to restart the scheduler after changing the ISO download code...

excuse me while I put some salt on my hat to go with this pie!

now I fixed the scheduler, we have a Rawhide test actually running anaconda:

https://openqa.fedoraproject.org/tests/7016

so it does indeed look like one change or the other fixed this.

I'll just confirm that Branched works too, but this looks good.

For the record, the last tests that actually failed in anaconda were Fedora-24-20160301.n.0:

https://openqa.fedoraproject.org/tests/6634

that tree has lorax-24.13-1.fc25.x86_64.rpm and glibc-2.23.90-2.fc25.i686.rpm , so we can't tell for sure whether glibc change alone would've fixed this from that. If bcl wants to know if he could drop the lorax change, I'll download some ISOs from the composes in the middle if I can find one with the glibc change but not the lorax change and check manually.

damnit, looked at the wrong tree, but same info - it has glibc-2.23.1-4.fc24.x86_64.rpm and lorax-24.13-1.fc24.x86_64.rpm , i.e. the non-fixed package in both cases.

(In reply to Adam Williamson from comment #16)
> damnit, looked at the wrong tree, but same info - it has
> glibc-2.23.1-4.fc24.x86_64.rpm and lorax-24.13-1.fc24.x86_64.rpm , i.e. the
> non-fixed package in both cases.

Right, those are the old glibc packages with the upgrade issues.

F24 compose includes the fixed version as of yesterday:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/AKFL6K2HNWBY6W535OVQW3QIHC2OV2YN/

F25 compose includes the fixed version as of today:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/SFVADLBHDFSXPV3UCQTEHDCTGUMLXEX3/

So you'd have to use the latest composes to get the fix.

right, I've already said the latest trees are fixed. But what I'm trying to determine now is whether the glibc fix was sufficient or if the lorax fix was still needed.

(In reply to Adam Williamson from comment #18)
> right, I've already said the latest trees are fixed. But what I'm trying to
> determine now is whether the glibc fix was sufficient or if the lorax fix
> was still needed.

OK, the glibc fix is sufficient to fix the locale.Error, if it isn't, then I'd like to know and dig deeper. Other issues I can't comment on.

Welp, I've got a ton of stuff on my plate and this is definitely fixed one way or the other, so let's just close it for now.