Bug 989517

Summary: glibc-2.17.90-6.fc20 fails to build with /usr/lib/locale: No such file or directory
Product: [Fedora] Fedora Reporter: Dan Horák <dan>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: codonell, dan, ffesti, fweimer, jakub, jzeleny, law, novyjindrich, ovasik, packaging-team-maint, pfrankli, pknirsch, pmatilai, schwab, spoyarek
Target Milestone: ---   
Target Release: ---   
Hardware: s390x   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-06 21:36:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Horák 2013-07-29 12:27:45 UTC
glibc-2.17.90-6.fc20 fails to build on s390x with
...
++ pwd
+ olddir=/builddir/build/BUILD/glibc-2.17-906-g8ab0740
+ pushd /builddir/build/BUILDROOT/glibc-2.17.90-6.fc20.s390x/usr/lib/locale
/var/tmp/rpm-tmp.5ojToy: line 153: pushd: /builddir/build/BUILDROOT/glibc-2.17.90-6.fc20.s390x/usr/lib/locale: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.5ojToy (%install)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.5ojToy (%install)
Child return code was: 1
...

for a full log see http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1117919

Another question is who should own the /usr/lib/locale and whether it should exists on 64-bit arches. There is a difference between s390x (it has /usr/lib64/locale) and x86_64 (has /usr/lib/locale). filesystem maintainer is added in CC

Version-Release number of selected component (if applicable):
glibc-2.17.90-6.fc20

Comment 1 Dan Horák 2013-07-29 12:38:17 UTC
ppc64 also uses /usr/lib/locale for -DLOCALEDIR=

Comment 2 Carlos O'Donell 2013-07-29 18:38:36 UTC
I'm looking at this. We've been rearranging the glibc.spec file in order to complete the "Move to /usr" transition which was never done for glibc.

Comment 3 Siddhesh Poyarekar 2013-07-30 04:35:20 UTC
Dan mentioned on IRC that this failure occurs with glibc-2.17.90-4.fc20 too, so it's not the spec file rearrangement.  -DLOCALEDIR is set to /usr/lib64/locale instead of /us/lib/locale, which seems to be a build options change.  A good place to look would be the changes made in rpm-build macros.

Comment 4 Carlos O'Donell 2013-07-30 06:55:55 UTC
The glibc build expects all architectures to install locales into `/usr/lib/locale'. There is no allowance for this being dynamic and it doesn't change based on the target.

It is possible to force the glibc build to install the locales into a directory other than `/usr/lib/locale' via `LOCALEDIR' but doing so is not supported by the glibc rpm.

The glibc build failures are an indication that the above expectation has been violated. We should really add asserts into the glibc build with sensible error messages to point out which things are not expected to change.

I'm moving this to `rpm' component to see if we can get some input about the s390x locale directory change.

Comment 5 Panu Matilainen 2013-08-01 09:42:40 UTC
Well, lib64 getting used where lib is expected is generally a packaging issue of using %{_libdir} (or %{_lib}) macro where hardcoded "/usr/lib" (or "lib") is needed. Rpm doesn't set LOCALEDIR or such, and there's no macro for the unchanging /usr/lib path. I dont see anything obvious in glibc.spec that would cause such an issue specifically on s390 but that doesn't mean much, considering how complex the spec and filelist generation in there is.

Comment #2 mentions rearranging the glibc.spec recently, perhaps you should try reproducing with an older glibc version to catch out possible spec change regressions?

Comment 6 Dan Horák 2013-08-01 11:09:57 UTC
it will be probably more complicated because
- recent glibc could be built within F-19 buildroot, but not in F-20
- pre-reorg glibc also failed in F-20
but I will look more carefully in the logs, buildroots, etc, what could be different

Comment 7 Panu Matilainen 2013-08-01 11:32:14 UTC
Hmm, rpm between F19 and rawhide is virtually identical. Looking at the actual diff, the only thing from rpm-side that could affect things like this is that in rawhide, autoconf config.site processing is disabled (see bug 962837), in F19 its not.

Comment 8 Panu Matilainen 2013-08-01 11:51:00 UTC
Looking at the root.log from the failed attempt:

DEBUG util.py:257:   rpm                       s390x     4.11.0.1-7.fc20             build    1.1 M

That version of rpm is not yet setting CONFIG_SITE=NONE which I suppose could cause stuff going wrong. There is sufficiently new rpm on s390 now (although this is still behind real rawhide):
http://s390.koji.fedoraproject.org/koji/buildinfo?buildID=192859

Me thinks this is likely just an issue with the s390(x) builds being out of sync wrt rest of Fedora.

Comment 9 Dan Horák 2013-08-01 17:12:38 UTC
thanks for the ideas, Panu, I'll try a build with the latest rpm

