devel May 2018

devel@lists.stg.fedoraproject.org

192 participants
212 discussions

Updates to mathematical software
by Jerry James 07 Aug '18

07 Aug '18

Hello everyone. Months ago, I started working on updates to a couple of our mathematical packages. But they, in turn, required other packages to be updated, and those updates required other packages to be updated, and the whole thing kind of snowballed. I believe that I have finally reached a point of closure, where I can update the whole pile and have everything still work afterwards. I propose to do the following updates and builds in Rawhide in about a week. If maintainers of any of these packages object, please let me know the nature of your objection. The only explicit soname bump in these updates is libntl.so.35 to libntl.so.36. However, there are a few other libraries that changed ABI without a corresponding soname bump (typically with an soname of libfoo.so.0, sigh), so I will rebuild all consumers. Changes: - arb: update from 2.11.1 to 2.13.0 - brial: update from 0.8.5 to 1.2.3. Build for both python 2 and 3. Add a %check script. - cbmc: rebuild for glpk 4.65 - coin-or-lemon: rebuild for glpk 4.65 - eclib: update from 20170815 to 20171002 - fflas-ffpack: update from 2.2.2 to 2.3.2. Drop all patches. - flint: rebuild for ntl 11.0.0. Attempt to work around bz 1555151 on arm. - gap-pkg-float: rebuild for libfplll 5.2.1 and mpfi 1.5.3 - gfan: build libgfan as a shared library and distribute it in a new subpackage, which obsoletes the erroneous gfanlib subpackage of Singular. - giac: rebuild for libfplll 5.2.1 and mpfi 1.5.3 - givaro: update from 4.0.2 to 4.0.4 - glpk: update from 4.61 to 4.65. Add a patch slated for 4.66, needed by sagemath. Build with ODBC and MariaDB support. - latte-integrale: rebuild for ntl 11.0.0 and glpk 4.65 - libfplll: update from 5.1.0 to 5.2.1. Drop the rounding patch, fixed upstream. - libgap: require the GAP default packages (silences startup warnings about missing packages). - linbox: update from 1.4.2 to 1.5.2. Drop upstreamed fplll patch. Add gcc8 patch as recommended by upstream to fix a C++ issue. - Macaulay2: update from 1.9.2 to 1.11. Drop upstreamed verbose_build, givaro, pari, and endian patches. - mpfi: update from 1.5.1 to 1.5.3. Drop the aarch64 patch, fixed upstream. - normaliz: update from 3.4.0 to 3.5.4. Drop all patches. - ntl: update from 10.5.0 to 11.0.0 - octave: rebuild for glpk 4.65 - openms: rebuild for glpk 4.65 - pari: backport ellratpoints and hyperellratpoints from pari 2.10 alpha, needed by sagemath. The alternative is to update pari to an alpha version, which makes me very uncomfortable. - polymake: update from 3.1 to 3.2r3. Drop upstreamed gcc7 patch. - ppl: rebuild for glpk 4.65 - pynac: update from 0.7.8 to 0.7.16. Drop arch conditionals for giac, which is now available on all supported arches. - python-cvxopt: update from 1.1.9 to 1.2.0 - python-cypari2: update from 1.1.3 to 1.1.4. Drop upstreamed offbyone patch. - python-cysignals: update from 1.6.4 to 1.7.1 - python-flask-autoindex: update from 0.4.1 to 0.6. Drop upstreamed tests patch. Build for both python 2 and 3. Build and package the documentation. - python-flask-silk: update from 0.1.2 to 0.2. Do not bundle flask-sphinx-themes. Build for both python 2 and 3. Build and package the documentation. Add a %check script. - python-fpylll: update from 0.2.4dev to 0.4.0dev for libfplll 5.2.1. - python-gmpy2: update from 2.0.8 to 2.1.0a2. The alpha version has some functions required by the latest sagemath. Since the only consumers of this package currently in Fedora are sagemath and sympy, which is consumed by sagemath, I figure that if the sagemath team is going to require an alpha version, they are only hurting themselves if something goes wrong. - sagemath: update from 8.0 to 8.2. Numerous changes were necessary to make this work. - shogun: rebuild for glpk 4.65. Add two patches to fix FTBFS. The sources use some deprecated json-c macros, which are no longer defined by default; the first patch includes the relevant header. The second patch works around a bug in pybtex, which has already been reported to upstream pybtex and fixed in git. If a new pybtex release is made soon, I will build it and drop this patch. - Singular: drop the mistakenly exposed gfanlib package; build with libgfan instead. Rebuild for ntl 11.0.0 and polymake 3.2r2. Drop the sequence-point patch, which patches the libgfan sources. NOTE ON MPFR: There is an update to mpfr 4 in the works: https://fedoraproject.org/wiki/Changes/mpfr-4.0.0. The above updates help that effort in the following ways: - The mpfi update brings in a version that is compatible with both mpfr 3 and 4, so when the time comes, simply rebuilding against mpfr 4 will work. - The sagemath update brings in a version that wants mpfr 4. For now, I will patch it to use the old mpfr 3 interface. Once we have mpfr 4 available, all we have to do is remove that patch and rebuild. Let me know of any concerns you might have about this pile of updates. As usual with this particular set of packages, some builds take many hours, so the rebuilds will probably span multiple days. Expect broken deps reports out of Rawhide while in the middle. They will disappear once the entire stack has been built. Regards, -- Jerry James http://www.jamezone.org/

