Fedora-Cloud-33-20210212.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210211.0): ID: 775353 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/775353 ID: 775360 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/775360 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
> A few more things: > > * btrfs-progs tools don't yet have a way to report compression > information. While 'df' continues to report correctly about actual > blocks used and free, both regular 'du' (coreutils) and 'btrfs > filesystem du' will report uncompressed values. Are there plans for upstream to address this pretty major shortcoming in the next release of btrfs-progs? From what I can see on the btrfs wiki the user space support for compression is very rudimentary and with no real indication that it is being worked on or seen as a priority. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [F34] wait-repo task has been opened for approx 2 hours
On 2/11/21 1:40 PM, Miro Hrončok wrote: > Ad side-tags: >> >> IMO the process should work for buildroot overrides too. Side tags look >> good for big rebuilds, where not all packages belong to one maintainer, >> but it looks like an overhead for only two packages. > > If you want multiple (even two) packages to be shipped via a single > update in rawhide or branched (prior to updates testing activation), > side tag is the only way. Aha, so a chain-build only makes a sequence of builds, but they arrive into stable separately. Thanks! > > For branched (prior to updates testing activation) buildroot overrides > are possible, but the updates will be separated in bodhi. > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] 389 DS nightly 2021-02-12 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/12/report-389-ds-base-2.0.2-20210212git946f2048c.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: how to switch from rawhide to current, following branch
On Thu, Feb 11, 2021 at 9:29 PM Matthew Miller wrote: > > On Thu, Feb 11, 2021 at 06:50:05PM -0700, Chris Murphy wrote: > > OK it's updated. > > https://fedoraproject.org/wiki/Releases/Rawhide#Questions_and_Answers > > > > I couldn't figure out the offline distrosync method, dnf complained > > about it maybe being a plugin but couldn't help me find it. > > Known bug -- it's part of the python3-dnf-plugin-system-upgrade package but > the virtual provides isn't there. Should be fixed soon. The package is 51k > and probably should be installed by default. Tested that and it works also. sudo dnf config-manager --set-disabled rawhide,rawhide-modular sudo dnf config-manager --set-enabled fedora,fedora-modular,updates,updates-modular,updates-testing,updates-testing-modular sudo dnf install python3-dnf-plugin-system-upgrade sudo dnf offline-distrosync download sudo dnf offline-distrosync reboot -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
On Thu, Feb 11, 2021 at 9:58 AM Jeremy Linton wrote: > > Hi, > > On 1/1/21 8:59 PM, Chris Murphy wrote: > > Anyway, compress=zstd:1 is a good default. Everyone benefits, and I'm > > not even sure someone with a very fast NVMe drive will notice a slow > > down because the compression/decompression is threaded. > > I disagree that everyone benefits. Any read latency sensitive workload > will be slower due to the application latency being both the drive > latency plus the decompression latency. And as the kernel benchmarks > indicate very few systems are going to get anywhere near the performance > of even baseline NVMe drives when its comes to throughput. It's possible some workloads on NVMe might have faster reads or writes without compression. https://github.com/facebook/zstd btrfs compress=zstd:1 translates into zstd -1 right now; there are some ideas to remap btrfs zstd:1 to one of the newer zstd --fast options, but it's just an idea. And in any case the default for btrfs and zstd will remain as 3 and -3 respectively, which is what 'compress=zstd' maps to, making it identical to 'compress=zstd:3'. I have a laptop with NVMe and haven't come across such a workload so far, but this is obviously not a scientific sample. I think you'd need a process that's producing read/write rates that the storage can meet, but that the compression algorithm limits. Btrfs is threaded, as is the compression. What's typical, is no change in performance and sometimes a small small increase in performance. It essentially trades some CPU cycles in exchange for less IO. That includes less time reading and writing, but also less latency, meaning the gain on rotational media is greater. >Worse, if the workload is very parallel, and at max CPU already > the compression overhead will only make that situation worse as well. (I > suspect you could test this just by building some packages that have > good parallelism during the build). This is compiling the kernel on a 4/8-core CPU (circa 2011) using make -j8, the kernel running is 5.11-rc7. no compression real55m32.769s user369m32.823s sys 35m59.948s -- compress=zstd:1 real53m44.543s user368m17.614s sys 36m2.505s That's a one time test, and it's a ~3% improvement. *shrug* We don't really care too much these days about 1-3% differences when doing encryption, so I think this is probably in that ballpark, even if it turns out another compile is 3% slower. This is not a significantly read or write centric workload, it's mostly CPU. So this 3% difference may not even be related to the compression. > Plus, the write amplification comment isn't even universal as there > continue to be controllers where the flash translation layer is > compressing the data. At least consumer SSDs tend to just do concurrent write dedup. File system compression isn't limited to Btrfs, there's also F2FS contributed by Samsung which implements compression these days as well, although they commit to it at mkfs time, where as on Btrfs it's a mount option. Mix and match compressed extents is routine on Btrfs anyway, so there's no concern with users mixing things up. They can change the compression level and even the algorithm with impunity, just tacking it onto a remount command. It's not even necessary to reboot. > OTOH, it makes a lot more sense on a lot of these arm/sbc boards > utilizing MMC because the disks are so slow. Maybe if something like > this were made the default the machine should run a quick CPU > compress/decompress vs IO speed test and only enable compression if the > compress/decompress speed is at least the IO rate. It's not that simple because neither the user space writers nor kworkers are single threaded. You'd need a particularly fast NVMe matched with a not so fast CPU with a workload that somehow dumps a lot of data in a way that the compression acts as a bottle neck. It could exist. But it's not a per se problem that I've seen. But if you propose a test, I can do A/B testing. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: how to switch from rawhide to current, following branch
On Thu, Feb 11, 2021 at 06:50:05PM -0700, Chris Murphy wrote: > OK it's updated. > https://fedoraproject.org/wiki/Releases/Rawhide#Questions_and_Answers > > I couldn't figure out the offline distrosync method, dnf complained > about it maybe being a plugin but couldn't help me find it. Known bug -- it's part of the python3-dnf-plugin-system-upgrade package but the virtual provides isn't there. Should be fixed soon. The package is 51k and probably should be installed by default. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1926738] perl-Graphics-TIFF-8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1926738 --- Comment #13 from Fedora Update System --- FEDORA-2021-45a4f1130e has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-45a4f1130e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-45a4f1130e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #11 from Fedora Update System --- FEDORA-EPEL-2021-806ecfba31 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-806ecfba31 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1926738] perl-Graphics-TIFF-8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1926738 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #12 from Fedora Update System --- FEDORA-2021-e9ac81a02d has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e9ac81a02d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e9ac81a02d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: how to switch from rawhide to current, following branch
OK it's updated. https://fedoraproject.org/wiki/Releases/Rawhide#Questions_and_Answers I couldn't figure out the offline distrosync method, dnf complained about it maybe being a plugin but couldn't help me find it. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1924375] perl-JavaScript-Minifier-1.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1924375 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-JavaScript-Minifier-1. |perl-JavaScript-Minifier-1. |15-1.fc34 |15-1.fc34 ||perl-JavaScript-Minifier-1. ||15-1.fc33 Resolution|--- |ERRATA Last Closed||2021-02-12 01:41:33 --- Comment #3 from Fedora Update System --- FEDORA-2021-c3904984c0 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: how to switch from rawhide to current, following branch
On Thu, Feb 11, 2021 at 01:44:42PM -0700, Chris Murphy wrote: > The closest thing I've found for a guide on this is: > https://fedoraproject.org/wiki/Releases/Rawhide#Upgrade_from_existing_stable_install Also, we should probably migrate that to the docs site. Thread: https://lists.fedoraproject.org/archives/list/d...@lists.fedoraproject.org/message/WDR4QTGXKMXTSHULMR23SNBKLM5YK5XN/ -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-34-20210211.n.1 compose check report
Missing expected images: Minimal raw-xz armhfp Xfce raw-xz armhfp Failed openQA tests: 40/183 (x86_64), 25/124 (aarch64) New failures (same test not failed in Fedora-34-20210210.n.1): ID: 775032 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/775032 ID: 775035 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/775035 ID: 775037 Test: x86_64 Server-dvd-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/775037 ID: 775040 Test: x86_64 Server-dvd-iso server_database_client URL: https://openqa.fedoraproject.org/tests/775040 ID: 775043 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/775043 ID: 775050 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/775050 ID: 775052 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/775052 ID: 775055 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/775055 ID: 775057 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/775057 ID: 775060 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/775060 ID: 775080 Test: x86_64 Workstation-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/775080 ID: 775081 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/775081 ID: 775085 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/775085 ID: 775087 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/775087 ID: 775089 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/775089 ID: 775095 Test: x86_64 KDE-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/775095 ID: 775097 Test: x86_64 KDE-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/775097 ID: 775104 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/775104 ID: 775133 Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/775133 ID: 775139 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/775139 ID: 775144 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/775144 ID: 775172 Test: aarch64 Server-dvd-iso install_updates_nfs@uefi URL: https://openqa.fedoraproject.org/tests/775172 ID: 775185 Test: aarch64 Server-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/775185 ID: 775189 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/775189 ID: 775194 Test: aarch64 Workstation-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/775194 ID: 775200 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/775200 ID: 775285 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/775285 ID: 775333 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/775333 ID: 775336 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/775336 ID: 775337 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/775337 Old failures (same test failed in Fedora-34-20210210.n.1): ID: 775048 Test: x86_64 Server-dvd-iso mediakit_fileconflicts URL: https://openqa.fedoraproject.org/tests/775048 ID: 775086 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/775086 ID: 775091 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/775091 ID: 775092 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/775092 ID: 775096 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/775096 ID: 775098 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/775098 ID: 775101 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/775101 ID: 775102 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/775102 ID: 775106 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/775106 ID: 775107 Test: x86_64 KDE-live-iso desktop_printing URL:
Re: how to switch from rawhide to current, following branch
On Thu, Feb 11, 2021 at 4:29 PM Neal Gompa wrote: > > On Thu, Feb 11, 2021 at 6:24 PM Matthew Miller > wrote: > > > > On Thu, Feb 11, 2021 at 01:44:42PM -0700, Chris Murphy wrote: > > > sudo dnf config-manager --set-enabled > > > fedora,fedora-modular,updates,updates-modular,updates-testing,updates-testing-modular > > > sudo dnf config-manager --set-disabled rawhide,rawhide-modular > > > sudo dnf update > > > sudo dnf distro-sync > > > sudo reboot > > > > distro-sync includes upgrade / update (I prefer "update" as the term for > > non-release updates to just the newest package set, but according to the DNF > > docs that's deprecated...), so that step can be consolidated > > > > And for a big change like this, and since reboot is indicated anyway, how > > about > > > > sudo dnf offline-distrosync download > > sudo dnf offline-distrosync reboot > > > > instead of doing it online? > > > > You can also do dnf system-upgrade --releasever=rawhide, that's > usually worked for me. :) > Well the idea is to stay on current, so I guess that would be --releasever=fedora34 ? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: how to switch from rawhide to current, following branch
On Thu, Feb 11, 2021 at 6:24 PM Matthew Miller wrote: > > On Thu, Feb 11, 2021 at 01:44:42PM -0700, Chris Murphy wrote: > > sudo dnf config-manager --set-enabled > > fedora,fedora-modular,updates,updates-modular,updates-testing,updates-testing-modular > > sudo dnf config-manager --set-disabled rawhide,rawhide-modular > > sudo dnf update > > sudo dnf distro-sync > > sudo reboot > > distro-sync includes upgrade / update (I prefer "update" as the term for > non-release updates to just the newest package set, but according to the DNF > docs that's deprecated...), so that step can be consolidated > > And for a big change like this, and since reboot is indicated anyway, how > about > > sudo dnf offline-distrosync download > sudo dnf offline-distrosync reboot > > instead of doing it online? > You can also do dnf system-upgrade --releasever=rawhide, that's usually worked for me. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: how to switch from rawhide to current, following branch
On Thu, Feb 11, 2021 at 01:44:42PM -0700, Chris Murphy wrote: > sudo dnf config-manager --set-enabled > fedora,fedora-modular,updates,updates-modular,updates-testing,updates-testing-modular > sudo dnf config-manager --set-disabled rawhide,rawhide-modular > sudo dnf update > sudo dnf distro-sync > sudo reboot distro-sync includes upgrade / update (I prefer "update" as the term for non-release updates to just the newest package set, but according to the DNF docs that's deprecated...), so that step can be consolidated And for a big change like this, and since reboot is indicated anyway, how about sudo dnf offline-distrosync download sudo dnf offline-distrosync reboot instead of doing it online? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: how to switch from rawhide to current, following branch
On Thu, Feb 11, 2021 at 01:44:42PM -0700, Chris Murphy wrote:
> The closest thing I've found for a guide on this is:
> https://fedoraproject.org/wiki/Releases/Rawhide#Upgrade_from_existing_stable_install
>
> Specifically
> "Q: How do I get out of Rawhide again? I want to switch to the
> Branched release or a stable release."
>
> The problem is the suggested commands depending on 'su -c' don't work
> by default on at least Workstation because the root user is disabled;
> and is not required to be enabled even on Server. And modifying the
> command to work with sudo, it gets tripped up on the parentheses:
> -bash: syntax error near unexpected token `('
>
> I've tested the following, and propose it as a change to the wiki:
>
> --
>
> sudo dnf config-manager --set-enabled
> fedora,fedora-modular,updates,updates-modular,updates-testing,updates-testing-modular
> sudo dnf config-manager --set-disabled rawhide,rawhide-modular
> sudo dnf update
> sudo dnf distro-sync
> sudo reboot
>
> This should work for systems updated before or after branch. The more
> confusion with mixed Rawhide and current release packages, the more
> distro-sync will have to clean up.
+1, its a wiki, be bold and change it. :)
We could I suppose also advocate now offline upgrades with dnf, but that
would be more steps, so probibly not worth it.
kevin
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora 34 compose report: 20210211.n.1 changes
OLD: Fedora-34-20210210.n.1 NEW: Fedora-34-20210211.n.1 = SUMMARY = Added images:0 Dropped images: 3 Added packages: 2 Dropped packages:7 Upgraded packages: 223 Downgraded packages: 0 Size of added packages: 3.24 MiB Size of dropped packages:18.03 MiB Size of upgraded packages: 1.68 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -28.09 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-34-20210210.n.1.iso Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-34-20210210.n.1.iso Image: Xfce_Appliance raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-armhfp-34-20210210.n.1-sda.raw.xz = ADDED PACKAGES = Package: python-imageio-2.9.0-1.fc34 Summary: Python IO of image, video, scientific, and volumetric data formats. RPMs:python3-imageio Size:3.21 MiB Package: python-wled-0.4.4-2.fc34 Summary: Python client for WLED RPMs:python3-wled Size:27.36 KiB = DROPPED PACKAGES = Package: apache-log4j-extras-1.2.17.1-18.fc33 Summary: Apache Extras Companion for Apache log4j RPMs:apache-log4j-extras Size:253.71 KiB Package: azureus-5.7.6.0-13.fc34 Summary: A BitTorrent Client RPMs:azureus Size:15.65 MiB Package: nodejs-shelljs-0.8.4-4.fc34 Summary: Portable Unix shell commands for Node.js RPMs:nodejs-shelljs Size:167.88 KiB Package: nodoka-theme-gnome-0.3.90-21.fc34 Summary: The Nodoka Theme Pack for Gnome RPMs:nodoka-filesystem nodoka-metacity-theme nodoka-theme-gnome Size:35.07 KiB Package: sugar-getiabooks-18.2-2.fc31 Summary: Internet Archive Books receiver for Sugar RPMs:sugar-getiabooks Size:214.83 KiB Package: sugar-infoslicer-25-7.fc31 Summary: Downloader for articles from Wikipedia RPMs:sugar-infoslicer Size:1.63 MiB Package: sugar-ruler-33-13.fc31 Summary: Simple collection of measurement tools RPMs:sugar-ruler Size:98.57 KiB = UPGRADED PACKAGES = Package: CImg-1:2.9.6-1.fc34 Old package: CImg-1:2.9.4-2.fc34 Summary: C++ Template Image Processing Toolkit RPMs: CImg-devel Size: 11.13 MiB Size change: 37.01 KiB Changelog: * Wed Feb 10 2021 josef radinger - 1:2.9.6-1 - bump version Package: NetworkManager-1:1.30.0-0.5.fc34 Old package: NetworkManager-1:1.30.0-0.4.fc34 Summary: Network connection manager and user applications RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora NetworkManager-config-server NetworkManager-dispatcher-routing-rules NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi NetworkManager-wwan Size: 29.08 MiB Size change: 55.44 KiB Changelog: * Thu Feb 11 2021 Thomas Haller - 1:1.30.0-0.5 - update to 1.30-rc1 (1.29.90-dev) snapshot Package: Thunar-4.16.3-1.fc34 Old package: Thunar-4.16.2-2.fc34 Summary: Thunar File Manager RPMs: Thunar Thunar-devel Thunar-docs Size: 10.25 MiB Size change: 4.96 KiB Changelog: * Tue Feb 09 2021 Mukundan Ragavan - 4.16.3-1 - Update to 4.16.3 Package: appeditor-1.1.1-5.fc34 Old package: appeditor-1.1.1-4.fc34 Summary: Edit application menu RPMs: appeditor Size: 575.91 KiB Size change: 776 B Changelog: * Tue Feb 09 2021 Benjamin A. Beasley - 1.1.1-5 - Correct License from ???LGPLv2+??? to ???GPLv3 and LGPLv2+ and CC0??? Package: appstream-0.14.0-1.fc34 Old package: appstream-0.13.1-2.fc34 Summary: Utilities to generate, maintain and access the AppStream database RPMs: appstream appstream-devel appstream-qt appstream-qt-devel Size: 12.61 MiB Size change: 286.87 KiB Changelog: * Thu Feb 04 2021 Rex Dieter - 0.14.0-1 - 0.14.0 Package: awscli-1.19.5-1.fc34 Old package: awscli-1.19.4-1.fc34 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.97 MiB Size change: -248 B Changelog: * Wed Feb 10 2021 Gwyn Ciesla - 1.19.5-1 - 1.19.5 Package: bacula-11.0.1-1.fc34 Old package: bacula-11.0.0-5.fc34 Summary: Cross platform network backup for Linux, Unix, Mac and Windows RPMs: bacula-client bacula-common bacula-console bacula-console-bat bacula-devel bacula-director bacula-libs bacula-libs-sql bacula-logwatch bacula-storage bacula-traymonitor nagios-plugins-bacula Size: 26.90 MiB Size change: 7.85 KiB Changelog: * Thu Feb 11 2021 Simone Caronni - 11.0.1-1 - Update to 11.0.1. Package: cairomm-1.12.0-15.fc34 Old package: cairomm-1.12.0-14.fc34 Summary: C++ API for the cairo graphics library RPMs: cairomm cairomm-devel cairomm-doc Size: 1.24 MiB Size change: -78.93 KiB Changelog: * Thu Feb 11 2021
Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage
Rex Dieter wrote: > Rex Dieter wrote: > >> Antonio T. sagitter wrote: >> >>> Hi all. >>> >>> I can't compile IceCat on Fedora 33+ since some days because of these >>> errors: >>> >>> ... >>> /usr/include/c++/11/type_traits:3164:1: error: template with C linkage >> >> This is impacting plasma-discover and flatpak, the latter's flatpak.h >> header will need to fixed first (I think) before plasma-discover can >> build again. > > Filed flatpak bug, > https://bugzilla.redhat.com/1927439 > > which blocks fixing plasma-discover FTBFS nominated as f34 blocker, and filed upstream issue https://github.com/flatpak/flatpak/issues/4117 -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ACTION NEEDED: A regression was found and fixed in pyproject-rpm-macros wrt %pyproject_save_files
On 11. 02. 21 21:38, Miro Hrončok wrote: Fedora 33: python3-blurb python3-first python3-iniconfig python3-pipdeptree python3-pygments-pytest python3-sphinx-last-updated-by-git Fedora 32: python3-blurb python3-first python3-pipdeptree python3-pygments-pytest Queries included updates testing. I've made a mistake in how I checked things, sorry. There appear to be no affected packages for Fedora 32/33. There was only ilua, but I've fixed it already. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
how to switch from rawhide to current, following branch
The closest thing I've found for a guide on this is:
https://fedoraproject.org/wiki/Releases/Rawhide#Upgrade_from_existing_stable_install
Specifically
"Q: How do I get out of Rawhide again? I want to switch to the
Branched release or a stable release."
The problem is the suggested commands depending on 'su -c' don't work
by default on at least Workstation because the root user is disabled;
and is not required to be enabled even on Server. And modifying the
command to work with sudo, it gets tripped up on the parentheses:
-bash: syntax error near unexpected token `('
I've tested the following, and propose it as a change to the wiki:
--
sudo dnf config-manager --set-enabled
fedora,fedora-modular,updates,updates-modular,updates-testing,updates-testing-modular
sudo dnf config-manager --set-disabled rawhide,rawhide-modular
sudo dnf update
sudo dnf distro-sync
sudo reboot
This should work for systems updated before or after branch. The more
confusion with mixed Rawhide and current release packages, the more
distro-sync will have to clean up.
--
--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: ACTION NEEDED: A regression was found and fixed in pyproject-rpm-macros wrt %pyproject_save_files
On 10. 02. 21 11:04, Miro Hrončok wrote: Hello Pythonistas. Unfortunately, we have found a regression in pyproject-rpm-macros wrt %pyproject_save_files. The nested __pycache__ directories were not properly owned. E.g.: /usr/lib/python3.9/site-packages/rope /usr/lib/python3.9/site-packages/rope/__pycache__ - NOT OWNED /usr/lib/python3.9/site-packages/rope/__pycache__/__init__.cpython-39.pyc A fix is approaching in pyproject-rpm-macros-0-38. Due to the mass rebuild, (close to) all packages using %pyproject_save_files have been affected in F34+. Only packages without Python directories in site-packages were immune to this bug. Binary packages affected on Fedora 34+: black doge ilua marshalparser mu oraculum python3-aioeafm python3-aioflo python3-aionotion python3-aiosqlite python3-arpeggio python3-beniget python3-bitcoinlib python3-click python3-colorzero python3-crashtest python3-distlib python3-enturclient python3-fastjsonschema python3-gast python3-guizero python3-iniconfig python3-junit_xml python3-jupyter-client python3-jupyter-core python3-jupyter-kernel-test python3-matrix-nio python3-more-itertools python3-nbformat python3-niaaml python3-noggin-messages python3-numpydoc python3-packaging python3-parver python3-pendulum python3-pep517 python3-pipreqs python3-plette python3-poetry python3-poetry-core python3-pyairnow python3-pyairvisual python3-PyGithub python3-pyglet python3-pygments python3-pyopenuv python3-pytest-spec python3-pytest-venv python3-pytile python3-requests python3-rope python3-rq python3-ryu python3-setuptools_scm python3-shellingham python3-sklearn-nature-inspired-algorithms python3-sockjs-tornado python3-sphinx-inline-tabs python3-toml python3-wtf-peewee python3-yarg pythran tox Packages on Fedora 32/33 might have been affected as well, I'll post the list(s) later today. Fedora 33: python3-blurb python3-first python3-iniconfig python3-pipdeptree python3-pygments-pytest python3-sphinx-last-updated-by-git Fedora 32: python3-blurb python3-first python3-pipdeptree python3-pygments-pytest Queries included updates testing. Since I assume the packages will be rebuilt for unrelated reasons in Fedora 34 before GA, I won't do any targeted rebuild (yet anyway). If your package was affected, a rebuild is recommended (if another update/rebuild is not anticipated in the near future). The fixed pyproject-rpm-macros is building. Ensure it is available for a given Fedora version 3X before you rebuild: $ koji wait-repo f3X-build --build=pyproject-rpm-macros-0-38.fc3X It is already available for rawhide (Fedora 35). Sorry for the trouble. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
koji save-failed-tree enabled
Greetings. We have enabled the koji 'save-failed-tree' plugin in koji.fedoraproject.org. This plugin allows you to tell koji to bundle up a failed official builds chroot (either partly or fully) and download it to investigate it locally. This plugin should only be used for the case where you cannot determine the cause of a build failure by any other means and need to examine specific files in the chroot to do so. A few things to note: * This will only work on failed official builds that have failed recently enough to still have their chroot on the builder where they failed (default: 1 day) Not scratch builds. Not canceled builds. The chroot downloads are REALLY LARGE. Please use this sparingly. * This will only work on buildArch tasks, not images, etc * Saved tree .tar.gz's are deleted from koji after 14 days. * You need to have python3-koji-cli-plugins subpackage installed to use the command. * You run the command as: koji save-failed-tree I hope that this will be of use to help maintainers track down hard to isolate bugs when all other means fail. kevin signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@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-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
koji save-failed-tree enabled
Greetings. We have enabled the koji 'save-failed-tree' plugin in koji.fedoraproject.org. This plugin allows you to tell koji to bundle up a failed official builds chroot (either partly or fully) and download it to investigate it locally. This plugin should only be used for the case where you cannot determine the cause of a build failure by any other means and need to examine specific files in the chroot to do so. A few things to note: * This will only work on failed official builds that have failed recently enough to still have their chroot on the builder where they failed (default: 1 day) Not scratch builds. Not canceled builds. The chroot downloads are REALLY LARGE. Please use this sparingly. * This will only work on buildArch tasks, not images, etc * Saved tree .tar.gz's are deleted from koji after 14 days. * You need to have python3-koji-cli-plugins subpackage installed to use the command. * You run the command as: koji save-failed-tree I hope that this will be of use to help maintainers track down hard to isolate bugs when all other means fail. kevin signature.asc Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Pytest 4 in Fedora, let's get rid of it please
On 11. 02. 21 17:36, Dan Radez wrote: On 2/2/21 12:09 PM, Miro Hrončok wrote: Hello Pythonistas. When we updated pytest to 5, I've introduced python-pytest4 compatibility package to ease the transition. We are now on pytest 6.2 and python-pytest4 still exists. However, pytest 4 has problems on Python 3.10 and I lack the enthusiasm to backport the fixes from 6.2 to 4. The most recent issue proved to be nontrivial: https://bugzilla.redhat.com/show_bug.cgi?id=1914847 The only Fedora package pulling in pytest4 is python-pytest-relaxed, which Requires pytest < 5. - python-invoke and python-paramiko BuildRequire python3-pytest-relaxed - python-jsonmodels and python-paramiko BuildRequire python3-invoke - many packages (Build)Require python3-paramiko Ideas: 1) Add support of recent pytest to python-pytest-relaxed [ideal] Issue: https://github.com/bitprophet/pytest-relaxed/issues/12 Volunteers? bitprophet seems to be willing to make this happen, Running the tests on py39 doesn't go well. Not against keeping it, but seems it may be easier to prune it out if it becomes unused and is so out of date. 2) Retire python-pytest4 and introduce python-pytest5 pytest-relaxed seem to work with pytest5 witch some patches that are available. However, this is not a long term solution, so I'd rather not spend my time on it. 3) Retire python-pytest4 and python-pytest-relaxed This requires disabling tests in invoke and slightly patching tests of paramiko. Once pytest-relaxed supports recent pytest, we can reintroduce it. This patch in paramiko would remove the pytest-relaxed dependency. Then we could remove both? https://github.com/paramiko/paramiko/pull/1665/ May be least path of resistance to patch out pytest-relaxed like this. Then we get all the paramiko tests to run and retire pytest4? Yes, but we would also need to disable tests of python-invoke entirely, because patching them out is not as simple as from paramiko. 4) Somebody else than me takes care of pytest4 and fixes it for Python 3.10 This requires long term involvement, not one time effort. Volunteers? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Ars claims: Fedora 32 is sluggish
Hi, On 2/5/21 3:03 AM, Roberto Ragusa wrote: On 2/4/21 9:52 PM, Alexander Ploumistos wrote: considerable lag. In the last 4 or so years I remember issues with tracker, gnome-shell, mutter/clutter and friends on specific GPUs, default or popular shell extensions and dbus services. A recent bug If tracker is enabled the performance drop after booting is huge. rpm -e tracker-miners I regularly have problems with runaway processes on fedora. Frequently the first indication of a problem are fans on a laptop running when the machine is idle. Just yesterday, clean install of F33, enabled Plasma, and korgac sat there for a few minutes at 100% until I killed it and told it never to start again. There isn't anything like a couple runaway processes to make the whole machine "sluggish". Fedora suffers from having a lot of things starting by default that are only used by a fraction of the user base. If it were smarter about starting/installing things provided by systemd/gnome/kde/etc I suspect that not only would it utilize less resources, but there security benefits of simply not having much of this running all the time would be clearer too. To pick on a couple. iscsi and avahi, are very important for a subset of the users, but frankly i suspect they are trivial fraction of the overall userbase. But they show up in security audits (lynis) simply because systemd-analyze itself reports them as insecure. Runaway processes are also a bit of an abrt failure in that there isn't a good automated way to report them. A package flag to the effect "this package doesn't contain anything which should consume 100% cpu for > 10 seconds" could be set on a wide range of these services to at least notify the upstream developers that there might be something wrong. Of course this would require yet another always on monitoring daemon. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Review swap: newsboat rust dependencies
On Thu, Feb 11, 2021 at 7:44 AM Jan Staněk wrote: > I maintain newsboat [1], which in the latest version(s) grew new rust > dependencies. I have prepared a review request for all of them, > and I'm willing to review other packages in return. > > The reviews are the following bugs: > 1927183, 1927210, 1927248, 1927353, > 1927362, 1927385, 1927763, 1927790 I took them all. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream
On Thu, 11 Feb 2021 at 18:04, Adam Williamson wrote: > On Thu, 2021-02-11 at 09:55 +0100, Clement Verna wrote: > > > > > > So, what do folks think? Does this seem like a good idea? Should I go > > > ahead with trying to get it deployed and onboard things to it? Any > > > comments, ideas, potential problems? Thanks! > > > > > > > > > I am pretty sure you did :-) but have you looked at adding the missing > > information to Bodhi ? Now that we have rawhide in Bodhi we should be > able > > to expose most the information needed. > > I didn't look at that in any technical detail but conceptually it seems > kinda wrong to me. The problem with using any existing system is that > all existing systems are *for* something. Bodhi is for dealing with > updates. There's no reason why Bodhi would track, for instance, whether > 34 is under a string freeze, right? Because Bodhi doesn't have anything > to do with translations. There are a zillion other 'states' that it > would be useful to have info on which aren't relevant to any *one* > existing system, and that's why to me it makes sense to have a separate > thing for that. > I was wondering about the 4 Needs bullet points in your original email which could be in Bodhi but yes if we want to add more and more info a seperate app makes sense :-) -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream
On Thu, Feb 11, 2021 at 09:04:12AM -0800, Adam Williamson wrote: > On Thu, 2021-02-11 at 09:55 +0100, Clement Verna wrote: > > > > > > So, what do folks think? Does this seem like a good idea? Should I go > > > ahead with trying to get it deployed and onboard things to it? Any > > > comments, ideas, potential problems? Thanks! > > > > > > > > > I am pretty sure you did :-) but have you looked at adding the missing > > information to Bodhi ? Now that we have rawhide in Bodhi we should be able > > to expose most the information needed. > > I didn't look at that in any technical detail but conceptually it seems > kinda wrong to me. The problem with using any existing system is that > all existing systems are *for* something. Bodhi is for dealing with > updates. There's no reason why Bodhi would track, for instance, whether > 34 is under a string freeze, right? Because Bodhi doesn't have anything > to do with translations. There are a zillion other 'states' that it > would be useful to have info on which aren't relevant to any *one* > existing system, and that's why to me it makes sense to have a separate > thing for that. The other problem that comes from this is: When we are 'go' for a new release, we start pushing '0-day' updates. Usually this is the day after the 'go' decision and a week or two ahead of the actual release. At that point bodhi thinks the release is "released", even though it is not. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Installing packages in fedora:rawhide containers is broken
On Thu, Feb 11, 2021 at 03:31:36PM +, Daniel P. Berrangé wrote: > I have the latest fedora:rawhide container image: > > $ podman image list | grep rawhide > registry.fedoraproject.org/fedora rawhide > cea65dfcb551 7 hours ago188 MB > > > Actually attempting to install any extra packages fails: Yeah, we are still resigning rawhide with the new key. So, most packages will be f35 signed, but some number are still f34 signed. I'm hoping the signing will finish today and tomorrows rawhide will be 100% f35 key signed. This is all my fault for not starting this signing sooner. ;( kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora rawhide compose report: 20210211.n.0 changes
On Thu, Feb 11, 2021 at 02:21:28PM +0100, Vít Ondruch wrote: > Just seeing that the Rawhide compose reports keep coming and there was also > successful F34 compose, I'd like to thank to everybody involved in branching > F34, because so far, this appears to me to be the smoothest branching ever > (I hope this is not premature and I have not tried to update my Rawhide yet > ;)). Ha. No, it didn't go completely smoothly... but better than last time at least. :) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927876] New: perl-Search-Elasticsearch-7.711 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1927876 Bug ID: 1927876 Summary: perl-Search-Elasticsearch-7.711 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Search-Elasticsearch Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 7.711 Current version/release in rawhide: 7.30-2.fc34 URL: http://search.cpan.org/dist/Search-Elasticsearch/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/10543/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)
On Thu, Feb 11, 2021 at 06:46:18AM -0800, Tom Stellard wrote: > On 2/11/21 2:27 AM, Vít Ondruch wrote: > > Tom, Kevin, > > > > What is the status here? It seems that Koji does not include make anymore. > > However, my local build does. So whatever change was done on Koji should be > > probably reflected also in fedora-comps. > > > > I submitted a pull request for this: > https://pagure.io/fedora-comps/pull-request/601 Merged. Should be in next compose(es). kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Graphics-TIFF] PR #2: Add FMF plan
ppisar opened a new pull-request against the project: `perl-Graphics-TIFF` that you are following: `` Add FMF plan `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Graphics-TIFF/pull-request/2 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Ars claims: Fedora 32 is sluggish
This was once discussed here in Ask Fedora https://ask.fedoraproject.org/t/how-to-increasing-performance-by-changing-cpu-governor-and-reducing-swappiness/10006 and there's an ongoing investigation regarding the same here https://pagure.io/fedora-workstation/issue/212. You would want to check both to stay posted about the updates regarding this 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream
On Thu, 2021-02-11 at 09:55 +0100, Clement Verna wrote: > > > > So, what do folks think? Does this seem like a good idea? Should I go > > ahead with trying to get it deployed and onboard things to it? Any > > comments, ideas, potential problems? Thanks! > > > > > I am pretty sure you did :-) but have you looked at adding the missing > information to Bodhi ? Now that we have rawhide in Bodhi we should be able > to expose most the information needed. I didn't look at that in any technical detail but conceptually it seems kinda wrong to me. The problem with using any existing system is that all existing systems are *for* something. Bodhi is for dealing with updates. There's no reason why Bodhi would track, for instance, whether 34 is under a string freeze, right? Because Bodhi doesn't have anything to do with translations. There are a zillion other 'states' that it would be useful to have info on which aren't relevant to any *one* existing system, and that's why to me it makes sense to have a separate thing for that. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-02-12 from 17:00:00 to 18:00:00 US/Eastern At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9854/ ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
Hi, On 1/1/21 8:59 PM, Chris Murphy wrote: On Fri, Jan 1, 2021 at 11:31 AM Artem Tim wrote: It's faster. Here is some benchmark with different zstd compression ratios https://lkml.org/lkml/2019/1/28/1930. Could be outdated a little bit though. But for HDD it makes sense to increase it probably. And IIRC Chris wrote about such plans. There are ideas but it's difficult because the kernel doesn't expose the information we really need to make an automatic determination. sysfs commonly misreports rotational devices as being non-rotational and vice versa. Since this is based on the device self-reporting, it's not great. I use zstd:1 for SSD/NVMe. And zstd:3 (which is the same as not specifying a level) for HDD/USB sticks/eMMC/SD Card. For the more archive style of backup, I use zstd:7. But these can all be mixed and matched, Btrfs doesn't care. You can even mix and match algorithms. Anyway, compress=zstd:1 is a good default. Everyone benefits, and I'm not even sure someone with a very fast NVMe drive will notice a slow down because the compression/decompression is threaded. I disagree that everyone benefits. Any read latency sensitive workload will be slower due to the application latency being both the drive latency plus the decompression latency. And as the kernel benchmarks indicate very few systems are going to get anywhere near the performance of even baseline NVMe drives when its comes to throughput. With PCIe Gen4 controllers the burst speeds are even higher (>3GB/sec read & write). Worse, if the workload is very parallel, and at max CPU already the compression overhead will only make that situation worse as well. (I suspect you could test this just by building some packages that have good parallelism during the build). So, your penalizing a large majority of machines built in the past couple years. Plus, the write amplification comment isn't even universal as there continue to be controllers where the flash translation layer is compressing the data. OTOH, it makes a lot more sense on a lot of these arm/sbc boards utilizing MMC because the disks are so slow. Maybe if something like this were made the default the machine should run a quick CPU compress/decompress vs IO speed test and only enable compression if the compress/decompress speed is at least the IO rate. I expect if we get the "fast" levels (the negative value levels) new to zstd in the kernel, that Btrfs will likely remap its level 1 to one of the negative levels, and keep level 3 set to zstd 3 (the default). So we might actually see it get even faster at the cost of some compression ratio. Given this possibility, I think level 1 is the best choice as a default for Fedora. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 --- Comment #10 from Itamar Reis Peixoto --- the correctly thing was just git merge master to keep it in sync with fedora spec. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 Fedora Update System changed: What|Removed |Added Status|ON_QA |MODIFIED --- Comment #9 from Fedora Update System --- FEDORA-EPEL-2021-806ecfba31 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-806ecfba31 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 --- Comment #8 from Devrim Gündüz --- @Petr: Updating it to 5.6.0 now. Revoked that action, will push 5.6.0 soon. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 Petr Pisar changed: What|Removed |Added Status|CLOSED |ON_QA Fixed In Version||bucardo-5.5.0-1.el8 Resolution|WONTFIX |--- Assignee|nob...@redhat.com |dev...@gunduz.org Keywords||Reopened --- Comment #7 from Petr Pisar --- I built it and Devrim submitted it into testing repository. The 5.5.0 version should appear on mirrors in a few days and in stable repository in 2 weeks. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 --- Comment #6 from Fedora Update System --- FEDORA-EPEL-2021-018e865ab5 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-018e865ab5 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Packages conflict in /usr/lib/.build-id/
Lumír Balhar wrote: > It seems to me that both apps are using the same engine which might lead > to this. > > Is there any way how to solve this problem from user perespective? Electron upstream needs to fix its distribution model. It just does not make sense to have every single application bundle a copy of Electron. That is also one of the issues preventing Electron from going into Fedora. Imagine every GTK application bundling their own GTK (and GTK is smaller than Electron!). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 --- Comment #5 from Itamar Reis Peixoto --- (In reply to Devrim Gündüz from comment #4) > > > he is not interested in contributing to Fedora, > > Really? not sure, look his last commit on fedora git. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Schedule for Thursday's FPC Meeting (2021-02-11 17:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2021-02-11 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2021-02-11 09:00 PST US/Pacific 2021-02-11 12:00 EST --> US/Eastern <-- 2021-02-11 17:00 GMT Europe/London 2021-02-11 17:00 UTC UTC 2021-02-11 18:00 CET Europe/Berlin 2021-02-11 18:00 CET Europe/Paris 2021-02-11 22:30 IST Asia/Calcutta New Day: Friday - 2021-02-12 01:00 HKT Asia/Hong_Kong 2021-02-12 01:00 +08 Asia/Singapore 2021-02-12 02:00 JST Asia/Tokyo 2021-02-12 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot #topic Open Floor * decathorpe look through non-meeting tickets, see if any are stuck/need to be discussed = Followup Issues = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 = Pull Requests = #topic #pr-1045 WIP: Add discussion of macro names beginning with underscores. https://pagure.io/packaging-committee/pull-request/1045 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 --- Comment #4 from Devrim Gündüz --- (In reply to Itamar Reis Peixoto from comment #3) > he is not interested in contributing to Fedora, Really? > he has his own repo at https://yum.postgresql.org/ This is the community repo I am responsible for. It is not a "personal" and "own" repo. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 --- Comment #3 from Itamar Reis Peixoto --- (In reply to Petr Pisar from comment #2) > Devrim Gündüz was the only one who tried to build bucardo for EPEL 8 in > August 2019. But the build failed (probably because of missing > dependencies). He might shed light on what was the problem. he is not interested in contributing to Fedora, he has his own repo at https://yum.postgresql.org/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 Petr Pisar changed: What|Removed |Added CC||dev...@gunduz.org, ||ppi...@redhat.com --- Comment #2 from Petr Pisar --- Devrim Gündüz was the only one who tried to build bucardo for EPEL 8 in August 2019. But the build failed (probably because of missing dependencies). He might shed light on what was the problem. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927813] not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 Itamar Reis Peixoto changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Assignee|ita...@ispbrasil.com.br |nob...@redhat.com Doc Type|--- |If docs needed, set a value Last Closed||2021-02-11 15:33:46 --- Comment #1 from Itamar Reis Peixoto --- Can't fix, fedora blocked my fas account. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Installing packages in fedora:rawhide containers is broken
I have the latest fedora:rawhide container image: $ podman image list | grep rawhide registry.fedoraproject.org/fedora rawhide cea65dfcb551 7 hours ago188 MB Actually attempting to install any extra packages fails: $ podman run -iv fedora:rawhide # dnf install vim Fedora 35 openh264 (From Cisco) - x86_64 13 kB/s | 70 kB 00:05 Errors during downloading metadata for repository 'fedora-cisco-openh264': - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-35=x86_64 (IP: 38.145.60.21) - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-35=x86_64 (IP: 38.145.60.20) Error: Failed to download metadata for repo 'fedora-cisco-openh264': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-35=x86_64 (IP: 38.145.60.20) Ignoring repositories: fedora-cisco-openh264 Last metadata expiration check: 0:01:08 ago on Thu Feb 11 15:21:34 2021. Dependencies resolved. == PackageArchitecture Version Repository Size == Installing: vim-enhanced x86_64 2:8.2.2488-1.fc34rawhide 1.8 M Installing dependencies: gpm-libs x86_64 1.20.7-25.fc34 rawhide 20 k vim-common x86_64 2:8.2.2488-1.fc34rawhide 6.7 M vim-filesystem noarch 2:8.2.2488-1.fc34rawhide 23 k which x86_64 2.21-21.fc34 rawhide 41 k Transaction Summary == Install 5 Packages Total download size: 8.5 M Installed size: 34 M Is this ok [y/N]: y Downloading Packages: (1/5): gpm-libs-1.20.7-25.fc34.x86_64.rpm 82 kB/s | 20 kB 00:00 (2/5): vim-filesystem-8.2.2488-1.fc34.noarch.rpm 135 kB/s | 23 kB 00:00 (3/5): which-2.21-21.fc34.x86_64.rpm 157 kB/s | 41 kB 00:00 (4/5): vim-enhanced-8.2.2488-1.fc34.x86_64.rpm 1.2 MB/s | 1.8 MB 00:01 (5/5): vim-common-8.2.2488-1.fc34.x86_64.rpm 1.7 MB/s | 6.7 MB 00:03 -- Total 1.9 MB/s | 8.5 MB 00:04 warning: /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/gpm-libs-1.20.7-25.fc34.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY Fedora - Rawhide - Developmental packages for the next Fedora release 1.6 MB/s | 1.6 kB 00:00 GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-35-x86_64 (0x9867C58F) is already installed The GPG keys listed for the "Fedora - Rawhide - Developmental packages for the next Fedora release" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository.. Failing package is: gpm-libs-1.20.7-25.fc34.x86_64 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-35-x86_64 Public key for vim-common-8.2.2488-1.fc34.x86_64.rpm is not installed. Failing package is: vim-common-2:8.2.2488-1.fc34.x86_64 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-35-x86_64 Public key for vim-enhanced-8.2.2488-1.fc34.x86_64.rpm is not installed. Failing package is: vim-enhanced-2:8.2.2488-1.fc34.x86_64 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-35-x86_64 Public key for vim-filesystem-8.2.2488-1.fc34.noarch.rpm is not installed. Failing package is: vim-filesystem-2:8.2.2488-1.fc34.noarch GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-35-x86_64 Public key for
[Bug 1927813] New: not a bug - bucardo missing in "stream" repos
https://bugzilla.redhat.com/show_bug.cgi?id=1927813 Bug ID: 1927813 Summary: not a bug - bucardo missing in "stream" repos Product: Fedora EPEL Version: epel8 Hardware: x86_64 OS: Linux Status: NEW Component: bucardo Severity: high Assignee: ita...@ispbrasil.com.br Reporter: pelj...@yahoo.co.uk QA Contact: extras...@fedoraproject.org CC: bazanlui...@gmail.com, ita...@ispbrasil.com.br, perl-devel@lists.fedoraproject.org, puiterw...@redhat.com Target Milestone: --- Classification: Fedora Description of problem: Hi. By omission or by intention Bucardo is not available in Centos Stream Epel repos. It would be great to have it back if possible. many thanks, L. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage
I'm wondering, though, whether we have to fix a FTBFS on F34 (!) just a few days after the mass rebuild. The glib change which caused all this was pushed after the mass rebuild, basically rendering mute the point of the mass rebuild. In my case (notmuch) I got the notice from koschei - funnily referring to the f34 package for the rawhide failure after rawhide "was" f35 already. I guess I'll go and scratch build some more ... (notmuch is fixed now, haha). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Thank you for your advice and willingness to help with testing. There is a plan to create a side tag and test appropriate changes there. Changed category to system-wide change. Ondrej On Thu, Feb 11, 2021 at 3:42 PM David Cantrell wrote: > On Wed, Feb 10, 2021 at 12:30:20PM -0700, Jeff Law wrote: > > > > > >On 2/10/21 11:00 AM, Miro Hrončok wrote: > >> On 10. 02. 21 18:47, Ben Cotton wrote: > >>> == Upgrade/compatibility impact == > >>> Problems during build can appear in multiple packages what can lead to > >>> build failure, as multiple packages require autoconf-2.69 as their > >>> upstream dependency. These problems have to be resolved before adding > >>> autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages > >>> are having problems during build, which could be caused by a problem > >>> with same pattern. > >> > >> In absolute numbers, what is 20%? I see ~200 failures at > >> https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/ > >> (obviously not all of them are necessarily caused by autoconf). > >> > >> Should this be a system-wide change instead? > >Given how many packages use autoconf, I think so. > > +1 > > autoconf changes are a big build impact and [most?] maintainers like > to avoid surprises here. > > >I've already volunteered my tester to help shake out this change. It's > >actually a really good fit because of the autoconf/LTO interactions we > >had to sort out for F33/LTO. The plan is to spin it up next week. > > > >In simplest terms autoconf generated code to test for the existence of > >certain capabilities can be optimized away completely by LTO. This > >results in autoconf incorrectly claiming certain capabilities exist. > >This can cause packages to FTBFS or to even mis-behave at runtime. > > > >Thus it was critical to find these cases and deal with them as part of > >the LTO effort. So my tester has the ability to capture generated > >config.h files across its control and test builds and will report a > >failure if the generated config.h files differ (with an ability to > >exclude those where timestamps and such end up in the generated config.h > >files). > > > >In the test I'm going to run the only difference between the control and > >test build will be the version of autoconf. So the failures should give > >us a highly accurate picture of how autoconf-2.70 will impact the > >distribution as a whole. > > This is a good idea. But really, I would like to see packages that > run autoconf during build to be checked. I do not think it is > sufficient to just check a subset of packages or even one particular > use case. I think to do this with minimal impact, we kind of need to > make sure everything using autoconf has incorporated the necessary > changes for autoconf-2.71. In many cases, things may be ready to go. > But I don't think we can assume that. > > The approach mhroncok@ and others have used for major Python changes I > think could be applied here. As an autoconf user [under duress, but > still, I have to rely on it], I would like the opportunity to have an > autoconf-2.71 side tag to verify my packages build there before we > update rawhide with 2.71. We could automate builds to test things out > and file bugs for package maintainers for failures. I know this is a > lot of work, but I think the proactive approach is better than > throwing it in to rawhide and fixing the fallout. > > I am volunteering to help perform these test builds and file bugs > and/or PRs for packages since what I am suggesting is a lot of work. > > Thanks, > > -- > David Cantrell > Red Hat, Inc. | Boston, MA | EST5EDT > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)
On 2/11/21 2:27 AM, Vít Ondruch wrote:
Tom, Kevin,
What is the status here? It seems that Koji does not include make anymore.
However, my local build does. So whatever change was done on Koji should be
probably reflected also in fedora-comps.
I submitted a pull request for this:
https://pagure.io/fedora-comps/pull-request/601
-Tom
BTW it would be nice if Koji used standard mock configs, especially I don't see
a reason why Koji should not use standard `config_opts['chroot_setup_cmd'] =
'install @{% if mirrored %}buildsys-{% endif %}build'`
Vít
Dne 04. 11. 20 v 19:12 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
== Summary ==
This change will remove make from the default buildroot in Koji and mock.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email:
== Detailed Description ==
= Phase 1: Analysis =
For this change, we will start by creating a list of all packages that
have a build-time dependency on make. This will be done by analyzing
spec files and also by rebuilding all packages in Fedora with make
removed from the buildroot to see which packages fail to build. Once
we have this list, we will remove packages that already have
BuildRequires:make in their spec file, and this final list[1] will be
all the packages that need to be updated in Phase 2.
[1]
https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_br_make.txt
= Phase 2: Package Updates =
Once we have the list of packages that need to be updated, we will
proceed with adding BuildRequires: make to all spec files that require
it. This new BuildRequires will be added to the line after the last
BuildRequires in the spec file. The release number for packages will
'''*not*''' be incremented for this change.
The spec file updates will be automated and changes will be pushed
directly to dist-git once they are ready.
= Phase 3: Update Buildroot =
Once package spec files have been updated, then we can proceed with
removing make from the BuildRoot. This will be done by removing make
from the build group in Koji and by removing make from the
buildsys-build group in comps (fedora-comps). In order to avoid
issues with Koschei, this change will need to be made as close as
possible to the start of the mass rebuild. If possible, we will try
to first remove make from the mass rebuild side-tag and then remove it
from rawhide after the rebuild completes.
= Phase 4: Monitor Failures =
Once all the changes are in place, we will continue to monitor koji
builds to see if there are any failures related to this change. We
expect that the analysis done in Phase 1 would give us the complete
list of packages that need to be updated, but it is always possible
that something will be missed.
== Feedback ==
* Removing make from the Buildroot without rebuilding the packages
first has the potential to cause mass failures in Koschei. This is
because Koschei builds from the latest SRPM and not from dist-git. We
can minimize this problem by removing make from the buildroot as close
as possible to the mass rebuild. The proposal has been updated now to
account for this issue.
== Benefit to Fedora ==
Based on my research[1], Fedora Rawhide has 22,309 packages, and there
are approximately 10,378 packages that either use make explicitly or
fail to build when make is removed form the buildroot. This means
that there are around 11,931 packages that don't need make. Removing
make from the BuildRoot will reduce the network traffic, download
times, and disk usage for these builds in Koji and also for users
doing builds with mock.
Removing make (and its dependencies) will:
* Reduce the BuildRoot download size by: 7.3 MB [2]:
** make: 539k
** gc: 104k
** guile22: 6.6M
** libtool-ltdl: 36k
* Reduce the BuildRoot install size by; 46 MB [2]:
** make: 1.6M
** gc: 229k
** guile22: 44M
** libtool-ltdl: 71k
[1] https://github.com/tstellar/fedora-change-make-buildroot
[2] Package sizes are from the x86_64 packages.
== Scope ==
* '''Proposal owners:''' Tom Stellard
* '''Package Maintainers:''' Fedora package maintainers should report
bugs if they think there is a problem caused by this change, but
otherwise there will be no action required by them.
* '''Proven Packager:''' The proposal owner will need to either apply
for provenpackager status or get the help of someone with
provenpackager status in order to make the spec file changes that are
required.
* '''Release engineering:''' [https://pagure.io/releng/issue/9829
#9829] (a check of an impact with Release Engineering is needed)
* '''Policies and guidelines:''' The packager guidelines will need to
be updated to mention that BuildRequires: make is now required for all
packages that need make.
* '''Trademark approval:''' N/A (not needed for this Change)
* '''Alignment with Objectives:''' This aligns with the Fedora
Minimization [https://pagure.io/minimization/issue/12 objective].
== Upgrade/compatibility
Review swap: newsboat rust dependencies
Hi all, I maintain newsboat [1], which in the latest version(s) grew new rust dependencies. I have prepared a review request for all of them, and I'm willing to review other packages in return. The reviews are the following bugs: 1927183, 1927210, 1927248, 1927353, 1927362, 1927385, 1927763, 1927790 All of them are generated with rust2rpm, so the review should be a quick one. Note however that they might depend on one another – I suggest using the TreeView+ in bugzilla to see their relations. As a rule of thumb, lower numbers generally needs to be reviewed/built before a higher one could begin. Thanks in advance to the brave soul(s) that are willing to pick this up :) [1]: https://newsboat.org -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Ars claims: Fedora 32 is sluggish
Am 11.02.21 um 15:28 schrieb Peter Robinson: > On Thu, Feb 11, 2021 at 1:03 PM Ondrej Mosnacek wrote: >> On Thu, Feb 11, 2021 at 10:14 AM Viktor Ashirov wrote: >>> On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro >>> wrote: > […] >>> This was bugging me for a while. I also noticed that Fedora 32 is a bit >>> slower than it used to be. Compilation time of a project that I'm working >>> on went from ~35-36 seconds to ~47-48. At first I thought that it's just >>> another round of CPU vulnerabilities mitigations that introduced a >>> performance drop. But after some digging I found that the default CPU >>> governor was switched from 'ondemand' to 'schedutil' in Fedora kernel 5.9.7: > […] > It was upstream changes, the Intel maintainer changed it in [1] if > X86_INTEL_PSTATE state was selected in late March which would make > sense in the timg, and also changed for arm arches [2] in July. > > If that change was made upstream I'm assuming it was assumed that > performance should be equivalent or better than the other option, I > suspect we should engage with upstream as they're probably interested > in the issues. FWIW, I wonder if some changes that were merged for mainline this week might be related: https://git.kernel.org/torvalds/c/291009f656e8eaebbdfd3a8d99f6b190a9ce9deb https://git.kernel.org/torvalds/c/d11a1d08a082a7dc0ada423d2b2e26e9b6f2525c https://git.kernel.org/torvalds/c/3c55e94c0adea4a5389c4b80f6ae9927dd6a4501 But I'm not entirely sure what CPUs are affected by d11a1d08a082 HTH, CU, thl ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wed, Feb 10, 2021 at 12:30:20PM -0700, Jeff Law wrote: On 2/10/21 11:00 AM, Miro Hrončok wrote: On 10. 02. 21 18:47, Ben Cotton wrote: == Upgrade/compatibility impact == Problems during build can appear in multiple packages what can lead to build failure, as multiple packages require autoconf-2.69 as their upstream dependency. These problems have to be resolved before adding autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages are having problems during build, which could be caused by a problem with same pattern. In absolute numbers, what is 20%? I see ~200 failures at https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/ (obviously not all of them are necessarily caused by autoconf). Should this be a system-wide change instead? Given how many packages use autoconf, I think so. +1 autoconf changes are a big build impact and [most?] maintainers like to avoid surprises here. I've already volunteered my tester to help shake out this change. It's actually a really good fit because of the autoconf/LTO interactions we had to sort out for F33/LTO. The plan is to spin it up next week. In simplest terms autoconf generated code to test for the existence of certain capabilities can be optimized away completely by LTO. This results in autoconf incorrectly claiming certain capabilities exist. This can cause packages to FTBFS or to even mis-behave at runtime. Thus it was critical to find these cases and deal with them as part of the LTO effort. So my tester has the ability to capture generated config.h files across its control and test builds and will report a failure if the generated config.h files differ (with an ability to exclude those where timestamps and such end up in the generated config.h files). In the test I'm going to run the only difference between the control and test build will be the version of autoconf. So the failures should give us a highly accurate picture of how autoconf-2.70 will impact the distribution as a whole. This is a good idea. But really, I would like to see packages that run autoconf during build to be checked. I do not think it is sufficient to just check a subset of packages or even one particular use case. I think to do this with minimal impact, we kind of need to make sure everything using autoconf has incorporated the necessary changes for autoconf-2.71. In many cases, things may be ready to go. But I don't think we can assume that. The approach mhroncok@ and others have used for major Python changes I think could be applied here. As an autoconf user [under duress, but still, I have to rely on it], I would like the opportunity to have an autoconf-2.71 side tag to verify my packages build there before we update rawhide with 2.71. We could automate builds to test things out and file bugs for package maintainers for failures. I know this is a lot of work, but I think the proactive approach is better than throwing it in to rawhide and fixing the fallout. I am volunteering to help perform these test builds and file bugs and/or PRs for packages since what I am suggesting is a lot of work. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Local/Copr Rawhide build failures due to GPG check [Was: Fedora 34 Mass Branching]
On Thursday, February 11, 2021 2:24:28 PM CET Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Feb 11, 2021 at 10:19:25AM +0100, Pavel Raiskup wrote: > > On Wednesday, February 10, 2021 2:49:00 PM CET Pavel Raiskup wrote: > > > On Wednesday, February 10, 2021 12:29:51 AM CET Kevin Fenzi wrote: > > > > On Tue, Feb 09, 2021 at 06:19:41PM -0500, Mohan Boddu wrote: > > > > > On Mon, Feb 8, 2021 at 7:18 PM Petr Menšík > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I were unable to find time in the schedule, at which the new F35 > > > > > > GPG key > > > > > > would be activated to sign new builds. > > > > > > > > > > It will be done a week before mass branching, but we are thinking of > > > > > doing it a bit earlier to give more time. > > > > > > > > I think we should make the f36 key right now and add it to fedora-repos > > > > and push it out to all branches. Then, when we get to f35 branching, we > > > > make the f37 key (ie, we stay 6 months ahead). > > > > > > > > This way everyone has the new key already and there's no scrambling. > > > > > > > > (or this week, doesn't have to be today, just soon) > > > > > > Yes please! Something along those lines was proposed before, because it > > > significantly eases mock maintenance during the branching period. E.g. > > > now, at the time of F34 branching we already have released > > > mock-core-configs (check updates-testing) with new F35 configuration and > > > everything should be working. > > > > > > Sure, temporarily, the fedora-34-x86_64 chroot builds against 34 repos > > > (still equivalent to rawhide), fedora-35-x86_64 config is symlink to > > > rawhide, and builds against rawhide (still f34). So the only thing users > > > will observe that 'fedora-rawhide-*' and 'fedora-35-*' are temporarily > > > producing RPMs with fc34 %dist tag and this will automatically change once > > > the mirrors are updated. > > > > > > It works now because the gpg keys have been generated a bit in advance for > > > a few last fedora releases (in copr team we try to notify administrators > > > to do that), but having it 6 months in advance will be better (less rush). > > > I think we should dump this to the branching policy/howto documents so we > > > don't have to manually track that. Finally, if we could document there > > > that updated distribution-gpg-keys and mock-core-configs packages should > > > be released, it would be an awesome help ... > > > > And we forgot to bump one configuration option in mock-core-configs, which > > eventually broke the fluent branching process in mock. The related mock > > failure > > looks like this: > > > > >> [SKIPPED] zlib-1.2.11-24.fc34.x86_64.rpm: Already downloaded > > >> warning: > > >> /var/lib/mock/fedora-rawhide-x86_64-bootstrap-1613034650.541875/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/fedora-gpg-keys-35-0.1.noarch.rpm: > > >> Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY > > >> fedora 1.6 MB/s | 1.6 kB > > >> 00:00 > > >> GPG key at > > >> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary > > >> (0x45719A39) is already installed > > >> fedora 1.6 MB/s | 1.6 kB > > >> 00:00 > > >> GPG key at > > >> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary > > >> (0x45719A39) is already installed > > > > > > I've just wrapped a new mock-core-configs release which has the fix, and > > updated > > the builds in bodhi updates. > > Hmm, I still see a failure: > warning: > /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/fedora-gpg-keys-35-0.1.noarch.rpm: > Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY > fedora > 1.6 MB/s | 1.6 kB 00:00 > GPG key at > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary > (0x45719A39) is already installed > fedora > 1.6 MB/s | 1.6 kB 00:00 > GPG key at > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary > (0x45719A39) is already installed > fedora > 1.6 MB/s | 1.6 kB 00:00 > GPG key at > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-33-primary > (0x9570FF31) is already installed > The GPG keys listed for the "fedora" repository are already installed but > they are not correct for this package. > Check that the correct key URLs are configured for this repository.. Failing > package is: fedora-gpg-keys-35-0.1.noarch > > $ rpm -q mock-core-configs > mock-core-configs-34-1.fc33.noarch Yeah, that's still the problem I meant - please install 34.1-1, not 34-1. Pavel
Re: Ars claims: Fedora 32 is sluggish
On Thu, Feb 11, 2021 at 1:03 PM Ondrej Mosnacek wrote: > > On Thu, Feb 11, 2021 at 10:14 AM Viktor Ashirov wrote: > > On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro > > wrote: > >> > >> Hi, > >> > >> Has anybody investigated Jim Salter's claims that Fedora 32 is slow to > >> launch applications? Recent article: > >> > >> https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/ > >> > >> "in my experience, Fedora 32 is noticeably, demonstrably more sluggish > >> to launch applications than Ubuntu is in general." > >> > >> Original article: > >> > >> https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workstation-32/ > >> > >> Would be good to know, for starters, whether this difference is real > >> and measurable. > > > > This was bugging me for a while. I also noticed that Fedora 32 is a bit > > slower than it used to be. Compilation time of a project that I'm working > > on went from ~35-36 seconds to ~47-48. At first I thought that it's just > > another round of CPU vulnerabilities mitigations that introduced a > > performance drop. But after some digging I found that the default CPU > > governor was switched from 'ondemand' to 'schedutil' in Fedora kernel 5.9.7: > > https://src.fedoraproject.org/rpms/kernel/c/73c86ebaee23df8310b903c1dab2176d443f5a3a?branch=rawhide > > (see configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL) > > > > I switched it back using cpupower from kernel-tools: > > $ sudo cpupower frequency-set --governor ondemand > > > > And confirmed that my compilation time went back to the previous ~35 > > seconds. > > In the end I switched the governor to 'performance' and shaved another 5 > > seconds. And gnome-shell no longer feels sluggish, switching tabs in the > > browser is also instant. > > To make the change permanent I used settings in /etc/sysconfig/cpupower and > > enabled cpupower service: > > $ sudo systemctl enable --now cpupower.service > > > > The change of the default CPU governor looks pretty significant to me, but > > I couldn't find any discussions about it. > > CCing the Fedora kernel list and Justin. At the ARK tree level, the > change was introduced in this commit, with no explanation: > https://gitlab.com/cki-project/kernel-ark/commit/9d69ad49ab90db607e25a99eacbf31dc9e513dfa > > Justin, do you remember the reason for the change? Can/should it be reverted? It was upstream changes, the Intel maintainer changed it in [1] if X86_INTEL_PSTATE state was selected in late March which would make sense in the timg, and also changed for arm arches [2] in July. If that change was made upstream I'm assuming it was assumed that performance should be equivalent or better than the other option, I suspect we should engage with upstream as they're probably interested in the issues. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a00ec3874e7d3 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f259eab3ea0e7 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora CoreOS Virtual Meetup this week
On Sun, 7 Feb 2021 at 13:46, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Feb 06, 2021 at 10:41:16AM +0100, Clement Verna wrote: > > Recordings are available on Fedora's youtube channel > > > > Growing Fedora CoreOS Community : > > https://www.youtube.com/watch?v=HSuBWeosAvQ > > Fedora CoreOS as an Official Edition : > > https://www.youtube.com/watch?v=t5VAw8NRXNc > > > > You can also find the discussions notes here : > > https://github.com/coreos/fedora-coreos-tracker/pull/732/files - > > Pull-request but that should be merged soon :) > > Hi Clement, > > thanks for making those available. > Thanks for taking the time to watch it and provide feedback :-) > > I listened avidly to the discussion, and here's my take on the subject > of "FCOS as Edition": > > in the discussion, you asked whether there should be "FCOS 33", "FCOS > 34", etc, and the answer was an emphatic "no". My answer is "yes". > What do I mean by that? I think it's fine to have a *goal* of just a > smooth FCOS stream, i.e. to make the underlying Fedora version > unimportant to users. But as a practical matter, it'll not be > achievable and FCOS should instead accept that as long as FCOS is > based on Fedora, the choices that Fedora "proper" makes and the > cadence of releases will be visible in FCOS. As mentioned in the > discussion "the package set is fairly vanilla bodhi stable with a bit > of delay for the two week promotion timing". Even if FCOS is just a > subset of those packages, the semiannual jump in package versions and > configuration choices must be visible to some extent. > I think a lot of the work and thoughts that went into designing the stream release process was to effectively hide or at least make the semi-annual jump in package versions a non event. The update barrier approach [0] that is currently in use is a good example. Currently a user might notice a Fedora version bump only because of an extra update and reboot. IMO having to worry or know which Fedora version is used as a base for FCOS is defeating the point of FCOS and automatic updates. > There seems to be a broad consensus that FCOS should participate more in > the Fedora Change process: both to monitor announced Changes and to > announce changes in FCOS using a similar process. > I believe that we are already doing a good job at monitoring the announced changes [1] but yeah we definitely can do better at announcing changes in FCOS. > > But I think FCOS should go a step further, and also *declare* that it > follows the Fedora schedule. I do *not* mean by that FCOS stable > stream should by switched on the same day that other Fedora editions > make a release. The two week delay is quite reasonable. (In fact, > seasoned users of Fedora "proper" know not to update immediately on > the release day, and instead wait two or three weeks for wrinkles to > be ironed out. Since FCOS does updates automatically, I think it's > totally reasonable to bake such a delay into the plan.) But we should > be able to say, in the release announcements, that "Workstation, > Server, etc. release today, and FCOS switch of stable stream will > follow in two weeks, if no last minute bugs are discovered. Users who > want to preview the next version, should use the devel stream." > So I personally don't agree with that, IMO there is nothing wrong with the stable stream not being on the latest version of Fedora as long as it is using a base version that is supported. I associate stable with words like slow, solid, robust,etc ... If we provide support for ~1 year why not make use of that ? FCOS values stability over new features. That said I think the goal is to make the switch as soon as possible and things like having a rawhide stream [2] will certainly help. In the case that we want to tightly couple FCOS stable stream to the latest Fedora version then we should be ready to delay the GA of other Editions until FCOS as a working stable stream. About release announcement, I believe that FCOS should follow it's own life and announce changes and major features as they happen. This is something we have to improve on (we already do some announcement [3]) and ideas like having a monthly newsletter are possibilities. I don't think that making FCOS an edition means that we have to mention it when other editions are released. > > Matthew said that users should be able to see all editions on > getfedora.org, and it would be great to also have FCOS there, but it > means that FCOS stable must be available on a predictable schedule. > It is already there in the "Emerging Fedora Editions" sections, the website is also automatically updated when new streams are released every 2 weeks. > > I think that tying FCOS to the the release schedule of other editions > will actually be more of a change in perception than any reality, > since FCOS already is following the bodhi update stream. FCOS has the > ability to delay some changes and to apply local overrides. But doing > that burns FCOS
[Bug 1926738] perl-Graphics-TIFF-8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1926738 --- Comment #11 from Fedora Update System --- FEDORA-2021-45a4f1130e has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-45a4f1130e -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1926738] perl-Graphics-TIFF-8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1926738 Fedora Update System changed: What|Removed |Added Status|ON_QA |MODIFIED --- Comment #10 from Fedora Update System --- FEDORA-2021-e9ac81a02d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e9ac81a02d -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: dropping php-imap (was Re: Orphaned packages looking for new maintainers)
Benson Muite wrote: > There are a number of php-imap implementations such as: > https://github.com/barbushin/php-imap > https://github.com/Webklex/php-imap These confusingly all use the same generic name "php-imap", but they are all different things. https://github.com/barbushin/php-imap appears to be a higher-level wrapper around the PHP IMAP extension, not a replacement: > Features > Connect to mailbox by POP3/IMAP/NNTP, using PHP IMAP extension […] > Requirements […] > PHP imap extension must be present; so make sure this line is active in > > your php.ini: extension=php_imap.dll https://github.com/Webklex/php-imap appears to be a partial replacement: > PHP-IMAP is a wrapper for common IMAP communication without the need to > have the php-imap module installed / enabled. though: > You can enable the php-imap module in order to handle edge cases, improve > message decoding quality and is required if you want to use legacy > protocols such as pop3. and the API is probably yet another one, otherwise it would not make sense to use this library together with the PHP IMAP extension. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927466] perl-Graphics-TIFF-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1927466 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Graphics-TIFF-9-1.fc35 --- Comment #1 from Petr Pisar --- An enhancement release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Graphics-TIFF] PR #1: fmf
ppisar closed without merging a pull-request against the project: `perl-Graphics-TIFF` that you are following. Closed pull-request: `` fmf `` https://src.fedoraproject.org/rpms/perl-Graphics-TIFF/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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Packages conflict in /usr/lib/.build-id/
One of the mentioned packages already has a fix upstream: https://github.com/microsoft/vscode/pull/116105 Thanks for help. Lumír On 2/11/21 10:32 AM, Miro Hrončok wrote: On 11. 02. 21 8:39, Lumír Balhar wrote: Hello. I'm facing a problem with a conflict between two packages from non-fedora repositories. I'm using vscodium and rememberthemilk apps for a long time but now I cannot update both because there is a conflict in /usr/lib/.build-id/. Error: Transaction test error: file /usr/lib/.build-id/14/512ca58e91f1940ba8e68d620c03e13cfb7d82 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/1c/1eccea7fe32b13593eb32f999fc3ce90432239 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/63/e57a96064e30d496ce9596cb5861ce64f52160 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/66/c77539c4ab0def65c2f355188fe71bff7b602d from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/74/589964965a9efc95d3e4202f7fc6a7226b6e78 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/76/90a7dcb40a4a052fdfb0f46a0dbeabbdf6df47 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/a7/97d3b4a5fac6864fda3d230e3ac9104d624990 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 It seems to me that both apps are using the same engine which might lead to this. Is it possible that both packages ship identical pre-compiled binaries (ELFs), e.g. by bundling the "same engine" you mention? The build-id files are links to the affected files, which should give you a hint. $ rpm -qlvp codium-1.53.1-1612917076.el7.x86_64.rpm | grep $ rpm -qlvp rememberthemilk-1.3.2-1.x86_64.rpm | grep Is there any way how to solve this problem from user perespective? You could unpack the RPM, delete the build-id files and repack it. That is, if you have no power over the build If you have even a slightest úpwer over the build process (even by filing tickets), suggest to disable the generation of build-ids (I don't recall how exactly). See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/436G5ITF4T7UMMWIDT6HIW6QUNLXD4AK/ See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GV2GKNX5RUYXNOTPHPH6AE3NNJDUXFP2/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20210211.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 11 of 43 required tests failed, 1 result missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 35/124 (aarch64), 42/183 (x86_64) New failures (same test not failed in Fedora-Rawhide-20210210.n.0): ID: 774516 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/774516 ID: 774517 Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/774517 ID: 774518 Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/774518 ID: 774519 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/774519 ID: 774523 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/774523 ID: 774555 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/774555 ID: 774570 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/774570 ID: 774692 Test: aarch64 universal install_blivet_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/774692 Old failures (same test failed in Fedora-Rawhide-20210210.n.0): ID: 774414 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/774414 ID: 774417 Test: x86_64 Server-dvd-iso server_role_deploy_database_server **GATING** URL: https://openqa.fedoraproject.org/tests/774417 ID: 774419 Test: x86_64 Server-dvd-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/774419 ID: 774422 Test: x86_64 Server-dvd-iso server_database_client **GATING** URL: https://openqa.fedoraproject.org/tests/774422 ID: 774425 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/774425 ID: 774430 Test: x86_64 Server-dvd-iso mediakit_fileconflicts URL: https://openqa.fedoraproject.org/tests/774430 ID: 774432 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/774432 ID: 774434 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/774434 ID: 774437 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/774437 ID: 774439 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/774439 ID: 774442 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING** URL: https://openqa.fedoraproject.org/tests/774442 ID: 774462 Test: x86_64 Workstation-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/774462 ID: 774463 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/774463 ID: 774467 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/774467 ID: 774468 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/774468 ID: 774473 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/774473 ID: 774474 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/774474 ID: 774478 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/774478 ID: 774479 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/774479 ID: 774480 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/774480 ID: 774484 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/774484 ID: 774488 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/774488 ID: 774489 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/774489 ID: 774491 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/774491 ID: 774502 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/774502 ID: 774511 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING** URL: https://openqa.fedoraproject.org/tests/774511 ID: 774515 Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/774515 ID: 774528 Test: aarch64 Server-dvd-iso server_role_deploy_database_server@uefi URL: https://openqa.fedoraproject.org/tests/774528 ID: 774530 Test: aarch64 Server-dvd-iso base_update_cli@uefi URL:
Re: Local/Copr Rawhide build failures due to GPG check [Was: Fedora 34 Mass Branching]
On Thu, Feb 11, 2021 at 10:19:25AM +0100, Pavel Raiskup wrote: > On Wednesday, February 10, 2021 2:49:00 PM CET Pavel Raiskup wrote: > > On Wednesday, February 10, 2021 12:29:51 AM CET Kevin Fenzi wrote: > > > On Tue, Feb 09, 2021 at 06:19:41PM -0500, Mohan Boddu wrote: > > > > On Mon, Feb 8, 2021 at 7:18 PM Petr Menšík wrote: > > > > > > > > > > Hi, > > > > > > > > > > I were unable to find time in the schedule, at which the new F35 GPG > > > > > key > > > > > would be activated to sign new builds. > > > > > > > > It will be done a week before mass branching, but we are thinking of > > > > doing it a bit earlier to give more time. > > > > > > I think we should make the f36 key right now and add it to fedora-repos > > > and push it out to all branches. Then, when we get to f35 branching, we > > > make the f37 key (ie, we stay 6 months ahead). > > > > > > This way everyone has the new key already and there's no scrambling. > > > > > > (or this week, doesn't have to be today, just soon) > > > > Yes please! Something along those lines was proposed before, because it > > significantly eases mock maintenance during the branching period. E.g. > > now, at the time of F34 branching we already have released > > mock-core-configs (check updates-testing) with new F35 configuration and > > everything should be working. > > > > Sure, temporarily, the fedora-34-x86_64 chroot builds against 34 repos > > (still equivalent to rawhide), fedora-35-x86_64 config is symlink to > > rawhide, and builds against rawhide (still f34). So the only thing users > > will observe that 'fedora-rawhide-*' and 'fedora-35-*' are temporarily > > producing RPMs with fc34 %dist tag and this will automatically change once > > the mirrors are updated. > > > > It works now because the gpg keys have been generated a bit in advance for > > a few last fedora releases (in copr team we try to notify administrators > > to do that), but having it 6 months in advance will be better (less rush). > > I think we should dump this to the branching policy/howto documents so we > > don't have to manually track that. Finally, if we could document there > > that updated distribution-gpg-keys and mock-core-configs packages should > > be released, it would be an awesome help ... > > And we forgot to bump one configuration option in mock-core-configs, which > eventually broke the fluent branching process in mock. The related mock > failure > looks like this: > > >> [SKIPPED] zlib-1.2.11-24.fc34.x86_64.rpm: Already downloaded > >> warning: > >> /var/lib/mock/fedora-rawhide-x86_64-bootstrap-1613034650.541875/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/fedora-gpg-keys-35-0.1.noarch.rpm: > >> Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY > >> fedora 1.6 MB/s | 1.6 kB > >> 00:00 > >> GPG key at > >> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary > >> (0x45719A39) is already installed > >> fedora 1.6 MB/s | 1.6 kB > >> 00:00 > >> GPG key at > >> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary > >> (0x45719A39) is already installed > > > I've just wrapped a new mock-core-configs release which has the fix, and > updated > the builds in bodhi updates. Hmm, I still see a failure: warning: /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/fedora-gpg-keys-35-0.1.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY fedora 1.6 MB/s | 1.6 kB 00:00 GPG key at file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary (0x45719A39) is already installed fedora 1.6 MB/s | 1.6 kB 00:00 GPG key at file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary (0x45719A39) is already installed fedora 1.6 MB/s | 1.6 kB 00:00 GPG key at file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-33-primary (0x9570FF31) is already installed The GPG keys listed for the "fedora" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository.. Failing package is: fedora-gpg-keys-35-0.1.noarch $ rpm -q mock-core-configs mock-core-configs-34-1.fc33.noarch 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:
Re: Fedora rawhide compose report: 20210211.n.0 changes
Just seeing that the Rawhide compose reports keep coming and there was also successful F34 compose, I'd like to thank to everybody involved in branching F34, because so far, this appears to me to be the smoothest branching ever (I hope this is not premature and I have not tried to update my Rawhide yet ;)). Vít OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Graphics-TIFF] PR #1: fmf
ppisar opened a new pull-request against the project: `perl-Graphics-TIFF` that you are following: `` fmf `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Graphics-TIFF/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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Ars claims: Fedora 32 is sluggish
On Thu, Feb 11, 2021 at 10:14 AM Viktor Ashirov wrote: > On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro wrote: >> >> Hi, >> >> Has anybody investigated Jim Salter's claims that Fedora 32 is slow to >> launch applications? Recent article: >> >> https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/ >> >> "in my experience, Fedora 32 is noticeably, demonstrably more sluggish >> to launch applications than Ubuntu is in general." >> >> Original article: >> >> https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workstation-32/ >> >> Would be good to know, for starters, whether this difference is real >> and measurable. > > This was bugging me for a while. I also noticed that Fedora 32 is a bit > slower than it used to be. Compilation time of a project that I'm working on > went from ~35-36 seconds to ~47-48. At first I thought that it's just another > round of CPU vulnerabilities mitigations that introduced a performance drop. > But after some digging I found that the default CPU governor was switched > from 'ondemand' to 'schedutil' in Fedora kernel 5.9.7: > https://src.fedoraproject.org/rpms/kernel/c/73c86ebaee23df8310b903c1dab2176d443f5a3a?branch=rawhide > (see configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL) > > I switched it back using cpupower from kernel-tools: > $ sudo cpupower frequency-set --governor ondemand > > And confirmed that my compilation time went back to the previous ~35 seconds. > In the end I switched the governor to 'performance' and shaved another 5 > seconds. And gnome-shell no longer feels sluggish, switching tabs in the > browser is also instant. > To make the change permanent I used settings in /etc/sysconfig/cpupower and > enabled cpupower service: > $ sudo systemctl enable --now cpupower.service > > The change of the default CPU governor looks pretty significant to me, but I > couldn't find any discussions about it. CCing the Fedora kernel list and Justin. At the ARK tree level, the change was introduced in this commit, with no explanation: https://gitlab.com/cki-project/kernel-ark/commit/9d69ad49ab90db607e25a99eacbf31dc9e513dfa Justin, do you remember the reason for the change? Can/should it be reverted? -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Stale provenpackagers to be removed from group
On 11. 02. 21 13:29, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Feb 11, 2021 at 09:22:54PM +0900, Mamoru TASAKA wrote: Ben Cotton wrote on 2021/02/11 0:44: In accordance with the new FESCo policy[1] the following provenpackagers will be submitted for removal in two weeks based on a lack of builds submitted in the last six months. If you received this directly, you can reply off-list to indicate you believe you should still have provenpackager status. This is the first time we have done a regular audit of the provenpackagers group, so please be patient with any hiccups in the process. This will be done regularly at the branch point in each release. [1] https://pagure.io/fesco/issue/2549 Checked 252 provenpackagers The following 117 provenpackagers have not submitted a Koji build since at least 2020-08-05 00:00:00: A question from me as a worrier: How will become the status of provenpackagers whose sponsor (as provenpackager role) is one of the persons listed here to be removed? Just the sponsor of such person will be changed to NONE? I hope it will not change. Though this matters mostly for historical reasons: I think the old idea of sponsors being forever responsible for their sponsorees is very far from current practice. Once the sponsorship happens, the sponsor doesn't matter much anymore. For "packagers" people have individual sponsors. However for "provenpackagers" the sponsor is basically a person who processed the ticket, i.e.: 1 bpepple 2 churchyard 53 jstanley 1 jwboyer 90 kevin 32 notting 1 toshio 72 NONE I don't think "whoever sponsored a provenpackager into the provenpackager group" bears any useful information. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [F34] wait-repo task has been opened for approx 2 hours
On 11. 02. 21 13:33, Zdenek Dohnal wrote: Thanks, Miro! foomatic-db build is now in testing and I was able to create a override for it, but when I built foomatic, it got into bodhi automatically and now I cannot add foomatic build to foomatic-db update to prevent foomatic landing into stable than foomatic-db. I cannot even unpush the foomatic update - do you have any tips how to proceed? Let it happen, both updates will be pushed to stable once the freeze is over. Ad side-tags: IMO the process should work for buildroot overrides too. Side tags look good for big rebuilds, where not all packages belong to one maintainer, but it looks like an overhead for only two packages. If you want multiple (even two) packages to be shipped via a single update in rawhide or branched (prior to updates testing activation), side tag is the only way. For branched (prior to updates testing activation) buildroot overrides are possible, but the updates will be separated in bodhi. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [F34] wait-repo task has been opened for approx 2 hours
Thanks, Miro! foomatic-db build is now in testing and I was able to create a override for it, but when I built foomatic, it got into bodhi automatically and now I cannot add foomatic build to foomatic-db update to prevent foomatic landing into stable than foomatic-db. I cannot even unpush the foomatic update - do you have any tips how to proceed? Ad side-tags: IMO the process should work for buildroot overrides too. Side tags look good for big rebuilds, where not all packages belong to one maintainer, but it looks like an overhead for only two packages. On 2/10/21 4:24 PM, Miro Hrončok wrote: > On 10. 02. 21 9:09, Zdenek Dohnal wrote: >> Hi all, >> >> I have started foomatic-db+foomatic chainbuild this morning for F34 and >> it has been opened for 2 hours till now. Is it expected? >> >> IIUC I don't need a buildroot override yet, since F34 hasn't been >> enabled in bodhi. So the process should be the same as in rawhide. >> >> Does anyone know what's going on? > > The first build is left in pending until the freeze is over: > > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#post-branch-freeze > > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-2e2e2883c5 > > You need a buildroot override, but the bodhi CLI will tell you: > > "Invalid build. It must be tagged as either candidate or testing." > > But the web UI allows it :/ > > Tip: You could have avoided the problem entirely by using side tags: > > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Stale provenpackagers to be removed from group
On Thu, Feb 11, 2021 at 09:22:54PM +0900, Mamoru TASAKA wrote: > Ben Cotton wrote on 2021/02/11 0:44: > >In accordance with the new FESCo policy[1] the following > >provenpackagers will be submitted for removal in two weeks based on a > >lack of builds submitted in the last six months. If you received this > >directly, you can reply off-list to indicate you believe you should > >still have provenpackager status. > > > >This is the first time we have done a regular audit of the > >provenpackagers group, so please be patient with any hiccups in the > >process. This will be done regularly at the branch point in each > >release. > > > >[1] https://pagure.io/fesco/issue/2549 > > > >Checked 252 provenpackagers > >The following 117 provenpackagers have not submitted a Koji build > >since at least 2020-08-05 00:00:00: > > A question from me as a worrier: > > How will become the status of provenpackagers whose sponsor (as > provenpackager role) is one of the persons listed here to be removed? > Just the sponsor of such person will be changed to NONE? I hope it will not change. Though this matters mostly for historical reasons: I think the old idea of sponsors being forever responsible for their sponsorees is very far from current practice. Once the sponsorship happens, the sponsor doesn't matter much anymore. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Stale provenpackagers to be removed from group
Ben Cotton wrote on 2021/02/11 0:44: In accordance with the new FESCo policy[1] the following provenpackagers will be submitted for removal in two weeks based on a lack of builds submitted in the last six months. If you received this directly, you can reply off-list to indicate you believe you should still have provenpackager status. This is the first time we have done a regular audit of the provenpackagers group, so please be patient with any hiccups in the process. This will be done regularly at the branch point in each release. [1] https://pagure.io/fesco/issue/2549 Checked 252 provenpackagers The following 117 provenpackagers have not submitted a Koji build since at least 2020-08-05 00:00:00: A question from me as a worrier: How will become the status of provenpackagers whose sponsor (as provenpackager role) is one of the persons listed here to be removed? Just the sponsor of such person will be changed to NONE? Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210211.n.0 changes
OLD: Fedora-Rawhide-20210210.n.0 NEW: Fedora-Rawhide-20210211.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 8 Dropped packages:0 Upgraded packages: 62 Downgraded packages: 0 Size of added packages: 185.15 MiB Size of dropped packages:0 B Size of upgraded packages: 1.57 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -72.38 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: ghc-pretty-terminal-0.1.0.0-2.fc35 Summary: Styling and coloring terminal output with ANSI escape sequences RPMs:ghc-pretty-terminal ghc-pretty-terminal-devel ghc-pretty-terminal-doc ghc-pretty-terminal-prof Size:882.47 KiB Package: pgaudit-1.4.0-3.module_f35+11266+bc07fe3e Summary: PostgreSQL Audit Extension RPMs:pgaudit Size:281.87 KiB Package: postgres-decoderbufs-1.4.0-1.Final.module_f35+11266+bc07fe3e Summary: PostgreSQL Protocol Buffers logical decoder plugin RPMs:postgres-decoderbufs postgres-decoderbufs-llvmjit Size:306.75 KiB Package: postgresql-12.5-1.module_f35+11266+bc07fe3e Summary: PostgreSQL client programs RPMs:postgresql postgresql-contrib postgresql-docs postgresql-llvmjit postgresql-plperl postgresql-plpython postgresql-plpython3 postgresql-pltcl postgresql-server postgresql-server-devel postgresql-static postgresql-test postgresql-test-rpm-macros postgresql-upgrade postgresql-upgrade-devel Size:174.78 MiB Package: python-aexpect-1.5.1-6.module_f35+11283+bceb36c7 Summary: A python library to control interactive applications RPMs:python3-aexpect Size:51.33 KiB Package: python-avocado-85.0-1.module_f35+11283+bceb36c7 Summary: Framework with tools and libraries for Automated Testing RPMs:python-avocado-bash python-avocado-common python-avocado-examples python3-avocado python3-avocado-plugins-golang python3-avocado-plugins-output-html python3-avocado-plugins-result-upload python3-avocado-plugins-resultsdb python3-avocado-plugins-varianter-cit python3-avocado-plugins-varianter-pict python3-avocado-plugins-varianter-yaml-to-mux Size:867.21 KiB Package: python-imageio-2.9.0-1.fc35 Summary: Python IO of image, video, scientific, and volumetric data formats. RPMs:python3-imageio Size:3.21 MiB Package: python-pynn-0.9.6-1.fc35 Summary: A package for simulator-independent specification of neuronal network models RPMs:python-pynn-devel python-pynn-doc python3-pynn Size:4.83 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: CImg-1:2.9.6-1.fc35 Old package: CImg-1:2.9.4-2.fc34 Summary: C++ Template Image Processing Toolkit RPMs: CImg-devel Size: 11.13 MiB Size change: 37.43 KiB Changelog: * Wed Feb 10 2021 josef radinger - 1:2.9.6-1 - bump version Package: agenda-1.1.0-6.fc35 Old package: agenda-1.1.0-6.fc34 Summary: Simple, fast, no-nonsense to-do (task) list RPMs: agenda Size: 385.54 KiB Size change: 22 B Package: appstream-0.14.0-1.fc35 Old package: appstream-0.13.1-2.fc34 Summary: Utilities to generate, maintain and access the AppStream database RPMs: appstream appstream-devel appstream-qt appstream-qt-devel Size: 12.61 MiB Size change: 286.31 KiB Changelog: * Thu Feb 04 2021 Rex Dieter - 0.14.0-1 - 0.14.0 Package: borgbackup-1.1.15-3.fc35 Old package: borgbackup-1.1.15-2.fc34 Summary: A deduplicating backup program with compression and authenticated encryption RPMs: borgbackup Size: 5.05 MiB Size change: -1.53 KiB Changelog: * Wed Feb 10 2021 Felix Schwarz - 1.1.15-3 - fix building with Python 3.10 (#1927146) Package: compsize-1.5-1.fc35 Old package: compsize-1.4-2.fc34 Summary: Utility for measuring compression ratio of files on btrfs RPMs: compsize Size: 94.83 KiB Size change: -239 B Changelog: * Wed Feb 10 2021 Juan Orti Alcaine - 1.5-1 - Version 1.5 (#1918100) Package: fedora-obsolete-packages-35-1 Old package: fedora-obsolete-packages-34-13 Summary: A package to obsolete retired packages RPMs: fedora-obsolete-packages Size: 19.12 KiB Size change: -15.22 KiB Changelog: * Wed Feb 10 2021 Miro Hron??ok - 35-1 - Clean for Fedora 35 Package: gap-pkg-ferret-1.0.5-1.fc35 Old package: gap-pkg-ferret-1.0.4-1.fc35 Summary: Backtracking search in permutation groups RPMs: gap-pkg-ferret gap-pkg-ferret-doc Size: 1.94 MiB Size change: 2.70 KiB Changelog: * Wed Feb 10 2021 Jerry James - 1.0.5-1 - Version 1.0.5 Package: generic-release-35-0.1 Old package: generic-release-34-0.1 Summary: Generic release files RPMs: generic-release generic-release-common generic-release-notes Size: 28.81 KiB Size change: -973 B Changelog: * Wed Feb 10 2021 Tom Callaway - 35-0.1 - bump to 35 for rawhide Package
Re: need help to get started with contributing
Thank you so much @Ankur Sinha I have already gone through the "Information for Gsoc 2021 " . I have joined the IRC , MAILING LIST and the DISCORD channel Thanks , Unnikrishnan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)
Tom, Kevin,
What is the status here? It seems that Koji does not include make
anymore. However, my local build does. So whatever change was done on
Koji should be probably reflected also in fedora-comps.
BTW it would be nice if Koji used standard mock configs, especially I
don't see a reason why Koji should not use standard
`config_opts['chroot_setup_cmd'] = 'install @{% if mirrored
%}buildsys-{% endif %}build'`
Vít
Dne 04. 11. 20 v 19:12 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
== Summary ==
This change will remove make from the default buildroot in Koji and mock.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email:
== Detailed Description ==
= Phase 1: Analysis =
For this change, we will start by creating a list of all packages that
have a build-time dependency on make. This will be done by analyzing
spec files and also by rebuilding all packages in Fedora with make
removed from the buildroot to see which packages fail to build. Once
we have this list, we will remove packages that already have
BuildRequires:make in their spec file, and this final list[1] will be
all the packages that need to be updated in Phase 2.
[1]
https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_br_make.txt
= Phase 2: Package Updates =
Once we have the list of packages that need to be updated, we will
proceed with adding BuildRequires: make to all spec files that require
it. This new BuildRequires will be added to the line after the last
BuildRequires in the spec file. The release number for packages will
'''*not*''' be incremented for this change.
The spec file updates will be automated and changes will be pushed
directly to dist-git once they are ready.
= Phase 3: Update Buildroot =
Once package spec files have been updated, then we can proceed with
removing make from the BuildRoot. This will be done by removing make
from the build group in Koji and by removing make from the
buildsys-build group in comps (fedora-comps). In order to avoid
issues with Koschei, this change will need to be made as close as
possible to the start of the mass rebuild. If possible, we will try
to first remove make from the mass rebuild side-tag and then remove it
from rawhide after the rebuild completes.
= Phase 4: Monitor Failures =
Once all the changes are in place, we will continue to monitor koji
builds to see if there are any failures related to this change. We
expect that the analysis done in Phase 1 would give us the complete
list of packages that need to be updated, but it is always possible
that something will be missed.
== Feedback ==
* Removing make from the Buildroot without rebuilding the packages
first has the potential to cause mass failures in Koschei. This is
because Koschei builds from the latest SRPM and not from dist-git. We
can minimize this problem by removing make from the buildroot as close
as possible to the mass rebuild. The proposal has been updated now to
account for this issue.
== Benefit to Fedora ==
Based on my research[1], Fedora Rawhide has 22,309 packages, and there
are approximately 10,378 packages that either use make explicitly or
fail to build when make is removed form the buildroot. This means
that there are around 11,931 packages that don't need make. Removing
make from the BuildRoot will reduce the network traffic, download
times, and disk usage for these builds in Koji and also for users
doing builds with mock.
Removing make (and its dependencies) will:
* Reduce the BuildRoot download size by: 7.3 MB [2]:
** make: 539k
** gc: 104k
** guile22: 6.6M
** libtool-ltdl: 36k
* Reduce the BuildRoot install size by; 46 MB [2]:
** make: 1.6M
** gc: 229k
** guile22: 44M
** libtool-ltdl: 71k
[1] https://github.com/tstellar/fedora-change-make-buildroot
[2] Package sizes are from the x86_64 packages.
== Scope ==
* '''Proposal owners:''' Tom Stellard
* '''Package Maintainers:''' Fedora package maintainers should report
bugs if they think there is a problem caused by this change, but
otherwise there will be no action required by them.
* '''Proven Packager:''' The proposal owner will need to either apply
for provenpackager status or get the help of someone with
provenpackager status in order to make the spec file changes that are
required.
* '''Release engineering:''' [https://pagure.io/releng/issue/9829
#9829] (a check of an impact with Release Engineering is needed)
* '''Policies and guidelines:''' The packager guidelines will need to
be updated to mention that BuildRequires: make is now required for all
packages that need make.
* '''Trademark approval:''' N/A (not needed for this Change)
* '''Alignment with Objectives:''' This aligns with the Fedora
Minimization [https://pagure.io/minimization/issue/12 objective].
== Upgrade/compatibility impact ==
This should not impact upgrades.
== How To Test ==
This change can be tested by rebuilding affected packages. The goal
is
Re: need help to get started with contributing
On Thu, Feb 11, 2021 09:56:04 -, Unnikrishnan V wrote: > Hey , I am new to open source , can someone help me to get started > with how to start contributing . I want to participating in GSOC 2021 > with fedora. I am a bit confused and don't know to look out things Hi! Welcome to the community! The Fedora Join SIG can help you get started. Can you please get in touch with them on any of their channels? https://docs.fedoraproject.org/en-US/project/join/#_not_sure_where_to_start_come_hang_out_with_us Next, Information on GSoC 2021 can be found here: https://docs.fedoraproject.org/en-US/mentored-projects/gsoc/2021/ -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927466] perl-Graphics-TIFF-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1927466 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1927663] New: Upgrade perl-POE-Component-Client-Ping to 1.177
https://bugzilla.redhat.com/show_bug.cgi?id=1927663 Bug ID: 1927663 Summary: Upgrade perl-POE-Component-Client-Ping to 1.177 Product: Fedora Version: rawhide Status: NEW Component: perl-POE-Component-Client-Ping Assignee: maria...@tuxette.fr Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: maria...@tuxette.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 1.176 version. Upstream released 1.177. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
need help to get started with contributing
Hey , I am new to open source , can someone help me to get started with how to start contributing . I want to participating in GSOC 2021 with fedora. I am a bit confused and don't know to look out things ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Packages conflict in /usr/lib/.build-id/
On 11. 02. 21 8:39, Lumír Balhar wrote: Hello. I'm facing a problem with a conflict between two packages from non-fedora repositories. I'm using vscodium and rememberthemilk apps for a long time but now I cannot update both because there is a conflict in /usr/lib/.build-id/. Error: Transaction test error: file /usr/lib/.build-id/14/512ca58e91f1940ba8e68d620c03e13cfb7d82 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/1c/1eccea7fe32b13593eb32f999fc3ce90432239 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/63/e57a96064e30d496ce9596cb5861ce64f52160 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/66/c77539c4ab0def65c2f355188fe71bff7b602d from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/74/589964965a9efc95d3e4202f7fc6a7226b6e78 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/76/90a7dcb40a4a052fdfb0f46a0dbeabbdf6df47 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 file /usr/lib/.build-id/a7/97d3b4a5fac6864fda3d230e3ac9104d624990 from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file from package rememberthemilk-1.3.2-1.x86_64 It seems to me that both apps are using the same engine which might lead to this. Is it possible that both packages ship identical pre-compiled binaries (ELFs), e.g. by bundling the "same engine" you mention? The build-id files are links to the affected files, which should give you a hint. $ rpm -qlvp codium-1.53.1-1612917076.el7.x86_64.rpm | grep $ rpm -qlvp rememberthemilk-1.3.2-1.x86_64.rpm | grep Is there any way how to solve this problem from user perespective? You could unpack the RPM, delete the build-id files and repack it. That is, if you have no power over the build If you have even a slightest úpwer over the build process (even by filing tickets), suggest to disable the generation of build-ids (I don't recall how exactly). See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/436G5ITF4T7UMMWIDT6HIW6QUNLXD4AK/ See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GV2GKNX5RUYXNOTPHPH6AE3NNJDUXFP2/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-32-20210211.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20210210.0): ID: 774398 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/774398 ID: 774405 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/774405 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Local/Copr Rawhide build failures due to GPG check [Was: Fedora 34 Mass Branching]
On Wednesday, February 10, 2021 2:49:00 PM CET Pavel Raiskup wrote: > On Wednesday, February 10, 2021 12:29:51 AM CET Kevin Fenzi wrote: > > On Tue, Feb 09, 2021 at 06:19:41PM -0500, Mohan Boddu wrote: > > > On Mon, Feb 8, 2021 at 7:18 PM Petr Menšík wrote: > > > > > > > > Hi, > > > > > > > > I were unable to find time in the schedule, at which the new F35 GPG key > > > > would be activated to sign new builds. > > > > > > It will be done a week before mass branching, but we are thinking of > > > doing it a bit earlier to give more time. > > > > I think we should make the f36 key right now and add it to fedora-repos > > and push it out to all branches. Then, when we get to f35 branching, we > > make the f37 key (ie, we stay 6 months ahead). > > > > This way everyone has the new key already and there's no scrambling. > > > > (or this week, doesn't have to be today, just soon) > > Yes please! Something along those lines was proposed before, because it > significantly eases mock maintenance during the branching period. E.g. > now, at the time of F34 branching we already have released > mock-core-configs (check updates-testing) with new F35 configuration and > everything should be working. > > Sure, temporarily, the fedora-34-x86_64 chroot builds against 34 repos > (still equivalent to rawhide), fedora-35-x86_64 config is symlink to > rawhide, and builds against rawhide (still f34). So the only thing users > will observe that 'fedora-rawhide-*' and 'fedora-35-*' are temporarily > producing RPMs with fc34 %dist tag and this will automatically change once > the mirrors are updated. > > It works now because the gpg keys have been generated a bit in advance for > a few last fedora releases (in copr team we try to notify administrators > to do that), but having it 6 months in advance will be better (less rush). > I think we should dump this to the branching policy/howto documents so we > don't have to manually track that. Finally, if we could document there > that updated distribution-gpg-keys and mock-core-configs packages should > be released, it would be an awesome help ... And we forgot to bump one configuration option in mock-core-configs, which eventually broke the fluent branching process in mock. The related mock failure looks like this: >> [SKIPPED] zlib-1.2.11-24.fc34.x86_64.rpm: Already downloaded >> warning: >> /var/lib/mock/fedora-rawhide-x86_64-bootstrap-1613034650.541875/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/fedora-gpg-keys-35-0.1.noarch.rpm: >> Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY >> fedora 1.6 MB/s | 1.6 kB 00:00 >> GPG key at >> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary >> (0x45719A39) is already installed >> fedora 1.6 MB/s | 1.6 kB 00:00 >> GPG key at >> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary >> (0x45719A39) is already installed I've just wrapped a new mock-core-configs release which has the fix, and updated the builds in bodhi updates. Sorry for inconvenience, I'm going to mention this in mock documentation so it shouldn't happen next time. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Ars claims: Fedora 32 is sluggish
On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro wrote: > Hi, > > Has anybody investigated Jim Salter's claims that Fedora 32 is slow to > launch applications? Recent article: > > > https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/ > > "in my experience, Fedora 32 is noticeably, demonstrably more sluggish > to launch applications than Ubuntu is in general." > > Original article: > > > https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workstation-32/ > > Would be good to know, for starters, whether this difference is real > and measurable. > This was bugging me for a while. I also noticed that Fedora 32 is a bit slower than it used to be. Compilation time of a project that I'm working on went from ~35-36 seconds to ~47-48. At first I thought that it's just another round of CPU vulnerabilities mitigations that introduced a performance drop. But after some digging I found that the default CPU governor was switched from 'ondemand' to 'schedutil' in Fedora kernel 5.9.7: https://src.fedoraproject.org/rpms/kernel/c/73c86ebaee23df8310b903c1dab2176d443f5a3a?branch=rawhide (see configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL) I switched it back using cpupower from kernel-tools: $ sudo cpupower frequency-set --governor ondemand And confirmed that my compilation time went back to the previous ~35 seconds. In the end I switched the governor to 'performance' and shaved another 5 seconds. And gnome-shell no longer feels sluggish, switching tabs in the browser is also instant. To make the change permanent I used settings in /etc/sysconfig/cpupower and enabled cpupower service: $ sudo systemctl enable --now cpupower.service The change of the default CPU governor looks pretty significant to me, but I couldn't find any discussions about it. > Michael > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Viktor ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream
On Wed, 13 Jan 2021 at 18:53, Adam Williamson
wrote:
> Hi folks!
>
> Before the RH holiday shutdown, I started a new project designed to
> address a long-standing pain point in Fedora: we don't really have a
> good source of truth for release cycle information. I'm thinking of
> situations where something:
>
> * Needs to know what the "current stable" Fedora release(s) are
> * Needs to know if Fedora X is Branched
> * Needs to know whether Fedora X Beta happened yet
> * Needs to know whether Fedora X is frozen
>
> ...etc etc etc. Some of this information is available...sort of...from
> various different systems, with various awkward caveats that I won't
> dive into unless someone asks. But there isn't really a single source
> of truth for it, and some of it just isn't really available in any
> easily machine-consumable way.
>
> So I wrote releasestream:
> https://pagure.io/fedora-qa/releasestream
>
> releasestream is intended to be a system that will let us do this. It
> is a very very simple webapp with three capabilities:
>
> * It can read a simple record ("stream") of "release events" for a
> "release" and produce several static JSON representations of the
> information
> * It can write an entry to one of these streams in response to a
> properly-formatted POST request
> * It can publish a message when a new entry is received
>
> that is all it does. The "releases" and "events" are entirely
> arbitrary; a "release" can be any string, and so can the "state" for a
> given "event". An "event" is defined as a state being either reached or
> left; any number of events for the same state can be present for a
> release.
>
> The JSON outputs are basically "states by release" and "releases by
> state", as you might want either depending on what you're doing. You
> can conveniently look up "what releases are currently in state X?" or
> "what states is release X currently in?".
>
> This all works right now; the main thing that isn't implemented yet is
> any form of authentication. Right now if you can talk to the server you
> can submit events. I wanted to check if there is interest in moving
> forward with this, and discuss various options, before working on that.
> There is a ticket where I sketched out various possible approaches:
> https://pagure.io/fedora-qa/releasestream/issue/2
>
> My idea for using this is basically that we deploy an 'official'
> releasestream instance in infra, and then find things that do the
> actual work of moving Fedora releases into and out of given "states"
> and tack on a bit at the end to tell releasestream about it. So when
> e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a
> "submit 'enter freeze' event to releasestream" to that process somehow
> - ideally something that has to be run as part of the process anyway
> would send the POST, but in a pinch a human could do it too. When
> Fedora 34 is being 'released', we tweak that process to include sending
> a releasestream event POST. And so on.
>
> The thing I like about this design is that there's a low barrier to
> entry, and can easily be adopted piecemeal but still be immediately
> useful for some things - as long as the event your code needs to watch
> for has been "onboarded", you're good. It also allows for the
> implementation details of a state change to change radically - it can
> go from being done by a human to being done by system X to being done
> by system Y, and all that needs to happen is to ensure the same dead
> simple POST request is sent to the same server.
>
> So, what do folks think? Does this seem like a good idea? Should I go
> ahead with trying to get it deployed and onboard things to it? Any
> comments, ideas, potential problems? Thanks!
>
I am pretty sure you did :-) but have you looked at adding the missing
information to Bodhi ? Now that we have rawhide in Bodhi we should be able
to expose most the information needed.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
> ___
> rel-eng mailing list -- rel-...@lists.fedoraproject.org
> To unsubscribe send an email to rel-eng-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/rel-...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
