Re: Request for Intel WiFi Backports - AX2xx
Hello, On Fri, Dec 31, 2021 at 2:34 AM Peter Robinson wrote: > > On Thu, Dec 30, 2021 at 6:21 PM Marcin Juszkiewicz > wrote: > > > > W dniu 28.12.2021 o 00:30, Kevin Anderson pisze: > > > > > There was a iwlwifi issue that would cause firmware resets and cause > > > performance to significantly degrade to around ~500Kb/s till the > > > interface was brought down and then up again. Upstream identified the > > > issue and there are 2 patches that fix the issue by increasing the > > > scan timeout[1] and in cases where the firmware resets allows it to > > > recover quicker[2]. The patch to allow for quicker firmware recovery > > > is present in Linus' tree and present in the 5.16 rc releases while > > > the patch to prevent the firmware from crashing in the instance is in > > > net-next for 5.17. > > > > Did anyone thought of merging those patches into 5.15-stable upstream? > > > > This way it lands in all distributions on next kernel sync. > > The kernel team will generally request that, outside of Fedora that > probably makes sense given 5.15 is LTS and I'm surprised it hasn't > actually happened given the widespread uses of iwl One of the changes was already in 5.15-stable upstream. The other change is still in netdev-next and once it is in Linus' tree I am going to request a backport (assuming the maintainers don't do it automatically). Thanks, Kevin Anderson ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On Thu, Dec 30, 2021 at 12:19:14 +0100, Vitaly Zaitsev via devel wrote: On 30/12/2021 09:21, Chris Murphy wrote: CPU is proprietary, the firmware is proprietary. Guess we can't trust our computers? RISC-V. RISC-V isn't the answer. It is an ISA (with varients), not a computer. A RISC-V based computer has the same issues as other computers. Computers can be trusted to some extent, because useful, hard to detect misexecution is hard outside of some special instructions (such as random number generators). You can purchase computers today without proprietary firmware in key areas. (Essentially you can limit proprietary firmware to denial of service attacks.) Look into Raptor Computering Services Blackbird or Talos 2 power 9 based systems if you are interested. These are not cheap consumer machines; so they aren't for everyone. You can go lower down the stack and use free computer implementations. For example Microwatt is a power ISA implementation for FPGAs. You still have to worry about trusting FPGAs, but you can do more about that than you can with proprietary computers. Bunny Huang has written about trusting FPGAs as part of his precursor project. ___ 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: Koji notifications arriving days late
On Fri, 2021-12-31 at 12:19 +0100, Fabio Valentini wrote: > Yup, my IRC notifications are often delayed by days, as well, making > them ... very much less useful. I second this -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Fri, Dec 31, 2021 at 4:32 AM Richard W.M. Jones wrote: > > On Thu, Dec 30, 2021 at 12:00:06PM +0100, Vitaly Zaitsev via devel wrote: > > On 29/12/2021 18:47, Gordon Messmer wrote: > > >If /usr really is read-only, then it probably doesn't matter where > > >the rpmdb is, since packages can't be installed (generally). > > > > dnf opens these database files for writing, even for the simple `dnf list`. > > If so this is definitely a bug. (However "dnf list" and "dnf download" > seem to work as non-root, so I guess it must fall back to read-only?) Made a note in the change to investigate this. What I'm seeing with stat are ctime and/or mtime updates of the -shm and -wal files. I'm not sure either should be changing. I'm using noatime, but I expect atime updates probably happen with all these files normally. -- 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Fri, Dec 31, 2021 at 4:30 AM Richard W.M. Jones wrote: > > On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr > > * Other developers: > > ** changes in SElinux policy > > Please can you make sure two bugs are filed against libguestfs and > supermin components to track this change (if it happens). Made a note for this in the scope > Will the symlink also exist on new installs, or only on upgrades? Both. -- 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: F36 Change: DIGLIM (System-Wide Change proposal)
On Fri, Dec 31, 2021 at 3:32 AM Vitaly Zaitsev via devel wrote: > > On 30/12/2021 12:58, Roberto Sassu wrote: > > This has not been decided yet, but likely the Fedora kernel will > > contain the official Fedora keys, and the user will decide to add > > new keys (including those from COPR). > > 1. What about self-built RPMs? I always build RPMs in mock and test them > locally before submitting them to Koji as Fedora updates. Sounds like, if this is enabled, they'll need a GPG key associated with their personal repository. > 2. Such keys must be added/removed automatically with the corresponding > COPR repositories. Key management is one of the reasons GPG validation od deployed software has never really taken off. ___ 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: Koji notifications arriving days late
On Fri, 31 Dec 2021 at 10:58, Matthew Miller wrote: > On Fri, Dec 31, 2021 at 12:19:17PM +0100, Fabio Valentini wrote: > > It seems that there is some kind of bottleneck somewhere, because the > > delay often gets progressively worse if there are lots of > > notifications in a short period of time, and then things are only able > > to catch up to recent notifications multiple days later (or get lost, > > when something seemingly crashes and needs to be restarted). > > I think I remember something about the Libera IRC connection being > rate-limited? > > There are several different delays occurring. 1. Currently we are generating a lot of different notifications for EPEL-9 setup and branching. This affects general notifications with delays 2. there is a major delay happening between IRC and Matrix wherever that pass through happens. Messages are generated in IRC and will take a while to shift over to the matrix side. [Vice versa does not seem to have a similar delay which leads to some weird conversations] 3. There are a lot of 'dead-accounts' and 'full-accounts' on Fedora lists and tools. Ones that go to gmail will cause google to throttle any email going to all gmail.com accounts for hours if delivered from a mailing list like the various notifications ones or devel etc. It used to be mailman and various tools would unsubscribe people but that odes not seem to be happening for whatever reasons. I have been just having to do manual unsubscribes from lists when I have time to. There used to be some problems with notification tools in the past where they would crash, then ask for a lot of old messages to make sure they were done, then send a couple and crash again and... but I don't know if that has been fixed in the last 9 months since I left Fedora IT. > -- > 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 > -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Koji notifications arriving days late
Even if it does, it's unlikely to be the culprit, since in my case, I only use e-mail notifications. A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Koji notifications arriving days late
On Fri, Dec 31, 2021 at 12:19:17PM +0100, Fabio Valentini wrote: > It seems that there is some kind of bottleneck somewhere, because the > delay often gets progressively worse if there are lots of > notifications in a short period of time, and then things are only able > to catch up to recent notifications multiple days later (or get lost, > when something seemingly crashes and needs to be restarted). I think I remember something about the Libera IRC connection being rate-limited? -- 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-Rawhide-20211231.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 8 of 43 required tests failed, 8 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 20/228 (x86_64), 24/159 (aarch64) New failures (same test not failed in Fedora-Rawhide-20211230.n.0): ID: 1092962 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/1092962 ID: 1093052 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1093052 ID: 1093069 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/1093069 ID: 1093070 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/1093070 ID: 1093071 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/1093071 ID: 1093080 Test: aarch64 Server-dvd-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1093080 ID: 1093083 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/1093083 ID: 1093087 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/1093087 ID: 1093089 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1093089 ID: 1093090 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1093090 ID: 1093117 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1093117 ID: 1093146 Test: x86_64 Workstation-upgrade desktop_login URL: https://openqa.fedoraproject.org/tests/1093146 Old failures (same test failed in Fedora-Rawhide-20211230.n.0): ID: 1092933 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/1092933 ID: 1092938 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1092938 ID: 1092939 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1092939 ID: 1092954 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/1092954 ID: 1092955 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/1092955 ID: 1092956 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1092956 ID: 1092957 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/1092957 ID: 1092965 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1092965 ID: 1092966 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1092966 ID: 1092989 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1092989 ID: 1092990 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/1092990 ID: 1092995 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1092995 ID: 1093022 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/1093022 ID: 1093106 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1093106 ID: 1093107 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1093107 ID: 1093112 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1093112 ID: 1093123 Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1093123 ID: 1093125 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1093125 ID: 1093134 Test: x86_64 Workstation-upgrade desktop_fprint URL: https://openqa.fedoraproject.org/tests/1093134 ID: 1093148 Test: aarch64 Workstation-upgrade desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1093148 ID: 1093151 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1093151 ID: 1093152 Test: aarch64 Workstation-upgrade evince@uefi URL: https://openqa.fedoraproject.org/tests/1093152 ID: 1093163 Test: aarch64 Workstation-upgrade gedit@uefi URL: https://openqa.fedoraproject.org/tests/1093163 ID: 1093164 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1093164 ID: 1093180 Test: x86_64 universal upgrade
Missing ownership /usr/share/locale/ directories
Hi all, While reviewing switchboard-plug-onlineaccounts [0], I noticed the package places files in /usr/share/locale/mo which isn't owned by anything. This isn't allowed by the packaging guidelines. Normally such folders should be owned by filesystem. There are more packages which place files in /usr/share/locale/mo, most noticable iso-codes: /usr/share/locale/mo/LC_MESSAGES/[iso_3166.mo|iso_3166-1.mo]. Since filesystem uses iso-codes to create the directory structure, this is odd. The origin of /usr/share/locale/mo/LC_MESSAGES/[iso_3166.mo|iso_3166-1.mo] is [1]. This file provides translation of ISO 3166-1 to Moldovan. The file names seems to be created using iso-639 codes, but the problem is that the "mo" ISO 639-1 code is deprecated. This is why filesystem doesn't create/own the /usr/share/locale/mo directory. There are more directories with missing ownership (probably with different reasons), I have compiled a list of them: == am_ET ar_LY ar_MA ar_SA ary as_IN bar be_BY be@tarask ca_ES@valencia cak cz en_BR es_419 es_ar gr gug gug_PY hy_AM hye it_CH jam kmr ko_KO kok@roman ko.UTF-8 ks@deva ks_IN LC_MESSAGES miq mjw mnw mnw_MM mo ms@Arab pa_IN pl.UTF-8 pt_br ro_MD sd@devanagari sr_BA@latin sr_CS sr_Cyrl sr_Latn zh_cn zh_CN.UTF-8 zh_Hans zh_Hans_CN zh_Hant zh_SG zh_TW.UTF-8 === I'm not familiar with this stuff, so I'm not sure how to solve this issue. I would like to complete my review of switchboard-plug-onlineaccounts, but this issue blocks it. I see multiple solutions: - Ignore it and approve switchboard-plug-onlineaccounts (this is against the packaging guidelines) - Patch it, so that "mo" is renamed to "ro" or "rom" and create an issue upstream. I'm not sure how feasible this is, since "mo" is effectively removed and there are also translation files for "ro". This may also cause conflict. - Add an entry to lang-exceptions [2] in filesystem to include "mo" - Suggest upstream iso-codes to look into this issue For the other directories, I sadly don't have time to look into all of them, and I think I have too little knowledge in this field. Regards, Arthur [0] https://bugzilla.redhat.com/show_bug.cgi?id=2033886 [1] https://salsa.debian.org/iso-codes-team/iso-codes/-/blob/main/iso_3166-1/mo.po [2] https://src.fedoraproject.org/rpms/filesystem/blob/rawhide/f/lang-exceptions ___ 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: 20211231.n.0 changes
OLD: Fedora-Rawhide-20211230.n.0 NEW: Fedora-Rawhide-20211231.n.0 = SUMMARY = Added images:0 Dropped images: 4 Added packages: 3 Dropped packages:0 Upgraded packages: 99 Downgraded packages: 0 Size of added packages: 948.60 KiB Size of dropped packages:0 B Size of upgraded packages: 4.18 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 66.67 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20211230.n.0.s390x.tar.xz Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20211230.n.0.armhfp.raw.xz Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20211230.n.0.s390x.raw.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20211230.n.0.s390x.qcow2 = ADDED PACKAGES = Package: mingw-qt6-qtpositioning-6.2.2-2.fc36 Summary: Qt6 for Windows - Qt Positioning component RPMs:mingw32-qt6-qtpositioning mingw64-qt6-qtpositioning Size:694.65 KiB Package: repo-2.19-1.fc36 Summary: Repository management tool built on top of git RPMs:repo Size:82.92 KiB Package: rit-meera-new-fonts-1.2.1-0.fc36 Summary: OpenType sans-serif font for Malayalam traditional script RPMs:rit-meera-new-fonts Size:171.04 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: alt-ergo-2.3.0-1.fc36 Old package: alt-ergo-2.2.0-14.fc36 Summary: Automated theorem prover including linear arithmetic RPMs: alt-ergo alt-ergo-gui ocaml-alt-ergo-lib ocaml-alt-ergo-lib-devel ocaml-alt-ergo-parsers ocaml-alt-ergo-parsers-devel Added RPMs: ocaml-alt-ergo-lib ocaml-alt-ergo-lib-devel ocaml-alt-ergo-parsers ocaml-alt-ergo-parsers-devel Dropped RPMs: ocaml-alt-ergo ocaml-alt-ergo-devel Size: 100.38 MiB Size change: 25.04 MiB Changelog: * Mon Dec 27 2021 Jerry James - 2.3.0-1 - Version 2.3.0 - New ocaml-alt-ergo-lib and ocaml-alt-ergo-parsers subpackages Package: appstream-0.15.1-1.fc36 Old package: appstream-0.14.6-1.fc36 Summary: Utilities to generate, maintain and access the AppStream database RPMs: appstream appstream-compose appstream-compose-devel appstream-devel appstream-qt appstream-qt-devel Size: 13.85 MiB Size change: 113.27 KiB Changelog: * Wed Dec 29 2021 Rex Dieter - 0.15.1-1 - 0.15.1 (#2028696) - update triggers to consistently use --force flag on 'appstreamcli refresh' calls Package: appx-util-0.4-5.fc36 Old package: appx-util-0.4-3.fc35 Summary: Utility to create Microsoft .appx packages RPMs: appx-util Size: 279.48 KiB Size change: 1001 B Changelog: * Tue Sep 14 2021 Sahana Prasad - 0.4-4 - Rebuilt with OpenSSL 3.0.0 * Thu Dec 30 2021 Neal Gompa - 0.4-5 - Backport fix for OpenSSL 3.0 compatibility (RH#2018887) Package: apron-0.9.13-7.fc36 Old package: apron-0.9.13-6.fc36 Summary: Numerical abstract domain library RPMs: apron apron-devel japron ocaml-apron ocaml-apron-devel Size: 21.33 MiB Size change: -521.54 KiB Changelog: * Mon Dec 27 2021 Jerry James - 0.9.13-7 - Rebuild for ocaml-mlgmpidl 1.2.14 Package: audacious-plugins-4.1-5.fc36 Old package: audacious-plugins-4.1-4.fc35 Summary: Plugins for the Audacious audio player RPMs: audacious-plugins audacious-plugins-amidi audacious-plugins-exotic audacious-plugins-jack Size: 9.11 MiB Size change: -33.65 KiB Changelog: * Thu Dec 30 2021 Michael Schwendt - 4.1-5 - rebuild for migration to SDL2 Package: bind-dyndb-ldap-11.9-11.fc36 Old package: bind-dyndb-ldap-11.9-9.fc36 Summary: LDAP back-end plug-in for BIND RPMs: bind-dyndb-ldap Size: 529.47 KiB Size change: -422 B Changelog: * Wed Dec 15 2021 Petr Menk - 11.9-10 - Rebuilt for BIND 9.16.23 (#2032934) * Thu Dec 30 2021 Alexander Bokovoy - 11.9-11 - Rebuild for BIND 9.16.24 (#2035298) Package: coccinelle-1.1.1-2.fc36 Old package: coccinelle-1.1.1-1.fc36 Summary: Semantic patching for Linux (spatch) RPMs: coccinelle coccinelle-bash-completion coccinelle-doc coccinelle-examples Size: 47.80 MiB Size change: 7.81 MiB Changelog: * Mon Dec 27 2021 Jerry James - 1.1.1-2 - Rebuild for ocaml-pcre 7.5.0 - Fetch the official 1.1.1 release tarball - New URLs - Drop unused BRs: ocaml-extlib-devel, chrpath - Add ocaml-parmap-devel BR - Trim the list of filtered modules - Mark ocaml-stdcompat as bundled - Minor spec file cleanups Package: coq-8.14.1-2.fc36 Old package: coq-8.14.1-1.fc36 Summary: Proof management system RPMs: coq coq-coqide coq-coqide-server coq-core coq-doc Size: 1005.96 MiB Size change: -1.16 MiB Changelog: * Mon Dec 27 2021 Jerry James - 8.14.1-2 - Rebuild for ocam
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On 31/12/2021 12:32, Richard W.M. Jones wrote: However "dnf list" and "dnf download" seem to work as non-root, so I guess it must fall back to read-only? Without root and `-C` command-line option it will download all metadata to your $HOME. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Copr - look back at 2021
On Fri, Dec 31, 2021 at 9:20 AM Benson Muite wrote: > > On 12/30/21 5:33 PM, Miroslav Suchý wrote: > > Let me sum up what the Copr team did during 2021: > > > Awesome work. Looking forward to a great 2022! Let me second that. Thank you all for working on COPR and related projects. I use those services and programs almost on a daily basis, and they continue to get better. :) > availability of native s390x builders in the early months of 2022 Having a big-endian architecture available for (native) COPR builds would be great. Thanks for working on it! Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Thu, Dec 30, 2021 at 12:00:06PM +0100, Vitaly Zaitsev via devel wrote: > On 29/12/2021 18:47, Gordon Messmer wrote: > >If /usr really is read-only, then it probably doesn't matter where > >the rpmdb is, since packages can't be installed (generally). > > dnf opens these database files for writing, even for the simple `dnf list`. If so this is definitely a bug. (However "dnf list" and "dnf download" seem to work as non-root, so I guess it must fall back to read-only?) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr > * Other developers: > ** changes in SElinux policy Please can you make sure two bugs are filed against libguestfs and supermin components to track this change (if it happens). We now use librpm to parse the RPM database so I think we're OK from the inspection side, but we do use the RPM database's real location in two places: [supermin] To test if a package has been installed/upated/removed so that we can rebuild our cache [libguestfs] To build a "phony" Fedora image for testing with a fake RPM database. > == Upgrade/compatibility impact == > Change will be applied to offline upgrades, similar to the RPM sqlite > database change. A systemd service will move the rpmdb from /var to > /usr, then create a symlink pointing to /usr from /var. Will the symlink also exist on new installs, or only on upgrades? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ 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: Koji notifications arriving days late
On Fri, Dec 31, 2021 at 12:13 PM Ewoud Kohl van Wijngaarden wrote: > > On Fri, Dec 31, 2021 at 09:59:08AM -, Artur Frenszek-Iwicki wrote: > >This is happening to me, too - but it doesn't seem to be limited > >to koji notifications. It happens with bugzilla notifications as well. > > > >There isn't any pattern to the delays that I can see. > >I regularly receive notification digests during the day, > >yet every now and then I receive a digest informing me > >of stuff that happened 2 or 3 days ago. I think once > >it informed me on stuff that was almost a week old. > > > >My settings in Fedora Notifications are "100 messages or 1 hour". > >I don't receive many notifications, so 100% of the time, > >the time limit kicks in first; most digests I receive > >have single-digit message counts. This applies to the delayed digests > >as well - I've never seen one actually reach 100. > > For me the notifications over IRC arrive a few days after the events > happened. I'm not sure when this started (I don't receive that many > notifications) but I get the impression that they were never instant on > Libera while I have received them instantly on Freenode in the past. Yup, my IRC notifications are often delayed by days, as well, making them ... very much less useful. It seems that there is some kind of bottleneck somewhere, because the delay often gets progressively worse if there are lots of notifications in a short period of time, and then things are only able to catch up to recent notifications multiple days later (or get lost, when something seemingly crashes and needs to be restarted). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Koji notifications arriving days late
On Fri, Dec 31, 2021 at 09:59:08AM -, Artur Frenszek-Iwicki wrote: This is happening to me, too - but it doesn't seem to be limited to koji notifications. It happens with bugzilla notifications as well. There isn't any pattern to the delays that I can see. I regularly receive notification digests during the day, yet every now and then I receive a digest informing me of stuff that happened 2 or 3 days ago. I think once it informed me on stuff that was almost a week old. My settings in Fedora Notifications are "100 messages or 1 hour". I don't receive many notifications, so 100% of the time, the time limit kicks in first; most digests I receive have single-digit message counts. This applies to the delayed digests as well - I've never seen one actually reach 100. For me the notifications over IRC arrive a few days after the events happened. I'm not sure when this started (I don't receive that many notifications) but I get the impression that they were never instant on Libera while I have received them instantly on Freenode in the past. ___ 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: Koji notifications arriving days late
This is happening to me, too - but it doesn't seem to be limited to koji notifications. It happens with bugzilla notifications as well. There isn't any pattern to the delays that I can see. I regularly receive notification digests during the day, yet every now and then I receive a digest informing me of stuff that happened 2 or 3 days ago. I think once it informed me on stuff that was almost a week old. My settings in Fedora Notifications are "100 messages or 1 hour". I don't receive many notifications, so 100% of the time, the time limit kicks in first; most digests I receive have single-digit message counts. This applies to the delayed digests as well - I've never seen one actually reach 100. A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20211231.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211230.0): ID: 1092891 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1092891 ID: 1092902 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1092902 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Koji notifications arriving days late
Hello, is it a known problem that koji notifications arrive way too late? For example, I got mame build notifications in the wee hours today (31.12) wheras the builds completed around noon on the 29th: https://koji.fedoraproject.org/koji/buildinfo?buildID=1871260 https://koji.fedoraproject.org/koji/buildinfo?buildID=1871254 https://koji.fedoraproject.org/koji/buildinfo?buildID=1871253 This does not seem normal. Is anybody seeing this too? Best regards, Julian ___ 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-35-20211231.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20211230.0): ID: 1092875 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1092875 ID: 1092886 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1092886 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On 30/12/2021 12:58, Roberto Sassu wrote: This has not been decided yet, but likely the Fedora kernel will contain the official Fedora keys, and the user will decide to add new keys (including those from COPR). 1. What about self-built RPMs? I always build RPMs in mock and test them locally before submitting them to Koji as Fedora updates. 2. Such keys must be added/removed automatically with the corresponding COPR repositories. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Copr - look back at 2021
On 12/30/21 5:33 PM, Miroslav Suchý wrote: Let me sum up what the Copr team did during 2021: Awesome work. Looking forward to a great 2022! ___ 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