devel August 2020

devel@lists.fedoraproject.org

217 participants
358 discussions

Remove old GPG keys?
by Miroslav Suchý 04 May '21

04 May '21

I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remov… with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from… And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? Mirek

15 29

Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok 28 Mar '21

28 Mar '21

Recently I've reported some Big Endian related test failures to an upstream project [0]. I was asked by an upstream project maintainer, whether I know some free Continuous Integration services where they can easily run their testsuite on Big Endian. Any tips? * Upstream uses Travis CI to test on x86_64 Linux (Ubuntu) * Upstream uses AppVeyor to test on Microsoft Windows * It's a pure Python project, noarch, but some changes need to be done when loading/saving binary data (LE) with NumPy on BE system. What I've considered: * COPR (but there is no big endian arch) * (Ab)using Koji (I guess that would be considered a bad practice?) * using QUEMU on Travis CI [1] Any better tips? Thanks [0] https://github.com/mikedh/trimesh/issues/249 [1] https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

8 10

git push permission denied
by Neal Becker 10 Feb '21

10 Feb '21

I just had to setup a new machine, and new ssh keys. I visited https://admin.fedoraproject.org/accounts/user/edit/xxxx I chose my new id_rsa.pub to upload. But I get: git push --verbose Pushing to ssh://nbecker@pkgs.fedoraproject.org/mercurial Permission denied (publickey). fatal: The remote end hung up unexpectedly Hints?

4 5

Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3
by Stephen Gallagher 29 Jan '21

29 Jan '21

I sent out the V2 version of the Change on Friday and then promptly managed to injure myself and be away from email until today. I've read through the email threads again this morning and I decided that, rather than try to address them one by one, I'd try again with a V3 that hopefully answers some of the repeated questions and concerns on that list. Please see the newly-updated https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose for more details[1]. [1] https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Com…

19 62

Server Side Public License (SSPL) v1
by Tom Callaway 21 Jan '21

21 Jan '21

After review, Fedora has determined that the Server Side Public License v1 (SSPL) is not a Free Software License. It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk. It is also worth nothing that while there is a draft for a "v2" of the SSPL: A) It is not final. B) It is not in use anywhere at this time (as far as we know). C) The intent of the v2 draft text is not changed from the v1 license currently in use. We have updated our "Bad License" list to include SSPLv1. No software under that license may be included in Fedora (including EPEL and COPRs). Thanks, Tom Callaway Fedora Legal

4 6

Re: NeuroFedora review swaps
by Ankur Sinha 12 Jan '21

12 Jan '21

On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote: > > > I'd like to get this package reviewed please: > > > > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913# > > > > Would anyone like to swap reviews? > > I would review it for wdune sponsoring. Sorry---I'm not current with the wdune scenario. I assumed you meant that you'd review it unofficially as part of the work to get sponsored to the packagers group: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group… I'm not a sponsor yet so I cannot sponsor you to the group myself, but once you've done a few reviews, a sponsor will be happy to take a look at them and guide you through the sponsorship process. If you've submitted a review ticket for wdune already, I will be happy to review it and provide comments. -- Thanks, Regards, Ankur Sinha https://ankursinha.in Time zone: Europe/London

6 27

%lua_requires behaves differently in F33+
by Michel Alexandre Salim 08 Dec '20

08 Dec '20

Hi, Björn added some useful Lua packaging macros in https://bugzilla.redhat.com/show_bug.cgi?id=1447324 One of them, %lua_requires, adds a dependency on either `lua(abi) = %{lua_version}` or, on EL6 and below, on lua >= current version and lua < next version. Somehow this seems to be automatically applied on Fedora 33 and above -- without adding any manual require on lua(abi) e.g. lua-lunitx on Fedora 33 https://bodhi.fedoraproject.org/updates/FEDORA-2020-7c23dc64c0 on Fedora 32, though, the macro is not automatically invoked (so the update below is bad and I need to redo it) https://bodhi.fedoraproject.org/updates/FEDORA-2020-9074133de4 In fact, trying to use %lua_requires does not seem to work, with and without curly braces: error: line 15: Unknown tag: %lua_requires error: line 15: Unknown tag: %{lua_requires} Could someone help explain these two behaviors? I'm working on resuming the Lua packaging draft so I want to have a canonical example on how the macros are supposed to be used. PS Björn -- we should consider moving the macros out of lua-devel and into lua-rpm-macros, that lua-devel then depends on. That will fix the inability to get these macros out to EPEL6 and EPEL7 - on those, lua packages can just BR the macro package directly. -- Michel Alexandre Salim profile: https://keyoxide.org/michel@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

3 10

Disabling Fedora 30 chroots in Copr
by Jakub Kadlcik 23 Nov '20

23 Nov '20

Hello, we have just disabled Fedora 30 chroots in Copr. According to the Fedora wiki [1], Fedora 30 reached the end of its life on 2020-05-26 and therefore we are disabling it in Copr. That effectively means that from this moment, it is no longer possible to submit builds for the following chroots: - fedora-30-x86_64 - fedora-30-i386 - fedora-30-ppc64le - fedora-30-aarch64 - fedora-30-armhfp [1] https://fedoraproject.org/wiki/End_of_life Jakub

4 12

Fedora 33 blocker status
by Ben Cotton 16 Oct '20

16 Oct '20

