Re: Election Status?
On Wed, May 24, 2023 at 6:35 PM Tom Stellard wrote: > I've filed a ticket here: > > https://pagure.io/Fedora-Council/tickets/issue/457 > > Thanks Kevin and Tom for getting this flagged as a Council ticket. -- *jwf* (*he/him*) || 📧 j...@redhat.com TZ=America/New_York (UTC-4) 🕗 While I may be sending this email outside my normal office hours, I have no expectation to receive a reply outside yours. ___ 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: Election Status?
Hi Gary, hi all, Thanks for filing the Fedora Council ticket and flagging this. Ben trained me on the election process and transferred ACLs to me before his final day at Red Hat. I dropped the ball on continuity. I will run the elections this round. The timing with Red Hat Summit this week, the F38 release party next week, and ongoing Flock logistics ended up spilling over. On Wed, May 24, 2023 at 3:37 PM Tom Stellard wrote: > Maybe this has happened and I missed it, but it would nice if the Council > put > out a statement acknowledging the position has been eliminated and > explaining > what will happen next. > Matthew and I were working on something to share with the community and wanted to publish last week, but for several reasons, it hasn't been timely. I hope to have more in hand soon. -- *jwf* (*he/him*) || 📧 j...@redhat.com TZ=America/New_York (UTC-4) 🕗 While I may be sending this email outside my normal office hours, I have no expectation to receive a reply outside yours. ___ 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: Election Status?
On Wed, May 24, 2023 at 9:50 PM Mattia Verga via devel wrote: > Wait, what?? Someone at RH wakes up in the morning and decides to cut > one of the key roles (or better, THE) of Fedora community and this goes > completely unannounced, unnoticed and without any backup plan? I do understand why RedHat itself will not announce who got laid off, but the Council members should have been informed (I hope!) at the time, and should have worked on an announcement to the community, even if all they could say was "stay tuned, we are working it out". I would like to believe this will be a learning opportunity for the Council to improve their communications for the next time something impacts their group (and the Fedora community). ___ 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On 5/24/23 08:44, Zdenek Kabelac wrote: > Dne 20. 05. 23 v 22:43 Demi Marie Obenour napsal(a): >> I noticed that by default, Qubes OS has voluntary kernel preemption >> as opposed to full preemption. I found that enabling full preemption >> (preempt=full on kernel command line) makes the system significantly >> more responsive under heavy I/O load. In particular, if I build a >> kernel in a Qubes OS VM, it significantly degrades responsiveness >> without preempt=full. With preempt=full, the system remains >> responsive. The storage stack used is LVM thin provisioning on LUKS, >> and I have observed significant CPU usage in dom0 kernel threads with >> names that indicate they are related to dm-thin and dm-crypt. >> >> The kernel config used by the Qubes kernel package I use (6.1.28) is >> based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd) >> indicated that the same arguments apply to Fedora. Therefore, I am >> asking if Fedora should use full kernel preemption by default. > > > Hi Demi > > > Could you please provide 'dmsetup table' - so we could see how doe your > device stack looks like ? The output of 'dmsetup table' contains all qube names so I would prefer to not post it publicly. The device stack is NVMe -> crypt -> linear -> thin pool -> thin. > Aren't you disabling work-queues on the table line for crypt targets ? The only optional parameter passed to dm_crypt is allow_discards, so presumably no. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ 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: Election Status?
On 5/24/23 13:00, Kevin Fenzi wrote: On Wed, May 24, 2023 at 12:36:58PM -0700, Tom Stellard wrote: On 5/24/23 12:31, Gary Buhrmaster wrote: On Wed, May 24, 2023 at 7:23 PM Tom Stellard wrote: What's the process for selecting a new Program Manager? From the words that have been shared at: https://docs.fedoraproject.org/en-US/council/fpgm/ the position itself has been eliminated. The important responsibilities will (presumably) need to be passed to others on the Fedora Council, who will likely need to triage some of their current work to make room. I hope the Fedora Council members will soon share the updated roles and responsibilities of the remaining members. I agree with this. Maybe this has happened and I missed it, but it would nice if the Council put out a statement acknowledging the position has been eliminated and explaining what will happen next. Going back to the original topic, though, what is the best way to raise the issue of the elections being delayed, should I file a ticket for the Council? just as a note, our FPL (Fedora Project Leader) (Matthew) and FCA (Fedora community architect) (Justin) are both at Red Hat summit this week. So yeah, likely they are aware, but busy... but I guess a council ticket would be good to make sure. I've filed a ticket here: https://pagure.io/Fedora-Council/tickets/issue/457 -Tom kevin ___ 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: Election Status?
On 5/24/23 4:49 PM, Mattia Verga via devel wrote: Wait, what?? Someone at RH wakes up in the morning and decides to cut one of the key roles (or better, THE) of Fedora community and this goes completely unannounced, unnoticed and without any backup plan? I have seen other dumb decisions by RH about Fedora in the past, but I think this is the greatest one, both for Ben's role and for their person. I totally agree. I am pretty upset that they chose to let bcotton go. His work was top notch and I will miss him and his contributions. Losing him as the Fedora Program Manager is going to be very impacting to the project in the short to medium term. We are already seeing things fall through the cracks. What a short-sighted decision. Also finding out about this in a random thread is a bummer. There should have been an announcement. To the RH powers that be that made this decision. You chuckleheads dun goofed. Joe -- Joe Doss j...@solidadmin.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Election Status?
Il 24/05/23 21:19, Josh Boyer ha scritto: > On Wed, May 24, 2023 at 2:55 PM Peter Boy wrote: >> >> >>> Am 24.05.2023 um 20:30 schrieb Chris Murphy : >>> >>> I'm pretty sure we no longer have a program manager? >> What’s that about? > Red Hat recently announced a round of layoffs[1] and the Fedora > Program Manager role was impacted. > > Ben posted this blog: > https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/ > > josh > > [1] https://www.redhat.com/en/blog/message-red-hat-associates-today Wait, what?? Someone at RH wakes up in the morning and decides to cut one of the key roles (or better, THE) of Fedora community and this goes completely unannounced, unnoticed and without any backup plan? I have seen other dumb decisions by RH about Fedora in the past, but I think this is the greatest one, both for Ben's role and for their person. Mattia ___ 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: Election Status?
On Wed, May 24, 2023 at 12:36:58PM -0700, Tom Stellard wrote: > On 5/24/23 12:31, Gary Buhrmaster wrote: > > On Wed, May 24, 2023 at 7:23 PM Tom Stellard wrote: > > > > > What's the process for selecting a new Program Manager? > > > > From the words that have been shared at: > > https://docs.fedoraproject.org/en-US/council/fpgm/ > > the position itself has been eliminated. > > > > The important responsibilities will (presumably) > > need to be passed to others on the Fedora Council, > > who will likely need to triage some of their current > > work to make room. > > > > I hope the Fedora Council members will soon > > share the updated roles and responsibilities > > of the remaining members. > > I agree with this. > > Maybe this has happened and I missed it, but it would nice if the Council put > out a statement acknowledging the position has been eliminated and explaining > what will happen next. > > Going back to the original topic, though, what is the best way to > raise the issue of the elections being delayed, should I file a ticket for > the Council? just as a note, our FPL (Fedora Project Leader) (Matthew) and FCA (Fedora community architect) (Justin) are both at Red Hat summit this week. So yeah, likely they are aware, but busy... but I guess a council ticket would be good to make sure. kevin signature.asc Description: PGP signature ___ 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: Election Status?
On 5/24/23 12:31, Gary Buhrmaster wrote: On Wed, May 24, 2023 at 7:23 PM Tom Stellard wrote: What's the process for selecting a new Program Manager? From the words that have been shared at: https://docs.fedoraproject.org/en-US/council/fpgm/ the position itself has been eliminated. The important responsibilities will (presumably) need to be passed to others on the Fedora Council, who will likely need to triage some of their current work to make room. I hope the Fedora Council members will soon share the updated roles and responsibilities of the remaining members. I agree with this. Maybe this has happened and I missed it, but it would nice if the Council put out a statement acknowledging the position has been eliminated and explaining what will happen next. Going back to the original topic, though, what is the best way to raise the issue of the elections being delayed, should I file a ticket for the Council? -Tom ___ 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: Election Status?
On Wed, May 24, 2023 at 7:23 PM Tom Stellard wrote: > What's the process for selecting a new Program Manager? From the words that have been shared at: https://docs.fedoraproject.org/en-US/council/fpgm/ the position itself has been eliminated. The important responsibilities will (presumably) need to be passed to others on the Fedora Council, who will likely need to triage some of their current work to make room. I hope the Fedora Council members will soon share the updated roles and responsibilities of the remaining members. ___ 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: Election Status?
On Wed, May 24, 2023 at 3:23 PM Tom Stellard wrote: > > On 5/24/23 12:19, Josh Boyer wrote: > > On Wed, May 24, 2023 at 2:55 PM Peter Boy wrote: > >> > >> > >> > >>> Am 24.05.2023 um 20:30 schrieb Chris Murphy : > >>> > >>> I'm pretty sure we no longer have a program manager? > >> > >> What’s that about? > > > > Red Hat recently announced a round of layoffs[1] and the Fedora > > Program Manager role was impacted. > > > > Ben posted this blog: > > https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/ > > > > What's the process for selecting a new Program Manager? The Fedora Program Manager was a paid Red Hat position before. We do not have a process defined for selecting one from the community. There are a few people trying to spread the responsibilities around in the meantime. 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
Re: Election Status?
On 5/24/23 12:19, Josh Boyer wrote: On Wed, May 24, 2023 at 2:55 PM Peter Boy wrote: Am 24.05.2023 um 20:30 schrieb Chris Murphy : I'm pretty sure we no longer have a program manager? What’s that about? Red Hat recently announced a round of layoffs[1] and the Fedora Program Manager role was impacted. Ben posted this blog: https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/ What's the process for selecting a new Program Manager? -Tom josh [1] https://www.redhat.com/en/blog/message-red-hat-associates-today ___ 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: Election Status?
On Wed, May 24, 2023 at 2:55 PM Peter Boy wrote: > > > > > Am 24.05.2023 um 20:30 schrieb Chris Murphy : > > > > I'm pretty sure we no longer have a program manager? > > What’s that about? Red Hat recently announced a round of layoffs[1] and the Fedora Program Manager role was impacted. Ben posted this blog: https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/ josh [1] https://www.redhat.com/en/blog/message-red-hat-associates-today ___ 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: Election Status?
On Wed, May 24, 2023, at 2:55 PM, Peter Boy wrote: >> Am 24.05.2023 um 20:30 schrieb Chris Murphy : >> >> I'm pretty sure we no longer have a program manager? > > What’s that about? As I understand it, part of recent Red Hat layoffs. Red Hat and Fedora program/project managers were impacted. And also no emails or matrix messages from Ben Cotton in two weeks. He is the one who announces elections and sets up that whole system, reports the results, updates everything related to the subsequent changes, etc. That's all I know. -- Chris Murphy ___ 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: more distinct default bash prompt?
On Tue, May 23, 2023, at 1:08 AM, Jens-Ulrik Petersen wrote: > On Tue, May 23, 2023 at 12:47 PM Neal Gompa wrote: >> I actually would prefer that we color both, and make it obvious that >> "root" is special. We should account for common color-blindness >> issues, though. > > Sure, I think I agree: perhaps purple for root? I think if we avoid the need to distinguish between redish and greenish, it's OK. Redish includes red, pink, magenta. Greenish includes green, cyan, sky blue. Ergo, you can use green or red, you just don't want to make the A vs B red and green because they will look the same to anyone with a red/green color discrimination limitation. Much less common is blue/yellow. I don't have data handy but off the top of my head, tritonopia and tritonomaly cases will notice the difference between purple vs orange OK. We do have publicly available math to predict the discrimination of various nopias and nomalies; I'm not sure exactly how it's implemented in GIMP but there is a "color deficient vision" filter should give an adequate idea whether or not a design has expected/sufficient/desired differentiation of elements based on color. (We don't actually know what anyone's color experience is, as it turns out. That's what I mean by this.) https://docs.gimp.org/2.10/en/gimp-display-filter-dialog.html > > I am all for "color blind testing" (though I am not completely sure that > "color-blind" is the right term here > though I am not an a11y expert - I thought color blind is more about > differentiating different colors like green and red, > but if you mean visual impairment/contrast/readability then I completely > agree). It's common vernacular. But it's more interesting than this term because it suggests one variety or effect. There are more than several. If we consider "color blind" means total lack of color discrimination, or monochromat - they are rare. I don't even know the number. Dichromats are much more common, where these are broken down into whether it's the long, medium, or short wavelngth cone is missing (entirely). The world does have some color, we think, at least there's discrimination possible. But it's of course limited without a third color receptor. Quite a lot more common are tricromats with anomalous spectral sensitivity of one of the receptors, i.e. the long wavelength cone might be green shifted, so it's more sensitive to yellows than the "standard observer". This then questions the whole age old concept of the standard observer, and for a while now it's been suspected we need more than one standard observer - because, well, they did all these tests in the early 1900's with something like 50 people. Seriously. And that's the data still largely used today. Anyway... I tend to call it a color discrimination variance. Or limitation. Oh and there are such folks as quadchromats. They have four color receptors. And then still there's the entire non-human animal kingdom full of completely different receptor peak wavelenth sensitivities, including tetrachromats and pentachromats. > I think in the end it will come down also to wider user testing since there > are so many different terminals > and color palettes around. > > Anyway that's why I proposed green since it seems to have reasonable contrast > for both light and dark terminals (unlike blue/cyan/yellow often). > I assume that may also be why Ubuntu and Nixos went with green. Green is an efficient color choice. It tends to appear to the brightest. Part of this relates to the luminosity function of human vision which has a peak wavelength that happens to be the same as the medium wavelength photo receptor (i.e. green). So given the same amount of radiant energy emitted across the visible spectrum, green will appear to be the brightest. Light purple is OK, Blue, indigo, or yellow tends to be harder to to detect complex shapes (like letters and numbers) but I'm not sure of the reason(s). -- Chris Murphy ___ 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: Election Status?
> Am 24.05.2023 um 20:30 schrieb Chris Murphy : > > I'm pretty sure we no longer have a program manager? What’s that about? -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast ___ 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
[CoreOS] Fedora CoreOS Meeting Minutes 2023-05-24
#fedora-meeting-1: fedora_coreos_meeting Meeting started by dustymabe at 16:29:48 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2023-05-24/fedora_coreos_meeting.2023-05-24-16.29.log.html . Meeting summary --- * roll call (dustymabe, 16:29:54) * Action items from last meeting (dustymabe, 16:35:18) * there was no need for jlebon to open a ticket for rpm-ostree dnf5 investigation because one already existed at https://github.com/coreos/rpm-ostree/issues/2139 (dustymabe, 16:35:35) * dustymabe opened a ticket to track us updating our RPMs to be SPDX compatible in https://github.com/coreos/fedora-coreos-tracker/issues/1497 (dustymabe, 16:35:42) * there was already a libdnf tracker issue at https://github.com/coreos/rpm-ostree/issues/2139 (jlebon, 16:35:57) * Enable libostree automatic early pruning (dustymabe, 16:38:53) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1495 (dustymabe, 16:38:58) * AGREED: We'll enable ostree autopruning for aarch64 in next for at least 3 cycles (6 weeks) then promote to testing. We'll enable it for ppc64le right away for the streams that we decide to release ppc64le for. (dustymabe, 17:17:14) * docs re-organize sections (dustymabe, 17:17:23) * LINK: https://github.com/coreos/fedora-coreos-docs/pull/538 (dustymabe, 17:17:26) * LINK: https://docs.fedoraproject.org/en-US/fedora-coreos/storage/ > The storage page is very long for example and has "unrelated" content (travier, 17:20:52) * AGREED: We like the nested topics idea from travier and have given him a lot of feedback on possible options. (dustymabe, 17:31:15) * open floor (dustymabe, 17:31:53) * LINK: https://accounts.fedoraproject.org/group/coreos/ and https://accounts.fedoraproject.org/group/sysadmin-coreos/ (bgilbert, 17:32:21) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1487 (quentin9696[m], 17:34:24) * LINK: https://github.com/coreos/fedora-coreos-docs/issues/286 (travier, 17:40:47) * fifofonix and I are thinking of doing a "How do you Fedora CoreOS?" session at the F38 release party next week. (dustymabe, 17:43:19) Meeting ended at 17:44:24 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (123) * bgilbert (50) * jlebon (49) * travier (32) * zodbot (26) * jdoss (21) * quentin9696[m] (14) * apiaseck (6) * ravanelli (2) * jmarrero (2) * marmijo[m] (1) * JasonBrooks[m] (1) * fifofonix (1) * mnguyen (1) 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
Re: Election Status?
On Wed, May 24, 2023, at 12:03 PM, Tom Stellard wrote: > Hi, > > According to the schedule[1], the voting period was supposed to begin > on Friday, but elections.fedoraproject.org does not list any open elections > yet. Does anyone have an ETA for when voting will start? I'm pretty sure we no longer have a program manager? So I'm kinda expecting a lot of things to just silently break. I don't know what the fallback plan is. -- Chris Murphy ___ 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On Sat, May 20, 2023, at 4:43 PM, Demi Marie Obenour wrote: Therefore, I am > asking if Fedora should use full kernel preemption by default. https://pagure.io/fedora-workstation/issue/228 The outstanding questions: a. Do we need some tests that help decide this with metrics? If so what should those be? b. Should it be restricted to the desktop edition/spins? Or Fedora wide? c. How do we make the change? I have no ideas for a.) and I don't know what would be a sufficient sample of workloads across all of Fedora; or whether to separately test the different editions. I think if the answer to b.) is it should be Fedora-wide, means there's more pressure to answer yes to a.) Whereas if it's focused on desktops, perhaps less testing is needed? Still another strategy might be to just make preempt full the default Fedora wide in Rawhide with enough advance notice (like, nowish or soon after Fedora 39 branches). And once it starts causing issues, revert. That's a bit spaghetti on the wall test strategy but it's also cheap. (I am aware this is not a good strategy for testing doneness of spaghetti.) Regarding c.) gets tricky if it's not Fedora wide. The simplest case is, the change applies only to desktops, everything else remains on voluntary. The only way I'm aware of we can change it on the desktops is to set a kernel parameter. This means we need to have Anaconda set it as a boot parameter, but only for desktops. There is a debugfs facility for changing it during runtime, but this is not reliable due to debugfs being disabled when kernel lockdown is in place, which is tied to Secure Boot being enabled. Hence, the lkml thread referenced in the issue. But the lkml thread went no where (no responses). Possibly it wasn't provocative enough. Or simply there are no plans to expose this switch anywhere else. https://lkml.org/lkml/2023/4/11/1291 Conversely if even two other Fedora editions/spins/variants want some kind of opt out or opt in, it quickly gets tricky to do all that unique work setting a boot parameter, rather than just flipping the default across the board and not having a boot parameter. Anyway, it seems like it would be semi-straightforward to do it in Anaconda just for desktops using kickstart `bootloader --append=` command. https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#bootloader -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On Tue, May 9, 2023 at 11:52 AM Kevin Fenzi wrote: > Just a general answer/info here at the bottom of the thread... > > I realize our container build pipeline is not great, but it's currently > working and I will keep it working until we replace it. > > I agree we should replace it, and there's lots of options, but I don't > think this thread is the place to go back and forth about them. > > I know of at least kiwi, osbuild, some other build systems that don't > fully exist yet, switching to use quay.io, osbs2 (based on openshift4), > and probibly others. > What if we made the Toolbox container image just one more base image and built it with ImageFactory? - Integrated into the compose process - Across all architectures - No OSBS dependency The main disadvantage is that it is no longer layered, so *if* you happen to have the exact same Fedora image version around for some other reason (a big if), you save a fraction of space: Fedora 38 container - 71M compressed, 201M uncompressed Toolbox add-on layer - 232M compressed, 753M uncompressed Toolbox squashed - 291M compressed, 884M uncompressed But generally seems like it would be a win. osbuild/kiwi/whatever can be left as a separate project. - Owen ___ 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
Election Status?
Hi, According to the schedule[1], the voting period was supposed to begin on Friday, but elections.fedoraproject.org does not list any open elections yet. Does anyone have an ETA for when voting will start? Thanks, Tom [1] https://fedorapeople.org/groups/schedule/f-38/f-38-elections-tasks.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: Status of the forge macros?
If the need to package a snapshot goes away
'need' is certainly one right operative question.
whose?
Redhat's?
official Fedora packaging's?
"just us COPR users"?
i'm in the last camp.
i build/package to scratch my own projects' requirements' itch(es).
here's one, below, that depends on forge macros, making the build
manageable/trivial
no, i don't expect this to be used by anyone else, especially not official
packaging
but, without the ease/convenience forge macros, the cost of building here rises
quickly
-
%{?_pgnd_macros}
%global _owner pgnd
%global _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S --utc )
%bcond_without testcondition 1
%define _ngx_namenginx
%define _ngx_comment Nginx Web Server
%define _ngx_version 1.25.0
%define _modsecurity_version 1.0.3
%define _ngx_usr wwwrun
%define _ngx_grp www
%define _ngx_prefix /usr/local/nginx
%define _ngx_logdir /var/log/nginx
%define _ngx_confdir /usr/local/etc/ORIG-nginx
%define _ngx_moddir /usr/local/nginx-modules
%define _ngx_tmpdir %{_localstatedir}/lib/nginx/tmp
%define _ngx_cc /usr/bin/gcc
%define _ngx_cpp /usr/bin/cpp
%define _ngx_debug_flags -Wp,-D_FORTIFY_SOURCE=2
%global forgeurl0 https://github.com/nginx/nginx
Version: %{_ngx_version}
%global tag0 release-%{version}
%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%global branch1 master
%global forgeurl4 https://github.com/leev/ngx_http_geoip2_module
%global branch4 master
%global forgeurl5 https://github.com/vision5/ngx_devel_kit
%global branch5 master
%global forgeurl8 https://github.com/google/ngx_brotli
%global branch8 master
%global forgeurl9 https://github.com/nginx/njs
%global branch9 master
%global forgeurl11 https://github.com/GetPageSpeed/ngx_security_headers
%global branch11 master
%global forgeurl12 https://github.com/nulab/nginx-length-hiding-filter-module
%global branch12 master
%global forgeurl13 https://github.com/GetPageSpeed/ngx_immutable
%global branch13 master
%global forgeurl14 https://github.com/SpiderLabs/ModSecurity-nginx
%global tag14 v%{_modsecurity_version}
%forgemeta -i -a
%global dist .%{_owner}_%{_build_timestamp}.fc%{fedora}
Name: %{_ngx_name}
Release: 0%{?dist}
Summary: %{_ngx_comment}
License: BSD-2-Clause
URL: %{forgeurl0}
Source0: %{forgesource0}
Source1: %{forgesource1}
Source4: %{forgesource4}
Source5: %{forgesource5}
Source8: %{forgesource8}
Source9: %{forgesource9}
Source11: %{forgesource11}
Source12: %{forgesource12}
Source13: %{forgesource13}
Source14: %{forgesource14}
Source100: https://nginx.org/en/CHANGES
Source101: https://nginx.org/LICENSE
BuildRequires: brotli-devel
BuildRequires: coreutils
BuildRequires: gcc
BuildRequires: gd-devel
BuildRequires: git
BuildRequires: grep
BuildRequires: gnupg2
BuildRequires: libatomic_ops-devel
BuildRequires: libmaxminddb-devel
BuildRequires: libmodsecurity-devel
BuildRequires: libxml2-devel
BuildRequires: libxslt-devel
BuildRequires: make
BuildRequires: openssl-devel
BuildRequires: pcre2-devel
BuildRequires: perl-ExtUtils-Embed
BuildRequires: perl-generators
BuildRequires: pkgconf-pkg-config
BuildRequires: zlib-devel
Requires: nginx-filesystem
Requires: libmodsecurity
Requires: mod_security_crs
Requires: openssl
Requires: pcre2
BuildRequires: systemd
Requires(post):systemd
Requires(preun): systemd
Requires(postun): systemd
Provides: webserver
Conflicts: nginx-core
Conflicts: nginx-mimetypes
Obsoletes: nginx< %{_ngx_version}
Obsoletes: nginx-filesystem < %{_ngx_version}
%description
%{_ngx_comment}
%package filesystem
Summary: nginx directory layout
BuildArch: noarch
Requires(pre): shadow-utils
%description filesystem
nginx directory layout
dummy, to satisfy php-fpm reqt and prevent pulling distro pkg
%prep
%forgesetup -a
cp %{SOURCE100} %{SOURCE101} .
%build
export CFLAGS="%{_CFLAGS} -Wno-dangling-pointer"
export CPPFLAGS="%{_CFLAGS} -Wno-dangling-pointer"
export CXXFLAGS="%{_CFLAGS} -Wno-dangling-pointer"
export LDFLAGS="%{_LDFLAGS} -Wno-dangling-pointer"
export DESTDIR=%{buildroot}
cd %{_builddir}/%{name}-%{tag0}
export LUAJIT_LIB=""
export LUAJIT_INC=""
./auto/configure \
--with-debug \
--build="PGNd Custom Build" \
--user=%{_ngx_usr} --group=%{_ngx_grp} \
--prefix=%{_ngx_prefix} \
--conf-path=%{_ngx_confdir}/nginx.conf \
--error-log-path=%{_ngx_logdir}/main.error.log \
--http-log-path=%{_ngx_logdir}/main.access.log \
--modules-path=%{_ngx_moddir} \
--http-client-body-temp-path=%{_ngx_tmpdir}/client_body \
--http-proxy-temp-path=%{_ngx_tmpdir}/proxy \
--http-fastcgi-temp-path=%{_
Re: Status of the forge macros?
On Wed, May 24, 2023 at 11:13:15AM -0400, Ben Beasley wrote:
> In your example, the forge macros simplify the spec file only because a
> snapshot is involved; but the forge macros put the snapshot info in the
> Release field, which is still permissible but deprecated[1].
>
> Without the forge macros, the spec file would admittedly be a little more
> complex. I would probably do something like the following:
>
> %global commit 791953030836d39687688a8e7f1a3e708892cfa1
> %global snapdate 20230420
>
> Version: 1.2^%{snapdate}git%(echo '%{commit}' | cut -b -7)
> Release: 1%{?dist}
Minor comment:
%(c=%{commit}; echo ${c:0:7})
is a bit nicer because it doesn't require 'cut', it just uses 'echo',
which is a shell builtin.
Zbyszek
___
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: Status of the forge macros?
In your example, the forge macros simplify the spec file only because a
snapshot is involved; but the forge macros put the snapshot info in the Release
field, which is still permissible but deprecated[1].
Without the forge macros, the spec file would admittedly be a little more
complex. I would probably do something like the following:
%global commit 791953030836d39687688a8e7f1a3e708892cfa1
%global snapdate 20230420
Version: 1.2^%{snapdate}git%(echo '%{commit}' | cut -b -7)
Release: 1%{?dist}
URL: https://github.com/riscv/opensbi
Source: %{url}/archive/%{commit}/opensbi-%{commit}.tar.gz
%prep
%autosetup -n opensbi-%{commit}
If the need to package a snapshot goes away, then the utility of the forge
macros does too, as the packaging without them is perhaps even simpler than
wirh them:
Version: 1.2.12345
Release: 1%{?dist}
URL: https://github.com/riscv/opensbi
Source: %{url}/archive/v%{version}/opensbi-%{version}.tar.gz
%prep
%autosetup
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#traditional-versioning
On Wed, May 24, 2023, at 9:32 AM, Richard W.M. Jones wrote:
> On Wed, May 24, 2023 at 09:56:30AM +0200, Vitaly Zaitsev via devel wrote:
>> On 23/05/2023 19:27, Richard W.M. Jones wrote:
>> >... so today I was taking part in a package review which uses these
>> >macros and was surprised to be told that they are deprecated.
>>
>> Their author left Fedora a few years ago. They're now unmaintained
>> and may be removed soon (see FPC ticket[1]).
>>
>> [1]: https://pagure.io/packaging-committee/pull-request/1270
>
> So the issue for me is I'm considering a new package (opensbi). It is
> greatly(?) simplified by using the forge macros. Nothing in official
> documentation says that new packages shouldn't use the forge macros,
> although the link above would add such a statement. There seems to be
> disagreement in this thread about the best way forwards.
>
> Proposed spec:
> http://git.annexia.org/?p=fedora-reviews.git;a=blob;f=opensbi/opensbi.spec
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> ___
> 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: Obsolete of DNF by DNF5 in RAWHIDE
V Wed, May 24, 2023 at 02:34:57PM +0100, Richard W.M. Jones napsal(a): > On Wed, May 24, 2023 at 09:40:40AM +0200, Jaroslav Mracek wrote: > > I have great news that the upcoming release of DNF5 will obsolete DNF in > > rawhide (Fedora 39). The release is planned not before the end of May. The > > change was already announced in https://fedoraproject.org/wiki/Changes/ > > ReplaceDnfWithDnf5. > > This is quite an ambitious schedule. Bugs filed yesterday against > packages using dnf, for a change that is planned in 7 days time. If I understand the change correctly, packages are expected to RPM-depend on "dnf5", but to execute "dnf" command. That means the bugs are not actionable until the change is implemented in dnf5. -- Petr signature.asc Description: PGP signature ___ 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: Obsolete of DNF by DNF5 in RAWHIDE
On Wed, May 24, 2023 at 09:40:40AM +0200, Jaroslav Mracek wrote: > Hello, > > I have great news that the upcoming release of DNF5 will obsolete DNF in > rawhide (Fedora 39). The release is planned not before the end of May. The > change was already announced in https://fedoraproject.org/wiki/Changes/ > ReplaceDnfWithDnf5. This is quite an ambitious schedule. Bugs filed yesterday against packages using dnf, for a change that is planned in 7 days time. And 'dnf download' is not as featureful as the old version of dnf so it really does require deeper changes to supermin. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: Status of the forge macros?
On Wed, May 24, 2023 at 09:56:30AM +0200, Vitaly Zaitsev via devel wrote: > On 23/05/2023 19:27, Richard W.M. Jones wrote: > >... so today I was taking part in a package review which uses these > >macros and was surprised to be told that they are deprecated. > > Their author left Fedora a few years ago. They're now unmaintained > and may be removed soon (see FPC ticket[1]). > > [1]: https://pagure.io/packaging-committee/pull-request/1270 So the issue for me is I'm considering a new package (opensbi). It is greatly(?) simplified by using the forge macros. Nothing in official documentation says that new packages shouldn't use the forge macros, although the link above would add such a statement. There seems to be disagreement in this thread about the best way forwards. Proposed spec: http://git.annexia.org/?p=fedora-reviews.git;a=blob;f=opensbi/opensbi.spec Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
Dne 20. 05. 23 v 22:43 Demi Marie Obenour napsal(a): I noticed that by default, Qubes OS has voluntary kernel preemption as opposed to full preemption. I found that enabling full preemption (preempt=full on kernel command line) makes the system significantly more responsive under heavy I/O load. In particular, if I build a kernel in a Qubes OS VM, it significantly degrades responsiveness without preempt=full. With preempt=full, the system remains responsive. The storage stack used is LVM thin provisioning on LUKS, and I have observed significant CPU usage in dom0 kernel threads with names that indicate they are related to dm-thin and dm-crypt. The kernel config used by the Qubes kernel package I use (6.1.28) is based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd) indicated that the same arguments apply to Fedora. Therefore, I am asking if Fedora should use full kernel preemption by default. Hi Demi Could you please provide 'dmsetup table' - so we could see how doe your device stack looks like ? Aren't you disabling work-queues on the table line for crypt targets ? Regards Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20230524.n.0 changes
OLD: Fedora-Rawhide-20230523.n.1 NEW: Fedora-Rawhide-20230524.n.0 = SUMMARY = Added images:2 Dropped images: 7 Added packages: 1 Dropped packages:0 Upgraded packages: 49 Downgraded packages: 0 Size of added packages: 174.69 KiB Size of dropped packages:0 B Size of upgraded packages: 268.27 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -1.94 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20230524.n.0.x86_64.vagrant-virtualbox.box Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20230524.n.0.x86_64.vagrant-libvirt.box = DROPPED IMAGES = Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20230523.n.1.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230523.n.1.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20230523.n.1.s390x.tar.xz Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230523.n.1.iso Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230523.n.1.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20230523.n.1.iso Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230523.n.1.iso = ADDED PACKAGES = Package: rust-ratatui-0.20.1-1.fc39 Summary: Library to build rich terminal user interfaces or dashboards RPMs:rust-ratatui+crossterm-devel rust-ratatui+default-devel rust-ratatui+serde-devel rust-ratatui+termion-devel rust-ratatui-devel Size:174.69 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: academic-admin-0.8.1-2.fc39 Old package: academic-admin-0.8.1-1.fc39 Summary: Admin tool for the Academic website builder RPMs: academic-admin Size: 41.36 KiB Size change: 180 B Changelog: * Tue May 23 2023 W. Michael Petullo - 0.8.1-2 - Revise academic-admin-0.8.1-dependencies.patch to use more liberal dependencies Package: awscli-1.27.139-1.fc39 Old package: awscli-1.27.138-1.fc39 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.32 MiB Size change: 1.31 KiB Changelog: * Tue May 23 2023 Gwyn Ciesla - 1.27.139-1 - 1.27.139 Package: azure-cli-2.49.0-1.fc39 Old package: azure-cli-2.48.1-1.fc39 Summary: Microsoft Azure Command-Line Tools RPMs: azure-cli python3-azure-cli-core python3-azure-cli-telemetry python3-azure-cli-testsdk Size: 10.78 MiB Size change: 211.87 KiB Changelog: * Tue Apr 25 2023 Major Hayden - 2.48.1-2 - Allow older cryptography/pyOpenSSL * Wed May 17 2023 Major Hayden - 2.48.1-3 - Migrated to SPDX license * Tue May 23 2023 Major Hayden - 2.49.0-1 - Update to 2.49.0 rhbz#2209184 Package: babeltrace2-2.0.5-1.fc39 Old package: babeltrace2-2.0.4-9.fc39 Summary: A trace manipulation toolkit RPMs: babeltrace2 libbabeltrace2 libbabeltrace2-devel python3-bt2 Size: 5.50 MiB Size change: 8.12 KiB Changelog: * Tue May 23 2023 Michael Jeanson - 2.0.5-1 - New upstream release Package: bpftrace-0.18.0-1.fc39 Old package: bpftrace-0.17.0-1.fc38 Summary: High-level tracing language for Linux eBPF RPMs: bpftrace Size: 8.05 MiB Size change: 210.00 KiB Changelog: * Tue May 16 2023 Yaakov Selkowitz - 0.18.0-1 - Rebased to version 0.18.0 Package: iaito-5.8.6-1.fc39 Old package: iaito-5.8.4-2.fc39 Summary: GUI for radare2 reverse engineering framework RPMs: iaito Size: 5.52 MiB Size change: 3.52 KiB Package: kig-23.04.1-2.fc39 Old package: kig-23.04.1-1.fc39 Summary: Interactive Geometry RPMs: kig Size: 18.58 MiB Size change: -3.52 KiB Changelog: * Tue May 23 2023 Kevin Kofler - 23.04.1-2 - backport upstream patch for crash on startup (kde#469962, #2209374) Package: mingw-curl-8.1.1-1.fc39 Old package: mingw-curl-8.1.0-1.fc39 Summary: MinGW Windows port of curl and libcurl RPMs: mingw32-curl mingw32-curl-static mingw64-curl mingw64-curl-static Size: 1.62 MiB Size change: 595 B Changelog: * Tue May 23 2023 Sandro Mani - 8.1.1-1 - Update to 8.1.1 Package: nextcloud-client-3.8.2-1.fc39 Old package: nextcloud-client-3.8.1-1.fc39 Summary: The Nextcloud Client RPMs: nextcloud-client nextcloud-client-caja nextcloud-client-devel nextcloud-client-dolphin nextcloud-client-libs nextcloud-client-nautilus nextcloud-client-nemo Size: 12.70 MiB Size change: -163.38 KiB Changelog: * Wed May 24 2023 Mukundan Ragavan - 3.8.2-1 - Update
Re: Status of the forge macros?
On 24-05-2023 09:56, Vitaly Zaitsev via devel wrote: On 23/05/2023 19:27, Richard W.M. Jones wrote: ... so today I was taking part in a package review which uses these macros and was surprised to be told that they are deprecated. Their author left Fedora a few years ago. They're now unmaintained and may be removed soon (see FPC ticket[1]). [1]: https://pagure.io/packaging-committee/pull-request/1270 I don't infer a removal request from the ticket's title: "SourceURL: document that the forge macros are deprecated / unmaintained". Yes, it should be mentioned that they are currently unmaintained. I, for one, am a happy user of the forge macros and would like to keep using them. I probably started using them seeing examples, that did not have a deprecation warning. As mentioned in the ticket above and the PR [1] linked, separating the forge macros from redhat-rpm-config, may be the way forward. @gotmax23 already provided a PoC. I'd be willing to help out making this happen. That said, my knowledge of RPM macros is limited. [1] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/248 -- Sandro ___ 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: Status of the forge macros?
On 23/05/2023 19:27, Richard W.M. Jones wrote: ... so today I was taking part in a package review which uses these macros and was surprised to be told that they are deprecated. Their author left Fedora a few years ago. They're now unmaintained and may be removed soon (see FPC ticket[1]). [1]: https://pagure.io/packaging-committee/pull-request/1270 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
Obsolete of DNF by DNF5 in RAWHIDE
Hello, I have great news that the upcoming release of DNF5 will obsolete DNF in rawhide (Fedora 39). The release is planned not before the end of May. The change was already announced in https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5. Best regards Jaroslav Mracek ___ 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
