devel August 2021

devel@lists.stg.fedoraproject.org

183 participants
358 discussions

deltarpm usefulness?
by Marek Marczykowski-Górecki 08 Nov '21

08 Nov '21

Hi all, I think deltarpm is not really useful anymore: - there are very few drpm files in the repository, see for example: https://download.fedoraproject.org/pub/fedora/linux/updates/34/Everything/x… https://download.fedoraproject.org/pub/fedora/linux/updates/33/Everything/x… - those that actually are there, are mostly about small packages anyway - personally, I haven't seen it being used for a long time - there is also argument that people's connection bandwidth nowadays tends to be fast enough to make the package rebuilding actually slower than downloading the whole package (but that really vary between different installations) - and most importantly: drpm files are - by design - processed before checking the package signature, which exposes rather big attack surface(*) Can deltarpm be disabled by default? In the few cases where it's actually useful (if there are any...), user is free to enable it, but the default would be significantly more secure this way. (*) it is integrity protected via a hash in the repository metadata, but repository metadata in Fedora are still not signed - so this all heavily depends on the integrity of the [HTTPS connection to] mirrors.fedoraproject.org server (or any of CAs trusted by the system) - a rather fragile single point of failure. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

16 23

openbabel-3.1* in Rawhide
by Antonio T. sagitter 07 Nov '21

07 Nov '21

Hi all. openbabel-3.1.1 is ready for Rawhide branch. 'libopenbabel' soname is updated from 5 to 7, all dependent packages will need a rebuild at least: $ repoquery --whatrequires openbabel-devel --disablerepo=* --enablerepo=*-source IQmol-0:2.15.0-3.fc34.src ghemical-0:3.0.0-16.fc34.src molsketch-0:0.7.2-1.fc34.src xdrawchem-0:1.10.2-4.fc34.src I'm waiting some days (one week around) before creating a side-tag. Ragards. -- --- Antonio Trande Fedora Project mailto: sagitter(a)fedoraproject.org GPG key: 0x29FBC85D7A51CC2F GPG key server: https://keyserver1.pgp.com/

6 31

Fedora 32 System-Wide Change proposal: iptables-nft-default
by Ben Cotton 04 Nov '21

04 Nov '21

https://fedoraproject.org/wiki/Changes/iptables-nft-default == Summary == Make iptables-nft the preferred iptables variant. == Owner == * Name: [[User:psutter| Phil Sutter]] * Email: psutter(a)redhat.com == Detailed Description == <code>iptables-nft</code> package provides alternative implementations of iptables, ip6tables, ebtables and arptables and associated save and restore commands. These use nftables internally while providing the same look'n'feel as the original tools. Users may choose between both implementations using <code>alternatives</code> tool. Upstream considers the traditional implementations legacy and therefore renamed the binaries adding '-legacy' suffix. In Fedora, same has been done to <code>arptables</code> and <code>ebtables</code> packages, namely renaming them to <code>arptables-legacy</code> and <code>ebtables-legacy</code>. Legacy <code>iptables</code> and <code>ip6tables</code> remain in <code>iptables</code> package, which in fact is the only one other packages depend upon. To change the status quo, two measures are planned: === Raise priority of nft-variants in <code>alternatives</code> === Currently, legacy variants are installed with priority 10 and nft variants with priority 5. This must be changed as otherwise installing <code>iptables-legacy</code> in a system with <code>iptables-nft</code> installed would change the active alternative (since they are in automatic mode by default). On the other hand, existing systems using legacy variants should not be changed by a system update. Therefore nft variants' priorities should be chosen to match legacy ones. === Rename <code>iptables</code> package === New name should be <code>iptables-legacy</code> which aligns with ebtables and arptables and reflects upstream status. To resolve dependencies, <code>Provides: iptables</code> statement will be added to <code>iptables-nft</code> package. This should automatically change the default variant to nft. == Benefit to Fedora == * RHEL8 ships nft-variants exclusively, make Fedora align with that by default while still providing the option to fall back to legacy tools. * New features and improvements are likely to hit nft-variants due to the possibility nftables backend allows for. Although at this point some legacy features (e.g. ebtables among match) are still missing, others are already there (like, e.g. xtables-monitor tool) or are being upstreamed right now (improved tool performance when dealing with large rulesets). == Scope == * Proposal owners: Changes are rather simple: Rename <code>iptables</code> package, add <code>Provides:</code> line to <code>iptables-nft</code> package, change priorities used when calling <code>alternatives</code>. * Other developers: N/A The changed tools may cause regressions among packages using them and it affects only new installations (or those manually switched over). So while no explicit effort is required from them, they should be made aware of the change so they take a possible regression in iptables into account, quickly test against legacy variant and file a ticket (or complain to the right person) if that fixes the problem. * Release engineering: [https://pagure.io/releng/issue/8934 #8934] * Policies and guidelines: No change required * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Due to the package rename and <code>Provides:</code> line, upgrades will pull in <code>iptables-nft</code> package. But due to the equal alternatives priorities, existing choices won't be changed and so existing installations shouldn't be harmed (apart from forced installation of <code>iptables-nft</code> package). Sadly, there are a few known issues, like e.g. missing support for ebtables broute table or among match and a few iptables targets/matches. Users depending on such features are advised to install <code>iptables-legacy</code> package and switch variants using <code>alternatives</code>. == How To Test == Any users of iptables/ebtables/arptables should switch to nft-variants using alternatives tool (if necessary) and check that everything works as before. Any issues should be reported despite the known compatibility issues described above since knowledge about who uses the missing features is valuable information for both up- and downstream. == User Experience == Ideally look'n'feel shouldn't change. Since iptables-nft does not need a lock file anymore, no problems with stale xtables-lock or parallel iptables calls in different mount namespaces are expected anymore. Given the changes currently being upstreamed, users dealing with large rulesets should see a performance increase when manipulating the ruleset (lower run-times of iptables or iptables-restore, packet processing speed should not really change). == Dependencies == Other packages depending on iptables: * NFStest * clatd * ctdb * fail2ban-server * firewalld * fwsnort * iptstate * libvirt-daemon-driver-network * libvirt-daemon-driver-nwfilter * moby-engine * nfacct * origin * podman * psad * python3-ipatests * ravada * rkt * shorewall * shorewall-init * shorewall-lite * shorewall6 * shorewall6-lite * sshuttle * sslsplit * ufw Since nft-variants are supposed to be drop-in replacements, no outside contribution is needed in order to perform this change. == Contingency Plan == * Contingency mechanism: Nothing needs to be done, the change should be atomic. * Contingency deadline: N/A * Blocks release? No == Documentation == * https://wiki.nftables.org/wiki-nftables/index.php/Legacy_xtables_tools * Man pages: ** [http://man7.org/linux/man-pages/man8/xtables-nft.8.html xtables-nft.8] ** [http://man7.org/linux/man-pages/man8/xtables-legacy.8.html xtables-legacy.8] ** [http://man7.org/linux/man-pages/man8/xtables-monitor.8.html xtables-monitor.8] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