Comment 10 Carlos O'Donell 2013-08-03 06:18:11 UTC
(In reply to Panu Matilainen from comment #5)
> Well, lib64 getting used where lib is expected is generally a packaging
> issue of using %{_libdir} (or %{_lib}) macro where hardcoded "/usr/lib" (or
> "lib") is needed. Rpm doesn't set LOCALEDIR or such, and there's no macro
> for the unchanging /usr/lib path. I dont see anything obvious in glibc.spec
> that would cause such an issue specifically on s390 but that doesn't mean
> much, considering how complex the spec and filelist generation in there is.

What sets and passes CFLAGS down to the rpm build?

Something, other than the glibc.spec file, sets -DLOCALEDIR=\"/path/\" in CFLAGS which alters the glibc package build, and causes the package to build with a locale directory that isn't what the spec file expects.

The solution is to fix whatever is setting -DLOCALEDIR to select the right path e.g. /usr/lib/locale.

Comment 11 Panu Matilainen 2013-08-05 05:58:48 UTC
(In reply to Carlos O'Donell from comment #10)
> What sets and passes CFLAGS down to the rpm build?

Not rpm, because glibc.spec doesn't use %configure macro. And even with %configure used, rpm only sets various arch/optimization flags, never anything like LOCALEDir (see 'rpm --eval %{optflags}')

> Something, other than the glibc.spec file, sets -DLOCALEDIR=\"/path/\" in
> CFLAGS which alters the glibc package build, and causes the package to build
> with a locale directory that isn't what the spec file expects.
> 
> The solution is to fix whatever is setting -DLOCALEDIR to select the right
> path e.g. /usr/lib/locale.

Grepping around glibc sources I see:
./locale/Makefile:locale-CPPFLAGS = -DLOCALEDIR='"$(localedir)"' \
./intl/Makefile:CPPFLAGS += -D'LOCALEDIR="$(msgcatdir)"' \

Rpm's %configure doesn't set explicitly set autoconf's localedir, and glibc.spec doesn't even use that. 

This does seem like something that autoconf's config.site processing could affect (see comment #7 and #8). So I'd suggest just try rebuilding it now that rpm + autoconf should be "compatible" in the s390 koji.

Comment 12 Dan Horák 2013-08-05 08:55:04 UTC
new scratch build [1] with rpm-4.11.1-1.fc20.s390x in the buildroot looks good now, it has -DLOCALEDIR='"/usr/lib/locale"' on s390x, thanks Panu

[1] http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1128083

Comment 13 Carlos O'Donell 2013-08-06 16:20:16 UTC
(In reply to Panu Matilainen from comment #11)
> (In reply to Carlos O'Donell from comment #10)
> > What sets and passes CFLAGS down to the rpm build?
> 
> Not rpm, because glibc.spec doesn't use %configure macro. And even with
> %configure used, rpm only sets various arch/optimization flags, never
> anything like LOCALEDir (see 'rpm --eval %{optflags}')

Perfect, thanks for clarifying that.
 
> > Something, other than the glibc.spec file, sets -DLOCALEDIR=\"/path/\" in
> > CFLAGS which alters the glibc package build, and causes the package to build
> > with a locale directory that isn't what the spec file expects.
> > 
> > The solution is to fix whatever is setting -DLOCALEDIR to select the right
> > path e.g. /usr/lib/locale.
> 
> Grepping around glibc sources I see:
> ./locale/Makefile:locale-CPPFLAGS = -DLOCALEDIR='"$(localedir)"' \
> ./intl/Makefile:CPPFLAGS += -D'LOCALEDIR="$(msgcatdir)"' \

Right, but these are derived from $(localedir) which glibc doesn't set but gets from the options passed to configure, or automatically computed and set by autoconf.
 
> Rpm's %configure doesn't set explicitly set autoconf's localedir, and
> glibc.spec doesn't even use that. 

Agreed.
 
> This does seem like something that autoconf's config.site processing could
> affect (see comment #7 and #8). So I'd suggest just try rebuilding it now
> that rpm + autoconf should be "compatible" in the s390 koji.

Agreed.

Comment 14 Carlos O'Donell 2013-08-06 16:22:07 UTC
(In reply to Dan Horák from comment #12)
> new scratch build [1] with rpm-4.11.1-1.fc20.s390x in the buildroot looks
> good now, it has -DLOCALEDIR='"/usr/lib/locale"' on s390x, thanks Panu
> 
> [1] http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1128083

Given that the build completed are you opposed to marking this issue as CLOSED/CURRENTRELEASE?

Comment 15 Dan Horák 2013-08-06 16:28:12 UTC
please close as stated