Re: Guidance on individual packages requiring x86_64-v2 baseline ?

[Daniel P . Berrangé]

On Wed, Jun 12, 2024 at 11:50:00AM -0400, Ben Cotton wrote:
> On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé  
> wrote:
> >
> > The context is that QEMU has recently merged changes upstream that force
> > use of the x86-64-v2 baseline for QEMU, in order get more efficient code
> > in the TCG emulator. The changes were made in QEMU's global CFLAGS so this
> > will affect all usage of QEMU, whether KVM, or TCG, for both VMs and user
> > space emulation (the latter used by podman for non-native containers)
> >
> > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users
> > with older x86_64 hardware would likely be unable to run QEMU, from F41
> > onwards, unless some TBD action is taken.
> 
> Could the answer be "we patch the build to not use the changed FLAGS"?
> (Perhaps also creating a qemu-zoomzoom package that's the same as the
> regular qemu but with the upstream CFLAGS that people who can take
> advantage can install instead)

It isn't as simple as changing the CFLAGS. QEMU used to check for
the CPU feature at startup, set a flag, and then later use that flag
to choose different codepaths, but this logic was removed. Avoiding
the flag check in hot-paths makes a perf difference.

So we would have to revert the whole patch series in Fedora. That's
doable today, but I'm not confident carrying a local only revert over
time.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Guidance on individual packages requiring x86_64-v2 baseline ?

[Daniel P . Berrangé]

On Wed, Jun 12, 2024 at 10:05:13AM -0400, Ben Beasley wrote:
> This never made it to the packaging guidelines, but FESCo made a relevant
> decision a few years ago:
> 
> Libraries packaged in Fedora may require ISA extensions, however any
> packaged application must not crash on any officially supported
> architecture, either by providing a generic fallback implementation OR by
> cleanly exiting when the requisite hardware support is unavailable.
> 
> https://pagure.io/packaging-committee/issue/1044

Wow, that is incredibly *loosely* written. That allows for glibc to
build itself with '-march=x86-64-v2', or for systemd to build itself
with '-march=x86_64-v2 -mneeded', at the discretion of the maintainer.
This would effectively reverse the entire decision to reject the
x86-64-v2 baseline feature proposal for.

Surely that is not what they meant to permit ? Surely this exception
was only intended to be scoped more narrowly ? Perhaps to non-critical
path libraries, or only packages outside the default release media ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Guidance on individual packages requiring x86_64-v2 baseline ?

[Daniel P . Berrangé]

On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote:
> On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé  
> wrote:
> >
> > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
> > > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé  
> > > wrote:
> > > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users
> > > > with older x86_64 hardware would likely be unable to run QEMU, from F41
> > > > onwards, unless some TBD action is taken.
> > > >
> > > > Thus I'm wondering whether Fedora has any policy or guidance on handling
> > > > such a situation both in general, and more specifically for "critical 
> > > > path"
> > > > packages, if that difference is relevant ? The packaging guidelines 
> > > > aren't
> > > > especially explicit about this situation, unless I've missed something
> > > > beyond the "compiler flags" and "architecture support" sections.
> > > >
> > >
> > > Absent a project-wide decision to move to the newer baseline, I think
> > > the best approach we can take would be to find some way to communicate
> > > to the user that the software isn't usable. In the case of Qemu, does
> > > the application report an error or crash if it's run on hardware
> > > without the requisite baseline?
> >
> > I've not tested, but I would expect it to crash attempting to execute an
> > illegal instruction
> >
> 
> OK, that's a situation that will lead to annoying and unresolvable bug
> reports. Would it be possible to put something in place that would
> check processor capabilities early in execution before hitting any of
> the affected instructions?

Not trivial as a bunch of code executes from ELF constructors before
main() starts.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Guidance on individual packages requiring x86_64-v2 baseline ?

[Daniel P . Berrangé]

On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
> On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé  
> wrote:
> > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users
> > with older x86_64 hardware would likely be unable to run QEMU, from F41
> > onwards, unless some TBD action is taken.
> >
> > Thus I'm wondering whether Fedora has any policy or guidance on handling
> > such a situation both in general, and more specifically for "critical path"
> > packages, if that difference is relevant ? The packaging guidelines aren't
> > especially explicit about this situation, unless I've missed something
> > beyond the "compiler flags" and "architecture support" sections.
> >
> 
> Absent a project-wide decision to move to the newer baseline, I think
> the best approach we can take would be to find some way to communicate
> to the user that the software isn't usable. In the case of Qemu, does
> the application report an error or crash if it's run on hardware
> without the requisite baseline?

I've not tested, but I would expect it to crash attempting to execute an
illegal instruction

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Guidance on individual packages requiring x86_64-v2 baseline ?

[Daniel P . Berrangé]

There have been various change proposals & associated mailing list threads
over the years about the possibility of moving Fedora compiler toolchain
to build with a newer x86_64 baseline ABI, which have ended up rejected,
with some quite strong negative feedback.

Regardless of the Fedora general policy, however, individual packages may
have forced a particular x86_64 baseline ABI through their own CFLAGS
defined by the upstream project.

The context is that QEMU has recently merged changes upstream that force
use of the x86-64-v2 baseline for QEMU, in order get more efficient code
in the TCG emulator. The changes were made in QEMU's global CFLAGS so this
will affect all usage of QEMU, whether KVM, or TCG, for both VMs and user
space emulation (the latter used by podman for non-native containers)

IOW, if [when] we rebase Fedora to the next QEMU upstream release, users
with older x86_64 hardware would likely be unable to run QEMU, from F41
onwards, unless some TBD action is taken.

Thus I'm wondering whether Fedora has any policy or guidance on handling
such a situation both in general, and more specifically for "critical path"
packages, if that difference is relevant ? The packaging guidelines aren't
especially explicit about this situation, unless I've missed something
beyond the "compiler flags" and "architecture support" sections.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)

[Daniel P . Berrangé]

On Tue, Jun 11, 2024 at 01:52:19PM +0100, Sérgio Basto wrote:
> On Tue, 2024-06-04 at 14:26 +0200, Jiri Konecny wrote:
> > You should be able to install from Live ISO which we are not
> > modifying 
> > (depends on environment set by SIG owners). However, we won't support
> > X11 together with Wayland on boot.iso. That would be hard to achieve 
> > given to the big amount of changes we are required to do now to
> > support 
> > Wayland.
> 
> 
> If you can't support X11 together with Wayland on boot.iso , why you
> want move to Wayland ? it is stupid break Linux user experience just
> because Wayland is fancy , what we get with Wayland that we don't get
> with X11 ? if you need remove X11 to add Wayland, don't do it ! . Don't
> break the other Linux user systems . Is difficult understand that you
> should not remove components without agreement of everyone ? 
> 
> Linux should support all kind of hardware, if Wayland don't, you should
> provide at least fall backs , and not just ignore the others .

Open Source software in general supports a wide variety of use cases and
hardware. The role of most Linux distros, however, is NOT to provide a
solution for every conceivable scenario or hardware or user.

Instead a Linux distro exists to pull together a curated set of software
that best solves the set of goals their distro has. Each Linux distro
will have their own priorities, and make different tradeoffs in choosing
what software to provide & how to configure & use stuff they do provide.

What we're seeing here is that in Fedora, the distro priorities & goals
are taking us down a path of prioritizing Wayland, over X11. This is a
valid decision & direction for Fedora to choose, because it aligns with
our distro mission statement, part of which is to focus on innovation.

At times some users will be left without support for things that previously
worked, and thus be unhappy with the result. That is an unfortunate, but at
the same time, acceptable outcome. Fedora is not trying to cater to every
possible user feature demand, it is trying to optimize for its mission.

The beauty of open source is that users have a choice to distros, and can
select whichever has a mission & deliverables that best satisfy the user's
needs. There will be distros around that aim to support X11 with a higher
priority.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Macros stored in a separate file

[Daniel P . Berrangé]

On Mon, Jun 10, 2024 at 08:35:36AM -0700, Adam Williamson wrote:
> On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:
> > Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
> > > On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
> > > > Lately, I noticed that several SPEC files in Fedora use this syntax:
> > > > 
> > > > Source:        macros.vlc
> > > > 
> > > > And this file defines macros that are loaded by rpmbuild during 
> > > > buildtime and are used in the SPEC file.
> > > > 
> > > > This makes parsing of the SPEC file harder, because any parser have to 
> > > > have
> > > > this maro file in current directory - just reading SPEC file is not 
> > > > enough.
> > 
> > 
> > There is also:
> > 
> > ~~~
> > 
> > %{load:%{S:1}}
> > 
> > ~~~
> > 
> > 
> > Which actually loads the file.
> > 
> > 
> > > > 
> > > > I mentioned vlc, but it is used in many other packages: valkey, zig,
> > > > typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
> > > > 
> > > > Why are packagers doing this? I am not saying this is bad, it just 
> > > > surprised
> > > > me. I am used to put all macros at the top of the SPEC file and this is 
> > > > new
> > > > to me. What is the benefit?
> > > I don't know if it is the case for vlc, but the common benefit would be
> > > where the same macros are to be used in both this local spec, and the
> > > specs of other dependent RPMs.
> > 
> > 
> > That is precisely the reason I have pioneered this approach and using it 
> > for Ruby.
> 
> It might be nice to package the macros, in that case. That's what we do
> for other languages like Python, in python-rpm-macros...

I guess there's a distinction here between packaging the macros in
their own self-contained RPM, vs packaging them as a sub-RPM of the
"main" package. I don't recall our packaging guidelines expressing
a preference either way. We seem to have a mix of both approaches
across various Fedora packages.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Macros stored in a separate file

[Daniel P . Berrangé]

On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
> Lately, I noticed that several SPEC files in Fedora use this syntax:
> 
> Source:        macros.vlc
> 
> And this file defines macros that are loaded by rpmbuild during buildtime and 
> are used in the SPEC file.
> 
> This makes parsing of the SPEC file harder, because any parser have to have
> this maro file in current directory - just reading SPEC file is not enough.
> 
> I mentioned vlc, but it is used in many other packages: valkey, zig,
> typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
> 
> Why are packagers doing this? I am not saying this is bad, it just surprised
> me. I am used to put all macros at the top of the SPEC file and this is new
> to me. What is the benefit?

I don't know if it is the case for vlc, but the common benefit would be
where the same macros are to be used in both this local spec, and the
specs of other dependent RPMs.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpm-4.20 and __debug_install_post

[Daniel P . Berrangé]

On Tue, Jun 04, 2024 at 08:40:15AM +0200, Sandro Mani wrote:
> Hi
> 
> In rpm 4.20 as currently available in rawhide, defining __debug_install_post
> seems to have no effect. The %mingw_package_header sets __debug_install_post
> as follows
> 
> %mingw_package_header \
> %global __strip %{mingw_strip}    \
> %global __objdump %{mingw_objdump}    \

FWIW, I don't think these two overrides should be required
anymore. The standard strip/objdump commands in /usr/bin
work with PE files these days, and for the pacakges where
we have merged mingw+native specs these overrides aren't
used.

Given that, I'd question whether %mingw_package_header needs
to continue to exist either ? it is no harder / great lines
of code to simply call %mingw_debug_install_post in %install,
thus avoiding the rpm 4.20 compat issue.

> %global __debug_install_post %%{mingw_debug_install_post} \
> %{nil}
> 
> but %mingw_debug_install_post is never executed. Manually running
> 
> %mingw_debug_install_post
> 
> in %install works however.
> 
> Perhaps this is related to [1]? What is the correct way now to trigger the
> custom debug extraction script?
> 
> Thanks
> Sandro
> 
> [1] https://github.com/rpm-software-management/rpm/issues/2204
> --

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: New Fedora Planet

[Daniel P . Berrangé]

On Thu, May 16, 2024 at 05:16:17PM -0300, Pedro Moura wrote:
> Hi everyone,
> 
> We are moving Fedora Planet from the old (python2) software running on
> fedorapeople.org to a new application that is running in OpenShift.
> This new application uses information from the Fedora Account System to
> find blogs, so please make sure your account is updated.
> 
> You can see the new planet at: https://planet.apps.ocp.fedoraproject.org/
> 
> To add blog posts in Fedora Planet you basically need to update RSS URL
> field at https://accounts.fedoraproject.org/

IIUC, you're indicating that the existing planet feed addresses will not
be automatically migrated, and thus everyone has to update their profile,
even if already on the Fedora Planet today ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GIMP 3.0 in F41?

[Daniel P . Berrangé]

On Mon, May 13, 2024 at 12:38:06PM +0200, Fabio Valentini wrote:
> On Mon, May 13, 2024, 12:34 Daniel P. Berrangé  wrote:
> 
> > On Mon, May 13, 2024 at 12:14:14PM +0200, Fabio Valentini wrote:
> > > On Mon, May 13, 2024, 11:50 Dominik 'Rathann' Mierzejewski <
> > > domi...@greysector.net> wrote:
> > >
> > > > On Monday, 13 May 2024 at 01:00, Neal Gompa wrote:
> > > > > On Sun, May 12, 2024 at 4:59 PM Sérgio Basto 
> > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > https://src.fedoraproject.org/rpms/gimp3
> > > > > >
> > > > >
> > > > > What the heck? This should have been gimp2 for the old version, not
> > > > > gimp3 for the new version...
> > > >
> > > > Also, how did this pass review?
> > > >
> > > > License:LGPLv3+
> > > >
> > > > And I'll answer myself: it hasn't or at least I can't find any review
> > > > ticket.
> > > >
> > > > Nils, could you explain how this package ended up in Fedora?
> > >
> > > Standard procedure, everything seems to be in order:
> > >
> > > https://pagure.io/releng/fedora-scm-requests/issue/62152
> > >
> > > The review exception is valid because it's an alternative version of an
> > > existing package, and Nils is also the maintainer of the existing
> > package.
> >
> > It that exception automatic ? I thought it had to be explicitly
> > requested from FPC ? eg in
> >
> >
> > https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure
> >
> > It says:
> >
> >   "The FPC can grant exceptions to the normal package review process.
> >This may happen, for instance, if a large number of similar packages
> >are being submitted at once or if a package is being updated to a
> >new major version while the old version is being kept in the
> >distribution with a different name.
> >..
> >Just file a ticket here, set the component to "Review Process Exception"
> >and explain (with detail) why you're requesting the exemption and the
> >committee will consider it in the next meeting. "
> >
> > So gimp3 falls under the 2nd example documented there, but still sounds
> > like an FPC ticket was needed ?
> >
> 
> The wiki is outdated. All documentation from FPC has been moved to
> docs.fp.o.
> 
> The exceptions are documented here:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process

FYI, the wiki isn't the only outdated place then, see also

  https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#what

  "The Packaging Committee can grant exceptions to the normal
   package review process. This may happen, for instance, if
   a large number of similar packages are being submitted at
   once or if a package is being updated to a new major version
   while the old version is being kept in the distribution with
   a different name. The process for granting exceptions is
   described at Packaging Committee#Review Process Exemption
   Procedure."

the latter being a link to the wiki page with outdated info

> These cases are treated as "automatically approved" and don't need package
> review nor FPC approval.

Ok, does make sense to avoid "bureaucratic rubber stamping" wasting
FPC time in the common case.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GIMP 3.0 in F41?

[Daniel P . Berrangé]

On Mon, May 13, 2024 at 12:14:14PM +0200, Fabio Valentini wrote:
> On Mon, May 13, 2024, 11:50 Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
> 
> > On Monday, 13 May 2024 at 01:00, Neal Gompa wrote:
> > > On Sun, May 12, 2024 at 4:59 PM Sérgio Basto  wrote:
> > > >
> > > >
> > > >
> > > > https://src.fedoraproject.org/rpms/gimp3
> > > >
> > >
> > > What the heck? This should have been gimp2 for the old version, not
> > > gimp3 for the new version...
> >
> > Also, how did this pass review?
> >
> > License:LGPLv3+
> >
> > And I'll answer myself: it hasn't or at least I can't find any review
> > ticket.
> >
> > Nils, could you explain how this package ended up in Fedora?
> 
> Standard procedure, everything seems to be in order:
> 
> https://pagure.io/releng/fedora-scm-requests/issue/62152
> 
> The review exception is valid because it's an alternative version of an
> existing package, and Nils is also the maintainer of the existing package.

It that exception automatic ? I thought it had to be explicitly
requested from FPC ? eg in 

 
https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure

It says:

  "The FPC can grant exceptions to the normal package review process.
   This may happen, for instance, if a large number of similar packages
   are being submitted at once or if a package is being updated to a
   new major version while the old version is being kept in the
   distribution with a different name.
   ..
   Just file a ticket here, set the component to "Review Process Exception"
   and explain (with detail) why you're requesting the exemption and the
   committee will consider it in the next meeting. "

So gimp3 falls under the 2nd example documented there, but still sounds
like an FPC ticket was needed ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Enabling RPM based sysuser handling

[Daniel P . Berrangé]

On Fri, May 10, 2024 at 01:28:07PM +0200, Florian Festi wrote:
> Hi everyone!
> 
> RPM 4.19 added automatic sysuser handling [1]. In Fedora 39 this feature
> was not enabled right away [2] as it requires some care to properly
> transition to it. Also going back to 4.18 was technically still the
> fallback option during this change.
> 
> I just noticed in an issue in the RPM upstream repository [3] that the
> sysuser feature is still not enabled. May be right now might be a good
> time to get this going for Fedora 41. I am happy to help with the
> technical details but would prefer if this effort was driven from within
> Fedora.
> 
> Currently users are either done manually by calling useradd in
> scriptlets or using the macros in systemd-rpm-macros which is a sub
> package of the systemd package. RPM's mechanism is switched off by
> rpm-4.18.92-disable-sysusers.patch in the rpm package.
> 
> 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).
> 
> 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.

IIRC with the current sysusers impl from systemd-rpm-macros, there's an
hard constraint, that the sysusers file had to be explicitly listed
as a separate "SourceNN" file. You could not point %sysusers_create_compat
to a file from the either the build root, or the unpacked source tarball,
as the macro appeared to load its argument at spec parse time.

Does the native RPM implementation avoid this limitation ? It looks like
it probably does...

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Spec file using github repo - not tarball

[Daniel P . Berrangé]

On Thu, May 09, 2024 at 11:21:11AM -0400, Nico Kadel-Garcia wrote:
> On Wed, May 8, 2024 at 4:36 PM Kenneth Goldman  wrote:
> >
> > Is it possible for a .spec file to clone a github.com repo rather than
> > download a tarball?  Can someone link to a working example?
> 
> Git clones are bulky, with the entire history of a project rather than
> merely the state of the repo at the moment of that tag or git commit.

FWIW, they don't have to be bulky  'git clone --maxdepth 1 ...' will skip
downloading the entire history. Still not suggesting that be used for RPMs
though, as the zipfile/tarball will be sufficient

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

calendar.fp.o pointing to obsolete IRC for meetings

[Daniel P . Berrangé]

Somehow the news that various (some ? all? ) Fedora meetings have
moved off IRC, to Matrix passed me by. This is not helped by the
official project meeting calendar:

   https://calendar.fedoraproject.org/

which continues to mislead people who want to attend, by publishing
libera.chat IRC as the venue for meetings which have definitely
moved to Matrix.

Who's responsible for updating this, and is there somewhere issues
should be reported ? Presumably whomever owns each meeting is
responsible for updating it to point to the new Matrix locations,
but do we need a bulk update ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

[Daniel P . Berrangé]

On Wed, Apr 24, 2024 at 01:05:08PM +, Gary Buhrmaster wrote:
> On Mon, Apr 22, 2024 at 12:15 PM Josef Řídký  wrote:
> >
> > Hi folks,
> >
> > this is in advance notice about the upcoming rebase of the openexr package 
> > in Fedora Rawhide and f40.
> >
> 
> I note that there is a patent clause which
> allows DreamWorks to revoke the patent
> grants under some conditions for the
> lossy compression.
> 
> Has Fedora Legal reviewed the revocable
> patent license language, and does there
> need to be a (new) SPDX license to include
> that patent grant (BSD-3-Clause-Patent?)

The revocable patent language is probably harmless, because it looks
to be somewhat similar to the revocable patent clause already considered
acceptable in the Apache 2.0 license. Does need legal review though.

