Review request - python-spyder-kernels
Can someone please review this package for me? This should be relatively straightforward. https://bugzilla.redhat.com/show_bug.cgi?id=1599026 I need this to update python IDE spyder to version 3.3.0. I can review a package in return. Thanks, Mukundan. 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/BY6LZTS7RVE5FN4ZZ5AI3XBKJVQKTNA4/
Review swaps
A new version of cvc4 is available. It depends on cryptominisat 5.x instead of 4.x. Since cvc4 was the last consumer of cryptominisat 4.x in Fedora, this means that we can finally retire the cryptominisat4 package. On the other hand, cvc4 1.6 has new dependencies. I get to add 4 packages in order to retire 1. Um ... yay? I need reviews for the following. Let me know what I can review for you in exchange: - drabt: https://bugzilla.redhat.com/show_bug.cgi?id=1599011 - cadical: https://bugzilla.redhat.com/show_bug.cgi?id=1599012, depends on drabt - lfsc: https://bugzilla.redhat.com/show_bug.cgi?id=1599013; see note below - symfpu: https://bugzilla.redhat.com/show_bug.cgi?id=1599014 We used to have an lfsc package in Fedora. Then cvc4 absorbed lfsc; the upstream lfsc repository disappeared, and the sources were shipped as part of cvc4. Now the cvc4 developers have decided to distribute lfsc separately again, so we need to revive the old lfsc package (with some substantial changes). Thank you, -- 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/UOOMCI4OKFM46QRMIPTKQWWNW2WGA6L7/
Re: Annobin: "causes a section type conflict with..."
On Fri, Jul 6, 2018 at 2:14 PM Jonathan Wakely wrote: > I'm seeing this in Boost too, and given my schedule I'm going to > abandon the Boost update for f29. Ugh, that's unfortunate. I wonder if we should perhaps postpone the mass rebuild until this issue has been fixed. It would be interesting to know if turning off annobin fixes the boost problem, too. That would lend credence to the idea that annobin has something to do with the issue. Another data point: the first time I saw this problem was just after annobin-8.3-1 landed in Rawhide. I see that annobin-8.4-1 is in there now, but another build attempt for openfst with that version still shows the issue. -- 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/KVSSMDG7LFSKFFK3OGOO6HJSHPC4GX6P/
Re: Packages which needlessly use %defattr
On 07/04/2018 03:18 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jul 03, 2018 at 02:02:16PM -0500, Jason L Tibbitts III wrote: >> I ran the find-needless-defattr command from >> https://pagure.io/fedora-misc-package-utilities to find specfiles which >> include a non-default-changing %defattr as the first line of a %files >> section. This found 2513 packages. Because this number is so large, I >> was not able to verify each result manually but I did check a random >> sample of 50 packages and found the results to be correct. > >> Since this >> change is so simple, I may begin doing automated cleanup once F29 >> branches but feel free to fix your packages at any time. Since I am >> running this against the nightly specfile tarball, a rebuild is not >> needed for the script to notice that a package has been fixed. > > What about just doing a mass specfile update now? I think asking > individual maintainers to fix their packages isn't worth their > time. It's a safe change, just announce it, and patch all 2513 > packages a week later, without building. Also, there's no reason imho > to delay this until after branching, now is very good time for this > kind of fix. I agree. If this could be done before mass rebuild we can catch any issues/typos/mistakes in this with the mass rebuild. kevin 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/XD7PSMZSGOYSHNSHTRXEQQFFMCVUAROK/
Self Introduction: Jani Juhani Sinervo
Hi all! I'm a second-year university computer science student (well, the second year technically starts this September, but details :P) I've been using Fedora on and off for a few months now, and felt like it'd be only fair that I give back to the community that has made my own computing a breeze. I just submitted my first contribution to this project, which is a package for the Vis editor, whose review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=1598982 I hope that the co-operation with myself and the project shall be fuitful! Best regards, Jani Sinervo (sham1) ___ 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/6YBJLSGP34VEUJADLNICZH7Z75OW77IT/
Re: Your package doesn't build with Python 3.7
https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/ See: https://copr.fedorainfracloud.org/coprs/ttorling/pystatgrab/ (I didn’t try to build any other architectures on copr) On Sat, Jul 7, 2018 at 10:06 AM Sergio wrote: > What you add to rawhide repos ? We still haven't composes of rawhide with > python 3.7 . Please and thanks > > Sent from my Android > Em 06/07/2018 9:55 da tarde, Tim Orling escreveu: > > 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.org/archives/list/devel@lists.fedoraproject.org/message/DMWCEHQIOTWJ2MXWY2T4YFBHUT263CFS/ > > > ___ 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/ZZPTR2V4OCON7ECCVQC3Y7TRPRSO4N6B/
Re: Your package doesn't build with Python 3.7
What you add to rawhide repos ? We still haven't composes of rawhide with python 3.7 . Please and thanks Sent from my AndroidEm 06/07/2018 9:55 da tarde, Tim Orling escreveu: > > 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.org/archives/list/devel@lists.fedoraproject.org/message/DMWCEHQIOTWJ2MXWY2T4YFBHUT263CFS/ > > ___ 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/ILJFAUNQGLYIOMJUYLJJT4CJZA7XAGHO/
Re: installing glibc-minimal-langpack in buildroots
Posting on top becauseessage is really long and there is nothing to comment on. So what do you propose? Here we have thread about pulling all Lang's instead of just minimal set. You describe how Solaris works. If you feel that there is architecture change is needed, then please start separate topic. On Fri, Jul 6, 2018, 18:32 Tomasz Kłoczko wrote: > 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/ > -- -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/3YB55YBMOOHYIXV5IPEZFZEO5BGVCE35/
Re: F29 System Wide Change: Remove Excessive Linking
On Tue, Jul 03, 2018 at 10:21:42AM +0200, Jan Kurik wrote: > * 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. That is not true, this option is quite dangerous and breaks a lot of stuff, ask SUSE people or other distros on how many times they need to add workarounds for this. 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/DDVU26FKAABQW5CPE3TY7RWVVKLOPCKA/
Re: F29 System Wide Change: Remove Excessive Linking
On Sat, Jul 7, 2018 at 11:27 AM Matthew Miller
wrote:
> On Tue, Jul 03, 2018 at 10:21:42AM +0200, Jan Kurik wrote:
> > 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.
>
> This might reduce auto-generated dependencies, too, right? Generally
> that's a good thing, but of course there's always the off chance that
> something that someone expects to be there because it was always pulled
> into an install by a dep now won't be
>
Yes, RPM generates dependencies based on what binary is linked against.
With spec below, change produces this result:
⋊> ~/r/SPECS rpm -qpR
/home/brain/rpmbuild/RPMS/x86_64/hello-1-1.fc29.no_as_needed.x86_64.rpm
libatk-1.0.so.0()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libcairo-gobject.so.2()(64bit)
libcairo.so.2()(64bit)
libfribidi.so.0()(64bit)
libgdk-3.so.0()(64bit)
libgdk_pixbuf-2.0.so.0()(64bit)
libgio-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libgtk-3.so.0()(64bit)
libpango-1.0.so.0()(64bit)
libpangocairo-1.0.so.0()(64bit)
libpthread.so.0()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)
⋊> ~/r/SPECS rpm -qpR
/home/brain/rpmbuild/RPMS/x86_64/hello-1-1.fc29.as_needed.x86_64.rpm
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libgtk-3.so.0()(64bit)
libpthread.so.0()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)
And here is the spec:
Name: hello
Version:1
Release:1%{?dist}
Summary:Hello
License:Public Domain
URL:https://fedoraproject.org
BuildRequires: gcc
BuildRequires: pkgconfig(gtk+-3.0)
%description
%{summary}.
%prep
%setup -c -T
cat > hello.c << EOF
#include
#include
int
main (int argc,
char *argv[])
{
gtk_init(&argc, &argv);
printf("Hello!\n");
return 0;
}
EOF
%build
gcc %{build_cflags} $(pkg-config --cflags gtk+-3.0) hello.c -o hello
%{build_ldflags} $(pkg-config --libs gtk+-3.0)
%install
install -Dpm0755 -t %{buildroot}%{_bindir} hello
%files
%{_bindir}/hello
%changelog
> --
> Matthew Miller
>
> Fedora Project Leader
> ___
> 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/2YS4DBHOHVWN4IUPQ3VLXYNAUOYAJ2FR/
>
--
-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/IFCPR574TD4DKJNRMPKUOVS6ZYRBMVXL/
Re: F29 System Wide Change: Remove Excessive Linking
On Sat, Jul 7, 2018 at 5:18 AM Matthew Miller wrote: > > On Tue, Jul 03, 2018 at 10:21:42AM +0200, Jan Kurik wrote: > > 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. > > This might reduce auto-generated dependencies, too, right? Generally > that's a good thing, but of course there's always the off chance that > something that someone expects to be there because it was always pulled > into an install by a dep now won't be > This has actually been the default in Mageia for quite a long time, since the times of Mandriva. We even have a wiki page describing the problems of overlinking[1]. [1]: https://wiki.mageia.org/en/Overlinking_issues_in_packaging -- 真実はいつも一つ！/ 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/X2URWLQRPB5HQ4RQWUYPM3LJ4VTVL2LL/
Re: Compiling binaries with PGO (Profile-Guided Optimization)
On Sat, Jul 07, 2018 at 06:18:41AM -0400, Matthew Miller wrote: > On Sat, Jul 07, 2018 at 06:04:20AM -0400, Charalampos Stratakis wrote: > > Not sure if that is possible for getting official signed builds for > > those arch's. > > Could whatever output from the benchmark build be saved in a file and > added as a separate source file? With normal PGO hardly, because the *.gcda files need to match exactly the sources (so any time you'd change anything in the sources, you'd need to drop all the (on the side?) *.gcda files). Anyway, the packages that take many hours to days to build on the extremely slow architectures (arm/aarch64 :( ) aren't the only packages that would benefit from PGO, e.g. building bash, or findutils etc. with PGO with training on some reasonable typical workloads is very helpful too. I think e.g. OpenSUSE does that much more often than our packages. 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/L3FJTW4GJFBLSZHL5AGX75I2JVI4MLU6/
Re: Compiling binaries with PGO (Profile-Guided Optimization)
On Sat, Jul 07, 2018 at 06:04:20AM -0400, Charalampos Stratakis wrote: > Not sure if that is possible for getting official signed builds for > those arch's. Could whatever output from the benchmark build be saved in a file and added as a separate source file? -- Matthew Miller Fedora Project Leader ___ 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/GQN3H5762TVTIYTNMQAWSSBV7JQM52RO/
Re: Compiling binaries with PGO (Profile-Guided Optimization)
- Original Message - > From: "Matthew Miller" > To: "Development discussions related to Fedora" > > Sent: Saturday, July 7, 2018 11:21:51 AM > Subject: Re: Compiling binaries with PGO (Profile-Guided Optimization) > > On Fri, Jul 06, 2018 at 01:46:17PM -0400, Charalampos Stratakis wrote: > > 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. > > Hmmm. It seems like the slow architectures is where the _benefit_ will > be most interesting, too. Is there a way to run outside the koji build > and cache the results? > Not sure if that is possible for getting official signed builds for those arch's. But it would be certainly interesting testing the rpm's from a scratch build and benchmarking various workloads on the slow arch's. Python 3 builds, depending on the host, can take from 1h30m up to 3h and extending that to more than double would hinder the speed of pushing fixes fast for a core component of the operating system like python, hence the decision for limiting PGO to only specific architectures. If however the benefits would be considered significant, especially on the "snappiness" of the operating system, I'd be inclined to enable it. > -- > Matthew Miller > > Fedora Project Leader > ___ > 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/UZAVQY5CQUP5QBWFY46IZHTTG2CJV5SW/ > -- 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/MGGIRTGVMJAEV43XQKUENO24EWANHFFK/
Re: Compiling binaries with PGO (Profile-Guided Optimization)
On Fri, Jul 06, 2018 at 01:46:17PM -0400, Charalampos Stratakis wrote: > 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. Hmmm. It seems like the slow architectures is where the _benefit_ will be most interesting, too. Is there a way to run outside the koji build and cache the results? -- Matthew Miller Fedora Project Leader ___ 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/UZAVQY5CQUP5QBWFY46IZHTTG2CJV5SW/
Re: F29 System Wide Change: Remove Excessive Linking
On Tue, Jul 03, 2018 at 10:21:42AM +0200, Jan Kurik wrote: > 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. This might reduce auto-generated dependencies, too, right? Generally that's a good thing, but of course there's always the off chance that something that someone expects to be there because it was always pulled into an install by a dep now won't be -- Matthew Miller Fedora Project Leader ___ 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/2YS4DBHOHVWN4IUPQ3VLXYNAUOYAJ2FR/
