Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
On Wed, Jul 24, 2024 at 1:46 PM Miroslav Suchý wrote: > > Dne 24. 07. 24 v 12:30 odp. Joe Orton napsal(a): > > Having a "majority rule" vote of e.g. packagers or provenpackagers on > major technical decisions would be far superior, in my view. Apache > communities have worked this way forever. > > You can always propose this as a change to our process. For what it's worth, I don't believe that this process will work well. I'm all for democracy, but direct democracy without compulsory voting inevitably leads to "grievance-based voting", where the majority of folks ignore the discussion and a plurality of voters with a strong opinion effectively stuff the ballot box. The effect is to have a tyranny of the (loud) minority. The closest we could get to "compulsory voting" would be to require a quorum of votes to be considered binding, but even the FESCo and Council elections traditionally see extremely low voter turnout. I don't think we'd be able to reach a sensible quorum on a referendum-based system. Beyond that, I don't think the current approach is actually broken. People elected us to make these sorts of decisions on their behalf. If any of us were to consistently vote in a way that the general community members felt is not in the interests of Fedora, then I fully expect and hope that we would not be re-elected. The current approach is the best one I can think of for our community: we have an active feedback period where anyone can (and is encouraged) to chime in on potential changes. I can assure you that I read that feedback and I expect that the other members of FESCo do the same. If you look at our meeting notes, you'll notice we often defer our decisions when a discussion remains highly active. As for the accusations of "rubber stamping" all Changes, I'd like to note that FESCo has declined to accept several Changes this cycle based on feedback. If you look at last week's minutes, you'll note that we discussed and rejected two proposals and approved another reluctantly (due to a lack of better options). By the time issues get to a FESCo vote, they've generally run through the discussion and have either been agreed to or the disagreement is clearly not going to reach a compromise, at which point FESCo has to make a decision. Sometimes that's going to be controversial (as in this case, apparently). When voting, we don't always restate our thought process, which admittedly means that the votes - taken in a vacuum - can lack context and perhaps appear unconsidered. -- ___ 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: Announcing fmt library soversion bump
On Thu, Jul 18, 2024 at 7:37 PM kefu chai wrote: > > > > On Fri, Jul 19, 2024 at 2:22 AM Stephen Gallagher wrote: >> >> On Thu, Jul 18, 2024 at 4:51 AM Vitaly Zaitsev via devel >> wrote: >> > >> > On 18/07/2024 08:27, Adam Williamson wrote: >> > > I guess the fmt10 compat package needs to be imported to ELN (or >> > > everything patched/rebuilt to so.11). >> > >> > You're right, a compatibility version is required to unbreak Koji/dnf5 >> > there, but Fedora maintainers can't do anything with it since ELN is a >> > separate subset of Fedora packages. >> >> I'm not sure what you mean by "Fedora maintainers can't do anything >> with it". The ELN team is happy to work with people on things like >> this. Ideally, the rebuilds would have been done in a side-tag, which >> >> will usually allow us to rebuild them all together (inheriting the >> Rawhide builds into the buildroot to avoid bootstrapping loops). There >> was no side-tag in this instance, so we probably got bitten by that. > > > hi Stephen, > > i did requested a side tag "f41-build-side-92475" for building the packages > depending on fmt. > do you mean that we should also have used a dedicated side-tag for building > for ELN? > No, that should have been sufficient. ELN triggers its build (automatically creating its own side tag) when the contents of a side tag are tagged back into the Rawhide tag. Did you create a Bodhi update to tag these all back in? I guess we need to investigate why this didn't work in this situation. -- ___ 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: Announcing fmt library soversion bump
On Thu, Jul 18, 2024 at 4:51 AM Vitaly Zaitsev via devel wrote: > > On 18/07/2024 08:27, Adam Williamson wrote: > > I guess the fmt10 compat package needs to be imported to ELN (or > > everything patched/rebuilt to so.11). > > You're right, a compatibility version is required to unbreak Koji/dnf5 > there, but Fedora maintainers can't do anything with it since ELN is a > separate subset of Fedora packages. I'm not sure what you mean by "Fedora maintainers can't do anything with it". The ELN team is happy to work with people on things like this. Ideally, the rebuilds would have been done in a side-tag, which will usually allow us to rebuild them all together (inheriting the Rawhide builds into the buildroot to avoid bootstrapping loops). There was no side-tag in this instance, so we probably got bitten by that. > > To prevent such issues in the future, I think the dnf5 package should > have a %bcond option to build it against fmt in a header-only mode > (fully supported by fmt-devel). > > This will help fmt maintainers too - the compatibility package fmtX > won't be needed: > > 1. Rebuild dnf5 in a header-only mode. > 2. Update fmt. > 3. Rebuild dnf5 again in normal mode. > I've asked Yaakov Selkowitz to try and untangle the situation now. Thanks for letting us know! -- ___ 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: aarch64 iso images - can we link the Everything installer?
On Tue, Jul 16, 2024 at 5:41 AM Peter Robinson wrote: > > On Tue, 16 Jul 2024 at 08:28, Adam Samalik wrote: > > > > I noticed we're no longer link to aarch64 isos: > > https://fedoraproject.org/spins/kde/download > > Not even for Workstation: https://fedoraproject.org/workstation/download > > > > I heard it failed to build. Fair enough. > > We do link the Server installer which can be used in the same way > although being labelled server it's not obvious. Note though that the Server installer does not use the same default filesystem layout as Everything, due to Server Edition preferring the XFS+LVM layout. So it's not going to be the exact same experience. > > But the Everything installer iso for aarch64 works fine, we just don't seem > > to link it from anywhere: > > https://mirror.serverion.com/fedora/releases/40/Everything/aarch64/iso/ > > > > Can we link it from the website? > > I'm not sure we link Everything for other arches, although maybe it's > worthwhile for all arches as a minimum base that should work as a > default fallback. > > > > > I just had this experience: I wanted to install the Fedora KDE Edition > > (hah, sorry, Spin!) on an M1 MacBook Pro, using UTM (an open source GUI to > > manage VMs on a Mac, built on top of QEMU). For that I'd normally get the > > iso, and install the system using Anaconda. But that isn't provided > > anymore, and the Everything installer is also not mentioned anywhere. So if > > I didn't know my way around, or was new to Fedora, I would have thought > > it's no longer an option. Even though it is and works perfectly fine. > > > > The Everything installer, in my opinion, is the superior one anyway because > > it lists all the options and is smaller. And the installed system is > > up-to-date right away. But that's a different conversation. :-) That's a double-edged sword: yes, it has all the latest updates. At the same time, that means it's not as rigorously tested and updates may have introduced issues into the install 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: The future Fedora Copr "rolling" chroot cleanup policy
On Tue, Jul 16, 2024 at 3:44 AM Pavel Raiskup wrote:
>
> On pondělí 15. července 2024 16:32:45, SELČ Stephen Gallagher wrote:
> > On Mon, Jul 15, 2024 at 10:21 AM Miroslav Suchý wrote:
> > >
> > > Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a):
> > >
> > > Instead of always keeping "Rawhide" around as a separate buildroot,
> > > why not just rename it at Branching and then create a NEW Rawhide
> > > chroot?
> > >
> > > 1) Different workflow compared to the one we have in Fedora.
> >
> > How do you mean?
> >
> > > 2) Create it with what? Empty content ("why you are forcing be to rebuild
> > > everything")? Copy everything (you end up in the same situation)? Rebuild
> > > packages from previous rawhide (what if it fails to build? what if it
> > > succeed but no one uses it anyway?).
> >
> > Let me flip it around: how did you create "Fedora 40" when Rawhide
> > branched for that? I'm just saying to do it the other way around.
>
> Actually, I think the current Copr process is similar to what Fedora
> does. We hardlink the RPMs to branched chroot and run createrepo_c
> (unless user decides this is unwanted behavior, and opts-out).
> There's no need to re-sign the RPMs, sure - as the signature is shared
> for all the project's chroots.
>
> Do you suggest moving rawhide to branched, and start with a fresh (empty)
> rawhide chroots for every branching?
>
Yes, that was exactly what I was suggesting. (Well, possibly with
auto-triggering builds for the new chroot if the option to follow
Fedora branching is enabled).
--
___
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: the sad state of installability tests
On Mon, Jul 15, 2024 at 4:06 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jul 15, 2024 at 08:55:03AM -0400, Stephen Gallagher wrote: > > This seems like overkill. Wouldn't the simplest valid installability > > test just be to test whether each subpackage *individually* could be > > installed? > > That's a really nice idea. > > > If we have 20 subpackages, just launch 20 separate minimal containers > > and see if `dnf install subpackageN` succeeds. Then it doesn't matter > > if there are conflicts; we know that at least installing that package > > directly will work. (Dependency resolution may pull in other > > subpackages of course, which is proving that it works properly.) > > I'm not sure if we actually want a container. Because if it's a container, > then we need _some_ packages inside. But that creates a problem for > some packages like cannot be just installed, but need to be swapped > with other packages. (systemd-standalone-*, coreutils-single, etc.) > I think it'd be more reliable to do something like > dnf install --enablerepo=/path/to/repo/with/updates > --sysroot=/var/tmp/inst-package1 /path/to/repo/with/updates/package1.rpm > dnf install --enablerepo=/path/to/repo/with/updates > --sysroot=/var/tmp/inst-package1 /path/to/repo/with/updates/package2.rpm > ... > > And to make this work reliably, the invocation of dnf should be > wrapped in 'bwrap' to set up /dev, /proc for the invocation. > > This should be quick and more reliable than the current tests, > even with no config. > Sure, I oversimplified by saying "container", but I agree with your suggestion. That seems both simple and effective. -- ___ 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: The future Fedora Copr "rolling" chroot cleanup policy
On Mon, Jul 15, 2024 at 10:21 AM Miroslav Suchý wrote:
>
> Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a):
>
> Instead of always keeping "Rawhide" around as a separate buildroot,
> why not just rename it at Branching and then create a NEW Rawhide
> chroot?
>
> 1) Different workflow compared to the one we have in Fedora.
How do you mean?
>
> 2) Create it with what? Empty content ("why you are forcing be to rebuild
> everything")? Copy everything (you end up in the same situation)? Rebuild
> packages from previous rawhide (what if it fails to build? what if it succeed
> but no one uses it anyway?).
Let me flip it around: how did you create "Fedora 40" when Rawhide
branched for that? I'm just saying to do it the other way around.
--
___
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 41 Mass Rebuild Notification - Scheduled for 2024-07-17
On Mon, Jul 15, 2024 at 9:43 AM Miroslav Suchý wrote: > > Dne 15. 07. 24 v 3:38 odp. samyak.j...@gmail.com napsal(a): > > The content of this message was lost. It was probably cross-posted to > > multiple lists and previously handled on another list. > > This is not first time I see this. First I thought it is my setup. But it is > in ML archives too. > > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/X3SCXM6BNDJ2AZHVSQNVU2NWQNFZMND4/ > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X3SCXM6BNDJ2AZHVSQNVU2NWQNFZMND4/ > > Is something somewhere broken? > I am not sure what happened here exactly. I saw this morning that there was a message stuck in the devel-announce queue awaiting approval from Samyak with an appropriate title, so I approved it. I noticed after I did that the held message had a zero-length body, which I assume Mailman translated into this message. I'm not sure where the missing content went. -- ___ 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: The future Fedora Copr "rolling" chroot cleanup policy
On Mon, Jul 15, 2024 at 4:25 AM Pavel Raiskup wrote: > > Hello maintainers. > > This is a gentle heads-up (at least a year in advance) that we plan to > address Fedora Copr storage consumption related to Fedora Rawhide > builds. Currently, Rawhide build results are kept indefinitely, but > this is going to change in the future. > > For the full story, see the blog post: > https://fedora-copr.github.io/posts/cleanup-rawhide-builds > > TL;DR: We plan to start monitoring build activity in Copr projects. > If no builds appear for a long time in these "rolling" chroots (such as > Fedora Rawhide), we'll disable such chroots, preserve the built results > for a while, and then delete them if no action is taken by the user. > > Hope this isn't going to cause too much inconvenience. Feel free to > discuss this here or under the blog post. Rather than keep them indefinitely, why don't the "Rawhide" builds just become the equivalent Branched buildroot? Instead of always keeping "Rawhide" around as a separate buildroot, why not just rename it at Branching and then create a NEW Rawhide chroot? -- ___ 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: the sad state of installability tests
On Mon, Jul 15, 2024 at 8:03 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jul 15, 2024 at 01:26:09PM +0200, Petr Pisar wrote: > > V Mon, Jul 15, 2024 at 08:45:53AM +, Zbigniew Jędrzejewski-Szmek > > napsal(a): > > > On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > > > > I guess the test does not take RPM Conflicts into account. It's overly > > > > optimistic when populating a system by installing all tested packages > > > > together > > > > instead of creating a new system for each test seperately. Or by adding > > > > --allowerasing to "dnf install" invocations if the CI wants to reuse > > > > the system. > > > > > > Yes and no. The test does not look at the package metadata at all, it just > > > tries to install all the packages that were part of the update. > > > In the case above, coreutils.srpm builds coreutils.rpm and > > > coreutils-single.srpm, > > > which have Conflicts on one another, and cannot be installed at the same > > > time. > > > > > > The test which (I think) we really want is to install the combined set > > > of packages from the update, so we exercise the situation that will occur > > > on end-user systems, but exclude the packages from this set which are > > > known > > > to be not co-installable. > > > > > Maybe I conflate installability tests with rpmdeplint tests. We need both: > > A test which checks that each package is separately installable. And a test > > which tcgecks that wanted combinations of packages can be installed > > together. > > > > I cannot see how "exclude the packages from this set which are known > > to be not co-installable" can be achieved automatically. Either the test > > will > > examine package metadata for Conflicts to exclude the conflicting packages, > > or > > someone will have to maintain the good set of combinanations. > > Yes, I think those sets would need to be declared. The natural place > for this declaration would be in dist-git of the package. > This seems like overkill. Wouldn't the simplest valid installability test just be to test whether each subpackage *individually* could be installed? If we have 20 subpackages, just launch 20 separate minimal containers and see if `dnf install subpackageN` succeeds. Then it doesn't matter if there are conflicts; we know that at least installing that package directly will work. (Dependency resolution may pull in other subpackages of course, which is proving that it works properly.) -- ___ 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: Summary/Minutes from today's FESCo Meeting (2024-07-09)
On Fri, Jul 12, 2024 at 3:18 PM Kevin Fenzi wrote: > > On Fri, Jul 12, 2024 at 09:11:49AM GMT, Stephen Gallagher wrote: > > > > Well, one thing that we ALSO lost in the conversion to Matrix was that > > the minutes used to include links to the full text (in both text and > > HTML formats) on meetbot.fedoraproject.org > > In that case, the summary was enough to at least let people know 1) > > what was discussed and 2) if a decision was made. If they wanted more, > > a handy link was available to get the full logs. > > > > I have been trying to remember to manually add those links back when I > > chair, but I'm inconsistent (at best). > > If something is missing that was there before, please do file a RFE on > it. > > https://github.com/GregSutcliffe/maubot-meetings/issues > > or do you mean the web interface? > https://github.com/fedora-infra/mote > > Possibly https://github.com/fedora-infra/mote/issues/684 ? ^^ This is exactly what I'm referring to. -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Jul 11, 2024 at 3:24 PM Stephen Gallagher wrote: > > On Thu, Jul 11, 2024 at 8:01 AM wrote: > > > > Dear all, > > > > You are kindly invited to the meeting: > >ELN SIG on 2024-07-12 from 12:00:00 to 13:00:00 US/Eastern > >At fedora-meet...@irc.libera.chat > > > > The meeting will be about: > > > Converting away from ODCS for ELN composes. Summary provided by ChatGPT and reviewed by me. In the Fedora ELN meeting on July 12, 2024, several key topics were discussed: 1. **Init Process and Agenda**: - The meeting started with a brief introduction and setting of the agenda. Items included decommissioning ODCS and converting image-building away from ImageFactory. 2. **Decommissioning ODCS**: - Fedora ELN is the sole user of the On-Demand Compose Service (ODCS), which is being phased out upstream. Plans to migrate ELN to a new compose approach aligned with the rest of Fedora were discussed. A meeting with Fedora Releng was scheduled to finalize migration details. 3. **Replacing ELN Disk Image Creation**: - Discussion revolved around migrating from ImageFactory/Oz to Kiwi for building ELN Guest and Container images. Plans included attending a Kiwi workshop at Flock or DevConf.US to facilitate this transition. 4. **Open Floor**: - Various logistical issues regarding conference scheduling and technical details about the migration were addressed. The meeting concluded with approval to summarize discussions using an AI tool (ChatGPT). Overall, the meeting focused on transitioning ELN infrastructure away from outdated services and tools towards more sustainable solutions, with active engagement expected at upcoming Fedora events. Full meeting log is available at https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-12/eln.2024-07-12-16.00.log.html -- ___ 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: Summary/Minutes from today's FESCo Meeting (2024-07-09)
On Fri, Jul 12, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jul 11, 2024 at 01:46:04PM -0400, Josh Boyer wrote: > > I'm saying the thing they > > are doing today is not really valuable for a consumer base that wasn't > > in the meeting. If they want to make it better, AI is a tool that is > > actually pretty simple to use to do that without a ton of effort. If > > they don't want to make it better, then maybe just stop publishing the > > summary emails entirely and save themselves and others time. The > > meeting logs will still be there. > > Meh, that's throwing out the baby with the bathwater. > > The idea of the summary is very simple: > the text consists of a series of > > # ticket , do this and that > → resolution: APPROVED/REJECTED (+x, ±y, -z) > optionally: links or additional infos > > link to minutes > link to full log > > When this is implemented correctly, it is enough for the interested > parties to get a general idea of what happened in the meeting. > Sometimes we mess things up, but there is no reason why this summary > wouldn't be useful when done correctly. > > (The case that doesn't work well is when there is no clear decision > and we don't record anything. We should make it a habit to at least > record '!info We will return to this next week' to make the summary > more useful.) Well, one thing that we ALSO lost in the conversion to Matrix was that the minutes used to include links to the full text (in both text and HTML formats) on meetbot.fedoraproject.org In that case, the summary was enough to at least let people know 1) what was discussed and 2) if a decision was made. If they wanted more, a handy link was available to get the full logs. I have been trying to remember to manually add those links back when I chair, but I'm inconsistent (at best). -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Jul 11, 2024 at 8:01 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-07-12 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: Converting away from ODCS for ELN composes. -- ___ 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: Summary/Minutes from today's FESCo Meeting (2024-07-09)
I'm guessing Josh's response was an attempt to use AI to generate a summary. In the future, please label it as such, so people will read it with a critical eye. It has some flaws which I will address inline: On Wed, Jul 10, 2024 at 6:56 AM Josh Boyer wrote: > > On Tue, Jul 9, 2024 at 3:14 PM Josh Stone wrote: > > > > Text Log: > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.log.txt > > HTML Log: > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.log.html > > Text Minutes: > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.txt > > HTML Minutes: > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.html > > > > Meeting summary > > --- > > * TOPIC: Init Process (@jistone:fedora.im, 17:00:24) > > * TOPIC: #3231 Update exception request for rust-add-determinism > > (@jistone:fedora.im, 17:06:22) > > * AGREED: An update exception is explicitly granted to > > rust-add-determinism for Fedora <= 40, but not yet for 41+ (+8, 1, -0) > > (@jistone:fedora.im, 17:28:55) > > * TOPIC: #3232 Change: Mark Fedora KDE AArch64 as Release-Blocking > > (@jistone:fedora.im, 17:29:21) > > The discussion revolved around the proposal to designate Fedora KDE > AArch64 disk images as release-blocking for Fedora 41 and potentially > subsequent releases. Here are the key topics discussed and decisions > made: > > Proposal Context: The proposal was to elevate Fedora KDE AArch64 disk > images to release-blocking status starting from Fedora 41, with > concerns about the high failure rate of live ISO images. This is unintentionally conflating two different issues. The KDE team was originally proposing that BOTH live ISOs and disk images be blocking. Due to discussion prior to the meeting, they withdrew the live ISO proposal due to the failure rate. > > Failure Rate and Infrastructure: There was acknowledgment of a > significant failure rate (~50%) for live ISO images, prompting plans > to migrate to a more stable build system (Kiwi) for Fedora 42. > Additionally, discussions touched on exploring separate server > infrastructure due to funding and support limitations for automated > testing. This is tangential to the proposal on the table, but accurate. > QA and SIG Collaboration: Debate ensued over whether QA resources > could handle the additional testing workload, with a suggestion that > SIGs (Special Interest Groups) should contribute more actively to > testing and bug fixing. > > ARM SIG Input: There was a consensus that input from the ARM SIG was > crucial, given the impact on ARM platforms. Concerns were raised about > whether the ARM SIG had the necessary resources and whether they > should be involved in decisions regarding blocking status. "Consensus" is an overstatement. From my personal opinion, this was an attempt to delay making a decision, because there was no clear statement made about WHAT feedback, exactly, is needed from the ARM SIG. > Decision Making Process: The proposal faced some opposition due to > concerns about the practicality and cost-effectiveness of making > changes without adequate resources. Ultimately, a decision was > deferred pending further input from the ARM SIG. This is not exactly true. The opposition was due to the lack of current resources, with a debate over the chicken-and-egg problem of whether volunteers should expend their own money to provide hardware to perform release-blocking testing without the release-blocking status. Some FESCo members feel that the hardware needs to be satisfied before approving release-blocking status, whereas the KDE SIG does not feel like it should be expected to spend money until they know it will directly serve a purpose. > Future Steps: It was agreed to postpone the final decision, gather > input from the ARM SIG, and revisit the proposal in the next meeting > to ensure all stakeholders' concerns are adequately addressed. The conversation was going in circles and FESCo latched on "get info from the ARM SIG" as a way to end the current conversation so we could move on to the other topics. > In summary, while there was initial support for the proposal to > designate Fedora KDE AArch64 disk images as release-blocking, concerns > about testing resources, infrastructure limitations, and the need for > ARM SIG input led to a decision to delay the final vote and gather > more information before proceeding. That's an acceptable summary, I suppose. > > * TOPIC: #3233 Change: GIMP version 3 (@jistone:fedora.im, 18:00:57) > > * AGREED: FESCo would like to see the proposal reworked. We also > > require that GIMP v2 must not be present in Fedora 41+ due to python 2 > > removal. (+9, 0, -0) (@jistone:fedora.im, 18:06:27) > > * TOPIC: #3234 Change: Replace Nose with Pynose (@jistone:fedora.im, > > 18:07:15) > > * AGREED:
Re: PR for rebuild and autochangelog
On Tue, Jul 9, 2024 at 11:29 AM David Bold wrote: > > Sandro wrote: > > On 09-07-2024 17:01, David Bold wrote: > > > Is it possible to have a PR without any code changes? > > > Is there an alternative, recommended way to ask for rebuilds? > > Specifically in the case of %autorelease, you can bump the release with > > an empty commit: > > git commit --allow-empty -m 'Rebuild for ...' > > -- Sandro > > I have done that. I have also pushed to my fork. However, I cannot open a PR. > The button is greyed-out. I do not see any error, as to why it is not working. > > In this case it seems petsc has already been rebuild, so a rebuild is not > needed. However, I am still wondering how to open a PR in such a case? > > Specifically, I have done: > # add empty commit > git commit --allow-empty -m 'rebuild for openmpi' > # push to fork > git push davidsch rawhide > # visit website [0] > > And this is where I am stuck, I seem to be unable to open a PR. If I include > a change, I can open a PR [1] > > [0] > https://src.fedoraproject.org/fork/davidsch/rpms/petsc/diff/rawhide..rawhide > [1] > https://src.fedoraproject.org/fork/davidsch/rpms/petsc/diff/rawhide..do-not-merge Well, Pagure appears to be down at the moment, but to work around this, you can have the maintainer or a provenpackager do a bump-and-build for you at the moment. This is definitely a shortcoming in Pagure, though. -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Jun 27, 2024 at 9:17 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-06-28 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > Due to a lack of agenda topics, today's meeting is CANCELED -- ___ 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: 2FA policy for provenpackagers is now active
On Tue, Jun 25, 2024 at 10:32 AM Vitaly Zaitsev via devel wrote: > > On 25/06/2024 15:06, Stephen Gallagher wrote: > > I am not a lawyer, but I would assume that if Fedora offered to > > provide such a token, it would be reviewed by Legal and provide some > > form of legally-binding assertion that we weren't sending out > > malicious devices. > > Who can guarantee that these devices were not replaced during delivery? > > > In that situation, the > > provenpackagers would be making a three way decision: 1) Stop being a > > provenpackager, 2) buy their own token or 3) accept one provided by > > Fedora. > > 4. Allow classic OTP codes. > > I would prefer this one since I can use open source applications to > generate these codes. I can't find any FIDO2 implementations that are > completely open source which doesn't require proprietary technologies > like TPM or SGX. Relying on a black box is not an option for me. > No one said otherwise. This hypothetical started from "what if we required physical tokens?", so I was noting the possibilities under that restriction. -- ___ 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: 2FA policy for provenpackagers is now active
On Tue, Jun 25, 2024 at 4:48 AM Vitaly Zaitsev via devel wrote: > > On 24/06/2024 23:38, Gary Buhrmaster wrote: > > As I recall from a previous query, there are > > (around) 90 active proven packagers (and > > ~250 total who were in the PP group). > > I think most privacy/security focused developers/maintainers won't plug > USB tokens they get from random people on the Internet into their > PC/laptop because it could be a BadUSB or something even worse. > > The most common attack is when an attacker plants USB devices near the > office of the company they want to attack. Connecting such devices is > completely NO-GO. There's a certain amount of trust required in accepting a USB key from *anyone* (even if you were to order one directly from Yubico, RSA, Adafruit, etc.). If we move to requiring tokens, I think it's entirely certain that we would allow anyone to provide their own that we enroll. I assume that Matthew's offer was for us to be able to help those who (for one reason or another) cannot afford one. In that situation, the provenpackagers would be making a three way decision: 1) Stop being a provenpackager, 2) buy their own token or 3) accept one provided by Fedora. I am not a lawyer, but I would assume that if Fedora offered to provide such a token, it would be reviewed by Legal and provide some form of legally-binding assertion that we weren't sending out malicious devices. -- ___ 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: 2FA policy for provenpackagers is now active
On Mon, Jun 24, 2024 at 1:30 PM Miro Hrončok wrote: > > On 24. 06. 24 19:13, Kevin Fenzi wrote: > > tickets are valid for 24hours and can be renewed for 1 week. (Either via > > gnome online accounts or just 'kinit -R') > > How do I do that? > > $ fkinit > ... all good ... > > later: > > $ klist > Ticket cache: KCM:1000:. > Default principal: churchy...@fedoraproject.org > > Valid starting Expires Service principal > 24.6.2024 15:42:35 25.6.2024 15:42:21 > krbtgt/fedoraproject@fedoraproject.org > 24.6.2024 15:42:41 25.6.2024 15:42:21 > HTTP/koji.fedoraproject@fedoraproject.org > > > $ kinit -R > kinit: KDC can't fulfill requested option while renewing credentials > > $ kinit -R churchy...@fedoraproject.org > kinit: KDC can't fulfill requested option while renewing credentials > Seems like a bug on your end; I just tested it on my end and it worked just fine. Maybe your kerberos configuration is out of date? It's changed a few times over the years and if you ever made any manual edits, they may be overriding newer RPM content. -- ___ 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: 2FA policy for provenpackagers is now active
On Mon, Jun 24, 2024 at 1:30 PM Daniel P. Berrangé wrote: > > On Mon, Jun 24, 2024 at 05:11:07PM +, Mattia Verga via devel wrote: > > > > Messaggio originale > > 24/06/24 18:21, Kevin Fenzi ha scritto: > > > > > > > > I personally don't see why entering a otp once a week is such a > > > burden... but it does seem to be. ;( > > > > > > > Once a week? When I get a kerberos ticket with fkinit it expires > > after 24h. Is there a setting to change somewhere to make it last > > a week? > > Tickets expire after 24 hours, but before expiry, it is possible > to request renewal eg > > kinit @FEDORAPROJECT.ORG -R > > this renewable won't prompt for credentials. IIUC, it basically just > validates that your krb account hasn't been disabled by the server > admin. > > klist will tell you the upper limit on renewals before you must > fully re-authenticate, and in Fedora it appears to be 7 days. > > Note, you *MUST* renew it before it expires, as you can't renew an > expired ticket, even if it were still within the renewal lifetime. > > Incidentally there's not particularly any need to use fkinit, as > it is just a thin wrapper around kinit. It avoids the need to type > the "@FEDORAPROJECT.ORG" part of your krb account, and for some > reason forces use of the "FILE" credential cache, overriding the > system default. The latter feels dubious to me but perhaps there's > some good reason for it ? > It's required if you are using 2FA because it handles the fact that you need to do TWO kinit actions, one to set up the anonymous pre-authentication channel and another to actually send the credentials. I wrote fkinit to abstract those details for Fedora users since it's subtle and easy to get wrong. Also, it doesn't use the FILE credential cache for the final credentials, it uses whatever your system default is. It only uses FILE: to set up the preauthentication channel. -- ___ 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: 2FA policy for provenpackagers is now active
On Mon, Jun 24, 2024 at 1:11 PM Mattia Verga via devel wrote: > > > Messaggio originale > 24/06/24 18:21, Kevin Fenzi ha scritto: > > > > > I personally don't see why entering a otp once a week is such a > > burden... but it does seem to be. ;( > > > > Once a week? When I get a kerberos ticket with fkinit it expires after 24h. > Is there a setting to change somewhere to make it last a week? You get a TGT that is valid for 24 hours but can be used to renew (get a new TGT by using the old one) for up to a week. You just need to do the equivalent of `kinit -R` which GNOME's tool can be configured to do for you. -- ___ 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: 2FA policy for provenpackagers is now active
On Mon, Jun 24, 2024 at 12:54 PM Leigh Scott wrote: > > > > I personally don't see why entering a otp once a week is such a > > burden... but it does seem to be. ;( > > > > kevin > > It isn't just once. > > 1. kerberos > 2. Web login on infra, bugzilla, bodhi, devel list and accounts Not really an issue if you have GSSAPI set up on your system. Such as by installing fedora-chromium-config-gssapi (for Chrome/Chromium users) or by using Firefox which is set up for GSSAPI out-of-the-box. > > If you do nightly shutdown you would need to enter it many times per week. Not if you're using the Kerberos Credential Manager (KCM) for Kerberos (the default on Fedora for at least several years). -- ___ 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: [Node.js] Stepping down as Node.js Maintainer in Fedora
On Mon, Jun 24, 2024 at 10:40 AM Stephen Gallagher wrote: > > On Mon, Jun 24, 2024 at 4:07 AM Jan Staněk wrote: > > > > Hi Stephen! > > > > Stephen Gallagher writes: > > > Just a reminder that I will be orphaning the nodejsXX packages in a > > > little over a week. As of yet, no one has requested access to take it > > > over. If anyone is going to do so, I encourage you to do it soon if > > > you would like my help coming up to speed. > > > > Unless any brave hero appears from the weeds, I'll be taking them. > > Right now I see no way on Pagure to request ownership/co-maintenance > > (maybe I'm just blind). Anyway, feel free to add me to maintainers > > and/or transfer the ownership. > > I've added you as "admin" to nodejs18, nodejs20, nodejs22 and > nodejs-packaging. > I also went ahead and gave you "main admin" for those packages. Thank you for taking over. > > > As for getting up to speed, unless you've added anything new in the last > > month or so, I think I'm good. > > Just the hacks I threw in to bundle the wasm stuff again, since that > still needs to be sorted out for the default and non-default major > versions. -- ___ 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: [Node.js] Stepping down as Node.js Maintainer in Fedora
On Mon, Jun 24, 2024 at 4:07 AM Jan Staněk wrote: > > Hi Stephen! > > Stephen Gallagher writes: > > Just a reminder that I will be orphaning the nodejsXX packages in a > > little over a week. As of yet, no one has requested access to take it > > over. If anyone is going to do so, I encourage you to do it soon if > > you would like my help coming up to speed. > > Unless any brave hero appears from the weeds, I'll be taking them. > Right now I see no way on Pagure to request ownership/co-maintenance > (maybe I'm just blind). Anyway, feel free to add me to maintainers > and/or transfer the ownership. I've added you as "admin" to nodejs18, nodejs20, nodejs22 and nodejs-packaging. > As for getting up to speed, unless you've added anything new in the last > month or so, I think I'm good. Just the hacks I threw in to bundle the wasm stuff again, since that still needs to be sorted out for the default and non-default major versions. -- ___ 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: 2FA policy for provenpackagers is now active
On Mon, Jun 24, 2024 at 9:28 AM Michael J Gruber wrote: > > Guinevere Larsen venit, vidit, dixit 2024-06-24 13:53:37: > > On 6/24/24 5:08 AM, Miroslav Suchý wrote: > > > Dne 24. 06. 24 v 9:48 dop. Mattia Verga via devel napsal(a): > > >> IMO, having the token stored in your password manager means going > > >> from 2FA to 1FA effectively ;-) if someone gets access to your > > >> password manager vault, all accounts will be compromised. > > > > > > Only if you use the same password manager for both: password and OTP. > > > > > It still makes it 1FA. If all you need to get the OTP is know which > > password managers the user uses, and what is the password for that > > passowrd manager, OTP goes from being a "something you have" type of > > authentication factor, to a "something you know" authentication factor, > > which is the same factor as the password. Multi factor authentication is > > not about steps, is about what you need to complete the authentication > > challenge (something you know, something you have, or something you are). > > Sure, and the "something you have" is access to the OTP device which in > this case is the (token stored in the ) password manager's database. > > The password or passphrase which unlocks the password manager is nothing > which you could provide as a "factor". > > Or else, all cloneable OTP apps would need to be disallowed as 2nd > factors, and only physical tokens should count. Also, why does everyone seem to assume that a password manager isn't ITSELF protected by 2FA? For my lower-concern sites, I am just fine with keeping the TOTP code in the manager because the manager itself is protected by a strong password and a physical FIDO device (Yubikey). Remember that security is a spectrum, not an end-state. Every person and environment makes a choice between how much security and how much convenience is appropriate. If you want perfect security, you can unplug your PC, fill it with concrete and drop it into the Marianas Trench. Otherwise, you make some compromises... -- ___ 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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Thu, Jun 20, 2024 at 11:52 AM Chris Adams wrote: > > Once upon a time, Stephen Gallagher said: > > three) and recommend creation of a Fedora "Hardware Life Extension" > > Remix that can provide rebuilds of (a subset of) Fedora that they want > > to run on ancient hardware. > > TBH I feel that approach would be doomed to the same failure as the > attempts to extend Fedora life-cycles. There's enough people that would > want it, but not necessarily the critical mass needed to do the work to > make it happen. That's kind of my point. If people want something, but aren't willing to put any effort into it, why do they expect that the rest of the Fedora community will do it for them? -- ___ 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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Thu, Jun 20, 2024 at 10:49 AM Daniel P. Berrangé wrote: > > On Thu, Jun 20, 2024 at 03:24:18PM +0100, Tom Hughes via devel wrote: > > On 20/06/2024 15:03, Stephen Gallagher wrote: > > > > > Honestly, I'd like to pitch that we retarget Fedora at x86_64-v3 (yes, > > > three) and recommend creation of a Fedora "Hardware Life Extension" > > > Remix that can provide rebuilds of (a subset of) Fedora that they want > > > to run on ancient hardware. It could be something similar to Fedora > > > ELN, where a subset of the main repo that might be useful on old > > > hardware can be rebuilt (though unlike ELN, I suggest that this should > > > be an entirely separate infrastructure not maintained by the Fedora > > > Project). Such a project could then live or die based on willingness > > > to maintain it and stop holding back Fedora as a whole. > > > > I definitely think going to v2 would be reasonable bit I tink > > forcing v3 might be a step too far. > > If going to v3, compared v2 > > For AMD, we would loose Opteron Gen4 and Opteron Gen5 models, but > keep EPYC/Ryzen all generations. > > For Intel, we would loose Denverton, IvyBridge, Nehalem, > SandyBridge, Snowridge, Westmere, but keep Skylake, > SapphireRapids, Icelake, Haswell, GraniteRapids, Cooperlake, > Cascadelake, Broadwell. > > > Personally I'd say v2 is the better first step, as plenty of > those generations we'd loose are still pretty relevant, even > if not the state of the art shipping today. > OK, I think I got my baselines mixed up. Sorry about that. I could have sworn what you were describing above was the effect of moving to -v4. -- ___ 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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Thu, Jun 20, 2024 at 8:49 AM Chris Adams wrote: > > Once upon a time, Stephen Smoogen said: > > I don't think Peter meant additional packages since with the i686 it > > didn't mean that. What it did mean was having to understand why two > > architectures might do things differently and why bugs might show up > > in one but not another. > > In the i686 days, that was essentially THE second architecture for the > bulk of packagers. Now we have Fedora on multiple really separate > architectures, I don't feel the difference between x86_64-v1 and -v2 is > such a big deal (as compared to x86_64 vs. aarch64 for example). > > I'm not saying there's not a potential for issues exclusive to one > x86_64 level, but it seems like a small area in comparison. > > I think this needs to be decided for Fedora as soon as practical; while > it'd be nice to keep the baseline at -v1 (I'd still like to see some > more concrete "these CPU models are -v1" list), I also would prefer > optimum performance e.g. from my VMs (and everything I have is at least > -v2, most are -v3, and one is -v4). Even just bumping the baseline to > -v2 won't enable some useful things like AVX2, so I think it makes sense > to look more at enabling a multi-level approach (e.g. like the i386/i686 > days with targeted packages built for multiple). > Honestly, I'd like to pitch that we retarget Fedora at x86_64-v3 (yes, three) and recommend creation of a Fedora "Hardware Life Extension" Remix that can provide rebuilds of (a subset of) Fedora that they want to run on ancient hardware. It could be something similar to Fedora ELN, where a subset of the main repo that might be useful on old hardware can be rebuilt (though unlike ELN, I suggest that this should be an entirely separate infrastructure not maintained by the Fedora Project). Such a project could then live or die based on willingness to maintain it and stop holding back Fedora as a whole. -- ___ 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: [Node.js] Stepping down as Node.js Maintainer in Fedora
On Wed, May 29, 2024 at 11:32 AM Stephen Gallagher wrote: > > tl;dr: I'll be stepping down from maintaining the nodejs22, nodejs20 > and nodejs16 packages in Fedora, effective June 30, 2024. I will > continue to maintain libuv. > Just a reminder that I will be orphaning the nodejsXX packages in a little over a week. As of yet, no one has requested access to take it over. If anyone is going to do so, I encourage you to do it soon if you would like my help coming up to speed. -- ___ 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: Schedule for Monday's FESCo Meeting (2024-06-17)
On Tue, Jun 18, 2024 at 1:51 PM Josh Boyer wrote: > > On Tue, Jun 18, 2024 at 8:25 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Jun 18, 2024 at 03:20:07PM +0300, Otto Liljalaakso wrote: > > > Stephen Gallagher kirjoitti 17.6.2024 klo 23.07: > > > > = > > > > # #meeting:fedoraproject.org: fesco > > > > = > > > > > > > > Meeting started by @sgallagh:fedora.im at 2024-06-17 19:00:05 > > > > > > > > Meeting summary > > > > --- > > > > * TOPIC: Init Process (@sgallagh:fedora.im, 19:00:31) > > > > * TOPIC: #3222 Change: Make Tuned the Default Power Profile > > > > Management Daemon (@sgallagh:fedora.im, 19:12:35) > > > > * TOPIC: Next week's chair (@sgallagh:fedora.im, 19:50:59) > > > > * ACTION: zbyszek to chair the next meeting (@sgallagh:fedora.im, > > > > 19:53:23) > > > > * TOPIC: Open Floor (@sgallagh:fedora.im, 19:53:30) > > > > * ACTION: @sgallagh to submit a Change to migrate Fedora ELN away > > > > from ODCS (@sgallagh:fedora.im, 20:04:29) > > > > > > > > Meeting ended at 2024-06-17 20:06:17 > > > > > > > > On Mon, Jun 17, 2024 at 8:21 AM Stephen Gallagher > > > > wrote: > > > > > = New business = > > > > > > > > > > #3222 Change: Make Tuned the Default Power Profile Management Daemon > > > > > https://pagure.io/fesco/issue/3222 > > > > > > This creates the impression that you did not decide anything regarding > > > #3222. Checking from logs, I see that that is not the case: > > > > > > > #agreed FESCo approves the Change to use tuned as the default > > > power-management tool for desktop installs. P-P-D remains in the > > > distribution as an alternative that can be manually installed. (+7, 0, -1) > > > > > > Is the meetbot somehow broken, or was that just wrong syntax or something? > > We forgot to say '!agreed …'. That's my fault. I've been on FESCo for too many years and my fingers instinctually still type the old IRC syntax instead of the new Matrix syntax. > I would love for someone to tweak zodbot to use generative AI to > actually make it useful. It served us well for a very long time, but > the published summaries aren't useful for those just wanting to follow > along and the need to remember what was agreed on with implicit > commands is cumbersome. It wouldn't be that hard to just pipe the > logs through an LLM to produce a much better summary and auto-generate > the agreements and decisions. A human would need to review before > sending it out, but I think end consumers would benefit much more. > > josh > -- > ___ > 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: Schedule for Monday's FESCo Meeting (2024-06-17)
= # #meeting:fedoraproject.org: fesco = Meeting started by @sgallagh:fedora.im at 2024-06-17 19:00:05 Meeting summary --- * TOPIC: Init Process (@sgallagh:fedora.im, 19:00:31) * TOPIC: #3222 Change: Make Tuned the Default Power Profile Management Daemon (@sgallagh:fedora.im, 19:12:35) * TOPIC: Next week's chair (@sgallagh:fedora.im, 19:50:59) * ACTION: zbyszek to chair the next meeting (@sgallagh:fedora.im, 19:53:23) * TOPIC: Open Floor (@sgallagh:fedora.im, 19:53:30) * ACTION: @sgallagh to submit a Change to migrate Fedora ELN away from ODCS (@sgallagh:fedora.im, 20:04:29) Meeting ended at 2024-06-17 20:06:17 Action items * zbyszek to chair the next meeting * @sgallagh to submit a Change to migrate Fedora ELN away from ODCS People Present (lines said) --- * @sgallagh:fedora.im (76) * @conan_kudo:matrix.org (71) * @zbyszek:fedora.im (38) * @nirik:matrix.scrye.com (25) * @salimma:fedora.im (24) * @zodbot:fedora.im (12) * @decathorpe:fedora.im (11) * @humaton:fedora.im (4) * @meetbot:fedora.im (3) * @blackwell:fedora.im (1) * @jsteffan:fedora.im (1) Full meeting notes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-17/fesco.2024-06-17-19.00.log.html On Mon, Jun 17, 2024 at 8:21 AM Stephen Gallagher wrote: > > Following is the list of topics that will be discussed in the > FESCo meeting Monday at 19:00 UTC in #meeting:fedoraproject.org > on Matrix. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/UTCHowto > > or run: > date -d '2024-06-17 19:00 UTC' > > Links to all issues to be discussed can be found at: > https://pagure.io/fesco/report/meeting_agenda > > = Discussed and Voted in the Ticket = > > Change: Multiple Versioned CRI-O and CRI-Tools Packages > https://pagure.io/fesco/issue/3218 > APPROVED (+6, 0, 0) > > Change: IBus Chewing for Traditional Chinese (Taiwan) Desktop by Default > https://pagure.io/fesco/issue/3217 > APPROVED (+6, 0, 0) > > Change: DNF and bootc in Image Mode Fedora variants > https://pagure.io/fesco/issue/3216 > APPROVED (+5, 0, 0) > > > = Followups = > > > = New business = > > #3222 Change: Make Tuned the Default Power Profile Management Daemon > https://pagure.io/fesco/issue/3222 > > = Open Floor = > > For more complete details, please visit each individual > issue. The report of the agenda items can be found at > https://pagure.io/fesco/report/meeting_agenda > > If you would like to add something to this agenda, you can > reply to this e-mail, file a new issue at > https://pagure.io/fesco, e-mail me directly, or bring it > up at the end of the meeting, during the open floor topic. Note > that added topics may be deferred until the following meeting. -- ___ 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
Schedule for Monday's FESCo Meeting (2024-06-17)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-06-17 19:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Change: Multiple Versioned CRI-O and CRI-Tools Packages https://pagure.io/fesco/issue/3218 APPROVED (+6, 0, 0) Change: IBus Chewing for Traditional Chinese (Taiwan) Desktop by Default https://pagure.io/fesco/issue/3217 APPROVED (+6, 0, 0) Change: DNF and bootc in Image Mode Fedora variants https://pagure.io/fesco/issue/3216 APPROVED (+5, 0, 0) = Followups = = New business = #3222 Change: Make Tuned the Default Power Profile Management Daemon https://pagure.io/fesco/issue/3222 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ 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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Wed, Jun 12, 2024 at 10:07 AM Daniel P. Berrangé wrote: > > On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote: > > On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé > > wrote: > > > > > > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote: > > > > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé > > > > wrote: > > > > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, > > > > > users > > > > > with older x86_64 hardware would likely be unable to run QEMU, from > > > > > F41 > > > > > onwards, unless some TBD action is taken. > > > > > > > > > > Thus I'm wondering whether Fedora has any policy or guidance on > > > > > handling > > > > > such a situation both in general, and more specifically for "critical > > > > > path" > > > > > packages, if that difference is relevant ? The packaging guidelines > > > > > aren't > > > > > especially explicit about this situation, unless I've missed something > > > > > beyond the "compiler flags" and "architecture support" sections. > > > > > > > > > > > > > Absent a project-wide decision to move to the newer baseline, I think > > > > the best approach we can take would be to find some way to communicate > > > > to the user that the software isn't usable. In the case of Qemu, does > > > > the application report an error or crash if it's run on hardware > > > > without the requisite baseline? > > > > > > I've not tested, but I would expect it to crash attempting to execute an > > > illegal instruction > > > > > > > OK, that's a situation that will lead to annoying and unresolvable bug > > reports. Would it be possible to put something in place that would > > check processor capabilities early in execution before hitting any of > > the affected instructions? > > Not trivial as a bunch of code executes from ELF constructors before > main() starts. > Wrapper application that just does feature tests and then fork/exec()'s the real application? -- ___ 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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé wrote: > > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote: > > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé > > wrote: > > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users > > > with older x86_64 hardware would likely be unable to run QEMU, from F41 > > > onwards, unless some TBD action is taken. > > > > > > Thus I'm wondering whether Fedora has any policy or guidance on handling > > > such a situation both in general, and more specifically for "critical > > > path" > > > packages, if that difference is relevant ? The packaging guidelines aren't > > > especially explicit about this situation, unless I've missed something > > > beyond the "compiler flags" and "architecture support" sections. > > > > > > > Absent a project-wide decision to move to the newer baseline, I think > > the best approach we can take would be to find some way to communicate > > to the user that the software isn't usable. In the case of Qemu, does > > the application report an error or crash if it's run on hardware > > without the requisite baseline? > > I've not tested, but I would expect it to crash attempting to execute an > illegal instruction > OK, that's a situation that will lead to annoying and unresolvable bug reports. Would it be possible to put something in place that would check processor capabilities early in execution before hitting any of the affected instructions? -- ___ 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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé wrote: > > There have been various change proposals & associated mailing list threads > over the years about the possibility of moving Fedora compiler toolchain > to build with a newer x86_64 baseline ABI, which have ended up rejected, > with some quite strong negative feedback. > > Regardless of the Fedora general policy, however, individual packages may > have forced a particular x86_64 baseline ABI through their own CFLAGS > defined by the upstream project. > > The context is that QEMU has recently merged changes upstream that force > use of the x86-64-v2 baseline for QEMU, in order get more efficient code > in the TCG emulator. The changes were made in QEMU's global CFLAGS so this > will affect all usage of QEMU, whether KVM, or TCG, for both VMs and user > space emulation (the latter used by podman for non-native containers) > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users > with older x86_64 hardware would likely be unable to run QEMU, from F41 > onwards, unless some TBD action is taken. > > Thus I'm wondering whether Fedora has any policy or guidance on handling > such a situation both in general, and more specifically for "critical path" > packages, if that difference is relevant ? The packaging guidelines aren't > especially explicit about this situation, unless I've missed something > beyond the "compiler flags" and "architecture support" sections. > Absent a project-wide decision to move to the newer baseline, I think the best approach we can take would be to find some way to communicate to the user that the software isn't usable. In the case of Qemu, does the application report an error or crash if it's run on hardware without the requisite baseline? -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Fri, May 31, 2024 at 1:22 PM Fabio Valentini wrote: > > On Fri, May 31, 2024 at 7:15 PM Stephen Gallagher wrote: > > > > Looking forward to EPEL 10! More work for me, yay! > Just a few questions - I would have looked them up in the meeting log, > but it's not linked. > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-31/eln.2024-05-31-16.01.txt I'm not sure why that wasn't part of the "minutes" output. Probably worth looking into... > > * AGREED: All packages currently included in ELN Extras will have > > an EPEL 10 branch created for them (@sgallagh:fedora.im, 16:28:51) > > Is there a list of these packages available somewhere? > https://tiny.distro.builders/view--view-eln-extras.html > > * AGREED: We will mass-create empty branches for EPEL 10 and will > > work towards a better solution for EPEL 11 (@sgallagh:fedora.im, > > 16:51:54) > > I hope you will not create epel10 branches for *all* packages in Fedora. > Which packages *will* get an epel10 branch auto-created? > This was the result of a discussion as to whether we should pre-populate the branch contents. We settled on creating them as empty. It's the same list as above. > > * INFO: Investigation topic: Drop ELN Extras in favor of starting > > EPEL 11 soon after EPEL 10, backed by ELN until branching. > > (@sgallagh:fedora.im, 16:56:06) > > This sounds great! ELN Extras has always been confusing to me. > The idea behind ELN Extras was to get an early preview of stuff that people want in the next EPEL release. During the discussion today, we decided that it might be easier to essentially just create EPEL N+1 earlier and take advantage of the ELN tooling and tagging. I'm going to work up a proposal over the next week or so and send it out for discussion. -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, May 30, 2024 at 2:10 PM Stephen Gallagher wrote: > > On Thu, May 30, 2024 at 8:02 AM wrote: > > > > Dear all, > > > > You are kindly invited to the meeting: > >ELN SIG on 2024-05-31 from 12:00:00 to 13:00:00 US/Eastern > >At fedora-meet...@irc.libera.chat > > > > The meeting will be about: > > > Planning for EPEL 10, derived from ELN Extras. = # #meeting:fedoraproject.org: eln = Meeting started by @sgallagh:fedora.im at 2024-05-31 16:01:03 Meeting summary --- * TOPIC: Init Process (@sgallagh:fedora.im, 16:01:17) * TOPIC: Creating EPEL 10 from ELN Extras (@sgallagh:fedora.im, 16:04:03) * LINK: https://red.ht/epel10 (@carlwgeorge:matrix.org, 16:04:23) * LINK: https://hackmd.io/@carlwgeorge/S1r2tzZsp (@carlwgeorge:matrix.org, 16:05:19) * LINK: https://github.com/fedora-eln/eln/issues/187 (@sgallagh:fedora.im, 16:06:35) * INFO: The ELN Extras sub-project was created to be an analog for the relationship to EPEL in the same way that ELN itself was created to be an analog for the relationship to RHEL (@sgallagh:fedora.im, 16:10:31) * AGREED: All packages currently included in ELN Extras will have an EPEL 10 branch created for them (@sgallagh:fedora.im, 16:28:51) * AGREED: We will mass-create empty branches for EPEL 10 and will work towards a better solution for EPEL 11 (@sgallagh:fedora.im, 16:51:54) * INFO: Investigation topic: Drop ELN Extras in favor of starting EPEL 11 soon after EPEL 10, backed by ELN until branching. (@sgallagh:fedora.im, 16:56:06) * ACTION: sgallagh to create a first-draft proposal for EPEL 11 to replace ELN Extras. (@sgallagh:fedora.im, 17:05:37) Meeting ended at 2024-05-31 17:07:50 Action items * sgallagh to create a first-draft proposal for EPEL 11 to replace ELN Extras. People Present (lines said) --- * @sgallagh:fedora.im (89) * @carlwgeorge:matrix.org (38) * @conan_kudo:matrix.org (23) * @tdawson:fedora.im (22) * @yselkowitz:fedora.im (17) * @davide:cavalca.name (12) * @zodbot:fedora.im (8) * @nhanlon:beeper.com (6) * @meetbot:fedora.im (3) -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, May 30, 2024 at 8:02 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-05-31 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: Planning for EPEL 10, derived from ELN Extras. > > Source: https://calendar.fedoraproject.org//meeting/10568/ > > -- > ___ > 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
[Node.js] Stepping down as Node.js Maintainer in Fedora
tl;dr: I'll be stepping down from maintaining the nodejs22, nodejs20 and nodejs16 packages in Fedora, effective June 30, 2024. I will continue to maintain libuv. It's been a hard decision to come to, but I think this is the correct decision for me. I've been effectively the sole maintainer of Node.js in Fedora for nearly a dozen years now (apparently, I landed the first official package in Fedora on Dec. 18, 2012). It has been a long, long road. I first picked up Node.js because it was being added as a new dependency on a package I maintained at the time: Review Board (a Django-base code-review application). When I looked into it, I discovered that others had tried - and failed - to package Node.js previously, but Fedora's rules at the time were *very* strict with regards to carrying bundled software and Node.js upstream at the time had a build-system that pretty much only allowed bundling. It took quite a bit of effort to work through that, but we got there in the end and I was able to deliver Node.js 0.8 as the very first version to ship as part of Fedora. It's been a wild ride ever since. For a long time, Fedora carried a single version of Node.js - whatever was the latest version destined for LTS status at the time that Fedora version would be released. Then, along came... Modularity. As you may know, I was heavily involved with the design of Modularity. Node.js in particular was something I viewed as a perfect consumer of this new packaging mechanism: it gave us the ability to ship all versions of Node.js in Fedora (not just the LTS ones) in a way that could be packaged in VMs and (new at the time) container images without needing to modify the way the applications were launched. Sadly, as you probably know, the implementation of Modularity fell short of its lofty goals and has largely been relegated to the dust-bin of history. When it became clear that Modules were going to be dropped from Fedora, I took on another big packaging exercise: DE-modularizing Node.js. Rather than go back to the "single Node.js version in Fedora" approach, I moved to a hybrid approach where we would have a single "system" version of Node.js LTS like in the older style, but we would also package the older (and newer!) LTS releases in a non-default arrangement, similar to how Python packages are delivered in Fedora. I've been doing it this way for a few years now, and while there have been some bumps in the road around major-release upgrades, it's been overall quite workable. Recently, the Node.js downstream maintainers made some additional improvements in Node.js 20 to unbundle some previously-precompiled WASM code into their own packages which build it properly. This is great! Unfortunately, it has introduced some new issues with the non-default version in the release (as many of you probably saw last week). We sorted this out by temporarily re-bundling the WASM in the non-default versions, but this is really a stop-gap solution. It's not a huge issue, but it took a big chunk out of my week to get that resolved and in doing it, I came to an important realization: I'm burnt out. I took a moment to think through it and realized that I don't actually *use* Node.js anywhere anymore. I've been maintaining it for so long that it's become a habit, but I'm not a real consumer of it. I've sent requests in the past to fedora-devel asking for comaintainers, but I've never actually had anyone step up, so I've just kept going. So that brings us to today and my decision to step down. It's been a wild ride, but I need to step away and focus on other things. I hope someone out there will pop up and take over for me. I'm perfectly happy to train someone on how I maintain the various versions, but my time as a maintainer is coming to an end. I'll keep things going for another month, but after that it becomes Someone Else's Problem. If you read this far, thanks for suffering through that rambling journey. -- ___ 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: Node.js 22.x coming to Rawhide/F41
tl;dr I screwed up and accidentally made two critical mistakes:
1) Node.js 22 got into Rawhide as the default early. I'm not sure of
how to back that out safely.
2) A change made in Node.js 20 to split out two libraries
(cjs-module-lexer and undici) that we were bundling in prior releases
has introduced issues with Node.js 22 because it can't find them (and
the ones from Node.js 20 are older). I'll probably re-bundle them in
the short term to unbreak things.
On Tue, May 21, 2024 at 8:55 AM Sérgio Basto wrote:
>
> Hi,
> Since the thread is in top posting, I will top posting too ...
>
> I also saw a "Native stack trace" [1] on Rawhide on nodejs-electron [2]
>
> Best regards,
>
> [2]
> https://copr.fedorainfracloud.org/coprs/sergiomb/electrons/build/7462286/
>
> [1]
> [432/39358] python3 ../../tools/polymer/html_to_wrapper.py --in_folder
> gen/components/flags_ui/resources/preprocessed --out_folder
> gen/components/flags_ui/resources/preprocessed --in_files
> experiment.html app.html --template native --minify
> FAILED:
> gen/components/flags_ui/resources/preprocessed/experiment.html.ts
> gen/components/flags_ui/resources/preprocessed/app.html.ts
> python3 ../../tools/polymer/html_to_wrapper.py --in_folder
> gen/components/flags_ui/resources/preprocessed --out_folder
> gen/components/flags_ui/resources/preprocessed --in_files
> experiment.html app.html --template native --minify
> Traceback (most recent call last):
> File
> "/builddir/build/BUILD/src/out/Release/../../tools/polymer/html_to_wrap
> per.py", line 242, in
> main(sys.argv[1:])
> File
> "/builddir/build/BUILD/src/out/Release/../../tools/polymer/html_to_wrap
> per.py", line 175, in main
> raise err
> File
> "/builddir/build/BUILD/src/out/Release/../../tools/polymer/html_to_wrap
> per.py", line 170, in main
> node.RunNode(
> File "/builddir/build/BUILD/src/third_party/node/node.py", line 34,
> in RunNode
> raise RuntimeError('Command \'%s\' failed\n%s' % (' '.join(cmd),
> err))
> RuntimeError: Command
> '/builddir/build/BUILD/src/third_party/node/linux/node-linux-
> x64/bin/node
> /builddir/build/BUILD/src/out/Release/../../tools/polymer/html_minifier
> .js
> /builddir/build/BUILD/src/out/Release/gen/components/flags_ui/resources
> /preprocessed
> /builddir/build/BUILD/src/out/Release/gen/components/flags_ui/resources
> /preprocessed/tmpf1m6ift1 experiment.html app.html' failed
> Cannot load externalized builtin: "internal/deps/cjs-module-
> lexer/lexer:/usr/lib/node_modules/cjs-module-lexer/lexer.js".
> - Native stack trace -
>
> 1: 0x7f16cd92a585
> node::builtins::BuiltinLoader::AddExternalizedBuiltin(char const*, char
> const*) [/lib64/libnode.so.127]
> 2: 0x7f16cd92a763 node::builtins::BuiltinLoader::BuiltinLoader()
> [/lib64/libnode.so.127]
> 3: 0x7f16cd88ee61 node::InitializePrimordials(v8::Local)
> [/lib64/libnode.so.127]
> 4: 0x7f16cd88efa0 node::GetPerContextExports(v8::Local)
> [/lib64/libnode.so.127]
> 5: 0x7f16cd88ed68 node::InitializePrimordials(v8::Local)
> [/lib64/libnode.so.127]
> 6: 0x7f16cd88f080
> node::InitializeMainContextForSnapshot(v8::Local)
> [/lib64/libnode.so.127]
> 7: 0x7f16cd88f0a5 node::InitializeContext(v8::Local)
> [/lib64/libnode.so.127]
> 8: 0x7f16cd88f109 node::NewContext(v8::Isolate*,
> v8::Local) [/lib64/libnode.so.127]
> 9: 0x7f16cd9aa564
> node::NodeMainInstance::CreateMainEnvironment(node::ExitCode*)
> [/lib64/libnode.so.127]
> 10: 0x7f16cd9aa6bb node::NodeMainInstance::Run()
> [/lib64/libnode.so.127]
> 11: 0x7f16cd90d85f node::Start(int, char**) [/lib64/libnode.so.127]
> 12: 0x7f16ccbb81c8 [/lib64/libc.so.6]
> 13: 0x7f16ccbb828b __libc_start_main [/lib64/libc.so.6]
> 14: 0x55af7f18a035 _start
> [/builddir/build/BUILD/src/third_party/node/linux/node-linux-
> x64/bin/node]
>
>
>
> On Tue, 2024-05-21 at 11:26 +0200, Sandro Mani wrote:
> > I also get a crash when running npm install:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2282103
> >
> > Sandro
> >
> > On 21.05.24 09:57, Vít Ondruch wrote:
> > > It seems that it breaks at least two of my packages unfortunately:
> > >
> > > https://koschei.fedoraproject.org/package/rubygem-ejs
> > >
> > > https://koschei.fedoraproject.org/package/rubygem-execjs
> > >
> > > The former is using the latter, so the real issue is likely in the
> > > latter. I don't have cycles to investigate more :(
> > >
> > > BTW these are likely used in some other components of Ruby on
> > > Rails,
> > > so the potential for breakage is higher. But Koschei is
> > > experiencing
>
Re: Schedule for Monday's FESCo Meeting (2024-05-20)
= # #meeting:fedoraproject.org: FESCO (2024-05-20) !meetingname fesco Chairs: @conan_kudo:matrix.org, @ngompa:fedora.im, @nirik:matrix.scrye.com, @humaton:fedora.im, @zbyszek:fedora.im, @sgallagh:fedora.im, @jistone:fedora.im, @dcantrell:fedora.im, @mhayden:fedora.im, @tstellar:fedora.im !topic Init Process = Meeting started by @sgallagh:fedora.im at 2024-05-20 19:00:09 Meeting summary --- * TOPIC: Exception request to ship prebuilt macOS binaries in asahi-installer (@sgallagh:fedora.im, 19:11:58) * AGREED: FESCo will permit the inclusion of binaries provided by upstream Python and FFI exclusively for the purposes of loading the installer on MacOS since we have no reasonable way to cross-compile for that platform at this time. (+5, 0, -4) (@sgallagh:fedora.im, 20:01:08) * TOPIC: Request exception to permit shipping pre-built, signed SGX (@sgallagh:fedora.im, 20:02:23) * TOPIC: Next Week's Chair (@sgallagh:fedora.im, 20:52:32) * ACTION: zbyszek to chair the 2024-05-27 meeting (@sgallagh:fedora.im, 20:53:42) * TOPIC: Open Floor (@sgallagh:fedora.im, 20:53:48) Meeting ended at 2024-05-20 20:57:16 Action items * zbyszek to chair the 2024-05-27 meeting People Present (lines said) --- * @sgallagh:fedora.im (90) * @conan_kudo:matrix.org (80) * @davide:cavalca.name (50) * @berrange:matrix.org (32) * @zbyszek:fedora.im (30) * @tstellar:fedora.im (29) * @nirik:matrix.scrye.com (24) * @jistone:fedora.im (22) * @zodbot:fedora.im (16) * @dcantrell:fedora.im (8) * @humaton:fedora.im (6) * @farchord:matrix.org (4) * @mhayden:fedora.im (3) * @meetbot:fedora.im (2) * @blackwell:fedora.im (2) * @jonathanspw:fedora.im (1) -- ___ 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
Schedule for Monday's FESCo Meeting (2024-05-20)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-05-20 19:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #3210 Change: Perl 5.40 https://pagure.io/fesco/issue/3210 APPROVED (+5, 0, -0) #3209 Change: Node.js 22.x by default https://pagure.io/fesco/issue/3209 APPROVED (+3, 0, -0) #3208 Change: Fedora Miracle https://pagure.io/fesco/issue/3208 APPROVED (+5, 0, -0) #3207 Change: Drop Mandatory Requires on JRE https://pagure.io/fesco/issue/3207 APPROVED (+4, 0, -0) = Followups = #3203 Change: Replace Redis with Valkey https://pagure.io/fesco/issue/3203 #3205 Request exception to permit shipping pre-built, signed SGX enclave binaries in Fedora https://pagure.io/fesco/issue/3205 = New business = #3212 Exception request to ship prebuilt macOS binaries in asahi-installer https://pagure.io/fesco/issue/3212 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
This meeting is canceled due to lack of agenda. On Thu, May 16, 2024 at 8:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-05-17 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > > > > Source: https://calendar.fedoraproject.org//meeting/10568/ > > -- > ___ > 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
Node.js 22.x coming to Rawhide/F41
As of today, I have built Node.js 22.2.0 for Fedora Rawhide. It is currently available as a non-default package (Node.js 20 remains the default during this short transition period). If you maintain a package that depends on Node.js (either runtime or build-time), please take some time in the next week or so to verify whether it continues to work properly with Node.js 22. I plan to switch the default in Rawhide over to 22.x as per the recently-approved Change[1] on or shortly after May 27th. If you encounter a significant problem with Node.js 22, please contact the nod...@fedoraproject.org mailing list and we will try to help you. [1] https://fedoraproject.org/wiki/Changes/Nodejs22 -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Node.js 22.x coming to Rawhide/F41
As of today, I have built Node.js 22.2.0 for Fedora Rawhide. It is currently available as a non-default package (Node.js 20 remains the default during this short transition period). If you maintain a package that depends on Node.js (either runtime or build-time), please take some time in the next week or so to verify whether it continues to work properly with Node.js 22. I plan to switch the default in Rawhide over to 22.x as per the recently-approved Change[1] on or shortly after May 27th. If you encounter a significant problem with Node.js 22, please contact the nod...@fedoraproject.org mailing list and we will try to help you. [1] https://fedoraproject.org/wiki/Changes/Nodejs22 -- ___ 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: [Input Requested] Ending support for i686 builds of Node.js
On Tue, May 14, 2024 at 3:47 PM Fabio Valentini wrote: > > On Tue, May 14, 2024 at 9:43 PM Stephen Gallagher wrote: > > > > Do you think that's worth a separate Change from the Node.js 22 Change > > I already filed? I can amend that (and ask FESCo to re-vote based on > > new information). > > I think the change is significant enough, yes. > Having a separate change would lead to more visibility, but I think > just amending the existing Change and having FESCo re-approve would be > fine too. > Looks like we can avoid this question for a bit longer. Node.js 22.2.0 appears to have fixed the incompatibility with i686 builds. Phew. -- ___ 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: [Input Requested] Ending support for i686 builds of Node.js
On Tue, May 14, 2024 at 3:38 PM Fabio Valentini wrote: > > On Tue, May 14, 2024 at 9:33 PM Stephen Gallagher wrote: > > > > On Mon, May 13, 2024 at 8:21 AM Fabio Valentini > > wrote: > > > > > > On Mon, May 13, 2024 at 2:02 PM Stephen Gallagher > > > wrote: > > > > > > > > Upstream Node.js has not supported the i686 architecture officially > > > > since Node.js 10.x (released in 2018). As of Node.js 22, it appears > > > > that v8 will no longer build at all on that architecture. > > > > > > > > I'm not particularly willing to go to any great lengths to keep it > > > > alive on i686, but I want to know if there's anyone out there who is > > > > *desperately* in need of it in Fedora. > > > > > > Most (all?) nodejs "library" packages were retired, right? > > > > > > And even if there are still some of them around, most of them should > > > be "noarch"? In that case, they shouldn't need adaptations, since koji > > > now no longer schedules noarch builds to run on i686. > > > But those nodejs packages that are not noarch (however many of them > > > are still in Fedora) will need ExcludeArch: i686. > > > > > > However, another problem might arched non-nodejs packages that need > > > nodejs at build-time. It looks like there's a bunch of packages that > > > "BuildRequires: nodejs" - among them, chromium, firefox, thunderbird, > > > RStudio, qt?-webengine, tinygo, etc. I'm not sure how many of these > > > still build on i686, but some might not be able to disable the nodejs > > > BR, so they would need to stop building on i686 too. > > > > > > > I've looked through most of these and they generally seem to be either > > noarch or else using one of %nodejs_arches or %java_arches for their > > BuildArch. If I make this change, I'll adapt %nodejs_arches to exclude > > i686 and %java_arches already does so. > > That sounds good to me, but it doesn't really answer my question: > Those packages dropping i686 might cause follow-up issues in *their* > dependent packages, and so on. > If they are leaf packages, that's not an issue, but dropping > architecture support is a breaking change that needs to be > coordinated. > > So what you're *really* saying is that you will drop i686 from %nodejs_arches? > I think that has a big enough (and possibly ill-defined) scope that it > would qualify as a Change. > Do you think that's worth a separate Change from the Node.js 22 Change I already filed? I can amend that (and ask FESCo to re-vote based on new information). -- ___ 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: [Input Requested] Ending support for i686 builds of Node.js
On Mon, May 13, 2024 at 8:21 AM Fabio Valentini wrote: > > On Mon, May 13, 2024 at 2:02 PM Stephen Gallagher wrote: > > > > Upstream Node.js has not supported the i686 architecture officially > > since Node.js 10.x (released in 2018). As of Node.js 22, it appears > > that v8 will no longer build at all on that architecture. > > > > I'm not particularly willing to go to any great lengths to keep it > > alive on i686, but I want to know if there's anyone out there who is > > *desperately* in need of it in Fedora. > > Most (all?) nodejs "library" packages were retired, right? > > And even if there are still some of them around, most of them should > be "noarch"? In that case, they shouldn't need adaptations, since koji > now no longer schedules noarch builds to run on i686. > But those nodejs packages that are not noarch (however many of them > are still in Fedora) will need ExcludeArch: i686. > > However, another problem might arched non-nodejs packages that need > nodejs at build-time. It looks like there's a bunch of packages that > "BuildRequires: nodejs" - among them, chromium, firefox, thunderbird, > RStudio, qt?-webengine, tinygo, etc. I'm not sure how many of these > still build on i686, but some might not be able to disable the nodejs > BR, so they would need to stop building on i686 too. > I've looked through most of these and they generally seem to be either noarch or else using one of %nodejs_arches or %java_arches for their BuildArch. If I make this change, I'll adapt %nodejs_arches to exclude i686 and %java_arches already does so. -- ___ 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
On Mon, May 13, 2024 at 10:09 AM Vít Ondruch wrote: > > > Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a): > > On 5/13/24 16:09, Vít Ondruch wrote: > >> > >> Dne 13. 05. 24 v 11:39 Florian Festi napsal(a): > >>> %patch otoh (now) is a regular (though internally implemented) macro > >>> that is expanded with other macros and though can be used in other > >>> macros and expressions. > >> > >> > >> Do I read correctly that we can now use `%patch` in e.g. `%check` > >> section? Interesting. Is this documented? > > > > No, while %patch and %setup *could* be made available elsewhere now, > > they are still only available in %prep because that's the only place > > where they make sense. > > > Working with Ruby, which is interpreted language, there are cases where > we want to patch tests, while we want to keep them in their original > form in the package. This might sound weird, but the thing is that for > running tests, we might be limited by infrastructure. E.g. Koji does not > have internet access, builders are slow, etc. So we might want to apply > some patch to workaround such issues. > > I have no hopes convincing you. But thank you for clarification. > This last statement was unnecessarily hostile. You are better than that, Vit. I assume that Panu's statement above - "that's the only place where they make sense" - was an unintentional overstatement and should have been read as "that's the only place we could think of where it made sense". You've now provided a reasonable argument for why %check might make sense. To expand on your example a bit, what I think you're saying is that in the case of Ruby, we ship not only the binary bits but also the Ruby tests in the RPMs. For sensible reasons, we want to deliver those unmodified from upstream, but we also want to be able to run them in the %check section which necessitates making some modifications due to the limitations and restrictions present in the Koji build system. By being able to constrain the patch application to the %check section (which, if I remember correctly is run AFTER the creation of the binary RPMs) means that we can package the unmodified sources without having to resort to custom trickery in the specfile (copying all the tests to a new location to modify them before running or some such). Is that a fair restatement of your use-case, Vit? -- ___ 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: GIMP 3.0 in F41?
On Mon, May 13, 2024 at 5:23 PM Nils Philippsen wrote: > > On Mon, 2024-05-13 at 14:58 +0200, Vít Ondruch wrote: ... > > Why would you push Gimp 3 into Fedora <= 40? > > Why wouldn’t I? It’s technically feasible without really jumping > through hoops, and I don’t want to force users to upgrade the OS – or > wait for Fedora 41 to be at a level of stability acceptable to them – > before they can use the new version. Right, if there's no technical reason not to backport it, you absolutely should. You should ALSO make sure to file a Change Proposal to make sure that people know it's coming to Fedora 41, if only for the marketing benefit. For example, I submit a Change every year for new Node.js major versions (the latest of which becomes the default in the next release), but I also always make the parallel-installable version available on the prior releases. They just don't own the default locations (/usr/bin/node et. al.). -- ___ 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
[Input Requested] Ending support for i686 builds of Node.js
Upstream Node.js has not supported the i686 architecture officially since Node.js 10.x (released in 2018). As of Node.js 22, it appears that v8 will no longer build at all on that architecture. I'm not particularly willing to go to any great lengths to keep it alive on i686, but I want to know if there's anyone out there who is *desperately* in need of it in Fedora. -- ___ 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: calendar.fp.o pointing to obsolete IRC for meetings
On Fri, May 3, 2024 at 5:18 AM Daniel P. Berrangé wrote: > > Somehow the news that various (some ? all? ) Fedora meetings have > moved off IRC, to Matrix passed me by. This is not helped by the > official project meeting calendar: > >https://calendar.fedoraproject.org/ > > which continues to mislead people who want to attend, by publishing > libera.chat IRC as the venue for meetings which have definitely > moved to Matrix. > > Who's responsible for updating this, and is there somewhere issues > should be reported ? Presumably whomever owns each meeting is > responsible for updating it to point to the new Matrix locations, > but do we need a bulk update ? > It gets worse; the calendar can't handle Matrix locations currently. It expects all locations to be of the form ircroom@irc.server and doesn't have any way to address Matrix channels. -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
= # #meeting:fedoraproject.org: eln = Meeting started by @sgallagh:fedora.im at 2024-05-03 16:02:32 Meeting summary --- * TOPIC: Init Process (@sgallagh:fedora.im, 16:02:47) * TOPIC: Agenda (@sgallagh:fedora.im, 16:05:27) * INFO: Davide and Stephen will present on Fedora ELN at Red Hat Summit's Community Day on Monday in Denver, Colorado. (@sgallagh:fedora.im, 16:12:27) Meeting ended at 2024-05-03 16:18:12 Action items People Present (lines said) --- * @sgallagh:fedora.im (13) * @zodbot:fedora.im (4) * @nhanlon:beeper.com (2) * @meetbot:fedora.im (2) * @yselkowitz:fedora.im (1) * @davide:cavalca.name (1) On Thu, May 2, 2024 at 8:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-05-03 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > > > > Source: https://calendar.fedoraproject.org//meeting/10568/ > > -- > ___ > 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
Schedule for Monday's FESCo Meeting (2024-04-29)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-04-29 19:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = None this week = Followups = None this week = New business = #3198 Request to update Kubernetes version in Fedora 38 https://pagure.io/fesco/issue/3198 #3203 Change: Replace Redis with Valkey https://pagure.io/fesco/issue/3203 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Apr 4, 2024 at 8:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-04-05 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: = # #meeting:fedoraproject.org: eln = Meeting started by @sgallagh:fedora.im at 2024-04-05 16:01:47 Meeting summary --- * TOPIC: Init Process (@sgallagh:fedora.im, 16:01:57) * TOPIC: Agenda (@sgallagh:fedora.im, 16:05:39) * INFO: Agenda Item: Issues with guest image building (@sgallagh:fedora.im, 16:07:26) * INFO: Agenda Item: How to include ELN-only packages (@sgallagh:fedora.im, 16:09:34) * INFO: Agenda Item: ELN buildroot retention (@sgallagh:fedora.im, 16:12:40) * TOPIC: ELN buildroot retention (@sgallagh:fedora.im, 16:15:07) * LINK: https://pagure.io/releng/issue/12053 (@yselkowitz:fedora.im, 16:15:36) * INFO: No specific actions to take here at the moment, other than to schedule and work on migration of composes off of ODCS. (@sgallagh:fedora.im, 16:28:44) * TOPIC: How to include ELN-only packages (@sgallagh:fedora.im, 16:28:08) * INFO: ELN-only packages should be built into eln-extras from a separate SRPM name than the Rawhide package. (@sgallagh:fedora.im, 16:57:09) * INFO: That separate SRPM name will be added to the exclusion list in ELNBuildSync to avoid accidental rebuilds (@sgallagh:fedora.im, 16:57:48) * INFO: The needed subpackage(s) will be added to Content Resolver for ELN Extras. (@sgallagh:fedora.im, 16:58:05) * ACTION: Davide Cavalca to update the docs (@sgallagh:fedora.im, 17:00:41) Meeting ended at 2024-04-05 17:02:12 Action items * Davide Cavalca to update the docs People Present (lines said) --- * @sgallagh:fedora.im (59) * @davide:cavalca.name (17) * @yselkowitz:fedora.im (15) * @nirik:matrix.scrye.com (6) * @tdawson:fedora.im (4) * @zodbot:fedora.im (4) * @meetbot:fedora.im (2) * @nhanlon:beeper.com (1) -- ___ 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: Three steps we could take to make supply chain attacks a bit harder
On Tue, Apr 2, 2024 at 7:41 PM Kevin Fenzi wrote: > > On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote: > > On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette wrote: > > > > > > I personally would very much agree with enforcing the use of 2fa on the > > > Fedora Account System. Maybe take that opportunity to make it a bit more > > > user friendly? (Such as the fkinit prompt requiring the 2fa code being > > > added at the end of your password -- to be clear I think the 2fa code > > > should be separate) > > > > https://pagure.io/fedora-packager/pull-request/179 > > I agree that fixing the mismatch in prompts might be nice, but why does > having 2fa seperate make things any better? I mean, it's one more return > you get to hit. ;) > > And... I am not sure about moving the handling of passwords to a bash > script from a kinit prompt. > The kinit is already being run inside a bash script, so if bash is compromised with a keylogger, you've already lost the game... I'm not sure how this is worse. Yeah, it's an extra keystroke, but I think there's value in helping the user provide the input in the proper format. Right now it's confusing (particularly since the kinit prompt gives bad information that we have to warn about). -- ___ 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: Three steps we could take to make supply chain attacks a bit harder
On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette wrote: > > I personally would very much agree with enforcing the use of 2fa on the > Fedora Account System. Maybe take that opportunity to make it a bit more user > friendly? (Such as the fkinit prompt requiring the 2fa code being added at > the end of your password -- to be clear I think the 2fa code should be > separate) https://pagure.io/fedora-packager/pull-request/179 -- ___ 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: Reminder: F40 final freeze starts next week (2024-04-02)
On Tue, Apr 2, 2024 at 12:18 PM Fabio Valentini wrote: > > On Tue, Apr 2, 2024 at 6:08 PM Sandro wrote: > > > > On 26-03-2024 22:15, Adam Williamson wrote: > > > On Tue, 2024-03-26 at 21:34 +0100, Sandro wrote: > > >> On 26-03-2024 16:25, Kevin Fenzi wrote: > > >>> So, please take this time to do any last minute testing and bugfixing > > >>> and make sure any packages you expect to be in the final f40 base > > >>> repositories are pushed stable before next Tuesday (2024-04-02). > > >> > > >> I was just wondering, and someone else with me, if today's updates would > > >> still make it in time? > > >> > > >> If not, I thank you for the reminder nonetheless, but would also like to > > >> ask to have it sent in time for updates to still be able to land in the > > >> release before freeze happens. > > >> > > >> Of course, there's always the option of going around begging for > > >> (instant) karma ... > > > > > > You still have a week until next Tuesday, so...yes. > > > > We are one week down the road. I've submitted an update a week ago > > shortly after Adam's reply was sent (March 26, 21:48 UTC). Final freeze > > is now in effect and the update[1] has *not* made it to stable. It's > > still in testing. > > > > Luckily, this update can wait until after freeze. I'm glad I decided to > > ask for karma for another update submitted earlier the same day. > > > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ebd1e2c45 > > Yes, 7 days between end of beta freeze and start of final freeze is > not enough to land an update that has autotime=7days. Which is really > annoying. > Maybe next time we can make the non-freeze period last like 8-9 days? > One week (especially if that week contains the Easter holiday) is not > enough. For the record, FESCo reviewed a request to extend the non-freeze period and decided that we would take on the burden of going through the Freeze Exception approval process rather than extend the non-Freeze period (which would have necessitated extending the F40 schedule). These updates are certainly candidates for Freeze Exception consideration, so please raise them as such via https://qa.fedoraproject.org/blockerbugs/propose_bug -- ___ 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: xz backdoor
Please add “Fedora ELN” as well. We have updates ready that should be composed by midnight tonight, but it should be mentioned in the announcements. On Fri, Mar 29, 2024 at 5:11 PM Michael Catanzaro wrote: > On Fri, Mar 29 2024 at 08:16:55 PM +00:00:00, Richard W.M. Jones > wrote: > > These are the exact builds which were vulnerable. Note the tags are > > all empty because Kevin untagged them last night, so you'll probably > > need to cross-reference these with bodhi updates. > > OK, I am going to ask Product Security to edit their blog post to > remove the incorrect information. I will CC you on that request. > > Thanks, > > Michael > > -- > ___ > 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: [Fedocal] Reminder meeting : ELN SIG
On Fri, Mar 22, 2024 at 9:50 AM Stephen Gallagher wrote:
>
> On Thu, Mar 21, 2024 at 8:00 AM wrote:
> >
> > Dear all,
> >
> > You are kindly invited to the meeting:
> >ELN SIG on 2024-03-22 from 12:00:00 to 13:00:00 US/Eastern
> >At fedora-meet...@irc.libera.chat
> >
> > The meeting will be about:
>
> * Schedule the "%{rhel} == 11" mass-rebuild
=
# #meeting:fedoraproject.org: eln
=
Meeting started by @sgallagh:fedora.im at 2024-03-22 16:01:00
Meeting summary
---
* TOPIC: Init Process (@sgallagh:fedora.im, 16:01:11)
* TOPIC: Agenda (@sgallagh:fedora.im, 16:04:45)
* INFO: Agenda Item: ELN mass-rebuild to adapt to `%{rhel} == 11`
(@sgallagh:fedora.im, 16:05:14)
* INFO: Agenda Item: Flock to Fedora CfP (@sgallagh:fedora.im, 16:06:52)
* TOPIC: ELN mass-rebuild to adapt to `%{rhel} == 11`
(@sgallagh:fedora.im, 16:07:35)
* AGREED: Out of interest in not burning people out, we'll plan to
do the mass-rebuild in May and check in with toolchain teams for
additional features to pull in at that time. (@sgallagh:fedora.im,
16:43:43)
* INFO: The conversation also lead to a reminder that we have
https://sgallagh.fedorapeople.org/dbs_status.html as a guide for
packages in ELN and ELN Extras that need some love. Help would be
appreciated. (@sgallagh:fedora.im, 16:44:54)
* TOPIC: Flock to Fedora CfP (@sgallagh:fedora.im, 16:45:43)
* TOPIC: Open Floor (@sgallagh:fedora.im, 16:53:39)
Meeting ended at 2024-03-22 17:00:57
Action items
People Present (lines said)
---
* @sgallagh:fedora.im (67)
* @conan_kudo:matrix.org (58)
* @yselkowitz:fedora.im (21)
* @nhanlon:beeper.com (14)
* @davide:cavalca.name (13)
* @zodbot:fedora.im (6)
* @tdawson:fedora.im (4)
* @meetbot:fedora.im (2)
--
___
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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Mar 21, 2024 at 8:00 AM wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2024-03-22 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
* Schedule the "%{rhel} == 11" 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: Default NodeJS stream packages with versioned names are not available
On Thu, Mar 21, 2024 at 6:28 AM Jan Staněk wrote: > Stephen Gallagher writes: > > That said, I agree that it's completely reasonable to have the default > > version also `Provides: nodejsXX` and I'll look into it. > > Provides is something I did not consider at all, and it looks like the > easiest way forward! Let me know when you get around to it; > alternatively, I can throw together a package PR. > https://src.fedoraproject.org/rpms/nodejs20/pull-request/11 I haven’t had time to properly test upgrades with that patch yet, so I’d appreciate it if you could review the patch and help with upgrade testing. -- ___ 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: Default NodeJS stream packages with versioned names are not available
On Wed, Mar 20, 2024 at 12:35 PM Jan Staněk wrote:
>
> Hello all,
> recently, when trying to spin up a CI for NodeJS in Fedora, I ran into a
> slight problem: when a NodeJS stream is the default one, versioned
> packages (i.e. nodejs20) are not generated and are not installable.
>
> For example, on current rawhide, I cannot install `nodejs20` package,
> only `nodejs`; this will give me the version 20.x as expected.
> The problem is that this complicates the CI setup,
> and requires me to take into account which Fedora I'm currently on.
>
> As an example, when adding tests for nodejs20 dist-git[1],
> I would like to simply specify `requires: nodejs20` into the test
> metadata. However, with the current setup, I would need something akin
> to the following (pseudocode, I did not really test if that would work):
>
> requires:
> - {% if fedora == 40 %}nodejs{% else %}nodejs20{% fi %}
>
> In addition to being more complicated, this will also break if the
> default stream for a given Fedora version ever change
> (which is not unlikely to happen, as the upstream release schedule
> is not really synchronized with the Fedore one).
>
The default version is fixed for the life of each Fedora release. It
works out fine, because we always use whichever is the most recent LTS
release that will be supported through the life of that Fedora
release.
That said, I agree that it's completely reasonable to have the default
version also `Provides: nodejsXX` and I'll look into it.
> ---
>
> I recall that the current status is the result of already existing
> long discussion, with associated debugging, so I would like to have this
> solved with as minimal disruption as possible. That being said,
> what is the reason for having the non-versioned packages (`nodejs`) *in
> stead* of the versioned ones (`nodejs20`), as opposed to *in addition*
> to them?
I'm confused; it *is* in addition to the versioned ones. We just don't
duplicate the default version because it would be a complete waste.
> The non-versioned packages could then require the appropriate versioned
> ones and contain only symlinks (/usr/bin/node → /usr/bin/node-20,
> /usr/lib/node_modules → /usr/lib/node_modules_20, etc.).
The overly-simplified answer here is mainly that there are too many
symlinks to maintain for this to be practical.
--
___
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
[CANCELED] Re: [Fedocal] Reminder meeting : ELN SIG
No agenda, no meeting. See you next time. On Thu, Mar 7, 2024 at 7:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-03-08 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > > > > Source: https://calendar.fedoraproject.org//meeting/10568/ > > -- > ___ > 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: Current status of OSTree and its handling RPM scriptlets?
On Thu, Feb 22, 2024 at 4:51 AM Zdenek Dohnal wrote: > > Hi Jonathan! > > On 2/13/24 16:47, Jonathan Lebon wrote: > > Has it got fixed during the time? Or is there a new technology which > would do the trick for Silverblue and Fedora Linux alike? > > Just a note: I would say "for Silverblue and traditional systems > alike" instead. Silverblue is part of Fedora Linux. :) > > Ok, I thought there are Fedora Linux, Fedora Silverblue and Fedora CoreOS > (maybe others :) ). Thanks! > > The common way to make "image-mode friendly" system state changes is > to e.g. use a systemd service > > Do you have an example of such systemd service? I could see that a shell > script can be started by systemd unit to do the migration, but that would > have to be run in %post scriptlet again AFAIK - unless you would require > machine restart (and the service is run during reboot) or manual service > start... > https://docs.fedoraproject.org/en-US/packaging-guidelines/Initial_Service_Setup/ -- ___ 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: distrobuildsync-eln is building unnecessary liborc and libarrow
On Mon, Feb 26, 2024 at 8:38 AM Kaleb Keithley wrote: > > Hi, > > Anyone know why distriobuildsync-eln has started building liborc and libarrow > again? > > They were stopped at one point, but now they have started again. > > There are not needed for ceph in ELN. > They're getting pulled into ELN-Extras, not ELN proper. Looks like Digikam depends on them indirectly (by way of opencv-imgcodecs and gdal-libs). A few notes: * ELN is currently tracking RHEL 11 * ELN Extras is essentially a preview for EPEL, not RHEL. * The Content Resolver will show you the dependency chain: https://tiny.distro.builders/view-rpm--view-eln-extras--libarrow.html -- ___ 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: A note about riscv64 changes
On Wed, Feb 14, 2024 at 7:30 AM Peter Robinson wrote: > > On Wed, 14 Feb 2024 at 12:07, David Abdurachmanov > wrote: > > > > On Wed, Feb 14, 2024 at 12:49 PM Dan Horák wrote: > > > > > > On Wed, 14 Feb 2024 10:42:52 + > > > "Richard W.M. Jones" wrote: > > > > > > > On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote: > > > > > Hi Richard, > > > > > > > > > > > A quick note that you may be seeing pull requests for riscv64 > > > > > > changes > > > > > > against your packages, like these examples: > > > > > > > > > > > > https://src.fedoraproject.org/rpms/ghc/pull-request/7 > > > > > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11 > > > > > > https://src.fedoraproject.org/rpms/gdal/pull-request/21 > > > > > > > > > > > > For many years we have been building Fedora for the RISC-V > > > > > > architecture on a separate build system at > > > > > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches > > > > > > against dist-git in http://fedora.riscv.rocks:3000/rpms/ > > > > > > (Most of this work was done by David Abdurachmanov, not me.) > > > > > > > > > > I'm very happy to see these start to land, let me know if you need any > > > > > assistance. > > > > > > > > > > > I'm trying to get as much of this stuff back into Fedora dist-git, > > > > > > although only (hopefully!) where it doesn't break ordinary builds > > > > > > and > > > > > > isn't intrusive. Obviously I may get this wrong sometimes so feel > > > > > > free to make comments if you disagree with changes. > > > > > > > > > > > > Some time, with any luck soon, we will be creating a new Koji > > > > > > instance > > > > > > with FAS authentication which will allow anyone to optionally build > > > > > > their packages on RISC-V builders. And then later in the year we > > > > > > may > > > > > > be in a position with the availability of new hardware to discuss > > > > > > adding RISC-V as a regular architecture. (We're not there yet as > > > > > > current hardware is far too slow to force it on Fedora developers.) > > > > > > > > > > Will this instance run with koji-shadow to properly mirror the builds > > > > > with all the appropriate NVR dependencies to properly mirror Fedora > > > > > primary builds? > > > > > > > > TBD. > > > > > > > > Koji-shadow specifically is unmaintained. Maybe we'll try to hack > > > > something together with scripts, or get koji-shadow working. > > > > > > on the other hand, it's still tags, targets, buildroots in koji ... > > > > > > I should be able dig out some koji-shadow know-how out of my memory if > > > needed. Those were wonderful years :-) > > > > Many years ago I tried using koji-shadow, but I didn't like what it > > was doing. Cooking something custom seemed easier at that point. These > One tool to look into could be the one we use for automatically rebuilding Rawhide packages for Fedora ELN: https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync I'd be happy to work with you to extend it for RISC use (though probably not sooner than March, as we've got kind of a lot going on with the CentOS Stream 10 fork from ELN this week and next). -- ___ 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: Schedule for Monday's FESCo Meeting (2024-02-12)
= # #meeting:fedoraproject.org: fesco = Meeting started by @sgallagh:fedora.im at 2024-02-12 19:30:38 Meeting summary --- * TOPIC: Init Process (@sgallagh:fedora.im, 19:32:09) * TOPIC: #3165 Requesting FESCo assistance with issue about plasma-x11 (@sgallagh:fedora.im, 19:37:28) * AGREED: KDE packages which reintroduce support for X11 are allowed in the main Fedora repositories, however they may not be included by default on any release-blocking deliverable (ISO, image, etc.). The KDE SIG should provide a notice before major changes, but is not responsible for ensuring that these packages adapt. Upgrades from F38 and F39 will be automatically migrated to Wayland. (+5, 0, -1) (@sgallagh:fedora.im, 20:33:45) * TOPIC: Next Week's Chair (@sgallagh:fedora.im, 20:37:40) * ACTION: zbyszek to chair the 2024-02-19 meeting (@sgallagh:fedora.im, 20:38:36) * TOPIC: Open Floor (@sgallagh:fedora.im, 20:38:41) Meeting ended at 2024-02-12 20:42:10 Action items * zbyszek to chair the 2024-02-19 meeting People Present (lines said) --- * @conan_kudo:matrix.org (80) * @sgallagh:fedora.im (57) * @nirik:matrix.scrye.com (30) * @salimma:fedora.im (23) * @zbyszek:fedora.im (15) * @marcdeop:matrix.org (14) * @jistone:fedora.im (14) * @farchord:matrix.org (10) * @tstellar:fedora.im (10) * @zodbot:fedora.im (10) * @stevenfalco:fedora.im (5) * @mhayden:fedora.im (3) * @nhanlon:beeper.com (2) * @solopasha:matrix.org (2) * @humaton:fedora.im (2) * @meetbot:fedora.im (2) * @aleasto:matrix.org (1) * @davide:cavalca.name (1) * @jonathanspw:fedora.im (1) -- ___ 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
Schedule for Monday's FESCo Meeting (2024-02-12)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-02-12 19:30 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #3164 Change: IoT Simplified Provisioning https://pagure.io/fesco/issue/3164 APPROVED (+6, 0, 0) #3163 Change: ibus 1.5.30 https://pagure.io/fesco/issue/3163 APPROVED (+6, 0, 0) #3162 Change: ibus-anthy 1.5.16 https://pagure.io/fesco/issue/3162 APPROVED (+6, 0, 0) #3161 Change: Build Fedora IoT Using rpm-ostree unified core https://pagure.io/fesco/issue/3162 APPROVED (+6, 0, 0) #3160 Change: Fedora IoT Bootable Container https://pagure.io/fesco/issue/3160 APPROVED (+5, 0, 0) #3159 Change: Deprecate_ntlm_in_cyrus_sasl https://pagure.io/fesco/issue/3159 APPROVED (+6, 0, 0) #3156 Change: Replace iotop with iotop-c https://pagure.io/fesco/issue/3156 APPROVED (+6, 0, 0) #3155 Change: ROCm 6 Release https://pagure.io/fesco/issue/3155 APPROVED (+6, 0, 0) #3154 Change: PyTorch Release https://pagure.io/fesco/issue/3154 APPROVED (+6, 0, 0) Change: Default Bpfman as eBPF manager https://pagure.io/fesco/issue/3153 APPROVED (+6, 0, 0) = Followups = #3165 Requesting FESCo assistance with issue about plasma-x11 https://pagure.io/fesco/issue/3165 = New business = #3158 Change: Arm Minimal Image OS Build https://pagure.io/fesco/issue/3158 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Feb 8, 2024 at 9:18 AM Stephen Gallagher wrote: > > On Thu, Feb 8, 2024 at 7:00 AM wrote: > > > > Dear all, > > > > You are kindly invited to the meeting: > >ELN SIG on 2024-02-09 from 12:00:00 to 13:00:00 US/Eastern > >At fedora-meet...@irc.libera.chat > > > > The meeting will be about: > > * The status of and assigning tasks for the EL10 fork > > > Source: https://calendar.fedoraproject.org//meeting/10568/ > > = # #meeting:fedoraproject.org: eln = Meeting started by @sgallagh:fedora.im at 2024-02-09 17:01:06 Meeting summary --- * TOPIC: Init Process (@sgallagh:fedora.im, 17:01:48) * TOPIC: Forking EL 10 (@sgallagh:fedora.im, 17:06:54) * INFO: As previously announced, Tuesday February 13th marks the end of Fedora ELN syncing to CentOS Stream 10 (@sgallagh:fedora.im, 17:08:29) * LINK: https://docs.fedoraproject.org/en-US/eln/branching/ (@sgallagh:fedora.im, 17:09:48) * LINK: https://github.com/fedora-eln/eln/issues/180 (@sgallagh:fedora.im, 17:11:20) * LINK: https://github.com/fedora-eln/eln/issues/179 (@sgallagh:fedora.im, 17:11:36) * LINK: https://github.com/fedora-eln/eln/issues/176 (@sgallagh:fedora.im, 17:11:57) * ACTION: Neil Hanlon to look into gtk-doc (@sgallagh:fedora.im, 17:22:15) * TOPIC: RHEL-like Koji Builders (@sgallagh:fedora.im, 17:31:01) * TOPIC: Open Floor (@sgallagh:fedora.im, 17:35:30) * TOPIC: OpenSSL 3.2 (@sgallagh:fedora.im, 17:49:39) * TOPIC: Next Meeting (@sgallagh:fedora.im, 17:55:53) * INFO: There will be no meeting on Feb. 23rd. We may have an out-of-schedule meeting on Mar. 1 if interest is high. (@sgallagh:fedora.im, 18:00:49) Meeting ended at 2024-02-09 18:01:03 Action items * Neil Hanlon to look into gtk-doc People Present (lines said) --- * @sgallagh:fedora.im (61) * @yselkowitz:fedora.im (23) * @smooge:fedora.im (16) * @nhanlon:beeper.com (5) * @tdawson:fedora.im (4) * @zodbot:fedora.im (4) * @meetbot:fedora.im (2) * @jonathanspw:fedora.im (1) -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Feb 8, 2024 at 7:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-02-09 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: * The status of and assigning tasks for the EL10 fork > Source: https://calendar.fedoraproject.org//meeting/10568/ > > -- > ___ > 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: cloud-init switching to udhcpc
On Tue, Feb 6, 2024 at 3:30 PM Chris Adams wrote: > > Once upon a time, Major Hayden said: > > Stephen Gallagher pointed out that ELN doesn't have busybox, but it does > > have dhcpcd, and that should work fine. I've reverted the switch to udhcpcd > > and I'm waiting on upstream cloud-init to have a new release with the > > recently added dhcpcd support. > > ISC dhcpd is also EOL upstream from October 5, 2022, so making a new > dependency on it is probably not a good idea. ISC dhcpd[1] and dhcpcd[2] are different projects. [1] https://www.isc.org/dhcp/ [2] https://github.com/NetworkConfiguration/dhcpcd -- ___ 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: bodhi push error
On Mon, Feb 5, 2024 at 9:12 PM Christoph Junghans wrote: > > Hi, > > Has anybody seen this error before: > FEDORA-2024-310c0537ac ejected from the push because "Cannot find > relevant tag for gromacs-2023.4-1.fc39. None of ['f39-updates', > 'f39-updates-pending'] are in ['epel9-next-testing', 'epel7-testing', > 'eln-updates-testing', 'epel8-testing', 'epel9-testing', > 'epel8-next-testing', 'f40-container-updates-testing', > 'f38-modular-updates-testing', 'f38-flatpak-updates-testing', > 'f40-updates-testing', 'f38-updates-testing', > 'f38-container-updates-testing', 'f39-updates-testing', > 'f39-container-updates-testing', 'f39-flatpak-updates-testing']." > I'm not sure if you got this fixed in the meantime, but it appears that update is tagged for `f39-updates`, so it got pushed. -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Wed, Jan 31, 2024 at 8:44 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Jan 30, 2024 at 08:45:37AM -0500, Stephen Gallagher wrote: > > One additional point I forgot to address: the initial concern was that > > the KDE SIG would be implicitly responsible for maintaining these > > packages if they are included in the main repository. From a purely > > technical perspective, I think that we should state clearly that the > > KDE SIG would be required only to provide advance notice of major > > changes but would NOT be responsible for ensuring that these packages > > adapt to them. Of course, communicating that to users is harder (and > > they'll naturally report bugs to the wrong place in many cases), but I > > think the KDE SIG is completely permitted to refuse and retarget any > > issues that come up to the appropriate group. > > > > > > > My proposal for consideration is this: > > > "FESCo will allow these packages in the main Fedora repositories, > > > however they may not be included by default on any release-blocking > > > deliverable (ISO, image, etc.)" > > I think we should reword this proposal to address this point: > > "FESCo will allow these packages in the main Fedora repositories, > however they may not be included by default on any release-blocking > deliverable (ISO, image, etc.). The KDE SIG should provide a notice > before major changes, but is NOT responsible for ensuring that these > packages adapt." I can absolutely support that. -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, Jan 30, 2024 at 8:38 AM Stephen Gallagher wrote: > > On Tue, Jan 30, 2024 at 8:07 AM Richard W.M. Jones wrote: > > > > On Tue, Jan 30, 2024 at 12:47:44PM +, Sérgio Basto wrote: > > > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165 > > > > > > and I'm very upset > > > > Assume best intent first of all. An injunction is a temporary thing > > to allow some space for a decision to be made. > > > > (I added my personal opinion to the ticket itself) > > > > First of all, thank you for assuming best intent. > > I'll apologize first for the terseness of those messages; I was in a > rush between meetings and I left out basically all of the context (and > probably used a stronger word -- injunction -- than was strictly > called for). I'm sorry for that. > > Next, I'll address Kevin's comment that the "injunction" lacked a > quorum vote to enforce: you are correct. That's the whole reason for > it: the issue came up at the end of an already-long FESCo meeting and > we did not have time to discuss it in the detail it deserves. The > intent was not to make a ruling (which was impossible without quorum), > but to instead indicate that the package review should refrain from > landing until FESCo makes a determination of its suitability and > alignment with Fedora's goals. This is as much for the packagers > involved as anyone; we don't want you to be putting in effort that > FESCo might ultimately require you to revert if the decision goes that > way. > > Again, I apologize for not doing a better job communicating that yesterday. > > > Now, as for my personal stance on the issue upon a night's reflection > (some of this is in reply to comments on > https://pagure.io/fesco/issue/3165 that I feel should be discussed in > a more public forum): > > 1) I agree that if a Fedora packager wants to maintain a package, then > that package should not be excluded from Fedora except under very > exceptional cases. > 2) FESCo is ultimately the arbiter of what software comprises "Fedora > Linux" as made available to the rest of the world. In practice, this > mostly means the install/Live media contents as well as container and > VM images that are released as official Fedora deliverables. > 3) Fedora has a long-standing and well-communicated stance that we are > a Wayland distribution first and foremost and that X11 support is > intended as a migration-support tool rather than a first-class > citizen. > 4) There was a comment on the FESCo ticket to the effect of '"you must > move to Wayland because no one maintains X11!". Here are some people > who are maintaining X11 packages, so let them do their thing.' This is > misleading, as the move to Wayland is specifically because the > upstream of X11 *itself* is largely unmaintained. These packages are > not maintaining X11, they are adding new dependencies on it. One additional point I forgot to address: the initial concern was that the KDE SIG would be implicitly responsible for maintaining these packages if they are included in the main repository. From a purely technical perspective, I think that we should state clearly that the KDE SIG would be required only to provide advance notice of major changes but would NOT be responsible for ensuring that these packages adapt to them. Of course, communicating that to users is harder (and they'll naturally report bugs to the wrong place in many cases), but I think the KDE SIG is completely permitted to refuse and retarget any issues that come up to the appropriate group. > My proposal for consideration is this: > "FESCo will allow these packages in the main Fedora repositories, > however they may not be included by default on any release-blocking > deliverable (ISO, image, etc.)" -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, Jan 30, 2024 at 8:07 AM Richard W.M. Jones wrote: > > On Tue, Jan 30, 2024 at 12:47:44PM +, Sérgio Basto wrote: > > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165 > > > > and I'm very upset > > Assume best intent first of all. An injunction is a temporary thing > to allow some space for a decision to be made. > > (I added my personal opinion to the ticket itself) > First of all, thank you for assuming best intent. I'll apologize first for the terseness of those messages; I was in a rush between meetings and I left out basically all of the context (and probably used a stronger word -- injunction -- than was strictly called for). I'm sorry for that. Next, I'll address Kevin's comment that the "injunction" lacked a quorum vote to enforce: you are correct. That's the whole reason for it: the issue came up at the end of an already-long FESCo meeting and we did not have time to discuss it in the detail it deserves. The intent was not to make a ruling (which was impossible without quorum), but to instead indicate that the package review should refrain from landing until FESCo makes a determination of its suitability and alignment with Fedora's goals. This is as much for the packagers involved as anyone; we don't want you to be putting in effort that FESCo might ultimately require you to revert if the decision goes that way. Again, I apologize for not doing a better job communicating that yesterday. Now, as for my personal stance on the issue upon a night's reflection (some of this is in reply to comments on https://pagure.io/fesco/issue/3165 that I feel should be discussed in a more public forum): 1) I agree that if a Fedora packager wants to maintain a package, then that package should not be excluded from Fedora except under very exceptional cases. 2) FESCo is ultimately the arbiter of what software comprises "Fedora Linux" as made available to the rest of the world. In practice, this mostly means the install/Live media contents as well as container and VM images that are released as official Fedora deliverables. 3) Fedora has a long-standing and well-communicated stance that we are a Wayland distribution first and foremost and that X11 support is intended as a migration-support tool rather than a first-class citizen. 4) There was a comment on the FESCo ticket to the effect of '"you must move to Wayland because no one maintains X11!". Here are some people who are maintaining X11 packages, so let them do their thing.' This is misleading, as the move to Wayland is specifically because the upstream of X11 *itself* is largely unmaintained. These packages are not maintaining X11, they are adding new dependencies on it. My proposal for consideration is this: "FESCo will allow these packages in the main Fedora repositories, however they may not be included by default on any release-blocking deliverable (ISO, image, etc.)" -- ___ 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: runaway fork() in Lua script
https://bugzilla.redhat.com/show_bug.cgi?id=2254463 reappeared, this time on Fedora 39. The fix is known, it just needs to get built and released. On Mon, Jan 29, 2024 at 1:35 PM Richard Shaw wrote: > > On Mon, Jan 29, 2024 at 12:03 PM Jerry James wrote: >> >> For the second time in two days, running "fedpkg build" gave me a few >> dozen lines that say: >> >> warning: runaway fork() in Lua script >> >> before the usual build messages start appearing. Is this a known issue? > > > Just started seeing this after a `dnf update` and reboot... > > Thanks, > Richard > -- > ___ > 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Jan 25, 2024 at 3:29 PM Stephen Gallagher wrote: > > On Thu, Jan 25, 2024 at 7:00 AM wrote: > > > > Dear all, > > > > You are kindly invited to the meeting: > >ELN SIG on 2024-01-26 from 12:00:00 to 13:00:00 US/Eastern > >At fedora-meet...@irc.libera.chat > > > > The meeting will be about: > > > > * Status of the mass-rebuild > * Status of the impending branch of EL10 > > Also note that we have published an updated SOP[1] document for ELN > branching at https://docs.fedoraproject.org/en-US/eln/branching/ > > [1] Standard operating procedure = # #meeting:fedoraproject.org: Fedora ELN (2024-01-26) !meetingname eln !topic Init Process = Meeting started by @sgallagh:fedora.im at 2024-01-26 17:00:25 Meeting summary --- * TOPIC: Mass Rebuild Status (@sgallagh:fedora.im, 17:03:38) * ACTION: yselkowitz will populate a framacalc spreadsheet with the packages requiring attention post-mass-rebuild (@sgallagh:fedora.im, 17:27:38) * INFO: Any interested person should feel welcome to jump in and help, instructions on how will be posted to https://github.com/fedora-eln/eln/issues/176 (@sgallagh:fedora.im, 17:28:20) * TOPIC: EL10 Branching (@sgallagh:fedora.im, 17:29:21) * INFO: sgallagh has updated https://docs.fedoraproject.org/en-US/eln/branching/ with the operations required at branch-time (@sgallagh:fedora.im, 17:30:08) * AGREED: Packages in ELN-Extras will branch for EPEL 10 from the `f40` branch at some point after we branch EL10. (@sgallagh:fedora.im, 17:46:55) * TOPIC: Open Floor (@sgallagh:fedora.im, 17:48:56) * LINK: https://lite.framacalc.org/tgyaghuoob-a5pt (@sgallagh:fedora.im, 17:51:08) Meeting ended at 2024-01-26 17:57:14 Action items * yselkowitz will populate a framacalc spreadsheet with the packages requiring attention post-mass-rebuild People Present (lines said) --- * @sgallagh:fedora.im (74) * @salimma:fedora.im (43) * @tdawson:fedora.im (19) * @yselkowitz:fedora.im (13) * @nhanlon:beeper.com (10) * @zodbot:fedora.im (8) * @smooge:fedora.im (5) * @meetbot:fedora.im (2) * @davide:cavalca.name (1) -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Jan 25, 2024 at 3:29 PM Stephen Gallagher wrote: > > On Thu, Jan 25, 2024 at 7:00 AM wrote: > > > > Dear all, > > > > You are kindly invited to the meeting: > >ELN SIG on 2024-01-26 from 12:00:00 to 13:00:00 US/Eastern > >At fedora-meet...@irc.libera.chat CORRECTION: New meeting location this week will be on Matrix in the "Fedora Meeting" channel. > > > > The meeting will be about: > > > > * Status of the mass-rebuild > * Status of the impending branch of EL10 > > Also note that we have published an updated SOP[1] document for ELN > branching at https://docs.fedoraproject.org/en-US/eln/branching/ > > [1] Standard operating procedure -- ___ 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
[EPEL-devel] Re: Packaging a newer singularity-ce as singularity-ce4
On Fri, Jan 26, 2024 at 8:08 AM David Trudgian via epel-devel wrote: > > Hi all, > > I’ve had some discussion with Jonathan Wright elsewhere about the topic of > this message, but wanted to verify my understanding is correct before I > embark on it, and thought I’d do so on list. > > singularity-ce is currently packaged at v4.0.3 in Fedora Rawhide, and > v.3.11.5 elsewhere (Fedora releases and EPEL). > > We want to make a v4 available to EPEL users, as many would be interested in > it, but I wouldn’t consider it a compatible update because there are some CLI > changes, and small behaviour changes. > > My understanding is that in order to provide a 4.x in EPEL, without any > incompatible update happening for users: > > 1) I create a new package, singularity-ce4, to package the 4.x version. In > rawhide, this will be the same as the singularity-ce package currently in > rawhide, but needs new package review etc. Creating a versioned package does NOT require a new review[1], though if you feel that packaging changes are going to be large enough to warrant one, you may still request it. > > 2) For rawhide / upcoming f40 *only*, the new singularity-ce4 package will > provide/obsolete singularity-ce as it is the same thing … and singularity-ce > can be retired in rawhide. > 3) When singularity-ce4 is added to EPEL it will *not* provide/obsolete > singularity-ce, but a message can be added to %post to inform people about > the availability of v4. Do not do this. %post messages are really only intended to inform users of failures and, frankly, no one reads them until something has gone wrong. Even then, it's only going to be the sysop for the machine that sees it, who may not be the person who deals with Singularity. I don't know anything about Singularity, but if it has a user interface of any kind (like the CLI), what you might want to do is add a wrapper around it that prints your message. That's much more likely to be viewed by the people who would care. > At some point in the future, if 3.x is no longer maintainable for good > reason, then the incompatible update procedure can be pursued to make > singularity-ce4 provide/obsolete singularity-ce in EPEL 7/8/9 - and > singularity-ce is fully retired. EPEL 10 will only get singularity-ce4. Is v3 still supported upstream today? If not, you probably want to make the message above a deprecation notice and add an EOL date. > Apologies for the multiple complex queries lately. I really appreciate your > guidance! > [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedocal] Reminder meeting : ELN SIG
On Thu, Jan 25, 2024 at 7:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-01-26 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > * Status of the mass-rebuild * Status of the impending branch of EL10 Also note that we have published an updated SOP[1] document for ELN branching at https://docs.fedoraproject.org/en-US/eln/branching/ [1] Standard operating procedure -- ___ 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
[EPEL-devel] Re: Bundling newer 3rd party binaries than are packaged separately
On Tue, Jan 23, 2024 at 11:58 AM David Trudgian via epel-devel wrote: > > Hi all, > > I currently package singularity-ce for Fedora and EPEL. > > Upstream, we bundle current versions of squashfuse and conmon with our source > and own binary packages… because many distros package versions that are too > old to work with SingularityCE, and users installing our upstream binary > packages just want them to work. > > In Fedora & EPEL packaging I disable the building of the bundled squashfuse > and conmon in the spec file, and we rely on the distro’s squashfuse and > conmon packages. > > This is fine with Fedora, and has been okay up until now for EPEL. However, I > want to move forward with packaging SingularityCE 4.x for EPEL and there we > need a newer squashfuse than is available in EPEL7. Given our user base, > leaving EPEL7 without the update wouldn’t be popular, even if it is > approaching EOL. > > I wanted to verify if whether it's acceptable to bundle a newer squashfuse in > the SingularityCE package as a binary under our libexec dir, given that an > older squashfuse is provided by an existing squashfuse package? If so, are we > required to declare the bundling in the spec file, as we are doing for > bundled go deps in the spec? > > What has given me pause is reviewing the bundling guidelines at > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling - where > it seems, at least for libraries, that a `Provides: bundled() = > ` is required… and it’s not really clear to me whether the > discussion there about libraries can be directly applied to *executables* > that might be bundled? > > I note that the apptainer spec / package is already bundling a newer > squashfuse binary into its libexec dir without a corresponding Provides: … so > perhaps it’s fine to go ahead? Apologies if I have missed prior discussion on > this. > > https://src.fedoraproject.org/rpms/apptainer/blob/rawhide/f/apptainer.spec > https://packages.fedoraproject.org/pkgs/apptainer/apptainer/epel-7.html#files > > And it looks like their next release might be bundling a newer fuse2fs than > is in the distro e2fstools package too, plus a newer fuse-overlayfs than is > in the distro package: > > https://src.fedoraproject.org/rpms/apptainer/blob/rawhide/f/apptainer.spec > https://packages.fedoraproject.org/pkgs/apptainer/apptainer/fedora-rawhide.html#files If you are bundling any software, you need to `Provides: bundled(software)`. This is so we can easily locate affected packages when e.g. a security issue necessitates fixing it. Also, since it wasn't clear from your text above: It's (generally) alright under these circumstances to bundle the extra packages, but you need to meet certain requirements: * The code that you're bundling still has to be built in Fedora. That probably means compiling it as part of your SingularityCE build. You may not ship code that was compiled somewhere else (e.g. upstream). * If you are shipping executables exclusively for use with your package, make sure they are properly namespaced in /usr/libexec/singularityce (or similar). This is to ensure that no other package accidentally tries to use your bundled version. -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: Eliminate buildroot overrides
On Mon, Jan 22, 2024 at 2:11 PM Miro Hrončok wrote: > > On 22. 01. 24 20:04, Stephen Gallagher wrote: > > On Mon, Jan 22, 2024 at 1:55 PM Miro Hrončok wrote: > >> > >> On 22. 01. 24 19:07, Stephen Gallagher wrote: > >>> I am unaware of any remaining use cases for buildroot overrides that > >>> are not covered by side tags. If you know of any, please speak up. > >> > >> Every time somebody asks this, I say: Pull Requests CI > >> > >> I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago. > >> > >> It works in CentOS Stream, but not in Fedora. > >> > >> Without that, I sometimes need to create a buildroot override to be able to > >> test the the second package change before merging it. > >> > > > > This sounds a lot more like a workaround than a use-case, but it's > > good to know about. So thank you. > > Yes, it is. > > > Unfortunately, I feel like that workaround is dangerous, since it is > > putting untested code into the buildroot. > > In this case the PR-based CI has already passed for the build I add as a > buidlroot override. > > > I would like to see that get > > fixed properly with support for the side tags. > > I would like that very much. However, it seems it has not been a priority. > > > In the meantime, if we > > otherwise disabled free-access buildroot overrides, this would > > definitely be grounds for granting an exception. > > How would that work? Would I ask FESCo every time I need to do it? If it's something that a specific packager has justifiable cause to do on a regular basis, I think we could potentially grant them that privilege (at least until we get a proper solution in place). Or do you think this is the sort of thing where the number of people needing this access would be prohibitively high? -- ___ 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: Proposal: Eliminate buildroot overrides
On Mon, Jan 22, 2024 at 1:55 PM Miro Hrončok wrote: > > On 22. 01. 24 19:07, Stephen Gallagher wrote: > > I am unaware of any remaining use cases for buildroot overrides that > > are not covered by side tags. If you know of any, please speak up. > > Every time somebody asks this, I say: Pull Requests CI > > I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago. > > It works in CentOS Stream, but not in Fedora. > > Without that, I sometimes need to create a buildroot override to be able to > test the the second package change before merging it. > This sounds a lot more like a workaround than a use-case, but it's good to know about. So thank you. Unfortunately, I feel like that workaround is dangerous, since it is putting untested code into the buildroot. I would like to see that get fixed properly with support for the side tags. In the meantime, if we otherwise disabled free-access buildroot overrides, this would definitely be grounds for granting an exception. -- ___ 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: Proposal: Eliminate buildroot overrides
On Mon, Jan 22, 2024 at 1:55 PM Florian Weimer wrote: > > * Stephen Gallagher: > > > I am unaware of any remaining use cases for buildroot overrides that > > are not covered by side tags. If you know of any, please speak up. > > The overrides are more discoverable: > > <https://bodhi.fedoraproject.org/overrides/?expired=False> > > With side tags, you really have to know the name, or you won't be able > to find it. On the other hand, you can just make your own and tag the > builds into it, so creating yet another one isn't that much of a problem > because they expire evenutally, just like overrides. > What does that gain you, though? I'm not clear on the use-case here. Generally when there's a multi-packager effort going on for a side-tag, it's coordinated by mail or IRC between people. I'm not sure when you'd need to "discover" 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: Proposal: Eliminate buildroot overrides
On Mon, Jan 22, 2024 at 1:53 PM Florian Weimer wrote: > > * blinxen: > > >> I am unaware of any remaining use cases for buildroot overrides that > > are not covered by side tags > > > > One use case that I sometimes encounter is requiring a newer version > > for a dependency, that is submitted to Bodhi with a side-tag. Since > > the build is in a side-tag, I can't access it without building into > > that specific side-tag. Also I can't stop the Bodhi Update just to add > > my own build. In this case, I need to create a buildroot override to > > be able to build my package in my own side-tag. > > I think you can tag that build into your side tag? This should require > provenpackager privileges, as far as I understand it. > Yes, if you have privileges on the other package, I think you can just do `koji tag N-V-R` -- ___ 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
Proposal: Eliminate buildroot overrides
tl;dr: Buildroot overrides should be restricted to releng members and packagers should use on-demand side-tags instead. I'd like to ascertain whether there are any remaining use-cases for which buildroot overrides are preferable to (or necessary instead of) on-demand side-tags. We've had support for side-tags for some years now (my history-spelunking suggests 2020, but it might be longer). Some of the advantages of side-tags over the old buildroot override approach: 1) The common buildroot for packages is not polluted. Historically, one would build a new library package, tag it into a buildroot override, then build the packages that depend upon it. During this time, the (possibly backwards-incompatible) package would remain in the common buildroot, potentially impacting other packages' builds. With side-tags, the updated libraries don't affect other builds until the side tag has completed and been merged into the main release. This action also ensures that the contents of the side-tag go through Bodhi and are properly reviewed, which helps avoid cases where the packager may not have been aware of other potential breakage. 2) Side tags are easy to abandon. If, in the middle of a large update, a major issue occurs (the change needs to be backed out or priorities shift and it cannot be completed in time), the side-tag can be either aborted or ignored until later. It doesn't require going through any effort to revert changes the way that buildroot overrides would. 3) Side tags make it much easier to submit multiple, related package updates together. Prior to side-tag support, including multiple packages in a single Bodhi update was a highly manual effort. Now, as long as they were built together in the side tag, they can be easily submitted together as a single update. I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up. Otherwise, my proposal that I plan to take to FESCo is to disallow the general use of buildroot overrides in favor of side tags. Buildroot overrides themselves wouldn't go away, but they'd be restricted to members of Fedora Release Engineering in exceptional situations. Thank you in advance for your input. Documentation on side-tags and multiple-package updates: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_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: fedora-distro-aliases - The easiest way to get numbers of active Fedora releases
On Thu, Jan 18, 2024 at 10:32 AM Stephen Gallagher wrote: > > On Wed, Jan 17, 2024 at 5:58 AM Jakub Kadlcik wrote: > > > > Hello, > > I just wanted to quickly announce a small project I did in collaboration > > with the Packit folks. > > > > Do you have some tools or services that perform actions on all currently > > active Fedora releases? And do you have to manually update their list every > > time a new Fedora release is branched or EOLed? The fedora-distro-aliases > > will make your life easier. > > > > https://github.com/rpm-software-management/fedora-distro-aliases > > > > It defines aliases such as `fedora-stable`, `epel-all`, `fedora-latest`, > > etc. To evaluate them, it queries Bodhi, so they are always up-to-date (but > > the tradeoff is that it requires an internet connection). There are > > multiple examples in the project README but the usage is simple, e.g.: > > > > >>> from fedora_distro_aliases import get_distro_aliases > > >>> aliases = get_distro_aliases() > > >>> [x.namever for x in aliases["fedora-all"]] > > ['fedora-38', 'fedora-39', 'fedora-rawhide'] > > > > The package is already in Fedora, give it a shot, > > Thanks! I'll look into updating > https://github.com/sgallagher/get-fedora-releases-action with this. Scratch that, it appears that `pip3 install fedora_distro_aliases` requires installing krb5 devel packages (and compiling it) on the target system before it can be used. This had the effect in my testing of increasing the time spent running my Action from ~10s to ~240s, which is too big of an increase. Is there a good reason why you're using the complete BodhiClient interface instead of just doing simple HTTP requests against https://bodhi.fedoraproject.org/releases ? -- ___ 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-distro-aliases - The easiest way to get numbers of active Fedora releases
On Wed, Jan 17, 2024 at 5:58 AM Jakub Kadlcik wrote: > > Hello, > I just wanted to quickly announce a small project I did in collaboration with > the Packit folks. > > Do you have some tools or services that perform actions on all currently > active Fedora releases? And do you have to manually update their list every > time a new Fedora release is branched or EOLed? The fedora-distro-aliases > will make your life easier. > > https://github.com/rpm-software-management/fedora-distro-aliases > > It defines aliases such as `fedora-stable`, `epel-all`, `fedora-latest`, etc. > To evaluate them, it queries Bodhi, so they are always up-to-date (but the > tradeoff is that it requires an internet connection). There are multiple > examples in the project README but the usage is simple, e.g.: > > >>> from fedora_distro_aliases import get_distro_aliases > >>> aliases = get_distro_aliases() > >>> [x.namever for x in aliases["fedora-all"]] > ['fedora-38', 'fedora-39', 'fedora-rawhide'] > > The package is already in Fedora, give it a shot, Thanks! I'll look into updating https://github.com/sgallagher/get-fedora-releases-action with this. -- ___ 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: dnsmasq default configuration changed
On Mon, Jan 15, 2024 at 11:32 AM Kevin Kofler via devel wrote: > > Petr Menšík wrote: > > systemd-resolved is unfortunately known to broken. > [snip] > > Dnsmasq does not break DNSSEC, systemd-resolved does. > [snip] > > Unfortunately broken are clients having systemd-resolved enabled. > > How exactly is it broken? If you refer to: > https://github.com/systemd/systemd/issues/25676 > fixes for that are finally coming in now (as of 3 weeks ago). > > > I would recommend having systemd-resolved forwarded to dnsmasq, which can > > then be forwarded further. > > If you think dnsmasq should replace systemd-resolved by default, then please > propose that through the Changes process, which will also ensure the glibc > resolver, NetworkManager, and the like get configured properly for it. > Simply shipping dnsmasq with a default configuration that conflicts with > systemd-resolved is not a productive approach. > > If systemd-resolved is really broken, then it either needs to be fixed or > replaced. The former needs to be handled through systemd upstream, the > latter through the Fedora Changes process. > > > But this change should create conflict with systemd-resolved only in case > > it was improperly configured. > > But the default configuration you ship will conflict. > > > Anyway, dnsmasq will listen by default on 127.0.0.1, as every standard > > resolver does. You can use listen-address=127.0.0.53 if you like, but > > then it will conflict with systemd-resolved. > > You just wrote that you make it listen by default on all interfaces, and > then filter. This means it will conflict over the port 53. That said, > listening on the lo interface only will also conflict with systemd-resolved > or any other local resolver, so you are probably right that your change does > not change much for the default configuration, it just makes it harder (more > settings to change) to set up coexistence. 127.0.0.53 is unfortunately not > an independent interface, it is still the lo interface. > > > On 14. 01. 24 1:57, Kevin Kofler via devel wrote: > >> On a server I administer for work, I have dnsmasq serving the DNS for an > >> ocserv (OpenConnect) VPN, listening only on the VPN interface. Any > >> request for a host not within the VPN network (coming in from clients > >> with no or broken split DNS support, e.g., old GNU/Linux distros without > >> systemd- resolved, or Windows, where the OpenConnect client is still > >> unable to set up split DNS) is forwarded to systemd-resolved, which in > >> turn forwards it to the upstream DNS from the datacenter. Relying instead > >> on the filtering would not have worked exactly for the reason you > >> describe above. But that server is not running Fedora anyway. > > > > I would recommend to skip systemd-resolved stub and using > > resolv-file=/run/systemd/resolve/resolv.conf > > > > in such case. It would use servers configured by systemd-resolved, but > > without using broken port domain at address 127.0.0.53. Alternatively > > use server=127.0.0.54, which should not break incoming queries so much. > > Well, I do not see a good reason to disable systemd-resolved for the > server's own queries (which includes the forwarding queries from dnsmasq, if > the domain is not one it knows). It just works. > > > Consider using unbound as a cache for other VPN clients. dnsmasq is > > great for its integration with DHCP server, but is targeted to use > > minimal resources. Unfortunately at cost of some design issues. Unbound > > is a high quality cache, while still relatively small compared to bind's > > named.service. > > Using minimal resources is exactly what I want here. Which is why I do not > want to use dnsmasq for what systemd-resolved can do, nor unbound for what > dnsmasq can do. > > And sending the server's own queries through dnsmasq is not going to work > (not without a second instance, at least), because the VPN server is not a > VPN client, so I have the server's /etc/hosts resolve its own domain to > 127.0.0.1 (not the public IP, because services listen only on localhost and > the VPN, that is what the VPN is for), which is honored by systemd-resolved, > whereas my dnsmasq configuration overrides this to return the VPN IP to the > VPN clients querying that same domain. Sounds hackish, but works great. > Based on my reading of this thread, this change is going to break the default configuration and needs to be reverted immediately. Petr, please file a Change Proposal for Fedora *41*. You have missed the deadline for F40 System-Wide Changes (Dec. 26th) and this is absolutely NOT a self-contained Change. -- ___ 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:
Re: auditd systemd preset
On Mon, Jan 15, 2024 at 12:01 PM Steve Grubb wrote: > > Hello, > > I have a procedural question. Auditd-4.0 is ready for release. One of the > major changes is splitting rule loading from logging in the service. IOW, it > was one service doing both and now would be two services. Auditd would depend > on the rule loader, but the rule loader would not depend on auditd in case > you wanted to log to journald only. > > Auditd is one of the few programs that has a preset such that if it is > installed, it is automatically enabled. I think we'd need the same thing for > the rule loading service. I have been testing it with an addition to /usr/ > lib/systemd/system-preset/90-default.preset and it seems to work as expected. > > Would this update require just a FESCO ticket asking for the preset or does > this need both a FESCO ticket and a self-contained change notice? > The official docs are here: https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/ There's a link in that doc above to create a Bugzilla ticket with boilerplate questions that gets forwarded to the fedora-release maintainers to review the request. (Usually, me). Based on those questions, I will either go ahead and make the change if it meets the requirements or else raise it to FESCo for approval if it isn't eligible to be auto-approved. -- ___ 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: [Fedocal] Reminder meeting : ELN SIG
On Thu, Jan 11, 2024 at 7:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-01-12 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: The upcoming inheritance break for CentOS Stream 10 at the Fedora 40 Branch event. > > Source: https://calendar.fedoraproject.org//meeting/10568/ > > -- > ___ > 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: Heads up: libgweather4 to libgweather rename in rawhide
On Wed, Jan 10, 2024 at 1:38 PM Yaakov Selkowitz wrote: > > On Wed, 2024-01-10 at 19:13 +0100, Kalev Lember wrote: > > On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz > > > > wrote: > > > > > Since the previous libgweather versions were 40.y and the new > > > versions > > > are 4.4.z, shouldn't there be an Epoch? > > > > > > > I was thinking about this hard as well and I managed to convince > > myself > > that it should be fine without an epoch, for two reasons: > > > > 1) The libgweather package was last part of the F38 package set, and > > has > > been retired ever since (in F39+). Because of that, new F39 installs > > don't > > have the package, and people who have updated from F38 to either F39 > > or > > current rawhide (F40) don't have the package either (it was obsoleted > > in > > fedora-obsolete-packages). > > > > 2) This only leaves people who would do F38->F40 distro upgrade in > > the > > future, but I think this case should be fine as well because AFAIK > > both dnf > > and PackageKit use distro-sync for distro upgrades, so they handle > > downgrades just fine. > > > > Normally this should have definitely warranted an epoch, but because > > it was > > retired for a long time, I believe it should be fine without. We can > > also > > always add an epoch in the future if it turns out we missed some > > case. > > > > What do you think? > > > > > Still concerned. You've mentioned those who have already upgraded 38- > >rawhide, but what about those who *will* upgrade (e.g. post-branching) > 38->40? Since that is a supported upgrade path, and 38 had 40.0, this > will be a downgrade. If this wasn't landing until F41 the answer could > be different, but it really hasn't been out long enough. After all, > the fedora-obsolete-packages entry was set to be removed for F41 for a > reason. I agree with Yaakov here. While you're correct that the standard upgrade mechanism now defaults to using `dnf distro-sync`, it's not the ONLY upgrade path that people take. There are a huge number of users who still insist on doing a basic DNF upgrade, no matter how much documentation we write. This WILL cause issues for them and will translate into bug reports that need to be at least triaged. So please, just support a clean upgrade path with the epoch bump. > Also, what about RHEL upgrades? c9s has libgweather-40.0, this will > cause c10s to have 4.4.0. > RHEL major upgrades have special tooling, so I wouldn't worry about that. > 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
F40 Approved Change Announcement (2024-01-08)
There is no FESCo meeting scheduled for today due to the close proximity to the previous meeting. However, we have two approved Changes to announce: = Discussed and Voted in the Ticket = Change: Boost 1.83 Upgrade https://pagure.io/fesco/issue/3127 APPROVED (+7, 0, -0) Change: Podman 5 https://pagure.io/fesco/issue/3126 APPROVED (+6, 0, -0) -- ___ 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: rawhide missing xgettext: command not found
On Fri, Jan 5, 2024 at 8:16 AM Martin Gansser wrote:
>
> I'm just wondering why my packages under rawhide suddenly need gettext as a
> dependency ?
>
> should i set an if condition for rawhide ?
>
> %if 0%{?fedora} >= 40
> BuildRequires: gettext
> %endif
This shouldn't be conditional. If you require gettext, you should
`BuildRequires: gettext`.
If it worked before, it was accidental (something else you had a BR on
must have pulled it in). That subsequently changed. You can't rely on
that behavior even to remain in released Fedoras, so just add the
requirement explicitly to your specfile.
--
___
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: F40 Change Proposal: LLVM 18 (System-Wide)
On Fri, Dec 22, 2023 at 8:05 PM Aoife Moloney wrote: > > Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18 > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > Update all llvm sub-projects in Fedora Linux to version 18. > > > == Owner == > * Name: [[User:tstellar| Tom Stellard]] > * Email: > > > == Detailed Description == > All llvm sub-projects in Fedora will be updated to version 18, and > there will be a soname version change for the llvm libraries. > Compatibility packages clang17, llvm17, and lld17 will be added to > ensure that packages that currently depend on clang and llvm version > 17 libraries will continue to work. We may add other compatibility > packages too if they're determined to be necessary to maintain > functionality in other RPMS that use llvm/clang. We also plan to > retire these older compatibility packages (that we own): > > * llvm14 > * llvm15 > * llvm16 > * clang14 > * clang15 > * clang16 > * lld14 > * lld15 > * lld16 > > We will also be asking the maintainers of the following packages to > retire them if possible: > > * llvm7.0 > * llvm8.0 > * llvm11 > * llvm12 > * llvm13 > > Other notable changes: > > * clang will emit DWARF-5 by default instead of DWARF-4. This matches > the upstream default. We have been using DWARF-4 as the default for > the last few releases due to: > https://bugzilla.redhat.com/show_bug.cgi?id=2064052 > * The compatibility packages will now include the same content as the > main package. In previous releases, the compatibility packages > contained only libraries and headers, and the binaries and other > content was stripped out. These packages will be supported for use as > dependencies for other RPM packages, but not for general purpose usage > by end users. Fedora users should use Clang/LLVM 18. > * The compatibility packages added for Fedora 40 will be retired prior > to the Fedora 41 branch. > * We will be enabling Fat LTO in redhat-rpm-config if this feature is > complete in time for the upstream LLVM 18 release. Fat LTO is a > feature that allows the compiler to produce libraries that contain LTO > bitcode along side the traditional ELF binary code so that the > libraries can be linked in both LTO mode and non-LTO mode. gcc also > supports this feature and has it enabled in Fedora. In Fedora 39 and > older, with LTO enabled, clang produces binaries with only LTO > bitcode, so we need to run a post-processing script > (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code > so they can be used by other packages. Enabling Fat LTO will allow us > to remove this script and simplify the build process. > > ===LLVM Build Schedule=== > > Important Dates > > * Jan 26: Upstream: 18.0.0-rc1 Release > * Feb 6: Fedora: f40 branch created > * Feb 6: Upstream: 18.0.0-rc2 Release > * Feb 20: Fedora: f40 Beta Freeze > * Feb 20: Upstream: 18.0.0-rc3 Release > * Mar 5: Upstream: 18.0.0 Release > * Apr 2: Fedora: f40 Final Freeze > > Plan > # Build nightly trunk (LLVM 18) snapshots in > [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/packages/ > copr]. > # Build LLVM 18.0.0-rc1 in COPR. > # Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji. > # Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji. > # Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji. > # Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji. > # Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji > # Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji > # Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not > ready) as a Beta Freeze exception. > # Continue building new release candidates and pushing them to stable > until the Final Freeze. > > We are not planning to push 18.0.0-rc1 into rawhide because the > library ABI is not stabilized at that point. Typically, the ABI > stabilizes after -rc3, but there are no guarantees from upstream about > this. Given the history of minimal ABI changes after -rc3, we feel > like it's safe to push -rc3 into rawhide. The worst case scenario > would be an ABI change -rc4 or the final release that we force us to > patch LLVM to maintain compatibility with the -rc3 ABI. This scenario > would not require rebuilding LLVM library users in Fedora, so this > would not require much extra work from our team. > > Updates after 18.0.0-rc3 will generally be very small and can be done > after the Final Freeze is over. If we are late packaging release > candidates after -rc3 or the final release, we will not ask for a > Final Freeze exception, unless they contain a fix for a critical > release blocking bug. > > == Feedback == > This came in while I was on PTO, so my apologies for the late reply on it. My concern here is with the timing and its inclusion
Re: Schedule for Thursday's FESCo Meeting (2024-01-04)
= #fedora-meeting-2: FESCO (2024-01-04) = Meeting started by sgallagh at 17:00:18 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2024-01-04/fesco.2024-01-04-17.00.log.html . Meeting summary --- * Init Process (sgallagh, 17:00:34) * #3101 Change: Remove OpenSSL Compat (sgallagh, 17:09:26) * AGREED: The Change is approved, any package still depending on openssl-compat at Beta Freeze will be dropped from Fedora at that time. (+7, 0, -1) (sgallagh, 17:26:11) * New Meeting Time (sgallagh, 17:26:47) * LINK: https://whenisgood.net/agyhckd/results/sxn8wpk (sgallagh, 17:27:11) * The new FESCo meeting time will be at 1930 UTC, beginning on 2024-01-16 (sgallagh, 17:41:35) * Next Week's Chair (sgallagh, 17:43:23) * ACTION: sgallagh to send out the voting announcements on 2024-01-08 (sgallagh, 17:44:02) * ACTION: tstellar will chair the 2024-01-15 meeting and offers to mentor jistone at the same time (sgallagh, 17:49:40) * Open Floor (sgallagh, 17:49:52) * ACTION: sgallagh to update the FESCo Meeting Process with new bat-time, new bat-location (sgallagh, 17:57:15) Meeting ended at 18:01:26 UTC. Action Items * sgallagh to send out the voting announcements on 2024-01-08 * tstellar will chair the 2024-01-15 meeting and offers to mentor jistone at the same time * sgallagh to update the FESCo Meeting Process with new bat-time, new bat-location Action Items, by person --- * jistone * tstellar will chair the 2024-01-15 meeting and offers to mentor jistone at the same time * sgallagh * sgallagh to send out the voting announcements on 2024-01-08 * sgallagh to update the FESCo Meeting Process with new bat-time, new bat-location * tstellar * tstellar will chair the 2024-01-15 meeting and offers to mentor jistone at the same time * **UNASSIGNED** * (none) People Present (lines said) --- * sgallagh (80) * Son_Goku (39) * nirik (21) * dcantrell (20) * zbyszek (18) * zodbot (17) * jistone (17) * jednorozec (17) * tstellar (8) * michel-slm (7) * smooge (6) * decathorpe (4) * jonathanspw (2) * humaton (0) * mhayden (0) * Conan_Kudo (0) * Pharaoh_Atem (0) * King_InuYasha (0) * Sir_Gallantmon (0) * Eighth_Doctor (0) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions -- ___ 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
Schedule for Thursday's FESCo Meeting (2024-01-04)
Following is the list of topics that will be discussed in the FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on irc.libera.chat. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-01-04 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Change: Wget2 as wget https://pagure.io/fesco/issue/3118 APPROVED (+5, 0, -0) Change: 389 Directory Server 3.0.0 https://pagure.io/fesco/issue/3120 APPROVED (+4, 0, -0) Change: Systemd Security Hardening https://pagure.io/fesco/issue/3117 APPROVED (+4, 0, -0) Change: Linker Error On Security Issues https://pagure.io/fesco/issue/3110 APPROVED (+4, 0, -0) = Followups = #3101 Change: Remove OpenSSL Compat https://pagure.io/fesco/issue/3101 = New business = #topic New Meeting Time = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ 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: Are package-owner mail addresses working?
On Wed, Jan 3, 2024 at 8:15 AM Sergio Pascual wrote: > > El lun, 1 ene 2024 a las 13:49, Mamoru TASAKA > () escribió: > > > > Sergio Pascual wrote on 2024/01/01 21:36: > > > Hello and happy new year. > > > > > > Are package-owner mail addresses working? I have send mails to several > > > and they return a 550 error message, for example: > > > > > > 550 5.1.1 : Recipient address > > > rejected: User unknown in local recipient table > > > > > > Best, Sergio > > > -- > > > > Currently it is -maintain...@fedoraproject.org : > > > > https://fedoraproject.org/wiki/EmailAliases > > > > Great, thank you. In that case, the "senmail.to" property in the rpm > git repositories should be updated to point to the correct address. I > have checked several repositories and all have -owner addresses there. > > For example: > > $ git config sendemail.to > cfitsio-ow...@fedoraproject.org > Please file a report with Fedora Infrastructure at 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
