Schedule for Monday's FESCo Meeting (2018-07-09)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-07-09 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

https://pagure.io/fesco/issue/1920
F29 System Wide Change: Build non-RELRO ELF binaries with .plt.got isolation
APPROVED

https://pagure.io/fesco/issue/1923
F29 Self Contained Change: glibc 32 Build Adjustments
APPROVED

https://pagure.io/fesco/issue/1924
F29 System Wide Change: Rename Atomic Workstation to Silverblue
APPROVED

https://pagure.io/fesco/issue/1926
F29 System Wide Change: The GNU C Library version 2.28
APPROVED

https://pagure.io/fesco/issue/1927
F29 Self Contained Change: Origin 3.10
APPROVED

https://pagure.io/fesco/issue/1929
F29 System Wide Change: IBus 1.5.19
APPROVED

https://pagure.io/fesco/issue/1930
F29 System Wide Change: Modules for Everyone
APPROVED

https://pagure.io/fesco/issue/1932
Nonresponsive maintainer: kylev (python-beaker and possibly other packages)

= Followups =

None

= New business =

#topic #1917 F29 System Wide Change: Make BootLoaderSpec-style
configuration files the default
.fesco 1917
https://pagure.io/fesco/issue/1917

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B5Q4JBBXH2HRXSPSF62UB6247KKZZX24/

[Test-Announce] Proposal to CANCEL: 2018-07-09 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't
see anything urgent to discuss, so let's take the time off.

If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.
Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org/message/WSPKRDYU46VEQ6UDBAGQVNEEIIMQKHE7/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WSPKRDYU46VEQ6UDBAGQVNEEIIMQKHE7/

Re: Your package doesn't build with Python 3.7

[Tim Orling]

Fixed pystatgrab.
python3.7 on copr worked fine for me, with your suggestion of adding the
rawhide repo

On Mon, Jul 2, 2018 at 12:38 AM, Miro Hrončok  wrote:

> On 2.7.2018 02:54, Sérgio Basto wrote:
>
>> On Mon, 2018-07-02 at 01:37 +0200, Miro Hrončok wrote:
>>
>>> On 2.7.2018 01:20, Sérgio Basto wrote:
>>>
 Hmm I was under the impression that PyString_AsString does not
> exist
> in Python3
> and you'll have to use PyUnicode_AsEncodedString. Was it actually
> compiling with
> previous versions of Python3?
>

 I was testing disable python2 [1], to see what happen but copr
 rawhide
 still have python 3.6 !
 How I enable python-3.7 on copr ?

>>>
>>> You can add a repo in copr settings:
>>>
>>> https://kojipkgs.fedoraproject.org/repos/f29-python/938830/$basearch
>>>
>>
>> Unfortunately failed [1]
>>
>> Thanks
>>
>> [1]
>> https://copr.fedorainfracloud.org/coprs/sergiomb/opencv/build/772874/
>> https://copr-be.cloud.fedoraproject.org/results/sergiomb/opencv/fedora-
>> rawhide-x86_64/00772874-opencv/root.log
>>
>> DEBUG util.py:489:  BUILDSTDERR: Error:
>> DEBUG util.py:489:  BUILDSTDERR:  Problem: package
>> gdb-headless-8.1.50.20180629-26.fc29.x86_64 requires
>> libpython3.6m.so.1.0()(64bit), but none of the providers can be installed
>> DEBUG util.py:489:  BUILDSTDERR:   - cannot install both
>> python3-libs-3.7.0-1.fc29.x86_64 and python3-libs-3.6.5-4.fc29.x86_64
>> DEBUG util.py:489:  BUILDSTDERR:   - cannot install both
>> python3-libs-3.6.5-4.fc29.x86_64 and python3-libs-3.7.0-1.fc29.x86_64
>> DEBUG util.py:489:  BUILDSTDERR:   - cannot install the best update
>> candidate for package python3-libs-3.6.5-4.fc29.x86_64
>> DEBUG util.py:489:  BUILDSTDERR:   - cannot install the best update
>> candidate for package gdb-headless-8.1.50.20180629-26.fc29.x86_64
>> DEBUG util.py:491:  (try to add '--allowerasing' to command line to
>> replace conflicting packages or '--skip-broken' to skip uninstallable
>> packages)
>>
>
> In that case, sorry, no idea how to use 3.7 in copr. I've asked releng to
> merge the side tag today anyway. https://pagure.io/releng/issue/7564
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.or
> g/archives/list/devel@lists.fedoraproject.org/message/DMWCEH
> QIOTWJ2MXWY2T4YFBHUT263CFS/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7FJYG34EPA5GRZUSDJNEOWZL7UYM5WAG/

Re: Your package requires Python 3.6, rebuild it!