Even if the patent clause is a problem, openexr grants the option
to consume it under the terms of the Apache 2.0, instead of the
BSD + patent grant.

I notice Josef has opened a ticket to request review of this now

  https://gitlab.com/fedora/legal/fedora-license-data/-/issues/510

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

[Daniel P . Berrangé]

On Wed, Apr 24, 2024 at 03:48:28PM +0200, Josef Řídký wrote:
> As the mentioned patent clause is there for 10+ years I might just believe
> it went through Fedora Legal, as it is a much older legal related task than
> I am co-maintainer of the openexr itself.
> 
> But I am fine with having conversation with the Legal team about the proper
> SPDX license clause that should be used for this project.

Yes, I don't think it is correct to merely have "License: BSD-3-Clause"
listed in the spec. The LICENSE file refers to BSD-3-Clause as the
overall license, but the PATENTS file refines that to indicate that
a subset of files are under a choice of BSD-3-Clause OR Apache-2.0,
and that when taken under the BSD-3-Clause there is an additional
patent grant (whose language looks derived from the Apache patent
grant clause). The patent grant feels like it effectively creates
a new version of the BSD-3-Clause that would need a name. IOW the RPM
license would end up being an expression along the lines of:

  "BSD-3-Clause AND (BSD-3-Clause-with-...something... OR Apache-2.0)"

A ticket for Fedora legal at the 'fedora-license-data' repo is the
way forward.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d

[Daniel P . Berrangé]

On Fri, Apr 19, 2024 at 02:21:57PM +0200, Florian Weimer wrote:
> There are multiple PRs and patches floating around that make RISC-V use
> the /usr/lib64 directory, like other 64-bit ports.  However, RISC-V
> recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and
> various upstream projects follow that.
> 
> I think we should follow upstream, so that it's possible to use Fedora
> to do upstream development without patching the sources, or elaborate
> Fedora-specific configure invocations.

I'm not convinced that using /usr/lib64/lp64d would lead to
*less* patching.

Apps targetting Fedora are long used to having to adapt from
using /usr/lib to /usr/lib64. Introducing the use of
/usr/lib64/lp64d instead, just for RiscV, feels likely to
break expectations resulting in apps which build fine on all
Fedora arches except for RiscV

> The other reasons is to
> future-proof the Fedora port against the arrival of an alternative ABI
> that is not fully backwards-compatible (the same reason why the official
> RISC-V documentation requires use of these paths).

This implies we would have to have two different RiscV ABIs built for
every binary, and made parallel installable, as opposed to completely
distinct Fedora arch targets. 

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Daniel P . Berrangé]

On Sat, Mar 30, 2024 at 09:37:44AM +, Richard W.M. Jones wrote:
> I'm not pretending these will solve everything, but they should make
> attacks a little harder in future.
> 
> 
> (1) We should routinely delete autoconf-generated cruft from upstream
> projects and regenerate it in %prep.  It is easier to study the real
> source rather than dig through the convoluted, generated shell script
> in an upstream './configure' looking for back doors.

I've noted many times before how inconsistent it is that many
of us will happily mock a website saying "curl  | sh -",
and then with a straight face tell users to download a tarball
and run the 1 MB auto-generated 'configure' shell script that
is obfuscated to the point of unreadability by autotools. It
is the perfect place to hide malicious code in tarballs. 

> For most projects, just running "autoreconf -fiv" is enough.
> 
> Yes, there are some projects that depend on a specific or old version
> of autoconf.  We should fix those.  But that doesn't need to delay us
> from using autoreconf on many projects today.
> 
> In the xz case this wouldn't have been enough, it turns out we would
> also have to delete m4/build-to-host.m4, which then autoreconf
> regenerates.  I don't fully understand why that is.

This is challenging to address too, since often the 'm4/' directory
contains a mixture of application provided m4 files, and autotools
provided m4 files. You can't blindly purge the m4/ directory. They
could have provided a "m4/my-build-to-host.m4" file that interferes
or overides the main 'm4/build-to-host.m4'. So even if autoreconf
did regenerate that file as desired, you're still not entirely
safe.

Still, it would be good practice to have a way to purge any files
that are known to be autoconf provided, so at least you know which
remaining files to look at for threats / problems.

> (2) We should discourage gnulib as much as possible.
> 
> In libvirt we took the decision a few years ago to remove gnulib.
> It's extremely convoluted and almost no one understands how it really
> works.  It's written in obscure m4 macros and shell script.
> 
> It's also not necessary for Linux since gnulib is mainly about
> porting to non-Linux platforms.  There are better ways to do this.

Be honest about which platforms you genuinely need portability
too in the modern world. Cull obsolete / dead platforms.

While it is a fun intellectual challenge to write portable code
against POSIX, most projects are better off not reinventing the
wheel. Something like GLib takes out a large part of the portability
pain if you really must stick with developing C, and is easy to
adopt incrementally. This is what let libvirt cull its use of
gnulib, which in turn lets us cull the use of autotools

> In the xz case it was a gnulib-derived script which was modified to do
> the initial injection (original:
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD).



> 
> 
> (3) We should have a "security path", like "critical path".
> 
> sshd is linked to a lot of libraries:
> 
> /lib64/libaudit.so.1audit-libs
> /lib64/libc.so.6glibc
> /lib64/libcap-ng.so.0   libcap-ng
> /lib64/libcap.so.2  libcap
> /lib64/libcom_err.so.2  libcom_err
> /lib64/libcrypt.so.2libxcrypt
> /lib64/libcrypto.so.3   openssl-libs
> /lib64/libeconf.so.0libeconf
> /lib64/libgcc_s.so.1libgcc
> /lib64/libgssapi_krb5.so.2  krb5-libs
> /lib64/libk5crypto.so.3 krb5-libs
> /lib64/libkeyutils.so.1 keyutils-libs
> /lib64/libkrb5.so.3 krb5-libs
> /lib64/libkrb5support.so.0  krb5-libs
> /lib64/liblz4.so.1  lz4-libs
> /lib64/liblzma.so.5 xz-libs
> /lib64/libm.so.6glibc
> /lib64/libpam.so.0  pam-libs
> /lib64/libpcre2-8.so.0  pcre2
> /lib64/libresolv.so.2   glibc
> /lib64/libselinux.so.1  libselinux
> /lib64/libsystemd.so.0  systemd-libs
> /lib64/libz.so.1zlib / zlib-ng
> /lib64/libzstd.so.1 zstd
> 
> Should we have a higher level of attention to these packages?  We
> already have "critical path", but that's a broad category now.  These
> seem like they are "security path" packages, an intentionally small
> subset associated with very secure services which are enabled by
> default.
> 
> 
> These are just my thoughts on a Saturday morning.  Feedback welcome of
> course.
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of 

Re: Three steps we could take to make supply chain attacks a bit harder

[Daniel P . Berrangé]

On Sun, Mar 31, 2024 at 01:58:21AM -0700, Adam Williamson wrote:
> On Sat, 2024-03-30 at 09:37 +, Richard W.M. Jones wrote:
> > I'm not pretending these will solve everything, but they should make
> > attacks a little harder in future.
> 
> I don't disagree with Richard's list. However...more in regards to some
> of the grandiose ideas in later posts than Richard's list...I think
> we're in danger of building castles in the sky while not cleaning up
> the poop in our backyard, here.
> 
> Before we start in on the grand fantasies about converting the world
> off autotools or banning binaries in repos or centralized source depots
> authenticated by a committee of Top People, can we remember:
> 
> 1. We *still don't have compulsory 2FA for Fedora packagers*. We *still
> don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE
> COMPULSORY 2FA FOR FEDORA PACKAGERS*.
> 
> 2. Our process for vetting packagers is, let's face it, from a security
> perspective almost *comically* patchy. There are 140 sponsors in the
> packager FAS group. Any one of those people - or someone who
> compromises any one of those 140 accounts - can grant any other person
> on earth Fedora packager status. Our policy on how they should do this
> is
> https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Sponsor_a_New_Contributor/#sponsoring_someone_for_fedora_package_collection
> . The words "trust" and "identity" do not appear in it. There is,
> AFAIK, no policy or procedure by which inactive sponsors have this
> power removed. There is no mandatory 2FA policy for sponsors.
> 
> 3. We have no mechanism to flag when J. Random Packager adds
> "Supplements: glibc" to their random leaf node package. As a reminder,
> *we are a project that allows 1,601 minimally-vetted people to deliver
> arbitrary code executed as root on hundreds of thousands of systems*,
> and this mechanism allows any one of those people to cause the package
> they have complete control over to be automatically pulled in as a
> dependency on virtually every single one of those systems.

This is as much a distro design problem, as a Fedora process
problem. The typical Linux distro model is that everything is
installed in the same namespace, and we only avoid interference
(whether accidental or intentional) by careful packaging design
and review.

This is somewhere where the image based Linux distro model has
a potential benefit, with a comparatively slim distro base, and
then applications as self contained separated entities, whether
server apps in podman containers, or GUI apps in flatpaks.

No easy anwere here though, as the traditional Linux model isn't
going away any time in the forseeable future.

> 4. Our main auth system was written years ago by someone who no longer
> contributes and nobody is really actively maintaining it[0].


5. We review initial new packages in a moderate level of detail,
   but after that it is largely a free for all for every rebase.
   It is up to the maintainer's discretion what to do for new
   releases, and any oversight is patchy at best. The threat here
   was in relation to an update to an existing package, and where
   we have no formal process that was even /interested/ in addressing
   that threat, let alone capable of stopping it.

   Now, in this particular case, it would have been challenging
   to detect it the problem even with "new package" review process,
   so I'm sceptical we can easily build a "updated package" process
   that would have blocked it and yet remain practical for maintainers. 


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

[Daniel P . Berrangé]

On Wed, Mar 20, 2024 at 03:27:34PM +0100, Petr Pisar wrote:
> V Wed, Mar 20, 2024 at 02:05:52PM +0000, Daniel P. Berrangé napsal(a):
> > Consider you've built your own app on Fedora 39 that uses these
> > symbols, and now upgrade to F40. RPM will consider the dependency
> > still satisfied, as the SONAME hasn't changed on libcrypto. The
> > app throws linker errors at some point due to the missing symbols.
> > 
> > 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.
> > 
> Another option is remove the symbols, change soname, and rebuild reverse
> dependencies.

Changing soname is something I don't think distros should ever do. ELF
soname designation belongs to the upstream project maintainers.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

[Daniel P . Berrangé]

On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote:
> Dear Daniel,
> 
> On Wed, Mar 20, 2024 at 1:44 PM Daniel P. Berrangé 
> wrote:
> 
> > On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
> > > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> > >
> > > This is a proposed Change for Fedora Linux.
> > > This document represents a proposed Change. As part of the Changes
> > > process, proposals are publicly announced in order to receive
> > > community feedback. This proposal will only be implemented if approved
> > > by the Fedora Engineering Steering Committee.
> > >
> > > == Summary ==
> > > We disable support of engines in OpenSSL
> > >
> > > == Owner ==
> > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> > > * Email: dbely...@redhat.com
> > >
> > > == 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.

Lets explicitly note that as a blocking /  pre-requisite dependency
for landing this change then.

> > > == 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

That makes sense, as it solves the ELF ABI / SONAME change
issue with removing the APIs.

> 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.

Fedora shouldn't neccessarily be rushed into something just because
RHEL wants to do it prematurely due to RHEL's long lifecycle.

> > > == Upgrade/compatibility impact ==
> > > OpenSSL engines will no longer be supported. Engines will not be
> > > supported in openssl configuration files (presumably silently
> > > ignored). Users will have to reconfigure systems to providers if they
> > > use engines.
> > >
> > >
> > > == How To Test ==
> > > OpenSSL libcrypto.so doesn't export any ENGINE_* symbols (~120 lines).
> > > Application is normally built.
> >
> > Removing symbols is an ABI break, so would imply the need for
> > an SONAME version bump. This is not normally something that
> > downstreams should ever touch though - it is an upstream
> > decision when to bump their SONAME version.
> >
> > 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...

Intentionally forking the upstream ABI is worse IMHO.

Consider you've built your own app on Fedora 39 that uses these
symbols, and now upgrade to F40. RPM will consider the dependency
still satisfied, as the SONAME hasn't changed on libcrypto. The
app throws linker errors at some point due to the missing symbols.

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.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

[Daniel P . Berrangé]

On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
> Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> 
> This is a proposed Change for Fedora Linux.
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> We disable support of engines in OpenSSL
> 
> == Owner ==
> * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> * Email: dbely...@redhat.com
> 
> == 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.

> == 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 ?


> == Upgrade/compatibility impact ==
> OpenSSL engines will no longer be supported. Engines will not be
> supported in openssl configuration files (presumably silently
> ignored). Users will have to reconfigure systems to providers if they
> use engines.
> 
> 
> == How To Test ==
> OpenSSL libcrypto.so doesn't export any ENGINE_* symbols (~120 lines).
> Application is normally built.

Removing symbols is an ABI break, so would imply the need for
an SONAME version bump. This is not normally something that
downstreams should ever touch though - it is an upstream
decision when to bump their SONAME version.

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.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Why can't I add karlowich as co-maintainer of this package?

[Daniel P . Berrangé]

On Mon, Mar 18, 2024 at 09:57:58AM +, Richard W.M. Jones wrote:
> 
> https://src.fedoraproject.org/rpms/xnvme/adduser
> 
> I try to add karlowich (https://accounts.fedoraproject.org/user/karlowich/)
> but his name doesn't appear in the username field even though he's
> in the packager group.  Why?

If they were only recently granted packager status, they might need login
to 'src.fedoraproject.org' to (re)sync group membership perhaps ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dmesg restricted to root in Rawhide

[Daniel P . Berrangé]

On Wed, Feb 28, 2024 at 10:30:10AM +, Richard W.M. Jones wrote:
> On Wed, Feb 28, 2024 at 11:24:41AM +0100, Karel Zak wrote:
> > On Tue, Feb 27, 2024 at 08:15:49PM +, Richard W.M. Jones wrote:
> > > 
> > > https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793a627e7c9aae8854
> > > 
> > > Why wasn't this a Fedora change proposal?
> > > 
> > > Also the justification given for such a major change is very thin.
> > > I'm sure product security can give us some more details of precisely
> > > what exploits will be mitigated, in the change proposal.
> > 
> > You can restore the original behavior by using:
> > 
> > # sysctl kernel.dmesg_restrict=0
> > 
> > However, be aware of the security consequences ;-)
> 
> Right ... which are what exactly?
> 
> I don't have untrusted local users, and if I wanted to host untrusted
> local users I'd need to do a lot of extra lock down, so perhaps the
> default here can be kernel.dmesg_restrict=0 with
> kernel.dmesg_restrict=1 being used on locked down systems.

The protection against information leakage applies to system services as
much as to interactive local users, so it is still valid hardening to do
even on single user machines IMHO.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dmesg restricted to root in Rawhide

[Daniel P . Berrangé]

On Tue, Feb 27, 2024 at 08:15:49PM +, Richard W.M. Jones wrote:
> 
> https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793a627e7c9aae8854
> 
> Why wasn't this a Fedora change proposal?
> 
> Also the justification given for such a major change is very thin.
> I'm sure product security can give us some more details of precisely
> what exploits will be mitigated, in the change proposal.

FWIW, Googling for 'CONFIG_SECURITY_DMESG_RESTRICT' finds several posts
illustrating techniques for exploiting historical CVEs that would be
made harder were CONFIG_SECURITY_DMESG_RESTRICT set, preventing dmesg from
undermining KASLR by leaking kernel addresses to unprivileged processes.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fw: [Bug 2066129] mingw-libgsf-1_14_52 is available

[Daniel P . Berrangé]

On Fri, Feb 09, 2024 at 11:12:42PM -0600, Greg Hellings wrote:
> Looks like I'm not allowed to retire on the f39 branch. It was already
> retired in Rawhide before I could get there.
> 
> $ fedpkg retire "MinGW support merged to native package in Fedora 39
> release"
> Fedora release (f39) is in state 'current' - retire operation is not
> allowed.

Oh well, it should be harmless as long as no one ever updates that
branch with new versions, nor does any new builds from that branch.
The NEVR from the native package should be newer and thus the mingw
sub-RPMs from the native build are what should get into the yum repos.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fw: [Bug 2066129] mingw-libgsf-1_14_52 is available

[Daniel P . Berrangé]

On Tue, Feb 06, 2024 at 08:27:33AM -0600, Greg Hellings wrote:
> I'm happy to pass the project off to whomever needs it, if you give me the
> user name and a quick reference. Or retire it, if you have a link with
> instructions on how to do that.

It should not require more than  the first step in the docs[1]

  fedpkg retire "Merged mingw support into native package"

un in the 'rawhide' branch of dist-git for mingw-libgsf
and then push.

Normally you would never retire in a fedora release branch, but that's
ok in this place as the content isn't going away, it just moved to the
native package. So I think its ok to run fedpkg retire in the f39
branch too, unless something blocks that.

Blocking from koji isn't needed, as the sub-RPMs from the native build
should be newer and thus take priority in the compose too.

With regards,
Daniel