We've branched, so let's start the weekly blocker status email yayyyyy Action summary ==================== Accepted blockers ----------------- 1. libreport — abrt-server errors when processing zstd compressed core dumps produced by systemd-246~rc1-1.fc33 — POST ACTION: abrt maintainers to make a new release containing the fix 2. resteasy — FreeIPA deployment fails in current Rawhide due to various issues with Java 11 — NEW ACTION: resteasy maintainers to diagnose issue and fix or pass the buck as appropriate 3. sddm — login stuck when changing users repeatedly (log out, log in a different one) — NEW ACTION: sddm maintainers to diagnose issue and fix or pass the buck as appropriate 4. selinux-policy — SELinux is preventing systemd-machine from 'create' accesses on the sock_file io.systemd.Machine. — POST ACTION: selinux-policy maintainers to make a new release containing the fixes 5. tomcat — FreeIPA server deployment fails in Fedora-Rawhide-20200714.n.0 — MODIFIED ACTION: tomcat maintainers to investigate failed upgrade test Proposed blockers ----------------- 1. gnome-shell — Network manager started stuck when I tries connecting to VPN (openconnect) after upgrade gnome-shell to 3.37.1-1.fc33 version — NEW ACTION: gnome-shell maintainers to diagnose issue 2. systemd — systemd-resolved.service not work with DNS server placed behind VPN (openconnect) — NEW ACTION: systemd maintainers to diagnose issue 3. udisks2 — zram-setup(a)zram0.service: Failed to load configuration: No such file or directory — NEW ACTION: Someone! to figure out why udisks2-zram gets pulled in Bug-by-bug detail ============= Accepted blockers ----------------- 1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST abrt-server errors when processing zstd compressed core dumps produced by systemd-246~rc1-1.fc33 abrt doesn't support core dumps compressed with zstd, which is now used by systemd. Merged upstream PR uses libarchive to add support for zstd (and other compression formats): https://github.com/abrt/libreport/pull/656. 2. resteasy — https://bugzilla.redhat.com/show_bug.cgi?id=1866570 — NEW FreeIPA deployment fails in current Rawhide due to various issues with Java 11 Deploying FreeIPA fails with a traceback in pki-tomcat. This appears to be a dependency chain issue that (currently) ends at resteasy via dogtag-pki. This may not be the last layer in the Java 11 onion. 3. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1861700 — NEW login stuck when changing users repeatedly (log out, log in a different one) This is now a blocker based on a recent approval-in-principle of a release criterion related to logout and user switching. User processes linger after logout which blocks logging in when another user has logged in between the two sessions. Or when the second user logs back in. Or when a single user logs in repeatedly. Using KillUserProcesses=Yes helps the first problem, but raises on of its own. It appears to be a race condition of some kind as the behavior is not fully consistent. 4. selinux-policy — https://bugzilla.redhat.com/show_bug.cgi?id=1862686 — POST SELinux is preventing systemd-machine from 'create' accesses on the sock_file io.systemd.Machine. librvirt VMs and systemd-machined service fail with AVC denials. Merged upstream PRs should fix the denials mentioned in this bug: https://github.com/fedora-selinux/selinux-policy/pull/405 and https://github.com/fedora-selinux/selinux-policy/pull/407 5. tomcat — https://bugzilla.redhat.com/show_bug.cgi?id=1857043 — MODIFIED FreeIPA server deployment fails in Fedora-Rawhide-20200714.n.0 due to pki-tomcat failing to run with "java.lang.ClassNotFoundException: org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource" An upstream commit resulted in tomcat-coyote.jar missing packages. A previous fix (FEDORA-2020-f897a68801) moved the goalposts. tomcat-9.0.37-3 should fix this. Verification is blocked on BZ1866570, but Adam's most recent upgrade test still fails with a ClassNotFoundException for com.sun.xml.internal.bind.v2.ContextFactory. Proposed blockers ----------------- 1. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=1830343 — NEW Network manager started stuck when I tries connecting to VPN (openconnect) after upgrade gnome-shell to 3.37.1-1.fc33 version Connecting to an OpenConnect VPN using 2FA hangs after the second factor is entered. The journal contains an array.toString() message which may or may not be a red herring (it looks like a deprecation warning). 2. systemd — https://bugzilla.redhat.com/show_bug.cgi?id=1863041 — NEW systemd-resolved.service not work with DNS server placed behind VPN (openconnect) When connected to an OpenConnect VPN, host name resolution fails. Manually disabling the systemd-resolved service works around this issue. 3. udisks2 — https://bugzilla.redhat.com/show_bug.cgi?id=1861463 — NEW zram-setup(a)zram0.service: Failed to load configuration: No such file or directory Installation on armhfp and aarch64 single-board computers fails with zram-setup errors. It appears to be a conflict betwen udisks2-zram and zram-generator-defaults. Update FEDORA-2020-e143a283fb renamse the service unit file to make its origin more obvious. Removing udisks2-zram fixes the issue, but it's pulled in as a dependency of something, so that needs to be identified. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

12 24

Reproducible builds/bootstrap
by Pablo Greco 09 Oct '20

09 Oct '20

I'm starting to work on a project to make Fedora fully reproducible and bootstrappable from scratch. I know it is a long term plan and still working on the steps, but it would be good to know the current status, if there is an internal interest in this, if someone is already working (or planning to). Thanks for the info. Pablo

8 11

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 2020