Re: GenericError: srpm mismatch for [debuginfo file]
On Wed, May 29, 2024 at 04:35:57PM +0200, Michal Domonkos wrote: > On Wed, May 29, 2024 at 12:38:31PM +0100, Richard W.M. Jones wrote: > > It failed right at the end with this mysterious error: > > > > GenericError: srpm mismatch for > > /mnt/koji/work/tasks/4737/118234737/ocaml-ocamldoc-debuginfo-5.2.0-1.fc41.x86_64.rpm: > > (none) (expected ocaml-5.2.0-1.fc41.src.rpm) > > OK, this should be fixed now: > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-0cdd01deef Thanks! Do you plan to submit rebuilds for the failed packages are should packagers do that individually? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
No FESCO meeting today
Hi, We have Memorial Day in the USA and no new topics on the agenda, so I'm cancelling today's meeting. See y'all next weeek! 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, May 22, 2024 at 09:06:07AM +0200, Vitaly Zaitsev via devel wrote: > On 17/04/2024 09:20, Zbigniew Jędrzejewski-Szmek wrote: > > In some ways, that'd be nice, because we wouldn't have to install > > additional tools in the buildroot. But OTOH, those tools are rather > > small and bash/find/etc probably need to be installed anyway. > > It doesn't seem to work properly without the marshalparser Python package > installed: > > + /usr/bin/add-determinism --brp -j48 > /builddir/build/BUILDROOT/nheko-0.11.3-11.fc41.x86_64 > Cannot initialize handler pyc: ModuleNotFoundError: No module named > 'marshalparser' Yes. The plan is to pull in the marshalparser module from python3-devel (conditionalized on python not being bootstrapped). The lack of the marshalparser module means that the program doesn't handle .pyc files, but otherwise works. > Also, is it possible to suppress these "Bye!" messages? Yeah, I left in the debugging message to have more clarity if things are working. They'll be gone in the next version. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to retire mlocate
On Tue, May 21, 2024 at 01:19:24PM +0200, Miro Hrončok wrote: > On 21. 05. 24 12:29, Fabio Valentini wrote: > > On Mon, May 20, 2024 at 2:42 PM Michal Sekletar wrote: > > > > > > On Fri, May 17, 2024 at 6:14 PM Michal Sekletar > > > wrote: > > > > > > > > Hi everyone, > > > > > > > > We have had a plocate as a drop-in replacement for mlocate for quite a > > > > while now. My intention is to retire the mlocate package next week in > > > > order to prevent duplication and so that we can focus only on plocate > > > > going forward. > > > > > > > > > mlocate is now retired in Rawhide. > > > > > > https://src.fedoraproject.org/rpms/mlocate/c/7277dd5f59db126d1046a6aa5c4077a597dc?branch=rawhide > > > > Thanks for the heads-up! > > Should the package also be added to fedora-obsolete-packages so that > > it is - if installed - removed on upgrade to Fedora 41? > > If a specific replacement exists (plocate), I think it should Obsolete it > explicitly. It already does. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Mon, May 20, 2024 at 10:55:58AM +0200, Petr Pisar wrote: > V Sat, May 18, 2024 at 08:20:53PM +0200, Sandro napsal(a): > > On 16-05-2024 13:14, Petr Pisar wrote: > > > A workaround could be rpm-build or mock to register rpm-build package in > > > /etc/dnf/protected.d configuration files. Packages listed there are > > > prevented > > > from removal no matter of --allow-erasing. > > > > A bit late to the party, but I was wondering if making `add-determinism` and > > `add-determinism-nopython` require `rpm-build` would also achieve > > `rpm-build` being protected from removal as a workaround. > > > > If either package requires it there should only be one way forward, if my > > understanding of the issue is correct. > > > That's also a possible way. Many times defining the reverse dependendency can > be justified as (add-determinism) being a plugin (of rpm-build). It also helps > cleaning useless plugins (add-determinism) when the framework (rpm-build) is > uinstalled. > > A drawback is creating dependency loop. Thank you for the suggestion. I think that with the current state things are good, so I don't plan to change things, unless we discover some breakage. FWIW, add-determinism is fully functional without rpm-build… I expect that most people who use it would have rpm-build installed, but I think it's better to not create dependency loops to keep things flexible. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Fri, May 17, 2024 at 12:19:34PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, May 17, 2024 at 09:43:22AM +0100, Paul Howarth wrote:
> > On Thu, 16 May 2024 10:52:29 +
> > Zbigniew Jędrzejewski-Szmek wrote:
> >
> > > On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote:
> > > > This looks like you're putting the resolver between a rock and a
> > > > hard place. :thinking:
> > > > I don't think I've ever seen packages being *removed* when
> > > > installing BuildRequires on top of the minimal buildroot ...
> > > >
> > > > Would it be possible to adapt the packages so that add-determinism
> > > > and add-determinism-nopython are parallel-installable, and have the
> > > > macro fall back to the add-determinism-nopython executable if the
> > > > add-determinism executable is not available?
> > > > That way BuildRequires are additive and wouldn't force package
> > > > removal from the buildroot, and the rich dependency could be
> > > > simpler - i.e. `Requires: (add-determinism if python3-libs)`,
> > > > without Suggests or else branch.
> > >
> > > Yeah, I think this is the most reasonable approach.
> > > I'll push a build that does this shortly.
> > >
> > > (I tried to test this locally with mock, with the additional packages
> > > in a local repo. When I install everything in one go, things work as
> > > expected. Why I try to check the original issue, and install packages
> > > piecemeal, mock downgrades packages to fall back to the koji version
> > > without dependencies, instead of installing the additional deps. In
> > > koji, it'll only have one version of the package available, so
> > > hopefully it'll pick addition instead of removals.)
> >
> > Not sure how this is supposed to work: add-determinism-nopython seems
> > to install %{_bindir}/add-determinism.nopython but the macro only seems
> > to look for %{_bindir}/add-determinism, resulting in this when only
> > add-determinism-nopython is installed:
> >
> > (https://koji.fedoraproject.org/koji/taskinfo?taskID=117791675)
>
> Oh, this is embarrasing. I added two patches but they didn't get
> applied because %setup not %autosetup. :(
> I'll push a fixed build in a moment. Sorry for breaking the builds.
perl-Finance-Quote-1.6200-1.fc41:
https://koji.fedoraproject.org/koji/taskinfo?taskID=117804013
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Fri, May 17, 2024 at 09:43:22AM +0100, Paul Howarth wrote:
> On Thu, 16 May 2024 10:52:29 +
> Zbigniew Jędrzejewski-Szmek wrote:
>
> > On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote:
> > > This looks like you're putting the resolver between a rock and a
> > > hard place. :thinking:
> > > I don't think I've ever seen packages being *removed* when
> > > installing BuildRequires on top of the minimal buildroot ...
> > >
> > > Would it be possible to adapt the packages so that add-determinism
> > > and add-determinism-nopython are parallel-installable, and have the
> > > macro fall back to the add-determinism-nopython executable if the
> > > add-determinism executable is not available?
> > > That way BuildRequires are additive and wouldn't force package
> > > removal from the buildroot, and the rich dependency could be
> > > simpler - i.e. `Requires: (add-determinism if python3-libs)`,
> > > without Suggests or else branch.
> >
> > Yeah, I think this is the most reasonable approach.
> > I'll push a build that does this shortly.
> >
> > (I tried to test this locally with mock, with the additional packages
> > in a local repo. When I install everything in one go, things work as
> > expected. Why I try to check the original issue, and install packages
> > piecemeal, mock downgrades packages to fall back to the koji version
> > without dependencies, instead of installing the additional deps. In
> > koji, it'll only have one version of the package available, so
> > hopefully it'll pick addition instead of removals.)
>
> Not sure how this is supposed to work: add-determinism-nopython seems
> to install %{_bindir}/add-determinism.nopython but the macro only seems
> to look for %{_bindir}/add-determinism, resulting in this when only
> add-determinism-nopython is installed:
>
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=117791675)
Oh, this is embarrasing. I added two patches but they didn't get
applied because %setup not %autosetup. :(
I'll push a fixed build in a moment. Sorry for breaking the builds.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote: > Proper solution is actually minimazing content of the minimal build root Most of the packages in the buildroot are libraries, pulled in via dependencies. @buildsys-build group is: Mandatory packages : bash # basic shell env : bzip2 # source extraction : coreutils # basic shell env : cpio # source extraction : diffutils # source extraction : fedora-release-common # rpm environment : findutils # basic shell env : gawk # basic shell env : glibc-minimal-langpack # we want this to avoid other langpacks : grep # basic shell env : gzip # source extraction : info : patch # source extraction : redhat-rpm-config # rpm environment : rpm-build # rpm environment : sed # basic shell env : shadow-utils : tar # source extraction : unzip # source extraction : util-linux# basic shell env : which # basic shell env. (command -v is more portable, but meh.) : xz# source extraction Out of this list, I see only three candidates for removal: 1. info. This is presumably present for /usr/sbin/install-info. It's a small package (360kB) and probably not worth the hassle to remove. On my system, 472 rpms provide info files, and if we remove it from the default set, we'd need to patch a huge amount of packages to add it back to make the builds work. 2. util-linux. This could be replaced by util-linux-core. This has a bunch of deps too, so it'd save some. util-linux has 95 binaries, and while _most_ of them have little use in a constrained build environment, probably a few are used somewhere. So this would need some investigation. 3. shadow-utils. It was added in: commit 79e1728c1b9e9e98d2e38b1286d90d596f233a56 Author: Jesse Keating Date: Tue Jan 15 15:31:27 2008 + Make sure shadow-utils makes it into a buildroot, or else mock will fail It's been a while, and I doubt we actually need it. Maybe we could drop that? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote: > This looks like you're putting the resolver between a rock and a hard > place. :thinking: > I don't think I've ever seen packages being *removed* when installing > BuildRequires on top of the minimal buildroot ... > > Would it be possible to adapt the packages so that add-determinism and > add-determinism-nopython are parallel-installable, and have the macro > fall back to the add-determinism-nopython executable if the > add-determinism executable is not available? > That way BuildRequires are additive and wouldn't force package removal > from the buildroot, and the rich dependency could be simpler - i.e. > `Requires: (add-determinism if python3-libs)`, without Suggests or > else branch. Yeah, I think this is the most reasonable approach. I'll push a build that does this shortly. (I tried to test this locally with mock, with the additional packages in a local repo. When I install everything in one go, things work as expected. Why I try to check the original issue, and install packages piecemeal, mock downgrades packages to fall back to the koji version without dependencies, instead of installing the additional deps. In koji, it'll only have one version of the package available, so hopefully it'll pick addition instead of removals.) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
rich deps result in packages being uninstalled from buildroot
Hi, I've been trying to get 'add-determinism' deployed in buildroots. This has been unsuccessful because of the following issue. The dependency chain is: redhat-rpm-config has Requires build-reproducibility-srpm-macros and build-reproducibility-srpm-macros has Requires:(add-determinism if python3-libs else add-determinism-nopython) Suggests:add-determinism-nopython (The idea is that we install 'add-determinism-nopython' which is self-contained, but if python3 is installed into the buildroot, we pull in the heavier version which has a dependency on python3-libs.) This works well enough when installing packages using dnf on a test system. But, in koji and mock builds, this results in rpm-build being unistalled (!). For example, see https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626 and root.log there: first rpm-build is installed along with a bunch of other packages expected in the buildroot, but then cargo-rpm-macros is requested (presumably via %generate_buildrequires), which depends on python3 and python3-libs. Dnf5 realizes that to satisfy all bounds, it can either: a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and remove add-determinism-nopython b) install cargo-rpm-macros, python3, python3-libs, and remove build-reproducibility-srpm-macros, rpm-build, fonts-srpm-macros, redhat-rpm-config, and a few other packages. and picks option b). Without rpm-build installed, the build immediately faceplants. (This can be reproduced by calling 'mock -i redhat-rpm-config' and later 'mock -i cargo-rpm-macros'. It reproduces with both dnf5 and dnf, so it's not a dnf5-related regresion.) How to make this not happen, i.e. how to prevent rpm-build and other packages that were explicitly pulled in via the @buildsys-build group from being uninstalled? I think this is a general problem, not just limited to the case described above. We now have hundreds of rich Requires deps declared in packages, and each one creates the possibility that dnf might opt to uninstall the package involved in the rich dep, rather than installing the deps, if there is no mechanism to prevent previously-explicitly-requested packges from being removed. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling RPM based sysuser handling
On Tue, May 14, 2024 at 02:01:09PM +0300, Panu Matilainen wrote:
> On 5/14/24 13:39, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:
> > > I outlined the migration process last year in
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
> > > but failed to follow-up, so I'm glad to see this getting revisited.
> >
> > I started looking into this, and I think we need to start at the
> > bottom, i.e. in the setup package.
> >
> > It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
> > and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
> > but some of the groups listed in sysusers are not listed in the /etc files.
> > IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
> > automatically, and the file provided by setup will be ignored.
> > (It's specified as %config(noreplace).)
> >
> > Should be drop the static /etc/{passwd,group} from setup?
>
> The static files aren't harmful as long as they're not duplicated in other
> packages.
Harmful — no, but unnecessary and confusing. If we go decide to switch
to the rpm sysusers mechanism, then I think we should go all-in on it.
It doesn't make sense to ship a file in setup that would never be installed.
> I seem to recall seeing systemd-sysusers error out if those files were not
> present, but I might be misremembering and/or it might've changed since
> then. The default mechanism uses useradd/groupadd though, I don't know if
> those support non-existent /etc/{passwd,group}.
There might have been bugs for some specific cases, but in general
sysusers was always intended for starting with empty /etc. We certainly
test that case in our tests.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling RPM based sysuser handling
On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:
> I outlined the migration process last year in
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
> but failed to follow-up, so I'm glad to see this getting revisited.
I started looking into this, and I think we need to start at the
bottom, i.e. in the setup package.
It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
but some of the groups listed in sysusers are not listed in the /etc files.
IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
automatically, and the file provided by setup will be ignored.
(It's specified as %config(noreplace).)
Should be drop the static /etc/{passwd,group} from setup?
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling RPM based sysuser handling
On Fri, May 10, 2024 at 01:28:07PM +0200, Florian Festi wrote: > Anyone interested in picking this up? I remember quite a few people > being exited about this when it was announced with the rpm-4.19 Change. I would be interested in making this happen. You mentioned that the transition "requires some care". What are the problems? > This whole thing probably needs to be a Global Change involving a change > to the Packaging Guidelines [4] and may be an Mass Package Change > (although that might be avoided by changing the macros in > systemd-rpm-macros to NOPs). The macros are written in a way that if the user/group exist, no operation is done. Thus, naively, I would think that if rpm starts to create users and groups on its own, then the existing scriptlets would become noops. That would mean that we could enable the feature in rpm without any mass package changes first. If the rpm approach works, I think it'd make sense to a) change the macros to be noops, b) do a mass package change to strip the scriptlets from all packages. That's probably the right thing to do for the rawhide branch, but as usual, the question becomes how to handle packages that use a common branch for older releases. But the Mass Change process is intended to deal with such cases. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Smaller buildroot for Perl packages
On Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar wrote: > My idea is to split systemtap-sdt-devel into two packages: one with all the > content but without the python script (/usr/bin/dtrace) and a new one > containing only the mentioned script. +1 I think it's weird that a user program (/usr/bin/dtrace) is installed in a package called *-devel. So I think it'd good to split it out to a separate package even for that. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Summary/Minutes from today's FESCo Meeting (2024-05-06)
Text Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-06/fesco.2024-05-06-19.00.log.txt HTML Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-06/fesco.2024-05-06-19.00.log.html Text Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-06/fesco.2024-05-06-19.00.txt HTML Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-06/fesco.2024-05-06-19.00.html Meeting summary --- * TOPIC: Init Process (@zbyszek:fedora.im, 19:00:54) * TOPIC: #3204 Request for one-time Updates Policy Exception: GStreamer 1.24 for Fedora 40 * AGREED: APPROVE (+8, 0, 0) * TOPIC: #3200 provenpackager nomination for fche * INFO: Request was withdrawn and may be resubmitted later on. * TOPIC: #3186 Mandatory 2FA for all packagers * AGREED: We want packagers to use 2FA and will start with proven packagers. As an initial step, the policy will be changed that PPs SHOULD enroll tokens for 2FA. Once the UX for packagers improved, we'll consider changing the policy to "MUST". (+6, 0, 0) * TOPIC: Next week's chair * ACTION: Tom Stellard will chair next meeting * TOPIC: Open Floor * ACTION: Tom Stellard to mail admins of redhat-rpm-config for official access and do some reviews of open PRs. Meeting ended at 2024-05-06 19:54:52 Action items * Tom Stellard will chair next meeting * Tom Stellard to mail admins of redhat-rpm-config for official access and do some reviews of open PRs. People Present (lines said) --- * @zbyszek:fedora.im (65) * @nirik:matrix.scrye.com (38) * @tstellar:fedora.im (20) * @zodbot:fedora.im (12) * @mhayden:fedora.im (6) * @jistone:fedora.im (6) * @dcantrell:fedora.im (4) * @humaton:fedora.im (3) * @fche:fedora.im (3) * @meetbot:fedora.im (2) * @codonell:fedora.im (1) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Schedule for Monday's FESCo Meeting (2024-05-06)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-05-06 19:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #3202 Change: Python Built with gcc -O3 https://pagure.io/fesco/issue/3202 APPROVED (+3, 0, 0) #3201 Change: Reproducible Package Builds https://pagure.io/fesco/issue/3201 APPROVED (+5, 0, 0) = Followups = = New business = #3204 Request for one-time Updates Policy Exception: GStreamer 1.24 for Fedora 40 https://pagure.io/fesco/issue/3204 #3200 provenpackager nomination for fche https://pagure.io/fesco/issue/3200 #3186 Mandatory 2FA for all packagers https://pagure.io/fesco/issue/3186 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Thanks to my FESCo friends! ♥️
Hi Major, thank you for your work in FESCo. Good to hear that you're just taking a break, not breaking off. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
systemd 256~rc1 in rawhide
Hi, systemd-256~rc1 is building in rawhide. This is a major update, in development for 5 months. We've been doing continuous builds and testing of the development versions in rawhide, but bugs are possible (even likely). Plese report issues in bugzilla or here. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Fedora Miracle Spin (self-contained)
On Wed, Apr 24, 2024 at 10:33:51PM -0500, Neal Gompa wrote:
> On Wed, Apr 24, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Wed, Apr 24, 2024 at 04:57:40PM +0100, Aoife Moloney wrote:
> > > Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
> >
> > > {{package|miracle-wm}} is available in Fedora Linux 40, so it can be
> > > installed on top of something like the existing Sway spin and
> > > configured to reuse much of the tools used there.
> > >
> > > For Fedora Linux 41, once the spin is produced, people can download
> > > and try the experience intended to be released.
> >
> > I applaud people trying out new window managers and doing stuff with
> > Fedora. But the overhead of creating and distributing a spin is quite
> > high… It seems that the contents of this spin would overlap very
> > strongly with Sway Spin. Would it make sense to combine them and
> > allow users to easily select one or the other? Even during boot, there
> > could be two boot menu entries and we could provide simple instructions
> > to switch between the desktops on an installed system.
> >
>
> Aside from actually being unintuitive and confusing to people to smush
> two spins together like that, the experience will eventually differ
> because different tools will be used.
What tools?
> Also, you overestimate the burden of creating a spin. Aside from
> comps, kickstart definitions, and pungi config being done initially
> (which isn't too high to begin with either), the effort required to
> maintain a spin image is extremely low.
There's also the effort of distribuiting and archiving a few
additional gigabytes, putting up the links on the website and browsing
through them, some additional time and and additional step that can
fail during builds…
> A large chunk of our spins are essentially semi-automatic these days,
> and people don't really notice because at the end of the day, it's a
> bundle of things configured together.
Yes. And my point is that we can come up with a hundred or a thousands
of such bundle definitions, and my question is whether we should
create a separate deliverable for each possible definition.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Fedora Miracle Spin (self-contained)
On Wed, Apr 24, 2024 at 04:57:40PM +0100, Aoife Moloney wrote:
> Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
> {{package|miracle-wm}} is available in Fedora Linux 40, so it can be
> installed on top of something like the existing Sway spin and
> configured to reuse much of the tools used there.
>
> For Fedora Linux 41, once the spin is produced, people can download
> and try the experience intended to be released.
I applaud people trying out new window managers and doing stuff with
Fedora. But the overhead of creating and distributing a spin is quite
high… It seems that the contents of this spin would overlap very
strongly with Sway Spin. Would it make sense to combine them and
allow users to easily select one or the other? Even during boot, there
could be two boot menu entries and we could provide simple instructions
to switch between the desktops on an installed system.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, Apr 17, 2024 at 11:28:53AM +0200, Fabio Valentini wrote: > On Wed, Apr 17, 2024, 08:45 Tim Landscheidt wrote: > > > Zbigniew Jędrzejewski-Szmek wrote: > > > > > […] > > > > >> - use dynamic buildrequires to detect what plugins are needed > > > > > My problem is that the binary is linked to the libpython3.12.so shared > > > library… The detection part is easy, the hard part is how to have the > > > binary work when the shared lib is not installed. > > > > Quick 'n' dirty: Have two binaries, unconditionally call > > add-determinism-python for *.pyc files, either from > > add-determinism or the BRP macro (which essentially should > > be called when %__brp_python_bytecompile is called?), rely > > on the packager to build-require add-determinism-python or > > require that from python3-devel (the missing binary should > > fail the build otherwise). > > > Something like this could be even made automatic. > > - split Python-specific functionality into a separate binary and subpackage > of add-determinism > - add only add-determinism to the default buildroot > - add "Requires: (add-determinism-python if python3)" to add-determinism > > That way the pyc processing functionality would only be pulled in iff > python3 is already getting installed by something else. Thanks to everyone who made suggestions. A variant of the above is implemented in https://src.fedoraproject.org/rpms/rust-add-determinism/pull-request/1: We' install either add-determinism or add-determinism-nopython. (The two packages provide the same files and declare Conflicts with each other). The appropriate variant will be pulled in via rich dependencies. (The arrangement is a bit different than what is described above, i.e. one or the other binary is installed, because of some low-level implementation needs: - I don't want to spawn a separate "handler" for each type of cleanup. Right now, the different handlers don't process files of the same type, so it doesn't matter much, but such cases can easily occur, for example a .pyc file stored in a .jar, or more realistically, a .html javadoc file embedded in a .jar file. If it's all in a single process, it's fairly easy to arrange how this should be sequenced. - The multi-worker mode is now implemented by spawning N workers, and each worker accepts all file types. This makes the distribution of jobs trivial, we always have one coordinator and N workers. But if we had workers of different types, we'd suddenly need to figure out answers to questions like: how many workers of each type to spawn, e.g. does this particular package have both .jar and .a files, etc. It's much better to avoid this. - Right now the discovery which handlers are used is made once, in the first binary that is called. If it cannot initialize some type of handler (right now mainly only the pyc handler, if python cannot be initialized or marshalparser cannot be imported, but some other handlers have checks on allowed $SOURCE_DATE_EPOCH values), a warning is printed and the handler is skipped. The workers are then initialized with an explicit handler list, and if any of the specified handlers doesn't initialize, this becomes a hard error. Overall, we get warnings just once, and every unexpected failure is an error. If initialization of handlers was moved down, things would become noisier and less tight.) This approach solves the problem and is fairly simple and should be robust. If if turns out to be problematic we can always switch to some different solution in the future. Zbyszek P.S. https://github.com/keszybz/add-determinism/pull/5 was merged, which cuts down on unneeded features in dependencies. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Łukasz W.
On Sun, Apr 21, 2024 at 08:37:12PM +0200, Łukasz Wojniłowicz wrote: > Hi all, > > @decathorpe reviewed my first package positively at > https://bugzilla.redhat.com/show_bug.cgi?id=2271100 > and now I'm looking for somebody to sponsor me. My official request for > sponsorship is at https://pagure.io/packager-sponsors/issue/640. > > I would like to package aw-server-rust and eventually other components > from ActivityWatch. Fedora is missing several dozens of dependencies > for aw-server-rust and I would like to follow up on them as well. > > If that's of any use, I already maintain nvidia-340xx-kmod at RPMFusion > and provide ungoogled-chromium at my own COPR. > > I look forward to hearing from you soon. Welcome to Fedora. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
No FESCo Meeting this Monday (2024-04-22)
There is nothing on the agenda, so the meeting is cancelled. I'll chair the next meeting. = Discussed and Voted in the Ticket = #3197 Request for Updates Policy Exception: ruff https://pagure.io/fesco/issue/3197 APPROVED (+4, 0, 0) #3195 Change: Pytest 8 https://pagure.io/fesco/issue/3195 APPROVED (+4, 0, 0) #3194 Change: Versioned Kubernetes Packages https://pagure.io/fesco/issue/3194 APPROVED (+3, 0, 0) #3193 Change: Openssl Deprecate Engine https://pagure.io/fesco/issue/3193 APPROVED (+3, 0, 0) #3190 Change: Enable Consistent Device Naming in Cloud Images https://pagure.io/fesco/issue/3190 APPROVED (+4, 0, 0) #3189 Change: Change Compose Settings https://pagure.io/fesco/issue/3189 APPROVED (+8, 0, 0) #3188 Change: RPM 4.20 https://pagure.io/fesco/issue/3188 APPROVED (+7, 0, 0) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, Apr 17, 2024 at 05:12:07PM -0500, Maxwell G wrote: > On 4/13/24 06:41, Fabio Valentini wrote: > > On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > Yes. But actually I think Rust is the optimal choice here. Writing > > > this in Python would be possibly slightly nicer, but we don't want > > > to pull the interpreter and packages into the buildroot. Python > > > also has the problem (challenge?) that it needs to be bootstrapped > > > once per year. The less packages are involved in the bootstrap, the > > > easier it is. And if the brp was written in Python, we'd need to > > > deal with that, and it would probably increase the number of builds > > > which are done without the cleanup. Having this as an indepedent > > > binary avoids some of the issues with bootstrap. > > I think Rust*would* be a good choice here ... > > BUT add-determinism uses pyo3 to link to CPython, so it pulls in > > python3-libs anyway. > > So you get the downsides of pulling in Python without the upsides of > > using Rust ... > > Would it be possible to shell out to Python instead of using pyo3? I assume > add-determinism's Python handler is not that complicated given that > marshalparser does most of the work. Possible — yes. Desirable — not clear. Firstly, Python interpreter startup with module imports is relatively slow. In the current implementation we do that just once in each worker, and then read the list of files to process from a socket. People were worried about the postprocessing being slow, so I implemented a fairly nice multiprocessing scheme that cuts down on this avoidable overhead. Secondly, calling a library function is generally preferred over calling a binary for the purposes of error handling. For example, right now I can catch an exception and handle it as appropriate. When calling a subprogram, we only get an error code and maybe some error message, and, for example, supressing or customizing the message for some classes of exceptions cannot be done cleanly. Thirdly, bootstrapping might actually be easier with a link to a library. We might install older python3-libs together with a new versions of python3-libs and python3, since they don't conflict, but we can have only one /usr/bin/python… But yeah, just calling an external python binary is certainly an option if the current approach doesn't work out. Thank you for the suggestion. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, Apr 17, 2024 at 10:41:22AM -0700, Brian C. Lane wrote: > On Sat, Apr 13, 2024 at 11:16:37AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > If we don't want to pull in an additional language framework, the > > options are either a compiled language or a scripting language that is > > already installed anyway, i.e. bash or awk. Considering that we want > > to do multiprocessing and/or multithreading to make things quick, a > > compiled language seems better. And among the compiled languages, I > > think Rust should be the default choice nowadays. > > But this does seem to be using python? The readme says it uses > marshalparser and the pyc handler imports it: > > https://github.com/keszybz/add-determinism/blob/ffdc8364839b42e22e846dce41061a061da64451/src/handlers/pyc.rs#L323 > > so you still need python, right? Yes, kind of. Python and the marshalparser module are used for .pyc files. The marshalparser module is already there, and I didn't see a good reason to reimplement that code. But if there are no .pyc files, that code is not used. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)
On Wed, Apr 17, 2024 at 04:38:32PM +0100, Aoife Moloney wrote: > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) Do not > obsolete Redis with Valkey > * Contingency deadline: N/A Hmm, is this coningency. plan realistic at all? IIUC, we can't update redis, so we wouldn't want to make a new release with it. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, Apr 17, 2024 at 08:58:46AM -0400, Neal Gompa wrote: > On Wed, Apr 17, 2024 at 5:30 AM Fabio Valentini wrote: > > > > On Wed, Apr 17, 2024, 08:45 Tim Landscheidt wrote: > >> > >> Zbigniew Jędrzejewski-Szmek wrote: > >> > >> > […] > >> > >> >> - use dynamic buildrequires to detect what plugins are needed > >> > >> > My problem is that the binary is linked to the libpython3.12.so shared > >> > library… The detection part is easy, the hard part is how to have the > >> > binary work when the shared lib is not installed. > >> > >> Quick 'n' dirty: Have two binaries, unconditionally call > >> add-determinism-python for *.pyc files, either from > >> add-determinism or the BRP macro (which essentially should > >> be called when %__brp_python_bytecompile is called?), rely > >> on the packager to build-require add-determinism-python or > >> require that from python3-devel (the missing binary should > >> fail the build otherwise). > > > > > > Something like this could be even made automatic. > > > > - split Python-specific functionality into a separate binary and subpackage > > of add-determinism > > - add only add-determinism to the default buildroot > > - add "Requires: (add-determinism-python if python3)" to add-determinism > > > > That way the pyc processing functionality would only be pulled in iff > > python3 is already getting installed by something else. > > Because this is written in Rust instead of Python, you will need a > build variant for *every* Python interpreter shipped in Fedora. No, just one one, at any given time. Or in other words, it's the same as any application using Python in Fedora: it is built against some version of Python, usually the default one. (pyo3 has support for linking to the stable python abi, which theoretically would allow the program to be able to run with python versions newer than the one against which it was built. I didn't look at the details, so I don't know what would be needed to link it like that and whether that'd actually make things better for us.) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, Apr 17, 2024 at 09:38:30AM +0200, Miroslav Suchý wrote: > Dne 17. 04. 24 v 9:20 dop. Zbigniew Jędrzejewski-Szmek napsal(a): > > > By adding this functionality to Mock itself. It can be optional > > > (--add-determinism). And then Mock can call > > > > > > add-determinism $chroot/%buildroot/ > > I don't think we should make this particular functionality special. > > We have a bunch of brps: > > It depends... if you want to have this check/sanitization part of rpmbuild. > When it is small,and does not inflate buildroot, then fine. > > Over the years, I learn that people have different view where each component > should go. :) I will not argue. > > If you package add-determinism I can help you to add it to Mock. Likely as > plugin: > > https://rpm-software-management.github.io/mock/#plugins > > that is called in `postbuild` > > https://rpm-software-management.github.io/mock/Plugin-Hooks > > And by helping I mean that I will create the initial PR and you (and others) > will test the functionality. Deal? Thank you for the offer. I _might_ take you up on it later, but for now, I think it's better to keep this inside of the buildroot. I don't think that this functionality should be tied to mock. Right now, the helper runs for 'fedpkg local' (as all brps), but if it's moved to mock, then we'd need to at least call it from two places. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, Apr 17, 2024 at 08:39:48AM +0200, Miroslav Suchý wrote:
> Dne 16. 04. 24 v 10:04 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
> > Hmm, how would that work? We call mock, which calls systemd-nspawn,
> > which runs rpmbuild, and the build env is completely isolated from the
> > host.
>
> By adding this functionality to Mock itself. It can be optional
> (--add-determinism). And then Mock can call
>
> add-determinism $chroot/%buildroot/
I don't think we should make this particular functionality special.
We have a bunch of brps:
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-ldconfig
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/redhat/brp-strip-lto
+ /usr/lib/rpm/brp-strip-static-archive
+ /usr/lib/rpm/check-rpaths
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
+ /usr/lib/rpm/brp-remove-la-files
+ /usr/lib/rpm/redhat/brp-python-bytecompile
+ /usr/lib/rpm/redhat/brp-python-hardlink
And if such a feature is added, it should be generic to allow all
and any of those to be moved out of the build env.
In some ways, that'd be nice, because we wouldn't have to install
additional tools in the buildroot. But OTOH, those tools are rather
small and bash/find/etc probably need to be installed anyway. And
also, the package can configure and override the brps via macros. If
they were called from the outside, we'd need to at least figure out a
new protocol for that.
Certainly an interesting idea, but I'm not convinced, yet.
---
BTW.:
+ /usr/lib/rpm/brp-remove-la-files
This one means that various packages that remove .la files on their
own don't need to do this. Maybe we could have a pp sweep over the
specs and drop various 'find %{buildroot} -name *.la -delete'?
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Tue, Apr 16, 2024 at 09:42:27AM +0200, Pavel Raiskup wrote: > On sobota 13. dubna 2024 21:04:06, CEST Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Apr 13, 2024 at 01:38:49PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Sat, Apr 13, 2024 at 01:41:59PM +0200, Fabio Valentini wrote: > > > > On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek > > > > wrote: > > > > > > > > > > Yes. But actually I think Rust is the optimal choice here. Writing > > > > > this in Python would be possibly slightly nicer, but we don't want > > > > > to pull the interpreter and packages into the buildroot. Python > > > > > also has the problem (challenge?) that it needs to be bootstrapped > > > > > once per year. The less packages are involved in the bootstrap, the > > > > > easier it is. And if the brp was written in Python, we'd need to > > > > > deal with that, and it would probably increase the number of builds > > > > > which are done without the cleanup. Having this as an indepedent > > > > > binary avoids some of the issues with bootstrap. > > > > > > > > I think Rust *would* be a good choice here ... > > > > BUT add-determinism uses pyo3 to link to CPython, so it pulls in > > > > python3-libs anyway. > > > > So you get the downsides of pulling in Python without the upsides of > > > > using Rust ... > > > > > > Yes, it currently pulls in python3-libs as a dependency, but not the > > > rest of the Python stack. Ideally, the dependency on python3-libs will > > > become optional, and we'll use it if found at runtime if found and > > > ignore otherwise. (Anything that creates pyc files will have python > > > installed, so it's fine if the pyc handler only works if there.) > > > How to best do this is something that needs to be figured out… > > > > https://github.com/keszybz/add-determinism/pull/1 makes the dependency > > on libpython optional. One option would be to compile the binary > > twice, and use rich dependencies to install the heavyweight one if > > python3 is installed. If somebody has a better approach, I'm all ears. > > I do not claim these are better approaches, but you could: > > - you could consider using tooling "from host", not "from chroot" > (adding a dependency to Mock seems just fine then) Hmm, how would that work? We call mock, which calls systemd-nspawn, which runs rpmbuild, and the build env is completely isolated from the host. > - use dynamic buildrequires to detect what plugins are needed My problem is that the binary is linked to the libpython3.12.so shared library… The detection part is easy, the hard part is how to have the binary work when the shared lib is not installed. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Mon, Apr 15, 2024 at 12:59:04PM +0200, Vít Ondruch wrote: > Could you please share some comparison of what is impact on buildroot? How > many packages added, download size, install size. $ rpm -qiR add-determinism-0.2.0-1.fc40.x86_64 ... Size: 2801276 (installed size, 2.7 MB) ... libc.so.6()(64bit) libgcc_s.so.1()(64bit) libbz2.so.1()(64bit) libzstd.so.1()(64bit) libpython3.12.so.1.0()(64bit) ... So I think the size and deps are neglible, with the exception of libpython3, which is large (45 MB). As discussed, we'll make it optional. I amended the Proposal page now to say that explicitly. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On Mon, Apr 15, 2024 at 10:46:39AM +0200, Lukáš Nykrýn wrote: > Just for record, the removal of network-scripts was done because > https://fedoraproject.org/wiki/Changes/dhclient_deprecation That page has Category:ChangePageIncomplete. dhcp-client is present in F40, even though it has Provides:deprecated(). > Network-scripts heavily depend on dhclient and there is no plan to rework > them to use a different dhcp implementation. Ack. So it sounds like we could keep using both in F40 and prepare for removal in F41. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Mon, Apr 15, 2024 at 11:10:28AM +0200, Miroslav Suchý wrote: > Dne 13. 04. 24 v 1:16 odp. Zbigniew Jędrzejewski-Szmek napsal(a): > > The proposal explicitly states that we don't want Perl in all buildroots. > > How many seconds we save by NOT pulling Perl? Per each build? In total for > whole release cycle? > > How many seconds we loose (lost) by refactoring the code? I wasn't measuring the time exactly, but about two weeks of my time. > And syncing with Debian? > Or even worse finding issues that Debian will find and we not? Some divergence from Debian would happen anyway. Their build system is different enough that we have some non-overlapping issues. And in my implementation, I was a bit more conservative in what is changed, doing the minimal replacements. We'd either have to maintain some patches or wait until upstream accepts our changes and makes a release. Having a tool that is under our control allows us to update much more quickly. For Perl, the issue is not so much the seconds and megabytes, but that a) Perl is now effectively a niche language, we made the choice to use Python for tooling instead a long time ago, and b) it'd pull in the interpreter and a set of modules. Considering that we need python marshalparser for the pyc files, that'd mean two interpreter stacks in some cases. Perl certainly has and will have its uses, but I don't think we should use it when adding completely new tooling to our build system. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont
On Mon, Mar 25, 2024 at 04:15:44PM +, Aoife Moloney wrote: > Wiki - https://fedoraproject.org/wiki/Changes/VersionedKubernetesPackages > == Owner == > * Name: [[User:Buckaroogeek| Brad Smith]] > * Email: bradley.g.sm...@gmail.com > > > == Detailed Description == > The Kubernetes project maintains 3 concurrent versions with a new > release every 4 months. Each version has a defined life-cycle of > approximately 1 year (https://https://kubernetes.io/releases/ for > details and current versions). In this proposal a release is a > major:minor version combination such as 1.28 or 1.27 and ignores any > patch updates (e.g. 1.28.1 or 1.28.2 as these are part of the same > 1.28 minor release). Something that is not discussed explicitly in the proposal: what happens during an upgrade, when the user has a version installed that is not supported anymore. Do they get some notification that they should switch to the next one? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Dominik Wombacher
On Sun, Apr 14, 2024 at 01:45:58PM +0200, Dominik Wombacher wrote: > Hey everyone, > > I met a few people already on Events, during the Job or by contributing > to Pagure, Uyuni and some other projects. But I didn't properly > introduced myself on the Fedora devel list, so here we go. > > My nickname for most accounts, including FAS, is wombelix, you can also > call me Dom. I live in Germany and work as Sr. Partner Solutions > Architect at AWS. I would describe myself as Open Source Enthusiast and > Contributor, Dog Person and Passionate Engineer. I'm in IT my whole life > and on/off contributor to different open source projects since a couple > of years. Doing hands-on tech and devel stuff is what I enjoy most. Give > me problems to solve so I can go down the rabbit hole of troubleshooting > and debugging. Let me put some code and a fix together. That's how to > make my happy. Hi Dominik, welcome to Fedora (now officially ;) )! Rabbit holes and troubleshooting opportunities is something that don't lack, so I hope you find joy. Zbyszek > I had it on my bucket list for quite a while to do some packaging and > learn some of the Spec magic. I finally got started and work on my first > Fedora package. > I'm looking for a Reviewer and Sponsor: > https://bugzilla.redhat.com/show_bug.cgi?id=2274150 > > My intention is to work on a couple more AWS related packages and to see > if there are some orphaned packages that are interesting. > > Dom > > > -- > The Wombelix Post > https://dominik.wombacher.cc > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Sat, Apr 13, 2024 at 01:38:49PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Apr 13, 2024 at 01:41:59PM +0200, Fabio Valentini wrote: > > On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > Yes. But actually I think Rust is the optimal choice here. Writing > > > this in Python would be possibly slightly nicer, but we don't want > > > to pull the interpreter and packages into the buildroot. Python > > > also has the problem (challenge?) that it needs to be bootstrapped > > > once per year. The less packages are involved in the bootstrap, the > > > easier it is. And if the brp was written in Python, we'd need to > > > deal with that, and it would probably increase the number of builds > > > which are done without the cleanup. Having this as an indepedent > > > binary avoids some of the issues with bootstrap. > > > > I think Rust *would* be a good choice here ... > > BUT add-determinism uses pyo3 to link to CPython, so it pulls in > > python3-libs anyway. > > So you get the downsides of pulling in Python without the upsides of > > using Rust ... > > Yes, it currently pulls in python3-libs as a dependency, but not the > rest of the Python stack. Ideally, the dependency on python3-libs will > become optional, and we'll use it if found at runtime if found and > ignore otherwise. (Anything that creates pyc files will have python > installed, so it's fine if the pyc handler only works if there.) > How to best do this is something that needs to be figured out… https://github.com/keszybz/add-determinism/pull/1 makes the dependency on libpython optional. One option would be to compile the binary twice, and use rich dependencies to install the heavyweight one if python3 is installed. If somebody has a better approach, I'm all ears. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Sat, Apr 13, 2024 at 01:41:59PM +0200, Fabio Valentini wrote: > On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > Yes. But actually I think Rust is the optimal choice here. Writing > > this in Python would be possibly slightly nicer, but we don't want > > to pull the interpreter and packages into the buildroot. Python > > also has the problem (challenge?) that it needs to be bootstrapped > > once per year. The less packages are involved in the bootstrap, the > > easier it is. And if the brp was written in Python, we'd need to > > deal with that, and it would probably increase the number of builds > > which are done without the cleanup. Having this as an indepedent > > binary avoids some of the issues with bootstrap. > > I think Rust *would* be a good choice here ... > BUT add-determinism uses pyo3 to link to CPython, so it pulls in > python3-libs anyway. > So you get the downsides of pulling in Python without the upsides of > using Rust ... Yes, it currently pulls in python3-libs as a dependency, but not the rest of the Python stack. Ideally, the dependency on python3-libs will become optional, and we'll use it if found at runtime if found and ignore otherwise. (Anything that creates pyc files will have python installed, so it's fine if the pyc handler only works if there.) How to best do this is something that needs to be figured out… 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Sat, Apr 13, 2024 at 04:12:09AM -0500, Neal Gompa wrote: > On Sat, Apr 13, 2024 at 3:59 AM Richard W.M. Jones wrote: > > > > On Fri, Apr 12, 2024 at 10:41:43PM +0100, Aoife Moloney wrote: > > > [https://github.com/keszybz/add-determinism add-determinism] is a Rust > > > program which, as its name suggests, adds determinism to files that > > > are given as input by attempting to standardize metadata contained in > > > binary or source files to ensure consistency and clamping to > > > $SOURCE_DATE_EPOCH in all instances. `add-determinism` is the "Fedora > > > version" of > > > [https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > > strip-nondeterminism] from the Debian project. Since > > > strip-nondeterminism is written in perl, it is undesirable for use in > > > Fedora, as we don't want to pull perl in the buildroot for every > > > package. The proposal explicitly states that we don't want Perl in all buildroots. It doesn't say that explicitly, but we also don't want Python. In the past we made an effort to remove gcc and make [https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot, https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot], and Python would be a fairly big addition. If we don't want to pull in an additional language framework, the options are either a compiled language or a scripting language that is already installed anyway, i.e. bash or awk. Considering that we want to do multiprocessing and/or multithreading to make things quick, a compiled language seems better. And among the compiled languages, I think Rust should be the default choice nowadays. The resulting binary is a single file of 2.6 MB, which is more than it'd be if written in C, but still reasonably small. > > https://github.com/keszybz/add-determinism looks like a package with a > > lot of Rust dependencies just to make some small changes to four > > different file types. Isn't there an easier way to do this? I would > > have thought a Python library would be more suitable as the most > > complicated bit is the *.pyc change which is done using Python code. The program currently has just four "handlers", but I expect that we'll need to add some more. Those four address issues that were apparent after a "mini mass rebuild" of ~2k packages, but that covered only a subset of packages, and it's possible that those most obvious issues masked other issues, and we didn't analyze all failures in detail, etc. The program is structured so that it should be simple to add additional handlers. Now I'll try to channel Fabio V.: all the crates that are dependencies are commonly used, i.e. they're in the common set of crates that are used by modern Rust code and we need them to be packaged anyway. The packaging effort for add-determinism was miniscule. (I made a mistake by packaging a snapshot, which the guidelines disallow like I did it, but when doing it correctly, it's really just a matter of running rust2rpm and filling in some blanks.) > Considering Debian's version is in Perl, yes, it's quite reasonable to > consider that. It could have been written in Python, C++, or even > shell (if you truly hated yourself). I'm not a big fan of Rust for > this either. But unless someone offers to make another version that is > more appealing, this is what we have. Yes. But actually I think Rust is the optimal choice here. Writing this in Python would be possibly slightly nicer, but we don't want to pull the interpreter and packages into the buildroot. Python also has the problem (challenge?) that it needs to be bootstrapped once per year. The less packages are involved in the bootstrap, the easier it is. And if the brp was written in Python, we'd need to deal with that, and it would probably increase the number of builds which are done without the cleanup. Having this as an indepedent binary avoids some of the issues with bootstrap. Please note that add-determinism has: - configurable logging - unit tests - integration tests - multiprocess support - atomic file replacements (for files without hardlinks) - rewriting of files in place (for files with hardlinks) Doing this in bash would be doable, but not worth it, IMO. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Merging /usr/sbin to /usr/bin
On Thu, Apr 11, 2024 at 02:03:01PM -0700, Brian C. Lane wrote: > On Thu, Apr 11, 2024 at 01:39:32PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > >https://src.fedoraproject.org/rpms/filesystem/pull-request/11 > > The commit "Symlink /usr/sbin to /usr/bin if possible" would wipe out > any symlinks in /usr/sbin that point someplace other than /usr/bin when > everything becomes a symlink. It should make sure they all point to > where you expect before removing them all. Indeed. I added that check, and the same check in the place where symlinks were removed when package was uninstalled (/usr/sbin/foo should be removed only if it actually points to ../bin/foo). I also added one more scriptlet to do create symlinks, so now there's %filetriggerin -- /usr/bin %filetriggerpostun -- /usr/bin %filetriggerpostun -- /usr/sbin I did more testing and I think this now covers all cases of installs, upgrades, downgrades, and reinstalls. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Merging /usr/sbin to /usr/bin
On Thu, Apr 11, 2024 at 04:29:19PM +0200, David Sastre wrote: > Not sure if SELinux policy needs to learn about the merge as well. > Currently, `sudo semanage fcontext -l | rg bin.*=` shows: > > ``` > /sbin = /usr/sbin > /bin = /usr/bin > ``` > > And there are executables in both /usr/bin and /usr/sbin with specific > labels Oh, SELinux. I filed this is a dicusssion starter: https://github.com/fedora-selinux/selinux-policy/pull/2077 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Merging /usr/sbin to /usr/bin
Hi!
I'm trying to get
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin implemented.
It was approved for F40, but only a few days before the mass rebuild,
so there wasn't time to do much, so it was retargeted to F41.
We now have some time before the F41 mass rebuild, so I want to push
all the changes required in various packages so that we have time to
work out any kinks before the mass rebuild commences.
When I started looking at individual packages, I discovered that we
have an old rule that packages are SUPPOSED to use "historical paths"
to list their files. This rule was introduced to make the transition
easier when UsrMove was implemented for F17. For example, mount.nfs
was historically installed as /sbin/mount.nfs, so nfs-utils must use
%files:/sbin/mount.nfs, even though /sbin is a symlink to /usr/sbin,
meaning that the real path after installation is /usr/sbin/mount.nfs.
And packages using a file path dependency on mount.nfs must use
/sbin/mount.nfs too.
To implement this rule, packages must use %buildroot/sbin during
installation and use literal "/sbin/" in the files section. This idea
made sense at the time, but now it seems overcomplicated and
unecessary. It requires additional work from packagers who create the
packages that provide the files, but also additional work from
packagers that want to refer to those files. In fact, I only found
three packages that implement the rule correctly: nfs-utils, glibc,
and ocfs2-tools. So step 0. is to drop the packaging rule:
https://pagure.io/packaging-committee/pull-request/1355
As to the actual sbin merge:
Currently, we have %_bindir==/usr/bin, %_sbindir==/usr/sbin,
and /sbin->/usr/sbin, /bin->/usr/sbin.
In the end state, we will have %_bindir==%_sbindir==/usr/bin,
and /bin,/sbin,/usr/sbin -> /usr/bin. This end state is simple:
_any_ path will works for any binary.
It's the transition, as we rebuild packages with the new definition,
that requires some careful handling.
After experimenting with a few different ways to handle this, the
following approach seems to work best:
1. rpm is patched to provide %_sbindir==/usr/bin.
(This affects what paths packages will list after being rebuilt.)
2. filesystem is patched to not contain /usr/sbin in %files,
but instead symlink /usr/sbin -> bin in %pretrans.
On fresh installations, this will succeed, so the merge is in place.
On upgrades, this will fail, meaning that /usr/sbin remains a dir.
There is also a %posttrans scriptlet to attempt a merge on upgrades,
more about this below.
In particular, since buildroots are created afresh for each build,
package builds will get merged-sbin.
3. We need to handle the case where package foo had /usr/sbin/foo, but
this file will be in /usr/bin/foo after rebuild. After the merge is
done, /usr/sbin/foo and /usr/bin/foo will point to the same
location, no problem, but during the transition, users or scripts
might call /usr/sbin/foo. To make this work, filesystem rpm gets a
scriptlet that will create symlinks from /usr/sbin to /usr/bin, for
any files which were installed by packages in /usr/sbin. (A list
was obtained using repoquery.)
Initially, I wanted to put those scriptlets in individual packages,
but that turns out to be a lot of duplicate work. Some packages
have multiple subpackages with files (currently) in /usr/sbin, so
we'd end up with a lot of churn. Doing it once in filesystem turns
out to be fairly easy.
4. We also need to handle the case where other package bar has
Requires:/usr/sbin/foo. Once foo has been rebuilt, it has only an
automatic provides for /usr/bin/foo. We could adjust bar for the
new path, but then bar would not be installable on old systems.
Instead, a compat virtual Provides:/usr/sbin/foo is added to foo.
We know that either /usr/sbin will be a symlink, or that filesystem
will create the /usr/sbin/foo symlink.
We need to ensure that the filesystem package that is installed is
actually new enough so that the Provides is not a lie.
filesystem.rpm gets a virtual
Provides:filesystem(unmerged-sbin-symlinks)=1 which is used as
Requires:filesystem(unmerged-sbin-symlinks) by foo.
(An explicit Provides/Requires allows us to adjust or rescind the
mechanism in the future.)
5. After this preparatory work is done, we can rebuild
various packages with updated rpm and filesystem.
Packages which don't use %_sbindir generally don't care.
Some packages which use %_sbindir need small adjustments.
There are some common failure modes:
a. 'mv %buildroot/%_bindir/foo %buildroot/%_sbindir/'
b. 'ln -s ../bin/foo %buildroot/%_sbindir/foo'
c. Listing both %_bindir/foo and %_sbindir/foo in %files
d. 'ln -sf ../bin/foo %buildroot/%_sbindir/foo.alt'
e. 'ln -sf ../sbin/foo %buildroot/%_bindir/foo.alt'
To make builds work both before and after the merge, a-c should be
conditionalized on '%if "%{_sbindir}" != "%{_bindir}"'.
Re: convert everything to rpmautospec?
On Mon, Apr 08, 2024 at 01:12:38PM -0500, Michel Lind wrote: > On Mon, Apr 08, 2024 at 07:21:40AM -0400, Neal Gompa wrote: > > On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote: > > > It's bascially the same problem as Fedora has when users upgrade from > > > Fredora > > > 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade > > > path > > > between Fedoras is not maintained anymore and users need to do "dnf > > > distro-sync" to ignore the RPM versioning. > > > > > > All that stems from tha fact that a number of commits between parallelly > > > supported braches is not monotonic. > > > > > > > We did this long before rpmautospec existed. We switched to this > > behavior in Fedora 23 because we have never fully maintained "upgrade > > paths" across releases. > > > > Per private message with Neal this seems to be the Change that brought > it about: > > https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades > > I'm ... a bit surprised that we don't seem to have any documentation > stating explicitly that the assumption that NEVRAs in a newer release > are no longer assumed to be monotonically higher. That Change was primarily about replacing fedup with dnf-plugin-system-upgrade, changing from a custom-initrd-based solution that was rather fragile, to a special systemd target during early boot. dnf-plugin-system-upgrade uses 'distro-sync' because that's the most reliable and easy way to do the upgrade, suitable for end users. But this doesn't necessarilly mean that this is the only upgrade method that can be used. That Change certainly wasn't intended to change the packaging guidelines. In general, we still keep the upgrade path. It's not enforced all the time, but I think it's still good style. There is a lot of code out there that doesn't handle downgrades very well, in particular if there is data in files or state. So it seems always a bit iffy when a version is downgraded during a system upgrade. It seems that in practice, this actually happens mostly when people forget to build for rawhide or branched, not when they intentionally update a package in older releases only. > e.g. packaging guidelines still say "Rawhide is allowed to lag > *temporarily*" (emphasis mine) > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily > > I suppose the user facing documentation does say that upgrading using > only DNF is not tested -- but there's no guideline about loosening > monotonicity provided to packagers as far as I can tell. > > https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/#_can_i_upgrade_between_fedora_releases_using_only_dnf And I think that's all good ;) > - should we update the packaging docs? Does this need to be a new Change > Proposal or does this just need to go through the Fedora packaging > committee? (Those involved in the Change like zbyszek can probably > advise here) IMO, no. > - should we extend this further and say, if we no longer assume NEVRAs > are monotonically increasing in a new release, we should allow > packagers to use this opportunity to drop epochs in Rawhide? (likely > with proper announcement beforehand in devel@) IMO, no. The fact that you can upgrade between versions and mix packages from different releases, for testing or other purposes, is great. I wouldn't throw this out just to save the bit of hassle that is required to deal with Epochs. > (this might require coordination with RH's Leapp developers and > AlmaLinux's ELevate developers, to make sure those support upgrading > to lower NEVRAs too) It'd probably cause pain for our downstreams. While not a strict blocker, it's yet anothe reason to not do this. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 08, 2024 at 04:11:14PM +0200, Petr Pisar wrote:
> V Mon, Apr 08, 2024 at 11:37:48AM +0000, Zbigniew Jędrzejewski-Szmek
> napsal(a):
> > OK, so you mean that the approach with '.' at the end of Release
> > doesn't work. Yes, that case is not supported very well.
> >
> > There is no great solution here, but there are a few options. Which
> > one makes the most sense depends a lot on the package. But in particular:
> > - just switch to non-autorelease numbering when introducing the
> > minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
> >
> > Looking at the docs again, the docs are not great, and we should
> > support this case better. This certainly needs looking into.
> >
> Now I recalled yet another downstream issue: Importing without a git history
> will reset release numbers. That hashes RPM-dependencies which refer to
> a specific release (like "Conflicts: foo < 1-20" after a package split). One
> should of course carefully check them on import, but forking whole
> distribution like that into a new downstream distribution warrants there will
> remain gems like this.
I can feel the pain, but realistically, with 31% of specs in Fedora using
rpmautospec (as discussed in another leg of the thread), any downstream will
need to solve this issue programatically. Whether it's 15%, 30%, or 90%
of packages, doesn't matter at this point… it must be handled by a script.
Essentially this ship sailed when rpmautospec was officially allowed
in Fedora and was used in the first hundred packages. At that point,
downstream has no choice but to adapt.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Tue, Apr 09, 2024 at 12:57:33PM -0400, Neal Gompa wrote: > On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote: > > > > > > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a): > > > > And we already have a significant fraction of packages using > > > > rpmautospec, > > > > > > > > > Actually, could you quantify the "significant fraction"? > > > > 7399 / 23912 = 31%. > > How much of it is non-Rust and non-Go? 3720 / 19454 = 19% when '^(rust|golang)-.*\.spec' is filtered out (which matches most but not all rust packages). 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Tue, Apr 09, 2024 at 03:38:07PM +0200, Gerd Hoffmann wrote: > > In particular: > > - local builds work, I do them all the time, with 'fedpkg local' or > > through an srpm. > > Using rpmbuild directly needs some adaption though: > > (1) Use 'rpmautospec calculate-release' to figure what the release > number is. > (2) Pass that to rpmbuild using --define "_rpmautospec_release_number $nr". I don't use rpmbuild directly very often, but: fedpgk srpm fedpkg local work fine both when there are uncommitted modifications and when not. I actually use "fedpkg srpm && mock $options $(ls -1tr *.src.rpm|tail -n1)" all the time, and that also works with and without uncommitted modifications. What goes wrong if _rpmautospec_release_number is not difined? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote: > > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a): > > And we already have a significant fraction of packages using rpmautospec, > > > Actually, could you quantify the "significant fraction"? 7399 / 23912 = 31%. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Tue, Apr 09, 2024 at 10:04:11AM +0200, Remi Collet wrote: > Le 07/04/2024 à 17:15, Zbigniew Jędrzejewski-Szmek a écrit : > > Thus, the proposal: > > - new packages MUST use rpmautospec > > - packagers SHOULD convert their packages > > - provenpackagers MAY convert existing packages > >(e.g. when they want to push some fix or separately from other > > work) > > - people submitting pull requests against src.fp.o MAY also > >include a conversion in the pull request and packagers SHOULD > >merge it. > > Big -1 to all > > git log IS NOT a package changelog > > Read https://keepachangelog.com/en/1.1.0/ Then it's great the %autochangelog is designed to produce a human-readable changelog that omits what should be omitted and lists the things that are relevant to users. It even adds dates and version information and authorship just like described on the page you linked ;--] 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Summary/Minutes from today's FESCo Meeting (2024-04-08)
Text Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.log.txt HTML Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.log.html Text Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.txt HTML Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-08/fesco.2024-04-08-19.30.html Meeting summary --- * TOPIC: Init Process (@nirik:matrix.scrye.com, 19:30:15) * TOPIC: #3183 Change: PHP No 32-bit (@nirik:matrix.scrye.com, 19:34:05) * AGREED: Change was approved in ticket (+3, 0, -0) (@nirik:matrix.scrye.com, 19:51:47) * TOPIC: #3191 Change: Switch to DNF5 (@nirik:matrix.scrye.com, 19:52:21) * AGREED: APPROVED (+5, 2, 0) (@zbyszek:fedora.im, 20:22:48) * TOPIC: Next week's chair (@zbyszek:fedora.im, 20:26:07) * ACTION: Tom Stellard will chair the next meeting. (@zbyszek:fedora.im, 20:27:40) * TOPIC: Open Floor (@zbyszek:fedora.im, 20:27:54) * AGREED: The time of the meeting is moved half hour earlier, to 19:00 UTC (+6, 0, 0) (@zbyszek:fedora.im, 20:41:28) Meeting ended at 2024-04-08 20:42:15 Action items * Tom Stellard will chair the next 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Monday's FESCo Meeting (2024-04-08)
On Sat, Apr 06, 2024 at 10:45:52AM -0700, Kevin Fenzi wrote: > = Discussed and Voted in the Ticket = > > Change: GNU Toolchain F41 > https://pagure.io/fesco/issue/3181 > APPROVED (+6, 3, -0) Not that it matters for anything, but it's actually (+6, 0, 0), i.e. there were no abstaining votes. (I was surprised by the three, so I went to check the ticket.) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 08, 2024 at 01:11:22PM +0200, Petr Pisar wrote:
> V Mon, Apr 08, 2024 at 10:49:42AM +0000, Zbigniew Jędrzejewski-Szmek
> napsal(a):
> > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL
> > > minor
> > > releases).
> >
> > Hmm, can you provide describe the workflow that is broken in more
> > detail?
> >
> RHEL do updates into older minor distribution versions. E.g. you might want to
> build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should update to that
> build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
> from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to
> the 9.2 build before or not.
OK, so you mean that the approach with '.' at the end of Release
doesn't work. Yes, that case is not supported very well.
There is no great solution here, but there are a few options. Which
one makes the most sense depends a lot on the package. But in particular:
- just switch to non-autorelease numbering when introducing the
minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
Looking at the docs again, the docs are not great, and we should
support this case better. This certainly needs looking into.
> It's bascially the same problem as Fedora has when users upgrade from Fredora
> 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade path
> between Fedoras is not maintained anymore and users need to do "dnf
> distro-sync" to ignore the RPM versioning.
>
> All that stems from tha fact that a number of commits between parallelly
> supported braches is not monotonic.
>
> > > - I sometimes need a different commit message from an RPM changelog entry.
> >
> > That's not a problem, the %changelog entry is customziable, see
> > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
> >
> If I understand it correctly
You understand incorrectly ;) Please see the docs linked above.
> the customization is actually dumping a changelog
> into a static file. So instead of a few-line commit one would need to review
> the complete changelog. No, thanks.
>
> > > - I prefer "fedpkg local" over mock (faster, smaller, easier to debug).
> >
> > That also just works.
> >
> With preserving the release numbers. Last time it subsituted the release
> number with a dummy value. Part of the development is comparing old and new
> builds and testing an upgrade path. A dummy release number is not sufficient.
No. I don't know what "last time" means, but it hasn't been like that
since it was officially introduced in Fedora.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote: > V Sun, Apr 07, 2024 at 03:15:16PM +0000, Zbigniew Jędrzejewski-Szmek > napsal(a): > > I think it's time to switch to rpmautospec completely. > > Thus, the proposal: > > - new packages MUST use rpmautospec > > - packagers SHOULD convert their packages > > - provenpackagers MAY convert existing packages > > (e.g. when they want to push some fix or separately from other > >work) > > - people submitting pull requests against src.fp.o MAY also > > include a conversion in the pull request and packagers SHOULD > > merge it. > > > I don't like it because: > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL minor > releases). Hmm, can you provide describe the workflow that is broken in more detail? > - I sometimes need a different commit message from an RPM changelog entry. That's not a problem, the %changelog entry is customziable, see https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html. > - I prefer "fedpkg local" over mock (faster, smaller, easier to debug). That also just works. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Mon, Apr 08, 2024 at 05:52:07AM -0400, Neal Gompa wrote:
> On Mon, Apr 8, 2024 at 5:37 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> > > I wrote:
> > > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> > > > wrote:
> > > >> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
> > > >> detection of python, and it found /usr/bin/python3.13t that I have
> > > >> installed, and subsequently it got all the paths wrong.
> > > >
> > > > That's why you should never build packages outside of mock.
> >
> > That's another way of saying "it's broken" ;]
> > Mock is great, but I'm doing local development and a local build
> > against my envirnoment is what I need.
> >
> > > PS: Autotools also loves to autodetect random libraries that happen to be
> > > installed on the system. It is in no way specific to CMake.
> > >
> > > >> How do I override this?
> > > >> ('cmake -LAH' doesn't yield anything useful.)
> > >
> > > Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake
> > > for
> > > the variables it uses. (First, try to figure out whether RPM is using a
> > > system-installed FindPython or its own custom version, so you look at the
> > > correct version.)
> >
> > Exactly. I'm sure it doable, but CMake ecosystem somehow doesn't
> > want to integrate with the Linux userspace in the normal way.
> >
>
> You know that pkgconfig *also* uses variables too, right? It's
> perfectly "normal" to do it this way. Arguably, the fact that every
> variable is known and saved in the CMakeLists and CMakeCache data for
> you to read is a boon, because if you need to know a variable to
> override, you can find it easily in the logs.
So… this is what I'm talking about: there is no obvious way to
figure out what to set. Looking at the logs and trying to figure out
some variables from that is not very attractive.
Of course I know pgkconfig uses variables, I don't know what you
are trying to say.
I think CMake hits the "sour spot" here in a few different ways:
- because of the historical mindset, instead of using standard
mechanisms that everybody else uses, it implements custom detection,
- this autodetection very often does things wrong,
- because of the approach with Find* scripts, each package is different
and each detection script has a custom interface, so overriding things
is a lot of work,
- the complicated language that is partially variable-based, partially
macro-based is not easy to follow.
autotools has './configure --help',
meson has all options in `meson_options.txt' and also 'meson configure'
will print all options,
but with CMake the options are buried in Find* and not easy to figure out.
> And this your statement on normalcy is silly since we don't *have* a
> normal way. The GNU Build System (Autotools), Meson, and CMake all do
> things differently, and all three have significant share in our
> packages. Projects that use plain Makefiles are even *more*
> non-standard, as they do whatever they want too.
Yeah, I know we have a bazillion build systems. And all have
to work and the packagers need to use and understand all of them.
Nevertheless, for me, CMake and autotools are outdated technologies
that shouldn't be used in new projects.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> I wrote:
> > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> > wrote:
> >> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
> >> detection of python, and it found /usr/bin/python3.13t that I have
> >> installed, and subsequently it got all the paths wrong.
> >
> > That's why you should never build packages outside of mock.
That's another way of saying "it's broken" ;]
Mock is great, but I'm doing local development and a local build
against my envirnoment is what I need.
> PS: Autotools also loves to autodetect random libraries that happen to be
> installed on the system. It is in no way specific to CMake.
>
> >> How do I override this?
> >> ('cmake -LAH' doesn't yield anything useful.)
>
> Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake for
> the variables it uses. (First, try to figure out whether RPM is using a
> system-installed FindPython or its own custom version, so you look at the
> correct version.)
Exactly. I'm sure it doable, but CMake ecosystem somehow doesn't
want to integrate with the Linux userspace in the normal way.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 08, 2024 at 09:08:19AM +0200, Miroslav Lichvar wrote: > On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote: > > -1 for existing packages certainly - none of my git commit logs > > are written with the expectation that they will double as package > > changelogs so doing so may break the changelog. > > Yes, I think rpm changelog is for users of the package and git log > is for the maintainers. Most of the time the entries apply to both, > but sometimes they don't. This was already answered to some extent, but since it seems to a common misconception, I'll reply here again: %autochangelog is designed to keep the separation between git log and %changelog. Generally, only some git log entries end up with a matching entry in the autogenerated %changelog, see https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#skipping-changelog-entries. > I use a script to generate rpm changelog > entries from git log as a separate commit with the release bump, but > occasionally I need to edit the text. That still works. Just put the whatever text in 'changelog' file, and %autochangelog will use that. (The way it works is that it processes git log from the top, generating %changelog entries, until it hits a commit which touches 'changelog' file, at which points it uses the contensts of that file as the rest of the %changelog. This mechanism is also used when one needs to "edit" the autogenerated changelog.) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Sun, Apr 07, 2024 at 09:08:49PM -0700, Carlos Rodriguez-Fernandez wrote: > On 4/7/24 21:07, Carlos Rodriguez-Fernandez wrote: > > Not all commits correspond with a new release downstream, and not all > > commit messages are relevant to the end user to be part of the change > > log. For example, commits related with increasing gating test coverage > > efforts, or setting up gating.yaml itself. Another example is linting > > setting and/or configurations. How is that handled with autochangelog? > > Can we tell it to skip certain commits? Or should we include it all? Yes, you can skip %changelog for some commits with '[skip changelog]' and provide additional content in the commit message which is not part of the changelog. See https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 08, 2024 at 12:38:47AM +0200, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > I'm revisting the topic of rpmautospec because I was doing some work > > on various packages, and it's annoying that some packages are using > > rpmautospec and others are not. > > The fix for that inconsistency would be to ban rpmautospec. It just makes > everything more complicated. > > > All my packages have been converted, so in day-to-day work, I don't > > even think about %changelog. When working with other packages, I'll > > forget to update the Relase and/or %changelog. Today I was rebasing > > some pull requests in pagure, and the _only_ conflicts that I had were > > about Release and %changelog. > > Generally, it helps to keep all your branches in sync [...] if you are > building the same > versions for all releases (which is typically the one case where you bother > backporting specfile updates across releases at all), and to process pull > requests quickly, before you or rel-eng or another pull request bump the > specfile in Rawhide. Then you rarely have conflicts in %changelog to begin > with. Hmm, so KDE has an explicit exception for the updates policy, so that old releases can be updated and it's indeed possible to keep branches in sync. I _like_ keeping my branches in sync, but for most packages, this is not what is supposed to happen. And sorry, but saying to "process pull requests quickly" is just naive. Busy packages often have many different pull requests concurrently, and some of them need discussion and fixes and work in other places before they can be merged. > I mean, fast-forwarded to the exact same commit hash – no, it is not > a problem if the changelog for a Fedora release includes an entry > for a Rawhide mass rebuild made after that Fedora release branched, > it explains why the Release number has increased and is otherwise > harmless I find that distateful and annoying ;] It's also unnecessary, with rpmautospec and cherry-picking, you get a clean changelog. > > I think it's time to switch to rpmautospec completely. > > Thus, the proposal: > > - new packages MUST use rpmautospec > > - packagers SHOULD convert their packages > > - provenpackagers MAY convert existing packages > > (e.g. when they want to push some fix or separately from other > >work) > > - people submitting pull requests against src.fp.o MAY also > > include a conversion in the pull request and packagers SHOULD > > merge it. > > I am opposed to every part of this proposal. Allowing provenpackagers to > convert existing packages (that they do not explicitly comaintain) would be > particularly rude. I do NOT want any of this automagic (also the various > %auto* macros such as %autosetup) in my specfiles, it just makes my life > harder for no benefit whatsoever. I guess we'll just have to agree to disagree. In the other part of the thread, a proposal that was floated to allow opt-out. I hope that's acceptable. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Sun, Apr 07, 2024 at 06:44:57PM +0200, Emmanuel Seyman wrote: > * Zbigniew Jędrzejewski-Szmek [07/04/2024 15:56] : > > > > On Sun, Apr 07, 2024 at 05:47:57PM +0200, Emmanuel Seyman wrote: > > > > > > This doesn't solve the problem you have so that's a no-go as well. > > > > In what way doesn't it solve the problem? > > In your original post, you stated "When working with other packages, > I'll forget to update the Relase and/or %changelog." This will not go > away if packages are allowed to opt-out. The issue will be greatly reduced. Every package that is convered means a little less busy work ;) > > The opt-out with 'norpmautospec' would solve 1 and 2. > > I've noticed a trend in proposed changes in the way Fedora works. > > They start off as as things packagers will not have to use if they do > not want to and, over time, become default/forced (Matrix vs IRC, > Discourse, ...). Well, you and Kevin see "salami tactics" (whatever that may be), while I see normal engineering practice: some new idea is hatched, it's implemented and used narrowly, them it's applied by default and more widely, and possibly at the end previous methods are deprecated. And yes, the purpose of introducing it narrowly at first is so that we can change course or even revert completely if it turns out to be a bad idea. And also, so we can apply corrections. In another part of the thread, Miro raised some concrete issues, which is useful, because we know that there's something to fix before moving forward. The alternative would be to have "grand plans" where we decide that some technology will be used by default and mandatory before we deploy it widely and get feedback. Maybe this works in a company where management sets the course, but not such much in community project. I think that if you think this through, you'll realize that the "salami tactic" is quite reasonable. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Sun, Apr 07, 2024 at 12:58:04PM -0400, Neal Gompa wrote: > No. I do not want to use rpmautospec as it currently exists. It does > not help me. It does not achieve anything for me. It breaks my > packages for building outside of Fedora Koji. It doesn't even make > things better for supporting automation. > > I do not want to use it unless I absolutely have to (e.g. Rust > packages since rust2rpm sets it up that way). > > -100. > > No. I do not want to use this unless it is finally fixed to enable > rebuild automation. And since that will not happen anytime soon, I > have no compelling reason to use it and tremendous disadvantages > otherwise. It makes building things in COPR terrible, it makes > building things locally annoying, and I can't use it at all reasonably > in non-VCS oriented build systems. Neal, I appreciate the work you with other distributions, but in this case, you're essentially saying that you'll hold Fedora hostage in order to force some unrelated changes that have no consensus. In particular: - local builds work, I do them all the time, with 'fedpkg local' or through an srpm. - builds in copr work. - "non-VCS oriented build systems" — building from srpm works, so they probably actually work, but anyway, it's 2024, we want more version control, not less. - if you want automated rebuilds, please make a proposal and open a new dicussion. Don't beat up on rpmautospec. And we already have a significant fraction of packages using rpmautospec, so you must have _some_ solution in place that works for those packages. Even if rpmautospec doesn't fit those external workflows nicely, maybe even you would benefit if it is used consistently, because then you can apply the same (adjusted) workflow everywhere? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Sun, Apr 07, 2024 at 05:55:08PM +0100, Sérgio Basto wrote:
> I also still see some issues in %autorelease , why fix a typo is a new
> release ?
Either the fix is important and you rebuild and then you _must_ have a
new release, because koji requires a unique NEVRA. Or the fix can wait,
so you commit the fix, probably with '[skip changelog]'.
> in %{forgesource} , as I mention in
> https://src.fedoraproject.org/rpms/rawstudio/pull-request/2#comment-167038
> "forge date should be the date of the last commit upstream of upstream
> git (i.e. git log -1 --format=%cd --date=short | tr -d -)"
There is no problem with that. The forge date is part of the upstream
version information, so it goes into Version.
> and the most important, I don't see "great" benefits and give me more
> work .
Frankly, I think you are not using it properly. I think you must be trying
to adapt some obsolete workflow onto rpmautospec, because otherwise I don't
see how it can increase work. What step is taking more work for you?
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Sun, Apr 07, 2024 at 05:47:57PM +0200, Miro Hrončok wrote: > On 07. 04. 24 17:15, Zbigniew Jędrzejewski-Szmek wrote: > > Hi everyone, > > > > I'm revisting the topic of rpmautospec because I was doing some work > > on various packages, and it's annoying that some packages are using > > rpmautospec and others are not. > > > > All my packages have been converted, so in day-to-day work, I don't > > even think about %changelog. When working with other packages, I'll > > forget to update the Relase and/or %changelog. Today I was rebasing > > some pull requests in pagure, and the _only_ conflicts that I had were > > about Release and %changelog. > > > > I think it's time to switch to rpmautospec completely. > > Thus, the proposal: > > - new packages MUST use rpmautospec > > - packagers SHOULD convert their packages > > - provenpackagers MAY convert existing packages > >(e.g. when they want to push some fix or separately from other > > work) > > - people submitting pull requests against src.fp.o MAY also > >include a conversion in the pull request and packagers SHOULD > >merge it. > > I have some packages where the tooling isn't ready yet for %autorelease, so > I put them on hold. > > I also have some packages with pre-release info still in the Release filed > and moving it to Version with ~ (to use %autorelease) would make the package > downgrade, so I am waiting for a next upstream release to do that. > > I think it's to early to force this. In the other part of the thread, an opt-out via 'norpmautospec' is proposed. So I think we'd use this in such cases too. > > (FTR, 'rpmautospec convert' does the conversion, incl. the commit > > to dist-git. Manual conversion should not be used.) > > Note that it produces incorrect results if the Release value is not > numerical (or if it is a greater number than count of the commits since last > bump). It will happily convert release 0.1 to 3, 29.20130501hg26242d0aa7b8 > to 30 or even release 500 to 10. > > I converted all of my packages with it and in some cases I had to manually > fix the results. > > E.g.: > > https://src.fedoraproject.org/rpms/printrun/pull-request/8 > https://src.fedoraproject.org/rpms/pypy3.10/pull-request/15#comment-179619 > https://src.fedoraproject.org/rpms/poly2tri/pull-request/2 + fixup commit on > top https://src.fedoraproject.org/rpms/poly2tri/c/053f90 That's unfortunate :(. I'll take a look if the code can be improved. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Sun, Apr 07, 2024 at 05:47:57PM +0200, Emmanuel Seyman wrote: > * Zbigniew Jędrzejewski-Szmek [07/04/2024 15:35] : > > > > OK, so if there was an opt-out, [...] > > This doesn't solve the problem you have so that's a no-go as well. In what way doesn't it solve the problem? The problem was stated as (with numbering added): On Sun, Apr 07, 2024 at 05:23:01PM +0200, Miroslav Suchý wrote: > I have bunch of packages where the spec is > [1] present also in upstream and > [2] the package is build for epel7 too. > [3] build the package locally (outside of dist-git) often. The opt-out with 'norpmautospec' would solve 1 and 2. And actually 3 is a misunderstanding, I think. If the package is built locally, i.e. outside of dist-git, then it doesn't really matter if the original package was using rpmautospec or not, you get the srpm with the %changelog inserted. (And if you don't want to use rpmautospec, then put the opt-out in dist-git, and then 3 is solved too.) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Sun, Apr 07, 2024 at 03:30:01PM +, Gary Buhrmaster wrote: > On Sun, Apr 7, 2024 at 3:23 PM Miroslav Suchý wrote: > > > > Dne 07. 04. 24 v 5:15 odp. Zbigniew Jędrzejewski-Szmek napsal(a): > > > > I think it's time to switch to rpmautospec completely. > > > > -1 from me. > > > > While I enjoy simplicity of rpmautospec in some of my packages. > > > > I have bunch of packages where the spec is present also in upstream and the > > package is build for epel7 too. And I build the package locally (outside of > > dist-git) often. The enforcement would complicate my life. > > +1 to the -1 (for basically the same reasons). OK, so if there was an opt-out, like a file in dist-git 'norpmautospec' (in analogy to noautobuild that packages use to opt out of automatic rebuilds)? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
convert everything to rpmautospec?
Hi everyone, I'm revisting the topic of rpmautospec because I was doing some work on various packages, and it's annoying that some packages are using rpmautospec and others are not. All my packages have been converted, so in day-to-day work, I don't even think about %changelog. When working with other packages, I'll forget to update the Relase and/or %changelog. Today I was rebasing some pull requests in pagure, and the _only_ conflicts that I had were about Release and %changelog. I think it's time to switch to rpmautospec completely. Thus, the proposal: - new packages MUST use rpmautospec - packagers SHOULD convert their packages - provenpackagers MAY convert existing packages (e.g. when they want to push some fix or separately from other work) - people submitting pull requests against src.fp.o MAY also include a conversion in the pull request and packagers SHOULD merge it. (FTR, 'rpmautospec convert' does the conversion, incl. the commit to dist-git. Manual conversion should not be used.) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 10:15:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
> One particular issue I have with CMake as a downstream maintainer is
> it's often very hard to override linking or compilation options
> or when the project is using one of the cmake find scripts that gets
> something wrong… It's possible that those projects are "doing cmake wrong",
> but it seems that CMake makes it easy to do things wrong.
I just had to interact with CMake, so let's use that as example:
I'm rebuilding rpm.rpm with some local patches using 'fedpkg local' in F40.
The build fails with:
Directory not found:
/home/zbyszek/rpmbuild/BUILDROOT/rpm-4.19.1.1-2.fc41.x86_64/usr/lib64/python3.12/site-packages/rpm
Hmm, why? Oh, rpm uses cmake, and cmake has it's own special detection of
python, and it found /usr/bin/python3.13t that I have installed, and
subsequently
it got all the paths wrong. How do I override this?
('cmake -LAH' doesn't yield anything useful.)
(When compiling a python module, any other alternative would be better.
The build uses %python3, i.e. /usr/bin/python3.12, so there's no need
to detect anything, the location of python is known and all this binary
can be called to print all paths. Otherwise, either call
'python3-config' or 'pkgconf python', don't do you own reimplementation.)
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Thu, Apr 04, 2024 at 04:26:52PM -0700, Adam Williamson wrote: > On Thu, 2024-04-04 at 18:35 -0400, Neal Gompa wrote: > > On Thu, Apr 4, 2024 at 6:17 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote: > > > > So here are three brainstorming proposals: > > > > > > > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to be > > > > careful about how we do it. I would still promote Fedora Workstation as > > > > the > > > > main/recommended "leading" desktop, would call Plasma an "alternative > > > > desktop option," and would strongly caution against use of the word > > > > "Workstation" anywhere in the branding for the Plasma version. That is, > > > > let's continue to steer undecided users towards Fedora Workstation, > > > > while > > > > making Plasma easier to find and presenting it more prominently than it > > > > is > > > > today. > > > > > > I like this proposal. It would give the KDE spin more prominence and > > > would be a good reply to the huge work that has been put into the spin > > > in recent times. It also wouldn't disrupt our story about Fedora > > > Workstation. > > > > > > If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be > > > confused with Fedora Workstation. > > > > > > > So, effectively no change other than it moves from the Spins section > > to the Editions section? That would also mean it should be on the > > front page too, like the other Editions. > > Being an Edition is a very significant thing, though, as we conceive of > Fedora more widely than just the download page. We put a bunch of hoops > in the way of IoT and CoreOS becoming editions, and there are hoops in > the way of Silverblue becoming one (or, you know, wherever we go with > that path in the end). My silent assumption was that the current change proposal would be withdrawn and replaced by a new proposal. We have a formal procedure in [1]. Looking at that list, it seems all fine. The only sticky point is whether KDE desktop serves a different purpose than Workstation with GNOME. I'd say it does: desktop preferences are like religion, and people don't just switch (except when they do). [1] https://docs.fedoraproject.org/en-US/council/policy/edition-promotion-policy/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote: > So here are three brainstorming proposals: > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to be > careful about how we do it. I would still promote Fedora Workstation as the > main/recommended "leading" desktop, would call Plasma an "alternative > desktop option," and would strongly caution against use of the word > "Workstation" anywhere in the branding for the Plasma version. That is, > let's continue to steer undecided users towards Fedora Workstation, while > making Plasma easier to find and presenting it more prominently than it is > today. I like this proposal. It would give the KDE spin more prominence and would be a good reply to the huge work that has been put into the spin in recent times. It also wouldn't disrupt our story about Fedora Workstation. If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be confused with Fedora Workstation. > (b) Alternatively, elevate the positioning of all spins on the > fedoraproject.org homepage. Place the link to the spins right next to the > link to Fedora Workstation, above the atomic desktops (which are sadly still > experimental), above the Fedora labs and ALT downloads, and honestly > probably above the non-desktop Fedora editions. Nobody is going to be > confused as to which one is the primary product. I'm not sure. I think the getfedora.o page could use some work, but just moving one or two things might not be enough. For me, when using the website is the huge list semi-orthogonal categories: the top-level split is: - editions, as individual items - atomic desktops - spins - labs - alt downloads Alt downloads is split into: - Fedora 40 beta - network installer - torrent downloads - alternate architectures (even though download pages also have architectures?) - cloud base images - testing images - rawhide The Fedora Spins looks great, IMO. The Fedora Labs page looks nice too. There's also a visual split I also always struggle to find Beta releases when I need them. In some places there's a banner with a link, in other places there's a toogle. And there are at least three domains: getfedora.org, fedoraproject.org, alt.fedoraproject.org. This is hard to navigate. It seems that each subpage uses a different categorization and way to split things. And the different subpages use different visual styles. I think we should have: a) one domain b) a flat categorization where you first select the type (one of the editions or the desktops or spins or labs or network installer or cloud image). The editions should be listed prominently, and the other things can lower in the page or require a click to show. c) at all subpages there should be a toggle button to show pre-release d) once you know what to download, you can see the architecture and format options and torrent vs. iso. In such a structure the same "procedure" would be used to navigate different choices, making it easier to figure out what all the options are. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Tue, Apr 02, 2024 at 04:32:24PM +0100, Richard W.M. Jones wrote: > On Tue, Apr 02, 2024 at 12:45:18AM -0700, Gordon Messmer wrote: > > On 2024-04-01 23:59, Gordon Messmer wrote: > > >Now gdb can print the GOT with the paths providing the memory > > >section containing a function. For example, on a Debian 12 system > > >with liblzma 5.6: > Since no one else replied yet, this is a nice bit of analysis. +1. I put the tool on my TODO list of things to look into. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
[Replying to two mails at once to conserve some electrons.] On Tue, Apr 02, 2024 at 04:03:31PM +0200, Dmitry Belyavskiy wrote: > Thanks. In the period between the proposal was written and published the > TPM2 provider has landed in Fedora. > PKCS#11 provider is already here for a while. > > Should I update the Wiki page to adjust this point? Please do. > > == How To Test == > > > OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40. > > > Applications relying on the ENGINE API can't be built but still work. > > > > That's incompatible with package rebuilds… > > > > An acceptable approach would be to split out the headers to a separate > > -devel file, e.g. openssl-engine-devel, mark it as Provides: deprecated(). > > Existing packages which need the engine headers can adjust to use the > > new header and new packages are prevented by the Packaging Guidelines > > from adding a dependency on deprecated packages. > > Thanks! I like this idea and can update the Wiki page accordingly. Thanks! On Tue, Apr 02, 2024 at 05:12:20PM +0200, Dmitry Belyavskiy wrote: > On Tue, Apr 2, 2024 at 4:32 PM Luca Boccassi wrote: > [...] > The TPM2 package is suitable for all required operations, AFAIK. > I'm also sure about the PKCS11 provider which I follow close enough. > > Please raise detailed issues if you have something particular. > I remember that you mentioned a particular issue about PKCS#11, could you > please try the current version? > My colleagues working on PKCS#11 are not aware of any Yubikey issues, BTW. > > Third-party engines may be a problem but as we don't break ABI, it's not a > problem of the moment. On Wed, Apr 03, 2024 at 09:50:27AM +0200, Clemens Lang wrote: > I did try using the current pkcs11-provider with my Yubikey to > create a signature using openssl dgst -sign > 'pkcs11:serial=18c9662a9c930e9e;id=%02;type=private'. It worked just > fine for me, including prompting for the PIN, twice. > > I did have to enable the PKCS11 provider in my openssl.cnf, but that > could also be done programmatically at runtime by applications> > should they choose to do so. > > I was not able to reproduce the problems you faced in the systemd > upstream ticket you referred to earlier. It is possible that they > have been fixed upstream in the meantime. Thank you both, it sounds like this should work. In systemd, we'll need to adjust the code to use providers, but that should be doable. OK, so with discussed changes, I'm +1. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
On Tue, Apr 02, 2024 at 10:45:32AM +0100, Aoife Moloney wrote: > == Summary == > We disable building the packages using ENGINE API in OpenSSL without > breaking ABI. "Without breaking ABI" is a improvement. Everything else — not so much. > == Detailed Description == > We are going to deprecate OpenSSL engine support. Engines are not FIPS > compatible and corresponding API is deprecated since OpenSSL 3.0. The > engine functionality we are aware of (PKCS#11, TPM) is either covered > by providers or will be covered soon. This doesn't really answer the problems that were raised in the previous round of discussion. Even if the plan is that some functionality will be provided "soon", dropping engine support _right now_ will cause problems for developers and for users: first the providers need to become available and have the complete feature set, then the upstreams have add the relevant provider code and document things so that users know how to adapt, and then we need to integrate all of that downstream in packaging. If we start be ripping out the engine functionality, we'll have a window, of unpredictable length, where the functionality will not be available. This is bad for users, but also breaks the promise that Fedora is the best environment for upstream development. > We don't plan to remove the API from libcrypto.so. We are going to > prevent creating the new packages dependent on OpenSSL ENGINE API and > remove ENGINE dependencies from the existing packages. IIUC, this is implemented by dropping the header files. This is not acceptable: it would break package rebuilds. > == Benefit to Fedora == > We get rid of deprecated functionality and enforce using up-to-date > API. Engine support is deprecated in OpenSSL upstream, and after > provider migration caused some deficiencies with engine support. No > new features will be added to engine. So we reduce maintenance burden > and potentially attack surface. > > It follows approach planned for CentOS 10. Such things are always a tradeoff. The benefit of removing the deprecated code obviously reduced the maintanance burder a bit. But is is really that much? OTOH, it disables features that are being used or developed in a bunch of important projects. It seems very premature to take this step for F41, i.e. sometime within the next two—three months. It seems that the ecosystem isn't ready. The tradeoff for CentOS 10 is different: the first release is still a while away and most people will not jump onto the 10.0 release anyway. By the time CentOS is used in anger, the ecosystem might be ready. This is one of the cases where using Fedora as a pre-release for CentOS as a pre-release for RHEL is detrimental to Fedora. > == How To Test == > OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40. > Applications relying on the ENGINE API can't be built but still work. That's incompatible with package rebuilds… An acceptable approach would be to split out the headers to a separate -devel file, e.g. openssl-engine-devel, mark it as Provides: deprecated(). Existing packages which need the engine headers can adjust to use the new header and new packages are prevented by the Packaging Guidelines from adding a dependency on deprecated packages. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Tue, Apr 02, 2024 at 02:00:52AM -0700, Gordon Messmer wrote: > On 2024-03-30 09:12, Neal Gompa wrote: > > Note that dlopen() doesn't fix the problem of the giant libsystemd in > > the first place. It just obfuscates the true dependency graph of > > libsystemd. > > > This isn't my area of expertise, but I am curious: > > Why doesn't dlopen() solve the problem? As best I understand it, liblzma > was able to steal one (or more) of the symbols from libcrypto.so.3 because > it ran constructors at a point in time when the GOT was still writable. > After loading shared objects is complete, that table is made read-only. If > dlopen() is used after the program starts, then even if the library is > loaded, it can't steal symbols in the table any more. > > Or do I misunderstand this entirely? You understood correctly ;) As you wrote, dlopen() is done after RELRO has taken effect. Also, dlopen() is only called lazily when the required library is to be used for the first time… So in this particular case, the program could call sd_notify(), but no dlopen() call would be done. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote: > On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote: > > Adam, > > > > Is there a way already to achieve test isolation during the rpm build? > > Nothing systematic that I'm aware of, no. It would be tricky because > there is no one universal Standard Test System (not even within a > single language ecosystem, let alone across all of them). Currently > you'd have to design something unique, if you wanted to implement this > for your package. If we wanted to pursue that, I'd suggest the following: remount $RPM_BUILD_ROOT read-only for the %check phase (or maybe overmount it with a writable overlayfs that is thrown away after %check finishes, and warn if any modifications were made.) %check is executed after %install, so everything should be in place before %check, and %check may be skipped, so no modifications to installed files should be done in %check. Considering possible implemention details, machinectl has 'bind' and 'bind --read-only' that might be useful here. But mock uses systemd-nspawn in a way that does register the container with machined. So maybe it'd be more reasonable to just execute a mount command directly from mock. This is independent of the test system and does not require splitting of the test sources. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Mon, Apr 01, 2024 at 09:06:16AM +0900, Dominique Martinet wrote: > Scott Schmit wrote on Sun, Mar 31, 2024 at 05:02:44PM -0400: > > Deleting the tests makes no sense to me either, but it seems like a > > mechanism that ensures the test code can't change the build outputs (or > > a mechanism to detect that it's happened and abort the build) would > > allow upstream tests to be run without compromising the integrity of the > > build itself. > > Just to be clear here that wouldn't have been enough: it's not the test > step that's modifying the binaries, the actual build step is modified in > the right conditions to use data that looks like it belongs to a test > (I've read the actual files aren't actually used in any test and just > look like test data, I didn't check, it wouldn't be hard to make a test > that uses them anyway) > > So short of deleting all blobs e.g. all test data this wouldn't have > been prevented, just not running tests isn't enough. Yep. And since we're talking about xz, note that a second malicious issue has beend found: [1] is a revert of [2] which sabotages CMakeLists.txt to always disable Landlock sandbox. Clearly, the only reasonable solution is to delete all the CMake cruft ;) [1] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00 [2] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Mon, Apr 01, 2024 at 08:46:39AM -, François Rigault wrote: > To echo > > > To trust code, it needs to be reviewed. > > If the code is reviewed, and the build system is sane, [..] > > I deduce from your response that the binary tests committed in > systemd were not reviewed neither by co-maintainers nor by > downstream package maintainers. Yes, some of those blobs are treated as opaque. > I understand that the build system used by systemd makes it much > less probable that some binary blob used in a test obfuscates > something that could be used for other purposes outside the test; > still, wouldn't you agree it would be a good practice to make sure > everyone is able to review everything in the source code repository? It's a trade-off. We can include a useful test case (e.g. a journal file that causes journalctl to busyloop or crash), to verify that the issue was fixed and that we don't regress, or we can reject the file and forego the test. With a reasonable build system, it's fairly easy to figure out how the file is used, and I think it's entirely reasonable to review _that_. OTOH, figuring out what effect that file would have if (hypothetically) used as input to a different tool or whether it might embed some code which might be extracted somehow is hard. But I really think that the risk is low. Also, consider that systemd has 2500 .c and .h files with 875k lines… It's not like you can review that in a weekend. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote: > Adam Williamson wrote: > > Maybe this needs to go on the growing pile of reasons why the > > traditional Linux model *does* need to go away. Maybe Fedora, with its > > foundation of First, should be kind of at the forefront of making that > > happen. > > Switching to a container-based model is just going to introduce more > different library versions (in the worst case, one per container) with a > higher probability that one of them is compromised. Our traditional distro model is not perfect — far from it — and we certainly try to improve it. But I agree with Kevin that in _this particular case_, the other models have smaller chances of catching the issue. Here the upstream was compromised, so 2FA, upstream signatures, and any other checks don't help at all. But in our "traditional model" we have one version of the dependency used for everbody, so there is a strong incentive to review and improve this one particular version. The packaging process is also very open: it is absolutely routine for people to change packagaging for packages owned by other maintainers. The newfangled models are much more about picking particular versions of dependencies and duplicating them in multiple projects. This makes some things easier, and makes things more independent, but I think it'd make the xz bug less likely to be caught. If sshd was packaged as a container or a flatpak, and I saw that it takes .8 instead of .1 seconds to log in, I certainly wouldn't spend the time to figure out why. I'd assume that the authors did something strange and move on to my own things. We talk a lot about the "new ways", but software must still come from somewhere, and the dependencies need to be maintained… Changing the delivery format is not going to magically makes this unnecessary. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, Mar 31, 2024 at 09:07:21AM -, François Rigault wrote: > hi Zbyszek, > how did you review the corrupted journal files committed in systemd? Can you > know for certain that they do not contain any backdoor or anything illegal or > unlicensed? The licensing and legal side is easy: those files are produced by a program that we wrote (journald), so copyright and patents don't apply. In principle there could be some privileged information in those files, but it was disclosed by the person who submitted a pull request with those files, so at this point distributing this information wouldn't make further difference. And also the person submitting them accept the license which allows redistribution. If there's a backdoor: those files are read by a program which is supposed to be resilient against broken input. We execute this program under multiple sanitizers over this input file. So we're doing pretty strong testing that the input is parsed correctly (or refused). I wrote a bit more abou this in other part of the thread [1]. I think that while it's theoretically possible to do something malicious with bad fuzzer samples, it'd be very very do pull off. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4DB56MMWUSBEY7YPD5ARIZGF4FFVRYHJ/, 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 09:07:19PM -, Daniel Alley wrote: > It's not how free software works, but there are some interesting projects > working on (distributed, not centrally managed) code review systems that are > kind of similar in spirit to what OP describes. > > https://github.com/crev-dev/crev > https://github.com/crev-dev/cargo-crev > https://mozilla.github.io/cargo-vet/ > > That is, individuals and organizations can publish the results of their code > audits publicly in a standardized format, tied to a package artifact, and a > downstream consumer could denote which individuals and organizations they > trust to perform said audits. > > It's technically possible and not an entirely ridiculous idea, it's just > economically challenging. How do you find enough people willing and able to > audit a package (including e.g. autotools build scripts), in multiple, to the > level of scrutiny that would be required to catch something like this. I think such cross-checks already happen in practice. When distro packages are updated, maintainers will do _some_ review. We can't force them to full reviews every time, and it wouldn't even make sense, but we can be certain that if anything malicious is found, notifications too the other distros will go out immediately. Or to put in a different way: if distribution publishes a package, we implicitly know that they did the review of that package in that version to the level they consider acceptable. We if asked them to make an additional signature, it wouldn't add much. As a maintainer, the level of review I do for updates varies a lot: for some upstreams I'll do a patch-by-patch review and maybe use diffoscope to see what changed in the internals, for some upstreams I'll scan the NEWS file, and for other upstreams I'll not even do that, if I know what is hapenning in the project and I trust the quality and integrity. If there was a "task force" auditing packages, I think it should apply some variant of that rule: focus on packages which are a) important, b) have few maintainers, c) have lots of ugly internals, d) raise suspicion for whatever other reason. This would probably yield better results then trying to apply the same level of scrutiny accross the board. -- That said, one useful variant of the auditing proposal would be to check that different distributions actually have the same source tarballs, for the same versions of the same packages. This is something that could scripted and occasionally executed. It'd be very suspicious if it turned out that the "upstream tarball" differs in Fedora or Arch or Debian or Suse or any other distro. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 06:56:27PM +0100, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > Meson outclasses CMake in functionality, > > LOL, how so? Everything in Meson is hardcoded, you have very little > flexibility (but still enough to plant a backdoor if that is what you want, > because you can just invoke a shell script or any other external command). > CMake is completely extensible with a complete programming language (it is > Turing-complete if and only if you use recursive functions; if you avoid > FUNCTION or at least recursive ones, then it is guaranteed to always > terminate and still usually expressive enough, but Turing-completeness > through recursion is there if you really need it). Pretty much every build system is Turing-complete, and pretty much every build system allows scripts to be called. Upstreams can do crazy stuff with any build system too. I think Meson hits the sweet spot where simple projects can be expressed in very few very readable lines. And common configuration tests that need to be done are still very readable. The handling of dependencies and options is very declarative. (Meson is also evolving, in early versions it was less so.) It'd be interesting to see some real statistics, e.g. over all Fedora packages, but in my experience, CMake projects tend to have many more files with lots of lines. > > clarity, and brevity. > > That is very much in the eye of the beholder, and it also depends on whether > you use modern CMake or legacy constructs that are often overly verbose. True ;) In _my_ eye, it's prettier. I guess we'll not achieve consensus. One particular issue I have with CMake as a downstream maintainer is it's often very hard to override linking or compilation options or when the project is using one of the cmake find scripts that gets something wrong… It's possible that those projects are "doing cmake wrong", but it seems that CMake makes it easy to do things wrong. > > I doesn't make sense to consider switching to CMake at this point. > > CMake being what the whole Qt and KDE community uses nowadays (even Qt > itself switched to it with Qt 6), it very much makes sense to switch to > CMake now more than ever. Right, but if one doesn't work on Qt, then this argument doesn't do much. [snip] > > One thing which is happening, mostly for unrelated reasons, it that > > systemd code is being changed to use dlopen() for various libraries which > > are usually not needed at runtime. The primary motivation for this is to > > omit such libraries from the initrd. But this also helps with overlinking. > > > > In systemd git main, libsystemd is only linked to libc, libcap, > > and libgcrypt + libgpg-error. A pull request to convert that that last > > pair to dlopen is under review. > > That helps somewhat (it would have prevented this backdoor from working), > but it also makes things even less transparent: How do we know whether some > random sd_foobarify() function or some random foobard linked against > libsystemd will (always or ever (and when?)) end up dlopening liblzma or > not? > > Distribution packagers tend to dislike dlopen due to the hidden dependencies > it introduces. This is true. It'd be great if the compilers and linkers supported a "weak dependency" model, where we'd use the normal call syntax and things would be the same as with a normal shared library link, but if that library is not found, the program would still load and run. Then we could still autogenerate those dependencies on optional libraries, but using Recommends instead of Requires. Right now the dependency handling needs to be handled manually, which is error-prone and annoying. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 06:58:05PM +0100, Kevin Kofler via devel wrote: > Neal Gompa wrote: > > Note that dlopen() doesn't fix the problem of the giant libsystemd in > > the first place. It just obfuscates the true dependency graph of > > libsystemd. > > At least it (hopefully) means liblzma will not be opened if you do not use > an API that needs liblzma. But it makes it even harder to tell whether > liblzma will end up being loaded or not. > > > Long ago (I think like ~10 years ago), libsystemd was actually several > > separate smaller libraries. Perhaps we could consider asking upstream > > to switch back to that model? > > +1 This comes up occasionally, and the main reason to not do this is that systemd code has a lot of helpers that are used across a lot of the codebase and we end up with recursive calls between many of the different "components". So if tried to split things, we'd either need to remove a lot of polish, or copy code, or have the shared code duplicated. Some of those split-out libraries would probably end up embedding almost all of some of the other ones. libsystemd now consists of 12 parts (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path, sd-resolve) and it'd be a lot of work to untangle, and the overall footprint would likely grow. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 08:51:03PM +0100, Dmitry Belyavskiy wrote: > Dear Kevin, > > On Sat, Mar 30, 2024 at 8:12 PM Kevin Kofler via devel < > devel@lists.fedoraproject.org> wrote: > > > Miroslav Suchý wrote: > > > 4) Fetch build artifacts before executing tests > > > > > > https://github.com/rpm-software-management/mock/issues/1352 > > > > Or better: Do not execute tests to begin with! rm -rf test in %prep and > > NEVER run tests during builds. Even when the tests are all legitimate, all > > it does is slow down the build (e.g., compare glibc build times without > > and > > with tests) and every so often break it because the test, not the > > software, > > is broken. And a claimed "test file" is what allowed the payload to be > > snuck > > in here. > > > > It's a terrible idea. Sorry. Yes, it's a terrible idea. Also it doesn't solve anything. Because if you can inject code into the tarball to inject code into the tests, then you can also inject code into the output binaries, but you can also inject it into configuration tests. Our official policy is to run tests during build, because that helps to catch many silly mistakes and miscompilations. If we stop doing that, we'll close one avanue of attack, leaving a few ~equivalent avanues of attack open which share the characteristic that if one is accessible to the attacker, most likely all are. > > Unit tests are something for upstream developers. They should NEVER be run > > in a distribution build. > > > > The first thesis is completely wrong. Having, say, a 30+ downstream patches > and declining to run upstream tests is the most effective way to break a > gazillion use-cases. > > But the fuzzing tests look quite dangerous to me here and now. No one can > review a corpse of binary files :( Meh, the primary purpose of such tests is to stress the code under sanitizers. Those test cases are not added randomly, they are added by upstream developers when they solve an issue. To construct an attack, somebody would need to construct a sample that does not trigger any failures with sanitizers, but actually causes a misbehaviour allowing taking control of execution. Then this control would need to be used to modify the build artifacts (because presumably doing something in the sandboxed build environment is not particularly interesting), and _then_ the attacker would need to convince the maintainers to commit the sample. This is all theoretically possible, but pretty hard to pull off. Again, I think that the important aspect is reviewability, not some simple rule about the format of files. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 08:00:29PM +0100, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > I think there's some useful points here, but this would need to be > > qualified and/or made more flexible to be applied. > > > > For example, systemd repo has fuzzer case files, which are a mix of > > text, mojibake, and actual binary protocol samples. For example, dhcp > > input packets, dns packets. There are also other ~binary test files, > > for example corrupted journal files. > > > > The tests are defined via meson.build, so those files are "referred to > > in the build tools", and would not be allowed by the above definition. > > But if we dropped those, we'd lose very valuable testing of the codebase. > > On the other hand, "test files" are exactly how the payload of this backdoor > was disguised! So a policy that deletes all binary test files or even all > test files altogether would have prevented this backdoor. Well, if we made a rule that "binary" files are not allowed, the attacker would e.g. commit some minified bash that generates whatever output is needed. The real problem was the complex and unreadable build system that made it easy to embed _multiple_ obfuscated components for the attack. To trust code, it needs to be reviewed. And if the code is reviewed, and the build system is sane, it's usually fairly easy to say "oh, this is a sample and the only way it's used is as input to a fuzzer binary", or "this sample is used as input to a unit test", etc. A policy against binary files would hinder this particular implementation of the attack, but the attacker had full control of the repo, so they would be able to arrange the attack around such a policy without too much trouble. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 07:28:43PM +0100, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > In fact, we should probably make the effort to add pkgconf files for the > > few libraries that don't have it to make it completely standard and > > expected. > > That is a particularly bad idea. Downstream .pc files are a nuisance. I agree, I never suggested doing this downstream. This kind of thing needs to happen upstream so that other upstreams can start depending on it. A pkgconf file is very simple to add, it's the kind of a thing that can be provided as a pull request by an external contributor, in particular a downstream maintainer. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 09:20:28AM -0700, Carlos Rodriguez-Fernandez wrote: > I like the idea of the security path as well, where all packages in that > path have upstream subject to higher security standards (that means helping > them to achieve it as well), and greater defense downstream in any way > possible. > > Two things that came to mind I shared in another channel: > * no binary blobs in the upstream, or no blob referred to in the source > built, or referred to in the build tools I think there's some useful points here, but this would need to be qualified and/or made more flexible to be applied. For example, systemd repo has fuzzer case files, which are a mix of text, mojibake, and actual binary protocol samples. For example, dhcp input packets, dns packets. There are also other ~binary test files, for example corrupted journal files. The tests are defined via meson.build, so those files are "referred to in the build tools", and would not be allowed by the above definition. But if we dropped those, we'd lose very valuable testing of the codebase. > * diffoscope should show no difference except file stats between the tar.gz > being pulled by the spec, and the source brought with a git clone. Here, OTOH, I'd just say that the tarball generated from a git clone should be bit-identical to the tar.gz pulled in by the spec. > Both things could be automated with tools. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
On Sat, Mar 30, 2024 at 05:59:36PM -, Daniel Alley wrote: > It appears that libsystemd links to libraries for lzma/xz, bzip2, gzip and > also zstd, because some systemd utilities provide them as options in various > different contexts (but not consistently, zstd for instance is seemingly > supported by some utilities and not by others, and I see some code such as > [0] that doesn't account for it) > > I'm sure having all of those different options available is nice in some > context or another, but how unrealistic would it be to pare that back to a > few slightly more opinionated and consistent choices? Bzip2 for instance > isn't particularly good on *any* metric, are there legacy / ecosystem reasons > that are sufficiently important for libsystemd to be dragging it around? > libsystemd linking 4 different compression libraries does seem a bit > excessive (if it can be helped). > > [0] > https://github.com/systemd/systemd/blob/3799fa803efb04cdd1f1b239c6c64803fe85d13a/src/import/importctl.c#L493 libsystemd is linked to compression libraries primarly because those compressors are options for journald files, and we generally want to mainain the property that all journal files from the past, as well as journal files from other systems, can be read by later journal code. (bzip2 is an exception here. It is only used by systemd-importd and related tools, so libsystemd was never linked to it, IIRC.) In recent systemd versions, dlopen is used for various compression libraries and other libraries, so they'll be opportunistically loaded if needed, effectively making those dependencies optional at runtime. Conversions to use dlopen require a bit of boilerplate code and make the code less readable, so we only would to them if there was a reason. Usually, this reason was size and/or the dependency tree. Compression libraries are very small and have no dependencies, so it wasn't considered important to use dlopen for them. But now that there's a new motivation, as mentioned elsewhere in the thread, we'll load pretty much all dependencies of libsystemd via dlopen. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 03:23:55PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote: > > Once upon a time, Michael Catanzaro said: > > > I agree that running autoreconf on our packages makes sense to start > > > doing. Still, to avoid this backdoored m4 file, we would have needed > > > to stop using release tarballs altogether and switch to using git > > > tags directly instead. That would at least force the malicious > > > attacker to commit their code to version control, making it slightly > > > harder to hide the attack. > > > > Using a signed tarball is ideally better than a git tag (it's an extra > > level of author attestation)... but where both are available, it'd be > > nice to have a way to denote in the spec file that there are two URLs > > for the source. In this case, if both URLs were listed and something > > could be run to automatically fetch and compare them, the attack code > > would have been flagged. > > Tarball production should be reproducible. Then the maintainer can > both make a signature locally and make it public, and users can download > the auto-generated tarball. > > In fact, github tarball generation is stable. A few years ago they tried > to improve the compression method (i.e. .tar would be still identical, > but .tar.gz would be different), and after a huge outcry this was reverted. > They still haven't officially said that it's stable, but let's hope that > it never changes, at least not without a suitable advance warning. I used the following to check all 193 github tarballs provided for systemd (those are autogenerated): git clone --bare https://github.com/systemd/systemd dir=systemd.git tags=$(git --git-dir=$dir tag|rg '^v\d+(\.\d+)?$'|sed 's/^v//'|sort -g) for v in $tags; do echo $v if [[ v =~ . ]]; then wget https://github.com/systemd/systemd-stable/archive/v$v/systemd-$v.tar.gz git --git-dir=$dir archive v$v --prefix=systemd-stable-$v/ | gzip >systemd-$v.local.tar.gz else wget https://github.com/systemd/systemd/archive/v$v/systemd-$v.tar.gz git --git-dir=$dir archive v$v --prefix=systemd-$v/ | gzip >systemd-$v.local.tar.gz fi cmp systemd-$v.local.tar.gz systemd-$v.tar.gz || break rm systemd-$v.local.tar.gz systemd-$v.tar.gz echo done Fortunately, they all match ;) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 10:02:42AM -0500, Michael Catanzaro wrote: > On Sat, Mar 30 2024 at 02:55:21 PM +00:00:00, Zbigniew Jędrzejewski-Szmek > wrote: > > CMake for many years fought against pkgconf and pushed people towards > > copying those scripts into sources. It is still very common for projects > > using CMake to come with a whole directory of badly written detection > > scripts that each replace a single-line pkgconf invocation. > > > > And of course nobody has time to look into those scripts, making it > > easy to smuggle something through there. > > It's still better than Autotools, though. If a project doesn't want to > switch to Meson for whatever reason, then CMake is a reasonable alternative. > > I agree that CMake is not as good as Meson, and that CMake find modules are > inferior to pkg-config. But then we shouldn't describe them as equivalent alternatives ;) If we say "switch to a modern build systemd, e.g. cmake or meson", people will randomly choose on or the other and since the whole CMake ecosystem is built around find modules, we'll end with a bazillion of those. Instead we should say: "Use meson. If you can't for some reason, consider CMake, but come talk to us first." > The CMake developers are working on replacing find > modules with CPS [1] which is intended to be a replacement for pkg-config > that will work better on non-Linux platforms, where pkg-config is not always > adequate. It looks like that work has maybe stalled? but if successful that > would fix the problem with find modules. > > [1] https://cps-org.github.io/cps/overview.html Ack. But from our point of view, this wouldn't be great. We already have pkgconf files for almost everything and CPS files for nothing… In fact, we should probably make the effort to add pkgconf files for the few libraries that don't have it to make it completely standard and expected. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote: > Once upon a time, Michael Catanzaro said: > > I agree that running autoreconf on our packages makes sense to start > > doing. Still, to avoid this backdoored m4 file, we would have needed > > to stop using release tarballs altogether and switch to using git > > tags directly instead. That would at least force the malicious > > attacker to commit their code to version control, making it slightly > > harder to hide the attack. > > Using a signed tarball is ideally better than a git tag (it's an extra > level of author attestation)... but where both are available, it'd be > nice to have a way to denote in the spec file that there are two URLs > for the source. In this case, if both URLs were listed and something > could be run to automatically fetch and compare them, the attack code > would have been flagged. Tarball production should be reproducible. Then the maintainer can both make a signature locally and make it public, and users can download the auto-generated tarball. In fact, github tarball generation is stable. A few years ago they tried to improve the compression method (i.e. .tar would be still identical, but .tar.gz would be different), and after a huge outcry this was reverted. They still haven't officially said that it's stable, but let's hope that it never changes, at least not without a suitable advance warning. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 09:09:35AM -0400, Neal Gompa wrote: > And in CMake's favor, there's a huge ecosystem of helpers and > integrations that make it easier for people to understand what CMake > is doing as it's being developed, built, and shipped. That is actually a weakness: On Sat, Mar 30, 2024 at 01:38:45PM +, Tim Landscheidt wrote: > Kevin Kofler wrote: > > Well, I have been arguing against this exception (exempting prebuilt > > autotools output) from the "no prebuilt blobs" rule for years, and it > > saddens me that something like this had to happen for Fedora to finally > > realize that that exception has always been a bad idea. > CMIIW, but it would not have made any difference as the > source code had been shipped as part of the tar ball and > auto(re)conf would have happily integrated it into the next > build. I suspect that a modification to CMakeLists.txt and > its includes would not have been detected either; even a > daring, but obvious change in the 3+ lines of source > itself might have gone unnoticed. CMake for many years fought against pkgconf and pushed people towards copying those scripts into sources. It is still very common for projects using CMake to come with a whole directory of badly written detection scripts that each replace a single-line pkgconf invocation. And of course nobody has time to look into those scripts, making it easy to smuggle something through there. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 08:23:48AM -0400, Neal Gompa wrote: > On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel > wrote: > > > (At which point I'd suggest it's probably faster to convert it all to > > > meson or another new shiny, and saner, build system, but getting upstreams > > > to agree will be fun) > > > > CMake! :-) Meson outclasses CMake in functionality, clarity, and brevity. I doesn't make sense to consider switching to CMake at this point. > > This drags in libsystemd > > for sd_notify, and libsystemd is linked to way too much stuff including > > liblzma. Either we need a split libsdnotify that contains only sd_notify, or > > we should just stop using sd_notify at all. It increases the attack surface > > of daemons a lot just to allow the service to be "Type=notify" rather than > > one of the other available approaches. Arch Linux is also systemd-based > > nowadays, but still does not link OpenSSH against libsystemd. > > > > This is related to philosophical differences between Arch and Fedora. > > That said, it probably makes sense for sd_notify to be its own library > instead of being part of libsystemd. I'm sure systemd upstream will > consider it now. :) I don't think a separate library would be particularly useful. sd_notify() as used by sshd just writes a static string to a unix socket. This can be implemented in ~10 lines of C, including error handling. If that is the _only_ thing needed from libsystemd, then open-coding it is a good option. I guess it'd make sense for systemd to provide a header file that provides a reference documentation as an inline function. One thing which is happening, mostly for unrelated reasons, it that systemd code is being changed to use dlopen() for various libraries which are usually not needed at runtime. The primary motivation for this is to omit such libraries from the initrd. But this also helps with overlinking. In systemd git main, libsystemd is only linked to libc, libcap, and libgcrypt + libgpg-error. A pull request to convert that that last pair to dlopen is under review. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"
On Wed, Mar 27, 2024 at 08:32:41PM +0200, Otto Liljalaakso wrote: > > 27. maaliskuuta 2024 12.59.11 GMT+02:00 Petr Pisar > kirjoitti: > >V Tue, Mar 26, 2024 at 02:52:50PM +0100, Miroslav Suchý napsal(a): > >> I have no strong opinion how to process with the case of "MIT and BSD and > >> Bitstream Vera and OFL". I think that converting it to " MIT and BSD and > >> Bitstream-Vera and OFL" is probably best option. I.e. the License tag will > >> become mixture of Callaway and SPDX. It will not make it valid SPDX formula > >> so it will still pop up as package to be fixed, but at least some work will > >> be done. > > > >In other words, it will be a regression. Invalid by either system: > > > >$ license-validate 'MIT AND BSD AND Bitstream-Vera and OFL' > >Not a valid license string > >Run with -v option to see more information. > >$ license-validate --old 'MIT AND BSD AND Bitstream-Vera and OFL' > >Not a valid license string > >Run with -v option to see more information. > > > >I wouldn't do it. > > > >If you want to hint the packager, then open a pull request with the partial > >conversion. > > > >-- Petr > > I also think the conversion should only be done if the full License string > can be converted. Partial conversion is confusing, and there is not much > value, since trivial conversion is, well, trivial, and whoever will > eventually need to take a look at the nontrivial parts can easily handle it > then. I'd add a "me too": I think if we have mixed spdx and callaways strings, this will make later automatic processing even harder. I that is possible, I think you should just do the full conversion for those packages, even if that requires some manual introspection. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Switch to DNF 5 (System-Wide)
On Tue, Mar 26, 2024 at 06:39:35AM +0100, Jan Kolarik wrote: > Previously, I had issues that migration from DNF4 to DNF5 left a lot of > > data in /var/cache. How is this going to be addressed? I don't think it is > > fair to leave those behind and waste disk space for regular users. > > > > That's a good point. Though since this migration isn't entirely removing > dnf4 from the system but just altering the symlink, users can still access > it. Hence, automated removal isn't feasible. However, we could consider > offering a user prompt after the transaction involving symlink replacement, > advising users to delete /var/cache/dnf if they no longer intend to use > dnf4. What about adding the scriptlet to remove /var/cache/dnf to the dnf4 package? (That's how I understood the original ask.) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Change Compose Settings (system-wide)
On Mon, Mar 25, 2024 at 04:50:28PM -0400, Neal Gompa wrote: > On Mon, Mar 25, 2024 at 4:40 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Mon, Mar 25, 2024 at 07:29:09PM +0100, Kevin Kofler via devel wrote: > > > Daniel Alley wrote: > > > > One more point: createrepo_c uses zstd compression level 10, but the > > > > range > > > > goes all the way up to level 22. I would oppose making the default much > > > > computationally heavier than it is currently, but if spending 20x longer > > > > to compress the repo 10% more is desirable to the fedora project, then > > > > createrepo_c could perhaps add a the ability to select a compression > > > > level. > > > > > > > > zstd at high compression levels is very nearly as good at compressing as > > > > xz and sometimes better, while remaining much faster to decompress. -- > > > > > > Considering that compression happens once on the server and downloading > > > and > > > decompression happens many times on many computers, I think we should use > > > the highest possible compression level. > > > > +1 > > > > Keep in mind we also want to make the compose process faster too, I > don't know if it's worth it to spend 20x more time compressing > repodata when we keep trying to get back hours and minutes in the > compose time. I wanted to write that the compression times are small enough for this not not matter, but indeed, at the very highest levels, they do become noticable. $ mv 8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060-filelists.xml filelists.xml $ time zstd -k -9 filelists.xml filelists.xml : 5.38% ( 863 MiB => 46.4 MiB, filelists.xml.zst) zstd -k -9 4.96s user 0.18s system 103% cpu 4.971 total $ time zstd -k -21 filelists.xml Warning : compression level higher than max, reduced to 19 filelists.xml : 4.74% ( 863 MiB => 40.9 MiB, filelists.xml.zst) zstd -k -21 321.49s user 0.31s system 99% cpu 5:22.20 total $ time zstd -k -21 -T8 filelists.xml Warning : compression level higher than max, reduced to 19 filelists.xml : 4.74% ( 863 MiB => 40.9 MiB, filelists.xml.zst) zstd -k -21 -T8 874.57s user 0.70s system 732% cpu 1:59.51 total $ time xz -k -v 8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060-filelists.xml 8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060-filelists.xml (1/1) 100 %44.3 MiB / 862.9 MiB = 0.05133 MiB/s 0:26 xz -k -v 196.88s user 0.63s system 749% cpu 26.337 total (This is multithreaded, and gives a compression ratio of 5.14%.) Dunno, I think anything below a minute should be OK… 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Change Compose Settings (system-wide)
On Mon, Mar 25, 2024 at 07:29:09PM +0100, Kevin Kofler via devel wrote: > Daniel Alley wrote: > > One more point: createrepo_c uses zstd compression level 10, but the range > > goes all the way up to level 22. I would oppose making the default much > > computationally heavier than it is currently, but if spending 20x longer > > to compress the repo 10% more is desirable to the fedora project, then > > createrepo_c could perhaps add a the ability to select a compression > > level. > > > > zstd at high compression levels is very nearly as good at compressing as > > xz and sometimes better, while remaining much faster to decompress. -- > > Considering that compression happens once on the server and downloading and > decompression happens many times on many computers, I think we should use > the highest possible compression level. +1 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2024-03-25)
On Mon, Mar 25, 2024 at 08:30:30PM +, Zbigniew Jędrzejewski-Szmek wrote: > Text Log: > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.log.txt > HTML Log: > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.log.html > Text Minutes: > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.txt > HTML Minutes: > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.html > > * TOPIC: Init Process > * TOPIC: #3173 F40 Change Proposal Status: Incomplete Changes > * INFO: https://fedoraproject.org/wiki/Changes/DefaultBpfman > * INFO: https://bugzilla.redhat.com/show_bug.cgi?id=2269411 > > * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258084 > * INFO: LLVM 18 is effectively complete. (@zbyszek:fedora.im, 19:44:47) > > * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258090 > * INFO: Removing Opessl 1.1 is waiting on a pull request for python2.7, > which is almost ready. > [In fact, this PR was merged tonight and the build is in progress. Yay!] > * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2260081 > > * INFO: Cloud image kiwification is done as of Beta. > * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2260082 > > * TOPIC: #3182 Change: Open SSL No Engine > * AGREED: REJECTED (+1, 1, -5) > > * TOPIC: #3184 Possibility of Delaying Final Freeze Start Date > * AGREED: REJECTED (-6, 0, 0) > > * TOPIC: Next week's chair > * ACTION: Josh Stone will chair the next meeting. > > * TOPIC: Open Floor (@zbyszek:fedora.im, 20:15:05) > * INFO: We will try to hold the meeting April 1st, even though there are > some worries about quorum because of the holidays. > > Meeting ended at 2024-03-25 20:23:38 > > Action items > > * Josh Stone will chair the next meeting. There was in fact one more that should have been announced together with the agenda: = Discussed and Voted in the Ticket = #3174 Nonresponsive maintainer: Irina Boverman irina https://pagure.io/fesco/issue/3174 APPROVED: (+1, 0, 0) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Summary/Minutes from today's FESCo Meeting (2024-03-25)
Text Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.log.txt HTML Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.log.html Text Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.txt HTML Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.html * TOPIC: Init Process * TOPIC: #3173 F40 Change Proposal Status: Incomplete Changes * INFO: https://fedoraproject.org/wiki/Changes/DefaultBpfman * INFO: https://bugzilla.redhat.com/show_bug.cgi?id=2269411 * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258084 * INFO: LLVM 18 is effectively complete. (@zbyszek:fedora.im, 19:44:47) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258090 * INFO: Removing Opessl 1.1 is waiting on a pull request for python2.7, which is almost ready. [In fact, this PR was merged tonight and the build is in progress. Yay!] * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2260081 * INFO: Cloud image kiwification is done as of Beta. * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2260082 * TOPIC: #3182 Change: Open SSL No Engine * AGREED: REJECTED (+1, 1, -5) * TOPIC: #3184 Possibility of Delaying Final Freeze Start Date * AGREED: REJECTED (-6, 0, 0) * TOPIC: Next week's chair * ACTION: Josh Stone will chair the next meeting. * TOPIC: Open Floor (@zbyszek:fedora.im, 20:15:05) * INFO: We will try to hold the meeting April 1st, even though there are some worries about quorum because of the holidays. Meeting ended at 2024-03-25 20:23:38 Action items * Josh Stone will chair the next 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Switch to DNF 5 (System-Wide)
On Mon, Mar 25, 2024 at 03:46:47PM +, Aoife Moloney wrote: > == Summary == > Change the default package manager from dnf to dnf5. > > == Owner == > * Name: [[User:jkolarik| Jan Kolarik]] > * Email: jkola...@redhat.com > > * Name: [[User:jmracek| Jaroslav Mracek]] > * Email: jmra...@redhat.com First, thank you for putting together such a detailed proposal. Having all the dependencies listed allows a proper evaluation of how things are going to work during the upgrade. Second, I think that the lack of support for dnf5 in some areas is going to be painful: in particular, as long as Anaconda and PackageKit depend on dnf-3, we're going to be in a strange state the basic system tools use two different versions of the code, and perhaps more importantly, use two different databases of information about installed packages. But, third, I think we should do the switch. Dnf5 is some aspects significantly better than dnf-3, so users will really benefit from the switch. And we cannot and should not maintain the situation where the dnf team is working on two different versions of the code. We need to switch to the new thing and devote the resources we have to making it work great. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Obsoleted packages in F40
On Mon, Mar 25, 2024 at 07:30:43AM -0700, Tom Stellard wrote: > On 3/24/24 02:25, Miroslav Suchý wrote: > > I just upgraded my workstation to F40 and it surprised how many packages > > were reported by `remove-retired-packages`. > > There was lots of orphaned packages - there is nothing to do about them. > > But there was lot of packages that were removed intentionally. See the list > > at the end of my email. > > > > I want to highlight that we have policy for removing policy > > > > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal > > which at the end mention adding the package to > > https://src.fedoraproject.org/rpms/fedora-obsolete-packages > > > > Doing this will improve the experience of users upgrading to the next > > Fedora version. > > > > Sorry, I missed this step for some of my packages. Is there still > time to add packages to fedora-obsolete-packages for f41? Yes, both for f40 and f41. There is actually no time limit: if we figure out that e.g. a package is blocking upgrades, we'll add it to f-o-p even after the release. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Schedule for Monday's FESCo Meeting (2024-03-25)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-03-25 19:30 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #3180 Change: SPDX License Phase 4 (The last one) https://pagure.io/fesco/issue/3180 APPROVED (+8, 0, 0) #3144 Nonresponsive maintainer: Christopher Engelhard lcts https://pagure.io/fesco/issue/3144 APPROVED (+2, 0, 0) = Followups = #3173 F40 Change Proposal Status: Incomplete Changes https://pagure.io/fesco/issue/3173 = New business = #3182 Change: Open SSL No Engine https://pagure.io/fesco/issue/3182 #3184 Possibility of Delaying Final Freeze Start Date https://pagure.io/fesco/issue/3184 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
On Thu, Mar 21, 2024 at 12:15:43PM +0100, Dmitry Belyavskiy wrote: > Dear Jun, > > > > On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him) > wrote: > > > On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy > > wrote: > > > > > ... > > >> > == Detailed Description == > > >> > We are going to build OpenSSL without engine support. Engines are not > > >> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. > > >> > The engine functionality we are aware of (PKCS#11, TPM) is either > > >> > covered by providers or will be covered soon. > > >> > > >> "will be covered soon" > > >> > > >> ... so lets wait until that work is actually complete before > > >> removing this from openssl, otherwise there's a window of > > >> brokenness in Fedora where the old feature is removed and > > >> the new feature is not ready. > > > > > > > > > I am not going to land this change until the tpm2 provider is landed in > > Fedora. > > > But the affected packages must start prepare to this change as early as > > possible. > > > > Hi Dmitry, > > Could you provide the upstream OpenSSL project's issue ticket(s) or > > pull-request(s) about the feature adding or updating the providers to > > cover all the functionalities that engines have? > > I would like to track the progress of the work. > > > > I'm quite surprised. > I'm pretty sure that providers cover all the functionalities that engines > have. > (It doesn't mean that for each an every engine exists a 1:1 replacing > provider, but it's a question to the authors of these engines) > > If you are aware of any deficiencies, could you please let upstream or me > know? https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MUFNAZT3IIVWPAYVNHP72SRL4XTKJRTY/ ? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
On Wed, Mar 20, 2024 at 07:15:56PM +0100, Clemens Lang wrote: > Hi, > > > On 20. Mar 2024, at 18:11, Joe Orton wrote: > > > > On Wed, Mar 20, 2024 at 02:05:52PM +, Daniel Berrange wrote: > >> Another alternative is to continue providing fully functional engine > >> symbols, but remove the header files so in practice you can't compile > >> something new that uses it. This is still forking the API, but at least > >> has not forked the ELF ABI, so the upgrade doesn't explode. > > > > This is a really good idea, I hope Daniel's comment is not lost here. > > It isn’t, we are very much aware of this possibility and have already > discussed it before. > > The ENGINE API is a source of subtle bugs especially when used together with > providers, though, so we would really prefer to disable it completely rather > than keeping it around. PKEY objects backed by an ENGINE use a number of > different lesser tested code paths in the OpenSSL source code, which lead to > all sorts of weird an inconsistent behavior. > > > > On 20. Mar 2024, at 16:07, Zbigniew Jędrzejewski-Szmek > > wrote: > > > > Sorry, but the idea to drop symbols without changing the SONAME > > must be rejected. If upstream plans to drop the symbols for 4.0, then > > that is OK, assuming that the SONAME is bumped then. > > > This does already not match reality. OpenSSL provides a number of symbols > that are dependent on compile-time options. Take a look at [1, 2]. Every > symbol in there that is tagged with EXIST::FUNCTION followed by a string that > is not DEPRECATEDIN_3_0 is only present when the associated configure-time > option is enabled. > > For example, an OpenSSL configured with no-des will not provide the > DES_xcbc_encrypt symbol. The assumption that one specific SOVERSION of > OpenSSL will always contain the same symbols on all operating systems is thus > incorrect. Obviously this is not a change that can be made during the > lifetime of a specific Fedora release, but ahead of a mass rebuild, it should > be doable to land a change such as this without changing the SONAME, > considering the problem you want to avoid with the SONAME bump *already* > exists between different builds of OpenSSL with different configuration. I expect the following behaviour from Fedora (or any distro that cares about stability for users): - For a given SONAME, symbols are only ever added, never removed. - Ideally, symbol versioning is used. - ABI stability is also maintained for a given SONAME. - If support for a given symbol needs to be removed, it can be replaced by a stub that is noop or returns an error, as appropriate. This approach was discussed earlier in the thread. (This can be useful e.g. for functions that implement some optional functionality and programs using those functions can still work even if those specific functions stop working. For example, a library that implements a bunch of compression methods, and one of them starts returning an error, and the programs will fall back to a different compression method, is a case where this could be useful.) - SONAME changes happen only if absolutely necessary. This means that if I compile a program against a library in Fedora, it'll continue to function indefinitely, in the sense of the dynamic linker loading the program without fuss. If the SONAME changes, I'll need to either recompile or install the older version of the library with the old SONAME. Dependent packages, both from the distro and external, can use rpm dependencies to prevent upgrades that'd break programs. Obviously, the items in the list above are much easier if the library upstream does the right things. So please, don't ever change compilation options in Fedora in a way that would cause symbols to disappear. Certainly not during one release. But even doing this at a release boundary is bad. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote:
> > > == Benefit to Fedora ==
> > > We get rid of deprecated functionality and enforce using up-to-date
> > > API. Engine support is deprecated in OpenSSL upstream, and after
> > > provider migration caused some deficiencies with engine support. No
> > > new features will be added to the engine. So we reduce the maintenance
> > > burden and potentially attack surface.
> >
> > What is upstream's intention with the 'engine' feature deprecation ?
> >
> > Are they going actively remove this functionality after some
> > period of deprecation ? If so what's upstream timeframe, and
> > should Fedora just wait for that, rather than jumping the
> > gun ?
> >
>
> As I understand, upstream is going to remove engines but it wouldn't happen
> before OpenSSL 4.0
> I don't think Fedora should wait for that. We definitely want to land
> no-engine in RHEL10 so Fedora should be ready for that.
Sorry, but the idea to drop symbols without changing the SONAME
must be rejected. If upstream plans to drop the symbols for 4.0, then
that is OK, assuming that the SONAME is bumped then.
We can try to rebuild distro packages, but we do not control everything
that is built by users. Removing symbols without bumping SONAME will
break user programs.
> > Should we not preserve the ENGINE_* symbols, but turn
> > their impl into either a no-op, or reporting a runtime
> > error, as appropriate for each API.
>
> All 100+ symbols? I don't think providing non-working stubs would be a good
> idea...
If we were to do this, this would be the least bad option.
It's not that much work to generate a 100 stubs of the form
ENGINE* ENGINE_by_id(const char*) { return NULL; }
But I don't think we should do the removal at all.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