[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fw: [Bug 2066129] mingw-libgsf-1_14_52 is available

[Daniel P . Berrangé]

On Mon, Feb 05, 2024 at 05:34:06PM +0100, Dan Horák wrote:
> Hi,
> 
> could someone in the mingw team look at mingw-libgsf / libgsf (please
> see the bug forwarded below)? If I see right, then the standalone
> mingw-libgsf package should be retired as there are mingw builds from
> the regular libgsf package, which seems to be regularly updated.

Copying Marc-André who added the mingw sub-RPMs to the native
package.

The mingw-libgsf should have been retired on rawhide, as soon
as the libgsf native had a successful build with mingw packages.

At this point I guess it'll need retiring on both rawhide
and f39

> 
> 
>   Thanks,
> 
>   Dan
> 
> 
> 
> Begin forwarded message:
> 
> Date: Mon, 05 Feb 2024 00:09:44 +
> From: bugzi...@redhat.com
> Subject: [Bug 2066129] mingw-libgsf-1_14_52 is available
> 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2066129
> 
> Upstream Release Monitoring
>  changed:
> 
>What|Removed |Added
> 
> Summary|mingw-libgsf-1_14_51 is |mingw-libgsf-1_14_52 is
>|available   |available
> 
> 
> 
> --- Comment #8 from Upstream Release Monitoring
>  --- Releases retrieved:
> 1_14_52 Upstream release that is considered latest: 1_14_52
> Current version/release in rawhide: 1.14.48-7.fc40
> URL: http://www.gnome.org/projects/libgsf/
> 
> Please consult the package updates policy before you issue an update to
> a stable branch:
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
> 
> 
> More information about the service that created this bug can be found
> at:
> https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring
> 
> 
> Please keep in mind that with any upstream change, there may also be
> packaging changes that need to be made. Specifically, please remember
> that it is your responsibility to review the new version to ensure that
> the licensing is still correct and that no non-free or legally
> problematic items have been added upstream.
> 
> 
> Based on the information from Anitya:
> https://release-monitoring.org/project/1980/
> 
> 
> To change the monitoring settings for the project, please visit:
> https://src.fedoraproject.org/rpms/mingw-libgsf
> 
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
> https://bugzilla.redhat.com/show_bug.cgi?id=2066129
> 
> Report this comment as SPAM:
> https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202066129%23c8
> --
> ___
> 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

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Figure out what killed an app (rhbz#2253099)

[Daniel P . Berrangé]

On Wed, Jan 31, 2024 at 11:06:02AM +, Tom Hughes via devel wrote:
> On 31/01/2024 10:08, Milan Crha wrote:
> 
> > I tried to investigate a rawhide bug:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2253099
> > which is about Evolution being killed "by something". That's the thing,
> > I do not know what killed it, thus even why it had been killed. It's
> > even not killed after certain steps, it's killed "randomly", on various
> > occasions.
> > 
> > I did search the internet, but they usually expect the killer is the
> > OOM service, which logs about the action either in the dmesg or in the
> > journal, but in this case there is no sign about whom killed it in
> > either of these logs.
> > 
> > The evolution terminal just says:
> > 
> > Killed
> 
> At the end of of the day it means a SIGKILL was sent to the process
> and that's not something that is logged anywhere as a matter of course
> so you're reliant on whatever sends it saying so.
> 
> You're right that OOM is the usual cause so if you've ruled that out
> you need to think about other things.
> 
> The problem is that SIGKILL is deliberately a very hard stop that
> nothing can trap so normal things like using strace or gdb to catch
> who went it aren't going to work.

The audit subsystem is probably the first choice to find out what's
killing it. Other than that, systemtap or eBPF scripts can be written
to trace this.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Daniel P . Berrangé]

On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote:
> On Tue, Jan 30, 2024 at 8:07 AM Richard W.M. Jones  wrote:
> >
> > On Tue, Jan 30, 2024 at 12:47:44PM +, Sérgio Basto wrote:
> > > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
> > >
> > > and I'm very upset

snip

> My proposal for consideration is this:
> "FESCo will allow these packages in the main Fedora repositories,
> however they may not be included by default on any release-blocking
> deliverable (ISO, image, etc.)"

The approved KDE change https://fedoraproject.org/wiki/Changes/KDE_Plasma_6
indicates the intent for existing Plasma X11 installs to switch to Wayland
during the upgrade process.

There's no perfect answer as some users will be happy to switch to Wayland,
while others will not, while perhaps more will not even be aware of anything
changing.

IMHO if the KDE Sig wants the upgrade path to take users from X11 to
Wayland automatically, then the criteria for allowing back in RPMs
with X11 builds should include "no interference with the X11->Wayland
upgrade path determined by the KDE Sig".

The BZ ticket indicates that there was some testing to show that is not
causing a problem with the upgrades, so it might be a non-issue, but
setting clear expectations in this respect would be a good idea anyway.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: A reminder: you cannot just "revert" package version bumps

[Daniel P . Berrangé]

On Mon, Jan 29, 2024 at 03:43:39PM -0800, Adam Williamson wrote:
> nirik ran a script that checks for versioning issues in Rawhide today, and
> it found several: https://pagure.io/releng/issue/11922#comment-893797
> 
> Some of these followed a pattern, so I figured a reminder was in order. In
> all these cases, a new version was pushed to Rawhide, then "reverted" some
> time later:
> 
> golang-github-nats-io-jwt - bumped to 2.4.1 in July, reverted to 1.2.2 in
> September
> golang-google-grpc - bumped to 1.58.0 in September, reverted to 1.48.0 in
> October; no 1.58.0 build ever landed, but the revert left the %release much
> lower than before
> python-mizani - bumped to 0.10.0 on September 10, reverted to 0.9.3 on
> September 12
> python-pywlroots - bumped to 0.16.6 on November 4, reverted to 0.16.4 later
> the same day
> 
> so the reminder is this: you cannot simply "downgrade" RPM package versions
> like this. Especially not if the upgraded version ever made it into a
> Rawhide compose.

This is the kind of rule that is a prime target for automation. Can we
have Fedora Rawhide gating validate that the NEVR doesn't go backwards,
and block bad builds from getting into the compose.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build error with GCC 14, not even a warning in GCC 13

[Daniel P . Berrangé]

On Tue, Jan 16, 2024 at 11:54:48PM +, Tom Hughes via devel wrote:
> On 16/01/2024 23:49, Richard Shaw wrote:
> > On Tue, Jan 16, 2024 at 5:36 PM Aleksei Bavshin
> > mailto:aleba...@fedoraproject.org>> wrote:
> > 
> > Ah, I misread the include path. It's our package that is too old :(
> > https://src.fedoraproject.org/rpms/rapidjson/pull-request/4
> >  should
> > help.
> > 
> > It doesn't look like the pull request has gotten any attention. Perhaps
> > it's time to initiate the non-responsive maintainer process?
> 
> Right because the other two PRs I've merged in the last couple of
> weeks, including one today, are not evidence of responsiveness?
> 
> That PR is on my to look at list but rather obviously it needs
> more work than the other ones.
> 
> I'm not really keen on packaging a random git snapshot because
> there's no way to know how good or bad it is but I realise that
> due to upstream being a pain it may be necessary here.

The big question is whether the git snapshot is API compatible with
the current version in Fedora.  There are a decent number of things
that depend on rapidjson in the distro and so this needs testing
IMHO before pulling in a git snapshot.

Given the upstream seemingly has no intention of doing more releases,
it feels like our hand will be forced though.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Obsoleting zlib in Fedora Rawhide

[Daniel P . Berrangé]

On Mon, Dec 04, 2023 at 04:10:18PM -0300, Tulio Magno Quites Machado Filho 
wrote:
> Following the recent approval from Fesco, I'm planning to distribute
> zlib-ng-compat packages for Rawhide later this week. 
> I hope this will give us enough time to work on the issues before
> Fedora 40 is released. 爛
> 
> So, keep in mind this will *obsolete zlib in Rawhide*.

snip

> If you have any questions or need help with these issues, let me know.

I've just tried to build latest QEMU in rawhide. We have

  BuildRequires: zlib-devel
  BuildRequires: zlib-ng-static

and when building koji fails to install the build root deps

DEBUG util.py:446:  Error: 
DEBUG util.py:446:   Problem: problem with installed package 
zlib-ng-compat-2.1.5-1.fc40.x86_64
DEBUG util.py:446:- package zlib-ng-compat-2.1.5-1.fc40.x86_64 from @System 
conflicts with zlib(x86-64) provided by zlib-1.2.13-5.fc40.x86_64 from build
DEBUG util.py:446:- installed package zlib-ng-compat-2.1.5-1.fc40.x86_64 
obsoletes zlib < 1.3 provided by zlib-1.2.13-5.fc40.x86_64 from build
DEBUG util.py:446:- package zlib-ng-compat-2.1.5-1.fc40.x86_64 from build 
conflicts with zlib(x86-64) provided by zlib-1.2.13-5.fc40.x86_64 from build
DEBUG util.py:446:- package zlib-ng-compat-2.1.5-1.fc40.x86_64 from build 
obsoletes zlib < 1.3 provided by zlib-1.2.13-5.fc40.x86_64 from build
DEBUG util.py:446:- package zlib-devel-1.2.13-5.fc40.x86_64 from build 
requires zlib(x86-64) = 1.2.13-5.fc40, but none of the providers can be 
installed
DEBUG util.py:446:- package zlib-static-1.2.13-5.fc40.x86_64 from build 
requires zlib-devel(x86-64) = 1.2.13-5.fc40, but none of the providers can be 
installed
DEBUG util.py:446:- conflicting requests
DEBUG util.py:448:  (try to add '--allowerasing' to command line to replace 
conflicting packages or '--skip-broken' to skip uninstallable packages)

It appears that the zlib-ng replacement is not providing a
zlib-static replacement. So rpm ends up trying to install
bot zlib (for zlib-static) and zlib-ng (for zlib-devel) and
this all fails.

AFAICT, this will only work if zlib-ng provides a -static
package.

We can't build QEMU without zlib static, as it is a mandatory
dependancy of the QEMU userspace emulators which are static
linked in order to work as linux binary translators in chroots.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Change of cronie and crontabs CIS compliance

[Daniel P . Berrangé]

On Wed, Dec 06, 2023 at 11:16:44AM +0100, Ondrej Pohorelsky wrote:
> Hi everyone,
> 
> For F40 I would like to change file permissions of few files that are
> provided by cronie and crontabs and swap deny list for allow list. I'm not
> really sure if I should make a change proposal. I figured I'll send an
> email first and see the feedback.
> 
> The driving force of this change is feedback from RHEL customers, that they
> would like to have cronie and crontabs CIS compliant out of the box. Which
> means changing some of the file permissions and swapping `cron.deny` for
> `cron.allow`. As it stands now, they have to run their own scripts or dnf
> plugin (post-transaction-actions) to ensure that each update doesn't
> overwrite the file permissions they manually set.

This CIS compliance problem is not something that is limited to cron. Their
list of hardening steps covers a wide variety of software. IOW, even if cron
were changed, presuambly such customers will need need their own scripts /
dnf plugin to fix all the other apps listed in the CIS compliance guide.

IOW, I feel like the real question here is whether the distro *as a whole*,
not cron, wants/needs to be CIS compliant out of the box, or whether it
should be explicitly an admin deployment task to enable compliance via a
plugin / script.

I understand some organizations have no choice in whether or not they
comply with the CIS guidance - its mandated for many. At the same time
though some of the recommendations, including those for cron, are verging
on snakeoil / extreme paranoia, and as such are dubious to impose on
every users of the distro by default.

> I would like these changes for F40, as this is going to be a branching
> point for next RHEL and I would like to go with upstream first approach.
> 
> *cronie* changes:
> `cron.allow` replaces `cron.deny`  (file permission 600)

I don't see a functional need to create cron.allow by default
to avoid "dnf update" problems.

An admin who wants to deny non-root access to crontab can create
this cron.allow file, even if cron.deny already exists & continues
to exist, and cron.allow will take priority over cron.deny. There's
no need to actally delete cron.deny, if I'm reading the docs right:

[quote 'man crontab']
   Scheduling  cron jobs with crontab can be allowed or disal‐
   lowed for different  users.   For  this  purpose,  use  the
   cron.allow and cron.deny files.  If the cron.allow file ex‐
   ists,  a  user  must  be  listed in it to be allowed to use
   crontab.  If the cron.allow file does  not  exist  but  the
   cron.deny  file  does exist, then a user must not be listed
   in the cron.deny file in order to use crontab.  If  neither
   of  these  files exist, then only the super user is allowed
   to use crontab.
[/quote]

IMHO, the CIS mandate to delete cron.deny looks dubious, and the
stated "dnf update" problem does not exist, and so does not justify
the behaviour regression for Fedora users of switching to a 'deny all'
policy by default.

> `cron.d` permission change (755 → 700)
> `cron.hourly` permission change (755 → 700)
> 
> *crontabs* changes:
> `crontab` permission change (644 → 600)
> `cron.{hourly,daily,weekly,monthly}` permission change (755 → 700)

The main effect of the permissions change on these files is that non-root
users can't see any env variables set against the commands scheduled to run.
The actual command lines are still all visible in the proces listing when
the command runs.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Change of cronie and crontabs CIS compliance

[Daniel P . Berrangé]

On Wed, Dec 06, 2023 at 11:53:26AM +, Tom Hughes via devel wrote:
> On 06/12/2023 11:08, Ondrej Pohorelsky wrote:
> 
> > The only difference is that if you have populated the cron.deny list,
> > after update it gets saved as .rpmsave and cron.allow is created.
> > If the cron.deny is blank, it will get replaced.
> > Also, if you had cron.allow populated before, it will stay this way and
> > blank cron.allow.rpmnew is created.
> 
> Surely there is one more change though?
> 
> Namely that users who could previously run crontab to create
> cron jobs can no longer do so unless they have been added to
> the cron.allow file.
> 
> That seems like a breaking change to me?

Yes, making cron unusable out of the box for non-root users feels like
an pretty major regression in behaviour.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Change of cronie and crontabs CIS compliance

[Daniel P . Berrangé]

On Wed, Dec 06, 2023 at 12:39:02PM +0100, Fabio Valentini wrote:
> On Wed, Dec 6, 2023 at 11:17 AM Ondrej Pohorelsky  wrote:
> >
> > Hi everyone,
> >
> > For F40 I would like to change file permissions of few files that are 
> > provided by cronie and crontabs and swap deny list for allow list. I'm not 
> > really sure if I should make a change proposal. I figured I'll send an 
> > email first and see the feedback.
> >
> > The driving force of this change is feedback from RHEL customers, that they 
> > would like to have cronie and crontabs CIS compliant out of the box. Which 
> > means changing some of the file permissions and swapping `cron.deny` for 
> > `cron.allow`. As it stands now, they have to run their own scripts or dnf 
> > plugin (post-transaction-actions) to ensure that each update doesn't 
> > overwrite the file permissions they manually set.
> 
> Just out of curiosity - what does CIS even stand for?
> The linked Red Hat docs don't expand the acronym, and googling for it
> obviously yields results for something entirely different

It'll be referring to

  https://www.cisecurity.org/benchmark/red_hat_linux

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

[Daniel P . Berrangé]

On Tue, Dec 05, 2023 at 04:14:00PM -0500, Neal Gompa wrote:
> On Tue, Dec 5, 2023 at 3:47 PM Aoife Moloney  wrote:
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > Improve support for unified kernels in Fedora.
> >
> > == Owner ==
> > * Name: [[User:kraxel| Gerd Hoffmann]]
> > * Email: kra...@redhat.com
> >
> > * Name: [[User:vittyvk| Vitaly Kuznetsov]]
> > * Email: vkuzn...@redhat.com
> >
> >
> > == Detailed Description ==
> > See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 
> > goals.
> >
> >  Phase 2 goals 
> >
> > * Add support for booting UKIs directly.
> > ** Boot path is shim.efi -> UKI, without any boot loader (grub,
> > sd-boot) involved.
> > ** The UEFI boot configuration will get an entry for each kernel installed.
> > ** Newly installed kernels are configured to be booted once (via BootNext).
> > ** Successful boot of the system will make the kernel update permanent
> > (update BootOrder).
> > * Enable UKIs for aarch64.
> > ** Should be just flipping the switch, dependencies such as kernel
> > zboot support are merged.
> > * Add a UEFI-only cloud image variant which uses UKIs.
> > ** Also suitable for being used in confidential VMs.
> > ** Cover both x86_64 and aarch64.
> >
> 
> What is the point of using shim in this path? We're not having UKIs
> signed by Microsoft, and unless the Linux kernel knows how to call
> shim for certificates, I don't see how this is supposed to be useful
> for the Microsoft->Fedora->OS boot chain.

The VM UEFI firmware almost always only has the Microsoft certs
installed. Thus the only thing it can boot is shim, which is
signed by Microsoft. The boot configuration tells shim to boot
the desired UKI, signed by Fedora, instead of its compiled
default of booting grub.

The only way you could do away with shim is to install the Fedora
certs in UEFI directly, which isn't something most public clouds
or other VM mgmt  tools support well (if at all).

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update on the Modern C initiative

[Daniel P . Berrangé]

On Sat, Dec 02, 2023 at 05:42:11PM +0100, Florian Weimer wrote:
> * Vít Ondruch:
> 
> > Dne 01. 12. 23 v 11:40 Milan Crha napsal(a):
> >> On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
> >>> Again, some of these are false positives.
> >>Hi,
> >> I think the errors from the configure time of the script are not always
> >> problems, are they?
> >
> >
> > This probably falls into the configuration bucket:
> >
> > https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/blob/main/logs/r/rubygem-ruby-libvirt.log?ref_type=heads
> >
> > But I don't even know where GCC digs up the issues.
> 
> It looks like the GCC output lands in this file:
> 
> ruby-libvirt-0.7.1/usr/lib64/gems/ruby/ruby-libvirt-0.7.1/mkmf.log
> 
> I have not seen that one before, so the log dumper in the buildroot
> instrumentation does not cover it, sorry.
> 
> The failures look like this:
> 
> “
> LD_LIBRARY_PATH=.:/usr/lib64 "gcc -I/usr/include -I/usr/include/ruby/backward 
> -I/usr/include -I. -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Werror=implicit-function-declaration -Werror=implicit-int 
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -fPIC  -m64  -c 
> conftest.c"
> conftest.c:8:16: error: initialization of ‘int’ from ‘char *’ makes integer 
> from pointer without a cast
> 8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>   |^
> In file included from /usr/include/libvirt/libvirt.h:35,
>  from conftest.c:5:
> conftest.c:8:16: error: initializer element is not computable at load time
> 8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>   |^
> conftest.c:8:12: warning: ‘t’ defined but not used [-Wunused-variable]
> 8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>   |^
> checked program was:
> /* begin */
> 1: #include "ruby.h"
> 2: 
> 3: #include "ruby.h"
> 4: 
> 5: #include 
> 6: 
> 7: /*top*/
> 8: static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
> /* end */
> ”
> 
> Looking at the Ruby MakeMakefile documention:
> 
> 
> 
> I think you need to supply a type for these constants and call
> have_const like this:
> 
>   have_const(["VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES",
>   "const char *"], ["libvirt/virterror.h"])
> 
> Does this help?  I'm not a Ruby programmer, so I'm not even sure if I
> got the list syntax right …

Thanks, it turns out these checks are really terribly obsolete. Checking
for existence of features that have been around for 10 years, so I'm
proposing to kill them all upstream and we'll get this into rawhide
after that.

  https://gitlab.com/libvirt/libvirt-ruby/-/merge_requests/28

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proven to be sickened

[Daniel P . Berrangé]

On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:

[snip]

> Granted, these are dissimilar to initial Michaels's issue. But how can I be
> sure that if I touch some of the packages, I won't be told that they were in
> such state for purpose?

IMHO all changes should be opened as merge requests in pagure. This gives
the regular package maintainers a window of opportunity to review the
change before it is merged. If there's no response from the package
maintainer after a couple of weeks then a proven packager can go ahead
and approve the merge request.

Essentially proven packagers can follow the same workflow as anyone else
does for contributing to a package that they are not a (co)maintainer of.
They just need the extra priv of being able to approve their own MR at
their discretion. Pushing directly to git, bypassing merge requests,
should not be required in order to achieve what provenpackagers exist
to do.

At the same time I think it is good to remember that Fedora package
maintainers should think of themselves as guardians, not owners, and
thus should expect to receive contributions from others, including
provenpackagers, doing cleanups to follow Fedora guidelines better.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Daniel P . Berrangé]

On Mon, Nov 27, 2023 at 04:20:16PM +0100, Fabio Valentini wrote:
> On Fri, Nov 24, 2023 at 12:08 PM David King  wrote:
> >
> > The latest released versions of libxml2 have a couple of important
> > changes in header files that have unintentionally caused some packages
> > to fail to build without modification, including:
> >
> > * several functions now accept or return a const xmlError struct
> > * cyclic dependencies in header files were fixed (by dropping some
> >includes)
> 
> Sorry if the answer to this question is obvious - but shouldn't
> breaking changes like these cause an soname bump?
> I realize the whole "unintentional" part - but if these changes also
> affect ABI (the first sounds like it might do that), dependent
> packages would need to be rebuilt either way, wouldn't they?

IIUC, the changes in libxml2 are API breaks, but not ABI breaks.

ie the 'xmlError' parameter should have been const all along,
and apps would have been using it as if it were const. The
API was changed to correct this mistake and should be backcompat
with an pre-existing compiled app, but cause warnings on new
builds. Annoying, but an acceptable change without soname bump.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Daniel P . Berrangé]

On Mon, Nov 27, 2023 at 02:23:51PM +0100, Frederic Berat wrote:
> On Fri, Nov 24, 2023 at 12:07 PM David King  wrote:
> 
> > The latest released versions of libxml2 have a couple of important
> > changes in header files that have unintentionally caused some packages
> > to fail to build without modification, including:
> >
> > * several functions now accept or return a const xmlError struct
> > * cyclic dependencies in header files were fixed (by dropping some
> >includes)
> >
> > Most failures that have been witnessed so far by davidlt while
> > rebuilding RISCV packages, and have been related to the xmlError const
> > change, but xmlsec1 was hit by the include changes:
> >
> > https://github.com/lsh123/xmlsec/pull/729
> > https://src.fedoraproject.org/rpms/xmlsec1/pull-request/4
> >
> > As libxml2 is used rather widely, I expect more changes to come up over
> > time, so please feel free to ask me for help (amigadave on IRC, or Cc
> >  on bugs) and I will be happy to submit patches
> > upstream and do builds; I am a provenpackager, so happy to help.
> >
> > Thanks to davidlt for spotting the breakages!
> >
> 
> Hello,
> 
> I made a mass rebuild of the packages that directly depend on libxml2, and
> found 115 packages (out of 621) with build failure correlated to the
> libxml2 update.
> Out of these 115 packages, 102 so far are highly related (i.e. they show
> xml related errors in the build logs).
> 
> Few notes:
> - Since the new version of libxml2 is already in rawhide I made the mass
> rebuild on F39 with it instead of a rawhide build. That implies that some
> of the packages may already have been fixed but that still gives a rough
> idea on potential problems. I threfore started a mass-rebuild on rawhide to
> cross-check, but I don't have a report to give yet.
> - Out of the 13 packages that seem correlated but don't show obvious errors
> directly related to libxml2, there are still some quite suspicious ones,
> like cinnamon which fails due to a missing xml file.
> 
> When you plan to do such an update, I can only recommend you to do a mass
> prebuild [1][2].
> 
> Full report can be found attached. I also added a log file listing the
> obvious failures.
> 
> I hope that helps a bit.
> 
> Fred.
> 
> [1] https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
> [2] https://gitlab.com/fedora/packager-tools/mass-prebuild
> 

