[EPEL-devel] Re: Should we retire weechat from EPEL 7?
On Thu, Oct 06, 2022 at 07:11:19PM +0200, Neal Gompa wrote: > On Thu, Oct 6, 2022 at 7:03 PM Michel Alexandre Salim > wrote: > > > > Hi all, > > > > We should probably retire weechat from EPEL 7 - it has multiple CVEs > > that can only be fixed by updating to versions >= 3.5, but the spec no > > longer works on EPEL 7 thanks to macros like `%cmake_build` not being > > available. > > > > https://bugz.fedoraproject.org/weechat > > > > I'm not sure either Paul or myself really care enough about EL7 to > > maintain a divergent spec. If someone does still care, PR appreciated to > > fix this, otherwise consider this the first notice that I'll retire this > > branch in a few days. > > > > The cmake3 package has all the macros from the mainline cmake package in > Fedora. > > It should be fully compatible, just swap %cmake_* for %cmake3_*. > > Oh thanks, that works. We can keep this going for now then: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e8cd6275b1 -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads up! OpenImageIO 2.4 series coming to rawhide
On Thu, Oct 6, 2022 at 8:26 PM Luya Tshimbalanga wrote: > Send us the sidetag as Blender and openshadinglanguage need update. > You can use f38-build-side-59007 I've already built OIIO and wait-repo is done. I'll probably finish the builds tomorrow since it's getting late here. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads up! OpenImageIO 2.4 series coming to rawhide
Send us the sidetag as Blender and openshadinglanguage need update. Thanks. On 2022-10-06 18:14, Richard Shaw wrote: All builds will be done in a side tag. I don't expect any issues. I'd like to update f37 as well unless there are any objections. Thanks, Richard ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
fedpkg new-sources errors
I'm still getting this on occasion and have no idea what the issue is: $ fedpkg new-sources OpenImageIO-2.4.4.2.tar.gz Uploading: OpenImageIO-2.4.4.2.tar.gz # 52.0%Could not execute new_sources: (56, 'OpenSSL SSL_read: error:0A0003FC:SSL routines::sslv3 alert bad record mac, errno 0') Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads up! OpenImageIO 2.4 series coming to rawhide
All builds will be done in a side tag. I don't expect any issues. I'd like to update f37 as well unless there are any objections. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 Final blocker status update
The Go/No-Go for the early target date is Thursday. In order to be ready, we need blockers to be resolved by Tuesday at the latest. Action summary Accepted blockers - 1. abrt — Abrt does not report a segfault which is reported in journalctl. — ASSIGNED ACTION: QA to come up with a reproducer 2. anaconda — Installer Crashes When Attempting to Reclaim Space — ON_QA ACTION: QA to verify FEDORA-2022-2c9c1ebab5 3. glibc — glibc 2.36+ breaks EAC with removal of DT_HASH (and other game libraries), making games fail to load — POST ACTION: Maintainers to merge PR and build update 4. gnome-calendar — Month names are not in sync — VERIFIED ACTION: (none) 5. gnome-calendar — Editing recurring events is broken, changes a single instance instead of all instances — VERIFIED ACTION: (none) 6. gnome-calendar — Calendar does not delete events properly — VERIFIED ACTION: (none) 7. gnome-contacts — Editing an existing contact's email address causes Contacts to display an empty "Unnamed Person" card, other edits made at the same time are lost — ASSIGNED ACTION: upstream to diagnose and fix issue 8. gnome-contacts — Link Contacts feature completely broken — NEW ACTION: upstream to diagnose and fix issue 9. gnome-shell — On Screen Keyboard cannot type a space anywhere — NEW ACTION: upstream to diagnose and fix issue Proposed blockers - 1. gnome-calendar — Changes to recurring events don't redraw correctly — NEW ACTION: upstream to diagnose and fix issue 2. gnome-calendar — Editing a recurring event moves it forward in time — NEW ACTION: upstream to diagnose and fix issue 3. gnome-photos — Memory exhaustion when editing a cropped photo — NEW ACTION: upstream to diagnose and fix issue 4. gnome-software — rpm-ostree plugin refuses to update — ON_QA ACTION: QA to verify FEDORA-2022-b53191498a 5. imsettings — Default GTK_IM_MODULE should be ibus in GNOME Xorg — ON_QA ACTION: QA to verify FEDORA-2022-d5a9bcdac5 6. mesa — Mesa 22.2.0~rc3 is built without support for common video codecs, missing mesa-va-drivers might cause issues — ASSIGNED ACTION: Maintainers to diagnose and fix issue 7. poppler — CVE-2022-38784: integer overflow in JBIG2 decoder using malformed files — ON_QA ACTION: QA to verify FEDORA-2022-fcb3b063a6 Bug-by-bug detail = Accepted blockers - 1. abrt — https://bugzilla.redhat.com/show_bug.cgi?id=2128662 — ASSIGNED Abrt does not report a segfault which is reported in journalctl. A possible race condition caused abrt to fail to report segfaults. Restarting the service caused abrt to work as expected. Recent attempts to reproduce the behavior have failed. 2. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2131183 — ON_QA Installer Crashes When Attempting to Reclaim Space When using custom storage configuration, deleting existing mount points and devices on the Manual Partitioning Screen causes Anaconda to crash. FEDORA-2022-2c9c1ebab5 contains a candidate fix. 3. glibc — https://bugzilla.redhat.com/show_bug.cgi?id=2129358 — POST glibc 2.36+ breaks EAC with removal of DT_HASH (and other game libraries), making games fail to load Not including DT_HASH data in glibc's ELF binaries causes Steam games using Epic Games Easy Anti-Cheat software to fail to load the EAC module. This was made a blocker by FESCo due to the reptuational impact it would have in the gaming community. A PR exists to restore this data, but the maintainers have concerns about testing. 4. gnome-calendar — https://bugzilla.redhat.com/show_bug.cgi?id=2130964 — VERIFIED Month names are not in sync Under a variety of conditions, the month names do in the two panels do not adjust in sync. In fact, it's possible to create an event in one month while the main view and left pane each say different months. FEDORA-2022-89b6622d53 contains a verified fix. 5. gnome-calendar — https://bugzilla.redhat.com/show_bug.cgi?id=2130977 — VERIFIED Editing recurring events is broken, changes a single instance instead of all instances When editing a recurring event, only one isntance moves. That instance is duplicated, while previous instances are deleted and subsequent instances are unchanged. FEDORA-2022-89b6622d53 contains a verified fix (although the UI does not correctly redraw events, which is RHBZ 2132769). 6. gnome-calendar — https://bugzilla.redhat.com/show_bug.cgi?id=2130981 — VERIFIED Calendar does not delete events properly Deleting a calendar event before the confirmation appears results in events listed in certain views. After an application restart, the events are back but cannot be deleted or edited. FEDORA-2022-89b6622d53 contains a verified fix. 7. gnome-contacts — https://bugzilla.redhat.com/show_bug.cgi?id=2130657 — ASSIGNED Editing an existing contact's email address causes Contacts to display an empty "Unnamed Person" card, other edits made at the same time are lost Clicking back on an edited contact shows the card correctly if only one
[Bug 2132841] New: perl-HTTP-Message-6.38 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2132841 Bug ID: 2132841 Summary: perl-HTTP-Message-6.38 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTTP-Message Keywords: FutureFeature, Triaged Assignee: mspa...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 6.38 Upstream release that is considered latest: 6.38 Current version/release in rawhide: 6.37-1.fc38 URL: http://search.cpan.org/dist/HTTP-Message/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/2977/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-HTTP-Message -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2132841 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 37 Final Go/No-Go meeting next week
The Fedora Linux 37 Final Go/No-Go[1] meeting is scheduled for Thursday 13 October at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F37 Final for the 18 October early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. Currently, we have 9 accepted and 7 proposed release blocker bugs[4]. [1] https://calendar.fedoraproject.org/meeting/10352/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting [4] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora Linux 37 Final Go/No-Go meeting next week
The Fedora Linux 37 Final Go/No-Go[1] meeting is scheduled for Thursday 13 October at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F37 Final for the 18 October early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. Currently, we have 9 accepted and 7 proposed release blocker bugs[4]. [1] https://calendar.fedoraproject.org/meeting/10352/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting [4] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F38 proposal: Deprecate python-toml (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/DeprecatePythonToml
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The {{package|python-toml}} (`python3-toml`) package will be
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
deprecated] in [[Releases/38|Fedora 38]]. The
[https://pypi.org/project/toml/ upstream toml package] is considered
unmaintained (see [[#Detailed_Description|description]]) and Python
3.11 contains [https://peps.python.org/pep-0680/ a TOML-reading
library in the standard library]. Existing Fedora packages depend on
{{package|python-toml}}, so we cannot remove it yet. Packagers are
encouraged to work with upstreams to switch to
[https://peps.python.org/pep-0680/
tomllib]/[https://pypi.org/project/tomli/ tomli] for reading toml or
[https://pypi.org/project/tomli/ tomli-w] for writing it. But
{{package|python-toml}} remains available until it is a leaf package,
it will be removed then (possibly not yet in Fedora 38).
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com
== Detailed Description ==
The {{package|python-toml}} package is [https://pypi.org/project/toml/
unmaintained upstream]. It does not support the latest TOML standard
and no longer releases newer versions.
We'd like to drop it from Fedora, but several packages still require
it. Before we attempt to remove the package, we need to stop new
packages to (Build)Require `python3-toml`, hence we want to have it
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
deprecated]. No new packages that require it may be added to Fedora
and existing packages may not gain new dependencies on it. Requiring
it only `if python3 < 3.11` or similar is allowed because python3 on
Fedora 38 is 3.11.
Packagers are encouraged to switch to an alternative TOML library with
upstream involvement. Downstream-only patches to switch are not
encouraged. Change owners recommend the following alternatives:
* Use the [https://docs.python.org/3.11/library/tomllib.html tomllib]
module from the standard library to read TOML with Python 3.11+.
* Use the {{package|python-tomli}} package to read TOML with an older
version of Python. The `tomllib` module has started as `tomli` and
they share the same API except for the module name.
* Use the {{package|python-tomli-w}} package to write TOML.
Note that repoquery gives many packages depending on
`python3-toml`:
$ repoquery --repo=rawhide{,-source} --whatrequires python3-toml | wc -l
443
This is because many packages BuildRequire `(python3dist(toml) if
python3-devel < 3.11)` due to {{package|pyproject-rpm-macros}}.
$ repoquery --repo=rawhide{,-source} --whatrequires
'(python3dist(toml) if python3-devel < 3.11)' | wc -l
413
The change owners don't know how to
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3YA5AVHIM65FRSTLLISY5Y7KNGOS4KYA/
easily filter them out], but when filtered the hard way, this remains:
(Results from 2022-10-05, may contain false positives.)
$ for pkg in $(repoquery --repo=rawhide{,-source} --whatrequires
python3-toml); do repoquery -q --repo=rawhide{,-source} --requires
$pkg | grep -Fv '(python3dist(toml) if python3-devel < 3.11)' | grep
-Eq '(\(|-)toml\b' && echo $pkg; done
academic-admin-0:0.5.1-10.fc37.noarch
academic-admin-0:0.5.1-10.fc37.src
bandit-0:1.7.4-3.fc37.src
bst-external-0:0.29.0-1.fc38.src
cvc4-0:1.8-12.fc37.src
fedora-license-data-0:1.5-1.fc38.src
fedora-messaging-0:3.1.0-5.fc38.src
gi-docgen-0:2022.1-7.fc38.noarch
gi-docgen-0:2022.1-7.fc38.src
jrnl-0:3.0-3.fc37.src
micropipenv-0:1.4.2-1.fc37.noarch
pre-commit-0:2.20.0-2.fc37.noarch
pre-commit-0:2.20.0-2.fc37.src
pylint-0:2.14.4-3.fc37.src
python-anyconfig-0:0.13.0-3.fc37.src
python-anymarkup-0:0.8.1-10.fc37.src
python-anymarkup-core-0:0.8.1-9.fc37.src
python-ast-monitor-0:0.2.1-1.fc38.src
python-asttokens-0:2.0.8-1.fc38.src
python-autopep8-0:1.6.0-5.fc37.src
python-botocore-0:1.27.86-1.fc38.src
python-box-0:6.0.2-1.fc38.src
python-build-0:0.8.0-4.fc37.src
python-check-manifest-0:0.48-3.fc37.src
python-deepdiff-0:5.8.2-2.fc37.src
python-devicely-0:1.1.1-3.fc37.src
python-elpy-0:1.34.0-8.fc37.src
python-exoscale-0:0.7.1-4.fc37.src
python-fasjson-client-0:1.0.7-5.fc38.src
python-fireflyalgorithm-0:0.3.2-2.fc37.src
python-interrogate-0:1.5.0-4.fc37.src
python-jsonpickle-0:2.2.0-4.fc37.src
python-lsp-black-0:1.2.0-3.fc37.src
python-matrix-nio-0:0.19.0-6.fc38.src
python-molecule-podman-0:1.0.1-4.fc37.src
python-neurom-0:3.1.0-5.fc37.src
python-niaaml-0:1.1.11-1.fc38.src
python-niaarm-0:0.2.1-2.fc38.src
python-niaclass-0:0.1.2-8.fc37.src
python-nikola-0:8.2.2-4.fc37.src
python-pendulum-0:2.1.2-8.fc37.src
python-podman-3:4.2.0-7.fc38.src
F38 proposal: Deprecate python-toml (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/DeprecatePythonToml
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The {{package|python-toml}} (`python3-toml`) package will be
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
deprecated] in [[Releases/38|Fedora 38]]. The
[https://pypi.org/project/toml/ upstream toml package] is considered
unmaintained (see [[#Detailed_Description|description]]) and Python
3.11 contains [https://peps.python.org/pep-0680/ a TOML-reading
library in the standard library]. Existing Fedora packages depend on
{{package|python-toml}}, so we cannot remove it yet. Packagers are
encouraged to work with upstreams to switch to
[https://peps.python.org/pep-0680/
tomllib]/[https://pypi.org/project/tomli/ tomli] for reading toml or
[https://pypi.org/project/tomli/ tomli-w] for writing it. But
{{package|python-toml}} remains available until it is a leaf package,
it will be removed then (possibly not yet in Fedora 38).
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com
== Detailed Description ==
The {{package|python-toml}} package is [https://pypi.org/project/toml/
unmaintained upstream]. It does not support the latest TOML standard
and no longer releases newer versions.
We'd like to drop it from Fedora, but several packages still require
it. Before we attempt to remove the package, we need to stop new
packages to (Build)Require `python3-toml`, hence we want to have it
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
deprecated]. No new packages that require it may be added to Fedora
and existing packages may not gain new dependencies on it. Requiring
it only `if python3 < 3.11` or similar is allowed because python3 on
Fedora 38 is 3.11.
Packagers are encouraged to switch to an alternative TOML library with
upstream involvement. Downstream-only patches to switch are not
encouraged. Change owners recommend the following alternatives:
* Use the [https://docs.python.org/3.11/library/tomllib.html tomllib]
module from the standard library to read TOML with Python 3.11+.
* Use the {{package|python-tomli}} package to read TOML with an older
version of Python. The `tomllib` module has started as `tomli` and
they share the same API except for the module name.
* Use the {{package|python-tomli-w}} package to write TOML.
Note that repoquery gives many packages depending on
`python3-toml`:
$ repoquery --repo=rawhide{,-source} --whatrequires python3-toml | wc -l
443
This is because many packages BuildRequire `(python3dist(toml) if
python3-devel < 3.11)` due to {{package|pyproject-rpm-macros}}.
$ repoquery --repo=rawhide{,-source} --whatrequires
'(python3dist(toml) if python3-devel < 3.11)' | wc -l
413
The change owners don't know how to
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3YA5AVHIM65FRSTLLISY5Y7KNGOS4KYA/
easily filter them out], but when filtered the hard way, this remains:
(Results from 2022-10-05, may contain false positives.)
$ for pkg in $(repoquery --repo=rawhide{,-source} --whatrequires
python3-toml); do repoquery -q --repo=rawhide{,-source} --requires
$pkg | grep -Fv '(python3dist(toml) if python3-devel < 3.11)' | grep
-Eq '(\(|-)toml\b' && echo $pkg; done
academic-admin-0:0.5.1-10.fc37.noarch
academic-admin-0:0.5.1-10.fc37.src
bandit-0:1.7.4-3.fc37.src
bst-external-0:0.29.0-1.fc38.src
cvc4-0:1.8-12.fc37.src
fedora-license-data-0:1.5-1.fc38.src
fedora-messaging-0:3.1.0-5.fc38.src
gi-docgen-0:2022.1-7.fc38.noarch
gi-docgen-0:2022.1-7.fc38.src
jrnl-0:3.0-3.fc37.src
micropipenv-0:1.4.2-1.fc37.noarch
pre-commit-0:2.20.0-2.fc37.noarch
pre-commit-0:2.20.0-2.fc37.src
pylint-0:2.14.4-3.fc37.src
python-anyconfig-0:0.13.0-3.fc37.src
python-anymarkup-0:0.8.1-10.fc37.src
python-anymarkup-core-0:0.8.1-9.fc37.src
python-ast-monitor-0:0.2.1-1.fc38.src
python-asttokens-0:2.0.8-1.fc38.src
python-autopep8-0:1.6.0-5.fc37.src
python-botocore-0:1.27.86-1.fc38.src
python-box-0:6.0.2-1.fc38.src
python-build-0:0.8.0-4.fc37.src
python-check-manifest-0:0.48-3.fc37.src
python-deepdiff-0:5.8.2-2.fc37.src
python-devicely-0:1.1.1-3.fc37.src
python-elpy-0:1.34.0-8.fc37.src
python-exoscale-0:0.7.1-4.fc37.src
python-fasjson-client-0:1.0.7-5.fc38.src
python-fireflyalgorithm-0:0.3.2-2.fc37.src
python-interrogate-0:1.5.0-4.fc37.src
python-jsonpickle-0:2.2.0-4.fc37.src
python-lsp-black-0:1.2.0-3.fc37.src
python-matrix-nio-0:0.19.0-6.fc38.src
python-molecule-podman-0:1.0.1-4.fc37.src
python-neurom-0:3.1.0-5.fc37.src
python-niaaml-0:1.1.11-1.fc38.src
python-niaarm-0:0.2.1-2.fc38.src
python-niaclass-0:0.1.2-8.fc37.src
python-nikola-0:8.2.2-4.fc37.src
python-pendulum-0:2.1.2-8.fc37.src
python-podman-3:4.2.0-7.fc38.src
[Bug 2132803] New: perl-URI-5.13 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2132803 Bug ID: 2132803 Summary: perl-URI-5.13 is available Product: Fedora Version: rawhide Status: NEW Component: perl-URI Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 5.13 Upstream release that is considered latest: 5.13 Current version/release in rawhide: 5.12-2.fc37 URL: http://search.cpan.org/dist/URI/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3485/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-URI -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2132803 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is a file dependency appropriate?
On 06. 10. 22 15:04, Kalev Lember wrote: I guess a transition plan (if we make up our minds that it makes sense to do it) could be to first make sure the provides are autogenerated, then do a mass rebuild, let people try it out in their packages for 6 months, and then provenpackager-edit all of Requires/BuildRequires: /usr/bin/foo in the distro to the new format as at that point all of supported Fedora releases are going to have the provides. Unfortunately, I am afraid the my-EPEL-package-must-use-the-same-spec people will not like this. We can mass update everything in 15 years maybe. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Grub menu with 3 kernels by default
Daniel P. Berrangé writes: > We need PCRs to cover at minimum > > 1. Machine firmware > 2. Bootloader(s) > 3. Bootloader configuration > 4. Booted kernel > 5. Booted initrd > 6. Booted cmdline > Item 5 and 6 are a problem, because as mentioned thse are not signed > by the OS vendor with their secureboot key. The PCRs reflect their > contents, but the expected PCR digests will change any time the > initrd/cmdline are updated, meaning the LUKS keys needs to be > re-sealed. One practical approach to this problem is to use > prebuilt unified kernel images, such that the OS vendor's secureboot > signature covers the kernel,initrd and cmdline. Verification now > merely involves checking the PCR for SecureBOot state. The flipside > is that we loose flexibility that exists today with per-host > generated initrd/cmdline. This may matter for some scenarios (bare > metal) but not for others (most VMs). This isn't a grub2 specific problem, but yes - we've discussed how to accomplih signing initrd/cmdline on calls with you before. > Item 3 is a problem. Grub is highly configurable, via grub.conf, and > its contents are tuned for each install. > > This is a really challenging eventlog when trying to validate the PCR > state is matching some expected "known good" state. Given a single > grub.conf, you get both a huge number of entries for every boot, plus > a combinatorial expansion of possible entries that would be considered > valid for a given install over time as kernels and/or grub itself are > updated. A tiny change to the way grub2-mkconfig could result in a > very different PCR eventlog, but which is semantically identical to > what came before. > > Thus any attempt to validate the the grub.conf PCR eventlog, as it > exists in typical distro deployments today, is going to be both > complex and fragile, which is a bad combination. But this is only a problem if you're assuming grub2-mkconfig is nondeterministic, which just isn't the case. I'll grant that the event log isn't terse, but what's valid isn't be hard to precompute. On generally identical systems, what will differ is uuids and partition numbers... which is important information to have logged for booting because it's part of recording *what* was booted. Glibly, if you don't want a config change, don't run grub2-mkconfig :) We don't run mkconfig on the system after install because it doesn't change - it only get run to change something. And if you update configuration, you'd want to know that things changed - that's the whole point of logging it. Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Should we retire weechat from EPEL 7?
On Thu Oct 6, 2022 at 19:11 +0200, Neal Gompa wrote: > The cmake3 package has all the macros from the mainline cmake package in > Fedora. > > It should be fully compatible, just swap %cmake_* for %cmake3_*. Oops, I responded before I saw this. -- Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Should we retire weechat from EPEL 7?
On Thu Oct 6, 2022 at 12:02 CDT, Michel Alexandre Salim wrote: > I'm not sure either Paul or myself really care enough about EL7 to > maintain a divergent spec. The %cmake3* macros work everywhere. -- Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Should we retire weechat from EPEL 7?
On Thu, Oct 6, 2022 at 7:03 PM Michel Alexandre Salim wrote: > > Hi all, > > We should probably retire weechat from EPEL 7 - it has multiple CVEs > that can only be fixed by updating to versions >= 3.5, but the spec no > longer works on EPEL 7 thanks to macros like `%cmake_build` not being > available. > > https://bugz.fedoraproject.org/weechat > > I'm not sure either Paul or myself really care enough about EL7 to > maintain a divergent spec. If someone does still care, PR appreciated to > fix this, otherwise consider this the first notice that I'll retire this > branch in a few days. > The cmake3 package has all the macros from the mainline cmake package in Fedora. It should be fully compatible, just swap %cmake_* for %cmake3_*. -- 真実はいつも一つ！/ Always, there's only one truth! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Should we retire weechat from EPEL 7?
Hi all, We should probably retire weechat from EPEL 7 - it has multiple CVEs that can only be fixed by updating to versions >= 3.5, but the spec no longer works on EPEL 7 thanks to macros like `%cmake_build` not being available. https://bugz.fedoraproject.org/weechat I'm not sure either Paul or myself really care enough about EL7 to maintain a divergent spec. If someone does still care, PR appreciated to fix this, otherwise consider this the first notice that I'll retire this branch in a few days. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Grub menu with 3 kernels by default
On Thu, Oct 06, 2022 at 10:45:40AM -0400, Robbie Harwood wrote:
> Daniel P. Berrangé writes:
>
> > The way grub has to write its entire grub.conf into the TPM PCRs is
> > totally impractical for anyone wishing to maintain attestation
> > policies to verify the OS boot state from the TPM eventlog.
>
> So this has been mentioned in several places, but no one in grub
> development has actually seen this problem articulated out, which makes
> me worry that it's spreading FUD. Could you write up a bug report or
> something concrete?
I've not filed a bug report, as to I tended to view it as an inherant
result of the goals of grub to be a flexible boot
environment. Let me try to explain in more detail here though...
Right now the default way more or less any Linux distro does SecureBoot
is not too useful, since only the kernel is signed by the vendor. The
content of both the initrd and cmdline is local to the installation.
Mostly I'd say it solves the problem of enabling a Linux distro to boot
in an environment where SecureBoot is active. It doesn't solve the
problem of enabling the booted OS to be verified, or at least not in a
manner that is practical to use for unknowledable users.
Despite this we still have functionality that can tie LUKS volume key
unlock to the state of a specific set of TPM PCRs, such disks are
unlocked if-and-only-if the OS is launched in the expected configuration.
This is only secure, if everything that can influence the configuration
is covered by the PCRs we're using for unlock policy.
We need PCRs to cover at minimum
1. Machine firmware
2. Bootloader(s)
3. Bootloader configuration
4. Booted kernel
5. Booted initrd
6. Booted cmdline
Item 1 is OK-ish. It won't change unless you upgrade your firmware,
so is relatively stable, though fwupd has made this more dynamic
than in the past.
Items 2 & 4 are OK because Microsoft signs shim, and the OS vendor
signs grub and their kernels. So we can rely on the fact that if
SecureBoot is signalled enabled by the relevant PCR, the bootloaders(s)
& kernel are trusted (within scope of the SecureBoot keys that are
enrolled).
Item 5 and 6 are a problem, because as mentioned thse are not signed
by the OS vendor with their secureboot key. The PCRs reflect their
contents, but the expected PCR digests will change any time the
initrd/cmdline are updated, meaning the LUKS keys needs to be
re-sealed. One practical approach to this problem is to use
prebuilt unified kernel images, such that the OS vendor's secureboot
signature covers the kernel,initrd and cmdline. Verification now
merely involves checking the PCR for SecureBOot state. The flipside
is that we loose flexibility that exists today with per-host
generated initrd/cmdline. This may matter for some scenarios (bare
metal) but not for others (most VMs).
Item 3 is a problem. Grub is highly configurable, via grub.conf, and
its contents are tuned for each install. We need to validate any
parts of grub.conf that applied to the current boot state. On a fairly
typical VM the PCR eventlog recording the bootloader configuration
contains something that looks similarish to:
(hd0,gpt15)/EFI/ubuntu/grub.cfg
grub_cmd: search.fs_uuid c73d8355-1ac9-41b4-8edf-c1c1a9d5bd6a root
grub_cmd: set prefix=(hd0,gpt1)/boot/grub
(hd0,gpt1)/boot/grub/x86_64-efi/command.lst
(hd0,gpt1)/boot/grub/x86_64-efi/fs.lst
(hd0,gpt1)/boot/grub/x86_64-efi/crypto.lst
(hd0,gpt1)/boot/grub/x86_64-efi/terminal.lst
grub_cmd: configfile (hd0,gpt1)/boot/grub/grub.cfg
(hd0,gpt1)/boot/grub/grub.cfg
grub_cmd: [ -s (hd0,gpt1)/boot/grub/grubenv ]
(hd0,gpt1)/boot/grub/grubenv
grub_cmd: set have_grubenv=true
grub_cmd: load_env
(hd0,gpt1)/boot/grub/grubenv
grub_cmd: [ = 2 ]
grub_cmd: [ = 1 ]
grub_cmd: [ ]
grub_cmd: set default=0
grub_cmd: [ xy = xy ]
grub_cmd: menuentry_id_option=--id
grub_cmd: export menuentry_id_option
grub_cmd: [ ]
grub_cmd: terminal_input console
grub_cmd: terminal_output console
grub_cmd: [ = 1 ]
grub_cmd: [ xy = xy ]
grub_cmd: set timeout_style=hidden
grub_cmd: set timeout=0.1
grub_cmd: [ -n true ]
grub_cmd: [ -n ]
grub_cmd: set initrdless_boot_fallback_triggered=0
grub_cmd: save_env initrdless_boot_fallback_triggered
grub_cmd: set menu_color_normal=white/black
grub_cmd: set menu_color_highlight=black/light-gray
grub_cmd: set partuuid=bf817bdf-6a3a-4221-8edb-2c1ca7c5537f
grub_cmd: [ != 1 ]
grub_cmd: [ -e (hd0,gpt1)/boot/grub/gfxblacklist.txt ]
grub_cmd: hwmatch (hd0,gpt1)/boot/grub/gfxblacklist.txt 3
grub_cmd: [ = 0 ]
grub_cmd: set linux_gfx_mode=keep
grub_cmd: export linux_gfx_mode
grub_cmd: menuentry Ubuntu --class ubuntu --class gnu-linux --class gnu
--class os --id gnulinux-simple-c73d8355-1ac9-41b4-8edf-c1c1a9d5bd6a {
if [
[EPEL-devel] Re: Proposal: Dropping modules from EPEL-8. Not adding modules to EPEL-9
On Wed, 31 Aug 2022 at 17:08, Stephen Smoogen wrote: > > When EPEL-8 was launched, it came with some support for modules with the > hope that a module ecosystem could be built from Fedora packages using RHEL > modules as an underlying tool. This has never happened and we have ended up > with a muddle of modular packages which will 'build' but may not install or > even run on an EL-8 system. Attempts to fix this and work within how EPEL > is normally built have been tried for several years by different people but > have not worked. > > At this point it is time to say this experiment with modules in EPEL has > not worked and focus resources on what does work. I would like to propose > that modular support is removed from EPEL by January 2023. > > Steps: > 1. Approval of this proposal by the EPEL Steering committee and any other > ones required. > 2. Announcement of end of life to various lists. > 3. Archiving of the modules on XYZ date to > /pub/archive/epel/8.-MM/Modular and pointing mirrormanager to that for > that > 4. Make changes in bodhi to turn off reporting about modules for EL8. > 5. Make changes in MBS configs to turn off building modules for EL8. > 6. Make changes in PDC for EL8 modules > 7. Make changes in compose scripts and tools to no longer cover EPEL-8 > modules > 8. Remove epel-8 modules from /pub/epel/8 > 9. Announce closure of this proposal and any lessons learned. > > Due to the year end freezes that many Enterprise consumers are starting, I would like to propose the change to the timeline 2b. Make changes to epel-release so that EPEL modular is no longer turned on by default with README. 2c. Document configuration changes that would be needed for sites mirroring using Enterprise patch management systems. 3a. Start regular Archiving of the modules on XYZ date to /pub/archive/epel/8 3b. and pointing mirrormanager to that for that We can do steps up to 3a. and then start on 3b and other items after February 1st 2023. -- Stephen Smoogen, Red Hat Automotive 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1ee1fe2c17 libopenmpt-0.6.6-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing gnome-shell-extension-appindicator-46-1.el9 ioping-1.3-1.el9 weechat-3.6-1.el9 Details about builds: gnome-shell-extension-appindicator-46-1.el9 (FEDORA-EPEL-2022-2531c94250) AppIndicator/KStatusNotifierItem support for GNOME Shell Update Information: Update to latest version ChangeLog: * Fri Sep 30 2022 Artem Polishchuk 46-1 - chore(update): 46 * Thu Sep 29 2022 Artem Polishchuk 45-1 - chore(update): 45 ioping-1.3-1.el9 (FEDORA-EPEL-2022-43ac9fb3fb) Simple disk I/O latency monitoring tool Update Information: ioping lets you monitor I/O latency in real time. It shows disk latency in the same way as ping shows network latency ChangeLog: * Thu Oct 6 2022 Robin Lee 1.3-1 - Update to 1.3 * Thu Jul 21 2022 Fedora Release Engineering - 1.1-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Thu Jan 20 2022 Fedora Release Engineering - 1.1-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release Engineering - 1.1-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 1.1-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild References: [ 1 ] Bug #2132428 - Please branch and build ioping in epel9 https://bugzilla.redhat.com/show_bug.cgi?id=2132428 weechat-3.6-1.el9 (FEDORA-EPEL-2022-1c6c522b07) Portable, fast, light and extensible IRC client Update Information: - add command "/item" to create custom bar items - add bar item "spacer" - add case conversion in evaluation of expressions with "lower:string" and "upper:string" - move detailed list of hooks from command "/plugin listfull" to "/debug hooks " - allow to remove multiple filters at once with command "/filter del" - allow to catch multiple signals in functions hook_signal and hook_hsignal - rename option "save" to "apply" in IRC command "/autojoin" - add support of RPL_HELPSTART, RPL_HELPTXT and RPL_ENDOFHELP (IRC messages 524, 704, 705, 706) - add support of PHP 8.2 - many bugs fixed. ChangeLog: * Wed Oct 5 2022 Michel Alexandre Salim 3.6-1 - Update to 3.6 References: [ 1 ] Bug #2063856 - weechat: SSL verification vulnerability [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=2063856 [ 2 ] Bug #2128160 - New version of weechat available 3.6 https://bugzilla.redhat.com/show_bug.cgi?id=2128160 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8 Modules get the axe on Halloween 2022
On Wed, Sep 28, 2022 at 3:09 PM Troy Dawson wrote: > When EPEL-8 was launched, it came with some support for modules with the > hope that a module ecosystem could be built from Fedora packages using RHEL > modules as an underlying tool. This has never happened and we have ended up > with a muddle of modular packages which will 'build' but may not install or > even run on an EL-8 system. Attempts to fix this and work within how EPEL > is normally built have been tried for several years by different people but > have not worked. > > At this point we are saying that this experiment with modules in EPEL has > not worked and we will focus our resources on what does work. > > Schedule of EPEL 8 Module Retirement: > Next Week: > - epel-release will be updated. > -- epel-modular will set enabled = 0 > -- epel-modular full name will have "Deprecated" in it > > October 31 2022: > - The EPEL 8 modules will be archived and removed. > -- The mirror manager will be pointed to the archive. > - Packagers will no longer be able to build EPEL 8 modules. > > After October 31st (Actual date to be determined): > - epel-release will be updated again. > -- epel-modular repo configs will be removed. > > Questions and Answers: > > Question: Will I still be able to access the modules after October 31st? > Answer: It is not recommended, because the modules will not get any > security or bug fixes, but yes. They will be in the Fedora archives, > and the mirror managers will point at them. > > Question: What will you be dressed as on Halloween? > Answer (Troy): A Penguin > > EPEL Steering Committee > > [1] - https://pagure.io/epel/issue/198 > Question: Many Enterprise customers need time for a transition like this. Can the transition date be pushed back? Answer: This will have to be voted on by the EPEL Steering Committee. The answer is likely yes, but I won't give a firm answer until it's been discussed and voted on. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-de23d337b0 libopenmpt-0.6.6-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-66467c33ea seamonkey-2.53.14-3.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d8f75949c3 git-lfs-2.10.0-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing luajit-2.0.5-1.20220913.46e62cd.el7 python3-mod_wsgi-4.7.1-3.el7 Details about builds: luajit-2.0.5-1.20220913.46e62cd.el7 (FEDORA-EPEL-2022-f174e47230) Just-In-Time Compiler for Lua Update Information: - Update to latest snapshot of 2.0 branch - Fixes CVE-2020-15890, resolves rhbz#1860331 - Fixes CVE-2020-24372, resolves rhbz#1870308 ChangeLog: * Mon Oct 3 2022 Carl George - 2.0.5-1.20220914.46e62cd - Update to latest snapshot of 2.0 branch - Fixes CVE-2020-15890, resolves rhbz#1860331 - Fixes CVE-2020-24372, resolves rhbz#1870308 References: [ 1 ] Bug #1860331 - CVE-2020-15890 luajit: out-of-bounds read because __gc handler frame traversal is mishandled [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1860331 [ 2 ] Bug #1870308 - CVE-2020-24372 luajit: out-of-bounds read in lj_err_run function in lj_err.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1870308 python3-mod_wsgi-4.7.1-3.el7 (FEDORA-EPEL-2022-3f600666f9) A WSGI interface for Python web applications in Apache Update Information: - Backported fix for CVE-2022-2255 ChangeLog: * Wed Oct 5 2022 Diego Herrera - 4.7.1-3 - Backported fix for CVE-2022-2255 References: [ 1 ] Bug #2108272 - CVE-2022-2255 python3-mod_wsgi: mod_wsgi: Trusted Proxy Headers Removing Bypass [epel-7] https://bugzilla.redhat.com/show_bug.cgi?id=2108272 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Grub menu with 3 kernels by default
Daniel P. Berrangé writes: > The way grub has to write its entire grub.conf into the TPM PCRs is > totally impractical for anyone wishing to maintain attestation > policies to verify the OS boot state from the TPM eventlog. So this has been mentioned in several places, but no one in grub development has actually seen this problem articulated out, which makes me worry that it's spreading FUD. Could you write up a bug report or something concrete? Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2132720] Upgrade perl-Test-Unit-Lite to 0.1202
https://bugzilla.redhat.com/show_bug.cgi?id=2132720 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Paul Howarth --- The version in Fedora has been 0.1202 since December 2012. However, this is not reflected in the package version number since at that time I'd expected a version 0.13 to appear in the future, which wouldn't play well with RPM version numbering. I think the best thing to do would be to rebuild the package using a version number of 0.12.02. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2132720 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Has the final freeze for f37 started?
Hi, yes the freeze started on the scheduled date and time. Please create releng ticket with packages that require blocking in koji. On Thu, Oct 6, 2022 at 3:25 PM Fabio Valentini wrote: > Hi all, > > I retired some packages from f37 and rawhide on Tuesday and Wednesday, > but their retirements were no longer processed correctly. After > looking at the F37 schedule, the Final Freeze for Fedora 37 should > have started two days ago (14:00 UTC on 2022-10-04), which might > explain this (at least in part, some packages were retired before > 14:00 UTC), but right now I can't find an announcement that the freeze > has actually started. > > Should I open a releng ticket to get the affected packages correctly > retired? Right now they're "retired" in dist-git but not blocked in > koji etc., and since they're unused and / or broken packages, I'd like > F37 not to ship with them. > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Tomas Hrcka role: CPE Team - Senior Software Engineer fas: humaton freenode: jednorozec ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF5 Blockers
On Thu, Oct 6, 2022 at 5:11 AM Maxwell G via devel wrote: > > Some of mine: > > - `dnf repoquery` -- Currently, `dnf5 repoquery` nowhere near meets the > capabilities of the old version. This is the most important to me. I agree, repoquery is an absolutely essential tool for me. Without it, it would be impossible to maintain the number of packages I do without breaking things left and right twice a week. At the very least, dnf5-repoquery will need to support the most common things from "dnf repoquery", otherwise things will be very broken in many people's packaging automation, release engineering scripts, etc. > - `dnf system-upgrade` That also seems to be important ... Isn't "dnf system-upgrade" the "officially blessed" way of upgrading from one Fedora release to another on the command line? I also need "dnf repoclosure" ... without it, I'd need to either completely reimplement or shut down the service that provides "broken dependencies" / fails-to-install data for the Fedora Packager Dashboard. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF5 Blockers
On Thu, 2022-10-06 at 13:53 +0100, Richard W.M. Jones wrote: > On Wed, Oct 05, 2022 at 09:20:47PM -0500, Maxwell G via devel wrote: > > Hi Fedorians, > > > > I think we should define a more through list of blockers/criteria > > that > > dnf5 needs to meet before it can replace the current dnf. > > > > The DNF maintainers have their list of requirements, but it would > > be > > helpful for the wider community to test dnf5 and report which > > currently > > unimplemented features/usecases would block them from adopting it. > > Hopefully, the more popular, for lack of a better word, blockers > > can be > > incorporated into the Change Proposal or otherwise required by > > FESCo as > > a prerequisite for this change. This should help the DNF > > maintainers > > prioritize, keep everyone on the same page, and ensure that dnf5 > > doesn't > > prematurely become the default. > > Is there a way to test it? This didn't work: > > # dnf install dnf5 > Last metadata expiration check: 0:52:30 ago on Thu 06 Oct 2022 > 13:00:16 BST. > No match for argument: dnf5 > Error: Unable to find a match: dnf5 > > > Anyway, as previously mentioned "dnf5 download" should work as for > dnf, and especially must not require root privileges. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: > http://rwmj.wordpress.com > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://people.redhat.com/~rjones/virt-top > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue It's in a COPR. sudo dnf copr enable rpmsoftwaremanagement/dnf5-unstable signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Has the final freeze for f37 started?
Hi all, I retired some packages from f37 and rawhide on Tuesday and Wednesday, but their retirements were no longer processed correctly. After looking at the F37 schedule, the Final Freeze for Fedora 37 should have started two days ago (14:00 UTC on 2022-10-04), which might explain this (at least in part, some packages were retired before 14:00 UTC), but right now I can't find an announcement that the freeze has actually started. Should I open a releng ticket to get the affected packages correctly retired? Right now they're "retired" in dist-git but not blocked in koji etc., and since they're unused and / or broken packages, I'd like F37 not to ship with them. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2132720] New: Upgrade perl-Test-Unit-Lite to 0.1202
https://bugzilla.redhat.com/show_bug.cgi?id=2132720 Bug ID: 2132720 Summary: Upgrade perl-Test-Unit-Lite to 0.1202 Product: Fedora Version: rawhide URL: https://metacpan.org/release/Test-Unit-Lite Status: NEW Component: perl-Test-Unit-Lite Assignee: p...@city-fan.org Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.12 version. Upstream released 0.1202. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2132720 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is a file dependency appropriate?
On Thu, Oct 6, 2022 at 2:51 PM Vít Ondruch wrote:
>
> Dne 06. 10. 22 v 14:38 Kalev Lember napsal(a):
>
> On Thu, Oct 6, 2022 at 11:05 AM Vít Ondruch wrote:
>
>> BTW re-reading the ticket and since there are talks about DNF5, maybe it
>> would be worth of reopening the discussion. I think we could generally
>> do better and I see two options:
>>
>> 1) There seems to be a way to download additional data if needed
>>
>> 2) The metadata we provide in reposotories could be better. I.e. instead
>> of providing full file list, it could be actually enough to collect just
>> the files of the interest. E.g. if there is somewhere `BR:
>> /usr/bin/foo`, then during preparation of repo data, there could be file
>> list with record for bar package, providing entry such as "/usr/bin/foo:
>> bar". This would probably not require any big changes in DNF IMHO.
>>
>
> One problem I have with `BuildRequires: /usr/bin/foo` is that it hardcodes
> the /usr/bin directory, which is the right thing to do when the program
> that uses foo invokes it with full /usr/bin/foo path, but not at all when
> foo is searched from PATH.
>
>
> * I don't think that PATH plays a role here, because otherwise we will be
> back to discussion if and when we should use `env` in shebangs or not.
>
> * We had this issue for SCLs before and I think there are some proposals
> such as:
>
> https://github.com/rpm-software-management/rpm/issues/721
>
> https://github.com/rpm-software-management/rpm/issues/1850
>
Thanks!
This has been a bit of a pain point for flatpak builds in Fedora where the
> rpms are rebuilt for /app prefix. If a package that has `BuildRequires:
> /usr/bin/foo` but the package that provides foo is rebuilt for /app prefix,
> then we no longer have /usr/bin/foo but instead /app/bin/foo and the BR no
> longer finds the package providing foo. Using %{_bindir} doesn't help
> either because not all packages that are used for flatpaks are rebuilt for
> /app (some are part of the flatpak runtime and stay in /usr).
>
> Maybe it would instead make sense to have an abstraction where instead of
> listing /usr/bin/foo in the repo data, we'd have 'Provides:
> executable(foo)' and then other packages could do 'BuildRequires:
> executable(foo)' instead? That would nicely solve the hardcoded path issue.
>
>
> Not sure I like it or not (I would need to give it more thought), but if
> it was autogenerated
>
Yes, of course autogenerated, anything else would be crazy :) I'll need to
give this some more thought myself, it was just a quick idea I got when
reading this.
I guess a transition plan (if we make up our minds that it makes sense to
do it) could be to first make sure the provides are autogenerated, then do
a mass rebuild, let people try it out in their packages for 6 months, and
then provenpackager-edit all of Requires/BuildRequires: /usr/bin/foo in the
distro to the new format as at that point all of supported Fedora releases
are going to have the provides.
After that, all of /usr/bin provides can be removed from the primary repo
metadata (maybe after 6 more months to give time for 3rd party repos to
catch up) and kept only in the extra filelists metadata.
--
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Bug 2132717] New: Upgrade perl-Net-DNS-SEC to 1.20
https://bugzilla.redhat.com/show_bug.cgi?id=2132717 Bug ID: 2132717 Summary: Upgrade perl-Net-DNS-SEC to 1.20 Product: Fedora Version: rawhide URL: https://metacpan.org/release/Net-DNS-SEC Status: NEW Component: perl-Net-DNS-SEC Assignee: wjhns...@hardakers.net Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: paul.wout...@aiven.io, perl-devel@lists.fedoraproject.org, wjhns...@hardakers.net Target Milestone: --- Classification: Fedora Latest Fedora delivers 1.19 version. Upstream released 1.20. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2132717 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2132704] New: Upgrade perl-Image-Info to 1.43
https://bugzilla.redhat.com/show_bug.cgi?id=2132704 Bug ID: 2132704 Summary: Upgrade perl-Image-Info to 1.43 Product: Fedora Version: rawhide URL: https://metacpan.org/release/Image-Info Status: NEW Component: perl-Image-Info Assignee: spo...@gmail.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org, rob.my...@gtri.gatech.edu, spo...@gmail.com, xav...@bachelot.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 1.42 version. Upstream released 1.43. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2132704 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 1937653] Upgrade perl-HTTP-OAI to 4.12
https://bugzilla.redhat.com/show_bug.cgi?id=1937653 Jitka Plesnikova changed: What|Removed |Added Summary|Upgrade perl-HTTP-OAI to|Upgrade perl-HTTP-OAI to |4.2 |4.12 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1937653 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF5 Blockers
On Wed, Oct 05, 2022 at 09:20:47PM -0500, Maxwell G via devel wrote: > Hi Fedorians, > > I think we should define a more through list of blockers/criteria that > dnf5 needs to meet before it can replace the current dnf. > > The DNF maintainers have their list of requirements, but it would be > helpful for the wider community to test dnf5 and report which currently > unimplemented features/usecases would block them from adopting it. > Hopefully, the more popular, for lack of a better word, blockers can be > incorporated into the Change Proposal or otherwise required by FESCo as > a prerequisite for this change. This should help the DNF maintainers > prioritize, keep everyone on the same page, and ensure that dnf5 doesn't > prematurely become the default. Is there a way to test it? This didn't work: # dnf install dnf5 Last metadata expiration check: 0:52:30 ago on Thu 06 Oct 2022 13:00:16 BST. No match for argument: dnf5 Error: Unable to find a match: dnf5 Anyway, as previously mentioned "dnf5 download" should work as for dnf, and especially must not require root privileges. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is a file dependency appropriate?
Dne 06. 10. 22 v 14:38 Kalev Lember napsal(a):
On Thu, Oct 6, 2022 at 11:05 AM Vít Ondruch wrote:
BTW re-reading the ticket and since there are talks about DNF5,
maybe it
would be worth of reopening the discussion. I think we could
generally
do better and I see two options:
1) There seems to be a way to download additional data if needed
2) The metadata we provide in reposotories could be better. I.e.
instead
of providing full file list, it could be actually enough to
collect just
the files of the interest. E.g. if there is somewhere `BR:
/usr/bin/foo`, then during preparation of repo data, there could
be file
list with record for bar package, providing entry such as
"/usr/bin/foo:
bar". This would probably not require any big changes in DNF IMHO.
One problem I have with `BuildRequires: /usr/bin/foo` is that it
hardcodes the /usr/bin directory, which is the right thing to do when
the program that uses foo invokes it with full /usr/bin/foo path, but
not at all when foo is searched from PATH.
* I don't think that PATH plays a role here, because otherwise we will
be back to discussion if and when we should use `env` in shebangs or not.
* We had this issue for SCLs before and I think there are some proposals
such as:
https://github.com/rpm-software-management/rpm/issues/721
https://github.com/rpm-software-management/rpm/issues/1850
This has been a bit of a pain point for flatpak builds in Fedora where
the rpms are rebuilt for /app prefix. If a package that has
`BuildRequires: /usr/bin/foo` but the package that provides foo is
rebuilt for /app prefix, then we no longer have /usr/bin/foo but
instead /app/bin/foo and the BR no longer finds the package providing
foo. Using %{_bindir} doesn't help either because not all packages
that are used for flatpaks are rebuilt for /app (some are part of the
flatpak runtime and stay in /usr).
Maybe it would instead make sense to have an abstraction where instead
of listing /usr/bin/foo in the repo data, we'd have 'Provides:
executable(foo)' and then other packages could do 'BuildRequires:
executable(foo)' instead? That would nicely solve the hardcoded path
issue.
Not sure I like it or not (I would need to give it more thought), but if
it was autogenerated
Vít
--
Kalev
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: When is a file dependency appropriate?
On Thu, Oct 6, 2022 at 11:05 AM Vít Ondruch wrote:
> BTW re-reading the ticket and since there are talks about DNF5, maybe it
> would be worth of reopening the discussion. I think we could generally
> do better and I see two options:
>
> 1) There seems to be a way to download additional data if needed
>
> 2) The metadata we provide in reposotories could be better. I.e. instead
> of providing full file list, it could be actually enough to collect just
> the files of the interest. E.g. if there is somewhere `BR:
> /usr/bin/foo`, then during preparation of repo data, there could be file
> list with record for bar package, providing entry such as "/usr/bin/foo:
> bar". This would probably not require any big changes in DNF IMHO.
>
One problem I have with `BuildRequires: /usr/bin/foo` is that it hardcodes
the /usr/bin directory, which is the right thing to do when the program
that uses foo invokes it with full /usr/bin/foo path, but not at all when
foo is searched from PATH.
This has been a bit of a pain point for flatpak builds in Fedora where the
rpms are rebuilt for /app prefix. If a package that has `BuildRequires:
/usr/bin/foo` but the package that provides foo is rebuilt for /app prefix,
then we no longer have /usr/bin/foo but instead /app/bin/foo and the BR no
longer finds the package providing foo. Using %{_bindir} doesn't help
either because not all packages that are used for flatpaks are rebuilt for
/app (some are part of the flatpak runtime and stay in /usr).
Maybe it would instead make sense to have an abstraction where instead of
listing /usr/bin/foo in the repo data, we'd have 'Provides:
executable(foo)' and then other packages could do 'BuildRequires:
executable(foo)' instead? That would nicely solve the hardcoded path issue.
--
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: When is a file dependency appropriate?
Dne 06. 10. 22 v 14:18 Panu Matilainen napsal(a): On 10/6/22 11:55, Vít Ondruch wrote: Dne 06. 10. 22 v 9:18 Otto Liljalaakso napsal(a): Miro Hrončok kirjoitti 6.10.2022 klo 2.33: On 06. 10. 22 1:21, Otto Liljalaakso wrote: Recently, I have run into some cases where file dependencies like Requires: /usr/bin/foo are used. In a recent thread on this mailing list [1], it is mentioned that such Requires should be avoided, because resolving file dependencies requires a large amount of memory. I don't believe that resolving file-Requires from directories listed at [2] from your email is more memory hungry. Where exactly was that said? [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/ [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies Maybe I should have re-read the thread closely before posting, because the most relevant message is this [3]: " The discussion in the bug indicates that this memory growth is related to loading of the full filepath dataset. We have been discussing splitting out the non-primary-filepath-data (i.e. paths that are not /etc, /usr/bin, /usr/sbin), out into a separate lazilly-loaded file. If we manage to do that, we'll kill two birds with one stone: - initial download of repo metadata on every freakin' dnf operation can go down from 80 to 20 MB - the peak memory use will go down " Which exactly confirms what you say. I am still wondering a bit if there is something else bad about file dependencies? If I am not mistaken, in the YUM days, the file list was split into two parts. One list contained several high profile directories such as /usr/bin [1] while the other contained everything. By default YUM have not loaded the full file list by default, just the short one. The data were not loaded by default. But AFAIK, DNF always loads everything and it does not look that this would change. This is one BZ which comes to my mind for a reference: https://bugzilla.redhat.com/show_bug.cgi?id=968006 IOW for your example, the file dependency was always supported (and IMO preferable). It probably does not matter these days, unless you really consider memory consumption (and I don't think we should generally avoid the file dependencies just on the base of memory consumption). In the yum days, certain locations of the file list, such as /usr/bin were embedded in the main data. They're still there, look for entries in primary.xml. This is good point. I have already forget the details. So if there was embedded just the right amount of information in the main data, we would not need the full list (and lazy loading). Currently, the data contains e.g. /usr/bin/*, which is useful for installing `/usr/bin/foo`. But we know that in the repository, there is RPM with `Requires: /some/strange/path`. Therefore during creating the repository metadata, we could look for RPM providing this path and include it into the main metadata. This would blow the metadata a bit, but it would allow to not care about the full file list at all. Of course that would mean `dnf install /some/random/path` won't work universally, but 1) I don't think this is widely used for random stuff 2) it is easy to detect and download the full file list instead if needed. Should I open request against createrepo_c? Vít I don't know if libsolv/dnf look at that data at all, the architecture is so drastically different compared to yum that the seemingly obvious lazy loading may well be very very difficult to achieve. I remember that being the case with apt-rpm (if anybody remembers *that* old beast) whose operational model was closer to libsolv than yum. - Panu - - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 37 compose report: 20221006.n.0 changes
OLD: Fedora-37-20221005.n.0 NEW: Fedora-37-20221006.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-37-20221006.n.0.aarch64.tar.xz = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is a file dependency appropriate?
On 10/6/22 11:55, Vít Ondruch wrote: Dne 06. 10. 22 v 9:18 Otto Liljalaakso napsal(a): Miro Hrončok kirjoitti 6.10.2022 klo 2.33: On 06. 10. 22 1:21, Otto Liljalaakso wrote: Recently, I have run into some cases where file dependencies like Requires: /usr/bin/foo are used. In a recent thread on this mailing list [1], it is mentioned that such Requires should be avoided, because resolving file dependencies requires a large amount of memory. I don't believe that resolving file-Requires from directories listed at [2] from your email is more memory hungry. Where exactly was that said? [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/ [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies Maybe I should have re-read the thread closely before posting, because the most relevant message is this [3]: " The discussion in the bug indicates that this memory growth is related to loading of the full filepath dataset. We have been discussing splitting out the non-primary-filepath-data (i.e. paths that are not /etc, /usr/bin, /usr/sbin), out into a separate lazilly-loaded file. If we manage to do that, we'll kill two birds with one stone: - initial download of repo metadata on every freakin' dnf operation can go down from 80 to 20 MB - the peak memory use will go down " Which exactly confirms what you say. I am still wondering a bit if there is something else bad about file dependencies? If I am not mistaken, in the YUM days, the file list was split into two parts. One list contained several high profile directories such as /usr/bin [1] while the other contained everything. By default YUM have not loaded the full file list by default, just the short one. The data were not loaded by default. But AFAIK, DNF always loads everything and it does not look that this would change. This is one BZ which comes to my mind for a reference: https://bugzilla.redhat.com/show_bug.cgi?id=968006 IOW for your example, the file dependency was always supported (and IMO preferable). It probably does not matter these days, unless you really consider memory consumption (and I don't think we should generally avoid the file dependencies just on the base of memory consumption). In the yum days, certain locations of the file list, such as /usr/bin were embedded in the main data. They're still there, look for entries in primary.xml. I don't know if libsolv/dnf look at that data at all, the architecture is so drastically different compared to yum that the seemingly obvious lazy loading may well be very very difficult to achieve. I remember that being the case with apt-rpm (if anybody remembers *that* old beast) whose operational model was closer to libsolv than yum. - Panu - - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedocal] Reminder meeting : ELN SIG
Dear all, You are kindly invited to the meeting: ELN SIG on 2022-10-07 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/10133/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20221006.n.0 changes
OLD: Fedora-Rawhide-20221005.n.0 NEW: Fedora-Rawhide-20221006.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 4 Dropped packages:6 Upgraded packages: 194 Downgraded packages: 0 Size of added packages: 4.11 MiB Size of dropped packages:1.06 MiB Size of upgraded packages: 2.29 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 10.73 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server_KVM qcow2 s390x Path: Server/s390x/images/Fedora-Server-KVM-Rawhide-20221006.n.0.s390x.qcow2 = DROPPED IMAGES = = ADDED PACKAGES = Package: QXlsx-1.4.4-2.fc38 Summary: Excel/XLSX file reader/writer library for Qt RPMs:QXlsx QXlsx-devel Size:1.42 MiB Package: iir1-1.9.3-1.fc38 Summary: DSP IIR Realtime C++ filter library RPMs:iir1 iir1-devel iir1-devel-doc Size:1.25 MiB Package: pageedit-1.9.20-1.fc38 Summary: ePub visual XHTML editor RPMs:pageedit Size:1.24 MiB Package: pstreams-devel-1.0.3-6.fc38 Summary: POSIX Process Control in C++ RPMs:pstreams-devel pstreams-doc Size:209.43 KiB = DROPPED PACKAGES = Package: libcxxabi-15.0.0-2.fc38 Summary: Low level support for a standard C++ library RPMs:libcxxabi libcxxabi-devel libcxxabi-static Size:898.61 KiB Package: perl-Type-Tie-0.015-9.fc37 Summary: Tie a variable to a type constraint RPMs:perl-Type-Tie Size:28.68 KiB Package: php-firephp-firephp-core-0.5.3-1.fc36 Summary: Minimal library for sending PHP variables to browsers RPMs:php-firephp-firephp-core Size:27.42 KiB Package: rust-enum-as-inner0.3-0.3.4-2.fc37 Summary: Proc-macro for deriving inner field accessor functions on enums RPMs:rust-enum-as-inner0.3+default-devel rust-enum-as-inner0.3-devel Size:27.10 KiB Package: rust-phf_shared0.7-0.7.24-6.fc37 Summary: Support code shared by PHF libraries RPMs:rust-phf_shared0.7+core-devel rust-phf_shared0.7+default-devel rust-phf_shared0.7+unicase-devel rust-phf_shared0.7-devel Size:33.62 KiB Package: rust-socket2_0.3-0.3.19-4.fc37 Summary: Utilities for handling networking sockets RPMs:rust-socket2_0.3+default-devel rust-socket2_0.3+pair-devel rust-socket2_0.3+reuseport-devel rust-socket2_0.3+unix-devel rust-socket2_0.3-devel Size:71.97 KiB = UPGRADED PACKAGES = Package: ClanLib-2.3.7-27.fc38 Old package: ClanLib-2.3.7-26.fc37 Summary: Cross platform C++ game library RPMs: ClanLib ClanLib-devel Size: 462.84 MiB Size change: -46.97 KiB Changelog: * Wed Oct 05 2022 Hans de Goede - 2.3.7-27 - Stop building clanRegExp lib, pcre1 is no longer maintained (rhbz#2128277) Package: avocado-vt-82.0-3.module_f38+15479+30bb558c Old package: avocado-vt-82.0-3.module_f38+15459+2a10b5c5 Summary: Avocado Virt Test Plugin RPMs: python3-avocado-vt Size: 8.70 MiB Size change: 4 B Package: azure-cli-2.40.0-2.fc38 Old package: azure-cli-2.40.0-1.fc38 Summary: Microsoft Azure Command-Line Tools RPMs: azure-cli python3-azure-cli-core python3-azure-cli-telemetry python3-azure-cli-testsdk Size: 6.44 MiB Size change: 426 B Changelog: * Wed Oct 05 2022 Major Hayden 2.40.0-2 - Add subparser patch Package: bash-5.2.0-2.fc38 Old package: bash-5.1.16-4.fc38 Summary: The GNU Bourne Again shell RPMs: bash bash-devel bash-doc Size: 13.43 MiB Size change: 903.22 KiB Changelog: * Tue Oct 04 2022 Siteshwar Vashisht - 5.2.0-1 - Update to bash-5.2 Resolves: #2129927 * Wed Oct 05 2022 Siteshwar Vashisht - 5.2.0-2 - Bump version number Related: #2129927 Package: catatonit-0.1.7-10.fc38 Old package: catatonit-0.1.7-7.fc37 Summary: A signal-forwarding process manager for containers RPMs: catatonit Size: 1.43 MiB Size change: -962 B Changelog: * Tue Aug 16 2022 Lokesh Mandvekar 0.1.7-8 - Fix debbuild maintainer issue * Wed Aug 17 2022 Lokesh Mandvekar 0.1.7-9 - use easier tag macros to make both fedora and debbuild happy * Wed Oct 05 2022 Lokesh Mandvekar 0.1.7-10 - remove debbuild macros to comply with Fedora guidelines Package: cfn-lint-0.66.1-1.fc38 Old package: cfn-lint-0.65.1-1.fc38 Summary: CloudFormation Linter RPMs: cfn-lint Size: 2.53 MiB Size change: 41.89 KiB Changelog: * Wed Oct 05 2022 Benjamin A. Beasley 0.66.1-1 - Update to 0.66.1 (close RHBZ#2131077) Package: chkconfig-1.21-1.fc38 Old package: chkconfig-1.19-3.fc37 Summary: A system tool for maintaining the /etc/rc*.d hierarchy RPMs: alternatives chkconfig ntsysv Size: 961.31 KiB Size change: 22.68 KiB Changelog: * Wed Oct 05 2022 Jan Macku - 1.21-1 - ci: Add CodeQL to replace LGTM - alternatives: replace master/slave with leader/follower - chkconfig: use correct cmp function - Bump redhat-plumbers-in-action/differential-shellcheck from 2 to 3 - ci
Re: Grub menu with 3 kernels by default
On Thu, Oct 06, 2022 at 10:13:58AM +0200, Hans de Goede wrote: > Hi, > > On 10/5/22 23:07, Chris Murphy wrote: > > > > > > On Wed, Oct 5, 2022, at 3:01 PM, Vít Ondruch wrote: > >> > >> 3. "Boot menu" in GUI? Given that one can reach the GUI, why it should > >> not be possible to choose the boot entry for next boot? Or even choose > >> to open FW setup. > > > > This could solve this other problem too. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2049849 > > > > The GUI tool can use efibootmgr to set bootnext or even bootorder. > > Right, this is definitely interesting. > > sdboot already offers some nice features for this. > > bootctl --list: shows available boot menu entries > systemctl reboot --boot-loader-entry=ID: select which entry to boot > > And I believe that there are also dbus equivalents of this. > > If we want this we should consider either switching > to sdboot or make grub support: > https://systemd.io/BOOT_LOADER_INTERFACE/ > > And then this is something which could be an upstream GNOME feature > using the systemd DBUS APIs for this. > > The only problem is that this requires someone to make time to > work on this... > > I personally believe that for the Fedora workstation case > it makes sense to just switch to sdboot for EFI installs > giving us nice features like this; while at the same time > offering a much simpler code-base then grub, which is > good from a secureboot POV. Providing an alternative to the use of grub is inevitable IMHO from a SecureBoot and/or Confidential virtualization POV. The way grub has to write its entire grub.conf into the TPM PCRs is totally impractical for anyone wishing to maintain attestation policies to verify the OS boot state from the TPM eventlog. sd-boot's usage of TPM PCRs when combined with unified kernel images is massively simpler & saner to handle. So at very least I'd see sd-boot being an option alongside grub, and there's a decent case to be made for it to even be the default in at least some scenarios. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Grub menu with 3 kernels by default
On 06-10-2022 10:13, Hans de Goede wrote: Hi, On 10/5/22 23:07, Chris Murphy wrote: On Wed, Oct 5, 2022, at 3:01 PM, Vít Ondruch wrote: 3. "Boot menu" in GUI? Given that one can reach the GUI, why it should not be possible to choose the boot entry for next boot? Or even choose to open FW setup. This could solve this other problem too. https://bugzilla.redhat.com/show_bug.cgi?id=2049849 The GUI tool can use efibootmgr to set bootnext or even bootorder. Right, this is definitely interesting. sdboot already offers some nice features for this. bootctl --list: shows available boot menu entries systemctl reboot --boot-loader-entry=ID: select which entry to boot And I believe that there are also dbus equivalents of this. If we want this we should consider either switching to sdboot or make grub support: https://systemd.io/BOOT_LOADER_INTERFACE/ +1 for making sd-boot the default bootloader on EFI. I would prefer that to making grub wrap around sd-boot, so to speak. But I'm sure there's more to it than simply switching. -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is a file dependency appropriate?
Dne 06. 10. 22 v 10:55 Vít Ondruch napsal(a): Dne 06. 10. 22 v 9:18 Otto Liljalaakso napsal(a): Miro Hrončok kirjoitti 6.10.2022 klo 2.33: On 06. 10. 22 1:21, Otto Liljalaakso wrote: Recently, I have run into some cases where file dependencies like Requires: /usr/bin/foo are used. In a recent thread on this mailing list [1], it is mentioned that such Requires should be avoided, because resolving file dependencies requires a large amount of memory. I don't believe that resolving file-Requires from directories listed at [2] from your email is more memory hungry. Where exactly was that said? [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/ [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies Maybe I should have re-read the thread closely before posting, because the most relevant message is this [3]: " The discussion in the bug indicates that this memory growth is related to loading of the full filepath dataset. We have been discussing splitting out the non-primary-filepath-data (i.e. paths that are not /etc, /usr/bin, /usr/sbin), out into a separate lazilly-loaded file. If we manage to do that, we'll kill two birds with one stone: - initial download of repo metadata on every freakin' dnf operation can go down from 80 to 20 MB - the peak memory use will go down " Which exactly confirms what you say. I am still wondering a bit if there is something else bad about file dependencies? If I am not mistaken, in the YUM days, the file list was split into two parts. One list contained several high profile directories such as /usr/bin [1] while the other contained everything. By default YUM have not loaded the full file list by default, just the short one. The data were not loaded by default. But AFAIK, DNF always loads everything and it does not look that this would change. This is one BZ which comes to my mind for a reference: https://bugzilla.redhat.com/show_bug.cgi?id=968006 BTW re-reading the ticket and since there are talks about DNF5, maybe it would be worth of reopening the discussion. I think we could generally do better and I see two options: 1) There seems to be a way to download additional data if needed 2) The metadata we provide in reposotories could be better. I.e. instead of providing full file list, it could be actually enough to collect just the files of the interest. E.g. if there is somewhere `BR: /usr/bin/foo`, then during preparation of repo data, there could be file list with record for bar package, providing entry such as "/usr/bin/foo: bar". This would probably not require any big changes in DNF IMHO. Vít IOW for your example, the file dependency was always supported (and IMO preferable). It probably does not matter these days, unless you really consider memory consumption (and I don't think we should generally avoid the file dependencies just on the base of memory consumption). Vít [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies I was asked not to use those in a recent package review [4]. Maybe that was just a reviewer preference then, and not based on any benefit for the distribution? [3]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QOQQNVN4JPJOAVUBJJM4XLSINPTOG3VE/ [4]: https://bugzilla.redhat.com/show_bug.cgi?id=2115066 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is a file dependency appropriate?
Dne 06. 10. 22 v 9:18 Otto Liljalaakso napsal(a): Miro Hrončok kirjoitti 6.10.2022 klo 2.33: On 06. 10. 22 1:21, Otto Liljalaakso wrote: Recently, I have run into some cases where file dependencies like Requires: /usr/bin/foo are used. In a recent thread on this mailing list [1], it is mentioned that such Requires should be avoided, because resolving file dependencies requires a large amount of memory. I don't believe that resolving file-Requires from directories listed at [2] from your email is more memory hungry. Where exactly was that said? [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/ [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies Maybe I should have re-read the thread closely before posting, because the most relevant message is this [3]: " The discussion in the bug indicates that this memory growth is related to loading of the full filepath dataset. We have been discussing splitting out the non-primary-filepath-data (i.e. paths that are not /etc, /usr/bin, /usr/sbin), out into a separate lazilly-loaded file. If we manage to do that, we'll kill two birds with one stone: - initial download of repo metadata on every freakin' dnf operation can go down from 80 to 20 MB - the peak memory use will go down " Which exactly confirms what you say. I am still wondering a bit if there is something else bad about file dependencies? If I am not mistaken, in the YUM days, the file list was split into two parts. One list contained several high profile directories such as /usr/bin [1] while the other contained everything. By default YUM have not loaded the full file list by default, just the short one. The data were not loaded by default. But AFAIK, DNF always loads everything and it does not look that this would change. This is one BZ which comes to my mind for a reference: https://bugzilla.redhat.com/show_bug.cgi?id=968006 IOW for your example, the file dependency was always supported (and IMO preferable). It probably does not matter these days, unless you really consider memory consumption (and I don't think we should generally avoid the file dependencies just on the base of memory consumption). Vít [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies I was asked not to use those in a recent package review [4]. Maybe that was just a reviewer preference then, and not based on any benefit for the distribution? [3]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QOQQNVN4JPJOAVUBJJM4XLSINPTOG3VE/ [4]: https://bugzilla.redhat.com/show_bug.cgi?id=2115066 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Grub menu with 3 kernels by default
Hi, On 10/5/22 23:07, Chris Murphy wrote: > > > On Wed, Oct 5, 2022, at 3:01 PM, Vít Ondruch wrote: >> >> 3. "Boot menu" in GUI? Given that one can reach the GUI, why it should >> not be possible to choose the boot entry for next boot? Or even choose >> to open FW setup. > > This could solve this other problem too. > > https://bugzilla.redhat.com/show_bug.cgi?id=2049849 > > The GUI tool can use efibootmgr to set bootnext or even bootorder. Right, this is definitely interesting. sdboot already offers some nice features for this. bootctl --list: shows available boot menu entries systemctl reboot --boot-loader-entry=ID: select which entry to boot And I believe that there are also dbus equivalents of this. If we want this we should consider either switching to sdboot or make grub support: https://systemd.io/BOOT_LOADER_INTERFACE/ And then this is something which could be an upstream GNOME feature using the systemd DBUS APIs for this. The only problem is that this requires someone to make time to work on this... I personally believe that for the Fedora workstation case it makes sense to just switch to sdboot for EFI installs giving us nice features like this; while at the same time offering a much simpler code-base then grub, which is good from a secureboot POV. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Grub menu with 3 kernels by default
Hi, On 10/5/22 20:56, Christopher Klooz wrote: > > On 05/10/2022 20:28, Hans de Goede wrote: >> Hi, >> >> On 10/5/22 19:59, Christopher Klooz wrote: >>> On 05/10/2022 18:39, Christopher Klooz wrote: On 05/10/2022 17:33, Chris Murphy wrote: > On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote: > >> However, on ask.fp, a user mentioned that the grub menu is no longer >> enabled by default on single boot systems so that changing the kernel is >> no longer easily possible, and put forward >> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for >> this argument. Yet, the article indicates that the argument is not fully >> correct and even with single boot installations, SHIFT can be used to >> get into the grub menu. > I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, > because it's reserved by UEFI firmware for one of its menus. And SHIFT > has never worked. Maybe Esc or TAB? >> Holding left shift is the easiest method, but with firmware being >> firmware does not work on all systems. >> >> What does always work is ESC or F8, Fedora's grub supports both to >> show the menu. On some systems one of those key get intercepted by >> the firmware which is why there are 2 choices. >> > Given this inconsistency, I have a mixed opinion of the hidden GRUB menu. > > Me, too. Especially as it makes support more problematic for unexperiened users. It is easy to say that people should push another kernel when they see the grub menu. They see text, and I can tell them which text to choose. But with unexperiened users, telling when to push tab/esc/shift/F8 can already need to start an elaboration of what "boot" means and when this happens and so on. Such elaborations are already annoying for them (and for the supporters). >> The menu automatically unhides after a failed boot. Just blindly >> doing ctrl + alt + f4 followed by ctrl + alt + delete; or just >> power-cycling the machine counts as a failed boot. > Many problems that can occur do not cause a failed boot. This starts with the > current issue in 5.19.12. Assuming the current issue causes users to not be able to login, it does count as a failed boot. On Fedora workstation a successful boot is the user loging in in gdm and the user session then lasting at least 2 minutes. Or the user shuttingdown/rebooting the machine from the GNOME system menu. Anything else counts as a failure. > Another widespread issue is that users have problems with a piece of hardware > (e.g., bluetooth controller), or with modules causing unintended behavior > with one kernel (freeze, slow, something like wifi or bluetooth does not > work, other acpi issues, and so on). All that does not necessarily cause > failed boots, but is widespread among our "user base" at ask.fp especially > because Fedora is used on much different hardware, and some needs > additionally external modules. If a user can interact with gdm / GNOME then they can keep left-alt pressed while on the confirm you want to reboot screen, this will visible change "Restart" into "Boot Options" and clicking "Boot Options" (while keeping left-lat pressed) will then cause the grub menu to show for 60 seconds the next boot. Also power-cycling / ctrl+alt+del rebooting from a text virtual console without logging in will show the menu on the next boot. I have put a lot of effort in making it easy for users to still get the menu if necessary. To me it seems the biggest problem is users not being aware of the various options to get the menu when they need it. Also I want to point out that the reason which started this thread, the phoronix post about LCD panels possibly getting damages is mostly scare-mongering. Yes theoretically LCD panels might get damaged but there have been 0 reports about this and this is already fixed now. In my experience making policy changes as a sort of shooting from the hip reaction to a specific incident is usually a bad idea. For an extreme example of this see how 9-11 has got us all sort of draconian surveillance laws all over the world. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is a file dependency appropriate?
Miro Hrončok kirjoitti 6.10.2022 klo 2.33: On 06. 10. 22 1:21, Otto Liljalaakso wrote: Recently, I have run into some cases where file dependencies like Requires: /usr/bin/foo are used. In a recent thread on this mailing list [1], it is mentioned that such Requires should be avoided, because resolving file dependencies requires a large amount of memory. I don't believe that resolving file-Requires from directories listed at [2] from your email is more memory hungry. Where exactly was that said? [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/ [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies Maybe I should have re-read the thread closely before posting, because the most relevant message is this [3]: " The discussion in the bug indicates that this memory growth is related to loading of the full filepath dataset. We have been discussing splitting out the non-primary-filepath-data (i.e. paths that are not /etc, /usr/bin, /usr/sbin), out into a separate lazilly-loaded file. If we manage to do that, we'll kill two birds with one stone: - initial download of repo metadata on every freakin' dnf operation can go down from 80 to 20 MB - the peak memory use will go down " Which exactly confirms what you say. I am still wondering a bit if there is something else bad about file dependencies? I was asked not to use those in a recent package review [4]. Maybe that was just a reviewer preference then, and not based on any benefit for the distribution? [3]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QOQQNVN4JPJOAVUBJJM4XLSINPTOG3VE/ [4]: https://bugzilla.redhat.com/show_bug.cgi?id=2115066 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
