Fedora-Cloud-33-20210407.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210406.0): ID: 846159 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/846159 ID: 846166 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/846166 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Gating feedback from early adopters after almost 2 years: It doesn't seem to work
Hello, I was torn whether to share this here or not. I don't want to be the one who always complains about things, but at the end I've decided that without honest feedback, there cannot be progress (and I've realized I already am that guy). Please don't take this feedback personally, I know that building things is hard. I don't criticize people, but the tools. Almost 2 years ago, we've decided to be the early adopters of gating in Fedora with the python-virtualenv package: https://src.fedoraproject.org/rpms/python-virtualenv/c/66b7533376f Gating has proved more problematic than useful. It almost never works reliably, the problems are impossible to decipher and/or debug. Too often we had to ask for a CI-expert human intervention or straight out waive the results. The humans we've contacted were always very friendly, helpful and they were able to solve our issues. However, human-operated CIs unfortunately don't scale very well. At first, we assumed the issues will get ironed out with time, but there seem to be no visible progress. Moreover, the gating caught 0 issues, because we already test our changes via Pull Requests. I'm not sure if others have similar experience, or if we just got unlucky :( After a very bumpy ride, we've now removed the (quite incomprehensible) gating config, because frankly, it just gets in the way: https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/39 We will continue to run the CI in pull requests (which isn't perfect either but at least we have redundancy and we see visible progress there over time) and to run tests in %check (which works perfectly, but has many unfortunate limitations). Let me be 100% clear: The situation wrt CI is complex and brings many interesting challenges, but if I compare it with the dark ages before that, I would not trade. Thank you everybody for making Fedora a better place to contribute to. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Offering strongswan for (co)maintaining
Thanks, added you both. Anyone with direct feedback from people using it is quite welcome. On 3/31/21 7:38 PM, Michel Alexandre Salim wrote: > Hi Petr, > > On Wed, 2021-03-31 at 14:12 +0200, Petr Menšík wrote: >> Hello, >> >> strongswan and NetworkManager-strongswan packages were passed to me >> from >> previous maintainer. I admit I have little experience with them and >> do >> not run any service based on them. Because IPSsec is quite complex >> technology, I am looking for help with its maintenance. I was always >> using OpenVPN based solutions myself, so I guess I am not the best >> person as main admin. I would like to transfer main admin to anyone >> doing a good job, not not immediately. That is why I haven't orphaned >> it >> already. >> > We use this at work, could you add these FASes? > - salimma (Michel) > - dcavalca (Davide Cavalca) > > Davide did a PR for strongswan recently. > > Likewise, we don't want to be main admins immediately either, but would > like to help comaintaining. We can channel requests from the internal > team that directly uses it. > > > Best regards, > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
On 4/6/21 7:40 PM, Vít Ondruch wrote:
Dne 06. 04. 21 v 16:02 Panu Matilainen napsal(a):
On 4/6/21 1:36 PM, Miro Hrončok wrote:
For example, what is common for Python "namepsace" packages, e.g.
pkg_name.foo.
1) We want to test installed files, not what is in $PWD, so we set
PYTHONPATH to
%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
(try hard to) exclude $PWD from it. This is crucial to ensure the
files
we actually ship are working and the installed file set is complete.
Our macros do this for the packagers.
2) The %{python3_site...}/pkg_name/ directory and
%{python3_site...}/pkg_name/__init__.py and
%{python3_site...}/pkg_name/__pycache__/ and
%{python3_site...}/pkg_name/__pycache__/__init__...pyc
files must be present in %{buildroot} to successfully run the tests.
3) The files from (2) must be excluded from the package because
*pkg_name* owns
them, not *pkg_name.foo*.
We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
The files are not bit-by-bit+metadata identical,
so both packages cannot ship them.
This seems like a fairly exotic case to me - okay, a Python-peculiar
problem. And a problem of stepping (not saying crossing, because I'm
not sure it is) on the boundaries of the %check use-case I suppose.
%ghost'ing the files might be one option - I don't know about the Ruby
cache case beyond that there is one.
There is only `%{gem_cache}` (I assume it was mentioned in the context
of `%exclude`, because that has nothing to do with testing). Not
shipping this file is enough and we don't ship it just because we don't
want to ship file which looks like upstream file but it is not the
original upstream file. Moreover we don't really need it for the
purposes it is used by upstream, which is restoring the original state
of the library.
Ah, okay, it's an entirely different case then. Does this file ever get
created when running the installed software (by root)? If so, then
%ghost'ing it would seem to be the right thing.
If it's just something that needs to be scrubbed on each and every ruby
package ever built, we could always add a buildroot policy for it. Just
like we could automatically clean .la files rather than manually clean
them in thousands of packages...
But since Ruby was mentioned there, we generally run test suite in
`%{_builddir}` (and there are (unfortunately) two possible location,
while only one is preferred). Generally, it could be run in
`%{buildroot}` with similar results, but it should be discouraged due to
possible `%{buildroot}` pollution.
Ok, good. Indeed, buildroot should not be used by %check because it can
and often does have side-effects.
I'm starting to think the right thing to do is to move %check to run
after %build rather than %install. That would completely eliminate
arguments over what is proper use and should this or that be done etc.
- 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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
On 4/7/21 11:45 AM, Panu Matilainen wrote:
On 4/6/21 7:40 PM, Vít Ondruch wrote:
Dne 06. 04. 21 v 16:02 Panu Matilainen napsal(a):
On 4/6/21 1:36 PM, Miro Hrončok wrote:
For example, what is common for Python "namepsace" packages, e.g.
pkg_name.foo.
1) We want to test installed files, not what is in $PWD, so we set
PYTHONPATH to
%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
(try hard to) exclude $PWD from it. This is crucial to ensure
the files
we actually ship are working and the installed file set is
complete.
Our macros do this for the packagers.
2) The %{python3_site...}/pkg_name/ directory and
%{python3_site...}/pkg_name/__init__.py and
%{python3_site...}/pkg_name/__pycache__/ and
%{python3_site...}/pkg_name/__pycache__/__init__...pyc
files must be present in %{buildroot} to successfully run the
tests.
3) The files from (2) must be excluded from the package because
*pkg_name* owns
them, not *pkg_name.foo*.
We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
The files are not bit-by-bit+metadata identical,
so both packages cannot ship them.
This seems like a fairly exotic case to me - okay, a Python-peculiar
problem. And a problem of stepping (not saying crossing, because I'm
not sure it is) on the boundaries of the %check use-case I suppose.
%ghost'ing the files might be one option - I don't know about the
Ruby cache case beyond that there is one.
There is only `%{gem_cache}` (I assume it was mentioned in the context
of `%exclude`, because that has nothing to do with testing). Not
shipping this file is enough and we don't ship it just because we
don't want to ship file which looks like upstream file but it is not
the original upstream file. Moreover we don't really need it for the
purposes it is used by upstream, which is restoring the original state
of the library.
Ah, okay, it's an entirely different case then. Does this file ever get
created when running the installed software (by root)? If so, then
%ghost'ing it would seem to be the right thing.
If it's just something that needs to be scrubbed on each and every ruby
package ever built, we could always add a buildroot policy for it. Just
like we could automatically clean .la files rather than manually clean
them in thousands of packages...
But since Ruby was mentioned there, we generally run test suite in
`%{_builddir}` (and there are (unfortunately) two possible location,
while only one is preferred). Generally, it could be run in
`%{buildroot}` with similar results, but it should be discouraged due
to possible `%{buildroot}` pollution.
Ok, good. Indeed, buildroot should not be used by %check because it can
and often does have side-effects.
I'm starting to think the right thing to do is to move %check to run
after %build rather than %install. That would completely eliminate
arguments over what is proper use and should this or that be done etc.
https://github.com/rpm-software-management/rpm/pull/1618
- 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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
On 07. 04. 21 10:45, Panu Matilainen wrote: I'm starting to think the right thing to do is to move %check to run after %build rather than %install. That would completely eliminate arguments over what is proper use and should this or that be done etc. This is what I don't understand: The current %exclude change is backwards incompatible and breaks things. How does breaking it even more help this problem? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
On 4/7/21 12:06 PM, Miro Hrončok wrote: On 07. 04. 21 10:45, Panu Matilainen wrote: I'm starting to think the right thing to do is to move %check to run after %build rather than %install. That would completely eliminate arguments over what is proper use and should this or that be done etc. This is what I don't understand: The current %exclude change is backwards incompatible and breaks things. How does breaking it even more help this problem? Because they kinda go together: the %exclude change revealed that %check is being used in ways it wasn't really intended to be used - just like %exclude was - and both "abuses" come with unwanted side-effects (note quotes, while I know the internal intention, the intended uses were never clearly documented anywhere) Further rationale at https://github.com/rpm-software-management/rpm/pull/1618 - 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
On 4/7/21 11:38 AM, Panu Matilainen wrote: On 4/7/21 12:06 PM, Miro Hrončok wrote: On 07. 04. 21 10:45, Panu Matilainen wrote: I'm starting to think the right thing to do is to move %check to run after %build rather than %install. That would completely eliminate arguments over what is proper use and should this or that be done etc. This is what I don't understand: The current %exclude change is backwards incompatible and breaks things. How does breaking it even more help this problem? Because they kinda go together: the %exclude change revealed that %check is being used in ways it wasn't really intended to be used - just like %exclude was - and both "abuses" come with unwanted side-effects (note quotes, while I know the internal intention, the intended uses were never clearly documented anywhere) Further rationale at https://github.com/rpm-software-management/rpm/pull/1618 I understand wanting a perfect system, but I think it's important to realize that rpm is a tool for maintainers to simplify their life and make packaging other software possible. What you're proposing now is to break thousands of packages with no advanced warning, no migration path, just because they're using rpm in a way that wasn't predicted. Please don't do this. If you really want to introduce such backwards incompatible changes, please first work with us maintainers on the migration path and a reasonable timeline to do so. Tomas - 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
On 4/7/21 1:12 PM, Tomas Orsava wrote: On 4/7/21 11:38 AM, Panu Matilainen wrote: On 4/7/21 12:06 PM, Miro Hrončok wrote: On 07. 04. 21 10:45, Panu Matilainen wrote: I'm starting to think the right thing to do is to move %check to run after %build rather than %install. That would completely eliminate arguments over what is proper use and should this or that be done etc. This is what I don't understand: The current %exclude change is backwards incompatible and breaks things. How does breaking it even more help this problem? Because they kinda go together: the %exclude change revealed that %check is being used in ways it wasn't really intended to be used - just like %exclude was - and both "abuses" come with unwanted side-effects (note quotes, while I know the internal intention, the intended uses were never clearly documented anywhere) Further rationale at https://github.com/rpm-software-management/rpm/pull/1618 I understand wanting a perfect system, but I think it's important to realize that rpm is a tool for maintainers to simplify their life and make packaging other software possible. What you're proposing now is to break thousands of packages with no advanced warning, no migration path, just because they're using rpm in a way that wasn't predicted. Please don't do this. If you really want to introduce such backwards incompatible changes, please first work with us maintainers on the migration path and a reasonable timeline to do so. Isn't that exactly what we're doing here? The %check PR may or may not go in, it was linked here so people have a chance to discuss it. Because there's this just discovered linkage between %exclude and %check uses, it probably makes sense for them to go in together. Which could mean doing both, or neither, in 4.17. As in, reverting the %exclude change in 4.17 is entirely possible if it makes sense in the grand scheme things. We cannot possibly know what all the tens of thousands of packages out there are doing, and people will only ever wake up when the change is about to hit them. We've done a dozens of similar changes not because it's fun or because I enjoy getting yelled at for breaking their stuff but because there's no other way to fix ambiguity than making it unambiguous. - 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-32-20210407.0 compose check report
No missing expected images. Failed openQA tests: 1/7 (aarch64) New failures (same test not failed in Fedora-Cloud-32-20210406.0): ID: 846664 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/846664 Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20210406.0): ID: 846657 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/846657 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210407.n.0 changes
OLD: Fedora-Rawhide-20210406.n.0 NEW: Fedora-Rawhide-20210407.n.0 = SUMMARY = Added images:2 Dropped images: 5 Added packages: 10 Dropped packages:1 Upgraded packages: 248 Downgraded packages: 0 Size of added packages: 4.81 MiB Size of dropped packages:27.72 KiB Size of upgraded packages: 8.00 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 41.36 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210407.n.0.x86_64.vagrant-libvirt.box Image: Scientific vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210407.n.0.x86_64.vagrant-virtualbox.box = DROPPED IMAGES = Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-Rawhide-20210406.n.0.armhfp.raw.xz Image: Server raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-Rawhide-20210406.n.0.armhfp.raw.xz Image: Minimal raw-xz armhfp Path: Spins/armhfp/images/Fedora-Minimal-Rawhide-20210406.n.0.armhfp.raw.xz Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20210406.n.0.iso Image: Xfce raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-Rawhide-20210406.n.0.armhfp.raw.xz = ADDED PACKAGES = Package: golang-github-insomniacslk-termhook-0-0.1.20210406gita267c97.fc35 Summary: Simple terminal that allows attaching hooks RPMs:golang-github-insomniacslk-termhook golang-github-insomniacslk-termhook-devel Size:3.04 MiB Package: golang-github-pkg-diff-0-0.1.20210406git20ebb0f.fc35 Summary: Create, modify, and print diffs RPMs:golang-github-pkg-diff golang-github-pkg-diff-devel Size:57.87 KiB Package: golang-mvdan-editorconfig-0.2.0-1.fc35 Summary: EditorConfig support in Go RPMs:golang-mvdan-editorconfig-devel Size:17.22 KiB Package: logitech-27mhz-keyboard-encryption-setup-0.1-1.fc35 Summary: Logitech 27MHz keyboard encryption setup tool RPMs:logitech-27mhz-keyboard-encryption-setup Size:108.15 KiB Package: nwg-panel-0.2.1-1.fc35 Summary: GTK3-based panel for sway window manager RPMs:nwg-panel Size:120.83 KiB Package: openssh-ldap-authkeys-0.1.0~git20200205.aee4c46-2.fc35 Summary: Python script to generate SSH authorized_keys files using an LDAP directory RPMs:openssh-ldap-authkeys Size:35.74 KiB Package: php-doctrine-deprecations-0.5.3-2.fc35 Summary: A small layer on top of trigger_error or PSR-3 logging RPMs:php-doctrine-deprecations Size:13.57 KiB Package: python-drgn-0.0.11-2.fc35 Summary: Scriptable debugger library RPMs:drgn drgn-doc Size:1.04 MiB Package: python-nashpy-0.0.21-1.fc35 Summary: A library to compute equilibria of 2 player normal form games RPMs:python-nashpy-doc python3-nashpy Size:334.41 KiB Package: rust-cryptoki-0.1.1-1.fc35 Summary: Rust-native wrapper around the PKCS #11 API RPMs:rust-cryptoki+default-devel rust-cryptoki+generate-bindings-devel rust-cryptoki+psa-crypto-conversions-devel rust-cryptoki+psa-crypto-devel rust-cryptoki-devel Size:68.61 KiB = DROPPED PACKAGES = Package: mate-optimus-20.04.0-3.fc34 Summary: NVIDIA Optimus GPU switcher RPMs:mate-optimus Size:27.72 KiB = UPGRADED PACKAGES = Package: HepMC3-3.2.3-3.fc35 Old package: HepMC3-3.2.3-2.fc34 Summary: C++ Event Record for Monte Carlo Generators RPMs: HepMC3 HepMC3-devel HepMC3-doc HepMC3-interfaces-devel HepMC3-rootIO HepMC3-rootIO-devel HepMC3-search HepMC3-search-devel python3-HepMC3 python3-HepMC3-rootIO python3-HepMC3-search Size: 48.27 MiB Size change: -10.98 KiB Changelog: * Tue Apr 06 2021 Mattias Ellert - 3.2.3-3 - Rebuild for root 6.22.08 Package: R-broom-0.7.6-1.fc35 Old package: R-broom-0.7.5-1.fc35 Summary: Convert Statistical Objects into Tidy Tibbles RPMs: R-broom Size: 1.72 MiB Size change: -12.57 KiB Changelog: * Tue Apr 06 2021 Elliott Sales de Andrade - 0.7.6-1 - Update to latest version (#1946374) Package: R-cli-2.4.0-1.fc35 Old package: R-cli-2.3.1-1.fc35 Summary: Helpers for Developing Command Line Interfaces RPMs: R-cli Size: 524.52 KiB Size change: 29.84 KiB Changelog: * Tue Apr 06 2021 Elliott Sales de Andrade - 2.4.0-1 - Update to latest version (#1946272) Package: R-pkgcache-1.2.0-1.fc35 Old package: R-pkgcache-1.1.1-2.fc34 Summary: Cache 'CRAN'-Like Metadata and R Packages RPMs: R-pkgcache Size: 641.31 KiB Size change: 95.59 KiB Changelog: * Tue Mar 02 2021 Elliott Sales de Andrade - 1.2.0-1 - Update to latest version (#1933854) Package: R-remotes-2.3.0-1.fc35 Old package: R-remotes-2.2.0-3.fc34 Summary: R Package Installation from Remote Repositories RPMs: R-remotes Size: 396.07 KiB Size change: 4.67 KiB Changelog: * Sat Apr 03 2021 Elliott Sales
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
On 4/7/21 12:45 PM, Panu Matilainen wrote: On 4/7/21 1:12 PM, Tomas Orsava wrote: On 4/7/21 11:38 AM, Panu Matilainen wrote: On 4/7/21 12:06 PM, Miro Hrončok wrote: On 07. 04. 21 10:45, Panu Matilainen wrote: I'm starting to think the right thing to do is to move %check to run after %build rather than %install. That would completely eliminate arguments over what is proper use and should this or that be done etc. This is what I don't understand: The current %exclude change is backwards incompatible and breaks things. How does breaking it even more help this problem? Because they kinda go together: the %exclude change revealed that %check is being used in ways it wasn't really intended to be used - just like %exclude was - and both "abuses" come with unwanted side-effects (note quotes, while I know the internal intention, the intended uses were never clearly documented anywhere) Further rationale at https://github.com/rpm-software-management/rpm/pull/1618 I understand wanting a perfect system, but I think it's important to realize that rpm is a tool for maintainers to simplify their life and make packaging other software possible. What you're proposing now is to break thousands of packages with no advanced warning, no migration path, just because they're using rpm in a way that wasn't predicted. Please don't do this. If you really want to introduce such backwards incompatible changes, please first work with us maintainers on the migration path and a reasonable timeline to do so. Isn't that exactly what we're doing here? The %check PR may or may not go in, it was linked here so people have a chance to discuss it. Because there's this just discovered linkage between %exclude and %check uses, it probably makes sense for them to go in together. Which could mean doing both, or neither, in 4.17. As in, reverting the %exclude change in 4.17 is entirely possible if it makes sense in the grand scheme things. We cannot possibly know what all the tens of thousands of packages out there are doing, and people will only ever wake up when the change is about to hit them. We've done a dozens of similar changes not because it's fun or because I enjoy getting yelled at for breaking their stuff but because there's no other way to fix ambiguity than making it unambiguous. You're right, knowing the scope of the breakage in advance is just not possible. We have similar problems with Python, but given the nature of RPM, you've got it even tougher. I really apologize if it felt like yelling, that was not my intention. However, I hope you'll understand why I felt a certain urgency when writing my response. From my own packaging experience the change would break a lot of usage, and other people on this thread only reinforced that this would be a major problem in many areas. And so when I saw that the follow up to this discussion was a PR that would break even more use cases, I grew worried. On the other hand, I understand where you're coming from: we have fought battles with unintended use of our tools too (e.g. sudo pip breaking dnf). But given the scope of the breakage here, I would advocate for postponing this change for now. It seems none of us is sure how to square this circle at the moment. All the best, Tomas - 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-35-20210407.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 2/16 (x86_64), 3/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20210406.0): ID: 846693 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/846693 ID: 846695 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay URL: https://openqa.fedoraproject.org/tests/846695 ID: 846699 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/846699 ID: 846704 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/846704 ID: 846708 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/846708 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20210406.0): ID: 846682 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/846682 Passed openQA tests: 13/16 (x86_64), 12/15 (aarch64) Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.39 to 0.26 Previous test data: https://openqa.fedoraproject.org/tests/86#downloads Current test data: https://openqa.fedoraproject.org/tests/846697#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Fedora 34 Branched 20210407.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 34 Branched 20210407.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20210329.n.0: anaconda-34.24.6-1.fc34.src, 20210407.n.0: anaconda-34.24.8-1.fc34.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/34 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210407.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210407.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210407.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210407.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210407.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210407.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210407.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20210407.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 7 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 23/189 (x86_64), 19/127 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210406.n.0): ID: 846394 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/846394 ID: 846406 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/846406 ID: 846407 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/846407 ID: 846415 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/846415 ID: 846470 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/846470 ID: 846475 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/846475 ID: 846488 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/846488 ID: 846490 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/846490 ID: 846493 Test: aarch64 Server-dvd-iso install_repository_nfs_variation@uefi URL: https://openqa.fedoraproject.org/tests/846493 ID: 846494 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/846494 ID: 846520 Test: aarch64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/846520 ID: 846521 Test: aarch64 Cloud_Base-qcow2-qcow2 base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/846521 ID: 846559 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/846559 ID: 846570 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/846570 ID: 846573 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/846573 ID: 846577 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/846577 ID: 846580 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/846580 ID: 846584 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/846584 ID: 846596 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/846596 ID: 846599 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/846599 ID: 846600 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/846600 Old failures (same test failed in Fedora-Rawhide-20210406.n.0): ID: 846350 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/846350 ID: 846351 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/846351 ID: 846354 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/846354 ID: 846363 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/846363 ID: 846368 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/846368 ID: 846375 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/846375 ID: 846381 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/846381 ID: 846382 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/846382 ID: 846411 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/846411 ID: 846466 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/846466 ID: 846467 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/846467 ID: 846471 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/846471 ID: 846482 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/846482 ID: 846486 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/846486 ID: 846528 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/846528 ID: 846603 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/846603 ID: 846632 Test:
Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)
On Tue, 6 Apr 2021 at 12:58, Peter Robinson wrote:
> On Tue, Apr 6, 2021 at 11:36 AM Neal Gompa wrote:
> >
> > On Tue, Apr 6, 2021 at 3:23 AM Clement Verna
> wrote:
> > >
> > >
> > >
> > > On Mon, 5 Apr 2021 at 20:30, Daniel Walsh wrote:
> > >>
> > >> On 4/3/21 02:34, Tomasz Torcz wrote:
> > >> > Dnia Fri, Apr 02, 2021 at 05:30:30PM -0400, Neal Gompa napisał(a):
> > >> >> On Fri, Apr 2, 2021 at 5:18 PM Lars Seipel wrote:
> > >> >>> On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:
> > >> Unless OpenShift and RKE recently changed so that containers can
> run
> > >> as root by default (as of yesterday, they didn't), this is
> solidly a
> > >> bad idea, since it makes it much more unintuitive to set up
> secure
> > >> containers conforming with the guidelines for these Kubernetes
> > >> platforms.
> > >> >>> In my experience, containers trying to run stuff from
> shadow-utils in
> > >> >>> their entrypoint/startup scripts tend to be a reason for
> containers to
> > >> >>> *not* run on OpenShift/OKD without additional adjustments.
> > >> >>>
> > >> >>> A related (and more common) issue are images that expect to run
> with a
> > >> >>> particular named user (or UID) determined during the build process
> > >> >>> (again, most likely created using shadow-utils).
> > >> >>>
> > >> >>> I'm not familiar with Rancher but at least for OpenShift, I don't
> think
> > >> >>> the availability of shadow-utils is very useful. At run time, you
> can't
> > >> >>> use the shadow-utils at all and whatever you do with it during
> build
> > >> >>> time is unlikely to be helpful (and actively harmful more often
> than
> > >> >>> not) at run time when OpenShift assigns you an arbitrary UID.
> > >> >> It's basically required for building containers that will work at
> > >> >> runtime where OpenShift assigns an arbitrary UID.
> > >> >>
> > >> >> For example, in my containers, I *build* and create a "runtime
> user"
> > >> >> with the UID 1000, and then set things up to use that context at
> the
> > >> >> end. OpenShift uses that for its dynamic UID assignment.
> > >> >But you do not need shadow-utils for that. Even OpenShift
> > >> > documentation shows simple echo is enough:
> > >> >
> > >> > if ! whoami &> /dev/null; then
> > >> >if [ -w /etc/passwd ]; then
> > >> >echo "${USER_NAME:-default}:x:$(id
> -u):0:${USER_NAME:-default} user:${HOME}:/sbin/nologin" >> /etc/passwd
> > >> >fi
> > >> > fi
> > >> >
> https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html
> > >> > (yeah, I know it's an old and obsolete version of docs)
> > >> >
> > >> What about all of the users of Docker and Podman who do?
> > >>
> > >>
> > >>
> > >> ```
> > >>
> > >> from fedora
> > >>
> > >> run useradd XYZ
> > >>
> > >> user XYZ
> > >>
> > >> ...
> > >>
> > >> ```
> > >>
> > >> Do you just break them out of the box?
> > >
> > >
> > > Yes and that's the point of the Change Proposal (ie make this more
> widely known and allow people to change their Dockerfile). This change
> would only be applied starting from the Fedora 35 base image, I don't think
> it is unreasonable to have breaking change between major version of the
> container base image.
> > >
> >
> > I think it would be unreasonable to break such a commonly established
> > pattern, though. That's enough of a reason for people to stop using
> > the Fedora base container.
>
> We do have the Base container and a Base Minimal, so maybe do it in
> the later and not the former?
>
Yes that's a good suggestion :-), I can probably make another Change for
that tho.
Based on the feedback received, I will update the change proposal to
exclude shadow-utils from the packages proposed to be removed. That way we
should be able to move on and at least remove sssd-client and util-linux ;-)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Heads Up: openexr 3.x requires new Imath library
I'm still working on the package but just wanted to give everyone a heads up and potentially find a reviewer when I'm ready :) This package includes the functions of libHalf from ilmbase and may need to obsolete that package, still need to dig in a bit more. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)
On Wed, Apr 7, 2021 at 8:12 AM Clement Verna wrote:
>
>
>
> On Tue, 6 Apr 2021 at 12:58, Peter Robinson wrote:
>>
>> On Tue, Apr 6, 2021 at 11:36 AM Neal Gompa wrote:
>> >
>> > On Tue, Apr 6, 2021 at 3:23 AM Clement Verna
>> > wrote:
>> > >
>> > >
>> > >
>> > > On Mon, 5 Apr 2021 at 20:30, Daniel Walsh wrote:
>> > >>
>> > >> On 4/3/21 02:34, Tomasz Torcz wrote:
>> > >> > Dnia Fri, Apr 02, 2021 at 05:30:30PM -0400, Neal Gompa napisał(a):
>> > >> >> On Fri, Apr 2, 2021 at 5:18 PM Lars Seipel wrote:
>> > >> >>> On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:
>> > >> Unless OpenShift and RKE recently changed so that containers can
>> > >> run
>> > >> as root by default (as of yesterday, they didn't), this is solidly
>> > >> a
>> > >> bad idea, since it makes it much more unintuitive to set up secure
>> > >> containers conforming with the guidelines for these Kubernetes
>> > >> platforms.
>> > >> >>> In my experience, containers trying to run stuff from shadow-utils
>> > >> >>> in
>> > >> >>> their entrypoint/startup scripts tend to be a reason for containers
>> > >> >>> to
>> > >> >>> *not* run on OpenShift/OKD without additional adjustments.
>> > >> >>>
>> > >> >>> A related (and more common) issue are images that expect to run
>> > >> >>> with a
>> > >> >>> particular named user (or UID) determined during the build process
>> > >> >>> (again, most likely created using shadow-utils).
>> > >> >>>
>> > >> >>> I'm not familiar with Rancher but at least for OpenShift, I don't
>> > >> >>> think
>> > >> >>> the availability of shadow-utils is very useful. At run time, you
>> > >> >>> can't
>> > >> >>> use the shadow-utils at all and whatever you do with it during build
>> > >> >>> time is unlikely to be helpful (and actively harmful more often than
>> > >> >>> not) at run time when OpenShift assigns you an arbitrary UID.
>> > >> >> It's basically required for building containers that will work at
>> > >> >> runtime where OpenShift assigns an arbitrary UID.
>> > >> >>
>> > >> >> For example, in my containers, I *build* and create a "runtime user"
>> > >> >> with the UID 1000, and then set things up to use that context at the
>> > >> >> end. OpenShift uses that for its dynamic UID assignment.
>> > >> >But you do not need shadow-utils for that. Even OpenShift
>> > >> > documentation shows simple echo is enough:
>> > >> >
>> > >> > if ! whoami &> /dev/null; then
>> > >> >if [ -w /etc/passwd ]; then
>> > >> >echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default}
>> > >> > user:${HOME}:/sbin/nologin" >> /etc/passwd
>> > >> >fi
>> > >> > fi
>> > >> > https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html
>> > >> > (yeah, I know it's an old and obsolete version of docs)
>> > >> >
>> > >> What about all of the users of Docker and Podman who do?
>> > >>
>> > >>
>> > >>
>> > >> ```
>> > >>
>> > >> from fedora
>> > >>
>> > >> run useradd XYZ
>> > >>
>> > >> user XYZ
>> > >>
>> > >> ...
>> > >>
>> > >> ```
>> > >>
>> > >> Do you just break them out of the box?
>> > >
>> > >
>> > > Yes and that's the point of the Change Proposal (ie make this more
>> > > widely known and allow people to change their Dockerfile). This change
>> > > would only be applied starting from the Fedora 35 base image, I don't
>> > > think it is unreasonable to have breaking change between major version
>> > > of the container base image.
>> > >
>> >
>> > I think it would be unreasonable to break such a commonly established
>> > pattern, though. That's enough of a reason for people to stop using
>> > the Fedora base container.
>>
>> We do have the Base container and a Base Minimal, so maybe do it in
>> the later and not the former?
>
>
> Yes that's a good suggestion :-), I can probably make another Change for that
> tho.
>
> Based on the feedback received, I will update the change proposal to exclude
> shadow-utils from the packages proposed to be removed. That way we should be
> able to move on and at least remove sssd-client and util-linux ;-)
>
I wouldn't suggest removing shadow-utils from fedora-minimal either,
because again, you are breaking a pattern people expect to have
working.
If we _really_ want to go down this rabbit hole, then we should
probably take a page out of openSUSE's handbook and make it possible
to swap coreutils + shadow-utils + util-linux with busybox and have a
fedora-busybox container that uses busybox + microdnf.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list
Fedora 34 compose report: 20210407.n.0 changes
OLD: Fedora-34-20210406.n.0 NEW: Fedora-34-20210407.n.0 = SUMMARY = Added images:0 Dropped images: 7 Added packages: 6 Dropped packages:0 Upgraded packages: 62 Downgraded packages: 0 Size of added packages: 3.33 MiB Size of dropped packages:0 B Size of upgraded packages: 1.08 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 8.13 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Minimal raw-xz armhfp Path: Spins/armhfp/images/Fedora-Minimal-34-20210406.n.0.armhfp.raw.xz Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-34-20210406.n.0.armhfp.raw.xz Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-34-20210406.n.0.armhfp.raw.xz Image: SoaS raw-xz armhfp Path: Spins/armhfp/images/Fedora-SoaS-34-20210406.n.0.armhfp.raw.xz Image: Xfce raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-34-20210406.n.0.armhfp.raw.xz Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-34-20210406.n.0.armhfp.raw.xz Image: Server raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-34-20210406.n.0.armhfp.raw.xz = ADDED PACKAGES = Package: cockpit-machines-242.1-1.fc34 Summary: Cockpit user interface for virtual machines RPMs:cockpit-machines Size:1.65 MiB Package: golang-github-fyne-io-glfw-0-0.1.20210402gitf227906.fc34 Summary: Go bindings for GLFW 3 RPMs:golang-github-fyne-io-glfw-devel Size:693.31 KiB Package: golang-github-racingmars-go3270-0-0.1.20210402gitb6d2a09.fc34 Summary: 3270 server library for Go RPMs:golang-github-racingmars-go3270-devel Size:22.82 KiB Package: golang-salsa-debian-vasudev-gospake2-0.2.0-1.fc34 Summary: Go SPAKE2 Implementation RPMs:golang-salsa-debian-vasudev-gospake2-devel Size:47.08 KiB Package: pw3270-5.4-1.fc34 Summary: IBM 3270 Terminal emulator for GTK RPMs:pw3270 Size:420.12 KiB Package: python-sport-activities-features-0.1.2-1.fc34 Summary: Extracting features from sport activity files RPMs:python-sport-activities-features-doc python3-sport-activities-features Size:538.90 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: GtkAda3-2020-4.fc34 Old package: GtkAda3-2020-3.fc34 Summary: GTKada 3, an Ada binding to GTK+ 3 RPMs: GtkAda3 GtkAda3-devel GtkAda3-doc GtkAda3-gl Size: 35.12 MiB Size change: -8.24 KiB Changelog: * Fri Apr 02 2021 Bj??rn Persson - 2020-4 - rebuilt with gcc-11.0.1-0.3 Package: ahven-2.7-10.fc34 Old package: ahven-2.7-9.fc34 Summary: A unit testing framework for Ada 95 RPMs: ahven ahven-devel Size: 1.90 MiB Size change: -1.26 KiB Changelog: * Fri Apr 02 2021 Bj??rn Persson - 2.7-10 - rebuilt with gcc-11.0.1-0.3 Package: anaconda-34.24.8-1.fc34 Old package: anaconda-34.24.6-1.fc34 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 21.94 MiB Size change: 37.63 KiB Changelog: * Tue Mar 30 2021 Martin Kolman - 34.24.7-1 - network: match also connections named by MAC created by NM in initramfs (rvykydal) - Create /tmp with the right permissions (#1937626) (vponcova) - Don't recommend zram-generator-defaults (#1938132) (vponcova) - Don't automatically execute the default partitioning (vponcova) - Fix the warning about working NTP servers (#1889180) (vponcova) - Remove implicit dependencies (vponcova) - Don't install anaconda-install-env-deps by default (vponcova) * Wed Mar 31 2021 Martin Kolman - 34.24.8-1 - ostree: ignore exit code 65 for systemd-tmpfiles (vponcova) - Turn off wrapping of the scale values (vponcova) - Make the scale visible by default (#1943370) (vponcova) Package: anet-0.4.1-9.fc34 Old package: anet-0.4.1-8.fc34 Summary: Ada Networking Library RPMs: anet anet-devel Size: 979.81 KiB Size change: -352 B Changelog: * Fri Apr 02 2021 Bj??rn Persson - 0.4.1-9 - rebuilt with gcc-11.0.1-0.3 Package: appstream-data-34-1.fc34 Old package: appstream-data-33-2.fc34 Summary: Fedora AppStream metadata RPMs: appstream-data Size: 11.25 MiB Size change: 28.15 KiB Changelog: * Wed Mar 31 2021 Richard Hughes 34-1 - New metadata version Package: aws-2020-4.fc34 Old package: aws-2020-3.fc34 Summary: Ada Web Server RPMs: aws aws-devel aws-doc aws-tools Size: 20.84 MiB Size change: -4.13 KiB Changelog: * Fri Apr 02 2021 Bj??rn Persson - 2020-4 - rebuilt with gcc-11.0.1-0.3 Package: conda-4.10.0-1.fc34 Old package: conda-4.9.2-3.fc34 Summary: Cross-platform, Python-agnostic binary package manager RPMs: conda python3-conda Size: 824.71 KiB Size change: 6.3
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
On 4/7/21 2:21 PM, Tomas Orsava wrote: On 4/7/21 12:45 PM, Panu Matilainen wrote: On 4/7/21 1:12 PM, Tomas Orsava wrote: On 4/7/21 11:38 AM, Panu Matilainen wrote: On 4/7/21 12:06 PM, Miro Hrončok wrote: On 07. 04. 21 10:45, Panu Matilainen wrote: I'm starting to think the right thing to do is to move %check to run after %build rather than %install. That would completely eliminate arguments over what is proper use and should this or that be done etc. This is what I don't understand: The current %exclude change is backwards incompatible and breaks things. How does breaking it even more help this problem? Because they kinda go together: the %exclude change revealed that %check is being used in ways it wasn't really intended to be used - just like %exclude was - and both "abuses" come with unwanted side-effects (note quotes, while I know the internal intention, the intended uses were never clearly documented anywhere) Further rationale at https://github.com/rpm-software-management/rpm/pull/1618 I understand wanting a perfect system, but I think it's important to realize that rpm is a tool for maintainers to simplify their life and make packaging other software possible. What you're proposing now is to break thousands of packages with no advanced warning, no migration path, just because they're using rpm in a way that wasn't predicted. Please don't do this. If you really want to introduce such backwards incompatible changes, please first work with us maintainers on the migration path and a reasonable timeline to do so. Isn't that exactly what we're doing here? The %check PR may or may not go in, it was linked here so people have a chance to discuss it. Because there's this just discovered linkage between %exclude and %check uses, it probably makes sense for them to go in together. Which could mean doing both, or neither, in 4.17. As in, reverting the %exclude change in 4.17 is entirely possible if it makes sense in the grand scheme things. We cannot possibly know what all the tens of thousands of packages out there are doing, and people will only ever wake up when the change is about to hit them. We've done a dozens of similar changes not because it's fun or because I enjoy getting yelled at for breaking their stuff but because there's no other way to fix ambiguity than making it unambiguous. You're right, knowing the scope of the breakage in advance is just not possible. We have similar problems with Python, but given the nature of RPM, you've got it even tougher. I really apologize if it felt like yelling, that was not my intention. No worries. Didn't mean to imply *you* were yelling, this has been entirely civil as far as I'm concerned. I was just referring to years of battling these issues: for every little loophole in rpm we close in order to make it saner we get a backslash, and not always so civilized. It just gets tiresome sometimes. I'm sure you know the feeling. I myself was kicking and screaming through most of the Python 3 transition, so been on the other side of it too :) However, I hope you'll understand why I felt a certain urgency when writing my response. From my own packaging experience the change would break a lot of usage, and other people on this thread only reinforced that this would be a major problem in many areas. And so when I saw that the follow up to this discussion was a PR that would break even more use cases, I grew worried. Yes, message heard. This has been an important discussion to have because it revealed various things I had no idea about, in particular the %exclude linkage to %check. On the other hand, I understand where you're coming from: we have fought battles with unintended use of our tools too (e.g. sudo pip breaking dnf). But given the scope of the breakage here, I would advocate for postponing this change for now. It seems none of us is sure how to square this circle at the moment. Nod. I'll need to sleep on this all a bit. - 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for users of userfaultfd(2) syscall in Fedora
On Tue, Apr 6, 2021 at 7:33 PM Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Apr 06, 2021 at 06:57:27PM +0200, Ondrej Mosnacek wrote: > > Hi all, > > > > Kernel 5.12 added support to SELinux for controlling access to the > > userfaultfd interface [1][2] and we'd like to implement this in > > Fedora's selinux-policy. However, once we add the corresponding class > > to the policy, all SELinux domains for which we don't add the > > appropriate rules will have any usage of userfaultfd(2) denied. > > https://codesearch.debian.net/search?q=userfaultfd(&literal=1 > lists a few candidates… Thanks, that's a nice tool! Filtering out false-positives, the kernel itself, and user programs that would normally run under unconfined_t, packages dead in Fedora, ..., the only relevant one seems to be 'criu' (already mentioned in this thread). Strange that it didn't find QEMU... maybe needs a more generic search... -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for users of userfaultfd(2) syscall in Fedora
On Tue, Apr 6, 2021 at 10:30 PM Florian Weimer wrote: > * Ondrej Mosnacek: > > > Kernel 5.12 added support to SELinux for controlling access to the > > userfaultfd interface [1][2] and we'd like to implement this in > > Fedora's selinux-policy. However, once we add the corresponding class > > to the policy, all SELinux domains for which we don't add the > > appropriate rules will have any usage of userfaultfd(2) denied. > > What's special about this system call that this is necessary? Our primary motivation is not so much to have this specific syscall covered, but rather to close the gap between what is supported by the kernel versus the policy. On the default "targeted" policy the security classes/permissions (think of this as individual kinds of operations that can be allowed or denied) that are unknown to the policy are allowed by default, but on the more strict "mls" variant they are denied. So once the kernel adds a new security class/permission, we are forced to implement it in some way so that the corresponding functionality is not blanket-denied on the MLS policy. It is of course possible to just allow the new operation globally if it's something not worth bothering with, but we rather try to follow the principle of least privilege and allow new things only where they are needed. That said, I heard that userfaultfd(2) has been used in some exploits, so there may be merit in trying to restrict its use (especially when the legitimate use seems to be limited to just a few applications). A quick Google search indeed reveals a few interesting examples: https://blog.lizzie.io/using-userfaultfd.html https://www.exploit-db.com/exploits/45983 https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html#heap-spraying -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for users of userfaultfd(2) syscall in Fedora
On Tue, Apr 6, 2021, at 4:30 PM, Florian Weimer wrote: > * Ondrej Mosnacek: > > > Kernel 5.12 added support to SELinux for controlling access to the > > userfaultfd interface [1][2] and we'd like to implement this in > > Fedora's selinux-policy. However, once we add the corresponding class > > to the policy, all SELinux domains for which we don't add the > > appropriate rules will have any usage of userfaultfd(2) denied. > > What's special about this system call that this is necessary? https://lwn.net/Articles/835373/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-34-20210407.0 compose check report
No missing expected images. Failed openQA tests: 1/16 (x86_64), 4/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20210406.0): ID: 847045 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/847045 ID: 847051 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/847051 ID: 847055 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/847055 ID: 847056 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/847056 ID: 847063 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/847063 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210406.0): ID: 847034 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/847034 Passed openQA tests: 14/16 (x86_64), 11/15 (aarch64) New passes (same test not passed in Fedora-IoT-34-20210406.0): ID: 847039 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/847039 ID: 847048 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/847048 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-34-20210407.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Minimal raw-xz armhfp Failed openQA tests: 22/189 (x86_64), 15/127 (aarch64) New failures (same test not failed in Fedora-34-20210406.n.0): ID: 846736 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/846736 ID: 846757 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/846757 ID: 846764 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/846764 ID: 846840 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/846840 ID: 846857 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/846857 ID: 846891 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/846891 ID: 846952 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/846952 ID: 846959 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/846959 ID: 846978 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/846978 ID: 846981 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/846981 ID: 846997 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/846997 Old failures (same test failed in Fedora-34-20210406.n.0): ID: 846732 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/846732 ID: 846733 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/846733 ID: 846745 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/846745 ID: 846763 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/846763 ID: 846790 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/846790 ID: 846791 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/846791 ID: 846793 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/846793 ID: 846794 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/846794 ID: 846795 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/846795 ID: 846798 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/846798 ID: 846799 Test: x86_64 KDE-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/846799 ID: 846803 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/846803 ID: 846848 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/846848 ID: 846849 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/846849 ID: 846852 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/846852 ID: 846864 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/846864 ID: 846872 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/846872 ID: 846876 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/846876 ID: 846910 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/846910 ID: 846966 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/846966 ID: 846982 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/846982 ID: 846985 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/846985 ID: 847014 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/847014 ID: 847017 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/847017 ID: 847027 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/847027 ID: 847028 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/847028 Soft failed openQA tests: 3/189 (x86_64), 5/127 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-34-20210406.n.0): ID: 846721 Test: x86_64 Server-dvd-iso install_vncconn
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
Dne 07. 04. 21 v 11:05 Panu Matilainen napsal(a):
On 4/7/21 11:45 AM, Panu Matilainen wrote:
On 4/6/21 7:40 PM, Vít Ondruch wrote:
Dne 06. 04. 21 v 16:02 Panu Matilainen napsal(a):
On 4/6/21 1:36 PM, Miro Hrončok wrote:
For example, what is common for Python "namepsace" packages, e.g.
pkg_name.foo.
1) We want to test installed files, not what is in $PWD, so we set
PYTHONPATH to
%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
(try hard to) exclude $PWD from it. This is crucial to ensure
the files
we actually ship are working and the installed file set is
complete.
Our macros do this for the packagers.
2) The %{python3_site...}/pkg_name/ directory and
%{python3_site...}/pkg_name/__init__.py and
%{python3_site...}/pkg_name/__pycache__/ and
%{python3_site...}/pkg_name/__pycache__/__init__...pyc
files must be present in %{buildroot} to successfully run the
tests.
3) The files from (2) must be excluded from the package because
*pkg_name* owns
them, not *pkg_name.foo*.
We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
The files are not bit-by-bit+metadata identical,
so both packages cannot ship them.
This seems like a fairly exotic case to me - okay, a
Python-peculiar problem. And a problem of stepping (not saying
crossing, because I'm not sure it is) on the boundaries of the
%check use-case I suppose.
%ghost'ing the files might be one option - I don't know about the
Ruby cache case beyond that there is one.
There is only `%{gem_cache}` (I assume it was mentioned in the
context of `%exclude`, because that has nothing to do with testing).
Not shipping this file is enough and we don't ship it just because
we don't want to ship file which looks like upstream file but it is
not the original upstream file. Moreover we don't really need it for
the purposes it is used by upstream, which is restoring the original
state of the library.
Ah, okay, it's an entirely different case then. Does this file ever
get created when running the installed software (by root)? If so,
then %ghost'ing it would seem to be the right thing.
The chances to have this file created are pretty slim end even if it was
created, it would not be trustworthy.
If it's just something that needs to be scrubbed on each and every
ruby package ever built, we could always add a buildroot policy for
it. Just like we could automatically clean .la files rather than
manually clean them in thousands of packages...
Is it correct assumption that any "random" packages can ship BRP?
Interesting idea, I have to give it thought. I guess the concern would
be that the packages for the most recent Fedora/RPM won't be compatible
with older releases without the BRP. But it should be possible to
backport it I guess.
Vít
OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Looking for users of userfaultfd(2) syscall in Fedora
* Colin Walters: > On Tue, Apr 6, 2021, at 4:30 PM, Florian Weimer wrote: >> * Ondrej Mosnacek: >> >> > Kernel 5.12 added support to SELinux for controlling access to the >> > userfaultfd interface [1][2] and we'd like to implement this in >> > Fedora's selinux-policy. However, once we add the corresponding class >> > to the policy, all SELinux domains for which we don't add the >> > appropriate rules will have any usage of userfaultfd(2) denied. >> >> What's special about this system call that this is necessary? > > https://lwn.net/Articles/835373/ I have some understanding of what the system call does, which is why I'm asking the question. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora Linux 34 Final Go/No-Go meeting next week
Hi everyone, It's that time! The Fedora Linux 34 Final Go/No-Go[1] meeting is scheduled for Thursday 15 April at 1700 UTC in #fedora-meeting-1. At this time, we will determine the status of F34 for the 20 April preferred target date. For more information about the Go/No-Go meeting, see the wiki[2]. [1] https://calendar.fedoraproject.org/meeting/9957/ [2] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
License change: jrnl (changed from MIT to GPLv3 upstream)
I just picked up this package after it was orphaned. The upstream license changed to MIT to GPLv3 in release 2.4; the previous maintainer missed the change, so the RPMs in all current Fedora releases have the incorrect License field. (The version in EPEL8 is old enough to be correct.) I will be providing the latest version, 2.8, with the corrected License field, as a compatible update to all current Fedora releases. This update will also resolve a variety of FTI and FTBFS bugs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[NEWS]: Ludovic Courtès
https://gnu.support/richard-stallman/Ludovic-Court%C3%A8s-Guix-is-accusing-Stallman-of-Thoughtcrime-on-his-own-domain-GNU-org.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [NEWS]: Ludovic Courtès
This is not the place for this, even if it were intended to start a good-faith discussion, which this clearly isn't. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F33 to F34
Hi, On Sat, 2021-02-20 at 10:49 +0100, Miroslav Suchý wrote: > Do you want to make Fedora 34 better? Please spend 1 minute of your > time and try to run: > ># Run this only if you use default Fedora modules ># next time you run any DNF command default modules will be > enabled again >sudo dnf module reset '*' > >sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 > \ > --enablerepo=updates-testing --enablerepo=updates-testing- > modular \ > distro-sync > > This command does not replace `dnf system-upgrade`, but it will > reveal potential problems. You may also run `dnf > upgrade` before running this command. I think we should do this exact same test but after Fedora release , For example on Dec 6 2020, I upgrade from F31 to F32 and I had these results [1] I did a dnf distro-sync , but we found some mistakes if we verify why package have lower versions in Fedora n+1 , sometimes maintainer didn't send package to bodhi, other times package it is in updates-testing forever and many other issues. Best regards, [1] libappindicator-0:12.10.0-29.fc31.i686 libappindicator-0:12.10.0-29.fc31.x86_64 libappindicator-gtk3-0:12.10.0-29.fc31.i686 libappindicator-gtk3-0:12.10.0-29.fc31.x86_64 microcode_ctl-2:2.1-39.3.fc31.x86_64 perl-Net-DNS-SEC-0:1.17-1.fc31.x86_64 perl-Type-Tiny-0:1.010006-1.fc31.noarch python2-pillow-0:6.2.2-3.fc31.x86_64 python2-setuptools-0:41.6.0-1.fc31.noarch slirp4netns-0:1.1.6-1.fc31.x86_64 tpm2-abrmd-selinux-0:2.3.1-2.fc31.noarch xawtv-0:3.107-2.fc31.x86_64 Downgrading: baobab x86_64 3.34.0-2.fc32k libappindicatorx86_64 12.10.0-28.fc32 libappindicator-gtk3 x86_64 12.10.0-28.fc32 microcode_ctl x86_64 2:2.1-39.fc32 perl-Net-DNS-SEC x86_64 1.12-4.fc32 perl-Type-Tiny noarch 1.010004-1.fc32 python2-pillow x86_64 6.2.2-2.fc326 k python2-setuptools noarch 41.2.0-2.fc32 slirp4netnsx86_64 1.1.4-1.fc32 tpm2-abrmd-selinux noarch 2.3.1-1.fc32 xawtv x86_64 107-1.fc32 > If you have have rdma-core.i686 installed you have to pass ` > --allowerasing`. > https://bugzilla.redhat.com/show_bug.cgi?id=1919864 > > > If you get this prompt: > >... >Total download size: XXX M >Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the actual > upgrade. > > But very likely you get some dependency problem now. In that case, > please report it against the appropriate package. Or > against fedora-obsolete-packages if that package should be removed in > Fedora 34. Please check existing reports against > fedora-obsolete-packages first: >https://red.ht/2kuBDPu > and also there is already bunch of "Fails to install" reports: >https://bugzilla.redhat.com/show_bug.cgi?id=F34FailsToInstall > > Thank you > > P.S. sent from workstation successfully upgraded to F34 :) > > -- > Miroslav Suchy, RHCA > Red Hat, Associate Manager, Community Packaging Tools, #brno, > #fedora-buildsys > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Disabling BZ `fedora_requires_release_note` flag
I intend to disable the `fedora_requires_release_note` flag in Bugzilla. These days, the Release Notes are mostly built via issues against the Release Notes repo[1] on Pagure. Removing unused flags simplifies the BZ experience for users and prevents the Docs team from having to look in multiple places. pbokoc said it's okay, but I wanted to run it by a wider audience just in case. I see one open bug with the flag granted and none with it requested. Five bugs closed in 2020 had the flag granted. One of those was a test bug and two were for Change tracking bugs, which get Release Notes issues as part of the process. I will disable the flag on Friday 16 April unless there's a good reason to keep it. [1] https://pagure.io/fedora-docs/release-notes/issues -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)
On Tue, Apr 06, 2021 at 12:42:33PM +0200, Fabio Valentini wrote: > - virt-dib-1:1.44.1-1.fc33 > virt-dib-0:1.45.3-3.fc34 > > This subpackage seems to have been accidentally dropped from F34+ when > it was dropped for RHEL 9? What happened here was part of libguestfs (Epoch 1) was split into a separate upstream repo and Fedora package called guestfs-tools (Epoch 0). I don't really want to use Epoch 1 for the whole of the new package. I wonder if it will work to just put Epoch 1 into the virt-dib subpackage? Let's see ... We're not shipping virt-dib in RHEL 9. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)
On Wed, Apr 07, 2021 at 09:07:53PM +0100, Richard W.M. Jones wrote: > On Tue, Apr 06, 2021 at 12:42:33PM +0200, Fabio Valentini wrote: > > - virt-dib-1:1.44.1-1.fc33 > virt-dib-0:1.45.3-3.fc34 > > > > This subpackage seems to have been accidentally dropped from F34+ when > > it was dropped for RHEL 9? > > What happened here was part of libguestfs (Epoch 1) was split into a > separate upstream repo and Fedora package called guestfs-tools (Epoch 0). > > I don't really want to use Epoch 1 for the whole of the new package. > I wonder if it will work to just put Epoch 1 into the virt-dib > subpackage? Let's see ... So yes is the answer. I'll push the appropriate update soon. Rich. > We're not shipping virt-dib in RHEL 9. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: Debuginfod By Default (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/DebuginfodByDefault == Summary == Fedora users / developers who need to debug/trace distro binaries can make use of the recently activated elfutils-debuginfod servers to automatically fetch debugging data and source code, instead of having to use `# sudo dnf` commands. == Owner == * Name: [[User:fche| Frank Ch. Eigler]] * Email: f...@redhat.com == Detailed Description == Numerous fedora debugging-type tools have built-in capabilities to use the [https://sourceware.org/elfutils/Debuginfod.html debuginfod] protocol to fetch debuginfo/source code automatically. We would like to activate a setting so that Fedora's debuginfod servers are automatically used, rather than requiring hand-editing individual users' dot files. == Feedback == There has existed [https://www.spinics.net/lists/fedora-devel/msg279002.html broad interest] in a Fedora debuginfod server since the project was proposed / announced in 2020, and several distros already operate public servers of this nature. Some of the distros configure their installations by default to talk to those servers, some do not. Turning on this by default has some limited privacy implications. Some Debian users have [https://lists.debian.org/debian-devel/2021/02/msg00262.html expressed concerns] that this facility "calls home" during debugging, so it may expose a limited amount of information about what a user is debugging. The information is limited to the build-id and source code file names of programs being debugged, and is only sent to the servers if their machine lacks locally installed debuginfo. Whether this should be opt-in or opt-out and how has been resolved there via an install-time query to the sysadmin. In contrast, on OpenSUSE Tumbleweed, it is [https://build.opensuse.org/request/show/879926 simply defaulted-on], and we have heard of no controversy. We anticipate discussing this topic on the mailing list, and noting it in the release notes either way. == Benefit to Fedora == This will improve developers' experience. It may reduce download server burden, as only individual ELF/DWARF/source files are downloaded rather than entire `-debuginfo` and `-debugsource` RPMs. It would help Fedora catch up to other distros who put up `debuginfod` servers already. :-) == Scope == * Proposal owners: The work could consist one extra parameter in the `elfutils.spec` `%configure`. Its effect is to arrange for the `elfutils-debuginfod-client` RPM to install an `/etc/profile.d` file that sets the `DEBUGINFOD_URLS` environment variable automatically to `https://debuginfod.fedoraproject.org/`. (At the time of this writing, the _staging_ server is getting ready for testing: `https://debuginfod.stg.fedoraproject.org/`.) * Other developers: None - relevant code has been previously upstreamed! * Release engineering: None - our team is operating the `debuginfod[.stg].fedoraproject.org` VMs. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == None. Note that these servers index all active Fedora releases (32-), all architectures, so users of those versions can already set `DEBUGINFOD_URLS` manually to take advantage. == How To Test == * Install `elfutils-debuginfod-client` * Open arbitrary fedora binary via gdb. ** Admire the immediate downloading of debuginfo and source code. * Run `eu-stack -v -p $pid` for an arbitrary process. ** Admire the immediate downloading of debuginfo to give precise file:line data. == User Experience == Primarily: users running debuggers, profilers, tracing tools on internet-capable machines can work immediately, without switching to privileged users and fragile manual `dnf` commands to install this data. == Dependencies == The `debuginfod` servers at `fedora-infra` need to be up. == Contingency Plan == * Contingency mechanism: change the elfutils-debuginfod-client subrpm to not set the default `DEBUGINFOD_URLS` environment variable for all users. In the case of a server outage, the debugger tools revert to debuginfo-less operation, prior to this feature. * Contingency deadline: shortly before freeze * Blocks release? No == Documentation == There is upstream documentation in the debugging tools as well as associated with the client code / cli tooling. What our Release Notes would focus on however is the _automatic activation_ of this facility via the environment variable. == Release Notes == TBD. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: ht
F35 Change: Switching Cyrus Sasl from BerkeleyDB to GDBM (System-Wide Change proposal)
https://fedoraproject.org/wiki/Change/CyrusSaslBerkeleyDBtoGdbm == Summary == cyrus-sasl package was built with libdb requirement, now it is replaced by gdbm. == Owner == * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] * Email: dbely...@redhat.com == Detailed Description == This change switches the default backend Key-Value DB used by sasldb plugin from BerkeleyDB to GDBM and provides a migration tool for automatic conversion from old to new format. == Benefit to Fedora == According to more restrictive libdb licence policy exists effort to remove libdb's dependencies. cyrus-sasl package can now be built without libdb requirement. == Scope == * Proposal owners: * Other developers: The owners of the packages depending on cyrus-sasl sasldb plugin should provide the documentation about the migration procedure. * Release engineering: [https://pagure.io/releng/issue/10084] * Policies and guidelines: not needed for this Change * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == The migration script should be used to upgrade the particular databases used by specific applications via sasldb plugin == How To Test == * Install the new version of the cyrus-sasl. * Use the migration tool bdb2current provided by the package to migrate your sasldb file * update the configuration file to point on the new sasldb file * restart the application if necessary * Check that auth is still working == User Experience == not provided == Dependencies == A lot of application use cyrus-sasl sasldb plugins. Their maintainers were notified via email and some of them have responded. == Contingency Plan == * Contingency mechanism: Revert the shipped configuration * Contingency deadline: Beta freeze * Blocks release? Yes == Documentation == Here is the notification sent to known developers of the depending packages: New version of the cyrus-sasl is planned to use the gdbm database for the sasldb plugins. I've implemented the patch (https://src.fedoraproject.org/rpms/cyrus-sasl/pull-request/3#request_diff) changing the default DB and implementing the migration tool to make the switching from BerkeleyDB to GDBM seamless. I kindly ask you to check the information in the following spreadsheet: https://docs.google.com/spreadsheets/d/1z5eTSm3rtlKtEKPCxhI_wE861Xzg8kbvINWixSwQmLg/edit?usp=sharing: whether your package is affected by the proposed change whether the migration tool is suitable for your purposes and let me know or mark the results in the table == Release Notes == a new version of the cyrus-sasl package is landing in rawhide. This version changes the database used to store saslauthdb data. This is part of the move to deprecate use of Berkley DB. The new package will use GDBM instead. We provided a tool to perform migrations for database should that be needed by a package: The syntax of the migration tool is bdb2current Please check whether your packages use the sasldb plugin and provide a relevant migration guideline. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
Panu Matilainen wrote: > I'm starting to think the right thing to do is to move %check to run > after %build rather than %install. Here's one thing that would be affected by such a change: https://docs.fedoraproject.org/en-US/packaging-guidelines/Ada/#_runpaths Our Ada packaging policy has a requirement to run check-rpaths at the end of %check to guard against runpaths slipping into packaged files. It was added on the FPC's request. They wanted it to run as late as possible. Here's the discussion for reference: https://meetbot.fedoraproject.org/teams/fpc/fpc.2013-12-19-17.02.log.html check-rpaths checks files in RPM_BUILD_ROOT, so it would have to be moved to the end of %install if %check would run before %install. I'm aware that there's a proposal to run check-rpaths automatically on all packages: https://pagure.io/packaging-committee/issue/886 I think that's a good idea. If it gets implemented, then we can remove check-rpaths from the Ada spec files – but there might be other similar usecases where something runs in %check to check files in the buildroot, which would break if %check would be moved before %install. Björn Persson pgpfJE5qbRvw7.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: thinking journal retention timelimits
Hi, Workstation working group discussed this at a recent meeting, and reached no decision. There's general agreement that a time based limitation should apply rather than disk usage limit, to make the retention more predictable. I think this can work by default for all Fedora editions and spins. Consider this a pre-change proposal for Fedora 35. Summary of the current behaviors: * Fedora Server, minimally configured from out of the box, the current 4G limit translates into ~60 months of journal retention. * Fedora Workstation, out of the box, the same 4G limit translates into ~12 months of journal retention. * In practice, max used space retention limit has a large range of implied retention time, depending on the configuration. * rsyslog+logrotate are in editions and spins using @standard, which is pretty much all except Workstation edition. Logrotate's default policy is a 4 week retention before logs are purged. This is also used at least since RHEL 7 with the same default. About journald.conf's MaxRetentionSec= "This controls whether journal files containing entries older than the specified time span are deleted." That is, once a journal file contains an entry older than the specified time, the entire file is purged. Journal files can grow up to 128M, however MaxFileSec= defaults to 1 month, so a journal file shouldn't contain more than one month of entries. A single change to 'MaxRetentionSec=6month' combined with other existing defaults, means a max of 5-6 months of journal entries. To get systemd-journald more like the rsyslog+logrotate default, 'MaxRetentionSec=5week' and 'MaxFileSec=1week'. That would permit a float of 4-5 weeks, tending to be closer to 4 weeks. My take is that probably most folks are a bit surprised by the logrotate 4 week default, and prefer a longer retention time. And yet they still want something more consistent and shorter than the present defaults. While there are other possibilities, 6 months is both more consistent and shorter than today, and longer than the 4 week logrotate default. Per the language in man pages, my working assumption is all Max limits are in effect. If any Max value is busted, vacuuming is triggered. If anyone knows differently, now would be a good time to know! -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
wlroots 0.13.0 update for rawhide and f34
Greetings, wlroots 0.13.0 and sway 1.6 have been released today. As usual, the update is API and ABI breaking and all dependent packages must be rebuilt. For all the dependents I identified either upstream patches or ETA for the new release and have successful copr builds. I'm planning to create rawhide side-tag later today, rebuild all @sway-sig packages and send PRs with instructions to the packages I don't have access to. The side-tag will be merged in a week or when all the rebuilds are done. I also plan to prepare a day 0 update for f34 once rawhide rebuilds are completed. Let me know if you have any concerns about that. BCC: maintainer aliases for cage, labwc, phoc and wayfire -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)
On Wed, Apr 7, 2021 at 4:33 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DebuginfodByDefault > > == Summary == > Fedora users / developers who need to debug/trace distro binaries can > make use of the recently activated elfutils-debuginfod servers to > automatically fetch debugging data and source code, instead of having > to use `# sudo dnf` commands. > > == Owner == > * Name: [[User:fche| Frank Ch. Eigler]] > * Email: f...@redhat.com > > > > > == Detailed Description == > Numerous fedora debugging-type tools have built-in capabilities to use > the [https://sourceware.org/elfutils/Debuginfod.html debuginfod] > protocol to fetch debuginfo/source code automatically. We would like > to activate a setting so that Fedora's debuginfod servers are > automatically used, rather than requiring hand-editing individual > users' dot files. > > == Feedback == > > There has existed > [https://www.spinics.net/lists/fedora-devel/msg279002.html broad > interest] in a Fedora debuginfod server since the project was proposed > / announced in 2020, and several distros already operate public > servers of this nature. Some of the distros configure their > installations by default to talk to those servers, some do not. > > Turning on this by default has some limited privacy implications. > Some Debian users have > [https://lists.debian.org/debian-devel/2021/02/msg00262.html expressed > concerns] that this facility "calls home" during debugging, so it may > expose a limited amount of information about what a user is debugging. > The information is limited to the build-id and source code file names > of programs being debugged, and is only sent to the servers if their > machine lacks locally installed debuginfo. Whether this should be > opt-in or opt-out and how has been resolved there via an install-time > query to the sysadmin. In contrast, on OpenSUSE Tumbleweed, it is > [https://build.opensuse.org/request/show/879926 simply defaulted-on], > and we have heard of no controversy. > > We anticipate discussing this topic on the mailing list, and noting it > in the release notes either way. > > == Benefit to Fedora == > This will improve developers' experience. > > It may reduce download server burden, as only individual > ELF/DWARF/source files are downloaded rather than entire `-debuginfo` > and `-debugsource` RPMs. > > It would help Fedora catch up to other distros who put up `debuginfod` > servers already. :-) > > == Scope == > * Proposal owners: > The work could consist one extra parameter in the `elfutils.spec` > `%configure`. Its effect is to arrange for the > `elfutils-debuginfod-client` RPM > to install an `/etc/profile.d` file that sets the `DEBUGINFOD_URLS` > environment variable automatically to > `https://debuginfod.fedoraproject.org/`. (At the time of this > writing, the _staging_ server is getting ready for testing: > `https://debuginfod.stg.fedoraproject.org/`.) > > * Other developers: None - relevant code has been previously upstreamed! > > * Release engineering: None - our team is operating the > `debuginfod[.stg].fedoraproject.org` VMs. > > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: N/A > > > == Upgrade/compatibility impact == > None. > > Note that these servers index all active Fedora releases (32-), all > architectures, so users of those versions can already set > `DEBUGINFOD_URLS` manually to take advantage. > > == How To Test == > > * Install `elfutils-debuginfod-client` > * Open arbitrary fedora binary via gdb. > ** Admire the immediate downloading of debuginfo and source code. > * Run `eu-stack -v -p $pid` for an arbitrary process. > ** Admire the immediate downloading of debuginfo to give precise file:line > data. > > == User Experience == > Primarily: users running debuggers, profilers, tracing tools on > internet-capable machines can work immediately, without switching to > privileged users and fragile manual `dnf` commands to install this > data. > > == Dependencies == > > The `debuginfod` servers at `fedora-infra` need to be up. > > == Contingency Plan == > > * Contingency mechanism: change the elfutils-debuginfod-client subrpm > to not set the default `DEBUGINFOD_URLS` environment variable for all > users. In the case of a server outage, the debugger tools revert to > debuginfo-less operation, prior to this feature. > * Contingency deadline: shortly before freeze > * Blocks release? No > > == Documentation == > There is upstream documentation in the debugging tools as well as > associated with the client code / cli tooling. What our Release Notes > would focus on however is the _automatic activation_ of this facility > via the environment variable. > > == Release Notes == > > TBD. > Woohoo! I'm excited for this! I got a chance to use debuginfod to do some debugging of DNF on openSUSE last Saturday and the experience was fantastic. I'm looking forward to this being wired
Re: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)
On Tue, Apr 06, 2021 at 10:28:08AM -0400, Matthew Miller wrote: > On Tue, Apr 06, 2021 at 12:42:33PM +0200, Fabio Valentini wrote: > > - icedtea-web-0:2.0.0-pre.2.alpha13.patched1.fc33 > > > icedtea-web-0:2.0.0-pre.0.3.alpha16.patched1.fc34.3 > > > > Versioning snafu - alpha 13 should not sort higher than alpha 16, I guess. > > > In case it's not obvious, it's the change from "pre.2" to "pre.0.3" that is > the oops. Strictly speaking, we don't require versions to not go down (i.e. 'distro-sync --releasever=34' is recommended over 'upgrade --releasever=34'). So while ugly, this is not a problem. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Orphaning fbreader and libunibreak
Dear all, I'm finding I don't have the time to maintain fbreader (an ebook reader) - and I don't use it anymore these days. I also maintain libunibreak as a fbreader dependency, so I'm also orphaning it. Looks like coolreader is the only other user of libunibreak at the moment, cc:ing its maintainers here $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires libunibreak-devel Last metadata expiration check: 0:00:18 ago on Wed 07 Apr 2021 03:59:08 PM PDT. coolreader-0:3.2.54-1.fc35.src fbreader-0:0.99.4-7.fc34.src -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name 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 on the list, report it: https://pagure.io/fedora-infrastructure
Schedule for Thursday's FPC Meeting (2021-04-08 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2021-04-08 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2021-04-08 09:00 PDT US/Pacific 2021-04-08 12:00 EDT --> US/Eastern <-- 2021-04-08 16:00 UTC UTC 2021-04-08 17:00 BST Europe/London 2021-04-08 18:00 CEST Europe/Berlin 2021-04-08 18:00 CEST Europe/Paris 2021-04-08 21:30 IST Asia/Calcutta New Day: Friday - 2021-04-09 00:00 HKT Asia/Hong_Kong 2021-04-09 00:00 +08 Asia/Singapore 2021-04-09 01:00 JST Asia/Tokyo 2021-04-09 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot = Followup Issues = #topic #886 Enable BRP for detecting RPATH .fpc 886 https://pagure.io/packaging-committee/issue/886 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #1058 How to handle %lang files in package owned directories? .fpc 1058 https://pagure.io/packaging-committee/issue/1058 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-1045 WIP: Add discussion of macro names beginning with underscores. https://pagure.io/packaging-committee/pull-request/1045 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
