devel June 2021

devel@lists.stg.fedoraproject.org

214 participants
345 discussions

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

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

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

Orphaning the cura-lulzbot package set
by Tom Callaway 02 Oct '21

02 Oct '21

This fork of cura has basically been abandoned by upstream, and the new company that acquired Lulzbot has gone out of compliance with the source code for the firmware. They have made it very clear that they have no real interest in working with the community to improve this situation, and I no longer have any motivation to maintain these packages. Accordingly, I've orphaned the following packages: * cura-lulzbot * lulzbot-marlin-firmware * CuraEngine-lulzbot * python-uranium-lulzbot ~spot P.S. I opened an upstream pull request to add support for the Lulzbot TAZ Pro and the Mini 2 in the main Cura codebase (still actively maintained). I would highly recommend that anyone considering reviving these packages devote their efforts in that direction instead.

3 2

Fedora 35 Change: Add Fedora Kinoite as a variant (Self-Contained Change proposal)
by Ben Cotton 29 Sep '21

29 Sep '21

https://fedoraproject.org/wiki/Changes/Fedora_Kinoite == Summary == Introduce Fedora Kinoite as a variant of Fedora alongside Fedora Silverblue. == Owner == * Name: [[User:siosm| Timothée Ravier]] (travier AT redhat DOT com) * FESCo shepherd: [[User:Ngompa| Neal Gompa]] (ngompa13 A gmail D com) * SIG: [[SIGs/KDE|KDE SIG]] == Detailed Description == Fedora Kinoite is an immutable desktop operating system featuring the KDE Plasma desktop. It is based on the same technologies as Fedora Silverblue (rpm-ostree, Flatpak, podman). Fedora Kinoite is to the Fedora KDE Spin what Fedora Silverblue is to Fedora Workstation. We chose the Kinoite name for the following reasons: * KDE based projects traditionally start with a 'K' * Kinoite is a blue mineral (https://en.wikipedia.org/wiki/Kinoite) thus referring to both the 'silver' and 'blue' part of Silverblue and the blue color of the KDE logo. * "Kinoite" means "There is a tree" in Japanese (https://translate.google.com/?sl=auto&tl=en&text=kinoite&op=translate) thus referring to the 'tree' in 'ostree'. == Benefit to Fedora == This will make Fedora more attractive to users that are interested in immutable OSes and underlying technologies but would prefer to use the KDE desktop environment. This should also strengthen Silverblue as more effort may be put into fixing the issues in the shared technologies. == Scope == * Proposal owners: ** The KDE SIG will submit the [https://pagure.io/pungi-fedora Pungi changes] needed to add this new variant to the compose. ** The KDE SIG will submit the changes to add a new sub-package to [https://src.fedoraproject.org/rpms/fedora-release fedora-release]. ** The KDE SIG will maintain the Kinoite specific rpm-ostree config in the [https://pagure.io/workstation-ostree-config workstation-ostree-config repo]. * Other developers: N/A (not a System Wide Change) * Release engineering: Submitted as [https://pagure.io/releng/issue/9952 #9952]. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: The "Fedora Kinoite" trademark has been [https://pagure.io/Fedora-Council/tickets/issue/344 approved] * Alignment with Objectives: N/A == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == This edition has been built and made available as an unofficial preview and can be tested with the instructions from this [https://fedoramagazine.org/discover-fedora-kinoite/ Fedora Magazine article]. == User Experience == Current limitations (last updated 2021-01-18): * No rpm-ostree support in Discover (graphical package and update manager). A Season of KDE is in progress to work on that. * Partial Flatpak support in Discover. * [https://pagure.io/fedora-kde/SIG/issue/13 KDE applications are not yet available as Flatpak from the Fedora registry]. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == Report to the next release. * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? N/A == Documentation == A lot of the known issues impacting Fedora Kinoite are shared with Silverblue and their resolution is the same: https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/. It is not clear for now if Kinoite specific documentation is needed but a landing page with pointer to known issues might be good. == Release Notes == Fedora Kinoite has been introduced as a new variant of Fedora Linux featuring the KDE desktop environment and the same technologies as Silverblue (rpm-ostree, Flatpak, podman). -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

2 1

Fedora 33 network configuration (ifcfg*) migration guide available?
by Peter Boy 27 Sep '21

27 Sep '21

With Fedora 33 network configuration is by default persisted in /etc/NetworkManager/system-connections/*.nmconnection files. The old /etc/sysconfig/network-scripts/ifcfg* files are „legacy“. They are still being processed for the time being, but obviously it is time to migrate. (cf https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_if…) Is there a kind of „mapping“ ifcfg-* —> *-nmconnection. ? Most items are simple to migrate, but servers in particular sometimes have unusual configurations, e.g. - for p2p Connections: SCOPE="peer xxx.yyy.zzz.aaa" - and corresponding a lot of (ADDRESSx / NETMASKx / GATEWAYx ) entries in route-{ifname} file How do I handle that kind of config items in *.nmconnection ? The "search engine I trust" couldn't answer that for me (or I couldn’t ask the right question). Thanks Peter

7 9

libvirt and systemd-resolved integration?
by Juan Orti Alcaine 19 Sep '21

19 Sep '21

Hello, In the network bridges that libvirt creates there's a dnsmasq daemon to resolve the VM's IPs. Is there any way to signal systemd-resolved from libvirt to say that in the bridge interface there is a DNS server and a domain? Thank you.

7 13

Re-Launching the Java SIG
by Fabio Valentini 15 Sep '21

15 Sep '21

This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now. What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here: - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied by an old, unused bot account) - new private mailing list: java-maint-sig (for RHBZ bugs - so, possibly, also CVEs - hence, private) - tracking project on pagure: https://pagure.io/java-maint-sig (for maintenance scripts, tracking tickets, awesome package dashboards, etc.) There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net) which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file. Major upcoming projects for the "new" Java Package Maintainers group include: - managing OpenJDK 11 / Java 11 transition for hundreds of Java packages in fedora 33 - starting to transition well-maintained Java packages from the Stewardship SIG back into Java SIG - possibly porting packages from gradle to maven to fix build issues and broken dependencies - transitioning from old java.net / JavaEE projects to the new ones now under the eclipse-ee4j umbrella I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well. So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list. Let's make this happen. Fabio

36 90

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