> libosinfo: 
> Source: (distgit) fedora
> NVR: libosinfo-1.11.0-1.fc39
> Commit/branch: 74d2faa889b6199ce7a6b1dfb584d36793796ffb

Not yet fixed upstream, but will get it addressed.

> libvirt: 
> Source: (distgit) fedora
> NVR: libvirt-9.7.0-1.fc39
> Commit/branch: 5828ec5da6d0d2496a964e09f492672b254870c0
> libvirt-glib: 
> Source: (distgit) fedora
> NVR: libvirt-glib-4.0.0-9.fc39
> Commit/branch: 3a288ed6f451fd2719432a9351df72577ae8dc8f

Fixed upstream, pending rawhide update

> virt-viewer: 
> Source: (distgit) fedora
> NVR: virt-viewer-11.0-7.fc39
> Commit/branch: 477761744846305911fd27650219906f7713fac3

Not yet fixed upstream, but will get it addressed.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Summary/Minutes from today's FESCo Meeting (2023-11-09)

[Daniel P . Berrangé]

On Thu, Nov 16, 2023 at 01:39:14PM +0100, Kevin Kofler via devel wrote:
> Fabio Valentini wrote:
> > There's a difference between *claiming* LSB compliance (what you refer
> > to as backwards compatibility ?) and actually *achieving* it.
> > Claiming it (the thing we objected to) without achieving it (i.e. the
> > status quo for many Fedora releases) is a lie that helps nobody.
> 
> True, but the issue is that FESCo sees the bug in the claim and not in the 
> failure to achieve it, which is where the real issue lies.

Attaining LSB compliance requires some interested persons to step up and
volunteer their time to make it happen. FESCo doesn't have the ability to
force people to work on features they're not interested in. So in the
absence of any volunteers, the FESCo decision is the only outcome that
was reasonably possible at this point in time.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Making -Wmissing-include-dirs an error?

[Daniel P . Berrangé]

On Tue, Oct 10, 2023 at 12:16:55PM +0100, Ian McInerney via devel wrote:
> On Tue, Oct 10, 2023 at 11:59 AM Neal Gompa  wrote:
> 
> > Hey all,
> >
> > Recently, one of the folks working on packaging stuff in Fedora KDE
> > nearly missed an issue caused by GCC emitting a warning about missing
> > include dirs:
> >
> > > cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or
> > directory [-Wmissing-include-dirs]
> > > cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or
> > directory [-Wmissing-include-dirs]
> >
> > I did manage to figure out this meant we needed an additional build
> > dependency (qt6-qtbase-private-devel, FYI), but it made me think if
> > there's a reason this shouldn't be an error.
> >
> > If it's an error, then at least we can evaluate these things and
> > ensure we have the right build inputs...
> >
> 
> Missing an include directory isn't necessarily the problem though, it is
> the missing headers that aren't present when they are included that would
> be - and that should trigger a build error for the missing file. What
> advantage does failing on this warning provide that the failure on the
> include file missing doesn't?

The header file may be present in another directory, but as an older
version that should not be used, resulting in building the wrong
featureset.

Last week I uncovered a bug in opensuse 15.4 where they had
patched libtirpc to move its headers directly into /usr/include,
but not correctly changed the pkg-config file which still pointed
to the non-existant /usr/include/libtirpc. 

This case was harmless, as /usr/include is on the default search
path, but it was none the less a genuine bug, and was caught due
our code using -Werror=missing-include-dirs in CI.

The reason for missing-include-dirs to not to be a build error by
default though, is that I suspect there are plenty of apps which
have sloppy build system setup that results in bogus dirs being
added.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Linker Error on Security Issues (System-Wide)

[Daniel P . Berrangé]

On Mon, Nov 13, 2023 at 11:07:19AM +, Aoife Moloney wrote:
> == Scope ==
> * Proposal owners:
> Enable the 'error_for_executable_stacks' and 'error_for_rwx_segments'
> optional features in the binutils.spec file and then rebuild the
> binutils.
> 
> Following that a system wide rebuild will be needed in order for the
> change to have a chance to take affect and cause vulnerable packages
> to fail to build.  Any packages that fail to build because of the
> change will need to be updated to either remove the cause of the
> problem or else add an extra command line option to be passed to the
> linker to disable the new feature.
> 
> * Other developers:
> Other developers will only be affected if their package(s) fail to
> build with the new linker.  In this case the developer will need to
> decide if the security vulnerability is actually needed by their
> package, and if so add a linker command line option to turn off the
> error, or if the vulnerability is not needed then fix their code so
> that the problem is removed.
> 
> It is known that this change will affect the edk2, glibc and grub2
> packages.  Their owners will be contacted to assist them in deciding
> how they wish to resolve the problems specific to their packages.

Looking at selinux policy, there are a fair few other things that
have 'execstack' permission allowed in their policy, which presumably
implies they'll be impacted by the linkage change (either directly or
via some library they utilize).


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Fedora-legal-list] SPDX short name for "Redistributable, no modification permitted" (firmware)

[Daniel P . Berrangé]

On Sun, Oct 15, 2023 at 03:02:34PM -0400, Richard Fontana wrote:
> On Sun, Oct 15, 2023 at 5:13 AM Robert-André Mauchin  
> wrote:
> >
> > Hi,
> >
> > I'm doing a MR on an old package that contains firmware data.
> >
> > I wanna convert to SPDX, what is the equivalent to "Redistributable, no 
> > modification
> > permitted" in SPDX.
> >
> > The license is:
> >
> > The files in the directory src/miniloader are provided pursuant to the
> > following license agreement:
> >
> > License For Customer Use of NVIDIA Software
> >
> 
> >
> > What can I use for SPDX?
> 
> The license first has to be reviewed; this will ultimately result in a
> license identifier that can be used in place of "Redistributable, no
> modification permitted" assuming the license is allowed or otherwise
> tolerated. Please open a new issue in fedora-license-data.
> 
> I think this would be the first firmware license we would specifically
> consider since instituting the new license review process last year.
> The policy on allowed firmware licenses is described here:
> https://docs.fedoraproject.org/en-US/legal/license-approval/#_license_requirements_for_firmware
> These criteria were based on an analysis of known firmware licenses in
> Fedora done sometime around ... maybe 2010 or so? To accommodate this
> license we might have to make some additions to those criteria.
> 
> We haven't yet had to address the question of how to deal with license
> identifiers for firmware. There are three possibilities:
> 1. Ask SPDX to assign an identifier, the usual approach for allowed
> licenses. This is unlikely to be viable because these kinds of
> firmware licenses are pretty far from SPDX's license inclusion
> criteria (which are generally much looser than Fedora's).
> 2. Create a unique LicenseRef- identifier for each firmware license.
> 3. Create an umbrella LicenseRef- identifier for all allowed Fedora
> firmware licenses (similar to how 'Redistributable, no modification
> permitted' was used in the Callaway system).

I guess I'd say what is important / valuable is that we have some
review over the license text, so it isn't a total free for all of
packagers just blindly using the LicenseRef umbrella without oversight.

We have precedent for (3) in our Public Domain and UltraPermissive
handling.

In both cases, we have the text file in fedora-license-data collecting
records of which package contains which license text. Thus if we chose
(3) now, we have the information record to let us fairly easily switch
to (2) if we change our minds.

IOW unless there are substantive legal differences between the various
"redistributable, no modification permitted" texts, that we need to
convey to consumers of Fedora, option (3) would be a sufficient starting
point.

Or possibly we end up with a mixture of (2) and (3) where most firmware
are under an umbrella but a few oddballs with unusual terms justify a
dedicated LicenseRef.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Getting package NEVR list from core dump ?

[Daniel P . Berrangé]

On Fri, Oct 13, 2023 at 03:10:45PM +0200, František Šumšal wrote:
> Hey
> 
> On 10/13/23 09:41, Daniel P. Berrangé wrote:
> > Not too long ago Fedora added a new ELF note with the NEVR information for
> > a package, to all shared libraries
> > 
> >https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
> > 
> > For cores dumped by processes on my local system, coredumpctl extracts the
> > package info which is great.
> 
> Along with the ELF notes, systemd-analyze gained a new verb - inspect-elf - 
> that can be used to retrieve them:

Excellent, that is perfect, thank you

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Getting package NEVR list from core dump ?

[Daniel P . Berrangé]

Not too long ago Fedora added a new ELF note with the NEVR information for
a package, to all shared libraries

  https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects

For cores dumped by processes on my local system, coredumpctl extracts the
package info which is great.

Lets say, however, that I receive a coredump from an end user, and thus it
isn't known to coredumpctl.

What's the "right" way to extract the NEVR list from a standalone core
dump ?

Presumably there's a better way than just running 'strings' over the binary...

$ strings core | grep osCpe:

{"type":"rpm","name":"qemu","version":"7.2.6-1.fc38","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:38"}

{"type":"rpm","name":"librsvg2","version":"2.56.3-1.fc38","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:38"}

{"type":"rpm","name":"libogg","version":"1.3.5-5.fc38","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:38"}
..snip...

{"type":"rpm","name":"pixman","version":"0.42.2-1.fc38","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:38"}

{"type":"rpm","name":"libXau","version":"1.0.11-2.fc38","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:38"}

{"type":"rpm","name":"qemu","version":"7.2.6-1.fc38","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:38"}


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: An update on RHEL moving to issues.redhat.com

[Daniel P . Berrangé]

On Mon, Sep 18, 2023 at 09:57:28AM +0200, Petr Pisar wrote:
> V Fri, Sep 15, 2023 at 01:27:23PM -0400, Colin Walters napsal(a):
> > To state the blindingly obvious thing, RHEL made a decision to centralize on
> > Gitlab.  Having Fedora be on pagure creates IMO unnecessary friction for me.
> > I would be quite curious to get some sort of survey of other engineers for
> > how they feel.
> 
> My selfishly preferable option is not to use Gitlab.com for Fedora exactly
> because RHEL uses Gitlab.com. The reason is very practical: You need separate
> accounts for the two projects and GitLab.com is not good at using multiple
> accounts simulatenously. Having different systems makes to problem go away and
> my life easier.

You don't require separate accounts. It is a choice developers can
make to keep their upstream vs RHEL work in gitlab.com separated,
or under the same account. There are pros & cons, so it is really
a matter of personal preference.

With regards,
Daniel
___
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: Automate your Fedora package maintenance using Packit

[Daniel P . Berrangé]

On Fri, Sep 15, 2023 at 04:02:04PM +0200, Frantisek Lachman wrote:
> Thanks Dan and Daniel for the responses. You both are right. For our
> defence, this is always setup by an existing Fedora user (=human).
> 
> I can't speak of rel-eng (and honestly don't know) how problematic
> this "physical removal" on request is.
> We can at least promote the licence check more
> and provide instructions on what to do if something does not fulfil the rules.
> (E.g. as a part of the issue Ankur created and mentioned
> (https://github.com/packit/packit/issues/2035))
> 
> Does anyone have any realistic solution (or an improvement) to this
> for Packit itself?
> 
> We can also stop uploading the source to the lookaside cache (or make
> it configurable),
> but the benefit of such automation is significantly reduced.

I think it isn't too hard to make it acceptable, just stick a
flag in the middle of your process that human has to acknowledge
eg:

  1. Release monitoring files the new BZ ticket (it already includes
 wording warning the maintainer to review the new release for
 licensing changes).

 This BZ would have a flag set  'license-review=?' initially

  2. Maintainer reviews the new tarball to check the license
 situation is all still golden.

 If OK, maintainer toggles flag to license-review=+,
 else toggles to license-review=-

  3. Packit sees the flag approval and its magic happens to
 upload tarball and file pull request, etc


If you wanted to be especially helpful, perhaps Packit could compare
the old and new tarballs, and present the maintainer a list of newly
added files as a BZ attachment. It could also run 'licensecheck -r'
on old and new tarballs and report any notable changes. Still needs
human review, but that might help nudge the maintainer to actually
do the license review, as I bet it is often skipped on rebases.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Daniel P . Berrangé]

On Fri, Sep 15, 2023 at 03:13:58PM +0200, Frantisek Lachman wrote:
> Hi Petr,
> 
> we would like to avoid storing the archive in the lookaside cache before
> approving but the problem is that the CI on the PR (mainly the scratch
> build) does not work without the archive being in the lookaside cache
> already. Once this becomes possible, we (=Packit) would be happy to do this
> only when approved.

IIUC strictly speaking content must be validated for license compliance
before it is present on any Fedora infrastructure. IOW, doing scratch
builds in either Koji or Copr is also predicated on having permissible
content under an approved license, just as lookaside cache uploads are.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: KDE and GNOME Join Hands To Add Payments To Turn Flathub Into a Store for the Linux Desktop

[Daniel P . Berrangé]

On Wed, Aug 30, 2023 at 10:18:50PM -, Ryan Bach via devel wrote:
> It would be nice for Redhat to monetize the Desktop. What do you guys think?

IMHO talking about Red Hat needing to monetize the desktop is missing
the point of this. There are 1000's of OSS projects that will never be
interesting to big the Linux vendors like Red Hat, SUSE, etc, and yet
the people working on those projects still have bills to pay.

The proposals wrt donations / payments in Flathub would support the
long tail of OSS projects, by providing another place to potentially
collect some funds directly from users, without having a commercial
Linux vendor in the middle picking & choosing who to give funding to
while skimming off the top of the funds.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: KDE and GNOME Join Hands To Add Payments To Turn Flathub Into a Store for the Linux Desktop

[Daniel P . Berrangé]

On Fri, Sep 01, 2023 at 08:35:54AM -0400, JT wrote:
> That looks like it's just a proposal by some random people that KDE and
> GNOME should to work together.  I've not seen a statement by either
> desktop. the file referenced is literally under a directory called
> "proposals". and I've never heard of this "Plaintext Group" before.
> It does not look like KDE and GNOME have agreed to anything.

The "Plaintext Group" looks to be an org that sponsors efforts
to improve the sustainability of OSS. The "proposals" directory
is a place where interested projects can make their bid for
sponsorship.

IOW, the Flathub project made such a bid hence the linked file
that is is shown, but it appears they were not ultimately
successful according to their own status summary in 2023:

  https://discourse.flathub.org/t/flathub-in-2023/3808

You can see there though, that Flathub already has developed
the facility for one-off donations and/or purchases though
does not appear to have actually launched it, and are also
interested in supporting subscriptions too, both with the goal
to help projects/developers sustain their work.

GNOME has been involved in sponsorintg flathub development
as the project was incubated under the GNOME foundation, but
IIUC it is intended to split off into its own legal entity
and attract a diverse sponsorship base. Endless Network gave
a sizeable one off grant this year per that link above.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: zlib-ng as a compat replacement for zlib

[Daniel P . Berrangé]

On Fri, Sep 01, 2023 at 11:03:54AM +0100, Richard W.M. Jones wrote:
> On Fri, Sep 01, 2023 at 10:55:50AM +0100, Daniel P. Berrangé wrote:
> > On Fri, Sep 01, 2023 at 10:42:16AM +0100, Richard W.M. Jones wrote:
> > > On Fri, Sep 01, 2023 at 10:48:14AM +0200, Kevin Wolf wrote:
> > > > Am 31.08.2023 um 11:20 hat Richard W.M. Jones geschrieben:
> > > > > On Thu, Aug 31, 2023 at 11:05:55AM +0200, Kevin Wolf wrote:
> > > > > > [ Cc: qemu-block ]
> > > > > > 
> > > > > > Am 30.08.2023 um 20:26 hat Richard W.M. Jones geschrieben:
> > > > > > > On Tue, Aug 29, 2023 at 05:49:24PM -, Daniel Alley wrote:
> > > > > > > > > The background to this is I've spent far too long trying to 
> > > > > > > > > optimize
> > > > > > > > > the conversion of qcow2 files to raw files.  Most existing 
> > > > > > > > > qcow2 files
> > > > > > > > > that you can find online are zlib compressed, including the 
> > > > > > > > > qcow2
> > > > > > > > > images provided by Fedora.  Each cluster in the file is 
> > > > > > > > > separately
> > > > > > > > > compressed as a zlib stream, and qemu uses zlib library 
> > > > > > > > > functions to
> > > > > > > > > decompress them.  When downloading and decompressing these 
> > > > > > > > > files, I
> > > > > > > > > measured 40%+ of the total CPU time is doing zlib 
> > > > > > > > > decompression.
> > > > > > > > > 
> > > > > > > > > [You don't need to tell me how great Zstd is, qcow2 supports 
> > > > > > > > > this for
> > > > > > > > > compression also, but it is not widely used by existing 
> > > > > > > > > content.]
> > > > > > 
> > > > > > You make it sound like compressing each cluster individually has a 
> > > > > > big
> > > > > > impact. If so, does increasing the cluster size make a difference, 
> > > > > > too?
> > > > > > That could be an change with less compatibility concerns.
> > > > > 
> > > > > The issue we're discussing in the original thread is speed of
> > > > > decompression.  We noted that using zlib-ng (a not-quite drop-in
> > > > > replacement for zlib) improves decompression speed by 40% or more.
> > > > > 
> > > > > Original thread:
> > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CDNPJ4SOTRQMYVCDI3ZSY4SP4FYESCWD/
> > > > > zlib-ng proposed change:
> > > > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/3
> > > > > 
> > > > > Size of the compressed file is also a concern, but wasn't discussed.
> > > > 
> > > > I understand the context and didn't really think about file size at all.
> > > > 
> > > > My question was essentially if decompressing many small blocks (as we do
> > > > today) performs significantly different from decompressing fewer larger
> > > > blocks (as we would do with a larger cluster size).
> > > 
> > > I did a quick test just by adjusting the cluster size of a qcow2 file:
> > > 
> > >   $ virt-builder fedora-36
> > >   $ ls -lsh fedora-36.img 
> > >   1.2G -rw-r--r--. 1 rjones rjones 6.0G Sep  1 09:53 fedora-36.img
> > >   $ cat fedora-36.img fedora-36.img fedora-36.img fedora-36.img  > 
> > > test.raw
> > >   $ ls -lsh test.raw 
> > >   4.7G -rw-r--r--. 1 rjones rjones 24G Sep  1 09:53 test.raw
> > >   $ qemu-img convert -f raw test.raw -O qcow2 test.qcow2.zlib.4k -c -o 
> > > compression_type=zlib,cluster_size=4096
> > > 
> > > (for cluster sizes 4k, 64k, 512k, 2048k, and
> > > compression types zlib & zstd)
> > > 
> > > I tested the speed of decompression using:
> > > 
> > >   $ hyperfine 'qemu-img convert -W -m 16 -f qcow2 test.qcow2.XXX -O raw 
> > > test.out'
> > >   (qemu 8.0.0-4.fc39.x86_64)
> > > 
> > >   $ hyperfine 'nbdkit -U - --filter=qcow2dec file test.qcow2.XXX --run 
> > > '\''nbdcopy --request-size "$uri" test.out'\'' '
> > >   (nbdkit-1.35.11-2.fc40.x86_64)
> > > 
&

Re: zlib-ng as a compat replacement for zlib

[Daniel P . Berrangé]

On Fri, Sep 01, 2023 at 10:42:16AM +0100, Richard W.M. Jones wrote:
> On Fri, Sep 01, 2023 at 10:48:14AM +0200, Kevin Wolf wrote:
> > Am 31.08.2023 um 11:20 hat Richard W.M. Jones geschrieben:
> > > On Thu, Aug 31, 2023 at 11:05:55AM +0200, Kevin Wolf wrote:
> > > > [ Cc: qemu-block ]
> > > > 
> > > > Am 30.08.2023 um 20:26 hat Richard W.M. Jones geschrieben:
> > > > > On Tue, Aug 29, 2023 at 05:49:24PM -, Daniel Alley wrote:
> > > > > > > The background to this is I've spent far too long trying to 
> > > > > > > optimize
> > > > > > > the conversion of qcow2 files to raw files.  Most existing qcow2 
> > > > > > > files
> > > > > > > that you can find online are zlib compressed, including the qcow2
> > > > > > > images provided by Fedora.  Each cluster in the file is separately
> > > > > > > compressed as a zlib stream, and qemu uses zlib library functions 
> > > > > > > to
> > > > > > > decompress them.  When downloading and decompressing these files, 
> > > > > > > I
> > > > > > > measured 40%+ of the total CPU time is doing zlib decompression.
> > > > > > > 
> > > > > > > [You don't need to tell me how great Zstd is, qcow2 supports this 
> > > > > > > for
> > > > > > > compression also, but it is not widely used by existing content.]
> > > > 
> > > > You make it sound like compressing each cluster individually has a big
> > > > impact. If so, does increasing the cluster size make a difference, too?
> > > > That could be an change with less compatibility concerns.
> > > 
> > > The issue we're discussing in the original thread is speed of
> > > decompression.  We noted that using zlib-ng (a not-quite drop-in
> > > replacement for zlib) improves decompression speed by 40% or more.
> > > 
> > > Original thread:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CDNPJ4SOTRQMYVCDI3ZSY4SP4FYESCWD/
> > > zlib-ng proposed change:
> > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/3
> > > 
> > > Size of the compressed file is also a concern, but wasn't discussed.
> > 
> > I understand the context and didn't really think about file size at all.
> > 
> > My question was essentially if decompressing many small blocks (as we do
> > today) performs significantly different from decompressing fewer larger
> > blocks (as we would do with a larger cluster size).
> 
> I did a quick test just by adjusting the cluster size of a qcow2 file:
> 
>   $ virt-builder fedora-36
>   $ ls -lsh fedora-36.img 
>   1.2G -rw-r--r--. 1 rjones rjones 6.0G Sep  1 09:53 fedora-36.img
>   $ cat fedora-36.img fedora-36.img fedora-36.img fedora-36.img  > test.raw
>   $ ls -lsh test.raw 
>   4.7G -rw-r--r--. 1 rjones rjones 24G Sep  1 09:53 test.raw
>   $ qemu-img convert -f raw test.raw -O qcow2 test.qcow2.zlib.4k -c -o 
> compression_type=zlib,cluster_size=4096
> 
> (for cluster sizes 4k, 64k, 512k, 2048k, and
> compression types zlib & zstd)
> 
> I tested the speed of decompression using:
> 
>   $ hyperfine 'qemu-img convert -W -m 16 -f qcow2 test.qcow2.XXX -O raw 
> test.out'
>   (qemu 8.0.0-4.fc39.x86_64)
> 
>   $ hyperfine 'nbdkit -U - --filter=qcow2dec file test.qcow2.XXX --run 
> '\''nbdcopy --request-size "$uri" test.out'\'' '
>   (nbdkit-1.35.11-2.fc40.x86_64)
> 
> Results:
> 
>   Cluster  Compression  Compressed size  Prog   Decompression speed
> 
>   4k   zlib 3228811264   qemu   5.921 s ±  0.074 s
>   4k   zstd 3258097664   qemu   5.189 s ±  0.158 s
> 
>   4k   zlib/zstd nbdkit failed, bug!!
> 
>   64k  zlib 3164667904   qemu   3.579 s ±  0.094 s
>   64k  zstd 3132686336   qemu   1.770 s ±  0.060 s
> 
>   64k  zlib 3164667904   nbdkit 1.254 s ±  0.065 s
>   64k  zstd 3132686336   nbdkit 1.315 s ±  0.037 s
> 
>   512k zlib 3158744576   qemu   4.008 s ±  0.058 s
>   512k zstd 3032697344   qemu   1.503 s ±  0.072 s
> 
>   512k zlib 3158744576   nbdkit 1.702 s ±  0.026 s
>   512k zstd 3032697344   nbdkit 1.593 s ±  0.039 s
> 
>   2048kzlib 3197569024   qemu   4.327 s ±  0.051 s
>   2048kzstd 2995143168   qemu   1.465 s ±  0.085 s
> 
>   2048kzlib 3197569024   nbdkit 3.660 s ±  0.011 s
>   2048kzstd 2995143168   nbdkit 3.368 s ±  0.057 s
> 
> No great surprises - very small cluster size is inefficient, but
> scaling up the cluster size gain performance, and zstd performs better
> than zlib once the cluster size is sufficiently large.

The default qcow2 cluster size is 64k, which means we've already
got the vast majority of the perfornmance and file size win. Going
beyond 64k defaults doesn't seem massively compelling.

zstd does have a small space win over zlib as expected, but again
nothing so drastic that it seems compelling to change - that win
will be line noise in the overall bigger picture of image storage
and download times.

The 

Re: Why does mingw-filesystem depend on mingw-binutils-generic?

[Daniel P . Berrangé]

On Wed, Aug 30, 2023 at 10:39:44AM +0100, Richard W.M. Jones wrote:
> On Wed, Aug 30, 2023 at 10:36:26AM +0200, Sandro Mani wrote:
> > Hi
> > 
> > I'd say, as least as it stands now, this is because the dependency
> > generators require mingw-objdump, see mingw.req [1].
> > 
> > Sandro
> > 
> > [1] 
> > https://src.fedoraproject.org/rpms/mingw-filesystem/blob/rawhide/f/mingw.req
> 
> I see, good point.
> 
> There's a concern in this bug:
> 
> > >https://src.fedoraproject.org/rpms/virt-v2v/pull-request/2
> 
> that pulling in mingw-srvany pulls in too many dependencies.  We only
> need this binary because it gets copied into Windows virtual machines
> during various virt-v2v and virt-customize operations (it is used to
> run some "firstboot"-type services in Windows).
> 
> The dependency chain is:
> 
> virt-v2v -> mingw32-srvany -> mingw32-crt
>|
>   \v
>-> mingw32-filesystem -> mingw-binutils-generic
> 
> Both dependencies of mingw32-srvany are justified -- the program is a
> Windows binary that gets installed in the mingw "filesystem", and it
> needs various C runtime dependencies if you want to run it under Wine.
> But indirectly pulling in programs like mingw-objdump and mingw-strip
> seems less justified.

Thinking about the intended usage of mingw ecosystem in Fedora context,
the mingw RPMs are really considered to be devel input to enable end
user applications to be built. Such applications would typically be
bundled up into a NSIS/WXI installer binary, which end users will then
run in order to install the app on their Windows host/VM.

IOW, the mingw RPMs aren't particularly targetted at end users, more
developers. 

When creating the application installer, the fact that mingw-filesystme
contains a dep on objdump/etc is essentially harmless. Your NSIS/WXI
recipe specifies exactly what files are to be included into the installer
binary, and ought to omit objdump/etc

> What do you think about adding {ucrt64,mingw32,mingw64}-srpm-macros to
> contain the rpmbuild macros and the dependency on mingw-binutils-generic?

That would be in keeping with the general Fedora approach for SRPM macros
these days, so despite what I said above, it might none the less be a
good idea. Still it will require updating every single mingw package to
add the new dep :-(

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Request to review a MinGW subpackges in libsodium

[Daniel P . Berrangé]

On Mon, Aug 21, 2023 at 03:17:21PM +0200, Marián Konček wrote:
> I opened a PR adding mingw subpackages to libsodium according to my best
> knowledge (which is not too large related to mingw packaging):
> https://src.fedoraproject.org/rpms/libsodium/pull-request/3
> 
> I talked with the maintainer and it could be accepted, but I would like
> someone more experienced from https://fedoraproject.org/wiki/MinGW to take a
> look and tell me if i missed some simplifications.

The main item I see missing is conditionalization of the sub-packages,
which is important for anyone wanting to rebuild the same spec on
RHEL/EPEL where most of mingw is not present.

https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_disabling_mingw_packages

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Removal of Modular repos broke upgrades to Fedora 39: What now?

[Daniel P . Berrangé]

On Fri, Aug 04, 2023 at 12:25:34PM +0100, Adam Williamson wrote:
> On Fri, 2023-08-04 at 12:16 +0100, Daniel P. Berrangé wrote:
> > > 
> > > It looks like the public 'rawhide' location *does* still have a Modular
> > > tree:
> > > 
> > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/
> > > 
> > > but there's still a problem there, because...it's now just stale data.
> > > That is the Modular tree from the 20230802.n.0 compose, and unless
> > > someone does something about it, it always *will* be. Keeping the last
> > > set of modular repos frozen in amber forever doesn't seem like the best
> > > permanent situation :)
> > 
> > Do we still have the problem where dnf will preferrentially pick
> > content from a modular repo, even if it has older NEVR than the
> > same package name in a non-modular repo ?
> > 
> > IOW, would the existance of this stale modular content, prevent
> > the upgrade tools from correctly bringing in content from the
> > new release ?
> 
> Well, I think only if you have a module explicitly enabled. We dropped
> the whole "ooh, if this is in a module, pull it in and enable the
> module!" thing aaages ago, it only lasted like one release I think.
> IIRC, anyway.

Ok, so for most people it should be fairly harmless having the stale
content in the modular repo. During upgrade dnf will look at the repo
and ignore all the outdated RPMs. Them presumably something will have
an "Obsoletes: fedora-modular-repos" so the repo config files all
get erased during the upgrade, and thus the modular content will never
be consulted thereafter.

IOW, just leavnig the stale repo there forever wouldn't look
to be terrible, though from a conceptual POV it would be
nicer to just have an empty repo at the URL instead.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Removal of Modular repos broke upgrades to Fedora 39: What now?

[Daniel P . Berrangé]

On Fri, Aug 04, 2023 at 11:42:07AM +0100, Adam Williamson wrote:
> On Fri, 2023-08-04 at 12:16 +0200, Miro Hrončok wrote:
> > Hello folks,
> > 
> > With the retirement of modularity, the modular dnf repositories for Fedora 
> > 39 
> > no longer exist. However, this will introduce a problem during upgrades. 
> > When 
> > users try to upgrade from previous Fedora releases with 
> > fedora-repos-modular 
> > installed, they will hit fatal errors that will probably look like this:
> > 
> > Errors during downloading metadata for repository 'fedora-modular':
> >- Status code: 404 for 
> > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64
> >  
> > (IP: ...)
> >- Status code: 404 for 
> > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64
> >  
> > (IP: ...)
> >- Status code: 404 for 
> > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64
> >  
> > (IP: ...)
> > Error: Failed to download metadata for repo 'fedora-modular': Cannot 
> > prepare 
> > internal mirrorlist: Status code: 404 for 
> > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64
> >  
> > (IP: ...)
> > 
> > Or:
> > 
> > Error: Failed to download metadata for repository 'fedora-modular': Cannot 
> > download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were 
> > tried
> > 
> > (The actual error might differ depending on the exact state of the removal 
> > of 
> > the modular repos and their mirrorlist etc.)
> > 
> > 
> > This is caused by the combination of the following facts:
> > 
> >   - the modular repo configuration in Fedora 37/38 has 
> > skip_if_unavailable=False
> >   - when the releasever is set to 39, the URLs of the repos give error 404
> > 
> > This is a big deal, because even users who don't use modularity at all (but 
> > have not uninstalled fedora-repos-modular) will not be able to upgrade to 
> > Fedora 39+ without reaching for help.
> > 
> > Adam outlined 3 options to solve this problem in the bugzilla where he 
> > reported 
> > this: https://bugzilla.redhat.com/2228827
> 
> So an update to this, thanks to Miro for double-checking me: I had
> forgotten that the openQA tests edit the dnf config to point to the
> compose tree (in order to make sure we're testing the right thing -
> there's an ordering problem if we just test the actual 'rawhide'
> location on the mirror system, it might not have been synced by the
> time the tests run).
> 
> It looks like the public 'rawhide' location *does* still have a Modular
> tree:
> 
> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/
> 
> but there's still a problem there, because...it's now just stale data.
> That is the Modular tree from the 20230802.n.0 compose, and unless
> someone does something about it, it always *will* be. Keeping the last
> set of modular repos frozen in amber forever doesn't seem like the best
> permanent situation :)

Do we still have the problem where dnf will preferrentially pick
content from a modular repo, even if it has older NEVR than the
same package name in a non-modular repo ?

IOW, would the existance of this stale modular content, prevent
the upgrade tools from correctly bringing in content from the
new release ?


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

dlmalloc CC0 license (was Re: Packaging a cross-compilation environment (wasi-libc))

[Daniel P . Berrangé]

Bringing a year old thread back from the dead...

On Mon, Aug 29, 2022 at 06:54:35AM -0700, Jan Staněk wrote:
> Florian Weimer  writes:
> > You can try to replace the current version with dlmalloc 2.7.2, which
> > still comes with the previous public domain dedication:
> >
> >   

IIUC, it is not required to go all the way back to 2.7.2. The
version 2.8.3 has the older creative commons public domain
dedication - https://spdx.org/licenses/CC-PDDC.html which
is permitted in Fedora.

> > We can also ask Doug Lea if he can go back to the previous public domain
> > dedication.
> 
> I've got some comments on the wasi-libc issue that another malloc might
> work as well. Nevertheless, I'll try to contact Doug Lea with the
> explanation and see where that leads.

I'm reviewing another package (sgxsdk) which also includes a copy
of dlmalloc with the CC0 license declaration. I wondered if you
ever made contact with Doug Lea around this question ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)

[Daniel P . Berrangé]

On Wed, Jul 26, 2023 at 09:59:26AM +0200, Vitaly Zaitsev via devel wrote:
> On 26/07/2023 08:48, Dominik 'Rathann' Mierzejewski wrote:
> > Define small. 
> 
> Only Dell, HP and Lenovo laptops are fully supported:
> https://fwupd.org/lvfs/devices/
> 
> fwupd is a great tool on laptops but completely useless on desktops since no
> motherboard vendors support it.

Merely enabling the fwupd to check for available updates has negligible
downside for machines which can't be updated. It'll merely find no updates
available, so the cost is an extra service running periodically and its
network download data usage.

Those devices which do support fwupd have a large enough market share
that it is justifiable to enable it, even if there are many machines
which can't support it.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

License correction for vhostmd: LGPL-2.1-or-later

[Daniel P . Berrangé]

The vhostmd package was mistakenly tagged as GPLv2+, and has 
been corrected to LGPL-2.1-or-later during the SPDX conversion.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Daniel P . Berrangé]

On Mon, Jul 24, 2023 at 11:45:26AM -0400, Solomon Peachy via devel wrote:
> On Mon, Jul 24, 2023 at 04:00:21PM +0100, Daniel P. Berrangé wrote:
> > If I have a USB flash stick I plug in every day, it shouldn't ask me
> > about that after the first time I use it.
> 
> Based on this "threat model" all an attacker has to do then is 
> snag/modify/replace your existing drive and then they can pwn your 
> system.  That's probably much easier to accomplish than getting you to 
> insert a previously-unseen device (the latter has a lot of awareness 
> around it, but the "of course I trust this one, it's mine!" will get you 
> pwned.)

While in-person attackers are real, IMHO that are not the big risk
factor for the general populace. I wasn't claiming this was a perfect
solution, just that it addresses some easy low hanging fruit, where
you have no clue what will be on a new drive you receive (whether
purchased online, or as a swag at a trade show, etc). 

> (Besides, how are you to distinguish the exact stick?  Most of the stuff 
> I have lying around here reports the same generic vendor/product/serial 
> number.  And drive/volume labels are notoriously unreliable.)

Yes there are some lame vendors, that don't burn unique serials,
which will make it imperfect. IMHO it is still credible to use
the vendor/product/serial despite that.



> > If I acquire a new USB flash stick I've never plugged in before, I
> > don't want it auto-mounting before I can wipe & reformat it.
> 
> Honestly, what makes more sense to me is treat this whole thing purely 
> as a usability problem.  Upon insertion, prompt the user to "mount, 
> mount reat-only, check, ignore", because at least then we'd get an 
> really easy method of fscking a disk without having to do the whole 
> unmount dance.  It also provides a mechanism to supply user feedback (eg 
> showing fsck results, or the XFS case where you _have_ to mount the 
> filesystem to replay the journal before an fsck can be safely run)

If you prompt a user every single time, all that results is
training the user to press 'yes' without looking. To be useful
the prompts need to only happen in unusual circumstances, that
are infrequent enough to avoid training an instinctive response.

> Again, let's be realistic about the threat models here -- the 
> overwhelmingly common situations are accidental corruption due to 
> improper shutdown/ejection, and malicious files on a well-formed 
> filesystem (eg ransomware or something that's banking on users having we 
> passwordless sudo in place, or curl https://url/setup.sh | sudo bash)

Accidental corruption is indeed important, and wouldn't be solved
by prompting. Protecting against that I think requires taking the
libguestfs approach of mounting in an isolated guest OS kernel.

In terms of malicious files, I think that not trusting newly seen
devices is a valid strategy. There's plenty of documented cases
where new  devices had malware pre-installed. Re-formatting newly
seen devices means the user only needs worry about their own usage
from that point onwards, bringing in malware.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Daniel P . Berrangé]

On Mon, Jul 24, 2023 at 10:08:50AM -0400, Demi Marie Obenour wrote:
> On 7/24/23 08:47, Richard W.M. Jones wrote:
> > On Sun, Jul 23, 2023 at 11:18:45PM -0400, Demi Marie Obenour wrote:
> >> On 7/23/23 12:10, Solomon Peachy via devel wrote:
> >>> On Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal Gompa wrote:
> > If the system administrator wants to mount $UNCOMMONFS, they should be
> > able to do so without hassle, but that doesn't mean that a normal user
> > who got handed a sketchy USB stick at a conference should be able to do
> > so with no restrictions at all.
> >
> 
>  So then some kind of configuration to udisks2 to have a similar effect?
> >>>
> >>> And we're right back at square one, with the *overwhelmingly* common case 
> >>> of a single-user system whose "admin" is sitting in front of the system.
> >>>
> >>> Of _course_ they want to mount the disk.  It's why they plugged it in, 
> >>> and they don't give two hoots if it's a "common filesystem" or not.
> >>>
> >>> (FFS, most of the stuff I personally plug in these days is ext4 or ntfs, 
> >>> because fat32 sucks and I can't rely on exfat on all systems I need to 
> >>> interoperate with)
> >>>
> >>> And let's be realistic here -- the overwhelmingly common threat model 
> >>> here is that there are untrusted files on a correctly-formed filesystem.  
> >>> Bad guys rarely need or care to get root on the system; what they're 
> >>> after requires normal, non-elevated user permissions.
> >>>
> >>> Prompting users 'are you sure you want to use this device' will turn a 
> >>> "yes" into an automatic reflex.  Not automounting by default will just 
> >>> add another thing to the "things to change on default fedora 
> >>> installations" lists out there (ie right after the "enable freshrpms and 
> >>> install modern video codecs" step), becuase it's a usability nightmare.
> >>>
> >>> In the "usability vs security" tradeoff, usability/convenience *always* 
> >>> wins unless you're at a place that has armed guards at the door with 
> >>> instructions to shoot first.
> >>>
> >>>  - Solomon
> >>
> >> Then the mount needs to be done in a sandbox, such as a KVM guest or
> >> sandboxed userspace process.
> > 
> > This is what libguestfs does (KVM guest).
> > 
> > Rich.
> 
> I saw that libguestfs has a guestmount(1) tool, and I think this could be
> a potential solution.  An exploit against the kernel FS driver would only
> grant access to a KVM guest, and the QEMU process can be tightly sandboxed
> by means such as seccomp and SELinux.
> 
> I still believe that mounting should _not_ be automatic, though, because
> it could have side-effects (such as replaying the FS journal) that might
> not be wanted.  To prevent prompt fatigue, Fedora could offer to remember
> the user’s choice.

Remember the choice per device.

If I have a USB flash stick I plug in every day, it shouldn't ask me
about that after the first time I use it.

If I acquire a new USB flash stick I've never plugged in before, I
don't want it auto-mounting before I can wipe & reformat it.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[Daniel P . Berrangé]

On Sat, May 20, 2023 at 06:14:17PM -0500, Justin Forbes wrote:
> On Sat, May 20, 2023 at 3:44 PM Demi Marie Obenour
>  wrote:
> >
> > I noticed that by default, Qubes OS has voluntary kernel preemption
> > as opposed to full preemption.  I found that enabling full preemption
> > (preempt=full on kernel command line) makes the system significantly
> > more responsive under heavy I/O load.  In particular, if I build a
> > kernel in a Qubes OS VM, it significantly degrades responsiveness
> > without preempt=full.  With preempt=full, the system remains
> > responsive.  The storage stack used is LVM thin provisioning on LUKS,
> > and I have observed significant CPU usage in dom0 kernel threads with
> > names that indicate they are related to dm-thin and dm-crypt.
> >
> For workstation, preempt=full does likely make sense, and I have been
> running it for a while.  For server, maybe not so much. That is the
> joy of dynamic preempt. You can boot with preempt=full and run that
> way if you like.  There is an open issue for the workstation WG to
> look at making preempt=full the default there at some point.

What's the downside from full pre-empt that makes it inappropriate
as the defualt for Fedora server spins too ? Is it that it is
trading off overall peak performance in favour of reduced latency,
and we think servers would prefer the peak performance in general ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Possible to combine ExclusiveArch?

[Daniel P . Berrangé]

On Sat, Jul 15, 2023 at 05:11:02PM +0200, Nils Philippsen wrote:
> On Fri, 2023-07-14 at 13:30 +0100, Richard W.M. Jones wrote:
> > For some virt packages we need to combine 2 or 3 of:
> > 
> >   ExclusiveArch: %{kernel_arches}
> >   ExclusiveArch: %{qemu_sysemu_host_arches}   # [1]
> >   ExclusiveArch: %{ocaml_native_compiler}
> > 
> > to mean only compile on the intersection of these arches.  If you
> > have
> > multiple ExclusiveArch lines then RPM seems to do the union of arches
> > which is the opposite of what anyone would want.
> 
> I beg to differ. When a tag in RPM can have multiple items (e.g.
> Provides, (Build)Requires), this …:
> 
> Tag: item1 item2 item3
> 
> … is consistently equivalent to this:
> 
> Tag: item1
> Tag: item2
> Tag: item3
> 
> To have ExclusiveArch behave differently would be surprising – nobody
> () would read this and expect the effective list of arches the
> package would be built for to be empty:
> 
> ExclusiveArch: x86_64
> ExclusiveArch: s390x
> ExclusiveArch: aarch64
> 
> > Dan Berrange came up with a clever way to do it though ...
> > 
> >   %ifnarch %{kernel_arches}
> >   ExcludeArch: %{_arch}
> >   %endif
> >   %ifnarch %{qemu_sysemu_host_arches}
> >   ExcludeArch: %{_arch}
> >   %endif
> > 
> > But this makes my head hurt.  Is there a better way or could RPM
> > provide explicit union and intersection operators?
> 
> I think this would be a good approach.

It is certainly easier to read and understand than using a LUA script
to get to implement variable intersection for ExclusiveArch !

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: btrfs loses 32-bit application compatibility after a while

[Daniel P . Berrangé]

On Fri, Jul 14, 2023 at 11:47:39PM +0200, Fabio Valentini wrote:
> On Fri, Jul 14, 2023 at 10:45 PM Eric Sandeen  wrote:
> >
> > On 7/14/23 6:53 AM, Florian Weimer wrote:
> > > * Neal Gompa:
> > >
> > >> On Thu, Jul 13, 2023 at 8:29 AM Fabio Valentini  
> > >> wrote:
> > >>>
> > >>> On Thu, Jul 13, 2023 at 10:33 AM Florian Weimer  
> > >>> wrote:
> > 
> >  Fedora lists are hostile to upstream collaboration via cross-posting, 
> >  so
> >  I can only forward this for your information.
> > 
> >  This causes problems with the i686 builders.
> > >>>
> > >>> I wonder how this only started to happen recently? Has something
> > >>> changed in BTRFS with the 6.3 kernel?
> > >>> This only started happening a few days after builders were rebooted at
> > >>> the end of June to apply updates (and kernel 6.3 was among those
> > >>> updates, as far as I can tell).
> > >>>
> > >>
> > >> This was always possible. I'm curious as to why it took so long for us
> > >> to hit it, though.
> > >>
> > >> The recommended solution is to create a new subvolume for these
> > >> environments, since the inode count is reset for each subvolume.
> > >
> > > What about impact beyond the builders?
> > >
> > > Are end users are expected to do this?  Do we have a tool for this?
> >
> > FWIW, 64 bit inodes have existed in some Linux filesystems for a very
> > long time. On XFS, you'll get them by default - and quickly, not after
> > extended use - on a filesystem of sufficient size (around 1T-2T by
> > default, if I remember right.)
> >
> > XFS does have a hack^Wmount option to force inodes into the 32-bit
> > range, but just FWIW we almost never see users running into problems
> > with 32-bit applications (but maybe because they know about the mount
> > option...)
> 
> But that still raises the question - why does it look like this
> started to happen pretty suddenly around June 30?
> The list of updates that were applied to builders in that timeframe
> doesn't raise any alarm bells (except maybe the 6.3 kernel):
> (see https://pagure.io/releng/issue/11531#comment-864471)
> I read the release notes for the 6.3 kernel but didn't see any
> mentions of BTRFS changes that could explain this. :(

Or what 32-bit code is being run in the context of koji that is
NOT compiled with LFS ?  Is this something silly like configure
script tests not enabling LFS, but the resulting applications
correctly using LFS ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: btrfs loses 32-bit application compatibility after a while

[Daniel P . Berrangé]

On Fri, Jul 14, 2023 at 09:49:04AM -0400, Neal Gompa wrote:
> On Fri, Jul 14, 2023 at 8:48 AM Florian Weimer  wrote:
> >
> > * Miroslav Suchý:
> >
> > > Dne 14. 07. 23 v 13:53 Florian Weimer napsal(a):
> > >> What about impact beyond the builders?
> > >>
> > >> Are end users are expected to do this?  Do we have a tool for this?
> > >
> > > Close to zero. You have to do a really lots of builds. And keep the
> > > buildroots of these (failed) builds.
> >
> > This is not restricted to mock or Koji, though.  There just needs to be
> > one application that creates and deletes many files (or produces other
> > events that causes object ID allocation in btrfs).
> >
> > For me it's going to be slow enough that the file system will likely be
> > recreated before I encounter the 31-bit object ID limit.  But I wonder
> > if that's true for everyone.
> >
> 
> I don't know of a 32-bit workload that would trigger this reliably and
> reasonably quickly, but if there is one, then I would be interested in
> knowing about it.

The 32-bit binary is what suffers the consequences.

The workload that /causes/ the problem can be anything which creates
lots of files.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Daniel P . Berrangé]

On Fri, Jul 07, 2023 at 12:41:00PM +0200, Leon Fauster via devel wrote:
> Am 07.07.23 um 12:19 schrieb Richard W.M. Jones:
> > On Thu, Jul 06, 2023 at 05:10:24PM +0100, Aoife Moloney wrote:
> > > Important process note: we are experimenting with using Fedora
> > > Discussion as part of the Changes process. Change announcements (like
> > > the one you are reading right now) will still be sent to the
> > > devel-announce mailing list, but the conversation about each change
> > > will take place on Fedora Discussion at
> > > https://discussion.fedoraproject.org/t/f40-change-request-privacy-preserving-telemetry-for-fedora-workstation-system-wide/85320
> > 
> > Why?  This was discussed a while back and the number problems with
> > discourse were covered, and to my knowledge none of them have been
> > fixed.
> > 
> > > == Summary ==
> > > 
> > > The Red Hat Display Systems Team (which develops the desktop) proposes
> > > to enable limited data collection of anonymous Fedora Workstation
> > > usage metrics.
> > > 
> > > Fedora is an open source community project, and nobody is interested
> > > in violating user privacy. We do not want to collect data about
> > > individual users. We want to collect only aggregate usage metrics that
> > > are actually needed to achieve specific Fedora improvement objectives,
> > > and no more. We understand that if we violate our users' trust, then
> > > we won't have many users left, so if metrics collection is approved,
> > > we will need to be very careful to roll this out in a way that
> > > respects our users at all times. (For example, we should not collect
> > > users' search queries, because that would be creepy.)
> > 
> > This also keeps coming up and the answer is again, no!  There's no
> > such thing as anonymous data collection, people don't want it, it must
> > not be enabled by default (making it useless to you), it's probably
> > illegal in the Europe, so stop asking for it.
> 
> +1
> 
> General Data Protection Regulation in EU law.
> 
> "... consent can't be implied and must always be given through an opt-in
> ..."

Note the proposal at the top of the thread directly addresses this
opt-in vs opt-out Q wrt GDPR compliance:

[quote]
Fedora Legal has determined that if we collect any
personally-identifiable data, the entire metrics system must be
opt-in. Since we are only interested in opt-out metrics due to the low
value of opt-in metrics, we must accordingly never collect any
personally-identifiable data. We must also not collect any data that
could become personally-identifiable if combined with other data,
which notably means IP addresses must not be stored. We only want to
collect anonymous data anyway, but we need to be especially mindful of
the possibility that combining two "anonymous" data points could
result in the data no longer being anonymous.
[/quote]

IOW, the intention is to avoid triggering GDPR obligations by not
collecting (potentially) personally identifiable data.

The last sentance though hints at how tricky this can be to put into
practice in reality though.

Combining anonymous data sets can be surprisingly effective at producing
metrics that could uniquely identify users - it is the heart of online
advertizment targetting techniques after all.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_

[Daniel P . Berrangé]

On Mon, Jun 26, 2023 at 12:19:46PM +0200, Lennart Poettering wrote:
> On Do, 22.06.23 12:24, Jeremy Linton (jeremy.lin...@arm.com) wrote:
> 
> > But, IMHO the largest change is moving the boot kernel/initrd to the ESP,
> > rather than the use of systemd-boot itself. Given the filesystem layout
> > remains the same outside of those two items and the BLS entries, all the
> > common tools (dracut/etc) seem to be able to deal with it, and random other
> > packages not manipulating kernel/initrd images are behavior should not be
> > affected anymore than putting reFind/whatever in the boot path.
> 
> While putting kernle/initrd (UKIs) into the ESP is a good thing
> systemd-boot actually is fine with loading them from a separate boot
> partition to, i.e. the XBOOTLDR partition, which in many ways is
> similar to traditional /boot/, but must be marked via recognized
> XBOOTLDR partition type uuid. (also it must be a firmware recognizable
> fs, i.e. vfat)

NB, Fedora doesn't currently have a supported way to making /boot
be compliant with XBOOTLDR requirements, as anaconda blocks use of
vfat on /boot:

   https://bugzilla.redhat.com/show_bug.cgi?id=2106706

> Such an XBOOTLDR partition is supposed to be the escape hatch if the
> ESP is pre-existing and too small to contain multiple full sized
> UKIs. But you could also make it an escape hatch for simplifying
> transitions from the status quo ante.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fuse3 allows differing NVR subpackages to be installed

[Daniel P . Berrangé]

On Wed, Jun 21, 2023 at 10:58:28PM +0100, Richard W.M. Jones wrote:
> It's possible to create this situation:
> 
> fuse3-libs-3.13.1-1.fc38.x86_64
> fuse3-devel-3.13.1-1.fc38.x86_64
> fuse3-3.14.1-1.fc39.x86_64
> 
> fuse3-devel correctly requires the exact version of fuse3-libs.
> However there doesn't seem to be any similar requirement connecting
> fuse3 & fuse3-libs.

fuse3 will get the automatic elf dependancy, but that's merely
tied to the soname by default. If libfuse had symbol versioning
you would get much more fine grained dependencies that might
block it, but it doesnt use versioning.

> Is this a mistake or intentional for some reason?  I wasn't sure
> whether to just fix this or file a bug.

When a package has a binary that depends on a 3rd party library
I think its reasonable to just rely on the auto-generated deps
by default. You can assume the binary will be expecting to work
aganist a wide variety of versions of the 3rd party library and
has probably been tested as such to some extent.

When a package has a binary that depends on a library in its
own sub-pacakge, then I tend to think the full NEVR dep should
be present, as you can assume upstream will have probably never
done any testing of mismatched versions. Forcing an exact match
is the safe option to maximise reliablity.

So even if the fuse/fuse-libs mis-match is harmless today, I
would still suggest preventing it via an explicit dep.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_

[Daniel P . Berrangé]

On Thu, Jun 22, 2023 at 04:59:38PM +0100, Aoife Moloney wrote:
> https://fedoraproject.org/wiki/Changes/cleanup_systemd_install
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> Fedora default installs with a shim + grub bootloader on EFI
> platforms, yet has been shipping systemd-boot in various forms for a
> number of releases. There are a few howto's which describe how to
> replace grub with systemd-boot with varying levels of functionality.
> This should be easier with a formalized default method that can be
> built upon. This proposal aims to complete the work started with
> anaconda (inst.sdboot), kickstart (bootloader --sdboot) such that the
> "everything" media can install a grub free machine.

snip

> Beyond that there are various enhancements which can be made to remove
> the /boot partition (leaving the EFI at /boot/efi), enrolling fedora
> keys if the secure boot mode is "Setup", adding options to enable
> shim+systemd-boot, assuring that there is a systemd-boot-signed
> package, etc.

This is the $million question to - is there any proposal and/or agreement
by relevant maintainers, to start signing systemd-boot with Fedora SecureBoot
certs yet ? Without that, sdboot looks destined to remain a niche use case.

If that's part of this proposal, then it feels more like a system-wide
change, than self-contained.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What's the error in this build?

[Daniel P . Berrangé]

On Thu, Jun 22, 2023 at 09:07:34AM +0100, Richard W.M. Jones wrote:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=102443065
> 
> I don't see what the error is ...

Mock appears to have failed to install the builddeps, for unknown
reasons. I would just re-try the build in hope that it is a transient
infra problem ? If it isn't transient, I guess it'll require admin
attention ? Either way it doesn't look like a problem on your side.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What is Fedora?

[Daniel P . Berrangé]

On Wed, Jun 21, 2023 at 04:26:35PM -0400, Gerald Henriksen wrote:
> On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:
> 
> >Hi all,
> >
> >Obviously many will have seen:
> >
> >https://www.redhat.com/en/blog/furthering-evolution-centos-stream
> >
> >and see, where EL (contributors like you of fedora/EPEL) have been knocked 
> >down:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=2215299
> >
> >Let us face it our efforts with the Fedora project are not valued and it is 
> >a means nothing to the
> >new corporate IBM/Red Hat enterprise systems that we have to struggle to get 
> >access to srpms, to
> >make a community. What is community now to Red Hat?
> 
> My interpretation of the blog post, combined with recent actions
> towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as
> the new "Fedora" for basing future versions of RHEL.

IMHO this is a mis-reading of the above blog / general situation. The
flow of development for future versions of RHEL is absolutely still
originating in Fedora, where Rawhide feeds into ELN (Enterprise Linux
Next), which then becomes the next major RHEL release.

Fedora -> ELN -> RHEL-$NEXT

Nothing described in that blog post above changes this process, so
what's written there doesn't have any direct impact on Fedora. If you
look at rawhide / eln branches in Fedora dist-git today you can see
ongoing changes in many packages that will feed into RHEL-10. CentOS
Stream is *not* the new Fedora. Fedora remains critical to future RHEL.

CentOS Stream is the development path *within* a major RHEL release
eg

   CentOS Stream 9 --->
 |   ||
 V   VV
 RHEL-9.1.0   RHEL-9.2.0  RHEL-9.x.0
 |   ||
 |   ||
 V   VV

The main effect of the blog post I see is that the bug fixes / CVEs
that go into RHEL-9.1.z, 9.2.z, 9.x.z  streams are no longer going
to be freely available - only the initial content of each poinmt
release in available from CentOS Stream.

This doesn't impact Fedora, but will certainly impact the various
RHEL rebuilds whether community based (AlmaLinux, Rocky Linux),
or fully commercial (Oracle OEL). Those distros can still provide
the initial point releases, but will have to do all the work to
figure out backports for bug fixes/CVEs/etc within the release.
This is going to be a serious burden for those distros.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Daniel P . Berrangé]

On Sat, Jun 03, 2023 at 09:09:57AM +0200, Peter Boy wrote:
> > Am 03.06.2023 um 02:06 schrieb Sandro :
> > What will we ship in Fedora if we were to follow in Red Hat's
> > footsteps? LibreOffice Flatpak? That may prove to be the straw
> > that broke the camel's back. As I said before, I don't want to
> > to reiterate the Flatpak vs. RPM discussion. But maybe that
> > topic needs to be picked up and discussed, so we get a better
> > understanding of where this will leave us.
> 
> Instead of Flatpak I would prefer to pick up the software directly
> from the project.

The LibreOffice Flatpak *is* provided directly by the upstream
Document Foundation (LibreOffice) project.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Managing multiple cross-dependent patches

[Daniel P . Berrangé]

On Fri, Jun 02, 2023 at 04:27:37PM +0200, Dmitry Belyavskiy wrote:
> Dear colleagues,
> 
> I maintain OpenSSH that has a lot of heavy-interfering downstream
> patches. I’d like to reduce the burden of rebase by combining some of
> them.

Trying to reduce the burden by combining patches won't help IMHO, and
if anything make life worse, as any patch failing to apply will leave
a bigger conflict mess to resolve. I always favour a larger number of
small patches, over a small number of big patches.

> So I wonder if there is software checking for cross-dependencies
> between patches to see what are the natural candidates for combining?
>
> I’m aware of quilt and git-absorb but it looks like they don’t help me much.

Are you primarily using dist-git and managing the patches manually ?
It looks like it, since the paches I see in openssh.git aren't git
commit exports.

If so, I'd highly recommend switching to using a src-git model instead,
where you manage a Fedora branch of commits directly against the upstream
git repo. This lets you exploit the full power of git for rebasing and
cherry-picking patches and resolving conflicts. dist-git largely becomes
an export of patches from the src-git branch which is largely automatable.
I'm not saying src-git is a magic bullet, just that it is much less painful
that directly working on dist-git.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Daniel P . Berrangé]

On Wed, May 31, 2023 at 07:38:38PM +0200, Jiri Vanek wrote:
> > Can you clarify this a bit?  It sounds like some versions of the JDK in
> > Fedora will actually be built in EPEL.  I feel that all Fedora packages
> > should actually built for Fedora, not RHEL.
> >
> > Also, what exactly does "latest live EPEL" mean - how is 8 the latest?
> >
> > I guess basically, can you further explain/clarify exactly which
> > versions of what OS which JDKs will be built on, and when those versions
> > will change.
> 
> 
> Jdk is designed, to be severely forward comaptible from os where it was built.
> So jdk8, 11 and 17 would be build in oldest live fedora, and repacked
> everywhere. The idea is to build them on oldest viable system, as we
> can guarantee they will run ok in newer Fedroas..
> java-latest-openjdk however, is built also for epel8 and elep9. Thus
> logically the oldest system where we can built it to repack it everywhere
> is el8. Then it can be reapcked for el8,el9, and all live fedoras.

IIRC, RHEL-8 forked from Fedora in circa F28 timeframe. Directly
comparing RHEL-8 content to Fedora is a bit of a fools errand since
RHEL does rebase certain packages periodically, but a decent chunk
of RHEL-8 is 5 years old at this point. The most notable part is
the compiler toolchain on RHEL-8 is GCC 8.x, which is 5 major
releases behind what F39 rawhide uses, and 4 major release behind
what F37 uses.

RHEL-8 also has a long lifetime left, and thus so does EPEL8. By
building JDK on EPEL8, we're fixing the toolchain for JDK in Fedora
on a version already 5 years out of date, and by the time EPEL8 goes
away, the toolchain will be 10+ years out of date. 

By building JDK on the oldest stable Fedora release, we're fixing the
toolchain on a version that's never going to be much more then 1 year
out of date.

Same applies to compiler toolchain flags, though where the flags don't
depend on GCC version that can be partially mitigated in the JDK spec.

Overall, I find the idea of basing Fedora builds on oldest EPEL quite
challenging to accept, due to the age differences. It feels contrary
to Fedora goal of always being on, or at least very near, the cutting
edge. 

> I do not have hard requirement to build java-latest-openjdk on epel8 and
> repack everywhere, but it gave sense. If the hard demand will be to build
> also java-latest-opnejdk in oldest fedora, and repack in all fedoras, and
> built it in oldest epel, and repack in all epels, then it gave somehow
> sesnse too. Although I would conisdered it a bit wasted cycle, it is
> acceptable.

IMHO it'd be more palatable for the RHEL (EPEL) build stream to be separate
from the Fedora build stream. While RHEL and Fedora share heritage, they are
ultimately different distros with different goals and needs.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Daniel P . Berrangé]

On Wed, May 31, 2023 at 07:32:09PM +0200, Vitaly Zaitsev via devel wrote:
> On 31/05/2023 19:24, Daniel P. Berrangé wrote:
> > Can you point to the specific guideline that this violates ?  I know we've
> > always expected that apps are built from pristine upstream source, but I'm
> > not finding the specific guideline that describes this right now.
> 
> This:
> 
> > All program binaries and program libraries included in Fedora packages
> > must be built from the source code that is included in the source
> > package.
> 
> Source:
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

So the important think there is the justification for why this policy
exists:

[quote]
This is a requirement for the following reasons:

Security: Pre-packaged program binaries and program libraries not built 
from the source code could contain parts that are malicious, dangerous, or just 
broken. Also, these are functionally impossible to patch.

Compiler Flags: Pre-packaged program binaries and program libraries not 
built from the source code were probably not compiled with standard Fedora 
compiler flags for security and optimization.
[/quote]

The proposal still satisfies the "Security" reasons. The also still
satisfies the "Compiler Flags" reason, albeit by using flags from an
earlier Fedora release. In any case, packages can already opt-out of
Fedora compiler flags at any time they wish.

Overall I'd say the JDK proposal still meets the spirit of the stated
guidelines and would be reasonable for FPC to approve as an exception.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Daniel P . Berrangé]

On Tue, May 30, 2023 at 04:31:01PM -0700, Kevin Fenzi wrote:
> So, the only way I can see to do this would be to have releng manually
> tag the builds from oldest release into newer ones each time they are
> built. I do not like this for a number of reasons:
> 
> * It's more manual work. 
> * It bypasses a bunch of our process. There wouldn't be any bodhi
> update, so no CI checks, no chance for karma, no updates-testing step
> (unless there's more work to retag a bunch of times).

The build in the oldstable branch can still use bodhi, go through
CI checks, get karma, etc. Once that's all satisfactorily passed,
it could then be tagged for the newer release(s). The fact that
we're shipping the exact same binary for both streams, static
linked, means must of that testing work for oldstable will remain
valid for newer branches too. Yes, it would loose some amount of
integration testing of the distro release differences, but the
use of static linking of its deps would partially mitigate this
downside.

Informally, people could grab the F37 update from bodhi and install
it on F38/rawhide to do that testing, it just wouldn't explicitly
tracked by bodhi as it wouldn't know what stream each person had
tested against. People who care about Java though have a vested
interest in doing such testing though. So mostly I think we loose
enforcement of the testing, but the actual level of testing is not
likely to be terribly different or have a negative impactful.

The level of testing of JDK is still going to be massively better
than most other packages in Fedora, by virtue of going through the
formal JDK certification test suite which is pretty comprehensive.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Daniel P . Berrangé]

On Wed, May 31, 2023 at 06:48:37PM +0200, Vitaly Zaitsev via devel wrote:
> On 31/05/2023 15:44, Gerd Hoffmann wrote:
> > We do similar things in other cases, see for example shim-unsigned.rpm +
> > shim.rpm
> 
> Shim is a special case:
> 1. Shim need to be signed by Microsoft on their own infrastructure and this
> signature will be built directly into PE file.
> 2. Shim runs on UEFI, so it can use exception for firmware.
> 
> > The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't
> > see how that violates the 'build from source' requirement.
> 
> If the package uses prebuilt blobs (their origin is irrelevant), it violates
> current Fedora packaging guidelines.

Can you point to the specific guideline that this violates ?  I know we've
always expected that apps are built from pristine upstream source, but I'm
not finding the specific guideline that describes this right now.

There *is* absolutely a difference between using a pre-built blob provided
by a 3rd party, vs using a pre-built blob obtained from a previous Fedora
RPM build.

The purpose of Fedora building from pristine source is to ensure that the
binary we distribute actually matches the source we distribute, which is
important for licensing compliance and also should we ever need to rebuild
later to patch the RPM we want confidence we can do so. Using a pre-built
blob from a 3rd party can't satisfy our goals in this respect. Using a
pre-built blob from a previous Fedora build absolutey *can* satisfy our
needs. In fact we do this all the time - when we build cloud images or
containers we are using pre-built blobs from a previous Fedora build
process.

What is proposed for the JDK is definitely a new scenario for Fedora,
but we will still be able to satisfy our needs to trace a binary back
to its pristine source. That critical traceability aspect is preserved.
Thus I do NOT see this proposal as fundamentally unsound from a packaging
POV, merely different and unusual.

Finally the Fedora packaging guidelines are guidelines, not rules:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy

 "As these guidelines can never cover all possible contingencies, there
  will always be packages which need exception."

In the worst case the exception would require approval of FPC, and that
is what this change proposal ultimately seeks to attain, which is good.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Statistics - SPDX Hackfest edition

[Daniel P . Berrangé]

On Wed, May 17, 2023 at 08:23:51AM +0200, Miroslav Suchý wrote:
> If your package does not have neither git-log entry nor spec-changelog entry
> mentioning SPDX and you know your license tag matches SPDX formula, you can
> put your package on ignore list
> 
> https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt
> 
> Either pull-request or email to me is fine.

The 'yajl' package uses the ISC license, and the Fedora & SPDX names
match, so no update is required. Please add to the ignore list.

If any other packages in Fedora exist with merely 'ISC' license they
also can potentially be ignored.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to get a rawhide i686 VM?

[Daniel P . Berrangé]

On Mon, May 15, 2023 at 12:38:35PM +0200, Dmitry Belyavskiy wrote:
> Dear colleagues,
> 
> What is the simplest way to get a rawhide i686 VM? I came across a
> nasty architecture-specific bug, and the code investigation isn't of
> much help. There is no obvious way to access a core dump via mock
> (could you please ping me if it exists?) and the VM looks like a
> reasonable choice.

Fedora discontinued i686 installation support quite a while ago
now. As such there is no rawhide i686 VM or cloud image or container
image available.

The only usage of i686 libraries in Fedora should be in a multilib
context on an x86_64 installation, and even then maintainers are
encouraged to drop i686 builds of leaf packages.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Daniel P . Berrangé]

On Wed, May 10, 2023 at 11:37:34AM -0500, Chris Adams wrote:
> Once upon a time, Daniel P. Berrangé  said:
> > If the idea to allow a UKI to contain multiple alternate, signed,
> > cmdline line profiles gets accepted
> 
> Are those of us who need boot-time kernel options (e.g. for hardware
> workarounds or such) just screwed in the signed command-line cases?

Today yes, but in future no. There's very active ongoing discussion
and coding to sort out how to securely allow local customization
of kernel command lines. Note, I said "local customization", I didn't
say "arbitrary interactive override at boot time". IOW, the way it is
achieved will probably look different to what we're used to historically.

Some form of local deployment level customization is clearly critical if
UKIs are to be viable beyond tightly constrained deployment scenarios.
Hardware specific workarounds is one use case that needs to be supported.

If you want to learn more, the systemd ticket I linked to in my mail
has all the discussion (sorry, a very long read, I know) and links to
pull requests where relevant.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Daniel P . Berrangé]

On Wed, May 10, 2023 at 12:00:36PM -0400, Neal Gompa wrote:
> On Wed, May 10, 2023 at 11:12 AM Simo Sorce  wrote:
> >
> > On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> > > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering  
> > > wrote:
> > > >
> > > > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> > > >
> > > > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > > > that it no longer has a fixed space allocation to deal with the ever
> > > > > increasing amount of firmware required for NVIDIA GPUs[1]. This is
> > > > > currently incompatible with how systemd views the world, because the
> > > > > "discoverable partition spec" is wired to partitions, and there is no
> > > > > equivalent spec for subvolumes of a volume. And I imagine that
> > > > > XBOOTLDR (whatever that is) also would have a problem with this.
> > > >
> > > > This makese no sense. If you want /boot to just be a subvolume of the
> > > > rootfs btrfs, then this would imply it's also covered by the same
> > > > security choices, i.e. encryption. We want to bind that sooner or
> > > > later to things like TPM2, FIDO2, PKCS11. And that's simply not
> > > > feasible from a boot loader environment.
> > > >
> > > > Hence, the place the kernel is loaded from (regardless if you call it
> > > > /efi or /boot or /boot/efi, and regardless what fs it is) must be
> > > > accessible from the boot loader easily, without requiring
> > > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader.
> > > >
> > > > Hence: btrfs subvols won't work for this
> > >
> > > If we're not using LUKS for encryption, then this is not a problem.
> > > We're generally looking toward encrypting subvolumes individually
> > > using the upcoming Btrfs native encryption capability rather than
> > > using LUKS. That allows us to
> > >
> > > 1. Pick which subvolumes are encrypted
> > > 2. Pick the security binding method per subvolume
> > >
> > > For example, the root and home subvolumes would use TPM or some other
> > > non-interactive binding. The user subvolume in home would decrypt with
> > > user login.
> >
> > Neal,
> > I think you are barking up the wrong tree here.
> >
> > The design of the boot loader *nedds* to be simple.
> >
> > Simple means, VFAT and *no trust* in the filesystem, individual files
> > are signed and verified.
> > Only the bare minimum *necessary* is in the boot partition, which means
> > kernel images and the bare minimum init image needed to unlock and
> > mount the root partition.
> >
> > There is no point in building a more complex system than that and load
> > tons of garbage drivers in the EFI.
> >
> > Booting is a staged system, and should be kept as simple as possible to
> > avoid duplication (which means subtle bugs and a ton of maintenance
> > overhead).
> >
> 
> This proposal isn't better. Neither Windows nor macOS put critical
> operating system code in the ESP, and we shouldn't either. But you
> want to put kernels in the ESP? That's the wrong approach too.
> 
> As soon as you throw UKIs in the mix, you've completely broken that
> because now the absolutely most valuable code for your system is in a
> "hostile" environment. At least we can make /boot authenticated and
> tamper resistant as a Btrfs subvolume.

The firmware will start by booting a binary found in the ESP,
and thus given the ESP is untrusted (hostile) we need a means
to validate that binary's integrity no matter what, most likely
using SecureBoot & TPM PCR measurements. Using this mechanism
for validating the UKI makes sense since it has to exist no
matter what. There's no need for the filesystem to be authenticated
/ tamper resistant if the binaries themselves are authenticated
and tamper resistant.

> I would rather have a multi-stage boot process, where the first stage
> does just enough to unlock and load the OS volume to load the real
> boot environment.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Daniel P . Berrangé]

On Wed, May 10, 2023 at 03:52:51PM -, Luca Boccassi wrote:
> > On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> > 
> > It sounds reasonable for sure.
> > The only concern is, given Microsoft creates at most 500MB ESP
> > partitions, are we sure all UEFI systems out there will not choke on a
> > 1GB one?
> > 
> > Can't we reduce the number of kernels by having *only* one UKI and a
> > rescue one that can be used to restore the previous working UKI from
> > /root if the active one fails?
> > 
> > Or perhaps just have always 2 UKI (current, and former working).
> > Do we actually need a separate dedicated rescue UKI? Can't rescue be
> > implemented by booting the previously working UKI with a "rescue"
> > command line option ?
> 
> Word of caution on 'rescue' images: MSFT just had to essentially
> render 10 years of recovery/install media unbootable due to the
> black lotus vulnerability. It was not (and still is not) pretty.
> 
> When there's signatures and verifications involved, you really
> want an upgradable system. But if you set that whole infrastructure
> up, there's really not that much difference left with an A/B scheme.

If the idea to allow a UKI to contain multiple alternate, signed,
cmdline line profiles gets accepted [1], then a "rescue" image
won't neccessarily need to be a separate image anymore. There could
just be an alternative cmdline that caused the initrd to launch in
a "rescue" / "safe" mode, and that would be nicely complemented by
an A/B scheme to cope with bad kernel upgrades.

With regards,
Daniel

[1] https://github.com/systemd/systemd/issues/24539
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: mingw missing debuginfo

[Daniel P . Berrangé]

On Fri, May 05, 2023 at 10:29:07AM -0600, Orion Poplawski wrote:
> On 5/5/23 09:45, Daniel P. Berrangé wrote:
> > On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
> > > I'm trying to add mingw builds to the libssh package here:
> > > 
> > > https://src.fedoraproject.org/rpms/libssh/pull-request/15
> > > 
> > > build is failing with:
> > > 
> > >  Could not open %files file
> > > /home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such
> > > file or directory
> > > 
> > > What am I doing wrong?
> > 
> > Missing call to:
> > 
> >   %{?mingw_debug_install_post}
> > 
> > in the %install section, after installing the mingw build
> > 
> > With regards,
> > Daniel
> 
> Thanks.  That seems to be missing from the example spec files in the docs:
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_example_integrated_package_specfile

Yeah my bad. I documented it earlier

  
https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_debuginfo_subpackage

but missed it from the example. Will send a fix next week.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: mingw missing debuginfo

[Daniel P . Berrangé]

On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
> I'm trying to add mingw builds to the libssh package here:
> 
> https://src.fedoraproject.org/rpms/libssh/pull-request/15
> 
> build is failing with:
> 
> Could not open %files file
> /home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such
> file or directory
> 
> What am I doing wrong?

Missing call to:

 %{?mingw_debug_install_post}

in the %install section, after installing the mingw build

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Statistics - ZX Spectrum edition

[Daniel P . Berrangé]

On Sun, Apr 23, 2023 at 11:09:04AM +0200, Miroslav Suchý wrote:
> Two weeks ago we had:
> 
> > * 22918 spec files in Fedora
> > 
> > * 29406license tags in all spec files
> > 
> > * 19348 tags have not been converted to SPDX yet
> > 
> > * 7521tags can be trivially converted using `license-fedora2spdx`
> > 
> > * Progress: 34% ░░░███ 100%
> > 
> 
> Today we have:
> 
> * 22961 spec files in Fedora
> 
> * 29459license tags in all spec files
> 
> * 19099 tags have not been converted to SPDX yet
> 
> * 7404tags can be trivially converted using `license-fedora2spdx`
> 
> * Progress: 35% ░░░███ 100%

 given we're not doing license minimization any more, I'm curious
what package is going to win the prize for the longest license tag :-)

> NEW: the package fedora-license-data now contains BNF grammar which you can
> use. It is available in `/usr/share/fedora-license-data/grammar.lark`

Any guidance on how to use this grammar ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: mingw sysroot paths (and generalizing them)

[Daniel P . Berrangé]

On Fri, Apr 28, 2023 at 02:22:40PM +0200, Florian Weimer wrote:
> Looking at
> 
>   Information for RPM mingw64-zlib-1.2.13-2.fc38.noarch.rpm
>   
> 
> sysroot paths look like this:
> 
>   /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll
>   /usr/x86_64-w64-mingw32/sys-root/mingw/include/zconf.h
>   /usr/x86_64-w64-mingw32/sys-root/mingw/include/zlib.h
>   /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libz.dll.a
>   /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/zlib.pc
> 
> Is the /mingw/ part of the sysroot path, or is it within the sysroot?
> Would I use --sysroot=/usr/x86_64-w64-mingw32/sys-root or
> --sysroot=/usr/x86_64-w64-mingw32/sys-root/mingw to build against the
> sysroot?
> 
> I assumed the latter, but now I wonder if /mingw in the sysroot is the
> analogue of /usr in GNU/Linux sysroots.
> 
> Eventually, we want to produce some GNU/Linux sysroots.  I picked
> 
>   /usr/%{_arch}-redhat-linux/sys-root/fc%{fedora}
> 
> or (depending on the operating system)
> 
>   /usr/%{_arch}-redhat-linux/sys-root/el%{rhel}
> 
> or (as the fallback)
> 
>   /usr/%{_arch}-redhat-linux/sys-root/root
> 
> and we have /usr inside the sysroot, e.g.  is
> 
>   /usr/x86_64-redhat-linux/sys-root/fc35/usr/include/stdio.h
> 
> in a Fedora 35 sysroot on x86-64 (although the Fedora 35 update with
> this never actually went out).  We essentially use the /mingw/ part as
> an OS ABI version indicator, to make the different versions
> co-installable.

Parallel install of different versions of mingw has never been
something we needed to consider. We only need parallel install
the different ABIs, which is handled by the higher level dir
in the path. So from that POV, I don't think mingw particularly
cares what semantics are attached to the 4th path component
'mingw'. As long as we don't have to change our paths currently
used in Fedora, I think it'd be OK for you to define the 4th
component as the OS version indicator. 


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: mingw sysroot paths (and generalizing them)

[Daniel P . Berrangé]

On Fri, Apr 28, 2023 at 01:41:05PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 28, 2023 at 02:22:40PM +0200, Florian Weimer wrote:
> > Looking at
> > 
> >   Information for RPM mingw64-zlib-1.2.13-2.fc38.noarch.rpm
> >   
> > 
> > sysroot paths look like this:
> > 
> >   /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll
> >   /usr/x86_64-w64-mingw32/sys-root/mingw/include/zconf.h
> >   /usr/x86_64-w64-mingw32/sys-root/mingw/include/zlib.h
> >   /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libz.dll.a
> >   /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/zlib.pc
> > 
> > Is the /mingw/ part of the sysroot path, or is it within the sysroot?
> > Would I use --sysroot=/usr/x86_64-w64-mingw32/sys-root or
> > --sysroot=/usr/x86_64-w64-mingw32/sys-root/mingw to build against the
> > sysroot?
> > 
> > I assumed the latter, but now I wonder if /mingw in the sysroot is the
> > analogue of /usr in GNU/Linux sysroots.
> 
> FWIW:
> 
> $ x86_64-w64-mingw32-gcc -print-sysroot
> /usr/x86_64-w64-mingw32/sys-root
> 
> which would indicate that you are correct that /mingw is somehow
> "inside" the sysroot.

Then on the Meson side we define

  root = '/usr/i686-w64-mingw32/sys-root/mingw'

in the /usr/share/mingw/toolchain-mingw32.meson spec, while with
configure we invoke

  configure \
--host=i686-w64-mingw32 \
--build=x86_64-redhat-linux-gnu \
--target=i686-w64-mingw32 \
--prefix=/usr/i686-w64-mingw32/sys-root/mingw \
--exec-prefix=/usr/i686-w64-mingw32/sys-root/mingw \
--bindir=/usr/i686-w64-mingw32/sys-root/mingw/bin \
--sbindir=/usr/i686-w64-mingw32/sys-root/mingw/sbin \
--sysconfdir=/usr/i686-w64-mingw32/sys-root/mingw/etc \
--datadir=/usr/i686-w64-mingw32/sys-root/mingw/share \
--includedir=/usr/i686-w64-mingw32/sys-root/mingw/include \
--libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib \
--libexecdir=/usr/i686-w64-mingw32/sys-root/mingw/libexec \
--localstatedir=/usr/i686-w64-mingw32/sys-root/mingw/var \
--sharedstatedir=/usr/i686-w64-mingw32/sys-root/mingw/com \
--mandir=/usr/i686-w64-mingw32/sys-root/mingw/share/man \
--infodir=/usr/i686-w64-mingw32/sys-root/mingw/share/info \

is there any difference between the notion of the 'sysroot' vs
the install 'prefix' ?

The pkg-config files for mingw also typically define

   prefix=/usr/i686-w64-mingw32/sys-root/mingw


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Daniel P . Berrangé]

On Mon, Apr 24, 2023 at 12:15:12PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/BiggerESP
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> 
> The Fedora installer includes an EFI System Partition of between 200MB
> and 600MB by default, of which the lower size is much too small for
> firmware updates on modern hardware and also for future bootloader
> features like UKI.
> This change will increase the minimum size of the ESP to be 500MB,
> which is also the same value used by Microsoft for Windows 10 and
> newer.

This refers to the minimum size being changed, but later it mentions
the default size being changed. Are the default & minimum sizes
effectively the same in this case ?

nitpick - the github change linked is 512 MiB rather than 500 MB.

> == Owner ==
> * Name: [[User:rhughes| Richard Hughes]]
> * Email: rich...@hughsie.com
> 
> 
> == Detailed Description ==
> 
> Modern hardware has UEFI firmware updates that are more than 64MB in
> size. The OEMs recommend a ESP free space of double the flash size
> plus 20MB and fwupd now enforces this requirement to ensure flash
> success. As the ESP is often shared between Windows and Linux, and
> also used for firmware updates, and soon to be used by UKIs it's not
> enough to just allocate a few hundreds of megabytes. Windows 10 and 11
> allocates an ESP of at least 500MiB. Arch also specifies a minimum of
> 512 MiB.

My only thought is whether 512 MiB is sufficiently future proofed if we
start to make more use of UKIs, given that /boot by comparison is already
at 1 GiB by default IIUC ?

> == Feedback ==
> 
> There is no alternative -- the ESP has to scale up if we want firmware
> updates to continue to work and to support UKIs for next-generation
> bootloaders.
> 
> == Benefit to Fedora ==
> 
> Firmware updates will work on future hardware, and we can boot the
> kernel using UKIs using next-generation bootloaders.
> 
> == Scope ==
> * Proposal owners:
> 
> We need to change a number in Anaconda:
> https://github.com/rhinstaller/anaconda/pull/4711
> 
> == Upgrade/compatibility impact ==
> 
> We can't grow the ESP in size, and so this change will only affect new
> installs. This is fine, as this will affect new hardware more than old
> hardware.
> 
> == How To Test ==
> 
> Install Fedora and observe that /boot/efi has at least 276MB free
> space, even when installed alongside Windows.
> 
> == Dependencies ==
> 
> Anaconda would need to be modified, and Fedora would have a / or /home
> partition that's ~300MB smaller by default than it is now.

For any install which does end up using UKIs on the ESP, the /boot would
no longer need to be as large as it is today as it would not have kernel
images. In fact /boot could potentially not need to exist at all in any
EFI installs using UKIs.

IOW, the increased size for the ESP could potentially be won back by
permitting /boot to be smaller, or eliminating /boot. I'm not suggesting
this needs to be a pre-requisite of this change proposal though, just a
thought for the future. Could be something that is optimized in any cloud
image kickstarts that end up using UKIs.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Daniel P . Berrangé]

On Fri, Apr 21, 2023 at 11:07:16AM -0500, Chris Adams wrote:
> Once upon a time, Matthew Miller  said:
> > * also, to fix typos :) 
> 
> So, I will say this is kind of a peeve of mine about server-based
> discussion systems (whether web or client like Slack/Discord): allowing
> people to edit messages, especially after people have replied to them,
> is a bad idea.  Person 1 says "we should do XYZ", somebody replies "no
> XYZ is bad", and person 1 can go change their original message to say
> something completely different.

Sure that is possible, but lets not assume nor optimize for malicious
engagement. We should be optimizing for honest engagement because our
contributors are decent people. The vast majority of the time when
people go back to edit messages it will be to correct mistakes/typos,
or syntax errors in formatting text, and so a clear benefit.

In the unlikely / rare event that someone did maliciously change the
original message for some nefarious reason, other users can call them
out, and in the worst case moderators could take action. I very much
doubt that would happen enough to be a problem worth worrying about
in a constructive community environment like Fedora.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Daniel P . Berrangé]

On Fri, Apr 21, 2023 at 04:55:00PM +0200, Emmanuel Seyman wrote:
> * Kevin P. Fleming [21/04/2023 10:03] :
> >
> > lots of people say "I decide
> > what to read based on what I see in my email client", but when the subject
> > of the emails doesn't reflect their contents, that's a losing proposition.
> 
> I agree there's a huge lack of netiquette in Fedora's mailing lists,
> with wholesale quoting, top-posting, subjects not being updated, etc but
> changing mediums seems far more expensive than asking people to post
> emails that are easier to read.

I generally find the term "netiquette" to be quite unpleasant, because
it is historically frequently applied in user hostile manner, where
people repeatedly rebuke (new) contributors/participants who don't
follow the "rules", which has the effect of discouraging engagement
with the project.

Contributor guidelines are fine, but it is important to accept, expect
and tolerate that people are *NOT* going to following the guidelines,
for a variety of reasons.

IMHO the application of "netiquette" rules in a particular scenario is
usually a sign that the tools being used are inadequate for the job
they're be applied to.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Daniel P . Berrangé]

On Thu, Apr 20, 2023 at 05:20:37PM -0400, Matthew Miller wrote:
> We’re missing people
> 
> 
> A Mastodon post from long-time Fedora contributor Major Hayden got me
> thinking:
> 
> > How do people make so much time available for mailing list
> > discourse?
> >
> > Once I ensure my team has the technical guidance they need
> > and I work through the tasks of work that I owe other
> > people, I take a look at the mailing list and say: "Oh my
> > gosh, what the heck happened here?" Then the discussion
> > goes further off the rails while I'm typing out a reply and
> > my reply is no longer relevant.
> >
> > — https://tootchute.com/@major/109666036733834421
> 
> I know many Fedora folks, old-school and new, for whom devel list is
> just too much. 

I think that applies to the vast majority of people on my team. They
are doing work that ends up in Fedora, they use Fedora, and they will
sometimes needs to make changes in Fedora packages, but they'll rarely
/ never read the mailing lists. Essentially, unless a very large amount
of your daily work is Fedora oriented, the devel list is not feasible
to follow. It is not suited to infrequent/sporadic Fedora contributors.

Myself I'll try to keep an eye out for interesting $SUBJECTs and read
those, or peek into exploding threads to see what the fuss is about,
but the rest I'll just ignore as it is too much. I'll try to relay the
important nuggets of info to others in my team, but that's a limited
mitigation.



When you say "We're missing people" there's actually another factor
that you've not mentionedspam, or more specifically anti-spam
countermeasures.

There are a handful of very regular Fedora contributors, for whom
about 50% of messages they send get reliably classified as spam
by my employer's mail service because of something it dislikes
about their mail server/domain's reputation. While I can allow-list
their addrs for myself, each subscriber has to repeat the same
allow-listing and I expect many won't bother.

IOW, we have people who think they are contributing to Fedora
discussions, but in fact their mails are getting effectively
silently discarded. This is bad if we want inclusive discussions.


In other mailing lists where I am the admin I get to see even worse
problems where mails get unconditionally discarded at time of delivery
due to disagreements between mail servers about the correct way to
implement DMARC and DKIM. As a result certain senders are entirely
prevented from collaborating via the mailing list in the worst possible
way. They successfull send the mail, it is accepted by the list server,
added to the online archives, but when the list server delivers to
subscribers the message bounces back. Unless the mailing list admin
watches non-delivery bounces no one will know this is happening.
Certain senders will simply not be part of the discussions.

Having battled email/spam problems wrt mailing lists for years now,
I can only conclude that email is not viable as a reliable & inclusive
communications tool in the modern world.


> We’re scattered in actual practice
> --

> Many groups have actually moved away from lists to using tickets for
> team conversations — both those non-engineering functions
> and development. Design Team has a mailing list, but mostly for
> announcements: the work happens in tickets. Workstation largely uses
> their Pagure tracker. And CoreOS conversations happen almost entirely
> in tickets on Github.
> 
> Tickets are made for tracking specific, actionable tasks, and that kind
> of tracking is part of why teams use them over mailing lists — but
> Fedora teams use them for open development conversations too. I think
> that’s largely a symptom of mailing lists not being enough for what we
> need. The trackers have media support, editing for typos or updates,
> reactions for simple agreement, tagging people, and granular
> subscriptions. They are effectively “off-label use” mini-forums that
> teams can quietly move to using without the sort of conversation I
> expect this message to generate.

> Airplane diagram, survivorship bias
> ---
> 
> The set of remaining regular participants on this list is naturally
> biased towards those for whom it is working just fine. But, core Fedora
> development discussion can’t be limited to that ever-shrinking group.
> Consider who isn’t here. The problems are real, and the trend isn’t in
> a good direction.

Or stockholm syndrome. As a long term email users I'm familiar with it
and learn to put up with all its flaws and figured out ways to mitigate
the limitations of email.

If you speak to any long term email users in high traffic OSS communities
you'll find many of them have created very elaborate mail filters, scripts
and tools to create workflows for handling the high volume of their inbox.
Newer contributors won't have this, so when you ask them to turn on the
fire hose by subscribing to Fedora 

Re: DNF Sytem Upgrade requirements for an F37 → F38 upgrade

[Daniel P . Berrangé]

On Thu, Mar 30, 2023 at 10:49:33AM +0200, Miroslav Suchý wrote:
> Dne 30. 03. 23 v 0:08 Fabio Valentini napsal(a):
> > Additionally, the smallest offerings of popular VPS providers have
> > just 1 or 2 GB of RAM, is Fedora Server no longer supported on systems
> > like these?
> 
> At first place - upgrades in cloud environment should be discouraged. The
> standard should be 1) describe your system in Ansible playbook 2) terminate
> machine 3) change in your playbook the name of new image 4) run your
> playbook. This is how we upgrade machines in cloud in fedora-infra.

I don't think it is realistic to expect users to follow such steps
in the general case as plenty of cloud VMs are considered precious
and not simply able to be thrown away and replaced by freshly built
system that way.

> And not sure if it worth a work (likely not easy) as the upgrades from F39
> to F40 will be done by DNF5 with totally different (smaller I hope)
> footprint.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: SPDX License Phase 2 (System-Wide Change proposal)

[Daniel P . Berrangé]

On Thu, Mar 16, 2023 at 03:16:29PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_2
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> 
> == Summary ==
> 
> Second phase of transition from using Fedora's short names for
> licenses to [https://spdx.org/licenses/ SPDX identifiers] in the
> License: field of Fedora package spec files. This phase addresses how
> to update the License: field for existing packages, including
> documenting more specific guidance on how to find licenses in a
> package.
> 
> == Owner ==
> 
> * Name: [[User:msuchy| Miroslav Suchý]], [[User:jlovejoy| Jilayne
> Lovejoy]], [[User:ngompa| Neal Gompa]], [[User:dcantrell| David
> Cantrell]], [[User:ref| Richard Fontana]], [[User:mattdm| Matthew
> Miller]]
> * Email: msu...@redhat.com, dcantr...@redhat.com, jlove...@redhat.com,
> ngomp...@gmail.com, rfont...@redhat.com
> 
> 
> == Detailed Description ==
> This is follow-up of [[Changes/SPDX_Licenses_Phase_1|Phase 1]]. During
> this phase, all remaining packages should be migrated to use SPDX
> license identifiers in the License: field of the package spec file.
> 
> So far, package maintainers have been updating their packages in
> accordance with the guidance provided at
> https://docs.fedoraproject.org/en-US/legal/update-existing-packages/
> and filing issues in the
> [https://gitlab.com/fedora/legal/fedora-license-data
> fedora-license-data repo]. Miroslav has been tracking how many
> packages that have been updated. Given the large number of packages in
> Fedora, this progress is good, but slow.
> 
> We are considering options for how to more quickly migrate, in terms
> of how much automation can be applied as opposed to taking this as an
> opportunity as a more thorough license review. Automated updating of
> Fedora legacy abbreviations to SPDX expressions is only possible to a
> limited extent due to different criteria used in each system, most
> notably the use of
> [https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_updating_existing_packages_callaway_short_name_categories
> "category" short names in the Fedora legacy system]. Also, the
> [https://docs.fedoraproject.org/en-US/legal/license-field/ policy for
> populating the License: field] has been clarified with a view to
> eliminating inconsistent guidance in past documentation, which may
> mean that a determination made in the past would be different today.
> Nonetheless, automated updates for a curated set of Fedora legacy
> abbreviations can help speed up the migration and serve as a reminder
> and helping hand to package maintainers who may have not started this
> process. If the automatic migration is not possible (e.g., needs
> clarification from legal), then a Bugzilla issue has to be created.
> 
> Plan:
> * Hold a hackfest focusing on a limited set of Fedora packages.
> Feedback from the hackfest can then be used to improve documentation
> related to updating existing packages.
> * Review of licenses for which there seems to be a one-to-one mapping
> from Fedora legacy abbreviations to SPDX identifiers to ensure
> reliable mapping. license-fedora2spdx will then be updated to use that
> curated set of mappings.
> * Packages using legacy license expressions will be automatically
> converted if the package maintainer has not already taken care of it.
> Packages with compound legacy license expressions will only be
> converted if all included identifiers can map to fedora-license-data.
> That is, there is no mixing of SPDX and legacy Fedora identifiers.
> ** The conversion will be done in waves to minimize errors in
> automation (e.g., 100 packages in the first week, 200 packages in
> another week, ...).  A pull request for the package spec file will be
> created as part of the conversion. If the maintainer does not respond
> to the pull-request within 14 days, the pull request will be merged by
> Change owners.
> ** As mentioned above and at
> https://docs.fedoraproject.org/en-US/legal/update-existing-packages/,
> automatic conversion is not possible for a lot of packages and will
> need direct review.  For example, legacy license identifiers that
> cannot be automatically converted: BSD, MIT, with exceptions.

This paragraph is ambiguously worded.

   Does this imply that packages for which automatic conversion
   is impossible are out of scope for conversion during phase 2 ?

or

   Does this imply that there is a group of people who are
   actively going to do manual review and conversion  as prt
   of phase 2 ?

or something else again ?

> * Regular office hours will be held to help answer questions for
> package maintainers.
> 
> As of 2023-03-13 the automatic conversion can be done for
> approximately 8096 packages.
> 
> Around Fedora 39 Beta owners will 

Re: HaveIBeenPwned database in Fedora somewhere?

[Daniel P . Berrangé]

On Tue, Mar 21, 2023 at 02:28:08PM +0100, Pavel Raiskup wrote:
> Hello all!
> 
> Do we have HaveIBeenPwned database of hashes somewhere in Fedora, as a
> file or service (regularly updated)?  I'd prefer checking my passwords
> manually, without actually giving the passwords to the
> https://haveibeenpwned.com service.  Speaking of that, I really dislike
> that the service takes the real passwords on it's input.

The query API only takes a partial hash of the password, not the
clear text password

https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByRange

  "In order to protect the value of the source password being
   searched for, Pwned Passwords also implements a k-Anonymity
   model that allows a password to be searched for by partial
   hash. This allows the first 5 characters of either a SHA-1
   or an NTLM hash (not case-sensitive) to be passed to the API "


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposed integrated mingw packaging guidelines [Re: Planning to start unifying native and mingw packages]

[Daniel P . Berrangé]

On Wed, Mar 01, 2023 at 01:45:14PM +, Daniel P. Berrangé wrote:
> On Wed, Aug 24, 2022 at 03:00:06PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote:
> > > On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé  
> > > wrote:
> > > >
> > > > On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:
> > > > > Hi
> > > > >
> > > > > Following recent discussions and to reduce the maintenance burden, I'm
> > > > > planning to start merging native and mingw packages. Initially, I'll 
> > > > > be
> > > > > looking at these packages where I maintain both variants:
> > > >
> > > > I've done the same with all the mingw packages I maintained just
> > > > before Fedora 37 branched. So the following native packages now
> > > > just contain mingw sub-RPMs:
> > > >
> > > >  libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc
> > > >
> > > > I'm so happy to have reduced this maint burden. I see a few new mingw
> > > > packages pending in package review and think it'd be nice to first ask
> > > > the native maintainer to consider unified package, before we approve
> > > > any new separate mingw packages.
> > > >
> > > > Our Mingw packaging guidelines, however, exclusively describe fully
> > > > separated mingw packages.  So if I suggest this to a native package
> > > > maintainer who is not already familiar with mingw, they would be
> > > > right to question whether this is a desirable thing.
> > > >
> > > > IOW, I think we need to look at getting the mingw packaging docs
> > > > updated to promote unified packaging as an officially supported
> > > > (and even preferred) option, alongside separate packaging.
> > > 
> > > Sounds great.
> > > The Packaging Committee is looking forward to your PR ;)
> > 
> > I don't want to rush into doing that myself in case someone else reading
> > along is very enthusiastic to do the work themselves ;-P
> 
> Fast forward 6 months and evidentally no one else was enthusiastic about
> updating the MinGW packaging guidelines, so I've taken on that task myself :-)
> 
> I have not yet submitted to the Packaging Committee for approval. The
> first draft of updated guidelines I have is here:

I've now opened ticket and pull request with the packaging committee

  https://pagure.io/packaging-committee/issue/1259
  https://pagure.io/packaging-committee/pull-request/1260

so ideally please direct any feedback to the above locations.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Timeframe for EPEL retirement vs RHEL new package releases

[Daniel P . Berrangé]

On Fri, Mar 03, 2023 at 06:55:46AM -0800, Troy Dawson wrote:
> We are currently in the middle of changing the workflow of retiring these
> packages.  We are changing it so that the package maintainer doesn't do the
> removing.  It will be automated, or semi-automated, so there is a
> consistent time when all of them are removed.

That's a good idea.

> When do you actually remove the packages from the EPEL repository?
> It has been agreed that it will be after both Alma and Rocky have their
> latest release out.

Ok, that's good, and should at least avoid breaking my upstream CI
use case since our containers should transparently start receiving
the 9.2 content when Alma releases their rebuilt container iamges.

> But how long after?
> Immediately after?  a month? 6 months?
> 
> I personally am leaning towards a month after.
> Here is my reasoning.
> At the time a new RHEL release is released, we take a snapshot of the EPEL
> repo and put it in the archives.
> So all the packages that were built, and run on RHEL 9.1 are available in
> that archive.

snip

> Anyway, if some users are still doing new installs of RHEL 9.1 (or
> compatible) after that month, then they should probably add the epel 9.1
> archive to their yum repositories.

That's interesting, I didn't know about the y-stream archive
snapshots.

Is there any mileage in considering a way to make the use of the epel
9.1 archive automatic so users don't have risk of breakage needing manual
reconfiguration to keep working ?

eg perhaps have 2 yum repos provided and enabled by epel-release. One
repo URL always the latest release and one repo URL always the current
9.x release number, with a lower priority number set. The latter repo
initially empty of packages, but at the start of 9.2 it receives the
snapshot of 9.1 content, and so becomes dominent over the former repo
which will henceforth be holding 9.2 content.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gnutls time_t breakage on i686

[Daniel P . Berrangé]

On Fri, Mar 03, 2023 at 12:56:27PM +0100, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> > AFAICT, Fedora either keeps 32-bit time_t, or kills i686 for good.
> 
> I agree with this position.
> 
> For additional details, here is what I wrote in the other thread
> (regarding defaulting time64):
> 
> | That still needs some per-package work (mainly for scripting languages
> | using FFI) because dlsym for gettimeofday etc. still find the 32-bit
> | variant.  There are various ways we can hack around that, I guess.
> | 
> | Anyway, this dual ABI break (for off_t and time_t) needs to be proposed
> | as a Fedora change, and we can discuss mechanics if Fedora wants to move
> | in that direction.  I think this is far from a given because a
> | still-unknown amount of third-party software will break.  GNUTLS, for
> | example, used to have a fairly stable ABI: libgnutls.so.30 goes back a
> | couple of years; I think it was part of CentOS 7 already.
> | 
> | I think the first step is to decide if we want to do this.  After that,
> | we can discuss mechanics.  For example, traditionally, ABI changes like
> | this have not been implemented through build flags injection in Fedora,
> | rather we updated the toolchain defaults.
> | 
> | Needless to say, I have very little interest to work on this (I consider
> | all this a pointless distraction, to be blunt), but I guess I can help
> | with toolchain enablement.

Yes, this whole episode makes me want to kill off i686 builds of everything
I maintain, even when its not a leaf package. I only spent time investigating
the root cause in gnutls because I saw valgrind warnings and wanted to be
sure there wasn't a security flaw lurking that would impact x86_64 too. I
have absolutely no interest in spending resources to retrofit 64-bit time_t
to a build target that ceased to be relevant to the overwhealming majority
of Fedora users many years ago.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue