Re: F42 Change Proposal: Deprecate Zezere Provisioning Server (IoT) (self-contained)

[Dan Čermák]

Hi,

Aoife Moloney via devel-announce
 writes:

> Wiki - https://fedoraproject.org/wiki/Changes/Deprecate_Zezere
> Discussion thread -
>
*snip*
> == Early Testing (Optional) ==
>
>
> == How To Test ==
> To test, users will need to provision a new Fedora IoT system after
> the change is made to enable `systemd-firstboot`.

How will this work in practice? I have found the ssh key enrollment very
convenient and would hate to see it go away.


Cheers,

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

Re: nothing provides group(uuidd) needed by uuidd-2.40.4-1.fc42.x86_64

[Petr Pisar]

V Wed, Jan 15, 2025 at 09:07:49PM +0100, Miro Hrončok napsal(a):
> I just wasn't sure if the user/group Provides aren't "magical" in some sort
> -- e.g. dnf on F42+ treating them specially by creating the user/group,

DNF does not create any users or groups.

-- Petr


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

Re: F42 Change Proposal: Deprecate Zezere Provisioning Server (IoT) (self-contained)

[Fabio Alessandro Locati via devel]

On Wed, Jan 15, 2025, at 22:41, Aoife Moloney via devel-announce wrote:
> == Upgrade/compatibility impact ==
> None.

What about the deployments that were zezere based? Will it be possible to 
enroll new systems with systemd-firstboot in the same way that it was possible 
with zezere? Will people have to change their setup processes to accomodate 
this change?

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

Re: F42 Change Proposal: Deprecate Zezere Provisioning Server (IoT) (self-contained)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 16, 2025 at 10:49:41AM +, Peter Robinson wrote:
> On Thu, 16 Jan 2025 at 10:44, Zbigniew Jędrzejewski-Szmek 
> wrote:
> 
> > On Wed, Jan 15, 2025 at 10:41:15PM +, Aoife Moloney via devel-announce
> > wrote:
> > > Wiki - https://fedoraproject.org/wiki/Changes/Deprecate_Zezere
> > > Discussion thread -
> > >
> > > 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 ==
> > > Deprecate use of the {{package|Zezere}} provisioning server, currently
> > > used to configure Fedora IoT devices.
> > >
> > > == Owner ==
> > >
> > > * Name: [[User: pwhalen| Paul Whalen]]
> > > * Email: pwha...@fedoraproject.org
> > > * Name: Fedora IoT SIG
> > >
> > >
> > > == Detailed Description ==
> > > Currently, Fedora IoT users can add an SSH key to the root user
> > > account using the Zezere provisioning tool. While convenient for most
> > > use cases, users have given feedback that this does not work for all.
> >
> > For reference, can you provide some links to issues or discussions
> > here?
> >
> > > == How To Test ==
> > > To test, users will need to provision a new Fedora IoT system after
> > > the change is made to enable `systemd-firstboot`.

The way this sentence is structured, it's not clear if the users will
need to enable systemd-firstboot or if it is part of the change.

> > … and? Some more instructions what to expect and how to configure
> > things would be welcome.
>
> What do you mean by that? We would have it run by default, and once a user
> has an account they can continue as per normal, or they can use FDO or
> ignition which are already available.

I would expect this information to be part of the Detailed Description,
and then have some more detailed steps here.

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

Re: F42 Change Proposal: Promote KDE Plasma Desktop variant to Edition (self-contained)

[Neal Gompa]

On Thu, Jan 16, 2025 at 5:39 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> > == User Experience ==
> > The main change will be the Fedora website showing the KDE Plasma
> > Desktop Edition alongside Workstation and others.
>
> Sounds reasonable.
>
> BTW, looking at that page, shouldn't "container optimized OS" be
> "container-optimized OS"? On the page it's show an "containeroptimized"
> which is rather confusing.
>

Yes, it should be.



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Neal Gompa]

On Thu, Jan 16, 2025 at 3:28 AM Vitaly Zaitsev via devel
 wrote:
>
> On 15/01/2025 23:53, Aoife Moloney via devel-announce wrote:
> > There should be no visible impact to users. Live installations
> > continue to work as expected, and live environments may be slightly
> > faster.
>
> Is it true that new ISO images will take up 2x more disk space due to
> weak compression?
>

Nope. The EROFS folks worked with us to improve the compression to
match SquashFS with LZMA compression. Even before that, there was no
case where it was going to take 2x the disk space unless we just did
uncompressed EROFS (and that's way more than 2x).



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: List of long term FTBFS packages to be retired in 2 weeks

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 15, 2025 at 01:47:56PM +0100, Miro Hrončok wrote:
> jaero vascom
I fixed this one which just needed an updated library name.

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

Re: F42 Change Proposal: Deprecate Zezere Provisioning Server (IoT) (self-contained)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 15, 2025 at 10:41:15PM +, Aoife Moloney via devel-announce 
wrote:
> Wiki - https://fedoraproject.org/wiki/Changes/Deprecate_Zezere
> Discussion thread -
> 
> 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 ==
> Deprecate use of the {{package|Zezere}} provisioning server, currently
> used to configure Fedora IoT devices.
> 
> == Owner ==
> 
> * Name: [[User: pwhalen| Paul Whalen]]
> * Email: pwha...@fedoraproject.org
> * Name: Fedora IoT SIG
> 
> 
> == Detailed Description ==
> Currently, Fedora IoT users can add an SSH key to the root user
> account using the Zezere provisioning tool. While convenient for most
> use cases, users have given feedback that this does not work for all.

For reference, can you provide some links to issues or discussions
here?

> == How To Test ==
> To test, users will need to provision a new Fedora IoT system after
> the change is made to enable `systemd-firstboot`.

… and? Some more instructions what to expect and how to configure
things would be welcome.

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

Re: F42 Change Proposal: Promote KDE Plasma Desktop variant to Edition (self-contained)

[Zbigniew Jędrzejewski-Szmek]

> == User Experience ==
> The main change will be the Fedora website showing the KDE Plasma
> Desktop Edition alongside Workstation and others.

Sounds reasonable.

BTW, looking at that page, shouldn't "container optimized OS" be
"container-optimized OS"? On the page it's show an "containeroptimized"
which is rather confusing.

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

Re: Fedora Mass Rebuild 42 has started

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 16, 2025 at 02:26:12PM +0530, Samyak Jain wrote:
> Failures can be seen
> 

On the failed builds, I see
"BuildError: error building package (arch i686), mock exited with status 1; see 
build.log or root.log for more information"
IIRC, the "build.log or root.log" cop-out message was added because
mock (?) stopped returning the correct error message at some point, so
koji was changed to give a generic explanation. But that initial
problem was fixed a long time ago and we do have the correct code.
Since a lot of people will be looking at the failures, can we revert
the workaround in koji and direct people to the right log again?

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

Re: F42 Change Proposal: Deprecate Zezere Provisioning Server (IoT) (self-contained)

[Peter Robinson]

On Thu, 16 Jan 2025 at 10:44, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Wed, Jan 15, 2025 at 10:41:15PM +, Aoife Moloney via devel-announce
> wrote:
> > Wiki - https://fedoraproject.org/wiki/Changes/Deprecate_Zezere
> > Discussion thread -
> >
> > 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 ==
> > Deprecate use of the {{package|Zezere}} provisioning server, currently
> > used to configure Fedora IoT devices.
> >
> > == Owner ==
> >
> > * Name: [[User: pwhalen| Paul Whalen]]
> > * Email: pwha...@fedoraproject.org
> > * Name: Fedora IoT SIG
> >
> >
> > == Detailed Description ==
> > Currently, Fedora IoT users can add an SSH key to the root user
> > account using the Zezere provisioning tool. While convenient for most
> > use cases, users have given feedback that this does not work for all.
>
> For reference, can you provide some links to issues or discussions
> here?
>
> > == How To Test ==
> > To test, users will need to provision a new Fedora IoT system after
> > the change is made to enable `systemd-firstboot`.
>
> … and? Some more instructions what to expect and how to configure
> things would be welcome.
>

What do you mean by that? We would have it run by default, and once a user
has an account they can continue as per normal, or they can use FDO or
ignition which are already available.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora Mass Rebuild 42 has started

[Samyak Jain]

Hi all,

Per the Fedora Linux f42 schedule [1] we have started a mass rebuild on
2025-01-16 for Fedora f42. We are running this mass rebuild for the
changes listed in:
https://pagure.io/releng/issues?status=Open&tags=mass+rebuild

The discussions for mass rebuild is happening at releng issue tracker:

https://pagure.io/releng/issue/12527

This mass rebuild will be done in a side tag (f42-rebuild) and merged
when completed.

Failures can be seen


Things still need rebuilding


FTBFS (Fails To Build From Source) bugs will be filed shortly after the
mass rebuild is complete.

Please let releng know if you see any bugs in the reporting.
You can contact releng in the #releng:fedoraproject.org room on Matrix,
or by dropping an email to our list [2] or filing an issue in pagure [3].

This email template is also in https://pagure.io/releng if you wish to
propose improvements or changes to it.

Regards,
SamyakJain
Fedora Release Engineering

[1]https://fedorapeople.org/groups/schedule/f-42/f-42-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Deprecate Zezere Provisioning Server (IoT) (self-contained)

[Peter Robinson]

On Thu, 16 Jan 2025 at 11:05, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Thu, Jan 16, 2025 at 10:49:41AM +, Peter Robinson wrote:
> > On Thu, 16 Jan 2025 at 10:44, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl>
> > wrote:
> >
> > > On Wed, Jan 15, 2025 at 10:41:15PM +, Aoife Moloney via
> devel-announce
> > > wrote:
> > > > Wiki - https://fedoraproject.org/wiki/Changes/Deprecate_Zezere
> > > > Discussion thread -
> > > >
> > > > 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 ==
> > > > Deprecate use of the {{package|Zezere}} provisioning server,
> currently
> > > > used to configure Fedora IoT devices.
> > > >
> > > > == Owner ==
> > > >
> > > > * Name: [[User: pwhalen| Paul Whalen]]
> > > > * Email: pwha...@fedoraproject.org
> > > > * Name: Fedora IoT SIG
> > > >
> > > >
> > > > == Detailed Description ==
> > > > Currently, Fedora IoT users can add an SSH key to the root user
> > > > account using the Zezere provisioning tool. While convenient for most
> > > > use cases, users have given feedback that this does not work for all.
> > >
> > > For reference, can you provide some links to issues or discussions
> > > here?
> > >
> > > > == How To Test ==
> > > > To test, users will need to provision a new Fedora IoT system after
> > > > the change is made to enable `systemd-firstboot`.
>
> The way this sentence is structured, it's not clear if the users will
> need to enable systemd-firstboot or if it is part of the change.
>

It will be part of the change.


> > > … and? Some more instructions what to expect and how to configure
> > > things would be welcome.
> >
> > What do you mean by that? We would have it run by default, and once a
> user
> > has an account they can continue as per normal, or they can use FDO or
> > ignition which are already available.
>
> I would expect this information to be part of the Detailed Description,
> and then have some more detailed steps here.
>

Details steps for what exactly? The FDO and ignition pieces are already
there and documented in the IoT docs. Zezere and FDO are first boot run
once technologies so it doesn't affect already deployed systems, it's
purely for new systems.

I am sure Paul will update the proposal with feedback as he's leading 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: nothing provides group(uuidd) needed by uuidd-2.40.4-1.fc42.x86_64

[Miro Hrončok]

On 16. 01. 25 9:47, Petr Pisar wrote:

V Wed, Jan 15, 2025 at 09:07:49PM +0100, Miro Hrončok napsal(a):

I just wasn't sure if the user/group Provides aren't "magical" in some sort
-- e.g. dnf on F42+ treating them specially by creating the user/group,


DNF does not create any users or groups.

Thanks for clarifying.

--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Vít Ondruch]

Dne 15. 01. 25 v 23:53 Aoife Moloney via devel-announce napsal(a):

== Benefit to Fedora ==
EROFS is considerably more actively developed than SquashFS, and
offers more modern file system features that can be utilized in the
future.



This is pretty brief (especially the "modern file system features" 
part). Could you please elaborate more?



Thx


Vít



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

Re: GCC 15 for Fedora 42 in a side-tag

[Siddhesh Poyarekar]

On 2025-01-15 20:46, Fabio Valentini wrote:

TBH we haven't had enough time since upstream gcc stage 1 close to
finish going through all the failures[1].  If only we had a week or two
more for the mass rebuild; it got delayed by a couple of weeks last
year
and a similar delay would have helped this year too.


This might be a stupid question ... but if it would have helped you, 
then why wasn't a delay requested?


I had it in my TODO list to file a Fesco ticket for *future* even 
numbered Fedora, but I suppose I could have requested an additional week 
or so to file these issues even for F42.  Most of the packages succeeded 
so I figured we could use the stabilization period following the rebuild 
(as we would do in F39 and earlier) to help iron out the failures that 
we couldn't cover during the prebuild and avoid a schedule slippage.


Sid

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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Neal Gompa]

On Thu, Jan 16, 2025 at 8:21 AM Vít Ondruch  wrote:
>
>
> Dne 15. 01. 25 v 23:53 Aoife Moloney via devel-announce napsal(a):
> > == Benefit to Fedora ==
> > EROFS is considerably more actively developed than SquashFS, and
> > offers more modern file system features that can be utilized in the
> > future.
>
>
> This is pretty brief (especially the "modern file system features"
> part). Could you please elaborate more?
>

It's mostly that it behaves more like a real filesystem. It uses
extents, supports inline compression, DAX, and other features that you
expect from advanced filesystems.

There's a lot more detail about it on the EROFS website:
https://erofs.docs.kernel.org/en/latest/



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Vitaly Zaitsev via devel]

On 15/01/2025 23:53, Aoife Moloney via devel-announce wrote:

There should be no visible impact to users. Live installations
continue to work as expected, and live environments may be slightly
faster.


Is it true that new ISO images will take up 2x more disk space due to 
weak compression?


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

Re: tree-sitter build broke Emacs

[Andreas Schneider]

On Wednesday, 15 January 2025 22:31:22 CET Jerry James wrote:
> On Wed, Jan 15, 2025 at 2:34 AM Andreas Schneider  wrote:
> > On Wednesday, 15 January 2025 01:06:19 CET Jerry James wrote:
> > > Emacs is uninstallable in Rawhide due to a tree-sitter soname bump.
> > > Are the tree-sitter maintainers planning to rebuild (quickly!) the
> > > broken dependencies soon?  The mass rebuild is about to start...
> > 
> > emacs and neovim already have been rebuilt.
> 
> Thank you.  Would you please update tree-sitter, emacs, etc. in a side
> tag next time?

I just followed orders ...

https://src.fedoraproject.org/rpms/tree-sitter/pull-request/2

See also
https://src.fedoraproject.org/rpms/tree-sitter/pull-request/3


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

Fedora rawhide compose report: 20250116.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20250115.n.0
NEW: Fedora-Rawhide-20250116.n.0

= SUMMARY =
Added images:4
Dropped images:  0
Added packages:  12
Dropped packages:3
Upgraded packages:   143
Downgraded packages: 0

Size of added packages:  1.83 MiB
Size of dropped packages:28.59 MiB
Size of upgraded packages:   6.19 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   8.23 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20250116.n.0.iso
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-Rawhide-20250116.n.0.x86_64.iso
Image: Python_Classroom live aarch64
Path: 
Labs/aarch64/iso/Fedora-Python-Classroom-Live-Rawhide-20250116.n.0.aarch64.iso
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20250116.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: casilda-0.2.0-1.fc42
Summary: Wayland compositor for GTK4
RPMs:casilda casilda-devel
Size:223.41 KiB

Package: kiwi-stackbuild-plugin-1.0.10-1.fc42
Summary: KIWI - Stack Build Plugin
RPMs:kiwi-stackbuild-plugin python3-kiwi-stackbuild-plugin
Size:50.11 KiB

Package: newflasher-57-1.fc42
Summary: Flash tool for new Sony flash tool protocol (Xperia XZ Premium and 
further)
RPMs:newflasher
Size:138.51 KiB

Package: python-eth-stdlib-0.2.7-1.fc42
Summary: A collection of libraries for developers building on the EVM
RPMs:python3-eth-stdlib
Size:62.19 KiB

Package: python-proton-vpn-api-core-0.36.6-1.fc42
Summary: Expose a uniform API to available Proton VPN services
RPMs:python3-proton-vpn-api-core
Size:222.19 KiB

Package: rubygem-useragent-0.16.11-1.fc42
Summary: HTTP User Agent parser
RPMs:rubygem-useragent rubygem-useragent-doc
Size:374.25 KiB

Package: rust-arcstr-1.2.0-1.fc42
Summary: Better reference-counted string type
RPMs:rust-arcstr+default-devel rust-arcstr+serde-devel 
rust-arcstr+std-devel rust-arcstr+substr-devel 
rust-arcstr+substr-usize-indices-devel rust-arcstr-devel
Size:72.00 KiB

Package: rust-libphosh-0.0.5-1.fc42
Summary: Rust bindings for libphosh
RPMs:rust-libphosh+default-devel rust-libphosh+gtk_v2_10-devel 
rust-libphosh+gtk_v2_12-devel rust-libphosh+gtk_v2_18-devel 
rust-libphosh+gtk_v2_20-devel rust-libphosh+gtk_v2_4-devel 
rust-libphosh+gtk_v2_6-devel rust-libphosh+gtk_v3-devel 
rust-libphosh+gtk_v3_12-devel rust-libphosh+gtk_v3_14-devel 
rust-libphosh+gtk_v3_20-devel rust-libphosh+gtk_v3_4-devel 
rust-libphosh+gtk_v3_8-devel rust-libphosh+v3_12-devel 
rust-libphosh+v3_14-devel rust-libphosh-devel
Size:137.95 KiB

Package: rust-picky-asn1-der0.4-0.4.1-1.fc42
Summary: ASN.1-DER subset for serde
RPMs:rust-picky-asn1-der0.4+debug_log-devel 
rust-picky-asn1-der0.4+default-devel rust-picky-asn1-der0.4+lazy_static-devel 
rust-picky-asn1-der0.4-devel
Size:54.60 KiB

Package: rust-picky-asn1-x509_0.12-0.12.0-1.fc42
Summary: ASN1 types defined by X.509 related RFCs
RPMs:rust-picky-asn1-x509_0.12+ctl-devel 
rust-picky-asn1-x509_0.12+default-devel rust-picky-asn1-x509_0.12+legacy-devel 
rust-picky-asn1-x509_0.12+num-bigint-dig-devel 
rust-picky-asn1-x509_0.12+pkcs12-devel rust-picky-asn1-x509_0.12+pkcs7-devel 
rust-picky-asn1-x509_0.12+widestring-devel 
rust-picky-asn1-x509_0.12+zeroize-devel rust-picky-asn1-x509_0.12-devel
Size:162.00 KiB

Package: rust-picky-asn1_0.8-0.8.0-1.fc42
Summary: Provide ASN.1 simple types
RPMs:rust-picky-asn1_0.8+chrono-devel 
rust-picky-asn1_0.8+chrono_conversion-devel rust-picky-asn1_0.8+default-devel 
rust-picky-asn1_0.8+time-devel rust-picky-asn1_0.8+time_conversion-devel 
rust-picky-asn1_0.8+zeroize-devel rust-picky-asn1_0.8-devel
Size:70.72 KiB

Package: rust-picky-test-data-0.1.0-1.fc42
Summary: Test data for the picky crates
RPMs:rust-picky-test-data+default-devel rust-picky-test-data-devel
Size:308.34 KiB


= DROPPED PACKAGES =
Package: caffe-1.0^git20200212.9b89154-14.fc42
Summary: A deep learning framework
RPMs:caffe caffe-devel
Size:20.98 MiB

Package: libgit2_1.7-1.7.2-1.fc42
Summary: C implementation of the Git core methods as a library with a solid API
RPMs:libgit2_1.7 libgit2_1.7-devel
Size:4.13 MiB

Package: mingw-SDL2-2.30.11-1.fc42
Summary: MinGW Windows port of SDL2 cross-platform multimedia library
RPMs:mingw32-SDL2 mingw32-SDL2-static mingw64-SDL2 mingw64-SDL2-static
Size:3.48 MiB


= UPGRADED PACKAGES =
Package:  GtkAda-2.24.2-50.fc42
Old package:  GtkAda-2.24.2-49.fc41
Summary:  GTKada 2, an Ada binding to GTK+ 2
RPMs: GtkAda GtkAda-devel GtkAda-doc GtkAda-gl GtkAda-gnome
Size: 21.89 MiB
Size change:  -169.79 KiB
Changelog:
  * Tue Jan 14 2025 Bj??rn Persson  - 2.24.2-50
  - Rebuilt with GCC 15 prerelease.


Package:  GtkAda3-2:25.0.0-2.fc42
Old package:  GtkAda3-2:25.0.0-1.fc42
Summary

Re: F42 Change Proposal: Deprecate Zezere Provisioning Server (IoT) (self-contained)

[Vít Ondruch]

Dne 15. 01. 25 v 23:41 Aoife Moloney via devel-announce napsal(a):

Wiki - https://fedoraproject.org/wiki/Changes/Deprecate_Zezere
Discussion thread -

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 ==
Deprecate use of the {{package|Zezere}}



This is expanded to https://src.fedoraproject.org/rpms/Zezere , what 
does not work. The initial `Z` should be likely lower case.




  provisioning server, currently
used to configure Fedora IoT devices.

== Owner ==

* Name: [[User: pwhalen| Paul Whalen]]
* Email: pwha...@fedoraproject.org
* Name: Fedora IoT SIG


== Detailed Description ==
Currently, Fedora IoT users can add an SSH key to the root user
account using the Zezere provisioning tool. While convenient for most
use cases, users have given feedback that this does not work for all.
In Fedora 42 we plan to deprecate the Zezere provisioning server in
favour of offering a local means for user configuaration -
`systemd-firstboot` - as well as the existing options of `FDO` or
`ignition`.



Could you please elaborate what you mean by "deprecating"? My 
understanding is that you mark it deprecated following this guideline:


https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/#_marking_a_package_deprecated

But maybe you considering retiring it entirely? Not sure.


Thanks.


Vít



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

Re: Fedora Mass Rebuild 42 has started

[Miroslav Suchý]

Dne 16. 01. 25 v 11:48 dop. Zbigniew Jędrzejewski-Szmek napsal(a):

IIRC, the "build.log or root.log" cop-out message was added because
mock (?) stopped returning the correct error message at some point, so
koji was changed to give a generic explanation. But that initial
problem was fixed a long time ago and we do have the correct code.
Since a lot of people will be looking at the failures, can we revert
the workaround in koji and direct people to the right log again?


FYI the exit codes are documented here:

https://github.com/rpm-software-management/mock/blob/main/mock/py/mockbuild/exception.py#L30

https://rpm-software-management.github.io/mock/#exit-codes

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Vít Ondruch]

Dne 16. 01. 25 v 14:25 Neal Gompa napsal(a):

On Thu, Jan 16, 2025 at 8:21 AM Vít Ondruch  wrote:


Dne 15. 01. 25 v 23:53 Aoife Moloney via devel-announce napsal(a):

== Benefit to Fedora ==
EROFS is considerably more actively developed than SquashFS, and
offers more modern file system features that can be utilized in the
future.


This is pretty brief (especially the "modern file system features"
part). Could you please elaborate more?


It's mostly that it behaves more like a real filesystem. It uses
extents, supports inline compression, DAX, and other features that you
expect from advanced filesystems.

There's a lot more detail about it on the EROFS website:
https://erofs.docs.kernel.org/en/latest/





Thanks for elaborating. Make sense 👍


Vít



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

Re: Fedora Mass Rebuild 42 has started

[Adam Williamson]

On Thu, 2025-01-16 at 10:48 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jan 16, 2025 at 02:26:12PM +0530, Samyak Jain wrote:
> > Failures can be seen
> > 
> 
> On the failed builds, I see
> "BuildError: error building package (arch i686), mock exited with status 1; 
> see build.log or root.log for more information"
> IIRC, the "build.log or root.log" cop-out message was added because
> mock (?) stopped returning the correct error message at some point, so
> koji was changed to give a generic explanation. But that initial
> problem was fixed a long time ago and we do have the correct code.
> Since a lot of people will be looking at the failures, can we revert
> the workaround in koji and direct people to the right log again?

IIRC, 30 always means root.log, but 1 *can* still mean build.log or
root.log.
-- 
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

Re: GCC 15 for Fedora 42 in a side-tag

[Siddhesh Poyarekar]

On 2025-01-16 07:22, Siddhesh Poyarekar wrote:

On 2025-01-15 20:46, Fabio Valentini wrote:

    TBH we haven't had enough time since upstream gcc stage 1 close to
    finish going through all the failures[1].  If only we had a week 
or two

    more for the mass rebuild; it got delayed by a couple of weeks last
    year
    and a similar delay would have helped this year too.


This might be a stupid question ... but if it would have helped you, 
then why wasn't a delay requested?


I had it in my TODO list to file a Fesco ticket for *future* even 
numbered Fedora, but I suppose I could have requested an additional week 
or so to file these issues even for F42.  Most of the packages succeeded 
so I figured we could use the stabilization period following the rebuild 
(as we would do in F39 and earlier) to help iron out the failures that 
we couldn't cover during the prebuild and avoid a schedule slippage.


I've filed this Fesco issue for future even numbered Fedora releases:

https://pagure.io/fesco/issue/3331

Sid

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

Re: rpmlint+readelf corrupted interpreter on generated binaries

[Carlos Rodriguez-Fernandez]

Now I recall, it was happening in Zulu CI for my package, and all I 
could do was to ignore it as known issue while waiting for the rpmlint 
update. No workaround.



On 1/15/25 8:33 AM, Carlos Rodriguez-Fernandez wrote:

Thank you Miro,

I was certain that I had sent a fix for that to rpmlint. The problem 
went away in my package in the CI (bodhi or Zulu, can't recall), 
perhaps rpmlint was updated for the affected CI back then or was 
removed from the gating/ci pipelines, or I removed rpmlint from the 
gating/ci. I don't recall what the solution was back then.



On 1/15/25 5:52 AM, Miro Hrončok wrote:

On 15. 01. 25 10:18, Robin Jarry wrote:

Hi folks,

I found out that rpmlint errors out without producing any meaningful 
result when the analyzed RPMs contain binaries:


 sh-5.2# strace -f -e trace=execve -s 65536 rpmlint 
build/RPMS/aerc-*.rpm

...
[pid   107] execve("/usr/bin/readelf", ["readelf", "-W", "-l", 
"/tmp/rpmlint.aerc-debuginfo-0.19.0-1.fc42.x86_64.rpm.5obt7_7n/usr/lib/debug/usr/bin/aerc-0.19.0-1.fc42.x86_64.debug", 
"--debug-dump=no-follow-links"], 0x7fe85e1a3590 /* 27 vars */) = 0

...
E: fatal error while reading 
aerc-debuginfo-0.19.0-1.fc42.x86_64.rpm: 'utf-8' codec can't decode 
byte 0xe4 in position 455: invalid continuation byte


...

Relevant package versions:

binutils-2.43.50-9.fc42.x86_64
file-5.45-8.fc42.x86_64
gcc-14.2.1-6.fc42.x86_64
rpmlint-2.5.0-10.fc42.x86_64

I suspect this is a bug in binutils/files which should not print 
binary code in lieu of the interpreter name. But maybe the culprit 
is in gcc.


If anyone has an idea, I'd like some help.


This should be fixed in rpmlint 2.6 currently available in rawhide.
I see you actually use rawhide, so just updating rpmlint should do.

https://github.com/rpm-software-management/rpmlint/issues/1147

https://bodhi.fedoraproject.org/updates/FEDORA-2025-59cc5ecf54

Pending (lack of) user feedback, I plan to update rpmlint in Fedora 
41 as well, after a while.




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

Re: List of long term FTBFS packages to be retired in 2 weeks

[Mikel Olasagasti]

Hau idatzi du Miro Hrončok (mhron...@redhat.com) erabiltzaileak (2025
urt. 15(a), az. (13:48)):

> golang-github-prometheus  @go-sig, fuller, mikelo2

https://src.fedoraproject.org/rpms/golang-github-prometheus/pull-request/2

I would merge it after https://pagure.io/fesco/issue/3330 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: Retiring python-nose from Fedora 43+

[Miro Hrončok]

On 06. 01. 25 12:45, Miro Hrončok wrote:

Hello,

I propose we retire python-nose from Fedora 43+ immediately after branching.

The package has been deprecated for 5 years:

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

It does not build with Python 3.14:

   https://bugzilla.redhat.com/2323163

We carry downstream-only patches since Python 3.5.

Currently, the following packages need it:

$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-nose --qf 
'%{name}.%{arch}'

...


The most dependent-upon packages in the list are:

  python-behave (affects 7 packages including self)
  vigra (4)


Due to a fix in the python-httpretty package which once again built it with 
tests:

https://src.fedoraproject.org/rpms/python-httpretty/pull-request/33

The dependency tree is now once again enormous and contains 1000+ packages.

Removing that dependency is now the top priority before nose can be removed.

--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

Re: Retiring python-nose from Fedora 43+

[Miro Hrončok]

On 16. 01. 25 13:29, Miro Hrončok wrote:

On 06. 01. 25 12:45, Miro Hrončok wrote:

Hello,

I propose we retire python-nose from Fedora 43+ immediately after branching.

The package has been deprecated for 5 years:

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

It does not build with Python 3.14:

   https://bugzilla.redhat.com/2323163

We carry downstream-only patches since Python 3.5.

Currently, the following packages need it:

$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-nose --qf 
'%{name}.%{arch}'

...


The most dependent-upon packages in the list are:

  python-behave (affects 7 packages including self)
  vigra (4)


Due to a fix in the python-httpretty package which once again built it with 
tests:

https://src.fedoraproject.org/rpms/python-httpretty/pull-request/33

The dependency tree is now once again enormous and contains 1000+ packages.

Removing that dependency is now the top priority before nose can be removed.

https://src.fedoraproject.org/rpms/python-httpretty/pull-request/34

--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Phillip Lougher]

Gao Xiang wrote:

> > By doing this they deliberately reduce the compression and speed of 
> > Squashfs in their tests.  This IMHO is biased and unethical.   But that is 
> > how it is.
> > Also if I were a random filesystem author, I will never argue just due to 
> > lack of development resource.

The insinuation here is that I'm that random filesystem author.  So I'm now 
getting personal attacks because I'm defending Squashfs.   How low will you go?

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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Phillip Lougher]

Neal Gompa wrote:

> > Thank you, I appreciate whatever you can do to make things better for
> our use-cases. :)

Well it is obvious where your bias 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: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Gao Xiang]

On 2025/1/17 14:26, Phillip Lougher wrote:

Gao Xiang wrote:


By doing this they deliberately reduce the compression and speed of Squashfs in 
their tests.  This IMHO is biased and unethical.   But that is how it is.
Also if I were a random filesystem author, I will never argue just due to lack 
of development resource.


The insinuation here is that I'm that random filesystem author.  So I'm now 
getting personal attacks because I'm defending Squashfs.


Why do you think it's a personal attack by `random`? Did I say SquashFS?

`lack of more development resource` is a common issue of the kernel
filesystem community as far as I know [1].  But I will not argue that
since that is the truth and I've always working on EROFS these years.

IOWs, I just said `I'm one of a filesystem author as other filesystems
in the world why it sounds not good to you?`


How low will you go?


Even considering I'm not a native speaker, I think it more sounds like
a personal attack to me.
I will just ignore this, since I've said I will just write code myself,
and catch the missing cases in my spare time.

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

Fedora rawhide compose report: 20250117.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20250116.n.0
NEW: Fedora-Rawhide-20250117.n.0

= SUMMARY =
Added images:12
Dropped images:  4
Added packages:  3
Dropped packages:1
Upgraded packages:   103
Downgraded packages: 0

Size of added packages:  942.14 KiB
Size of dropped packages:34.67 KiB
Size of upgraded packages:   874.31 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   7.23 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Disk-Rawhide-20250117.n.0.aarch64.raw.xz
Image: Python_Classroom raw-xz aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Disk-Rawhide-20250117.n.0.aarch64.raw.xz
Image: Budgie live x86_64
Path: Spins/x86_64/iso/Fedora-Budgie-Live-Rawhide-20250117.n.0.x86_64.iso
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20250117.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom vagrant-libvirt aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Vagrant-libvirt-Rawhide-20250117.n.0.aarch64.vagrant.libvirt.box
Image: Onyx bootable-container x86_64
Path: Onyx/x86_64/images/Fedora-Onyx-x86_64-Rawhide.20250117.n.0.ociarchive
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-VirtualBox-Rawhide-20250117.n.0.x86_64.vagrant.virtualbox.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-libvirt-Rawhide-20250117.n.0.x86_64.vagrant.libvirt.box
Image: COSMIC live aarch64
Path: Spins/aarch64/iso/Fedora-COSMIC-Live-Rawhide-20250117.n.0.aarch64.iso
Image: COSMIC live x86_64
Path: Spins/x86_64/iso/Fedora-COSMIC-Live-Rawhide-20250117.n.0.x86_64.iso
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20250117.n.0.x86_64.vagrant-libvirt.box
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20250117.n.0.iso