5 9

[fesco] Updated FTBFS package policy
by Zbigniew Jędrzejewski-Szmek 26 Jul '18

26 Jul '18

Fedora package maintainers, FESCo approved an updated policy for packages which fail to build from source during mass rebuilds (FTBFS) [1]. The updated policy is still at https://fedoraproject.org/wiki/Fails_to_build_from_source. Highlights: - packages which FTBFS are subject to orphaning if there is no maintainer acknowledgement within 8 weeks - packages which FTBFS in two consecutive mass rebuilds will be retired soon after the second mass rebuild The implementation of this policy hinges on improving the releng scripts used to create and manage FTBFS bugs. There is approximately two months until the next use of those scripts, so I'm hopeful we'll get them working. If your package wasn't successfully built for F28, please fix that! [1] https://pagure.io/fesco/issue/1890 [2] https://pagure.io/fesco/issue/1877#comment-509161

9 12

Intent to orphan Python 2
by Petr Viktorin 22 Jul '18

22 Jul '18

tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now. Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance. Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help. We (rightly) don't have the authority to say "please drop your unneeded python2 subpackages, or let us drop them for you" [0]. The next best thing we *can* say is: "if Fedora is to keep python2 alive, we won't be the ones doing it – at least not at the current magnitude". Here are the details. The current maintainers of python2 would like to "orphan" the python2 package in 2020 (~ Fedora 30): - Charalampos Stratakis (cstratak) - Tomáš Orsava (torsava) - Miro Hrnočok (churchyard) - Petr Viktorin (pviktori) - Iryna Schcherbina (ishcherb) - Michal Cyprian (mcyprian) - Bohuslav Kabrda (bkabrda) - David Malcolm (dmalcolm) - Thomas Spura (tomspur) As with any orphaning, that leaves two options: - someone else agrees now to take over in 2020 (keeping in mind this is a security-critical package and will be abandoned upstream), or - dependent packages drop support for Python 2. Unlike most other orphanings, we have some thousands of dependent packages, so a lot of time and care is required. In case no one steps up, we'd like to start dropping Python 2 support from dependent packages *now*, starting with ported libraries on whose python2 version nothing in Fedora depends. (We keep a list of those at [1].) Of course, we're ready to make various compromises with interested packagers, as long as there's an understanding that we won't just support python2 forever. If you are a maintainer of anything at [1] we ask you kindly to consider removing the python2 subpackages. You can either do it now in Rawhide, or add a conditional for Fedora > 29. (On the current schedule, Fedora 30 will be the first release still supported after 2020-01-01.) If no one steps up to maintain python2 after 2020, we're prepared to package a "legacy" python27 package, similar to what we do for e.g. python33 [2], to: - help developers that still need to test against this version - support exceptionally important non–security critical applications, if their upstreams don't manage to port to Python 3 in time [0] https://pagure.io/packaging-committee/issue/753 [1] http://fedora.portingdb.xyz/#legacy-leaf [2] https://src.fedoraproject.org/rpms/python33/

25 65

Hiding the grub menu by default on single OS installs
by Hans de Goede 10 Jul '18

10 Jul '18

Hi All, I'm working on improving the Fedora boot experience, with the end goal being a user pressing the on button and then going to the graphical login manager without him seeing any text messages / menus filled with technical jargon. IIRC we used to hide the grub-menu by default on single OS installs, but we seemed to have stopped doing that, for new Fedora 29 installs I would like us to start hiding the menu by default on single OS installs again, see: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu The goal if this email is to: 1) Give people an advance warning about the plan to change this so we can discuss this early on 2) See if anyone knows why we stopped doing this, I think we may simply have stopped doing this to simplify to bootconfig code in anaconda and because we did not always identify the single OS case correctly, but I wonder if there were other reasons? Regards, Hans

43 71

Valid use case for modularity or not?
by Fabio Valentini 29 Jun '18

29 Jun '18

Hi all, I think I finally found a scenario where building some of my (and others') packages as modules would be beneficial. The situation is: - The syncthing package has a lot of golang dependencies. - Some of them are too old in fedora, even in fedora rawhide, and some of them have not been touched in years. - However, some other packages may depend on those older versions, or the packagers don't have time to check for compatibility. The idea for a solution I came up with: - Build syncthing as a module. - Add "syncthing" branches to all incompatible dependencies (I guess I have to request commit/admin access to do that for packages I don't own yet?). - Update those branches to use the exact same commit as the vendored sources in upstream syncthing. - Use those modules as dependencies for the syncthing module. Is that a valid, feasible use case of modularity? Fabio

5 9

F29 System Wide Change: Hide the grub menu
by Jan Kurik 28 Jun '18

28 Jun '18

= Proposed System Wide Change: Hide the grub menu = https://fedoraproject.org/wiki/Changes/HiddenGrubMenu Owner(s): * Hans de Goede <hdegoede at redhat dot com> On systems with only a single OS installed, the grub menu does not offer any useful functionality, so we should hide it by default. == Detailed description == On systems with only a single OS installed, the grub menu's only function is to allow booting older kernels, which is only necessary as a rescue option in case of a severe kernel bug and as such not something which is directly useful for normal use. Fedora already has a lot of work done to not show too technical boot messages to end users during bootup, e.g. we pass quiet to the kernel and we've plymouth to show a bootsplash instead of a bunch of "Starting service-foo: OK" messages. The grub menu with its kernel versions is another example of showing too technical info to end-users and on non multi-boot systems it normally is not necessary, so it is better to hide it. The implementation of this consists of the following changes: 1. Currently if the menu is hidden the user needs to press ESC to show it, modify grub to also except F8 as show-menu key, there are 2 reasons for this: 1.1 F8 is (was) the key to bring up the boot/rescue menu in Windows 1.2 On some machines ESC brings up the firmware-setup menu 2. On non multi-boot systems set GRUB_HIDDEN_TIMEOUT=1 and GRUB_HIDDEN_TIMEOUT_QUIET="true" in /etc/default/grub == Scope == * Proposal owners: 1. Add patches to grub to also make pressing F8 show the menu 2. Make sure this is all properly documented in release-notes, etc. 3. Write patches for anaconda to set GRUB_HIDDEN_TIMEOUT=1 and GRUB_HIDDEN_TIMEOUT_QUIET="true" in /etc/default/grub on non multi-boot systems * Other developers: The anaconda developers will need to review and merge the /etc/default/grub related patches * Release engineering: https://pagure.io/releng/issue/7539 ** List of deliverables: all * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: 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

23 55

Prioritizing ~/.local/bin over /usr/bin on the PATH
by Tomas Orsava 26 Jun '18

26 Jun '18

Hi! I'd like to propose putting the ~/.local/bin in front of the /usr/bin on the PATH. Currently /usr/bin has priority over ~/.local/bin, which causes a [bug] where the old system-installed executable written in Python (from /usr/bin) is launched, but it finds new Python sources (installed into $HOME) which it doesn't work with and crashes. [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650 I believe the current configuration breaks the intuitive expectation that things installed closer to the user should take priority. That's for example how it works with Python. Interestingly, ubuntu and opensuse do not have ~/.local/bin on their PATH (though Ubuntu has ~/bin) so we can't take guidance there. Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin? Regards, Tomas

24 70

ga (global arrays) package maintainer needed
by Marcin Dulak 12 Jun '18

12 Jun '18

Hi, I have a problem with an unmaintained https://src.fedoraproject.org/rpms/ga, a dependency for https://src.fedoraproject.org/rpms/nwchem. Recently nwchem unbundled ga from its sources https://github.com/nwchemgit/nwchem/issues/28, but that requires a recent ga version, built in a way that makes `${EXTERNAL_GA_PATH}/bin/ga-config` available. ga seems unmaintaned https://bugzilla.redhat.com/show_bug.cgi?id=1432661, and therefore I'm looking for someone who can take it over. I believe I'm not allowed to bundle ga in nwchem https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplicatio…, and in this case if ga (in Fedora and EPEL) does not follow closely the nwchem development cycle I'll need to retire nwchem. ga seems to be used only as nwchem dependency on Fedora/EPEL as seen from `repoquery --whatrequires ga-openmpi` Marcin

5 5

HEADS UP - libbson and libmongoc soname bump in rawhide
by Remi Collet 11 Jun '18

11 Jun '18

Hi, Both libraries are now build from the same source tarball (upstream change), see mongo-c-driver package Soname are bumped - libbson-1.0.so.0 => libbson-1.0.so.1 - libmongoc-1.0.so.0 => libmongoc-1.0.so.1 Please take care of rebuilding your packages Regards, Remi

1 4

equivalent of Debian config-package?
by Dave Love 07 Jun '18

07 Jun '18

Is there any existing system for rpm like the Debian one <https://debathena.mit.edu/config-package-dev/> for building local configuration packages? If not, would it be feasible to implement one?

7 16

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel May 2018