Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 8:52 AM Stephen John Smoogen wrote: > > > > > On Wed, 29 Dec 2021 at 10:19, Tom Hughes via devel > wrote: >> >> I don't see how this is FHS compliant, which in turn would make >> it non-compliant with Fedora Packaging Guidelines, namely: >> > > > I am in agreement here and think that this is NOT a change to be made in F36 > but needs to be worked through the proper channels of 'upstream'. Get the FHS > updated and fixed, work out that the change actually is going to be stuck to > in SuSE and not rolled back and then push it to Fedora. It's actually /usr/lib not /usr that applies here. https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html And it's been worked through proper upstream channels for 4+ years. Location http://lists.rpm.org/pipermail/rpm-maint/2017-October/006722.html FHS question http://lists.rpm.org/pipermail/rpm-maint/2017-October/006697.html There's a bunch of back and forth throughout. The rpmdb isn't really variable data. It's static data that describes other static data. -- 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 Wed, Dec 29, 2021 at 03:17:42PM +, Tom Hughes via devel wrote: > At this point somebody will no doubt argue that /usr changes on a > package update and that the RPM database is a static definition of > the currently installed OS files, but evidence says otherwise: > > % ls -l /var/lib/rpm > > total 378M > > -rw-r--r--. 1 root root 378M Dec 28 16:08 rpmdb.sqlite > -rw-r--r--. 1 root root 32K Dec 29 09:27 rpmdb.sqlite-shm > -rw-r--r--. 1 root root0 Dec 28 16:08 rpmdb.sqlite-wal > > > While "Dec 28 16:08" is indeed the last time I updated that machine > it seems one of the files has changed more recently - no idea what > triggered that but clearly the files are not static between updates. That is a sqlite write-ahead log shared memory file used to coordinate access between concurrent clients. Someone who knows more about the depths of DNF and RPM than me will need to comment, but it looks like `dnf list` touches it -- even though `rpm -qa` doesn't. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On 30/12/2021 07:02, Chris Murphy wrote: On Wed, Dec 29, 2021 at 8:19 AM Tom Hughes via devel wrote: I don't see how this is FHS compliant, which in turn would make it non-compliant with Fedora Packaging Guidelines, namely: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_filesystem_layout The FHS describes /usr here: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html#purpose18 as "/usr is shareable, read-only data" which clearly does not apply to a database that changes. In practice it is read-only data, except when software is being installed or updated. The FHS is a PITA sometimes, but it's not advocating for systems that can't be updated or changed.. As I demonstrated later in my email the contents of /var/lib/rpm do change at other times though. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 8:19 AM Tom Hughes via devel wrote: > > I don't see how this is FHS compliant, which in turn would make > it non-compliant with Fedora Packaging Guidelines, namely: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_filesystem_layout > > The FHS describes /usr here: > >https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html#purpose18 > > as "/usr is shareable, read-only data" which clearly does not > apply to a database that changes. In practice it is read-only data, except when software is being installed or updated. The FHS is a PITA sometimes, but it's not advocating for systems that can't be updated or changed.. -- 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 Wed, Dec 29, 2021 at 7:36 PM Matthew Miller wrote: > > On Wed, Dec 29, 2021 at 12:57:25PM -0500, Neal Gompa wrote: > > of the RPM database. Once the RPM database is moved, it becomes > > possible to split /var into its own subvolume and make it trivial to > > configure a full boot-to-snapshot system leveraging the technologies > > we have available to us. > > The Benefit to Fedora section alludes to this, but doesn't really spell it > out... since this seems like a pretty compelling benefit, it probably > should. Added. There's more hurdles to jump, just so no one thinks snapshots and rollbacks are showing up in Fedora 36. There's a quandary with /boot which likewise is married to /usr via the vmlinuz kernel modules. As we snapshot /usr how do we retain vmlinuz such that we can still boot those older snapshots? And then how do we do it considering Boot Loader Spec expects "boot" (or $BOOT) volume to be shared among multiple distros? Related is the "discoverable sub-volumes specification" discussion, so that we have a way of self-described assembly of systems during startup instead of having to depend on fstab, or any other database for that matter, to know how a system should boot. https://lists.freedesktop.org/archives/systemd-devel/2021-November/047059.html -- 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: Default To Noto Fonts (System-Wide Change proposal)
On 12/29/21 2:20 PM, Neal Gompa wrote: On Wed, Dec 29, 2021 at 12:27 PM Artem Tim wrote: Cantarell current default UI font in GNOME (Workstation) will be replaced by Noto font as well or remain? The current plan is to keep Cantarell for now, though GNOME upstream may decide to switch to Noto as KDE Plasma did years ago. Does Noto have the default font-variant-numeric as tabular-nums? (non proportional decimal digits) because it will be a welcomed change. The current default of Cantarell makes any number showing application a pain to style, specially on toolkits that use the system font but are unable to change font variants (Java Swing with GTK Look and Feel). Even GNOME applications aren't properly styled for number entry use cases. See for example Calculator where 111,111,111 looks like a smaller number than 99,999,999 when the are one on top of the other, because the font is proportional by default. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
On 12/29/21 6:38 PM, Elliott Sales de Andrade wrote: On Wed, 29 Dec 2021 at 10:02, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change == Summary == Update Hunspell Dictionary system directory from /usr/share/myspell/ to /usr/share/hunspell/ == Owner == * Name: [[User:vishalvvr| Vishal Vijayraghavan]] * Email: == Detailed Description == In most of Linux distributions the standard Hunspell dictionary path is `/usr/share/hunspell/` but in Fedora still has `/usr/share/myspell/`. This effort is to follow default standard to install all Hunspell dictionary into `/usr/share/hunspell/` instead of `/usr/share/myspell/`. == Benefit to Fedora == This will future proof Fedora to use the correct current location for hunspell spelling dictionaries. == Scope == * Proposal owners: In total there are `135` packages which is to be updated. libreoffice & Firefox are the two main applications and rest are mostly language dictionary packages. * Other developers: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == 1. Check if default installed dictionary path is `/usr/share/hunspell/` instead of `/usr/share/myspell/` `$ hunspell -D` or `$ ls /usr/share/hunspell/` 2. Install any language dictionary and check if it getting installed into '/usr/share/hunspell/' `$ dnf install hunspell-hi` `$ hunspell -D` If, as mentioned above, this will possibly affect applications such as Firefox and LibreOffice, then those should also be tested as well. and Thunderbird. I came here to say this too but you won. I remember a few releases back a change like that broke dictionaries in Firefox and Thunderbird, the workaround and the patch later applied was to change some internal preference that pointed to the local installed dictionaries. == User Experience == User should not notice any difference: their applications should continue to work as expected after this directory migration. == Dependencies == == Contingency Plan == * Contingency mechanism: revert release back to /usr/share/myspell * Contingency deadline: Beta * Blocks release? No -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031484] Please branch and build perl-Hash-Merge in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2031484 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2021-6f30e2081b has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6f30e2081b 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. https://bugzilla.redhat.com/show_bug.cgi?id=2031484 ___ 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 2031801] perl-HTML-Template for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031801 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2021-739ea2e5e0 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-739ea2e5e0 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. https://bugzilla.redhat.com/show_bug.cgi?id=2031801 ___ 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 1811624] [RFE] EPEL8 branch of perl-HTML-TableExtract
https://bugzilla.redhat.com/show_bug.cgi?id=1811624 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2021-3afd09548b 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-3afd09548b 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. https://bugzilla.redhat.com/show_bug.cgi?id=1811624 ___ 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 12:57:25PM -0500, Neal Gompa wrote: > of the RPM database. Once the RPM database is moved, it becomes > possible to split /var into its own subvolume and make it trivial to > configure a full boot-to-snapshot system leveraging the technologies > we have available to us. The Benefit to Fedora section alludes to this, but doesn't really spell it out... since this seems like a pretty compelling benefit, it probably should. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 10:51:44AM -0500, Stephen John Smoogen wrote: > F36 but needs to be worked through the proper channels of 'upstream'. Get > the FHS updated and fixed, work out that the change actually is going to be Pretty sure that's a non-starter. FHS 3.0 was released in 2015, and the whole thing has been effectively dead since. -- 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-afc31f929c seamonkey-2.53.10.1-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82b601cdc1 libofx-0.9.9-3.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing unrealircd-5.2.3-1.el7 Details about builds: unrealircd-5.2.3-1.el7 (FEDORA-EPEL-2021-33a94b58ec) Open Source IRC server Update Information: # UnrealIRCd 5.2.3 This release contains a couple of small changes. **Important: From upstream's perspective, UnrealIRCd 6 is the new "stable", UnrealIRCd 5.2.x is now "oldstable".** ## Enhancements * Spanish example conf was added (`conf/help/example.es.conf`) ## Fixes * `set::anti-flood::connect- flood` was only expiring entries every 2 minutes. Only after a `REHASH` the configuration file setting was used. * Memory leak in websocket module * Send `WALLOPS` back to the sender too # Changes * Update `HELPOP` docs * Add information on EOL date * Add `CONTRIBUTING.md` file with a reference to docs on how people can help out. ChangeLog: * Wed Dec 29 2021 Robert Scheck 5.2.3-1 - Upgrade to 5.2.3 ___ 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
Fedora-Rawhide-20211229.n.1 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 14 of 43 required tests failed, 8 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 29/228 (x86_64), 30/159 (aarch64) ID: 1091854 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/1091854 ID: 1091859 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1091859 ID: 1091860 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1091860 ID: 1091875 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/1091875 ID: 1091876 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/1091876 ID: 1091877 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1091877 ID: 1091878 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/1091878 ID: 1091880 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/1091880 ID: 1091881 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1091881 ID: 1091886 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1091886 ID: 1091887 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1091887 ID: 1091910 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1091910 ID: 1091911 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/1091911 ID: 1091916 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1091916 ID: 1091943 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/1091943 ID: 1091965 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1091965 ID: 1091966 Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1091966 ID: 1091973 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1091973 ID: 1091990 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/1091990 ID: 1091991 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/1091991 ID: 1091992 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/1091992 ID: 1092001 Test: aarch64 Server-dvd-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1092001 ID: 1092004 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/1092004 ID: 1092008 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/1092008 ID: 1092010 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1092010 ID: 1092011 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1092011 ID: 1092027 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1092027 ID: 1092028 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1092028 ID: 1092033 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1092033 ID: 1092044 Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1092044 ID: 1092046 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1092046 ID: 1092049 Test: x86_64 Workstation-upgrade gedit URL: https://openqa.fedoraproject.org/tests/1092049 ID: 1092055 Test: x86_64 Workstation-upgrade desktop_fprint URL: https://openqa.fedoraproject.org/tests/1092055 ID: 1092069 Test: aarch64 Workstation-upgrade desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1092069 ID: 1092072 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1092072 ID: 1092084 Test: aarch64 Workstation-upgrade gedit@uefi URL: https://openqa.fedoraproject.org/tests/1092084 ID: 1092085 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1092085 ID: 1092095 Test: x86_64 universal support_server
Re: Fedora rawhide compose report: 20211229.n.1 changes
Thank you. ___ 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 2034440] perl-Module-CoreList-5.20211220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2034440 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021 |1220-1.fc36 |1220-1.fc36 |perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021 |1220-1.fc35 |1220-1.fc35 ||perl-Module-CoreList-5.2021 ||1220-1.fc34 --- Comment #6 from Fedora Update System --- FEDORA-2021-f1dcc59128 has been pushed to the Fedora 34 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. https://bugzilla.redhat.com/show_bug.cgi?id=2034440 ___ 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 2034443] perl-CPAN-Perl-Releases-5.20211220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2034443 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0211220-1.fc36 |0211220-1.fc36 |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0211220-1.fc35 |0211220-1.fc35 ||perl-CPAN-Perl-Releases-5.2 ||0211220-1.fc34 --- Comment #6 from Fedora Update System --- FEDORA-2021-1fdd440e82 has been pushed to the Fedora 34 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. https://bugzilla.redhat.com/show_bug.cgi?id=2034443 ___ 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: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
On Wednesday, 29 December 2021 15.01.49 WET Ben Cotton wrote: > == Detailed Description == > In most of Linux distributions the standard Hunspell dictionary path > is `/usr/share/hunspell/` but in Fedora still has > `/usr/share/myspell/`. This effort is to follow default standard to > install all Hunspell dictionary into `/usr/share/hunspell/` instead of > `/usr/share/myspell/`. It is too late in my timezone to do a joke about this. :-D I am not sure if this is the cause but I had problems when I installed jupyterlab_spellchecker extension to work in Jupyter Lab. And it seems that I am not the only one: https://discourse.jupyter.org/t/jupyter-lab-dictionary-not-loaded/12228 it is difficult to remember how I fixed the issue but it was a frustrating and tiring experience. :-( I hope that this change help theses cases. Regards, -- José Abílio___ 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: 20211229.n.1 changes
On Thu, Dec 30, 2021 at 12:47:56AM +, Fedora Rawhide Report wrote: > OLD: Fedora-Rawhide-20211217.n.1 > NEW: Fedora-Rawhide-20211229.n.1 So, FYI, breakage here in composes was: - A glibc update broke 'ldconfig -p' on armv7 on 2021-12-17. https://bugzilla.redhat.com/show_bug.cgi?id=2034715 This caused pyudev to not be able to figure out where the udev library was to load it, and anaconda calls that, so the armv7 images failed the compose. The problem change has been reverted. - In the mean time, a libzstd update broke systemd on armv7. https://bugzilla.redhat.com/show_bug.cgi?id=2035802 A fix has been built, although i686 may still be broken. - And finally systemd-250 broke booting on aarch64 https://bugzilla.redhat.com/show_bug.cgi?id=2036145 This cased the aarch64 cloud image to fail to boot. I have untagged 250-1 and 250-2 for now. Many thanks to all the maintainers who checked bugs and landed fixes/new builds over the holidays. 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 2034443] perl-CPAN-Perl-Releases-5.20211220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2034443 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0211220-1.fc36 |0211220-1.fc36 ||perl-CPAN-Perl-Releases-5.2 ||0211220-1.fc35 Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2021-12-30 01:18:02 --- Comment #5 from Fedora Update System --- FEDORA-2021-7bcbfef712 has been pushed to the Fedora 35 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. https://bugzilla.redhat.com/show_bug.cgi?id=2034443 ___ 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 2034440] perl-Module-CoreList-5.20211220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2034440 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Fixed In Version|perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021 |1220-1.fc36 |1220-1.fc36 ||perl-Module-CoreList-5.2021 ||1220-1.fc35 Status|ON_QA |CLOSED Last Closed||2021-12-30 01:17:59 --- Comment #5 from Fedora Update System --- FEDORA-2021-8a66d13dea has been pushed to the Fedora 35 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. https://bugzilla.redhat.com/show_bug.cgi?id=2034440 ___ 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
[Test-Announce] Fedora 36 Rawhide 20211229.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 36 Rawhide 20211229.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20211215.n.0: anaconda-36.11-1.fc36.src, 20211229.n.1: anaconda-36.12-1.fc36.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/36 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211229.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211229.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211229.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211229.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211229.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211229.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211229.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, 2021-12-29 at 12:57 -0500, Neal Gompa wrote: > On Wed, Dec 29, 2021 at 12:48 PM Gordon Messmer > wrote: > > > > On 12/29/21 07:26, Vitaly Zaitsev via devel wrote: > > > On 29/12/2021 16:01, Ben Cotton wrote: > > > > Currently, the RPM databases is located in `/var`. Let's move it > > > > to > > > > `/usr`. The move is already under way in rpm-ostree-based > > > > installations, and in (open)SUSE. > > > > > > It will break FHS compatibility. /usr must contain read-only data. > > > > > > If /usr really is read-only, then it probably doesn't matter where > > the > > rpmdb is, since packages can't be installed (generally). > > > > Moreover, for systems where /usr is read-only and/or shared > > (especially > > stateless systems), having the rpmdb on /usr seems like the most > > rational place for it, if one expects to be able to use rpm to query > > the > > package list. Otherwise, there is an implicit coupling of /usr and > > /var/lib/rpmdb that requires two mounts rather than one. > > Bingo. It's generally accepted that the RPM database changes when the > system state changes. And if the system state is not allowed to > change, the rpmdb should not either. The bigger problem is that having > the RPM database in /var makes it much harder to correctly implement a > boot-to-snapshot scheme for Fedora Linux that reasonably maintains > system state properly once /var is carved out. you just need change to change the default --dbpath of rpm [1] , i.e, I suggest instead change default location of rpm , change the dbpath configuration for the atomic images, is just one idea . [1] man rpm --dbpath DIRECTORY Use the database in DIRECTORY rather than the default path /var/lib/rpm > The reason that /var > *isn't* carved out by default with our Btrfs configuration is because > of the RPM database. Once the RPM database is moved, it becomes > possible to split /var into its own subvolume and make it trivial to > configure a full boot-to-snapshot system leveraging the technologies > we have available to us. > > > > -- > 真実はいつも一つ！/ 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 -- 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
intend to orphan jctools
Hi, I'd like orphan jctools , because it is a FTBFS on rawhide (F36) The only direct dependency is log4j [1] if someone want take it, let me know , and I will transfer the ownership . Thank you, [1] Depending on: jctools (4), status change: 2021-04-26 (35 weeks ago) log4j (maintained by: pwouters) log4j-2.15.0-1.fc36.src requires mvn(org.jctools:jctools-core) = 3.3.0 jericho-html (maintained by: terjeros) jericho-html-3.3-21.fc35.src requires log4j = 2.15.0-1.fc36 jglobus (maintained by: ellert) jglobus-2.1.0-24.fc36.src requires mvn(log4j:log4j) = 2.15.0 jglobus-ssl-proxies-2.1.0-24.fc36.noarch requires mvn(log4j:log4j) = 2.15.0 ditaa (maintained by: terjeros) ditaa-0.10-14.fc35.noarch requires jericho-html = 3.3-21.fc35 ditaa-0.10-14.fc35.src requires jericho-html = 3.3-21.fc35 Affected (co)maintainers ellert: jctools pwouters: jctools sergiomb: jctools terjeros: jctools Depending packages (rawhide) (4): ditaa jericho-html jglobus log4j -- 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: Default To Noto Fonts (System-Wide Change proposal)
Ben Cotton wrote: > == Summary == > Changing the default fonts for various languages to Noto Fonts as much > as possible, to make consistency on the text rendering. > > == Owner == > * Name: [[User:Tagoh|Akira TAGOH]] > * Email: Considering that DejaVu had been chosen as the default font for its high coverage (by the standards at that time), that that coverage has been significantly surpassed by Noto, and that DejaVu appears to be unmaintained upstream (no commits for 5 years, whereas it used to be released every 2 weeks or so to improve coverage back in the day), this looks like a reasonable thing to do. Also note that Noto is already the default in KDE Plasma. > == Detailed Description == > For a long time we have used DejaVu fonts as the default font for > European and other language scripts. On the other hand some language > scripts are not covered by DejaVu and hence have other default fonts. > (A few languages like Chinese, Japanese and Korean, as well as > Gurmukhi, Sinhala, and emoji are already using Noto fonts by default > for some time.) This situation leads to inconsistencies in text > rendering on applications and desktops, particularly when mixing > different character sets. Further Noto fonts bring some further > advantages: the fonts are generally higher quality and support > variable fonts for most scripts, making them more compact. > > This change aims to provide better experience and consistent text > rendering across more languages by replacing DejaVu with Noto as the > general system default set of fonts. +1 However: > And you can check > [https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to > see what languages will be affected by this change. I see in this table that there are still a bunch of languages using non-Noto fonts where there appears to be a Noto equivalent available, e.g., https://fonts.google.com/noto shows me Devanagari, Bengali, and Tamil on the first page whereas your table indicates that Lohit fonts will continue to be used there. What is the reason for that? Are the Noto fonts for those scripts incomplete? I think using Noto wherever possible would lead to a more consistent experience. 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
Re: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
On Wed, 29 Dec 2021 at 10:02, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change > > == Summary == > Update Hunspell Dictionary system directory from /usr/share/myspell/ > to /usr/share/hunspell/ > > == Owner == > * Name: [[User:vishalvvr| Vishal Vijayraghavan]] > * Email: > > > == Detailed Description == > In most of Linux distributions the standard Hunspell dictionary path > is `/usr/share/hunspell/` but in Fedora still has > `/usr/share/myspell/`. This effort is to follow default standard to > install all Hunspell dictionary into `/usr/share/hunspell/` instead of > `/usr/share/myspell/`. > > > == Benefit to Fedora == > This will future proof Fedora to use the correct current location for > hunspell spelling dictionaries. > > == Scope == > * Proposal owners: > In total there are `135` packages which is to be updated. libreoffice > & Firefox are the two main applications and rest are mostly language > dictionary packages. > > * Other developers: > > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > > == Upgrade/compatibility impact == > > > == How To Test == > 1. Check if default installed dictionary path is > `/usr/share/hunspell/` instead of `/usr/share/myspell/` > > `$ hunspell -D` or `$ ls /usr/share/hunspell/` > > 2. Install any language dictionary and check if it getting installed > into '/usr/share/hunspell/' > > `$ dnf install hunspell-hi` > > `$ hunspell -D` > If, as mentioned above, this will possibly affect applications such as Firefox and LibreOffice, then those should also be tested as well. > > == User Experience == > User should not notice any difference: their applications should > continue to work as expected after this directory migration. > > == Dependencies == > > > == Contingency Plan == > > * Contingency mechanism: revert release back to /usr/share/myspell > * Contingency deadline: Beta > * Blocks release? No > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On 12/29/21 13:21, Sebastian Crane wrote: Why would you need to move the rpmdb? Users probably aren't installing rpm packages in containers at run time (particularly if /usr is read-only); installation typically happens when building the container image, at which point /usr isn't read-only. I do actually install RPM package inside containers, but in my case I'm using containers more as short-lived virtual machines for testing than as a deployment mechanism. That said, I don't think that this nullifies your point, as I'm not using a read-only /usr inside these containers. Yeah, that was poorly worded. Sorry. What I meant was simply that containers don't seem to be a unique use case. If a container has a writable /usr, then that should be a suitable location for the rpmdb. And if the container's /usr is read-only, then the rpmdb doesn't need to be in /var. ___ 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 05:06:37PM -0500, Stephen John Smoogen wrote: > On Wed, 29 Dec 2021 at 16:16, Michel Alexandre Salim < > sali...@fedoraproject.org> wrote: > > > All that said, this isn't the first time this has happened. It is the > reason why various large changes usually require groups to sort of make a > sample sausage for people to eat before they have to sit through watching > the larger sausage made. Because we are all going to have to do that while > any of these changes are working through the grinder. > That's good feedback, thanks. It can probably be done in both this case and fs-verity: - for the RPMDB change: have a COPR repo with the patched RPM and the systemd service, with clear instructions how to test Potential issue: if someone enables this without reading the instructions, and did not create the symlink either manually or via the service, this can break their system. Probably have to name it something like 'rpmdb-move-READ-INSTRUCTIONS-FIRST' or something scary like that - for fsverity: having a COPR with the plugin and some re-signed packages would probably work, so people can get familiar with it Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 3:36 PM Stephen John Smoogen wrote: > > > > On Wed, 29 Dec 2021 at 13:51, Gordon Messmer wrote: >> >> On 12/29/21 09:59, Stephen John Smoogen wrote: >> > The modern day case where /usr is read-only is inside a container and >> > you put an overlay or using some sort of linking to /var which is >> > read-write in case of reboots. >> >> >> Right, that makes sense. >> >> >> > To me this is like saying 'move everything into /usr but because its >> > volitile move it back into /var but in a sub-directory from where it >> > was so you can keep an image running.' In this case, this doesn't >> > sound like any savings and more of a headache of why did it corrupt >> > this time. >> >> >> But this doesn't. Why would you need to move the rpmdb? Users probably >> aren't installing rpm packages in containers at run time (particularly >> if /usr is read-only); installation typically happens when building the >> container image, at which point /usr isn't read-only. >> > Most of the containers I am dealing with are > Grab the base image, > Create a layer, and add the images you want, > Test and deploy the layered image. > Update that image over time. > > Theoretically people should build the thing from scratch every time but > instead you get someone downloading the base image which they have gotten an > OK to use, then adding the stuff they need, and then running with that for > YEARS because the person who built the first one left long ago and no one > wants to break the paycheck program again. This is a very, very old problem: I was dealing with it with OS images 20 years ago. ___ 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, 29 Dec 2021 at 16:16, Michel Alexandre Salim < sali...@fedoraproject.org> wrote: > On Wed, Dec 29, 2021 at 10:51:44AM -0500, Stephen John Smoogen wrote: > > Also please realise that the community can eat only so many changes per > > release no matter how much you want to otherwise. You can probably get > this > > OR the fs-verity in some future release, but not both in the same release > > and trying to fight for both is going to mean you get neither. In fact, > at > > a certain point too many changes start making it that any CR with certain > > names attached will get derailed because people are sure there is some > sort > > of agenda or conspiracy which they have to fight to stop. > > I'm not sure I understand this point. Chris is proposing this change, > and Neal and I listed because I volunteered to help him implement some of > the > changes. > > And Chris is not on the fs-verity change, and neither is Neal. > > My apologies.. I lost track of who was on each of these, and I did not double check before posting. That is my fault 100%. I should have just said I have Change Fatigue with all the proposed changes and have left it at that. > I do hope everyone give each other the benefit of the doubt and not jump > to assuming there is a secret agenda or conspiracy afoot -- I see this > raised against the DIGLIM proposal too, at least once -- but if it helps > make it clear that there is no agenda being pushed, I'll take my name > off this change so there is no confusion. > > My main issue is that people are seeing agenda's, and it isn't just the usual suspects of people who say NO to many changes. After rereading the changes to make sure I know who is on them, the main problem I am seeing is that there is nothing to sell why the standard Fedora contributor will want any of them in their OS. There is not even a 'Hey we did this already for this rebuild and you can play with it to see if it makes sense for you'. There does not seem to be any community involvement beforehand and nothing for people but to 'react against' the change. Add in the number of them and those reactions become looking for 'hidden' agendas etc. All that said, this isn't the first time this has happened. It is the reason why various large changes usually require groups to sort of make a sample sausage for people to eat before they have to sit through watching the larger sausage made. Because we are all going to have to do that while any of these changes are working through the grinder. > Best regards, > > -- > Michel Alexandre Salim > profile: https://keyoxide.org/mic...@michel-slm.name > ___ > 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: F-ExcludeArhc-aarch64 tracker closed?
Hi Peter, On Wed, Dec 29, 2021 at 09:19:02PM +, Peter Robinson wrote: > > Looks like of all the architecture build failures tracking bugs listed > > in > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures, > > the aarch64 one is currently closed: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=922257 > > > > Looks like at some point all bugs are indeed closed, but there are now > > four bugs listed against it. Should the status go back to NEW? > > No, we moved everything to ARMTracker and track it all under a single > tracker bug, it's more straight forward. Thanks for the confirmation! It's still listed in the packaging guidelines, so I opened a PR to remove it here: https://pagure.io/packaging-committee/pull-request/1146 Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
Dear Gordon, > Why would you need to move the rpmdb? Users probably aren't > installing rpm packages in containers at run time (particularly if > /usr is read-only); installation typically happens when building the > container image, at which point /usr isn't read-only. I do actually install RPM package inside containers, but in my case I'm using containers more as short-lived virtual machines for testing than as a deployment mechanism. That said, I don't think that this nullifies your point, as I'm not using a read-only /usr inside these containers. Best wishes, Sebastian ___ 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: F-ExcludeArhc-aarch64 tracker closed?
> Looks like of all the architecture build failures tracking bugs listed > in > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures, > the aarch64 one is currently closed: > > https://bugzilla.redhat.com/show_bug.cgi?id=922257 > > Looks like at some point all bugs are indeed closed, but there are now > four bugs listed against it. Should the status go back to NEW? No, we moved everything to ARMTracker and track it all under a single tracker bug, it's more straight forward. ___ 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:51:44AM -0500, Stephen John Smoogen wrote: > Also please realise that the community can eat only so many changes per > release no matter how much you want to otherwise. You can probably get this > OR the fs-verity in some future release, but not both in the same release > and trying to fight for both is going to mean you get neither. In fact, at > a certain point too many changes start making it that any CR with certain > names attached will get derailed because people are sure there is some sort > of agenda or conspiracy which they have to fight to stop. I'm not sure I understand this point. Chris is proposing this change, and Neal and I listed because I volunteered to help him implement some of the changes. And Chris is not on the fs-verity change, and neither is Neal. I do hope everyone give each other the benefit of the doubt and not jump to assuming there is a secret agenda or conspiracy afoot -- I see this raised against the DIGLIM proposal too, at least once -- but if it helps make it clear that there is no agenda being pushed, I'll take my name off this change so there is no confusion. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 02:13:19PM -0500, Nico Kadel-Garcia wrote: > On Wed, Dec 29, 2021 at 12:48 PM Gordon Messmer > wrote: > > > > On 12/29/21 07:26, Vitaly Zaitsev via devel wrote: > > > On 29/12/2021 16:01, Ben Cotton wrote: > > >> Currently, the RPM databases is located in `/var`. Let's move it to > > >> `/usr`. The move is already under way in rpm-ostree-based > > >> installations, and in (open)SUSE. > > > > > > It will break FHS compatibility. /usr must contain read-only data. > > > > > > If /usr really is read-only, then it probably doesn't matter where the > > rpmdb is, since packages can't be installed (generally). > > There are plenty of packages which do not write to /usr/, especially > third party add-ons over in /opt/ . It makes more sense for /var to be in a separate volume from /usr, than for /usr and /opt to be in separate volumes though. Provided /usr and /opt are in the same volume, then snapshotting and rolling back works as expected. -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On Tue, Dec 28, 2021 at 09:20:11AM -0600, Bruno Wolff III wrote: > On Tue, Dec 28, 2021 at 14:45:59 +0100, > Kevin Kofler via devel wrote: > > > > But there is the inherent assumption there that the set of software released > > by Fedora is identical to the set of software the user trusts. In practice, > > those sets will, sure, be overlapping (non-disjoint), but still distinct > > (non-identical). And I think they will differ sufficiently for it to be an > > issue. > > I can tell you, I trust icecat a lot more than I trust firefox. But even > that isn't black and white. This proposal divides software into good and not > good categories. That really doesn't match how I use software. This seems to presume DIGLIM is the only mechanism available. Admins running large fleets likely have other mechanisms that complement this, e.g. selective sync of repos with unapproved software excluded, enforcing minimum versions of packages to exclude versions known to have security vulnerabilities, etc. If/when something like this gets shipped, I hope Fedora limits itself to shipping a policy that is the equivalent of SELinux's 'targeted' policy: protect the RPMs that Fedora ships from being tampered with, let users do whatever on top. With an option to turn it off completely or to enforce more strictly. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, 29 Dec 2021 at 13:51, Gordon Messmer wrote: > On 12/29/21 09:59, Stephen John Smoogen wrote: > > The modern day case where /usr is read-only is inside a container and > > you put an overlay or using some sort of linking to /var which is > > read-write in case of reboots. > > > Right, that makes sense. > > > > To me this is like saying 'move everything into /usr but because its > > volitile move it back into /var but in a sub-directory from where it > > was so you can keep an image running.' In this case, this doesn't > > sound like any savings and more of a headache of why did it corrupt > > this time. > > > But this doesn't. Why would you need to move the rpmdb? Users probably > aren't installing rpm packages in containers at run time (particularly > if /usr is read-only); installation typically happens when building the > container image, at which point /usr isn't read-only. > > Most of the containers I am dealing with are Grab the base image, Create a layer, and add the images you want, Test and deploy the layered image. Update that image over time. Theoretically people should build the thing from scratch every time but instead you get someone downloading the base image which they have gotten an OK to use, then adding the stuff they need, and then running with that for YEARS because the person who built the first one left long ago and no one wants to break the paycheck program again. -- 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, 29 Dec 2021 at 19:00, Gordon Messmer wrote: [..] > > To me this is like saying 'move everything into /usr but because its > > volitile move it back into /var but in a sub-directory from where it > > was so you can keep an image running.' In this case, this doesn't > > sound like any savings and more of a headache of why did it corrupt > > this time. > > But this doesn't. Why would you need to move the rpmdb? Users probably > aren't installing rpm packages in containers at run time (particularly > if /usr is read-only); installation typically happens when building the > container image, at which point /usr isn't read-only. > This is all because none of the file systems available on Linux invented volumes properties. +15 years ago on ZFS introduction on Solaris people had exactly the same problems and all those issues have been resolved by introduction of the volume property marking that exact volume needs to be snapshotted and cloned on making new boot env (global or non-global zone as well). That issue is not limited only to rpm database content or generally /var content. In case scenario when new boot env is created and on that new tree would be upgraded majost upgrade of the database engine which on first execution will change format of the database files you want to have some "backup solution" that in case if anything would go wrong you want to be able quickly be able back to original state. In such cases new upgraded database engine binaries will be on /usr and let's say that database data on /srv/database. To create new boot env in which not only / and /usr will be mounted from from exact clones all what needs to be done in case Solaris or Linux with ZFS would be mark volume mounted in /var that it needs to be snapshotted and cloned during created new instance of the bootable filesystems tree. In other words trying to solve the multiple volumes mount problem by moving more and more to a single volume (because that is the easiest case) is pointless because it will solve only the rpm database problem but it will not solve issues of mounting multiple volumes. Solving that kind of problems on top of all possible to use on Linux like systems is as well pointless because to solve such thing in civilised way it is necessary to have snapshotable FS which in case of linux for now is only btrfs (optionally zfs as well). Volulumes properties stored in volume metadata inside storage pools solves much more use cases than only /, /usr and /var separation. From that point of view I really do not understand why btrfs developers resist to implement well known ZFS functionality. In other words when btrfs will have possibility to possibility to describe a set of volumes which will be necessary to snapshot and clone on making new boot env volumes set SuSE will be rolling back move rpm database back to the /var where it should be. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML
https://bugzilla.redhat.com/show_bug.cgi?id=2036125 Paul Howarth changed: What|Removed |Added Blocks||1811577 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1811577 [Bug 1811577] perl-Finance-Quote EPEL8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036125 ___ 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 2036123] Please branch and build perl-HTML-Selector-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036123 Paul Howarth changed: What|Removed |Added Blocks||1811577 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1811577 [Bug 1811577] perl-Finance-Quote EPEL8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036123 ___ 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 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036122 Paul Howarth changed: What|Removed |Added Blocks||1811577 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1811577 [Bug 1811577] perl-Finance-Quote EPEL8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036122 ___ 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 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036118 Paul Howarth changed: What|Removed |Added Blocks||1811577 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1811577 [Bug 1811577] perl-Finance-Quote EPEL8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036118 ___ 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 1811577] perl-Finance-Quote EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1811577 Paul Howarth changed: What|Removed |Added Depends On||2036123, 2036120, 2036125, ||2036122, 2036118 --- Comment #2 from Paul Howarth --- Latest version has additional dependencies. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036118 [Bug 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2036120 [Bug 2036120] Please branch and build perl-HTML-TokeParser-Simple for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2036122 [Bug 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2036123 [Bug 2036123] Please branch and build perl-HTML-Selector-XPath for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2036125 [Bug 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1811577 ___ 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 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML
https://bugzilla.redhat.com/show_bug.cgi?id=2036125 --- Comment #1 from Paul Howarth --- This one needs bootstrapping without perl-Web-Scraper, which complicates things a bit. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036125 ___ 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: Package wishlist site?
Thank you for the feedback. It all makes sense, and I agree with your points, so I won't put any more effort into this idea. I am also glad, that this discussion happened and the idea won't be itching my brain anymore. Jakub On Sun, Dec 26, 2021 at 7:31 AM Dan Čermák wrote: > > Hi Jakube, > > Jakub Kadlčík writes: > > > Hello, > > > > TL;DR What about a place where people could ask for something to be > > packaged in Fedora? > > As others already commented: I don't think that this is a good > idea. > > Packaging a program for others where you have no real personal > interest/benefit/buy-in is in my experience not sustainable in the long > haul, besides nearly no one doing it (probably for that reason). I would > actually even say that having such a list is harmful to the project as > it would suggest that someone will eventually package the app, thereby > more or less guaranteeing disappointment. > > > Cheers, > > Dan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam 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
[Bug 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML
https://bugzilla.redhat.com/show_bug.cgi?id=2036125 Paul Howarth changed: What|Removed |Added Blocks||2036126 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036126 [Bug 2036126] Please branch and build perl-Web-Scraper for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036125 ___ 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 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036122 Paul Howarth changed: What|Removed |Added Blocks||2036126 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036126 [Bug 2036126] Please branch and build perl-Web-Scraper for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036122 ___ 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 2036123] Please branch and build perl-HTML-Selector-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036123 Paul Howarth changed: What|Removed |Added Blocks||2036126 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036126 [Bug 2036126] Please branch and build perl-Web-Scraper for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036123 ___ 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 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036118 Paul Howarth changed: What|Removed |Added Blocks||2036126 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036126 [Bug 2036126] Please branch and build perl-Web-Scraper for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036118 ___ 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 2036126] Please branch and build perl-Web-Scraper for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036126 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Depends On||2036123, 2036125, 2036122, ||2036118 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036118 [Bug 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2036122 [Bug 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2036123 [Bug 2036123] Please branch and build perl-HTML-Selector-XPath for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2036125 [Bug 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036126 ___ 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 2036126] New: Please branch and build perl-Web-Scraper for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036126 Bug ID: 2036126 Summary: Please branch and build perl-Web-Scraper for EPEL-8 Product: Fedora Version: rawhide Status: NEW Component: perl-Web-Scraper Assignee: rc040...@freenet.de Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Could you please branch and build perl-Web-Scraper for EPEL-8 ? If you prefer, you could add me (FAS: pghmcfc) as a committer and I'll do it myself. I'll probably want this for EPEL-9 eventually too (dependency of perl-Finance-Quote). -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036126 ___ 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 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036122 Paul Howarth changed: What|Removed |Added Blocks||2036125 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036125 [Bug 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036122 ___ 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 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036118 Paul Howarth changed: What|Removed |Added Blocks||2036125 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036125 [Bug 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036118 ___ 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 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML
https://bugzilla.redhat.com/show_bug.cgi?id=2036125 Paul Howarth changed: What|Removed |Added Depends On||2036122, 2036118 Doc Type|--- |If docs needed, set a value Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036118 [Bug 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2036122 [Bug 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036125 ___ 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 2036125] New: Please branch and build perl-HTML-TreeBuilder-LibXML
https://bugzilla.redhat.com/show_bug.cgi?id=2036125 Bug ID: 2036125 Summary: Please branch and build perl-HTML-TreeBuilder-LibXML Product: Fedora Version: rawhide Status: NEW Component: perl-HTML-TreeBuilder-LibXML Assignee: emman...@seyman.fr Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Could you please branch and build perl-HTML-TreeBuilder-LibXML for EPEL-8 ? If you prefer, you could add me (FAS: pghmcfc) as a committer and I'll do it myself. I'll probably want this for EPEL-9 eventually too (dependency of perl-Finance-Quote). -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036125 ___ 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 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036122 Paul Howarth changed: What|Removed |Added Blocks||2036123 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036123 [Bug 2036123] Please branch and build perl-HTML-Selector-XPath for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036122 ___ 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 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036118 Paul Howarth changed: What|Removed |Added Blocks||2036123 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036123 [Bug 2036123] Please branch and build perl-HTML-Selector-XPath for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036118 ___ 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 2036123] Please branch and build perl-HTML-Selector-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036123 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Depends On||2036122, 2036118 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036118 [Bug 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2036122 [Bug 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036123 ___ 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 2036123] New: Please branch and build perl-HTML-Selector-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036123 Bug ID: 2036123 Summary: Please branch and build perl-HTML-Selector-XPath for EPEL-8 Product: Fedora Version: rawhide Status: NEW Component: perl-HTML-Selector-XPath Assignee: rc040...@freenet.de Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Could you please branch and build perl-HTML-Selector-XPath for EPEL-8 ? If you prefer, you could add me (FAS: pghmcfc) as a committer and I'll do it myself. I'll probably want this for EPEL-9 eventually too (dependency of perl-Finance-Quote). -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036123 ___ 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 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036118 Paul Howarth changed: What|Removed |Added Blocks||2036122 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036122 [Bug 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036118 ___ 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 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036122 Paul Howarth changed: What|Removed |Added Depends On||2036118 Doc Type|--- |If docs needed, set a value Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2036118 [Bug 2036118] Please branch and build perl-XML-XPathEngine for EPEL-8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036122 ___ 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 2036122] New: Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036122 Bug ID: 2036122 Summary: Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8 Product: Fedora Version: rawhide Status: NEW Component: perl-HTML-TreeBuilder-XPath Assignee: emman...@seyman.fr Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Could you please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8 ? If you prefer, you could add me (FAS: pghmcfc) as a committer and I'll do it myself. I'll probably want this for EPEL-9 eventually too (dependency of perl-Finance-Quote). -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036122 ___ 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
F-ExcludeArhc-aarch64 tracker closed?
Hi, Looks like of all the architecture build failures tracking bugs listed in https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures, the aarch64 one is currently closed: https://bugzilla.redhat.com/show_bug.cgi?id=922257 Looks like at some point all bugs are indeed closed, but there are now four bugs listed against it. Should the status go back to NEW? Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2036118] New: Please branch and build perl-XML-XPathEngine for EPEL-8
https://bugzilla.redhat.com/show_bug.cgi?id=2036118 Bug ID: 2036118 Summary: Please branch and build perl-XML-XPathEngine for EPEL-8 Product: Fedora Version: rawhide Status: NEW Component: perl-XML-XPathEngine Assignee: jples...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: a...@biosysanalytics.com, jples...@redhat.com, mbo...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Could you please branch and build perl-XML-XPathEngine for EPEL-8 ? If you prefer, you could add me (FAS: pghmcfc) as a committer and I'll do it myself. I'll probably want this for EPEL-9 eventually too (dependency of perl-Finance-Quote). -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2036118 ___ 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 12:48 PM Gordon Messmer wrote: > > On 12/29/21 07:26, Vitaly Zaitsev via devel wrote: > > On 29/12/2021 16:01, Ben Cotton wrote: > >> Currently, the RPM databases is located in `/var`. Let's move it to > >> `/usr`. The move is already under way in rpm-ostree-based > >> installations, and in (open)SUSE. > > > > It will break FHS compatibility. /usr must contain read-only data. > > > If /usr really is read-only, then it probably doesn't matter where the > rpmdb is, since packages can't be installed (generally). There are plenty of packages which do not write to /usr/, especially third party add-ons over in /opt/ . ___ 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 Wed, Dec 29, 2021 at 1:35 PM Neal Gompa wrote: > > On Wed, Dec 29, 2021 at 11:03 AM Stephen Snow wrote: > > > > On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote: > > > With Windows 11, they're *mandatory*. Corporate policies now > > > effectively *require* TPM-based mechanisms *in addition* to classical > > > password or token-based multi-factor authentication. > > This certainly is not any reason to adopt this for Fedora. So far in my > > life with TPM, it has been an annoyance that I find refreshing not to > > have to even contemplate with my Fedora Linux installation. > > I see no benefit for the Fedora Community and the Fedora Project it > > supports to follow the lead of the proprietary driven objectives. The > > only obvious one that comes to mind is the recent announcements of it's > > inclusion on traditionally proprietary OS vendor supplied hardware. > > This wreaks of "for profit" motivation. > > > > Just my opinion on what I am reading here in the comments. > > To be fully transparent, the reason I mentioned that stuff is that > having the capability to do these things in Fedora Linux is key for > growth and adoption in more circles. At no point do I want to have > these features implemented in such a way that the user doesn't have > the capability to control and self-authenticate their whole system. If > we ever want Fedora Linux to displace Windows or macOS, we *need* to > be able to satisfy people's security requirements, including so-called > "zero trust" architectures. > > But none of that has much to do with this Change, since this is about > making it possible for a user to configure their system to enforce the > integrity of the system based on RPM database information. As users of > Fedora Linux systems, we *already* control the RPM database and the > RPM signature trust directly, so *if* you turn it on, all it does is > decrease the risk of external tampering. I'm staring at the introduction letter at: https://lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sa...@huawei.com/ RPM headers are a *possible* use. I'd expect this to be used, very quickly, for other signed metadata for less benign uses. ___ 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: New tool - license-validate
Dne 29. 12. 21 v 17:22 Artur Frenszek-Iwicki napsal(a): My personal suggestion would be to add a "line by line" mode for interactive usage, so instead of: K.I.S.S. I always start with tool which can handle one item. And then built large tool on top of it. $ license-validate --verbose "First" $ license-validate --verbose "Second" one could do something like: $ license-validate --stdin < licenses.txt Here it is: https://pagure.io/copr/license-validate/blob/main/f/download-all-fedora-licenses https://pagure.io/copr/license-validate/blob/main/f/check-all-licenses Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On 12/29/21 09:59, Stephen John Smoogen wrote: The modern day case where /usr is read-only is inside a container and you put an overlay or using some sort of linking to /var which is read-write in case of reboots. Right, that makes sense. To me this is like saying 'move everything into /usr but because its volitile move it back into /var but in a sub-directory from where it was so you can keep an image running.' In this case, this doesn't sound like any savings and more of a headache of why did it corrupt this time. But this doesn't. Why would you need to move the rpmdb? Users probably aren't installing rpm packages in containers at run time (particularly if /usr is read-only); installation typically happens when building the container image, at which point /usr isn't read-only. ___ 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 Wed, Dec 29, 2021 at 11:03 AM Stephen Snow wrote: > > On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote: > > With Windows 11, they're *mandatory*. Corporate policies now > > effectively *require* TPM-based mechanisms *in addition* to classical > > password or token-based multi-factor authentication. > This certainly is not any reason to adopt this for Fedora. So far in my > life with TPM, it has been an annoyance that I find refreshing not to > have to even contemplate with my Fedora Linux installation. > I see no benefit for the Fedora Community and the Fedora Project it > supports to follow the lead of the proprietary driven objectives. The > only obvious one that comes to mind is the recent announcements of it's > inclusion on traditionally proprietary OS vendor supplied hardware. > This wreaks of "for profit" motivation. > > Just my opinion on what I am reading here in the comments. To be fully transparent, the reason I mentioned that stuff is that having the capability to do these things in Fedora Linux is key for growth and adoption in more circles. At no point do I want to have these features implemented in such a way that the user doesn't have the capability to control and self-authenticate their whole system. If we ever want Fedora Linux to displace Windows or macOS, we *need* to be able to satisfy people's security requirements, including so-called "zero trust" architectures. But none of that has much to do with this Change, since this is about making it possible for a user to configure their system to enforce the integrity of the system based on RPM database information. As users of Fedora Linux systems, we *already* control the RPM database and the RPM signature trust directly, so *if* you turn it on, all it does is decrease the risk of external tampering. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
RE: F36 Change: DIGLIM (System-Wide Change proposal)
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com] > Sent: Wednesday, December 29, 2021 2:06 PM [...] > > With Windows 11, they're *mandatory*. Corporate policies now > > effectively *require* TPM-based mechanisms *in addition* to classical > > password or token-based multi-factor authentication. > > As often occurs with DRM. it's proven burdensome and there are > numerous published workarounds, including those published by > Microsoft. > > Can you point to a particular multi-factor authentication technology > that uses TPM? I'd not seen that in any server based setups, though I > could believe it exists for portable devices which support less > development. It's a problem partly because TPM puts private escrow > keys in the centralized hands, and the root keys to revoke other keys > in manufacturer's hands. The key management, and signature authority > management, is a problem. I'd be concerned at yet another attempt to > re-invent the security wheel, and secrete the wheel itself away in the > kernel without direct visibility to the user running or writing the > software. The TPM has a fundamental advantage, compared to other mechanisms. It is tamperproof, it often receives high-grade certifications, and it is one of the few components that you could rely on to protect your sensitive data in the event your host becomes compromised. The fact that the TPM might be used for DRM does not preclude its usage for the users themselves. The TPM technology is not meant to secrete the wheel, but rather the opposite. For example, it might help to detect tampering of audit logs by attackers trying to cover their tracks. The TPM has a very simple logic: record a security-relevant event before it happens, or do/release something if the system is in the condition I have myself defined. The TPM might not be even required if you like to enforce an IMA appraisal policy. The built-in and secondary keyrings in the kernel will act as your trust anchor. > > The difference between IMA/verity and DRM is that the former is under > > the system owner's control (in this case, *you*), and the latter is > > *not*. > > Since IMA is oriented to third party vendor keys, according to its own > documentation, I don't see how this would be. It would be easier, and > more visible, for signature validation and verification to occur in > userspace. There are old tools that attempted to provide such > validation for system files, such as "chkrootkit". and for which I've > provided up-to-date bundling. It would be a design problem. You cannot put a component at the same privilege level of the components you are defending against. > The work of signing and validating one's own data or software files is > so large, I don't see the benefit of embedding it in the kernel except > to enforce it for DRM use. > > > While Palladium as a whole hasn't *yet* made it, huge chunks of it > > has. Verified and measured boot mechanisms exist in Windows and macOS, > > remote and local attestation for integrity exist for Windows, and so > > on. Some of these features exist in Linux, but not all just yet. > > Nor should they, precisely for "free software" reasons. Palladium was > an attempt to provide a hardware verified, vendor signed stack from > boot to kernel to software to data files, all under the authority of > third-party generated signatures which could be revoked, at whim, by a > more root level authority, and which could be revoked or even turned > over from escrow at whim with no published procedure for when and how > such keys would be turned over. I'm concerned that these third-part > keys will suffer similar vulnerabilities. For IMA appraisal, there will be no keys in the kernel other than the ones your package manager uses to verify the integrity of the packages you install. Plus your own keys, if you wish. That would be sufficient to run any free software. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua ___ 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 2031801] perl-HTML-Template for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031801 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2021-739ea2e5e0 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-739ea2e5e0 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031801 ___ 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 1811577] perl-Finance-Quote EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1811577 Gwyn Ciesla changed: What|Removed |Added CC||gw...@protonmail.com Blocks||1794161 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1794161 [Bug 1794161] Request to package gnucash for EPEL 8 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1811577 ___ 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: F36 Change: Default To Noto Fonts (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 12:27 PM Artem Tim wrote: > > Cantarell current default UI font in GNOME (Workstation) will be replaced by > Noto font as well or remain? The current plan is to keep Cantarell for now, though GNOME upstream may decide to switch to Noto as KDE Plasma did years ago. -- 真実はいつも一つ！/ 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
[Bug 1811624] [RFE] EPEL8 branch of perl-HTML-TableExtract
https://bugzilla.redhat.com/show_bug.cgi?id=1811624 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2021-3afd09548b has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-3afd09548b -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1811624 ___ 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 2031484] Please branch and build perl-Hash-Merge in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2031484 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-EPEL-2021-6f30e2081b has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6f30e2081b -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031484 ___ 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, 29 Dec 2021 at 12:49, Gordon Messmer wrote: > On 12/29/21 07:26, Vitaly Zaitsev via devel wrote: > > On 29/12/2021 16:01, Ben Cotton wrote: > >> Currently, the RPM databases is located in `/var`. Let's move it to > >> `/usr`. The move is already under way in rpm-ostree-based > >> installations, and in (open)SUSE. > > > > It will break FHS compatibility. /usr must contain read-only data. > > > If /usr really is read-only, then it probably doesn't matter where the > rpmdb is, since packages can't be installed (generally). > > The modern day case where /usr is read-only is inside a container and you put an overlay or using some sort of linking to /var which is read-write in case of reboots. To me this is like saying 'move everything into /usr but because its volitile move it back into /var but in a sub-directory from where it was so you can keep an image running.' In this case, this doesn't sound like any savings and more of a headache of why did it corrupt this time. Looking at my /var/lib in F35, the __db.*** files seems to get written to regularly but I am not sure why. That would probably be something to track down and remove from images afterwards. > Moreover, for systems where /usr is read-only and/or shared (especially > stateless systems), having the rpmdb on /usr seems like the most > rational place for it, if one expects to be able to use rpm to query the > package list. Otherwise, there is an implicit coupling of /usr and > /var/lib/rpmdb that requires two mounts rather than one. > ___ > 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 12:48 PM Gordon Messmer wrote: > > On 12/29/21 07:26, Vitaly Zaitsev via devel wrote: > > On 29/12/2021 16:01, Ben Cotton wrote: > >> Currently, the RPM databases is located in `/var`. Let's move it to > >> `/usr`. The move is already under way in rpm-ostree-based > >> installations, and in (open)SUSE. > > > > It will break FHS compatibility. /usr must contain read-only data. > > > If /usr really is read-only, then it probably doesn't matter where the > rpmdb is, since packages can't be installed (generally). > > Moreover, for systems where /usr is read-only and/or shared (especially > stateless systems), having the rpmdb on /usr seems like the most > rational place for it, if one expects to be able to use rpm to query the > package list. Otherwise, there is an implicit coupling of /usr and > /var/lib/rpmdb that requires two mounts rather than one. Bingo. It's generally accepted that the RPM database changes when the system state changes. And if the system state is not allowed to change, the rpmdb should not either. The bigger problem is that having the RPM database in /var makes it much harder to correctly implement a boot-to-snapshot scheme for Fedora Linux that reasonably maintains system state properly once /var is carved out. The reason that /var *isn't* carved out by default with our Btrfs configuration is because of the RPM database. Once the RPM database is moved, it becomes possible to split /var into its own subvolume and make it trivial to configure a full boot-to-snapshot system leveraging the technologies we have available to us. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On 12/29/21 07:26, Vitaly Zaitsev via devel wrote: On 29/12/2021 16:01, Ben Cotton wrote: Currently, the RPM databases is located in `/var`. Let's move it to `/usr`. The move is already under way in rpm-ostree-based installations, and in (open)SUSE. It will break FHS compatibility. /usr must contain read-only data. If /usr really is read-only, then it probably doesn't matter where the rpmdb is, since packages can't be installed (generally). Moreover, for systems where /usr is read-only and/or shared (especially stateless systems), having the rpmdb on /usr seems like the most rational place for it, if one expects to be able to use rpm to query the package list. Otherwise, there is an implicit coupling of /usr and /var/lib/rpmdb that requires two mounts rather than one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)
Cantarell current default UI font in GNOME (Workstation) will be replaced by Noto font as well or remain? ___ 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: New tool - license-validate
On 29. 12. 21 13:42, Miroslav Suchý wrote: Dne 26. 12. 21 v 22:45 Matthew Miller napsal(a): On Sun, Dec 26, 2021 at 10:08:24PM +0100, Miroslav Suchý wrote: My next goal will be to download all Fedora's spec files, extract the license line and run it through this script. But I am going to be few days offline, so anyone who want step in QE shoes can do that - I will not be mad :) I would suggest holding off on that, as we are working on updating the guidelines to use SPDX identifiers (and therefore SPDX expressions). So far the deviations are mostly typos. So audit with currently used short names will easy the later transition. I have started doing the audit. All the deviation will be tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=2035991 Wouldn't it be faster to submit pull requests instead of buzgillas when the fix is obvious? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)
Hello,
On Wed, Dec 29, 2021 at 4:04 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
>
> == Summary ==
> Changing the default fonts for various languages to Noto Fonts as much
> as possible, to make consistency on the text rendering.
>
> == Owner ==
> * Name: [[User:Tagoh|Akira TAGOH]]
> * Email:
>
>
> == Detailed Description ==
> For a long time we have used DejaVu fonts as the default font for
> European and other language scripts. On the other hand some language
> scripts are not covered by DejaVu and hence have other default fonts.
> (A few languages like Chinese, Japanese and Korean, as well as
> Gurmukhi, Sinhala, and emoji are already using Noto fonts by default
> for some time.) This situation leads to inconsistencies in text
> rendering on applications and desktops, particularly when mixing
> different character sets. Further Noto fonts bring some further
> advantages: the fonts are generally higher quality and support
> variable fonts for most scripts, making them more compact.
>
> This change aims to provide better experience and consistent text
> rendering across more languages by replacing DejaVu with Noto as the
> general system default set of fonts.
>
> The following packages will be installed by default to replace
> DejaVu's coverage:
> * google-noto-sans-vf-fonts
> * google-noto-serif-vf-fonts
> * google-noto-sans-mono-vf-fonts
> * google-noto-sans-arabic-vf-fonts
> * google-noto-sans-cherokee-vf-fonts
> * google-noto-sans-thaana-vf-fonts
> * google-noto-sans-hebrew-vf-fonts
> * google-noto-rashi-hebrew-vf-fonts
> * google-noto-sans-math-vf-fonts
> * google-noto-sans-armenian-vf-fonts
> * google-noto-serif-armenian-vf-fonts
> * google-noto-sans-canadian-aboriginal-vf-fonts
> * google-noto-sans-georgian-vf-fonts
> * google-noto-serif-georgian-vf-fonts
> * google-noto-sans-lao-vf-fonts
> * google-noto-serif-lao-vf-fonts
> * google-noto-serif-gurmukhi-vf-fonts
> * google-noto-serif-sinhala-vf-fonts
Will all of them be installed by default or depending on langpacks selection?
> And you can check
> [https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to
> see what languages will be affected by this change.
>
>
> == Benefit to Fedora ==
> We would get better text rendering on applications and desktops. Also
> this change should save about 6MB on the fresh install.
>
>
> $ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts
> | awk 'BEGIN{a=0}{a+=$5}END{print a}'
> 10789272
>
> $ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts
> google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts
> google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts
> google-noto
> -sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts
> google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f
> onts google-noto-serif-armenian-vf-fonts
> google-noto-sans-canadian-aboriginal-vf-fonts
> google-noto-sans-georgian-vf-f
> onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts
> google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts
> google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print
> a}'
> 4753340
>
>
> == Scope ==
> * Proposal owners:
> ** Update google-noto-fonts and dejavu-fonts to change the priority
> for fontconfig config.
> ** Update langpacks to update the dependency.
> ** Update comps to make Noto fonts default.
> ** Update lorax templates related to DejaVu.
> ** Update fontconfig to change the order of fonts in the builtin config.
>
> * Other developers:
> ** Packagers who owns packages implicitly expects DejaVu is installed
> by default will needs to update the dependency for them.
>
> * Release engineering: [https://pagure.io/releng/issue/10492 #10492]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
>
> == Upgrade/compatibility impact ==
> The migration will be done by updating langpacks. after upgrading and
> rebooting, the default font will be Noto instead of DejaVu.
Is it safe to delete DejaVu fonts assuming they are not used by any known app?
> Since this change aims to switch non-variable fonts to variable fonts,
> it may not works with legacy applications as expected such as missing
> some variants. in that case, you can install non-variable fonts
> packages. the package name will be similar and simply drop `-vf` from
> the variable fonts packages.
>
>
> == How To Test ==
> * This change can be simply tested by `fc-match` command like
> `fc-match sans:lang=`, `fc-match serif:lang= language>` and `fc-match monospace:lang=`. You can
> check the expected result from
> [https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table].
> * Test the text rendering in your favorite application, which use the
> system default font.
I think this paragraph explains how to test already applied change,
but not really how to "test it before it lands"… Do
Re: New tool - license-validate
> I have created new tool license-validate: > https://pagure.io/copr/license-validate/ I've written something relatively similar a few years back (https://github.com/suve/vrms-rpm). I took a look at the code - using a proper parser is definitely a better solution than the error-prone, manual matching happening in my program. May be a good idea for some v3.0. ;) My personal suggestion would be to add a "line by line" mode for interactive usage, so instead of: > $ license-validate --verbose "First" > $ license-validate --verbose "Second" one could do something like: > $ license-validate --stdin < licenses.txt A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote: > With Windows 11, they're *mandatory*. Corporate policies now > effectively *require* TPM-based mechanisms *in addition* to classical > password or token-based multi-factor authentication. This certainly is not any reason to adopt this for Fedora. So far in my life with TPM, it has been an annoyance that I find refreshing not to have to even contemplate with my Fedora Linux installation. I see no benefit for the Fedora Community and the Fedora Project it supports to follow the lead of the proprietary driven objectives. The only obvious one that comes to mind is the recent announcements of it's inclusion on traditionally proprietary OS vendor supplied hardware. This wreaks of "for profit" motivation. Just my opinion on what I am reading here in the comments. Regards, Stephen Snow ___ 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, 29 Dec 2021 at 10:19, Tom Hughes via devel < devel@lists.fedoraproject.org> wrote: > I don't see how this is FHS compliant, which in turn would make > it non-compliant with Fedora Packaging Guidelines, namely: > > I am in agreement here and think that this is NOT a change to be made in F36 but needs to be worked through the proper channels of 'upstream'. Get the FHS updated and fixed, work out that the change actually is going to be stuck to in SuSE and not rolled back and then push it to Fedora. Also please realise that the community can eat only so many changes per release no matter how much you want to otherwise. You can probably get this OR the fs-verity in some future release, but not both in the same release and trying to fight for both is going to mean you get neither. In fact, at a certain point too many changes start making it that any CR with certain names attached will get derailed because people are sure there is some sort of agenda or conspiracy which they have to fight to stop. -- 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
[EPEL-devel] Re: Status of python-gevent in EL9
On Wed, 29 Dec 2021 at 10:19, Orion Poplawski wrote: > Can someone shed light on the status of python-gevent in EL9? It seems > to have been built for CS9: > > https://kojihub.stream.centos.org/koji/packageinfo?packageID=3414 > > (though perhaps not tagged?) > > but builds for EPEL9 fail to find it: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=80607754 > > This is a RHEL/CentOS Stream buildroot only package. It is only available in the koji buildroot and will not be shipped. An equivalent package will need to be built in EPEL to make builds work. > Thanks. > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > Manager of NWRA Technical Systems 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > ___ > 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 > -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On 29/12/2021 16:01, Ben Cotton wrote: Currently, the RPM databases is located in `/var`. Let's move it to `/usr`. The move is already under way in rpm-ostree-based installations, and in (open)SUSE. It will break FHS compatibility. /usr must contain read-only data. -- 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
[EPEL-devel] Status of python-gevent in EL9
Can someone shed light on the status of python-gevent in EL9? It seems to have been built for CS9: https://kojihub.stream.centos.org/koji/packageinfo?packageID=3414 (though perhaps not tagged?) but builds for EPEL9 fail to find it: https://koji.fedoraproject.org/koji/taskinfo?taskID=80607754 Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
I don't see how this is FHS compliant, which in turn would make it non-compliant with Fedora Packaging Guidelines, namely: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_filesystem_layout The FHS describes /usr here: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html#purpose18 as "/usr is shareable, read-only data" which clearly does not apply to a database that changes. While /var is described here: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05.html#purpose31 as "/var contains variable data files" which appears to exactly describe the RPM database. At this point somebody will no doubt argue that /usr changes on a package update and that the RPM database is a static definition of the currently installed OS files, but evidence says otherwise: % ls -l /var/lib/rpm total 378M -rw-r--r--. 1 root root 378M Dec 28 16:08 rpmdb.sqlite -rw-r--r--. 1 root root 32K Dec 29 09:27 rpmdb.sqlite-shm -rw-r--r--. 1 root root0 Dec 28 16:08 rpmdb.sqlite-wal While "Dec 28 16:08" is indeed the last time I updated that machine it seems one of the files has changed more recently - no idea what triggered that but clearly the files are not static between updates. Tom On 29/12/2021 15:01, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr == Summary == Currently, the RPM databases is located in `/var`. Let's move it to `/usr`. The move is already under way in rpm-ostree-based installations, and in (open)SUSE. == Owner == * Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel Alexandre Salim]], [[User:Ngompa|Neal Gompa]] * Email: bugzi...@colorremedies.com, mic...@michel-slm.name, ngomp...@gmail.com == Detailed Description == === Current location === /var/lib/rpm === New location === /usr/lib/sysimage/rpm /var/lib/rpm will be a symlink pointing to /usr/lib/sysimage/rpm Changing the file system layout to accommodate a snapshot+rollback regime is implied, but not required by this proposal. For example, Fedora has long placed `/home` on a separate subvolume (or file system) so it can be isolated from system root. Likewise, it makes sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so these locations continue to carry forward in time, even if the system root does a rollback. == Feedback == There will be no change to DNF as part of this change proposal. DNF's history will remain in `/var` until DNF 5. Discussion continues about the effect of a snapshot+rollback regime on DNF history. [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html Relocate DNF history to /usr.] Upstream RPM accept the change, but institutionally don't like the loss or weakening of a [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html very well known location] for the database, and [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html anticipate complaints]. == Benefit to Fedora == * The RPM database primarily describes the state of `/usr`. Storing the databases in `/usr` will more easily facilitate OS rollback, without affecting `/var`. * Helps align Fedora variants with each other ** rpm-ostree based systems (including CoreOS, IoT, Silverblue, Kinoite) already use `/usr/lib/sysimage` for rpmdb. * Consistency with another RPM-based distro, (open)SUSE has made this change * Accounts for various snapshot+rollback regimes, i.e. it's a beneficial change whether Btrfs or device-mapper based regimes. == Scope == * Proposal owners: ** changes in rpm package *** create the new path *** create a symlink for the old path pointing to new path * Other developers: ** changes in SElinux policy * Release engineering: [https://pagure.io/releng/issue/10441 #Releng issue 10441] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == 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. # Create `/usr/lib/sysimage/rpm` (rpm package will do this at preinst) # Create symlinks in `/usr/lib/sysimage/rpm/` pointing to files in `/var/lib/rpm/` (rpm package will do this at preinst) # Change the dbpath in `/usr/lib/rpm/macros` to `/usr/lib/sysimage/rpm` (rpm package will be patched to do this on F36+) # Request rpm rebuild the database (done via systemd service) # Remove `/var/lib/rpm` and create a symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm` (done via systemd service) == How To Test == # Perform a new clean install, or upgrade a system # Check that `/var/lib/rpm` is a symlink to `/usr/lib/sysimage/rpm` # Check that `/usr/lib/sysimage/rpm` is populated with at least `rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and `rpmdb.sqlite-wal` # Confirm `rpm -q ` and/or `rpm -qa` still work == User Experience == * symlink `/var/lib/rpm` ->
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, Dec 29, 2021 at 3:03 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr > > == Summary == > Currently, the RPM databases is located in `/var`. Let's move it to > `/usr`. The move is already under way in rpm-ostree-based > installations, and in (open)SUSE. How does this work on RO /usr files systems? I thought data in /usr was supposed to be static/ It works for rpm-ostree because it's updated at tree creation time. > == Owner == > * Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel > Alexandre Salim]], [[User:Ngompa|Neal Gompa]] > * Email: bugzi...@colorremedies.com, mic...@michel-slm.name, > ngomp...@gmail.com > > > == Detailed Description == > === Current location === > /var/lib/rpm > > === New location === > /usr/lib/sysimage/rpm > > /var/lib/rpm will be a symlink pointing to > /usr/lib/sysimage/rpm > > Changing the file system layout to accommodate a snapshot+rollback > regime is implied, but not required by this proposal. For example, > Fedora has long placed `/home` on a separate subvolume (or file > system) so it can be isolated from system root. Likewise, it makes > sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so > these locations continue to carry forward in time, even if the system > root does a rollback. > > == Feedback == > > There will be no change to DNF as part of this change proposal. DNF's > history will remain in `/var` until DNF 5. Discussion continues about > the effect of a snapshot+rollback regime on DNF history. > [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html > Relocate DNF history to /usr.] > > Upstream RPM accept the change, but institutionally don't like the > loss or weakening of a > [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html > very well known location] for the database, and > [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html > anticipate complaints]. > > > == Benefit to Fedora == > > * The RPM database primarily describes the state of `/usr`. Storing > the databases in `/usr` will more easily facilitate OS rollback, > without affecting `/var`. > > * Helps align Fedora variants with each other > ** rpm-ostree based systems (including CoreOS, IoT, Silverblue, > Kinoite) already use `/usr/lib/sysimage` for rpmdb. > > * Consistency with another RPM-based distro, (open)SUSE has made this change > > * Accounts for various snapshot+rollback regimes, i.e. it's a > beneficial change whether Btrfs or device-mapper based regimes. > > > == Scope == > * Proposal owners: > ** changes in rpm package > *** create the new path > *** create a symlink for the old path pointing to new path > > * Other developers: > ** changes in SElinux policy > > * Release engineering: [https://pagure.io/releng/issue/10441 #Releng > issue 10441] > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > == 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. > > # Create `/usr/lib/sysimage/rpm` (rpm package will do this at preinst) > # Create symlinks in `/usr/lib/sysimage/rpm/` pointing to files in > `/var/lib/rpm/` (rpm package will do this at preinst) > # Change the dbpath in `/usr/lib/rpm/macros` to > `/usr/lib/sysimage/rpm` (rpm package will be patched to do this on > F36+) > # Request rpm rebuild the database (done via systemd service) > # Remove `/var/lib/rpm` and create a symlink `/var/lib/rpm` -> > `/usr/lib/sysimage/rpm` (done via systemd service) > > > == How To Test == > > # Perform a new clean install, or upgrade a system > # Check that `/var/lib/rpm` is a symlink to `/usr/lib/sysimage/rpm` > # Check that `/usr/lib/sysimage/rpm` is populated with at least > `rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and > `rpmdb.sqlite-wal` > # Confirm `rpm -q ` and/or `rpm -qa` still work > > == User Experience == > > * symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm` > > Otherwise, the change should be invisible to users. > > == Dependencies == > * `rpm-ostree` probably should make `/usr/share/rpm` a symlink to > `/usr/lib/sysimage/rpm`, rather than the reverse as it is currently. > * `PackageKit` might use inotify on `/var/lib/rpm` need to check if it > does and whether it should be changed or add the additional path > > > == Contingency Plan == > * Contingency mechanism: Revert the change, try again the next Fedora release. > * Contingency deadline: Beta freeze > * Blocks release? Yes > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct:
[EPEL-devel] Re: Packages disappearing from the EPEL 9 buildroot
On Wed, 29 Dec 2021 at 06:29, Mattias Ellert wrote: > Hi! > > Two packages I built for EPEL 9 are now reported by koschei as having > missing build dependencies. > > https://koschei.fedoraproject.org/package/davix?collection=epel9 > > https://koschei.fedoraproject.org/package/uglify-js?collection=epel9 > > The EPEL 9 builds were built using the following build dependencies > according to the root.log files: > > rapidjson-devel-1.1.0-19.el9 > > web-assets-devel-5-15.el9 > nodejs-packaging-2021.01-5.el9 > > These can no longer be found in the koji buildroot. There are no > expired buildroot overrides for these builds, which could explain the > disappearance. > > I can't find these builds in EPEL's koji, so I guess they where > provided by RHEL, but now are no longer? Did RHEL dop these? > > OK there was a period in the EPEL-9 startup where the buildroot was pointing to a copy of the CentOS Stream-9 koji build root. This was done to help kickstart things, but it had the issue that packages that RHEL is not going to ship to customers were available also. About 2-3 weeks ago, the EPEL steering committee decided to move the buildroot to the properly shipped chain of packages in CentOS Stream versus the buildroot. This removed a bunch of packages that were 'available' but not going to be shipped. These packages will need to be made into epel-only packages or some other solution. I am fuzzy on this myself as I am from a different philosophy school of building and shipping packages. > Mattias > > ___ > 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 > -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr == Summary == Currently, the RPM databases is located in `/var`. Let's move it to `/usr`. The move is already under way in rpm-ostree-based installations, and in (open)SUSE. == Owner == * Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel Alexandre Salim]], [[User:Ngompa|Neal Gompa]] * Email: bugzi...@colorremedies.com, mic...@michel-slm.name, ngomp...@gmail.com == Detailed Description == === Current location === /var/lib/rpm === New location === /usr/lib/sysimage/rpm /var/lib/rpm will be a symlink pointing to /usr/lib/sysimage/rpm Changing the file system layout to accommodate a snapshot+rollback regime is implied, but not required by this proposal. For example, Fedora has long placed `/home` on a separate subvolume (or file system) so it can be isolated from system root. Likewise, it makes sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so these locations continue to carry forward in time, even if the system root does a rollback. == Feedback == There will be no change to DNF as part of this change proposal. DNF's history will remain in `/var` until DNF 5. Discussion continues about the effect of a snapshot+rollback regime on DNF history. [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html Relocate DNF history to /usr.] Upstream RPM accept the change, but institutionally don't like the loss or weakening of a [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html very well known location] for the database, and [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html anticipate complaints]. == Benefit to Fedora == * The RPM database primarily describes the state of `/usr`. Storing the databases in `/usr` will more easily facilitate OS rollback, without affecting `/var`. * Helps align Fedora variants with each other ** rpm-ostree based systems (including CoreOS, IoT, Silverblue, Kinoite) already use `/usr/lib/sysimage` for rpmdb. * Consistency with another RPM-based distro, (open)SUSE has made this change * Accounts for various snapshot+rollback regimes, i.e. it's a beneficial change whether Btrfs or device-mapper based regimes. == Scope == * Proposal owners: ** changes in rpm package *** create the new path *** create a symlink for the old path pointing to new path * Other developers: ** changes in SElinux policy * Release engineering: [https://pagure.io/releng/issue/10441 #Releng issue 10441] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == 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. # Create `/usr/lib/sysimage/rpm` (rpm package will do this at preinst) # Create symlinks in `/usr/lib/sysimage/rpm/` pointing to files in `/var/lib/rpm/` (rpm package will do this at preinst) # Change the dbpath in `/usr/lib/rpm/macros` to `/usr/lib/sysimage/rpm` (rpm package will be patched to do this on F36+) # Request rpm rebuild the database (done via systemd service) # Remove `/var/lib/rpm` and create a symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm` (done via systemd service) == How To Test == # Perform a new clean install, or upgrade a system # Check that `/var/lib/rpm` is a symlink to `/usr/lib/sysimage/rpm` # Check that `/usr/lib/sysimage/rpm` is populated with at least `rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and `rpmdb.sqlite-wal` # Confirm `rpm -q ` and/or `rpm -qa` still work == User Experience == * symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm` Otherwise, the change should be invisible to users. == Dependencies == * `rpm-ostree` probably should make `/usr/share/rpm` a symlink to `/usr/lib/sysimage/rpm`, rather than the reverse as it is currently. * `PackageKit` might use inotify on `/var/lib/rpm` need to check if it does and whether it should be changed or add the additional path == Contingency Plan == * Contingency mechanism: Revert the change, try again the next Fedora release. * Contingency deadline: Beta freeze * Blocks release? Yes -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change == Summary == Update Hunspell Dictionary system directory from /usr/share/myspell/ to /usr/share/hunspell/ == Owner == * Name: [[User:vishalvvr| Vishal Vijayraghavan]] * Email: == Detailed Description == In most of Linux distributions the standard Hunspell dictionary path is `/usr/share/hunspell/` but in Fedora still has `/usr/share/myspell/`. This effort is to follow default standard to install all Hunspell dictionary into `/usr/share/hunspell/` instead of `/usr/share/myspell/`. == Benefit to Fedora == This will future proof Fedora to use the correct current location for hunspell spelling dictionaries. == Scope == * Proposal owners: In total there are `135` packages which is to be updated. libreoffice & Firefox are the two main applications and rest are mostly language dictionary packages. * Other developers: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == 1. Check if default installed dictionary path is `/usr/share/hunspell/` instead of `/usr/share/myspell/` `$ hunspell -D` or `$ ls /usr/share/hunspell/` 2. Install any language dictionary and check if it getting installed into '/usr/share/hunspell/' `$ dnf install hunspell-hi` `$ hunspell -D` == User Experience == User should not notice any difference: their applications should continue to work as expected after this directory migration. == Dependencies == == Contingency Plan == * Contingency mechanism: revert release back to /usr/share/myspell * Contingency deadline: Beta * Blocks release? No -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
F36 Change: Default To Noto Fonts (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
== Summary ==
Changing the default fonts for various languages to Noto Fonts as much
as possible, to make consistency on the text rendering.
== Owner ==
* Name: [[User:Tagoh|Akira TAGOH]]
* Email:
== Detailed Description ==
For a long time we have used DejaVu fonts as the default font for
European and other language scripts. On the other hand some language
scripts are not covered by DejaVu and hence have other default fonts.
(A few languages like Chinese, Japanese and Korean, as well as
Gurmukhi, Sinhala, and emoji are already using Noto fonts by default
for some time.) This situation leads to inconsistencies in text
rendering on applications and desktops, particularly when mixing
different character sets. Further Noto fonts bring some further
advantages: the fonts are generally higher quality and support
variable fonts for most scripts, making them more compact.
This change aims to provide better experience and consistent text
rendering across more languages by replacing DejaVu with Noto as the
general system default set of fonts.
The following packages will be installed by default to replace
DejaVu's coverage:
* google-noto-sans-vf-fonts
* google-noto-serif-vf-fonts
* google-noto-sans-mono-vf-fonts
* google-noto-sans-arabic-vf-fonts
* google-noto-sans-cherokee-vf-fonts
* google-noto-sans-thaana-vf-fonts
* google-noto-sans-hebrew-vf-fonts
* google-noto-rashi-hebrew-vf-fonts
* google-noto-sans-math-vf-fonts
* google-noto-sans-armenian-vf-fonts
* google-noto-serif-armenian-vf-fonts
* google-noto-sans-canadian-aboriginal-vf-fonts
* google-noto-sans-georgian-vf-fonts
* google-noto-serif-georgian-vf-fonts
* google-noto-sans-lao-vf-fonts
* google-noto-serif-lao-vf-fonts
* google-noto-serif-gurmukhi-vf-fonts
* google-noto-serif-sinhala-vf-fonts
And you can check
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to
see what languages will be affected by this change.
== Benefit to Fedora ==
We would get better text rendering on applications and desktops. Also
this change should save about 6MB on the fresh install.
$ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts
| awk 'BEGIN{a=0}{a+=$5}END{print a}'
10789272
$ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts
google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts
google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts
google-noto
-sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts
google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f
onts google-noto-serif-armenian-vf-fonts
google-noto-sans-canadian-aboriginal-vf-fonts
google-noto-sans-georgian-vf-f
onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts
google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts
google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print
a}'
4753340
== Scope ==
* Proposal owners:
** Update google-noto-fonts and dejavu-fonts to change the priority
for fontconfig config.
** Update langpacks to update the dependency.
** Update comps to make Noto fonts default.
** Update lorax templates related to DejaVu.
** Update fontconfig to change the order of fonts in the builtin config.
* Other developers:
** Packagers who owns packages implicitly expects DejaVu is installed
by default will needs to update the dependency for them.
* Release engineering: [https://pagure.io/releng/issue/10492 #10492]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The migration will be done by updating langpacks. after upgrading and
rebooting, the default font will be Noto instead of DejaVu.
Since this change aims to switch non-variable fonts to variable fonts,
it may not works with legacy applications as expected such as missing
some variants. in that case, you can install non-variable fonts
packages. the package name will be similar and simply drop `-vf` from
the variable fonts packages.
== How To Test ==
* This change can be simply tested by `fc-match` command like
`fc-match sans:lang=`, `fc-match serif:lang=` and `fc-match monospace:lang=`. You can
check the expected result from
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table].
* Test the text rendering in your favorite application, which use the
system default font.
== User Experience ==
Users will see the default font is changed to Noto by this change
except for some languages which has much better quality of fonts.
== Dependencies ==
Only dejavu-fonts, langpacks, and fontconfig are required to update.
Other packages which explicitly has a dependency to dejavu-fonts are
basicaly optional to update.
== Contingency Plan ==
* Contingency mechanism: Revert the relevant packages updated.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None.
== Release Notes ==
The default fonts for
F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr == Summary == Currently, the RPM databases is located in `/var`. Let's move it to `/usr`. The move is already under way in rpm-ostree-based installations, and in (open)SUSE. == Owner == * Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel Alexandre Salim]], [[User:Ngompa|Neal Gompa]] * Email: bugzi...@colorremedies.com, mic...@michel-slm.name, ngomp...@gmail.com == Detailed Description == === Current location === /var/lib/rpm === New location === /usr/lib/sysimage/rpm /var/lib/rpm will be a symlink pointing to /usr/lib/sysimage/rpm Changing the file system layout to accommodate a snapshot+rollback regime is implied, but not required by this proposal. For example, Fedora has long placed `/home` on a separate subvolume (or file system) so it can be isolated from system root. Likewise, it makes sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so these locations continue to carry forward in time, even if the system root does a rollback. == Feedback == There will be no change to DNF as part of this change proposal. DNF's history will remain in `/var` until DNF 5. Discussion continues about the effect of a snapshot+rollback regime on DNF history. [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html Relocate DNF history to /usr.] Upstream RPM accept the change, but institutionally don't like the loss or weakening of a [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html very well known location] for the database, and [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html anticipate complaints]. == Benefit to Fedora == * The RPM database primarily describes the state of `/usr`. Storing the databases in `/usr` will more easily facilitate OS rollback, without affecting `/var`. * Helps align Fedora variants with each other ** rpm-ostree based systems (including CoreOS, IoT, Silverblue, Kinoite) already use `/usr/lib/sysimage` for rpmdb. * Consistency with another RPM-based distro, (open)SUSE has made this change * Accounts for various snapshot+rollback regimes, i.e. it's a beneficial change whether Btrfs or device-mapper based regimes. == Scope == * Proposal owners: ** changes in rpm package *** create the new path *** create a symlink for the old path pointing to new path * Other developers: ** changes in SElinux policy * Release engineering: [https://pagure.io/releng/issue/10441 #Releng issue 10441] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == 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. # Create `/usr/lib/sysimage/rpm` (rpm package will do this at preinst) # Create symlinks in `/usr/lib/sysimage/rpm/` pointing to files in `/var/lib/rpm/` (rpm package will do this at preinst) # Change the dbpath in `/usr/lib/rpm/macros` to `/usr/lib/sysimage/rpm` (rpm package will be patched to do this on F36+) # Request rpm rebuild the database (done via systemd service) # Remove `/var/lib/rpm` and create a symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm` (done via systemd service) == How To Test == # Perform a new clean install, or upgrade a system # Check that `/var/lib/rpm` is a symlink to `/usr/lib/sysimage/rpm` # Check that `/usr/lib/sysimage/rpm` is populated with at least `rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and `rpmdb.sqlite-wal` # Confirm `rpm -q ` and/or `rpm -qa` still work == User Experience == * symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm` Otherwise, the change should be invisible to users. == Dependencies == * `rpm-ostree` probably should make `/usr/share/rpm` a symlink to `/usr/lib/sysimage/rpm`, rather than the reverse as it is currently. * `PackageKit` might use inotify on `/var/lib/rpm` need to check if it does and whether it should be changed or add the additional path == Contingency Plan == * Contingency mechanism: Revert the change, try again the next Fedora release. * Contingency deadline: Beta freeze * Blocks release? Yes -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change == Summary == Update Hunspell Dictionary system directory from /usr/share/myspell/ to /usr/share/hunspell/ == Owner == * Name: [[User:vishalvvr| Vishal Vijayraghavan]] * Email: == Detailed Description == In most of Linux distributions the standard Hunspell dictionary path is `/usr/share/hunspell/` but in Fedora still has `/usr/share/myspell/`. This effort is to follow default standard to install all Hunspell dictionary into `/usr/share/hunspell/` instead of `/usr/share/myspell/`. == Benefit to Fedora == This will future proof Fedora to use the correct current location for hunspell spelling dictionaries. == Scope == * Proposal owners: In total there are `135` packages which is to be updated. libreoffice & Firefox are the two main applications and rest are mostly language dictionary packages. * Other developers: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == 1. Check if default installed dictionary path is `/usr/share/hunspell/` instead of `/usr/share/myspell/` `$ hunspell -D` or `$ ls /usr/share/hunspell/` 2. Install any language dictionary and check if it getting installed into '/usr/share/hunspell/' `$ dnf install hunspell-hi` `$ hunspell -D` == User Experience == User should not notice any difference: their applications should continue to work as expected after this directory migration. == Dependencies == == Contingency Plan == * Contingency mechanism: revert release back to /usr/share/myspell * Contingency deadline: Beta * Blocks release? No -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: Default To Noto Fonts (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
== Summary ==
Changing the default fonts for various languages to Noto Fonts as much
as possible, to make consistency on the text rendering.
== Owner ==
* Name: [[User:Tagoh|Akira TAGOH]]
* Email:
== Detailed Description ==
For a long time we have used DejaVu fonts as the default font for
European and other language scripts. On the other hand some language
scripts are not covered by DejaVu and hence have other default fonts.
(A few languages like Chinese, Japanese and Korean, as well as
Gurmukhi, Sinhala, and emoji are already using Noto fonts by default
for some time.) This situation leads to inconsistencies in text
rendering on applications and desktops, particularly when mixing
different character sets. Further Noto fonts bring some further
advantages: the fonts are generally higher quality and support
variable fonts for most scripts, making them more compact.
This change aims to provide better experience and consistent text
rendering across more languages by replacing DejaVu with Noto as the
general system default set of fonts.
The following packages will be installed by default to replace
DejaVu's coverage:
* google-noto-sans-vf-fonts
* google-noto-serif-vf-fonts
* google-noto-sans-mono-vf-fonts
* google-noto-sans-arabic-vf-fonts
* google-noto-sans-cherokee-vf-fonts
* google-noto-sans-thaana-vf-fonts
* google-noto-sans-hebrew-vf-fonts
* google-noto-rashi-hebrew-vf-fonts
* google-noto-sans-math-vf-fonts
* google-noto-sans-armenian-vf-fonts
* google-noto-serif-armenian-vf-fonts
* google-noto-sans-canadian-aboriginal-vf-fonts
* google-noto-sans-georgian-vf-fonts
* google-noto-serif-georgian-vf-fonts
* google-noto-sans-lao-vf-fonts
* google-noto-serif-lao-vf-fonts
* google-noto-serif-gurmukhi-vf-fonts
* google-noto-serif-sinhala-vf-fonts
And you can check
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to
see what languages will be affected by this change.
== Benefit to Fedora ==
We would get better text rendering on applications and desktops. Also
this change should save about 6MB on the fresh install.
$ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts
| awk 'BEGIN{a=0}{a+=$5}END{print a}'
10789272
$ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts
google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts
google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts
google-noto
-sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts
google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f
onts google-noto-serif-armenian-vf-fonts
google-noto-sans-canadian-aboriginal-vf-fonts
google-noto-sans-georgian-vf-f
onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts
google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts
google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print
a}'
4753340
== Scope ==
* Proposal owners:
** Update google-noto-fonts and dejavu-fonts to change the priority
for fontconfig config.
** Update langpacks to update the dependency.
** Update comps to make Noto fonts default.
** Update lorax templates related to DejaVu.
** Update fontconfig to change the order of fonts in the builtin config.
* Other developers:
** Packagers who owns packages implicitly expects DejaVu is installed
by default will needs to update the dependency for them.
* Release engineering: [https://pagure.io/releng/issue/10492 #10492]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The migration will be done by updating langpacks. after upgrading and
rebooting, the default font will be Noto instead of DejaVu.
Since this change aims to switch non-variable fonts to variable fonts,
it may not works with legacy applications as expected such as missing
some variants. in that case, you can install non-variable fonts
packages. the package name will be similar and simply drop `-vf` from
the variable fonts packages.
== How To Test ==
* This change can be simply tested by `fc-match` command like
`fc-match sans:lang=`, `fc-match serif:lang=` and `fc-match monospace:lang=`. You can
check the expected result from
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table].
* Test the text rendering in your favorite application, which use the
system default font.
== User Experience ==
Users will see the default font is changed to Noto by this change
except for some languages which has much better quality of fonts.
== Dependencies ==
Only dejavu-fonts, langpacks, and fontconfig are required to update.
Other packages which explicitly has a dependency to dejavu-fonts are
basicaly optional to update.
== Contingency Plan ==
* Contingency mechanism: Revert the relevant packages updated.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None.
== Release Notes ==
The default fonts for
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On 29/12/2021 12:38, Neal Gompa wrote: Were they really? TPM devices*are* commonly used today to support attestation and multi-factor encryption and authentication mechanisms. In many ways, the trusted computing initiative was a success. And even virtualization is used for implementing trusted computing in some platforms. All hardware TPM implementations are proprietary. We can't trust them. -- 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: Rawhide builds failing for a while now
On Tue, Dec 28, 2021 at 1:19 PM Adam Williamson wrote: > > On Tue, 2021-12-28 at 20:03 +0100, Frantisek Zatloukal wrote: > > So, it seems it didn't come to my mind that builders might not have new > > enough rpm to use rpm.open() which is available since rpm 4.17.0. > > > > A fix for it ( > > https://src.fedoraproject.org/rpms/authselect/pull-request/15# ) has been > > merged, old authselect untagged, the new build of authselect should > > hopefully behave well now and builds of other packages should start working > > soon (after the local repo gets updated). > > The -5 build is done and in the buildroot now - Justin, can you re-try > the kernel build and see if it works now? Sorry for the trouble. My builds worked. Thanks Frantisek ___ 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)
> From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl] > Sent: Wednesday, December 29, 2021 2:36 PM > Hi, > > I'm still reading the discussion, so just a short meta-comment > on grammar: please don't use masculine forms to describe all Fedora > users, we're not all guys… > > On Tue, Dec 28, 2021 at 02:49:43PM +, Roberto Sassu via devel wrote: > > It could be even possible that a user installs > > his own GPG key (adequately protected), if he wants to sign > > customized software. > > …*their* own GPG key, if *they* want to to customized software… Hi Zbyszek thanks for pointing out. Will keep in mind for the next messages. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua ___ 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)
Hi, I'm still reading the discussion, so just a short meta-comment on grammar: please don't use masculine forms to describe all Fedora users, we're not all guys… On Tue, Dec 28, 2021 at 02:49:43PM +, Roberto Sassu via devel wrote: > It could be even possible that a user installs > his own GPG key (adequately protected), if he wants to sign > customized software. …*their* own GPG key, if *they* want to to customized software… 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