6 10

Work getting hwcaps microchiecture package geneataion into rpm
by Reon Beon 26 Oct '21

26 Oct '21

https://hackweek.suse.com/all/projects/support-glibc-hwcaps-and-micro-archi… Comments dancermak 5 days ago by dancermak | Reply This sounds very intriguing! I have a few notes about this: you might be interested in this (sadly stalled) upstream PR: https://github.com/rpm-software-management/rpm/pull/1035 which adds better detection of the currently running microarchitecture once rpm gains the ability to automatically generate subpackages (https://github.com/rpm-software-management/rpm/pull/1485) this could be completely automated I would suggest to use actual boolean dependencies instead of packageand: Supplements: (libfoo1 and x86-64-v3) And please, please make some noise about this and coordinate it with the other rpm based distros, so that we don't end up with yet another SUSE-ism but instead lead the innovation.

3 6

x86_64-v2 in Fedora
by Neal Gompa 26 Oct '21

26 Oct '21

Hey all, Earlier this week, I was helping with processing features for openSUSE Leap 15.4[1] and I discovered that they're planning on introducing x86_64-v2 to openSUSE soon. The reference for this change was that RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions have been considering bumping up to v2 or v3[3][4]. Some cursory examination of the new x86_64 sublevels seem to indicate that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the first couple of generations of x86_64 CPUs from Intel and AMD. I personally don't have any computers that don't have support for x86_64-v2 anymore. Does anyone know if anyone is planning to propose this for Fedora anytime soon, either as an addon architecture (like what Arch is doing) or an upgrade of our x86_64 baseline like RHEL is doing? [1]: https://en.opensuse.org/Feature_Planning_15.4 [2]: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-l… [3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html [4]: https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-x86-64-v3-Po… -- 真実はいつも一つ！/ Always, there's only one truth!

31 58

Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches
by Kaleb Keithley 19 Oct '21

19 Oct '21

There is a proposal[1] in upstream GlusterFS to drop 32-bit arches. The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide. [1] https://github.com/gluster/glusterfs/issues/702 -- Kaleb

11 25

I think we should stop building i686 packages we're not shipping
by Matthew Miller 10 Oct '21

10 Oct '21

This is an off-shoot thought of the 32-bit ARM conversation. Right now, we build stuff like libreoffice for i686, but then (mostly) don't ship it. This seems like a waste of resources and time. I know it's somewhat complicated (for example, there's actually a library package in libreoffice, libreofficekit, so that gets plucked in to multilib), and there's quite a lot to work out, but ... does this seem like a good intended direction? One immediate way to do this is to start adding `ExcludeArch: i686` to "leaf" packages (I mean: to allow / encourage people to do that). But I don't want to add _more_ cruft to the standard minimal spec file, so this seems like the wrong direction. And I still think we want to keep multilib for compatibility (hello, old games!). Could we do something clever in koji instead? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

20 31

co/lead-maintainer sought: python-mailmerge (python)
by Brian (bex) Exelbierd 06 Oct '21

06 Oct '21

Hi, I added python-mailmerge to Fedora Linux as it was super important to large parts of my work as FCAIC. In my current $dayjob I use it less frequently, though I know of colleagues who still depend on it. I'd love to find a maintainer to help me with it. There is a new release pending, which I suspect will just be "build the rpm with new code; test it; ship it" level effort. I am happy to hand the whole thing off to someone or to work with you. Thank you. regards, bex -- Did this email arrive after work for you? Stop reading it and enjoy some work/life balance. Brian "bex" Exelbierd (he/him/his) Community Business Owner, RHEL Product Management @bexelbie | http://www.winglemeyer.org bexelbie(a)redhat.com

5 9

F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)
by Ben Cotton 04 Oct '21

04 Oct '21

https://fedoraproject.org/wiki/Changes/WirePlumber == Summary == PipeWire currently uses a simple example session manager. This proposal is to move to the more powerful WirePlumber session manager. == Owner == * Name: [[User:Wtaymans| Wim Taymans]] * Email: wim.taymans(a)gmail.com == Detailed Description == PipeWire requires a session manager that at least needs to implements the following features: * create and configure detected devices in the system. This includes audio cards, video and bluetooth devices. * configure applications and route audio/video to/from them to the devices and filters. * keep track of prefered devices and volumes. * move audio/video streams when devices appear and disappear. PipeWire uses a simple example session manager with limited features and configuration options. The proposal is to move to WirePlumber. WirePlumber is built on GNOME (GObject) technologies and has bindings for most languages using GObject introspection. WirePlumber allows one to implement many of the rules for setup and configuration using small LUA scripts, which are easier to maintain and customize. These are some of the functions that are scriptable in LUA: * setup and configuration of the devices and streams. This includes deciding if devices and streams need to operate in 5.1 or stereo mode, depending on the available devices. * routing of the streams based on metadata of the streams (Roles) and overall state of the system. * volume/mute restore of devices and streams == Benefit to Fedora == PipeWire currently uses a simple example session manager with mostly hardcoded logic and rules. This proposal wants to replace the session manager with a more advanced session manager, called WirePlumber. WirePlumber brings to following improvements * Drop-in replacement session manager for PipeWire, implements the exact same features as the example session manager * built with GObject, which provides a richer development experience and adds bindings for most languages * extensible with loadable modules * scriptable policy using small lua scripts * better integration with desktop settings The main benefits will be that this session manager would allow for more customization of the policy and rules. Initially we aim for feature parity with the current solution and work on more features in the next releases. == Scope == * Proposal owners: This is a rather isolated changed. Instead of starting the pipewire-media-session executable we would need to package and start WirePlumber instead. WirePlumber has been kept up to data with the features in the example session manager and would need testing. * Other developers: None. This is an isolated PipeWire change. * Release engineering: A new systemd service will need to be activated in the default install. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == Should not cause any change. == How To Test == Experience should be the same as before. Retest all audio testcases. == User Experience == Should not cause any visible change. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?): If the feature can not be completed we continue using the existing pipewire-media-session. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == [WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

14 16

co/lead-maintainer sought: gocryptfs+dependencies (go-lang)
by Brian (bex) Exelbierd 03 Oct '21

03 Oct '21

Hi, While I still actively use gocryptfs, I am busy enough with my $dayjob that I know I am not able to put enough time into maintaining it. Right now this has been OK as they have stopped new releases while they get v2.0 out the door. However, that will ship soon. I'd love to get some help maintaining the main rpm and the 6 dependencies I have for it. I am happy to hand it all over to you or to work with you. Thank you. regards, bex -- Did this email arrive after work for you? Stop reading it and enjoy some work/life balance. Brian "bex" Exelbierd (he/him/his) Community Business Owner, RHEL Product Management @bexelbie | http://www.winglemeyer.org bexelbie(a)redhat.com

1 1

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 August 2021