[Tim Orling]

Fixed pystatgrab

On Thu, Jul 5, 2018 at 4:10 AM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Wed, Jul 04, 2018 at 09:58:15PM +0200, Miro Hrončok wrote:
> > On 4.7.2018 21:51, Sérgio Basto wrote:
> > >since 2018-07-02 14:28 [1] we don't have compose this mean build root
> > >on copr aren't update , and we can't test it
> >
> > Try adding
> > http://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/ as a
> > repo to copr. there should be no more problems like iwth the
> > f29-python side tag, where packages had newer versions in rawhide
> > still depending on 3.6.
>
> Alternatively, build in mock:
> $ fedpkg srpm && mock --enablerepo=local whatever.src.pm
>
> (Repo 'local' pulls directly from koji.)
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/message/DXWIO4CIKCKXT2PREKXWCOKDZIWXH4T7/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EV6US2EGVJEAK77BKRXX3LQYCJOOYZFL/

Re: Annobin: "causes a section type conflict with..."

[Jonathan Wakely]

On 06/07/18 13:52 -0600, Jerry James wrote:

On Thu, Jul 5, 2018 at 4:01 PM Jerry James  wrote:

This afternoon, I received email from koschei, telling me that
polymake's builds have started to fail:


Here is another one, with a shorter build time than polymake, for
anybody trying to track this down:

https://apps.fedoraproject.org/koschei/package/sphinxtrain?collection=f29

It is kind of worrisome that this is happening just a few days before
the mass rebuild is set to begin.


I'm seeing this in Boost too, and given my schedule I'm going to
abandon the Boost update for f29.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BWBNS6Z7Z6QBY33KXIX2GL3WMLEPAMT7/

Re: Annobin: "causes a section type conflict with..."

[Jerry James]

On Thu, Jul 5, 2018 at 4:01 PM Jerry James  wrote:
> This afternoon, I received email from koschei, telling me that
> polymake's builds have started to fail:

Here is another one, with a shorter build time than polymake, for
anybody trying to track this down:

https://apps.fedoraproject.org/koschei/package/sphinxtrain?collection=f29

It is kind of worrisome that this is happening just a few days before
the mass rebuild is set to begin.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4NFZERAE5WXX5I4TQYXBOZZJXC5E7NJB/

Re: Self-Introduction: Dave Dykstra

[Charalampos Stratakis]

- Original Message -
> From: "Dave Dykstra" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, July 2, 2018 6:58:40 PM
> Subject: Self-Introduction: Dave Dykstra
> 
> Hello everyone,
> 
> I work at the Fermi National Accelerator Laboratory and have just joined
> this mailing list.  I expect to become a co-maintainer of the singularity
> package for Fedora and EPEL along with Brian Bockelman.  I support
> singularity for the Open Science Grid (https://opensciencegrid.org) and
> the Worldwide LHC Computing Grid (http://wlcg.web.cern.ch) and have many
> years of experience supporting Linux tools.  For example, about 20 years
> ago during a previous job at Bell Labs, for one year I was the primary
> upstream maintainer of rsync.
> 
> Dave
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UV35HCMGHOTPKJCQQ2QK4GY2NYETWDOZ/
> 

Hello Dave and welcome to Fedora!

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CENVT565K3OTUGYE3X5DU3BR2KPUSS6L/

Re: Compiling binaries with PGO (Profile-Guided Optimization)

[Jakub Jelinek]

On Fri, Jul 06, 2018 at 08:35:56PM +0300, Alexander Zaitsev wrote:
> > Some packages in Fedora _are_ compiled with PGO. Off the top of my
> > head, both Firefox and Python 3 are, but only for the x86
> > architectures. It takes too long for other architectures.

GCC is built with PGO as well (on all architectures).

> > I don't know if there's significant demonstrative benefit across the
> > board for PGO, given the additional time it adds to package builds...

It can often give a 10-30% boost.

> Hmm.. Sounds interesting. If some packages are built with PGO, so which
> profiling information is used for compilation with PGO? Maintainers manually
> collect it or take this information from some source?

The normal way of building with PGO is build once with -fprofile-generate,
run the program during package build with a typical workload (worst case
e.g. a testsuite, but a good testsuite should test also corner cases that
are unlikely in real-world usage) and then compile it again with
-fprofile-use where it picks the collected data.

Another option (though, no experience with that) is AutoFDO, where it is
built normally, run under perf, the so gathered data transformed with
create_gcov and finally built with -fauto-profile.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JHRDGVAAX7I4LCGD2PZGDEKIUOTDAFFP/

Re: Compiling binaries with PGO (Profile-Guided Optimization)

[Charalampos Stratakis]

- Original Message -
> From: "Alexander Zaitsev" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, July 6, 2018 7:35:56 PM
> Subject: Re: Compiling binaries with PGO (Profile-Guided Optimization)
> 
> 
> 
> 06.07.2018 17:26, Neal Gompa пишет:
> > On Fri, Jul 6, 2018 at 10:12 AM Aliaksandr Zaitsau 
> > wrote:
> >> Hello.
> >>
> >> As far as I know binaries in Fedora repositories are compiled without
> >> PGO (profile-guided optimization). Also I don't know any LInux-based OS
> >> where binaries are precompiled with PGO. With PGO we can improve
> >> performance of binaries for typical use-cases without compiling for some
> >> specific architecture (so binaries with PGO will be
> >> architecture-independent).
> >>
> >> Question: why PGO isn't used by maintainers for packages? Lack of
> >> profile data for compilation with PGO? Isn't interested for
> >> mainatainers? Something else? Will you try to use PGO for your packages,
> >> if will be available repository with profile data for different
> >> applications, where you can pick profile data for your application,
> >> recompile package with this information and, probably, increase
> >> performance of your application?
> >>
> > Some packages in Fedora _are_ compiled with PGO. Off the top of my
> > head, both Firefox and Python 3 are, but only for the x86
> > architectures. It takes too long for other architectures.
> >
> > I don't know if there's significant demonstrative benefit across the
> > board for PGO, given the additional time it adds to package builds...
> >
> >
> >
> Hmm.. Sounds interesting. If some packages are built with PGO, so which
> profiling information is used for compilation with PGO? Maintainers
> manually collect it or take this information from some source?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J2GKMR75ZC5YQ3O3UD5PQAWSLUOYJ46M/
> 

Python runs its huge upstream test suite to gather that information. Combined 
with the fact that we also run it once for the debug build
and another for the actual build, the slow arch's will take way too long. ARM 
was something like 7 hours if I recall correctly,
hence the reason for enabling it only on specific arch's.

You can examine the build logs here  if you are interested [0].

[0] https://koji.fedoraproject.org/koji/buildinfo?buildID=1099020

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5UOM5KBI3VNPJH47URVB5V6ZTG6GE77N/

Re: Compiling binaries with PGO (Profile-Guided Optimization)

[Alexander Zaitsev]

06.07.2018 17:26, Neal Gompa пишет:

On Fri, Jul 6, 2018 at 10:12 AM Aliaksandr Zaitsau  wrote:

Hello.

As far as I know binaries in Fedora repositories are compiled without
PGO (profile-guided optimization). Also I don't know any LInux-based OS
where binaries are precompiled with PGO. With PGO we can improve
performance of binaries for typical use-cases without compiling for some
specific architecture (so binaries with PGO will be
architecture-independent).

Question: why PGO isn't used by maintainers for packages? Lack of
profile data for compilation with PGO? Isn't interested for
mainatainers? Something else? Will you try to use PGO for your packages,
if will be available repository with profile data for different
applications, where you can pick profile data for your application,
recompile package with this information and, probably, increase
performance of your application?


Some packages in Fedora _are_ compiled with PGO. Off the top of my
head, both Firefox and Python 3 are, but only for the x86
architectures. It takes too long for other architectures.

I don't know if there's significant demonstrative benefit across the
board for PGO, given the additional time it adds to package builds...



Hmm.. Sounds interesting. If some packages are built with PGO, so which 
profiling information is used for compilation with PGO? Maintainers 
manually collect it or take this information from some source?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J2GKMR75ZC5YQ3O3UD5PQAWSLUOYJ46M/

Re: installing glibc-minimal-langpack in buildroots

[Tomasz Kłoczko]

On Fri, 6 Jul 2018 at 15:02, Igor Gnatenko
 wrote:
[..]
>> # rpm --rebuilddb; dnf cean all; df -k /; rpm -qal|grep
>> LC_MESSAGES|xargs rpm -qf 2>&1|sort|uniq| xargs dnf -yq reinstall; rpm
>> --rebuilddb; df -k /
>
>
> Look here, you have to reinstall RPM with new settings which means you have 
> to download full RPM. Main advantage of langpack subpackages us that you can 
> install them granularly with downloading just translations.

As long as all packages is possible to download only in form of whole
packages archives above it is only way to apply things like changing
some installed packages lang or other setting. In other words it is
something which is embedded into rpm philosophy/design.
For example IPS is using "facets" concept so to change something like
above you need one command:

# pkg change-facet locale.*=false locale.en=true locale.pl=true

Uninstalling all documentations? No problem ..

# pkg change-facet doc.*=false

Install only man pages?

# pkg change-facet doc.man=true.

(yeah ,, there are more than one type of documentation files to install or not)
You can combine as well more than one facet like locale.en=true and
doc.man=true to install only man pages in exact language(s).
Transform whole system to devel env is as well incredibly easy:

# pkg change-facet devel=true

No devel sub packages !!! :)
And after finishing compile some binaries ..

# pkg change-facet devel=false

Those operations may look simple during those changes is working whole
dependency checking machinery so if install or uninstall some sub
types of package files may break some dependencies (which are
connection resources knots not on whole packages level but each files)
such operation will fail with error message.
All is b*dy easy to do because all packages exist only in repositories
as separated files. Some files like ELF binaries may exist even in the
same repository as object owned by multiple versions of the package or
in architecture dependent types.
This allows for example on doing upgrade some A package from V.1 to
V.2 download only those files which has been changed between versions.

Without such design changes on packages representation side using
current rpm trying to implement something like Modularity will be
nothing more than Sisyphus work.
IPS already uses facets and variants more than decade ..
https://docs.oracle.com/cd/E23824_01/html/E21802/glmke.html
If you are interested try to read about other IPS concepts like
consolidation. This little thing solves all possible problems of have
some issues because something has been build not in environment of
exact versions of other packages.

But again .. as nothing in kickstart adds during initial installation
in /etc/rpm/macros lines about supported languages or settings to
install or not documentation only way to maintain two possible
optionally to install types of files using rpm is creating more and
more packages.
Wen you will try to install Solaris (you can use even free
OpenIndiana) just check how many types only facets is possible to
change in something like typical(tm) installation.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PKDHMCKI33YZMVU2GI5LOPV34WDGSXHM/

Re: F29 System Wide Change: Remove Excessive Linking

[Stephen Gallagher]

On Tue, Jul 3, 2018 at 4:23 AM Jan Kurik  wrote:

> Note from Change Wrangler: This Change Proposal requires mass rebuild.
> However, two weeks ago (June 19th), we have already passed the
> deadline for Change proposals requiring mass rebuild. I will leave the
> decision whether this Change proposal is accepted or not to RelEng and
> FESCo teams.
>
> = Proposed System Wide Change: Remove Excessive Linking =
> https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking
>
>
> Owner(s):
>   * Igor Gnatenko 
>   * Neal Gompa 
>
>
> Pass "--as-needed" flag the linker through default system-wide LDFLAGS.
>
>
> == Detailed description ==
> The flag ("--as-needed") tells the linker to link in the produced
> binary only the libraries containing symbols actually used by the
> binary itself. This binary can be either a final executale or another
> library.
> The use of the "--as-needed" flag allows the linker to avoid linking
> extra libraries in a binary. This not only improves startup times (as
> the loader does not have to load all the libraries for every step) but
> might avoid the full initialization of big frameworks.
>
>
> == Scope ==
> * Proposal owners:
> Add "-Wl,--as-needed" into RPM_LD_FLAGS (in redhat-rpm-config).
>
> * Other developers:
> Nothing should break, but immediate work-around would be to disable
> this flag (will be provided in redhat-rpm-config) and fix real issue
> later.
>
> * Release engineering:
> #7604 [https://pagure.io/releng/issue/7604] (mass rebuild is desired
> after this change).
>
> ** List of deliverables:
> N/A (not a System Wide Change)
>
> * Policies and guidelines:
> Add information how to turn it off (TODO link to FPC ticket).
>
> * Trademark approval:
> N/A (not needed for this Change)
> --
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71
> , 612 45
> Brno, Czech Republic
>


Changes that require or "desire" a mass-rebuild should have been submitted
by June 19th.

I can't find the reference offhand, but I feel like I remember that FESCo
has ruled in the past that any changes to the default buildroot or compiler
flags must be implemented as part of a mass-rebuild, to catch the fallout
all at once. So with my FESCo hat on, I'm -1 to this change for F29, but
I'm a strong +1 to implementing it for F30 in Rawhide immediately after we
branch.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QLYRW3HOJWR4GXF72UCOYYV3CTQZMXSM/

Re: DNF issue ? able to install redis with missing dependency

[Remi Collet]

Le 06/07/2018 à 16:30, Robert-André Mauchin a écrit :

> The update 389-ds-base-1.4.0.11-2.fc28 which fix it is in stable though so I 
> don't understand why your build still install 1.4.0.10-2.

Forget and sorry for the noise...
This is an old build


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RUZQ47NUJ5VQVR7KD4CT4OFI5GXXKIXZ/

Re: DNF issue ? able to install redis with missing dependency

[Robert-André Mauchin]

On vendredi 6 juillet 2018 16:15:21 CEST Remi Collet wrote:
> Hi
> 
> See https://koji.fedoraproject.org/koji/taskinfo?taskID=27817390
> 
> 
> + /usr/bin/redis-server ...
> /usr/bin/redis-server: error while loading shared libraries:
> libjemalloc.so.2: cannot open shared object file: No such file or directory
> error: Bad exit status from /var/tmp/rpm-tmp.5eQFNx (%check)
> 
> 
> Which means dnf accept to install redis without jemalloc
> 
> Despite $ rpm -qp --requires redis-4.0.10-1.fc29.x86_64.rpm
> libjemalloc.so.2()(64bit)
> ...
> 
> 
> How is it possible ?
> 
> Workaround is
>  BuildRequires: redis
> +BuildRequires: jemalloc
> 
> 
> 
> Remi

There was an issue with the wrong package providing jemalloc. See my comment 
here: https://bugzilla.redhat.com/show_bug.cgi?id=1594565#c1 and see bug 
https://bugzilla.redhat.com/show_bug.cgi?id=1591808

I guess you are affected. Basically it install 389-ds-base-libs 
1.4.0.10-2.fc28 because it provides a jemalloc.so instead of pulling jemalloc. 

The update 389-ds-base-1.4.0.11-2.fc28 which fix it is in stable though so I 
don't understand why your build still install 1.4.0.10-2.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V5K74HTXTNF5H3WVOQLLFBPZ5L47B62K/

DNF issue ? able to install redis with missing dependency

[Remi Collet]

Le 06/07/2018 à 16:15, Remi Collet a écrit :
> Hi
> 
> See https://koji.fedoraproject.org/koji/taskinfo?taskID=27817390
> 
> 
> + /usr/bin/redis-server ...
> /usr/bin/redis-server: error while loading shared libraries:
> libjemalloc.so.2: cannot open shared object file: No such file or directory
> error: Bad exit status from /var/tmp/rpm-tmp.5eQFNx (%check)
> 
> 
> Which means dnf accept to install redis without jemalloc
> 
> Despite $ rpm -qp --requires redis-4.0.10-1.fc29.x86_64.rpm
> libjemalloc.so.2()(64bit)
> ...
> 
> 
> How is it possible ?

=> https://bugzilla.redhat.com/show_bug.cgi?id=1594565
=> https://bugzilla.redhat.com/show_bug.cgi?id=1591808

But https://bodhi.fedoraproject.org/updates/FEDORA-2018-a00a3e9b36 is
supposed to already be in stable...


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LGS4NC7B6GN6QZ4MVDGRYOEVEDCAKCEG/

Re: Compiling binaries with PGO (Profile-Guided Optimization)

[Neal Gompa]

On Fri, Jul 6, 2018 at 10:12 AM Aliaksandr Zaitsau  wrote:
>
> Hello.
>
> As far as I know binaries in Fedora repositories are compiled without
> PGO (profile-guided optimization). Also I don't know any LInux-based OS
> where binaries are precompiled with PGO. With PGO we can improve
> performance of binaries for typical use-cases without compiling for some
> specific architecture (so binaries with PGO will be
> architecture-independent).
>
> Question: why PGO isn't used by maintainers for packages? Lack of
> profile data for compilation with PGO? Isn't interested for
> mainatainers? Something else? Will you try to use PGO for your packages,
> if will be available repository with profile data for different
> applications, where you can pick profile data for your application,
> recompile package with this information and, probably, increase
> performance of your application?
>

Some packages in Fedora _are_ compiled with PGO. Off the top of my
head, both Firefox and Python 3 are, but only for the x86
architectures. It takes too long for other architectures.

I don't know if there's significant demonstrative benefit across the
board for PGO, given the additional time it adds to package builds...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MRKQNDIRSWUU6CY6ZC3WQYMSCORSM4GE/

Re: Merging Perl 5.28 to Fedora 29

[Petr Pisar]

On 2018-07-04, Petr Pisar  wrote:
> Perl SIG completed Perl 5.28 upgrade
>  in f29-perl side tag
> that involved rebuildnig about 3000 packags. Once relengs merge the tag
> back to f29 , the new Perl becomes
> available.
>
The merge was completed. It took some time because not all packages were
signed and moved in one batch, so one could experience broken
dependencies for some time.

> If you encounter any broken dependencies on libperl.so.5.26() or
> perl(:MODULE_COMPAT_5.26.*), it's because the package fails to build
> (all the failures have been already reported) or because a package
> maintainer upgraded her packages before relengs merged the side tag.
> In that case feel free to rebuild the package again against the new
> Perl.
>
I rebuilt those packages again. Fedora 29 is clean ans smooth again.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QBS2322IWN3CL4UFVHJEKOMMVJ6ZVQPY/

DNF issue ? able to install redis with missing dependency

[Remi Collet]

Hi

See https://koji.fedoraproject.org/koji/taskinfo?taskID=27817390


+ /usr/bin/redis-server ...
/usr/bin/redis-server: error while loading shared libraries:
libjemalloc.so.2: cannot open shared object file: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.5eQFNx (%check)


Which means dnf accept to install redis without jemalloc

Despite $ rpm -qp --requires redis-4.0.10-1.fc29.x86_64.rpm
libjemalloc.so.2()(64bit)
...


How is it possible ?

Workaround is
 BuildRequires: redis
+BuildRequires: jemalloc



Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/472QSLBYMWYREE4YKJAV7YBNWWVCNQJC/

Compiling binaries with PGO (Profile-Guided Optimization)

[Aliaksandr Zaitsau]

Hello.

As far as I know binaries in Fedora repositories are compiled without 
PGO (profile-guided optimization). Also I don't know any LInux-based OS 
where binaries are precompiled with PGO. With PGO we can improve 
performance of binaries for typical use-cases without compiling for some 
specific architecture (so binaries with PGO will be 
architecture-independent).


Question: why PGO isn't used by maintainers for packages? Lack of 
profile data for compilation with PGO? Isn't interested for 
mainatainers? Something else? Will you try to use PGO for your packages, 
if will be available repository with profile data for different 
applications, where you can pick profile data for your application, 
recompile package with this information and, probably, increase 
performance of your application?


Thank you.

With best regards, Alexander Zaitsev.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2H4ZDRR326XAZ2EPCQKTNRMQYG5YZQ2K/

Re: installing glibc-minimal-langpack in buildroots

[Igor Gnatenko]

On Thu, Jul 5, 2018, 20:42 Tomasz Kłoczko  wrote:

> On Thu, 5 Jul 2018 at 16:08, Zbigniew Jędrzejewski-Szmek
>  wrote:
> [..]
> > Anyway, the langpacks split was made with full awareness of
> %_install_langs,
> > see https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging.
>
> Yep and simple this makes glibcs.spec one of the most complicated
> Fedora specs files by implementing generate set of sub packages to
> install lang dependent resources. If glibc and few other packages will
> be only using %lang() and everything aroud will be adding proper
> %_install_langs settings it will be not necessary to create next
> almost 200 glibc sub packages.
> Even separation glibc-minimal-langpack files is pointless because
> those files must be installed always to not have constantly annoying
> warning messages about missing locale "C" files.
>
> [..]
> > > Result is obvious: number of *langpack* packages is growing.
> > I don't think this is a big problem. The number of languages that can
> > be supported can't go much higher (in principle there's maybe ~2000
> languages
> > alive nowadays, but most of them are dying quickly, and are unlikely to
> ever
> > get glibc locale support). The 192 langpacks we have now is nothing
> compared
> > to the texlive package list.
>
> Just please correct me if I'm wrong. Does it mean that someone already
> started thinking about generate another 2k TeX packages? =8-O
> If it is true I'll put my private money to fund for this person
> special IgNoble price :)
>
> Fedora has those only glibc sub packages  because nothing OOTB in
> installer adds /etc/rpm/macros file with single line of text forefeet
> start install first package.
> Many packages have already marked man pages and gettext .mo files
> which have proper %lang() metadata.
> How you can compare probably single python code modification in
> kickstart code to number of man/hour resources spend by all Fedora
> packagers which are maintaining *langpack* sub packages scheme and
> man/hour resources already spent by Fedora end users choosing those
> langpacks?
>
> Yes .. this is level; of the "elegance and simplicity" which many
> Fedora packages already are trying hardly avoid by any cost.
>
> Again .. just please try sometimes to think a bit broader.
> If you will repeat enough times "I don't think this is a big problem"
> by a mass of those even smallest issues at least one big problem
> sooner or later will start kicking back. You already must know that
> this effect is well know in engendering and its name is "dead by
> thousands cuts".
>
> Someone implementing langpacks in glibc have been trying to not
> install some resources at the same time lost all other .mo and %lang)
> depended files installed in the system.
> This like trying to move around few buckets of sand sitting in the
> middle of the desert.
> How big proportion is between those disk space which is possible to
> "save" by using proper set  of *langpack* packages you can check on
> you own system by add /etc/rpm/macros with line like:
>
> %_install_langs en,pl
>
> (or any other set of the languages) is possible to check by run below
> oneliner:
>
> # rpm --rebuilddb; dnf cean all; df -k /; rpm -qal|grep
> LC_MESSAGES|xargs rpm -qf 2>&1|sort|uniq| xargs dnf -yq reinstall; rpm
> --rebuilddb; df -k /
>

Look here, you have to reinstall RPM with new settings which means you have
to download full RPM. Main advantage of langpack subpackages us that you
can install them granularly with downloading just translations.

In future I am hoping that those will be generated automatically.

