Re: Koschei builds fail with "error: %patchN is obsolete", but no %patchN in the spec file
Thank you Dominik, I hadn't noticed the commit message, I was looking at everything else. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Koschei builds fail with "error: %patchN is obsolete", but no %patchN in the spec file
Hello, I found a moment to catch up on my package maintainer tasks and I noticed that for the past 15 days fityk's rawhide builds started by Koschei have been failing[1]. There are no build logs and the only error I can spot in the root.log is this: DEBUG util.py:461: error: %patchN is obsolete, use %patch N (or %patch -P N): %patch0 -p0 The odd thing here is that the spec file has %patch -P0 -p0 I also did a scratch build[2] and it completed without any errors. Is there something I need to do? Best regards, A. 1. https://koschei.fedoraproject.org/package/fityk?collection=f41 2. https://koji.fedoraproject.org/koji/taskinfo?taskID=119026186 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Elections - Voting is now open!
Thanks for the swift response, I noticed the range values have been corrected as well. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Elections - Voting is now open!
Hello, On Mon, May 20, 2024 at 1:06 AM Aoife Moloney wrote: > […] > and dont forget to claim your Fedora badge too! That last bit doesn't seem to be working. Was the "Claim your I Voted badge." link always pointing to the URL of the corresponding badge without any other parameter? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: PWG+OpenPrinting meetup 2024
Hello Zdenek, All this seems very interesting, thank you for the update! Best regards, A. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - L'Aigle meteorite edition
On Thu, May 2, 2024 at 8:11 PM Matthew Miller wrote: > > If we extrapolate linearly just from 2023-09-29 on, that gives an end-date > of 2026-02-22. And linearly is probably optimistic too, given the classic > "last 10% is 90% of the time" thing. That sounds reasonable, but we'll also be enjoying the "SPDX statistics - X edition" tidbits for quite some time! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Package GNU Hello build errors
Hello Patrick, What was the command you issued? Were there any errors before the excerpt you've posted? Does your user belong to the 'mock' group? Best regards, A. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: intent to hand over or orphan several scientific packages and their build requirements
Hello Dominik, Thank you again. On Fri, Jan 5, 2024 at 10:45 AM Dominik 'Rathann' Mierzejewski wrote: > > On Thursday, 28 December 2023 at 10:27, Alexander Ploumistos wrote: > > Done. I put @scitech_sig as the default bugzilla assignee for EPEL. > Can you change the default assignee for Fedora to yourself? It looks > like it didn't get reset after transferring the project to you. Done. I've left a word for Antonio, in case he wants to maintain the EPEL branches. > > On Wed, Dec 27, 2023 at 11:26 PM Dominik 'Rathann' Mierzejewski > > wrote: > > > > > > chemtool > > > xdrawchem > > I gave you chemtool by mistake, feel free to give it back or orphan it. I can't bring myself to hit the "Orphan" button, all those memories (often of frustration)… Best regards, A. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning gnome-chemistry-utils, bodr and chemical-mime-data and stepping down as goffice and gnumeric co-maintainer
Hi Julian, Thank you for the work you've put into this over the years. I have taken gnome-chemistry-utils, bodr and chemical-mime-data. I am using the calculator almost daily and sometimes the spectrum and structure viewers. Antonio, will you be able to lend a hand if need be? Happy new year everybody, A. On Thu, Dec 28, 2023 at 1:46 PM Julian Sikorski wrote: > > Hi list, > > as I have not used gnome-chemistry-utils myself in years, I have decided > to finally orphan it. While upstream is dead since the lead developer > has retired from professional life, the package has been relatively easy > to keep running. The only issue is the versioned gnumeric plugin, > meaning a rebuild every gnumeric update. > I am also going to orphan the dependencies and step down as gnumeric and > goffice co-maintainer. > > Best regards, > Julian > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: intent to hand over or orphan several scientific packages and their build requirements
Hello Dominik, For the time being I will take inchi, if nobody else wants it. I haven't used EPEL in a very long time, so I'm only interested in the Fedora branches. On Wed, Dec 27, 2023 at 11:26 PM Dominik 'Rathann' Mierzejewski wrote: > > chemtool > xdrawchem Having used these two for almost two decades I'd hate to see them go, but I think we have a more capable (and maintained) replacement in molsketch. Most of the other packages on the list are installed on my systems, but I can't say I've actually used them in quite some time. Still, it would be a huge loss for Fedora's scientific capabilities to have them disappear. In any case, thank you for all your efforts so far. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How can I delete a rawhide Bodhi update?
On Thu, Nov 23, 2023 at 4:40 PM Florian Weimer wrote: > > I've got an update that I don't see pushed to stable. How do I make > sure that doesn't happen? > > As it's for rawhide, I didn't create the Bodhi update, and I don't see > an option to delete it. If it's still pending, do you have the option to unpush it? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is package (gnome-shell extension) split into legacy and current required?
Hi Kevin, On Mon, Oct 16, 2023 at 7:51 PM Kevin Fenzi wrote: > > On Mon, Oct 16, 2023 at 12:02:05PM +0200, Alexander Ploumistos wrote: > > Hello, > > > > I maintain the gnome-shell extension for bubblemail. I was informed by > > the upstream developer that in order to support GNOME ≥ 45, he is > > rewriting most of the code. What is currently the master branch will > > support (recent) GNOME versions up to 44.x and there will be another > > branch for 45 and newer. > > I assume you mean you maintain the Fedora package? Or are you maintainer > of the extension and asking what you should do upstream? Sorry I wasn't clear, I am the package maintainer. Upstream is extremely cooperative, if something would cause trouble downstream, they'd be willing to accommodate us. > > Do I need to create something like a compat package or can I just > > switch to the new source/branch from F39 onward? I suppose that a > > bugfix for F37 and F38 down the road is not out of the question, so > > there will be two different upstream branches for different Fedora > > versions. > > You should target the gnome version in each release, no need for compat > packages. That assumes versions on the package(s) are such that users > can upgrade going from one release to the next. Yes, that will be the case. Upstream uses semantic versioning (well, most of the time) and the upgrade path will be straightforward since each branch will be on a different major number. Thanks for clearing that up. Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Is package (gnome-shell extension) split into legacy and current required?
Hello, I maintain the gnome-shell extension for bubblemail. I was informed by the upstream developer that in order to support GNOME ≥ 45, he is rewriting most of the code. What is currently the master branch will support (recent) GNOME versions up to 44.x and there will be another branch for 45 and newer. Do I need to create something like a compat package or can I just switch to the new source/branch from F39 onward? I suppose that a bugfix for F37 and F38 down the road is not out of the question, so there will be two different upstream branches for different Fedora versions. Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging guidelines - validation of AppStream metadata files
On Mon, Sep 25, 2023 at 7:33 PM Artur Frenszek-Iwicki wrote: > > Without docs, the whole process is a black box. +1 That was actually one of the two reasons I started this thread. For instance, is this the package that must be rebuilt in order to see an AppStream metadata file appear/refreshed in GNOME Software? https://src.fedoraproject.org/rpms/appstream-data Could we get an explainer (for dummies) of how the entire pipeline works? The other reason was someone from Debian telling one of my upstreams "Don't use appstream-util to validate the file, it's deprecated, use appstreamcli". Frankly, that struck a chord, considering x years ago I had spent a considerable amount of time convincing dozens of projects to adopt "AppData" (at the time), filing tickets and submitting PRs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging guidelines - validation of AppStream metadata files
The current state of things, Fedora-wise, is summarized in FPC ticket #1053: https://pagure.io/packaging-committee/issue/1053 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Packaging guidelines - validation of AppStream metadata files
Hello, According to our packaging guidelines[1], "you MUST run appstream-util validate-relax (in %check or %install) and have BuildRequires: libappstream-glib, to help ensure the validity and safety of the appdata files you’re installing". For quite some time now, I've been seeing references to another tool, appstreamcli (provided by the appstream[2] package), being used instead of appstream-util. Debian guidelines recommend it[3], it's documented upstream[4] and apparently there are a few fedora packages that use it already[5] (google found 10, I know of a couple more). By the way, if you take a closer look, some of these packages appear to use the "--nonet" flag from appstream-util instead of "--no-net", which is used by appstreamcli. Furthermore, on the web page of AppStream-Glib there's a warning that it is in heavy maintenance mode and to use appstream instead[6]. By all indications, appstream will replace appstream-glib and in the case of the corresponding validator utilities, this has already begun. However, at least on this list, I was unable to find any clue that this was happening and there are zero mentions of appstreamcli on docs.fedoraproject org, hence this message. Could someone involved with AppStream please provide some information? Shouldn't our documentation be changed to reflect these changes? Does the FPC need to decide on this? Best regards, Alexander 1. https://docs.fedoraproject.org/en-US/packaging-guidelines/AppData/ 2. https://github.com/ximion/appstream 3. https://wiki.debian.org/AppStream/Guidelines 4. https://www.freedesktop.org/software/appstream/docs/api/re32.html 5. https://www.google.com/search?q=%22appstreamcli+validate%22+site%3Asrc.fedoraproject.org%2Frpms%2F 6. https://github.com/hughsie/appstream-glib ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
gucharmap license corrected
Hello, I have just corrected gucharmap's license from: GPL-3.0-or-later AND GFDL-1.3-or-later AND Unicode-DFS-2015 to: GPL-3.0-or-later AND GFDL-1.3-or-later AND Unicode-DFS-2016 The change happened upstream six months ago, but I hadn't spotted it at the time. Best regards, Alexander ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: KDE and GNOME Join Hands To Add Payments To Turn Flathub Into a Store for the Linux Desktop
On Tue, Sep 5, 2023 at 1:09 PM Liam Proven wrote: > > On Tue, 5 Sept 2023 at 11:51, Richard W.M. Jones wrote: > > > > (Everyone, it's best to not feed the troll) > > Since you don't quote any part of any message, we have no idea who you > consider to be a troll and so who we are not supposed to feed. That would be the OP. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Missing boot options - who is to blame?
On Fri, Aug 25, 2023 at 7:27 PM Hans de Goede wrote: > > If there is a /etc/kernel/cmdline file then that will be used > for the generated /boot/loader/entries/*.conf files. > > (I was recently bitten by this myself) Yes, there is and its contents are those of the problematic /boot/loader/entries/*.conf files. Should I delete it? # rpm -qf /etc/kernel/cmdline file /etc/kernel/cmdline is not owned by any package Where does it come from? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Missing boot options - who is to blame?
Hello, On one of my computers, for the last couple of kernel updates I'm not getting the proper options in the corresponding *.conf files in /boot/loader/entries. Some of the options specified in /etc/default/grub are there, but anything related to the root partition and some other options are consistently being left out, which results in a machine unable to boot, until I manually add the uuids and everything else that's missing. In the past I knew that grubby took care of these things, but some rather recent threads here have suggested this is no longer the case. Against which component should I file a bug report? It's an F38, Workstation edition. Thank you, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 39 Mass Rebuild
On Mon, Jul 24, 2023 at 10:45 PM Kevin Fenzi wrote: > […] > > Although it would be nice to figure out why it didn't get a > commit/build. A new version was released yesterday, but Anitya's scratch build never happened: https://bugzilla.redhat.com/show_bug.cgi?id=2227374 The task does not exist in koji. Could this be related? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
On Wed, Jul 26, 2023 at 12:14 PM Vitaly Zaitsev via devel wrote: > > On 26/07/2023 11:04, Dominik 'Rathann' Mierzejewski wrote: > > You could, for example, buy a supported Logitech > > Receiver > > I don't recommend anyone to buy this proprietary hardware: > > > The vulnerabilities allow attackers to sniff on keyboard traffic, but also > > inject keystrokes (even into dongles not connected to a wireless keyboard) > > and take over the computer to which a dongle has been connected. > https://www.zdnet.com/article/logitech-wireless-usb-dongles-vulnerable-to-new-hijacking-flaws/ And thanks to fwupd and Logitech's embracing it, we had the fix in a very short time. What Dominik wrote would apply e.g. for an NVMe replacement drive from Kingston or Samsung (proprietary hardware too, it's a shocker). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
On Wed, Jul 26, 2023 at 10:59 AM Vitaly Zaitsev via devel wrote: > > Only Dell, HP and Lenovo laptops are fully supported: > https://fwupd.org/lvfs/devices/ Not just laptops, desktops/workstations too. In the last six years, I've had five different models provided by my employers and they were all fully supported through fwupd. > fwupd is a great tool on laptops but completely useless on desktops > since no motherboard vendors support it. While most custom-built computers don't get full UEFI/BIOS updates, some hardware manufacturers provide firmware files for components used by other vendors in their boards. It's a far cry from being on par with windows, but calling it completely useless is not true either. > Maybe fwupd should start packaging UEFI BIOS images for desktop > motherboards without vendor assistance? Images in BIN format can be > easily downloaded from official websites or extracted from MS Windows > packages. That would require people volunteering to potentially brick their machines in order to test the updates. If something goes wrong, the equipment (and the knowledge) necessary to reprogram a chip is rather scarce. I'm afraid the way forward is to _convince_ vendors to make use of the service, starting with those who already have test accounts. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 39 Mass Rebuild
On Mon, Jul 24, 2023 at 10:45 PM Kevin Fenzi wrote: > > Please do bump and rebuild it. It's done: https://koji.fedoraproject.org/koji/taskinfo?taskID=103849749 > Although it would be nice to figure out why it didn't get a > commit/build. Indeed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 39 Mass Rebuild
Hello, On Mon, Jul 24, 2023 at 9:31 PM Samyak Jain wrote: > > The mass rebuild was done in a side tag (f39-rebuild) and moved over to > f39. So it's over? > Things still needing rebuilding > https://kojipkgs.fedoraproject.org/mass-rebuild/f39-need-rebuild.html Is it up to the packagers to rebuild these? I have a package on this list, but there is no commit in dist-git concerning the F39 Mass Rebuild. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
Hello, On Mon, Jul 17, 2023 at 8:49 PM Miro Hrončok wrote: > > switcheroo-controlorphan 2 weeks ago Has anyone from the Workstation WG noticed this? Won't losing switcheroo-control be a considerable usability regression? At the same time, the upstream developer is/was Bastien, which complicates things. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning packages (was LibreOffice packages)
On Sat, Jul 1, 2023 at 1:00 AM Kevin Kofler via devel wrote: > > What corporate desktop customers do not use LibreOffice? I know two big-name scientific instrument manufacturers that offer RHEL workstations on which to run the control software. I suspect there are other domains with similar use cases, i.e. dedicated computers that only run a certain piece of software or software suite. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %find_lang does not find locale files
On Wed, May 24, 2023 at 5:11 AM Parag Nemade wrote: > > Hi, > > > On Tue, May 23, 2023 at 11:58 PM Alexander Ploumistos > wrote: >> >> Hello, >> >> I know this has been asked before, more recently four years ago in >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OQDWCHFDTBKCPHWF2VLPUF74WC76TCNY/#6VUBRYAAZMX6SOREM7ZENDV44MIPE7WH >> >> I'm not sure what the "right" way of dealing with this is, so I would >> really appreciate any advice. >> >> I've recently packaged input-remapper[1] and during the review[2], >> Zbigniew pointed out that I had forgotten to use the %find_lang macro >> for the localization files. >> >> The translations are placed in /usr/share/input-remapper/lang/ and >> apparently, %find_lang does not want to find them there. Is there a >> standard location that works across linux distributions? I guess that >> if the answer is yes, I should get upstream to move their files there. >> If not, is there something else to be done? >> >> >> 1. https://github.com/sezanzeb/input-remapper/ >> 2. https://bugzilla.redhat.com/show_bug.cgi?id=2180418 >> ___ > > > I did a quick search and found this discussion > https://pagure.io/packaging-committee/issue/1058#comment-775111 > Maybe this will not help you but will give some insights. Thank you Parag, that was indeed enlightening. @churchyard: Miro, is it possible to tell %pyproject_save_files about the locale directory or should I resort to one of the workarounds mentioned in the ticket? Does the %lang tag serve any purpose when there aren't separate language-specific packages? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
%find_lang does not find locale files
Hello, I know this has been asked before, more recently four years ago in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OQDWCHFDTBKCPHWF2VLPUF74WC76TCNY/#6VUBRYAAZMX6SOREM7ZENDV44MIPE7WH I'm not sure what the "right" way of dealing with this is, so I would really appreciate any advice. I've recently packaged input-remapper[1] and during the review[2], Zbigniew pointed out that I had forgotten to use the %find_lang macro for the localization files. The translations are placed in /usr/share/input-remapper/lang/ and apparently, %find_lang does not want to find them there. Is there a standard location that works across linux distributions? I guess that if the answer is yes, I should get upstream to move their files there. If not, is there something else to be done? 1. https://github.com/sezanzeb/input-remapper/ 2. https://bugzilla.redhat.com/show_bug.cgi?id=2180418 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: review swaps
Hi Zbigniew, On Sat, May 13, 2023 at 11:55 PM Zbigniew Jędrzejewski-Szmek wrote: > > I have a bunch of nice python packages looking for a reviewer: > > #2121902 pyinstrument - Python profiler with colorful output I've taken the profiler. Do you think you could take 2180418? I would really appreciate your input. pyinstrument seems simple enough, I think I might be able to take on another review if nobody else steps up. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Sytem Upgrade requirements for an F37 → F38 upgrade
On Sat, Apr 1, 2023 at 3:44 PM Alexander Ploumistos wrote: > > Something is glitching on my provider's side and it's impossible to > create new VMs. I've opened a ticket, but I doubt anyone is going to > deal with it before Monday. It has taken them over a month to (sort of) resolve the problem, but in any case, I was able to set up another VM to test. I can confirm that with the backported fix in 251.14-2.fc37, 2GB of RAM is more than enough to perform the upgrade. Sorry for the delay. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
Hello Matthew, everyone, The TL;DR version of my thoughts and suggestions on this topic: implement the improvements suggested so far as best as possible, so that the people who want to interact with Discourse through their mail reader can do so with little to no friction. Clearly define and document the new tags, what type of information should go where and who needs to subscribe to which tag. Redefine our information channels in a saner way, that reflects our consumption and use of that information. Document on the docs website how subscriptions, filtering etc. work in the Discourse UI for each use case. Avoid further community fragmentation by switching cold turkey once the organization of the site and the mailing features are on par with what people have come to expect from mailing lists. Turn on the requirement of adhesion to a fas group for people who can post on the new channels. Longer version: Like most of the people who have chimed in so far, I too have strong opinions and feelings about such a transition. I joined the mailing list almost a decade ago and I have been following it for much longer. I am subscribed to a number of lists, I set up my filters ages ago and over time, as the project and my involvement with it changed, I adapted those filters with minimal effort. I can certainly sympathize with all the people who are far more active than I am and who interact with Fedora first and foremost through these lists, even though I don't go so far as to run an NNTP server or type my replies in vi (admittedly, that was fun for a while). Since this transition is more or less a settled issue, as far as I can understand, I would like to make some suggestions as to how this could be as painless as possible for everyone. Before that though, I'd like to take a moment to point out something that has been very lightly touched upon, the nature of the medium (e-mail) and its non-technical aspects. I think most people are acquainted with the formalisms and the urgency/importance attributed to different means of communication. We don't feel the same way about a written letter we found in our mailbox, a phone call, an e-mail, an instant message, an SMS or a forum post. E-mail commands a certain "decorum" close to that of a written letter. Perhaps this is the reason why certain people find it daunting to engage with the project through the mailing lists. At the same time and while we're no strangers to heated exchanges and a far cry from literary correspondence, the etiquette dictated by the medium does create a safe space for its users. We all pretty much understand and adhere to the rules associated with this kind of written communication and have certain expectations when we use it and even more so given our relationship to Fedora. This is not the case with a forum and certainly not the case with all the people who will go on d.f.o. For this reason I strongly suggest that the "Project Discussion" category or whatever subcategory our particular subcommunity ends up on, is indeed walled off from the rest of the website. I do not need the noise, the rudeness and the abuse that I often found on ask.fedoraproject.org (which is now a part of d.f.o) to flood over these channels. The requirement on people belonging to a specific fas group before they can post should be on from day one and exceptions made only when they are warranted. On Thu, Apr 20, 2023 at 11:21 PM Matthew Miller wrote: > > We’re scattered in actual practice > -- This is not necessarily or always a bad thing, nor is it a problem that can be solved by the transition to Discourse. I thought I had a fairly good grasp of most of Fedora's activities and communities until I saw the organizational chart posted by Marie Nordin a while back and I realized that about a third of Fedora was terra incognita to me. Then again, we cannot all afford the time nor do we have the skills and proclivities required to be involved with everything. The devel ML has been a good "firehose" of information for people who work on packaging and development and everything tangentially tied to these. It's only natural that the stream of information will get fragmented down the road, but we've mostly had a "bird's eye view" of the issues of interest to us through this channel and we could (usually) follow up on whatever place a particular discussion unfolded, be it bugzilla, a pagure ticket or whatever. The "announce" ML could become an "announce" category for all things Fedora, which might be of interest to people from different subcommunities, while keeping it relatively low-traffic. E.g. voting for the default wallpaper for the next Fedora release is something that would fit that description, whereas a release party in Paraguay or the move to Python 3.12 would not. If the mailing lists and Discourse are being used simultaneously, we will end up even more scattered than we are now. If the concerns voiced so far can be addressed and
Re: fedora-review crash
On Sun, Apr 23, 2023 at 3:37 PM Sérgio Basto wrote: > > On Thu, 2023-03-23 at 01:38 +0200, Alexander Ploumistos wrote: > > On Wed, Mar 22, 2023 at 8:29 PM Sérgio Basto > > wrote: > > > > > > ah. I think this is one bug in Fedora review (already reported) > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1824526 > > > > Sorry, I want mention this bug report > https://bugzilla.redhat.com/show_bug.cgi?id=2132574 Thank you Sergio, this makes more sense. I've been meaning to ask, but I've been overwhelmed with work and it slipped my mind. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Change my new package name in src.fedoraporject.org ?
On Thu, Apr 13, 2023, 10:28 Miro Hrončok wrote: > On 13. 04. 23 10:18, Sébastien Le Roux wrote: > > Dear all, > > yesterday I created my first package repository: > > > > https://src.fedoraproject.org/rpms/Atomes > > > > I used the command (that you all must be familiar with): > > > > fedpkg request-repo Atomes 2130607 > > > > After a first try using "atomes" that did not work, indeed fedpkg > requested > > the keyword to be "Atomes" because of an information in the bug report. > > > > I could only certify afterwards that the repo was named "Atomes" and not > > "atomes" as I hoped. > > Can anyone help in renaming the project "atomes" instead of "Atomes" ? > > > > Thanks in advance for your help. > > RENAME the package review request bugzilla to "Review Request: atomes - An > atomistic tool box" and try `fedpkg request-repo atomes 2130607` again. > > If it works, retire the Atomes package with `fedpkg retire "Renamed to > atomes"`. > > In http://bugzilla.redhat.com/2130607 the reviewer should have noted this > and > not approve the package. > Sorry everyone for the formatting, I have to reply from my phone. I mistakenly thought that the name could be whatever upstream calls their package and for the rest, the spec file is what matters. My bad. That being said, now that the requirement on lower case names has been relaxed, I guess Sébastien can name the package with the same spelling he's using upstream, i.e. "Atomes". If indeed he prefers that, can he use the same branch that he's got now, rename his spec file to Atomes.spec and add an "Obsolètes: atomes" in it to take care of users who might have already installed it? I guess if he wants to strictly adhere to the rules, he'll have to jump through the renaming hoop. My sincere apologies for the blunder. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Sytem Upgrade requirements for an F37 → F38 upgrade
On Fri, Mar 31, 2023 at 7:25 PM Alexander Ploumistos wrote: > > On Fri, Mar 31, 2023 at 7:09 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > I will submit systemd-tests-251.14-2.fc37 with the patch. > > I doubt that it solves the issue completely, but it shouldn't make > > it worse, so let's at least do this for now. > > Thank you, I see it's still being built in koji. I will spin a VM with > the same configuration over the weekend and try the upgrade again. Something is glitching on my provider's side and it's impossible to create new VMs. I've opened a ticket, but I doubt anyone is going to deal with it before Monday. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Sytem Upgrade requirements for an F37 → F38 upgrade
On Fri, Mar 31, 2023 at 7:09 PM Zbigniew Jędrzejewski-Szmek wrote: > > I will submit systemd-tests-251.14-2.fc37 with the patch. > I doubt that it solves the issue completely, but it shouldn't make > it worse, so let's at least do this for now. Thank you, I see it's still being built in koji. I will spin a VM with the same configuration over the weekend and try the upgrade again. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Sytem Upgrade requirements for an F37 → F38 upgrade
On Thu, Mar 30, 2023 at 2:33 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Mar 30, 2023 at 02:25:33PM +0200, Alexander Ploumistos wrote: > > On Thu, Mar 30, 2023 at 2:10 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Thu, Mar 30, 2023 at 12:08:03AM +0200, Fabio Valentini wrote: > > > > On Mon, Mar 6, 2023 at 4:09 AM Alexander Ploumistos > > > > wrote: > > > > > > > > > > Hello, > > > > > > > > > > TL;DR: > > > > > DNF memory usage during upgrades from F37 to F38 on a couple of Fedora > > > > > Cloud images (with 2 GB of RAM each) led to oomd kicking in and > > > > > killing the upgrade process. It might be worth looking into before the > > > > > final (also beta?) release. > > > > > > Please try with systemd-253.2-1.fc38 / systemd-253.2-1.fc39. > > > > > > Hi Zbigniew, is F37 getting that version too or are you talking about > > a future F38 → F39 upgrade? > > That version — no. The patch for oomd config — yes (if it proves to be > beneficial in F38/rawhide). Could you please bump this thread when it's done? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Sytem Upgrade requirements for an F37 → F38 upgrade
On Thu, Mar 30, 2023 at 2:10 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Mar 30, 2023 at 12:08:03AM +0200, Fabio Valentini wrote: > > On Mon, Mar 6, 2023 at 4:09 AM Alexander Ploumistos > > wrote: > > > > > > Hello, > > > > > > TL;DR: > > > DNF memory usage during upgrades from F37 to F38 on a couple of Fedora > > > Cloud images (with 2 GB of RAM each) led to oomd kicking in and > > > killing the upgrade process. It might be worth looking into before the > > > final (also beta?) release. > > Please try with systemd-253.2-1.fc38 / systemd-253.2-1.fc39. Hi Zbigniew, is F37 getting that version too or are you talking about a future F38 → F39 upgrade? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Sytem Upgrade requirements for an F37 → F38 upgrade
On Thu, Mar 30, 2023 at 12:09 AM Fabio Valentini wrote: > > Additionally, the smallest offerings of popular VPS providers have > just 1 or 2 GB of RAM, is Fedora Server no longer supported on systems > like these? > Do we need to update the documentation for system requirements? Ping > cloud hosting providers that they shouldn't offer installing Fedora on > configurations with too little RAM? > There's also lots of SBCs with limited RAM - are Fedora users on these > devices supposed to reinstall Fedora every six months, since in-place > upgrades might no longer be possible? Another solution could be to tweak systemd-oomd not to touch dnf when running a system upgrade (perhaps through python3-dnf-plugin-system-upgrade). When I repeated the upgrade process with the second VM and I kept an eye out for memory usage, I saw that there were more than 300 MB available when oomd stepped in. Even installations requiring much larger transactions should be fine as long as there's a swap. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to generate new fedora.cert for package update
I don't think we're using that anymore. See this: https://docs.fedoraproject.org/en-US/package-maintainers/Installing_Packager_Tools/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedora-review crash
On Wed, Mar 22, 2023 at 8:29 PM Sérgio Basto wrote: > > ah. I think this is one bug in Fedora review (already reported) > > https://bugzilla.redhat.com/show_bug.cgi?id=1824526 Thanks for that, though I do not have any non-rpm files in that folder: $ ls -AC Desktop/coding/reviews/deps/ edwin-fonts-0.54-1.fc39.noarch.rpm finale-broadway-text-fonts-1.1-1.fc39.noarch.rpm finale-legacy-fonts-1.6-1.fc39.noarch.rpm leland-fonts-all-0.77-1.fc39.noarch.rpm finale-ash-fonts-1.7-1.fc39.noarch.rpm finale-engraver-fonts-1.4-1.fc39.noarch.rpm finale-lyrics-fonts-2.3-1.fc39.noarch.rpm leland-text-fonts-0.77-1.fc39.noarch.rpm finale-ash-text-fonts-1.3-1.fc39.noarch.rpm finale-jazz-fonts-1.9-1.fc39.noarch.rpm finale-maestro-fonts-2.7-1.fc39.noarch.rpm finale-broadway-fonts-1.4-1.fc39.noarch.rpm finale-jazz-text-fonts-1.3-1.fc39.noarch.rpm finale-maestro-text-fonts-1.6-1.fc39.noarch.rpm finale-broadway-legacy-text-fonts-1.1-1.fc39.noarch.rpm finale-jazz-text-lowercase-fonts-1.4-1.fc39.noarch.rpm leland-fonts-0.77-1.fc39.noarch.rpm ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedora-review crash
On Wed, Mar 22, 2023 at 5:59 PM Sérgio Basto wrote: > > works for me [1] , have you any custom configuration on > ~/.config/mock.cfg ? No, nothing custom there. > [1] > rpm -q fedora-review > fedora-review-0.9.0-1.fc37.noarch > > fedora-review -b 2180243 > ERROR: 'mock build failed, see logs in > /home/sergio/rpmbuild/musescore/2180243-musescore/results' > > cat /home/sergio/rpmbuild/musescore/2180243-musescore/results/root.log > (...) > DEBUG util.py:443: No matching package to install: > 'font(finalebroadway)' > DEBUG util.py:443: No matching package to install: > 'font(finalebroadwaytext)' > DEBUG util.py:443: No matching package to install: > 'font(finalemaestro)' > DEBUG util.py:443: No matching package to install: > 'font(finalemaestrotext)' If I don't specify the missing fonts, that's where fedora-review stops. Could you please retry after downloading the missing packages someplace and feeding those to fedora-review? (fedora-review -b 2180243 -v -L path/to/deps/) It's these three font families: https://copr.fedorainfracloud.org/coprs/jjames/MuseScore4/package/makemusic-finale-fonts/ https://copr.fedorainfracloud.org/coprs/jjames/MuseScore4/package/edwin-fonts/ https://copr.fedorainfracloud.org/coprs/jjames/MuseScore4/package/leland-fonts/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedora-review crash
Hi Sergio, On Wed, Mar 22, 2023 at 5:23 PM Sérgio Basto wrote: > > what is you fedora-review version ? and Fedora version ? It's fedora-review-0.9.0-1 on F37. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
fedora-review crash
Hello, When running fedora-review on RHBZ#2180243, the program crashes and I can't figure out what the problem is. There are a few dependencies of the package currently under review, which I've downloaded and passed on to fedora-review with the -L flag. This is the error I'm getting: 03-21 15:46 root INFO Build completed 03-21 15:46 root DEBUGRunning: rpm -ql --dump --nosignature -p /home/aleplo/Desktop/coding/reviews/2180243-musescore/results/musescore-4.0.2-1.fc39.x86_64.rpm 03-21 15:46 root DEBUGRunning: rpm -ql --dump --nosignature -p /home/aleplo/Desktop/coding/reviews/2180243-musescore/results/musescore-soundfont-0.2.0-1.fc39.noarch.rpm 03-21 15:46 root DEBUGException down the road... Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/FedoraReview/review_helper.py", line 236, in run self._do_run(outfile) File "/usr/lib/python3.11/site-packages/FedoraReview/review_helper.py", line 226, in _do_run self._do_report(outfile) File "/usr/lib/python3.11/site-packages/FedoraReview/review_helper.py", line 99, in _do_report self._run_checks(self.bug.spec_file, self.bug.srpm_file, outfile) File "/usr/lib/python3.11/site-packages/FedoraReview/review_helper.py", line 117, in _run_checks self.checks.run_checks(output=output, writedown=not Settings.no_report) File "/usr/lib/python3.11/site-packages/FedoraReview/checks.py", line 381, in run_checks run_check(name) File "/usr/lib/python3.11/site-packages/FedoraReview/checks.py", line 356, in run_check check.run() File "/usr/lib/python3.11/site-packages/FedoraReview/plugins/generic_build.py", line 214, in run listfiles() File "/usr/lib/python3.11/site-packages/FedoraReview/plugins/generic_build.py", line 192, in listfiles dirs, files = deps.listpaths(path) File "/usr/lib/python3.11/site-packages/FedoraReview/deps.py", line 320, in listpaths mode = int(mode, 8) ValueError: invalid literal for int() with base 8: 'root' Can anyone shed some light? I'd be happy to file a bug, but I am not sure what kind of information I could provide beyond the traceback. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review swaps
Hello Jerry, I've taken the musescore review (I haven't been able to keep up with the font packaging changes). Could you please have a look at this package in return? https://bugzilla.redhat.com/show_bug.cgi?id=2180418 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dogtag-pki is not installable on F38/Rawhide because it fails the GPG check even if you attempt to skip the check
On Thu, Mar 9, 2023 at 7:07 PM Stephen Smoogen wrote: > > The keys need to be regenerated in COPR I believe to fix this. How does one do that in COPR? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedpkg: Failed to get repository name from Git url or pushurl -> %build
On Wed, Mar 8, 2023 at 12:15 AM Kenneth Goldman wrote: > > Where are the macros defined? I.e., %configure probably expands > to ./configure and %make_build to make. In addition to Chuck's reply, you can also use the --eval (or -E) flag with rpm to see the values of variables or to what a macro actually corresponds. For example, "rpm -E %{_isa}" gives "(x86-64)" on an x86_64 host. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
DNF Sytem Upgrade requirements for an F37 → F38 upgrade
Hello, TL;DR: DNF memory usage during upgrades from F37 to F38 on a couple of Fedora Cloud images (with 2 GB of RAM each) led to oomd kicking in and killing the upgrade process. It might be worth looking into before the final (also beta?) release. The longer story: I have a couple of hosted VMs, which started their lives as Fedora Cloud 27 and which I have been upgrading to the next Fedora release via dnf-plugin-system-upgrade. These VMs run very few things, mainly some PHP applications on Apache and a good chunk of the PHP stack, some scheduled network scripts, a private rpm repository, OpenVPN and Wireguard nodes and when I am far from my main computer and koji or copr happen to be busy, I test things in mock on them. These VMs are near clones of each other, so usually only one of them is up at any moment. I've never had an issue with memory use up to now and when the systems aren't building packages, they seldom require more than 200 MB of RAM. What's more, there's the default swap-on-zram, so they should be more than happy memory-wise with 2 GB of RAM. I tried to upgrade one VM to F38, to see what problems I might face and after the packages had been downloaded, I lost the ssh connection as DNF was running the transaction test, right after a successful transaction check. I repeated the whole thing a couple more times, until I remembered that oomd is there and sure enough, DNF had been consuming 1-1.3 GB until oomd decided to kill it. Well, actually it killed my entire session and not just DNF. I tried running the upgrade inside a screen (the GNU one) session and I came back to an empty session. The transaction involved the upgrade of 1620 packages, with a total size of 1.2 GB. I think the difference between that and the previous upgrade F36 to F37) is around 100 MB and 30 or 40 packages. In each of the failed attempts, the memory pressure was 55 to 78% for more than 20 seconds, according to systemd-oomd. The exact same issues appeared when upgrading the second VM. Eventually I did the upgrade by doubling the available RAM to 4 GB (and then set it back to 2), but perhaps this could be a problem for others, especially those who pay for cloud-based resources. Is DNF supposed to be a legitimate target for systemd-oomd? Conversely, is DNF supposed to use up so much memory? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: livcd-creator gives incorrect checksum for recently rebuilt local repo packages
Todd is right, we ditched createrepo back in F30 an what's left is a symlink to createrepo_c. On Mon, Feb 27, 2023 at 4:52 AM Globe Trotter via devel wrote: > > OK, I tried createrepo_c . but I get the same error. > > Here is what I tried: > > > createrepo_c --update . > > And now, nothing from the local repo come in. I guess that dnf doesn't know about the refreshed metadata/packages. Have you tried running `dnf clean all` as the user that runs the script? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: livcd-creator gives incorrect checksum for recently rebuilt local repo packages
On Mon, Feb 27, 2023 at 4:15 AM Globe Trotter via devel wrote: > I wonder if anyone has any suggestions on how to get around this problem. I > create my local repo using > > createrepo . > > inside my RPMS/x86_64 directory. Is there a specific reason you are not using createrepo_c? Does that give you the same error? You can read about their differences here: https://github.com/rpm-software-management/createrepo_c#differences-in-behavior-between-createrepo_c-and-createrepo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: how to specify distribution (f37, say, not fc37) in a spec file
On Mon, Feb 27, 2023 at 2:39 AM Globe Trotter via devel wrote: > I am writing a spec file for SliM, the Simple Login Manager for Fedora 37. I > was thiniking of changing the default login image to the Fedora one. It > appears that that is stored in the RPM: f37-backgrounds-base and the file is > /usr/share/backgrounds/f37/default/f37-01-day.png > > So, my question is: how do I include both the rpm as well as the file that > depends on the distribution version. > > Now, from https://docs.fedoraproject.org/en-US/packaging-guidelines/DistTag/ > > I get that %{dist} or %{?dist} will give me fc37, but this is different, i > need f37, etc so that an updated spec file is not needed everytime we have an > upgrade. One way to go about it would be to use the %{fedora} variable, e.g.: Requires: f%{?fedora}-backgrounds-base If you are going to maintain EPEL branches as well, you will have to use a conditional there. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Unretiring a package
On Wed, Feb 22, 2023 at 4:43 PM Globe Trotter via devel wrote: > > According to > > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming > > unretiring a package requires review if retired for more than eight weeks. > According to releng, the package slim has been retired for 6+ weeks. Do I > still need to ask for review of this package, and file a BZ request? The package was actually retired almost a year ago, so yes. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired next week
Hi Georg, On Mon, Feb 6, 2023 at 1:17 AM Georg Sauthoff wrote: > > In case this comes up again - how does unretirement work, exactly? > Does one request to unretire a package via writing to this mailing list > or does the process work differently? These links are pertinent to your questions, it wouldn't be a bad idea to go through the enitre documents: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/#claiming_ownership_of_an_orphaned_package Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Error in python3-ptyprocess on latest update
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XI2QFIRCUJGX2FMEJ5K6ILLXOIWBGBIN/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Tue, Jan 24, 2023 at 3:56 PM Miro Hrončok wrote: > > IQmoljussilehtola I'm leaving this comment in case Susi (Cc) didn't get the previous mail like last time. I know that they're working with upstream to package the next version of IQmol, so this should be resolved sooner or later. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)
On Wed, Jan 11, 2023 at 4:47 PM Michael Catanzaro wrote: > > On Wed, Jan 11 2023 at 02:44:01 AM +0100, Alexander Ploumistos > wrote: > > Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of > > ffmpeg and so on. Why is it ok now to get these from flathub, but not > > from RPM Fusion? > > Hi, it's because RPM Fusion is explicitly designed to provide extra > packages for Fedora, whereas Flathub is not. Apparently Fedora Legal is > now OK with Flathub risk, but not with RPM Fusion risk. So there you > have it. > > Specific packages from RPM Fusion might still be allowed if split into > separate repos that don't provide access to the rest of RPM Fusion, so > that Fedora Legal can review them individually. So far, this has only > been used to allow the NVIDIA driver. Thanks Michael, what a headache. So for RPM Fusion to be included, it would have to change its scope/definition and host a more "varied" suit of packages? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)
On Wed, Jan 11, 2023 at 1:59 AM Michael Catanzaro wrote: > > On Wed, Jan 11 2023 at 01:33:18 AM +0100, Fabio Valentini > wrote: > > Also, given that it is now apparently considered "allowed" to enable > > unfiltered flathub with the "Enable third-party repositories" switch, > > I wonder if that reasoning also applies to the equivalent situation > > for RPMFusion repos? The "Enable third-party repositories" switch only > > enables "filtered" repos (containing only RPMs for proprietary NVidia > > drivers and the Steam client), so following the same reasoning, it > > should now be possible to enable "unfiltered" RPMFusion repos with > > that switch instead, as well? > > This is only allowed for RPM Fusion's NVIDIA driver repo. Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of ffmpeg and so on. Why is it ok now to get these from flathub, but not from RPM Fusion? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Mon, Jan 2, 2023 at 7:21 PM Dale Turner via devel wrote: > > As I mentioned last week, I would be interested in xaos. BUT, I am not > presently a packager/maintainer... Hi Dale, Unfortunately there's nothing that can be done (except perhaps delaying the retirement of xaos) until you become a package maintainer: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ If it does get a "stay of execution", you will be able to claim it once you are in the packagers group, but even if that doesn't happen, you will be able to get it reintroduced into the distribution. https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Christmas edition
On Wed, Dec 28, 2022 at 9:29 AM Miroslav Suchý wrote: > > I want to point one - if you are maintainer of package with license > "Copyright only" or "Redistributable" then please read: > > > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_freely_redistributable_without_restrictions > > Because in your case you will likely have to submit the license for review. > And that takes some time. Same thing for "Public Domain" license tags. Happy New Year to you too, Miroslav! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Fri, Dec 23, 2022 at 7:21 PM Steve Grubb wrote: > > This is nice, but all I ever seen is a black screen and a spinning circle. No > text of any kind. If something were written to the console, how do you see > it? Have you tried hitting "Esc" when that happens? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 8:55 PM Chris Murphy wrote: > > Also I wonder if there's a way for desktops to opt into this behavior? Or a > way for servers, iot, cloud, and rpm-ostree based systems to opt out? Do you mean like setting the "DefaultTimeoutStopSec" variable in /etc/systemd/system.conf? (at least that's the one I *think* is responsible) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Mon, Dec 19, 2022 at 4:44 PM Miro Hrončok wrote: > > seahorse-nautilus gnome-sig, orphan, stefw 2 weeks ago Taken, though I'm wondering if someone from the GNOME SIG wants it (I wouldn't mind giving it up). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Policy on supporting old and external software packages and compat RPMS
Hello Terry, On Thu, Dec 8, 2022 at 12:28 AM Terry Barnaby wrote: > > Well I don't want to rock the boat with the maintainer, they are just > doing what they think is expected. > > I will just continue with my own local RPM for our own uses and provide > it for anyone else that is in the same boat as we are. I think that you are about to miss an important opportunity here. Since you are willing to maintain the package, why not do it within the distribution? This would give you access to the infrastructure and the people that can help you with problems down the road. Since you are forced to use tools that employ old bits of software, it is more than likely that sooner or later you'll be faced with another deprecation. When that happens, as a package maintainer you will be in a better position to do something about it, either by adopting a package that is going to be retired or by becoming a co-maintainer, plus you can test your own packages. https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenVPN 2.6 Beta released
Thanks for the detailed response. There was quite a lot of reading, but in the end the upgrade from 2.5 was uneventful. I do hope there will be a migration guide when version 3 lands though. I see these messages in my system logs: Dec 07 22:56:24 bb3 audit[1786]: AVC avc: denied { setpcap } for pid=1786 comm="openvpn" capability=8 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=capability permissive=0 Dec 07 22:56:24 bb3 openvpn[1786]: libcap-ng used by "/usr/sbin/openvpn" failed dropping bounding set in capng_apply I tested a few Linux and Android clients, but I didn't notice any problems. Do you want me to file a bug report? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenVPN 2.6 Beta released
Hello David, Thanks for the heads up. Is there a tool that can test server and client configurations for compatibility before upgrading? If not, how can one verify that certificates, TLS version etc. comply with the minimum requirements? Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Gary Mann
Hello Gary, And welcome aboard! On Thu, Dec 1, 2022 at 6:17 PM Gary Mann wrote: > > […] > > My goal here is to contribute to Fedora/Redhat by > becoming a package maintainer. I've noticed that the 'mylvmbackup' > package is a simple package that currently has been retired in EL8 > that could serve as a starting point for me if anyone is interested in > mentoring me. I'm not really sure what the next steps would be in that > regard though. There's some light reading ahead, non-fiction I'm afraid: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ This should help you find your bearings. Don't hesitate to ask for help if something is not clear. Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Red Hat Bugzilla fonts
On Tue, Nov 29, 2022 at 9:02 PM Vitaly Zaitsev via devel wrote: > > On 29/11/2022 20:33, Alexander Ploumistos wrote: > > It's not "demanding", but rather "suggesting". It's not offering the > > font either. > > FOSS fonts should be placed first. I'm with you here. > > It makes sense from the web developer's perspective to > > have the page appear as good or consistent as possible on every > > platform. > > Even Windows can use FOSS fonts with WebFonts. All modern Web browsers > support it. That's more data that needs to be sent over to display the page. Unless you have a very "artistic" design or some other reason to demand a specific font, it is arguably better to make things work with what's already there on each platform and specify some reasonable fallback for edge cases. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Red Hat Bugzilla fonts
It's not "demanding", but rather "suggesting". It's not offering the font either. It makes sense from the web developer's perspective to have the page appear as good or consistent as possible on every platform. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mirros aren't working in Fedora Rawhide
Will you please stop making new threads about the same issue? You were told 4 days ago that your metadata is stale and how to refresh it (pkcon refresh force). If you think there's a bug, file a bug report in bugzilla: https://bugzilla.redhat.com/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Failed RPM database migrations
I've just checked 4 systems (2x Workstation, MATE and Cloud), and the migration was successful on all of them. They were all upgraded to the latest versions in testing at the time with dnf system-upgrade. Regular package updates were performed weekly at the latest. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What do do with failed f37 updates?
Hi Dan, On Mon, Oct 24, 2022 at 8:46 AM Dan Horák wrote: > > the docs doesn't talk about gating, I have received the same messages > ("gating failed" first, then "ignored", but no details why), hopefully > someone familiar with these process details will reply here :-) > Otherwise we should wait for the end of final freeze. I don't think the test results have anything to do with the freeze. There have been more than a few discussions[1,2,3] on this list about test gating results and what they might actually mean. From what I've been able to grasp, when it comes to failures, they could be actual test failures, or the result of infrastructure problems. We'd have to be able to tell between the two though… Also, there is some documentation, but the couple of times I tried to see if and how test gating could be of use for my packages, I was left with more questions than answers and I abandoned the effort: https://docs.fedoraproject.org/en-US/ci/gating/ 1. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/S43QRNBKN7RFWHWVYXTM7UOMIXXUCA6X/ 2. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MCCT4MBLKVYADXYQLWYR3NHQTEDYOSJX/ 3. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VSGOFN5OQP3ZCFF4L5SWQ3BDSDO7MPKA/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What do do with failed f37 updates?
On Mon, Oct 24, 2022 at 4:46 AM Richard Shaw wrote: > > Is some sort of manual intervention required or not? > > Do I need to put in a ticket somewhere or not? > > Nothing in the message gives me any context as to what is required. There's nothing to do, but wait. https://docs.fedoraproject.org/en-US/releases/lifecycle/#_development_process ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What do do with failed f37 updates?
Hello Richard, We are at the final freeze stage, so that's probably why these updates haven't moved to stable. What do you mean by "ignored"? The only thing I see is that test gating is ignored. On Mon, Oct 24, 2022 at 3:11 AM Richard Shaw wrote: > > So > > Maybe this is documented somewhere, but I don't see an obvious action to take > when an update has failed to push and is now "ignored" (what does that mean > anyway?!?). > > Is there something I need to do or will they be magically taken care of? > > Thanks, > Richard > > https://bodhi.fedoraproject.org/updates/FEDORA-2022-6be9fa2074 > https://bodhi.fedoraproject.org/updates/FEDORA-2022-714f4e1c6b > https://bodhi.fedoraproject.org/updates/FEDORA-2022-b020436122 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Sébastien Le Roux
On Wed, Sep 28, 2022 at 8:35 PM Sébastien Le Roux wrote: > > Le 28/09/2022 à 20:13, Alexander Ploumistos a écrit : > > > Yes I did look into this documents today, followed the procedure, and > submitted the bugzilla: > > https://bugzilla.redhat.com/show_bug.cgi?id=2130607 I'm preparing for an interview with the CNRS these days, but if nobody else turns up, I will do the review. > About what I understand the first thing is to find a sponsor, and I hope > what I provided is enough, > please let me know if you think that I missed something, I would correct > it ASAP. I've set the FE-NEEDSPONSOR flag to your review request, it should help with that. In the meantime, you could add this to your reading list: https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/ It could give you some pointers as to what you could do to get sponsored, e.g. unofficial reviews. > However I wasn't able to understand how to provide a 'koji' build, > I can build the package using 'fedpkg' (local) but not sure how both > relate ... It's in the "Scratch Builds" section of this document (they're quickly piling up, I know…): https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/ Essentially, you do a scratch build of your package in Rawhide and if it is successful, you post the link to your review request. > > Eventually, you might be interested in joining the Sci-Tech SIG, it's > > more than likely that we maintain some package you might be using and > > more hands are always welcome: > > https://fedoraproject.org/wiki/Category:SciTech_SIG > > Sure, but I would need a proper training before that ;-) There are quite a few chemistry-related packages that could use more love. I think you are more than qualified to lend a hand in many of them, should the need occur. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Sébastien Le Roux
Hello Sébastien, Bienvenue ! Have you taken a look at these documents? They should help you get started. https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/ Eventually, you might be interested in joining the Sci-Tech SIG, it's more than likely that we maintain some package you might be using and more hands are always welcome: https://fedoraproject.org/wiki/Category:SciTech_SIG Feel free to ask for help with anything. I'm looking forward to a 'dnf install atomes'! Best regards On Wed, Sep 28, 2022 at 5:30 PM Sébastien Le Roux wrote: > > Dear all, > my name is Sébastien Le Roux, I just join the mailing list today. > I am a computational material scientist, > my work can be separated in two parts: studying the physico-chemical > properties > of materials using computational/theoretical methods, and developing tools to > help > scientists in this field of expertise. > I am the author of several open source programs, so far none being packaged > by Fedora, but I recently released a new software named 'Atomes' and I would > like to propose Atomes for packaging, and then providing that it can be > packaged > maintain it. > > Atomes is a Free (Open Source) cross-platform toolbox developed to analyze, > to visualize and to create/edit three-dimensional atomistic models. > Among the possibilities offered by Atomes: > > Analysis of 3D atomistic model: neutron and x-rays diffraction, rings > statistics, chain statistics, bond order, MSD ... > Visualization: measures, coordination polyhedras, advanced coloring, advanced > design > Edition: molecular library, crystal builder, cell edition, surface creation > and passivation ... > Molecular Dynamics input preparation systems: > > Classical MD: DLPOLY and LAMMPS > ab-initio MD: CPMD and CP2K > QM-MM MD: CPMD and CP2K > > > More info about me here: https://www.ipcms.fr/sebastien-le-roux/ > More information about Atomes here: https://atomes.ipcms.fr/ > > So hello world ;-) > > Best regards. > > Sébastien Le Roux > > PS: using Fedora since FC2 > > -- > === > Dr. Sébastien Le Roux > Ingénieur de Recherche CNRS > Institut de Physique et Chimie des Matériaux de Strasbourg > Département des Matériaux Organiques > 23, rue du Loess > BP 43 > F-67034 Strasbourg Cedex 2, France > E-mail: sebastien.ler...@ipcms.unistra.fr > Webpage: https://www.ipcms.fr/sebastien-le-roux/ > ATOMES project: https://atomes.ipcms.fr/ > RINGS project: http://rings-code.sourceforge.net/ > ISAACS project: http://isaacs.sourceforge.net/ > Fax: +33 3 88 10 72 46 > Phone: +33 3 88 10 71 58 > === > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
The only issues I've encountered were related to nautilus extensions. Bugs are open for all of them and I submitted a PR for an rpmfusion package. However, I think that for people on Workstation who encrypt/decrypt/sign files through nautilus (and who are not comfortable with a terminal), the loss of seahorse-nautilus is going to be a significant problem. Could anyone take a look to see if it can be patched to work on F37? I was able to get the compilation going up to a point, but the subsequent errors were beyond my knowledge. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 37 mass rebuild started
Thank you Vitaly. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 37 mass rebuild started
Hello, Two of my packages failed to build due to a trailing "." after the %cmake macro in the spec file. I have a couple of questions: First, do I need to wait for the FTBFS bugs to be filed before I fix the packages or can I submit updated builds to the f37-rebuild side tag myself? Second, I hadn't touched these spec files because I was waiting to see what the resolution of RHBZ#2079833 would be. If I understand correctly, any packages that required the declaration of a source path after the %cmake macro in order to build were exploiting an unintended behavior and the paths should be set in the corresponding cmake files, regardless of the macro's behavior. Have I got things right? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
There are some issues with Open Babel's dependencies: Error: Problem 1: package expo-1.18.11-1.fc28.x86_64 requires libopenbabel.so.5()(64bit), but none of the providers can be installed - openbabel-libs-2.4.1-37.fc35.x86_64 does not belong to a distupgrade repository - problem with installed package expo-1.18.11-1.fc28.x86_64 Problem 2: problem with installed package IQmol-2.15.0-5.fc35.x86_64 - package IQmol-2.15.0-5.fc35.x86_64 requires libopenbabel.so.5()(64bit), but none of the providers can be installed - cannot install both openbabel-libs-3.1.1-6.fc36.x86_64 and openbabel-libs-2.4.1-37.fc35.x86_64 - package ghemical-3.0.0-19.fc36.x86_64 requires libopenbabel.so.7()(64bit), but none of the providers can be installed - problem with installed package ghemical-3.0.0-17.fc35.x86_64 - ghemical-3.0.0-17.fc35.x86_64 does not belong to a distupgrade repository ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Copr success but no packages?
Hi Steve, It looks like you had some (browser?) caching issue, all the rpms in all the chroots are there. Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: sdsl-lite package review
Hello Antonio, I'll take care of it. Till later, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, registriy) - 2021-11-09 17:00 UTC
Now they're back up and running again. I think that when I started the builds before, s390x did not appear in the output of "koji list-tasks --mine". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, registriy) - 2021-11-09 17:00 UTC
Hello Kevin, On Fri, Nov 5, 2021 at 2:26 PM Kevin Fenzi wrote: > > Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, > registriy) - 2021-11-09 17:00 UTC […] > > We will be doing several maint tasks during this outage: > > All the s390x builders will be moving from the current z13 maintframe to > a z15 mainframe. I'm getting a bunch of build failures only on s390x with a message about a read-only filesystem, e.g.: https://koji.fedoraproject.org/koji/buildinfo?buildID=1854066 https://koji.fedoraproject.org/koji/buildinfo?buildID=1854065 https://koji.fedoraproject.org/koji/buildinfo?buildID=1854067 Are these related to the problems with the move between mainframes? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
On Fri, Nov 5, 2021 at 9:23 PM Antonio T. sagitter wrote: > > On 10/24/21 15:11, Alexander Ploumistos wrote: > > Hello Antonio, > > > > On Sun, Oct 24, 2021 at 3:05 PM Antonio T. sagitter > > wrote: > >> > >> We are ready to push openbabel3 in Rawhide > > > > Will it be just Rawhide? Will you please let us know when the build is > > done in order to rebuild dependent packages? > > Within 24 hours i will create a side-tag in Rawhide. Thanks Antonio, I'll probably be able to do the rebuild on Sunday night. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Checking part of package version number in spec file
Thanks a lot Björn, this is very helpful! All the best, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Checking part of package version number in spec file
Hello, I'm wondering if there's an "elegant" and "rpm" way to do the following, without calling an external tool (and maybe adding another dependency to a package): Project "foo" tracks the development of project "bar" and both use basic semantic versioning, X.Y.Z. Project "bar" rarely increments the patch version and only for internal development purposes. Regular releases always carry a patch version of 0, e.g. 16.5.0. Project "foo" follows the same major and minor versions as "bar", but they also publish releases with incremented patch versions. Any given foo release should be built against a bar release with the same major and minor versions. Does rpm provide a way to require that part of the version string, e.g. for foo-16.5.4: Requires: bar >= 16.5 without hard coding the actual values? Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
Hello Antonio, On Sun, Oct 24, 2021 at 3:05 PM Antonio T. sagitter wrote: > > We are ready to push openbabel3 in Rawhide Will it be just Rawhide? Will you please let us know when the build is done in order to rebuild dependent packages? Are we saying goodbye to Avogadro 1.x? Thank you for all the work you've put into this, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Renaming a project/package?
Hello Ron, On Thu, Sep 30, 2021 at 9:55 PM Ron Olson wrote: > > I haven’t found any info about renaming an existing project/package, and was > wondering what the procedures would be. We have this: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
On Sun, Sep 26, 2021 at 12:59 PM Antonio T. sagitter wrote: > > On 9/26/21 10:22, Antonio T. sagitter wrote: > > I moved the openbabel's libraries under a private lib directory. > > 'desktop' files are modified for working in this sense. > > Sorry, i meant gchemistry's libraries under a private lib directory. > > > > Let me check again Avogadro2. My mistake about gnome-chemistry-utils, after the failure to open some cif files in F35, in F34 I kept launching the programs from the terminal. They do work (with the same problems they had with Open Babel 2). Avogadro launched with the right backend only suffers from the crash after the addition of a fourth atom. The Wayland backend works also on X11, whereas the X11 one shows a transparent canvas on Wayland. I am using your last copr build. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
On Sat, Sep 25, 2021 at 5:05 PM Alexander Ploumistos wrote: > > I will try with a Fedora 34 VM later and report back. I got pretty much the same results on F34. I think xdrawchem works better with Open Babel 3 than it does with Open Babel 2, at least as far as structure cleanup goes (I installed the current version in F34). With Open Babel 2, SMILES output is also asterisks and trying InChi output crashes the program, so nothing changed there. gnome-chemistry-utils programs can't find the required shared object files in F34 either. I built the latest avogadro2 and avogadro2-libs from the srpm in your copr for F34 and I hit some graphical glitches again. On Wayland, Avogadro2 for X11 has a transparent canvas, whereas the other one (I guess Wayland) doesn't, but as soon as I add a fourth atom to the drawing, it crashes: /usr/include/c++/11/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = Eigen::Matrix; _Alloc = std::allocator >; std::vector<_Tp, _Alloc>::reference = Eigen::Matrix&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' failed. Aborted (core dumped) However, when given a badly drawn propene or propane molecule, the structure optimization works fine. On X, I did not get the transparent canvas, but I got the crash at the fourth atom. I was able to open some of my existing files though, with up to several thousand atoms and the structure optimization worked fine after I had deformed them. At least any issues are not from Open Babel 3 (I guess). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
Hello Antonio, On Fri, Sep 24, 2021 at 7:50 PM Antonio T. sagitter wrote: > > Even the porting to openbabel3 of 'xdrawchem' is done. > Please, can anyone that uses these software test them? I spun up a Fedora 35 VM and installed everything from your copr, didn't mess with any system settings. Here's what I've got. * xdrawchem: I hadn't used it since Molsketch was revived a few years ago and I'm not sure if everything was working as expected. My guess was that structure refinement ("clean up molecule") and the SMILES/InChi output had to do with Open Babel, so I tried those. For SMILES, regardless of the atom type, I always get an asterisk, e.g. for butane. Double bonds and such are correctly placed in the star-filled strings though. InChi crashed the program: == *** Open Babel Warning in InChI code #1 :Unsupported in this mode element '*' == *** Open Babel Error in InChI code InChI generation failed /usr/include/c++/11/bits/basic_string.h:1058: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator[](std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::reference = char&; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]: Assertion '__pos <= size()' failed. Aborted (core dumped) Structure cleanup sort of works, but as 2D projections of the actual 3D structures, which is not that great-looking for a 2D drawing program. * gnome-chemistry-utils: While the (right) gnome-chemistry-utils-libs package is installed, I could not get the individual programs to start, e.g. $ gcrystal gcrystal: error while loading shared libraries: libgcu-0.14.so.0: cannot open shared object file: No such file or directory $ gchemcalc gchemcalc: error while loading shared libraries: libgcugtk-0.14.so.0: cannot open shared object file: No such file or directory * Avogadro2: Avogadro appears to be working, but I can't see anything on the canvas, it displays whatever window is behind it on the screen, or the wallpaper if there's nothing else there. Maybe a Wayland bug? I will try with a Fedora 34 VM later and report back. P.S.: I have never used ghemical, so I didn't try it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
On Thu, Sep 23, 2021 at 3:37 PM Antonio T. sagitter wrote: > > gnome-chemistry-utils is ready for openbabel3; it's in my Copr project. Well done Antonio! I will give it a try this weekend. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
Hello Antonio, On Fri, Sep 3, 2021 at 2:32 PM Antonio T. sagitter wrote: > > Links of Copr projects to get srpms for testing: > > openbabel3-3.1.1: > https://copr.fedorainfracloud.org/coprs/sagitter/Openbabel-3/ As expected, Molsketch had no problem with 3.1.1, it built fine. I also played with the binaries in /usr/bin/ a bit, not much difference from what I saw two years ago, some small bugs were fixed in the meantime and I was able to recreate some of the bugs reported upstream. I'd really love to say that I'd help with porting the other packages, but until March my spare time will be severely limited and I could use every second spent away from a computer screen. However, if you decide to move forward I'll at least try to lend a hand. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
Hi Antonio, On Wed, Sep 1, 2021 at 8:11 PM Antonio T. sagitter wrote: > > 'openbabel2' and 'openbabel3' cannot co-exist if installed because they > have same binary files, it's a "binary name conflicts". > > Is it acceptable an openbabel2/openbabel(3) conflict in Fedora? I think that the people you'd be catering to by providing both packages are also the ones more likely to be bitten by the conflict between them. Taking Avogadro as an example, there are people who use both Avogadro and Avogadro2, because of their different feature sets. If one day these people are notified that they can't have both Avogadro and Avogadro2 installed at the same time, I don't suppose they're going to be much less displeased than when they'd find out that Avogadro had been deprecated. In my view, the way forward is for maintainers to patch what can be patched to work with Open Babel 3 and lay the others to rest. Less work for you and slightly less or equal amount of frustration for the users. At least now that enough time has passed since the 3.x release, as Mamoru pointed out, a lot of the work required has already been done by other distros. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
On Tue, Aug 31, 2021 at 6:08 PM Antonio T. sagitter wrote: > > On 8/31/21 5:27 PM, Alexander Ploumistos wrote: > > > > We must decide if go forward with most recent software or stay stationary. > Which software are not ready for openbabel-3 yet? Almost two years ago (how time flies!), when the subject had been first broached, Dominik provided this list: Link-time dependencies: IQmol avogadro ghemical gnome-chemistry-utils kalzium molsketch xdrawchem Run-time dependencies: avogadro2 chemtool molsketch At the time, I think only Molsketch was compatible with Open Babel 3. After getting version 3.1.1 to build[1], I spent a few weekends trying to modify gnome-chemistry-utils, but due to lack of time I didn't go very far and looking at the code in my files, I'm not really sure what I've actually done, I don't remember much. Personally, I use avogadro* a lot, which you maintain (and therefore I don't worry about it ;) ) and GChemCalc (almost daily) and sometimes GSpectrum from g-c-u, neither of which is indispensable, though both are quite handy. I haven't checked any of the other programs on that list recently, but about a year ago, not much had changed. > I can leave to you an openbabel-3 srpm or Copr builds of it for your tests. > > One week is a minimal time, no problem if you need more time. > As far as I can tell, Molsketch will use whichever version of Open Babel is installed on the system and users of a couple of other distros have been building it against v3 without any problems, so I don't expect any either. Just please let me know when you've built it in Rawhide and I'll do the rebuild then - hopefully the new version will also be out by that time. Best regards, A. 1. https://copr.fedorainfracloud.org/coprs/alexpl/openbabel/builds/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
Hello Antonio, On Tue, Aug 31, 2021 at 5:03 PM Antonio T. sagitter wrote: > > 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: What about the packages that haven't been ported to work with Open Babel 3.* yet? Do you intend to keep v2 around in some form? > $ repoquery --whatrequires openbabel-devel --disablerepo=* > --enablerepo=*-source > > molsketch-0:0.7.2-1.fc34.src I'm waiting for Hendrik to release a new version sometime soon, at worst let it FTBFS and I'll deal with it in time. All the best, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: replace memtest86+ with pcmemtest, needs maintainer
Hi Vitaly, On Sat, Jul 31, 2021 at 10:28 AM Vitaly Zaitsev via devel wrote: > > They just closed the sources. Memtest86 is a commercial product now. It > has full UEFI support, etc. Just to be sure, you are talking about Memtest86, not Memtest86+, right? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self introduction : Nicolas FORMICHELLA
Salut Nicolas, And welcome aboard! On Sun, Jul 25, 2021 at 3:54 AM Nicolas FORMICHELLA wrote: > and in process of packaging Canon IJfilter driver for AUR/RPM and DEB A long time ago I had managed to create an rpm from canon's package for the iP7200 printer, which conformed to our guidelines at the time. I don't have the printer anymore, but Petar Dodev has kept it up to date: https://github.com/dodev/cnijfilter If you have to work with a different driver package, this might be of no use to you, but I hope it might give you some ideas. Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: debugging pipewire & root access to systemd userspace
Hello Zbigniew, Thank you very much for your answers and sorry for the late reply, IRL things have been hectic. I've had the problem with pipewire once since I last wrote, but I can't figure out how to trigger it at will. On Fri, Jun 18, 2021 at 8:36 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jun 18, 2021 at 01:38:08AM +0200, Alexander Ploumistos wrote: > > Should gdb be able to read from a sound device? > > It shouldn't attempt to. Should I file a bug against gdb or abrt? > > Having root logged in a terminal, I tried to check the state of > > pipewire.service: > > systemctl --machine=myuser@.host --user status pipewire.service > > > > to which I got the reply: > > Failed to get properties: Transport endpoint is not connected > > The way that myuser@.host is implemented is surprisingly complex. See > the original commit https://github.com/systemd/systemd/commit/1b630835df > for a description. > > Does it work for other users? If yes, then it looks like something > is borked for that particular user. Forgot to check, I will try to do it later today. > systemctl -M myuser@.host executes > systemd-run -p User=myuser systemd-stdio-bridge > -punix:path=${XDG_RUNTIME_DIR}/bus > The error message is most likely from systemd-stdio-bridge, > or from systemctl failing to connect to the bridge. Since the > invocation of systemd-stdio-bridge goes through the system manager, > you can look at the logs for that unit ('journalctl -b -u run-u.service'). > It should show some error. There is no such service. Assuming is the uid, I have these units listed: user-runtime-dir@1000.service user@1000.service user-1000.slice Looking at the logs for user@1000.service, there's nothing pertinent. Actually there's nothing even in the unfiltered log when I issue the command and it fails. > > I haven't had to bother with a userspace systemd service before, so > > going down that rabbit hole, at some point I started messing with > > machinectl, and apparently, running something seemingly innocuous such > > as "machinectl list-images --all" triggers a SELinux denial. But not > > always… > > The message I'm seeing is this: > > audit[1079]: AVC avc: denied { write } for pid=1079 > > comm="systemd-machine" name="/" dev="dm-1" ino=2 > > scontext=system_u:system_r:systemd_machined_t:s0 > > tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=0 > > > > setroubleshoot tells me that if I want to allow daemons to dump core, > > then I should enable the 'daemons_dump_core' boolean. I don't know if > > I want to, do I need to do that in order to dive deeper into my > > pipewire issue? How is listing the images on a system related to > > allowing demons to dump core though? > > If machined crashes, there should be logs about this. Did you > look at the journal? Nothing in the journal about machined crashing or doing anything else other than getting the SELinux denial. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
debugging pipewire & root access to systemd userspace
Hello, Apologies if you find the subject line vague or misleading, I couldn't figure out what to write. I've been trying to debug a transient pipewire issue so that I can file a bug report, but I keep stumbling from one roadblock to the next. When the problem occurs, pipewire receives a SIGSEGV and dies, e.g. kernel: pipewire[2239]: segfault at 0 ip sp 7fc634298998 error 14 in pipewire[55d7316d+1000] kernel: Code: Unable to access opcode bytes at RIP 0xffd6. At that point, abrt tries to get gdb to process the core dump, which fails because it wants to open a sound device: audit[7970]: AVC avc: denied { read } for pid=7970 comm="gdb" name="pcmC0D0p" dev="devtmpfs" ino=594 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file permissive=0 Should gdb be able to read from a sound device? There seems to be a problem in impl_node_process.lto_priv.0, but a) I can't reproduce it at will and b) abrt can't send a report to someone who knows what they're doing because it can't process the core dump. Having root logged in a terminal, I tried to check the state of pipewire.service: systemctl --machine=myuser@.host --user status pipewire.service to which I got the reply: Failed to get properties: Transport endpoint is not connected Am I doing something wrong here? How is root supposed to control (or just check on) userspace systemd services? I've also tried the loopback address and my actual IP instead of .host, but no luck with them either. The user can run all the systemctl --user commands just fine. By the way, what is the proper, Fedora way to restart pipewire? Is $ systemctl --user restart pipewire.service what I should be doing? I haven't had to bother with a userspace systemd service before, so going down that rabbit hole, at some point I started messing with machinectl, and apparently, running something seemingly innocuous such as "machinectl list-images --all" triggers a SELinux denial. But not always… The message I'm seeing is this: audit[1079]: AVC avc: denied { write } for pid=1079 comm="systemd-machine" name="/" dev="dm-1" ino=2 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=0 setroubleshoot tells me that if I want to allow daemons to dump core, then I should enable the 'daemons_dump_core' boolean. I don't know if I want to, do I need to do that in order to dive deeper into my pipewire issue? How is listing the images on a system related to allowing demons to dump core though? If anyone can shed some light on any of the above, please do. Again, sorry for the messy subject and the even messier post. Best regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure