Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)
On Wed, Jan 5, 2022 at 7:45 PM Akira TAGOH wrote: > > On Tue, Jan 4, 2022 at 11:07 PM Kevin Kofler via devel > wrote: > > Another case is the math symbols: Should the default sans-serif math font be > > changed to Noto Sans Math? STIX is a serif font, so it probably makes sense > > to keep as the serif math font (also considering that there is, at least at > > this time, no Noto Serif Math). For cases where the distinction matters, > > see, e.g., the summation sign (clearly visible serifs), the integral sign > > (dots at the ends that are a form of serifs), or the partial derivative sign > > (constant stroke thickness in Noto Sans Math vs. variable in STIX). > > Good point. Yes, that makes sense. I'll update the proposal with it. thanks! Unfortunately Noto Sans Math doesn't have enough coverage to represent math (as und-zmth orthography defined in fontconfig). I won't do it (even if I do, it won't be picked up as a math font) and keep STIX as a default math font this time for all the generic families. > > > > > Kevin Kofler > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > > > -- > Akira TAGOH -- Akira TAGOH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, 2022-01-05 at 21:52 -0600, Chris Adams wrote: > Once upon a time, Adam Williamson said: > > I already cited one upthread - openvswitch integration. And possibly > > ifup-pre , I haven't found a NetworkManager equivalent to that > > mechanism yet, but I might be missing it. > > Do you mean /sbin/ifup-pre-local? If so, is there a difference between > that and NM's dispatcher pre-up? I can't find any documentation about > the semantics of ifup-pre-local (just that it was called near the end of > the ifup script). Hmm, yeah, looks like that may be equivalent indeed. Not sure why I didn't find it before. Thanks for the pointer. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)
On Wed, Jan 05, 2022 at 05:05:26PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/GNUToolchainF36 > > == Summary == > Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35. > > The gcc 12 is currently under development and will be included in > Fedora 36 upon release. The glibc 2.35 change will be tracked in this > top-level GNU Toolchain system-wide update. > ... > > The GNU Binutils version 2.37 and GNU Debugger version 11.1 currently > included in Fedora 35 will continue to be included in Fedora 36. There > will be a GNU Binutils version 2.38 released at the end of January, > but the inclusion will be scheduled for Fedora 37. > What's the rationale behind holding these two back? Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Once upon a time, Adam Williamson said: > I already cited one upthread - openvswitch integration. And possibly > ifup-pre , I haven't found a NetworkManager equivalent to that > mechanism yet, but I might be missing it. Do you mean /sbin/ifup-pre-local? If so, is there a difference between that and NM's dispatcher pre-up? I can't find any documentation about the semantics of ifup-pre-local (just that it was called near the end of the ifup script). -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rawhide / systemd 250: kernel-install may place kernels and config in the wrong place
On Wed, Jan 05, 2022 at 05:36:56PM -0800, Adam Williamson wrote: ... snip ... > So, my question is...do other Rawhide users have this problem, or is my > system an outlier for some reason? I have not been able to figure out > *what* created the problematic directories on my system. An earlier > systemd rc may have created /boot/efi/(machine_id) if > /boot/efi/loader/entries existed, but I don't know what might have > created /boot/efi/loader/entries . I'm pretty sure I didn't do it > myself, though. I don't have those here at all on 2 rawhide laptops... one installed in aug 2020 and one aug 2021. I wonder if it's something to do with when they were installed? 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)
On Fri, Dec 31, 2021 at 1:08 AM Neal Becker wrote: > > After seeing this proposal I tried playing with Noto Sans Mono. I > find that while it comes with many weights, none look right to me. > Language is English. > > I'm testing in emacs. My usual default is Source code sans semibold > and I find that very pleasing. I also tried Dejavu Sans Mono > semibold, which looks very similar. But if I try Noto Sans Mono, no > weight looks right. Medium is too light, and the next weight, > semibold, is too heavy. Thank you for the feedback. one question just comes to mind. Do you see any difference when you try it again with a non-variable font of Noto Sans Mono? > > On Wed, Dec 29, 2021 at 9:59 PM Robert Marcano via devel > wrote: > > > > On 12/29/21 2:20 PM, Neal Gompa wrote: > > > On Wed, Dec 29, 2021 at 12:27 PM Artem Tim wrote: > > >> > > >> Cantarell current default UI font in GNOME (Workstation) will be > > >> replaced by Noto font as well or remain? > > > > > > The current plan is to keep Cantarell for now, though GNOME upstream > > > may decide to switch to Noto as KDE Plasma did years ago. > > > > > > > Does Noto have the default font-variant-numeric as tabular-nums? (non > > proportional decimal digits) because it will be a welcomed change. > > > > The current default of Cantarell makes any number showing application a > > pain to style, specially on toolkits that use the system font but are > > unable to change font variants (Java Swing with GTK Look and Feel). > > > > Even GNOME applications aren't properly styled for number entry use > > cases. See for example Calculator where 111,111,111 looks like a smaller > > number than 99,999,999 when the are one on top of the other, because the > > font is proportional by default. > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > > > -- > Those who don't understand recursion are doomed to repeat it > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Akira TAGOH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, 2022-01-05 at 18:21 -0500, Neal Gompa wrote: > On Wed, Jan 5, 2022 at 6:19 PM Demi Marie Obenour > wrote: > > > > On 1/5/22 17:43, Michael Cronenworth wrote: > > > On 1/5/22 2:17 PM, Zbigniew Jędrzejewski-Szmek wrote: > > > > I'd say we want to get rid of both;) > > > > > > There are use-cases that NetworkManager just doesn't support that > > > network-scripts > > > does. If network-scripts is orphaned I'll probably pick it up. > > > > Which use-cases are these? Does systemd-networkd address them? > > systemd-networkd has even *less* functionality than the legacy > network-scripts. > > I am, however, curious what functionality exists in network-scripts > that doesn't in NetworkManager, since most of the newer networking > features were only implemented in ifcfg-rh on NetworkManager. I already cited one upthread - openvswitch integration. And possibly ifup-pre , I haven't found a NetworkManager equivalent to that mechanism yet, but I might be missing it. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Rawhide / systemd 250: kernel-install may place kernels and config in the wrong place
Hey folks! So I looked into an interesting bug today where with systemd 250, kernel-install started installing kernels and config snippets to the wrong place. The bug happened on my system because it had, for some reason, these directories: /boot/efi/loader/entries /boot/efi/(machine_id) where (machine_id) is the machine ID from /etc/machine-id. With systemd 250+, if either of those directories exists, kernel- install will write the boot loader config snippets to /boot/efi/loader/entries, but our grub2 config will not find them there. It will *try* to write the kernel files themselves to a subdirectory of /boot/efi/(machine_id); but if that directory doesn't exist, it won't write them anywhere at all. Either way, you won't be able to boot the new kernel. What's supposed to happen is that the config snippets should get written to /boot/loader/entries , and the kernel/initrd files installed to /boot . If you don't have either of the directories listed above, this should still happen and things should work OK. So, my question is...do other Rawhide users have this problem, or is my system an outlier for some reason? I have not been able to figure out *what* created the problematic directories on my system. An earlier systemd rc may have created /boot/efi/(machine_id) if /boot/efi/loader/entries existed, but I don't know what might have created /boot/efi/loader/entries . I'm pretty sure I didn't do it myself, though. I have a patch I can send for systemd to make this behave more like it did previously (before 250, it checked /boot before /boot/efi when deciding which layout was in use; 250 checks /boot/efi before /boot). But it'd be useful to know how many people run into this. It'd also be great if anyone knows how /boot/efi/loader/entries may have come to exist on my system. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: How do we announce new packages?
On Wed, Jan 05, 2022 at 08:28:08PM +0100, Fabio Valentini wrote: > So ... something like: > > - create a ticketing system for idea / text submissions (project with > issue tracker on pagure?) > - there, Fedora contributors can propose their cool new features / > packages for inclusion in the next article > - person / small group of people curate submissions, put together a > final article, and propose it for Fedora Magazine > > I admit that this *does* sound better than "yet-another-mailing-list", > though it's probably more work :) Yeah, that'd work. Another idea would be to rather than creating a new ticketing system, put it alongside the Magazine article proposals with #new-feature/#new-packages tag (instead of #article-idea or something). Then, the Group 3 person could ... wait, actually. Let's continue this discussion with the Fedora Magazine folks. Please join me over at https://discussion.fedoraproject.org/t/idea-for-collecting-cool-new-features-cool-new-packages-article-ideas/35761 -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Malcolm Inglis (mcinglis)
On Wednesday, January 5, 2022 4:28:19 PM CST Inglis, Malcolm via devel wrote: > I have two outstanding PRs that I think are hanging on uploading new sources > to the Lookaside Cache I have experienced this issue myself and seen it happen to other newcomers several times. It nullifies the purpose of CI for a population that it can benefit the most. It is possible to run `fedpkg new-sources --offline`, which updates the `sources` file and `.gitignore` without actually touching the lookaside cache. This saves the package maintainer who merges the PR the trouble of creating another commit (they still have to run `fedpkg new-sources` to actually upload the tarball to the lookaside cahce), but the whole area still creates unnecessary friction. @msrb submitted a PR[1] to Fedora CI to fix the issue, but it was never merged. [1]: https://github.com/fedora-ci/dist-git-build-pipeline/pull/25 -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 6:19 PM Demi Marie Obenour wrote: > > On 1/5/22 17:43, Michael Cronenworth wrote: > > On 1/5/22 2:17 PM, Zbigniew Jędrzejewski-Szmek wrote: > >> I'd say we want to get rid of both;) > > > > There are use-cases that NetworkManager just doesn't support that > > network-scripts > > does. If network-scripts is orphaned I'll probably pick it up. > > Which use-cases are these? Does systemd-networkd address them? systemd-networkd has even *less* functionality than the legacy network-scripts. I am, however, curious what functionality exists in network-scripts that doesn't in NetworkManager, since most of the newer networking features were only implemented in ifcfg-rh on NetworkManager. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/5/22 17:43, Michael Cronenworth wrote: > On 1/5/22 2:17 PM, Zbigniew Jędrzejewski-Szmek wrote: >> I'd say we want to get rid of both;) > > There are use-cases that NetworkManager just doesn't support that > network-scripts > does. If network-scripts is orphaned I'll probably pick it up. Which use-cases are these? Does systemd-networkd address them? -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: How do we announce new packages?
On Wed, Jan 5, 2022 at 10:18 PM Ben Cotton wrote: > > On Wed, Jan 5, 2022 at 2:29 PM Fabio Valentini wrote: > > > > - create a ticketing system for idea / text submissions (project with > > issue tracker on pagure?) > > - there, Fedora contributors can propose their cool new features / > > packages for inclusion in the next article > > - person / small group of people curate submissions, put together a > > final article, and propose it for Fedora Magazine > > > > I admit that this *does* sound better than "yet-another-mailing-list", > > though it's probably more work :) > > The work (assuming we're just interested in new packages) could be > shortcut a bit by looking at the SCM requests repo: > https://pagure.io/releng/fedora-scm-requests/issues > > This only gives you the new packages, not any useful text, which the > maintainer might be better positioned to provide. Although you could > just use the Description: from the spec file. But one person could > probably put this together for the month in a relatively short time. > > Of course, if we want to include stuff beyond "here's the new > packages", this breaks down. The ticket system approach is probably > the best in that case, but the hard part is going to get people to > remember to add to it. Yeah, but just looking at "new" packages probably won't be enough (whether getting the data from fedora-scm-requests, bodhi, or compose reports, etc.). There's just too much low-level stuff getting added all the time (and by that I mean packaging of new library dependencies, to keep all applications happy and up-to-date), but most of those "new" packages are not interesting to users at all. Still, I'd hope that most people who worked on some cool new feature for Fedora would want people to know about it? Opening a ticket to get it included in a "Cool new stuff in Fedora this $MONTH" listicle seems like a low barrier to get things out "to the world". Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20220104.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 24 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 102/228 (x86_64), 63/159 (aarch64) Old failures (same test failed in Fedora-Rawhide-20220103.n.0): ID: 1096184 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1096184 ID: 1096195 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/1096195 ID: 1096201 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/1096201 ID: 1096207 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/1096207 ID: 1096225 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/1096225 ID: 1096227 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/1096227 ID: 1096240 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/1096240 ID: 1096241 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/1096241 ID: 1096244 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1096244 ID: 1096245 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1096245 ID: 1096268 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1096268 ID: 1096269 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/1096269 ID: 1096274 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1096274 ID: 1096288 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1096288 ID: 1096312 Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/1096312 ID: 1096323 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1096323 ID: 1096326 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/1096326 ID: 1096340 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/1096340 ID: 1096341 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1096341 ID: 1096352 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1096352 ID: 1096365 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1096365 ID: 1096391 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1096391 ID: 1096402 Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1096402 ID: 1096404 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1096404 ID: 1096413 Test: x86_64 Workstation-upgrade desktop_fprint URL: https://openqa.fedoraproject.org/tests/1096413 ID: 1096443 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1096443 ID: 1096459 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1096459 ID: 1096515 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/1096515 ID: 1096516 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1096516 ID: 1096519 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/1096519 ID: 1096549 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1096549 ID: 1096562 Test: aarch64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/1096562 ID: 1096563 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1096563 ID: 1096565 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1096565 ID: 1096568 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1096568 ID: 1096569 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/1096569 ID: 1096570 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1096570 ID: 1096571 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/1096571 ID: 10
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/5/22 2:17 PM, Zbigniew Jędrzejewski-Szmek wrote: I'd say we want to get rid of both;) There are use-cases that NetworkManager just doesn't support that network-scripts does. If network-scripts is orphaned I'll probably pick it up. I have raised the use cases with upstream, but they haven't had time to address them. I suspect they won't unless I pony up patches, which I cannot commit the time. There's nothing inherently wrong with network-scripts. They call the latest and greatest network command tools. I'd love to switch to NetworkManager, but we're not there yet. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Mic recording issues from browsers
On Sun, Jan 2, 2022 at 7:33 PM stan via devel wrote: > On Sun, 2 Jan 2022 02:00:34 +0100 > Pawel Veselov wrote: > > Greetings! > > I've been banging my head against this wall for a while now, and would > > really appreciate some pointers. > > > > I can no longer record Google Meet meetings using RecordRTC > > (https://www.webrtc-experiment.com/RecordRTC/). This promptly became a > > problem once I upgraded from F33 to F35. I'm fairly certain this has > > therefore something to do with PipeWire. The problem occurs on every > > browser I've tried, including Chrome and Firefox. The symptoms is that > > though my audio comes through clearly to other meeting participants, > > my recording of my own voice is at the minimum chopped off, and at > > worst is mostly silence with occasional blips of syllable fragments. > > The audio coming from other participants is recorded correctly. > I have very little understanding of pipewire and no understanding of > RecordRTC. But I have a couple of suggetions you could try. > > You could try installing wireplumber, if it isn't already installed, to > see if it fixes the issue. Yeah, that didn't help. > You could try using obs-studio (available from rpmfusion) to record the > session instead of RecordRTC (not sure how that fits with your > workflow). Thank you. First, I figured if I'm to use a native recorder, I can use vokoscreenNG. However, when I tried a full test - with the mic and the audio monitor, I ran into exactly the same problem - the "monitor" stream is recorded fine, but the mic stream is practically missing. Which is good, because then this problem seems to be about recording from more than one source at the same time, and I can debug this with vokoscreenNG, rather than with Chrome, and with a much simpler reproduction path. However, I also did try obs-studio, and yes, it's a lot more complicated than what I need from it at the moment, but amazingly it works. So great, now I can also try to understand how come it does when others don't. RecordRTC is best suited for what I want since it lets me capture the contents of a tab, at least in Chrome, but I can limp on obs-studio until I figured this out. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Malcolm Inglis (mcinglis)
Is someone willing to sponsor me into the `packager` group? I'd appreciate it! (I was bouncing around the documentation for that, but it seems there's no formalized process currently - sorry if I missed something) I have two outstanding PRs that I think are hanging on uploading new sources to the Lookaside Cache: https://src.fedoraproject.org/rpms/nfs-utils/pull-request/10 , https://src.fedoraproject.org/rpms/libesmtp/pull-request/1 I've been, and hope to continue, contributing small fixes for various packages that I've noticed while working on AL packaging, and in regular personal usage. Over time, I hope to do more. Cheers On Wed, 5 Jan 2022 02:11:15 +, Malcolm Inglis wrote: > Hi Fedora developers, > > I’m looking to join your ranks 😊 I’ve made > https://pagure.io/user/mcinglis/requests?type=filed&status=all > https://src.fedoraproject.org/user/mcinglis/requests?type=filed&status=all PRs > already, and had mistakenly skipped this important step of introducing myself. > > I’m a senior software engineer on the Amazon Linux team at AWS. I’m working on > the infrastructure and tooling we use for AL packaging, and on maintenance of > our user-space packages. I joined the AL team in Q3 2021 with much excitement > for our direction regarding https://aws.amazon.com/linux/amazon-linux-2022/ > and > Fedora collaboration, and am continuing to support that direction internally. > I’ve been at Amazon since 2016, having worked in internal developer tools > organization for the majority of that time, specifically on the massive > internal build system and on enabling AWS deployments for Amazon’s developers. > Prior to Amazon, I’ve worked on software for solar power system logging and > control, and on CRUD web development projects. I studied software engineering > and mathematics at the University of Queensland for several years. > > I’ve ran Fedora (Silverblue) as my daily driver on my laptop since at least > 2011, though I experiment and dual boot various other distros on other > machines > (big fan of Guix, Alpine and OpenBSD). Fedora’s always been my trusty > workhorse, though, and I’m ashamed that it’s taken me this long to start > contributing to the project that I’ve gotten so much value from. Better late > than never! > > I live in Newcastle, WA, USA, and have lived in the Seattle area for the past > six years. I’m originally from Brisbane, Australia. I have a > http://minglis.id.au/ that’s been gathering dust, but am hoping to get around > to that soon. Outside of software which I read and nerd about perhaps too > much, > I love going places and doing things with my family. I enjoy reading science > fiction and history. I am interested in futurism, space exploration and > human-scale urban design, and appreciate good coffee and dry wine. > > Excited to get to work with you all, > > Malcolm. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedora-legal-list] Re: List of packages with problematic license
On Wed, Jan 5, 2022 at 3:45 PM Jilayne Lovejoy wrote: > > There were some license combinations (could be AND, OR, or WITH) that > are on the "good" list but a different combination might need separate > approval. > > Off top of head, I think any L/GPL WITH [exception] would fall into the > category of needing to be capture as the full license expression since > the specific exception would need to be reviewed and approved and would > be different text than another exception. > > But for any combination of previously approved license for Fedora - > e.g., "MIT OR GPL-2.0-only", "Apache-2.0 AND BSD-3-Clause" and so on - > separate listings would not be necessary - agreed? > > (and this concept needs to be documented... adding to the list of items > to better document) > > > > > However, in many cases Fedora is ok with combining something with > > GPL-2.0-or-later with BSD-3-Clause using AND. The good list we've been > > working through has some of these expressions that are a license token > > and > > then a WITH qualifier. So this may be more about ensuring that a WITH > > clause > > isn't noted as approved without also requiring the main token. > See above. Also, as per SPDX License List expression syntax (found in an > appendix to the SPDX spec), you have to have a valid license ID on the > left side of the WITH operator and a valid exception ID on the right > side (as one would expect) In related internal work being done largely by Bryan Sutula and Russell Gelvin on certain Red Hat products, there's been an effort to review for approval exceptions (what SPDX would consider exceptions) identified mainly through ScanCode Toolkit. I believe a given exception text will be approved basically without regard to the license it is associated with. If you look at the current Fedora good list, the impression is that there are a small number of uses of exceptions out there used with particular licenses (I think in all cases, licenses in the GPL family). But as Bryan and Russell have been finding, the actual picture is much bigger and more complex. I am pretty sure I've seen cases where an exception normally used with GPL version 2 is used with LGPL version 2.x. This reminds me that not too long ago I suggested that Fedora abandon any effort to note the existence of (permissive) exceptions in license tags, as being too much work for dubious gain beyond classification for the sake of classification. But the anticipated switch to SPDX identifiers raises the issue of what the license tag is actually *for*, and how much detail or specificity it ought to embody, since SPDX identifiers permit and in a sense encourage a relatively high level of detail of license description. That's a whole other topic but something I think has to be addressed as well. We might be assuming now that license tags ought to have as much detail as possible (something akin to a human review of the output of a scanner like ScanCode Toolkit on the files in a source tarball, with only limited processing); this isn't the approach consistently taken by Fedora packagers today. 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 on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/GNUToolchainF36 == Summary == Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35. The gcc 12 is currently under development and will be included in Fedora 36 upon release. The glibc 2.35 change will be tracked in this top-level GNU Toolchain system-wide update. == Owner == * Name: [[User:submachine| Arjun Shankar]] * Email: ar...@redhat.com == Detailed Description == The GNU Compiler Collection, GNU C Library, GNU Debugger, and GNU Binary Utilities make up the core part of the GNU Toolchain and it is useful for our users to transition these components as a complete implementation when making a new release of Fedora. The GNU Compiler Collection is expected to release version 12 in Q2, before the Fedora 36 release. It will contain many new features, documented here: https://gcc.gnu.org/gcc-12/changes.html. The latest point release for gcc 12 will be included in Fedora 36, this will most probably be 12.1. The GNU C Library version 2.35 is expected to be released in the beginning of February 2022; we have started closely tracking the glibc 2.35 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 36 will branch after the release of glibc 2.35. However, the mass rebuild schedule means Fedora 36 will mass rebuild (if required) before the final release of glibc 2.35, but after the ABI is frozen. The GNU Binutils version 2.37 and GNU Debugger version 11.1 currently included in Fedora 35 will continue to be included in Fedora 36. There will be a GNU Binutils version 2.38 released at the end of January, but the inclusion will be scheduled for Fedora 37. == Benefit to Fedora == Stays up to date with latest features, improvements, security and bug fixes from gcc, glibc, binutils, and gdb upstream. The goal is to track and transition to the latest components of the GNU Toolchain. == Scope == * Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb, ...) developers need to ensure that gcc, glibc, binutils, and gdb in rawhide are stable and ready for the Fedora 36 branch. * Other developers: Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. An update to GCC 12.1 would mean a new major release and could have broad scope for change. * Release engineering: A mass rebuild is strongly encouraged; [https://pagure.io/releng/issue/10515] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == The compiler, the static linker and the the library are backwards compatible with the previous version of Fedora. The upgrade to glibc-2.35 coincides with the [[Changes/RemoveNSCD|removal of nscd]]. Some source changes may be required for gcc 12 rebase: https://gcc.gnu.org/gcc-12/changes.html == How To Test == The GNU Compiler Collection has its own testsuite which is run during the package build and examined by the gcc developers before being uploaded. The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future we may also run the microbenchmark to look for performance regressions. == User Experience == Users will see improved performance, many bugfixes and improvements to POSIX compliance, Unicode 14 support, C.UTF-8 locale support, improved experimental support for C++20 and C++23, new compiler warnings and improvements to existing ones, and more. == Dependencies == All packages do not need to be rebuilt due to backwards compatibility. However, it is advantageous if a mass rebuild is performed during the Fedora 36 cycle. The mass rebuild would ensure all packages can be built with the newer compiler and core runtime. == Contingency Plan == * Contingency mechanism glibc: If glibc 2.35 proves too disruptive to compiling the distribution we could revert to 2.34, but given that Rawhide has started tracking glibc 2.35, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.34 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency mechanism for gcc: If gcc 12 proves too disruptive to compiling the distribution we could revert to gcc 11. * Contingency deadline: Fedora mass rebuild on 2022-01-19. * Blocks release? Yes, upgrading to the gcc 12 release blocks the release. Yes, upgrading to glibc 2.35 does block the release. == Documentation == The gcc manual contains the documentation for the release and doesn't need any more additional work. The glibc manual contains the documentatio
Re: F36 Change: Django 4.0 (Self-Contained Change proposal)
On Wed, 5 Jan 2022 at 11:26, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Django4.0 > > == Summary == > Update Django to version 4.0. > > == Owner == > * Name: [[User:mrunge| Matthias Runge]] > * Email: mru...@redhat.com > > > == Detailed Description == > > The Django project has regular releases about every 9 months. Django > 4.0 is a major milestone, and this Change will > bring the Fedora included version to the latest version. > > The immediate step is to bump the python-django package to version > 4.0. It is expected, that dependent packages will be > updated as well, or retired, if they haven't seen an update for long time. > > > == Benefit to Fedora == > > This updates to the latest Django version and allows to use the > distribution provided version to be used both in new developments and > also with latest Django applications. > > The upstream project has more info on what's new > https://www.djangoproject.com/weblog/2021/dec/07/django-40-released/ > > The risk of not completing this change is that the next update will be > more disruptive, Django 4.1 is planned for about the same time as > Fedora 37 will land. > > == Scope == > * Proposal owners: python-django will be updated to version 4.0. > * Other developers: > Other developers or maintainers will have to test their packages with > Django 4.0. > * Release engineering: > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > > == How To Test == > The python3-django package has to be installed in order to run the test. > > django-admin --version > 4.0 > > > == Dependencies == > Django (the fedora package name is python-django) has a few dependent > packages which should get updated (or removed) as noted above. If they > were not updated for Django 4.0, that probably means that their > upstream is not very active anymore. > Which ones? I think you need to figure out what those dependent packages are and list them in this change. > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) N/A (not a > System Wide Change) > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > == Documentation == > > Extensive upstream documentation can be found at > https://docs.djangoproject.com/en/4.0/ > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Updating c4core to 0.1.8 with SONAME bump
On 2022-01-12, or slightly later, I plan to update c4core to version 0.1.8 [1] in Rawhide, which will bump the SONAME version. There are currently no dependent packages; c4core will be a dependency for rapidyaml, which is not yet packaged. [1] https://src.fedoraproject.org/rpms/c4core/pull-request/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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20220104.n.0 changes
OLD: Fedora-Rawhide-20220103.n.0 NEW: Fedora-Rawhide-20220104.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 88 Downgraded packages: 0 Size of added packages: 25.23 KiB Size of dropped packages:0 B Size of upgraded packages: 2.14 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 93.63 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: SoaS raw-xz armhfp Path: Spins/armhfp/images/Fedora-SoaS-Rawhide-20220104.n.0.armhfp.raw.xz Image: Python_Classroom raw-xz aarch64 Path: Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20220104.n.0.aarch64.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: php-league-container4-4.2.0-1.fc36 Summary: A fast and intuitive dependency injection container version 4 RPMs:php-league-container4 Size:25.23 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Lmod-8.6.4-1.fc36 Old package: Lmod-8.6.2-1.fc36 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.11 MiB Size change: 775 B Changelog: * Tue Jan 04 2022 Orion Poplawski - 8.6.4-1 - Update to 8.6.4 Package: OpenEXR_Viewers-2.3.0-8.fc36 Old package: OpenEXR_Viewers-2.3.0-7.fc35 Summary: Viewers programs for OpenEXR RPMs: OpenEXR_Viewers OpenEXR_Viewers-docs Size: 762.87 KiB Size change: 1.89 KiB Changelog: * Mon Jan 03 2022 Nicolas Chauvet - 2.3.0-8 - Fix FTBFS Package: R-flexiblas-3.0.0-5.fc36 Old package: R-flexiblas-3.0.0-4.fc35 Summary: FlexiBLAS API Interface for R RPMs: R-flexiblas Size: 188.23 KiB Size change: 2.10 KiB Changelog: * Mon Jan 03 2022 I??aki ??car - 3.0.0-5 - Fix test Package: WALinuxAgent-2.5.0.2-1.fc36 Old package: WALinuxAgent-2.3.1.1-2.fc35 Summary: The Microsoft Azure Linux Agent RPMs: WALinuxAgent WALinuxAgent-udev Size: 465.46 KiB Size change: 16.23 KiB Changelog: * Sun Jan 02 2022 Vitaly Kuznetsov - 2.5.0.2-1 - Update to 2.5.0.2 (#2008699) Package: We10X-icon-theme-0-18.20211227gitbd21e213.fc36 Old package: We10X-icon-theme-0-17.20211016gite23d4d82.fc36 Summary: Colorful icon theme inspired by Microsoft Windows 10 aesthetic RPMs: We10X-icon-theme Size: 4.29 MiB Size change: 117.21 KiB Changelog: * Mon Jan 03 2022 Artur Frenszek-Iwicki - 0-18.20211227gitebd21e21 - Update to latest git snapshot (2021-12-27) Package: antimicrox-3.2.1-1.fc36 Old package: antimicrox-3.2.0-1.fc36 Summary: Graphical program used to map keyboard buttons and mouse controls to a gamepad RPMs: antimicrox Size: 4.64 MiB Size change: 51.93 KiB Changelog: * Mon Jan 03 2022 Gergely Gombos - 3.2.1-1 - 3.2.1 Package: arc-theme-20220102-1.fc36 Old package: arc-theme-20211018-1.fc36 Summary: Flat theme with transparent elements RPMs: arc-theme arc-theme-plank Size: 761.30 KiB Size change: 90.75 KiB Changelog: * Mon Jan 03 2022 Mukundan Ragavan - 20220102-1 - Update to 20220108 Package: asymptote-2.74-1.fc36 Old package: asymptote-2.70-4.fc35 Summary: Descriptive vector graphics language RPMs: asymptote Size: 21.69 MiB Size change: -1.50 MiB Changelog: * Tue Nov 09 2021 Jerry James - 2.70-5 - Drop XEmacs support in F36 and later - Rationalize ownership of (X)Emacs directories * Wed Dec 29 2021 Tom Callaway - 2.73-1 - update to 2.73 * Mon Jan 03 2022 Tom Callaway - 2.74-1 - update to 2.74 Package: calibre-5.34.0-1.fc36 Old package: calibre-5.33.2-1.fc36 Summary: E-book converter and library manager RPMs: calibre Size: 69.46 MiB Size change: -58.31 KiB Changelog: * Mon Jan 03 2022 Kevin Fenzi 5.34.0-1 - Update to 5.34.0. Fixes rhbz#2033747 Package: candy-icon-theme-0-25.20211226gitb1a79d8e.fc36 Old package: candy-icon-theme-0-24.20211003gitdfd05c13.fc36 Summary: Sweet gradient icon theme RPMs: candy-icon-theme Size: 827.93 KiB Size change: 25.37 KiB Changelog: * Mon Jan 03 2022 Artur Frenszek-Iwicki - 0-25.20211226gitb1a79d8e - Update to latest upstream snapshot Package: codespell-2.1.0-3.fc36 Old package: codespell-2.1.0-2.fc35 Summary: Fix common misspellings in text files RPMs: codespell Size: 167.35 KiB Size change: -208 B Changelog: * Mon Jan 03 2022 Bastien Nocera - 2.1.0-3 + codespell-2.1.0-3 - Fix CC-BY-SA shortname (#2036037) Package: composer-2.2.3-1.fc36 Old package: composer-2.2.1-1.fc36 Summary: Dependency Manager for PHP RPMs: composer Size: 455.27 KiB Size change: 688 B Changelog: * Sat Jan 01 2022 Remi Collet - 2.2.3-1 - update to 2.2.3 Package: cpufetch-1.01-1.fc36 Old package: cpufetch-1.00-1.fc36 Summary: Simple tool for determining CPU architecture RPMs:
Re: How do we announce new packages?
On Wed, Jan 5, 2022 at 2:29 PM Fabio Valentini wrote: > > - create a ticketing system for idea / text submissions (project with > issue tracker on pagure?) > - there, Fedora contributors can propose their cool new features / > packages for inclusion in the next article > - person / small group of people curate submissions, put together a > final article, and propose it for Fedora Magazine > > I admit that this *does* sound better than "yet-another-mailing-list", > though it's probably more work :) The work (assuming we're just interested in new packages) could be shortcut a bit by looking at the SCM requests repo: https://pagure.io/releng/fedora-scm-requests/issues This only gives you the new packages, not any useful text, which the maintainer might be better positioned to provide. Although you could just use the Description: from the spec file. But one person could probably put this together for the month in a relatively short time. Of course, if we want to include stuff beyond "here's the new packages", this breaks down. The ticket system approach is probably the best in that case, but the hard part is going to get people to remember to add to it. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Self Introduction: Luna Jernberg
Hey! i just recognized and remembered i never sent an introduction to the devel list for Fedora I am Luna Jernberg 31 year old non binary person Already helped out with Fedora since Nest 2020 and done some Swedish translations for anaconda, Fedora Websites and dnf also has done some Kernel and QA testings for upcoming kernel .rpms and Fedora Releases since 32-33 and used Fedora since version 24 or 26 as an user on a Gitlab server and some other things i guess some of you have seen me around if not Hello //Luna bittin Jernberg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Subject: Self Introduction: Vanessa Christopher
Welcome to the community Vanessa. On Wed, 5 Jan 2022, 8:16 pm Vanessa Christopher, wrote: > Hi, I'm Vanessa Christopher from Cameroon, an Outreachy intern with Fedora > "Extend and improve NeuroFedora's user consumable artefacts". It's really > been exciting learning new stuffs and joining 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 on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wednesday, January 5, 2022 3:17:43 PM EST Zbigniew Jędrzejewski-Szmek
wrote:
> On Wed, Jan 05, 2022 at 11:37:48AM -0800, Adam Williamson wrote:
> > On Wed, 2022-01-05 at 20:19 +0100, Xose Vazquez Perez wrote:
> > > Neal Gompa wrote:
> > > > > On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto
> > > > > > > > >
> > > > > a big BTW when /etc/init.d/network will be removed or migrate to
> > > > > systemd scripts ?
> > > > >
> > > > > rpm -qf /etc/init.d/network --qf "packge =
> > > > > %{sourcerpm}\nsub-package =
> > > > > %{name}\n"
> > > > >
> > > > > packge = initscripts-10.09-1.fc34.src.rpm
> > > > > sub-package = network-scripts
> > > >
> > > > It's deprecated and expected to be retired eventually. I doubt a
> > > > "port" would ever happen.
> > >
> > > initscripts is needed by audit: https://bugzilla.redhat.com/2029105
>
> This is really sad. Somebody who understands audit should just propose a
> solution. We shouldn't have an archaic technology kept in Fedora for 10
> years because of one package.
I think audit can be moved to initscripts-service in Fedora. Would that help?
-Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 05, 2022 at 11:37:48AM -0800, Adam Williamson wrote:
> On Wed, 2022-01-05 at 20:19 +0100, Xose Vazquez Perez wrote:
> > Neal Gompa wrote:
> >
> > > > On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto > > > wrote:
> > > > ...
> > > >
> > > > a big BTW when /etc/init.d/network will be removed or migrate to
> > > > systemd scripts ?
> > > >
> > > > rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
> > > > %{name}\n"
> > > >
> > > > packge = initscripts-10.09-1.fc34.src.rpm
> > > > sub-package = network-scripts
> >
> > > It's deprecated and expected to be retired eventually. I doubt a
> > > "port" would ever happen.
> >
> > initscripts is needed by audit: https://bugzilla.redhat.com/2029105
This is really sad. Somebody who understands audit should just propose a
solution.
We shouldn't have an archaic technology kept in Fedora for 10 years
because of one package.
> network-scripts was split out as a subpackage specifically so it can be
> excluded from images/installs or deprecated without doing the same to
> the whole of initscripts, IIRC.
I'd say we want to get rid of both ;)
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Subject: Self Introduction: Vanessa Christopher
On Wed, Jan 05, 2022 at 07:15:49PM -, Vanessa Christopher wrote: > Hi, I'm Vanessa Christopher from Cameroon, an Outreachy intern with Fedora > "Extend and improve NeuroFedora's user consumable artefacts". It's really > been exciting learning new stuffs and joining the Fedora community. Awesome -- welcome! Let me know if you need anything! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, 2022-01-05 at 20:19 +0100, Xose Vazquez Perez wrote:
> Neal Gompa wrote:
>
> > > On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto > > wrote:
> > > ...
> > >
> > > a big BTW when /etc/init.d/network will be removed or migrate to
> > > systemd scripts ?
> > >
> > > rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
> > > %{name}\n"
> > >
> > > packge = initscripts-10.09-1.fc34.src.rpm
> > > sub-package = network-scripts
>
> > It's deprecated and expected to be retired eventually. I doubt a
> > "port" would ever happen.
>
> initscripts is needed by audit: https://bugzilla.redhat.com/2029105
network-scripts was split out as a subpackage specifically so it can be
excluded from images/installs or deprecated without doing the same to
the whole of initscripts, IIRC.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: How do we announce new packages?
On Sun, Jan 2, 2022 at 10:09 PM Matthew Miller wrote: > > On Sun, Jan 02, 2022 at 09:19:15PM +0100, Dan Čermák wrote: > > > new-tech? noteable-changes? new-features? > > > > fedora-contributor-announce? > > Heh: see > https://discussion.fedoraproject.org/t/proposal-contributor-announce-mailing-list/28902 > It's still on my todo list! > > But going back up in this thread ... this particular topic isn't supposed to > be contributor-focused, is it? So I don't think that's the right solution. > > I'm also hesitant about creating _even more_ lists.* I think that tends to > just fragment things more and create more confusion. So, I have two > counter-proposals: > > 1. As previously noted, Fedora Magazine seems like the right audience. Maybe >interested people could collect topics and run an article every month? > > 2. There is a News & Announcements category on Fedora Discussion, and people >can get that by email if they want (or as an RSS feed), and can have >granular control over what they're notified on by tag. We can create a >#new-and-cool tag or similar. So ... something like: - create a ticketing system for idea / text submissions (project with issue tracker on pagure?) - there, Fedora contributors can propose their cool new features / packages for inclusion in the next article - person / small group of people curate submissions, put together a final article, and propose it for Fedora Magazine I admit that this *does* sound better than "yet-another-mailing-list", though it's probably more work :) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Neal Gompa wrote: On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto It's deprecated and expected to be retired eventually. I doubt a "port" would ever happen. initscripts is needed by audit: https://bugzilla.redhat.com/2029105 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Subject: Self Introduction: Vanessa Christopher
Hi, I'm Vanessa Christopher from Cameroon, an Outreachy intern with Fedora "Extend and improve NeuroFedora's user consumable artefacts". It's really been exciting learning new stuffs and joining 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
On Tue, Jan 4, 2022 at 4:10 PM Caolán McNamara wrote: > > On Thu, 2021-12-30 at 09:21 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Dec 29, 2021 at 10:01:49AM -0500, Ben Cotton wrote: > > > == How To Test == > > > 1. Check if default installed dictionary path is > > > `/usr/share/hunspell/` instead of `/usr/share/myspell/` > > > > Would it be possible to symlink /usr/share/myspell → hunspell > > so that applications which try to use the old path still work? > > IIRC replacing a dir with a symlink needs special care > https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/ True, but note that the method documented in the Packaging Guidelines no longer works either (IIRC, because DNF aborts the RPM transaction early due to "file conflicts", as it cannot know that those would be fixed by running the scriptlets). We'll probably need to figure out a "modern" way to handle this scenario ... Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Review swaps
On Wed, Jan 5, 2022 at 8:34 AM Artur Frenszek-Iwicki wrote: > I've got this sad boy waiting for a review since September: > https://bugzilla.redhat.com/show_bug.cgi?id=2006685 > pasdoc - Documentation generator for Pascal source code > > I can review some C, C++, Pascal or shell stuff in return. Since Arthur Bols is giving me some freebies (thank you, Arthur!), I will do the same for you. -- Jerry James http://www.jamezone.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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: File collision advice
On 05. 01. 22 17:38, Jerry James wrote: On Tue, Jan 4, 2022 at 11:59 PM Elliott Sales de Andrade wrote: I think these packages are wrong upstream. The `sphinxcontrib` directory is provided by python3-sphinx, and it specifically doesn't have `__init__.py` there. Those extensions should not be adding one, so as to keep the implicit namespace package nature of that directory: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages By the contents of the files, it appears they are trying to force it to be a pkg_resources-style namespace package: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#pkg-resources-style-namespace-packages But since Sphinx didn't do that in the first place, there's no guarantee that other packages will contain `__init__.py` (and indeed most do not). Thank you, Elliott. That's good information. I will talk to the respective upstreams about this. For more context about Python namesapace packages, I recommend this thread (particularly Toshio's reply): https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/message/ZCNEOK2M67HMHM73CRSB3A4FDFLIS6I2/ As for the `sphinxcontrib` directory provided by python3-sphinx - note that this is done downstream. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, 2022-01-05 at 15:58 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jan 05, 2022 at 09:48:13AM -0500, Neal Gompa wrote:
> > On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto wrote:
> > >
> > > a big BTW when /etc/init.d/network will be removed or migrate to
> > > systemd scripts ?
> > >
> > > rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
> > > %{name}\n"
> > >
> > > packge = initscripts-10.09-1.fc34.src.rpm
> > > sub-package = network-scripts
> > >
> >
> > It's deprecated and expected to be retired eventually. I doubt a
> > "port" would ever happen.
>
> Yes, nobody wants to touch those scripts with a ten foot pole, so they
> are on life support. NetworkManager and systemd-networkd are the replacements.
Has anyone given openvswitch an equivalent level of integration with
NetworkManager as it has with init.d/network yet? I'm still using that
in production for the Fedora openQA servers:
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/tasks/tap-setup.yml
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/files/ifcfg-br0
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/templates/ifcfg-tap.j2
In particular, last I checked, there was no good way to replace the
ifup-pre mechanism from init.d/network which I use to ensure the tap
devices are created when we bring up the tap interfaces:
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/files/ifup-pre-local
I don't know if anyone else even knows that things exists (I'd never
heard of it before I found it) but it sure is useful. :)
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: File collision advice
On Tue, Jan 4, 2022 at 11:59 PM Elliott Sales de Andrade wrote: > I think these packages are wrong upstream. The `sphinxcontrib` > directory is provided by python3-sphinx, and it specifically doesn't > have `__init__.py` there. Those extensions should not be adding one, > so as to keep the implicit namespace package nature of that directory: > https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages > > By the contents of the files, it appears they are trying to force it > to be a pkg_resources-style namespace package: > https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#pkg-resources-style-namespace-packages > > But since Sphinx didn't do that in the first place, there's no > guarantee that other packages will contain `__init__.py` (and indeed > most do not). Thank you, Elliott. That's good information. I will talk to the respective upstreams about this. Regards, -- Jerry James http://www.jamezone.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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
I don't think we need to go too deep on this cloud-init vs Ignition thread; but you have a great message here and I just want to clarify some points, everything else you said here is fair/accurate/relevant from my PoV. On Wed, Jan 5, 2022, at 10:41 AM, David Duncan wrote: > In most of those > cases it has mostly been replaced in an effort to decrease boot time and > limit functionality to force the configuration time into the user space > instead of prior to instance service checks or replace the slower python > with a compiled language like go. In the case of Ignition, that's not quite accurate. I was not personally involved in the creation of Ignition, but this document lays it all out: https://coreos.github.io/ignition/rationale/ In particular, I don't think the boot speed or programming languages were ever a big part of the argument. To pick one thing from that list, the Ignition philosopy of running in the initramfs meaning you avoid whole large classes of race conditions of trying to re-configure the system in the middle of boot was a primary component.(OK this does lead into the language thing a bit I guess because no one sane wants Python in their initramfs, but it's really not about 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 on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: Django 4.0 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Django4.0 == Summary == Update Django to version 4.0. == Owner == * Name: [[User:mrunge| Matthias Runge]] * Email: mru...@redhat.com == Detailed Description == The Django project has regular releases about every 9 months. Django 4.0 is a major milestone, and this Change will bring the Fedora included version to the latest version. The immediate step is to bump the python-django package to version 4.0. It is expected, that dependent packages will be updated as well, or retired, if they haven't seen an update for long time. == Benefit to Fedora == This updates to the latest Django version and allows to use the distribution provided version to be used both in new developments and also with latest Django applications. The upstream project has more info on what's new https://www.djangoproject.com/weblog/2021/dec/07/django-40-released/ The risk of not completing this change is that the next update will be more disruptive, Django 4.1 is planned for about the same time as Fedora 37 will land. == Scope == * Proposal owners: python-django will be updated to version 4.0. * Other developers: Other developers or maintainers will have to test their packages with Django 4.0. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == == How To Test == The python3-django package has to be installed in order to run the test. django-admin --version 4.0 == Dependencies == Django (the fedora package name is python-django) has a few dependent packages which should get updated (or removed) as noted above. If they were not updated for Django 4.0, that probably means that their upstream is not very active anymore. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == Extensive upstream documentation can be found at https://docs.djangoproject.com/en/4.0/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Peter Robinson writes:
> On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa wrote:
>>
>> On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton wrote:
>> >
>> > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
>> >
>> > == Summary ==
>> > Do not not include NetworkManager support for legacy network
>> > configuration files by in new installations.
>> >
>> > == Owner ==
>> > * Name: [[User:Lkundrak| Lubomir Rintel]]
>> > * Email:
>> >
>> > * Name: Ana Cabral
>> > * Email:
>> >
>> > * Name: [[User:Thaller| Thomas Haller]]
>> > * Email:
>> >
>> > == Detailed Description ==
>> > Long ago, network was configured using "network" service.
>> > It was essentially a set of shell scripts, that sourced snippets of
>> > configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
>> > files").
>> > The ifcfg files compatible with the legacy network service were kept
>> > when NetworkManager was intruduced.
>> >
>> > As the NetworkManager feature set was expanding beyond what the legacy
>> > network service could support,
>> > the ifcfg files written by NetworkManager could no longer be
>> > guarranteed to be compatible.
>> > NetworkManager eventually gained support for connection types
>> > completely unknown to the legacy network service
>> > and ended up using a more streamlined configuration file format for
>> > those, known as keyfile.
>> >
>> > NetworkManager's use of various configuration files is, in fact,
>> > configurable and extensible with plugins.
>> > Prior to Fedora 33, NetworkManager by default was configured to enable
>> > both ifcfg files and keyfiles, with the former taking precedence when
>> > possible.
>> > The precedence changed in
>> > [https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
>> > Fedora 33] to perfer keyfile.
>> >
>> > The precedence has an effect when a network connection profile is created.
>> > Once the connection profile exists, NetworkManager is unable to
>> > convert the profile to a different configuration backend.
>> > This makes it necessary for NetworkManager to support the same feature
>> > set in all configuration backend.
>> > Given the complexities stemming from historical legacy of ifcfg files
>> > not being designed (or documented) in a
>> > particularly forward-looking way, this has been a huge and complex
>> > effort with all the downsides:
>> > The ifcfg support code is huge (130K lines, not counting the enormous
>> > test suite) and has constantly been a source of bugs.
>> >
>> > == Benefit to Fedora ==
>> > This change removes a body of code that has a large cost in terms of
>> > bugs and maintenance at questionable benefit.
>> >
>> > It slightly reduces the default installation size.
>> >
>> > == Scope ==
>> > * Proposal owners: Split the ifcfg plugin into a subpackage package.
>> > Make sure the ifcfg plugin stays on upgrades. Provide a migration
>> > tool.
>> >
>> > * Other developers: N/A
>> >
>> > * Release engineering: N/A
>> >
>> > * Policies and guidelines: N/A
>> >
>> > * Trademark approval: N/A
>> >
>> > * Alignment with Objectives: N/A
>> >
>> > == Upgrade/compatibility impact ==
>> > For the time being the ifcfg plugin is kept around, albeit in a
>> > sub-package that's not included in new installations.
>> > The appropriate RPM tags will ensure the sub-package with the ifcfg
>> > plugin will be installed on upgrades.
>> > A migration tool will be provided for users who'd like to remove the
>> > legacy package from their systems after upgrade.
>> >
>> > == How To Test ==
>> > N/A.
>> > The keyfiles are used by default in Fedora 33 already, so any problem
>> > with them would've already been spotted.
>> >
>> > == User Experience ==
>> > Regular users will not notice anything.
>> > Users of old installations with ifcfg files will get the new
>> > sub-package on upgrade.
>> > New systems will default to use keyfiles, which is not something
>> > regulars user would notice.
>> >
>> > System integrators and administrators might use tools that drop in
>> > ifcfg files during automated installations (e.g. via kickstart or a
>> > configration management tool).
>> > They will need to update their tools -- convert the ifcfg files to
>> > keyfiles or include the ifcfg sub-package.
>> >
>> > == Dependencies ==
>> > N/A
>> >
>> > == Contingency Plan ==
>> > * Contingency mechanism: If it turns out we can't drop support for
>> > ifcfg files by default, we can either fold the ifcfg sub-package back
>> > into the main NetworkManager package or make sure it is included in
>> > new installations (via comps change).
>> > * Contingency deadline: Any time.
>> > * Blocks release? No.
>> >
>> > == Documentation ==
>> > We'll need to write the documentation for the migration tool.
>> > Perhaps also something the sysadmins wondering why their ifcfg files
>> > don't work anymore could find and refer to.
>> >
>> > TODO: Update this once it's done.
>> >
>> > == Release Notes ==
>> > We'll need to include a paragraph about this in the release notes.
>> >
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
> Am 05.01.2022 um 15:05 schrieb Ben Cotton : > > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles > > == Summary == > Do not not include NetworkManager support for legacy network > configuration files by in new installations. > > …… > == Scope == > * Proposal owners: Split the ifcfg plugin into a subpackage package. > Make sure the ifcfg plugin stays on upgrades. Provide a migration > tool. > > ... > == Documentation == > We'll need to write the documentation for the migration tool. > Perhaps also something the sysadmins wondering why their ifcfg files > don't work anymore could find and refer to. > A big ++ for that. It is overdue. However, as members of the Server WG, I wonder how many administration tools, scripts and Ansible playbooks will need to be rewritten. We would need to have a test case as soon as possible and communicate that very actively in the sysadmin community. Otherwise, the surprise could be quite big. The migration tool comes a bit short in the proposal. I consider it an indispensable prerequisite for this change. From my own unfortunate experience - I have had to make this change manually on our servers without a migration tool and without dedicated documentation - how tedious and time-consuming such an action is. And while I can't help with a migration tool, I can offer help for documentation, just in case there's a shortage of hands. And may be, we should be prepared to postpone the change to F37 but provide the migration tool and doc with F36. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 05, 2022 at 09:48:13AM -0500, Neal Gompa wrote:
> On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto wrote:
> >
> > a big BTW when /etc/init.d/network will be removed or migrate to
> > systemd scripts ?
> >
> > rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
> > %{name}\n"
> >
> > packge = initscripts-10.09-1.fc34.src.rpm
> > sub-package = network-scripts
> >
>
> It's deprecated and expected to be retired eventually. I doubt a
> "port" would ever happen.
Yes, nobody wants to touch those scripts with a ten foot pole, so they
are on life support. NetworkManager and systemd-networkd are the replacements.
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: List of packages with problematic license
On Mon, 3 Jan 2022 at 18:35, Miro Hrončok wrote: > > On 03. 01. 22 19:16, Sérgio Basto wrote: > > Testing rpm-specs/hibernate-jpa-2.0-api.spec > > No terminal defined for 'E' at line 1 col 2 > > > > EPL and BSD > > > > What is the problem with this one ? > > There is no EPL in https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses > -- just EPL-1.0 and EPL-2.0. > EPL was renamed as EPL-1.0 when EPL-2.0 was added. However, don't make the assumption that your project is still EPL-1.0 because many projects moved over to EPL-2.0 after it was released. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 10:33 AM Jonathan Lebon wrote: > > On Wed, Jan 5, 2022 at 9:46 AM Neal Gompa wrote: > > That is not Ignition configuring the network, that is *you* knowing > > what an NM file looks like and dropping it in. With cloud-init, it > > knows how to access cloud provider data sources to get configuration > > information and translate it into machine network configuration > > automatically. > > For cloud-specific network configuration, we've been steering towards > nm-cloud-setup. We do ship it in FCOS, but it's currently disabled by > default pending more CI coverage and investigation: > > https://github.com/coreos/fedora-coreos-tracker/issues/320#issuecomment-791492732 > > So in theory, we could drop support for ifcfg as this Change is > proposing and add nm-cloud-setup. (And that'd take us closer to being > able to move from cloud-init to Ignition, which would have lots of > benefits too.) > What benefits? From a usability, workflow, and configuration perspective, Ignition is a *huge* downgrade from cloud-init for most Fedora Cloud users. From my own experience with Fedora CoreOS in OpenStack and AWS, Ignition configuration is clunky and awkward compared to the nicely integrated support for cloud-init. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Upgrade to Django 4.0.x for F36
On Wed, Jan 05, 2022 at 10:17:29AM -0500, Ben Cotton wrote: > On Wed, Jan 5, 2022 at 10:12 AM Neal Gompa wrote: > > > > Uhh, I think something is wrong here. How did this article get > > namespaced like that? Maybe Ben could help fix it if you don't know > > how that happened... > > Fixed. Thank you. -- Matthias Runge ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
IMA signing questions
Hi folks, I want to add "intro to IMA signing" instructions to https://docs.pagure.org/koji/signing/ . I wrote a basic PR at https://pagure.io/koji/pull-request/3206 but it lacks technical details. - How do I generate my own new keypair so I can IMA-sign an RPM? - Can I use my existing GPG keypair? - How do I IMA-sign files in an RPM locally (apart from Koji)? (Is it the --signfiles option from rpmsign(8)?) - How do I inspect the IMA signatures on an existing RPM? - When I gpg-sign an RPM with "Key A" and IMA-sign an RPM with "Key B", does Koji "know" about Key B at all? - Ken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Review swaps
I've got this sad boy waiting for a review since September: https://bugzilla.redhat.com/show_bug.cgi?id=2006685 pasdoc - Documentation generator for Pascal source code I can review some C, C++, Pascal or shell stuff in return. A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 9:46 AM Neal Gompa wrote: > That is not Ignition configuring the network, that is *you* knowing > what an NM file looks like and dropping it in. With cloud-init, it > knows how to access cloud provider data sources to get configuration > information and translate it into machine network configuration > automatically. For cloud-specific network configuration, we've been steering towards nm-cloud-setup. We do ship it in FCOS, but it's currently disabled by default pending more CI coverage and investigation: https://github.com/coreos/fedora-coreos-tracker/issues/320#issuecomment-791492732 So in theory, we could drop support for ifcfg as this Change is proposing and add nm-cloud-setup. (And that'd take us closer to being able to move from cloud-init to Ignition, which would have lots of benefits too.) I'm not sure how wide the gap between nm-cloud-setup and cloud-init is today 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Review swaps
On 5/01/2022 05:04, Jerry James wrote: On Sat, Jan 1, 2022 at 7:46 PM Jerry James wrote: Happy New Year! I am in need of some package reviews to update parts of the OCaml stack: - ocaml-bos: https://bugzilla.redhat.com/show_bug.cgi?id=2031160 - ocaml-odoc-parser: https://bugzilla.redhat.com/show_bug.cgi?id=2036395 - ocaml-mdx: https://bugzilla.redhat.com/show_bug.cgi?id=2036396 - ocaml-stdcompat: https://bugzilla.redhat.com/show_bug.cgi?id=2036398 - ocaml-pyml: https://bugzilla.redhat.com/show_bug.cgi?id=2036399 Let me know what I can review for you. Regards, I am still in need of these reviews. If you don't need a package reviewed, I am willing to swap for something else. Let me know what I can do for you. Happy new year to you too! It's been a bit quiet over the holidays, so I'll take the reviews. I currently don't need any help, if someone else is in desperate need of a review (and maybe didn't have time to do yours), maybe you could help them! Arthur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Upgrade to Django 4.0.x for F36
On Wed, Jan 5, 2022 at 10:12 AM Neal Gompa wrote: > > Uhh, I think something is wrong here. How did this article get > namespaced like that? Maybe Ben could help fix it if you don't know > how that happened... Fixed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Upgrade to Django 4.0.x for F36
On Wed, Jan 5, 2022 at 10:10 AM Matthias Runge wrote: > > On Wed, Jan 05, 2022 at 05:19:24AM -0500, Neal Gompa wrote: > > > As hinted in the previous paragraph, I am not involved in any > > > development connected to Django for some time now. This is a cry for > > > help. The whole Django stack in Fedora could use more helping hands. > > > Upstream is very good at providing insights, timelines etc and also > > > keeps it secured. That also means, there are regular updates. > > > > > > > It's fine to do. We haven't branched yet. You should file a > > Self-Contained Change for it. The deadline for those is January 18. > > So, go for it! > > Done: https://fedoraproject.org/wiki/Fedora_Project_Wiki:Changes/Django4.0 > Uhh, I think something is wrong here. How did this article get namespaced like that? Maybe Ben could help fix it if you don't know how that happened... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Upgrade to Django 4.0.x for F36
On Wed, Jan 05, 2022 at 05:19:24AM -0500, Neal Gompa wrote: > > As hinted in the previous paragraph, I am not involved in any > > development connected to Django for some time now. This is a cry for > > help. The whole Django stack in Fedora could use more helping hands. > > Upstream is very good at providing insights, timelines etc and also > > keeps it secured. That also means, there are regular updates. > > > > It's fine to do. We haven't branched yet. You should file a > Self-Contained Change for it. The deadline for those is January 18. > So, go for it! Done: https://fedoraproject.org/wiki/Fedora_Project_Wiki:Changes/Django4.0 Thanks! -- Matthias Runge ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: List of packages with problematic license
On Mon, Jan 03, 2022 at 12:12:38PM -0500, Matthew Miller wrote: On Mon, Jan 03, 2022 at 01:26:33PM +0100, Miroslav Suchý wrote: The License tag was never formally defined. If we agree that there can be anything, then let it be. The Pending PR here updates that to: SPDX License identifier or expression (from our "Good" list). https://pagure.io/packaging-committee/pull-request/1142#_1__38 Although given the context here, I note that that's ambiguous about whether the _whole expression_ must be on the list — I don't think that's the intention! I think in some cases, it may be. As our discussions on this PR have noted, Fedora may approve an expression but not all expressions that SPDX can represent. So the objective is more about using the tokens and expression syntax defined by SPDX, but then we have our list of approved expressions. This is also necessary because we need to maintain our own list of LicenseRef tokens for things we approve for Fedora but that do not have an upstream SPDX token. However, in many cases Fedora is ok with combining something with GPL-2.0-or-later with BSD-3-Clause using AND. The good list we've been working through has some of these expressions that are a license token and then a WITH qualifier. So this may be more about ensuring that a WITH clause isn't noted as approved without also requiring the main token. IANAL, so take my comments with that in mind. And this is where I defer to Jilayne for the actual expertise here. :) -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 9:52 AM David Cantrell wrote:
>
> On Wed, Jan 05, 2022 at 09:22:20AM -0500, Neal Gompa wrote:
> >On Wed, Jan 5, 2022 at 9:11 AM Peter Robinson wrote:
> >>
> >> On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa wrote:
> >> >
> >> > On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton wrote:
> >> > >
> >> > > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
> >> > >
> >> > > == Summary ==
> >> > > Do not not include NetworkManager support for legacy network
> >> > > configuration files by in new installations.
> >> > >
> >> > > == Owner ==
> >> > > * Name: [[User:Lkundrak| Lubomir Rintel]]
> >> > > * Email:
> >> > >
> >> > > * Name: Ana Cabral
> >> > > * Email:
> >> > >
> >> > > * Name: [[User:Thaller| Thomas Haller]]
> >> > > * Email:
> >> > >
> >> > > == Detailed Description ==
> >> > > Long ago, network was configured using "network" service.
> >> > > It was essentially a set of shell scripts, that sourced snippets of
> >> > > configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
> >> > > files").
> >> > > The ifcfg files compatible with the legacy network service were kept
> >> > > when NetworkManager was intruduced.
> >> > >
> >> > > As the NetworkManager feature set was expanding beyond what the legacy
> >> > > network service could support,
> >> > > the ifcfg files written by NetworkManager could no longer be
> >> > > guarranteed to be compatible.
> >> > > NetworkManager eventually gained support for connection types
> >> > > completely unknown to the legacy network service
> >> > > and ended up using a more streamlined configuration file format for
> >> > > those, known as keyfile.
> >> > >
> >> > > NetworkManager's use of various configuration files is, in fact,
> >> > > configurable and extensible with plugins.
> >> > > Prior to Fedora 33, NetworkManager by default was configured to enable
> >> > > both ifcfg files and keyfiles, with the former taking precedence when
> >> > > possible.
> >> > > The precedence changed in
> >> > > [https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
> >> > > Fedora 33] to perfer keyfile.
> >> > >
> >> > > The precedence has an effect when a network connection profile is
> >> > > created.
> >> > > Once the connection profile exists, NetworkManager is unable to
> >> > > convert the profile to a different configuration backend.
> >> > > This makes it necessary for NetworkManager to support the same feature
> >> > > set in all configuration backend.
> >> > > Given the complexities stemming from historical legacy of ifcfg files
> >> > > not being designed (or documented) in a
> >> > > particularly forward-looking way, this has been a huge and complex
> >> > > effort with all the downsides:
> >> > > The ifcfg support code is huge (130K lines, not counting the enormous
> >> > > test suite) and has constantly been a source of bugs.
> >> > >
> >> > > == Benefit to Fedora ==
> >> > > This change removes a body of code that has a large cost in terms of
> >> > > bugs and maintenance at questionable benefit.
> >> > >
> >> > > It slightly reduces the default installation size.
> >> > >
> >> > > == Scope ==
> >> > > * Proposal owners: Split the ifcfg plugin into a subpackage package.
> >> > > Make sure the ifcfg plugin stays on upgrades. Provide a migration
> >> > > tool.
> >> > >
> >> > > * Other developers: N/A
> >> > >
> >> > > * Release engineering: N/A
> >> > >
> >> > > * Policies and guidelines: N/A
> >> > >
> >> > > * Trademark approval: N/A
> >> > >
> >> > > * Alignment with Objectives: N/A
> >> > >
> >> > > == Upgrade/compatibility impact ==
> >> > > For the time being the ifcfg plugin is kept around, albeit in a
> >> > > sub-package that's not included in new installations.
> >> > > The appropriate RPM tags will ensure the sub-package with the ifcfg
> >> > > plugin will be installed on upgrades.
> >> > > A migration tool will be provided for users who'd like to remove the
> >> > > legacy package from their systems after upgrade.
> >> > >
> >> > > == How To Test ==
> >> > > N/A.
> >> > > The keyfiles are used by default in Fedora 33 already, so any problem
> >> > > with them would've already been spotted.
> >> > >
> >> > > == User Experience ==
> >> > > Regular users will not notice anything.
> >> > > Users of old installations with ifcfg files will get the new
> >> > > sub-package on upgrade.
> >> > > New systems will default to use keyfiles, which is not something
> >> > > regulars user would notice.
> >> > >
> >> > > System integrators and administrators might use tools that drop in
> >> > > ifcfg files during automated installations (e.g. via kickstart or a
> >> > > configration management tool).
> >> > > They will need to update their tools -- convert the ifcfg files to
> >> > > keyfiles or include the ifcfg sub-package.
> >> > >
> >> > > == Dependencies ==
> >> > > N/A
> >> > >
> >> > > == Contingency Plan ==
> >> > > * Contingency mechanism: If it turns out we can't drop support for
> >> > > ifcfg files by d
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 05, 2022 at 09:22:20AM -0500, Neal Gompa wrote:
On Wed, Jan 5, 2022 at 9:11 AM Peter Robinson wrote:
On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa wrote:
>
> On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
> >
> > == Summary ==
> > Do not not include NetworkManager support for legacy network
> > configuration files by in new installations.
> >
> > == Owner ==
> > * Name: [[User:Lkundrak| Lubomir Rintel]]
> > * Email:
> >
> > * Name: Ana Cabral
> > * Email:
> >
> > * Name: [[User:Thaller| Thomas Haller]]
> > * Email:
> >
> > == Detailed Description ==
> > Long ago, network was configured using "network" service.
> > It was essentially a set of shell scripts, that sourced snippets of
> > configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
> > files").
> > The ifcfg files compatible with the legacy network service were kept
> > when NetworkManager was intruduced.
> >
> > As the NetworkManager feature set was expanding beyond what the legacy
> > network service could support,
> > the ifcfg files written by NetworkManager could no longer be
> > guarranteed to be compatible.
> > NetworkManager eventually gained support for connection types
> > completely unknown to the legacy network service
> > and ended up using a more streamlined configuration file format for
> > those, known as keyfile.
> >
> > NetworkManager's use of various configuration files is, in fact,
> > configurable and extensible with plugins.
> > Prior to Fedora 33, NetworkManager by default was configured to enable
> > both ifcfg files and keyfiles, with the former taking precedence when
> > possible.
> > The precedence changed in
> >
[https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
> > Fedora 33] to perfer keyfile.
> >
> > The precedence has an effect when a network connection profile is created.
> > Once the connection profile exists, NetworkManager is unable to
> > convert the profile to a different configuration backend.
> > This makes it necessary for NetworkManager to support the same feature
> > set in all configuration backend.
> > Given the complexities stemming from historical legacy of ifcfg files
> > not being designed (or documented) in a
> > particularly forward-looking way, this has been a huge and complex
> > effort with all the downsides:
> > The ifcfg support code is huge (130K lines, not counting the enormous
> > test suite) and has constantly been a source of bugs.
> >
> > == Benefit to Fedora ==
> > This change removes a body of code that has a large cost in terms of
> > bugs and maintenance at questionable benefit.
> >
> > It slightly reduces the default installation size.
> >
> > == Scope ==
> > * Proposal owners: Split the ifcfg plugin into a subpackage package.
> > Make sure the ifcfg plugin stays on upgrades. Provide a migration
> > tool.
> >
> > * Other developers: N/A
> >
> > * Release engineering: N/A
> >
> > * Policies and guidelines: N/A
> >
> > * Trademark approval: N/A
> >
> > * Alignment with Objectives: N/A
> >
> > == Upgrade/compatibility impact ==
> > For the time being the ifcfg plugin is kept around, albeit in a
> > sub-package that's not included in new installations.
> > The appropriate RPM tags will ensure the sub-package with the ifcfg
> > plugin will be installed on upgrades.
> > A migration tool will be provided for users who'd like to remove the
> > legacy package from their systems after upgrade.
> >
> > == How To Test ==
> > N/A.
> > The keyfiles are used by default in Fedora 33 already, so any problem
> > with them would've already been spotted.
> >
> > == User Experience ==
> > Regular users will not notice anything.
> > Users of old installations with ifcfg files will get the new
> > sub-package on upgrade.
> > New systems will default to use keyfiles, which is not something
> > regulars user would notice.
> >
> > System integrators and administrators might use tools that drop in
> > ifcfg files during automated installations (e.g. via kickstart or a
> > configration management tool).
> > They will need to update their tools -- convert the ifcfg files to
> > keyfiles or include the ifcfg sub-package.
> >
> > == Dependencies ==
> > N/A
> >
> > == Contingency Plan ==
> > * Contingency mechanism: If it turns out we can't drop support for
> > ifcfg files by default, we can either fold the ifcfg sub-package back
> > into the main NetworkManager package or make sure it is included in
> > new installations (via comps change).
> > * Contingency deadline: Any time.
> > * Blocks release? No.
> >
> > == Documentation ==
> > We'll need to write the documentation for the migration tool.
> > Perhaps also something the sysadmins wondering why their ifcfg files
> > don't work anymore could find and refer to.
> >
> > TODO: Update this once it's done.
> >
> > == Release Notes ==
> > We'll need to include a paragraph about this in the release notes.
> >
> > TODO: Update this with the act
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 9:48 AM Colin Walters wrote: > > > > On Wed, Jan 5, 2022, at 9:05 AM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles > > > > == Summary == > > Do not not include NetworkManager support for legacy network > > configuration files by in new installations. > > It'd be nice to note this Change is actually just doing for other editions > what Fedora CoreOS has been doing since it was created. xref > https://github.com/coreos/fedora-coreos-tracker/issues/24 and > https://github.com/coreos/fedora-coreos-config/commit/a3834830db2ff66e43690a18c585cd96c48af826#diff-a75be0683fa944e789e6a29b3661927410a368e4b5f18c9cd283af4169abc5d4 > > (Which would be, what the 3rd change for which we're just doing elsewhere > what FCOS is doing already now? The rpmdb move, the sulogin one, and now > this) I think that shows that you're not doing this properly. None of those changes in FCOS were done as Changes. Nobody knew they were happening until *other* people started digging and proposing them. Nobody had a chance to judge them on their merits because you just *did* them and told nobody. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto wrote:
>
> a big BTW when /etc/init.d/network will be removed or migrate to
> systemd scripts ?
>
> rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
> %{name}\n"
>
> packge = initscripts-10.09-1.fc34.src.rpm
> sub-package = network-scripts
>
It's deprecated and expected to be retired eventually. I doubt a
"port" would ever happen.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022, at 9:05 AM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles > > == Summary == > Do not not include NetworkManager support for legacy network > configuration files by in new installations. It'd be nice to note this Change is actually just doing for other editions what Fedora CoreOS has been doing since it was created. xref https://github.com/coreos/fedora-coreos-tracker/issues/24 and https://github.com/coreos/fedora-coreos-config/commit/a3834830db2ff66e43690a18c585cd96c48af826#diff-a75be0683fa944e789e6a29b3661927410a368e4b5f18c9cd283af4169abc5d4 (Which would be, what the 3rd change for which we're just doing elsewhere what FCOS is doing already now? The rpmdb move, the sulogin one, and now 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 9:42 AM Colin Walters wrote: > > > > On Wed, Jan 5, 2022, at 9:22 AM, Neal Gompa wrote: > > > > There are none. Ignition deliberately cannot configure the network, > > This is not true. > https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-network-configuration/#_via_ignition > That is not Ignition configuring the network, that is *you* knowing what an NM file looks like and dropping it in. With cloud-init, it knows how to access cloud provider data sources to get configuration information and translate it into machine network configuration automatically. > > and as a CoreOS tool, it is incapable of configuring the system to the > > same level cloud-init can anyway. > > Er, what? Please see the whole above doc. A big part of the idea of CoreOS > is that our tooling is symmetric across bare metal and cloud - and in the > bare metal world, *lots* of nontrivial networking problems come up. It's > hard to understate the amount of time we've spent on this. > IMO we have a quite cool model now - our live ISO *is* CoreOS too, but > doesn't require networking by default to fetch Ignition. You can inject an > Ignition config into the ISO, and then e.g. boot that ISO in systems like > vSphere or attach via IPMI virtual media etc. That Ignition config can then > contain an Ignition config for the *real* system with static IP address, etc. > Your model only works as long as *you* do the configuration. You solve *nothing* for networking as you defer to the user to provide the raw configuration. Your symmetry was done by eliminating the ability for Ignition to handle cloud system stuff to process and configure directly. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
a big BTW when /etc/init.d/network will be removed or migrate to
systemd scripts ?
rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
%{name}\n"
packge = initscripts-10.09-1.fc34.src.rpm
sub-package = network-scripts
On Wed, 2022-01-05 at 09:05 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
>
> == Summary ==
> Do not not include NetworkManager support for legacy network
> configuration files by in new installations.
>
> == Owner ==
> * Name: [[User:Lkundrak| Lubomir Rintel]]
> * Email:
>
> * Name: Ana Cabral
> * Email:
>
> * Name: [[User:Thaller| Thomas Haller]]
> * Email:
>
> == Detailed Description ==
> Long ago, network was configured using "network" service.
> It was essentially a set of shell scripts, that sourced snippets of
> configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
> files").
> The ifcfg files compatible with the legacy network service were kept
> when NetworkManager was intruduced.
>
> As the NetworkManager feature set was expanding beyond what the legacy
> network service could support,
> the ifcfg files written by NetworkManager could no longer be
> guarranteed to be compatible.
> NetworkManager eventually gained support for connection types
> completely unknown to the legacy network service
> and ended up using a more streamlined configuration file format for
> those, known as keyfile.
>
> NetworkManager's use of various configuration files is, in fact,
> configurable and extensible with plugins.
> Prior to Fedora 33, NetworkManager by default was configured to enable
> both ifcfg files and keyfiles, with the former taking precedence when
> possible.
> The precedence changed in
> [
> https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
> Fedora 33] to perfer keyfile.
>
> The precedence has an effect when a network connection profile is
> created.
> Once the connection profile exists, NetworkManager is unable to
> convert the profile to a different configuration backend.
> This makes it necessary for NetworkManager to support the same feature
> set in all configuration backend.
> Given the complexities stemming from historical legacy of ifcfg files
> not being designed (or documented) in a
> particularly forward-looking way, this has been a huge and complex
> effort with all the downsides:
> The ifcfg support code is huge (130K lines, not counting the enormous
> test suite) and has constantly been a source of bugs.
>
> == Benefit to Fedora ==
> This change removes a body of code that has a large cost in terms of
> bugs and maintenance at questionable benefit.
>
> It slightly reduces the default installation size.
>
> == Scope ==
> * Proposal owners: Split the ifcfg plugin into a subpackage package.
> Make sure the ifcfg plugin stays on upgrades. Provide a migration
> tool.
>
> * Other developers: N/A
>
> * Release engineering: N/A
>
> * Policies and guidelines: N/A
>
> * Trademark approval: N/A
>
> * Alignment with Objectives: N/A
>
> == Upgrade/compatibility impact ==
> For the time being the ifcfg plugin is kept around, albeit in a
> sub-package that's not included in new installations.
> The appropriate RPM tags will ensure the sub-package with the ifcfg
> plugin will be installed on upgrades.
> A migration tool will be provided for users who'd like to remove the
> legacy package from their systems after upgrade.
>
> == How To Test ==
> N/A.
> The keyfiles are used by default in Fedora 33 already, so any problem
> with them would've already been spotted.
>
> == User Experience ==
> Regular users will not notice anything.
> Users of old installations with ifcfg files will get the new
> sub-package on upgrade.
> New systems will default to use keyfiles, which is not something
> regulars user would notice.
>
> System integrators and administrators might use tools that drop in
> ifcfg files during automated installations (e.g. via kickstart or a
> configration management tool).
> They will need to update their tools -- convert the ifcfg files to
> keyfiles or include the ifcfg sub-package.
>
> == Dependencies ==
> N/A
>
> == Contingency Plan ==
> * Contingency mechanism: If it turns out we can't drop support for
> ifcfg files by default, we can either fold the ifcfg sub-package back
> into the main NetworkManager package or make sure it is included in
> new installations (via comps change).
> * Contingency deadline: Any time.
> * Blocks release? No.
>
> == Documentation ==
> We'll need to write the documentation for the migration tool.
> Perhaps also something the sysadmins wondering why their ifcfg files
> don't work anymore could find and refer to.
>
> TODO: Update this once it's done.
>
> == Release Notes ==
> We'll need to include a paragraph about this in the release notes.
>
> TODO: Update this with the actual release note text.
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> __
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022, at 9:22 AM, Neal Gompa wrote: > > There are none. Ignition deliberately cannot configure the network, This is not true. https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-network-configuration/#_via_ignition > and as a CoreOS tool, it is incapable of configuring the system to the > same level cloud-init can anyway. Er, what? Please see the whole above doc. A big part of the idea of CoreOS is that our tooling is symmetric across bare metal and cloud - and in the bare metal world, *lots* of nontrivial networking problems come up. It's hard to understate the amount of time we've spent on this. IMO we have a quite cool model now - our live ISO *is* CoreOS too, but doesn't require networking by default to fetch Ignition. You can inject an Ignition config into the ISO, and then e.g. boot that ISO in systems like vSphere or attach via IPMI virtual media etc. That Ignition config can then contain an Ignition config for the *real* system with static IP address, etc. > Fedora Cloud will be forced to disable NetworkManager and switch back > to legacy network-scripts if this Change goes through. I don't want to > do that, because I *like* NetworkManager. I guess I could modify the > NetworkManager config as part of creating the image to re-enable the > ifcfg-rh plugin, but if it is getting disabled by default, it's not > far away from getting dropped. That's for the NM team to answer, but it certainly seems to me the simplest thing is for cloud-init systems to re-enable the ifcfg-rh backend for now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 9:11 AM Peter Robinson wrote:
>
> On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa wrote:
> >
> > On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
> > >
> > > == Summary ==
> > > Do not not include NetworkManager support for legacy network
> > > configuration files by in new installations.
> > >
> > > == Owner ==
> > > * Name: [[User:Lkundrak| Lubomir Rintel]]
> > > * Email:
> > >
> > > * Name: Ana Cabral
> > > * Email:
> > >
> > > * Name: [[User:Thaller| Thomas Haller]]
> > > * Email:
> > >
> > > == Detailed Description ==
> > > Long ago, network was configured using "network" service.
> > > It was essentially a set of shell scripts, that sourced snippets of
> > > configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
> > > files").
> > > The ifcfg files compatible with the legacy network service were kept
> > > when NetworkManager was intruduced.
> > >
> > > As the NetworkManager feature set was expanding beyond what the legacy
> > > network service could support,
> > > the ifcfg files written by NetworkManager could no longer be
> > > guarranteed to be compatible.
> > > NetworkManager eventually gained support for connection types
> > > completely unknown to the legacy network service
> > > and ended up using a more streamlined configuration file format for
> > > those, known as keyfile.
> > >
> > > NetworkManager's use of various configuration files is, in fact,
> > > configurable and extensible with plugins.
> > > Prior to Fedora 33, NetworkManager by default was configured to enable
> > > both ifcfg files and keyfiles, with the former taking precedence when
> > > possible.
> > > The precedence changed in
> > > [https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
> > > Fedora 33] to perfer keyfile.
> > >
> > > The precedence has an effect when a network connection profile is created.
> > > Once the connection profile exists, NetworkManager is unable to
> > > convert the profile to a different configuration backend.
> > > This makes it necessary for NetworkManager to support the same feature
> > > set in all configuration backend.
> > > Given the complexities stemming from historical legacy of ifcfg files
> > > not being designed (or documented) in a
> > > particularly forward-looking way, this has been a huge and complex
> > > effort with all the downsides:
> > > The ifcfg support code is huge (130K lines, not counting the enormous
> > > test suite) and has constantly been a source of bugs.
> > >
> > > == Benefit to Fedora ==
> > > This change removes a body of code that has a large cost in terms of
> > > bugs and maintenance at questionable benefit.
> > >
> > > It slightly reduces the default installation size.
> > >
> > > == Scope ==
> > > * Proposal owners: Split the ifcfg plugin into a subpackage package.
> > > Make sure the ifcfg plugin stays on upgrades. Provide a migration
> > > tool.
> > >
> > > * Other developers: N/A
> > >
> > > * Release engineering: N/A
> > >
> > > * Policies and guidelines: N/A
> > >
> > > * Trademark approval: N/A
> > >
> > > * Alignment with Objectives: N/A
> > >
> > > == Upgrade/compatibility impact ==
> > > For the time being the ifcfg plugin is kept around, albeit in a
> > > sub-package that's not included in new installations.
> > > The appropriate RPM tags will ensure the sub-package with the ifcfg
> > > plugin will be installed on upgrades.
> > > A migration tool will be provided for users who'd like to remove the
> > > legacy package from their systems after upgrade.
> > >
> > > == How To Test ==
> > > N/A.
> > > The keyfiles are used by default in Fedora 33 already, so any problem
> > > with them would've already been spotted.
> > >
> > > == User Experience ==
> > > Regular users will not notice anything.
> > > Users of old installations with ifcfg files will get the new
> > > sub-package on upgrade.
> > > New systems will default to use keyfiles, which is not something
> > > regulars user would notice.
> > >
> > > System integrators and administrators might use tools that drop in
> > > ifcfg files during automated installations (e.g. via kickstart or a
> > > configration management tool).
> > > They will need to update their tools -- convert the ifcfg files to
> > > keyfiles or include the ifcfg sub-package.
> > >
> > > == Dependencies ==
> > > N/A
> > >
> > > == Contingency Plan ==
> > > * Contingency mechanism: If it turns out we can't drop support for
> > > ifcfg files by default, we can either fold the ifcfg sub-package back
> > > into the main NetworkManager package or make sure it is included in
> > > new installations (via comps change).
> > > * Contingency deadline: Any time.
> > > * Blocks release? No.
> > >
> > > == Documentation ==
> > > We'll need to write the documentation for the migration tool.
> > > Perhaps also something the sysadmins wondering why their ifcfg files
> > > don't work anymore could find and refer to.
>
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa wrote:
>
> On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
> >
> > == Summary ==
> > Do not not include NetworkManager support for legacy network
> > configuration files by in new installations.
> >
> > == Owner ==
> > * Name: [[User:Lkundrak| Lubomir Rintel]]
> > * Email:
> >
> > * Name: Ana Cabral
> > * Email:
> >
> > * Name: [[User:Thaller| Thomas Haller]]
> > * Email:
> >
> > == Detailed Description ==
> > Long ago, network was configured using "network" service.
> > It was essentially a set of shell scripts, that sourced snippets of
> > configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
> > files").
> > The ifcfg files compatible with the legacy network service were kept
> > when NetworkManager was intruduced.
> >
> > As the NetworkManager feature set was expanding beyond what the legacy
> > network service could support,
> > the ifcfg files written by NetworkManager could no longer be
> > guarranteed to be compatible.
> > NetworkManager eventually gained support for connection types
> > completely unknown to the legacy network service
> > and ended up using a more streamlined configuration file format for
> > those, known as keyfile.
> >
> > NetworkManager's use of various configuration files is, in fact,
> > configurable and extensible with plugins.
> > Prior to Fedora 33, NetworkManager by default was configured to enable
> > both ifcfg files and keyfiles, with the former taking precedence when
> > possible.
> > The precedence changed in
> > [https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
> > Fedora 33] to perfer keyfile.
> >
> > The precedence has an effect when a network connection profile is created.
> > Once the connection profile exists, NetworkManager is unable to
> > convert the profile to a different configuration backend.
> > This makes it necessary for NetworkManager to support the same feature
> > set in all configuration backend.
> > Given the complexities stemming from historical legacy of ifcfg files
> > not being designed (or documented) in a
> > particularly forward-looking way, this has been a huge and complex
> > effort with all the downsides:
> > The ifcfg support code is huge (130K lines, not counting the enormous
> > test suite) and has constantly been a source of bugs.
> >
> > == Benefit to Fedora ==
> > This change removes a body of code that has a large cost in terms of
> > bugs and maintenance at questionable benefit.
> >
> > It slightly reduces the default installation size.
> >
> > == Scope ==
> > * Proposal owners: Split the ifcfg plugin into a subpackage package.
> > Make sure the ifcfg plugin stays on upgrades. Provide a migration
> > tool.
> >
> > * Other developers: N/A
> >
> > * Release engineering: N/A
> >
> > * Policies and guidelines: N/A
> >
> > * Trademark approval: N/A
> >
> > * Alignment with Objectives: N/A
> >
> > == Upgrade/compatibility impact ==
> > For the time being the ifcfg plugin is kept around, albeit in a
> > sub-package that's not included in new installations.
> > The appropriate RPM tags will ensure the sub-package with the ifcfg
> > plugin will be installed on upgrades.
> > A migration tool will be provided for users who'd like to remove the
> > legacy package from their systems after upgrade.
> >
> > == How To Test ==
> > N/A.
> > The keyfiles are used by default in Fedora 33 already, so any problem
> > with them would've already been spotted.
> >
> > == User Experience ==
> > Regular users will not notice anything.
> > Users of old installations with ifcfg files will get the new
> > sub-package on upgrade.
> > New systems will default to use keyfiles, which is not something
> > regulars user would notice.
> >
> > System integrators and administrators might use tools that drop in
> > ifcfg files during automated installations (e.g. via kickstart or a
> > configration management tool).
> > They will need to update their tools -- convert the ifcfg files to
> > keyfiles or include the ifcfg sub-package.
> >
> > == Dependencies ==
> > N/A
> >
> > == Contingency Plan ==
> > * Contingency mechanism: If it turns out we can't drop support for
> > ifcfg files by default, we can either fold the ifcfg sub-package back
> > into the main NetworkManager package or make sure it is included in
> > new installations (via comps change).
> > * Contingency deadline: Any time.
> > * Blocks release? No.
> >
> > == Documentation ==
> > We'll need to write the documentation for the migration tool.
> > Perhaps also something the sysadmins wondering why their ifcfg files
> > don't work anymore could find and refer to.
> >
> > TODO: Update this once it's done.
> >
> > == Release Notes ==
> > We'll need to include a paragraph about this in the release notes.
> >
> > TODO: Update this with the actual release note text.
> >
>
> This will break cloud-init, since it doesn't know how to configure
> NetworkManager dire
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
>
> == Summary ==
> Do not not include NetworkManager support for legacy network
> configuration files by in new installations.
>
> == Owner ==
> * Name: [[User:Lkundrak| Lubomir Rintel]]
> * Email:
>
> * Name: Ana Cabral
> * Email:
>
> * Name: [[User:Thaller| Thomas Haller]]
> * Email:
>
> == Detailed Description ==
> Long ago, network was configured using "network" service.
> It was essentially a set of shell scripts, that sourced snippets of
> configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
> files").
> The ifcfg files compatible with the legacy network service were kept
> when NetworkManager was intruduced.
>
> As the NetworkManager feature set was expanding beyond what the legacy
> network service could support,
> the ifcfg files written by NetworkManager could no longer be
> guarranteed to be compatible.
> NetworkManager eventually gained support for connection types
> completely unknown to the legacy network service
> and ended up using a more streamlined configuration file format for
> those, known as keyfile.
>
> NetworkManager's use of various configuration files is, in fact,
> configurable and extensible with plugins.
> Prior to Fedora 33, NetworkManager by default was configured to enable
> both ifcfg files and keyfiles, with the former taking precedence when
> possible.
> The precedence changed in
> [https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
> Fedora 33] to perfer keyfile.
>
> The precedence has an effect when a network connection profile is created.
> Once the connection profile exists, NetworkManager is unable to
> convert the profile to a different configuration backend.
> This makes it necessary for NetworkManager to support the same feature
> set in all configuration backend.
> Given the complexities stemming from historical legacy of ifcfg files
> not being designed (or documented) in a
> particularly forward-looking way, this has been a huge and complex
> effort with all the downsides:
> The ifcfg support code is huge (130K lines, not counting the enormous
> test suite) and has constantly been a source of bugs.
>
> == Benefit to Fedora ==
> This change removes a body of code that has a large cost in terms of
> bugs and maintenance at questionable benefit.
>
> It slightly reduces the default installation size.
>
> == Scope ==
> * Proposal owners: Split the ifcfg plugin into a subpackage package.
> Make sure the ifcfg plugin stays on upgrades. Provide a migration
> tool.
>
> * Other developers: N/A
>
> * Release engineering: N/A
>
> * Policies and guidelines: N/A
>
> * Trademark approval: N/A
>
> * Alignment with Objectives: N/A
>
> == Upgrade/compatibility impact ==
> For the time being the ifcfg plugin is kept around, albeit in a
> sub-package that's not included in new installations.
> The appropriate RPM tags will ensure the sub-package with the ifcfg
> plugin will be installed on upgrades.
> A migration tool will be provided for users who'd like to remove the
> legacy package from their systems after upgrade.
>
> == How To Test ==
> N/A.
> The keyfiles are used by default in Fedora 33 already, so any problem
> with them would've already been spotted.
>
> == User Experience ==
> Regular users will not notice anything.
> Users of old installations with ifcfg files will get the new
> sub-package on upgrade.
> New systems will default to use keyfiles, which is not something
> regulars user would notice.
>
> System integrators and administrators might use tools that drop in
> ifcfg files during automated installations (e.g. via kickstart or a
> configration management tool).
> They will need to update their tools -- convert the ifcfg files to
> keyfiles or include the ifcfg sub-package.
>
> == Dependencies ==
> N/A
>
> == Contingency Plan ==
> * Contingency mechanism: If it turns out we can't drop support for
> ifcfg files by default, we can either fold the ifcfg sub-package back
> into the main NetworkManager package or make sure it is included in
> new installations (via comps change).
> * Contingency deadline: Any time.
> * Blocks release? No.
>
> == Documentation ==
> We'll need to write the documentation for the migration tool.
> Perhaps also something the sysadmins wondering why their ifcfg files
> don't work anymore could find and refer to.
>
> TODO: Update this once it's done.
>
> == Release Notes ==
> We'll need to include a paragraph about this in the release notes.
>
> TODO: Update this with the actual release note text.
>
This will break cloud-init, since it doesn't know how to configure
NetworkManager directly. It only knows how to configure netplan (which
isn't packaged in Fedora currently), ifcfg-rh, and ifupdown configuration files.
If you want to do this, you need to extend cloud-init to be able to
configure NetworkManager properly.
--
真実はいつも一つ！/ Always, there's only one truth!
___
F36 Change proposal: No ifcfg by default (Self-Contained Change)
https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
== Summary ==
Do not not include NetworkManager support for legacy network
configuration files by in new installations.
== Owner ==
* Name: [[User:Lkundrak| Lubomir Rintel]]
* Email:
* Name: Ana Cabral
* Email:
* Name: [[User:Thaller| Thomas Haller]]
* Email:
== Detailed Description ==
Long ago, network was configured using "network" service.
It was essentially a set of shell scripts, that sourced snippets of
configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
files").
The ifcfg files compatible with the legacy network service were kept
when NetworkManager was intruduced.
As the NetworkManager feature set was expanding beyond what the legacy
network service could support,
the ifcfg files written by NetworkManager could no longer be
guarranteed to be compatible.
NetworkManager eventually gained support for connection types
completely unknown to the legacy network service
and ended up using a more streamlined configuration file format for
those, known as keyfile.
NetworkManager's use of various configuration files is, in fact,
configurable and extensible with plugins.
Prior to Fedora 33, NetworkManager by default was configured to enable
both ifcfg files and keyfiles, with the former taking precedence when
possible.
The precedence changed in
[https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
Fedora 33] to perfer keyfile.
The precedence has an effect when a network connection profile is created.
Once the connection profile exists, NetworkManager is unable to
convert the profile to a different configuration backend.
This makes it necessary for NetworkManager to support the same feature
set in all configuration backend.
Given the complexities stemming from historical legacy of ifcfg files
not being designed (or documented) in a
particularly forward-looking way, this has been a huge and complex
effort with all the downsides:
The ifcfg support code is huge (130K lines, not counting the enormous
test suite) and has constantly been a source of bugs.
== Benefit to Fedora ==
This change removes a body of code that has a large cost in terms of
bugs and maintenance at questionable benefit.
It slightly reduces the default installation size.
== Scope ==
* Proposal owners: Split the ifcfg plugin into a subpackage package.
Make sure the ifcfg plugin stays on upgrades. Provide a migration
tool.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
For the time being the ifcfg plugin is kept around, albeit in a
sub-package that's not included in new installations.
The appropriate RPM tags will ensure the sub-package with the ifcfg
plugin will be installed on upgrades.
A migration tool will be provided for users who'd like to remove the
legacy package from their systems after upgrade.
== How To Test ==
N/A.
The keyfiles are used by default in Fedora 33 already, so any problem
with them would've already been spotted.
== User Experience ==
Regular users will not notice anything.
Users of old installations with ifcfg files will get the new
sub-package on upgrade.
New systems will default to use keyfiles, which is not something
regulars user would notice.
System integrators and administrators might use tools that drop in
ifcfg files during automated installations (e.g. via kickstart or a
configration management tool).
They will need to update their tools -- convert the ifcfg files to
keyfiles or include the ifcfg sub-package.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: If it turns out we can't drop support for
ifcfg files by default, we can either fold the ifcfg sub-package back
into the main NetworkManager package or make sure it is included in
new installations (via comps change).
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
We'll need to write the documentation for the migration tool.
Perhaps also something the sysadmins wondering why their ifcfg files
don't work anymore could find and refer to.
TODO: Update this once it's done.
== Release Notes ==
We'll need to include a paragraph about this in the release notes.
TODO: Update this with the actual release note text.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: [Fedocal] Reminder meeting : Fedora Source-git SIG
Hi, This is now postponed and it's going to happen in two weeks, on the 19th of January. On Tue, Jan 4, 2022 at 3:30 PM wrote: > Dear all, > > You are kindly invited to the meeting: >Fedora Source-git SIG on 2022-01-05 from 14:30:00 to 15:30:00 GMT >At meet.google.com/mic-otnv-kse > > The meeting will be about: > Meeting of the Fedora source-git SIG > > Agenda: > https://pagure.io/fedora-source-git/sig/issues?tags=meeting&status=Open > > SIG Info: > https://fedoraproject.org/wiki/SIGs/Source-git > > > Source: https://calendar.fedoraproject.org//meeting/10101/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)
On Tue, Jan 4, 2022 at 11:07 PM Kevin Kofler via devel wrote: > Another case is the math symbols: Should the default sans-serif math font be > changed to Noto Sans Math? STIX is a serif font, so it probably makes sense > to keep as the serif math font (also considering that there is, at least at > this time, no Noto Serif Math). For cases where the distinction matters, > see, e.g., the summation sign (clearly visible serifs), the integral sign > (dots at the ends that are a form of serifs), or the partial derivative sign > (constant stroke thickness in Noto Sans Math vs. variable in STIX). Good point. Yes, that makes sense. I'll update the proposal with it. thanks! > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Akira TAGOH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: buildroot size growth
On Tue, Jan 04, 2022 at 12:25:36PM -0800, Adam Williamson wrote: > On Tue, 2022-01-04 at 14:57 +0100, Vít Ondruch wrote: > > One of the packages which caught my attention and previously was not > > installed is systemd (there always were just systemd-libs). So is > > systemd to blame or is it something else? > > I think the difference is that authselect is now pulled in. authselect > pulls in authselect-libs, which pulls in systemd, which I think pulls > in the other things. > > The reason authselect gets pulled in is that pam now requires it: > > https://src.fedoraproject.org/rpms/pam/c/ff21ecd19213fce0570d448831d21f66db6abc2c?branch=rawhide > > that change landed in Rawhide in pam-1.5.2-8.fc36, which was built late > on December 9th, and so likely appeared in the December 10th compose. This is unfortunate as it most likely affects not just the buildroot but also other types of minimal installs. I think the best place to cut this dependency chain would be in authselect-libs: it should not require systemd. What exactly does it need from systemd? 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Upgrade to Django 4.0.x for F36
On Wed, Jan 5, 2022 at 3:41 AM Matthias Runge wrote: > > Hey there, > > would it be too late to upgrade Django for Fedora 36 to version 4.0.x? > It may require some more package updates, not just Django itself. > > The releasenotes are here[1], We have version 3.2 in Fedora 35, which > is a long-term supported release (until 2024)[2]. > > Unfortunately, I am not able to answer the question of "what would > break?". However, not shipping a newer release would show Fedora as > outdated software. > > As hinted in the previous paragraph, I am not involved in any > development connected to Django for some time now. This is a cry for > help. The whole Django stack in Fedora could use more helping hands. > Upstream is very good at providing insights, timelines etc and also > keeps it secured. That also means, there are regular updates. > It's fine to do. We haven't branched yet. You should file a Self-Contained Change for it. The deadline for those is January 18. So, go for it! -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20220105.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220104.0): ID: 1095837 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1095837 ID: 1095848 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1095848 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Upgrade to Django 4.0.x for F36
Hey there, would it be too late to upgrade Django for Fedora 36 to version 4.0.x? It may require some more package updates, not just Django itself. The releasenotes are here[1], We have version 3.2 in Fedora 35, which is a long-term supported release (until 2024)[2]. Unfortunately, I am not able to answer the question of "what would break?". However, not shipping a newer release would show Fedora as outdated software. As hinted in the previous paragraph, I am not involved in any development connected to Django for some time now. This is a cry for help. The whole Django stack in Fedora could use more helping hands. Upstream is very good at providing insights, timelines etc and also keeps it secured. That also means, there are regular updates. Matthias [1] https://www.djangoproject.com/weblog/2021/dec/07/django-40-released/ [2] https://www.djangoproject.com/download/ -- Matthias Runge ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: List of packages with problematic license
On Sat, Jan 1, 2022 at 11:20 AM Miroslav Suchý wrote: > I am processing results of license-validate audit, but it takes longer... > > So I am providing raw results of what I have. If you are maintainer one of > these packages you may expect either BZ report or Pagure PR for your > package in upcoming days/weeks. > > In the attachment you will find more details (albeit not super human > friendly). > https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses for the Creative Commons licenses seems to e.g. just have CC-BY-SA while e.g. https://spdx.org/licenses/ suggests using the version with those like e.g. CC-BY-SA-4.0. Is there anything in the works already to take care of this issue? The attachment is showing a complaint in the pacemaker-package. Regards, Klaus > The list likely contains lots of false positives. And it is missing > packages I already reported. > > Miroslav > > > hibernate-jpa-2.0-api.spec > hibernate-jpa-2.1-api.spec > hunspell-pt.spec > iptables.spec > ipxe.spec > iucode-tool.spec > jbosscache-support.spec > jboss-jaxrs-2.0-api.spec > jsmath-fonts.spec > kdevelop-pg-qt.spec > knot-resolver.spec > knot.spec > libprelude.spec > librhsm.spec > libva-intel-hybrid-driver.spec > libvarlink.spec > lttng-ust.spec > lumina-desktop.spec > lvm2.spec > man-pages-l10n.spec > Mayavi.spec > midori.spec > mingw-LibRaw.spec > mingw-libunistring.spec > mingw-python-certifi.spec > mlir.spec > mono.spec > mono.spec > mpdecimal.spec > mxml.spec > nodejs-tape.spec > ogre.spec > opencascade.spec > openjfx.spec > openjfx8.spec > pacemaker.spec > paho-c.spec > passwdqc.spec > pcs.spec > perl-BSSolv.spec > perl-Date-HolidayParser.spec > perl-Exporter-Tidy.spec > perl-PDF-API2.spec > perl-PDF-Builder.spec > perl-qooxdoo-compat.spec > perl-Regexp-Pattern-DefHash.spec > perl-Regexp-Pattern.spec > perl-RPC-XML.spec > perl.spec > perl.spec > perl-TermReadKey.spec > perl-Test-Command-Simple.spec > perl-Text-Aligner.spec > php-manual-en.spec > phpMyAdmin.spec > pidgin-sipe.spec > pidgin-sipe.spec > pokerth.spec > ProDy.spec > proj.spec > python-coverage.spec > python-pathspec.spec > python-pyface.spec > python-pygit2.spec > python-resolvelib.spec > python-restfly.spec > python-Traits.spec > python-traitsui.spec > python-userpath.spec > qmmp.spec > qt5-qtfeedback.spec > rachota.spec > rizin.spec > rubygem-webrick.spec > rust-ambient-authority.spec > rust-base100.spec > rust-cap-primitives.spec > rust-cap-rand.spec > rust-cap-std.spec > rust-cranelift-bforest.spec > rust-cranelift-codegen-meta.spec > rust-cranelift-codegen-shared.spec > rust-cranelift-codegen.spec > rust-cranelift-entity.spec > rust-cranelift-frontend.spec > rust-cranelift-native.spec > rust-cranelift-wasm.spec > rust-file-per-thread-logger.spec > rust-fs-set-times.spec > rust-io-lifetimes.spec > rust-posish.spec > rust-rav1e.spec > rust-regalloc.spec > rust-target-lexicon.spec > rust-tpm2-policy.spec > rust-unsafe-io.spec > rust-wasmparser.spec > rust-wasmtime-cache.spec > rust-wasmtime-environ.spec > rust-wasmtime-fiber.spec > rust-wasmtime-types.spec > rust-wast.spec > rust-wat.spec > sblim-cim-client.spec > sblim-cim-client2.spec > sblim-cmpi-devel.spec > sblim-cmpi-devel.spec > sblim-cmpi-fsvol.spec > sblim-cmpi-network.spec > sblim-cmpi-nfsv3.spec > sblim-cmpi-nfsv4.spec > sblim-cmpi-params.spec > sblim-cmpi-sysfs.spec > sblim-cmpi-syslog.spec > sblim-sfcCommon.spec > sblim-smis-hba.spec > sblim-testsuite.spec > scantailor.spec > singularity.spec > smc-tools.spec > spec-version-maven-plugin.spec > star.spec > strace.spec > stun.spec > subscription-manager.spec > subscription-manager.spec > sunpinyin.spec > surgescript.spec > surgescript.spec > surgescript.spec > sympa.spec > tcmu-runner.spec > texlive-base.spec > texlive-base.spec > texlive.spec > texlive.spec > texlive.spec > texlive.spec > texlive.spec > texlive.spec > tlog.spec > uboot-tools.spec > virtualbox-guest-additions.spec > wwl.spec > yakuake.spec > ydotool.spec > zfs-fuse.spec > 4diac-forte.spec > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure
