Re: Closing most games (chroimumBSU etc) causes a reset of gnome in Tue Mar 5 on Fedora 41 (rawhide)

[Hans de Goede]

Hi Ryan,

On 3/6/24 02:44, Ryan Bach via devel wrote:
> Anyone else open a bug on this yet?

I guess this bug might be related:

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

I wonder if this is the same gnome-shell crash which I have reported as:

https://gitlab.gnome.org/GNOME/mutter/-/issues/3329

Can you check in "journalctl --user" if you see a
"libmutter:ERROR:../src/x11/group.c:76:meta_group_new: assertion failed: 
(g_hash_table_lookup (x11_display->groups_by_leader, _leader) == NULL)"

message in there ?

If you this likely is the same issue.

Also can you reproduce this at will, that is does closing
e.g. ChromiumBSU cause the crash every time ?

If this is the same issue and if it reproduces at will
for you please add the reproduction instructions to:

https://gitlab.gnome.org/GNOME/mutter/-/issues/3329

Regards,

Hans

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

Re: Looking for a new maintainer for ode

[Hans de Goede]

Hi Gwyn,

On 2/1/24 17:08, Gwyn Ciesla via devel wrote:
> Hi! I'd be happy to take ode, Xaw3d, and libcddb.

Great, thank you. I have handed over ownership
of all three packages to you now.

> Thank you for everything over the years. :)

You're welcome.

Regards,

Hans




> On Tuesday, January 30th, 2024 at 4:15 AM, Hans de Goede 
>  wrote:
> 
>> Hi All,
>>
> 
>> I used to do a lot of gaming related Fedora packaging and I still maintain
>> over 200 pkgs, but I really don't have much time for Fedora package
>> maintainership anymore.
>>
> 
>> The last few years I have been limiting my package maintainership
>> to fixing FTBFS, which for many game packages is fine since they
>> are not seeing any new upstream releases.
>>
> 
>> ode is currently 1 minor release behing the latest upstream release
>> and I don't have the time to fix it (since this is just a minor bump
>> the rebase should be trivial):
>>
> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=2218304
>>
> 
>> Anyone interested in taking over ode maintainership from me ?
>>
> 
>> Regards,
>>
> 
>> Hans
>>
> 
>>
> 
>>
> 
>>
> 
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Looking for new maintainer for widelands

[Hans de Goede]

Hi,

On 1/30/24 19:23, Peter Hanecak wrote:
> Hello,
> 
> I'll take the widelands package.

Great thank you. Can you let me know your FAS username
please ?  Then I'll give the package to you.

Regards,

Hans




> On 1/30/24 11:17, Hans de Goede wrote:
>> Hi All,
>>
>> I used to do a lot of gaming related Fedora packaging and I still maintain
>> over 200 pkgs, but I really don't have much time for Fedora package
>> maintainership anymore.
>>
>> The last few years I have been limiting my package maintainership
>> to fixing FTBFS, which for many game packages is fine since they
>> are not seeing any new upstream releases.
>>
>> Widelands however still has an active upstream and 6 months ago
>> a new version was released. I have been unable to find the time
>> to upgrade to this new release and I don't expect I will find
>> the time to do so in the near future.
>>
>> So I hope someone else is willing to takeover as maintainer ?
>>
>> Regards,
>>
>> Hans
>>
>> -- 
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>>
> -- 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Looking for a new maintainer for libcddb (used by vlc, qmmp, ...)

[Hans de Goede]

Hi Neal,

On 1/30/24 12:03, Neal Gompa wrote:
> On Tue, Jan 30, 2024 at 9:33 AM Hans de Goede  wrote:
>>
>> Hi All,
>>
>> After the recent filing of FTBFS bugs I noticed that I'm somehow
>> still the maintainer for libcddb.
>>
>> I guess I never asked anyone to takeover since it has seen very
>> little activity (nor bugs filed against it) the last few years.
>>
>> I really don't have much time for Fedora package maintainership
>> anymore, so I would appreciate it if someone can takeover
>> maintainership and fix the FTBFS bug:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2261305
>>
>> Note that is the only open bug against libcddb.
>>
> 
> While I'm not sure I can take it on myself, I would ask that you add
> the multimedia-sig with commit/admin privileges so that there can be
> shared maintenance of this (as other multimedia packages are
> increasingly co-maintained by the SIG now).

Ok, I have given the multimedia-sig group admin privileges now.

Regards,

Hans

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

Re: Looking for new maintainer for boswars

[Hans de Goede]

Hi,

On 1/30/24 13:55, Sandro wrote:
> On 30-01-2024 13:33, Hans de Goede wrote:
>> Hi Sandro,
>>
>> On 1/30/24 12:48, Sandro wrote:
>>> On 30-01-2024 10:41, Hans de Goede wrote:
>>>> I used to do a lot of gaming related Fedora packaging and I still maintain
>>>> over 200 pkgs, but I really don't have much time for Fedora package
>>>> maintainership anymore.
>>>
>>> Many thanks! I'm sure many still enjoy the fruits of your labor.
>>>
>>>> The last few years I have been limiting my package maintainership
>>>> to fixing FTBFS, which for many game packages is fine since they
>>>> are not seeing any new upstream releases.
>>>>
>>>> Boswars however still has an active upstream and 6 months ago
>>>> a new version was released. I have been unable to find the time
>>>> to upgrade to this new release and I don't expect I will find
>>>> the time to do so in the near future.
>>>>
>>>> So I hope someone else is willing to takeover as maintainer,
>>>> if not then I'll have to orphan boswars.
>>>
>>> I'd be willing to give that a shot. As always, co-maintainers are more than 
>>> welcome.
>>
>> Great thank you. If you can give me your FAS username then
>> I can hand over the package to you and you can merge your PR
>> yourself :)
> 
> Sure. My FAS username is gui1ty. It was mentioned in my signature ;)

Ah yes now that you mention it I see it :)

Thank you for taking over boswars from me.

I have given the package to you now, making you the main admin.

Regards,

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

Re: Looking for new maintainer for boswars

[Hans de Goede]

Hi Sandro,

On 1/30/24 12:48, Sandro wrote:
> On 30-01-2024 10:41, Hans de Goede wrote:
>> I used to do a lot of gaming related Fedora packaging and I still maintain
>> over 200 pkgs, but I really don't have much time for Fedora package
>> maintainership anymore.
> 
> Many thanks! I'm sure many still enjoy the fruits of your labor.
> 
>> The last few years I have been limiting my package maintainership
>> to fixing FTBFS, which for many game packages is fine since they
>> are not seeing any new upstream releases.
>>
>> Boswars however still has an active upstream and 6 months ago
>> a new version was released. I have been unable to find the time
>> to upgrade to this new release and I don't expect I will find
>> the time to do so in the near future.
>>
>> So I hope someone else is willing to takeover as maintainer,
>> if not then I'll have to orphan boswars.
> 
> I'd be willing to give that a shot. As always, co-maintainers are more than 
> welcome.

Great thank you. If you can give me your FAS username then
I can hand over the package to you and you can merge your PR
yourself :)

Regards,

Hans

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

Looking for new maintainer for widelands

[Hans de Goede]

Hi All,

I used to do a lot of gaming related Fedora packaging and I still maintain
over 200 pkgs, but I really don't have much time for Fedora package
maintainership anymore.

The last few years I have been limiting my package maintainership
to fixing FTBFS, which for many game packages is fine since they
are not seeing any new upstream releases.

Widelands however still has an active upstream and 6 months ago
a new version was released. I have been unable to find the time
to upgrade to this new release and I don't expect I will find
the time to do so in the near future.

So I hope someone else is willing to takeover as maintainer ?

Regards,

Hans

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

Looking for a new maintainer for ode

[Hans de Goede]

Hi All,

I used to do a lot of gaming related Fedora packaging and I still maintain
over 200 pkgs, but I really don't have much time for Fedora package
maintainership anymore.

The last few years I have been limiting my package maintainership
to fixing FTBFS, which for many game packages is fine since they
are not seeing any new upstream releases.

ode is currently 1 minor release behing the latest upstream release
and I don't have the time to fix it (since this is just a minor bump
the rebase should be trivial):

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

Anyone interested in taking over ode maintainership from me ?

Regards,

Hans




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

Looking for a new maintainer for Xaw3d

[Hans de Goede]

Hi All,

I used to do a lot of gaming related Fedora packaging and I still maintain
over 200 pkgs, but I really don't have much time for Fedora package
maintainership anymore.

The last few years I have been limiting my package maintainership
to fixing FTBFS, which for many game packages is fine since they
are not seeing any new upstream releases.

Xaw3d is currently 1 minor release behing the latest upstream release
and I don't have the time to fix it (since this is just a minor bump
the rebase should be trivial).

Anyone interested in taking over Xaw3d maintainership from me ?

Regards,

Hans


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

Looking for a new maintainer for adanaxisgpl

[Hans de Goede]

Hi All,

I used to do a lot of gaming related Fedora packaging and I still maintain
over 200 pkgs, but I really don't have much time for Fedora package
maintainership anymore.

The last few years I have been limiting my package maintainership
to fixing FTBFS, which for many game packages is fine since they
are not seeing any new upstream releases.

adanaxisgpl has had a bug open against it to port its pcre use
from pcre to pcre2, which needs to be fixed before F41 I believe:

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

I don't have the time to fix it, so I'm looking for a new maintainer ?

Regards,

Hans


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

Looking for a new maintainer for scorched3d

[Hans de Goede]

Hi All,

I used to do a lot of gaming related Fedora packaging and I still maintain
over 200 pkgs, but I really don't have much time for Fedora package
maintainership anymore.

The last few years I have been limiting my package maintainership
to fixing FTBFS, which for many game packages is fine since they
are not seeing any new upstream releases.

scorched3d however has been broken for a while now (it does not start)
and I don't have the time to fix it.

If someone wants to takeover I would first try to get it to work under
Xorg, and then Xwayland by setting the SDL videodriver env. variable
(IIRC that it uses SDL) and only then try to make it work under wayland.

There is at least the well known Wayland GLEW issues, to fix this
you can use something like this:

https://src.fedoraproject.org/rpms/quesoglc/blob/rawhide/f/quesoglc-0.7.2-wayland.patch

Regards,

Hans

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

Looking for new maintainer for boswars

[Hans de Goede]

Hi All,

I used to do a lot of gaming related Fedora packaging and I still maintain
over 200 pkgs, but I really don't have much time for Fedora package
maintainership anymore.

The last few years I have been limiting my package maintainership
to fixing FTBFS, which for many game packages is fine since they
are not seeing any new upstream releases.

Boswars however still has an active upstream and 6 months ago
a new version was released. I have been unable to find the time
to upgrade to this new release and I don't expect I will find
the time to do so in the near future.

So I hope someone else is willing to takeover as maintainer,
if not then I'll have to orphan boswars.

Note boswars is currently also FTBFS I don't know if the new
upstream release will fix this, but I would start with rebasing
to the new upstream release.

There also is one ABRT bug when can be closed when updating
to the new release since the backtrace will be invalid for
the new version.

Regards,

Hans


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

Looking for a new maintainer for libcddb (used by vlc, qmmp, ...)

[Hans de Goede]

Hi All,

After the recent filing of FTBFS bugs I noticed that I'm somehow
still the maintainer for libcddb.

I guess I never asked anyone to takeover since it has seen very
little activity (nor bugs filed against it) the last few years.

I really don't have much time for Fedora package maintainership
anymore, so I would appreciate it if someone can takeover
maintainership and fix the FTBFS bug:

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

Note that is the only open bug against libcddb.

Regards,

Hans

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

Re: Fwd: [F39 Beta] x86-64 Plymouth causes screen to stay black after boot

[Hans de Goede]

Hi Vinzenz,

On 10/26/23 23:02, Vinzenz Feenstra wrote:
> Hi,
> 
> After I upgraded an old netbook of mine to Fedora 39, the screen stays black 
> after the boot into multi-user.target is completed.
> Now I cannot see anything on the screen, however I can access the machine via 
> SSH.
> 
> I had a hunch that plymouth might be the reason for this behaviour, so i 
> removed the plymouth packages from the system and rebooted. Now the boot 
> completes and I can see the screen.
> 
> Now long story short, I need some help to investigate what caused this, so I 
> can file a proper report. I cannot seem to find anything useful, but I am 
> willing to investigate what was the reason for this.
> 
> Per DNF log I removed these packages:
> 
> 2023-10-26T22:32:22+0200 DEBUG Removed: plymouth-22.02.122-5.fc39.x86_64
> 2023-10-26T22:32:22+0200 DEBUG Removed: 
> plymouth-core-libs-22.02.122-5.fc39.x86_64
> 2023-10-26T22:32:22+0200 DEBUG Removed: 
> plymouth-scripts-22.02.122-5.fc39.x86_64

Hmm, did you also re-generated your initrd after this; or do a kernel ugprade ?

To help get to the bottom of this more information is needed. For starters:

1. Which desktop environment are you running, or are you booting into text mode 
directly?
2. What are the vendor and model of the netbook?
3. Can you collect dmesg output with F39, run: "dmesg > dmesg.txt" shorlty 
after booting the system and then attach dmesg.txt to a private email to me ?
4. Can you try re-installing plymouth (and run "sudo dracut -f" to regenerate 
the initrd) and then add: "plymouth.debug=stream:/dev/null" to your kernel 
commandline. And then reboot and after rebooting collect 
/var/log/plymouth-debug.log and attach it to a private email to me ?

Regards,

Hans


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

Re: Missing boot options - who is to blame?

[Hans de Goede]

Hi,