and compare reduction used disk space to summary size of all Fedora
> glibc-langpack* packages.
>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UDFAFJOR23NC7KCOFSWGWYOYFO33UXV6/
>
-- 

-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7DIQXG3YQOE2C734CTUXAPLMLATQMNT4/

Fedora 29 Mass Rebuild

[Mohan Boddu]

Hi all,

Per the Fedora 29 schedule[1] we will be starting a mass rebuild for Fedora
29 very shortly. We are doing a mass rebuild for Fedora 29 for all the
changes listed in

https://pagure.io/releng/issue/7480

we will start the mass rebuild on 2018-07-11

This is a heads up that it will be done in a side tag and moved over
when completed. We will be running scripts to output failure stats.
please be sure to let releng know if you see any bugs in the reporting.

You can contact releng in #fedora-releng on freenode.

Failures can be seen

https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html

Things still needing rebuilt

https://kojipkgs.fedoraproject.org/mass-rebuild/f29-need-rebuild.html

Regards

Mohan Boddu
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/OXVVLSV6GA5E5F6TVTZIRO637P67OPY3/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OXVVLSV6GA5E5F6TVTZIRO637P67OPY3/

Re: installing glibc-minimal-langpack in buildroots

[Tomasz Torcz]

July 6, 2018 1:25 PM, "Stephen Gallagher" mailto:%22Stephen%20Gallagher%22%20)> wrote:
 On Fri, Jul 6, 2018 at 5:07 AM Mikolaj Izdebski mailto:mizde...@redhat.com)> wrote: On 07/06/2018 10:48 AM, Zbigniew 
Jędrzejewski-Szmek wrote:

> When I run mock locally, it just passes the LC_*/LANG variables from
> the outside environment. I wonder if in koji this locale information is
> inherited from the default system settings, or if koji sets is specifically.

When LANG is not set mock sets it to en_US.UTF-8.
Fedora Koji doesn't configure LANG, AFAIK. 
Can we get that fixed upstream in mock? If there's no locale set, the *only* 
locale that is safe to assume is C[.UTF-8]. Assuming en-US.UTF-8 is *commonly* 
acceptable, but not guaranteed.   
Let's try:
https://github.com/rpm-software-management/mock/pull/208 
(https://github.com/rpm-software-management/mock/pull/208)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OPG4NE5CFA43SRDCFJDJMFC2U4KF5B7G/

Re: installing glibc-minimal-langpack in buildroots

[Stephen Gallagher]

On Fri, Jul 6, 2018 at 5:07 AM Mikolaj Izdebski  wrote:

> On 07/06/2018 10:48 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >> Either you need to change mock to set C.UTF-8, or change your proposal
> to
> >> install glibc-langpack-en instead of glibc-minimal-langpack. Otherwise
> various
> >> programs will fail to set the locale at build time. E.g. perl is quite
> >> noisy about that.
> >
> > Thanks, that's a good point. Do you know where this is configured?
> >
> > When I run mock locally, it just passes the LC_*/LANG variables from
> > the outside environment. I wonder if in koji this locale information is
> > inherited from the default system settings, or if koji sets is
> specifically.
>
> When LANG is not set mock sets it to en_US.UTF-8.
> Fedora Koji doesn't configure LANG, AFAIK.
>

Can we get that fixed upstream in mock? If there's no locale set, the
*only* locale that is safe to assume is C[.UTF-8]. Assuming en-US.UTF-8 is
*commonly* acceptable, but not guaranteed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4NKQAXQARLKDOGNJXENZ237YUUMIEMLQ/

Re: installing glibc-minimal-langpack in buildroots

[Mikolaj Izdebski]

On 07/06/2018 10:48 AM, Zbigniew Jędrzejewski-Szmek wrote:
>> Either you need to change mock to set C.UTF-8, or change your proposal to
>> install glibc-langpack-en instead of glibc-minimal-langpack. Otherwise 
>> various
>> programs will fail to set the locale at build time. E.g. perl is quite
>> noisy about that.
> 
> Thanks, that's a good point. Do you know where this is configured?
> 
> When I run mock locally, it just passes the LC_*/LANG variables from
> the outside environment. I wonder if in koji this locale information is
> inherited from the default system settings, or if koji sets is specifically.

When LANG is not set mock sets it to en_US.UTF-8.
Fedora Koji doesn't configure LANG, AFAIK.

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CNXXFTCEXVMBRBULAMUKS5F5535I3XB2/

Re: installing glibc-minimal-langpack in buildroots

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jul 06, 2018 at 08:15:04AM +, Petr Pisar wrote:
> On 2018-07-05, Zbigniew Jędrzejewski-Szmek  wrote:
> > On Thu, Jul 05, 2018 at 01:19:38PM +, Zbigniew Jędrzejewski-Szmek wrote:
> >> On Thu, Jul 05, 2018 at 02:41:01PM +0200, Florian Weimer wrote:
> >> > On 07/05/2018 02:28 PM, Stephen Gallagher wrote:
> >> > >So if we made this change, it should
> >> > >probably go through the System-Wide Change process, the same as
> >> > >any other item we remove from the default buildroot.
> >> > 
> >> > I agree that it is a useful change, but also that it should go
> >> > through the Change process.
> >> OK.
> >> 
> >> > On 07/05/2018 02:28 PM, Stephen Gallagher wrote:
> >> > >My concern there would be that any package that needs langpacks
> >> > >available in its build-system will now need to request them
> >> > >specifically (for example, if the package does tests of
> >> > >localization in %check). 
> >> I wonder how many such packages there are. I have seen many packages
> >> which fail in an non-unicode locale, especially in tests. 
> >> glibc-minimal-langpack
> >> contains C.UTF-8 so that is should not be an issue. So far I haven't
> >> seen packages that would depend on the presence of some specific
> >> locales, except that many packages need *some* utf-8 locale so they
> >> set some specific one, usually en_US.utf8. A quick grep shows that
> >> there's maybe a 50 such packages that would need to be adjusted.
> >
> > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
> >
> mock sets locale to en_US.UTF-8 on every build in Koji. Look at any
> build.log. Example:
> 
> Mock Version: 1.3.4
> ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 
> --nodeps /builddir/build/SPECS/libspf2.spec'], 
> chrootPath='/var/lib/mock/f29-build-12927811-944129/root'env={'TERM': 
> 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 
> 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf 
> "\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ', 'LANG': 
> 'en_US.UTF-8'}shell=Falselogger= 0x7f6cc8fb3fd0>timeout=172800uid=1000gid=425user='mockbuild'nspawn_args=[]printOutput=False)
> 
> Either you need to change mock to set C.UTF-8, or change your proposal to
> install glibc-langpack-en instead of glibc-minimal-langpack. Otherwise various
> programs will fail to set the locale at build time. E.g. perl is quite
> noisy about that.

Thanks, that's a good point. Do you know where this is configured?

When I run mock locally, it just passes the LC_*/LANG variables from
the outside environment. I wonder if in koji this locale information is
inherited from the default system settings, or if koji sets is specifically.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KONJ3NEVAYVXUBORVJRQFT4WPVEMQM44/

Re: installing glibc-minimal-langpack in buildroots

[Petr Pisar]

On 2018-07-05, Zbigniew Jędrzejewski-Szmek  wrote:
> On Thu, Jul 05, 2018 at 01:19:38PM +, Zbigniew Jędrzejewski-Szmek wrote:
>> On Thu, Jul 05, 2018 at 02:41:01PM +0200, Florian Weimer wrote:
>> > On 07/05/2018 02:28 PM, Stephen Gallagher wrote:
>> > >So if we made this change, it should
>> > >probably go through the System-Wide Change process, the same as
>> > >any other item we remove from the default buildroot.
>> > 
>> > I agree that it is a useful change, but also that it should go
>> > through the Change process.
>> OK.
>> 
>> > On 07/05/2018 02:28 PM, Stephen Gallagher wrote:
>> > >My concern there would be that any package that needs langpacks
>> > >available in its build-system will now need to request them
>> > >specifically (for example, if the package does tests of
>> > >localization in %check). 
>> I wonder how many such packages there are. I have seen many packages
>> which fail in an non-unicode locale, especially in tests. 
>> glibc-minimal-langpack
>> contains C.UTF-8 so that is should not be an issue. So far I haven't
>> seen packages that would depend on the presence of some specific
>> locales, except that many packages need *some* utf-8 locale so they
>> set some specific one, usually en_US.utf8. A quick grep shows that
>> there's maybe a 50 such packages that would need to be adjusted.
>
> https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
>
mock sets locale to en_US.UTF-8 on every build in Koji. Look at any
build.log. Example:

Mock Version: 1.3.4
ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 
--nodeps /builddir/build/SPECS/libspf2.spec'], 
chrootPath='/var/lib/mock/f29-build-12927811-944129/root'env={'TERM': 'vt100', 
'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ', 'LANG': 
'en_US.UTF-8'}shell=Falselogger=timeout=172800uid=1000gid=425user='mockbuild'nspawn_args=[]printOutput=False)

Either you need to change mock to set C.UTF-8, or change your proposal to
install glibc-langpack-en instead of glibc-minimal-langpack. Otherwise various
programs will fail to set the locale at build time. E.g. perl is quite
noisy about that.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YKEDXC6HVCSQNENMF22TMLJMPUGV4UPE/