SPDX Statistics - Human Space Flight edition
Hot news: https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ contains usage column for licenses that are allowed for something (documentation, firmware...) Automated migration of "trivial" conversions have started (see other threads in this mailing list). Two weeks ago we had: * 23849spec files in Fedora * 30493license tags in all spec files * 11026 tags have not been converted to SPDX yet * 5004 tags can be trivially converted using `license-fedora2spdx` * Progress: 63,84% ░░ 100% ELN subset: 100 out of 2395 packages are not converted yet (progress 95.82%) Today we have: * 23901spec files in Fedora * 30551license tags in all spec files * 10964 tags have not been converted to SPDX yet * 4964 tags can be trivially converted using `license-fedora2spdx` * Progress: 64,11% ░░ 100% ELN subset: 100 out of 2397 packages are not converted yet (progress 95.83%) Graph of these data with the burndown chart: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing The list of packages needed to be converted is here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt List by package maintainers is here https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt List of packages from ELN subset that needs to be converted: https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt New version of fedora-license-data has been released. With: 1 new license (plus two public domain declarations). 14 licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data) https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ was updated too. License analysis of remaining packages: http://miroslav.suchy.cz/fedora/spdx-reports/ New projection when we will be finished is 2025-04-01 (+20 days from last report). Pure linear approximation. If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license tag matches SPDX formula, you can put your package on ignore list https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt Either pull-request or direct email to me is fine. Why Human Space Flight edition? On today's date at 1961 Yuri Gagarin flew to the space in Vostok 1. Since 1963 this day is celebrated as International Day of Human Space Flight. Also on this day at 1981 the first Space Shuttle (Columbia) was lunched. https://en.wikipedia.org/wiki/International_Day_of_Human_Space_Flight https://en.wikipedia.org/wiki/Vostok_1 And you may also learn about Oleg Ivanovsky https://www.telegraph.co.uk/news/obituaries/1713/Oleg-Ivanovsky-obituary.html#disqus_thread Miroslav -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
I was hesitant to have MFA for a while. Imagine losing a phone with tons of tokens. What a hassle to recover from that. I found it less than ideal for practical reasons. However, I decided instead to buy two Yubikey (primary and backup), and I add the QRs to both of them with the Yubico App. I also screenshot my QRs, tar them, encrypt them with openssl and gpg, and upload them to two cloud locations also protected by MFA, and remove them from my computer. I repeat that when I add a new QR. I also have a txt together with the encrypted tars documenting the commands used to encrypt/decrypt so I remember the parameters to use. The reason I do that is to be able to load them into a new Yubikey in case I lose one. There are alternative to Yubikeys if they are too expensive for some. I do find them a good investment in general, though. I found having Yubikeys (at least two), or other similar devices cheaper than phones, to be the most practical way to do MFA. You can even use those same Yubikeys to unlock hard drives (luks), and go passwordless for some applications. On 4/11/24 17:09, Gary Buhrmaster wrote: On Mon, Apr 1, 2024 at 1:10 AM Kilian Hanich via devel wrote: 2FA in a lot of cases is just access to a different account (e.g. email or even SMS) and these normally aren't unique. Sure, there are other ways like FIDO2, but these are not necessarily used (or liked, quite frankly I know a lot of people who would loose them on a monthly basis, but still are quite smart about other stuff). Given that FIDO2 credentials can be stored on your mobile device (and exchanged with other devices), if those people are losing their mobile devices every month they likely have other issues (including a very expensive mobile device replacement budget) for which there is likely no viable solution. FAS' use of TOTP 2FA is not a great solution compared to FIDO2, and there are well known attacks against TOTP 2FA, but even TOTP 2FA can reduce the doorknob rattling exploits. As TOTP 2FA generators exist for most mobile devices one will tend to have a TOTP 2FA generator with one most of the time. To the Fedora leadership: What is the best way to formally propose that 2FA is required for packagers after some date (I suppose we could have different dates for PPs vs others if we wanted to do that in order to get started sooner). Do we need a formal Change Proposal to be voted on by someone? It does not really seem like a FESCo issue to me, but more of a policy issue that might need to go to the Council? I have no doubt that such a proposal will be controversial with some, and all those issues should get a (re-)airing in front of those making the decision. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Django latest vs LTS maintenance plan
On Fri, Apr 12, 2024 at 12:53:52AM +0200, Miro Hrončok wrote: > > > On 11. 04. 24 22:41, Michel Lind wrote: > > The different Django stacks are in the process of being updated so they > > can be swapped without affecting dependents, by providing and > > conflicting with the virtual `python-django-impl`; not only will this > > allow us to swap one Django LTS for another in EPEL when the older one > > EOLs, but it also allows those with dependencies that are not qualified > > for the latest Django to swap to the LTS in Fedora > > I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: > pytohn3dist(django)`? > Oh good point, that would work too. We'd still need to come up with names for the bash-completion and doc subpackages though. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Fri, 2024-04-12 at 00:09 +, Gary Buhrmaster wrote: > > What is the best way to formally propose > that 2FA is required for packagers after > some date There is already a FESCo ticket. https://pagure.io/fesco/issue/3186 / Please don't discuss there, discuss here; FESCo will vote in that ticket or a meeting when they feel it appropriate. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Mon, Apr 1, 2024 at 1:10 AM Kilian Hanich via devel wrote: > 2FA in a lot of cases is just access to a different account (e.g. email > or even SMS) and these normally aren't unique. Sure, there are other > ways like FIDO2, but these are not necessarily used (or liked, quite > frankly I know a lot of people who would loose them on a monthly basis, > but still are quite smart about other stuff). Given that FIDO2 credentials can be stored on your mobile device (and exchanged with other devices), if those people are losing their mobile devices every month they likely have other issues (including a very expensive mobile device replacement budget) for which there is likely no viable solution. FAS' use of TOTP 2FA is not a great solution compared to FIDO2, and there are well known attacks against TOTP 2FA, but even TOTP 2FA can reduce the doorknob rattling exploits. As TOTP 2FA generators exist for most mobile devices one will tend to have a TOTP 2FA generator with one most of the time. To the Fedora leadership: What is the best way to formally propose that 2FA is required for packagers after some date (I suppose we could have different dates for PPs vs others if we wanted to do that in order to get started sooner). Do we need a formal Change Proposal to be voted on by someone? It does not really seem like a FESCo issue to me, but more of a policy issue that might need to go to the Council? I have no doubt that such a proposal will be controversial with some, and all those issues should get a (re-)airing in front of those making the decision. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Rust] Re: Rust Stack Spring Cleaning - 2024 Edition
On Thu, Apr 11, 2024 at 9:09 PM Michel Lind wrote:
>
> > | rust-atomic-traits | 2022-09-02 | 587 | salimma
> >|
> Still trying to package mmtk, please keep this one for now
Then please follow up, the review request for mmtk was closed due to inactivity:
https://bugzilla.redhat.com/show_bug.cgi?id=2040994
> > | rust-signal | 2023-02-23 | 413 | salimma
> >|
> Not sure about this one. Looks like psutil depends on it, and ytop
> depends on psutil, but ytop is almost 4 years old... probably retire it
https://bugzilla.redhat.com/show_bug.cgi?id=2048155
Looks like pipewire bindings version < 0.7 depended on this, but
dropped the dependency with v0.7.
> > | rust-sptr| 2023-03-28 | 380 | salimma
> >|
> This is needed by portable-atomic which is needed by pyo3, right?
sptr is a dev-dependency for portable-atomic only, and portable-atomic
tests can no longer be run from the published tarbals.
It might be ok to drop sptr.
> > | rust-xcb | 2023-05-10 | 337 | salimma
> >|
> We can kill this I guess. Death to X
Looks like this used to be a dependency of x11-clipboard <0.7, but no
longer is as of v0.7.0.
> > | rust-powierza-coefficient| 2023-06-16 | 300 | salimma
> >|
> I wonder what used it in the past. crates.io now only lists kn ... so
> yeah kill it
This was packaged for nu-command, but the dependency has since been dropped:
https://bugzilla.redhat.com/show_bug.cgi?id=2211278
> > | rust-wayland-commons | 2024-01-02 | 100 | salimma
> >|
> Looks like wayland-{client,server} no longer needs this (since > 0.29).
> Kill.
Agree, this crate seems to have been dropped from wayland-rs.
> > | rust-nom-supreme | 2024-01-04 |98 | salimma
> >|
> Can't find what's actually using it, maybe kill
This was packaged for wax:
https://bugzilla.redhat.com/show_bug.cgi?id=2174116
And was was packaged for nu-command:
https://bugzilla.redhat.com/show_bug.cgi?id=2174146
But wax no longer depends on nom-supreme as of v0.6.0.
> > | rust-vec1| 2024-01-04 |98 | salimma
> >|
> Ditto - not sure what I needed this for, probably dropped upstream
Same here:
https://bugzilla.redhat.com/show_bug.cgi?id=2174097
This used to be a dependency of wax, but it was dropped as of v0.6.0
> > | rust-rlimit | 2024-01-17 |85 | salimma
> >|
> Ditto
Can't tell - the review request isn't marked as blocking anything.
https://bugzilla.redhat.com/show_bug.cgi?id=2258271
At least it's a dependency of "bsdutils":
https://crates.io/crates/bsdutils
So maybe it was part of the coreutils dependency tree for some of the
missing uu_* tools?
> > | rust-base32 | 2024-01-20 |82 | salimma
> >|
> rbw needs this, still in progress
Noted, thank you for checking!
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Rust Stack Spring Cleaning - 2024 Edition
On Thu, Apr 11, 2024 at 7:45 PM Ben Beasley wrote: > > The rust-circular-buffer crate was packaged as a dependency for bpftop, > https://github.com/Netflix/bpftop. > > I won’t necessarily be packaging bpftop myself, but I know several > parties are interested in doing so, and I expect it will happen soon one > way or the other. Thanks! I forgot about that, it's good to have this in writing. > A few existing dependencies still need to be updated first: > > Problem 1: nothing provides requested (crate(anyhow/default) >= 1.0.81 > with crate(anyhow/default) < 2.0.0~) > Problem 2: nothing provides requested (crate(libbpf-rs/default) >= > 0.23.0 with crate(libbpf-rs/default) < 0.24.0~) > Problem 3: nothing provides requested (crate(libbpf-sys/default) >= > 1.4.0 with crate(libbpf-sys/default) < 2.0.0~) > Problem 4: nothing provides requested (crate(ratatui) >= 0.26.1 with > crate(ratatui) < 0.27.0~) > Problem 5: nothing provides requested (crate(ratatui/crossterm) >= > 0.26.1 with crate(ratatui/crossterm) < 0.27.0~) > Problem 6: nothing provides requested (crate(tui-input/default) >= > 0.8.0 with crate(tui-input/default) < 0.9.0~) I can update anyhow tomorrow, that should be a simple update. Michel said he'll be looking at libbpf-rs / libbpf-sys soon. ratatui can be updated too, though it might require a compat package for the current version tui-input seems to be a new dependency. Thank you for checking, 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Django latest vs LTS maintenance plan
On 11. 04. 24 22:41, Michel Lind wrote: The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: pytohn3dist(django)`? -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Merging /usr/sbin to /usr/bin
On Thu, Apr 11, 2024 at 01:39:32PM +, Zbigniew Jędrzejewski-Szmek wrote: >https://src.fedoraproject.org/rpms/filesystem/pull-request/11 The commit "Symlink /usr/sbin to /usr/bin if possible" would wipe out any symlinks in /usr/sbin that point someplace other than /usr/bin when everything becomes a symlink. It should make sure they all point to where you expect before removing them all. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
RFC: Django latest vs LTS maintenance plan
Hi all, With the recent EOL of the Django 3.2 LTS series[^1], and Django being a key component of our mailing list infra for both Fedora and CentOS, I would like to propose the following plan to maintain Django in both Fedora and EPEL: - Fedora: `python-django` maintained as currently, not tracking any LTS series - **but** also fork off `python-django` each time it hits an LTS series to make a new `python-djangoX.Y` (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2274198) - LTS packages are introduced in Fedora first, until they either reach EOL or no longer build, at which point they are retired in Rawhide. See below for the EOL case. - EPEL: we will only branch LTS packages (as is the case now, with `python-django3` - though under the new naming scheme it should have been `python-django3.2`) - Handling EOL - not an issue for `python-django` - we just keep rebasing it - for LTS releases in Fedora, retire in Rawhide if the series will EOL before the EOL of the upcoming Fedora release - for LTS releases in EPEL, once it is EOL (like `python-django3`) we mark it as `Provides: deprecated()` and retire it if there is a replacement that works with add-on packages, *and* there is a CVE that is not fixed - Package ACL: cc-ing the current maintainers of python-django here. Please let me know if - you want to be added to the LTS packages as well - you want to be removed from python-django - you're not currently involved but want to help out - I'll also add infra-sig to the ACL for the LTS packages, as in practice they might need access to fix any issue affecting Mailman The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora Let me know if this makes sense, or if you have ideas of how to handle some of these better. [^1]: https://www.djangoproject.com/weblog/2024/apr/03/bugfix-release/ Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora Linux 40 Final NO-GO
Due to outstanding blocker bugs[1], the Fedora Linux 40 Final RC -1.13 was declared NO-GO in today's meeting[2][3]. The next Fedora Linux 40 Final Go/No-Go meeting[4] will be held at 1700 UTC on Thursday 18th April in #meeting:fedoraproject.org on Matrix. The new target date for the F40 Final release is now Tuesday 23rd April. The schedule[5] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist [2] HTML Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-11/f40-final-go-no-go-meeting.2024-04-11-17.00.log.html [3] Text Log(minutes): https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-11/f40-final-go-no-go-meeting.2024-04-11-17.00.txt [4] https://calendar.fedoraproject.org/meeting/10791/ [5] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust Stack Spring Cleaning - 2024 Edition
On Thu, Apr 11, 2024 at 01:45:26PM -0400, Ben Beasley wrote: > The rust-circular-buffer crate was packaged as a dependency for bpftop, > https://github.com/Netflix/bpftop. > > I won’t necessarily be packaging bpftop myself, but I know several parties > are interested in doing so, and I expect it will happen soon one way or the > other. > > A few existing dependencies still need to be updated first: > > Problem 1: nothing provides requested (crate(anyhow/default) >= 1.0.81 with > crate(anyhow/default) < 2.0.0~) > Problem 2: nothing provides requested (crate(libbpf-rs/default) >= 0.23.0 > with crate(libbpf-rs/default) < 0.24.0~) > Problem 3: nothing provides requested (crate(libbpf-sys/default) >= 1.4.0 > with crate(libbpf-sys/default) < 2.0.0~) > Problem 4: nothing provides requested (crate(ratatui) >= 0.26.1 with > crate(ratatui) < 0.27.0~) > Problem 5: nothing provides requested (crate(ratatui/crossterm) >= 0.26.1 > with crate(ratatui/crossterm) < 0.27.0~) > Problem 6: nothing provides requested (crate(tui-input/default) >= 0.8.0 > with crate(tui-input/default) < 0.9.0~) > Speaking of all the bpf* - I have a TODO (will ping the chat too) to update below, which I expect will require a lot of libbpf-* to be updated. For ratatui -- nu-explore >= 0.91.0 needs 0.26, but I dropped it to 0.25 instead, trying to remember why. Ah... because dua-cli, gimoji, and tui-react needs the old one ❯ fedrq-cratedeps-verbose.sh ratatui rust-dua-cli : (crate(ratatui) >= 0.25.0 with crate(ratatui) < 0.26.0~) rust-gimoji : (crate(ratatui/default) >= 0.25.0 with crate(ratatui/default) < 0.26.0~) rust-nu-explore : (crate(ratatui/default) >= 0.25.0 with crate(ratatui/default) < 0.26.0~) rust-tui-react : (crate(ratatui) >= 0.25.0 with crate(ratatui) < 0.26.0~) Best, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust Stack Spring Cleaning - 2024 Edition
Hi Fabio,
On Thu, Apr 11, 2024 at 03:26:13PM +0200, Fabio Valentini wrote:
> If you know of a reason why a leaf package where I am the primary
> maintainer should not be retired, please let me know, and I will
> exclude it from the list.
>
Thanks for organizing the cleanup!
>
> +--++---+--+
> | Package | Leaf since | Leaf days | Maintainer
> |
> +--++---+--+
> | rust-atomic-traits | 2022-09-02 | 587 | salimma
> |
Still trying to package mmtk, please keep this one for now
> | rust-signal | 2023-02-23 | 413 | salimma
> |
Not sure about this one. Looks like psutil depends on it, and ytop
depends on psutil, but ytop is almost 4 years old... probably retire it
> | rust-sptr| 2023-03-28 | 380 | salimma
> |
This is needed by portable-atomic which is needed by pyo3, right?
> | rust-xcb | 2023-05-10 | 337 | salimma
> |
We can kill this I guess. Death to X
> | rust-powierza-coefficient| 2023-06-16 | 300 | salimma
> |
I wonder what used it in the past. crates.io now only lists kn ... so
yeah kill it
> | rust-wayland-commons | 2024-01-02 | 100 | salimma
> |
Looks like wayland-{client,server} no longer needs this (since > 0.29).
Kill.
> | rust-nom-supreme | 2024-01-04 |98 | salimma
> |
Can't find what's actually using it, maybe kill
> | rust-vec1| 2024-01-04 |98 | salimma
> |
Ditto - not sure what I needed this for, probably dropped upstream
> | rust-async-process | 2024-01-07 |95 | decathorpe
> |
> | rust-notify-debouncer-mini | 2024-01-07 |95 | decathorpe
> |
> | rust-safetensors | 2024-01-07 |95 | thunderbirdtr
> |
> | rust-unidecode | 2024-01-15 |87 | decathorpe
> |
> | rust-rlimit | 2024-01-17 |85 | salimma
> |
Ditto
> | rust-base32 | 2024-01-20 |82 | salimma
> |
rbw needs this, still in progress
>
> - salimma (10): rust-atomic-traits, rust-base32, rust-nom-supreme,
> rust-powierza-coefficient, rust-rlimit, rust-signal, rust-sptr,
> rust-vec1, rust-wayland-commons, rust-xcb
>
Best,
--
_o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Rust Stack Spring Cleaning - 2024 Edition
The rust-circular-buffer crate was packaged as a dependency for bpftop, https://github.com/Netflix/bpftop. I won’t necessarily be packaging bpftop myself, but I know several parties are interested in doing so, and I expect it will happen soon one way or the other. A few existing dependencies still need to be updated first: Problem 1: nothing provides requested (crate(anyhow/default) >= 1.0.81 with crate(anyhow/default) < 2.0.0~) Problem 2: nothing provides requested (crate(libbpf-rs/default) >= 0.23.0 with crate(libbpf-rs/default) < 0.24.0~) Problem 3: nothing provides requested (crate(libbpf-sys/default) >= 1.4.0 with crate(libbpf-sys/default) < 2.0.0~) Problem 4: nothing provides requested (crate(ratatui) >= 0.26.1 with crate(ratatui) < 0.27.0~) Problem 5: nothing provides requested (crate(ratatui/crossterm) >= 0.26.1 with crate(ratatui/crossterm) < 0.27.0~) Problem 6: nothing provides requested (crate(tui-input/default) >= 0.8.0 with crate(tui-input/default) < 0.9.0~) Some of these might just reflect over-aggressive bounds from dependabot that could be loosened downstream, but other minimum versions are likely real. On 4/11/24 9:26 AM, Fabio Valentini wrote: Hello Rust packagers, I'm continuously working on reducing unnecessary accumulation of cruft in the Rust package stack in Fedora, and I have been keeping track of unused library packages for almost three years now. Some of these packages have been unused leaves for over two years! I will again start being more proactive with orphaning / retiring affected packages where I am the primary maintainer, starting incrementally from the packages which have been unused for the longest time - unless I know of a reason to keep a specific package, for example: - something that depends on the package is still going through package review - the package was updated to a "breaking" release and a compat package was created, and now the "main" package is not depended on while the compat package is in use If you know of a reason why a leaf package where I am the primary maintainer should not be retired, please let me know, and I will exclude it from the list. For packages where I am *not* the primary maintainer, I need help: - Is this package still required for something that I don't know about, or can it be dropped? - Was it added as a dependency for something else, but packaging this "something else" was abandoned? - Was it needed at the time, but is the library no longer needed now? Keeping unused packages around only makes maintenance of the Rust stack more difficult due to the more "dense" dependency graph that needs to be considered when pushing "breaking" changes. Over the past year or so, the number of Rust packages in Fedora has grown by almost 50% from about 2200 to over 3000, which is making this issue worse. Full report included below (view in monospace font for correct formatting). Thank you for your help, Fabio +--++---+--+ | Package | Leaf since | Leaf days | Maintainer | +--++---+--+ | rust-curve25519-dalek| 2021-11-18 | 875 | dcavalca | | rust-gstreamer-editing-services | 2021-11-18 | 875 | atim | | rust-gstreamer-player| 2021-11-18 | 875 | atim | | rust-rand_jitter | 2021-11-18 | 875 | jistone | | rust-rand_os | 2021-11-18 | 875 | jistone | | rust-tower-test | 2021-11-18 | 875 | decathorpe | | rust-tower-util | 2021-11-18 | 875 | decathorpe | | rust-partial-io | 2022-02-06 | 795 | decathorpe | | rust-minimad | 2022-02-18 | 783 | dcavalca | | rust-libhandy| 2022-02-20 | 781 | decathorpe | | rust-tiger | 2022-02-20 | 781 | decathorpe | | rust-rand_hc | 2022-02-21 | 780 | jistone | | rust-benfred-read-process-memory | 2022-02-27 | 774 | dcavalca | | rust-custom_error| 2022-02-27 | 774 | dcavalca | | rust-madvr_parse | 2022-02-27 | 774 | dcavalca | | rust-os-release | 2022-02-27 | 774 | dcavalca | | rust-strict | 2022-02-27 | 774 | dcavalca | | rust-subprocess | 2022-02-27 | 774 | dcavalca | | rust-libxml | 2022-04-07 | 735 | decathorpe | | rust-snake_case | 2022-04-25 | 717 | decathorpe | | rust-openat-ext | 2022-04-28 | 714 | walters | | rust-log-mdc | 2022-05-05 | 707 | decathorpe | | rust-cargo-manifes
Re: Self Introduction: Aditi Mishra
Hello Aditi, On Thu, 11 Apr 2024 22:31:41 +0530 Aditi Mishra wrote: > Hello everyone, > > I'm very new to open-source world however I'm willing and passionate > candiate to work with you all. I had worked in the field of linux > scheduler area as an intern. Willing to learn fedora packing and wants > to contribute my work in future journey of fedora. > > Looking forward for your help. welcome in the community :-) Feel free to reach me in case of any Fedora related questions. Dan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Self Introduction: Aditi Mishra
Hello everyone, I'm very new to open-source world however I'm willing and passionate candiate to work with you all. I had worked in the field of linux scheduler area as an intern. Willing to learn fedora packing and wants to contribute my work in future journey of fedora. Looking forward for your help. Thanks and regards, Aditi -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Merging /usr/sbin to /usr/bin
On Thu, Apr 11, 2024 at 04:29:19PM +0200, David Sastre wrote: > Not sure if SELinux policy needs to learn about the merge as well. > Currently, `sudo semanage fcontext -l | rg bin.*=` shows: > > ``` > /sbin = /usr/sbin > /bin = /usr/bin > ``` > > And there are executables in both /usr/bin and /usr/sbin with specific > labels Oh, SELinux. I filed this is a dicusssion starter: https://github.com/fedora-selinux/selinux-policy/pull/2077 Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Thu, Apr 11, 2024 at 09:18:09AM +0200, Ondrej Mosnáček wrote: > On Wed, 10 Apr 2024 at 16:30, Pierre-Yves Chibon wrote: > [...] > > Let's look at it in another way: would you say that the people who leaved > > in the > > 14th century were liars for saying that the earth is flat? > > No, they just didn't know. > > Off-topic and not really affecting the validity of your point, but the > idea that people in the 14th century / Middle Ages generally believed > that the earth was flat is a myth. I recently read about it in the > book "Fake History: 101 Things that Never Happened" by Jo Teeuwisse > (great book, BTW!), but also Wikipedia happens to have a decent > article about it: https://en.wikipedia.org/wiki/Myth_of_the_flat_Earth I stand corrected, maybe "we believed earth was the center of the universe" would have worked better? Or something related to medicine? Anyway, as you said, the point was: context changes and that doesn't make what someone said a lie. Thanks, Pierre -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
soname bump: mupdf 1.24.1 coming to rawhide and F40
Hi there, 1.24.0 was followed by a mostly bugfix minor release 1.24.1, which bumped soname, though. I have been using this locally (first on F39, then on F40 beta) for a while now so that I'm confident we can bring it to both rawhide and F40. (Also, upstream has slowed down since...). I built mupdf in a side-tag for rawhide and F40, and will rebuild the following dependencies: python-PyMuPDF zathura-pdf-mupdf There is one more dependency that I'm aware of. Since I don't have commit rights I filed a PR: https://src.fedoraproject.org/rpms/qpdfview/pull-request/5 In case I missed a dependency feel free to: fedpkg build --target=f41-build-side-87501 fedpkg build --target=f40-build-side-87511 Cheers, Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 40 compose report: 20240411.n.0 changes
OLD: Fedora-40-20240410.n.0 NEW: Fedora-40-20240411.n.0 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-40-20240411.n.0.aarch64.raw.xz = DROPPED IMAGES = Image: Kinoite ociarchive ppc64le Path: Kinoite/ppc64le/images/Fedora-Kinoite-40.20240410.n.0.ociarchive Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240410.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Merging /usr/sbin to /usr/bin
Not sure if SELinux policy needs to learn about the merge as well. Currently, `sudo semanage fcontext -l | rg bin.*=` shows: ``` /sbin = /usr/sbin /bin = /usr/bin ``` And there are executables in both /usr/bin and /usr/sbin with specific labels, e.g. `sudo semanage fcontext -l | rg bin/.*virt` ``` /usr/bin/imagefactory regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/imgfac\.pyregular file system_u:object_r:virtd_exec_t:s0 /usr/bin/nova-compute regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/qemu-ga regular file system_u:object_r:virt_qemu_ga_exec_t:s0 /usr/bin/qemu-pr-helperregular file system_u:object_r:virtd_exec_t:s0 /usr/bin/qemu-storage-daemon regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/vios-proxy-guest regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/vios-proxy-host regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/virt-who regular file system_u:object_r:virtd_exec_t:s0 /usr/sbin/condor_vm-gahp regular file system_u:object_r:virtd_exec_t:s0 /usr/sbin/fence_virtd regular file system_u:object_r:fenced_exec_t:s0 /usr/sbin/libvirt-qmf regular file system_u:object_r:virt_qmf_exec_t:s0 /usr/sbin/libvirtd regular file system_u:object_r:virtd_exec_t:s0 /usr/sbin/virtinterfaced regular file system_u:object_r:virtinterfaced_exec_t:s0 /usr/sbin/virtlockdregular file system_u:object_r:virtlogd_exec_t:s0 /usr/sbin/virtlogd regular file system_u:object_r:virtlogd_exec_t:s0 /usr/sbin/virtlxcd regular file system_u:object_r:virtd_lxc_exec_t:s0 /usr/sbin/virtnetworkd regular file system_u:object_r:virtnetworkd_exec_t:s0 /usr/sbin/virtnodedevd regular file system_u:object_r:virtnodedevd_exec_t:s0 /usr/sbin/virtnwfilterdregular file system_u:object_r:virtnwfilterd_exec_t:s0 /usr/sbin/virtproxyd regular file system_u:object_r:virtproxyd_exec_t:s0 /usr/sbin/virtqemudregular file system_u:object_r:virtqemud_exec_t:s0 /usr/sbin/virtsecretd regular file system_u:object_r:virtsecretd_exec_t:s0 /usr/sbin/virtstoraged regular file system_u:object_r:virtstoraged_exec_t:s0 /usr/sbin/virtvboxdregular file system_u:object_r:virtvboxd_exec_t:s0 /usr/sbin/virtvzd regular file system_u:object_r:virtvzd_exec_t:s0 /usr/sbin/virtxend regular file system_u:object_r:virtxend_exec_t:s0 ``` (should Fedora SELinux policy also drop historical paths for simplicity's sake if/when RPMs don't use them anymore?) On Thu, Apr 11, 2024 at 3:39 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > Hi! > > I'm trying to get > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin implemented. > It was approved for F40, but only a few days before the mass rebuild, > so there wasn't time to do much, so it was retargeted to F41. > We now have some time before the F41 mass rebuild, so I want to push > all the changes required in various packages so that we have time to > work out any kinks before the mass rebuild commences. > > When I started looking at individual packages, I discovered that we > have an old rule that packages are SUPPOSED to use "historical paths" > to list their files. This rule was introduced to make the transition > easier when UsrMove was implemented for F17. For example, mount.nfs > was historically installed as /sbin/mount.nfs, so nfs-utils must use > %files:/sbin/mount.nfs, even though /sbin is a symlink to /usr/sbin, > meaning that the real path after installation is /usr/sbin/mount.nfs. > And packages using a file path dependency on mount.nfs must use > /sbin/mount.nfs too. > > To implement this rule, packages must use %buildroot/sbin during > installation and use literal "/sbin/" in the files section. This idea > made sense at the time, but now it seems overcomplicated and > unecessary. It requires additional work from packagers who create the > packages that provide the files, but also additional work from > packagers that want to refer to those files. In fact, I only found > three packages that implement the rule correctly: nfs-utils, glibc, > and ocfs2-tools. So step 0. is to drop the packaging rule: > https://pagure.io/packaging-committee/pull-request/1355 > > As to the actual sbin merge: > > Currently, we have %_bindir==/usr/bin, %_sbindir==/usr/sbin, > and /sbin->/usr/sbin, /bin->/us
Fedora rawhide compose report: 20240411.n.0 changes
OLD: Fedora-Rawhide-20240410.n.0 NEW: Fedora-Rawhide-20240411.n.0 = SUMMARY = Added images:3 Dropped images: 3 Added packages: 9 Dropped packages:19 Upgraded packages: 107 Downgraded packages: 0 Size of added packages: 32.01 MiB Size of dropped packages:46.16 MiB Size of upgraded packages: 4.17 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -1.66 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base docker aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-GCE.aarch64-Rawhide-20240411.n.0.tar.gz Image: Cloud_Base_UKI qcow2 aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-UEFI-UKI.aarch64-Rawhide-20240411.n.0.qcow2 Image: Cloud_Base docker x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCE.x86_64-Rawhide-20240411.n.0.tar.gz = DROPPED IMAGES = Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20240410.n.0.x86_64.iso Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20240410.n.0.aarch64.iso Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20240410.n.0.iso = ADDED PACKAGES = Package: ffmpegthumbnailer-2.2.2-1.20240105git1b5a779.fc41 Summary: Lightweight video thumbnailer that can be used by file managers RPMs:ffmpegthumbnailer ffmpegthumbnailer-devel ffmpegthumbnailer-libs Size:675.47 KiB Package: gap-pkg-fplsa-1.2.6-1.fc41 Summary: Finitely presented Lie algebras RPMs:gap-pkg-fplsa gap-pkg-fplsa-doc Size:1.10 MiB Package: google-compute-engine-guest-configs-20240307.00-1.fc41 Summary: Google Compute Engine guest environment tools RPMs:google-compute-engine-guest-configs google-compute-engine-guest-configs-rsyslog google-compute-engine-guest-configs-udev Size:47.93 KiB Package: google-disk-expand-20240228.00-1.fc41 Summary: Expands root partition in Google Cloud instances RPMs:google-disk-expand Size:15.87 KiB Package: google-guest-agent-20240314.00-4.fc41 Summary: Google Compute Engine guest environment RPMs:google-guest-agent Size:18.23 MiB Package: google-osconfig-agent-20240409.00-1.fc41 Summary: Google OS Config Agent RPMs:google-osconfig-agent Size:10.41 MiB Package: mmtests-0.27-1.fc41 Summary: Configurable test framework RPMs:mmtests Size:1.33 MiB Package: rust-http-body0.4-0.4.6-1.fc41 Summary: Trait representing an asynchronous, streaming, HTTP request or response body RPMs:rust-http-body0.4+default-devel rust-http-body0.4-devel Size:26.82 KiB Package: ut-2.0.0-1.fc41 Summary: UT: C++20 ??(micro)/Unit Testing Framework RPMs:ut-devel Size:199.60 KiB = DROPPED PACKAGES = Package: fedmod-0.6.6-5.fc40 Summary: Utilities for generating & maintaining modulemd files RPMs:fedmod Size:176.01 KiB Package: golang-gopkg-src-d-billy-4-4.3.2-10.fc40 Summary: Interface filesystem abstraction for Go RPMs:golang-gopkg-src-d-billy-4-devel Size:43.75 KiB Package: golang-gopkg-src-d-git-fixtures-3-3.5.0-13.fc40 Summary: Several git fixtures to run go-git tests RPMs:golang-gopkg-src-d-git-fixtures-3-devel Size:43.11 MiB Package: libcxl-1.7-17.fc40 Summary: Coherent accelerator interface RPMs:libcxl libcxl-devel Size:106.48 KiB Package: liquidshell-1.9.0-3.fc40 Summary: Basic desktop shell using QtWidgets RPMs:liquidshell Size:1.56 MiB Package: perl-Git-PurePerl-0.53-25.fc40 Summary: Pure Perl interface to Git repositories RPMs:perl-Git-PurePerl Size:35.09 KiB Package: perl-Net-GitHub-1.05-5.fc40 Summary: Perl interface for github.com RPMs:perl-Net-GitHub Size:79.77 KiB Package: perl-Spreadsheet-ParseExcel-Simple-1.04-45.fc40 Summary: Simple interface to Excel data RPMs:perl-Spreadsheet-ParseExcel-Simple Size:15.28 KiB Package: perl-Spreadsheet-WriteExcel-Simple-1.04-45.fc40 Summary: Simple single-sheet Excel document creator RPMs:perl-Spreadsheet-WriteExcel-Simple Size:14.34 KiB Package: perl-String-Diff-0.07-26.fc40 Summary: Simple diff to String RPMs:perl-String-Diff Size:20.80 KiB Package: php-phpSmug-2.1-25.fc40 Summary: PHP wrapper for the SmugMug API RPMs:php-phpSmug Size:23.80 KiB Package: rust-cpython-0.7.1-2.fc38 Summary: Bindings to Python RPMs:rust-cpython+default-devel rust-cpython+extension-module-devel rust-cpython+nightly-devel rust-cpython+no-auto-initialize-devel rust-cpython+nonnull-devel rust-cpython+py-link-mode-default-devel rust-cpython+py-link-mode-unresolved-static-devel rust-cpython+python-3-10-devel rust-cpython+python-3-11-devel rust-cpython+python-3-4-devel rust-cpython+python-3-5-devel rust-cpython+python-3-6-devel rust-cpython+python-3-7-devel rust-cpython+python-3-8-devel rust-cpython+python-3-9-devel rust-cpython+python3-sys-devel rust-cpython+serde-convert-devel rust-cpython+serde-devel rust-cpython-devel
[Test-Announce] Re: Fedora Linux 40 Go/No-Go Meeting: 2024-11-04
REMINDER: The Fedora Linux 40 Go/No-Go meeting is scheduled for today, 11th April @ 1700 UTC in in #meeting:fedoraproject.org channel on Matrix. Aoife Moloney Fedora Operations Architect On Mon, Apr 8, 2024, 10:23 PM Aoife Moloney wrote: > Happy Monday folks! > > On Thursday 11th April, the Fedora Linux 40 Final Go/No-Go meeting[1] will > be held at 1700 UTC in #meeting:fedoraproject.org channel on Matrix. > > At this time, we will determine the status of the F40 Final release for > the 16th April, which is the early target date[2]. For more information > about the Go/No-Go meeting, see the wiki[3]. > > > [1] https://calendar.fedoraproject.org/meeting/10787/ > [2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html > [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting > > > -- > > Aoife Moloney > > Fedora Operations Architect > > Fedora Project > > Matrix: @amoloney:fedora.im > > IRC: amoloney > > > -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Merging /usr/sbin to /usr/bin
Hi!
I'm trying to get
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin implemented.
It was approved for F40, but only a few days before the mass rebuild,
so there wasn't time to do much, so it was retargeted to F41.
We now have some time before the F41 mass rebuild, so I want to push
all the changes required in various packages so that we have time to
work out any kinks before the mass rebuild commences.
When I started looking at individual packages, I discovered that we
have an old rule that packages are SUPPOSED to use "historical paths"
to list their files. This rule was introduced to make the transition
easier when UsrMove was implemented for F17. For example, mount.nfs
was historically installed as /sbin/mount.nfs, so nfs-utils must use
%files:/sbin/mount.nfs, even though /sbin is a symlink to /usr/sbin,
meaning that the real path after installation is /usr/sbin/mount.nfs.
And packages using a file path dependency on mount.nfs must use
/sbin/mount.nfs too.
To implement this rule, packages must use %buildroot/sbin during
installation and use literal "/sbin/" in the files section. This idea
made sense at the time, but now it seems overcomplicated and
unecessary. It requires additional work from packagers who create the
packages that provide the files, but also additional work from
packagers that want to refer to those files. In fact, I only found
three packages that implement the rule correctly: nfs-utils, glibc,
and ocfs2-tools. So step 0. is to drop the packaging rule:
https://pagure.io/packaging-committee/pull-request/1355
As to the actual sbin merge:
Currently, we have %_bindir==/usr/bin, %_sbindir==/usr/sbin,
and /sbin->/usr/sbin, /bin->/usr/sbin.
In the end state, we will have %_bindir==%_sbindir==/usr/bin,
and /bin,/sbin,/usr/sbin -> /usr/bin. This end state is simple:
_any_ path will works for any binary.
It's the transition, as we rebuild packages with the new definition,
that requires some careful handling.
After experimenting with a few different ways to handle this, the
following approach seems to work best:
1. rpm is patched to provide %_sbindir==/usr/bin.
(This affects what paths packages will list after being rebuilt.)
2. filesystem is patched to not contain /usr/sbin in %files,
but instead symlink /usr/sbin -> bin in %pretrans.
On fresh installations, this will succeed, so the merge is in place.
On upgrades, this will fail, meaning that /usr/sbin remains a dir.
There is also a %posttrans scriptlet to attempt a merge on upgrades,
more about this below.
In particular, since buildroots are created afresh for each build,
package builds will get merged-sbin.
3. We need to handle the case where package foo had /usr/sbin/foo, but
this file will be in /usr/bin/foo after rebuild. After the merge is
done, /usr/sbin/foo and /usr/bin/foo will point to the same
location, no problem, but during the transition, users or scripts
might call /usr/sbin/foo. To make this work, filesystem rpm gets a
scriptlet that will create symlinks from /usr/sbin to /usr/bin, for
any files which were installed by packages in /usr/sbin. (A list
was obtained using repoquery.)
Initially, I wanted to put those scriptlets in individual packages,
but that turns out to be a lot of duplicate work. Some packages
have multiple subpackages with files (currently) in /usr/sbin, so
we'd end up with a lot of churn. Doing it once in filesystem turns
out to be fairly easy.
4. We also need to handle the case where other package bar has
Requires:/usr/sbin/foo. Once foo has been rebuilt, it has only an
automatic provides for /usr/bin/foo. We could adjust bar for the
new path, but then bar would not be installable on old systems.
Instead, a compat virtual Provides:/usr/sbin/foo is added to foo.
We know that either /usr/sbin will be a symlink, or that filesystem
will create the /usr/sbin/foo symlink.
We need to ensure that the filesystem package that is installed is
actually new enough so that the Provides is not a lie.
filesystem.rpm gets a virtual
Provides:filesystem(unmerged-sbin-symlinks)=1 which is used as
Requires:filesystem(unmerged-sbin-symlinks) by foo.
(An explicit Provides/Requires allows us to adjust or rescind the
mechanism in the future.)
5. After this preparatory work is done, we can rebuild
various packages with updated rpm and filesystem.
Packages which don't use %_sbindir generally don't care.
Some packages which use %_sbindir need small adjustments.
There are some common failure modes:
a. 'mv %buildroot/%_bindir/foo %buildroot/%_sbindir/'
b. 'ln -s ../bin/foo %buildroot/%_sbindir/foo'
c. Listing both %_bindir/foo and %_sbindir/foo in %files
d. 'ln -sf ../bin/foo %buildroot/%_sbindir/foo.alt'
e. 'ln -sf ../sbin/foo %buildroot/%_bindir/foo.alt'
To make builds work both before and after the merge, a-c should be
conditionalized on '%if "%{_sbindir}" != "%{_bindir}"'.
Rust Stack Spring Cleaning - 2024 Edition
Hello Rust packagers, I'm continuously working on reducing unnecessary accumulation of cruft in the Rust package stack in Fedora, and I have been keeping track of unused library packages for almost three years now. Some of these packages have been unused leaves for over two years! I will again start being more proactive with orphaning / retiring affected packages where I am the primary maintainer, starting incrementally from the packages which have been unused for the longest time - unless I know of a reason to keep a specific package, for example: - something that depends on the package is still going through package review - the package was updated to a "breaking" release and a compat package was created, and now the "main" package is not depended on while the compat package is in use If you know of a reason why a leaf package where I am the primary maintainer should not be retired, please let me know, and I will exclude it from the list. For packages where I am *not* the primary maintainer, I need help: - Is this package still required for something that I don't know about, or can it be dropped? - Was it added as a dependency for something else, but packaging this "something else" was abandoned? - Was it needed at the time, but is the library no longer needed now? Keeping unused packages around only makes maintenance of the Rust stack more difficult due to the more "dense" dependency graph that needs to be considered when pushing "breaking" changes. Over the past year or so, the number of Rust packages in Fedora has grown by almost 50% from about 2200 to over 3000, which is making this issue worse. Full report included below (view in monospace font for correct formatting). Thank you for your help, Fabio +--++---+--+ | Package | Leaf since | Leaf days | Maintainer | +--++---+--+ | rust-curve25519-dalek| 2021-11-18 | 875 | dcavalca | | rust-gstreamer-editing-services | 2021-11-18 | 875 | atim | | rust-gstreamer-player| 2021-11-18 | 875 | atim | | rust-rand_jitter | 2021-11-18 | 875 | jistone | | rust-rand_os | 2021-11-18 | 875 | jistone | | rust-tower-test | 2021-11-18 | 875 | decathorpe | | rust-tower-util | 2021-11-18 | 875 | decathorpe | | rust-partial-io | 2022-02-06 | 795 | decathorpe | | rust-minimad | 2022-02-18 | 783 | dcavalca | | rust-libhandy| 2022-02-20 | 781 | decathorpe | | rust-tiger | 2022-02-20 | 781 | decathorpe | | rust-rand_hc | 2022-02-21 | 780 | jistone | | rust-benfred-read-process-memory | 2022-02-27 | 774 | dcavalca | | rust-custom_error| 2022-02-27 | 774 | dcavalca | | rust-madvr_parse | 2022-02-27 | 774 | dcavalca | | rust-os-release | 2022-02-27 | 774 | dcavalca | | rust-strict | 2022-02-27 | 774 | dcavalca | | rust-subprocess | 2022-02-27 | 774 | dcavalca | | rust-libxml | 2022-04-07 | 735 | decathorpe | | rust-snake_case | 2022-04-25 | 717 | decathorpe | | rust-openat-ext | 2022-04-28 | 714 | walters | | rust-log-mdc | 2022-05-05 | 707 | decathorpe | | rust-cargo-manifest | 2022-05-06 | 706 | laiot| | rust-digest_auth | 2022-05-06 | 706 | laiot| | rust-binascii| 2022-05-10 | 702 | saluki | | rust-inlinable_string| 2022-05-10 | 702 | decathorpe | | rust-ubyte | 2022-05-10 | 702 | decathorpe | | rust-email-encoding | 2022-05-17 | 695 | saluki | | rust-tabular | 2022-05-23 | 689 | jbtrystram | | rust-async-mutex | 2022-06-01 | 680 | decathorpe | | rust-awc | 2022-06-01 | 680 | decathorpe | | rust-infer | 2022-06-15 | 666 | decathorpe | | rust-escape_string | 2022-07-08 | 643 | dcavalca | | rust-actix | 2022-07-18 | 633 | decathorpe | | rust-envsubst| 2022-07-18 | 633 | jlebon | | rust-esphome | 2022-07-18 | 633 | dcavalca | | rust-fail| 2022-07-18 | 633 | jlebon | | rust-fn-er
Re: [Test-Announce] Re: Fedora 40 Candidate RC-1.12 Available Now! GRUB ISSUE
Yesterday, Nov10, a set of "Final candidate" for Fedora 40 was posted. Adam requested that we test it to the ends and make sure all is OK. So, I suppose positively, that tomorrow, Friday, we will know if Fedora 40 is a go/nogo. For me, as a single distro to be installed, it is ready to go. However, if you want a Gnome version on one drive, and a KDE version on a second drive, you may be out of luck. The problem I am experiencing is with each produced grub menu, each seems to prevent two Fedoras 40's from being listed within the boot menu. Not with workstation, the first, or the boot menu of the second (KDE). >From the desktop computer bios, I see both devices listed, and yes, via the >bios, I can boot the alternate Fedora40 version. However, using the bios' >presentation in order to select the Fedora Linux to boot is wrong!! I would use RH's bugzilla to report this issue, but right now, the Fedora activity is heavily focused on videos, documentation, web pages... etc. At this time, there is no "unlimited" number of people to provide Fedora 40 installation support. I will await post-install to see if grub.cfg can be less restrictive. Leslie Satenstein PSMy confignvme0 Fedora39 nvme1 Fedora40 Gnomesdax Fedora KDEsdbx Non Fedora setupsdc-sdf Empty,Backups, and available 1tb drives. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPDX] Mass license change Artistic 2.0 to Artistic-2.0
V Thu, Apr 11, 2024 at 01:04:22PM +0200, Miroslav Suchý napsal(a): > perl-Unix-Groups-FFI > perl-Unix-Groups-FFI You can remove perl-Unix-Groups-FFI from your list. I converted both of them. -- Petr signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[SPDX] Mass license change Artistic 2.0 to Artistic-2.0
Hi.
I am going to do the mass change of the license from Artistic 2.0 to
Artistic-2.0
The proposed diff is in attachment.
Affected packages:
chordpro
cleanfeed
libkdtree++
R-AnnotationDbi
perl-Data-IEEE754
mingw-ftplib
nicstat
perl-Test-Bits
perl-MaxMind-DB-Common
perl-MaxMind-DB-Reader-XS
perl-SQL-Abstract-Pg
R-MatrixGenerics
perl-Applify
perl-App-SVN-Bisect
perl-App-SVN-Bisect
perl-Business-ISSN
perl-Crypt-PWSafe3
perl-Dancer-Plugin-Database-Core
perl-Dist-Zilla-Plugin-Config-Git
perl-File-Next
perl-Flickr-API
perl-Ham-Reference-QRZ
perl-HTML-FormatText-WithLinks-AndTables
perl-HTTP-Tiny-Multipart
perl-Inline-CPP
perl-IPTables-ChainMgr
perl-IPTables-Parse
perl-JSON-Validator
perl-Log-Agent
perl-Mango
perl-Minion-Backend-SQLite
perl-Mojolicious-Plugin-AssetPack
perl-Mojolicious-Plugin-CHI
perl-Mojolicious-Plugin-I18N
perl-Mojolicious-Plugin-OAuth2
perl-Mojolicious-Plugin-OpenAPI
perl-Mojo-Pg
perl-Mojo-SQLite
perl-MojoX-JSON-RPC
perl-MooseX-ClassAttribute
perl-MooseX-SemiAffordanceAccessor
perl-Parse-CPAN-Distributions
perl-Perl-Critic-Bangs
perl-Razor-Agent
perl-Set-Object
perl-STD
perl-Test-PostgreSQL
perl-Test-YAML-Meta
perl-Text-Context-EitherSide
perl-Text-SimpleTable
perl-Tie-Cycle
perl-Unix-Groups-FFI
perl-Unix-Groups-FFI
perl-WWW-Shorten
pv
R-restfulr
R-KEGGREST
qstat
R-Biobase
R-BiocGenerics
R-biomaRt
R-Biostrings
R-BSgenome
R-DelayedArray
R-DynDoc
remoot
renrot
R-GenomeInfoDbData
R-GenomeInfoDb
R-GenomicAlignments
R-GenomicRanges
R-matrixStats
rpmgrill
R-Rsamtools
R-Rsolid
R-S4Vectors
R-SummarizedExperiment
R-tkWidgets
R-BiocIO
R-XVector
smaclient
xxkb
R-BiocFileCache
perl-Test-Snapshot
Unless somebody stop me, I will do this change directly in dist-git after a
week.
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
diff -Naur rpm-specs.orig/cleanfeed.spec rpm-specs/cleanfeed.spec
--- rpm-specs.orig/cleanfeed.spec 2024-01-25 03:03:00.0 +0100
+++ rpm-specs/cleanfeed.spec 2024-04-11 13:01:04.933821114 +0200
@@ -1,9 +1,9 @@
Summary: A spam filter for Usenet news servers
Name: cleanfeed
Version: 20020501
-Release: 31%{?dist}
+Release: 32%{?dist}
# Confirmed with upstream, website
-License: Artistic 2.0
+License: Artistic-2.0
URL: http://www.bofh.it/~md/cleanfeed/
Source0: http://www.bofh.it/~md/cleanfeed/cleanfeed-20020501.tgz
Patch0: cleanfeed-20020501-redhat.patch
@@ -56,6 +56,9 @@
%attr(-,news,news) %{_datadir}/news/bin/filter/filter_innd.pl
%changelog
+* Thu Apr 11 2024 Miroslav Suchý - 20020501-32
+- convert license to SPDX
+
* Wed Jan 24 2024 Fedora Release Engineering - 20020501-31
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
diff -Naur rpm-specs.orig/chordpro.spec rpm-specs/chordpro.spec
--- rpm-specs.orig/chordpro.spec 2024-02-15 03:02:20.0 +0100
+++ rpm-specs/chordpro.spec 2024-04-11 13:01:04.568817373 +0200
@@ -7,9 +7,9 @@
Name: chordpro
Summary: Print songbooks (lyrics + chords)
-License: Artistic 2.0
+License: Artistic-2.0
Version: 6.050
-Release: 2%{?dist}
+Release: 3%{?dist}
Source: https://cpan.metacpan.org/authors/id/J/JV/JV/%{FullName}-%{version}.tar.gz
Source1: README.ABC
Source2: README.LilyPond
@@ -250,6 +250,9 @@
gtk-update-icon-cache %{_datadir}/icons/hicolor
%changelog
+* Thu Apr 11 2024 Miroslav Suchý - 6.050-3
+- convert license to SPDX
+
* Wed Feb 14 2024 Johan Vromans - 6.050-2
- Repackage ABC support (abc2svg 1.22.13).
diff -Naur rpm-specs.orig/libkdtree++.spec rpm-specs/libkdtree++.spec
--- rpm-specs.orig/libkdtree++.spec 2024-04-10 04:19:33.0 +0200
+++ rpm-specs/libkdtree++.spec 2024-04-11 13:01:05.481826731 +0200
@@ -1,9 +1,9 @@
Name: libkdtree++
Version:0.7.0
-Release:38%{?dist}
+Release:39%{?dist}
Summary:C++ template container implementation of kd-tree sorting
URL:http://libkdtree.alioth.debian.org/
-License:Artistic 2.0
+License:Artistic-2.0
BuildRequires: gcc-c++
BuildRequires: autoconf automake python3-devel swig
BuildRequires: make
@@ -113,6 +113,9 @@
%doc examples/test*.cpp
%changelog
+* Thu Apr 11 2024 Miroslav Suchý - 0.7.0-39
+- convert license to SPDX
+
* Thu Jan 25 2024 Fedora Release Engineering - 0.7.0-38
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
diff -Naur rpm-specs.orig/mingw-ftplib.spec rpm-specs/mingw-ftplib.spec
--- rpm-specs.orig/mingw-ftplib.spec 2024-01-26 03:21:59.0 +0100
+++ rpm-specs/mingw-ftplib.spec 2024-04-11 13:01:06.768839922 +0200
@@ -2,10 +2,10 @@
Name: mingw-ftplib
Version:4.0
-Release:19%{?dist}
+Release:20%{?dist}
Summary:MinGW Library of FTP routines
-License:Artistic 2.0
+License:Artistic-2.0
URL:http://nbpfaus.net/~pfau/ftplib/
Source0:http://nbpfaus.net/~pfau/ftplib/ftplib-%{version}.tar.gz
Source1:ftplib-rc.rc
@@ -115,6 +115,9 @@
%changelog
+* Thu Apr 11 2024 Miroslav Suchý - 4.0-20
+-
Re: convert everything to rpmautospec?
On Thu, Apr 11, 2024 at 12:39 PM Leon Fauster via devel wrote: > > Am 08.04.24 um 08:01 schrieb Miro Hrončok: > > On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote: > >> > >> Not all commits correspond with a new release downstream, and not all > >> commit messages are relevant to the end user to be part of the change > >> log. For example, commits related with increasing gating test coverage > >> efforts, or setting up gating.yaml itself. Another example is linting > >> setting and/or configurations. How is that handled with autochangelog? > >> Can we tell it to skip certain commits? Or should we include it all? > > > > Put [skip changelog] in the commit message. > > > > https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries > > > > May be an [add rpmchangelog] would be more appropriate for some > scenarios, where branching and merging or whatever would clutter > the git log. Would lead to a more curated rpm changelog. Still, > not ideal. As far as I know, merge commits are already excluded automatically. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
Am 08.04.24 um 08:01 schrieb Miro Hrončok: On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote: Not all commits correspond with a new release downstream, and not all commit messages are relevant to the end user to be part of the change log. For example, commits related with increasing gating test coverage efforts, or setting up gating.yaml itself. Another example is linting setting and/or configurations. How is that handled with autochangelog? Can we tell it to skip certain commits? Or should we include it all? Put [skip changelog] in the commit message. https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries May be an [add rpmchangelog] would be more appropriate for some scenarios, where branching and merging or whatever would clutter the git log. Would lead to a more curated rpm changelog. Still, not ideal. -- Leon -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Wed, 10 Apr 2024 at 16:30, Pierre-Yves Chibon wrote: [...] > Let's look at it in another way: would you say that the people who leaved in > the > 14th century were liars for saying that the earth is flat? > No, they just didn't know. Off-topic and not really affecting the validity of your point, but the idea that people in the 14th century / Middle Ages generally believed that the earth was flat is a myth. I recently read about it in the book "Fake History: 101 Things that Never Happened" by Jo Teeuwisse (great book, BTW!), but also Wikipedia happens to have a decent article about it: https://en.wikipedia.org/wiki/Myth_of_the_flat_Earth -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
