devel December 2019

devel@lists.fedoraproject.org

196 participants
275 discussions

Adding Obsoletes to generated -debuginfo packages ?
by Daniel P. Berrangé 04 Jun '20

04 Jun '20

In libvirt we recently deleted a driver for the legacy Xen toolstack. This was shipped in a libvirt-daemon-driver-xen RPM. I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users. If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade. How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

7 12

New set of questions for FESCo candidates?
by Zbigniew Jędrzejewski-Szmek 15 May '20

15 May '20

Dear all, the semiannual exercise is upon us. FESCo candidates must submit an "interview" in which they answer a set of questions (but can also add whatever they want). The question whether we should have a new set of questions needs to be answered. Currently we have the following: Mandatory Question #1: Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues? Mandatory Question #2: What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development? Mandatory Question #3: What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"? Please answer with any proposals. If there is sufficient support for change, I'll gather a list and submit this for some kind of poll (details to be figured out...). Zbyszek

13 24

python-pep8 is orphaned
by iliana weller 03 May '20

03 May '20

Hello, I've orphaned python-pep8. pep8 was renamed to pycodestyle in 2016; it received its last release in 2017. It should be removed from Fedora in a future release. I unfortunately don't have time to proceed with the full retirement process myself. If somebody would like to pick it up: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#C… $ dnf repoquery --whatrequires python2-pep8 python2-autopep8-0:1.2.4-9.fc29.noarch python2-pytest-pep8-0:1.0.6-15.fc29.noarch python2-spyder-0:3.3.1-3.fc29.noarch $ dnf repoquery --whatrequires python3-pep8 python3-autopep8-0:1.2.4-9.fc29.noarch python3-hacking-0:1.1.0-3.fc29.noarch python3-pytest-pep8-0:1.0.6-15.fc29.noarch python3-spyder-0:3.3.1-3.fc29.noarch See also https://bugzilla.redhat.com/show_bug.cgi?id=1667200's dependent bugs. (Please CC me on replies that need my attention.) -- iliana weller <ilianaw(a)buttslol.net>

7 9

orphaning bleachbit
by Mukundan Ragavan 02 May '20

02 May '20

I intend to orphan bleachbit soon. If anyone is interested please let me know and I will transfer the package. https://src.fedoraproject.org/rpms/bleachbit Mukundan.

15 30

Fedora 32 Self-Contained Change proposal: Build Python with -fno-semantic-interposition for better performance
by Ben Cotton 23 Apr '20

23 Apr '20

https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup Simplified version of another change proposal|This change was originally proposed for [[Releases/32|Fedora 32]] as [[Changes/PythonStaticSpeedup]], however based on [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… community feedback], it has been significantly reduced. == Summary == We add the <code>-fno-semantic-interposition</code> compiler/linker flag when building Python interpreters, as it provides significant performance improvement, up to 27% depending on the workload. Users will no longer be able to use LD_PRELOAD to override a symbol from libpython, which we consider a good trade off for the speedup. == Owner == * Name: [[User:Cstratak| Charalampos Stratakis]], [[User:Vstinner| Victor Stinner]], [[User:Churchyard| Miro Hrončok]] * Email: python-maint(a)redhat.com * Shout-out: [[User:Jankratochvil|Jan Kratochvíl]] for first suggesting this instead of the original proposal, followed by [[User:Kkofler|Kevin Kofler]]. [[User:Fweimer|Florian Weimer]] for providing answers to our questions. David Gray for originally suggesting to link Python statically to gain performance. == Detailed Description == When we build the Python interpreter with the <code>-fno-semantic-interposition</code> compiler/linker flag, we can achieve a performance gain of 5% to 27% depending on the workload. Link time optimizations and profile guided optimizations also have a greater impact when python3 is built this way. As a negative side effect, it disables the LD_PRELOAD feature: it's no longer possible to override symbols in libpython with LD_PRELOAD. Interposition is enabled by default in compilers like GCC: function calls to a library goes through a "Procedure Linkage Table" (PLT). This indirection is required to allow a library loaded by LD_PRELOAD environment variable to override a function. The indirection puts more pressure on the CPU level 1 cache (instruction cache). In term of performance, the main drawback is that function calls from a library to the same library cannot be inlined, to respect the interposition semantics. Inlining is usually a big win in term of performance. Disabling interposition for libpython removes the overhead on function calls by avoiding the PLT indirection, and allows to inline more function calls. We're describing function calls from libpython to libpython, something which is very common in Python: almost all function calls are calls from libpython to libpython. If Fedora users need to use LD_PRELOAD to override symbols in libpython, the recommend way is to build a custom Python without <code>-fno-semantic-interposition</code>. It is still possible to use LD_PRELOAD to override symbols in other libraries (for example in glibc). === Affected Pythons === Primarily, we will change the interpreter in the {{package|python3}} package, that is Python 3.8 in Fedora 32 and any later version of Python in future Fedora releases. Impact on other Python packages (and generally software using Python) is not anticipated (other than the possible speedup). We will also change the [https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.… alternate Python interpreters] where possible and useful, primarily the upstream supported versions of CPython, such as {{package|python39}} (if already packaged), {{package|python37}} and {{package|python36}}. === Affected Fedora releases === This is a Fedora 32 change and it will be implemented in Rawhide (Fedora 32) only. Any future versions of Fedora will inherit the change until it is reverted for some reason. If it turns out that there are absolutely no issues, we might consider backporting the speedup to already released Fedora versions (for example Fedora 31). Such action would be separately coordinated with [https://docs.fedoraproject.org/en-US/fesco/ FESCo]. == Benefit to Fedora == Python's performance will increase significantly depending on the workload. Since many core components of the OS also depend on Python this could lead to an increase in their performance as well, however individual benchmarks will need to be conducted to verify the performance gain for those components. [https://pyperformance.readthedocs.io/ pyperformance] results, ignoring differences smaller than 5%: (See change proposal) == Scope == * Proposal owners: ** Review and merge the [https://src.fedoraproject.org/rpms/python3/pull-request/151 pull request with the implementation]. ** Monitor Koschei for significant problems. ** Backport the change to alternate Python versions. * Other developers are encouraged to check if their package works as expected * Release engineering: N/A (not needed for this Change) -- this change does not require a mass rebuild nor any other special releng work * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Python package maintainers should verify that their packages work as expected and the only impact the end users should see is a performance increase for workloads relying on Python. == How To Test == Test that everything Python related in Fedora works as usual. === Was the flag applied test === You can test whether the <code>-fno-semantic-interposition</code> flag was applied for your Python build: <pre> >>> import sysconfig >>> '-fno-semantic-interposition' in (sysconfig.get_config_var('PY_CFLAGS') + sysconfig.get_config_var('PY_CFLAGS_NODIST')) True >>> '-fno-semantic-interposition' in (sysconfig.get_config_var('PY_LDFLAGS') + sysconfig.get_config_var('PY_LDFLAGS_NODIST')) True </pre> Before the change, you would see <code>False</code>, <code>False</code>. === Performance test === The performance speedup can be measured using the official Python benchmark suite [https://pyperformance.readthedocs.io/ pyperformance]: see [https://pyperformance.readthedocs.io/usage.html#run-benchmarks Run benchmarks]. == User Experience == Python based workloads should see a performance gain of up to 27%. == Dependencies == This change is not dependent on anything else. == Contingency Plan == * Contingency mechanism: If issues appear that cannot be fixed in a timely manner the change can be easily reverted and will be considered again for the next fedora release. * Contingency deadline: Before the beta freeze of Fedora 32 (2020-02-25) * Blocks release? Yes * Blocks product? None == Documentation == This change proposal has all the documentation. See the [[Changes/PythonStaticSpeedup|previous change proposal]] and the [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… thread about it on the devel mailing list] for more relevant information about what we are not doing -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

2 1

Announcing new anitya integration and de-orphaning process
by Pierre-Yves Chibon 16 Apr '20

16 Apr '20

Good Morning Everyone, Tomorrow we are planning on deploying a new version of pagure and pagure-dist-git on production. These changes come with two changes to the packager workflow: * Anitya integration in dist-git Something we lost when loosing pkgdb was the easy integration to anitya (https://release-monitoring.org) With the coming changes we are getting them back. On the left hand-side column, there will be a drop-down button allowing to change the settings for anitya for the project. Existing status will be migrated from the fedora-scm-requests repo on pagure to use this drop-down. Using the fedora-scm-requests repo for the anitya integration will no longer be supported. * Change in the de-orphaning process Currently if a package is orphaned, one has to open a ticket against the releng project to adopt it. With these changes, anyone will be able to adopt orphaned projects (not retired on master) directly from dist-git's UI. If the project is retired or has been orphaned for too long, a ticket on the releng project will still be required though. Both of these changes can already be reviewed in staging at: https://src.stg.fedoraproject.org Looking forward for your feedback! Pierre _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…

13 17

Schedule for Thursday's FPC Meeting (2019-08-15 16:00 UTC)
by James Antill 09 Apr '20

09 Apr '20

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-08-15 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2019-08-15 09:00 PDT US/Pacific 2019-08-15 12:00 EDT --> US/Eastern <-- 2019-08-15 16:00 UTC UTC 2019-08-15 17:00 BST Europe/London 2019-08-15 18:00 CEST Europe/Berlin 2019-08-15 18:00 CEST Europe/Paris 2019-08-15 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2019-08-16 00:00 HKT Asia/Hong_Kong 2019-08-16 00:00 +08 Asia/Singapore 2019-08-16 01:00 JST Asia/Tokyo 2019-08-16 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #902 Cleanup & enhance spec files .fpc 902 https://pagure.io/packaging-committee/issue/902 #topic #904 Caret versioning .fpc 904 https://pagure.io/packaging-committee/issue/904 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #914 Automatic R runtime dependencies .fpc 914 https://pagure.io/packaging-committee/issue/914 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * 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.

2 1

Orphaning owncloud and nextcloud
by James Hogarth 04 Apr '20

04 Apr '20

Hi all, It's become clear that I haven't had the time I thought I'd have this past year due to $life ... These are in a bit of a broken state and right now I'd advise people that need them to use upstream packages/containers. I don't foresee sufficient time coming in the near future with family needs in advance of hobbies like Fedora of course. I'll give it a week or so for anyone to contact me who wants to pick them up, otherwise I'll update pagure to assign them to "orphan" James

6 17

Release rpkg-1.58 fedpkg-1.37
by Ondrej Nosek 17 Mar '20

17 Mar '20

Hi all, a new version rpkg-1.58 and fedpkg-1.37 is released. Currently, Fedora 30 packages are in the stable repository, feel free to try other waiting distributions in Bodhi. Numerous features and improvements (as well as bugfixes) includes: (For "rpkg") - Improvements for scratch module builds - Allow passing arguments to “mbs-manager build_module_locally” - Remove the ability to parse a module’s branch - Permit setting arbitrary rpm macros during build - Ignore specific files in a cloned repository - Pass specific arguments to “mock” - Added “depth” argument to "git clone" - Watch multiple module builds - Show module build links in output from command module-build - Add the ability to configure multiple regex expressions - Add “retire” command supporting both packages and modules - Import srpm without uploading sources - Ignore any specified profile when finding the Flatpak build target - Added update-docs script - And other fixes and small improvements (For "fedpkg") - Ignore files in a cloned repository - Enable shell completion for module scratch builds - Show hint when Pagure token expires - Include possible distprefix in “–define dist” for Forge-based packages - Other small fixes More specific changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.58.html https://docs.pagure.org/fedpkg/releases/1.37.html Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.58-1.el6&builds=rpkg… Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 rpkg is available from PyPI. Thanks to all contributors. Regards

2 2

Fonts packaging policy rewrite proposal
by Nicolas Mailhot 14 Mar '20

14 Mar '20

Hi, A fonts packaging policy rewrite proposal has been pushed to FPC today: https://pagure.io/packaging-committee/pull-request/934 It should be clearer, more opinionated, and take into account: – updates of The OpenType standard – variable fonts – web fonts – upstream depreciation of non OpenType formats: final stages of the Harfbuzz consolidation decided at the 2006 Text Layout summit https://www.freedesktop.org/wiki/TextLayout/ – appstream & fonts – weak dependencies – and probably more I forget here It is based on the new fonts-rpm-macros project for automation: This project builds on tooling enhancements in redhat-rpm-config and rpm itself, done during the past two years for the Forge and Go sets of packaging macros. It started 2 years ago as a fork of fontpackages, which is the core of our current fonts packaging guidelines. It will require putting the fonts-srpm-macros package in the default build root, like is done for other domain-specific packaging macro sets. Major additions: – better documentation (clearer and more complete) – better automation (less packager hassle for better and more complete results) Major removals: – tools and scripts – fixing metadata with ttname Mostly because no one seems willing to maintain those scripts, or port ttname to python 3. https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/ showcases the new policy on 62 real-world source packages, generating 139 installation packages. Some of those are badly delayed updates to Fedora packages, others are brand-new packages ready for Fedora inclusion. They include major font packages such as Stix, DejaVu, Droid, IBM Plex. Existing Fedora packages will continue to build, the old fontpackages macros are grandfathered in fonts-rpm-macros for now. They will be removed in a few years to give packagers time to apply the new guidelines. Regards, -- Nicolas Mailhot

2 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel December 2019