= DROPPED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20250116.n.0.iso
Image: Silverblue bootable-container ppc64le
Path: 
Silverblue/ppc64le/images/Fedora-Silverblue-ppc64le-Rawhide.20250116.n.0.ociarchive
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20250116.n.0.iso
Image: Kinoite bootable-container ppc64le
Path: 
Kinoite/ppc64le/images/Fedora-Kinoite-ppc64le-Rawhide.20250116.n.0.ociarchive

= ADDED PACKAGES =
Package: cockpit-image-builder-v54-1.fc42
Summary: Image builder plugin for Cockpit
RPMs:cockpit-image-builder
Size:582.64 KiB

Package: decibels-48.0~alpha-1.fc42
Summary: Audio player for the GNOME desktop
RPMs:decibels
Size:90.47 KiB

Package: python-avro-1.12.0-1.fc42
Summary: Python bindings for Apache Avro data serialization system
RPMs:python3-avro
Size:269.03 KiB


= DROPPED PACKAGES =
Package: php-wikimedia-avro-1.9.0-11.fc41
Summary: A library for using Avro with PHP
RPMs:php-wikimedia-avro
Size:34.67 KiB


= UPGRADED PACKAGES =
Package:  ShellCheck-0.10.0-4.fc42
Old package:  ShellCheck-0.10.0-3.fc41
Summary:  Shell script analysis tool
RPMs: ShellCheck ghc-ShellCheck ghc-ShellCheck-devel ghc-ShellCheck-doc 
ghc-ShellCheck-prof
Size: 64.89 MiB
Size change:  22.55 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
0.10.0-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild


Package:  aerc-0.19.0-1.fc42
Old package:  aerc-0.18.2-1.fc42
Summary:  Email client for your terminal
RPMs: aerc
Size: 21.18 MiB
Size change:  727.50 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
0.18.2-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Thu Jan 16 2025 Robin Jarry  - 0.19.0-1
  - Update to 0.19.0.


Package:  alacarte-3.54.1-1.fc42
Old package:  alacarte-3.54.0-1.fc42
Summary:  Menu editor for the GNOME desktop
RPMs: alacarte
Size: 177.62 KiB
Size change:  7.04 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
3.54.0-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Fri Jan 17 2025 Yaakov Selkowitz  - 3.54.1-1
  - Update to 3.54.1 (rhbz#2337387)


Package:  amdsmi-6.3.1-5.fc42
Old package:  amdsmi-6.3.1-3.fc42
Summary:  AMD System Management Interface
RPMs: amdsmi amdsmi-devel
Size: 852.90 KiB
Size change:  102.07 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
6.3.1-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Thu Jan 16 2025 Tom Rix  -6.3.1-5
  - Improve empty return patch
  - Fix shebangs


Package:  annobin-12.81-1.fc42
Old package:  annobin-12.80-2.fc42
Summary:  Annotate and examine compiled binary files
RPMs: annobin

Re: F42 Change Proposal: Deprecate Zezere Provisioning Server (IoT) (self-contained)

[Fabio Valentini]

On Thu, Jan 16, 2025 at 4:50 PM Vít Ondruch  wrote:
>
> Could you please elaborate what you mean by "deprecating"? My
> understanding is that you mark it deprecated following this guideline:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/#_marking_a_package_deprecated
>
> But maybe you considering retiring it entirely? Not sure.

"""
Deprecation will allow us to replace this configuration method
with something that is more robust, well tested and already installed
by default with `systemd`.
"""

This sounds like it should be a two-step process, with deprecation
first, and removal later?
But it would be good to have that explicit in the proposal, I agree.
If this proposal is about removing it, then calling it a "deprecation"
is misleading.

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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Neal Gompa]

On Thu, Jan 16, 2025 at 8:00 PM Gao Xiang  wrote:
>
> (resend this due to lack of subscription. and I just quote some reply to 
> express my basic ideas on this stuff)
>
> > There's one thing the EROFS developers never talk about, and that's 
> > metadata compression.  EROFS doesn't do it, but Squashfs does, and it has 
> > done since 2002.
>
> Did you notice that https://erofs.docs.kernel.org/en/latest/faq.html ?
>
> > The tests are all done in way to flater EROFS and put Squashfs in the worst 
> > light.  For example see 
> > https://erofs.docs.kernel.org/en/latest/comparsion/dedupe.html.  They 
> > deliberately disable Squashfs metadata compression because EROFS doesn't 
> > support it, and use 128K blocks despite Squashfs supporting 1Mbyte blocks 
> > (look for the line [1] SquashFS uses –b 131072 by default, -noI will 
> > disable its metadata compression.).
>
> It just shows that SquashFS doesn't support extent-based deduplication 
> (because SquashFS on-disk indexes just record compressed sizes and cannot be 
> randomly indexed), since EROFS doesn't support metadata compression so I 
> benchmarked against SquashFS and explicitly point out the metadata 
> compression is off on the SquashFS side to show the benefits of 
> deduplication.  Why it's called unbiased?
>
> Don't make me wrong, if -b 1048576 (1m chunks) is used, then the chunk 
> deduplication possibility is low.
> But not anyone cares image size (especially for smartphone) just by using 
> large extent sizes (like 1MiB) and real-time performance is important for 
> them, decompress 1MiB to get 4KiB random data is unacceptable for them.
>
> > By doing this they deliberately reduce the compression and speed of 
> > Squashfs in their tests.  This IMHO is biased and unethical.   But that is 
> > how it is.
>
> Also if I were a random filesystem author, I will never argue just due to 
> lack of development resource.
>
> Whether EROFS will use for Fedora LiveOS finally, honestly I don't care 
> (although I wish it could be used more widely), I will focus on new features 
> that end users really care and it's really an input.  I only care EROFS can 
> be totally usable on RHEL/CentOS since we have customers to use these OSes 
> and I will serve for their detailed use cases.
>
> Please note, EROFS was once proposed to resolve SquashFS unacceptable random 
> runtime performance issues on the high-performance Android scenerios, and 
> almost all smartphone vendors on the market use EROFS now.  As for other 
> scenarios, I would just call it as a plus.
>
> If users think metadata compression is useful to minimize their images, and I 
> will consider to add this in my spare time (Because it's never useful for my 
> paid job too, they even don't care about multithreaded compression).  Also I 
> did not ask random vendors to contribute EROFS, just because Bytedance or 
> other vendors need it and they develop new features for their use cases.
>

I certainly would appreciate features like metadata compression, BCJ
filters, and anything to improve image creation time when -Ededupe is
used. I also wanted to use zstd compression instead of lzma (since it
decompresses way faster), but the compression performance isn't quite
there yet.

Runtime speed is really valuable for us because typical media that
Linux live environments are running from are slower than even most
mobile device flash storage modules. At worst, we're talking about
actually booting from a DVD (which is still a thing people do in some
places), but we also need maximal space savings because of download
bandwidth and fitting on small media.



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Gao Xiang]

On 2025/1/17 09:14, Neal Gompa wrote:

On Thu, Jan 16, 2025 at 8:00 PM Gao Xiang  wrote:


(resend this due to lack of subscription. and I just quote some reply to 
express my basic ideas on this stuff)


There's one thing the EROFS developers never talk about, and that's metadata 
compression.  EROFS doesn't do it, but Squashfs does, and it has done since 
2002.


Did you notice that https://erofs.docs.kernel.org/en/latest/faq.html ?


The tests are all done in way to flater EROFS and put Squashfs in the worst 
light.  For example see 
https://erofs.docs.kernel.org/en/latest/comparsion/dedupe.html.  They 
deliberately disable Squashfs metadata compression because EROFS doesn't 
support it, and use 128K blocks despite Squashfs supporting 1Mbyte blocks (look 
for the line [1] SquashFS uses –b 131072 by default, -noI will disable its 
metadata compression.).


It just shows that SquashFS doesn't support extent-based deduplication (because 
SquashFS on-disk indexes just record compressed sizes and cannot be randomly 
indexed), since EROFS doesn't support metadata compression so I benchmarked 
against SquashFS and explicitly point out the metadata compression is off on 
the SquashFS side to show the benefits of deduplication.  Why it's called 
unbiased?

Don't make me wrong, if -b 1048576 (1m chunks) is used, then the chunk 
deduplication possibility is low.
But not anyone cares image size (especially for smartphone) just by using large 
extent sizes (like 1MiB) and real-time performance is important for them, 
decompress 1MiB to get 4KiB random data is unacceptable for them.


By doing this they deliberately reduce the compression and speed of Squashfs in 
their tests.  This IMHO is biased and unethical.   But that is how it is.


Also if I were a random filesystem author, I will never argue just due to lack 
of development resource.

Whether EROFS will use for Fedora LiveOS finally, honestly I don't care 
(although I wish it could be used more widely), I will focus on new features 
that end users really care and it's really an input.  I only care EROFS can be 
totally usable on RHEL/CentOS since we have customers to use these OSes and I 
will serve for their detailed use cases.

Please note, EROFS was once proposed to resolve SquashFS unacceptable random 
runtime performance issues on the high-performance Android scenerios, and 
almost all smartphone vendors on the market use EROFS now.  As for other 
scenarios, I would just call it as a plus.

If users think metadata compression is useful to minimize their images, and I 
will consider to add this in my spare time (Because it's never useful for my 
paid job too, they even don't care about multithreaded compression).  Also I 
did not ask random vendors to contribute EROFS, just because Bytedance or other 
vendors need it and they develop new features for their use cases.



I certainly would appreciate features like metadata compression, BCJ
filters, and anything to improve image creation time when -Ededupe is
used. I also wanted to use zstd compression instead of lzma (since it
decompresses way faster), but the compression performance isn't quite
there yet.


Since it's not my paid job, I will try my best to work them out in
my spare time.  But really, for our own use cases we don't care much
about them, it's also called "a labor of love".



Runtime speed is really valuable for us because typical media that
Linux live environments are running from are slower than even most
mobile device flash storage modules. At worst, we're talking about
actually booting from a DVD (which is still a thing people do in some
places), but we also need maximal space savings because of download
bandwidth and fitting on small media.


Anyway, EROFS was once specifically designed for Android devices
initially, I will try to make it work better for other useful cases,
questions, issues, and features are much helpful for me to improve
the filesystem itself.

Thanks,
Gao Xiang






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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Neal Gompa]

On Thu, Jan 16, 2025 at 8:28 PM Gao Xiang  wrote:
>
>
>
> On 2025/1/17 09:14, Neal Gompa wrote:
> > On Thu, Jan 16, 2025 at 8:00 PM Gao Xiang  
> > wrote:
> >>
> >> (resend this due to lack of subscription. and I just quote some reply to 
> >> express my basic ideas on this stuff)
> >>
> >>> There's one thing the EROFS developers never talk about, and that's 
> >>> metadata compression.  EROFS doesn't do it, but Squashfs does, and it has 
> >>> done since 2002.
> >>
> >> Did you notice that https://erofs.docs.kernel.org/en/latest/faq.html ?
> >>
> >>> The tests are all done in way to flater EROFS and put Squashfs in the 
> >>> worst light.  For example see 
> >>> https://erofs.docs.kernel.org/en/latest/comparsion/dedupe.html.  They 
> >>> deliberately disable Squashfs metadata compression because EROFS doesn't 
> >>> support it, and use 128K blocks despite Squashfs supporting 1Mbyte blocks 
> >>> (look for the line [1] SquashFS uses –b 131072 by default, -noI will 
> >>> disable its metadata compression.).
> >>
> >> It just shows that SquashFS doesn't support extent-based deduplication 
> >> (because SquashFS on-disk indexes just record compressed sizes and cannot 
> >> be randomly indexed), since EROFS doesn't support metadata compression so 
> >> I benchmarked against SquashFS and explicitly point out the metadata 
> >> compression is off on the SquashFS side to show the benefits of 
> >> deduplication.  Why it's called unbiased?
> >>
> >> Don't make me wrong, if -b 1048576 (1m chunks) is used, then the chunk 
> >> deduplication possibility is low.
> >> But not anyone cares image size (especially for smartphone) just by using 
> >> large extent sizes (like 1MiB) and real-time performance is important for 
> >> them, decompress 1MiB to get 4KiB random data is unacceptable for them.
> >>
> >>> By doing this they deliberately reduce the compression and speed of 
> >>> Squashfs in their tests.  This IMHO is biased and unethical.   But that 
> >>> is how it is.
> >>
> >> Also if I were a random filesystem author, I will never argue just due to 
> >> lack of development resource.
> >>
> >> Whether EROFS will use for Fedora LiveOS finally, honestly I don't care 
> >> (although I wish it could be used more widely), I will focus on new 
> >> features that end users really care and it's really an input.  I only care 
> >> EROFS can be totally usable on RHEL/CentOS since we have customers to use 
> >> these OSes and I will serve for their detailed use cases.
> >>
> >> Please note, EROFS was once proposed to resolve SquashFS unacceptable 
> >> random runtime performance issues on the high-performance Android 
> >> scenerios, and almost all smartphone vendors on the market use EROFS now.  
> >> As for other scenarios, I would just call it as a plus.
> >>
> >> If users think metadata compression is useful to minimize their images, 
> >> and I will consider to add this in my spare time (Because it's never 
> >> useful for my paid job too, they even don't care about multithreaded 
> >> compression).  Also I did not ask random vendors to contribute EROFS, just 
> >> because Bytedance or other vendors need it and they develop new features 
> >> for their use cases.
> >>
> >
> > I certainly would appreciate features like metadata compression, BCJ
> > filters, and anything to improve image creation time when -Ededupe is
> > used. I also wanted to use zstd compression instead of lzma (since it
> > decompresses way faster), but the compression performance isn't quite
> > there yet.
>
> Since it's not my paid job, I will try my best to work them out in
> my spare time.  But really, for our own use cases we don't care much
> about them, it's also called "a labor of love".
>

I understand this very well. Most of my FOSS work would fall in that
category too.

> >
> > Runtime speed is really valuable for us because typical media that
> > Linux live environments are running from are slower than even most
> > mobile device flash storage modules. At worst, we're talking about
> > actually booting from a DVD (which is still a thing people do in some
> > places), but we also need maximal space savings because of download
> > bandwidth and fitting on small media.
>
> Anyway, EROFS was once specifically designed for Android devices
> initially, I will try to make it work better for other useful cases,
> questions, issues, and features are much helpful for me to improve
> the filesystem itself.
>

Thank you, I appreciate whatever you can do to make things better for
our use-cases. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedorapro

Re: forwarding aliases (was: Non-responsive maintainer sham1)

[Daniel P . Berrangé]

On Wed, Jan 15, 2025 at 07:03:23PM +0100, Björn Persson wrote:
> Kevin Fenzi wrote:
> > On Wed, Jan 15, 2025 at 04:15:11PM +0100, Cristian Le via devel wrote:
> > > On 1/15/25 2:33 PM, Fabio Valentini wrote:
> > >   
> > > > No, AFAIK the @fedoraproject.org email alias should work for
> > > > all users who are in CLA+1 or something (so it should work for all
> > > > members of the "packager" group, for example, since signing the CLA is
> > > > prerequisite for joining the "packager" group).  
> > > 
> > > Indeed you are right, I have tried it out and something is setup there. 
> > > But
> > > the way it is setup guarantees it will break for most cases and it should 
> > > be
> > > discouraged.  
> > 
> > Well, it will break for senders who's mail domain sets reject on SPF and
> > who's recipient domain actually rejects those emails instead of just
> > marking them as less valid.
> > 
> > > I have tried to send a message from my work email to
> > > lec...@fedoraproject.org, and I got an SPF check failure. From the error
> > > message I see the failure is that @fedoraproject.org tries to
> > > impersonate the sender (in this case my work email) and the sender's SPF
> > > does not allow that IP address.  
> > 
> > Yeah, if your work email rejects such messages then indeed it will not
> > work in that case. 
> > 
> > Now, we could look at setting up some kind of rewriting thing that takes
> > the emails, rewrites them to come from some fedoraproject address and
> > set reply-to to the real sender. This would be a net new block of work
> > someone would have to implement, test, deploy and maintain it.
> 
> If it's only SPF, then it should be enough to use the forwarding
> server's own domain in the SMTP session, like list servers always do.
> SPF asks the receiving server to validate the hostname given in
> HELO/EHLO and the return address given in MAIL FROM in SMTP. A correct
> SPF implementation will only look at the SMTP envelope, not the email
> header.
> 
> The problems usually arise when the sender has a DMARC rule that forbids
> forwarding and the recipient enforces DMARC, because DMARC imposes
> requirements on the From field of the email header. That, I believe, is
> when this mailing list rewrites the From field, and the forwarding
> alias server would have to do the same. You can tell which posters have
> strict DMARC rules by the "via devel" that gets appended to their names.

NB, the "From" rewriting with "via devel" is generally only needed
if someone's domain has configured SPF and DMARC, but has *not* also
configured DKIM.

DMARC checks pass if either SPF or DKIM checks pass. So as long as
Fedora's forwarding logic *keeps* the existing DKIM signature, and
does not touch any part of the mail covered by the DKIM signature,
it shouldn't matter if SPF fails.

When debugging people's broken mail servers I usually end up
pointing them to this:

  https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html

NB Fedora could optionally also add its own DKIM signature, as long
as it preserves the senders original DKIM signature.

I would just say any domain with SPF + DMARC, but without DKIM just
has a broken mail config & not our problem. All use of mailing lists
is doomed in that scenario unless every list takes countermeasures
to rewrite From. Not worth the hassle for Fedora IMHO.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Neal Gompa]

On Thu, Jan 16, 2025 at 4:13 PM Phillip Lougher
 wrote:
>
> Neal Gompa wrote:
>
> > > It's mostly that it behaves more like a real filesystem. It uses
> > extents, supports inline compression, DAX, and other features that you
> > expect from advanced filesystems.
>
> That's just word salad.  Squashfs is a real filesystem, with real filesystems 
> techniques: inodes, extents, inline compression (I think you mean inline 
> decompression here).  In fact it has the features that EROFS has, and it has 
> had them for years.
>
> There's one thing the EROFS developers never talk about, and that's metadata 
> compression.  EROFS doesn't do it, but Squashfs does, and it has done since 
> 2002.
>
> In a supposedly technical proposal, I would have expected to see at the least:
>
> 1. Motivations and reasons for why it is necessary, including:
> 1.1 The current pain points with Squashfs.  Is there a problem with 
> compression size? Speed? Reliability?
> 1.2 The techniques that EROFS has that solves these problems.
> 1.3 Real world tests and benchmarking results that backup/illustrate the 
> problems and the solution.
>
> 2. A risk analysis of the possible consequences:
> 2.1 In real-world situations is EROFS less or more stable than Squashfs with 
> corrupted images.
> 2.2 Have you tested?  What were the results?  Undetected file corruption?, 
> kernel OOPses?, lockup?
>
> You say you have worked with the EROFS developers to improve compression.  I 
> see no dialogue or discussion with me, or on Squashfs websites/mailinglists 
> where you reached out to voice your issues/concerns with Squashfs and have 
> them addressed.   This strikes me as putting the cart before the horse, and 
> suggests the motivation is not driven by technical problems with Squashfs, 
> but because EROFS is seen as newer or there are politics involved, with 
> Squashfs being sucked into the Flatpak/Snap standoff.  I have absolutely 
> nothing to do with Canonical or Snaps.  If you don't want people to run Snaps 
> on Fedora, don't do it via the backdoor of deprecating and then disabling 
> Squashfs (I notice Squashfs is deprecated on RHEL 10 and is to be removed for 
> no discernible technical reason).
>

As I am one of the snap stack maintainers in Fedora and EPEL, I do not
care about this fight. I do know that the OCI world is adopting EROFS,
and Flatpak is getting sucked into that. I couldn't care less about
the Flatpak vs Snap thing, as I prefer to use neither. I use some
Flatpaks and snaps as I am required to, but otherwise prefer regular
packaging systems like RPM.

The initial driver for exploring the switch was because RHEL 10 is
dropping SquashFS support. My guess about that is that since the OCI
world and Red Hat's bootc are using EROFS (through composefs), they
want to consolidate things around it. I had also been previously
concerned about the long dry spell around squashfs-tools maintenance,
but that situation has improved in recent years.

No one is proposing to drop SquashFS in Fedora, certainly not me.

> > There's a lot more detail about it on the EROFS website:
> > https://erofs.docs.kernel.org/en/latest/
>
> If you believe everything that the EROFS developers claim then I've got a 
> bridge to sell you 
> (https://www.mylondon.news/news/nostalgia/ive-bridge-sell-you-conman-22497002).
>
> The tests are all done in way to flater EROFS and put Squashfs in the worst 
> light.  For example see 
> https://erofs.docs.kernel.org/en/latest/comparsion/dedupe.html.  They 
> deliberately disable Squashfs metadata compression because EROFS doesn't 
> support it, and use 128K blocks despite Squashfs supporting 1Mbyte blocks 
> (look for the line [1] SquashFS uses –b 131072 by default, -noI will disable 
> its metadata compression.).  By doing this they deliberately reduce the 
> compression and speed of Squashfs in their tests.  This IMHO is biased and 
> unethical.   But that is how it is.
>
> So far this proposal looks like something from the EROFS marketing department 
> and is remarkably light in motivations and technical detail.
>

I am aware of the bias. My tests were done with much more equivalent
settings. Kiwi built images have used 1MB blocks for quite some time
for squashfs, and I force the same block size for EROFS in our kiwi
definitions. Initially, EROFS was >50% larger than SquashFS and
getting it to comparable size would blow out the image build time by
5x. The EROFS developers noticed my comparisons and worked to improve
both compression and time to creation to make it possible to match
SquashFS.

As one of the upstream developers for the kiwi image build tool, I
have no intention of removing SquashFS support. It's perfectly fine
and usable. My only issue with it is that using unsquashfs to install
live environments causes the environment to freeze, which is not
great. This doesn't affect Anaconda, but it does affect Calamares
(which Fedora itself does not use).

And EROFS does have a couple of downsides right now for the 

Re: forwarding aliases (was: Non-responsive maintainer sham1)

[Kevin Fenzi]

Note: we are talking about @fedoraproject.org aliases here.
mailing lists already mitigate this as you note.

On Thu, Jan 16, 2025 at 10:11:22PM +, Daniel P. Berrangé wrote:
> 
> NB, the "From" rewriting with "via devel" is generally only needed
> if someone's domain has configured SPF and DMARC, but has *not* also
> configured DKIM.
> 
> DMARC checks pass if either SPF or DKIM checks pass. So as long as
> Fedora's forwarding logic *keeps* the existing DKIM signature, and
> does not touch any part of the mail covered by the DKIM signature,
> it shouldn't matter if SPF fails.

I'd have to look if this is the case in alias expansion or not.
> 
> When debugging people's broken mail servers I usually end up
> pointing them to this:
> 
>   https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html
> 
> NB Fedora could optionally also add its own DKIM signature, as long
> as it preserves the senders original DKIM signature.

Yes, but for lists we add footers and other things, so the orig 
signature is bad already. But it doesn't matter as for mailing lists we
sign with our own DKIM.

> I would just say any domain with SPF + DMARC, but without DKIM just
> has a broken mail config & not our problem. All use of mailing lists
> is doomed in that scenario unless every list takes countermeasures
> to rewrite From. Not worth the hassle for Fedora IMHO.

mailing lists, IMHO, are fine. They mitigate things.

email aliases however, do not.

kevin


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

Re: forwarding aliases

[Tom Hughes via devel]

On 16/01/2025 22:11, Daniel P. Berrangé wrote:


NB, the "From" rewriting with "via devel" is generally only needed
if someone's domain has configured SPF and DMARC, but has *not* also
configured DKIM.

DMARC checks pass if either SPF or DKIM checks pass. So as long as
Fedora's forwarding logic *keeps* the existing DKIM signature, and
does not touch any part of the mail covered by the DKIM signature,
it shouldn't matter if SPF fails.


Except that most mailing lists, and certainly this one, do touch
parts of the mail covered by the DKIM signature when they add the
list information to the bottom of each message.

It also strips the original DKIM signature so even if it didn't
modify the body things still wouldn't pass.

Tom

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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Gao Xiang]

(resend this due to lack of subscription. and I just quote some reply to 
express my basic ideas on this stuff)


There's one thing the EROFS developers never talk about, and that's metadata 
compression.  EROFS doesn't do it, but Squashfs does, and it has done since 
2002.


Did you notice that https://erofs.docs.kernel.org/en/latest/faq.html ?


The tests are all done in way to flater EROFS and put Squashfs in the worst 
light.  For example see 
https://erofs.docs.kernel.org/en/latest/comparsion/dedupe.html.  They 
deliberately disable Squashfs metadata compression because EROFS doesn't 
support it, and use 128K blocks despite Squashfs supporting 1Mbyte blocks (look 
for the line [1] SquashFS uses –b 131072 by default, -noI will disable its 
metadata compression.).


It just shows that SquashFS doesn't support extent-based deduplication (because 
SquashFS on-disk indexes just record compressed sizes and cannot be randomly 
indexed), since EROFS doesn't support metadata compression so I benchmarked 
against SquashFS and explicitly point out the metadata compression is off on 
the SquashFS side to show the benefits of deduplication.  Why it's called 
unbiased?

Don't make me wrong, if -b 1048576 (1m chunks) is used, then the chunk 
deduplication possibility is low.
But not anyone cares image size (especially for smartphone) just by using large 
extent sizes (like 1MiB) and real-time performance is important for them, 
decompress 1MiB to get 4KiB random data is unacceptable for them.


By doing this they deliberately reduce the compression and speed of Squashfs in 
their tests.  This IMHO is biased and unethical.   But that is how it is.


Also if I were a random filesystem author, I will never argue just due to lack 
of development resource.

Whether EROFS will use for Fedora LiveOS finally, honestly I don't care 
(although I wish it could be used more widely), I will focus on new features 
that end users really care and it's really an input.  I only care EROFS can be 
totally usable on RHEL/CentOS since we have customers to use these OSes and I 
will serve for their detailed use cases.

Please note, EROFS was once proposed to resolve SquashFS unacceptable random 
runtime performance issues on the high-performance Android scenerios, and 
almost all smartphone vendors on the market use EROFS now.  As for other 
scenarios, I would just call it as a plus.

If users think metadata compression is useful to minimize their images, and I 
will consider to add this in my spare time (Because it's never useful for my 
paid job too, they even don't care about multithreaded compression).  Also I 
did not ask random vendors to contribute EROFS, just because Bytedance or other 
vendors need it and they develop new features for their use cases.

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

Re: forwarding aliases (was: Non-responsive maintainer sham1)

[Kevin Fenzi]

On Wed, Jan 15, 2025 at 07:03:23PM +0100, Björn Persson wrote:
> 
> If it's only SPF, then it should be enough to use the forwarding
> server's own domain in the SMTP session, like list servers always do.
> SPF asks the receiving server to validate the hostname given in
> HELO/EHLO and the return address given in MAIL FROM in SMTP. A correct
> SPF implementation will only look at the SMTP envelope, not the email
> header.

Note that this is again just an alias, there's no other processing.
So, it goes:

pers...@a.com -> (mimecast) -> fedoraproject.org 
alias is expanded
fedoraproject.org -> pers...@b.com

so if a.com has a 'reject' rule, and b.com actually pays attention to
that it will reject/do whatever it wants with the email from
pers...@a.com.

> The problems usually arise when the sender has a DMARC rule that forbids
> forwarding and the recipient enforces DMARC, because DMARC imposes
> requirements on the From field of the email header. That, I believe, is
> when this mailing list rewrites the From field, and the forwarding
> alias server would have to do the same. You can tell which posters have
> strict DMARC rules by the "via devel" that gets appended to their names.

Right. 

I don't know of any existing software setup that does this, so
one would have to be written. :) (not me).

kevin


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

Re: rpmlint+readelf corrupted interpreter on generated binaries

[Mark Wielaard]

Hi! (Added nickc to the CC, see below)

On Wed, Jan 15, 2025 at 01:52:24PM +0100, Miro Hrončok wrote:
> On 15. 01. 25 10:18, Robin Jarry wrote:
> >I found out that rpmlint errors out without producing any meaningful result 
> >when the analyzed RPMs contain binaries:
> >
> > sh-5.2# strace -f -e trace=execve -s 65536 rpmlint 
> >build/RPMS/aerc-*.rpm
> >...
> >[pid   107] execve("/usr/bin/readelf", ["readelf", "-W", "-l", 
> >"/tmp/rpmlint.aerc-debuginfo-0.19.0-1.fc42.x86_64.rpm.5obt7_7n/usr/lib/debug/usr/bin/aerc-0.19.0-1.fc42.x86_64.debug",
> > "--debug-dump=no-follow-links"], 0x7fe85e1a3590 /* 27 vars */) = 0
> >...
> >E: fatal error while reading aerc-debuginfo-0.19.0-1.fc42.x86_64.rpm: 
> >'utf-8' codec can't decode byte 0xe4 in position 455: invalid continuation 
> >byte
> >
> >...
> >
> >Relevant package versions:
> >
> >binutils-2.43.50-9.fc42.x86_64
> >file-5.45-8.fc42.x86_64
> >gcc-14.2.1-6.fc42.x86_64
> >rpmlint-2.5.0-10.fc42.x86_64
> >
> >I suspect this is a bug in binutils/files which should not print binary code 
> >in lieu of the interpreter name. But maybe the culprit is in gcc.
> >
> >If anyone has an idea, I'd like some help.
> 
> This should be fixed in rpmlint 2.6 currently available in rawhide.
> I see you actually use rawhide, so just updating rpmlint should do.
> 
> https://github.com/rpm-software-management/rpmlint/issues/1147

I think that helps rpmlint not error out, so good!
But I also think this is a bug in binutils readelf (CCing nickc).

It really should not even try to print the "interpreter" of a separate
debuginfo file. For elfutils eu-readelf we have the following comment
(and code) to prevent printing gibberish for the interpreter when we
see a PT_INTERP segment:

  /* If we are sure the file offset is valid then we can show
 the user the name of the interpreter.  We check whether
 there is a section at the file offset.  Normally there
 would be a section called ".interp".  But in separate
 .debug files it is a NOBITS section (and so doesn't match
 with gelf_offscn).  Which probably means the offset is
 not valid another reason could be because the ELF file
 just doesn't contain any section headers, in that case
 just play it safe and don't display anything.  */

Cheers,

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

Re: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)

[Phillip Lougher]

Neal Gompa wrote:

> > It's mostly that it behaves more like a real filesystem. It uses
> extents, supports inline compression, DAX, and other features that you
> expect from advanced filesystems.

That's just word salad.  Squashfs is a real filesystem, with real filesystems 
techniques: inodes, extents, inline compression (I think you mean inline 
decompression here).  In fact it has the features that EROFS has, and it has 
had them for years.

There's one thing the EROFS developers never talk about, and that's metadata 
compression.  EROFS doesn't do it, but Squashfs does, and it has done since 
2002.

In a supposedly technical proposal, I would have expected to see at the least:

1. Motivations and reasons for why it is necessary, including:
1.1 The current pain points with Squashfs.  Is there a problem with compression 
size? Speed? Reliability?
1.2 The techniques that EROFS has that solves these problems.
1.3 Real world tests and benchmarking results that backup/illustrate the 
problems and the solution.

2. A risk analysis of the possible consequences:
2.1 In real-world situations is EROFS less or more stable than Squashfs with 
corrupted images.
2.2 Have you tested?  What were the results?  Undetected file corruption?, 
kernel OOPses?, lockup?

You say you have worked with the EROFS developers to improve compression.  I 
see no dialogue or discussion with me, or on Squashfs websites/mailinglists 
where you reached out to voice your issues/concerns with Squashfs and have them 
addressed.   This strikes me as putting the cart before the horse, and suggests 
the motivation is not driven by technical problems with Squashfs, but because 
EROFS is seen as newer or there are politics involved, with Squashfs being 
sucked into the Flatpak/Snap standoff.  I have absolutely nothing to do with 
Canonical or Snaps.  If you don't want people to run Snaps on Fedora, don't do 
it via the backdoor of deprecating and then disabling Squashfs (I notice 
Squashfs is deprecated on RHEL 10 and is to be removed for no discernible 
technical reason).

> There's a lot more detail about it on the EROFS website:
> https://erofs.docs.kernel.org/en/latest/

If you believe everything that the EROFS developers claim then I've got a 
bridge to sell you 
(https://www.mylondon.news/news/nostalgia/ive-bridge-sell-you-conman-22497002).

The tests are all done in way to flater EROFS and put Squashfs in the worst 
light.  For example see 
https://erofs.docs.kernel.org/en/latest/comparsion/dedupe.html.  They 
deliberately disable Squashfs metadata compression because EROFS doesn't 
support it, and use 128K blocks despite Squashfs supporting 1Mbyte blocks (look 
for the line [1] SquashFS uses –b 131072 by default, -noI will disable its 
metadata compression.).  By doing this they deliberately reduce the compression 
and speed of Squashfs in their tests.  This IMHO is biased and unethical.   But 
that is how it is.

So far this proposal looks like something from the EROFS marketing department 
and is remarkably light in motivations and technical detail.

Phillip

---
Dr. Phillip Lougher (Squashfs author and maintainer)
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue