Re: network service removed in Fedora 40 without a Change proposal(?)
On Fri, 2024-04-12 at 19:03 -0500, Neal Gompa wrote: > On Fri, Apr 12, 2024 at 4:41 PM Adam Williamson > wrote: > > > > Michel Lind just prompted me to notice that the 'network' service > > appears to have been removed from initscripts in Fedora 40+. This > > change seems to have landed in February without any fanfare - > > https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd043b75963f7cac?branch=rawhide > > . There is no Change for it, AFAICS. > > > > This does not appear to be driven by upstream removing it, because the > > commit apparently specifically adds 'NO_NETWORK_SCRIPTS=true' to remove > > it from the build. Presumably without that, it would still be built. > > > > I'm a bit worried about this arriving unannounced and apparently mostly > > unnoticed. There *are* still reasons to use the network service; I > > still use it on the openQA worker hosts, for instance, because there is > > integration between openvswitch and the legacy network service, but no > > integration between openvswitch and NetworkManager. I also use an ifup- > > pre-local script to pre-create tap devices; NetworkManager apparently > > does not support this natively. There's a suggested workaround at > > https://access.redhat.com/solutions/6900331 , which is helpful, but > > still, it's a significant change if you're using that mechanism. > > > > As a user of this service, I would've expected more of a heads-up that > > it was going away; if I hadn't happened to catch Michel's message I > > might have upgraded openQA staging to F40 immediately on release (as I > > usually do) and been rather surprised that the network setup stopped > > working. I'm sure I will find a way to re-engineer this rather > > complicated network setup without network.service, but a bit more of a > > heads up would have been nice. > > > > Should this have been a Change? How worried are we about it going out > > in Fedora 40 without having been through the Change process? > > This should have been an announced Change. This is a significant > change with wide impact. I've filed a bug, proposed it as a blocker, and filed a FESCo ticket asking FESCo to designate the bug as a blocker. https://bugzilla.redhat.com/show_bug.cgi?id=2274830 https://pagure.io/fesco/issue/3196 -- 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: F41 Change Proposal - Python Built with gcc -03 (self-contained)
Neal Gompa wrote: > I would like for us to consider evaluating a global change to -O3. I > am not convinced that there's a good reason anymore to remain at -O2. > > If we get this kind of benefit from Python, I would be interested in > seeing what we'd get elsewhere. How much larger is Python at -O3 compared to -O2? And other packages? I would like to see -Os as the default. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
On Fri, Apr 12, 2024 at 4:54 PM Aoife Moloney wrote: > > Wiki - https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3 > Discussion.fpo - > https://discussion.fedoraproject.org/t/f41-change-proposal-python-built-with-gcc-03-self-contained/112743 > > > This is a proposed Change for Fedora Linux. > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > > > == Summary == > Instead of > [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags > Fedora's default `-O2` compiler flag], we will use `-O3` to build > CPython. > This only impacts the interpreter and Python standard library, not any > 3rd party extension modules built as RPM or on developer machines. > This aligns with the way Python is built upstream. > According to our performance measurements, it makes Python > significantly faster (pyperformance geometric mean: 1.04x faster). > > == Owner == > * Name: [[User:churchyard|Miro Hrončok]] > * Email: mhron...@redhat.com > > > == Detailed Description == > > We will replace the `-O2` compiler flag with `-O3` when building the > python3.13 package. This change may be backported to older Pythons if > desired. [[Changes/Python3.13|Python 3.13 should be the main Python > version in Fedora 41+]]. > > The > [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags > Fedora packaging guidelines] about compiler flags explicitly say: > > ''> Overriding these flags for performance optimizations (for > instance, `-O3` instead of `-O2`) is generally discouraged. If you can > present benchmarks that show a significant speedup for this particular > code, this could be revisited on a case-by-case basis.'' > > This change proposal presents such benchmarks and a case for Python to > use `-O3`. > > This change is limited to CPython interpreter and extension modules > from the Python standard library only thanks to > [[Changes/Python_Extension_Flags_Reduction]] (since Fedora 39). Other > Python extension modules will remain bulidng as before, e.g. in RPM > packages, they will still be built with `-O2`, unless Fedora changes > that globally. The extension modules built with `-O2` still work with > Python built with `-O3`. I would like for us to consider evaluating a global change to -O3. I am not convinced that there's a good reason anymore to remain at -O2. If we get this kind of benefit from Python, I would be interested in seeing what we'd get elsewhere. -- 真実はいつも一つ！/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On Fri, Apr 12, 2024 at 4:41 PM Adam Williamson wrote: > > Michel Lind just prompted me to notice that the 'network' service > appears to have been removed from initscripts in Fedora 40+. This > change seems to have landed in February without any fanfare - > https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd043b75963f7cac?branch=rawhide > . There is no Change for it, AFAICS. > > This does not appear to be driven by upstream removing it, because the > commit apparently specifically adds 'NO_NETWORK_SCRIPTS=true' to remove > it from the build. Presumably without that, it would still be built. > > I'm a bit worried about this arriving unannounced and apparently mostly > unnoticed. There *are* still reasons to use the network service; I > still use it on the openQA worker hosts, for instance, because there is > integration between openvswitch and the legacy network service, but no > integration between openvswitch and NetworkManager. I also use an ifup- > pre-local script to pre-create tap devices; NetworkManager apparently > does not support this natively. There's a suggested workaround at > https://access.redhat.com/solutions/6900331 , which is helpful, but > still, it's a significant change if you're using that mechanism. > > As a user of this service, I would've expected more of a heads-up that > it was going away; if I hadn't happened to catch Michel's message I > might have upgraded openQA staging to F40 immediately on release (as I > usually do) and been rather surprised that the network setup stopped > working. I'm sure I will find a way to re-engineer this rather > complicated network setup without network.service, but a bit more of a > heads up would have been nice. > > Should this have been a Change? How worried are we about it going out > in Fedora 40 without having been through the Change process? This should have been an announced Change. This is a significant change with wide impact. -- 真実はいつも一つ！/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 40 Final Blocker Bug Report: 2024-04-12
Hi folks, We are still seeing a few blockers for the Fedora Linux 40 final milestone being filed in the blocker bugs app[1]. Your help in reproducing the bug, suggesting fixes and verifying updates would be greatly appreciated before the next Go/No-Go meeting[2][3] on Thursday April 18th to have these bugs resolved. Please refer to the bugs in bugzilla for more detailed descriptions. Below is an approximation of each bug's activity. == Proposed Blocker == 1. nautilus - [abrt] nautilus: ptr_array_fre(): nautilus killed by SIGABRT - NEW ACTION: Upstream to diagnose issue == Accepted Blockers == 1. gcc - Illegal instruction errors in libQt6Core - MODIFIED ACTION: QA to verify fix https://bodhi.fedoraproject.org/updates/FEDORA-2024-17bcbff3cf 2. khelpcenter - The KDE help center does not show the documentation for KDE applications - ON_QA ACTION: N/A == Accepted Previous Release Blocker == 1. distribution - dnf system-upgrade fails on some RPi4 due to system boot date that pre-dates gpg key - NEW ACTION: HELP WANTED to figure out a fix please = Bug by Bug Detail = == Proposed Blockers == 1. nautilus - [abrt] nautilus: ptr_array_free(): nautilus killed by SIGABRT - https://bugzilla.redhat.com/show_bug.cgi?id=2274724 - NEW Nautilus crashes when trying to compress a folder and file together. The issue does not seem to affect creating zip or downloading them and an upstream bug has been filed https://gitlab.gnome.org/GNOME/nautilus/-/issues/3389 == Accepted Blockers == 1. gcc - Illegal instruction errors in libQt6Core - https://bugzilla.redhat.com/show_bug.cgi?id=2272758 - MODIFIED There are Illegal instruction errors in libQt6Core and currently a small number of CPUs with AES-NI are affected. Please review the bug comments for a list of affected models. This bug causes plasma to be unable to boot this, or anything in the boot chain that's linked against qt6 to fail. A fix has been submitted which contains an updated build of gcc in the buildroots and this appears to be resolving the issue, but will await verification from QA https://bodhi.fedoraproject.org/updates/FEDORA-2024-17bcbff3cf 2. khelpcenter - The KDE help center does not show the documentation for KDE applications - https://bugzilla.redhat.com/show_bug.cgi?id=2271837 - ON_QA The KDE Help centre doesnt show, ir is missing, documentation for the KDE applications. A workaround can be found by doing a search for the documentation through the help centre, but there are two links, of which only one currently works. An upstream bug has been filed https://bugs.kde.org/show_bug.cgi?id=484176 and the upstream maintainers are aware of the issue and are working on a fix. == Accepted Previous Release Blocker == 1. distribution - dnf system-upgrade fails on some RPi4 due to system boot date that pre-dates gpg key - https://bugzilla.redhat.com/show_bug.cgi?id=2242759 - NEW beta dnf system-upgrade reboot fails on Raspberry Pi 4 (8 gb). Using dnf system-upgrade log --number=-1, an entry like "Signature 10d5 created at Wed Sep 27 16:33:34 2023 invalid: signature is not alive" is generated for each rpm in the upgrade list. Raspberry Pi 4 does not have a hardware real time clock so when the Pi is booting Fedora system time is at some (arbitrary?) date and time. During a normal boot chronyd is executed and will set the clock: "chronyd[571]: System clock wrong by 944623.935135 seconds". If the gpg key used by DNF during the system-upgrade has a valid period more recent than the boot time, system-upgrade will fail. There are various possible workarounds, but none ideal for users to have to implement, so a fix is still required for this bug to be resolved. Anyone with Python experience would be most welcome to give feedback on some of the ideas to fix that have been proposed or come up with a fix. [1] https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist [2] https://calendar.fedoraproject.org/meeting/10791/ [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting Kind regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Adam Williamson wrote: > Also, these days, most authenticator apps support some kind of backup > mechanism. FreeOTP lets you back up to a file (which you should, of > course, keep somewhere safe and ideally encrypted). Google > Authenticator can backup To The Cloud. If you use Keysmith, you can just SFTP your ~/.config/org.kde.keysmith/Keysmith.conf from/to all your GNU/Linux computers including the PinePhone or equivalent, and they will all be able to generate the same TOTP keys with the same master key. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On 4/12/24 16:46, Adam Williamson wrote: it seems since I last looked at this, NM has grown some level of openvswitch support, but it seems to be limited, and I don't know off- hand if it's sufficient for what openQA needs. I will need to look into that. https://github.com/NetworkManager/NetworkManager/blob/main/man/nm-openvswitch.xml I've attempted to use it on a couple occasions, and I've never been able to get it to work. It requires creating 3 different objects, in the correct order, with exactly the right settings. And AFAIK, it still doesn't support setting the internal port to the same name as the bridge itself, which is the default behavior of ovs-vsctl and the network scripts, so it's a disruptive change to the network configuration even if it can be made to work. -- Google Where SkyNet meets Idiocracy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
[rpms/perl-Task-Catalyst] PR #1: Stop building for 32-bit x86
jjames commented on the pull-request: `Stop building for 32-bit x86` that you
are following:
``
I have updated the PR to include the comment above the License tag.
The php stack is [dropping its i386
builds](https://fedoraproject.org/wiki/Changes/php_no_32_bit). The flamegraph
package consumes php. There is a [pull
request](https://src.fedoraproject.org/rpms/flamegraph/pull-request/1) to stop
building the php bits on i386. I looked at the number of packages sitting on
top of flamegraph. Only 4 of them do not already exclude i386 builds. My
preference is to stop building flamegraph on i386 altogether, rather than
single out the php parts. Since flamegraph is not currently a leaf package for
i386, I need to sweet talk the maintainers of those 4 packages into dropping
i386 support.
My understanding is that noarch packages show up in the i386 repository unless
an ExcludeArch or ExclusiveArch tag prevents that. This is why all Java
packages in Fedora now have something like this:
```
BuildArch: noarch
ExclusiveArch: %{java_arches} noarch
```
I will happily accept correction if I have misunderstood the situation.
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Task-Catalyst/pull-request/1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-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
The idea is rather to scan the same QR twice, for two yubikeys, and then screenshot it and save it securely in case you lose one yubikey and need to load it into a new one. On Fri, Apr 12, 2024 at 2:39 PM Richard W.M. Jones wrote: > On Fri, Apr 12, 2024 at 09:47:04AM -0700, Adam Williamson wrote: > > On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote: > > > 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. > > > > This is one reason most systems provide a sheet of one-time backup > > codes that you're meant to print out and keep in a safe place, for > > recovery from exactly that scenario. > > > > Alternatively, if you have an old phone or tablet lying around, just > > install an MFA app on that and enrol it too, lock it in a cabinet, then > > if you ever lose your primary phone, use it to recover. > > So the problem with github is they don't allow you to have 2FA on a > backup device (or rather, it *is* possible, but the process is > ludicrous[1]). If you have your phone as second FA and lose it then > you have to immediately fall back to the piece of paper. > > [1] https://github.com/orgs/community/discussions/78027 > > I really hope we can avoid that mistake. > > Rich. > > > Also, these days, most authenticator apps support some kind of backup > > mechanism. FreeOTP lets you back up to a file (which you should, of > > course, keep somewhere safe and ideally encrypted). Google > > Authenticator can backup To The Cloud. > > -- > > 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 > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal - Python Built with gcc -03 (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
Discussion.fpo -
https://discussion.fedoraproject.org/t/f41-change-proposal-python-built-with-gcc-03-self-contained/112743
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Instead of
[https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
Fedora's default `-O2` compiler flag], we will use `-O3` to build
CPython.
This only impacts the interpreter and Python standard library, not any
3rd party extension modules built as RPM or on developer machines.
This aligns with the way Python is built upstream.
According to our performance measurements, it makes Python
significantly faster (pyperformance geometric mean: 1.04x faster).
== Owner ==
* Name: [[User:churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com
== Detailed Description ==
We will replace the `-O2` compiler flag with `-O3` when building the
python3.13 package. This change may be backported to older Pythons if
desired. [[Changes/Python3.13|Python 3.13 should be the main Python
version in Fedora 41+]].
The [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
Fedora packaging guidelines] about compiler flags explicitly say:
''> Overriding these flags for performance optimizations (for
instance, `-O3` instead of `-O2`) is generally discouraged. If you can
present benchmarks that show a significant speedup for this particular
code, this could be revisited on a case-by-case basis.''
This change proposal presents such benchmarks and a case for Python to
use `-O3`.
This change is limited to CPython interpreter and extension modules
from the Python standard library only thanks to
[[Changes/Python_Extension_Flags_Reduction]] (since Fedora 39). Other
Python extension modules will remain bulidng as before, e.g. in RPM
packages, they will still be built with `-O2`, unless Fedora changes
that globally. The extension modules built with `-O2` still work with
Python built with `-O3`.
== Feedback ==
== Benefit to Fedora ==
Upstream already builds Python with `-O3` by default. Fedora's Python
built with `-O3` is faster (1.04x):
{| class="wikitable sortable"
|+ Benchmark with python3.12-3.12.2-3.fc41
|-
! Benchmark!! -O2 !! -O3 !!
Change !! Significance
|-
| 2to3 || 465 ms || 446 ms ||
1.04x faster || Significant (t=21.72)
|-
| async_generators || 853 ms || 784 ms ||
1.09x faster || Significant (t=36.61)
|-
| async_tree_cpu_io_mixed || 1.19 sec || 1.11 sec ||
1.08x faster || Significant (t=13.38)
|-
| async_tree_cpu_io_mixed_tg || 1.17 sec || 1.09 sec ||
1.08x faster || Significant (t=18.69)
|-
| async_tree_eager || 202 ms || 189 ms ||
1.07x faster || Significant (t=7.99)
|-
| async_tree_eager_cpu_io_mixed|| 727 ms || 664 ms ||
1.09x faster || Significant (t=18.56)
|-
| async_tree_eager_cpu_io_mixed_tg || 633 ms || 558 ms ||
1.13x faster || Significant (t=24.53)
|-
| async_tree_eager_io || 1.72 sec || 1.68 sec ||
1.03x faster || Significant (t=6.13)
|-
| async_tree_eager_io_tg || 1.65 sec || 1.62 sec ||
1.02x faster || Significant (t=4.65)
|-
| async_tree_eager_memoization || 437 ms || 422 ms ||
1.04x faster || Significant (t=5.09)
|-
| async_tree_eager_memoization_tg || 330 ms || 322 ms ||
1.03x faster || Significant (t=2.60)
|-
| async_tree_eager_tg || 137 ms || 125 ms ||
1.09x faster || Significant (t=16.94)
|-
| async_tree_io|| 1.64 sec || 1.60 sec ||
1.02x faster || Significant (t=9.49)
|-
| async_tree_io_tg || 1.65 sec || 1.61 sec ||
1.02x faster || Not significant
|-
| async_tree_memoization || 895 ms || 871 ms ||
1.03x faster || Significant (t=3.73)
|-
| async_tree_memoization_tg|| 848 ms || 836 ms ||
1.01x faster || Not significant
|-
| async_tree_none || 718 ms || 700 ms ||
1.03x faster || Significant (t=6.90)
|-
| async_tree_none_tg || 686 ms || 659 ms ||
1.04x faster || Significant (t=13.11)
|-
| asyncio_tcp || 757 ms || 748 ms ||
1.01x faster || Not significant
|-
| asyncio_tcp_ssl || 2.58 sec || 2.56 sec ||
1.01x faster || Not significant
|-
| asyncio_websockets || 419 ms || 418 ms ||
1.00x faster || Not significant
|-
| bench_mp_pool|| 10.7 ms || 10.7 ms ||
1.00x faster || Not significant
|-
| bench_thread_pool|| 1.62 ms || 1.61 ms ||
1.01x faster || Not significant
|-
| chameleon
F41 Change Proposal - Python Built with gcc -03 (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
Discussion.fpo -
https://discussion.fedoraproject.org/t/f41-change-proposal-python-built-with-gcc-03-self-contained/112743
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Instead of
[https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
Fedora's default `-O2` compiler flag], we will use `-O3` to build
CPython.
This only impacts the interpreter and Python standard library, not any
3rd party extension modules built as RPM or on developer machines.
This aligns with the way Python is built upstream.
According to our performance measurements, it makes Python
significantly faster (pyperformance geometric mean: 1.04x faster).
== Owner ==
* Name: [[User:churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com
== Detailed Description ==
We will replace the `-O2` compiler flag with `-O3` when building the
python3.13 package. This change may be backported to older Pythons if
desired. [[Changes/Python3.13|Python 3.13 should be the main Python
version in Fedora 41+]].
The [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
Fedora packaging guidelines] about compiler flags explicitly say:
''> Overriding these flags for performance optimizations (for
instance, `-O3` instead of `-O2`) is generally discouraged. If you can
present benchmarks that show a significant speedup for this particular
code, this could be revisited on a case-by-case basis.''
This change proposal presents such benchmarks and a case for Python to
use `-O3`.
This change is limited to CPython interpreter and extension modules
from the Python standard library only thanks to
[[Changes/Python_Extension_Flags_Reduction]] (since Fedora 39). Other
Python extension modules will remain bulidng as before, e.g. in RPM
packages, they will still be built with `-O2`, unless Fedora changes
that globally. The extension modules built with `-O2` still work with
Python built with `-O3`.
== Feedback ==
== Benefit to Fedora ==
Upstream already builds Python with `-O3` by default. Fedora's Python
built with `-O3` is faster (1.04x):
{| class="wikitable sortable"
|+ Benchmark with python3.12-3.12.2-3.fc41
|-
! Benchmark!! -O2 !! -O3 !!
Change !! Significance
|-
| 2to3 || 465 ms || 446 ms ||
1.04x faster || Significant (t=21.72)
|-
| async_generators || 853 ms || 784 ms ||
1.09x faster || Significant (t=36.61)
|-
| async_tree_cpu_io_mixed || 1.19 sec || 1.11 sec ||
1.08x faster || Significant (t=13.38)
|-
| async_tree_cpu_io_mixed_tg || 1.17 sec || 1.09 sec ||
1.08x faster || Significant (t=18.69)
|-
| async_tree_eager || 202 ms || 189 ms ||
1.07x faster || Significant (t=7.99)
|-
| async_tree_eager_cpu_io_mixed|| 727 ms || 664 ms ||
1.09x faster || Significant (t=18.56)
|-
| async_tree_eager_cpu_io_mixed_tg || 633 ms || 558 ms ||
1.13x faster || Significant (t=24.53)
|-
| async_tree_eager_io || 1.72 sec || 1.68 sec ||
1.03x faster || Significant (t=6.13)
|-
| async_tree_eager_io_tg || 1.65 sec || 1.62 sec ||
1.02x faster || Significant (t=4.65)
|-
| async_tree_eager_memoization || 437 ms || 422 ms ||
1.04x faster || Significant (t=5.09)
|-
| async_tree_eager_memoization_tg || 330 ms || 322 ms ||
1.03x faster || Significant (t=2.60)
|-
| async_tree_eager_tg || 137 ms || 125 ms ||
1.09x faster || Significant (t=16.94)
|-
| async_tree_io|| 1.64 sec || 1.60 sec ||
1.02x faster || Significant (t=9.49)
|-
| async_tree_io_tg || 1.65 sec || 1.61 sec ||
1.02x faster || Not significant
|-
| async_tree_memoization || 895 ms || 871 ms ||
1.03x faster || Significant (t=3.73)
|-
| async_tree_memoization_tg|| 848 ms || 836 ms ||
1.01x faster || Not significant
|-
| async_tree_none || 718 ms || 700 ms ||
1.03x faster || Significant (t=6.90)
|-
| async_tree_none_tg || 686 ms || 659 ms ||
1.04x faster || Significant (t=13.11)
|-
| asyncio_tcp || 757 ms || 748 ms ||
1.01x faster || Not significant
|-
| asyncio_tcp_ssl || 2.58 sec || 2.56 sec ||
1.01x faster || Not significant
|-
| asyncio_websockets || 419 ms || 418 ms ||
1.00x faster || Not significant
|-
| bench_mp_pool|| 10.7 ms || 10.7 ms ||
1.00x faster || Not significant
|-
| bench_thread_pool|| 1.62 ms || 1.61 ms ||
1.01x faster || Not significant
|-
| chameleon
Re: Three steps we could take to make supply chain attacks a bit harder
Once upon a time, Richard W.M. Jones said: > So the problem with github is they don't allow you to have 2FA on a > backup device (or rather, it *is* possible, but the process is > ludicrous[1]). If you have your phone as second FA and lose it then > you have to immediately fall back to the piece of paper. I haven't seen a site with TOTP 2FA allow multiple TOTP codes, they all just store one. It's trivial to scan the TOTP code into multiple devices (depending on the software used, you can sometimes "export" a TOTP code from one device to another by showing a QR code on the first device), so that's hardly a "ludicrous" method. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On Fri, 2024-04-12 at 14:40 -0700, Adam Williamson wrote: > unnoticed. There *are* still reasons to use the network service; I > still use it on the openQA worker hosts, for instance, because there is > integration between openvswitch and the legacy network service, but no > integration between openvswitch and NetworkManager. it seems since I last looked at this, NM has grown some level of openvswitch support, but it seems to be limited, and I don't know off- hand if it's sufficient for what openQA needs. I will need to look into that. https://github.com/NetworkManager/NetworkManager/blob/main/man/nm-openvswitch.xml -- 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
F41 Change Proposal - Reproducible Package Builds (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/ReproduciblePackageBuilds Discussion.fpo - https://discussion.fedoraproject.org/t/f41-change-proposal-reproducible-package-builds-system-wide/112740 == Summary == A post-build cleanup is integrated into the RPM build process so that common causes of build irreproducibility in packages are removed, making most of Fedora packages reproducible. == Owner == * Name: Davide Cavalca * Name: Neil Hanlon * Name: [[User:churchyard|Miro Hrončok]] * Name: [[User:zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: dcava...@fedoraproject.org * Email: neil at shrug.pw * Email: mhroncok at redhat.com * Email: zbyszek at in.waw.pl == Detailed Description == As of 2023 there is an active effort to implement [https://docs.fedoraproject.org/en-US/reproducible-builds/ Reproducible builds] in Fedora. Reproducible builds will allow our users to be able to independently verify that the RPMs have not been tampered with (either maliciously or via hardware/software fault): someone can do an independent rebuild of a package and confirm that they get identical binaries when building with the same versions of the compiler and other tools. This Change allows us to move forward in this direction by removing the common sources of irreproducibility. [https://github.com/keszybz/add-determinism add-determinism] is a Rust program which, as its name suggests, adds determinism to files that are given as input by attempting to standardize metadata contained in binary or source files to ensure consistency and clamping to $SOURCE_DATE_EPOCH in all instances. `add-determinism` is the "Fedora version" of [https://salsa.debian.org/reproducible-builds/strip-nondeterminism strip-nondeterminism] from the Debian project. Since strip-nondeterminism is written in perl, it is undesirable for use in Fedora, as we don't want to pull perl in the buildroot for every package. It's worth noting that this Change does not intend to impose any specific reproducibility requirements on Fedora packages. Once this Change is implemented and we have been through a mass rebuild and can verify that the common causes of irreproducibility have indeed been removed, we can consider further steps. But that will be at least one release later. This change does add a small amount of time to the processing of RPMs at the end of a build. Accordingly, packages containing large quantities or sizes of files can be slower, but this effect is not expected to be noticeable. `add-determinism` takes steps to ensure it does not interfere with other buildroot post processors like `mangle-shebangs`, `python-hardlink`, `python-bytecompile`. It defaults to not doing any modifications in case it doesn't understand the input file or there are any other problems. A mechanism to opt-out will be provided: to either completely disable the postprocessing step or to disable specific "handlers" (i.e. implementations of cleanup for specific file types, for example static archives). See [https://github.com/keszybz/add-determinism/blob/main/rpm/macros.build-reproducibility macros.build-reproducibility]. === Related Changes === * [https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes Clamp build mtimes to SOURCE_DATE_EPOCH] * [https://fedoraproject.org/wiki/Changes/RPM-4.20 RPM 4.20] — this pulls in changes to `%autosetup -S git` which removed a source of irreproducibility. == Feedback == == Benefit to Fedora == Adding determinism (i.e., removing non-determinsim) enables the Fedora community to have confidence that, if given the same source code, build environment, build instructions, and metadata from the build artifacts, any party can recreate copies of the artifacts that are identical except for the signatures and some parts of metadata. Reproducibility of builds leads to packages of higher quality. It turns out that quite often those irreproducible bits are caused by an error or sloppiness in the code. In particular, any dependence on architecture in noarch packages is almost always unwanted and/or a bug. Test builds that check reproducibility will expose such instances. Reproducibility of builds makes it easier to develop packages: when a small change is made and a package is rebuilt (in the same environment), then with a reproducible package, the only difference is directly caused by the change. If the package is different every time it is rebuilt, making a comparison is much harder. Build reproducibility for noarch ''sub''packages solves the problem where package builds on different architectures are different, causing mock to reject the whole build. In particular, this issue occurs for [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_byte_compilation_reproducibility pyc files]. This will now be solved without requiring opt-in from individual packages. == Scope == * Proposal Owners: ** Integrate `add-determinism` as a BuildRoot Policy script ** Add a dependency on `marshalparser` to `python3`
F41 Change Proposal - Reproducible Package Builds (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/ReproduciblePackageBuilds Discussion.fpo - https://discussion.fedoraproject.org/t/f41-change-proposal-reproducible-package-builds-system-wide/112740 == Summary == A post-build cleanup is integrated into the RPM build process so that common causes of build irreproducibility in packages are removed, making most of Fedora packages reproducible. == Owner == * Name: Davide Cavalca * Name: Neil Hanlon * Name: [[User:churchyard|Miro Hrončok]] * Name: [[User:zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: dcava...@fedoraproject.org * Email: neil at shrug.pw * Email: mhroncok at redhat.com * Email: zbyszek at in.waw.pl == Detailed Description == As of 2023 there is an active effort to implement [https://docs.fedoraproject.org/en-US/reproducible-builds/ Reproducible builds] in Fedora. Reproducible builds will allow our users to be able to independently verify that the RPMs have not been tampered with (either maliciously or via hardware/software fault): someone can do an independent rebuild of a package and confirm that they get identical binaries when building with the same versions of the compiler and other tools. This Change allows us to move forward in this direction by removing the common sources of irreproducibility. [https://github.com/keszybz/add-determinism add-determinism] is a Rust program which, as its name suggests, adds determinism to files that are given as input by attempting to standardize metadata contained in binary or source files to ensure consistency and clamping to $SOURCE_DATE_EPOCH in all instances. `add-determinism` is the "Fedora version" of [https://salsa.debian.org/reproducible-builds/strip-nondeterminism strip-nondeterminism] from the Debian project. Since strip-nondeterminism is written in perl, it is undesirable for use in Fedora, as we don't want to pull perl in the buildroot for every package. It's worth noting that this Change does not intend to impose any specific reproducibility requirements on Fedora packages. Once this Change is implemented and we have been through a mass rebuild and can verify that the common causes of irreproducibility have indeed been removed, we can consider further steps. But that will be at least one release later. This change does add a small amount of time to the processing of RPMs at the end of a build. Accordingly, packages containing large quantities or sizes of files can be slower, but this effect is not expected to be noticeable. `add-determinism` takes steps to ensure it does not interfere with other buildroot post processors like `mangle-shebangs`, `python-hardlink`, `python-bytecompile`. It defaults to not doing any modifications in case it doesn't understand the input file or there are any other problems. A mechanism to opt-out will be provided: to either completely disable the postprocessing step or to disable specific "handlers" (i.e. implementations of cleanup for specific file types, for example static archives). See [https://github.com/keszybz/add-determinism/blob/main/rpm/macros.build-reproducibility macros.build-reproducibility]. === Related Changes === * [https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes Clamp build mtimes to SOURCE_DATE_EPOCH] * [https://fedoraproject.org/wiki/Changes/RPM-4.20 RPM 4.20] — this pulls in changes to `%autosetup -S git` which removed a source of irreproducibility. == Feedback == == Benefit to Fedora == Adding determinism (i.e., removing non-determinsim) enables the Fedora community to have confidence that, if given the same source code, build environment, build instructions, and metadata from the build artifacts, any party can recreate copies of the artifacts that are identical except for the signatures and some parts of metadata. Reproducibility of builds leads to packages of higher quality. It turns out that quite often those irreproducible bits are caused by an error or sloppiness in the code. In particular, any dependence on architecture in noarch packages is almost always unwanted and/or a bug. Test builds that check reproducibility will expose such instances. Reproducibility of builds makes it easier to develop packages: when a small change is made and a package is rebuilt (in the same environment), then with a reproducible package, the only difference is directly caused by the change. If the package is different every time it is rebuilt, making a comparison is much harder. Build reproducibility for noarch ''sub''packages solves the problem where package builds on different architectures are different, causing mock to reject the whole build. In particular, this issue occurs for [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_byte_compilation_reproducibility pyc files]. This will now be solved without requiring opt-in from individual packages. == Scope == * Proposal Owners: ** Integrate `add-determinism` as a BuildRoot Policy script ** Add a dependency on `marshalparser` to `python3`
Orphaned packages looking for new maintainers
Report started at 2024-04-12 13:04:40 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainersStatus Change container-workflow-tool orphan 2 weeks ago emacs-htmlize orphan 3 weeks ago jolokia-jvm-agent orphan 0 weeks ago kio-upnp-ms jgrulich, orphan 5 weeks ago libteam orphan 0 weeks ago loudgainorphan 4 weeks ago mingw-freeimage orphan 0 weeks ago mrxvt orphan 4 weeks ago nextcloud ichavero, orphan 2 weeks ago perl-WWW-Google-Contactsorphan 5 weeks ago php-aws-sdk3orphan 2 weeks ago php-bantu-ini-get-wrapper adamwill, orphan 2 weeks ago php-christophwurst-id3parserorphan 2 weeks ago php-deepdiver-zipstreamer orphan 2 weeks ago php-doctrine-dbal orphan, remi 2 weeks ago php-fgrosse-phpasn1 orphan 2 weeks ago php-giggsey-locale orphan 2 weeks ago php-guzzlehttp-guzzle6 orphan 2 weeks ago php-league-uri-interfaces orphan 2 weeks ago php-opencloud-openstack orphan 2 weeks ago php-opis-closureorphan, remi 2 weeks ago php-pimple orphan 2 weeks ago php-punic orphan 2 weeks ago php-ralouphie-getallheaders orphan 2 weeks ago php-scssphp orphan 2 weeks ago php-stecman-symfony-console-orphan 2 weeks ago completion prometheus-jmx-exporter orphan 0 weeks ago prometheus-simpleclient-javaorphan 0 weeks ago python-aiomqtt orphan 5 weeks ago python-autoprop orphan 5 weeks ago python-colorcet orphan 5 weeks ago python-jose orphan 1 weeks ago python-limits orphan 4 weeks ago python-paramorphan 5 weeks ago python-pyct orphan 5 weeks ago python-signature-dispatch orphan 5 weeks ago python-vecrec orphan 5 weeks ago snakeyaml mizdebsk, orphan, sbluhm 0 weeks ago vim-editorconfigorphan 1 weeks ago The following packages require above mentioned packages: Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago) NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, thaller) NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = 1.32-4.fc40 NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires libteamdctl.so.0()(64bit) anaconda (maintained by: anaconda-maint, jkonecny, kkoukiou, m4rtink, rvykydal,
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 -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
network service removed in Fedora 40 without a Change proposal(?)
Michel Lind just prompted me to notice that the 'network' service appears to have been removed from initscripts in Fedora 40+. This change seems to have landed in February without any fanfare - https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd043b75963f7cac?branch=rawhide . There is no Change for it, AFAICS. This does not appear to be driven by upstream removing it, because the commit apparently specifically adds 'NO_NETWORK_SCRIPTS=true' to remove it from the build. Presumably without that, it would still be built. I'm a bit worried about this arriving unannounced and apparently mostly unnoticed. There *are* still reasons to use the network service; I still use it on the openQA worker hosts, for instance, because there is integration between openvswitch and the legacy network service, but no integration between openvswitch and NetworkManager. I also use an ifup- pre-local script to pre-create tap devices; NetworkManager apparently does not support this natively. There's a suggested workaround at https://access.redhat.com/solutions/6900331 , which is helpful, but still, it's a significant change if you're using that mechanism. As a user of this service, I would've expected more of a heads-up that it was going away; if I hadn't happened to catch Michel's message I might have upgraded openQA staging to F40 immediately on release (as I usually do) and been rather surprised that the network setup stopped working. I'm sure I will find a way to re-engineer this rather complicated network setup without network.service, but a bit more of a heads up would have been nice. Should this have been a Change? How worried are we about it going out in Fedora 40 without having been through the Change process? -- 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 Fri, Apr 12, 2024 at 09:47:04AM -0700, Adam Williamson wrote: > On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote: > > 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. > > This is one reason most systems provide a sheet of one-time backup > codes that you're meant to print out and keep in a safe place, for > recovery from exactly that scenario. > > Alternatively, if you have an old phone or tablet lying around, just > install an MFA app on that and enrol it too, lock it in a cabinet, then > if you ever lose your primary phone, use it to recover. So the problem with github is they don't allow you to have 2FA on a backup device (or rather, it *is* possible, but the process is ludicrous[1]). If you have your phone as second FA and lose it then you have to immediately fall back to the piece of paper. [1] https://github.com/orgs/community/discussions/78027 I really hope we can avoid that mistake. Rich. > Also, these days, most authenticator apps support some kind of backup > mechanism. FreeOTP lets you back up to a file (which you should, of > course, keep somewhere safe and ideally encrypted). Google > Authenticator can backup To The Cloud. > -- > 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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Obsolete pygobject3-devel usage
The pygobject3-devel compat provides was recently removed from python3- gobject-devel: https://src.fedoraproject.org/rpms/pygobject3/c/0eda657eab55405bdbebc6eb3112fcf7dcb517ba?branch=rawhide However, a number of packages still use it, and now FTBFS as a result: accerciser.spec:BuildRequires: pygobject3-devel bolt.spec:BuildRequires: pygobject3-devel gnome-abrt.spec:BuildRequires: pygobject3-devel gnumeric.spec:BuildRequires:pygobject3-devel gom.spec:BuildRequires: pygobject3-devel gst-editing-services.spec:BuildRequires: pygobject3-devel mozo.spec:BuildRequires: pygobject3-devel nautilus-python.spec:BuildRequires: pygobject3-devel nfoview.spec:BuildRequires: pygobject3-devel piper.spec:BuildRequires: pygobject3-devel pluma.spec:BuildRequires: pygobject3-devel python-caja.spec:BuildRequires: pygobject3-devel python-gstreamer1.spec:BuildRequires: pygobject3-devel sugar-toolkit-gtk3.spec:BuildRequires: pygobject3-devel xpra.spec:BuildRequires: pygobject3-devel zbar.spec:BuildRequires:pygobject3-devel This is blocking the F40 rebuild of a number of flatpaks, so I'll provenpackager them soon if not fixed by then. -- Yaakov Selkowitz Principal Software Engineer - Emerging RHEL Red Hat, Inc. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Fri, Apr 12, 2024 at 07:59:46AM -0700, Carlos Rodriguez-Fernandez wrote: > Regarding libteam, the author of the package is the maintainer, email in > bugzilla is different than the one on the project. I wonder if Jiro just > missed the notification that his package is failing to build in F40. > Indeed. cc-ing Jiri to see if he wants to be added back. Jiri, if you do so, maybe change your email in https://accounts.fedoraproject.org/user/salimma/settings/email/ ? Meanwhile I'm doing a build that removes the network-scripts-teamd subpackage - my initial glance at the changelog was wrong, most Fedora releases are already on 1.32 so we don't need to bump the package yet. 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
What about simply blocking access to the git repos/koji/bodhi for those
without 2fa?
On Fri, Apr 12, 2024 at 12:05 PM Kevin Fenzi wrote:
> On Thu, Apr 11, 2024 at 05:49:27PM -0700, Adam Williamson wrote:
> > 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.
>
> I was wanting to circle back and add some more info to this thread too.
>
> So, right now as far as I know, IPA doesn't have a way to easily say
> 'require a otp to be enrolled if you want to be added to this group'.
>
> We do have a script that can check current members of a group(s) for otp
> and nag them. This is what we do for sysadmin groups, although we
> haven't done it in a while.
>
> So, if FESCo decided we wanted to enforce 2fa for provenpackagers or
> whatever, right now that would require some work on some scripting,
> which I guess would remove people without otp? But then there would
> still be a window when the user was added and before the script removed
> them. Or some way for sponsors to check otp status before sponsoring
> someone, but if thats manually it could be missed.
>
> I think in any case it might be good to find all the {proven}packager
> members without otp and perhaps email them a note about how to set
> things up, etc.
>
> kevin
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Fri, Apr 12, 2024 at 09:09:31AM -0500, Maxwell G wrote: > Report started at 2024-04-12 13:04:40 UTC > libteam orphan 0 weeks > ago > > The following packages require above mentioned packages: > Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago) > NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, > danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, > thaller) > NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = > 1.32-4.fc40 > NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires > libteamdctl.so.0()(64bit) > > anaconda (maintained by: anaconda-maint, jkonecny, kkoukiou, m4rtink, > rvykydal, vladimirslavik, vponcova) > anaconda-core-41.9-1.fc41.x86_64 requires NetworkManager = > 1:1.46.0-2.fc41, NetworkManager-libnm = 1:1.46.0-2.fc41, NetworkManager-team > = 1:1.46.0-2.fc41, teamd = 1.32-4.fc40 > anaconda-gui-41.9-1.fc41.x86_64 requires NetworkManager-wifi = > 1:1.46.0-2.fc41 > > ladvd (maintained by: @epel-packagers-sig, ixs, ttorcz) > ladvd-1.1.2-20.fc40.src requires libteam-devel = 1.32-4.fc40 > ladvd-1.1.2-20.fc40.x86_64 requires libteam.so.5()(64bit) > ... That's a lot of dependent packages! I've taken up libteam, the open bugs seem reasonable to fix and there is a new release as well (I'll prioritize fixing the bug first then build the new release in Rawhide first). If there's anyone who is interested in comaintaining libteam, let me know. 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 10:10 -0700, Carlos Rodriguez-Fernandez wrote: > Yes that works too. By the time I was setting up MFA everywhere, and > doing the code printing, I recall not all systems giving me that option, Yeah, FreeOTP resisted doing backups for a long time on the basis that it wasn't "secure" enough, which may be what you're remembering. (you could still kinda back it up from a rooted phone, but it was a bit weird.) These days it has a native backup option, though. > and finding the paper thing not very good as recovery mechanism for me, > so I went with Yubikeys and my own backup-in-the-cloud mechanism. I was > just sharing an option just in case it could serve someone that is > hesitating by giving some ideas :). For sure, whatever works for you is always the best way :) -- 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
Yes that works too. By the time I was setting up MFA everywhere, and doing the code printing, I recall not all systems giving me that option, and finding the paper thing not very good as recovery mechanism for me, so I went with Yubikeys and my own backup-in-the-cloud mechanism. I was just sharing an option just in case it could serve someone that is hesitating by giving some ideas :). On 4/12/24 09:47, Adam Williamson wrote: On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote: 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. This is one reason most systems provide a sheet of one-time backup codes that you're meant to print out and keep in a safe place, for recovery from exactly that scenario. Alternatively, if you have an old phone or tablet lying around, just install an MFA app on that and enrol it too, lock it in a cabinet, then if you ever lose your primary phone, use it to recover. Also, these days, most authenticator apps support some kind of backup mechanism. FreeOTP lets you back up to a file (which you should, of course, keep somewhere safe and ideally encrypted). Google Authenticator can backup To The Cloud. 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: Three steps we could take to make supply chain attacks a bit harder
On Fri, Apr 12, 2024 at 09:47:04AM -0700, Adam Williamson wrote: > On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote: > > 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. > > This is one reason most systems provide a sheet of one-time backup > codes that you're meant to print out and keep in a safe place, for > recovery from exactly that scenario. > > Alternatively, if you have an old phone or tablet lying around, just > install an MFA app on that and enrol it too, lock it in a cabinet, then > if you ever lose your primary phone, use it to recover. > > Also, these days, most authenticator apps support some kind of backup > mechanism. FreeOTP lets you back up to a file (which you should, of > course, keep somewhere safe and ideally encrypted). Google > Authenticator can backup To The Cloud. yeah, I'll put in a plug for the one I use: https://github.com/beemdevelopment/Aegis It's open source, available on f-droid and play store, can to encrypted backups, pretty active upstream, highly rated in reviews. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote: > 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. This is one reason most systems provide a sheet of one-time backup codes that you're meant to print out and keep in a safe place, for recovery from exactly that scenario. Alternatively, if you have an old phone or tablet lying around, just install an MFA app on that and enrol it too, lock it in a cabinet, then if you ever lose your primary phone, use it to recover. Also, these days, most authenticator apps support some kind of backup mechanism. FreeOTP lets you back up to a file (which you should, of course, keep somewhere safe and ideally encrypted). Google Authenticator can backup To The Cloud. -- 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
[EPEL-devel] Re: RFC: Django latest vs LTS maintenance plan
On Thu, Apr 11, 2024 at 03:41:02PM -0500, Michel Lind wrote: > 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 To be clear, in fedora right? There wouldn't be a bare python-django in EPEL? > - 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. I think it does make a lot of sense. ;) On the epel side, it would be good to make some noise/announce when a LTS one is marked deprecated and when it's retired, since 3rd parties might be using it for the external stuff even if everything in EPEL moves to the new one. Would a EPEL package moving to a new LTS release need exceptions/announcements also? I mean, ideally it doesn't matter, but it would be a large version jump, even if the dependent package didn't change otherwise. Also, there might be cases where the dependent package does have to change... ie, foo-1.0 works with django-3.2, but when 4.2 lands you have to upgrade to foo-2.0 to work with it? Anyhow, I think this is a pretty reasonable process, but we should make sure and communicate it very well, document it and make sure epel steering comittee is happy with it. kevin signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Thu, Apr 11, 2024 at 05:49:27PM -0700, Adam Williamson wrote:
> 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.
I was wanting to circle back and add some more info to this thread too.
So, right now as far as I know, IPA doesn't have a way to easily say
'require a otp to be enrolled if you want to be added to this group'.
We do have a script that can check current members of a group(s) for otp
and nag them. This is what we do for sysadmin groups, although we
haven't done it in a while.
So, if FESCo decided we wanted to enforce 2fa for provenpackagers or
whatever, right now that would require some work on some scripting,
which I guess would remove people without otp? But then there would
still be a window when the user was added and before the script removed
them. Or some way for sponsors to check otp status before sponsoring
someone, but if thats manually it could be missed.
I think in any case it might be good to find all the {proven}packager
members without otp and perhaps email them a note about how to set
things up, etc.
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Fedora 40 compose report: 20240412.n.0 changes
OLD: Fedora-40-20240411.n.0 NEW: Fedora-40-20240412.n.0 = SUMMARY = Added images:2 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 5 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 27.96 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -3.03 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240412.n.0.iso Image: Kinoite ociarchive ppc64le Path: Kinoite/ppc64le/images/Fedora-Kinoite-40.20240412.n.0.ociarchive = DROPPED IMAGES = Image: SoaS raw-xz aarch64 Path: Spins/aarch64/images/Fedora-SoaS-40-20240411.n.0.aarch64.raw.xz = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: arm-image-installer-4.1-4.fc40 Old package: arm-image-installer-4.1-3.fc40 Summary: Writes binary image files to any specified block device RPMs: arm-image-installer Size: 46.87 KiB Size change: -96 B Changelog: * Wed Apr 10 2024 Peter Robinson - 4.1-4 - Fix for spi flashing tool Package: phoc-0.37.0-1.fc40 Old package: phoc-0.32.0-3.fc40 Summary: Display compositor designed for phones RPMs: phoc Size: 722.52 KiB Size change: 46.59 KiB Changelog: * Tue Apr 09 2024 Kevin Fenzi - 0.37.0-1 - Update for new phosh. Package: phosh-0.37.1-1.fc40 Old package: phosh-0.32.0-2.fc40 Summary: Graphical shell for mobile devices RPMs: phosh Size: 2.69 MiB Size change: -222.83 KiB Changelog: * Sun Jan 21 2024 Fedora Release Engineering - 0.32.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Thu Jan 25 2024 Fedora Release Engineering - 0.32.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Tue Apr 09 2024 Kevin Fenzi - 0.37.1-1 - Update to 0.37.1. Fixes FTBFS/FTI bug Package: snapshot-46.1-3.fc40 Old package: snapshot-46.1-1.fc40 Summary: Take pictures and videos RPMs: snapshot Size: 2.96 MiB Size change: -2.82 MiB Changelog: * Tue Apr 02 2024 Fabio Valentini - 46.1-2 - Revert to de-vendoring dependencies on Fedora * Tue Apr 09 2024 Adam Williamson - 46.1-3 - Backport caps preference fix, disable portal usage Package: uboot-tools-1:2024.04-1.fc40 Old package: uboot-tools-1:2024.04-0.8.rc5.fc40 Summary: U-Boot utilities RPMs: uboot-images-armv8 uboot-tools Size: 21.55 MiB Size change: -41.42 KiB Changelog: * Wed Apr 03 2024 Peter Robinson - 1:2024.04-1 - Update to 2024.04 GA - Rockchip rk3328 USB fixes = 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
On Thu, Apr 11, 2024 at 02:03:01PM -0700, Brian C. Lane wrote: > 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. Indeed. I added that check, and the same check in the place where symlinks were removed when package was uninstalled (/usr/sbin/foo should be removed only if it actually points to ../bin/foo). I also added one more scriptlet to do create symlinks, so now there's %filetriggerin -- /usr/bin %filetriggerpostun -- /usr/bin %filetriggerpostun -- /usr/sbin I did more testing and I think this now covers all cases of installs, upgrades, downgrades, and reinstalls. 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: Orphaned packages looking for new maintainers
Regarding libteam, the author of the package is the maintainer, email in bugzilla is different than the one on the project. I wonder if Jiro just missed the notification that his package is failing to build in F40. On 4/12/24 07:09, Maxwell G wrote: Report started at 2024-04-12 13:04:40 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainersStatus Change container-workflow-tool orphan 2 weeks ago emacs-htmlize orphan 3 weeks ago jolokia-jvm-agent orphan 0 weeks ago kio-upnp-ms jgrulich, orphan 5 weeks ago libteam orphan 0 weeks ago loudgainorphan 4 weeks ago mingw-freeimage orphan 0 weeks ago mrxvt orphan 4 weeks ago nextcloud ichavero, orphan 2 weeks ago perl-WWW-Google-Contactsorphan 5 weeks ago php-aws-sdk3orphan 2 weeks ago php-bantu-ini-get-wrapper adamwill, orphan 2 weeks ago php-christophwurst-id3parserorphan 2 weeks ago php-deepdiver-zipstreamer orphan 2 weeks ago php-doctrine-dbal orphan, remi 2 weeks ago php-fgrosse-phpasn1 orphan 2 weeks ago php-giggsey-locale orphan 2 weeks ago php-guzzlehttp-guzzle6 orphan 2 weeks ago php-league-uri-interfaces orphan 2 weeks ago php-opencloud-openstack orphan 2 weeks ago php-opis-closureorphan, remi 2 weeks ago php-pimple orphan 2 weeks ago php-punic orphan 2 weeks ago php-ralouphie-getallheaders orphan 2 weeks ago php-scssphp orphan 2 weeks ago php-stecman-symfony-console-orphan 2 weeks ago completion prometheus-jmx-exporter orphan 0 weeks ago prometheus-simpleclient-javaorphan 0 weeks ago python-aiomqtt orphan 5 weeks ago python-autoprop orphan 5 weeks ago python-colorcet orphan 5 weeks ago python-jose orphan 1 weeks ago python-limits orphan 4 weeks ago python-paramorphan 5 weeks ago python-pyct orphan 5 weeks ago python-signature-dispatch orphan 5 weeks ago python-vecrec orphan 5 weeks ago snakeyaml mizdebsk, orphan, sbluhm 0 weeks ago vim-editorconfigorphan 1 weeks ago The following packages require above mentioned packages: Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago) NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, thaller) NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = 1.32-4.fc40 NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires
Fedora rawhide compose report: 20240412.n.0 changes
OLD: Fedora-Rawhide-20240411.n.0 NEW: Fedora-Rawhide-20240412.n.0 = SUMMARY = Added images:3 Dropped images: 0 Added packages: 10 Dropped packages:5 Upgraded packages: 157 Downgraded packages: 0 Size of added packages: 12.07 MiB Size of dropped packages:5.96 MiB Size of upgraded packages: 11.79 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -38.69 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20240412.n.0.iso Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20240412.n.0.x86_64.iso Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20240412.n.0.aarch64.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: golang-github-gammazero-deque-0.2.1-1.fc41 Summary: Fast ring-buffer deque (double-ended queue) RPMs:golang-github-gammazero-deque-devel Size:17.25 KiB Package: golang-github-matrix-org-gomatrixserverlib-0-0.2.20240411gitc2391f7.fc41 Summary: Go library for matrix federation RPMs:golang-github-matrix-org-gomatrixserverlib-devel Size:176.83 KiB Package: golang-mau-util-0.4.1-1.fc41 Summary: Various Go utilities used by mautrix-go and bridges RPMs:golang-mau-util-devel Size:65.33 KiB Package: golang-mau-zeroconfig-0.1.2-1.fc41 Summary: A relatively simple declarative config format for zerolog RPMs:golang-mau-zeroconfig-devel Size:19.83 KiB Package: golang-maunium-mauflag-1.0.0-1.fc41 Summary: An extendable argument parser for Golang RPMs:golang-maunium-mauflag-devel Size:25.41 KiB Package: python-django4.2-4.2.11-2.fc41 Summary: A high-level Python Web framework RPMs:python-django4.2-bash-completion python3-django4.2 python3-django4.2-doc Size:10.20 MiB Package: python-pyzstd-0.15.10-1.fc41 Summary: Python bindings to Zstandard (zstd) compression library RPMs:python3-pyzstd Size:351.57 KiB Package: python-tensordict-0.3.1-1.fc41 Summary: TensorDict is a PyTorch dedicated tensor container RPMs:python3-tensordict Size:1000.37 KiB Package: rust-envy-0.4.2-1.fc41 Summary: Deserialize env vars into typesafe structs RPMs:rust-envy+default-devel rust-envy-devel Size:24.03 KiB Package: trend-1.4-1.fc41 Summary: A General-Purpose, Efficient Trend Graph RPMs:trend Size:241.56 KiB = DROPPED PACKAGES = Package: golang-github-alcortesm-tgz-0-0.18.20180405git9c5fe88.fc40 Summary: Go library to extract tgz files to temporal directories RPMs:golang-github-alcortesm-tgz-devel Size:12.47 KiB Package: golang-gopkg-src-d-git-4-4.13.1-15.fc40 Summary: A highly extensible git implementation in pure go RPMs:golang-gopkg-src-d-git-4 golang-gopkg-src-d-git-4-devel Size:5.62 MiB Package: rust-gstreamer-audio-sys0.21-0.21.1-1.fc41 Summary: FFI bindings to libgstaudio-1.0 RPMs:rust-gstreamer-audio-sys0.21+default-devel rust-gstreamer-audio-sys0.21+v1_16-devel rust-gstreamer-audio-sys0.21+v1_18-devel rust-gstreamer-audio-sys0.21+v1_20-devel rust-gstreamer-audio-sys0.21+v1_22-devel rust-gstreamer-audio-sys0.21+v1_24-devel rust-gstreamer-audio-sys0.21-devel Size:94.59 KiB Package: rust-gstreamer-base0.21-0.21.2-1.fc41 Summary: Rust bindings for GStreamer Base library RPMs:rust-gstreamer-base0.21+default-devel rust-gstreamer-base0.21+v1_14_1-devel rust-gstreamer-base0.21+v1_16-devel rust-gstreamer-base0.21+v1_18-devel rust-gstreamer-base0.21+v1_20-devel rust-gstreamer-base0.21+v1_22-devel rust-gstreamer-base0.21+v1_24-devel rust-gstreamer-base0.21-devel Size:127.90 KiB Package: rust-gstreamer-video-sys0.21-0.21.2-1.fc41 Summary: FFI bindings to libgstvideo-1.0 RPMs:rust-gstreamer-video-sys0.21+default-devel rust-gstreamer-video-sys0.21+v1_16-devel rust-gstreamer-video-sys0.21+v1_18-devel rust-gstreamer-video-sys0.21+v1_20-devel rust-gstreamer-video-sys0.21+v1_22-devel rust-gstreamer-video-sys0.21+v1_24-devel rust-gstreamer-video-sys0.21-devel Size:105.77 KiB = UPGRADED PACKAGES = Package: AusweisApp2-2.1.1-1.fc41 Old package: AusweisApp2-2.1.0-5.fc41 Summary: Online identification with German ID card (Personalausweis) RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc Size: 21.86 MiB Size change: 17.47 KiB Changelog: * Thu Apr 11 2024 Julian Sikorski - 2.1.1-1 - Update to 2.1.1 Package: Cython-3.0.9-2.fc41 Old package: Cython-3.0.9-1.fc41 Summary: Language for writing Python extension modules RPMs: python3-cython Size: 15.57 MiB Size change: -21.64 KiB Changelog: * Thu Apr 11 2024 Miro Hron??ok - 3.0.9-2 - Don't BuildRequire pythran in RHEL Package: Mayavi-4.8.1^20240314.db518f8-1.fc41 Old package: Mayavi-4.8.1-5.fc39 Summary: Scientific data 3-dimensional visualizer RPMs: Mayavi Mayavi
Orphaned packages looking for new maintainers
Report started at 2024-04-12 13:04:40 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainersStatus Change container-workflow-tool orphan 2 weeks ago emacs-htmlize orphan 3 weeks ago jolokia-jvm-agent orphan 0 weeks ago kio-upnp-ms jgrulich, orphan 5 weeks ago libteam orphan 0 weeks ago loudgainorphan 4 weeks ago mingw-freeimage orphan 0 weeks ago mrxvt orphan 4 weeks ago nextcloud ichavero, orphan 2 weeks ago perl-WWW-Google-Contactsorphan 5 weeks ago php-aws-sdk3orphan 2 weeks ago php-bantu-ini-get-wrapper adamwill, orphan 2 weeks ago php-christophwurst-id3parserorphan 2 weeks ago php-deepdiver-zipstreamer orphan 2 weeks ago php-doctrine-dbal orphan, remi 2 weeks ago php-fgrosse-phpasn1 orphan 2 weeks ago php-giggsey-locale orphan 2 weeks ago php-guzzlehttp-guzzle6 orphan 2 weeks ago php-league-uri-interfaces orphan 2 weeks ago php-opencloud-openstack orphan 2 weeks ago php-opis-closureorphan, remi 2 weeks ago php-pimple orphan 2 weeks ago php-punic orphan 2 weeks ago php-ralouphie-getallheaders orphan 2 weeks ago php-scssphp orphan 2 weeks ago php-stecman-symfony-console-orphan 2 weeks ago completion prometheus-jmx-exporter orphan 0 weeks ago prometheus-simpleclient-javaorphan 0 weeks ago python-aiomqtt orphan 5 weeks ago python-autoprop orphan 5 weeks ago python-colorcet orphan 5 weeks ago python-jose orphan 1 weeks ago python-limits orphan 4 weeks ago python-paramorphan 5 weeks ago python-pyct orphan 5 weeks ago python-signature-dispatch orphan 5 weeks ago python-vecrec orphan 5 weeks ago snakeyaml mizdebsk, orphan, sbluhm 0 weeks ago vim-editorconfigorphan 1 weeks ago The following packages require above mentioned packages: Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago) NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, thaller) NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = 1.32-4.fc40 NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires libteamdctl.so.0()(64bit) anaconda (maintained by: anaconda-maint, jkonecny, kkoukiou, m4rtink, rvykydal,
Re: [SPDX] Mass license change AGPLv3+ to AGPL-3.0-or-later
On 12. 04. 24 11:22, Miroslav Suchý wrote: Hi. I am going to do the mass change of the license from AGPLv3+ to AGPL-3.0-or-later The proposed diff is in attachment. Affected packages: simarrange I had a look at this package of mine and realized I borked the rpmautospec conversion, so I opened https://src.fedoraproject.org/rpms/simarrange/pull-request/3 -- it includes the SPDX conversion. -- 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: convert everything to rpmautospec?
I think missing easy to use documentation is the most missing part of current rpmautospec package. Manual page does not exist, readme is in wrong package. I have proposed to be able to include extra section just for changelog. I do not remember which exactly way was merged instead, there should be something use-able. But is not easy to find. Currently just first line is used as changelog entry. It might be skipped with special tag in commit, but that is nowhere to be found in documentation present with the package. I think simple tags could be used to mark noteworthy changes only for releases. I think autospec is great, as it especially makes longer term pull requests easy to merge. Avoiding stupid conflict with changelog bumps. But I think there is still a lot to improve in usability part. For many packages without significant function changes it is just fine. Significant changes should be mentioned in updates or linked bugs, rather than commit messages. But problem is rawhide automatic updates contains just changelog and not really anything useful. I find it not easy to fill this part. If the project contains changelog, I would recommend it as part of the package %doc files. It takes extra work to maintain one however. I would find it nice to generate nice looking update messages from commit, but current implementation is not sufficient IMO. Nice looking references to upstream issues or release notes would be nice too. On 09. 04. 24 10:04, Remi Collet wrote: Le 07/04/2024 à 17:15, Zbigniew Jędrzejewski-Szmek a écrit : Thus, the proposal: - new packages MUST use rpmautospec - packagers SHOULD convert their packages - provenpackagers MAY convert existing packages (e.g. when they want to push some fix or separately from other work) - people submitting pull requests against src.fp.o MAY also include a conversion in the pull request and packagers SHOULD merge it. Big -1 to all git log IS NOT a package changelog Read https://keepachangelog.com/en/1.1.0/ Remi -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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?
Before any such ideas continue, I think rpmautospec should have more decent documentation. Unfortunately it does not have even manual page for rpmautospec command, core of its functionality. I find that missing. While I think rpmautospec is great idea, I do not think it is ready universally. Correct me if I am wrong, but I think there is no way to make rightmost bump as done by rpmdev-bumpspec -r. We use it a lot for RHEL minor version updates. But there does not seem to be a way to mark some commit, after which only rightmost bumps should occur. While I have intentionaly converted many my packages, I am keeping some more complicated intentionally the old way. Especially because it allows me to rebuild those packages for CentOS/RHEL and compare their functionality. Is there full support for rpmautospec in COPR for example? I don't know. I have not seen it mentioned in docs. It seems too early for any MUST related with this. On 07. 04. 24 17:15, Zbigniew Jędrzejewski-Szmek wrote: Hi everyone, I'm revisting the topic of rpmautospec because I was doing some work on various packages, and it's annoying that some packages are using rpmautospec and others are not. All my packages have been converted, so in day-to-day work, I don't even think about %changelog. When working with other packages, I'll forget to update the Relase and/or %changelog. Today I was rebasing some pull requests in pagure, and the _only_ conflicts that I had were about Release and %changelog. I think it's time to switch to rpmautospec completely. Thus, the proposal: - new packages MUST use rpmautospec I think this still be SHOULD. AFAIK rpmfusion does not work with rpmautospec and other distributions may not as well. Forcing this to everyone does not seem reasonable to me, although I would recommend it everywhere where possible. - packagers SHOULD convert their packages - provenpackagers MAY convert existing packages (e.g. when they want to push some fix or separately from other work) No, please don't. provenpackagers should not make significant changes to packages without communication with their maintainers. rpmautospec conversion requires change of workflow and should never be done without maintainer agreement. PR are okay, but not direct commits. - people submitting pull requests against src.fp.o MAY also include a conversion in the pull request and packagers SHOULD merge it. (FTR, 'rpmautospec convert' does the conversion, incl. the commit to dist-git. Manual conversion should not be used.) Zbyszek This again should be documented in installed package. Sadly it does not contain even README doc file with very basic information. Or it does in python3-rpmautospec, which is where I doubt those information is usually expected. I think easy to find documentation with skip changelog [1] instructions should be easy to find on the installed system. I do not think it is. 1. https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries -- Petr Menšík Software Engineer, RHEL Red Hat,http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 AGPLv3+ to AGPL-3.0-or-later
Hi.
I am going to do the mass change of the license from AGPLv3+ to
AGPL-3.0-or-later
The proposed diff is in attachment.
Affected packages:
conspy
fastx_toolkit
fondo
libgtextutils
libquvi-scripts
netstat-monitor
pyhoca-cli
pyhoca-gui
python-x2go
python-surt
simarrange
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/conspy.spec rpm-specs/conspy.spec
--- rpm-specs.orig/conspy.spec 2024-04-11 04:03:22.0 +0200
+++ rpm-specs/conspy.spec 2024-04-12 11:18:22.429455246 +0200
@@ -1,9 +1,9 @@
Name: conspy
Version:1.14
-Release:13%{?dist}
+Release:14%{?dist}
Summary:Remote control for text mode virtual consoles
-License:AGPLv3+
+License:AGPL-3.0-or-later
URL:https://sourceforge.net/projects/conspy/
Source0:https://sourceforge.net/projects/conspy/files/%{name}-%{version}-1/%{name}-%{version}.tar.gz
@@ -40,6 +40,9 @@
%{_bindir}/%{name}
%changelog
+* Fri Apr 12 2024 Miroslav Suchý - 1.14-14
+- convert license to SPDX
+
* Wed Jan 24 2024 Fedora Release Engineering - 1.14-13
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
diff -Naur rpm-specs.orig/fastx_toolkit.spec rpm-specs/fastx_toolkit.spec
--- rpm-specs.orig/fastx_toolkit.spec 2024-01-25 03:06:58.0 +0100
+++ rpm-specs/fastx_toolkit.spec 2024-04-12 11:18:22.799458578 +0200
@@ -1,9 +1,9 @@
Name: fastx_toolkit
Version: 0.0.14
-Release: 34%{?dist}
+Release: 35%{?dist}
Summary: Tools to process short-reads FASTA/FASTQ files
-License: AGPLv3+
+License: AGPL-3.0-or-later
URL: http://hannonlab.cshl.edu/%{name}/index.html
Source0: http://hannonlab.cshl.edu/%{name}/%{name}-%{version}.tar.bz2
Patch0: %{name}-gcc47.patch
@@ -83,6 +83,9 @@
%{_datadir}/%{name}
%changelog
+* Fri Apr 12 2024 Miroslav Suchý - 0.0.14-35
+- convert license to SPDX
+
* Wed Jan 24 2024 Fedora Release Engineering - 0.0.14-34
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
diff -Naur rpm-specs.orig/fondo.spec rpm-specs/fondo.spec
--- rpm-specs.orig/fondo.spec 2024-01-25 03:07:40.0 +0100
+++ rpm-specs/fondo.spec 2024-04-12 11:18:23.260462729 +0200
@@ -2,10 +2,10 @@
Name: fondo
Version:1.6.1
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Find the most beautiful wallpapers
-License:AGPLv3+
+License:AGPL-3.0-or-later
URL:https://github.com/calo001/fondo
Source0:%{url}/archive/%{version}/%{name}-%{version}.tar.gz
@@ -68,6 +68,9 @@
%changelog
+* Fri Apr 12 2024 Miroslav Suchý - 1.6.1-8
+- convert license to SPDX
+
* Wed Jan 24 2024 Fedora Release Engineering - 1.6.1-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
diff -Naur rpm-specs.orig/libgtextutils.spec rpm-specs/libgtextutils.spec
--- rpm-specs.orig/libgtextutils.spec 2024-01-26 03:18:30.0 +0100
+++ rpm-specs/libgtextutils.spec 2024-04-12 11:18:23.631466070 +0200
@@ -1,9 +1,9 @@
Name: libgtextutils
Version: 0.7
-Release: 34%{?dist}
+Release: 35%{?dist}
Summary: Assaf Gordon text utilities
-License: AGPLv3+
+License: AGPL-3.0-or-later
URL: http://hannonlab.cshl.edu/fastx_toolkit/
Source0: https://github.com/agordon/%{name}/releases/download/%{version}/%{name}-%{version}.tar.gz
Patch0: libgtextutils-GCC6-iostream.patch
@@ -58,6 +58,9 @@
%{_libdir}/pkgconfig/gtextutils.pc
%changelog
+* Fri Apr 12 2024 Miroslav Suchý - 0.7-35
+- convert license to SPDX
+
* Thu Jan 25 2024 Fedora Release Engineering - 0.7-34
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
diff -Naur rpm-specs.orig/libquvi-scripts.spec rpm-specs/libquvi-scripts.spec
--- rpm-specs.orig/libquvi-scripts.spec 2024-01-26 03:19:21.0 +0100
+++ rpm-specs/libquvi-scripts.spec 2024-04-12 11:18:23.998469375 +0200
@@ -2,9 +2,9 @@
Name: libquvi-scripts
Version:0.9.20131130
-Release:22%{?dist}
+Release:23%{?dist}
Summary:Embedded lua scripts for parsing the media details
-License:AGPLv3+
+License:AGPL-3.0-or-later
URL:http://quvi.sourceforge.net
Source0:http://downloads.sourceforge.net/project/quvi/0.9/%{name}/%{name}-%{version}.tar.xz
BuildArch: noarch
@@ -41,6 +41,9 @@
%{_mandir}/man7/quvi-modules*.7*
%changelog
+* Fri Apr 12 2024 Miroslav Suchý - 0.9.20131130-23
+- convert license to SPDX
+
* Thu Jan 25 2024 Fedora Release Engineering - 0.9.20131130-22
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
diff -Naur rpm-specs.orig/netstat-monitor.spec rpm-specs/netstat-monitor.spec
--- rpm-specs.orig/netstat-monitor.spec 2024-04-11 04:21:28.0 +0200
+++ rpm-specs/netstat-monitor.spec 2024-04-12 11:18:24.519474067 +0200
@@ -1,9 +1,9 @@
Name: netstat-monitor
Version:
Re: [SPDX] Mass license change EUPL 1.2 to EUPL-1.2
Dne 05. 04. 24 v 10:49 dop. Miroslav Suchý napsal(a): Hi. I am going to do the mass change of the license from EUPL 1.2 to EUPL-1.2. The proposed diff is in attachment. Affected packages: AusweisApp2 rust-tpm2-policy dbus-parsec Unless somebody stop me, I will do this change directly in dist-git after a week. Done. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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, 2024-04-11 at 15:26 +0200, Fabio Valentini wrote: > > - alciregi (1): rust-backoff > Hello. This is required by a package still under review (waiting for a reviewer actually). https://bugzilla.redhat.com/show_bug.cgi?id=2268499 Thank you, Alessio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
> 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. Thanks for taking the time and looking into this! > - blinxen (8): rust-btoi, rust-fallible_collections, rust-noisy_float, rust-parse-size, rust-ptyprocess, rust-sanitize-filename, rust-serde_plain, rust-symlink I don't remember why these were packaged. They can be safely retired, if nothing depends on them. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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
