Re: Is there a policy for branches being merged or not

[Peter Robinson]

On Sun, 28 Apr 2024, 09:28 Julian Sikorski,  wrote:

> Hello,
>
> is there a general recommendation regarding keeping git release branches
> separate vs merged? I have been keeping mine separate. Originally to
> avoid release and changelog conflicts when cherry-picking, but I got
> used to it and kept doing it after converting to %autorelase and
> %autochangelog.
> Recently one of my packages got it branches merged by a provenpackager
> doing a deps rebuild. If there is no policy to merge, this is
> disappointing as force-pushes as not allowed and branches once merged
> cannot be unmerged. I know this is just a cosmetic issue, but choices
> made by the primary maintainers should be respected IMO.
>

It's up to the maintainers, but it's also hard to determine what the
maintainer's intentions are for those sorts of things, especially if you're
scripting a rebuild across 100s of packages for a bump.

As both a maintainer and a proven packagers I tend to just assume the
person has the best intentions of the project in mind.

Best regards,
> Julian
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Fedora Miracle Spin (self-contained)

[Peter Robinson]

On Thu, 25 Apr 2024 at 12:32, Neal Gompa  wrote:
>
> On Wed, Apr 24, 2024 at 10:49 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Apr 24, 2024 at 10:33:51PM -0500, Neal Gompa wrote:
> > > On Wed, Apr 24, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > >
> > > > On Wed, Apr 24, 2024 at 04:57:40PM +0100, Aoife Moloney wrote:
> > > > > Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
> > > >
> > > > > {{package|miracle-wm}} is available in Fedora Linux 40, so it can be
> > > > > installed on top of something like the existing Sway spin and
> > > > > configured to reuse much of the tools used there.
> > > > >
> > > > > For Fedora Linux 41, once the spin is produced, people can download
> > > > > and try the experience intended to be released.
> > > >
> > > > I applaud people trying out new window managers and doing stuff with
> > > > Fedora. But the overhead of creating and distributing a spin is quite
> > > > high… It seems that the contents of this spin would overlap very
> > > > strongly with Sway Spin. Would it make sense to combine them and
> > > > allow users to easily select one or the other? Even during boot, there
> > > > could be two boot menu entries and we could provide simple instructions
> > > > to switch between the desktops on an installed system.
> > > >
> > >
> > > Aside from actually being unintuitive and confusing to people to smush
> > > two spins together like that, the experience will eventually differ
> > > because different tools will be used.
> >
> > What tools?
> >
>
> Well, since it's based on Mir instead of wlroots, some Mir specific
> tooling may be developed. One of the goals is to have Fedora Miracle
> as a reference platform for showcasing and developing a community and
> ecosystem around the Mir compositor library.
>
> Two things being discussed upstream are how to support server-side
> decorations and how to support portals. Both of these are going to be
> Mir specific and at least the portal stuff will likely conflict with
> another spin's configuration.
>
> Miracle has only very slight compatibility with the Sway/i3 IPC, just
> barely enough for waybar to function. Most of the Sway tooling isn't
> going to work on Miracle because they rely on that IPC.
>
> > > Also, you overestimate the burden of creating a spin. Aside from
> > > comps, kickstart definitions, and pungi config being done initially
> > > (which isn't too high to begin with either), the effort required to
> > > maintain a spin image is extremely low.
> >
> > There's also the effort of distribuiting and archiving a few
> > additional gigabytes, putting up the links on the website and browsing
> > through them, some additional time and and additional step that can
> > fail during builds…
> >
> > > A large chunk of our spins are essentially semi-automatic these days,
> > > and people don't really notice because at the end of the day, it's a
> > > bundle of things configured together.
> >
> > Yes. And my point is that we can come up with a hundred or a thousands
> > of such bundle definitions, and my question is whether we should
> > create a separate deliverable for each possible definition.
> >
>
> If a SIG is willing to do it and support it, I don't see why not.

There's also QE efforts required to test it, and how many users will
it even get, is it worth it if there's a dozen users?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Rust Stack Spring Cleaning - 2024 Edition

[Peter Robinson]

On Thu, 11 Apr 2024 at 14:26, Fabio Valentini  wrote:
>
> Hello Rust packagers,
>
> I'm continuously working on reducing unnecessary accumulation of cruft
> in the Rust package stack in Fedora, and I have been keeping track of
> unused library packages for almost three years now.
>
> Some of these packages have been unused leaves for over two years!
>
> I will again start being more proactive with orphaning / retiring
> affected packages where I am the primary maintainer, starting
> incrementally from the packages which have been unused for the longest
> time - unless I know of a reason to keep a specific package, for
> example:
>
> - something that depends on the package is still going through package review
> - the package was updated to a "breaking" release and a compat package
> was created, and now the "main" package is not depended on while the
> compat package is in use
>
> If you know of a reason why a leaf package where I am the primary
> maintainer should not be retired, please let me know, and I will
> exclude it from the list.
>
> For packages where I am *not* the primary maintainer, I need help:
>
> - Is this package still required for something that I don't know
> about, or can it be dropped?
> - Was it added as a dependency for something else, but packaging this
> "something else" was abandoned?
> - Was it needed at the time, but is the library no longer needed now?
>
> Keeping unused packages around only makes maintenance of the Rust
> stack more difficult due to the more "dense" dependency graph that
> needs to be considered when pushing "breaking" changes. Over the past
> year or so, the number of Rust packages in Fedora has grown by almost
> 50% from about 2200 to over 3000, which is making this issue worse.
>
> Full report included below (view in monospace font for correct formatting).
>
> Thank you for your help,
> Fabio
>
> +--++---+--+
> | Package  | Leaf since | Leaf days | Maintainer  
>  |
> +--++---+--+
> | rust-curve25519-dalek| 2021-11-18 |   875 | dcavalca
>  |
> | rust-gstreamer-editing-services  | 2021-11-18 |   875 | atim
>  |
> | rust-gstreamer-player| 2021-11-18 |   875 | atim
>  |
> | rust-rand_jitter | 2021-11-18 |   875 | jistone 
>  |
> | rust-rand_os | 2021-11-18 |   875 | jistone 
>  |
> | rust-tower-test  | 2021-11-18 |   875 | decathorpe  
>  |
> | rust-tower-util  | 2021-11-18 |   875 | decathorpe  
>  |
> | rust-partial-io  | 2022-02-06 |   795 | decathorpe  
>  |
> | rust-minimad | 2022-02-18 |   783 | dcavalca
>  |
> | rust-libhandy| 2022-02-20 |   781 | decathorpe  
>  |
> | rust-tiger   | 2022-02-20 |   781 | decathorpe  
>  |
> | rust-rand_hc | 2022-02-21 |   780 | jistone 
>  |
> | rust-benfred-read-process-memory | 2022-02-27 |   774 | dcavalca
>  |
> | rust-custom_error| 2022-02-27 |   774 | dcavalca
>  |
> | rust-madvr_parse | 2022-02-27 |   774 | dcavalca
>  |
> | rust-os-release  | 2022-02-27 |   774 | dcavalca
>  |
> | rust-strict  | 2022-02-27 |   774 | dcavalca
>  |
> | rust-subprocess  | 2022-02-27 |   774 | dcavalca
>  |
> | rust-libxml  | 2022-04-07 |   735 | decathorpe  
>  |
> | rust-snake_case  | 2022-04-25 |   717 | decathorpe  
>  |
> | rust-openat-ext  | 2022-04-28 |   714 | walters 
>  |
> | rust-log-mdc | 2022-05-05 |   707 | decathorpe  
>  |
> | rust-cargo-manifest  | 2022-05-06 |   706 | laiot   
>  |
> | rust-digest_auth | 2022-05-06 |   706 | laiot   
>  |
> | rust-binascii| 2022-05-10 |   702 | saluki  
>  |
> | rust-inlinable_string| 2022-05-10 |   702 | decathorpe  
>  |
> | rust-ubyte   | 2022-05-10 |   702 | decathorpe  
>  |
> | rust-email-encoding  | 2022-05-17 |   695 | saluki  
>  |
> | rust-tabular | 2022-05-23 |   689 | jbtrystram  
>  |
> | rust-async-mutex | 2022-06-01 |   680 | decathorpe  
>  |
> | rust-awc | 2022-06-01 |   680 | decathorpe  
>  |
> | rust-infer   | 2022-06-15 |   666 | decathorpe  
>  |
> | rust-escape_string   | 2022-07-08 |   643 | dcavalca
>  |
> | rust-actix   

Re: network service removed in Fedora 40 without a Change proposal(?)

[Peter Robinson]

> > > Just for record, the removal of network-scripts was done because
> > > https://fedoraproject.org/wiki/Changes/dhclient_deprecation
> >
> > That page has Category:ChangePageIncomplete.
> > dhcp-client is present in F40, even though it has Provides:deprecated().
> >
> > > Network-scripts heavily depend on dhclient and there is no plan to rework
> > > them to use a different dhcp implementation.
> >
> > Ack. So it sounds like we could keep using both in F40
> > and prepare for removal in F41.
>
> There are various uses of the service that do not need a DHCP client,
> like the one I referred to in the bug report and FESCo ticket. Heck,
> you can kinda *assume* anyone still using the service at this point is
> doing something weird with it, not just a 'normal' "bring up this
> interface for me with DHCP" kinda thing.
>
> The removal of the network service should still be treated as its own
> significant operation, not a natural consequence of the removal of
> dhclient.

The System-V scripts are also deprecated since systemd v254 so
eventually they'll be going away too:

https://lists.freedesktop.org/archives/systemd-devel/2023-August/049349.html
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

[Peter Robinson]

> >>> I don't know how the assumption came up that F40 is only affected if
> >>> users opted in for testing, but that interpretation already ended up
> >>> in the Fedora Magazine and in the official linkedin post of Fedora (I
> >>> already asked to correct it).
> >>
> >> I believe that statement is correct, since none of the xz-5.6.x
> >> packages ever made it to F40 stable. The furthest they've got was
> >> updates-testing, which is not enabled in the official Beta releases.

The updates-testing repo isn't used in the Beta compose but it is
enabled by default so if someone took the beta and then applied
updates they would have automatically got the compromised package,
there's nuance there.

> >> However, if you installed F40 before Beta was released, then
> >> updates-testing is enabled and users may have installed the vulnerable
> >> package with a simple `sudo dnf upgrade`.

The same would be the case if they installed Beta.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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)

[Peter Robinson]

On Wed, 20 Mar 2024 at 09:05, Dmitry Belyavskiy  wrote:
>
> Hi!
>
> On Wed, Mar 20, 2024 at 9:50 AM Zbigniew Jędrzejewski-Szmek 
>  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.
>> >
>> > == Feedback ==
>> >
>> >
>> > == 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.
>>
>> Hi,
>>
>> In systemd, we recently added support for engines in various tools:
>> - systemd-{repart,measure} have --private-key-source=file|engine|provider
>>   (this is C code).
>
>
> As `provider` is a possible source, you will have to replace `engine` with a 
> particular provider.
> tpm2 provider is on the way to rawhide, and pkcs11 provider has already 
> landed, so TPMs and Yubikeys
>
>
>>
>> - ukify has --signing-engine.
>>   This is Python code that calls sbsign or pesign to do parts of the
>>   heavy lifting, and those binaries do not support providers. (At least
>>   the docs are silent on this, please correct it they do.)
>
>
> Have no idea but it means we have to change this code
>>
>>
>> So it seems we'd lose support for signing with keys stored on yubikeys
>> and tpms and other fancy approaches if the proposed change goes through.
>
>
> We don't lose this support but we still have to adjust configurations.
>
>>
>> --
>>
>> Also, what is the impact on:
>> - kernel module signing in the build system
>> - signing of shim, grub2, fwupd, and the kernel in the build system
>> - mokutil
>
>
> Does any kernel module rely on OpenSSL?

No but they use openssl for signing kernel modules, you can see
details in the spec [1], search openssl.

[1] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: GStreamer 1.24 Released With Vulkan H.264/H.265 Decode & Many Enhancements

[Peter Robinson]

> https://www.phoronix.com/news/GStreamer-1.24-Released

The Fedora gstreamer maintainers regularly and actively update and
maintain the GST stack, I'm not sure what a message with just a link
provides, did you have a particular query you wanted answered about
the release in the context of Fedora?

Peter
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

[Peter Robinson]

On Wed, 28 Feb 2024 at 13:38, Barry Scott  wrote:
>
>
>
> On 28 Feb 2024, at 10:24, Karel Zak  wrote:
>
> You can restore the original behavior by using:
>
># sysctl kernel.dmesg_restrict=0
>
> However, be aware of the security consequences ;-)
>
>
> Given I can get the same information from journalctl -k what is the 
> improvement?

I believe you need to be in the wheel group to get that info from journalctl
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Podman v5 breaking changes

[Peter Robinson]

On Mon, 26 Feb 2024 at 20:59, Gursewak Singh  wrote:
>
> In Fedora 40, Podman has undergone a major version upgrade to v5 [1], 
> introducing some breaking changes. Notably, CNI networking support has been 
> discontinued in favor of Netavark, and cgroups v1 support has been deprecated 
> in favor of cgroups v2.
>
> To know whether your nodes are affected, you can use podman info and look for 
> the cgroupVersion and networkBackend keys.
>
> If you're using cgroups v1, migrating to cgroups v2 is strongly recommended, 
> as a future Podman version will no longer support cgroups v1. Kernel 
> arguments can be adjusted to use cgroups v2 with rpm-ostree kargs [2].
>
> If you're using CNI networking, transitioning to Netavark requires running 
> podman system reset --force, leading to the deletion of images, containers, 
> and custom networks. Depending on your setup, it may be preferable to 
> reprovision the entire machine from the latest images to allow for Ignition 
> to bring up containerized applications from scratch.
>
> If you have any feedback or encounter issues related to the aforementioned 
> changes, please don't hesitate to participate in the upstream issue 
> discussion [3].

Sounds like a change of this size should have been a System Wide change.

> The Fedora CoreOS Team
>
> [1] https://fedoraproject.org/wiki/Changes/Podman5
> [2] 
> https://docs.fedoraproject.org/en-US/fedora-coreos/kernel-args/#_removing_existing_kernel_arguments
> [3] https://github.com/coreos/fedora-coreos-tracker/issues/1629
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: A note about riscv64 changes

[Peter Robinson]

On Wed, 14 Feb 2024 at 12:07, David Abdurachmanov
 wrote:
>
> On Wed, Feb 14, 2024 at 12:49 PM Dan Horák  wrote:
> >
> > On Wed, 14 Feb 2024 10:42:52 +
> > "Richard W.M. Jones"  wrote:
> >
> > > On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> > > > Hi Richard,
> > > >
> > > > > A quick note that you may be seeing pull requests for riscv64 changes
> > > > > against your packages, like these examples:
> > > > >
> > > > > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > > > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > > > > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> > > > >
> > > > > For many years we have been building Fedora for the RISC-V
> > > > > architecture on a separate build system at
> > > > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > > > > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > > > > (Most of this work was done by David Abdurachmanov, not me.)
> > > >
> > > > I'm very happy to see these start to land, let me know if you need any
> > > > assistance.
> > > >
> > > > > I'm trying to get as much of this stuff back into Fedora dist-git,
> > > > > although only (hopefully!) where it doesn't break ordinary builds and
> > > > > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > > > > free to make comments if you disagree with changes.
> > > > >
> > > > > Some time, with any luck soon, we will be creating a new Koji instance
> > > > > with FAS authentication which will allow anyone to optionally build
> > > > > their packages on RISC-V builders.  And then later in the year we may
> > > > > be in a position with the availability of new hardware to discuss
> > > > > adding RISC-V as a regular architecture.  (We're not there yet as
> > > > > current hardware is far too slow to force it on Fedora developers.)
> > > >
> > > > Will this instance run with koji-shadow to properly mirror the builds
> > > > with all the appropriate NVR dependencies to properly mirror Fedora
> > > > primary builds?
> > >
> > > TBD.
> > >
> > > Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
> > > something together with scripts, or get koji-shadow working.
> >
> > on the other hand, it's still tags, targets, buildroots in koji ...
> >
> > I should be able dig out some koji-shadow know-how out of my memory if
> > needed. Those were wonderful years :-)
>
> Many years ago I tried using koji-shadow, but I didn't like what it
> was doing. Cooking something custom seemed easier at that point. These

Yes, it was never a particularly nice process, but the advantage it
has was it made sure that a package build used the exact same packages
as on the mainline build so you could end up with identical builds and
that was very useful for bugs and build process problems.

> days we also have side tags, and thus some bootstrap operations happen
> there. Sadly those get removed relatively soonish after the tag gets
> merged. Sometimes before I get a chance to grab it. Otherwise I have a
> good picture of Fedora package land over so many years.
>
> Our "dist-git overlay" is relatively small these days. Should be <300
> packages, and majority of it was used to bump NVR for rebuilds.
>
> Cheers,
> david
>
> >
> > Dan
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 note about riscv64 changes

[Peter Robinson]

Hi Richard,

> A quick note that you may be seeing pull requests for riscv64 changes
> against your packages, like these examples:
>
> https://src.fedoraproject.org/rpms/ghc/pull-request/7
> https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> https://src.fedoraproject.org/rpms/gdal/pull-request/21
>
> For many years we have been building Fedora for the RISC-V
> architecture on a separate build system at
> http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> against dist-git in http://fedora.riscv.rocks:3000/rpms/
> (Most of this work was done by David Abdurachmanov, not me.)

I'm very happy to see these start to land, let me know if you need any
assistance.

> I'm trying to get as much of this stuff back into Fedora dist-git,
> although only (hopefully!) where it doesn't break ordinary builds and
> isn't intrusive.  Obviously I may get this wrong sometimes so feel
> free to make comments if you disagree with changes.
>
> Some time, with any luck soon, we will be creating a new Koji instance
> with FAS authentication which will allow anyone to optionally build
> their packages on RISC-V builders.  And then later in the year we may
> be in a position with the availability of new hardware to discuss
> adding RISC-V as a regular architecture.  (We're not there yet as
> current hardware is far too slow to force it on Fedora developers.)

Will this instance run with koji-shadow to properly mirror the builds
with all the appropriate NVR dependencies to properly mirror Fedora
primary builds?

Peter
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: do we need CONFIG_UPROBES=y in our kernels?

[Peter Robinson]

> > In a german developer blog article was the topic raised, that with
> > uprobes enabled, userland apps can i.e. circumvent tls security(and
> > other protections),
> > by telling the kernel to probe the function calls with the uprobes api.
> > As this enables i.e. the hosting system of a vm or container, to track
> > activity inside the container, trust is lost i.e. from customer to
> > hoster. To be fair, you need to be root on the host to do this, but as
> > it "wasn't possible before", and it is "now" ( out in a greater public
> > ), it tends to create trust issues, just for being there*.
> >
> > As this only works with uprobes enabled and has no use case besides a
> > developer debugging apps, the question is:
> >
> > Do we need this for all others out there enabled by default?
>
> Both systemtap and bpftrace can use uprobes.  Those capabilities have
> been important from time to time in my job.  That does not mean that
> my ability to do my job should outweigh security concerns, of course,
> but I think some effort should be made to find out if use of uprobes
> via systemtap and bpftrace is common amongst Fedora users.

And unfortunately it's not buildable as a module, I suspect there's
some form of capabilities around it, I'm not sure if that can be
tightened.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: List of long term FTBFS packages to be retired in February

[Peter Robinson]

On Wed, 24 Jan 2024 at 16:39, Miro Hrončok  wrote:
>
> Dear maintainers.
>
> Based on the current fail to build from source policy, the following packages
> should be retired from Fedora 40 approximately one week before branching.
>
> 5 weekly reminders are required, hence the retirement will happen
> approximately in 5 weeks, i.e. around 2024-02-28.
> Since this is unfortunately after the branching,
> packages will be retired on rawhide and f40.
>
> I apologize for starting this process a bit later than required again.
> Unfortunately, I had other work obligations.
> Volunteers to take over this are always welcome.
>
> Policy:
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
> The packages in rawhide were not successfully built at least since Fedora 37.
>
> This report is based on dist tags.
>
> Packages collected via:
> https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
>
> If you see a package that was built, please let me know.
> If you see a package that should be exempted from the process,
> please let me know and we can work together to get a FESCo approval for that.
>
> If you see a package that can be rebuilt, please do so.
>
>  Package  (co)maintainers
> 
> cl-asdf green
> erlang-jose bowlofeggs, erlang-maint-sig, jcline, 
> peter
> fwtsbenzea

I worked around the build failure for ftbfs and updated this package,
it doesn't like parallel builds, there's upstream reports but it
appears not to be getting attention from the maintainers even though
they're doing newer releases.

> ghdlsailer
> git-secrets  keesdejong
> golang-github-acme-lego  eclipseo, go-sig
> golang-github-eclesh-welford abulimov, dcavalca, go-sig
> golang-github-gatherstars-com-jwzeclipseo, go-sig
> golang-github-genuinetools-pkg   eclipseo, go-sig
> golang-github-gobs-prettyeclipseo, go-sig
> golang-github-google-gopacketgo-sig, salimma
> golang-github-jhillyerd-enmime   eclipseo, go-sig
> golang-github-pierrre-compareeclipseo, go-sig
> golang-github-smartystreets-goconvey alexsaezm, go-sig, jchaloup
> golang-gopkg-square-jose-2   alexsaezm, go-sig
> golang-gvisoreclipseo, elmarco, go-sig
> golang-opentelemetry-otel-0.20   alexsaezm, go-sig
> golang-sigs-k8s-kustomizedcavalca, go-sig
> golang-vitesseclipseo, go-sig
> infinipath-psm   honli
> j4-dmenu-desktop ibotty
> jackson-dataformats-binary   mbooth
> jackson-dataformats-text mbooth
> java-1.8.0-openjdk-aarch32   akasko, jvanek
> jreenrdieter
> kdevelop-pg-qt   jgrulich, kde-sig, rdieter, than
> libdeltacloudclalance
> libva-v4l2-request   kwizart, rathann
> lmms thm
> lxc  hguemar, sagarun, thm
> mingw-clucenegreghellings
> mingw-cppunitkwizart
> mingw-dirac  kwizart
> mingw-speexdsp   janisozaur
> nbd-runner   xiubli
> nodejs-generic-pool  patches, piotrp
> ofononjha, thunderbirdtr
> openni-primesensecottsay, jkastner, rmattes
> pcmciautils  harald
> pesign-test-app  javierm, nfrayer, pjones, rwood
> pthsem   ixs
> rust-drg jbtrystram, rust-sig
> telepathy-gabble aperezbios
> yaksazbyszek
>
> The following packages require above mentioned packages:
> Depending on: cl-asdf (5)
> common-lisp-controller (maintained by: green)
> common-lisp-controller-7.4-26.fc39.noarch requires cl-asdf
>
> emacs-slime (maintained by: bkreuter, salimma)
> emacs-slime-2:2.28-2.fc39.noarch requires 
> common-lisp-controller
> emacs-slime-2:2.28-2.fc39.src requires common-lisp-controller
>
> sbcl (maintained by: green, rdieter)
> sbcl-2.3.11-1.fc40.src requires common-lisp-controller
> sbcl-2.3.11-1.fc40.x86_64 requires common-lisp-controller
>
> maxima (maintained by: jamatos, rdieter)
> maxima-5.45.1-6.fc40.src requires sbcl
>
> wxMaxima (maintained by: jamatos, rdieter)
> wxMaxima-20.12.1-10.fc39.x86_64 requires maxima
>
> Depending on: erlang-jose (1)
> erlang-p1_acme (maintained by: bowlofeggs, erlang-maint-sig, peter)
>

Re: rawhide aarch64 Thunderbird FTBFS "internal compiler error: Segmentation fault"

[Peter Robinson]

Hi,

> Tried twice, same error, aarch64 build bails out with

There's at least one known ICE on aarch64 for gcc-14 so I suggest
checking if it looks related.

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

> | 34:29.97 *** WARNING *** there are active plugins, do not report this as a 
> bug unless you can reproduce it without enabling any plugins.
> | 34:29.97 Event| Plugins
> | 34:29.97 PLUGIN_FINISH_UNIT   | annobin: Generate final 
> annotations
> | 34:29.97 PLUGIN_START_UNIT| annobin: Generate global 
> annotations
> | 34:29.97 PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
> annotations
> | 34:29.97 PLUGIN_ALL_PASSES_END| annobin: Register per-function 
> end symbols
> | 34:29.97 during RTL pass: split1
> | 34:29.97 In file included from 
> /builddir/build/BUILD/thunderbird-115.7.0/gfx/skia/skia/src/core/SkOpts.cpp:43:
> | 34:29.97 
> /builddir/build/BUILD/thunderbird-115.7.0/gfx/skia/skia/src/opts/SkBlitMask_opts.h:
>  In function ‘void neon::blit_mask_d32_a8(SkPMColor*, size_t, const SkAlpha*, 
> size_t, SkColor, int, int)’:
> | 34:29.97 
> /builddir/build/BUILD/thunderbird-115.7.0/gfx/skia/skia/src/opts/SkBlitMask_opts.h:234:1:
>  internal compiler error: Segmentation fault
> | 34:29.97   234 | }
> | 34:29.97   | ^
> | 34:30.04 Please submit a full bug report, with preprocessed source (by 
> using -freport-bug).
> | 34:30.04 See  for instructions.
>
> I'm not going to jump through hoops there.
> All other platforms finished the build fine, f39 and f38 builds
> completed also for aarch64.
>
> See https://kojipkgs.fedoraproject.org//work/tasks/9052/112279052/build.log of
> https://koji.fedoraproject.org/koji/taskinfo?taskID=112279052 of
> https://koji.fedoraproject.org/koji/taskinfo?taskID=112278913
>
>   Eike
>
> --
> GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 
> 2D3A
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can't update from fedora 39 to rawhide

[Peter Robinson]

On Wed, 24 Jan 2024 at 13:04, Guinevere Larsen  wrote:
>
> Hi Fedora list!
>
> I'm trying to upgrade a VM from fedora 39 to rawhide but running dnf
> system-upgrade download --releasever=rawhide fails. the offending
> package seems to be "grubby-8.40-73.fc39", which conflicts with
> sdubby-1.0-5.fc40. Is this a known issue? Does anyone know a workaround?
> If not, where do I properly report this?

You could probably explicitly exclude sdubby.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Arm Minimal Image OS-Build (Self-Contained)

[Peter Robinson]

On Thu, 18 Jan 2024 at 14:39, Neal Gompa  wrote:
>
> On Thu, Jan 18, 2024 at 9:30 AM Aoife Moloney  wrote:
> >
> > Wiki -> https://fedoraproject.org/wiki/Changes/ArmMinimalImageOSBuild
> >
> > 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 ==
> > Build the Arm minimal image to be built using osbuild.
> >
> > == Owner ==
> > * Name: [[User:pbrobinson| Peter Robinson]]
> >
> > * Email: 
> >
> >
> > == Detailed Description ==
> > The Fedora Arm Minimal image is widely used as a base for various
> > usecases from low level board bring up right through to the basis of
> > other images. Over time the existing ImageFactory build process has
> > stagnated limiting our ability to enhance this image. The osbuild team
> > have worked with the Arm SIG to enable a number of enhancements around
> > things like Arm SystemReady and other such functionality to improve
> > this image creation process and to make it easier to use these images
> > with a much wider range of Arm devices making it easier to bring up
> > new types of Arm device in Fedora. In the future we are planning
> > further enhancements to ensure it's easy for developers and users to
> > make use of the Fedora within the Arm ecosystem.
> >
> > == Feedback ==
> > 
> >
> > == Benefit to Fedora ==
> > The Fedora arm Minimal Image currently requires a number of changes
> > and hacks to be used on specific devices or SoCs, the move to osbuild
> > will reduce or entirely eliminate these hacks right away with further
> > enhancements coming in the future.
> >
> > == Scope ==
> > * Proposal owners:
> > The proposal owners will:
> > ** Enable the creation of Minimal image using osbuild in pungi
> > ** Test the available artifacts
> >
> > * Other developers:
> >
> > * Release engineering: [https://pagure.io/releng/issues #Releng issue
> > number] 
> > Changes to the pungi config to use osbuild for minimal image will be
> > submitted as a PR by feature owners.
> >
> > * Policies and guidelines: N/A (not needed for this Change)
> >
> > * Trademark approval: N/A (not needed for this Change)
> >
> > * Alignment with Community Initiatives:
> >
> > == Upgrade/compatibility impact ==
> > No upgrade impact. Only for new users.
> >
> > == How To Test ==
> > There will be a new Minimal Image, it will be testable in the same way
> > as the old image. Test various SoCs with arm-image-installer to ensure
> > devices boot and run as expected.
> >
> > == User Experience ==
> > There should be no change to the user experience for existing users.
> > We will enable the wider use of
> >
> > == Dependencies ==
> > All changes are already in osbuild but we will work with the osbuild
> > team if any issues arise.
> >
> > == Contingency Plan ==
> > The contingency plan is to build the Arm minimal image in the same way
> > we currently do.
> >
> > == Documentation ==
> > There should be no changes required to documentation for existing
> > users, docs will be updated for specific devices where enhancements
> > have been made.
> >
> > == Release Notes ==
> > TBD.
>
>
> Is there a repository where the blueprint for the minimal image will
> be stored? Otherwise there’s not exactly anything Fedora side that
> anyone can actually observe, extend, or maintain.

At the moment no, because the minimal image hasn’t changed in years,
but we will be introducing that for the other images in a future
release. This is currently focused on Minimal just to get the full
process in place and issues ironed out.

It's available in osbuild so people can do their own blueprints and
extend and maintain if they want their own custom version.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Where to add new ssh key to my FAS account?

[Peter Robinson]

On Wed, 10 Jan 2024 at 11:55, Barry Scott  wrote:
>
> I have been changing from SSH RSA key to using ed25519 based keys.
> I cannot recall, or track down docs on where to upload my new ssh key to
> for my FAS account.
>
> Can you point me in the right direction please?

Login to https://accounts.fedoraproject.org/ and it should be on the
right side of your profile page under the avatar roughly.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: ARM PAC on koji vs COPR

[Peter Robinson]

On Wed, Jan 3, 2024 at 9:08 PM Stephen Smoogen  wrote:
>
>
>
> On Wed, 3 Jan 2024 at 15:01, Miroslav Suchý  wrote:
>>
>> Dne 03. 01. 24 v 14:46 Jarek Prokop napsal(a):
>>
>> 4. Why do koji and copr have CPU flag set that differs so much? Is our koji 
>> infra OK?
>>
>> For convenience of readers:
>>
>> Koji:
>> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
>> asimdrdm lrcpc dcpop asimddp ssbs
>>
>> Copr:
>> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
>> asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit 
>> uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng
>>
>> In Copr we use c7g.xlarge type from AWS as ARM builders. So if you spawn 
>> this machine in AWS you should be able to reproduce.
>
>
> My information may be old, but I believe the Fedora systems will be mostly 
> virtual machines running on Ampere systems from 2-3 years ago. I think there 
> are a couple of other systems which may be in usage also. The AWS systems are 
> a newer generation and different chipset. Another issue is that ARM like 
> Intel systems may be of the same generation but have different flags.
>

Ultimately builds should be using distro specified flags, not flags
based on detected build system features because that will lead to
builds that can't run on all supported platforms of a particular
architecture.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: RISC-V ABI issue with ULEB128

[Peter Robinson]

On Tue, Jan 2, 2024 at 5:15 PM David Abdurachmanov
 wrote:
>
> On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson  wrote:
> >
> > On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov
> >  wrote:
> > >
> > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer  wrote:
> > > >
> > > > * David Abdurachmanov:
> > > >
> > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones  
> > > > > wrote:
> > > > >>
> > > > >>
> > > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to
> > > > >> raise it here to get the attention of the Fedora toolchain team ...
> > > > >>
> > > > >> Here's the bug:
> > > > >>
> > > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179
> > > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 
> > > > >> objects
> > > > >>
> > > > >> It refers to this change in binutils 2.41:
> > > > >>
> > > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > > > >>
> > > > >> As far as I understand the issue (which is not too far) this mainly
> > > > >> affects shipped *.o and *.a files (ie. static libraries and similar)
> > > > >> which were compiled with binutils < 2.41, which either won't link
> > > > >> correctly or will give a linker error when using GNU ld from 
> > > > >> binutils 2.41.
> > > > >
> > > > > Correction. This is broken in <= 2.41 (incl. the current stable
> > > > > binutils release).
> > > > >
> > > > >>
> > > > >> Unclear if it also affects *.so files (which would be a much more
> > > > >> serious ABI break), and also if it affects most binaries or just a
> > > > >> few.  I initially thought this only affected programs using 128 bit
> > > > >> ints, so didn't think it was too important, but after reading the
> > > > >> commit I'm not sure that is really true.
> > > > >
> > > > > Nelson Chu committed (5 days ago) a change:
> > > > >
> > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > > > >
> > > > > This will accept whatever is produced by <= 2.41 and the final binary
> > > > > will be correct. There is also a new ld flag (--check-uleb128) which
> > > > > can produce a warning if it detects an issue.
> > > > >
> > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen
> > > > > before I start mass rebuilding, and that should fix this.
> > > >
> > > > Cc:ing Nick and Siddhesh for awareness.
> > > >
> > > > The current plan is to use binutils 2.41 for the mass rebuild.
> > >
> > > In Fedora/RISCV we typically end up using the latest available
> > > binutils. We are slightly different from upstream/normal Fedora.
> >
> > Which is fine when you're an out of mainline architecture but these
> > sorts of things need to be resolved well and truly before any
> > incorporation can happen.
>
> 100% true. We have plenty of stuff that isn't yet submitted to the
> official dist-git.

Is that delta easily viewable somewhere?

> I have been considering not going for 2.42 for Fedora 40, but we will
> do this again one more time (hopefully it's the last time, but you
> never know).
>
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: RISC-V ABI issue with ULEB128

[Peter Robinson]

On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov
 wrote:
>
> On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer  wrote:
> >
> > * David Abdurachmanov:
> >
> > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones  
> > > wrote:
> > >>
> > >>
> > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to
> > >> raise it here to get the attention of the Fedora toolchain team ...
> > >>
> > >> Here's the bug:
> > >>
> > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179
> > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
> > >>
> > >> It refers to this change in binutils 2.41:
> > >>
> > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > >>
> > >> As far as I understand the issue (which is not too far) this mainly
> > >> affects shipped *.o and *.a files (ie. static libraries and similar)
> > >> which were compiled with binutils < 2.41, which either won't link
> > >> correctly or will give a linker error when using GNU ld from binutils 
> > >> 2.41.
> > >
> > > Correction. This is broken in <= 2.41 (incl. the current stable
> > > binutils release).
> > >
> > >>
> > >> Unclear if it also affects *.so files (which would be a much more
> > >> serious ABI break), and also if it affects most binaries or just a
> > >> few.  I initially thought this only affected programs using 128 bit
> > >> ints, so didn't think it was too important, but after reading the
> > >> commit I'm not sure that is really true.
> > >
> > > Nelson Chu committed (5 days ago) a change:
> > >
> > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > >
> > > This will accept whatever is produced by <= 2.41 and the final binary
> > > will be correct. There is also a new ld flag (--check-uleb128) which
> > > can produce a warning if it detects an issue.
> > >
> > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen
> > > before I start mass rebuilding, and that should fix this.
> >
> > Cc:ing Nick and Siddhesh for awareness.
> >
> > The current plan is to use binutils 2.41 for the mass rebuild.
>
> In Fedora/RISCV we typically end up using the latest available
> binutils. We are slightly different from upstream/normal Fedora.

Which is fine when you're an out of mainline architecture but these
sorts of things need to be resolved well and truly before any
incorporation can happen.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Building the boot.iso with dnf5

[Peter Robinson]

On Fri, Dec 8, 2023 at 7:35 PM Brian C. Lane  wrote:
>
> With the approval of
> https://fedoraproject.org/wiki/Changes/BuildWithDNF5 it seems like a
> good time to move Lorax over to using dnf5 to create the boot.iso. My
> current plan is to merge my dnf5 branch do a new build on Monday
> (12/11). You can preview this here:
> https://github.com/weldr/lorax/pull/1319
>
> (the test is currently failing due to an issue with the rawhide
> container image, I've testing it locally and via a temporary switch to
> using fedora:39 container).
>
> The resulting image is the same content and size as the current rawhide
> boot.iso, so that's good :)
>
> To be clear, this change uses libdnf5 to *build* the boot.iso but it
> does not have dnf5 on the iso or the systems installed using it.

It was my understanding the switch to dnf5 was delayed until F-41 so I
don't think we should be using it for this either until it's the
default in Fedora as well.

Peter
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 deprecation/removal of Initial Setup from Fedora

[Peter Robinson]

On Thu, Nov 23, 2023 at 12:51 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Nov 22, 2023 at 01:53:14PM +0100, Gerd Hoffmann wrote:
> > On Tue, Nov 21, 2023 at 08:07:06AM -0800, Davide Cavalca wrote:
> > > On 2023-11-21 04:34, Jiri Konecny wrote:
> > > > Is Anaconda Initial Setup important for your project or workflow? What
> > > > functionality is absolutely necessary for you? Do you use the text
> > > > mode or the graphical mode? Are you aware of any alternatives? Is
> > > > there anything that would prevent you from migrating to one of the
> > > > proposed alternatives? Also please feel free to share this mail to any
> > > > relevant groups.
> > >
> > > The Fedora Asahi Remix uses initial-setup (in text mode) for our Server 
> > > and
> > > Minimal variants.
> >
> > I think this is used by *all* server images.  It offers to set the root
> > password and add users, so without that you simply can't login ...
>
> systemd-firstboot can set the root user password, but it cannot create
> other users. But maybe we should extend it allow that. We recently had
> a discussion about adding support for creating "normal" users from
> systemd-sysusers, and the conclusion was that we can add a basic mode
> where /etc/skel is copied and the user is written to file databases.
> If people think this would be useful, I could that this idea upstream.

There's other pieces that initial-setup takes care of as well, it
gives the option when creating a user to add them as an "admin" AKA
added to the wheel group and I also believe if only a root password is
set and no user created it may (it's been a while since I've tested)
add the ability for root to ssh in to the host as without a user you
can't access the machine remotely.

Peter
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 deprecation/removal of Initial Setup from Fedora

[Peter Robinson]

On Sat, Nov 25, 2023 at 12:21 AM Leslie Satenstein via devel
 wrote:
>
>
>
> I am a devout anaconda bigot, and  I exclusively use the Everything.iso with 
> it.
> Of course, I use it via terminal mode.
>
> A feature I relish in anaconda, is the ability to manage disks and 
> partitions.(using the right most radio button)
> My system has 2 SSD and 6 disks, and with anaconda, I select all of them and 
> then
> use the mentioned disk management to build the target system along with a 
> completed /etc/fstab.

This is run during install and is a different usecase to initial-setup
which doesn't offer disk configuration options.

> If I was looking to improve anaconda, I would add a one or two line 
> description against each group.
> the right most application selection column.
>
> As well, an option to offer a way to respond to what "Gerd Hoffmann" was 
> posting,
>
> Please do not add another tool, just embellish anaconda to include the extra 
> functionality.
>
>
>
>
> Leslie Satenstein
>
>
>
> On Friday, November 24, 2023 at 06:18:47 p.m. EST, Adam Williamson 
>  wrote:
>
>
> On Fri, 2023-11-24 at 13:38 +0100, Jiri Konecny wrote:
> > Hi,
> >
> > I wonder, I thought that the server images are usually using Anaconda to
> > create a user during installation. Am I missing something?
>
> No, I think you're right there. initial-setup is not part of the
> anaconda-deployed Server package set. anaconda - as it does for all
> other spins/editions except Workstation - requires you to create a root
> password or admin user, so you can always log in.
>
> I think if initial-setup was included in the package set, it would run
> on boot if you didn't *both* set the root password *and* create a user
> (as it does on spins where it is installed, e.g. KDE), but it isn't.
>
> I tested this with a Server DVD image I had lying around; doing an
> install with only root password (no user created) didn't run initial-
> setup on boot, and rpm shows initial-setup not installed.
>
> However, as dgilmore noted, the Server ARM disk images certainly do
> rely on initial-setup.
>
> >
> > Best Regards,
> > Jirka
> >
> > Dne 22. 11. 23 v 13:53 Gerd Hoffmann napsal(a):
> > > On Tue, Nov 21, 2023 at 08:07:06AM -0800, Davide Cavalca wrote:
> > > > On 2023-11-21 04:34, Jiri Konecny wrote:
> > > > > Is Anaconda Initial Setup important for your project or workflow? What
> > > > > functionality is absolutely necessary for you? Do you use the text
> > > > > mode or the graphical mode? Are you aware of any alternatives? Is
> > > > > there anything that would prevent you from migrating to one of the
> > > > > proposed alternatives? Also please feel free to share this mail to any
> > > > > relevant groups.
> > > > The Fedora Asahi Remix uses initial-setup (in text mode) for our Server 
> > > > and
> > > > Minimal variants.
> > > I think this is used by *all* server images.  It offers to set the root
> > > password and add users, so without that you simply can't login ...
> > >
> > > take care,
> > >Gerd
> > > --
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > Do not reply to spam, report it: 
> > > https://pagure.io/fedora-infrastructure/new_issue
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 

Re: Possible deprecation/removal of Initial Setup from Fedora

[Peter Robinson]

On Fri, Nov 24, 2023 at 12:39 PM Jiri Konecny  wrote:
>
> Hi,
>
> I wonder, I thought that the server images are usually using Anaconda to
> create a user during installation. Am I missing something?

For example there's cases where a vendor ships the OS pre-installed on
the device and they won't know what the user will want here, often you
also need to set the language/keyboard as well before creating
users/setting passwords.

I believe also in the RHEL case it has the ability for the user to
accept an agreement before they can create users/set passwords etc and
I'm not sure how that would integrate into the systemd variant.

> Best Regards,
> Jirka
>
> Dne 22. 11. 23 v 13:53 Gerd Hoffmann napsal(a):
> > On Tue, Nov 21, 2023 at 08:07:06AM -0800, Davide Cavalca wrote:
> >> On 2023-11-21 04:34, Jiri Konecny wrote:
> >>> Is Anaconda Initial Setup important for your project or workflow? What
> >>> functionality is absolutely necessary for you? Do you use the text
> >>> mode or the graphical mode? Are you aware of any alternatives? Is
> >>> there anything that would prevent you from migrating to one of the
> >>> proposed alternatives? Also please feel free to share this mail to any
> >>> relevant groups.
> >> The Fedora Asahi Remix uses initial-setup (in text mode) for our Server and
> >> Minimal variants.
> > I think this is used by *all* server images.  It offers to set the root
> > password and add users, so without that you simply can't login ...
> >
> > take care,
> >Gerd
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Swift on aarch64 and 39 and Rawhide...suggestions?

[Peter Robinson]

On Mon, Nov 6, 2023 at 2:31 AM Ron Olson  wrote:
>
> Hey all-
>
> I’m still having a difficult time trying to figure out what to do about this 
> issue I’m having. Swift 5.9 was released awhile ago and I’ve been able to 
> build it for x864_64 on all versions of Fedora (Rawhide, 39, 38, 37) just 
> fine. On aarch64 (the only other architecture supported), it fails to build 
> for 39 and Rawhide, where the Swift compiler crashes with an LLVM stacktrace 
> while in the process of building the rest of the toolchain (in other words, 
> it’s not that Swift builds and packages correctly and then doesn’t work when 
> installed, it crashes during one of the compilation phases it uses to build 
> the entire toolchain).
>
> I’ve been trying to troubleshoot this problem and have it seems that the 
> issue may lay with ld-linux-aarch.so.1:
>
> [root@6ba0f8c47e54 swift-source]# lldb 
> ./build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend
> (lldb) target create 
> "./build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend"
> Current executable set to 
> '/root/rpmbuild/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend'
>  (aarch64).
> (lldb) ru
> Process 142 launched: 
> '/root/rpmbuild/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend'
>  (aarch64)
> Process 142 stopped
>
> thread #1, name = 'swift-frontend', stop reason = exec
> frame #0: 0xf7fd84c0 ld-linux-aarch64.so.1`_start at dl-start.S:22
>
> That’s as far as I’ve gotten. I not sure what the next move should be; 
> troubleshooting core libraries is not something I’ve done before and have no 
> idea where to start.
>
> Any help or suggestions would be greatly appreciated. I’ve been extremely 
> busy on non-packaging things and honestly don’t really have the time to dig 
> into this.

Maybe start with a bug against glibc with the information you
currently have and a means to reproduce it and the toolchains team may
have some pointers to where the problem lies.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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-2023-ed0c57b4ba — unspecified update for libtirpc — Fedora Updates System

[Peter Robinson]

On Wed, Oct 25, 2023 at 5:04 PM Steve Dickson  wrote:
>
> Hello,
>
> This update failed [1] due to a system timeout [2]
> not a test failure... Is there some way to override
> or wave the failure.

There should be a waive option on the right panel for the update in
bodhi, and you can also retest from there too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: status openssl1.1

[Peter Robinson]

On Mon, Oct 16, 2023 at 10:05 AM Dmitry Belyavskiy  wrote:
>
> On Mon, Oct 16, 2023 at 10:21 AM Petr Pisar  wrote:
> >
> > V Mon, Oct 16, 2023 at 08:55:12AM +0200, josef radinger via devel napsal(a):
> > > Hi
> > >
> > > openssl1.1 reached EOS on recently (11th September 2023 I assume)
> > > https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
> > >
> > > according to
> > > https://www.openssl.org/source/:
> > > ...
> > > The previous LTS version (the 1.1.1 series) is also available but has
> > > recently gone out of support.
> > > ...
> > >
> > > paid extended support for 1.1.1 would be available, but is maybe not the 
> > > way
> > > to go for fedora.
> > >
> > > we have
> > > https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat#Upgrade/compatibility_impact
> > > with no changes since 2022
> > > and a closed tracker bug at
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2108694
> > >
> > > maybe we should start deprecating that package?
> > >
> > The package is already deprecated:
> >
> > # dnf5 repoquery --provides openssl1.1 | grep deprecated
> > deprecated()
> >
> > Maybe you wanted to say start removing? I rough estimation of an impact of 
> > the
> > removal are these 3 components:
> >
> > gloo-0.5.0^git20230824.01a0c81-6.fc40.src.rpm
> > opensmtpd-6.8.0p2-12.fc39.src.rpm
> > python3.6-3.6.15-20.fc39.src.rpm
>
> I'm afraid it's too late for removing the compat package in F40. If
> not, I can raise the change proposal, otherwise it will be delayed
> until F41 starts

Why is it too late for F-40? Do you mean F-39?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Intention to tighten RPM crypto-policy back

[Peter Robinson]

On Wed, Sep 27, 2023 at 11:04 AM Alexander Sosedkin
 wrote:
>
> On Tue, Sep 26, 2023 at 7:47 PM Peter Robinson  wrote:
> >
> > On Tue, Sep 19, 2023 at 10:20 AM Alexander Sosedkin
> >  wrote:
> > >
> > > Hello,
> > >
> > > 6 months ago, there's been a F38 blocker: 
> > > https://pagure.io/fesco/issue/2960
> > > Long story short:
> > > RPM has moved to sequoia,
> > > sequoia has started respecting crypto-policies,
> > > Google repos have been signed with a 1024-bit DSA key,
> > > Google Chrome was not installable => F38 blocker.
> > > Back at the time, it's been hastily "resolved"
> > > by relaxing RPM security through crypto-policies
> > > just enough to tolerate that Google signature:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2170878
> > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129
> > >
> > > Since then it has been brought to my attention that
> > > Google has now added a 4096 bit RSA key
> > > https://www.google.com/linuxrepositories/
> > > (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796)
> > >
> > > Because of that, I'd like to revert that RPM policy relaxation
> > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5
> > > in (f39) rawhide and align RPM security with the rest of the policy.
> > >
> > > Thoughts / feedback?
> >
> > I think it should be done as a system wide change so it can have the
> > appropriate review but it seems we're better off than we were.
>
> System-wide or self-contained?

System wide as it potentially affects ability to install 3rd party software.

> I'm not altering the system-wide default,
> I'm removing the exception that was limited to rpm/dnf in scope
> to bring them in line with system-wide default;
> but rpm/dnf are kinda important.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Peter Robinson]

On Wed, Sep 27, 2023 at 6:24 AM Remi Collet  wrote:
>
> Le 26/09/2023 à 19:32, Carlos O'Donell a écrit :
>
> >> In version 8.3 (F40) we'll includes the UTC definition
> >> in our patch to use system tzdata, UTC being use
> >> as the fallback value.
> >
> > I'm curious; what does this patch look like?
>
> (trivial) patch to our system tzdata patch attached
>
> In short, if file is missing use bundled content
>
> Full patch for PHP 8.3:
> https://git.remirepo.net/cgit/rpms/scl-php83/php.git/plain/php-8.3.0-systzdata-v24.patch
>
> Remi
>
>
> P.S. IMHO, allowing removal of tzdata for PHP doesn't make any sense
> as most app will fail badly (runtime exception) because of missing
> TZ when upstream use a bundle copy of the full database, so this can
> never happen, so this will create another RPM specific problem

Can't you just explicitly require tzdata?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Intention to tighten RPM crypto-policy back

[Peter Robinson]

On Tue, Sep 19, 2023 at 10:20 AM Alexander Sosedkin
 wrote:
>
> Hello,
>
> 6 months ago, there's been a F38 blocker: https://pagure.io/fesco/issue/2960
> Long story short:
> RPM has moved to sequoia,
> sequoia has started respecting crypto-policies,
> Google repos have been signed with a 1024-bit DSA key,
> Google Chrome was not installable => F38 blocker.
> Back at the time, it's been hastily "resolved"
> by relaxing RPM security through crypto-policies
> just enough to tolerate that Google signature:
> https://bugzilla.redhat.com/show_bug.cgi?id=2170878
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129
>
> Since then it has been brought to my attention that
> Google has now added a 4096 bit RSA key
> https://www.google.com/linuxrepositories/
> (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796)
>
> Because of that, I'd like to revert that RPM policy relaxation
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5
> in (f39) rawhide and align RPM security with the rest of the policy.
>
> Thoughts / feedback?

I think it should be done as a system wide change so it can have the
appropriate review but it seems we're better off than we were.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Intention to tighten RPM crypto-policy back

[Peter Robinson]

On Tue, Sep 26, 2023 at 6:23 PM Alexander Sosedkin  wrote:
>
> On Tue, Sep 19, 2023 at 7:47 PM Kevin Fenzi  wrote:
> >
> > On Tue, Sep 19, 2023 at 11:19:18AM +0200, Alexander Sosedkin wrote:
> > > Hello,
> > >
> > > 6 months ago, there's been a F38 blocker: 
> > > https://pagure.io/fesco/issue/2960
> > > Long story short:
> > > RPM has moved to sequoia,
> > > sequoia has started respecting crypto-policies,
> > > Google repos have been signed with a 1024-bit DSA key,
> > > Google Chrome was not installable => F38 blocker.
> > > Back at the time, it's been hastily "resolved"
> > > by relaxing RPM security through crypto-policies
> > > just enough to tolerate that Google signature:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2170878
> > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129
> > >
> > > Since then it has been brought to my attention that
> > > Google has now added a 4096 bit RSA key
> > > https://www.google.com/linuxrepositories/
> > > (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796)
> > >
> > > Because of that, I'd like to revert that RPM policy relaxation
> > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5
> > > in (f39) rawhide and align RPM security with the rest of the policy.
> > >
> > > Thoughts / feedback?
> >
> > It might be good to go through all the ones that were hit by this (it
> > wasn't just chrome) and indicate if they are now fixed.
> > You can see a partial list in the common bug:
> >
> > https://discussion.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/70498
> >
> > and in the discussion off it.
>
> Whoa, that's too many, I suspect misreporting.
> I seriously doubt they were all really using DSA-1024 and switched over.
> But if that really was the case --- great job to all of them.
>
> > The list from there:
> > Google Chrome (RPM signature rejected, repo key rejected)
> Repo has added RSA-4096, RPM is signed with SHA-512, installs
>
> > Microsoft Edge (repo key rejected)
> RSA-2048, RPM is signed with SHA-256, installs
>
> > Dropbox (repo key rejected)
> RSA-2048, RPM is signed with SHA-512
>
> > Skype (repo key rejected)
> RSA-2048 / SHA-512
>
> > Visual Studio Code (repo key rejected)
> RSA-2048 / SHA-256 (let's name a package `code`. outstanding move)
>
> > Sublime Text (repo key rejected)
> RSA-4096 / SHA-256
>
> > Microsoft Teams (repo key rejected)
> RSA-2048, but https://packages.microsoft.com/yumrepos/ms-teams/repodata
> looks barren

I believe MS has end of life the dedicated Linux Teams app and
possibly viewer and only support the web app now.

> > TeamViewer (repo key rejected)
> RSA-4096 / SHA-256
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package fails to build for aarch64, works for x86_64

[Peter Robinson]

On Thu, Sep 21, 2023 at 3:25 PM Ron Olson  wrote:
>
> Hey all-
>
> I was trying to submit the released version of Swift 5.9 to Fedora but I get 
> a build failure only for the aarch64 platform for Rawhide and F39:
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2291751 (F39)
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2291750 (Rawhide/F40)
>
> While it compiled for both fine on F38:
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2291752
>
> What is the rule/advice around a situation like this insofar as should I 
> release it for the current platforms (F38,F37,EPEL9) and try to figure out 
> what’s going on with the aarch64 build, or should it be an all-or-nothing, 
> release to every platform or none at all? I’d personally lean towards trying 
> to provide the new shiny where possible, but I can see making a case for 
> holding off due to F39 coming down the road. Complicating all this is trying 
> to gauge interest in there being an aarch64 version of Swift for Fedora.
>
> Could I, possibly, temporarily drop support for aarch64 in the spec file for 
> 5.9 so all versions of x86_64 can get it, and then re-enable it for if/when I 
> figure out what’s going on with the aarch64 version?
>
> The funny thing is that Apple has already started providing development 
> versions of Swift 5.10 and it does, in fact, build on both x86_64 and aarch64.

Well a quick google of one of the errors and it doesn't look like the
error is actually new to 5.9, this bug looks to have been reported in
May against F-38 / 5.8:
https://bugzilla.redhat.com/show_bug.cgi?id=2203541
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: TSS maintainer volunteer - IBM TSS

[Peter Robinson]

Hi Kenneth,

> I'm not 100% clear on the process.  I have a .spec file that passes fedpkg
> mockbuild.
>
> I submitted the request to
> https://bugzilla.redhat.com/show_bug.cgi?id=2238052.
>
> Is that all?  What else should I do?

Well the package is already in Fedora with a maintainer [1] so you
don't need to do a review but you should reach out to that maintainer
if you wish to assist them in co-maintaining the package. It seems you
already know them any way as you cc:ed them on the email.

I suggest a read through of the packaging guidelines [2] would also
assist you greatly as they're pretty decent :)

[1] https://src.fedoraproject.org/rpms/tss2
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Adding Passim as a Fedora 40 feature?

[Peter Robinson]

On Wed, Sep 6, 2023 at 12:58 PM Stephen Smoogen  wrote:
>
>
>
> On Fri, 25 Aug 2023 at 13:31, Richard Hughes  wrote:
>>
>> On Fri, 25 Aug 2023 at 16:27, Stephen Smoogen  wrote:
>> > It depends on the scanning from ports open to unknown shared files to 'why 
>> > did our network costs go up so much?'
>>
>> Surely if you're on a local network with bandwidth costs you'd turn
>> off avahi or lock down the firewall? Lots of stuff blasts out mDNS
>> traffic these days.
>
>
> In the Windows world, you have a one-click which says 'I am on a metered 
> line' which is supposed to do things like that. I don't see anything like 
> that on the Mac but I am only 'learning' it now.
>
> I just realized.. is avahi even on in a default install or would this be an 
> extra service needed to be turned on and 'configured' (not that avahi needs 
> much configuring). It isn't on my F38 box, but I have been living in it for a 
> long time so it could be something I did in the past or something I inherited 
> from a long ago release.

It is default on Workstation and I believe most desktops
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: firefox builds seem stuck on the farm - pls check

[Peter Robinson]

On Wed, Aug 30, 2023 at 9:55 AM Martin Stransky  wrote:
>
> On 8/30/23 10:51, Peter Robinson wrote:
> > On Wed, Aug 30, 2023 at 9:48 AM Martin Stransky  wrote:
> >>
> >> On 8/30/23 10:43, Peter Robinson wrote:
> >>> On Wed, Aug 30, 2023 at 9:42 AM Marius Schwarz  
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> as mozilla released the updates notes for ff 117, there are a lot of
> >>>> high impact security fixes for ff 117.
> >>>>
> >>>> unfortunatly, the ff 117 builds on the farm seem stuck for 40+h ,
> >>>> according to koji.
> >>>>
> >>>> I informed  Martin, but can someone else take a look too, in case hes
> >>>> not available?
> >>>
> >>> Which build in particular, can you provide a link to the root koji task?
> >>
> >> The builds are here:
> >>
> >> https://koji.fedoraproject.org/koji/packageinfo?packageID=37
> >
> > So you mean all 3?
>
> Yes.

Well I've freed the 3 x86 builds, I presume you didn't want the whole
lot just cancelled, please be more specific next time.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: firefox builds seem stuck on the farm - pls check

[Peter Robinson]

On Wed, Aug 30, 2023 at 9:48 AM Martin Stransky  wrote:
>
> On 8/30/23 10:43, Peter Robinson wrote:
> > On Wed, Aug 30, 2023 at 9:42 AM Marius Schwarz  
> > wrote:
> >>
> >> Hi,
> >>
> >> as mozilla released the updates notes for ff 117, there are a lot of
> >> high impact security fixes for ff 117.
> >>
> >> unfortunatly, the ff 117 builds on the farm seem stuck for 40+h ,
> >> according to koji.
> >>
> >> I informed  Martin, but can someone else take a look too, in case hes
> >> not available?
> >
> > Which build in particular, can you provide a link to the root koji task?
>
> The builds are here:
>
> https://koji.fedoraproject.org/koji/packageinfo?packageID=37

So you mean all 3?

> Thanks.
>
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: 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
>
> --
> Martin Stransky
> Software Engineer / Red Hat, Inc
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: firefox builds seem stuck on the farm - pls check

[Peter Robinson]

On Wed, Aug 30, 2023 at 9:42 AM Marius Schwarz  wrote:
>
> Hi,
>
> as mozilla released the updates notes for ff 117, there are a lot of
> high impact security fixes for ff 117.
>
> unfortunatly, the ff 117 builds on the farm seem stuck for 40+h ,
> according to koji.
>
> I informed  Martin, but can someone else take a look too, in case hes
> not available?

Which build in particular, can you provide a link to the root koji task?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Adding Passim as a Fedora 40 feature?

[Peter Robinson]

On Mon, Aug 28, 2023 at 9:50 PM Simo Sorce  wrote:
>
> On Mon, 2023-08-28 at 15:14 -0500, Chris Adams wrote:
> > Once upon a time, Richard Hughes  said:
> > > On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel
> > >  wrote:
> > > > whats the benefit of this "self-signed TLS certificate" (as it does
> > > > not provide any "security")? Is this stub for something later ... ?
> > >
> > > It's a good question. It provides encryption (so client A can provide
> > > the file to client B without client C being aware what's being sent)
> >
> > Without identification though, it doesn't do that, because there's no
> > way for client B to know it is really talking to client A - it could be
> > talking to client C with a man-in-the-middle attack and a different
> > self-signed cert pretending to be client A.
>
> It helps dealing with passive attacks, but not with active attacks.
>
> It could be improved by using TOFU, so that the window of impersonation
> is small, but requires clients to cache an association and then has
> weird failure modes to be dealt with if one of the actors get re-imaged
> or changes the cert for any reason.
>
>
> Richard,
> given your files are all independently integrity checked, you should
> probably not use a TLS connection, because it will be flagged up pretty
> rapidly if it is using a self-singed cert anyway.
>
> This thing works only within the same LAN, therefore already "within" a
> firewall so it does not need to cross any boundary for which encryption
> matters enough.
>
> Finally if an enterprise says TLS is a must you could give an option to
> use TLS if said enterprise provides the certs (they will probably
> disable the service anyway otherwise).

What about integration with Let's Encypt as an option, the cert
registration/renewal process is then pretty automated.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Adding Passim as a Fedora 40 feature?

[Peter Robinson]

On Fri, Aug 25, 2023 at 7:35 PM Richard Hughes  wrote:
>
> On Fri, 25 Aug 2023 at 19:26, Marcus Müller  wrote:
> > I fully agree with that assessment. "Here's a knob you turn that has the 
> > potential to make
> > your firmware update 2s faster and is generally good for the ecosystem, but 
> > you will have
> > set it on every machine you set up" will not lead to significant deployment.
>
> Agree.
>
> > Question: I presume you only want to share the metadata, and never 
> > downloaded fw images,
> > right?
>
> I think for phase 1 that's completely correct.
>
> > If that's the case, it'd alleviate a lot of the privacy concerns I'd have 
> > with my
> > laptop sharing with a campus network all of the devices for which I've 
> > lately downloaded
> > firmware.
>
> There are concerns with sharing firmware, I totally agree. It's
> non-free software (which you have permission to redistribute, but
> still unpalatable for many) -- the compromise I've done for people
> changing the default to "metadata,firmware" is that you need to reboot
> into the new firmware before the published firmware gets shared; on
> the logic that you don't want to advertise to the world that you're
> currently running insecure firmware.

In a lot of corporate datacentre networks the "users" on the network
would know what the network is comprised of, and often on these
networks they will have 10s, 100s of even 1000s of identical devices
where being able to do sharing of the same firmware is useful. Maybe
make that configurable so the network/system admin can make the
decision for what's best for their usecase?

> > Can I suggest we make this at most a "Recommends:" dependence for fwupd in 
> > any case, so
> > that one might uninstall passim without disabling fwupd?
>
> Yes, that's what I have right now. I do need to split out a
> passim-libs so that you can remove the daemon and just leave the tiny
> client library.
>
> > I'd actually love if I knew of a way my fedora containers could 
> > automagically find
> > local package and metadata sources. Knowing that "change dnf to pull data 
> > from
> > mDNS-announced sources *by default*" is a big change, flying the fwupd 
> > balloon first seems
> > very attractive to me.
>
> Yup, totally agree. I think it's a nice self contained test that if
> successful we could extend out to DNF metadata and other container-y
> stuff.
>
> Richard.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Adding Passim as a Fedora 40 feature?

[Peter Robinson]

On Fri, Aug 25, 2023 at 12:43 PM Richard Hughes  wrote:
>
> Hi all,
>
> I was thinking of adding Passim as a default-installed and
> default-enabled dep of fwupd in the Fedora 40 release. Before I create
> lots of unnecessary drama, is there any early feedback on what's
> described in https://github.com/hughsie/passim/blob/main/README.md
> please.
>
> The tl;dr: is I want to add a mDNS server that reshares the public
> firmware update metadata from the LVFS on your LAN. The idea is that
> rather than 25 users in an office downloading the same ~2MB file from
> the CDN every day, the first downloads from the CDN and the other 24
> download from the first machine. All machines still download the
> [tiny] jcat file from the CDN still so we know the SHA256 to search
> for and verify.
>
> The backstory is that as the fwupd grows and grows (to ChromeOS,
> FreeBSD, Windows and macOS) we need to scale things up a couple of
> orders of magnitude. This isn't specific to firmware stuff, although I
> think it makes a great testcase which we could add dnf or ostree
> content to in the future. Comments and questions are most welcome.
> Thanks,

Is this something where you could enable it on one specific device and
have a systemd time to pull the metadata and it advertises it to the
network so you can designate a single device to run the service?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Broken Discrete/Dedicated GPU support

[Peter Robinson]

On Fri, Aug 18, 2023 at 10:16 AM Leigh Scott  wrote:
>
> > On Mon, Aug 14 2023 at 07:19:05 PM +0200, Jan Drögehoff
> >  >
> > Unfortunately yes. There is more info here:
> >
> > https://www.hadess.net/2023/08/new-responsibilities.html
> >
> > Red Hat has instructed us to stop work on several core desktop
> > components. All of these components need new maintainers now. The
> > switcheroo-control repo has now been archived, and a future new
> > maintainer will need to recreate the repo in a new location. It's
> > certainly not good news. :(
> >
> > Michael
>
> So it's ok if Linuxmint  takes over maintenance for?

Don't see why not, as long as there's communication with the other
users/consumers of it.

>  - switcheroo-control
> - iio-sensor-proxy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Replacing DNF with DNF5: changes reverted and helping steps

[Peter Robinson]

On Tue, Aug 15, 2023 at 11:41 AM Petr Pisar  wrote:
>
> V Tue, Aug 15, 2023 at 12:09:34PM +0200, Vít Ondruch napsal(a):
> > Dne 14. 08. 23 v 19:30 Adam Williamson napsal(a):
> > > On Mon, 2023-08-14 at 16:59 +0200, Vít Ondruch wrote:
> > > > $ sudo dnf update -x dnf
> > > > Updating and loading repositories:
> > > > Repositories loaded.
> > > > Failed to resolve the transaction:
> > > > Problem 1: package mass-prebuild-1.1.0-1.fc39.noarch requires dnf, but
> > > > none of the providers can be installed
> [...]
> > > I think only the mass-prebuild maintainer can help you there. dnf5
> > > cannot be set to provide dnf, because it...doesn't.
> >
> > I know and yet again, I have not find any issues using mass-prebuild with
> > DNF5 and until now, it worked just fine. I probably won't ever understand
> > this game with names.
> >
> Since DNF5 is planned as a replacement for Fedora 40 and because Fedora 39 has
> already branched, I'd like to see making dnf5 replacing dnf package in Fedora
> 40 as soon as possible. To have a testing, integration, and stablization 
> period
> as long as possible.

Quoting Samantha [1]:

"We've gone ahead and decided not to replace DNF with DNF05 in Fedora
39 and, perhaps notably, Fedora 40 as well. Fedora 41 is the safest
option at the moment."

So I thought it wasn't coming until Fedora 41?

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EYE2JY537OM7GFW46EK7YIBLHJ52USAZ/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Disabling rawhide builds during branching - happening in 2hrs

[Peter Robinson]

On Fri, Aug 11, 2023 at 9:13 AM Luna Jernberg  wrote:
>
> I think so as there is Branched composes here atleast:
> https://kojipkgs.fedoraproject.org/compose/branched/

Builds of packages and composed are completely disconnnected. A
compose will just consume what ever packages are available in a
particular tag whether or not builds are allowed on that tag.

But there are currently f40 builds running just fine so it does look
like they've been re-enabled, if they weren't they would error out
very early on in the "fedpkg build" process.

> Den fre 11 aug. 2023 kl 09:45 skrev Florian Weimer :
> >
> > * Tomas Hrcka:
> >
> > > Once Fedora Linux 39 is branched we will reenable builds in koji with
> > > notification to this list.
> >
> > Has branching completed?  I didn't see an all-clear message.
> >
> > Thanks,
> > Florian
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

[Peter Robinson]

On Sun, Aug 6, 2023 at 5:35 AM Daniel Alley  wrote:
>
> >In my test zlib-ng is about 40% faster.
>
> I did some testing with zlib-ng and createrepo-c a few months ago [0], and I 
> also found that the compression portion of the workload was about 40% faster. 
>  So this matches my experience, too.
>
> (BTW, if that github comment [0] sounds negative, it isn't meant to, it's 
> just that zlib ended up not being the primary culprit of the performance 
> issue I was investigating at the time, so I was not as immediately interested 
> in replacing it.)
>
> I support this proposal.  A tricky detail is that one of the big upsides of 
> zlib-ng is that it has a lot of optimized codepaths for ARM, POWER, Z, 
> RISC-V, AVX-256, AVX-512 and so forth which madler/zlib does not have.  And 
> that's fantastic, but I expect it could make the testing process a bit more 
> painful.

We tried to pull some of the optimisations in some time ago to the
Fedora package and they caused some issues with compatibility.

> Since each of the arch-specific acceleration codepaths is behind a separate 
> build flag [1] though, (I assume) we could easily do a more conservative 
> rollout with most arch-specific optimizations disabled at first, and then 
> enabled gradually over time.
>
> [0] 
> https://github.com/rpm-software-management/createrepo_c/pull/335#issuecomment-1381362220
> [1] https://github.com/zlib-ng/zlib-ng#advanced-build-options
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 39 Mass Rebuild

[Peter Robinson]

On Thu, Aug 3, 2023 at 4:11 PM Artur Frenszek-Iwicki
 wrote:
>
> > I just discovered that the fontawesome-fonts package had no commit or
> > build either.  I wonder if it has something to do with this error I
> > just encountered while preparing an update for the package:
> >
> > $ git push
> > Source file '60-%{fontpkgname1}.conf' was neither listed in the
> > 'sources' file nor tracked in git. Push operation was cancelled
> > Hint: this check (.git/hooks/pre-push script) can be bypassed by
> > adding the argument '--no-verify' argument to the push command.
> > error: failed to push some refs to
> > 'ssh://pkgs.fedoraproject.org/rpms/fontawesome-fonts'
> >
> > The error is bogus.  Something failed to expand the %{fontpkgname1}
> > macro.  I wonder if the mass rebuilder actually made a commit, but the
> > push failed.
>
> Interesting. One of my fonts packages was also skipped during
> the Mass Rebuild, though in my case, pushing a manual rebuild
> later worked fine.
> https://src.fedoraproject.org/rpms/daniel-wikholm-segment16-fonts

Sometimes if a builder has issues during the "make srpm" phase it
fails in a weird way and isn't picked up I found during my days in
rel-eng.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 DNF05 in Fedora

[Peter Robinson]

On Fri, Jul 28, 2023 at 9:47 AM Vít Ondruch  wrote:
>
>
> Dne 27. 07. 23 v 22:23 Kevin Fenzi napsal(a):
> > On Thu, Jul 27, 2023 at 02:54:13PM -0400, DJ Delorie wrote:
> >> Samantha Bueno  writes:
> >>> We've gone ahead and decided not to replace DNF with DNF05 in Fedora
> >>> 39 and, perhaps notably, Fedora 40 as well.
> >> For those of us who upgraded to DNF05 in rawhide to test it, is there a
> >> quick reference for our paths forward?  Er, backward?  I upgraded at the
> >> wrong time and spent half a day recovering my system, I'd rather avoid
> >> that if I have to go back to DNF04...
> > I would expect a revert back to where /usr/bin/dnf is dnf4 (but
> > hopefully dnf5 is still available/seperate).
>
>
> Please note that this is not just about changing where /usr/bin/dnf
> points to. I was unpleasantly surprised that DNF5 is using different
> locations for data cache and there is no migration path back and forth,
> which leaves some unattended directories behind. I am very grumpy about
> this, because the cache is invaluable on Rawhide being sometimes the
> only (or at minimum the easiest) way to revert to older package in case
> of troubles.

In that sort of usecase it's a once off change when you move back to
dnf4, you can always grab rpms manually either from the remaining dnf5
local cache or worst case from koji.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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)

[Peter Robinson]

On Wed, Jul 26, 2023 at 3:37 PM Ralf Corsépius  wrote:
>
>
>
> Am 26.07.23 um 15:55 schrieb Solomon Peachy via devel:
> > On Wed, Jul 26, 2023 at 09:45:13AM +0200, Ralf Corsépius wrote:
> >> It could be "my bubble", but for me, in all these fwupd is around, it has
> >> never, ever worked on any piece of HW for me.
> >
> > Most of the stuff I have that is updated through fwupd are peripherals
> > [1] that are independent of the system vendor.
> >
> > That said, my two primary systems are a Lenovo laptop and an HP
> > workstation that are fully supported by fwupd/lvfs,
>
> My (older) lenovo laptop and my HPE Micro-Server are obviously not.
>
> > and the UEFI dbx
> > stuff works on all of the remaining physical systems (including servers)
> To my big surprise, for the first time ever, today fwupd installed a dbx
> update on one of my machine - Now, I am still wondering why it didn't do
> so on another, similar machine ;)
>
> > [1] Off the top of my head: Logitech wireless stuff, Jabra conference
> >  speaker, synaptics fingerprint sensor, (Samsung?) NVME storage, and
> This is the second time, somebody mentions Samsung NVMEs were supported.
> Well, what shall I say.
>
> I have several of them (and Samsung SATA SSDs), but so far, I always had
> to resort to other means of updating their firmware (Windows+Magician or
> iso-images), because fwupd would not want to update.

Ultimately being supported and the vendor actually bothering to
publish the firmware updates is two different things, I see this in
linux-firmware too WRT to in particular the various wireless driver
firmware.

From the NVME PoV the firmware update process is standardised as part
of the NVME spec, in most cases I have found, and I've tried a few
different vendors, you can use fwupdmgr to apply the updates from the
vendor's update zip file.

I blogged about it here:
https://nullr0ute.com/2022/06/using-fwupdmgr-to-update-nvme-firmware/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: List of long term FTBFS packages to be retired in August

[Peter Robinson]

On Tue, Jul 25, 2023 at 4:44 PM Florian Weimer  wrote:
>
> * Josh Boyer:
>
> > On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok  wrote:
> >>
> >> On 25. 07. 23 16:42, Florian Weimer wrote:
> >> > * Miro Hrončok:
> >> >
> >> >> glibc32   codonell, fweimer, jakub, 
> >> >> mcermak
> >> >
> >> > Is this about FTBFS issues?  There isn't any recent build failure in
> >> > Koji, so I don't get why it's on this list?
> >>
> >> The build currently in Rawhide was done on Fedora 36 which is end of life.
> >>
> >> Apparently the release engineering team has not rebuilt this package in a 
> >> mass
> >> rebuild at least since Fedora 35.
> >>
> >> To remove it from the list, build the package on Rawhide please.
> >
> > Or we could not, and drop i686 completely.
>
> If we drop glibc32, we can't build any 32-bit code at all because GCC
> will no longer support -m32.  In this regardm x86-64 is different than
> the other Fedora architectures which can target bare metal 32-bit even
> from 64-bit-only compilers.
>
> Are bootloaders fully treated as firmware and no longer built by Fedora?
> At least the shim package does not come with corresponding source code
> AFAICS.  But I expect that there are other 32-bit pre-boot packages that
> we still rebuild.

There's shim-unsigned* which is built in Fedora, the output of those
are sent off to be signed and then the signed binaries are put into
the final shim packages which don't have source code but they are
still built on Fedora with the source, just in a two step process due
to the out of band signing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Peter Robinson]

On Thu, Jul 20, 2023 at 10:46 AM Miroslav Suchý  wrote:
>
> Dne 20. 07. 23 v 10:08 Peter Robinson napsal(a):
> > The dnf5 API has similar primitives (Base, Goal, Package, etc.), but it's
> >> not at all compatible.
>
> It may be worth to add the link to the API:
>
> https://dnf5.readthedocs.io/en/latest/api/index.html
>
> > So everything has to be rewritten across the entire ecosystem to work
> > with it? Wow, who thinks that's a good idea? It took the ecosystem
> > long enough to migrate from the yum "API" to dnf and now they have to
> > do that all over again?
>
> "Only dead projects has stable API"

You can evolve APIs with versioning to ensure backwards compatibility
while also evolving the usecases.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Peter Robinson]

On Wed, Jul 19, 2023 at 11:35 PM Maxwell G  wrote:
>
>
> 2023-07-19T13:39:57Z Peter Robinson :
>
> > On Wed, Jul 19, 2023 at 2:20 PM Nicola Sella  wrote:
> >>
> >> Hi all,
> >> Yesterday, DNF5 5.1.0 was released upstream[1] and in rawhide[2]. This
> >> update makes DNF5's API stable. This means that changes to the API
> >> won't happen in stable Fedora releases.
> >
> > How compatible is this API with the old dnf4 API?
> The dnf5 API has similar primitives (Base, Goal, Package, etc.), but it's
> not at all compatible.

So everything has to be rewritten across the entire ecosystem to work
with it? Wow, who thinks that's a good idea? It took the ecosystem
long enough to migrate from the yum "API" to dnf and now they have to
do that all over again?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Peter Robinson]

On Wed, Jul 19, 2023 at 2:20 PM Nicola Sella  wrote:
>
> Hi all,
> Yesterday, DNF5 5.1.0 was released upstream[1] and in rawhide[2]. This update 
> makes DNF5's API stable. This means that changes to the API won't happen in 
> stable Fedora releases.

How compatible is this API with the old dnf4 API?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Wed, Jul 19, 2023 at 12:38 PM Neal Gompa  wrote:
>
> On Wed, Jul 19, 2023 at 6:11 AM Peter Robinson  wrote:
> >
> > On Wed, Jul 19, 2023 at 10:21 AM Jaroslav Mracek  wrote:
> > >
> > > > On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek 
> > > >  > > >
> > > > Does that mean the issues with dnf [2] we able to be solved all the
> > > > time but just weren't investigated?
> > >
> > > The issue was investigated also with DNF, but the issue was well hidden, 
> > > because the code uses hard coded set for downloaded elements. For most 
> > > investigation we used the biggest repository (Fedora) that showed a high 
> > > memory usage and we tried to mitigate what can we do to improve the 
> > > situation. The real issue was with update repository that surprisingly 
> > > uses slightly more RAM then fedora repository.
> > >
> > > With DNF5 we reinvest it as a completely different issue. DNF5 has a 
> > > better option for investigation that allow us to discover the real source 
> > > of the issue. We knew that DNF5 fixed RAM usage for `fedora` repository 
> > > therefore we continued to search in other directions. Basically we were 
> > > surprised why we got the report with DNF5 because we know that RAM usage 
> > > was  improved with DNF5 and default setting. It means that there where 
> > > two issues that overlaps with symptoms but has a different reproducers. 
> > > Solving the first one (too big metadata to process) uncover the second 
> > > issue with processing updateinfo metadata.
> > >
> > > The status of the issue - We have to wait until our patch is reviewed and 
> > > merged in libsolv and we have to wait until libsolv creates the upstream 
> > > release, because downstream of libsolv in Fedora is not under DNF team 
> > > control and the main admin doesn't like any downstream patches.
> >
> > Looking at upstream releases it seems they don't release often, in the
> > last 18 months there's been 4 releases anywhere between a month and 9
> > months apart.
> >
> > I don't see how it's feasible to sit around and tell users "I'm sorry,
> > you have to wait until upstream bothers to release before you can have
> > a fix to enable you to update your system" when there is a fix
> > available. Can you please explain that to me? It is entirely
> > reasonable to pull in a fix that is headed upstream to fix a key
> > problem in a key distro component so that it doesn't remain broken for
> > MONTHS!
>
> I agree. But the reason releases don't get made is that libsolv
> doesn't have a set schedule, and I can just ask upstream to make a
> release and they probably will.
>
> If the fix is already merged upstream, it's reasonable enough to
> backport. What we want to avoid is non-upstream patches, because this
> component is critical enough that we don't want that burden.

I agree with not having long term non upstream patches but at the same
time patches that are upstream or headed upstream to make things work
I think is a reasonable compromise.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Wed, Jul 19, 2023 at 10:21 AM Jaroslav Mracek  wrote:
>
> > On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek  > wrote:
> >
> > Does that mean the issues with dnf [2] we able to be solved all the
> > time but just weren't investigated?
>
> The issue was investigated also with DNF, but the issue was well hidden, 
> because the code uses hard coded set for downloaded elements. For most 
> investigation we used the biggest repository (Fedora) that showed a high 
> memory usage and we tried to mitigate what can we do to improve the 
> situation. The real issue was with update repository that surprisingly uses 
> slightly more RAM then fedora repository.
>
> With DNF5 we reinvest it as a completely different issue. DNF5 has a better 
> option for investigation that allow us to discover the real source of the 
> issue. We knew that DNF5 fixed RAM usage for `fedora` repository therefore we 
> continued to search in other directions. Basically we were surprised why we 
> got the report with DNF5 because we know that RAM usage was  improved with 
> DNF5 and default setting. It means that there where two issues that overlaps 
> with symptoms but has a different reproducers. Solving the first one (too big 
> metadata to process) uncover the second issue with processing updateinfo 
> metadata.
>
> The status of the issue - We have to wait until our patch is reviewed and 
> merged in libsolv and we have to wait until libsolv creates the upstream 
> release, because downstream of libsolv in Fedora is not under DNF team 
> control and the main admin doesn't like any downstream patches.

Looking at upstream releases it seems they don't release often, in the
last 18 months there's been 4 releases anywhere between a month and 9
months apart.

I don't see how it's feasible to sit around and tell users "I'm sorry,
you have to wait until upstream bothers to release before you can have
a fix to enable you to update your system" when there is a fix
available. Can you please explain that to me? It is entirely
reasonable to pull in a fix that is headed upstream to fix a key
problem in a key distro component so that it doesn't remain broken for
MONTHS!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek  wrote:
>
> > On Mon, Jul 17, 2023 at 6:40 AM Jaroslav Mracek  > wrote:
> >
> > Except dnf5 broke a number of microdnf usecases with low memory where
> > microdnf worked [1].
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2214520
>
> Correct but as you can see the issue was not in DNF5 but in libsolv (solver 
> for DNF, DNF5, zypper, PackageKit). Ales Matej from DNF team prepared two 
> patches - one to resolve the issue in libsolv and second to enable workaround 
> for DNF5. Thanks to better DNF5 structure we were able to discover the real 
> cause of the issue.

Does that mean the issues with dnf [2] we able to be solved all the
time but just weren't investigated?

> Therefore I am curios why the issue is mentioned here?

Because the issues, while quite probably now known, still aren't
resolved in F-38 where it was meant to be stable for those usecases
from the release of F-38. This in turn gives me little confidence in
the rest of dnf5 being ready to replace the much larger set of
usecases as implemented by dnf4 by the Change Completion [3] deadline
in less than 3 weeks time.

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1907030
[3] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Mon, Jul 17, 2023 at 6:40 AM Jaroslav Mracek  wrote:
>
> Hello Pavel,
>
> May I ask you to be more specific what is the problem with including 
> references for issues? I am not sure whether your issues are related to 
> issues referenced by Fabio or whether you have in mind something else. It 
> will help us to prioritize the work.
>
> On Fri, Jul 14, 2023 at 10:50 AM Pavel Březina  wrote:
>>
>> On 7/13/23 23:59, Fabio Valentini wrote:
>> > Hi all,
>> >
>> > I'm opening this thread to trigger discussion of the roadmap for DNF5
>> > in Fedora 39 - whether the switch still looks doable for this release,
>> > or whether it should be reverted for F39 and postponed to F40.
>>
>> +1 for postponing. We have hit issues preparing CI environment via
>> ansible and applying workarounds to make dnf5 work is imho not the way
>> to go with such core tool. It should be there as opt-in so it can get
>> tested but not default.
>
>
> DNF5 was released in Fedora 38 where it replaced microdnf, therefore it was 
> possible to test it in Fedora 38

Except dnf5 broke a number of microdnf usecases with low memory where
microdnf worked [1].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2214520

> Best regards
>
> Jaroslav
>
>>
>>
>> > This is also being tracked in a FESCo ticket:
>> > https://pagure.io/fesco/issue/3039
>> >
>> > The DNF5 Change was approved with the condition that bits that are
>> > important to the distribution *MUST* work, but this does not seem to
>> > be the case yet, six months after this was initially approved -
>> > there's at least a few things that are still using dnf-3 or have been
>> > broken since the switch to dnf5:
>> >
>> > - rawhide mock / koji builds still default to dnf-3 (DNF 4)
>> > - Fedora CI has been partially broken since the switch to DNF5 (c.f.
>> > [fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
>> > making CI results for bodhi updates at least partially useless
>> > - fedora-review has been broken since the switch to DNF5 (c.f.
>> > [FedoraReview#482](FedoraReview/issue/482)), which is really hurting
>> > the rate at which new packages are getting reviewed and added to
>> > Fedora
>> > - (not an exhaustive list, feel free to mention other things, I will
>> > update the list to include them)
>> >
>> > We are now mere days before the Fedora 39 mass rebuild is scheduled to
>> > start, so I think it's time to start talking about the roadmap for
>> > getting missing pieces into place for Fedora 39, or if that is not
>> > possible within this timeframe, whether the contingency mechanism
>> > should be enacted.
>> >
>> > Fabio
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct: 
>> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives: 
>> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> > Do not reply to spam, report it: 
>> > https://pagure.io/fedora-infrastructure/new_issue
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sun, Jul 2, 2023 at 10:27 PM Kevin Kofler via devel
 wrote:
>
> Peter Robinson wrote:
> > Assuming those "binary compatible distributions" choose to add
> > LibreOffice back in and support it, given what they actually do in
> > terms of actual development it's actually pretty unlikely they're
> > going to do all the extra work to add back an office suite and all the
> > dependencies it requires.
>
> If LibreOffice remains maintained in Fedora (and I sure hope so, because
> otherwise that would definitely make Fedora useless for me), there is a good
> chance that somebody will request and maintain EPEL branches for it, as has
> already been done for the KDE Plasma and KDE Gear applications stack.

Someone doing work in EPEL is quite a bit different to my point of a
corporate organisation downstream of RHEL adding value and
differentiation that Red Hat doesn't provide as part of RHEL.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sun, Jul 2, 2023 at 11:01 AM Vitaly Zaitsev via devel
 wrote:
>
> On 02/07/2023 10:51, Simon de Vlieger wrote:
> > The suppliers for these enterprise distributions and the support they
> > offer also abide by political lines.
>
> Indeed. That's why having RHEL repacks (Alma, Rocky, Oracle Linux) is good.
>
> > While your data won't be gone in an instant you still end up in the same 
> > situation with using an unsupported office suite.
>
> You can simply switch to one of these RHEL binary compatible distributions.

Assuming those "binary compatible distributions" choose to add
LibreOffice back in and support it, given what they actually do in
terms of actual development it's actually pretty unlikely they're
going to do all the extra work to add back an office suite and all the
dependencies it requires.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel
 wrote:
>
> On 01/07/2023 13:36, Chris Adams wrote:
> > A lot of the corporate world has gone to the "cloud"
>
> > don't have to worry about local backups of important documents and
> > spreadsheets, they get sharing with minimal effort, they can access
> > things from their mobile devices, etc.
>
> And voluntarily hand over all the corporate secrets to Google and
> Microsoft. Brilliant idea.

This sort of comment is off topic, various companies are free to do
with their data as they wish, just as you are free to do with it as
you please. Frankly it's often more secure with cloud providers than
on corporate networks. Either way that comment doesn't provide useful
discourse in this discussion.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sat, Jul 1, 2023 at 12:30 PM Peter Robinson  wrote:
>
> On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel
>  wrote:
> >
> > Peter Robinson wrote:
> > > I would hardly say Libreoffice, bluetooth on the desktop and certain
> > > iDevice pieces is "killing all work on the desktop" it's more focusing
> > > on things that are important to their customers in those contexts.
> >
> > What corporate desktop customers do not use LibreOffice? If RH considers
> > LibreOffice unimportant to their customers, it is obvious that they only
> > care about server customers.
>
> Well if the customer gets it via Flatpak they still have it, it also
> means it doesn't need to be upgraded in lockstep with the OS so they
> can go to newer versions while keeping the same rev of the desktop or
> vica versa.
>
> But then there's also "desktop usecases like retail point of sale and
> a whole lot of other single use UX graphical like display boards,
> ticket machines, places where they're technical workstations and the
> user has a separate windows device for email/office etc. There's a
> vast array.

Also a lot use online docs like Office365 or Google docs. I personally
used to use Libreoffice a lot but now I mostly use gDocs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel
 wrote:
>
> Peter Robinson wrote:
> > I would hardly say Libreoffice, bluetooth on the desktop and certain
> > iDevice pieces is "killing all work on the desktop" it's more focusing
> > on things that are important to their customers in those contexts.
>
> What corporate desktop customers do not use LibreOffice? If RH considers
> LibreOffice unimportant to their customers, it is obvious that they only
> care about server customers.

Well if the customer gets it via Flatpak they still have it, it also
means it doesn't need to be upgraded in lockstep with the OS so they
can go to newer versions while keeping the same rev of the desktop or
vica versa.

But then there's also "desktop usecases like retail point of sale and
a whole lot of other single use UX graphical like display boards,
ticket machines, places where they're technical workstations and the
user has a separate windows device for email/office etc. There's a
vast array.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Fri, Jun 30, 2023 at 4:41 AM Kevin Kofler via devel
 wrote:
>
> Bastien Nocera wrote:
> > As part of the same process outlined in Matthias Clasen's "LibreOffice
> > packages" email, my upstream and downstream work on desktop Bluetooth,
> > multimedia applications (namely totem, rhythmbox and sound-juicer) and
> > libfprint/fprintd is being stopped, and all the rest of my upstream and
> > downstream work will be reassigned depending on Red Hat's own priorities,
> > as I am transferred to another team.
>
> So Red Hat is essentially killing all work on desktop packages, not just on
> LibreOffice? Also considering that several of those packages are libraries
> that cannot just be put on Flathub as LibreOffice can (which was their
> excuse for terminating all work on LibreOffice packaging).

I would hardly say Libreoffice, bluetooth on the desktop and certain
iDevice pieces is "killing all work on the desktop" it's more focusing
on things that are important to their customers in those contexts.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: LibuserDeprecation (System Wide)

[Peter Robinson]

On Thu, Jun 22, 2023 at 5:15 PM Aoife Moloney  wrote:
>
> https://fedoraproject.org/wiki/Changes/LibuserDeprecation
>
>
> 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 ==
>
> Libuser is not actively developed. Most of the depending component
> have build-time option to work without libuser.
>
> == Owner ==
>
> * Name: [[User:THalman| Tomas Halman]]
>
> * Email: 
>
>
> == Detailed Description ==
>
> The libuser provides library and command line utilities to manipulate
> user and group information. The purpose of the library
> is/was to hide the differences between users in LDAP and files in etc
> (passwd, groups...). The support for LDAP
> is not complete and there is no plan to extend the functionality.
>
> The LDAP integration in Fedora is nowadays done by SSSD.
>
> In the past, the libuser was used by more component including Fedora
> installer. Currently the list is short
>
> * usermode (Requires development, it is not complicated but the
> dependency is unconditional)
> * util-linux (compile time option)
> * passwd (I suggest to ship passwd utility from shadow-utils instead
> of passwd and drop passwd package as well)

Has the maintainer of the passwd utility been engaged about this
suggestion? Is there a difference in functionality between the two
variants of passwd?

>
> == Feedback ==
>
>
> == Benefit to Fedora ==
>
> The main benefit is to decrease the maintenance and packaging work on
> library that does not bring much value while the functionality is
> provided by another components.
>
> == Scope ==
> * Proposal owners: Dropping the package, move it to EPEL eventually
>
>
> * Other developers:
>
> ** Update usermode code to make libuser dependency configurable.
> ** Update usermode packaging to compile it without libuser
> ** Change packaging of util-linux to compile without libuser dependency
> ** Change packaging of shadow-utils to provide passwd utility
>
>
> * Release engineering: [https://pagure.io/releng/issue/11492]
>
> Libuser is part of base image and must be removed. IMO mass rebuild is
> not required.
>
>
> * Policies and guidelines: Since this is about dropping packages
> release notes must be updated.
>
>
> * Trademark approval: N/A (not needed for this Change)
>
> * Alignment with Community Initiatives: N/A
>
>
> == Upgrade/compatibility impact ==
>
> People who used libuser to manipulate users in LDAP will have to move to SSSD.
>
> == How To Test ==
>
> 0. no special hardware needed
> 1. remove libuser, passwd, install new shadow-utils, usermod and util-linux
> 2. try to change password of some user
> 3. try to modify user using usermod
> 4. expected results: everything works normally
>
> == User Experience ==
> This change should not be visible for users.
>
>
>
> == Dependencies ==
>
>
> * usermod (code modification, packaging to drop libuser dependency)
> * shadow-utils (packaging to provide passwd utility
> * util-linux (packaging to drop libuser dependency)
> * passwd (drop package)
>
> == Contingency Plan ==
>
> * Contingency mechanism: Revert the shipped configuration
> * Contingency deadline: final development freeze
> * Blocks release? No
>
> == Documentation ==
>
> There is no extra documentation for this change except release notes.
>
> == Release Notes ==
>
>
>
>
>
> --
> Aoife Moloney
>
> Product Owner
>
> Community Platform Engineering Team
>
> Red Hat EMEA
>
> Communications House
>
> Cork Road
>
> Waterford
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Peter Robinson]

On Mon, Jun 26, 2023 at 7:10 PM Miro Hrončok  wrote:
>
> Hello Patsy,
>
> On 26. 06. 23 17:54, Aoife Moloney wrote:
> > https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata
> >
> > == Summary ==
> > Allow the removal of tzdata especially on containers in order to minimize 
> > size.
> > ...
> >
> > In order for this to work, we need packages that use tzdata at run
> > time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
> > packages should also gracefully handle instances where tzdata has been
> > removed.  For example, this would require recognizing that tzdata is
> > not present and providing an appropriate error, such as recommending
> > that the user install tzdata.
> > ...
> > * python3.XX (3.9, 3.10, 3.11, 3.12)
>
> Who is expected to work on this? Python maintainers or this Change proposal 
> owners?
>
> *PEP 615 – Support for the IANA Time Zone Database in the Standard Library* 
> says:
>
>
> """
> Python distributors are encouraged to ensure that time zone data is installed

The wording of "encouraged to ensure" doesn't sound like a hard
requirement to me based on a lot of specs I've dealt with, but it
depends a bit on how the specific spec defines "encouraged".

> alongside Python whenever possible (e.g. by declaring tzdata as a dependency
> for the python package).
> """
>
> from https://peps.python.org/pep-0615/#system-time-zone-information
>
>
> By changing the Requires to Recommends, we would diverge from upstream
> recommendation.
>
> ---
>
> The current problem with Python without tzdata is:
>
> ===
>  >>> from zoneinfo import ZoneInfo
>  >>> ZoneInfo("Europe/Prague")
> Traceback (most recent call last):
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
>  return resources.files(package_name).joinpath(resource_name).open("rb")
> ^
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, in 
> files
>  return from_package(get_package(package))
>  
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, in
> get_package
>  resolved = resolve(package)
> 
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, in 
> resolve
>  return cand if isinstance(cand, types.ModuleType) else
> importlib.import_module(cand)
>
> ^
>File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in 
> import_module
>  return _bootstrap._gcd_import(name[level:], package, level)
> 
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1140, in _find_and_load_unlocked
> ModuleNotFoundError: No module named 'tzdata'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
>  raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
> Europe/Prague'
> ===
>
> Not that ZoneInfo("UTC") also fails:
>
> ===
>  >>> ZoneInfo("UTC")
> Traceback (most recent call last):
> ...
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> ===
>
> So we would need to patch Python to detect missing tzdata and report something
> like:
>
>   ZoneInfoNotInstalledError: 'No time zone information installed on the 
> system,
> you can only use UTC'
>
> We would also need to ensure UTC work even without tzdata installed.
>
> I would be reluctant to carry this as a downstream-only patch. And the 
> upstream
> window for changes like this has already closed for Python 3.12.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> 

Re: Using AI/Machine Learning with rpmautospec?

[Peter Robinson]

On Mon, Jun 5, 2023 at 10:36 PM Reon Beon via devel
 wrote:
>
> Automatically complete/update the spec file with AI/ML.

Have you looked at Packit? https://packit.dev/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

[Peter Robinson]

On Mon, Jun 5, 2023 at 3:39 PM Vitaly Zaitsev via devel
 wrote:
>
> On 05/06/2023 13:54, Josh Boyer wrote:
> > I'm not sure what led you to the conclusion that IBM has anything to
> > do with this or that "they fired a lot of good engineers".  I don't
> > see evidence of either being the case.
> >
> > Please don't state your own assumptions as facts.
>
> https://news.ycombinator.com/item?id=35687687

HackerNews is not fact, also RH is a subsidiary not a unit with in IBM
so it has it's own management, CEO etc.

This thread is also widely off topic now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

[Peter Robinson]

On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen  wrote:
>
>
>
> On Fri, 2 Jun 2023 at 07:20, Matthias Clasen  wrote:
>>
>> Lets not make this a drama.
>>
>> Package maintenance changes have never gone through change proposals.
>>
>
> I am  sorry, but this was made into a drama by the way this was executed. 
> Surprise is the opposite of engagement and dropping a ton of packages and 
> their dependencies and then announcing it is absolute surprise.
>
> This isn't just package maintenance. This is a major change in what is 
> expected to be included in the next workstation editions with the removal of 
> expected functionality. If the packages are not picked up within a certain 
> amount of time or can be rebuilt it means many packages will need to be 
> edited. Those changes need to be researched, announced, and pushed through.
>
> It is also drama because people in the community have no idea what else will 
> take place? When uncertainty and doubt are allowed into the conversation, 
> people jump to the extremes so they can feel ready to deal with it.
>
> Could we try something different for future changes?
> 1. Announce that Red Hat will be moving from owning said packages and 
> dependencies on X date.
> 2. Let people grieve about things for a short while but make it clear its 
> happening. See if community members or other companies will take up the burden
> 3. Do the orphan or hand over of packages to the new group.
>
> Instead of 3,1,2?

That may not always be possible, sometimes it involves departure or
changes of roles for people and those can be delicate and are not
always notifiable. I'm not sure that is the case here but I do know,
from a blog post [1], that the previous maintainer is no longer at Red
Hat.

Peter

[1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Peter Robinson]

Terry,

> I appreciate and am empathetic to all of those carrying the burden of this 
> and the thousands of other RPM packages.  As a users of Fedora + RPM Fusion + 
> Cinnamon Desktop as my daily laptop driver since 2011, I love Fedora and am a 
> heavy user of Flatpacks.  So thank you all.
>
> That said, I will point out that I have heard of at least 4 enterprise 
> customers who use libreoffice as a headless file conversion utility.  I have 
> seen it used in customer facing production workflows, such as a financial 
> user support website to handle file uploads provided by end users, as well as 
> medical health records systems used by hospitals and doctors offices.  
> https://www.libreofficehelp.com/batch-convert-writer-documents-pdf-libreoffice/
>
> I am not asking for a change in strategy.  I understand our resource 
> challenges.  I only wanted to share this perspective.  Packaging the RPMS in 
> EPEL could alleviate the pain for these customers in the RHEL 10 timeframe, 
> as well as a container image (maybe built from the rpms pulled from EPEL?).

That is a Red Hat problem, and whether it's in RHEL proper or EPEL
someone has to do the work. It's not fair of you to ask the community
to shoulder that burden, that is a problem for Red Hat to deal with
internally to work out how to resource that whether it's it's in EPEL
or elsewhere. From the customer's perspective there's other commercial
vendors that provide support for LibreOffice too. But what ever way
that is done this is completely off topic for Fedora.

> Hope this is helpful.  And again, THANK YOU!
>
> Terry Bowling
> Sr. Product Manager - RHEL Installation & Build Services Experience
> Red Hat, Inc.
>
>
>
>
> On Thu, Jun 1, 2023 at 2:31 PM Matthias Clasen  wrote:
>>
>> Hey,
>>
>> as you've probably seen, the LibreOffice RPMS have recently been orphaned, 
>> and I thought it would be good to explain the reasons
>> behind this.
>>
>> The Red Hat Display Systems team (the team behind most of Red Hat’s desktop 
>> efforts) has maintained the LibreOffice packages in Fedora for years as part 
>> of our work to support LibreOffice for Red Hat Enterprise Linux. We are 
>> adjusting our engineering priorities for RHEL for Workstations and focusing 
>> on gaps in Wayland, building out HDR support, building out what’s needed for 
>> color-sensitive work, and a host of other refinements required by 
>> Workstation users. This is work that will improve the workstation experience 
>> for Fedora as well as RHEL users, and which, we hope, will be positively 
>> received by the entire Linux community.
>>
>> The tradeoff is that we are pivoting away from work we had been doing on 
>> desktop applications and will cease shipping LibreOffice as part of RHEL 
>> starting in a future RHEL version. This also limits our ability to maintain 
>> it in future versions of Fedora.
>>
>> We will continue to maintain LibreOffice in currently supported versions of 
>> RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of 
>> those releases (as published on the Red Hat website). As part of that, the 
>> engineers doing that work will contribute some fixes upstream to ensure 
>> LibreOffice works better as a Flatpak, which we expect to be the way that 
>> most people consume LibreOffice in the long term.
>>
>> Any community member is of course free to take over maintenance, both for 
>> the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that 
>> this is a sizable block of packages and dependencies and a significant 
>> amount of work to keep up with.
>>
>> Matthias
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List 

Re: Plans for dhclient / ISC dhcp?

[Peter Robinson]

On Tue, May 30, 2023 at 5:14 PM Richard W.M. Jones  wrote:
>
> On Tue, May 30, 2023 at 10:11:21AM -0400, David Cantrell wrote:
> > On Tue, May 30, 2023 at 11:09:39AM +0100, Richard W.M. Jones wrote:
> > > https://github.com/libguestfs/libguestfs/issues/121
> > >
> > > We use dhclient to get a DHCP address inside a minimal appliance.
> > > To get this out of the way: NetworkManager or systemd are not options.
> > >
> > > It seems as if the ISC dhcp package has been EOL'd upstream:
> > >
> > > https://www.isc.org/dhcp/
> > >
> > > I wonder what our plans are for this package, such as whether we are
> > > recommending moving to dhcpcd:
> > >
> > > https://roy.marples.name/projects/dhcpcd
> > >
> > > (we package this already, as does Debian), or another suggested
> > > replacement, or if another team is going to maintain the code, or if
> > > we will just keep packaging the last ISC version in Fedora?
> >
> > Personally, I see dhcpcd is the logical option here.  It's a nice and simple
> > client and actively maintained.  It is disconnected from any particular init
> > system making it appealing for appliances and other special use cases.
> >
> > Given ISC dropping dhclient, we should probably be doing the same in Fedora.
>
> This seems like the best plan, although we should probably communicate
> it somehow and find out what Fedora packages are affected.  A Fedora
> systemwide change maybe.

NetworkManager has defaulted to it's own dhcp client by default for
some time and systemd-networkd has it's own as well, I suspect actual
users are quite minimal. I'm not sure if anything like cloud-init uses
it but I also doubt it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Plans for dhclient / ISC dhcp?

[Peter Robinson]

On Tue, May 30, 2023 at 11:10 AM Richard W.M. Jones  wrote:
>
> https://github.com/libguestfs/libguestfs/issues/121
>
> We use dhclient to get a DHCP address inside a minimal appliance.
> To get this out of the way: NetworkManager or systemd are not options.
>
> It seems as if the ISC dhcp package has been EOL'd upstream:
>
> https://www.isc.org/dhcp/
>
> I wonder what our plans are for this package, such as whether we are
> recommending moving to dhcpcd:
>
> https://roy.marples.name/projects/dhcpcd
>
> (we package this already, as does Debian), or another suggested
> replacement, or if another team is going to maintain the code, or if
> we will just keep packaging the last ISC version in Fedora?

Upstream has replace it with Kea: https://www.isc.org/kea/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Are we ready for ipv6-mostly networks?

[Peter Robinson]

Hi,

> I have attended recently csnog.eu conference [1], where some interesting
> presentations took place. They were usually in Czech, so it is not
> something I am going to share more. But what took my interest were ipv6
> readiness with some exceptions. Fedora is ready to be run on dual-stack
> IPv4 and IPv6 networks just fine. But the presentation were about future
> case where we run most hosts on IPv6 network only, but allow some older
> devices to take and use also IPv4 address.

I've been running Fedora on dual stack v4/v6 for well over a decade
without issues as my ISP has long supported it.

> Fortunately there is roughly the same presentation[2] in English, which
> took the place on RIPE 85 meeting. What catched my interest were talk
> about Windows 11 and Apple systems are ready, but not really talk about
> how any linux distribution is ready for such situation. It seems to me
> we should improve the support for mentioned mechanisms in Fedora.
>
> What do you think about it?

There was a UK IPv6 Council meeting recently [1] that I was hoping to
attend but had conflicts, thankfully they've also published most of
the slides/videos which are useful and interesting.

Overall I have a bunch of thoughts as IPv6 is of large interest to
IoT/Edge so I have been following it somewhat. Reviewing a bunch of
the slides from that event, some referenced RIPE meetings, it lead me
to file a NetworkManager RFE [2] for RFC-8925 support. I also intend
to investigate setting up a IPv6 only VLAN but a quick look at my
Unifi GW UX didn't make it easy and I'm yet to dig into what's needed
from a cli PoV there :)

Overall I suspect there's some work directly in Fedora around defaults
but quite a bit may well be in upstream projects like NM. Happy to
help where I can.

Peter

[1] https://www.ipv6.org.uk/2023/02/03/enterprise-ipv6-workshop/
[2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1298

>
> [1] https://indico.csnog.eu/event/13/contributions/121/
> [2] https://ripe85.ripe.net/archives/video/923/
>
> --
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, http://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to get a rawhide i686 VM?

[Peter Robinson]

On Mon, May 15, 2023 at 12:45 PM Dmitry Belyavskiy  wrote:
>
> Dear Peter,
>
> On Mon, May 15, 2023 at 1:06 PM Peter Robinson  wrote:
> >
> > On Mon, May 15, 2023 at 11:39 AM 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.
> >
> > run an i686 userspace in a x86_64 is about the best option these days.
>
> Is there a guideline on how to do it?

dnf instal blah.i686 I believe should work, TBH it's been a long time
since I've tried anything i686.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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?

[Peter Robinson]

On Mon, May 15, 2023 at 11:39 AM 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.

run an i686 userspace in a x86_64 is about the best option these days.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Peter Robinson]

On Mon, May 8, 2023 at 9:11 PM Kevin Fenzi  wrote:
>
> On Mon, May 08, 2023 at 07:57:30PM +, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > I think we need some clarity wrt. to the dependency order here.
> > Let's say we:
> > > In order to do this at branch point, we will need to move building this
> > > image into the compose process and mark it blocking.
> > OK, so we build things, but then we need to publish to registry.fp.o,
> > which is asynchrounous (?). When we test the newly built ISOs, do
>
> No, it happens at the end of the compose (if no blocking deliverables
> failed causing the compose to fail)
>
> > we test them also with the latest image that we get from registry.fp.o?
> > And if we find a bug anywhere in this pipeline, we respin everything?
>
> Good question. I'll note that currently we do not do any specific
> testing after branch point. We freeze things to get a compose to
> complete, but then we move on. It's not like Beta or Final.
>
> > > I'd like to note that making this blocking doesn't waive any kind of
> > > magic wand that makes our infrastructure more reliable. ;)
> > > The container build pipeline is a long collection of fragile things.
> > > It may well result in us slipping more based on things not working. ;(
> >
> > Hmm, quoting from https://pagure.io/releng/issue/11092:
> > >> Also the aarch64 cluster is running on Fedora 33 boxes, so we
> > >> should probably try to do a full redeploy :-(
> > > We can't upgrade it from f33 because docker is no longer in f34+ and
> > > openshift origin / 3.11 doesn't support any newer either.
> >
> > Is this still true? I don't think we want to make the Fedora release
> > process contingent on something that requires F33.
>
> yes, it's still true. Note thats the aarch64 osbs cluster.
> The x86_64 one is rhel7.
>
> So, perhaps it would make sense to only make the x86_64 one blocking?

Or possibly build it with osbuild, the infra there is pretty stable
now for IoT, it's not perfect, but it does have x86_64/aarch64.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: linux-firmware RPM package

[Peter Robinson]

On Sun, Apr 30, 2023 at 11:48 AM Matthias Weckbecker
 wrote:
>
> Hi Dan,
>
> On Sun, Apr 30, 2023 at 12:16:02PM +0200, Dan Horák wrote:
> > On Sun, 30 Apr 2023 12:00:30 +0200
> > Matthias Weckbecker  wrote:
> >
> > > Hi,
> > >
> > > the linux-firmware package has recently added a requires in its spec for
> > > a bunch of other firmware packages: atheros-firmware, brcmfmac-firmware,
> > > mt7xxx-firmware, and realtek-firmware.
> > >
> > > Is this intentional? I don't have hardware in my computer that requires
> > > the atheros firmware. It makes me slightly uneasy to install those blobs
> > > if I don't absolutely have to.
> >
> > the new subpackages are the way how to leave the unneeded firmwares out,
> > similar to what was done for the GPU firmware earlier. There is nothing
> > new installed on your system, all files have been part of the main
> > linux-firmware rpm until now. To keep the upgrade path working the new
> > subpackages are "Requires" for F <= 38, but only "Recommends" for
> > F >= 39, see
> > https://src.fedoraproject.org/rpms/linux-firmware/c/be92a95e169422f1108bce0aee70ed96fc26fb0b?branch=rawhide
> > for details.
> >
>
> thank you! That's exactly what I was hoping for. I vaguely remember that
> something similar was done with gpu firmware packages in the past.

Correct, and when I initially did those with the soft deps on
exisiting installs things broke and people came out with pitch forks
so we do it like this to ensure upgrade paths as people like to have
their HW continue to work funnily enough, especially when it comes to
network and displays :)

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 check if a package is retired?

[Peter Robinson]

On Tue, Apr 25, 2023 at 10:19 AM Florian Weimer  wrote:
>
> * Peter Robinson:
>
> > On Tue, Apr 25, 2023 at 9:58 AM Florian Weimer  wrote:
> >>
> >> * Peter Robinson:
> >>
> >> > On Tue, Apr 25, 2023 at 8:56 AM Florian Weimer  
> >> > wrote:
> >> >>
> >> >> The xorg-x11-drv-fbturbo is supposed to have been retired (see
> >> >> <https://bugzilla.redhat.com/show_bug.cgi?id=2187060#c4>).   How can I
> >> >> check if this is actually the case?
> >> >
> >> > It's not, if you look at the tags at the bottom there should be a red
> >> > check mark against the f39 tag:
> >> > https://koji.fedoraproject.org/koji/packageinfo?packageID=20127
> >> >
> >> > I filed this issue at the time it has issues:
> >> > https://pagure.io/releng/issue/11388
> >> >
> >> > It's allegedly a problem here:
> >> > https://pagure.io/rpkg/issue/685
> >> >
> >> > II did actually note that in your bug report:
> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2187060#c6
> >>
> >> Sorry, it's still not clear to me if the dead.package stuff is an
> >> optional step of retirement to reflect it in dist-git to make it more
> >> noticeable (if all you do is a fedpkg clone), or the core criteria for
> >> retirement.
> >>
> >> Or put differently, if I want to fix this, can I just push a
> >> dead.package file myself, as a provenpackager?
> >
> > A dead.package is not the only piece required, there's koji commands
> > required to block the package that are run as part of the git commit
> > scripts, you won't have the appropriate ACLs to run those manually so
> > the rpkg problem needs to be fixed. I have run it again for that
> > package and it mostly appears to have worked but there was one error
> > but it make take some time for that to be clear if it worked behind
> > the scenes with various cron job style scripts.
>
> Ahh, and the Koji indicator is that the package owner is set to orphan?

No, orphan is a process that a maintainer can do separately, it can be
owned by orphan but not retired and vice versa.

> $ koji list-history --package=npm
> […]
> Wed Feb  8 22:33:08 2023 package owner orphan set for npm in f39 by humaton 
> [still active]
> […]
>
> (Using Tom Hughes' npm example.)
>
> Thanks for completing the retirement.
>
> Florian
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to check if a package is retired?

[Peter Robinson]

On Tue, Apr 25, 2023 at 9:58 AM Florian Weimer  wrote:
>
> * Peter Robinson:
>
> > On Tue, Apr 25, 2023 at 8:56 AM Florian Weimer  wrote:
> >>
> >> The xorg-x11-drv-fbturbo is supposed to have been retired (see
> >> <https://bugzilla.redhat.com/show_bug.cgi?id=2187060#c4>).   How can I
> >> check if this is actually the case?
> >
> > It's not, if you look at the tags at the bottom there should be a red
> > check mark against the f39 tag:
> > https://koji.fedoraproject.org/koji/packageinfo?packageID=20127
> >
> > I filed this issue at the time it has issues:
> > https://pagure.io/releng/issue/11388
> >
> > It's allegedly a problem here:
> > https://pagure.io/rpkg/issue/685
> >
> > II did actually note that in your bug report:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2187060#c6
>
> Sorry, it's still not clear to me if the dead.package stuff is an
> optional step of retirement to reflect it in dist-git to make it more
> noticeable (if all you do is a fedpkg clone), or the core criteria for
> retirement.
>
> Or put differently, if I want to fix this, can I just push a
> dead.package file myself, as a provenpackager?

A dead.package is not the only piece required, there's koji commands
required to block the package that are run as part of the git commit
scripts, you won't have the appropriate ACLs to run those manually so
the rpkg problem needs to be fixed. I have run it again for that
package and it mostly appears to have worked but there was one error
but it make take some time for that to be clear if it worked behind
the scenes with various cron job style scripts.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 check if a package is retired?

[Peter Robinson]

On Tue, Apr 25, 2023 at 8:56 AM Florian Weimer  wrote:
>
> The xorg-x11-drv-fbturbo is supposed to have been retired (see
> ).   How can I
> check if this is actually the case?

It's not, if you look at the tags at the bottom there should be a red
check mark against the f39 tag:
https://koji.fedoraproject.org/koji/packageinfo?packageID=20127

I filed this issue at the time it has issues:
https://pagure.io/releng/issue/11388

It's allegedly a problem here:
https://pagure.io/rpkg/issue/685

II did actually note that in your bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2187060#c6
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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)

[Peter Robinson]

On Mon, Apr 24, 2023 at 5:15 PM 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.

While I believe this to be low impact I do believe it should be a
system wide change as it impacts all aarch64 and basically all the
x86_64 we actively care about.

> == 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.
>
> == 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.
>
> == Contingency Plan ==
>
> * Contingency mechanism: (What to do?  Who will do it?) N/A (not a
> System Wide Change)
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A (not a System Wide Change), No
>
> == Documentation ==
>
> N/A (not a System Wide Change)
>
> == Release Notes ==
>
> Fedora now defaults to a larger EFI System Partition which allows
> firmware updates to work on newer hardware, and allows future
> bootloader and kernel modernizations.
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Firecracker microVM manager

[Peter Robinson]

> > There is no problem technically; the Copr repo[2] is building
> > Firecracker RPMs with musl.  Maintainers of both Rust and musl seemed
> > to be against it in Fedora.  From this thread:
> Why does Fedora not want to ship Firecracker statically linked to musl?
> That is the supported and tested configuration upstream.  Using glibc
> or dynamic linking is not supported for production use.

Because glibc is Fedora's supported libc implementation and supporting
two different implementations at the same time is complex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: TSS maintainer volunteer

[Peter Robinson]

On Fri, Feb 17, 2023 at 9:04 AM Petr Pisar  wrote:
>
> V Thu, Feb 16, 2023 at 07:29:07PM +, Kenneth Goldman napsal(a):
> > I think I followed all those steps - identifying the package, announcing 
> > that
> > I want to be the packager, making an account, etc.
> >
> > What's next?
>
> Submit an updated tss2 package for a package review. As far as I can see,
> there is no review opened for tss2 now

It was only retired on Jan 9th so should not need a re-review.

I think the process needs to be:
1) get a package sponsor. If you don't have one I can possibly do it
as I co-maintain the intel tpm2 packages
2) request ownership and unblocking of the package
3) build new versions as follow the process.

> .
> How to do it is described at
> .
> Especially pay attention to:
>
> If you are not member of the packager group, you need a sponsor. Add
> FE-NEEDSPONSOR to the bugs being blocked by your review request.
>
> > Does someone approve me?
>
> Based on the FE-NEEDSPONSOR blocker someone from sponsors should notice your
> review request and start to communicate with you in the review request in
> Bugzilla. (If that does not happen, approach you a sponsor of your choice as
> recommended at
> )
>
> Once the sponsor finds your package looks good and you understand how to
> maintain a package, he/she will sponsor you, i.e. adds you into a packagers
> group. Then you will be able to continue from this item on the
> Package_Review_Process document:
>
> When your package passes the review you should use fedpkg to request a Git
> repository for it.
>
> > Move a git repo somewhere?
>
> For the purpose of the package review, you need to publish the spec file and
> the SRPM file somewhere on the Internet. (Once you become a packager, you can
> also use  server for that purpose.)
>
> Once the package review passes, the offical git repository (called dist-git in
> Fedora) for the tss2 package will be reopened with completing this item:
>
> Request a Git repository for the package
>
> Then you will commit the new spec file into the reopen dist-git repository.
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux 38 blocker status summary

[Peter Robinson]

On Tue, Feb 14, 2023 at 2:25 AM Kevin Kofler via devel
 wrote:
>
> Neal Gompa wrote:
> > We're not getting rid of Firefox.
>
> At least that is an answer, unlike the complete radio silence on:
> https://bugzilla.redhat.com/show_bug.cgi?id=1920298
>
> Still does not explain why Firefox has to be the default though.

It was decided years ago that all desktops would have some Fedora
similarities, backgrounds, browser etc.

> But the thing is, this inevitably leads to:
> * unnecessarily including a redundant web engine on the Spin (because, as I
> explained, QtWebEngine cannot go away), a huge package increasing the
> download size for all users of the Spin, whether they want Firefox or not,

But there's also 2 other web engines other than firefox and
QtWebEngine (qt5-qtwebkit and webkit2gtk3) as well as a DB server and
the gcc toolchain which I would bet the average user either don't use
or don't need to have installed from the outset.

I bet there's a lot of low hanging fruit that could slim down KDE
rather than just moaning about Firefox which I suspect a lot more
people use by default that a lot of the other components.

> * a non-native browser experience (with controls/widgets based on the XUL
> implementation and the GTK look) instead of a native Qt/KDE one, and
> * a hindrance in getting critical QtWebEngine showstoppers fixed in time for
> the release, because they are not considered Blockers if they do not affect
> the default browser:
> https://bugzilla.redhat.com/show_bug.cgi?id=2001261#c7
>
> > It's the premier open source browser,
>
> That is arguable, considering that Chromium is also Open Source (*) and that
> there are many users of Chromium derivatives (though not necessarily Open
> Source (*) ones).
>
> But either way, it is not a KDE browser. The KDE Spin should be about
> shipping KDE applications wherever possible.
>
> > well-supported
>
> So is QtWebEngine. Chromium gets a lot of development, and Qt backports
> security fixes and important bug fixes to the stable QtWebEngine branches.
> Even the LTS releases of QtWebEngine are publicly available under the LGPL
> from git.qt.io.
>
> > and well-liked by the community,
>
> So "well-liked" that it has a fraction of the market share of Chrome and
> other Chromium-based browsers nowadays.
>
> I think there need to be more objective criteria for picking a default
> browser than allegedly being "well-liked by the community".
>
> > and most things on the Internet will at least accept Firefox as a browser.
>
> "Most things on the Internet" will also accept any Chromium-based browser,
> such as Falkon. The latest QtWebEngine is in fact more standards-compliant
> than Firefox, see the evidence under:
> https://bugzilla.redhat.com/show_bug.cgi?id=1920298
>
> Falkon even works for some sites that only officially support Chrome and do
> not work with Firefox. (E.g., the Microsoft Teams web interface. Last I
> checked, when I tried it with Firefox, it offered me only to download the
> desktop client. With Falkon, I can connect in the browser just fine.)
>
> Now, admittedly, one issue is that Falkon is currently stuck on QtWebEngine
> 5, hence on 5.15 LTS, which gets security backports, but not feature
> backports, so a handful websites are now causing problems with it. (It is
> unfortunate that the web has evolved to such a moving target that web
> developers are unwilling to support even supported LTS versions of browsers.
> They are also complaining about having to support Safari iOS branches,
> Firefox ESR, etc.) For Falkon, that issue should be solved as soon as a Qt 6
> port of Falkon is released.
>
> > It also works on all Fedora architectures, unlike anything Chromium-based.
>
> QtWebEngine works on all architectures for which a Fedora KDE deliverable is
> actually shipped:
> * The KDE Spin is shipped only for x86_64 on the main mirrors.
> * On alt.fedoraproject.org, the KDE Spin is shipped only for aarch64.
> * Kinoite is shipped only for x86_64 and aarch64.
>
> So the KDE Spin needs to support only x86_64 and aarch64, both of which are
> fully supported by QtWebEngine (and we also build -freeworld for both of
> them at that other repository nowadays, I fixed that a couple years ago).
>
> Kevin Kofler
>
> (*) I personally prefer the term "Free Software", but since you talked about
> the "premier open source browser", I am replying with your terms.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- 

Re: TSS maintainer volunteer

[Peter Robinson]

On Mon, Feb 13, 2023 at 9:16 PM Kenneth Goldman  wrote:

> I have a fedora account.
>
>
>
> How do I get packager status?  How do I work with a packager - is that a
> person or a program?
>

A quick google gave me this link:
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/


>
>
> *From:* Stephen Smoogen 
> *Sent:* Friday, February 10, 2023 3:04 PM
> *To:* Development discussions related to Fedora <
> devel@lists.fedoraproject.org>
> *Subject:* [EXTERNAL] Re: TSS maintainer volunteer
>
>
>
> On Fri, 10 Feb 2023 at 14: 56, Simo Sorce  wrote: On
> Fri, 2023-02-10 at 19: 49 +, Kenneth Goldman wrote: > I would like to
> volunteer to maintain the two TSS packages in Fedora: tss2, tss2-devel. > >
> I currently
>
> ZjQcmQRYFpfptBannerStart
>
> *This Message Is From an External Sender *
>
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
>
>
>
>
>
> On Fri, 10 Feb 2023 at 14:56, Simo Sorce  wrote:
>
> On Fri, 2023-02-10 at 19:49 +, Kenneth Goldman wrote:
> > I would like to volunteer to maintain the two TSS packages in Fedora:
> tss2, tss2-devel.
> >
> > I currently maintain the source.
> >
> > I would appreciate any tips on what steps I should take.
>
> I think you should contact the current maintainer first.
>
>
>
> The package tss2 is currently orphaned. I think that is why they are
> asking here.
>
>
>
> Keith,
>
> The first step you will need to do is create a Fedora account and working
> with a packager on how Fedora packages things up and getting packager
> status. tss2 and tss2-devel are built from the tss2 package
> https://src.fedoraproject.org/rpms/tss2
> 
> (that is the canonical place for the RPM spec file).
>
>
>
>
>
> Simo.
>
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> 
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> 
>
>
>
>
> --
>
> Stephen Smoogen, Red Hat Automotive
>
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux 38 blocker status summary

[Peter Robinson]

On Fri, Feb 10, 2023 at 5:52 PM Adam Williamson  wrote:
>
> On Fri, 2023-02-10 at 08:47 -0500, Ben Cotton wrote:
> >
> > Accepted blockers
> > -
> >
> > 1–3. distribution — {Workstation,Everything,Server} boot x86_64 image
> > exceeds maximum size — ASSIGNED
> > ACTION: Relevant Teams to reduce image size or increase the limit
> >
> > Accepted blockers
> > -
> >
> > 1–3. distribution — {Workstation,Everything,Server} boot x86_64 image
> > exceeds maximum size — ASSIGNED
> > https://bugzilla.redhat.com/show_bug.cgi?id=2149246
> > https://bugzilla.redhat.com/show_bug.cgi?id=2151495
> > https://bugzilla.redhat.com/show_bug.cgi?id=2151497
> >
> > Image sizes exceed the specified limits. The choices are to either
> > shrink the image by removing packages or to riase the limits.
>
> Well...not entirely. What I'm hoping we do to resolve this is get the
> linux-firmware changes from upstream:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11eb6f9ac2950b6c96bc54df791dcd7f170cd3c
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=fa3a6d5651db160911ffa373ba9c1c080044
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=177c593173817f58ee3d5cd604c04599006ad367
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=3435843535f747e5d68c7b084d234254dcd74f55
>
> that *should* save a significant amount of space, hopefully enough to
> get the images back undersize.

You'll find out with tomorrow's compose as
linux-firmware-20230210-147.fc38 has my upstreamed changes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 Linux 38 branched

[Peter Robinson]

On Fri, Feb 10, 2023 at 10:27 AM Iñaki Ucar  wrote:
>
> On Fri, 10 Feb 2023 at 09:44, Jakub Kadlcik  wrote:
> >
> > Hello Tomas,
> > thank you for the announcement.
> >
> > We also branched Fedora 38 in Copr so that everybody can submit builds
> > for it by now. Also, all projects with the "Follow Fedora branching"
> > option configured in their project settings have F38 chroots
> > automatically enabled and they contain the last build results from
> > Fedora Rawhide before the branch.
>
> Is this still ongoing? I don't see F38 in my projects.

I do in all of my packages, you should just need to do a git pull to
get the new branches.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases

[Peter Robinson]

On Tue, Feb 7, 2023 at 12:36 PM Lokesh Mandvekar  wrote:
>
> On Tue, Feb 7, 2023 at 5:56 PM Peter Robinson  wrote:
>
> > There are still active users of Fedora IoT 36 on armhfp using
> > containers so I suspect they may be unhappy of they go away before the
> > F-36 EOL in the late May/early June timeframe.
>
> I see. I guess we could leave armhfp be until then. Btw, just curious
> what happens to IoT on armhfp once f36 goes EOL.
> Would users have to pick something else?

Basically yes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases

[Peter Robinson]

On Tue, Feb 7, 2023 at 11:43 AM Lokesh Mandvekar  wrote:
>
> Hi,
>
> We (podman upstream and fedora maintainers) are hoping to disable i686
> and 32-bit arm builds for Podman and some related tools under
> https://github.com/containers org. We would like to do this also for
> released Fedora versions, and not just the upcoming ones.

There are still active users of Fedora IoT 36 on armhfp using
containers so I suspect they may be unhappy of they go away before the
F-36 EOL in the late May/early June timeframe.

Peter

> What Fedora paperwork do we need in place to get this going?
>
> Thanks
> --
> Lokesh
> Libera, GitLab, GitHub, Fedora: lsm5
> Matrix: @lsm5:lsm5.ems.host
> GPG: 0xC7C3A0DD
> https://keybase.io/lsm5
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: IoT Simplified Installer (Self-Contained Change proposal)

[Peter Robinson]

On Wed, Jan 18, 2023 at 11:20 AM Dan Čermák
 wrote:
>
> Ben Cotton  writes:
>
> > https://fedoraproject.org/wiki/Changes/IoTSimplifiedInstaller
> >
> > 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 ==
> > Offer Fedora IoT users a new method to create and deploy customized
> > Fedora IoT disk images using a new installer called Simplified
> > Installer.
> >
> > == Owner ==
> > * Name: [[User:runcom| Antonio Murdaca]], [[User:pwhalen| Paul Whalen]]
> > * Email: amurd...@redhat.com, pwha...@fedoraproject.org
> >
> >
> > == Detailed Description ==
> > The Fedora IoT Simplified Installer will use coreos-installer to write
> > an OStree raw image straight to a disk specified in a kernel argument,
> > without the need for a kickstart or user interaction. This type of
> > installation is ideal for devices connected at the edge where
> > connectivity can be slow or intermittent. It offers the ability to
> > configure the system via osbuild itself, FDO and Ignition.
> >
> > == Feedback ==
> >
> >
> > == Benefit to Fedora ==
> > The addition of the Fedora IoT Simplified Installer will benefit IoT
> > users by allowing them to create customized disk images for use on
> > their edge devices. This feature is already available downstream,
> > adding it to Fedora will once again bring Fedora back to the true
> > upstream of RHEL for edge and allows testing and adoption of new
> > functionality like FIDO Device Onboarding.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Test building Fedora IoT Simplified Installer with `osbuild-composer`
> > ** Update Fedora IoT documentation with usage instructions.
> >
> > * Other developers:
> >
> > * Release engineering:
> > * Policies and guidelines: N/A (not needed for this Change)
> >
> > * Trademark approval: N/A (not needed for this Change)
> > * Alignment with Objectives:
> >
> >
> > == Upgrade/compatibility impact ==
> > * Not applicable to this change.
> >
> > == How To Test ==
> > Testable by installing `osbuild-composer` in Fedora 38 and using the
> > command line tool or the Cockpit web interface to create a Fedora IoT
> > Simplified Installer iso to deploy a UEFI enabled edge device.
> >
> >
> > == User Experience ==
> > This change will greatly enhance the Fedora IoT user experience by
> > allowing users to utilize `osbuild-composer` and blueprints to create
> > customized Fedora IoT deployments and leverage new features like FIDO
> > Device Onboarding for secure zero touch device onboarding of edge
> > devices as well as Ignition to configure the device once it starts.
>
> Will it still be possible to use something simple like zezere /
> provision.fedoraproject.org to deploy your ssh keys? I find that to be
> one of the major advantage of Fedora IoT over all the other images for
> the Raspberry Pi out there, as I can easily get the IP of my newly
> setup device and push my ssh keys from FAS there without ever having to
> bother with ignition.

Yes, we're looking to revitalize zezere too but I think that will more
likely be a F-39 feature at this stage.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Porting Fedora for the LoongArch architecture.

[Peter Robinson]

Hi Folks,

> On Tue, Jan 10, 2023 at 11:12:22PM +0800, 孙海勇 wrote:
> > I want to add LoongArch to the official Fedora support architecture,
>
> This is really cool -- welcome, and I'd love to help make sure you succeed!
>
> > I'm currently a newbie in the Fedora community, so I need help from
> > community developers, and would like someone to guide me on what to do
> > next, such as what would be a better time to submit necessary patches to
> > packages in the Fedora repository, how to develop in a collaborative
> > manner, what other systems to be used for management, etc. In short, any
> > information would be useful. Could I get help here? :)
>
> This message is a good start! There is a little bit of information here
> https://fedoraproject.org/wiki/Architectures, but it's not really complete.
> I'm afraid a lot of the knowledge is really held in a few people's heads.
> Hopefully we can get you connected with the right people!

There's generally about a 5 stage process from initial bootstrap of an
arch to mainline Fedora support, it roughly lays out as follows:
1) Low level toolchain bring up
2) A small Linux kernel+userspace
3) Using 2) to build a reduced size/dep standard Fedora rpm userspace
of a random Fedora release
4) Standalone koji instance shadowing the primary Fedora instance
5) Proposal to merge/import the architecture packages into the main
Fedora koji instance

From your previous message [1] I gather you're basically now at 3) but
I'm not sure if you're yet at 4 and doing a shadow build operation of
rawhide.

As part of stages 3 and 4 you'll likely have a bunch of hacks, patches
and changes to both upstream project releases to add support for the
architecture, or possibly as simple as bumping autoconf macros to
detect the architecture that are required to get things to build or
run. This will include things like spec changes that need to get
merged into Fedora package git repos. Long before we get to proposing
5) this needs to be done and the shadow instance of koji should
ultimately be building unchanged packages.

Also before becoming a main Fedora architecture the infrastructure
team will need to be able to source enterprise grade hardware that can
be racked in a datacentre and remotely managed. There's likely some
other requirements the infrastructure team has here.

We have in the past not progressed to stage 5 on a number of
archtectures, and aarch64 was delayed for some time from this, due to
lack of readily available hardware for people to be able to purchase
for testing, development and just general hacking purposes. I have
read some articles about restrictions on getting Loongson chips [2]
but I am not sure if that's all variants or just a subset of the
Loongson architecture. I have in the past actually looked at getting a
Loongson device or two but ultimately gave up because it was far from
straight forward, this may end up being a problem.

Peter

[1] 
https://lists.fedoraproject.org/archives/list/second...@lists.fedoraproject.org/thread/7DDZMIPWP5AOZ7HTXDM4SHPXLNJMABQZ/
[2] https://www.theregister.com/2022/12/15/china_loongson_chip_export_ban/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: TeXLive 2022 landing in rawhide today

[Peter Robinson]

On Thu, Jan 5, 2023 at 4:47 AM Tom Callaway  wrote:
>
> Despite the size, I don't think TL updates have ever gone through that 
> process before. Not opposed to doing it though, do we need to revert those 
> builds from rawhide?

No, I don't think you need to revert it. The process is good to better
notify both developers and users of the change.

> ~spot
>
> On Wed, Jan 4, 2023 at 10:26 PM Peter Robinson  wrote:
>>
>> Hi Spot,
>>
>> > TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in 
>> > rawhide today. I've done extensive local testing in mock to try to make 
>> > sure it doesn't break anything obvious... but the size and scope of TL 
>> > means that there are probably still some bugs introduced by this update.
>> >
>> > Please let me know if something stops building as a result of the new 
>> > texlive packages, either via email, bugzilla, twitter, mastodon, or 
>> > carrier pigeon, with as much detail as you can provide.
>> >
>> > I do not plan to push this to any stable Fedora, BUT, I have tested with 
>> > it installed over Fedora 37 and it seems to work okay for me.
>> >
>> > Apologies on the delay in getting this done. I realize TL 2023 is probably 
>> > coming out in a few months, hopefully, it will not take a year for me to 
>> > get that update in place.
>>
>> While I appreciate the work here and I trust you to get it right I
>> can't help but think a change of this size should be going through the
>> official change process and I don't see an approved change for F-38
>> [1], is there a reason not to go via this process?
>>
>> Peter
>>
>> [1] 
>> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=gnupg2=Fedora=Fedora%20EPEL
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: TeXLive 2022 landing in rawhide today

[Peter Robinson]

Hi Spot,

> TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in 
> rawhide today. I've done extensive local testing in mock to try to make sure 
> it doesn't break anything obvious... but the size and scope of TL means that 
> there are probably still some bugs introduced by this update.
>
> Please let me know if something stops building as a result of the new texlive 
> packages, either via email, bugzilla, twitter, mastodon, or carrier pigeon, 
> with as much detail as you can provide.
>
> I do not plan to push this to any stable Fedora, BUT, I have tested with it 
> installed over Fedora 37 and it seems to work okay for me.
>
> Apologies on the delay in getting this done. I realize TL 2023 is probably 
> coming out in a few months, hopefully, it will not take a year for me to get 
> that update in place.

While I appreciate the work here and I trust you to get it right I
can't help but think a change of this size should be going through the
official change process and I don't see an approved change for F-38
[1], is there a reason not to go via this process?

Peter

[1] 
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=gnupg2=Fedora=Fedora%20EPEL
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Fedoras GnuPG default option is deprecated

[Peter Robinson]

On Wed, Jan 4, 2023 at 3:37 PM Christopher Klooz  wrote:
>
> A fresh installation of Fedora 37 has by default the "--supervised"
> option active in its gpg-agent systemd file
> (/usr/lib/systemd/user/gpg-agent.service).
>
> According to GnuPG Docs [1], this option is deprecated. Once gpg-agent
> is invoked, the log of "systemctl --user status gpg-agent.service"
> confirms that with: "gpg-agent[2022]: WARNING: "--supervised" is a
> deprecated option"
>
> Is this intended?
>
> Off the cuff I do not see an immediate security issue, but I guess it
> makes sense to get over deprecated options.

I would check bug reports [1] and file a bug if there's not one
already so it can be tracked, the maintainer may not follow this list
closely.

[1] 
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=gnupg2=Fedora=Fedora%20EPEL
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Peter Robinson]

On Fri, Dec 30, 2022 at 9:50 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Dec 30, 2022 at 08:46:46PM -, Leigh Scott wrote:
> > -1 for this change.
> > I will ignore it if it's accepted.
>
> That's OK, the idea is to make this opt-in.

So if the change is opt-in how is this an actual change to the process
we already have?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Peter Robinson]

On Tue, Nov 15, 2022 at 7:02 PM Colin Walters  wrote:
>
>
>
> On Fri, Nov 11, 2022, at 11:41 PM, Chris Murphy wrote:
> > On Thu, Nov 10, 2022, at 6:08 PM, Robbie Harwood wrote:
> >> Ben Cotton  writes:
> >>
> >>> By design, ostree does not manage bootloader updates as they can not
> >>> (yet) happen in a transactional, atomic and safe fashion.
> >>
> >> As we've talked about before, it's not possible to make updates
> >> transactional.  It involves, per spec and depending on processor
> >> architecture, updating multiple files in different directories,
> >> potentially on different filesystems entirely, one of which is fat32.
> >
> > EFI/FedoraA
> > EFI/FedoraB
> >
> > NVRAM bootorder uses A then B
> >
> > Update the bootloader in EFI/FedoraB
> >
> > At any point of failure, only the EFI/FedoraA bootloader path is used.
> > Once everything in EFI/FedoraB is committed to stable media, set
> > bootnext FedoraB. If the boot fails, automatic failback to FedoraA. If
> > the boot succeeds, bootupd can change bootorder. B then A.
>
> I think it makes sense for us to make some use of BootNext indeed.  However, 
> this heavily overlaps with a potential move to UKIs, which effectively 
> obviate this whole thread by dropping shim and grub out of the equation.  It 
> also overlaps with https://github.com/ostreedev/ostree/issues/2725 where 
> ostree could potentially start using BootNext itself - and this is I guess 
> strongly pushing things to be more integrated.  (I'd tried to keep the two 
> independent, but...)

The problem as it stands with UEFI BootNext booting the kernel
directly, as opposed to using grub2 or similar, is that it doesn't
currently deal with loading initrd/kernel command line strings etc.
There's people looking at solving those issues in a few different ways
though so it may be less of a problem in the not too distant future.

> (There's also an overlap in your proposal with fully redundant EFI partitions 
> across multiple disks and how that would need to be handled, also something 
> I'd hoped to support in bootupd explicitly)
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Peter Robinson]

> > > We *could* do something about repo metadata: only install the "main" 
> > > metadata,
> > > and not the "filepath" metadata. This would reduce the metadata size by 
> > > ~80%.
> > > It'd also have huge benefits for speed: on small dnf operations a 
> > > significant
> > > portion of time is spent just loading metadata.
> > >
> > > We had some discussions on this a few years ago, but this never went 
> > > anywhere.
> > > (I did a quick search, but can't find the ticket now.)  But the idea was 
> > > that
> > > dnf would load "main" metadata by default, and then load "filepath" 
> > > metadata
> > > if needed and restart the transaction. Our Packaging Guidelines forbid 
> > > filepath
> > > dependencies (except for a small set of directories which are in the 
> > > "main" part),
> > > so normal rpm transactions don't need the "filepath" metadata. It is only
> > > needed for non-confirming rpms and when the user does something like
> > > 'dnf install /some/strange/path'.
> >
> > AIUI this is already a part of dnf5.
>
> I would love to hear more about this.

The original yum used to do this
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Small rant: installer environment size

[Peter Robinson]

On Thu, Dec 8, 2022 at 5:06 PM Adam Williamson
 wrote:
>
> On Thu, 2022-12-08 at 16:51 +, Gary Buhrmaster wrote:
> > On Thu, Dec 8, 2022 at 12:58 PM Peter Robinson  wrote:
> >
> > > I've done a few passes, dropping a bunch of older firmware upstream
> > > that are no longer supported in any stable kernel release, also a
> > > bunch of de-dupe and linking of files rather than shipping of multiple
> > > copies of the same firmware. It's improved things a bit, unfortunately
> > > a lot of the dead firmware was tiny compared to say average modern
> > > devices like GPUs or WiFI.
> > >
> > > The problem with a lot of the firmware, and with the new nvidia "open
> > > driver" which shoves a lot of stuff into firmware in order to have an
> > > upstreamable driver apparently the firmwares there are going to be
> > > 30+Mb each, is that they're needed to bring up graphics/network etc to
> > > even just install so I don't know how we can get around this and still
> > > have a device work enough to be able to install the needed firmware
> > > across the network.
> > >
> > > Ideas on how to solve that problem welcome.
> >
> > Does compressing the firmware using zstd (perhaps
> > at an aggressive level) level help at all?
>
> It already *is* compressed, which is why it doesn't get any smaller in
> the compressed filesystem image, unlike the other things I mentioned.
> Check for yourself - look under /lib/firmware and you'll see only
> things ending in .xz.

And "aggressive level zstd" makes little difference TBH, and we went
with XZ over zstd because of the support matrix needed actoss various
pieces to support compression wasn't there, and may not be yet, I've
not revisited the whole end to end process since it landed to audit
all the bits since the first feature.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Small rant: installer environment size

[Peter Robinson]

On Thu, Dec 8, 2022 at 4:56 PM Adam Williamson
 wrote:
>
> On Thu, 2022-12-08 at 12:58 +, Peter Robinson wrote:
> >
> > I've done a few passes, dropping a bunch of older firmware upstream
> > that are no longer supported in any stable kernel release, also a
> > bunch of de-dupe and linking of files rather than shipping of multiple
> > copies of the same firmware. It's improved things a bit, unfortunately
> > a lot of the dead firmware was tiny compared to say average modern
> > devices like GPUs or WiFI.
> >
> > The problem with a lot of the firmware, and with the new nvidia "open
> > driver" which shoves a lot of stuff into firmware in order to have an
> > upstreamable driver apparently the firmwares there are going to be
> > 30+Mb each, is that they're needed to bring up graphics/network etc to
> > even just install so I don't know how we can get around this and still
> > have a device work enough to be able to install the needed firmware
> > across the network.
> >
> > Ideas on how to solve that problem welcome.
>
> Sorry if this is way off, but - do we need the GPU firmwares to run a
> graphical install on the fallback path, just using the framebuffer set
> up by the firmware? How crazy would it be to just do that - ship the
> installer env with no GPU firmware?

That has crossed my mind, and with simpledrm that may be more straight
forward now, but TBH it's not something I am skilled enough to deal
with, nor have the resources to test, or actually care enough about,
but the big GPU firmwares are now all split out so that should be much
more straightforward for someone with the resources to investigate.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Small rant: installer environment size

[Peter Robinson]

On Thu, Dec 8, 2022 at 3:54 PM Miroslav Suchý  wrote:
>
> Dne 08. 12. 22 v 13:58 Peter Robinson napsal(a):
> > Ideas on how to solve that problem welcome.
>
> Do we need - at install time - firmware for:
>
> * v4l
>
> * dvb
>
> * cameras

No, and we're looking at splitting those out, but the fact is they are
a tiny amount of the overall firmware collection. You could even argue
either way for something like bluetooth due to it sometimes being used
by keyboards.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Small rant: installer environment size

[Peter Robinson]

On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson
 wrote:
>
> Hi folks! Today I woke up and found
> https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which diverted me
> down a bit of an "installer environment size" rabbit hole.
>
> As of today, with that new dep in webkitgtk, Rawhide's network install
> images are 703M in size. Here's a potted history of network install
> image sizes:
>
> Fedora Core 8: 103.2M (boot.iso 9.2M + stage2.img 94M)
> Fedora 13: 208M
> Fedora 17: 162M (last "old UI")
> Fedora 18: 294M (first "new UI")
> Fedora 23: 415M
> Fedora 28: 583M
> Fedora 33: 686M
> Fedora 37: 665M
> Fedora Rawhide: 703M
>
> The installer does not really do much more in Rawhide than it did in
> FC8. Even after the UI rewrite in F18, we were only at 294M. Now the
> image is well over 2x as big and does...basically the same.
>
> Why does this matter? Well, the images being large is moderately
> annoying in itself just in terms of transfer times and so on. But more
> importantly, AIUI at least, the entire installer environment is loaded
> into RAM at startup - it kinda has to be, we don't have anywhere else
> to put it. The bigger it is, the more RAM you need to install Fedora.
> The size of the installer environment (for which the size of the
> network install image is more or less a perfect proxy) is one of the
> two key factors in this, the other being how much RAM DNF uses during
> package install.
>
> So, I did a bit of poking about into *what* is taking up all that
> space. There's a variety of answers, but there's two major culprits:
>
> 1. firmware
> 2. yelp (which pulls in webkitgtk and its deps)
>
> I've been using du and baobab (the GNOME visual disk usage analyzer,
> which is great) to examine the filesystems, but I ran a couple of test
> builds to confirm these suspects, especially after the impact of
> compression (it's hard to check the *compressed* size of things in the
> installer environment directly).
>
> I did a scratch build of lorax which does not pull in firmware
> packages, and had openQA build a netinst using that lorax. It came out
> at 489M - 214M smaller than current netinsts, a size we last managed in
> Fedora 26. I did a scratch build of anaconda with its requirement of
> yelp dropped (which would break help pages), and built a netinst with
> that; it came out at 662M - 41M smaller than current images. I haven't
> run a combined test yet, but it ought to come out around 448M, around
> the size of Fedora 24.
>
> Even then we'd still be about 50% larger than the Fedora 18 image, for
> not really any added functionality.
>
> I've moaned about the sheer amount and size of firmware blobs in other
> forums before, but 214M compressed is *really* obnoxious. We must be
> able to do something to clean this up (further than it's already
> cleaned up - this is *after* we dropped low-hanging fruit like
> enterprise switch 'firmwares' and garbage like that; most of the
> remaining size seems to be huge amounts of probably-very-similar
> firmware files for AMD graphics adapters and Intel wireless adapters).
> I know some folks were trying to work on this (there was talk that we
> could drop quite a lot of files that would only be loaded by older
> kernels no longer in Fedora); any news on how far along that effort is?

I've done a few passes, dropping a bunch of older firmware upstream
that are no longer supported in any stable kernel release, also a
bunch of de-dupe and linking of files rather than shipping of multiple
copies of the same firmware. It's improved things a bit, unfortunately
a lot of the dead firmware was tiny compared to say average modern
devices like GPUs or WiFI.

The problem with a lot of the firmware, and with the new nvidia "open
driver" which shoves a lot of stuff into firmware in order to have an
upstreamable driver apparently the firmwares there are going to be
30+Mb each, is that they're needed to bring up graphics/network etc to
even just install so I don't know how we can get around this and still
have a device work enough to be able to install the needed firmware
across the network.

Ideas on how to solve that problem welcome.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Policy on supporting old and external software packages and compat RPMS

[Peter Robinson]

On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
 wrote:
>
> On 05/12/2022 12:39, Terry Barnaby wrote:
> > I am wondering what Fedora's policy is on depreciated old shared
> > libraries and particularly compat RPM's ?
>
> Fedora is a bleeding edge distribution. If you need old versions, you
> should try CentOS or RHEL.

Being leading edge doesn't mean those usecases aren't relevant, one is
not mutually exclusive to the other, especially when it comes to
things like FPGAs etc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]

[Peter Robinson]

Hi Fabio,

Been meaning to reply to this, but it got lost in the mail pile.

> > I _very much_ appreciate all the work you and the other Rust SIG folks
> > (Igor and Zbyszek in particular but I'm sure others as well!) have put into
> > packaging rust apps and crates and all of the systems around that.
>
> I'll respond inline.

Same.

> > I fundamentally disagree with Kevin on a deep level about "entirely
> > useless", but ... find myself kind of agreeing about the "unpackagable"
> > part. I mean: clearly we've found a way, but I'm really not sure we're
> > providing a lot of _value_ in this approach, and I'm also not sure it's as
> > successful as it could be.
>
> We *do* provide value to both users *and* developers by doing things
> the way we do, but the benefits might not be obvious to people who
> don't know how (Rust) packaging works, and what we as package
> maintainers do.

As a rust packager I initially agreed but I am now having doubts here.

> > There are three ways having things packaged in Fedora repos _can_ be
> > helpful:
> >
> > 1. End-user applications and tools
> > 2. Useful development environment
> > 3. As convenience for ourselves for building packages for #1 or #2
> >
> > I am not discounting the value of #3 -- making a shared thing that we all
> > work on together is kind of the whole point, and the nicer we can make that
> > the better we can bring in more people, and those of us already here have a
> > lighter load and can work on the things we're most interested in. But
> > ultimately, we're doing it so we make a useful system for users. That means
> > the first two.
>
> This I can agree with :)
>
> > I'll start with the second: our system for Rust doesn't really do that.
> > Developers are going to use cargo and crates.io and we're not going to
> > convince them that they should do otherwise. (I don't expect anyone
> > disagrees with this.)
>
> This is true, and probably also not "fixable". We need to make some
> amount of non-upstreamable patches to some crates (most notably,
> removing Windows- or mac OS-specific dependencies, because we don't
> want to package those), but in some cases, these are "incompatible"
> changes, and Rust *developers* should not be targeting our downstream
> sources that have these differences with actual upstream sources.

Yet you say above "We *do* provide value to both users *and*
developers" yet you say developers shouldn't be targeting that work?

> This is due to a limitation of how cargo handles target-specific
> dependencies - all dependencies that are *mentioned in any way* need
> to be *present* for it to resolve dependencies / enabled optional
> features / update its lockfile etc. But since we don't want to package
> bindings for Windows and mac OS system APIs, we need to actually patch
> them out, otherwise builds will fail.

And that ends up being quite a bit of work from my point of view. Also
the way the packaging works with options things like devel or optional
features ends up being very painful. I will often drop out optional
features just so I can do less packaging.

> > We're doing okay with #1, but... I think #3 _even_ with all of the work in
> > Rust-to-RPM packaging isn't sufficient. I've played with the Bevy game
> > engine and will probably have a few things it would be nice to package to
> > make available in Fedora Linux. I might not even mind maintaining Bevy
> > itself.
>
> Somebody actually already started packaging Bevy components - some
> packages are already approved and some are still pending review. Not
> sure what the progress has been there, but it's not *impossible*.

Well nothing is *impossible* if you have enough stamina, resources or
whatever else. I don't find saying something isn't *impossible*
necessarily makes it compelling.

> > But running `cargo fetch` with a clean cache pulls down *390* crates. Of
> > these, it looks like 199 (!) are already packaged as rust-[crate]-devel,
> > which is *amazing*. But... that still is hundreds that I'd have to add. And
> > mostly they are things I don't know _anything_ about.
>
> You must realize that this is an extreme case. For many Rust
> applications that people want to package for Fedora, the number of
> dependencies that are missing is rather small, *because* most popular
> libraries are already packaged.

In my experience, and I'm not packaging any form of gaming engine,
it's not an extreme case, for a few small things and one slightly
larger thing I *have* packaged I now maintain over 60 more packages. I
have another one I want to package and AFAICT I get to package another
50-100 but frankly it's hard to tell, and this is something I have
control over and have been actively trying to do upstream reduction of
deps.

And requests to make things like this easier have been open for over a year:
https://pagure.io/fedora-rust/rust2rpm/issue/140

> Bevy is a bit special, because it (presumably) pulls in lots of GPU /
> OpenGL / Vulkan related libraries, which we didn't