On 8/25/23 22:05, Alexander Ploumistos wrote:
> On Fri, Aug 25, 2023 at 7:27 PM Hans de Goede  wrote:
>>
>> If there is a /etc/kernel/cmdline file then that will be used
>> for the generated /boot/loader/entries/*.conf files.
>>
>> (I was recently bitten by this myself)
> 
> Yes, there is and its contents are those of the problematic
> /boot/loader/entries/*.conf files. Should I delete it?

I think that if you delete it the contents of new entries
will be grabbed from /proc/cmdline of the running kernel
(I think).

Alternatively you can put the cmdline which you actually
want inside that file. That is what I've done to fix
a similar issue.

> # rpm -qf /etc/kernel/cmdline
> file /etc/kernel/cmdline is not owned by any package
> 
> Where does it come from?

I think it is generated by grubby, not sure why / when
though.

Regards,

Hans

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

Re: Missing boot options - who is to blame?

[Hans de Goede]

Hi,

On 8/25/23 17:53, Alexander Ploumistos wrote:
> Hello,
> 
> On one of my computers, for the last couple of kernel updates I'm not
> getting the proper options in the corresponding *.conf files in
> /boot/loader/entries. Some of the options specified in
> /etc/default/grub are there, but anything related to the root
> partition and some other options are consistently being left out,
> which results in a machine unable to boot, until I manually add the
> uuids and everything else that's missing.
> In the past I knew that grubby took care of these things, but some
> rather recent threads here have suggested this is no longer the case.
> Against which component should I file a bug report? It's an F38,
> Workstation edition.

If there is a /etc/kernel/cmdline file then that will be used
for the generated /boot/loader/entries/*.conf files.

(I was recently bitten by this myself)

Regards,

Hans


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

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

[Hans de Goede]

Hi,

On 7/25/23 15:52, Mikolaj Izdebski wrote:
> On Tue, Jul 25, 2023 at 2:48 PM Hans de Goede  wrote:
> 
>>> xmvn-connector-ivymizdebsk
>>
>> This one has a long long list of deps which will break if it is
>> retired and there is a pull-req here fixing the FTBFS:
>>
>> https://src.fedoraproject.org/rpms/xmvn-connector-ivy/pull-request/2
>>
>> Are there any objections against solving it with the rebase to
>> a newer git snapshot (it already is a git snapshot) ?
>>
>> If not then I'll use my proven-packager rights to get this
>> pull-request merge and close the FTBFS bug.
>>
>> Mikolaj any objections against merging the pull-request ?
> 
> I made a new upstream release of version 4.0.0 and updated the package
> to the latest version.
> Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-41256115ad

Great, thank you!

Regards,

Hans


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

Orphaning jansi-native jansi1 jline2 and bsh

[Hans de Goede]

Hi All,

jansi-native depends on hawtjni which is unmaintained and will no longer build 
after the maven2 to moven3 upgrade. Not having jansi-native will also break 
jansi1 -> jline2 -> bsh all of which are currently maintained by me.

I no longer have a need for any of these pkgs so I'm orphaning them.

jansi-native and jansi1 have no other packages directly depending on them.

jline2 is used by:

frysk (cagney)
picocli-shell-jline2 (didiksupriadi41)

bsh is used by:

jmock (didiksupriadi41)
maven-invoker-plugin (korkeala)
maven-script-interpreter (korkeala)

Note this is based on a repoquery on F38 x86_64 and if you want to take over
these packages because you depend upon them you will also need to take over
and somehow fix hawtjni or maybe you can just drop the jline2 dependency from
your packages or from bsh (if posssible).

Regards,

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

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

[Hans de Goede]

Hi all,

On 7/25/23 14:24, Miro Hrončok wrote:
> Dear maintainers.
> 
> Based on the current fail to build from source policy, the following packages
> should be retired from Fedora 39 approximately one week before branching.
> 
> 5 weekly reminders are required, hence the retirement will happen
> approximately in 2 weeks, i.e. around 2023-08-01.
> 
> Policy: 
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
> 
> The packages in rawhide were not successfully built at least since Fedora 36.
> 
> This report is based on dist tags.
> 
> Packages collected via:
> https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
> 
> If you see a package that was built, please let me know.
> If you see a package that should be exempted from the process,
> please let me know and we can work together to get a FESCo approval for that.
> 
> If you see a package that can be rebuilt, please do so.
> 
>     Package   (co)maintainers
> 
> DecodeIR  leamas
> apache-commons-fileupload jerboaa, jjelen, mizdebsk, spike
> avarice   lucilanga
> burp  cicku, kaptk2
> clang12   tstellar
> cvise mpolacek
> emacs-common-ess  alexlan, jamatos
> fasttext  kenhys
> glibc32   codonell, fweimer, jakub, mcermak
> golang-github-burntsushi-xgbutil  eclipseo, go-sig
> golang-github-chifflier-nfqueue   fab, go-sig
> golang-github-cupcake-rdb eclipseo, go-sig
> golang-github-d5-tengo-2  fab, go-sig
> golang-github-docker-slim eclipseo, go-sig
> golang-github-facebookarchive-inject  agerstmayr, go-sig, mgoodwin, 
> nathans
> golang-github-facebookarchive-structtag   agerstmayr, go-sig, mgoodwin, 
> nathans
> golang-github-facebookgo-clock    eclipseo, go-sig
> golang-github-facebookgo-ensure   dcavalca, go-sig
> golang-github-facebookgo-httpdown go-sig, orphan
> golang-github-facebookgo-stack    dcavalca, go-sig
> golang-github-facebookgo-stats    go-sig, orphan
> golang-github-fonts-dejavu    go-sig, orphan
> golang-github-ghemawat-stream eclipseo, go-sig
> golang-github-google-tspi go-sig, orphan
> golang-github-gorp-3  dcavalca, go-sig
> golang-github-haproxytech-models  bdperkin, go-sig
> golang-github-influxdata-tdigest  go-sig, orphan
> golang-github-jackc-pgproto3  eclipseo, go-sig
> golang-github-jackc-pgservicefile eclipseo, go-sig
> golang-github-michaeltjones-walk  go-sig, orphan
> golang-github-nkovacs-streamquote eclipseo, go-sig
> golang-github-phpdave11-gofpdi    go-sig, orphan
> golang-github-powerman-check  eclipseo, go-sig
> golang-github-quay-clair-3    eclipseo, go-sig
> golang-github-remind101-migrate   eclipseo, go-sig
> golang-github-tj-buffer   go-sig, orphan
> golang-github-vmihailenco-msgpack go-sig, orphan
> golang-github-vmware-vmw-guestinfo    eclipseo, go-sig
> golang-github-wsxiaoys-terminal   go-sig, orphan
> golang-github-x-cray-logrus-prefixed-formatter  dcavalca, go-sig
> golang-github-zmap-zlint  eclipseo, go-sig
> golang-github-zmap-zlint-2    go-sig, orphan
> golang-go4    eclipseo, go-sig, jchaloup
> golang-gopkg-redis-2  go-sig, orphan
> golang-gopkg-retry-1  eclipseo, go-sig
> golang-gopkg-seborama-govcr-2 go-sig, qulogic
> golang-gopkg-sourcemap-1  eclipseo, go-sig, jchaloup
> golang-gvisor eclipseo, elmarco, go-sig
> golang-k8s-legacy-cloud-providers go-sig, orphan
> golang-rsc-qr go-sig, qulogic
> golang-sigs-k8s-kustomize dcavalca, go-sig
> golang-vitess eclipseo, go-sig
> hibernate-jpa-2.1-api jjelen
> httping   fab
> jblas zbyszek
> libffi3.1 codonell
> libifp    konradm
> log4c stevetraylen, valtri
> mongo-cxx-driver  hhorak, mmuzila
> mspdebug  till
> multican  jnovy
> nom-tam-fits  gil, lupinix, zbyszek
> opentracker   cicku, lbazan
> procinfo-ng   fab
> racket   

Re: Orphaned packages looking for new maintainers

[Hans de Goede]

Hi all,

On 7/17/23 20:48, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will fail to install and/or build when the affected package gets 
> retired.
> 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2023-07-17.txt
> grep it for your FAS username and follow the dependency chain.
> 
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
> 
>     Package  (co)maintainers   Status 
> Change
> 
> Zim   ohaessler, orphan    0 weeks ago
> axc   orphan   3 weeks ago
> bctoolbox orphan   3 weeks ago
> bcunit    orphan   3 weeks ago
> belcard   orphan   3 weeks ago
> belr  orphan   3 weeks ago
> bitstower-markets orphan   3 weeks ago
> clblast   orphan, trix 1 weeks ago
> cmrt  kwizart, orphan  5 weeks ago
> dlrn  epel-packagers-sig, jpena,   0 weeks ago
>   openstack-sig, orphan
> eosrei-emojione-fonts orphan   2 weeks ago
> gfbgraph  orphan   3 weeks ago
> git-subrepo   orphan   3 weeks ago
> go-bindata    go-sig, jchaloup, orphan 0 weeks ago
> golang-bitbucket- go-sig, orphan   5 weeks ago
> bertimus9-systemstat
> golang-contrib-opencensus-    orphan   5 weeks ago
> exporter-prometheus
> golang-contrib-opencensus-    go-sig, orphan   5 weeks ago
> resource
> golang-gitea-lunny-log    go-sig, orphan   5 weeks ago
> golang-gitea-lunny-nodb   go-sig, orphan   5 weeks ago
> golang-github-abourget-teamcity   go-sig, orphan   5 weeks ago
> golang-github-acme-lego   go-sig, orphan   5 weeks ago
> golang-github-adalogics-fuzz- go-sig, orphan   5 weeks ago
> headers
> golang-github-aead-chacha20   go-sig, jchaloup, orphan 5 weeks ago
> golang-github-aead-poly1305   go-sig, jchaloup, orphan 5 weeks ago
> golang-github-agl-ed25519 go-sig, jchaloup, orphan 5 weeks ago
> golang-github-akamai- go-sig, orphan   5 weeks ago
> akamaiopen-edgegrid
> golang-github-akavel-rsrc go-sig, orphan   5 weeks ago
> golang-github-alecthomas- orphan   5 weeks ago
> kingpin
> golang-github-alicebob-gopher-    go-sig, orphan   5 weeks ago
> json
> golang-github-alicebob-   go-sig, orphan   5 weeks ago
> miniredis
> golang-github-aliyun-alibaba- bdperkin, go-sig, orphan 5 weeks ago
> cloud-sdk
> golang-github-aliyun-oss-sdk  bdperkin, go-sig, orphan 5 weeks ago
> golang-github-anacrolix-  go-sig, orphan   5 weeks ago
> envpprof
> golang-github-anacrolix-  go-sig, orphan   5 weeks ago
> missinggo
> golang-github-anacrolix-stm   go-sig, orphan   5 weeks ago
> golang-github-andy-kimball-   go-sig, orphan   5 weeks ago
> arenaskl
> golang-github-antchfx-htmlquery   go-sig, orphan   5 weeks ago
> golang-github-apache-arrow    go-sig, orphan   0 weeks ago
> golang-github-apache-thrift   go-sig, orphan   5 weeks ago
> golang-github-apex-log    go-sig, orphan   5 weeks ago
> golang-github-apex-logs   go-sig, orphan   5 weeks ago
> golang-github-apparentlymart- orphan   5 weeks ago
> textseg
> golang-github-appc-docker2aci go-sig, orphan  

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Hans de Goede]

Hi,

On 6/27/23 12:36, Adam Williamson wrote:
> On Tue, 2023-06-27 at 10:40 +0200, Hans de Goede wrote:
>> So although I realize this is not entirely fair IMHO if you want to push 
>> forward with this feature then you may also be on the hook to look into 
>> reducing the memory footprint elsewhere so that the end result still fits in 
>> 2G RAM. I have some experience with tweaking the livecd to work with less 
>> RAM and I'm happy to share my experience in this, but I do not have time to 
>> actually implement needed changes for this.
> 
> To be fair, you're writing as if it's certain that a webUI-based
> Workstation live cannot install to a 2G system, but AFAIK that has not
> yet been demonstrated. It would seem reasonable to test it before
> deciding we have a huge blocker issue here.

Right, first we need to test if this is a problem at all.
That is why I wrote "*may also* be on the hook".

Regards,

Hans


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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Hans de Goede]

Hi Simon,

On 6/27/23 11:00, Simon de Vlieger wrote:
> On 6/27/23 10:40, Hans de Goede wrote:
> 
>> Ok, so can you provide some instructions for how to make this work ? I guess 
>> it would be something like add the cmdline option + then start some systemd 
>> unit ?  Can you please put some instructions for this in the testing section 
>> of: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation 
>>  (with a note that this is currently not supported / recommended).
>>
>>> About the improvements on the Live ISO, that should be a question on Fedora 
>>> Workstation SIG. Anaconda team is not in charge of the environment on the 
>>> Live ISO.
>>
>> Well you are suggesting a change that is likely going to significantly 
>> increase the amount of memory needed to do a livecd workstation install and 
>> as mentioned above pushing the requirements above 2G would basically block 
>> this change since 2G RAM is currently the advertised minimum RAM requirement 
>> for Fedora workstation installs.
>>
>> So although I realize this is not entirely fair IMHO if you want to push 
>> forward with this feature then you may also be on the hook to look into 
>> reducing the memory footprint elsewhere so that the end result still fits in 
>> 2G RAM. I have some experience with tweaking the livecd to work with less 
>> RAM and I'm happy to share my experience in this, but I do not have time to 
>> actually implement needed changes for this.
> Hi Hans,
> 
> it would indeed involve adding the `inst.webui` and `inst.webui.remote` 
> kernel command line options and a systemd unit to start the relevant services 
> (I *think* that'd only be `cockpit.service`).
> 
> You likely also want to truncate the `/etc/cockpit/allowed-users` file so you 
> can use your empty password root login during installation.
> 
> This is normally taken care of when anaconda starts the webservice [1].
> 
> I've been working on landing live-installer generation in the image builder 
> projects (there's a separate change request for this). You can follow 
> progress on that here [2].
> 
> When the image builder PR lands the first follow ups will involve 
> customization of the live-installer. Including kernel options, packages, and 
> systemd service files. This would allow you to build a lighter version of the 
> live-installer locally to use on the devices you work with.
> 
> I am interested to know which tweaks you perform to have the livecd use less 
> RAM to see if I can codify those. Could you share your experience?

At the end of this email is a copy & paste of my own notes
of the set of hacks which I use to do a livecd install on
1G RAM x86 tablets.

Low hanging fruit would be evolution and gnome-software + packagekit.

There are 3 ways (IIRC) how the whole set of evolution-daya-server
processes gets started on a GNOME session:

1. Through /etc/xdg/autostart/org.gnome.Evolution-alarm-notify.desktop
for this we would need some way to annotate .desktop files to not
start on a livecd. This could be e.g. a X-GNOME-no-livecd-autostart=yes
on the .desktop + code in GNOME's code to generate systemd user
unit files to honor this.

2. Through a calendar search provider. This can easily be disabled in
the livecd sessions with a drop-in gconf settings file disabling the
search provider. In general many of the gnome-shell search providers
can be quite heavy for low spec machines. I think there might even
already be some code to disable some of them.

3. Stop gnome-shell starting /usr/libexec/gnome-shell-calendar-server,
which does the calendar integration in the clock widget in the top bar.
The main gnome-shell talks to this over a dbus proxy and if it cannot
be started it logs one warning and everything is fine.

Making it possible to run gnome-shell with calendar integration 
disabled has been on my wishlist for quite a while now. This may also
be useful for the efforts to make gnome-shell work better on mobile
devices. Since the evolution data server processes might be a bit
too heavy for some mobile platforms too.


As for gnome-software + packagekit getting started (and taking
up quite a lot of RAM). I think these might already be disabled
on the livecd case, since auto downloading updates to have them
ready for installation on shutdown / reboot makes little sense
there. So the first thing to do there would be to check if
these are running at all.

If they are running there are 2 places where gnome-software
gets started:

1. /etc/xdg/autostart/org.gnome.Software.desktop
2. From a gnome-shell search provider

As for packagekit (will that still be there in F39?) this
gets triggered by both gnome-software as well as by some
code in gnome-shell talking to it to see if offline-updates
should be offered on shutdown/reboot.

One

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Hans de Goede]

Hi Jirka,

On 6/27/23 01:09, Jiri Konecny wrote:
> 
> 
> Dne 26. 06. 23 v 20:39 Hans de Goede napsal(a):
>> Hi,
>>
>> On 6/26/23 18:00, Aoife Moloney wrote:
>>> https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
>>>
>>> This document represents a proposed Change. As part of the Changes
>>> process, proposals are publicly announced in order to receive
>>> community feedback. This proposal will only be implemented if approved
>>> by the Fedora Engineering Steering Committee.
>>>
>>>
>>> == Summary ==
>>> The new PatternFly-based UI has been developed by the Anaconda team
>>> for some time now and we would like to make it available for users of
>>> Fedora to enhance and modernize installation experience. As the first
>>> step in this user adoption process, we are targeting Fedora
>>> Workstation only.
>> 
>>
>> This all sounds great, thank you for working on this.
>>
>>> === Additional information ===
>>> * We are not planning to add support for spins with this change, they
>>> will use the existing GTK UI.
>>> * We don’t support remote connections to the WebUI yet.
>> Hmm, this really is going to be a problem for low memory machines.
>>
>> I regularly install Fedora Workstation on 2G (not an issue atm)
>> and 1G (requires some trickery) RAM systems. I know this is not
>> a lot of RAM but generally speaking these systems work fine
>> for non demanding work after the install.
>>
>> I'm pretty sure that not only the 1G but also the 2G RAM installs,
>> which currently barely fit in RAM will become a problem with
>> the new web installers. I was actually hoping the web-installer
>> would help here since one can then just setup networking in
>> the live environment and then have the browser showing the UI
>> run somewhere else, hopefully reducing memory consumption
>> compared to the gtk installer.
>>
>> Is there any chance this (remote installs) can at least be
>> enabled with a commandline option for advanced users?
>>
>> I realize that making something for remote installs which works
>> well for average users (and is also somehow using an authenticated
>> connection) is quite a bit of work.
>>
>> But in the interim a cmdline option to start listening on
>> other interfaces then the loopback device (and to not start
>> the local browser) would be nice to have for power users.
>>
>> Note related to this ATM:
>>
>> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/
>>
>> "Minimum System Configuration"
>>
>> Says 2G is the supported minimum. It would be good to see if
>> that can actually be made to / kept working.
>>
>> Has anyone already tested the new installer on a system with its
>> RAM limited to 2G ?
>>
>> As said I have some tricks to help with this which currently
>> allow me to go down to 1G. We should probably look into making
>> some of those the default on the livecd.
>>
>> E.g. changing a few things to not run evolution-data-services
>> on the livecd (no calendering will be configured anyways)
>> is an easy win of at least 50 MB of RAM.
>>
>> Regards,
>>
>> Hans
> If you need low memory footprint you probably don't want to use Live image 
> for installation. It's the biggest one because it needs to have whole Gnome 
> environment in memory. For that, I would suggest you to use Fedora Server 
> network installation ISO. It has much smaller memory footprint for 
> installation and still can install workstation system in the Software 
> Selection. The Fedora Server ISO is not part of this change so still GTK UI.
> If you want even smaller memory footprint then you can run the Server ISO in 
> the text mode by setting 'inst.text' kernel boot parameter in the grub menu.
> 
> We did some testing for the memory footprint of the web UI but it was some 
> time ago and I don't remember the results. We can definitely verify it.

The Workstation livecd is *the* default download on https://getfedora.org/ all 
the other Workstation options are hidden behind a "other Downloads" button.

Currently that default Workstation Download can be installed on machines with 
2G of RAM matching the advertised minimum system requirements.

Telling people with systems with 2G of RAM that they now need to use the server 
iso and then manually select the right package set is IMHO an unacceptable 
regressions and I consider this a blocker for moving forward with making the 
web based installer for Fedora Workstation.

Al

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Hans de Goede]

Hi,

On 6/26/23 18:00, Aoife Moloney wrote:
> https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> 
> == Summary ==
> The new PatternFly-based UI has been developed by the Anaconda team
> for some time now and we would like to make it available for users of
> Fedora to enhance and modernize installation experience. As the first
> step in this user adoption process, we are targeting Fedora
> Workstation only.



This all sounds great, thank you for working on this.

> === Additional information ===
> * We are not planning to add support for spins with this change, they
> will use the existing GTK UI.
> * We don’t support remote connections to the WebUI yet.

Hmm, this really is going to be a problem for low memory machines.

I regularly install Fedora Workstation on 2G (not an issue atm)
and 1G (requires some trickery) RAM systems. I know this is not
a lot of RAM but generally speaking these systems work fine
for non demanding work after the install.

I'm pretty sure that not only the 1G but also the 2G RAM installs,
which currently barely fit in RAM will become a problem with
the new web installers. I was actually hoping the web-installer
would help here since one can then just setup networking in
the live environment and then have the browser showing the UI
run somewhere else, hopefully reducing memory consumption
compared to the gtk installer.

Is there any chance this (remote installs) can at least be
enabled with a commandline option for advanced users?

I realize that making something for remote installs which works
well for average users (and is also somehow using an authenticated
connection) is quite a bit of work.

But in the interim a cmdline option to start listening on
other interfaces then the loopback device (and to not start
the local browser) would be nice to have for power users.

Note related to this ATM:

https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/

"Minimum System Configuration"

Says 2G is the supported minimum. It would be good to see if
that can actually be made to / kept working.

Has anyone already tested the new installer on a system with its
RAM limited to 2G ?

As said I have some tricks to help with this which currently
allow me to go down to 1G. We should probably look into making
some of those the default on the livecd.

E.g. changing a few things to not run evolution-data-services
on the livecd (no calendering will be configured anyways)
is an easy win of at least 50 MB of RAM.

Regards,

Hans


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

Re: Future of BIOS RAID support in the installer

[Hans de Goede]

Hi Max,

On 6/17/23 21:00, Max Mueller wrote:
> Hi,
> got a problem with mdadm and Fedora 38: 
> 
> https://forums.fedoraforum.org/showthread.php?330727-Fedora-38-on-Dell-Optiplex-755-using-INTEL-Matrix-Storage-RAID1=1872371#post1872371

Fedora has been using mdadm for Intel Matrix RAID since a very long long time:

https://fedoraproject.org/wiki/Anaconda/Features/MDRaid

dated 2009-07-16 .

So unless anaconda for some reason has switched back to using dmraid for IMSM 
based BIOS raid sets since that Fedora 12 change, your problem is not related 
to the recent plans to drop dmraid support.

Note I have left the anaconda team around the end of 2010 to work on other 
things, so my knowledge on this is not entirely up2date :)

Regards,

Hans

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

Re: ACPI-related bug in 6.3.X? At least an issue in ucsi_acpi, affecting several systems

[Hans de Goede]

Hi Christopher,

On 6/13/23 23:26, Christopher Klooz via devel wrote:
> In case you are already aware of the issue, feel free to ignore this mail. I 
> just want to make aware that there could be multiple interrelated (bug) 
> reports that might be considered in conjunction and not on their own, given 
> that the amount of affected users is above average (I could imagine this is 
> not limited to ask.Fedora).
> 
> As far as it concerns ask.Fedora: since 6.3 was introduced, we have many 
> users in ask.Fedora with issues that seem to be ACPI related (more precisely, 
> `ucsi_acpi`, but maybe not just this) and that makes it impossible to use 
> kernels after 6.2.15 except with `module_blacklist=ucsi_acpi`.
> 
> I already asked the users to provide a bug report (this is how I became aware 
> that the report template was broken ;), but I am not sure if the report(s) 
> illustrate the number of users that have come up with the same issue. Since 
> not all users with issues end up on ask.Fedora, we don't know the actual 
> number of affected systems, but so many users with the same kernel issue is a 
> seldom phenomenon.
>
> So far, most users with 6.3.X ACPI-related issues are found in this topics:
> 
> https://discussion.fedoraproject.org/t/fedora-hangs-on-boot-after-upgrading-to-kernel-6-3-4/83605/
> 
> -> black screen after grub menu with stable kernels after 6.2.15
> -> everything fine with 6.2.15
> -> mitigation: module_blacklist=ucsi_acpi (several users confirmed this to 
> mitigate the issue)
> 
> Links to the related bug reports are contained.


Thank you for reporting this and for the well written summary of the issue.

I believe that this is an issue which was already fixed recently and for which 
a patch is currently pending upstream:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linus=c4a8bfabefed706bb9150867db528ceefd5cb5fe

I have submitted a merge-request to get this fix added to the Fedora kernels as 
a downstream patch for now:

https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2511

So that we can hopefully get this resolved for Fedora users ASAP.

Regards,

Hans

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

Re: Looking for new xfig package-maintainer

[Hans de Goede]

Hi,

On 5/6/23 06:47, Globe Trotter via devel wrote:
> Did you find a co-maintainer for xfig? I use this package on and off and I 
> would not like to lose it.

No I did not find a co-maintainer for xfig yet.

Perhaps you can help co-maintain it, it is not a lot of work and I'm available 
for questions if necessary.

If you can let me know your FAS login/username then I add you as a 
co-maintainer to the package.

Regards,

Hans



> On Tuesday, April 25, 2023 at 08:31:59 AM CDT, Hans de Goede 
>  wrote: 
> 
> 
> 
> 
> 
> Hi All,
> 
> I have been keeping the Fedora xfig package alive all these years
> because I know that there are still users using xfig and xfig
> actually still has an active upstream.
> 
> Lately I have not been able to spend any time on this, as can
> be seen from the currently open / unfixed CVE against xfig:
> 
> https://bugz.fedoraproject.org/xfig
> 
> Upstream has a patch available fixing this, so fixing this
> is easy. I just have not been able to make the time for this.
> 
> As such I think the time has come to ask for help for
> maintaining xfig. If you can help by taking over or
> co-maintaining xfig, please let me know.
> 
> Regards,
> 
> Hans
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Looking for new freecol package-maintainer

[Hans de Goede]

Hi Peter,

On 4/26/23 13:33, Peter Hanecak wrote:
> Hello,
> 
> please pass that to me, I'll try to update and if it goes well, we can keep 
> it in the distro.

That is great, thank you.

I have added you as a co-admin of the package now, while
doing this I noticed that officially I have already handed
it over to Vojtěch Trefný (vtrefny, added to the Cc)
a while ago.

But Vojtěch also does not seem to have time to keep this
in sync with upstream, so if you can take care of that,
then that would be great.

Regards,

Hans






> On 4/25/23 15:32, Hans de Goede wrote:
>> Hi All,
>>
>> Once upon a time I packaged freecol, a FOSS game inspired by
>> the colonization computergame.
>>
>> Unfortunately I have not been able to make time to properly
>> maintain the package and now it is several versions behind
>> the latest upstream release.
>>
>> As such I think the time has come to hand freecol over
>> to a new maintainer, or remove it from Fedora so that
>> people can install it from flathub instead:
>> https://flathub.org/apps/org.freecol.FreeCol
>>
>> If you can help by taking over freecol, please let me know.
>>
>> Otherwise I'll remove it from Fedora for f38+ in a couple
>> of weeks.
>>
>> Note freecol is written in java.
>>
>> Regards,
>>
>> Hans
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Looking for new freecol package-maintainer

[Hans de Goede]

Hi All,

Once upon a time I packaged freecol, a FOSS game inspired by
the colonization computergame.

Unfortunately I have not been able to make time to properly
maintain the package and now it is several versions behind
the latest upstream release.

As such I think the time has come to hand freecol over
to a new maintainer, or remove it from Fedora so that
people can install it from flathub instead:
https://flathub.org/apps/org.freecol.FreeCol

If you can help by taking over freecol, please let me know.

Otherwise I'll remove it from Fedora for f38+ in a couple
of weeks.

Note freecol is written in java.

Regards,

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

Looking for new xfig package-maintainer

[Hans de Goede]

Hi All,

I have been keeping the Fedora xfig package alive all these years
because I know that there are still users using xfig and xfig
actually still has an active upstream.

Lately I have not been able to spend any time on this, as can
be seen from the currently open / unfixed CVE against xfig:

https://bugz.fedoraproject.org/xfig

Upstream has a patch available fixing this, so fixing this
is easy. I just have not been able to make the time for this.

As such I think the time has come to ask for help for
maintaining xfig. If you can help by taking over or
co-maintaining xfig, please let me know.

Regards,

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

mdbtools soname change headsup

[Hans de Goede]

Hi All,

I'm going to update mdbtools to the 1.0.0 release in rawhide, this will change 
the soname.

Only 2 packages are affected by this: libgda5 and recutils. I will take care of 
rebuilding these against the new mdbtools libs myself.

Regards,

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

[Hans de Goede]

Hi Michael,

On 1/10/23 18:04, Michael Cronenworth wrote:
> Hi all,
> 
> Unless someone speaks up in the next week I am going to retire the 
> libwebcam[1] package.
> 
> Background: Some of the first USB web cameras using the "UVC" protocol needed 
> a user-space driver for controlling the hardware features. Logitech developed 
> the libwebcam library as an interface for users. Around 2014 Logitech stopped 
> development on it and it is now abandoned.
> 
> I have seen replacements pop up with the 'v4l-utils' package and the v4l2-ctl 
> CLI tool and guvcview graphical tool. Both receive modern care so I don't see 
> a need to continue shipping the libwebcam package. There are no known 
> (reqoquery) dependencies on libwebcam.

ATM there is no replacement for uvcdynctrl which is still necessary for
some Logitech webcams. uvcdynctrl uses a userspace database to map
some Logitech custom control GUIDs to standard v4l2-controls.

This allows various extra functionality on Logitech webcams, like
adjusting the image (auto-exposure algorithm) for backlight conditions.

But also controlling the focus on some Logitech models with a manual
controlled electronic focus lens (instead of auto-focus) and I have
1 Logitech model with a motorized stand with electronic tilt / swivel
controls which needs this.

I actually recently discussed what to do with this with the kernel
UVC driver maintainer. When the discussion was made many years ago
to put the mapping of vendor specific GUIDs in userspace the thought
was that there would be many many vendor specific controls and that
we did not want to have to add all those to the kernel.

But other then the Logitech custom controls set no support for
other custom controls was ever added to uvcdynctrl-data. So
the UVC driver maintainer said that he would be ok with just
adding these mappings directly to the kernel.

Once someone finds the time to actually add these mappings
to the kenrel libwebcam can be retired but until then it would
be nice if we can keep it around for uvcdynctrl.

Regards,

Hans



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

Re: Unannounced? lua-libs soname change

[Hans de Goede]

Hi,

On 1/10/23 20:48, Kevin Kofler via devel wrote:
> Hans de Goede wrote:
>> lua-5.4.4-4.fc37 in F37 release provides both:
>>
>> liblua-5.3.so()(64bit)
>> liblua-5.4.so()(64bit)
>>
>> aka both of:
>>
>> /usr/lib64/liblua-5.3.so
>> /usr/lib64/liblua-5.4.so
> 
> This was a compatibility hack that was accidentally left enabled:
> https://src.fedoraproject.org/rpms/lua/c/519e6ee319c76a598fa09844a11461a091cb0e59?branch=rawhide
> 
>> but the recent update to lua-libs-5.4.4-7.fc37 only provides:
>>
>> liblua-5.4.so()(64bit)
>> /usr/lib64/liblua-5.4.so
> 
> which is how it should have been from the beginning.
> 
> Apparently, it was missed that some packages still depend on the old version 
> though. They need to be rebuilt.

Ok, the packages with deps on the old version appear to only be cegui
and megaglest I'll do builds + updates for the both of them.

Regards,

Hans

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

Unannounced? lua-libs soname change

[Hans de Goede]

Hi,

lua-5.4.4-4.fc37 in F37 release provides both:

liblua-5.3.so()(64bit)
liblua-5.4.so()(64bit)

aka both of:

/usr/lib64/liblua-5.3.so
/usr/lib64/liblua-5.4.so

but the recent update to lua-libs-5.4.4-7.fc37 only provides:

liblua-5.4.so()(64bit)
/usr/lib64/liblua-5.4.so

And the same appears to be happening in F36 (I did not check):

This is causing the following fails to install cegui bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2156354
https://bugzilla.redhat.com/show_bug.cgi?id=2156356
https://bugzilla.redhat.com/show_bug.cgi?id=2156626

and the following fails to install megaglest bug:

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

I can rebuild cegui (and issue updates of it for f36 + f37),
which I think might be easier/better then restoring the
liblua compat build.

And I guess I can also take care of megaglest while at it,
but first I wanted to make sure that this is the right
way to move forward with fixing this...  ?

Regards,

Hans




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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Hans de Goede]

Hi,

On 12/20/22 17:28, Neal Gompa wrote:
> On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton  wrote:
>>
>> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
>>
>> 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 ==
>> Add support for unified kernels images to Fedora.
>>
>> == Owner ==
>> * Name: [[User:kraxel| Gerd Hoffmann]]
>> * Email: kra...@redhat.com
>>
>>
>> == Detailed Description ==
>> The goal is to move away from initrd images being generated on the
>> installed machine.  They are generated while building the kernel
>> package instead, then shipped as part of a unified kernel image.
>>
>> A unified kernel image is an all-in-one efi binary containing kernel,
>> initrd, cmdline and signature.  The secure boot signature covers
>> everything, specifically the initrd is included which is not the case
>> when the initrd gets loaded as separate file from /boot.
>>
>> Main motivation for this move is to make the distro more robust and more 
>> secure.
>>
>> Switching the whole distro over to unified kernels quickly is not
>> realistic though.  Too many features are depending on the current
>> workflow with a host-specific initrd (and host-specific kernel command
>> line), which is fundamentally incompatible with unified kernels where
>> everybody will have the same initrd and command line. Thats why there
>> is 'Phase 1' in title, so we can have more Phases in future releases
>> 
>>
>> A host-specific initrd / command line is needed today for:
>>
>> * features needing optional dracut modules (initrd rebuild needed to
>> enable them).
>> * configuration / secrets baked into the initrd (booting from iscsi
>> for example).
>> * configuration being specified on the kernel command line.
>> ** root filesystem being the most important one.
>> [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions]
>> allow to remove this.
>>
>> Phase 1 goals (high priority):
>>
>> * Ship a unified kernel image as (optional) kernel sub-rpm.  Users can
>> opt-in to use that kernel by installing the sub-rpm.  Initial focus is
>> on booting virtual machines where we have a relatively small and well
>> defined set of drivers / features needed.  Supporting modern physical
>> machines with standard setup (i.e. boot from local sata/nvme storage)
>> too should be easy.
>> * Update kernel install scripts so unified kernels are installed and
>> updated properly.
>> * Add bootloader support for unified kernel images.  Add
>> [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
>> unified kernel bls support] to grub2, or support using systemd-boot,
>> or both.
>>
>> Phase 1 goals (lower priority, might move to Phase 2):
>>
>> * Add proper discoverable partitions support to installers (anaconda,
>> image builder, ...).
>> ** Temporary workaround possible: set types using sfdisk in %post script.
>> ** When using btrfs: configure 'root' subvolume as default volume.
>> * Add proper systemd-boot support to installers.
>> ** Temporary workaround possible: run 'bootctl install' in %post script.
>> * Better measurement and remote attestation support.
>> ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to
>> allow pre-calculate TPM PCR values.
>> ** avoid using grub2 (measures every config file line executed which
>> is next to impossible to pre-calculate).
>> * Switch cloud images to use unified kernels.
>>
>> Phase 2/3 goals (longer-term stuff which is not realistic to complete for 
>> F38).
>>
>> * Move away from using the kernel command line for configuration.
>> * Move away from storing secrets in the initrd.
>> * Handle dracut optional modules in a different way.
>>
>> systemd has some building blocks which can be used, although none of
>> them are used by fedora today.
>> [https://www.freedesktop.org/software/systemd/man/systemd-creds.html
>> systemd credentials] can be used for secrets (also for configuration).
>> The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html
>> unified kernel stub] can load credentials from the ESP.
>>
>> The unified kernel stub can also load
>> [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html
>> extensions] from the ESP, which can possibly be used to replace
>> optional dracut modules.
>>
>> == Feedback ==
>>
>>
>> == Benefit to Fedora ==
>> * Better secure boot support (specifically the initrd is covered by
>> the signature).
>> * Better confidential computing support (measurements are much more
>> useful if we know what hashes to expect for the initrd).
>> * More robust boot process (generating the initrd on the installed
>> system is fragile, root cause for kernel bugs reported is simply a
>> broken initrd sometimes).
>>
>> == Scope ==
>> * Proposal owners:
>> ** Update kernel 

Re: [Test-Announce] Help test backlight control changes on old laptops in the upcoming kernel

[Hans de Goede]

Hi All,

On 11/7/22 16:34, Kamil Paral wrote:
> Hello,
> 
> kernel 6.1 or 6.2 will change how laptop backlight is handled and it might 
> negatively affect some laptops, especially older ones. Hans De Goede, the 
> developer of that change, asks for wider community testing. Here are his blog 
> posts containing all necessary instructions:
> 
> * Part 1: https://hansdegoede.livejournal.com/26427.html 
> <https://hansdegoede.livejournal.com/26427.html>
> * Part 2: https://hansdegoede.livejournal.com/27130.html 
> <https://hansdegoede.livejournal.com/27130.html>
> 
> If you can, please help him identify affected laptops, so that this change 
> can be prepared with a minimum negative impact. All results are to be 
> submitted directly to Hans (not to this list), as described in the blog posts.

Kamil, thank you for bringing this to people's attention.

Note that the most problematic change in 6.1 has already been disabled, so it 
is no longer necessary to run the tests from the first blog post.

If you want to help test please run the tests from the second blogpost:

https://hansdegoede.livejournal.com/27130.html

which is about trying to re-introduce the 6.1 change in a different form. Note 
you can run the requested tests with any recent(ish) kernel.

The 6.2 changes will most likely affect only really old laptops (from around 
2005), so if possible please run the tests on older laptops.

So far only one laptop is known to be affected by the planned 6.2 changes and 
that is a laptop from 2003, for which I will add a DMI quirk to avoid that 
specific model from regressing in 6.2.

Regards,

Hans

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

Re: Building two conflicting binaries from the same source

[Hans de Goede]

Hi Again,

On 11/3/22 21:31, Bojan Smojver via devel wrote:
> This may be a trivial question, but my friend Google is not showing me any 
> obvious answers, so I will ask here at my own peril.
> 
> Say one needs to configure and build the same source with two (or more) 
> different sets of options that generate different binary RPMs, but which have 
> files in exactly the same place. This is to support different hardware. The 
> end result would be mutually conflicting binary packages that users then 
> install etc.
> 
> Sure, it is easy enough to configure/build repeatedly and stash the results 
> into non-conflicting paths of buildroot, but how does one then package this 
> in %files sections into exactly the same paths?
> 
> If there is an example floating somewhere, that would be very useful.

I just realized that my IPU6 plans might be useful for you
regardless of if that is your use case too.

So the IPU6 userspace bits consist of a bunch of closed source
.so files in 2 different variants for 2 different hw generations.

Against this a libcamerahal.so gets build, which build is
also hw generation specific.

And then there is a gstreamer-1.0 plugin which consumes
libcamerahal.so, but which build is not hw generation specific
(AFAICT, still need to verify this).

I want support for both hw generations to be installed
at the same time, rather then have 2 conflicting subpackages
because I don't want users to have to know which generation
they exactly have. And I want this to work with a read-only
/usr.

So here is what I've come up with (from my own notes,
so might be a bit cryptic):

  -Rename libcamerahal.so to libcamerahal-ipu6.so and patch in a rpath
   to /usr/lib64/ipu6 for the other libs, then make libcamerahal.so
   a symlink to /run/libcamerahal.so which is a symlink to the one we
   actual want; and have udev-rules dynamically set /run/libcamerahal.so
   symlink
  -See: https://github.com/Linuxbrew/legacy-linuxbrew/issues/7 for ideas to set
   the rpath
  -Needs something to allow building on non IPU6 systems -> hack .pc file
   to just always point to the plain (tgl) ipu6 version
  -Patch hal s|share/defaults/etc|share/defaults/etc/ipu6| for different etc 
dirs per
   IPU6 version

Maybe the rpath tricks + making the actual lib (or binary) a link to /run/foo
and then have a udev rule create /run/foo to point to the right version
depending on the hw it is running on might be useful for you too ?

Regards,

Hans


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

Re: Building two conflicting binaries from the same source

[Hans de Goede]

Hi,

On 11/3/22 21:31, Bojan Smojver via devel wrote:
> This may be a trivial question, but my friend Google is not showing me any 
> obvious answers, so I will ask here at my own peril.
> 
> Say one needs to configure and build the same source with two (or more) 
> different sets of options that generate different binary RPMs, but which have 
> files in exactly the same place. This is to support different hardware. The 
> end result would be mutually conflicting binary packages that users then 
> install etc.
> 
> Sure, it is easy enough to configure/build repeatedly and stash the results 
> into non-conflicting paths of buildroot, but how does one then package this 
> in %files sections into exactly the same paths?
> 
> If there is an example floating somewhere, that would be very useful.

Is this perhaps for the Intel IPU6 camera support userspace bits?

If yes I'm working on packaging those (for rpmfusion since parts
are closed source) and I have a plan how to deal with them.

If no, then please ignore this email :)

(just making sure that if the answer is yes we can coordinate /
avoid doing double work)

Regards,

Hans


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

Re: Grub menu with 3 kernels by default

[Hans de Goede]

Hi,

On 10/5/22 23:07, Chris Murphy wrote:
> 
> 
> On Wed, Oct 5, 2022, at 3:01 PM, Vít Ondruch wrote:
>>
>> 3. "Boot menu" in GUI? Given that one can reach the GUI, why it should 
>> not be possible to choose the boot entry for next boot? Or even choose 
>> to open FW setup.
> 
> This could solve this other problem too.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2049849
> 
> The GUI tool can use efibootmgr to set bootnext or even bootorder.

Right, this is definitely interesting.

sdboot already offers some nice features for this.

bootctl --list: shows available boot menu entries
systemctl reboot --boot-loader-entry=ID: select which entry to boot

And I believe that there are also dbus equivalents of this.

If we want this we should consider either switching
to sdboot or make grub support:
https://systemd.io/BOOT_LOADER_INTERFACE/

And then this is something which could be an upstream GNOME feature
using the systemd DBUS APIs for this.

The only problem is that this requires someone to make time to
work on this...

I personally believe that for the Fedora workstation case
it makes sense to just switch to sdboot for EFI installs
giving us nice features like this; while at the same time
offering a much simpler code-base then grub, which is
good from a secureboot POV.

Regards,

Hans


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

Re: Grub menu with 3 kernels by default

[Hans de Goede]

Hi,

On 10/5/22 20:56, Christopher Klooz wrote:
> 
> On 05/10/2022 20:28, Hans de Goede wrote:
>> Hi,
>>
>> On 10/5/22 19:59, Christopher Klooz wrote:
>>> On 05/10/2022 18:39, Christopher Klooz wrote:
>>>> On 05/10/2022 17:33, Chris Murphy wrote:
>>>>> On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:
>>>>>
>>>>>> However, on ask.fp, a user mentioned that the grub menu is no longer
>>>>>> enabled by default on single boot systems so that changing the kernel is
>>>>>> no longer easily possible, and put forward
>>>>>> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
>>>>>> this argument. Yet, the article indicates that the argument is not fully
>>>>>> correct and even with single boot installations, SHIFT can be used to
>>>>>> get into the grub menu.
>>>>> I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, 
>>>>> because it's reserved by UEFI firmware for one of its menus. And SHIFT 
>>>>> has never worked. Maybe Esc or TAB?
>> Holding left shift is the easiest method, but with firmware being
>> firmware does not work on all systems.
>>
>> What does always work is ESC or F8, Fedora's grub supports both to
>> show the menu. On some systems one of those key get intercepted by
>> the firmware which is why there are 2 choices.
>>
>>>>> Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.
>>>>>
>>>>>
>>>> Me, too. Especially as it makes support more problematic for unexperiened 
>>>> users. It is easy to say that people should push another kernel when they 
>>>> see the grub menu. They see text, and I can tell them which text to 
>>>> choose. But with unexperiened users, telling when to push tab/esc/shift/F8 
>>>> can already need to start an elaboration of what "boot" means and when 
>>>> this happens and so on. Such elaborations are already annoying for them 
>>>> (and for the supporters).
>> The menu automatically unhides after a failed boot. Just blindly
>> doing ctrl + alt + f4 followed by ctrl + alt + delete; or just
>> power-cycling the machine counts as a failed boot.
> Many problems that can occur do not cause a failed boot. This starts with the 
> current issue in 5.19.12.

Assuming the current issue causes users to not be able to login, it does count 
as a failed boot.

On Fedora workstation a successful boot is the user loging in in gdm and the 
user session
then lasting at least 2 minutes. Or the user shuttingdown/rebooting the machine 
from
the GNOME system menu. Anything else counts as a failure.

> Another widespread issue is that users have problems with a piece of hardware 
> (e.g., bluetooth controller), or with modules causing unintended behavior 
> with one kernel (freeze, slow, something like wifi or bluetooth does not 
> work, other acpi issues, and so on). All that does not necessarily cause 
> failed boots, but is widespread among our "user base" at ask.fp especially 
> because Fedora is used on much different hardware, and some needs 
> additionally external modules.

If a user can interact with gdm / GNOME then they can keep left-alt pressed 
while
on the confirm you want to reboot screen, this will visible change "Restart"
into "Boot Options" and clicking "Boot Options" (while keeping left-lat pressed)
will then cause the grub menu to show for 60 seconds the next boot.

Also power-cycling / ctrl+alt+del rebooting from a text virtual console without
logging in will show the menu on the next boot. I have put a lot of effort
in making it easy for users to still get the menu if necessary.

To me it seems the biggest problem is users not being aware of the various
options to get the menu when they need it.

Also I want to point out that the reason which started this thread,
the phoronix post about LCD panels possibly getting damages is mostly
scare-mongering. Yes theoretically LCD panels might get damaged but
there have been 0 reports about this and this is already fixed now.

In my experience making policy changes as a sort of shooting from
the hip reaction to a specific incident is usually a bad idea.
For an extreme example of this see how 9-11 has got us all sort of
draconian surveillance laws all over the world.

Regards,

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

Re: Grub menu with 3 kernels by default

[Hans de Goede]

Hi,

On 10/5/22 19:59, Christopher Klooz wrote:
> 
> On 05/10/2022 18:39, Christopher Klooz wrote:
>> On 05/10/2022 17:33, Chris Murphy wrote:
>>>
>>> On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:
>>>
 However, on ask.fp, a user mentioned that the grub menu is no longer
 enabled by default on single boot systems so that changing the kernel is
 no longer easily possible, and put forward
 https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
 this argument. Yet, the article indicates that the argument is not fully
 correct and even with single boot installations, SHIFT can be used to
 get into the grub menu.
>>> I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, 
>>> because it's reserved by UEFI firmware for one of its menus. And SHIFT has 
>>> never worked. Maybe Esc or TAB?

Holding left shift is the easiest method, but with firmware being
firmware does not work on all systems.

What does always work is ESC or F8, Fedora's grub supports both to
show the menu. On some systems one of those key get intercepted by
the firmware which is why there are 2 choices.

>>> Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.
>>>
>>>
>> Me, too. Especially as it makes support more problematic for unexperiened 
>> users. It is easy to say that people should push another kernel when they 
>> see the grub menu. They see text, and I can tell them which text to choose. 
>> But with unexperiened users, telling when to push tab/esc/shift/F8 can 
>> already need to start an elaboration of what "boot" means and when this 
>> happens and so on. Such elaborations are already annoying for them (and for 
>> the supporters).

The menu automatically unhides after a failed boot. Just blindly
doing ctrl + alt + f4 followed by ctrl + alt + delete; or just
power-cycling the machine counts as a failed boot.

We have spend a lot of time on creating a smooth boot experience
without any menus filled with "techno babble" which scare
novice users. Lets avoid regressing on this.

If anything what we need is to:

1. Detect we are running not the latest kernel
2. Pop up a dialog that 1. is true and ask the user if there
were issues with the latest kernel and if yes if they want
to pin the currently running kernel for say the next month ?

Regards,

Hans


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

Re: Grub menu with 3 kernels by default

[Hans de Goede]

Hi,

On 10/5/22 17:16, Christopher Klooz wrote:
> The current issue on 5.19.12 made it necessary for some users to change their 
> kernel on boot to avoid 5.19.12 until the update to 5.19.13 was pushed to 
> stable. Obviously, the option to easily boot recent kernels can be necessary 
> in several circumstances, especially for non-advanced users it has proven to 
> be very helpful on ask.fp to achieve that with two easily-to-describe clicks.
> 
> However, on ask.fp, a user mentioned that the grub menu is no longer enabled 
> by default on single boot systems so that changing the kernel is no longer 
> easily possible, and put forward 
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for this 
> argument. Yet, the article indicates that the argument is not fully correct 
> and even with single boot installations, SHIFT can be used to get into the 
> grub menu. Generally, my experience with non-advanced users on ask.fp and in 
> general does not correspond to the arguments in the article. However, on all 
> my Workstation and KDE/lxqt spin installations (one originally installed 
> before F29, others between F33 & F36), this article does not apply at all, 
> and by default, I can choose between the recent three kernels for 5 seconds 
> in the grub menu on all single boot systems, unless I change the grub config 
> myself.
> 
> So first of all, does the article currently apply to any edition? If not, we 
> might change the content to avoid further confusion...

We still hide the grub menu by default on single OS installs, at least in the 
Workstation product.

On EFI systems where holding down SHIFT relies on the EFI implementation 
actually giving us modififier key presses even when no "normal" key is pressed 
might not work, there are several other options documented in the hidden boot 
menu FAQ (also linked from the change page):

https://hansdegoede.dreamwidth.org/19180.html

Regards,

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

Re: Intel MIPI IPU6 cameras support

[Hans de Goede]

Hi,

On 9/9/22 15:05, Vratislav Podzimek wrote:
> On 9/9/22 13:50, Leigh Scott wrote:
>>
>>> Also note that you will also need to create a kmod package for
>>> the also out of tree v4l2-loopback kernel driver. The closed-source
>>> userspace bits Intel provide only work with gstreamer. So the
>>> way this is used on other distros is with a little helper process
>>> which runs a gstreamer-pipeline from the camera and then injects
>>> the resulting frames back into the kernel through v4l2-loopback
>>> so that e.g. firefox sees a good old /dev/video0 device.
>>> Regards,
>>>
>>> Hans
>> v4l2loopback-kmod already exists.

That is good to know, thank you.

> Thanks for the tips and advice, guys! I guess I should have explained myself 
> better -- my current goal is, of course, to make things work for me. And as 
> the next step I was thinking about a Copr repo, i.e. an equivalent of 
> PPA/AUR. Then RPMFusion. I haven't really started the work so I was trying to 
> avoid effort duplication and starting from zero in case somebody has already 
> made some progress.

You are allowed to put FOSS kernel-modules (I believe the IPU6 kernel bits are 
FOSS, but this needs to be double-checked) in COPR. But you are not allowed to 
put any non FOSS software like some of the userspace bits in COPR, so COPR will 
not work to make the full stack necessary available.

Note if you are already a Fedora packager then you are welcome to rpmfusion and 
rpmfusion's workflow is (deliberatily) pretty close to Fedora's so there is 
almost no learning curve.

Regards.

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

Re: Intel MIPI IPU6 cameras support

[Hans de Goede]

Hi Vratislav,

On 9/9/22 11:42, Vratislav Podzimek wrote:
> Hello,
> I got a new Dell XPS laptop with the "amazing" [1] Intel MIPI IPU6 webcam. 
> There are upstream repos with drivers [2] and user-space stuff and Ubuntu [3] 
> and Arch [4] have user repositories with everything required packaged. I 
> found nothing available for Fedora so before I go and spend a couple nights 
> trying to make things work on Fedora I want to make sure that, by any chance, 
> someone is not already working on this to avoid duplicate efforts. And I have 
> to add a disclaimer right away: I have no idea when I will find enough time 
> to do the work.
> 
> [1] https://www.phoronix.com/news/Greg-KH-No-ADL-Webcam-Laptop
> [2] https://github.com/intel/ipu6-drivers
> [3] https://launchpad.net/~oem-solutions-group/+archive/ubuntu/intel-ipu6
> [4] https://aur.archlinux.org/packages/intel-ipu6-dkms-git

As others have explained the support for this cannot go in Fedora proper,
but we can try to add support through rpmfusion.

Actually I have working on getting this packaged up (through rpmfusion)
on my radar so that we will at least have something working for Fedora
users. It won't be pretty but it should at least get people's cameras
to show an image.

I should have hardware with an IPU6 using camera in there soonish and
then I can help you with your packaging efforts. Please let me know
how your packaging efforts are going.

Also note that you will also need to create a kmod package for
the also out of tree v4l2-loopback kernel driver. The closed-source
userspace bits Intel provide only work with gstreamer. So the
way this is used on other distros is with a little helper process
which runs a gstreamer-pipeline from the camera and then injects
the resulting frames back into the kernel through v4l2-loopback
so that e.g. firefox sees a good old /dev/video0 device.

This of course is anything but sufficient, requiring every
video frame to be copied at least one extra time.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://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-arm] Heads-up / for discussion: dnf not working with 1G of RAM or less

[Hans de Goede]

Hi,

On 8/23/22 02:44, Adam Williamson wrote:
> Hey folks! I apologize for the wide distribution, but this seemed like
> a bug it'd be appropriate to get a wide range of input on.
> 
> There's a bug that was proposed as an F37 Beta blocker:
> https://bugzilla.redhat.com/show_bug.cgi?id=1907030
> 
> it's quite an old bug, but up until recently, the summary was
> apparently accurate - dnf would run out of memory with 512M of RAM, but
> was OK with 1G. However, as of quite recently, on F36 at least (not
> sure if anyone's explicitly tested F37), dnf operations are commonly
> failing on VMs/containers with 1G of RAM due to running out of RAM and
> getting OOM-killed.
> 
> There's some discussion in the bug about what might be causing this and
> potential ways to resolve it, and please do dig into/contribute to that
> if you can, but the other question here I guess is: how much do we care
> about this? How bad is it that you can't reliably run dnf operations on
> top of a minimal Fedora environment with 1G of RAM?
> 
> This obviously has some overlap with our stated hardware requirements,
> so here they are for the record:
> 
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/
> 
> that specifies 2GB as the minimum memory for "the default
> installation", by which I think it's referring to a default Workstation
> install, though this should be clarified. But then there's a "Low
> memory installations" boxout, which suggests that "users with less than
> 768MB of system memory may have better results performing a minimal
> install and adding to it afterward", which kinda is recommending that
> people do exactly the thing that doesn't work (do a minimal install
> then use dnf on it), and implying it'll work.
> 
> After some consideration I don't think it makes sense to take this bug
> as an F37 blocker, since it already affects F36, and that's what I'll
> be suggesting at the next blocker review meeting. However, it does seem
> a perfect candidate for prioritized bug status, and I've nominated it
> for that.
> 
> I guess if folks can chime in with thoughts here and/or in the bug
> report, maybe a consensus will emerge on just how big of an issue this
> is (and how likely it is to get fixed). There will presumably be a
> FESCo ticket related to prioritized bug status too.

I still have quite a few x86_64 tablets with only 1G RAM, so I personally
definitely care about this.

With that said I do regularly run dnf on them without issues,
although I think most of the 1G models I have are still at F35...

Still I wonder why this is an issue in some cases:

1. ZRAM helps a lot here, but I guess with containers when limiting them
to 1G you really only get 1G since ZRAM works on the system level not
the container level. In the VM case though ZRAM should help, is ZRAM
enabled ?  ZRAM is enabled by default for Workstation installs, but
maybe not in other installs ?

2. Maybe there are some other processes also taking up more RAM
then expected causing extra memory pressure ?

Regards,

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

dracut bluetooth hang + dbus permission errors are back in rawhide

[Hans de Goede]

Hi All,

After upgrading my workstation to rawhide for F37 dogfooding purposes
it hang for 30 seconds at switching root and then anything depending
on dbus would fail to start with permission errors.

Booting the F36 kernel and then creating a:

/etc/dracut.conf.d/nobluetooth.conf

with:

omit_dracutmodules+=" bluetooth "

in there, followed by re-generating the initrd works around this.

Once more people start testing F37 I expect more people to get
bitten by this, so it would be good to fix this soon if possible.

Since all the history about this is in:
https://bugzilla.redhat.com/show_bug.cgi?id=1964879

I've re-opened that bug to track this there.

Regards,

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

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

[Hans de Goede]

Hi,

On 6/27/22 13:18, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jun 27, 2022 at 11:20:13AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 6/27/22 10:10, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote:
>>>> This document represents a proposed Change. As part of the Changes
>>>> process, proposals are publicly announced in order to receive
>>>> community feedback. This proposal will only be implemented if approved
>>>> by the Fedora Engineering Steering Committee.
>>>>
>>>>
>>>> == Summary ==
>>>>
>>>> The `systemd-udev` package installs
>>>> `"/usr/lib/systemd/network/99-default.link"`,
>>>> which sets `Link.MACAddressPolicy=persistent`. This proposal is to
>>>> change it to set `Link.MACAddressPolicy=none` to stop changing the MAC 
>>>> address.
>>>> This is particularly important for bridge and bond devices.
>>>>
>>>> This change can either only apply to bridge/bond devices, or to
>>>> various software devices. That is to be discussed.
>>>
>>> Hi!
>>>
>>> I already participated in the upstream discussion, so what I write
>>> here will be a restatement to some extent, but with a look from the
>>> side of Fedora specifically.
>>>
>>> The proposal has two variants: 1. just changing the policy to 
>>> MACAddressPolicy=none
>>> or 2. limiting the change to bridge and bond devices.
>>>
>>> Re variant 1: MACAddressPolicy=persistent applies to all devices that don't 
>>> have
>>> a hardware address. The proposal as written (blanket MACAddressPolicy=none)
>>> would change behaviour for all kinds of devices, incl. e.g. software
>>> devices like veths, and cheap hardware devices without a fixed MAC.
>>> The proposal doesn't provide any justification for this (except for
>>> simplicity of implementation) and this variant seems pretty bad and
>>> I'm strongly opposed.
>>
>> 
>>
>> I did not know systemd/udev can save/restore MAC addresses for devices
>> where there is no MAC address. I have looking into a related issue on my
>> todo list. There are some cheap x86 devices with wifi which don't have
>> a nvram (eeprom) chip instead they load nvram from /lib/firmware. On most
>> devices there is enough otp inside the wifi chip that they do have a unique
>> MAC inside the wifi chip's otp memory so everything works well.
>>
>> But on some devices that otp is either not there or not programmed, so
>> they take their MAC from the nvram in /lib/firmware which means that
>> all devices from the same model end up using the same MAC (which is
>> defined in the nvram in /lib/firmware).
>>
>> Am I reading the above correctly that udev/systemd already is able
>> to deal with this and I just need to make it so that the device has
>> no MAC set at all and then the first time systemd sees this it will
>> generate a random MAC and use that on future boots ?
> 
> Yes. (With the following clarification: the MAC address is generated
> from as some hash of machine-id + device name. So "first time" and
> "any time" are the same — no state is ever saved, you're supposed to
> get the same result for a specific device on a specific system.)
> 
>> Any docs on this / code you can point me to how systemd determines
>> it needs to do this ?
> 
> udev looks at /sys/class/net/hub0/addr_assign_type.
> But the docs are not great :( The description is split between two man pages:
> - 
> https://www.freedesktop.org/software/systemd/man/systemd.link.html#MACAddressPolicy=
> - 
> https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html

Thanks this was useful. I've submitted a kernel patch upstream now 
which fixes the described issue by using a random MAC + setting
the addr_assign_type:

https://lore.kernel.org/linux-wireless/20220708133712.102179-2-hdego...@redhat.com/

Regards,

Hans




> 
>> 
>>
>> The same also applies to some bluetooth devices:
>>
>> https://github.com/bluez/bluez/issues/107
>>
>> I wonder if similar functionality for bluetooth would
>> be welcome in systemd ?
> 
> I think so. From what I can see, we don't do much setup for bluetooth
> devices, so I'm not sure if udevd is a better place for this than
> e.g. bluez. But if yes, it's nice to do things uniformly, i.e. in this
> case treat bluebooth interfaces more like other network interfaces…
> The implementation should be simple, since it'd be a question of
> extending existing code to cover one more case.
> 
> Zbyszek
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

[Hans de Goede]

Hi,

On 6/27/22 10:10, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote:
>> This document represents a proposed Change. As part of the Changes
>> process, proposals are publicly announced in order to receive
>> community feedback. This proposal will only be implemented if approved
>> by the Fedora Engineering Steering Committee.
>>
>>
>> == Summary ==
>>
>> The `systemd-udev` package installs
>> `"/usr/lib/systemd/network/99-default.link"`,
>> which sets `Link.MACAddressPolicy=persistent`. This proposal is to
>> change it to set `Link.MACAddressPolicy=none` to stop changing the MAC 
>> address.
>> This is particularly important for bridge and bond devices.
>>
>> This change can either only apply to bridge/bond devices, or to
>> various software devices. That is to be discussed.
> 
> Hi!
> 
> I already participated in the upstream discussion, so what I write
> here will be a restatement to some extent, but with a look from the
> side of Fedora specifically.
> 
> The proposal has two variants: 1. just changing the policy to 
> MACAddressPolicy=none
> or 2. limiting the change to bridge and bond devices.
> 
> Re variant 1: MACAddressPolicy=persistent applies to all devices that don't 
> have
> a hardware address. The proposal as written (blanket MACAddressPolicy=none)
> would change behaviour for all kinds of devices, incl. e.g. software
> devices like veths, and cheap hardware devices without a fixed MAC.
> The proposal doesn't provide any justification for this (except for
> simplicity of implementation) and this variant seems pretty bad and
> I'm strongly opposed.



I did not know systemd/udev can save/restore MAC addresses for devices
where there is no MAC address. I have looking into a related issue on my
todo list. There are some cheap x86 devices with wifi which don't have
a nvram (eeprom) chip instead they load nvram from /lib/firmware. On most
devices there is enough otp inside the wifi chip that they do have a unique
MAC inside the wifi chip's otp memory so everything works well.

But on some devices that otp is either not there or not programmed, so
they take their MAC from the nvram in /lib/firmware which means that
all devices from the same model end up using the same MAC (which is
defined in the nvram in /lib/firmware).

Am I reading the above correctly that udev/systemd already is able
to deal with this and I just need to make it so that the device has
no MAC set at all and then the first time systemd sees this it will
generate a random MAC and use that on future boots ?

Any docs on this / code you can point me to how systemd determines
it needs to do this ?



The same also applies to some bluetooth devices:

https://github.com/bluez/bluez/issues/107

I wonder if similar functionality for bluetooth would
be welcome in systemd ?

Regards,

Hans



> 
> Re variant 2: the proposal limited to brige/bond devices seems much more
> reasonable. In particular, the case described below of a server (virtualized
> or not) in a big datacenter is the one case where the benefits of
> MACAddressPolicy=none are clearly visible. I still don't think it's worth
> changing the default, but here the cost:benefit ratio is much closer.
> 
>> == Benefit to Fedora ==
>>
>> Pros:
>>
>> - Consistent behavior with RHEL8 and RHEL9.
>>
>> - Avoid race of udev and the tool that creates the interface.
> 
> The race will happen if the creation is done in a specific way. But at
> the same time, even the Change proposal describes how to avoid the
> race ('ip link add address aa:aa:aa:aa:aa:aa type bridge'). So the situation
> can be summarized as "we have a bunch of 'big' tools that create
> devices like NetworkManager or systemd-networkd, which already know or
> can be easily fixed to avoid the race, and a manual tool which can be invoked
> in a way that avoids the race". Instead of changing the default in udev we
> could educate people how to invoke it better.
> 
>> - Bridge and bond interfaces can get the MAC addresses from their first port.
>>
>> In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will
>> get a MAC related to one of its physical NIC devices. In the case of
>> provisioning
>> new systems (especially in a large datacenter) information about the server
>> can be used to configure the network environment (DHCP, Firewall, etc) before
>> the server is ever even powered on. This does mean that you may have to 
>> update
>> your network environment configuration if you replace a NIC (con), but that 
>> you
>> won't have to update your network environment configuration if you re-install
>> your server (pro), which is what you'd have to do now with
>> `MACAddressPolicy=persistent`.
> 
> Yep. This is *the* case.
> 
>> Cons:
>>
>> - Deviate from upstream systemd.
> 
> It is also important to mention that Fedora will "deviate" from itself
> (it's former self). We would be changing a default in place since ~2013 [1].
> 
> [1] 

Re: VirtualBox and HOST kernel-5.17.12 weirdness

[Hans de Goede]

Hi,

On 6/15/22 07:01, Ian Laurie wrote:
> On 6/12/22 14:34, Sérgio Basto wrote:
>> On Sun, 2022-06-12 at 13:59 +1000, Ian Laurie wrote:
>>> On 6/12/22 11:20, Ian Laurie wrote:
>>>> On 6/12/22 09:46, Ian Laurie wrote:
>>>>> On 6/12/22 00:58, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 6/11/22 01:02, Alexander G. M. Smith wrote:
>>>>>>> On 2022-06-08 15:00, Alexander G. M. Smith wrote:
>>>>>>>> Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.:
>>>>>>>>> Is anyone else seeing crashes and other strange events in
>>>>>>>>> VirtualBox
>>>>>>>>> 6.1.34 (from RPMFusion) with Linux guests when the Linux
>>>>>>>>> host is
>>>>>>>>> running
>>>>>>>>> Fedora 36 with kernel-5.17.12?
>>>>>>>> [...]
>>>>>>>> The weird thing is that it works on other CPUs, an AMD
>>>>>>>> Athlon X2
>>>>>>>> and an Intel 10th generation i5-10500H.  Just my Ivy Bridge
>>>>>>>> Intel
>>>>>>>> i7-4820K has the problem.  I did try the kernel boot
>>>>>>>> parameter
>>>>>>>> mitigations=off, in case the Spectre or other workarounds
>>>>>>>> were
>>>>>>>> wrong for Ivy Bridge, but it still didn't work.
>>>>>>> One more data point.  It fails on an Intel i5-750 too.  Same
>>>>>>> broken
>>>>>>> data connections and failed checksums.
>>>>>>>
>>>>>>> My go-to test is to use "dnf clean" followed by "dnf upgrade"
>>>>>>> running as root in a console (thus no networking is between
>>>>>>> keyboard and computer - pipes often fail).  My server
>>>>>>> snapshot
>>>>>>> fails to get through the complete dnf upgrade on kernel
>>>>>>> 5.17.13,
>>>>>>> works fine if booting the host with the earlier kernel
>>>>>>> 5.17.11
>>>>>>> (using the GRUB boot menu to pick the older OS).
>>>>>>>
>>>>>>> So, should we report this to VirtualBox?  They seem like the
>>>>>>> most
>>>>>>> appropriate people.  Kernel people would be a possibility?
>>>>>>>
>>>>>>> Found a relevant bug report:
>>>>>>> https://www.virtualbox.org/ticket/20976
>>>>>>>
>>>>>>> And a forum discussion:
>>>>>>> https://forums.virtualbox.org/viewtopic.php?f=7=106071
>>>>>>>
>>>>>>> Though they don't know that it only happens on certain CPUs
>>>>>>> (or
>>>>>>> motherboards or ?).  I'll add some notes about that there.
>>>>>> Note the rpmfusion VirtualBox packages now include this fix:
>>>>>> https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1
>>>>>>  
>>>>>>
>>>>>> See:
>>>>>> https://koji.rpmfusion.org/koji/buildinfo?buildID=22655
>>>>>>
>>>>>> Which is supposed to fix this.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Hans
>>>>> I'm currently running this version, with the 5.18 fixes, but it's
>>>>> not
>>>>> working with kernels 5.17.12/13 or 14.  A person reporting
>>>>> success
>>>>> with 5.18.3 reported not having problems with the 5.17 kernels,
>>>>> so
>>>>> maybe there are multiple issues (has been suggested it may be
>>>>> CPU/chipset related).  I have not yet tried it on 5.18 but I
>>>>> certainly will today.
>>>>>
>>>>> Ian
>>>>>
>>>> If I understand Sérgio's comment #15 correctly, the 5.18 kernel
>>>> fixes
>>>> don't address the CPU issues possibly created by CVE-2022-1789
>>>> fixes,
>>>> so there is probably no point in me trying an early 5.18.  So the
>>>> CPU
>>>> issues are common to both later 5.17 and 5.18.  Sadly all my
>>>> hardware
>>>> here falls under the broken category:
>>>>
>>>> [1] 

Re: VirtualBox and HOST kernel-5.17.12 weirdness

[Hans de Goede]

Hi,

On 6/11/22 01:02, Alexander G. M. Smith wrote:
> On 2022-06-08 15:00, Alexander G. M. Smith wrote:
>> Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.:
>> > Is anyone else seeing crashes and other strange events in VirtualBox
>> > 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running
>> > Fedora 36 with kernel-5.17.12?
>> [...]
>> The weird thing is that it works on other CPUs, an AMD Athlon X2 and an 
>> Intel 10th generation i5-10500H.  Just my Ivy Bridge Intel i7-4820K has the 
>> problem.  I did try the kernel boot parameter mitigations=off, in case the 
>> Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't 
>> work.
> 
> One more data point.  It fails on an Intel i5-750 too.  Same broken data 
> connections and failed checksums.
> 
> My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root 
> in a console (thus no networking is between keyboard and computer - pipes 
> often fail).  My server snapshot fails to get through the complete dnf 
> upgrade on kernel 5.17.13, works fine if booting the host with the earlier 
> kernel 5.17.11 (using the GRUB boot menu to pick the older OS).
> 
> So, should we report this to VirtualBox?  They seem like the most appropriate 
> people.  Kernel people would be a possibility?
> 
> Found a relevant bug report:
> https://www.virtualbox.org/ticket/20976
> 
> And a forum discussion:
> https://forums.virtualbox.org/viewtopic.php?f=7=106071
> 
> Though they don't know that it only happens on certain CPUs (or motherboards 
> or ?).  I'll add some notes about that there.

Note the rpmfusion VirtualBox packages now include this fix:
https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1

See:
https://koji.rpmfusion.org/koji/buildinfo?buildID=22655

Which is supposed to fix this.

Regards,

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

Re: F36 pvcs problem

[Hans de Goede]

Hi,

On 6/6/22 21:14, Florian Weimer wrote:
> * Roger Wells:
> 
>> we use pvcs here for CM and have for many years (~30).
>> Currently we are using it on RHEL 7 & Fedora.
>> On F35 (and earlier) no issues at all.
>> On F36 (installed end of last week) some programs are not recognized
>> and issue error message "not a dynamic executable" when examined with
>> "ldd":
>> any ideas?
> 
> Have you installed glibc.i686?

Yes that was what I was about to suggest to. The:

/home/roger/pvcs/vm/linux/bin/mlcproxy: No such file or directory

Error means that the loader/dynamic-linker for the executable is
missing, which likely is /lib/ld-linux.so.2 which is part of glibc.i686 .

Recent Fedora-s no longer have any 32 bit support as part of
the default install (for 64 bit binaries, the loader is
/lib64/ld-linux-x86-64.so.2 instead).

Regards,

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

Re: Announcing the Fedora BIOS boot SIG

[Hans de Goede]

Hi,

On 5/23/22 08:41, Adam Williamson wrote:
> On Fri, 2022-05-20 at 12:18 +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Now that FESCo has decided (1) that Fedora will keep supporting BIOS
>> booting, the people working on Fedora's bootloader stack will need
>> help from the Fedora community to keep Fedora booting on systems which
>> require Legacy BIOS to boot.
>>
>> To help with this the Fedora BIOS boot SIG (special interest group) has
>> been formed. The main goal of this SIG are to help the Fedora bootloader
>> people by:
>>
>> 1) Doing regular testing of nightly Fedora N + 1 composes on hardware
>> which only supports BIOS booting
> 
> Note, we already do automated a-lot-more-than-nightly testing of ISOs
> on VMs that only support BIOS booting (qemu without UEFI). This won't
> help with the specific case of real-world systems whose firmware can't
> handle GPT-labeled disks, or similar things, but we will at least
> notice very quickly if BIOS boot just breaks entirely.

That is good to know, thanks.

If things do break, please Cc: biosboot-...@lists.fedoraproject.org
on any bugs filed.

Regards,

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

Announcing the Fedora BIOS boot SIG

[Hans de Goede]

Hi All,

Now that FESCo has decided (1) that Fedora will keep supporting BIOS
booting, the people working on Fedora's bootloader stack will need
help from the Fedora community to keep Fedora booting on systems which
require Legacy BIOS to boot.

To help with this the Fedora BIOS boot SIG (special interest group) has
been formed. The main goal of this SIG are to help the Fedora bootloader
people by:

1) Doing regular testing of nightly Fedora N + 1 composes on hardware
which only supports BIOS booting

2) Triaging and/or fixing BIOS boot related bugs.

A biosboot-...@lists.fedoraproject.org mailinglist and bugzilla account
has been created, which will be used to discuss testing result and as
assignee / Cc for bootloader bugzillas which are related to BIOS booting.

If you are interested in helping with Fedora BIOS boot support please
subscribe to the email-list:
https://lists.fedoraproject.org/admin/lists/biosboot-sig.lists.fedoraproject.org/

and add yourself to the Members section of the SIG's wiki page:
https://fedoraproject.org/wiki/SIGs/BiosBoot

Regards,

Hans

1) 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KCJCEQMHITAQUW4SMWU3AXIPZ65GSDSU/

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

Re: grub2 BIOS booting iso and code

[Hans de Goede]

Hi Brian,

On 4/14/22 01:52, Brian C. Lane wrote:
> A huge thanks to Thomas Schmitt for posting xorrisofs arguments :)
> 
> Here is a lorax PR switching to grub2 for BIOS and changing the layout
> of the iso as described in his post:
> 
> https://github.com/weldr/lorax/pull/1226
> 
> And a Fedora 36 iso:
> 
> https://bcl.fedorapeople.org/boot-grub2-f36.iso
> 
> I've tested this with:
> 
> - qemu bios -cdrom
> - qemu uefi -cdrom
> - qemu bios -hda
> - qemu uefi -hda
> - USB stick on uefi PC hardware with SB off
> - USB stick on UEFI PC hardware with SB on
> - USB stick on Apple hardware UEFI
>   2010 Macbook Air and 2012 Macbook Pro
> - Media test works on all of the above
> 
> I have not tested it on CD or DVD physical media. I have a stack of
> blank discs but apparently have unplugged all my drives to use their
> SATA ports for SSDs :)

Thank you so much for working on this.

I've dd-ed the boot-grub2-f36.iso to an USB stick and successfully
tested it on the following machines:

1. Siemens PC with an i5-2400 with 8G RAM
2. Fujitsu-Siemens PC with a Core 2 Duo E6600 2.4 Ghz dual core with 4G RAM
3. Dell Latitude E6400 (core 2 duo) with 4G RAM
4. Acer One AO532 netbook with a N450 + 2G RAM

The image booted fine on all 4 machines, so from a machine
compatibility pov this looks good to me.

There were 2 minor issues with machine 2:

1. After the "Welcome to GRUB" text the 3.5" floppy drive
was searched repeatedly before showing the grub bootmenu.
It also took like 5-10 seconds to show the menu.
I guess that grub is using a minimal grub.cfg which is looking
for the actual grub.cfg based on the partition uuid or some such
and it is also checking the floppy drive. I wonder if we can
tweak grub.cfg on the bootmedia to not do this?

2. Booting the kernel once making the selection in the menu
takes forever (I walked away after 1 minute). But it does boot
eventually and I just tried with a Fedora 36 nightly, thus using
syslinux and the same happens. I believe that the USB stack of the
BIOS on this machine simply is terribly slow and reading the
big kernel + ramdisk files one sector at a time. So there is
nothing we can do here. Since this also happens with syslinux
this is not something to worry about.

Regards,

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

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Hans de Goede]

Hi Robbie,

On 4/14/22 20:02, Robbie Harwood wrote:
> Hans de Goede  writes:
> 
>> What I envision for the SIG is:
>>
>> 1. I'm not sure if it is possible to setup group ownership
>> of pkgs in pagure? So to keep things simple the few packages which
>> are only necessary for BIOS boot can be handed over to me and then
>> I'll just add other people willing to help out as co-maintainers.
> 
> As I've mentioned multiple times elsewhere, this isn't about packages,
> and I don't think it's helpful to think in terms of them.
> 
>> And I would also like to have a discussion about splitting
>> the BIOS boot grub bits out into a separate src.rpm
>> (using the same Source0 as the main grub) so that this can
>> be build by the SIG without needing help from the bootloader
>> team (the main grub package can only be built by a few people
>> because of secureboot signing). The idea is to avoiding
>> bottlenecking on the bootloader team when some BIOS boot bugs
>> in grub need to be fixed, quoting from my original email about
>> this:
> 
> Trying to avoid re-hashing our lengthy off-list conversation, here are
> some thoughts (mine and other interested parties's):
> 
> At minimum, we need a Legacy BIOS SIG to provide:
> 
> - a "place" to assign bugs (e.g., email address)
> - a means to fix issues
> 
> By default, we understand the former to be the SIG's email address, and
> the latter to be PRs to dist-git of relevant packages.
> 
> The overall goal of the SIG needs to be to reduce load on existing
> bootloader contributors.

Ack I agree that bugzilla triage of BIOS boot bugs +
fixing them once identified needs to be the main focus
of the SIG.

That and regularly testing N + 1 boot media BIOS booting
to catch any regressions early on.

> If it is not doing this, it needs to be
> dissolved.
> 
> ## SIG package maintenance
> 
> If the SIG wants to maintain any BIOS-only packages, that's up to them.
> Assuming Brian's change to use grub2 instead of syslinux on legacy
> install media ( https://github.com/weldr/lorax/pull/1226 ), the only
> other packages in question here would be those to support VESA/fbdev:
> 
> - xorg-x11-drv-vesa
> - xorg-x11-drv-fbdev
> - xorg-x11-server-Xorg

I personally do not believe that it will be necessary to keep
maintaining VESA support, I agree that without legacy BIOS
support it definitely is not needed though. I believe that ajax
has submitted a separate change proposal for this, so this is
best discussed there.

> - syslinux

As you say it looks like this one may no longer be necessary and
otherwise the SIG can pick it up.

> ## Fedora deliverables
> 
> Given there is consensus that legacy BIOS is on its way out, we think
> Fedora release criteria in this area should be re-evaluated.  Not only
> does support change from "fully supported" to "best effort", but we
> should re-evaluate what is/isn't release blocking, and probably clarify
> who owns what parts.

Given what the server product folks have indicated that BIOS
boot support is quite important for them I'm not sure if changing the
release criteria is in order. I do agree that any blocker bugs related
to legacy BIOS booting should be assigned to; and taken care of by
the legacy BIOS boot SIG.

> ## grub2
> 
> By default, the Legacy SIG is expected to perform contributions in the
> form of triage and PRs.  Normal “upstream first” rules apply here (i.e.,
> send it wherever possible, otherwise send to the downstream rhboot
> repo).
> 
> Current grub2 maintainers consider splitting the package (probably grub2
> and grub2-pc, to match current naming, or grub2-legacy or something)
> undesirable for a number of reasons.  A nonexhaustive list of what would
> need to be satisfactorily resolved before a split could considered:
> 
> - There needs to be a primary (and probably secondary) package owner
>   from the SIG as a prerequisite for a new bugzilla component.
> 
> - Everything in grub2-common, grub2-tools, and grub2-tools-extra is
>   available on both UEFI and legacy.  In most cases, the content is in
>   fact shared: one file works on both.
> 
> - The new grub2-bios is secondary to the main grub2 package, which means
>   that the Legacy SIG is responsible for not conflicting with any grub2
>   subpackage, and nothing in grub2 can depend on anything in the legacy
>   package.
> 
> - More generally, problems with the shared core can and will manifest
>   primarily on one platform.  Bugzilla ping-pong needs to not be played.
> 
> - Feature incompatibilities can and will occur.  (Maybe this is okay, or
>   just the Legacy SIG's responsibility to sort out in all cases.)
> 
> - Current maintainers do not have much c

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Hans de Goede]

Hi,

On 4/13/22 23:11, Matthew Miller wrote:
> On Wed, Apr 13, 2022 at 12:56:11PM -0700, Kevin Fenzi wrote:
>> If that proves acceptable for change owners here that would perhaps take
>> care of the short term problem. What about longer term though? Would the
>> thought be that the BIOS sig would remain around for the forseeable
>> future maintaining BIOS boot? Or would there be some kind of roadmap to
>> retirement?
> 
> I think it would make sense for the group to be set up with with some sort
> of "retirement becomes the default if the SIG stops being active" policy. I
> mean, not as a surprise, but so the situation is clear.

That is fair, although I hope that if the SIG runs out of steam for this,
that at least it will still have enough life in it to send out a proper
notice about BIOS boot support is really going away.

Regards,

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

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Hans de Goede]

Hi Michel,

On 4/13/22 22:29, Michel Alexandre Salim wrote:
> On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
>> Hi,
>>
>>
>> 1. I'm not sure if it is possible to setup group ownership
>> of pkgs in pagure? So to keep things simple the few packages which
>> are only necessary for BIOS boot can be handed over to me and then
>> I'll just add other people willing to help out as co-maintainers.
>>
> yup, Python, Rust, and Go SIG does this all the time
> 
>> 2. Setup a mailinglist for this and have that in bugzilla + PR
>> Cc for all the relevant packages.
>>
> The group will get emailed just like a normal maintainer, IIRC. Someone
> will need to register that group's email in Bugzilla just like a normal
> account

Interesting, so how does this work. I just realized that to allow
adding a list to the Cc in pagure (src.fedoraproject.org) it probably
needs a FAS account too and then log in with that account and then
hit the "watch" button ?

So does this require creating a "fake" FAS account for the SIG ?

So the steps would be:

1. Request mailinglist
2. Create FAS account using mailinglist address as email 
3. Create bugzilla account using mailinglist address as email

?

All I can find on this is:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_encouraging_comaintainers_of_packages/#current_solution

Which does not describe haivng actual groups at all ?

And I don't see how I can put the mailinglist in the Cc
for bugs + PRs without creating a FAS account for it ?


Regards,

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

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Hans de Goede]

Hi David,

On 4/13/22 21:27, David Cantrell wrote:
> On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 4/13/22 18:07, David Cantrell wrote:
>>> On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
>>>> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
>>>>  wrote:
>>>>> The core issue still comes down to having resources to continue
>>>>> maintaining
>>>>> BIOS boot support in Fedora and so far no one has come forward to work
>>>>> on
>>>>> that.
>>>>
>>>> It's not true, although you can be forgiven for missing it in such a 
>>>> massive
>>>> thread. Hans proposed to start a BIOS SIG to handle this. This seems like a
>>>> very credible proposal.
>>>
>>> Ah, yes.  I do remember the post from Hans, but thought he was more 
>>> outlining
>>> how a Legacy BIOS SIG could work and what would need to happen rather than
>>> volunteering to set one up and do that.  But I went back and reread that 
>>> post
>>> and yes, he did volunteer to do just that.
>>
>> Correct.
>>
>>> If a video call happens to discuss this feature proposal, ensure Hans can
>>> attend.
>>
>> FWIW, ATM I think everything which can be said about
>> this has been said and I'm not sure if having a video
>> call about this will add anything new.
> 
> Agreed.
> 
>> As for setting up the SIG if necessary, my plan is to
>> try to keep the SIG lite weight on the process side
>> and focus on the practical things.
>>
>> What I envision for the SIG is:
>>
>> 1. I'm not sure if it is possible to setup group ownership
>> of pkgs in pagure? So to keep things simple the few packages which
>> are only necessary for BIOS boot can be handed over to me and then
>> I'll just add other people willing to help out as co-maintainers.
>>
>> 2. Setup a mailinglist for this and have that in bugzilla + PR
>> Cc for all the relevant packages.
>>
>> 3. Have people from the SIG regularly test Fedora N and
>> Fedora N + 1 (after branching) on machines which only support
>> BIOS booting and file bugs (if any) + report the results to
>> the mailinglist.
>>
>> 4. Have people from the SIG try to regularly do bugzilla
>> triage of relevant packages.
>>
>> And I would also like to have a discussion about splitting
>> the BIOS boot grub bits out into a separate src.rpm
>> (using the same Source0 as the main grub) so that this can
>> be build by the SIG without needing help from the bootloader
>> team (the main grub package can only be built by a few people
>> because of secureboot signing). The idea is to avoiding
>> bottlenecking on the bootloader team when some BIOS boot bugs
>> in grub need to be fixed, quoting from my original email about
>> this:
>>
>> """
>> I've been thinking about how this could be done for grub; also
>> because of the issue that the EFI builds of grub need to be
>> signed with Fedora's secure boot keys, which means only a few
>> people can do grub2 builds atm.
>>
>> One option which I think we should consider is sticking with
>> a single downstream git fork (until we have managed to get
>> everything we need upstream), so stick with:
>>
>> https://github.com/rhboot/grub2/
>>
>> As the Source0 provider for the packages and then next to:
>>
>> https://src.fedoraproject.org/rpms/grub2
>>
>> Add a:
>>
>> https://src.fedoraproject.org/rpms/grub2-bios
>>
>> And moving the build of all sub-packages which are
>> only necessary for BIOS support to the second src.rpm.
>>
>> This way the Legacy BIOS SIG could maintain
>> the grub2-bios src.rpm (and binary pkgs it builds).
>> The SIG _must_ then of course still submit pull-reqs to:
>> https://github.com/rhboot/grub2/ for any changes.
>>
>> But in case of e.g. a beta blocking BIOS only bug they
>> could solve that with a patch in the src.rpm and kickof
>> a build right away without blocking on the bootloader
>> team and thus without causing a spike in
>> work-pressure/load for the bootloader team.
>>
>> And then once the pull-req is merged (possibly
>> a revised version of it) the next build of
>> the grub2-bios src.rpm can pull in the new Source0
>> and drop its local changes (IOW grub2-bios _must_
>> not become a separate fork).
>> """
> 
> OK, given this proposal, I'd like the original change

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Hans de Goede]

Hi,

On 4/13/22 18:07, David Cantrell wrote:
> On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
>> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
>>  wrote:
>>> The core issue still comes down to having resources to continue
>>> maintaining
>>> BIOS boot support in Fedora and so far no one has come forward to work
>>> on
>>> that.
>>
>> It's not true, although you can be forgiven for missing it in such a massive
>> thread. Hans proposed to start a BIOS SIG to handle this. This seems like a
>> very credible proposal.
> 
> Ah, yes.  I do remember the post from Hans, but thought he was more outlining
> how a Legacy BIOS SIG could work and what would need to happen rather than
> volunteering to set one up and do that.  But I went back and reread that post
> and yes, he did volunteer to do just that.

Correct.

> If a video call happens to discuss this feature proposal, ensure Hans can
> attend.

FWIW, ATM I think everything which can be said about
this has been said and I'm not sure if having a video
call about this will add anything new.

As for setting up the SIG if necessary, my plan is to
try to keep the SIG lite weight on the process side
and focus on the practical things.

What I envision for the SIG is:

1. I'm not sure if it is possible to setup group ownership
of pkgs in pagure? So to keep things simple the few packages which
are only necessary for BIOS boot can be handed over to me and then
I'll just add other people willing to help out as co-maintainers.

2. Setup a mailinglist for this and have that in bugzilla + PR
Cc for all the relevant packages.

3. Have people from the SIG regularly test Fedora N and
Fedora N + 1 (after branching) on machines which only support
BIOS booting and file bugs (if any) + report the results to
the mailinglist.

4. Have people from the SIG try to regularly do bugzilla
triage of relevant packages.

And I would also like to have a discussion about splitting
the BIOS boot grub bits out into a separate src.rpm
(using the same Source0 as the main grub) so that this can
be build by the SIG without needing help from the bootloader
team (the main grub package can only be built by a few people
because of secureboot signing). The idea is to avoiding
bottlenecking on the bootloader team when some BIOS boot bugs
in grub need to be fixed, quoting from my original email about
this:

"""
I've been thinking about how this could be done for grub; also
because of the issue that the EFI builds of grub need to be
signed with Fedora's secure boot keys, which means only a few
people can do grub2 builds atm.

One option which I think we should consider is sticking with
a single downstream git fork (until we have managed to get
everything we need upstream), so stick with:

https://github.com/rhboot/grub2/

As the Source0 provider for the packages and then next to:

https://src.fedoraproject.org/rpms/grub2

Add a:

https://src.fedoraproject.org/rpms/grub2-bios

And moving the build of all sub-packages which are
only necessary for BIOS support to the second src.rpm.

This way the Legacy BIOS SIG could maintain
the grub2-bios src.rpm (and binary pkgs it builds).
The SIG _must_ then of course still submit pull-reqs to:
https://github.com/rhboot/grub2/ for any changes.

But in case of e.g. a beta blocking BIOS only bug they
could solve that with a patch in the src.rpm and kickof
a build right away without blocking on the bootloader
team and thus without causing a spike in
work-pressure/load for the bootloader team.

And then once the pull-req is merged (possibly
a revised version of it) the next build of
the grub2-bios src.rpm can pull in the new Source0
and drop its local changes (IOW grub2-bios _must_
not become a separate fork).
"""

Regards,

Hans

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

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Hans de Goede]

Hi,

On 4/11/22 01:07, Gabriel Ramirez wrote:
> On 4/10/22 16:10, Neal Gompa wrote:
>> On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
>>  wrote:
>>> On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
>>> [...]
 Probably it isn't a problem for some users, but I'm still having bad
 experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
 system that works fine with UEFI. And my parents' laptop was purchased
 2 years ago and the UEFI firmware does not allow to boot anything
 other than Windows on UEFI mode (regardless of turning secure boot on
 or off) and I have to switch to BIOS mode to make Fedora work there.
 So in this situation, I think it's way too aggressive to accept the
 change - this will probably drive away some potential new users with
 decent laptop like my parents'.
>>> Have you tried renaming your Fedora boot entry to "Windows Boot
>>> Manager"? I have one Sony laptop that boots only the boot entry with
>>> that exact name.
>>>
>> I wonder if this would work with one of my old machines too. I've
>> never thought to rename the boot entry in the firmware before...
>>
>>
> 
> about "Windows Boot Manager" efi entry required to boot: 
> https://mjg59.dreamwidth.org/20187.html
> 
> the above happens too with the lenovo thinkcentre m91

Yes and some UEFI-s will only consider non USB disks to be bootable if they
have a FAT ESP with  EFI/Microsoft/Boot/bootmgfw.efi on there.

Some of them are hardcoded to boot that file (just put shim + grubia32.efi
/ grubx64.efi there), while others check for the file, but boot another
path (which may also be hardcoded) see:

https://hansdegoede.dreamwidth.org/24232.html

For a couple of devices which I encountered which do this. I did not
know about the "Windows Boot Manager" name being a thing too.

So yes so much for UEFI being a sensible standard...

Regards,

Hans

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

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Hans de Goede]

Hi Brian,

On 4/8/22 19:14, Brian C. Lane wrote:



> So like I said yesterday, I'll look into switching to use grub2 for
> Fedora 37, assuming grub2 continues to support BIOS.

Thank you for looking into switching to using GRUB for the livecds.

If you have some test livecd img using grub instead of syslinux
for BIOS booting and you wanted it tested on some more / older
hw let me know and I'll test it on the BIOS-only machines which
I have.

Regards,

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

Re: F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)

[Hans de Goede]

Hi,

On 4/8/22 13:18, Kevin Kofler via devel wrote:
> Hans de Goede wrote:
>> So most hw will either be new enough to offer an efifb which
>> simpledrm will turn into a drm/kms /dev/dri/card0 device. Or it
>> will be old enough that it almost certainly will have
>> a drm/kms driver.
>>  
>> And for the really odd duck out a vesa mode can be set on the kernel
>> cmdline which simpledrm should then pick up:
>>  
>> https://www.kernel.org/doc/html/latest/admin-guide/svga.html
>> https://www.systutorials.com/configuration-of-linux-kernel-video-mode/
> 
> Thanks for the explanation. If that is true, then this change should be more 
> acceptable than the partly related "desupport all non-(U)EFI systems" one 
> (which I consider entirely unacceptable).
> 
> Still, I remain worried about the details, such as:
> * that, if VESA is needed, the VESA mode has to be configured through the
>   kernel CLI,
> * that, as far as I can see, switching to another mode with kernel VESA
>   requires a reboot (with different kernel CLI options),

Both are correct and are indeed somewhat of a downside, although I'm
not sure if Xorg ever automatically uses vesa as fallback of last
resort, or if this needs manual setup.

> * what will happen to the "basic video mode" boot option (as pointed out by
>   Kamil Paral).

That is a good question, AFAIK this is just adding nomodeset on the
kernel cmdline, so on UEFI systems we will just end up with simpledrm
using the EFI framebuffer device. I'm not sure what will happen with
legacy BIOS boot here though.

Regards,

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

Re: F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)

[Hans de Goede]

Hi,

On 4/8/22 07:01, Kevin Kofler via devel wrote:
> Ben Cotton wrote:
>> == Owner ==
>> * Name: [[User:ajax|Adam Jackson]]
>> * Email: a...@redhat.com
>>
>> == Detailed Description ==
>>
>> Fedora's primary desktop environments are moving away from being X11
>> sessions, to being Wayland servers in their own right. This transition
>> is incomplete, and the Xorg server is still potentially used in a
>> variety of "fallback" situations. In particular the `vesa` and `fbdev`
>> drivers can find themselves pressed into use when accelerated graphics
>> is unavailable. Both of these drivers are somewhat deprecated
>> upstream, and the code to reach them is increasingly fragile as it
>> gets exercised less and less.
>>
>> This change will identify the remaining configurations that can reach
>> these drivers, establish an alternative for display support for each
>> configuration, and then remove the drivers and their support code in
>> xserver.
> 
> Removing the fallback drivers that (almost) always work strikes me as an 
> extraordinarily bad idea. It will knowingly desupport any graphics hardware 
> not covered by the main drivers and it may turn out to unknowingly desupport 
> even more hardware, where the hardware-specific drivers that should work 
> actually do not. It also means that there will be no workaround at all if 
> the native driver is temporarily broken on the given hardware for whatever 
> reason. Hence, I am strongly opposed to this change.

Note that for Fedora 36 we have already dropped efifb and replaced it
with simpledrm:

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

So this means that in our default configs we no longer have any
fbdev drivers active.

And simpledrm can also be used with the kernels builtin vesa support
on legacy BIOS systems, so in essence starting with F36 we will always
have a drm/kms node available for the Xorg modesetting to bind to.

With the above Fedora *36* change in place the fbdev/vesa drivers
will be practically completely unused, so I don't really expect
any problems from this change.

As for odd hw out there, a lot of work has been the last couple
of years to make sure that we have drm/kms drivers for almost all
hw out there, esp. also focusing on weird server hw VGA cards.

So most hw will either be new enough to offer an efifb which
simpledrm will turn into a drm/kms /dev/dri/card0 device. Or it
will be old enough that it almost certainly will have
a drm/kms driver.

And for the really odd duck out a vesa mode can be set on the kernel
cmdline which simpledrm should then pick up:

https://www.kernel.org/doc/html/latest/admin-guide/svga.html
https://www.systutorials.com/configuration-of-linux-kernel-video-mode/

So I believe that this change is fine.

Regards,

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

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Hans de Goede]

Hi,

On 4/6/22 16:23, Neal Gompa wrote:
> On Wed, Apr 6, 2022 at 10:18 AM Hans de Goede  wrote:
>>
>> Hi,
>>
>> >  behalf of my employer (Red Hat)>
>>
>> On 4/5/22 16:52, Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>>
>> 
>>
>>> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>>> mandates that machines must have been made after 2006).
>>
>> But machines made between 2006-2012 generally did not have
>> EFI support, anf for example at home I still have several
>> machines from that era which are BIOS only in active use:
>>
>> 1. My daughter's workstation is an i5-2400 with 8G RAM, this
>> is a 3.1 GHz base-freq quad-core processor very easily
>> matching Fedora's minimal requirements. Currently running
>> Fedora 35 just fine. Making it impossible to keep using this
>> in the future is just causing unnecessary ewaste for no good
>> reason IMHO.
>>
>> 2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual
>> core machine with 4G RAM, which also still works fine for
>> what she uses it for.
>>
>> 3. The living room laptop is another Core 2 Duo machine with
>> 4G RAM.
>>
>> Looking specifically at fixed PCs and not laptops this
>> proposal would (eventually) turn 2/5 PCs in my home
>> unusable, which really is unacceptable IMHO.
>>
>> Also note that all these machines use somewhat older Intel
>> integrated graphics. As he has already mentioned on this
>> this thread, Dave Airlie has just spend a lot of time on
>> making sure those iGPU-s will work with a gallium driver
>> so that the classic mesa code can be removed and it seems
>> rather silly to drop support for this hw after just investing
>> a significant chunk of time to breathe new live into their
>> GPU support.
>>
>> So a big -1 from me for this proposal as it stand.
>>
>> ###
>>
>> But I do completely understand that there is a workload issue
>> for the bootloader team and the proposal also mentions:
>>
>>> == Contingency Plan ==
>>> Leave things as they are.  Code continues to rot.  Community
>>> assistance is required to continue the status quo.  Current owners
>>> plan to orphan some packages regardless of whether the proposal is
>>> accepted.
>>
>> If the current owners no longer want to support some packages
>> which are only necessary for legacy BIOS support, then orphaning
>> these seems completely reasonable to me.
>>
>> Maybe you can provide a list of these pkgs before hand so that
>> people can already volunteer as co-maintainers now and then
>> when they are orphaned, instead of orphaning them they can
>> be directly handed over (using the "give away" button) to the
>> new maintainers ?
>>
>>> Another fallback option could be, if a Legacy BIOS SIG organizes, to
>>> donate the relevant packages there and provide some initial mentoring.
>>
>> I believe that that is a great idea, I hereby volunteer to
>> try and setup such a SIG. If anyone reading this is interested
>> in joining such a SIG please drop me an email.
>>
>> I realize that there have been similar attempts around keeping
>> 32 bit x86 alive and that those have failed, but I believe that
>> this is different for a number of reasons:
>>
>> 1. i686 support required making sure that *all* of Fedora kept
>> working on i686, the problem was not just the kernel breaking
>> sometimes, but also that huge projects like libreoffice would
>> no longer start on i686 (at least on some of my machines).
>>
>> Legacy BIOS boot support is basically only about the image-creation
>> tools + the bootloader. As various people have mentioned in the
>> thread BIOS support is still very much a thing in data-centers,
>> so I expect the upstream kernel community to keep the kernel
>> working with this for at least a couple of years. Where as both
>> the kernel + many userspace apps were breaking on i686.
>>
>> 2. I personally basically gave up on i686 support also because
>> there was very little 32 bit only x86 hw around remaining in
>> active use when it was dropped. And what was still on active
>> use was getting close to unusable from a performance pov.
>> Where as here we are talking about up to 2nd and 3th gen
>> core i5 / i7 machines which are still quite performant.
>>
>> Esp. the 2nd gen core machines (Sandy Bridge) are still
>> quite popular and lots of people have hung on to desktops
>> wi

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Hans de Goede]

Hi,



On 4/5/22 16:52, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS



> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> mandates that machines must have been made after 2006).

But machines made between 2006-2012 generally did not have
EFI support, anf for example at home I still have several
machines from that era which are BIOS only in active use:

1. My daughter's workstation is an i5-2400 with 8G RAM, this
is a 3.1 GHz base-freq quad-core processor very easily
matching Fedora's minimal requirements. Currently running
Fedora 35 just fine. Making it impossible to keep using this
in the future is just causing unnecessary ewaste for no good
reason IMHO.

2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual
core machine with 4G RAM, which also still works fine for
what she uses it for.

3. The living room laptop is another Core 2 Duo machine with
4G RAM.

Looking specifically at fixed PCs and not laptops this
proposal would (eventually) turn 2/5 PCs in my home
unusable, which really is unacceptable IMHO.

Also note that all these machines use somewhat older Intel
integrated graphics. As he has already mentioned on this
this thread, Dave Airlie has just spend a lot of time on 
making sure those iGPU-s will work with a gallium driver
so that the classic mesa code can be removed and it seems
rather silly to drop support for this hw after just investing
a significant chunk of time to breathe new live into their
GPU support.

So a big -1 from me for this proposal as it stand.

###

But I do completely understand that there is a workload issue
for the bootloader team and the proposal also mentions:

> == Contingency Plan ==
> Leave things as they are.  Code continues to rot.  Community
> assistance is required to continue the status quo.  Current owners
> plan to orphan some packages regardless of whether the proposal is
> accepted.

If the current owners no longer want to support some packages
which are only necessary for legacy BIOS support, then orphaning
these seems completely reasonable to me.

Maybe you can provide a list of these pkgs before hand so that
people can already volunteer as co-maintainers now and then
when they are orphaned, instead of orphaning them they can
be directly handed over (using the "give away" button) to the
new maintainers ?

> Another fallback option could be, if a Legacy BIOS SIG organizes, to
> donate the relevant packages there and provide some initial mentoring.

I believe that that is a great idea, I hereby volunteer to
try and setup such a SIG. If anyone reading this is interested
in joining such a SIG please drop me an email.

I realize that there have been similar attempts around keeping
32 bit x86 alive and that those have failed, but I believe that
this is different for a number of reasons:

1. i686 support required making sure that *all* of Fedora kept
working on i686, the problem was not just the kernel breaking
sometimes, but also that huge projects like libreoffice would
no longer start on i686 (at least on some of my machines).

Legacy BIOS boot support is basically only about the image-creation
tools + the bootloader. As various people have mentioned in the
thread BIOS support is still very much a thing in data-centers,
so I expect the upstream kernel community to keep the kernel
working with this for at least a couple of years. Where as both
the kernel + many userspace apps were breaking on i686.

2. I personally basically gave up on i686 support also because
there was very little 32 bit only x86 hw around remaining in
active use when it was dropped. And what was still on active
use was getting close to unusable from a performance pov.
Where as here we are talking about up to 2nd and 3th gen
core i5 / i7 machines which are still quite performant.

Esp. the 2nd gen core machines (Sandy Bridge) are still
quite popular and lots of people have hung on to desktops
with those because the CPU performance increase in generations
after SNB have been rather underwhelming.

> Longer term, packages that cannot be wholly donated could be split,
> though it is unclear whether the synchronization thereby required
> would reduce the work for anyone.

I've been thinking about how this could be done for grub; also
because of the issue that the EFI builds of grub need to be
signed with Fedora's secure boot keys, which means only a few
people can do grub2 builds atm.

One option which I think we should consider is sticking with
a single downstream git fork (until we have managed to get
everything we need upstream), so stick with:

https://github.com/rhboot/grub2/

As the Source0 provider for the packages and then next to:

https://src.fedoraproject.org/rpms/grub2

Add a:

https://src.fedoraproject.org/rpms/grub2-bios

And moving the build of all sub-packages which are
only necessary for BIOS support to the second src.rpm.

This way the Legacy BIOS SIG could maintain
the grub2-bios src.rpm (and binary pkgs it 

Re: dist-git force push

[Hans de Goede]

Hi,

On 4/1/22 18:09, Ondrej Mosnacek wrote:
> On Fri, Apr 1, 2022 at 4:27 PM Robbie Harwood  wrote:
>> Kamil Dudka  writes:
>>
>>> On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote:
>>>
 - check whether the "new object name" is descendant of
 (contains) "old build object name" (rather than "old object name", which
 would forbid any force push)
 This would allow to rewrite a branch as long as the last commit hasn't been
 built yet (but allow only rewrites to commits since the last build). In
 particular, this would allow to avoid the many "commit missing patch",
 "actually commit the change", "duh" commits which happen after a successful
 `fedpkg build --scratch --srpm` followed by a half-(how do you say this
 nicely)ed commit.
>>>
>>> I thought the plan was to use pull requests with some CI checks to
>>> avoid this.
>>
>> I hope not.  Unless merging the PRs and kicking off the builds are done
>> automatically, this'll just be as painful as the current centos
>> workflow:
>>
>> - commit
>> - push to fork
>> - open PR
>> - wait for checks
>> - click "merge" button
>> - wait for bots
>> - kick off build
>>
>> compared with:
>>
>> - fedpkg commit -sc && fedpkg push && fedpkg build
>>
>> Context switches for maintainers are expensive!  And while I don't
>> personally think the "oops fixup" commits are a problem, a "PR with CI"
>> workflow doesn't get rid of them by any means.
> 
> Why not this then:
> 
> - fedpkg commit -sc && fedpkg scratch-build --srpm && fedpkg push &&
> fedpkg build

If people are going to use this, please make it one of:

1. If you have plenty of bandwidth + enough CPU + RAM:

fedpkg mockbuild && fedpkg commit -sc && fedpkg push && fedpkg build

2. Or if you don't:

fedpkg commit -sc && fedpkg scratch-build --arches=x86_64 --srpm && fedpkg push 
&& fedpkg build

Notice the --arches=x86_64, this is done because some of the
other arches have limited builder capacity.

Regards,

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

Re: cmake failure to build in rawhide?

[Hans de Goede]

Hi,

On 4/1/22 18:09, Kamil Dudka wrote:
> On Friday, April 1, 2022 5:45:38 PM CEST Hans de Goede wrote:
>> Hi All,
>>
>> While fixing a hedgewars F36 bug, the f37/rawhide build of the
>> fixed pkg is failing:
>>
>> In both F36 and F37 the invocation is:
>>
>> /usr/bin/cmake -S . -B redhat-linux-build
>> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
>> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
>> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
>> -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include
>> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
>> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
>> -DBUILD_SHARED_LIBS:BOOL=ON -DMINIMAL_FLAGS=1 -DNOVIDEOREC=1
>> -DBUILD_ENGINE_C=1 -DGHFLAGS=-dynamic
>> '-DFONTS_DIRS=/usr/share/fonts;/usr/share/fonts/google-noto-vf;/usr/share/f
>> onts/dejavu-sans-fonts;/usr/share/fonts/wqy-zenhei;' .
>  
>> Followed by a bunch of output and then weirdness happens, F37 last cmake
>> output line:
>  
>> -- Build files have been written to:
>> /builddir/build/BUILD/hedgewars-src-1.0.0
>  
>> vs F36 last output line:
>>
>> -- Build files have been written to:
>> /builddir/build/BUILD/hedgewars-src-1.0.0/redhat-linux-build
>  
>> F37 cmake seems to ignore the "-B redhat-linux-build" leading to this
>> subsequent build error:
>  
>> + /usr/bin/cmake --build redhat-linux-build -j6 --verbose
>> Error: /builddir/build/BUILD/hedgewars-src-1.0.0/redhat-linux-build is not a
>> directory
>  
>> Any help with this would be much appreciated.
>>
>> Regards,
>>
>> Hans
> 
> It is most likely this (not a) bug:

Thanks.

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

Ugh, what a mess. Anyways I've fixed this by dropping the extra "."
at the end of the %cmake invocation.

Regards,

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

cmake failure to build in rawhide?

[Hans de Goede]

Hi All,

While fixing a hedgewars F36 bug, the f37/rawhide build of the
fixed pkg is failing:

In both F36 and F37 the invocation is:

/usr/bin/cmake -S . -B redhat-linux-build 
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr 
-DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 
-DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share 
-DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DMINIMAL_FLAGS=1 -DNOVIDEOREC=1 
-DBUILD_ENGINE_C=1 -DGHFLAGS=-dynamic 
'-DFONTS_DIRS=/usr/share/fonts;/usr/share/fonts/google-noto-vf;/usr/share/fonts/dejavu-sans-fonts;/usr/share/fonts/wqy-zenhei;'
 .

Followed by a bunch of output and then weirdness happens, F37 last cmake output 
line:

-- Build files have been written to: /builddir/build/BUILD/hedgewars-src-1.0.0

vs F36 last output line:

-- Build files have been written to: 
/builddir/build/BUILD/hedgewars-src-1.0.0/redhat-linux-build

F37 cmake seems to ignore the "-B redhat-linux-build" leading to this 
subsequent build error:

+ /usr/bin/cmake --build redhat-linux-build -j6 --verbose
Error: /builddir/build/BUILD/hedgewars-src-1.0.0/redhat-linux-build is not a 
directory

Any help with this would be much appreciated.

Regards,

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

Re: rpmlint 2.x totally bogus output on debuginfo sub-pkgs

[Hans de Goede]

Hi,

On 2/23/22 15:23, Petr Pisar wrote:
> V Wed, Feb 23, 2022 at 01:45:02PM +0100, Hans de Goede napsal(a):
>> I'm wondering if I'm the only one who is seeing quite a few bogus
>> warnings / errors getting thrown by rpmlint when run on C/C++
>> debuginfo sub-pkgs ?
>>
>> And assuming I'm not the only one I'm wondering if there are some
>> plans to address / fix this ?
>>
>> I tend to always run rpmlint as part of my workflow to avoid
>> unnecessary mistakes getting pushed out, but all the new
>> false-positive  errors/warnings make this a lot more painful
>> then it used to be.
>>
> You are not the only one
> <https://bugzilla.redhat.com/show_bug.cgi?id=2052451>. Upstream claims that
> rpmlint is not expected to run on debuginfo subpackages. Hence it's up to
> "fedpkg lint" to exclude the debuginfo subpackages from linting.

Ah, thank you.

I did check: http://bugz.fedoraproject.org/rpkg but not fedpkg.

Note I believe that rpkg would be a more appropriate component since
that is where the actual logic is implemented AFAIK.

Regards,

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

rpmlint 2.x totally bogus output on debuginfo sub-pkgs

[Hans de Goede]

Hi All,

I'm wondering if I'm the only one who is seeing quite a few bogus
warnings / errors getting thrown by rpmlint when run on C/C++
debuginfo sub-pkgs ?

And assuming I'm not the only one I'm wondering if there are some
plans to address / fix this ?

I tend to always run rpmlint as part of my workflow to avoid
unnecessary mistakes getting pushed out, but all the new
false-positive  errors/warnings make this a lot more painful
then it used to be.

Regards,

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

Re: xorg-x11-server maintenance

[Hans de Goede]

Hi Fabio,

On 12/17/21 12:21, Fabio Valentini wrote:
> Hi all,
> 
> With the recent updates to use a standalone xwayland package, the
> "classic" xorg-x11-server package seems to have fallen into disrepair.
> It is multiple versions behind upstream (Fedora has 1.20.11, upstream
> has released 1.20.12, 1.20.13, 1.20.14, 21.1.0, 21.1.1, 21.1.2), and
> has open CVE issues attached to it.
> 
> A BugZilla query for the xorg-x11-server package reveals a worrying
> state of things, with bugs not being touched in ages, and the
> xgl-maint account that is the "main admin" and bugzilla assignee for
> multiple xorg-related packages has a *deactivated BugZilla* account,
> so NEEDINFO requests etc. don't work (no idea what else doesn't work,
> I suppose maintainers won't get bug emails either, if their bugzilla
> account doesn't work ...). Does it count as "non-responsive
> maintainer", if the maintainer doesn't have an active BugZilla
> account? :)
> 
> I know that Wayland is the default on many Fedora Editions / Spins,
> but some of us plebs still rely on X11 / X.org sessions and it would
> be great to have the X server package updated. For a
> security-sensitive component like the X server, this is a worrying
> state of things.

Thank you for pointing this out. I have it on good authority that
an updated pkg for the CVE is being worked on.

Note this does not takeaway that the classic Xorg server packages
could definitely use some love / use some community co-maintainers.

Regards,

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

Re: RFC: Reduce number of packages that are built for i686

[Hans de Goede]

Hi,

On 11/18/21 16:27, Fabio Valentini wrote:
> On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto  wrote:
>>
>> Hi,
>> another subject that can be related
>>
>> In thread "I think we should stop building i686 packages we're not
>> shipping" we are alerted for builds for i686 that aren't publish .
>> Following the tip , I found some packages that we aren't shipped are
>> needed to allow mock start the buildroot for example tar-1.34-
>> 2.fc35.i686.rpm, tar is only available on koji local repo (1).
>>
>> I think we should have all i686 packages, that are needed to start a
>> buildrooot, published. i.e. available on x86_64 repos. To allow mock
>> build i686 packages without need to access to internal koji local repo
>> (which may not be public) .
> 
> This would break all sorts of things.
> 
> It's also not compatible with the current packaging guidelines,
> because packages must not conflict with each other unless they have an
> explicit Conflicts tag and a good reason to do so. in this case,
> tar.x86_64 and tar.i686 would conflict with each other (both providing
> /usr/bin/tar, among other files)

Ah, I see it has been so long ago since we made the switch that
some people no longer know the intricate details of how multilib
works :) Elf binaries are treated specially by rpm and are what
rpm calls colored IIRC. Not sure why it is called that, but the way
it works is that you can install both an i686 and x86_64 /usr/bin/tar
file with rpm and if you install i686 first then it will get replaced
with the x86_64 binary when you install that and if you install x86_64
first then that binary will stay in place (*).

This is done so that some package containing mainly a few .so.x libs
but also some small utils can be installed in multi-lib form without
need to split out the /usr/bin/utils into a separate package.

> so that's out of the question.

Not necessarily, note some files under e.g. /usr/share could still
conflict, but typically they do not.

Regards,

Hans



*) And I must admit I have no idea what happens if you remove the
x86_64 pkg while you still have the i686 pkg installed, maybe an
error ?

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

Re: F36 Change: Make Authselect Mandatorry (System-Wide Change proposal)

[Hans de Goede]

Hi Pavel,

On 10/14/21 12:57 PM, Pavel Březina wrote:
> On 10/13/21 3:17 PM, Michael Catanzaro wrote:
>> On Wed, Oct 13 2021 at 10:22:14 AM +0200, Hans de Goede 
>>  wrote:
>>> Making what IMHO is a poor default of always using sssd everywhere
>>> hardcoded even deeper into Fedora seems like a bad idea to me.
>>
>> I think we can fix this at the same time. Make authselect default to its 
>> minimal profile rather than its sssd profile, and make realmd responsible 
>> for running authselect to enable the sssd profile when it is required. I 
>> think realmd is already capable of installing the dependencies it needs when 
>> enabled, right? This way, most Fedora systems would no longer run sssd, but 
>> enabling enterprise login would not require manual configuration for those 
>> who need it.
> 
> Minimal profile is really minimal and does not provide almost any flexibility 
> so imho it should not be used as a default. We could however create a new 
> profile e.g. "local".
> 
> SSSD is default because it was serving local users as well. This in no longer 
> true since F35 [1], so there is certainly a possibility to switch the 
> default, if the community desires it and it is certainly beneficial to do it 
> together with this change.
> 
> I don't see a strong reason to change the default profile. Local users go 
> through nss_files and pam_unix, if SSSD is not running it does not do 
> anything.

Sorry, I somehow completely missed the F35 change to make files the first entry
in nssswitch.conf by default now.

I see on the changes (1) page that SSSD now also no longer is started by 
default,
that is great. 

Since SSSD already no longer runs by default, then I see no need
for a special "local" profile.

Thank you for your work on this!

Regards,

Hans

1) https://fedoraproject.org/wiki/Changes/FlexibleLocalUserCache

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

Re: F36 Change: Make Authselect Mandatory (System-Wide Change proposal)

[Hans de Goede]

Hi,

On 10/12/21 5:32 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
> 
> == Summary ==
> This change wants to make authselect required to configure
> authentication and identity sources and forcefully update
> non-authselect configuration to the sssd authselect profile to
> eliminate any existing non-authselect setups.
> 
> Even though it will still be possible to manually modify the
> configuration, users that require special configuration should create
> and use custom authselect profile.
> 
> ''Authselect is available in Fedora since Fedora 27 and enabled by
> default on new installations since Fedora 28. Authconfig compatibility
> tool was removed from Fedora 35 as a
> [[Changes/RemoveAuthselectCompatPackage|system wide change page]]. It
> is now well accepted by the community as well as the package
> maintainers. The package maintainers have repeatedly requested to make
> authselect mandatory for the users which lead to creation of
> [https://bugzilla.redhat.com/show_bug.cgi?id=2000936 this bugzilla].''
> 
> == Owner ==
> * Name: [[User:pbrezina|Pavel Březina]]
> * Email: pbrez...@redhat.com
> 
> 
> == Detailed Description ==
> The following components must be updated to make authselect mandatory:
> * authselect
> * pam
> * glibc
> * packages that use it: systemd, ecryptfs, nss-mdns and fingerprint.
> 
> 
> Required changes:
> # Remove user-nsswitch.conf functionality from authselect
> # Move ownership of /etc/nsswitch.conf and /etc/pam.d/{system-auth,
> password-auth, smartcard-auth, fingerprint-auth, postlogin} to
> authselect from glibc and pam
> # Require authselect in pam
> # Remove non-authselect support from systemd, ecryptfs, nss-mdns and 
> fingerprint
> # Select default profile when authselect is installed
> # Select default profile when authselect is upgraded
> 
> === Remove user-nsswitch.conf functionality ===
> File /etc/authselect/user-nsswitch.conf was introduced in authselect
> to allow partial user modifications of nsswitch.conf without the need
> to create a custom authselect profile. The main driver was to enable
> modules that are not included in authselect such as systemd-resolved
> and nss-mdns.
> 
> This however made the situation more confusing to users and it is not
> desirable any more if authselect is mandatory.
> 
> '''Authselect will drop user-nsswitch.conf functionality and instead
> add more nsswitch modules to existing profiles and be more open about
> future inclusion requests.'''
> 
> === Own /etc/nsswitch.conf and /etc/pam.d/{system-auth, password-auth,
> smartcard-auth, fingerprint-auth, postlogin} instead of glibc and pam
> ===
> File /etc/nsswitch.conf is currently owned by glibc. It will be now
> owned by authselect and removed from glibc.
> 
> PAM configuration generated by authselect is currently owned by pam.
> It will be now owned by authselect and removed from pam.
> 
> ''Note: that config-util and other will still be owned by pam since
> these files are not generated by authselect.''
> 
> '''All files that are generated by authselect are now owned by authselect.'''
> 
> === Require authselect in pam ===
> The pam package will require authselect. This will tie pam and
> authselect together and it will be impossible to uninstall authselect
> without uninstalling pam which fundamentally makes authselect a hard
> dependency on each system.
> 
> '''This step will make it impossible to uninstall authselect, making
> it always available to RPM packages.'''
> 
> === Remove non-authselect support from systemd, ecryptfs, nss-mdns and
> fingerprint ===
> '''Non-authselect configuration support will be dropped in these packages.'''
> 
> === Select default profile when authselect is installed ===
> If authselect configuration is not detected and this is a new
> installation of authselect it will automatically select the
> distribution default authselect profile by calling authselect select
> --force with distribution specific parameters.
> 
> If existing authselect configuration is detected (perhaps from
> previous installation), it will be updated (current behavior).
> 
> This makes sure that if authselect is installed (which is always) a
> configuration is created.
> Select default profile when authselect is upgraded
> If authselect is upgraded from an older version and non-authselect
> configuration is detected, it will forcefully overwrite it with
> distribution defaults by calling authselect select --force with
> distribution specific parameters.
> 
> This is a one time event so if someone does not want to use
> authselect, it remains possible. However, non-authselect
> configurations will not be supported by RPM packages mentioned above.
> 
> If authselect is upgraded on a system that already is configured by
> it, the update process remains the same as it is now.
> 
> '''This step will forcefully update existing installations to
> authselect configuration. It is a one time event and opt-out is still
> possible but no 

Re: Boot menu always displayed again?

[Hans de Goede]

Hi,

On 9/7/21 1:34 PM, Vít Ondruch wrote:
> 
> Dne 07. 09. 21 v 9:26 Hans de Goede napsal(a):
>> Hi,
>>
>> On 9/6/21 5:13 PM, Vít Ondruch wrote:
>>> Not sure if that is intentional, but if I am not mistaken, boot menu used 
>>> to be hidden if there were no issues, but it seems to be always on ATM. Is 
>>> this intentional?
>> What is the output of running:
>>
>> sudo grub2-editenv - list
> 
> 
> ~~~
> $ sudo grub2-editenv - list
> boot_success=1
> boot_indeterminate=0
> saved_entry=ec300db9bfdf4776bc07b7f4281374a5-5.14.1-300.fc35.x86_64
> 
> $ uname -a
> Linux localhost.localdomain 5.14.1-300.fc35.x86_64 #1 SMP Fri Sep 3 16:27:33 
> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
> ~~~

Ok, so for some reason this is missing the "menu_auto_hide=1" setting.

You can fix this by running:

sudo grub2-editenv - set menu_auto_hide=1

The question is why anaconda did not do this though. How did you install
this system?


> I have reported this against grub2:
> 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2001885

I've added the same comment there.

Regards,

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

Re: Boot menu always displayed again?

[Hans de Goede]

Hi,

On 9/6/21 5:13 PM, Vít Ondruch wrote:
> Not sure if that is intentional, but if I am not mistaken, boot menu used to 
> be hidden if there were no issues, but it seems to be always on ATM. Is this 
> intentional?

What is the output of running:

sudo grub2-editenv - list

Also is this a multi-boot system, or does grub at least think it is
a multiboot system? IOW does your grub-menu have a "Windows"
boot entry?

On multiboot systems the menu is always shown so that you can pick
Windows at boot.

Regards,

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

Re: can we remove device-mapper-multipath from default desktop installs?

[Hans de Goede]

Hi,

On 9/6/21 7:57 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Sep 05, 2021 at 04:43:01PM -0600, Chris Murphy wrote:
>> On Fri, Sep 3, 2021 at 10:47 AM Chris Murphy  wrote:
>>>
>>> systemd-udev-settle.service is deprecated. Please fix
>>> multipathd.service not to pull it in.
>>> https://bugzilla.redhat.com/show_bug.cgi?id=2001058
>>>
>>> This is not a regression, it's been around for a while with bugs that
>>> get no action. I'm wondering if we can just pull it out of the default
>>> installations? The only thing I can think of that (conditionally)
>>> needs it early on in a default case is Anaconda but only if there are
>>> multipath devices, which is probably pretty rare in the Workstation
>>> edition and desktop spins case?
> 
> +1 to dropping it. I'm sure it sees very little usage in Fedora
> installations. If somebody needs it, they can add it after installation.
> 
>> It's in Fedora 34 and 35:
>> https://pagure.io/fedora-comps/blob/main/f/comps-f35.xml.in#_59
>>
>> And I think that's why it's being dragged in post-install with regular
>> updates, even though it's not on the install media:
> 
> Yes, I think it's only pulled in through comps. It can be uninstalled
> without issue.

Hmm, I already fixed this for F33:
https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD

And I just checked and in F34 device-mapper-multipath is still not part
of the Workstation livecd.

So at least for the livecd, which is the default download, this is
already resolved.

Regards,

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

Re: replace memtest86+ with pcmemtest, needs maintainer

[Hans de Goede]

Hi,

On 8/30/21 9:35 PM, Gordon Messmer wrote:
> On 8/30/21 12:08 PM, Hans de Goede wrote:
>>
>> I checked the entry on a Windows multiboot system and it does not have the
>> "insmod chain" line, maybe droppint that helps?
> 
> 
> Same result.  GRUB returns immediately to its menu.  I'm certain the path is 
> correct, because GRUB will report an error if it is wrong.

So I took a quick look myself and I could not get this to work either,
the EFI binary is weird and the talk of "Linux handoff protocol" in the
README makes me think that the grub menu entry actually should look
like this:

linux /pcmemtest.efi

I tried that, with Fedora's grub but it does not work either
(the screen goes black IIRC).

Still I believe this is how it is supposed to work, also because
of this:

[root@x1 ~]# file /boot/efi/EFI/fedora/pcmemtest.efi 
/boot/efi/EFI/fedora/pcmemtest.efi: Linux kernel x86 boot executable bzImage, 
version \353fHdrS\014\002, RW-rootFS,

I believe this is not working with Fedora's EFI grub binaries
because we patch grub to not use the handover protocol when
running in EFI mode. The Linux x86_64 vmlinuz image actually
has an EFI stub, so that it can be executed as an EFI
executable without needing a bootloader at all. And AFAIK that
stub actually works better / on more hw then letting grub
do the BIOS oriented handover-protocol thingie on EFI.

So the Fedora EFI grub is patched to treat a "linux" line
as a chainload line (more or less) with the exception of
doing some stuff to pass the cmdline + initrd.

It might be interesting to try and using e.g. an EFI
grub binary from Ubuntu with a:

linux /pcmemtest.efi

menu entry, to confirm my theory and after that it is probably
best to reach out to pcmemtest's upstream about this.

Regards,

Hans



p.s.

Note that pcmemtest does not really seem to be a "proper"
EFI app instead it just contains the bare essentials to run,
but e.g. keyboard input does not work unless the BIOS compat
module of the EFI is enabled, which now a days usually it is
not. So I'm afraid that getting this ready will require a
fair amount of work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: replace memtest86+ with pcmemtest, needs maintainer

[Hans de Goede]

Hi,

On 8/30/21 7:11 PM, Gordon Messmer wrote:
> On 8/30/21 12:20 AM, Hans de Goede wrote:
>> For the grub bit I think you just need a menu entry with a chainloader
>> line in there, similar to how booting Windows in a multi-boot setup works.
> 
> 
> Among other things, I've tried
> 
>     insmod chain
>     chainloader //pcmemtest.efi
> 
> When that menuentry is selected, GRUB2 will immediately return to its list.  
> I've never dual-booted Windows on a UEFI system, so I don't know if there's 
> more to it than that.

I checked the entry on a Windows multiboot system and it does not have the
"insmod chain" line, maybe droppint that helps?

Regards,

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

Re: replace memtest86+ with pcmemtest, needs maintainer

[Hans de Goede]

Hi,

On 8/29/21 11:46 PM, Gordon Messmer wrote:
> On 8/1/21 3:54 PM, Neal Gompa wrote:
>> But that doesn't stop anyone from maintaining an unsigned version.
> 
> 
> The documentation suggests that the UEFI binary can be loaded directly (which 
> I've done), or through the EFI handover protocol. I haven't done the latter 
> successfully yet.  If I work out the correct GRUB invocation, I'll add 
> another helper and submit this for review.
> 
> https://fedorapeople.org/cgit/gordonmessmer/public_git/pcmemtest-unsigned-x64.git/
> https://gordonmessmer.fedorapeople.org/pcmemtest-unsigned-x64/

Thank you for working on this. For the grub bit I think you just need a menu 
entry with a chainloader
line in there, similar to how booting Windows in a multi-boot setup works.

Regards,

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

Re: Fedora 34 90 second timeout in initrd / dbus ordering issue

[Hans de Goede]

Hi,

On 7/29/21 12:57 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jul 29, 2021 at 09:16:48AM +0200, drago01 wrote:
>> On Thursday, July 29, 2021, Hans de Goede  wrote:
>>
>>> Hi Zbigniew, Justin,
>>>
>>> I assume you are familiar with $subject, also see e.g. :
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1976653
>>>
>>> I have just come back from a week vacation and I see that this is
>>> still not resolved, what is the current status of this ?
>>>
>>> This is really making Fedora look bad, IMHO we really need to
>>> get this fixed ASAP. Are there any ideas what is necessary to
>>> fix / who we need to poke to get this fixed?
>>>
>>
>> Revert the change that caused it? I don't get from the bug why it was added.
> 
> I assume David is on vacation… I fired of a build for F34 and rawhide with
> After=sysinit.target removed. I also opened a pull request upstream [1].
> 
> [1] https://github.com/bus1/dbus-broker/pull/271

Great, thank you.

Regards,

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

Fedora 34 90 second timeout in initrd / dbus ordering issue

[Hans de Goede]

Hi Zbigniew, Justin,

I assume you are familiar with $subject, also see e.g. :

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

I have just come back from a week vacation and I see that this is
still not resolved, what is the current status of this ?

This is really making Fedora look bad, IMHO we really need to
get this fixed ASAP. Are there any ideas what is necessary to
fix / who we need to poke to get this fixed?

Regards,

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

mdbtools soname change (libmdb, libmdbaql) change coming to rawhide

[Hans de Goede]

Hi All,

I'm currently working on rebasing mdbtools to the 0.9.z series,
which includes a soname bump.

This means that libgda and recutils need to be rebuild
(and possible patched as there are some small API changes).

I've also noticed that both libgda and recutils are a bit
behind downstream, there is a libgda 5.2.10 and a recutils
1.8 available. Both mostly contain bugfixes over the 5.2.9 /
1.7 versions which are currently in Fedora.

I also plan to rebase both versions while at it.

The new mdbtools is already available in the f35-build-side-43465
koji tag.

A rebased libgda us currently rebuild against the new
mdbtools in that same tag.

I'm preparing the rebase + rebuild of recutils and
I will submit a build for that in the f35-build-side-43465
tag soon too.

Regards,

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

Re: License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler

[Hans de Goede]

Hi,

On 7/9/21 6:56 PM, Ben Beasley wrote:
> Hans,
> 
> Thanks for noticing, and for your very reasonable question.
> 
> In all of these cases, the CC0 component was due to the AppData XML file for 
> a desktop application. (In libinstpatch, the Public Domain component was due 
> to md5-plumb “copylib” source files that are linked into the library.)
> 
> I’ve retained the pre-existing detailed comments in the spec files, so there 
> is still some record of per-file licensing for the curious.
> 
> -
> 
> Your interpretation of preserving separate license terms in the License field 
> when they apply to separate installed files seems to be supported by 
> https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple_licensing_situations.3F,
>  at least in the case of separate compiled binaries. However, there was a big 
> discussion about effective licensing on the fedora-devel list a month or two 
> ago (and, a little earlier, a question on fedora-legal) specifically 
> concerning CC0-licensed AppData XML files.
> 
> I recall that all parties who spoke up felt it was correct to form an 
> effective license that did not mention CC0 in this case. As far as I know, 
> everyone understood that the AppData is installed as a separate XML file 
> asset and not linked into the code. Some seemed to feel that leaving CC0 in 
> the License field rather than forming a simpler effective license is actually 
> *wrong* and should not be allowed, an opinion I don’t share but don’t care to 
> debate.> 
> -
> 
> I am hoping not to initiate a broader discussion of when it is and isn’t 
> reasonable to expect packagers to derive effective licenses. Suffice it to 
> say that, in these specific simple cases, I think the changes are clearly 
> consistent with the community consensus, such as it is, and with guidance 
> from fedora-legal.

Not listing the CC0 in case when it is only used for the appdata xml file seems 
reasonable to me. In this case the intent of the author of the file clearly was 
to give as broad a license as possible (1), so I think that not listing it 
separately is fine for appdata xml files (still not a lawyer, etc.).

1) arguably CC0 always indicates the author is trying to not claim any rights 
in so far possible, but that is a separate discussion.

Regards,

Hans



> On 7/9/21 10:07 AM, Hans de Goede wrote:
>> Hi Benjamin,
>>
>> On 7/9/21 3:47 PM, Benjamin Beasley wrote:
>>> I’ve updated several of my packages to use only the “effective license” in 
>>> their License fields, in cases where it was very clear that a single 
>>> effective license was correct. The following packages are affected:
>>>
>>> - agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
>>> - appeditor: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
>>> - gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
>>> - harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
>>> - libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
>>> - notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
>>> - sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
>>
>> In general this is the right thing to do, thank you for simplifying
>> the License field for these packages.
>>
>> One remark about this tough, I wonder what files the CC0 licenses
>> were for ?
>>
>> Sometimes acceptable CC licenses (typically other ones then CC0)
>> are used for assets, like icons / artwork / docs.
>>
>> In that case, since those assets are not linked into a resulting
>> binary the assets stay under the CC license (AFAIK, IANAL, etc.).
>>
>> So if that is the case for any of the above packages then the new
>> License field should still include the "and CC0", with the binaries
>> being under the GPL variant and the assets being under CC0.
>>
>> This is typically documented with a comment in the .spec above the
>> License field explaining things.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>
>>
>>
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>> Do not reply to spam on the list, report it: 
>>> https://pagure.io/fedora-infrastructure
>>>
>>
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler

[Hans de Goede]

Hi Benjamin,

On 7/9/21 3:47 PM, Benjamin Beasley wrote:
> I’ve updated several of my packages to use only the “effective license” in 
> their License fields, in cases where it was very clear that a single 
> effective license was correct. The following packages are affected:
> 
> - agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
> - appeditor: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
> - gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
> - harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
> - libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
> - notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
> - sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”

In general this is the right thing to do, thank you for simplifying
the License field for these packages.

One remark about this tough, I wonder what files the CC0 licenses
were for ?

Sometimes acceptable CC licenses (typically other ones then CC0)
are used for assets, like icons / artwork / docs.

In that case, since those assets are not linked into a resulting
binary the assets stay under the CC license (AFAIK, IANAL, etc.).

So if that is the case for any of the above packages then the new
License field should still include the "and CC0", with the binaries
being under the GPL variant and the assets being under CC0.

This is typically documented with a comment in the .spec above the
License field explaining things.

Regards,

Hans






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

Re: Guile & Fesco requiring package maintenance work (was: Re: guile22 -> gnutls -> lots of virt packages)

[Hans de Goede]

Hi,

On 7/7/21 2:14 PM, Florian Weimer wrote:
> * Hans de Goede:
> 
>> Hi,
>>
>> On 7/7/21 1:08 PM, Florian Weimer wrote:
>>> * Neal Gompa:
>>>
>>>> Wait, why don't we have guile 3.0?
>>>
>>> We have a mandate from Fesco that the core toolchain must depend on
>>> Guile.  Naturally that makes updates rather difficult.
>>
>> So I've gone and checked the Fesco issue where dropping guile
>> support from make + gdb was discussed:
>>
>> https://pagure.io/fesco/issue/2558
>>
>> And I must say that I find the argumentation for rejecting the
>> change very very weak. I would really expect Fesco to make better
>> motivated decisions then this one.
>>
>> I'm especially shocked about how Fesco is in essence mandating
>> a group of maintainers to spend time maintaining a feature
>> where they clearly have indicated they don't want to maintain
>> that feature.
> 
> I guess this is partly on us (on the toolchain side).  We missed the
> meeting

Yes that was less then ideal OTOH since there was no majority to
either reject or accept it would have been better IMHO for Fesco
to simply postpone the decision and explicitly invite you for the
next meeting.



>> My being shocked here is not so much about the guile issue,
>> but about a IMHO much bigger issue underlying this decision:
>>
>> Since when does Fesco get to mandate on which features our
>> volunteer maintainers get to spend there time ?
> 
> Most of us Fedora toolchain maintainers aren't volunteers in the actual
> sense of the word, so we shouldn't play the volunteer card (and Fesco
> probably knew this too).  I know that several members of the Red Hat
> Platform Tools team (who maintain the toolchain downstream) have Fedora
> work as goals or key responsibilities.

Right, I knew that already, but IMHO that only makes this Fesco
decision worse, if you were true volunteers you could choose to simply
walk away (which even for volunteers is not an easy decission, but it
is a real option) where as now you are stuck between a rock and a
hard place, which I see as worse then the pure volunteer situation.

I think it is great how you are simply taking this in stride,
if I were in your shoes I would certainly be very unhappy about this.

Anyways Neal and Miro have indicated that they would be happy to
revisit this for Fedora 35, so I think the best way forward here is
to resubmit the change for Fedora 35, you can still do this until
2021-07-20 .

Regards,

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

Re: guile22 -> gnutls -> lots of virt packages

[Hans de Goede]

Hi,

On 7/7/21 1:53 PM, Neal Gompa wrote:
> On Wed, Jul 7, 2021 at 7:38 AM Hans de Goede  wrote:
>>
>> Hi,
>>
>> On 7/7/21 1:08 PM, Florian Weimer wrote:
>>> * Neal Gompa:
>>>
>>>> Wait, why don't we have guile 3.0?
>>>
>>> We have a mandate from Fesco that the core toolchain must depend on
>>> Guile.  Naturally that makes updates rather difficult.
>>
>> So I've gone and checked the Fesco issue where dropping guile
>> support from make + gdb was discussed:
>>
>> https://pagure.io/fesco/issue/2558
>>
>> And I must say that I find the argumentation for rejecting the
>> change very very weak. I would really expect Fesco to make better
>> motivated decisions then this one.
>>
>> I'm especially shocked about how Fesco is in essence mandating
>> a group of maintainers to spend time maintaining a feature
>> where they clearly have indicated they don't want to maintain
>> that feature.
>>
>> My being shocked here is not so much about the guile issue,
>> but about a IMHO much bigger issue underlying this decision:
>>
>> Since when does Fesco get to mandate on which features our
>> volunteer maintainers get to spend there time ?
>>
>> I understand there need to be rules and I can understand
>> Fesco denying approval for enabling / adding certain
>> features for a wide set of reasons, thus in essence blocking
>> volunteers from spending time on something because that
>> something is deemed undesirable for Fedora.
>>
>> But this is different here Fesco is telling a group of
>> maintainers that they must maintain a feature even though
>> they have indicated that they find the benefits of that
>> feature not worth the amount of time it costs to maintain
>> support for that feature. So in essence Fesco is telling
>> the maintainers that they MUST spend time maintaining this
>> even though they don't want this.
>>
>> IMHO this is just outrageous and goes way way beyond the
>> purview of Fesco.
>>
>> Now if dropping this feature would cause major breakage this
>> would a different story, But in the whole discussion about
>> this, at least as documented in the Fesco issue, no actual
>> users of this feature have been indentified and nothing will
>> break by disabling this as far is is known. So since there
>> is no known breakage caused by this, I end up circling back
>> to this basically telling Fesco that the make/gdb timers
>> MUST spend them on maintaining this even though they
>> don't want to (and have good reasons for not wanting to).
>>
>> Which again, is IHMO pretty outrageous really.
>>
>> Sorry Fesco, I know that you all do a lot of (hard) work
>> as Fesco members and do your best when making decisions
>> like this; and I don't doubt that your intentions where
>> well, but you made a big booboo here (IMHO).
>>
>> I urge Fesco to reconsider this and I suggest that we
>> (Fedora) take another serious look at implementing:
>> https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain
>> for Fedora 35.
>>
> 
> If you want to be outraged at FESCo about this, then read the meeting
> log first[1].
> 
> My main point then is that *all* of the Change authors are upstream
> developers in the GNU Toolchain, meaning that they have to do
> maintenance effort around Guile support upstream anyway.

That is not how upstreams work, I'm an upstream kernel maintainer
that does not mean that I'm responsible for every feature which the
kernel has. Just become some upstream make maintainers care about
guile support enough to keep it alive upstream does not mean that
the Fedora toolchain people work on it upstream.

Also upstream maintenance != package maintenance. AFAIK having the
guile dep in make leads to circular deps causing a whole bunch of
work to update to a version which breaks the soname/ABI, as well
as causing pain for bootstrapping. IOW even if the feature is
100% ready to go upstream there still is a downstream price to
pay for enabling it.

> If they want
> to remove a feature that makes Fedora the best place to use the GNU
> Toolchain, they should do it upstream first.

And again you are telling other people what they should do,
last time I checked Fesco was supposed to be about policy,
not telling other people what they should do.

With this same logic the Fedora kernel MUST support every feature
which the upstream kernel supports, even features which the Fedora
kernel maintainers explicitly do not want to support. Or for that
matter every Fedora package MUST support every feature which upstream
of that package support. Last time I checked we left 

Re: guile22 -> gnutls -> lots of virt packages

[Hans de Goede]

Hi,

On 7/7/21 1:33 PM, Neal Gompa wrote:
> On Wed, Jul 7, 2021 at 7:18 AM Florian Weimer  wrote:
>>
>> * Neal Gompa:
>>
>>> On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer  wrote:

 * Neal Gompa:

> Wait, why don't we have guile 3.0?

 We have a mandate from Fesco that the core toolchain must depend on
 Guile.  Naturally that makes updates rather difficult.
>>>
>>> Are you telling me that GNU Make doesn't support GNU Guile 3.0?
>>> Because that's definitely not true:
>>> https://git.savannah.gnu.org/cgit/make.git/tree/configure.ac#n182
>>
>> No, Guile is just a core toolchain package, so it's difficult to update.
>>
>> I think it would be much easier (and self-contained) if it weren't a
>> required part of the toolchain.
>>
> 
> You already have the toolchain update change[1], just do it as part of that.
> 
> [1]: https://fedoraproject.org/wiki/Changes/GNUToolchainF35

Ugh, please see my other long reply in this thread
(probably best to reply there)

I felt that I must respond here too, because "just do it as part of that"
is again you (a Fesco member) telling others what to do, or at least
sound a lot like you are telling others what to do, which completely
rubs me the wrong way.

Last time I checked Fesco's role was to set policy, not to dictate how
other Fedora project members spend there time. So this very nicely
illustrates the point which I'm trying to make in my other email/

Regards,

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

Re: guile22 -> gnutls -> lots of virt packages

[Hans de Goede]

Hi,

On 7/7/21 1:08 PM, Florian Weimer wrote:
> * Neal Gompa:
> 
>> Wait, why don't we have guile 3.0?
> 
> We have a mandate from Fesco that the core toolchain must depend on
> Guile.  Naturally that makes updates rather difficult.

So I've gone and checked the Fesco issue where dropping guile
support from make + gdb was discussed:

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

And I must say that I find the argumentation for rejecting the
change very very weak. I would really expect Fesco to make better
motivated decisions then this one.

I'm especially shocked about how Fesco is in essence mandating
a group of maintainers to spend time maintaining a feature
where they clearly have indicated they don't want to maintain
that feature.

My being shocked here is not so much about the guile issue,
but about a IMHO much bigger issue underlying this decision:

Since when does Fesco get to mandate on which features our
volunteer maintainers get to spend there time ?

I understand there need to be rules and I can understand
Fesco denying approval for enabling / adding certain
features for a wide set of reasons, thus in essence blocking
volunteers from spending time on something because that
something is deemed undesirable for Fedora.

But this is different here Fesco is telling a group of
maintainers that they must maintain a feature even though
they have indicated that they find the benefits of that
feature not worth the amount of time it costs to maintain
support for that feature. So in essence Fesco is telling
the maintainers that they MUST spend time maintaining this
even though they don't want this.

IMHO this is just outrageous and goes way way beyond the
purview of Fesco.

Now if dropping this feature would cause major breakage this
would a different story, But in the whole discussion about
this, at least as documented in the Fesco issue, no actual
users of this feature have been indentified and nothing will
break by disabling this as far is is known. So since there
is no known breakage caused by this, I end up circling back
to this basically telling Fesco that the make/gdb timers
MUST spend them on maintaining this even though they
don't want to (and have good reasons for not wanting to).

Which again, is IHMO pretty outrageous really.

Sorry Fesco, I know that you all do a lot of (hard) work
as Fesco members and do your best when making decisions
like this; and I don't doubt that your intentions where
well, but you made a big booboo here (IMHO).

I urge Fesco to reconsider this and I suggest that we
(Fedora) take another serious look at implementing:
https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain
for Fedora 35.

Regards,

Hans

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

Re: Orphaned packages looking for new maintainers

[Hans de Goede]

Hi,

On 7/7/21 11:18 AM, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will fail to install and/or build when the affected package gets 
> retired.
> 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2021-07-07.txt
> grep it for your FAS username and follow the dependency chain.
> 
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
> 
>     Package  (co)maintainers   Status 
> Change
> 



> guile22   mlichvar, orphan 1 weeks ago



Does anyone know what is going on here / I was sorta surprised to learn that
ATM we have 2 guile packages:

[hans@x1 ~]$ rpm -q guile guile22
guile-2.0.14-24.fc34.x86_64
guile22-2.2.7-2.fc34.x86_64

Note that guile22 actually is the newer version of guile. And it seems that 
most of
the packages which use guile are actually using guile22.

So is the plan to make the "guile" packages contain guile-2.2 now and is that 
why
guile22 is going away?  Or ... ?

Regards,

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

Re: x86_64-v2 in Fedora

[Hans de Goede]

Hi,

On 6/16/21 12:19 PM, Daniel P. Berrangé wrote:
> On Wed, Jun 16, 2021 at 12:01:29PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 6/16/21 10:28 AM, Daniel P. Berrangé wrote:
>>> On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
>>>> Hey all,
>>>>
>>>> Earlier this week, I was helping with processing features for openSUSE
>>>> Leap 15.4[1] and I discovered that they're planning on introducing
>>>> x86_64-v2 to openSUSE soon. The reference for this change was that
>>>> RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
>>>> have been considering bumping up to v2 or v3[3][4].
>>>>
>>>> Some cursory examination of the new x86_64 sublevels seem to indicate
>>>> that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
>>>> first couple of generations of x86_64 CPUs from Intel and AMD. I
>>>> personally don't have any computers that don't have support for
>>>> x86_64-v2 anymore.
>>>
>>> Yes, you loose primarily Intel Conroe and Penryn generations and
>>> AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
>>> of Fedora installs.
>>>
>>> Slight tangent but I find Fedora's approach to hardware somewhat
>>> at odds with our approach to software.
>>>
>>> On the one hand we portray our project as a place for cutting
>>> edge Linux software & innovation.
>>>
>>> On the other hand we hold back our software by trying to keep
>>> supporting long obsolete hardware.
>>>
>>> There is of course always a balance between bumping min hardware
>>> specs and the impact on maintainers & users, but I'm not convinced
>>> that we have the balance right in targeting our x86_64 baseline at
>>> the very first generation of 64-bit CPUs from 15 years ago. I can't
>>> imagine such old CPUs makes up a significant portion of our users.
>>
>> I don't know about that, all I can offer is my own anecdotal to
>> the contrary. Of the 7 PCs/laptops which are in more or less
>> daily use in our houshold 3 of them are still core2 duo systems.
>>
>> Once the core2 duo / amd64 machines came out we really started hitting
>> the point of diminishing returns wrt PC performance for day 2 day
>> use. For a lot of simple day2  day use there really is no reason
>> to replace and x86_64-v1 capable machines unless they are
>> actually broken.
>>
>> Perhaps more importantly though, is that there we are also very
>> much at the point where bumping the processor architecture
>> requirements also leads to strongly diminishing returns.
>>
>> Also see Mateusz Jończyk excellent reply in this thread, how
>> rebuilding packages for x86_64-v2 vs x86_64 results in a barely
>> measurable performance improvement.
>>
>> Of course there are some specific algorithms which greatly
>> benefit from sse4.2, but those typically benefit even more
>> from avx/avx2 which are not included in x86_64-v2; and often
>> libraries already contain avx optimized code-paths for this
>> which they automatically use where possible.
>>
>> You talk about we "hold back our software by trying to keep
>> supporting long obsolete hardware". Let me flip the question
>> can you provide hard proof, as in concrete numbers showing
>> significant improvements, that switching to x86_64-v2
>> actually buys us anything meaningful ?
> 
> I wasn't so much thinking about the performance benefit,
> rather the CMPXCHG16B support which IIUC is required for
> atomics on 128 bit quantities and isn't present in the
> x86_64 baseline. QEMU already unconditionally adds -mcx16
> to its CFLAGS to enable usage of this instruction. 

CMPXCHG16B is indeed supported on pretty much any x86_64 machine,
including on Intel Conroe and Penryn AFAICT.

Only very old AMD64 CPUs, which are still using DDR1 don't
support this (AFAICT).

So yes requiring that is probably fine.

> I did think there might be some performance benefits too,
> so it was interesting to see the disappointing results
> posted elsewhere in this thread.

Ack, I suspect that the cases where there are really significant
gains in using SSE4 are already covered by (optional) SSE4 
optimized code paths.

I think it would be better if we want to look into using newer
instructions into looking into things like this.

E.g. if there is some library which does significantly benefit
from gcc's auto-vectorisation with sse4 and/or avx then we
could build it multiple times with different settings and use
the hwcaps based library loading mechanism

Re: x86_64-v2 in Fedora

[Hans de Goede]

Hi,

On 6/16/21 10:28 AM, Daniel P. Berrangé wrote:
> On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
>> Hey all,
>>
>> Earlier this week, I was helping with processing features for openSUSE
>> Leap 15.4[1] and I discovered that they're planning on introducing
>> x86_64-v2 to openSUSE soon. The reference for this change was that
>> RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
>> have been considering bumping up to v2 or v3[3][4].
>>
>> Some cursory examination of the new x86_64 sublevels seem to indicate
>> that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
>> first couple of generations of x86_64 CPUs from Intel and AMD. I
>> personally don't have any computers that don't have support for
>> x86_64-v2 anymore.
> 
> Yes, you loose primarily Intel Conroe and Penryn generations and
> AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
> of Fedora installs.
> 
> Slight tangent but I find Fedora's approach to hardware somewhat
> at odds with our approach to software.
> 
> On the one hand we portray our project as a place for cutting
> edge Linux software & innovation.
> 
> On the other hand we hold back our software by trying to keep
> supporting long obsolete hardware.
> 
> There is of course always a balance between bumping min hardware
> specs and the impact on maintainers & users, but I'm not convinced
> that we have the balance right in targeting our x86_64 baseline at
> the very first generation of 64-bit CPUs from 15 years ago. I can't
> imagine such old CPUs makes up a significant portion of our users.

I don't know about that, all I can offer is my own anecdotal to
the contrary. Of the 7 PCs/laptops which are in more or less
daily use in our houshold 3 of them are still core2 duo systems.

Once the core2 duo / amd64 machines came out we really started hitting
the point of diminishing returns wrt PC performance for day 2 day
use. For a lot of simple day2  day use there really is no reason
to replace and x86_64-v1 capable machines unless they are
actually broken.

Perhaps more importantly though, is that there we are also very
much at the point where bumping the processor architecture
requirements also leads to strongly diminishing returns.

Also see Mateusz Jończyk excellent reply in this thread, how
rebuilding packages for x86_64-v2 vs x86_64 results in a barely
measurable performance improvement.

Of course there are some specific algorithms which greatly
benefit from sse4.2, but those typically benefit even more
from avx/avx2 which are not included in x86_64-v2; and often
libraries already contain avx optimized code-paths for this
which they automatically use where possible.

You talk about we "hold back our software by trying to keep
supporting long obsolete hardware". Let me flip the question
can you provide hard proof, as in concrete numbers showing
significant improvements, that switching to x86_64-v2
actually buys us anything meaningful ?

Because this whole switch to x86_64-v2 sounds to me like
it is mostly being pursued because it is a higher number so
it must be better...

Dropping 32 bit x86 support was a good thing to do because
the virtual memory space offered by 32 bits was simply
becoming too small for many desktop applications like
web-browsers; and things were starting to become noticeably
broken there because upstream where no longer testing on it.

Forcing all Fedora PC users to move to x86_64 users as such
was a good thing to do and also had a significant benefits
in the form of lessening maintainer loads. Switching to
x86_64-v2 OTOH simply does not seem to give any significant
benefits.

Regards,

Hans

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

Re: The Javapocalypse is Monday

[Hans de Goede]

Hi,

On 6/3/21 11:30 PM, Jerry James wrote:
> I've just been looking through my packager-dashboard page.  A
> depressingly large chunk of my packages are going to become
> unbuildable on Monday when a bunch of orphaned Java packages are
> retired.  I think a lot of us are going to be affected.  In my case,
> there are quite a few non-Java packages involved (due to the parser
> generators antlr3 and antlr4-project), primarily OCaml and python
> packages.  Mikolaj has a huge pile of work on his shoulders, so don't
> take this as criticism of him.
> 
> Here are some of the pain points:
> - log4j will be retired, which will break ant.
> - hamcrest2 will be retired, which will break apache-commons-lang3,
> which will break bcel, which will also break ant.
> - google-gson and javassist will be retired, which will break
> reflections, which will break jna, which is used by about a dozen
> packages, including bcel.
> - maven-install-plugin will be retired, which will break tycho, which
> will break eclipse.
> - args4j will be retired, which will break jacoco and jgit.
> - maven-invoker-plugin and several of its dependencies
> (maven-doxia-sitetools, plexus-velocity, maven-reporting-api,
> maven-script-interpreter, and maven-reporting-impl) will be retired,
> which will break xml-maven-plugin, which is used by eclipse.
> - jakarta-el and jakarta-server-pages will be retired, which will break 
> eclipse.
> - aopalliance will be retired, which will break maven-native.
> - jdependency will be retired, which will break maven-shade-plugin,
> which is used by openjfx8, a dependency of java-1.8.0-openjdk.
> - apache-ivy will be retired, which will break javapackages-tools.
> 
> I have packages that depend directly on the following, so I am willing
> to adopt them if nobody more competent shows up (although there is no
> point in taking ant-contrib if ant is going to be broken anyway):
> - ant-contrib
> - jakarta-common-httpclient
> - jakarta-ws-rs
> - maven-invoker-plugin
> - spec-version-maven-plugin
> 
> I introduced the jansi1 and jline2 packages so that jansi could be
> moved to 2.x and jline to 3.x, but I don't actually maintain any
> packages that need the old versions.  I would like to give them away
> to someone who needs them, but note that you will need to grab
> jansi-native as well, before Monday!

I've a couple of packages which depend on jline2, so I've just taken
owner ship of jansi-native. Feel free to give jline2 and jansi1 to me
too (FAS: jwrdegoede) I would very much welcome co-maintainers for these,
if anyone wants co-admin rights, just let me know.

I've also taken javacc ownership as some of my packages depend on that too,
again co-maintainers are very much welcome.

Note I just maintain a couple of games written in java and I don't have
much interest in (nor time for) more generic jave packaging work.
I'm assuming that ant and jpackages-tools are going to get taken care
by people who are more into java then me. If those don't get sorted out
I will probably just orphan the 2 games which I maintain, as well as
a bunch of their java deps like bsh, javacc, cortado, (and now also jline2),
etc.

Regards,

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

Re: doxbox-staging package conflict

[Hans de Goede]

Hi,

On 6/1/21 10:33 PM, Otto Urpelainen wrote:
> Hans de Goede kirjoitti 1.6.2021 klo 21.02:
>> Hi,
>>
>> On 6/1/21 6:20 PM, Vitaly Zaitsev via devel wrote:
>>> Hello all.
>>>
>>> doxbox-staging is trying to overwrite the regular dosbox package:
>>>
>>> Installing:
>>>   dosbox-staging    x86_64    0.76.0-2.fc34  fedora 
>>>    1.4 M
>>>   replacing  dosbox.x86_64 0.74.3-7.fc34
>>>
>>>  From its SPEC[1]:
>>>
>>> # This package is a drop-in replacement for dosbox
>>> Provides:  dosbox = %{version}-%{release}
>>> Obsoletes: dosbox < 0.74.4
>>>
>>> Is this Okay? These packages has different maintainers. According to the 
>>> Fedora packaging guidelines, one package cannot introduce conflicts with 
>>> another.
>>
>> This is intentional, regular dosbox is more-or-less (*) unmaintained 
>> upstream so we have decided to switch to dosbox-staging, also see the 
>> Package Review for dosbox staging:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1884608
>>
>> As such dosbox-staging is intended as a replacement for the regular dosbox 
>> (and it is fully compatible with the regular dosbox). This was coordinated 
>> with the dosbox owner, but we have forgotten to actually retire dosbox, 
>> sorry about that. I'll retire dosbox in rawhide right away.
> 
> I think it is great that Fedora now has dosbox-staging and arrow keys work 
> again. Many games were quite annoying to play without them. And there are 
> other improvements as well.
> 
> But the complaint I have about this process is that, if you use the default 
> dosbox-staging config, quite many games that actually ran with dosbox crash 
> on dosbox-staging startup. That problem should be patched around somehow 
> before dosbox can go. See Bugzilla discussion [1].

Good news, the exec-heap permission issue should be fixed by this upstream 
commit:

https://github.com/dosbox-staging/dosbox-staging/commit/649a428dc368cc03b1cfa608faeae7b5b9290581

Unfortunately this does not apply at all to 0.76.0 though, so we cannot just 
cherry-pick the fix and add it to the Fedora packages.

One option would be to switch to a git snapshot for now.

Lets discuss this further in:

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

Which seems to be the bug where this is actually being tracked.

Regards,

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

Re: doxbox-staging package conflict

[Hans de Goede]

Hi,

On 6/2/21 12:47 AM, François Cami wrote:
> On Tue, Jun 1, 2021 at 10:36 PM Neal Gompa  wrote:
>>
>> On Tue, Jun 1, 2021 at 4:34 PM Otto Urpelainen  wrote:
>>>
>>> Hans de Goede kirjoitti 1.6.2021 klo 21.02:
>>>> Hi,
>>>>
>>>> On 6/1/21 6:20 PM, Vitaly Zaitsev via devel wrote:
>>>>> Hello all.
>>>>>
>>>>> doxbox-staging is trying to overwrite the regular dosbox package:
>>>>>
>>>>> Installing:
>>>>>   dosbox-stagingx86_640.76.0-2.fc34  fedora   
>>>>>  1.4 M
>>>>>   replacing  dosbox.x86_64 0.74.3-7.fc34
>>>>>
>>>>>  From its SPEC[1]:
>>>>>
>>>>> # This package is a drop-in replacement for dosbox
>>>>> Provides:  dosbox = %{version}-%{release}
>>>>> Obsoletes: dosbox < 0.74.4
>>>>>
>>>>> Is this Okay? These packages has different maintainers. According to the 
>>>>> Fedora packaging guidelines, one package cannot introduce conflicts with 
>>>>> another.
>>>>
>>>> This is intentional, regular dosbox is more-or-less (*) unmaintained 
>>>> upstream so we have decided to switch to dosbox-staging, also see the 
>>>> Package Review for dosbox staging:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1884608
>>>>
>>>> As such dosbox-staging is intended as a replacement for the regular dosbox 
>>>> (and it is fully compatible with the regular dosbox). This was coordinated 
>>>> with the dosbox owner, but we have forgotten to actually retire dosbox, 
>>>> sorry about that. I'll retire dosbox in rawhide right away.
>>>
>>> I think it is great that Fedora now has dosbox-staging and arrow keys
>>> work again. Many games were quite annoying to play without them. And
>>> there are other improvements as well.
>>>
>>> But the complaint I have about this process is that, if you use the
>>> default dosbox-staging config, quite many games that actually ran with
>>> dosbox crash on dosbox-staging startup. That problem should be patched
>>> around somehow before dosbox can go. See Bugzilla discussion [1].
>>>
>>> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1933849#c4
>>>
>>
>> As an aside, I'm slightly confused why dosbox wasn't just replaced
>> with dosbox-staging with the same packaging...
> 
> Different upstreams (different teams, etc).

Right, the original dosbox project is still somewhat alive, so the purpose
of having a dosbox-staging package instead of just putting the tarbal from
dosbox-staging into the dosbox package is to make it clear that Fedora is
packaging dosbox-staging and not the original dosbox.

Regards,

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

Re: doxbox-staging package conflict

[Hans de Goede]

Hi,

On 6/1/21 6:20 PM, Vitaly Zaitsev via devel wrote:
> Hello all.
> 
> doxbox-staging is trying to overwrite the regular dosbox package:
> 
> Installing:
>  dosbox-staging    x86_64    0.76.0-2.fc34  fedora    
> 1.4 M
>  replacing  dosbox.x86_64 0.74.3-7.fc34
> 
> From its SPEC[1]:
> 
> # This package is a drop-in replacement for dosbox
> Provides:  dosbox = %{version}-%{release}
> Obsoletes: dosbox < 0.74.4
> 
> Is this Okay? These packages has different maintainers. According to the 
> Fedora packaging guidelines, one package cannot introduce conflicts with 
> another.

This is intentional, regular dosbox is more-or-less (*) unmaintained upstream 
so we have decided to switch to dosbox-staging, also see the Package Review for 
dosbox staging:
https://bugzilla.redhat.com/show_bug.cgi?id=1884608

As such dosbox-staging is intended as a replacement for the regular dosbox (and 
it is fully compatible with the regular dosbox). This was coordinated with the 
dosbox owner, but we have forgotten to actually retire dosbox, sorry about 
that. I'll retire dosbox in rawhide right away.

Regards,

Hans


*) They have not done a release in many years, nor has any meaningful feature 
development are maintenance like moving to SDL2 happened.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Hans de Goede]

Hi,

On 5/27/21 5:54 PM, Tom Callaway wrote:
> FWIW, I have retired xmms. Upstream is long gone, and it was being held 
> together by spider-webs anyways.

And I've just retired xarchon for similar reasons. xarchon was fun
for me as a fan of the original c64 Archon games, but it really is
time for gtk+ to get retired and I don't want a silly (and not
very polished) game like xarchon to block retiring gtk+.

Regards,

Hans




> 
> ~spot
> 
> On Wed, May 26, 2021 at 4:43 AM Peter Robinson  > wrote:
> 
> On Tue, May 25, 2021 at 11:01 PM Michael Catanzaro  > wrote:
> >
> > On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple
> > mailto:bob.hep...@gmail.com>> wrote:
> > > I have no idea how significant this might be, but perhaps this should
> > > be discussed more publicly.
> >
> > Use containers? Ship your own glib as a static lib? I'm impressed you
> > have software that still needs it tbh.
> 
> I think copr is the perfect place for these sort of things for those
> that care enough.
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 
> 
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines 
> 
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
> 
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: soname bump on fluidsynth-libs in f32

[Hans de Goede]

Hi,

On 5/11/21 1:56 PM, Christoph Karl wrote:
> Hi!
> 
> Trying to fix two security issues
> https://bugzilla.redhat.com/show_bug.cgi?id=194953
> and
> https://bugzilla.redhat.com/show_bug.cgi?id=1955611
> I made an unintended soname bump in f32.
> As far as I have seen, this is only in f32.

Given that F32 is almost EOL, you could just
drop the update, assuming that the troublesome fluidsynth-libs
has not yet hit the stable updates repo.

If it has hit the stable repo, you could still
consider doing a rollback, by:

Adding an epoch 1, starting at f33+ (and not touching f32)
once the epoch bump has landed in f33+ you can do an epoch bump,
combined with a downgrade in f32 (the epoch bump will still
make it an update from rpm-s pov).

Regards,

Hans



> Carl Georg help me and already rebuild:
> 
> audacious-plugins-3.10.1-8.fc32
> Carla-2.2.0-2.fc32
> csound-6.15.0-2.fc32
> denemo-2.4.0-2.fc32
> drumstick-1.1.3-3.fc32
> gstreamer1-plugins-bad-free-1.16.2-4.fc32
> minuet-20.08.3-2.fc32
> openttd-1.11.2-2.fc32
> prboom-plus-2.5.1.4-19.fc32
> qsynth-0.9.2-2.fc32
> scummvm-2.2.0-3.fc32
> tuxguitar-1.5.3-3.fc32
> 
> The following are not building OK:
> ardour5-5.12.0-19.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67397828
> fluidsynth-dssi-1.0.0-22.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67398025
> lmms-1.1.3-16.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67398113
> muse-3.0.2-10.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67398110
> swami-2.0.0-22.20110806svn386.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67398310
> 
> I will try to find out why.
> 
> Best Regards
> Christoph
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GNOME only: KeepassXC quirks

[Hans de Goede]

Hi,

On 4/30/21 3:33 PM, Vitaly Zaitsev via devel wrote:
> On 30.04.2021 12:23, Germano Massullo wrote:
>> There are many Fedora GNOME Wayland users experiencing quirks in using 
>> KeepassXC. Textboxes not showing text that is being written, other quirks 
>> with GNOME, etc.
> 
> There are a lot of issues with Mutter and Qt5[1]. That's why the Qt upstream 
> forces XCB backend for the Gnome 3, but Fedora removes it in downstream[2], 
> as approved by the system-wide proposal[3].
> 
> Please try the following:
> QT_QPA_PLATFORM=xcb /usr/bin/keepassxc

Ah interesting, I use calibre regularly under a GNOME3 wayland sessions and
I have noticed some weird issues there too, like the "completion" pop-ups
for things like the Author and Series fields which allow you to select an
Author / Series already used for other books showing up in completely
the wrong places, as well as right-click context(sub)menus also showing up
in completely the wrong places too.

I also use the audacious media-player for music in its x11amp compatible
skinned mode and that is has serious issues when used without
QT_QPA_PLATFORM=xcb under GNOME3. I thought this was just a special case
because of the skinned UI, but I now see that it is part of a wider pattern.

I was going to write the following here:

"""
I can understand if the KDE SIG wants to use Wayland by default when running
a KDE Wayland session, but under GNOME3 this indeed seems like a bad idea for 
now.

Maybe instead the QT_QPA_PLATFORM environment option can be set in the
KDE wayland session, so that Wayland is used there while leaving GNOME3
alone ?
"""

Which seems like a reasonable compromise to me, but then I looked at the
patch from [2] and it seems that that is the upstream default and the
Fedora packages are actually overriding this sensible upstream default.

> I think this downstream patch should be dropped from Fedora.

I tend to agree, it seems this downstream patch breaks at least 3 apps:

1. KeepassXC
2. calibre
3. audacious

And I have a feeling it breaks all Qt apps to at least some extend, now the
changes process page [3] does list a couple of reasons why this is necessary,
but I just checked and calibre looks fine with the mutter provided window
decorations for X11 windows instead of using CSD, so this does not seem like
a strong argument.

I can understand that it is desirable to make this change, but it seems that
QT5 just is not completely ready for this yet. For me the patch[2] breaks
2/2 Qt apps which I regularly used, so it seems that it would be best to drop
this downstream modification for now.

Regards,

Hans



> See also:
> 
> [1]: https://bugreports.qt.io/browse/QTBUG-88293
> [2]: 
> https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-use-wayland-on-gnome.patch
> [3]: https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Hans de Goede]

Hi,

On 4/29/21 12:00 PM, Mikolaj Izdebski wrote:
> Hi Hans,
> 
> On Wed, Apr 28, 2021 at 3:47 PM Hans de Goede  wrote:
>> Also I hope it is ok if I pick your brain a bit on a java
>> packaging issue which I've been having.
>>
>> I maintain a couple of java leave packages (games) + some deps
>> which AFAIK are only used by these games.
>>
>> One of these deps (dom4j) has been FTBFS since F34:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1923601
>>
>> I've been looking into this and the actual problem seems to
>> be with Java 9 now including what once was the org.relaxng.datatype
>> except they did not just bundle it, they also changed where it
>> sits in the namespace to com.sun.tools.rngdatatype 
>>
>> Just doing a s/org.relaxng.datatype/com.sun.tools.rngdatatype/
>> got me a bit further, but it seems that msv, which is a dep of
>> dom4j needs to be rebuild first with the same search-replace
>> done on it and the FTBFS bug of msv is stuck because of one
>> of its deps getting orphaned+retired :
>> https://bugzilla.redhat.com/show_bug.cgi?id=1923446
>>
>> So I think I can fix this by:
>>
>> 1. Unorphaning jvnet-parent, which is the missing msv dep
> 
> You can unorphan/unretire it, but removing dependency on jvnet-parent
> is another choice. Probably better choice as jvnet-parent is no longer
> developed or maintained by upstream.
> 
>> 2. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in msv, rebuild
>> 3. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in dom4j, rebuild
> 
> relaxngDatatype was retired in Fedora. A replacement is
> jaxb-relaxng-datatype package (built from jaxb source package), but it
> uses a different namespace. Therefore steps 2 and 3 seem correct and
> necessary.
> 
>> And then either do this only for rawhide, or push all 3 modified
>> packages to F34 in a single bodhi update.
>>
>> Mikolaj, does this sounds like a reasonable plan to you; or
>> should I approach this differently?
> 
> Yes, that sounds good. I would also double check to see whether
> msv/dom4j are really needed by your packages.

Thank you for this hint. dom4j is still used by 4 packages,
but "dnf repoquery --whatrequires msv-" returns nothing
but msv for all msv packages. So it seems that nothing is using this
at runtime. As such I've just removed the classes from dom4j which
depend on msv as those seem to be unused.

I've only pushed this to rawhide for now and I've asked the
maintainers of the other 3 packages to test them with the new
dom4j build.

I'll also add a comment to the msv FTBFS bug that it might be
best to just orphan msv as it has been deprecated upstream and
not seen a new release since 2013 it seems.

>> Also if yes this is a reasonable plan any advice on also
>> pushing the fixed packages to F34, or not ?
> 
> I am in favor of F34 update. Users of dom4j/msv that do not rely on
> relaxngDatatype-related functionality should be unaffected by the
> update. Users that do rely on it would get it fixed.

Ok, I'll update dom4j once I've positive testing feedback from
the maintainers of the other pkgs depending on it.

Regards,

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