Re: modules signatures !

[Adam Williamson]

On Wed, 2025-02-26 at 11:18 -0800, Kevin Fenzi wrote:
> On Wed, Feb 26, 2025 at 01:29:51PM -0500, Jason Montleon wrote:
> > I have had a bug open for awhile on this with no response:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2334643
> > 
> > I also opened an issue on the kernel-ark repo a few days ago:
> > https://gitlab.com/cki-project/kernel-ark/-/issues/176
> > 
> > The last debug kernel that worked for me was 6.12.1.
> 
> Ah, ok. 
> 
> Do regulrar rawhide kernels boot ok for you?
> 
> (nothing after rc2 here works, I get it not finding the rootfs and
> haven't had any time to debug too much further).

https://bugzilla.redhat.com/show_bug.cgi?id=2330681 has been open for
longer, I've marked yours as a dupe. We're kinda waiting on the kernel
team, there.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: modules signatures !

[Kevin Fenzi]

On Sun, Mar 02, 2025 at 09:46:46AM -0800, Adam Williamson wrote:
> On Wed, 2025-02-26 at 11:18 -0800, Kevin Fenzi wrote:
> > On Wed, Feb 26, 2025 at 01:29:51PM -0500, Jason Montleon wrote:
> > > I have had a bug open for awhile on this with no response:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2334643
> > > 
> > > I also opened an issue on the kernel-ark repo a few days ago:
> > > https://gitlab.com/cki-project/kernel-ark/-/issues/176
> > > 
> > > The last debug kernel that worked for me was 6.12.1.
> > 
> > Ah, ok. 
> > 
> > Do regulrar rawhide kernels boot ok for you?
> > 
> > (nothing after rc2 here works, I get it not finding the rootfs and
> > haven't had any time to debug too much further).
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2330681 has been open for
> longer, I've marked yours as a dupe. We're kinda waiting on the kernel
> team, there.

FYI, my (non debug) boot failures seem to now be fixed. 

6.14.0-0.rc4.20250226gitac9c34d1e45a.38.fc43.x86_64 is working.

(I know this is unrelated to the debug kernel thing, but wanted to
mention it).

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

Re: modules signatures !

[Mark Williams]

For what it is worth, I had nothing but problems with 6.13 and nvidia. 
Never could get it to work. The 6.14 kernel appears to be working in 
f42. 6.14.0-0.rc3.29.fc42.x86_64



On 2/26/25 1:52 PM, Jason Montleon wrote:

I am able to boot the regular 6.14.0
0.rc4.20250226gitac9c34d1e45a.38.fc43 kernel built today, but the
debug kernel still fails with the same "BPF: Invalid offset" errors I
am seeing with 6.13 kernels.

On Wed, Feb 26, 2025 at 2:18 PM Kevin Fenzi wrote:

On Wed, Feb 26, 2025 at 01:29:51PM -0500, Jason Montleon wrote:

I have had a bug open for awhile on this with no response:
https://bugzilla.redhat.com/show_bug.cgi?id=2334643

I also opened an issue on the kernel-ark repo a few days ago:
https://gitlab.com/cki-project/kernel-ark/-/issues/176

The last debug kernel that worked for me was 6.12.1.

Ah, ok.

Do regulrar rawhide kernels boot ok for you?

(nothing after rc2 here works, I get it not finding the rootfs and
haven't had any time to debug too much further).

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


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

Re: modules signatures !

[Jason Montleon]

I am able to boot the regular 6.14.0
0.rc4.20250226gitac9c34d1e45a.38.fc43 kernel built today, but the
debug kernel still fails with the same "BPF: Invalid offset" errors I
am seeing with 6.13 kernels.

On Wed, Feb 26, 2025 at 2:18 PM Kevin Fenzi  wrote:
>
> On Wed, Feb 26, 2025 at 01:29:51PM -0500, Jason Montleon wrote:
> > I have had a bug open for awhile on this with no response:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2334643
> >
> > I also opened an issue on the kernel-ark repo a few days ago:
> > https://gitlab.com/cki-project/kernel-ark/-/issues/176
> >
> > The last debug kernel that worked for me was 6.12.1.
>
> Ah, ok.
>
> Do regulrar rawhide kernels boot ok for you?
>
> (nothing after rc2 here works, I get it not finding the rootfs and
> haven't had any time to debug too much further).
>
> kevin
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon

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

Re: modules signatures !

[Kevin Fenzi]

On Wed, Feb 26, 2025 at 01:29:51PM -0500, Jason Montleon wrote:
> I have had a bug open for awhile on this with no response:
> https://bugzilla.redhat.com/show_bug.cgi?id=2334643
> 
> I also opened an issue on the kernel-ark repo a few days ago:
> https://gitlab.com/cki-project/kernel-ark/-/issues/176
> 
> The last debug kernel that worked for me was 6.12.1.

Ah, ok. 

Do regulrar rawhide kernels boot ok for you?

(nothing after rc2 here works, I get it not finding the rootfs and
haven't had any time to debug too much further).

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

Re: modules signatures !

[Jason Montleon]

I have had a bug open for awhile on this with no response:
https://bugzilla.redhat.com/show_bug.cgi?id=2334643

I also opened an issue on the kernel-ark repo a few days ago:
https://gitlab.com/cki-project/kernel-ark/-/issues/176

The last debug kernel that worked for me was 6.12.1.

On Wed, Feb 26, 2025 at 1:07 PM Kevin Fenzi  wrote:
>
> On Wed, Feb 26, 2025 at 09:16:09AM +0100, lejeczek via test wrote:
> > Hi guys/devs
> >
> > Does anybody has a watchful eye on it ? not just one but at least couple of
> > latest "kernel-debug" do _not_ load in.
> >
> > many thanks, L.
>
> Can you provide more information here? Unfortunately 'modules' is not
> very clear to me at least. ;)
>
> Perhaps you could provide what you are trying to do and all the output
> from that?
>
> Thanks,
>
> kevin
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon

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

Re: modules signatures !

[Kevin Fenzi]

On Wed, Feb 26, 2025 at 09:16:09AM +0100, lejeczek via test wrote:
> Hi guys/devs
> 
> Does anybody has a watchful eye on it ? not just one but at least couple of
> latest "kernel-debug" do _not_ load in.
> 
> many thanks, L.

Can you provide more information here? Unfortunately 'modules' is not
very clear to me at least. ;) 

Perhaps you could provide what you are trying to do and all the output
from that?

Thanks,

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

Re: Draft anaconda webui test cases and matrix changes

[Kamil Paral]

On Sat, Feb 15, 2025 at 2:05 AM Adam Williamson 
wrote:

> Hey folks! So as we're once again trying the 'anaconda webui is release
> blocking' thing for F42, and it actually hasn't been reverted yet for
> once, I've drafted up new test cases and matrix changes. Here's my
> draft matrix page:
>
> https://fedoraproject.org/wiki/User:Adamwill/Draft_webui_matrix
>
> you can compare it to:
>
> https://fedoraproject.org/wiki/Template:Installation_test_matrix
>
> to see the differences - broadly, there's an additional table in
> "Guided storage configuration", an additional test case in "Guided
> storage shrinking", and a new "WebUI custom storage configuration"
> section. The new test cases are linked from those sections - the
> "webui_guided" test cases and the "webui_custom" test cases.
>
> Can folks please cast an eye over these changes and see if they look
> good?


Sorry for a late reply. I didn't go through all the testcases step by step,
but from the template view these changes make sense to me, and I don't have
any reservations. (I only tweaked the new section color so that it doesn't
repeat, couldn't resist my OCD).
Thanks for working on this.
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: pkgconf appears to be looping (Samuel Sieb)

[Samuel Sieb]

On 2/20/25 3:01 PM, George R Goffe via test wrote:

This is a F43 (rawhide) system... A few upgrades ago it changed from F42 to F43.

I have no idea how pkgconf runs during login. Something in my .rc file? I have 
my own .rc file that is referenced from the root .bashrc. I have commented out 
that reference which seems to have eliminated the hang at login. The moment I 
run my .rc file, the hang re-appears (sometimes). The term type is konsole, 
windowmaker (local build from their source repo) is the window manager. I have 
to CTRL-C to get out of the hang. Building other code doesn't always create the 
looping condition.


Sharing the contents of the .rc would be helpful unless you can tell 
which part of it is triggering pkgconf.


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

Re: pkgconf appears to be looping (Samuel Sieb)

[George R Goffe via test]

Samuel,

Thanks for responding. Sorry for the delay in my responding to your post, I got 
sick (cold or flu))...sigh.

So. To answer your questions.

This is a F43 (rawhide) system... A few upgrades ago it changed from F42 to F43.

I have no idea how pkgconf runs during login. Something in my .rc file? I have 
my own .rc file that is referenced from the root .bashrc. I have commented out 
that reference which seems to have eliminated the hang at login. The moment I 
run my .rc file, the hang re-appears (sometimes). The term type is konsole, 
windowmaker (local build from their source repo) is the window manager. I have 
to CTRL-C to get out of the hang. Building other code doesn't always create the 
looping condition. 

Various software tools hang in pkgconf. Htop is one. GNU make is another. Today 
I got a hang during the removal phase of a "normal" dnf upgrade. The hang 
appeared after these lines in the log (below). I waited several hours and then 
CTRL-C'd out of the upgrade. My logging did not catch the operands of pkgconf. 
I'll do better next time.

[664/668] Removing ksshaskpass-0:6.3.0- 100% | 575.0   B/s |  65.0   B |  00m00s
[665/668] Removing kate-krunner-plugin- 100% |  54.0   B/s |   4.0   B |  00m00s
 [666/668] Removing glibmm2.68-0:2.82.0- 100% |  95.0   B/s |  18.0   B |  
00m00s
 [667/668] Removing bluedevil-0:6.3.0-1. 100% |   4.0   B/s | 263.0   B |  
01m02s

Running dnf upgrade again did NOT experience any problems.

I ran "gdb -p" on a hanging process... and then did a where command. Here is 
the stack trace:

(gdb) where
#0  0x7f492bff91b4 in pkgconf_fgetline (buffer=buffer@entry=0x7ffa7c20, 
 
   stream=stream@entry=0x5636b9a9fa80) at libpkgconf/fileio.c:106
#1  0x7f492bffbbef in pkgconf_parser_parse (f=f@entry=0x5636b9a9fa80, 
data=data@entry=0x5636b9aa7ca0,  
   ops=ops@entry=0x7f492c000a60 , 
warnfunc=warnfunc@entry=0x7f492bff5a20 ,  
   filename=filename@entry=0x5636b9aa7e60 "/usr/lib64/pkgconfig/curlpp.pc") at 
libpkgconf/parser.c:39
#2  0x7f492bff673f in pkgconf_pkg_new_from_file 
(client=client@entry=0x5636972798a0 ,  
   filename=filename@entry=0x7ffa7cc0 "/usr/lib64/pkgconfig/curlpp.pc", 
f=0x5636b9a9fa80,  
   flags=flags@entry=0) at libpkgconf/pkg.c:535
#3  0x7f492bff6b7c in pkgconf_pkg_scan_dir 
(client=client@entry=0x5636972798a0 ,  
   path=0x5636b9a9f980 "/usr/lib64/pkgconfig", data=data@entry=0x7ffa9148,  
   func=func@entry=0x7f492bff5b00 ) at 
libpkgconf/pkg.c:730
#4  0x7f492bff6c47 in pkgconf_scan_all (client=client@entry=0x5636972798a0 
,  
   data=data@entry=0x7ffa9148, func=func@entry=0x7f492bff5b00 
)
   at libpkgconf/pkg.c:775
#5  0x7f492bff759f in pkgconf_pkg_scan_providers (client=0x5636972798a0 
,  
   pkgdep=0x5636b9a9fa00, eflags=0x7ffa91ac) at libpkgconf/pkg.c:1416
#6  pkgconf_pkg_verify_dependency (client=client@entry=0x5636972798a0 
,  
   pkgdep=pkgdep@entry=0x5636b9a9fa00, eflags=eflags@entry=0x7ffa91ac) at 
libpkgconf/pkg.c:1470
#7  0x7f492bff7a28 in pkgconf_pkg_walk_list 
(client=client@entry=0x5636972798a0 ,  
   parent=parent@entry=0x7ffa9280, deplist=deplist@entry=0x7ffa9340, 
func=func@entry=0x0,  
   data=data@entry=0x0, depth=depth@entry=1, skip_flags=2) at 
libpkgconf/pkg.c:1571
--Type  for more, q to quit, c to continue without paging--c
#8  0x7f492bff78ea in pkgconf_pkg_traverse_main 
(client=client@entry=0x5636972798a0 ,  
   root=0x7ffa9280, func=0x0, data=0x0, maxdepth=1, skip_flags=2) at 
libpkgconf/pkg.c:1725
#9  0x7f492bff7ce7 in pkgconf_pkg_traverse 
(client=client@entry=0x5636972798a0 ,  
   root=root@entry=0x7ffa9280, func=func@entry=0x0, data=data@entry=0x0, 
maxdepth=maxdepth@entry=1,  
   skip_flags=, skip_flags@entry=0) at libpkgconf/pkg.c:1756
#10 0x7f492bffad83 in pkgconf_queue_verify 
(client=client@entry=0x5636972798a0 ,  
   world=world@entry=0x7ffa9540, list=list@entry=0x7ffa94e0, 
maxdepth=1) at libpkgconf/queue.c:241
#11 0x7f492bffaeac in pkgconf_queue_solve 
(client=client@entry=0x5636972798a0 ,  
   list=list@entry=0x7ffa94e0, world=world@entry=0x7ffa9540, 
maxdepth=)
   at libpkgconf/queue.c:320
#12 0x56369727152d in main (argc=, argv=) at 
cli/main.c:1569
(gdb)

I'm unsure as to how to proceed at this time.

George...

On 2/14/25 11:47 AM, George R Goffe via test wrote:
> pkgconf seems to be consuming 99.9% of a core. It's not making system calls 
> based on NO activity from strace.
> 
> This problem begins at login. Unless I kill pkgconf, I will not get logged in.

How is pkgconfig running at login?

> This problem seems to appear during build operations. So far, building make 
> makes the loop appear. In this instance, pkgconf shows up when invoked from 
> the configure script. I have also tried building htop with the same results.
> 
> Has anyone seen this problem? I'm not sure what to do at this point

Re: nvidia

[Akbar Hamaminatu]

If you use gnome, there is an issue with reverse prime 
https://gitlab.gnome.org/GNOME/mutter/-/issues/3918. Should be fixed in 
upcoming release.
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: 2025-02-17 @ 16:00 UTC - Fedora Quality Meeting

[Luna Jernberg]

Hi!

will join the meeting today

Den mån 17 feb. 2025 kl 06:08 skrev Adam Williamson
:
>
> # Fedora Quality Assurance Meeting
> # Date: 2025-02-17
> # Time: 16:00 UTC
> (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
> # Location:
> https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
>
> Greetings testers! It's meeting time again.
>
> Here is a handy link which should show you the meeting time
> in your local time:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+quality+meeting&iso=20250217T16&p1=1440&ah=1
>
> If anyone has any other items for the agenda, please reply to this
> email and suggest them! Thanks.
>
> == Proposed Agenda Topics ==
>
> 1. Previous meeting follow-up
> 2. WebUI test case drafts
> 3. Fedora 42 status, Beta test dates / plan
> 4. Test Day / community event status
> 5. Open floor
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
>
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: nvidia

[Mark Williams]

Hi, other way around, it only uses the nvidia GPU  and disables the intel one. 
It basically forces the OS to use Nvidis, and actually, the nvidia card is 
twice as fast . Linux doesn’t handle switching GPUs very well

From: Samuel Sieb 
Sent: Saturday, February 15, 2025 2:18:17 AM
To: test@lists.fedoraproject.org 
Subject: Re: nvidia

On 2/14/25 10:40 PM, Mark Williams wrote:
> Hello,
>
> Nvidia driver looks like it is now working, however, when I turn off
> hybrid graphics, it fails to boot correctly and I get a blank desktop.
>
> Feb 15 00:35:06 fedora kernel: [drm:__nv_drm_connector_detect_internal
> [nvidia_drm]] *ERROR* [nvidia-drm] [GP
> U ID 0x0100] Failed to detect display state

Doesn't turning off hybrid graphics mean you only have the non-nvidia chip?

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

Re: nvidia

[Samuel Sieb]

On 2/14/25 10:40 PM, Mark Williams wrote:

Hello,

Nvidia driver looks like it is now working, however, when I turn off 
hybrid graphics, it fails to boot correctly and I get a blank desktop.


Feb 15 00:35:06 fedora kernel: [drm:__nv_drm_connector_detect_internal 
[nvidia_drm]] *ERROR* [nvidia-drm] [GP

U ID 0x0100] Failed to detect display state


Doesn't turning off hybrid graphics mean you only have the non-nvidia chip?

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

Re: nvidia

[Mark Williams]

Hello,

Nvidia driver looks like it is now working, however, when I turn off 
hybrid graphics, it fails to boot correctly and I get a blank desktop.


Thanks,

Mark


journalctl -b -1 | grep -i nvidia
Feb 15 00:34:51 fedora kernel: input: HDA NVidiaHDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00

.1/sound/card0/input31
Feb 15 00:34:51 fedora kernel: input: HDA NVidiaHDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00

.1/sound/card0/input32
Feb 15 00:34:51 fedora kernel: input: HDA NVidiaHDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00

.1/sound/card0/input33
Feb 15 00:34:51 fedora kernel: input: HDA NVidiaHDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00

.1/sound/card0/input34
Feb 15 00:34:52 fedora kernel: nvidia: loading out-of-tree module taints 
kernel.
Feb 15 00:34:52 fedora kernel: nvidia: module license 'NVIDIA' taints 
kernel.

Feb 15 00:34:52 fedora kernel: nvidia: module license taints kernel.
Feb 15 00:34:52 fedora kernel: nvidia-nvlink: Nvlink Core is being 
initialized, major device number 511
Feb 15 00:34:52 fedora kernel: nvidia:01:00.0: vgaarb: VGA decodes 
changed: olddecodes=io+mem,decodes=no

ne:owns=none
Feb 15 00:34:52 fedora kernel: NVRM: loading NVIDIAUNIX x86_64 Kernel 
Module  570.86.16  Fri Jan 24 21:25:51

UTC 2025
Feb 15 00:34:52 fedora kernel: nvidia_uvm: module uses symbols 
nvUvmInterfaceDisableAccessCntr from proprieta

ry module nvidia, inheriting taint.
Feb 15 00:34:52 fedora kernel: nvidia-uvm: Loaded the UVM driver, major 
device number 509.
Feb 15 00:34:52 fedora kernel: nvidia-modeset: Loading NVIDIAKernel Mode 
Setting Driver for UNIX platforms

570.86.16  Fri Jan 24 20:44:10 UTC 2025
Feb 15 00:34:52 fedora kernel: [drm] [nvidia-drm] [GPU ID 0x0100] 
Loading driver
Feb 15 00:34:54 fedora systemd[1]: Started nvidia-powerd.service - 
nvidia-powerd service.
Feb 15 00:34:54 fedora audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:syste
m_r:init_t:s0 msg='unit=nvidia-powerd comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? termina

l=? res=success'
Feb 15 00:34:54 fedora /usr/bin/nvidia-powerd[1367]: nvidia-powerd 
version:1.0(build 1)
Feb 15 00:34:54 fedora /usr/bin/nvidia-powerd[1367]: DBus Connection is 
established
Feb 15 00:34:54 fedora kernel: [drm] Initialized nvidia-drm 0.0.0 for 
:01:00.0 on minor 1
Feb 15 00:34:54 fedora systemd[1]: Starting 
systemd-backlight@backlight:nvidia_0.service - Load/Save Screen B

acklight Brightness of backlight:nvidia_0...
Feb 15 00:34:54 fedora systemd[1]: nvidia-fallback.service - Fallback to 
nouveau as nvidiadid not load was s
kipped because of an unmet condition check 
(ConditionPathExists=!/sys/module/nvidia).
Feb 15 00:34:55 fedora systemd[1]: Finished 
systemd-backlight@backlight:nvidia_0.service - Load/Save Screen B

acklight Brightness of backlight:nvidia_0.
Feb 15 00:34:55 fedora audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:syste
m_r:init_t:s0 msg='unit=systemd-backlight@backlight:nvidia_0 
comm="systemd" exe="/usr/lib/systemd/systemd" ho

stname=? addr=? terminal=? res=success'
Feb 15 00:35:06 fedora kernel: [drm:__nv_drm_connector_detect_internal 
[nvidia_drm]] *ERROR* [nvidia-drm] [GP

U ID 0x0100] Failed to detect display state
Feb 15 00:35:10 fedora systemd[2142]: Starting 
app-nvidia\x2dsettings\x2duser@autostart.service - nvidia-sett

ings...
Feb 15 00:35:10 fedora systemd[2142]: Started 
app-nvidia\x2dsettings\x2duser@autostart.service - nvidia-setti

ngs.
Feb 15 00:35:11 fedora systemd[2142]: 
app-nvidia\x2dsettings\x2duser@autostart.service: Main process exited,

code=exited, status=1/FAILURE
Feb 15 00:35:11 fedora systemd[2142]: 
app-nvidia\x2dsettings\x2duser@autostart.service: Failed with result 'e

xit-code'.
Feb 15 00:35:34 fedora packagekitd[3353]: Skipping refresh of 
rpmfusion-nonfree-nvidia-driver: Failed to down
load gpg key for repo 'rpmfusion-nonfree-nvidia-driver': Curl error 
(37): Could not read a file:// file for f
ile:///usr/share/distribution-gpg-keys/rpmfusion/RPM-GPG-KEY-rpmfusion-nonfree-fedora-42 
[Couldn't open file

/usr/share/distribution-gpg-keys/rpmfusion/RPM-GPG-KEY-rpmfusion-nonfree-fedora-42]
Feb 15 00:35:35 fedora systemd[1]: Stopping nvidia-powerd.service - 
nvidia-powerd service...

Feb 15 00:35:35 fedora /usr/bin/nvidia-powerd[1367]: Quit successfully
Feb 15 00:35:35 fedora systemd[1]: nvidia-powerd.service: Deactivated 
successfully.
Feb 15 00:35:35 fedora systemd[1]: Stopped nvidia-powerd.service - 
nvidia-powerd service.
Feb 15 00:35:35 fedora audit[1]: SERVICE_STOP pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system
_r:init_t:s0 msg='unit=nvidia-powerd comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal

=? res=success'
Feb 15 00:35:37 fedora systemd[1]: Stopping 
systemd-backlight@backlight:nvidia_0.service - Load/Save Screen B

acklight Brightness of backlight:nvidia_0...
Feb 15 00:35:37 fe

Re: pkgconf appears to be looping

[Samuel Sieb]

On 2/14/25 11:47 AM, George R Goffe via test wrote:

pkgconf seems to be consuming 99.9% of a core. It's not making system calls 
based on NO activity from strace.

This problem begins at login. Unless I kill pkgconf, I will not get logged in.


How is pkgconfig running at login?


This problem seems to appear during build operations. So far, building make 
makes the loop appear. In this instance, pkgconf shows up when invoked from the 
configure script. I have also tried building htop with the same results.

Has anyone seen this problem? I'm not sure what to do at this point in time. 
Removing it from the system (rename the binary) but then any expected results 
do not appear which makes the build fail.


What Fedora version?  (Since you're posting to this list, I'm guessing 
either F42 or rawhide.)  What are you trying to build?


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

Re: Where to fill bugs for fedora-kickstarts?

[Adam Williamson]

On Mon, 2025-02-10 at 11:01 -0800, Kevin Fenzi wrote:
> On Mon, Feb 10, 2025 at 06:27:12PM +0100, Milan Crha wrote:
> > On Mon, 2025-02-10 at 18:10 +0100, David Duncan wrote:
> > > We would be happy to assist you with building using the kiwi
> > > descriptions for them we are using now.
> > 
> > Hi,
> > should the Wiki page [3] be updated then? It looks recent,
> > it mentions `f42`. Updating the wiki, anyone can benefit,
> > not only me.
> > Thanks and bye,
> > Milan
> > 
> > [3] https://fedoraproject.org/wiki/QA/Test_Days/Live_Image
> 
> Yeah, that page needs a rework for sure. ;( 

It mentions current versions because it's using the version templates,
but it hasn't had a major edit (only cleanups) since 2013. However,
folks have been giving it minor touch-ups, and I think livecd-creator
was actually still working until fairly recently - jforbes noted it
wasn't working for the most recent kernel test day, but it *was*
working for the previous one.

We should probably update it to document use of Kiwi, since we're
gradually moving things towards that (and it's probably a bit easier to
run locally than livemedia-creator). I've filed a ticket for that:
https://pagure.io/fedora-qa/issue/800
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Where did dnf cache go? Where did fedora-qa on IRC go?

[Neal Gompa]

On Mon, Feb 10, 2025 at 3:12 PM Onyeibo Oku  wrote:
>
> Hi Everyone,
>
> I use a custom script to manage local repos of cached rpms.
> The script has been misbehaving since dnf5. At some point, I
> thought the devs were reworking repoquery. Now, I can't find the
> packages after running a dnf transaction.  I still have keepcache=1 (or
> True) in dnf.conf. /var/cache/dnf does not get new packages. Did
> something substantial change?
>

It moved to a new location: /var/cache/libdnf5

> Secondly, I logged into #fedora-qa channel on liberachat and discovered
> that the topic is more than two years old (last changed in 15-11-2022).
> What is going on? Am I losing touch?
>

It moved to Matrix: https://matrix.to/#/#quality:fedoraproject.org


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

Re: release dates

[Samuel Sieb]

On 2/5/25 7:33 PM, Felix Miata wrote:

Scott Dowdle composed on 2025-02-06 02:01 (UTC):


I search for "Fedora 42 schedule" and a page of useful information shows up... 
at least using Duck Duck Go.  I'm not sure what you are looking for specifically.


Today: branch date. Google thinks it's smart I guess, giving everything but a
schedule reference on page 1. Most of the time when I try DDG, nothing useful
shows up on the first page of hits, if anywhere. So I tried DDG, and no hits are
titled to resemble a release schedule or a roadmap to the future. I hit the 
first
anyway, and low and behold, on yet another scrollbar free page needing a
scrollbar, branching was yesterday:
December 18th – Changes requiring infrastructure changes
December 24th – Changes requiring mass rebuild
December 24th – System Wide changes
January 14th – Self Contained changes
February 4th – Changes need to be Testable
February 4th – Branching



The schedule is at:
https://fedorapeople.org/groups/schedule/f-42/f-42-all-tasks.html

I don't know what your scrollbar issue is, although you mention 
Seamonkey later on.  I've found that it has serious issues with some 
sites now.  It's not keeping up anymore.



OTOH, none of the usual system-upgrade options to work around conflicts
(--skip-broken, --allow-erasing, or whatever else used to be on
https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/) 
worked,


You don't actually say what the problem is, but parameter order matters 
now.  You can't just throw them anywhere you want.



so I tried simply upgrade --releasever=42, and ran into no such impediments.
Several packages, 6-7 or so, failed to upgrade. Ho hum. I cleaned up all but two
conflicteds with rpm and wget, and all now seems good enough:


Why would you need to use rpm and wget?  All of this sounds like you 
enjoy doing things the hard way...


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

Re: nvidia

[Mark Williams]

Great news. Thank you very much.

On 2/6/25 7:32 AM, Sérgio Basto via test wrote:


Is already fixed in xorg-x11-drv-nvidia-570.86.16-3.fc42 , the package 
is in koji but is not yet published, you have to wait for the package 
be published


On Thu, 2025-02-06 at 07:04 -0600, Mark Williams wrote:


Thank you.

On 2/6/25 6:58 AM, Sérgio Basto via test wrote:


On Thu, 2025-02-06 at 05:26 -0600, Mark Williams wrote:

nothing provides /usr/sbin/grubby needed by 
xorg-x11-drv-nvidia-3:570.86.16-2.fc42.x86_64 from rpmfusion-n

onfree-nvidia-driver


xorg-x11-drv-nvidia-3:570.86.16-2.fc42.x86_64 is an rpmfusion 
package to contact the maintainer we need report that on rpmfusion.


I did it for you https://bugzilla.rpmfusion.org/show_bug.cgi?id=7164



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

Re: nvidia

[Sérgio Basto via test]

Is already fixed in xorg-x11-drv-nvidia-570.86.16-3.fc42 , the package
is in koji but is not yet published, you have to wait for the package
be published 

On Thu, 2025-02-06 at 07:04 -0600, Mark Williams wrote:
>  
> Thank you. 
>  
> On 2/6/25 6:58 AM, Sérgio Basto via test wrote:
>  
> > 
> > On Thu, 2025-02-06 at 05:26 -0600, Mark Williams wrote:
> >  
> > >  
> > > nothing provides /usr/sbin/grubby needed by
> > > xorg-x11-drv-nvidia-3:570.86.16-2.fc42.x86_64 from rpmfusion-n
> > > onfree-nvidia-driver
> > >  
> >  
> > 
> >  
> >  
> > xorg-x11-drv-nvidia-3:570.86.16-2.fc42.x86_64 is an rpmfusion
> > package to contact the maintainer we need report that on
> > rpmfusion. 
> >  
> > 
> >  
> >  
> > I did it for
> > you https://bugzilla.rpmfusion.org/show_bug.cgi?id=7164 
> >  
> > 
> >  
> >  
> > 

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

Re: nvidia

[Mark Williams]

Thank you.

On 2/6/25 6:58 AM, Sérgio Basto via test wrote:

On Thu, 2025-02-06 at 05:26 -0600, Mark Williams wrote:
nothing provides /usr/sbin/grubby needed by 
xorg-x11-drv-nvidia-3:570.86.16-2.fc42.x86_64 from rpmfusion-n

onfree-nvidia-driver


xorg-x11-drv-nvidia-3:570.86.16-2.fc42.x86_64 is an rpmfusion package 
to contact the maintainer we need report that on rpmfusion.


I did it for you https://bugzilla.rpmfusion.org/show_bug.cgi?id=7164

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

Re: nvidia

[Sérgio Basto via test]

On Thu, 2025-02-06 at 05:26 -0600, Mark Williams wrote:
> nothing provides /usr/sbin/grubby needed by
> xorg-x11-drv-nvidia-3:570.86.16-2.fc42.x86_64 from rpmfusion-n
> onfree-nvidia-driver

xorg-x11-drv-nvidia-3:570.86.16-2.fc42.x86_64 is an rpmfusion package
to contact the maintainer we need report that on rpmfusion. 

I did it for you https://bugzilla.rpmfusion.org/show_bug.cgi?id=7164 

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

Re: release dates

[Luna Jernberg]

https://fedorapeople.org/groups/schedule/f-42/f-42-key-tasks.html

Den tors 6 feb. 2025 kl 02:12 skrev Felix Miata :
>
> Giving Google
>
> site:fedoraproject.org 42 alpha beta final rc dates
>
> produces nothing useful. Roadmap, branch and schedule don't help as search 
> terms
> either. What is the roadmap called? What links to it?
> --
> Evolution as taught in public schools is, like religion,
> based on faith, not based on science.
>
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
>
> Felix Miata
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: release dates

[Felix Miata]

Scott Dowdle composed on 2025-02-06 03:56 (UTC):

> I'm not sure what you mean about a-page-needs-a-scrollbar.  That isn't a 
> function of HTML nor the responsibility of someone creating a web page.  
> Browsers these days, for whatever reason the UI developers years ago, decided 
> that scrollbars should be hidden if the mouse isn't hovering over where they 
> should be... so they make them auto-hide (or drastically reduce them so they 
> are barely visible) and often only reveal them when the pointer is over them. 
>  I don't think browsers are the only programs that do that but I can't think 
> of another one off-hand.  UI developers think less-is-more and that 
> more-equals-clutter.

I'm not sure that's the whole story. There's only so much that can fit in the
micro screen of a mobile phone. My fingers are too big to use them with anything
but their NUM pads to put in phone numbers. Less than a week ago, I literally 
took
a sledge hammer to the one my sister gave me. First hit killed it. Third hit
exploded it and burned me with splatter. It was red hot for more than a minute
after the flames and smoke stopped.

>  I'm old and I would prefer that "clutter" personally... but developers don't 
> cater to old people. :(

That is oh so sadly true. "Powered by Discourse" in general equates to go away
unless you use the latest greatest awful bloatware web browser. openSUSE at 
least
employs a workaround on its Discourse pages that enables native scrollbars to
function in browsers that aren't Chrome wannabes, those with friendlier feature
sets and less bloat. Last visible text on
https://discussion.fedoraproject.org/t/fedora-operations-report/133731 is
"February 18th – Changes need to be Complete" unless CSS is disabled in 
SeaMonkey,
though some more is reachable via unzooming, and all is available via page 
source.
I don't open Discourse pages except when it results from clicking on a link
elsewhere, such as a Google hit, which is how I found out about Feb. 4th
branching. Last system-upgrade here was 3 days ago, before branching.

> I couldn't quite fully follow your email.  It sounded like you were trying to 
> upgraded Fedora 41 to Fedora 42... just because F42 branched from rawhide 
> today.  Is that just for a test to see what would happen?  That would be the 
> only reason I'd try it as branching from rawhide doesn't mean it is anywhere 
> near usable yet.  It'll still have several months of development... and have 
> one beta release.  I'm not looking at the schedule but I'm guessing it is 
> slated for near the end of April or beginning of May.  So, I'm not at all 
> surprised that attempting to upgrade from F41 to F42 today went badly as 
> that's what I would expect to happen.

> I sense quite a bit of frustration in your communication and I can only wish 
> to help ease that if only a little bit.

Bugzilla was barely into 6 digit bug numbers when I reported my first Rawhide 
bug
over two decades ago:
https://bugzilla.redhat.com/show_bug.cgi?id=107733 1st Rawhide; 103000 v9 
Anaconda
Now its numbers are well over 20 times that, and I've reported bugs there 66
times, possibly most of which started as Rawhide.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

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

Re: release dates

[Scott Dowdle via test]

I'm not sure what you mean about a-page-needs-a-scrollbar.  That isn't a 
function of HTML nor the responsibility of someone creating a web page.  
Browsers these days, for whatever reason the UI developers years ago, decided 
that scrollbars should be hidden if the mouse isn't hovering over where they 
should be... so they make them auto-hide (or drastically reduce them so they 
are barely visible) and often only reveal them when the pointer is over them.  
I don't think browsers are the only programs that do that but I can't think of 
another one off-hand.  UI developers think less-is-more and that 
more-equals-clutter.  I'm old and I would prefer that "clutter" personally... 
but developers don't cater to old people. :(

I couldn't quite fully follow your email.  It sounded like you were trying to 
upgraded Fedora 41 to Fedora 42... just because F42 branched from rawhide 
today.  Is that just for a test to see what would happen?  That would be the 
only reason I'd try it as branching from rawhide doesn't mean it is anywhere 
near usable yet.  It'll still have several months of development... and have 
one beta release.  I'm not looking at the schedule but I'm guessing it is 
slated for near the end of April or beginning of May.  So, I'm not at all 
surprised that attempting to upgrade from F41 to F42 today went badly as that's 
what I would expect to happen.

I sense quite a bit of frustration in your communication and I can only wish to 
help ease that if only a little bit.
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: release dates

[Felix Miata]

Scott Dowdle composed on 2025-02-06 02:01 (UTC):

> I search for "Fedora 42 schedule" and a page of useful information shows 
> up... at least using Duck Duck Go.  I'm not sure what you are looking for 
> specifically. 

Today: branch date. Google thinks it's smart I guess, giving everything but a
schedule reference on page 1. Most of the time when I try DDG, nothing useful
shows up on the first page of hits, if anywhere. So I tried DDG, and no hits are
titled to resemble a release schedule or a roadmap to the future. I hit the 
first
anyway, and low and behold, on yet another scrollbar free page needing a
scrollbar, branching was yesterday:
December 18th – Changes requiring infrastructure changes
December 24th – Changes requiring mass rebuild
December 24th – System Wide changes
January 14th – Self Contained changes
February 4th – Changes need to be Testable
February 4th – Branching


In the meantime while waiting for any response here, I simply looked on the
mirrors to see if 42 was there yet, and since it is, the question became moot.

OTOH, none of the usual system-upgrade options to work around conflicts
(--skip-broken, --allow-erasing, or whatever else used to be on
https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/) 
worked,
so I tried simply upgrade --releasever=42, and ran into no such impediments.
Several packages, 6-7 or so, failed to upgrade. Ho hum. I cleaned up all but two
conflicteds with rpm and wget, and all now seems good enough:
# inxi -MSaz --za --hostname
System:
  Host: ab560 Kernel: 6.12.12-200.fc41.x86_64 arch: x86_64 bits: 64
compiler: gcc v: 14.2.1 clocksource: tsc avail: hpet,acpi_pm
parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL= noresume audit=0
ipv6.disable=1 net.ifnames=0 consoleblank=0 preempt=full mitigations=off
  Desktop: TDE (Trinity) v: R14.1.3 tk: Qt v: 3.5.0 wm: Twin v: 3.0
with: kicker vt: 7 dm: 1: TDM 2: XDM Distro: Fedora Linux 42 (Adams
Prerelease)
Machine:
  Type: Desktop System: ASUS product: N/A v: N/A serial: N/A
  Mobo: ASUSTeK model: PRIME B560M-A v: Rev 1.xx serial: 
part-nu: SKU uuid:  UEFI: American Megatrends v: 1601
date: 05/07/2022
#
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

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

Re: release dates

[Scott Dowdle via test]

Greetings,

I search for "Fedora 42 schedule" and a page of useful information shows up... 
at least using Duck Duck Go.  I'm not sure what you are looking for 
specifically.

TYL,Scott Dowdle
(406) 750-3319 [cell]
(406) 994-3931 [work]

On Wednesday, February 5th, 2025 at 6:11 PM, Felix Miata 
 wrote:

> Giving Google
> 
> site:fedoraproject.org 42 alpha beta final rc dates
> 
> produces nothing useful. Roadmap, branch and schedule don't help as search 
> terms
> either. What is the roadmap called? What links to it?
> --
> Evolution as taught in public schools is, like religion,
> based on faith, not based on science.
> 
> Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> 
> Felix Miata
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dnf5

[Robert McBroom]

On 6/15/24 1:17 AM, Robert McBroom wrote:
Keep a local repository of system rpms using the commands on fc41 
QEMU/KVM virtual machine.


---

dnf repomanage --old . |xargs rm -rf
cd ../
createrepo_c --update -c cachedir Packages

---

After the latest system update get the message

Unknown argument "repomanage" for command "dnf5". Add "--help" for 
more information about the arguments.
It could be a command provided by a plugin, try: dnf5 install 
'dnf5-command(repomanage)'
Temporary repodata directory Packages/.repodata/ already exists! 
(Another createrepo process is running?)



Don't see any action to date. Is there another way to keep a local repo?
--
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Will bin-sbin-merge migrate existing systems?

[Ian Laurie via test]

On 29/1/25 10:37, Ian Laurie via test wrote:

As of Wednesday the list is down to 51 non-link entries in /usr/sbin.

Almost half of them caused by freeipmi that I can see is currently FTBFS
in 42 (BZ#2340176).


I'm down to 48 non-link entries in /usr/sbin.  The count isn't dropping
as quickly as I was hoping for, especially with the branch about to happen.

I guess the outstanding packages are caught in the FTBFS trap for now.

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

Re: systemd errors

[Robert McBroom]

On 1/30/25 12:49 PM, Adam Williamson wrote:

On Thu, 2025-01-30 at 12:27 -0500, Robert McBroom wrote:

dnf updates keep ending with the following--

  >>> Running trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64
  >>> Finished trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64
  >>> Scriptlet output:
  >>> Creating group 'gamemode' with GID 996.
  >>> Creating group 'stapunpriv' with GID 159.
  >>> Creating group 'gnome-remote-desktop' with GID 995.
  >>> Creating user 'gnome-remote-desktop' (GNOME Remote Desktop) with
UID 995 and GID 995.
  >>> Creating group 'passim' with GID 994.
  >>> Creating user 'passim' (Local Caching Server) with UID 994 and GID 994.
  >>> Creating user 'stapunpriv' (systemtap unprivileged user) with UID
159 and GID 159.
  >>> Failed to add existing group "wheel" to temporary group file:
Invalid argument
  >>>
  >>> Running trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64
  >>> Finished trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64
  >>> Scriptlet output:
  >>> /usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:2: Failed to
resolve user 'gnome-remote-desktop': No such process
  >>> /usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:3: Failed to
resolve user 'gnome-remote-desktop': No such process
  >>>

I don't use gnome. What is happening with all these strage groups that
systemd is trying to create?

This is likely fallout from
https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers -
the mechanism has been around for a while, but a lot of packages have
been changed to adopt it this cycle.

/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf is part of
gnome-remote-desktop, so even though you don't use GNOME, maybe you
have that package installed for some reason? Can you check? If so, you
could try removing it, maybe you don't need it - though this does look
like a bug that it'd be good to fix.

I'm not sure if the error on "wheel" is *causing* the g-r-d error,
either...CCing Zbigniew, who's looking after this Change, to see if he


gnome-remote-desktop
was installed
dnf remove accessed the single rpm
gnome-remote-desktop-0:47.3-1.fc41.x86_64 None of the the group entries 
are in /etc/group


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

Re: systemd errors

[Adam Williamson]

On Thu, 2025-01-30 at 12:27 -0500, Robert McBroom wrote:
> dnf updates keep ending with the following--
> 
>  >>> Running trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64
>  >>> Finished trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64
>  >>> Scriptlet output:
>  >>> Creating group 'gamemode' with GID 996.
>  >>> Creating group 'stapunpriv' with GID 159.
>  >>> Creating group 'gnome-remote-desktop' with GID 995.
>  >>> Creating user 'gnome-remote-desktop' (GNOME Remote Desktop) with 
> UID 995 and GID 995.
>  >>> Creating group 'passim' with GID 994.
>  >>> Creating user 'passim' (Local Caching Server) with UID 994 and GID 994.
>  >>> Creating user 'stapunpriv' (systemtap unprivileged user) with UID 
> 159 and GID 159.
>  >>> Failed to add existing group "wheel" to temporary group file: 
> Invalid argument
>  >>>
>  >>> Running trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64
>  >>> Finished trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64
>  >>> Scriptlet output:
>  >>> /usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:2: Failed to 
> resolve user 'gnome-remote-desktop': No such process
>  >>> /usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:3: Failed to 
> resolve user 'gnome-remote-desktop': No such process
>  >>>
> 
> I don't use gnome. What is happening with all these strage groups that 
> systemd is trying to create?

This is likely fallout from
https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers -
the mechanism has been around for a while, but a lot of packages have
been changed to adopt it this cycle.

/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf is part of
gnome-remote-desktop, so even though you don't use GNOME, maybe you
have that package installed for some reason? Can you check? If so, you
could try removing it, maybe you don't need it - though this does look
like a bug that it'd be good to fix.

I'm not sure if the error on "wheel" is *causing* the g-r-d error,
either...CCing Zbigniew, who's looking after this Change, to see if he
can make anything of these errors.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Will bin-sbin-merge migrate existing systems?

[Ian Laurie via test]

On 27/1/25 11:59, Ian Laurie via test wrote:

On my long-time running Rawhide instance, early Saturday my time, there
were 227 non-link entries in /usr/sbin.

As of now Monday (and with the fix for beesu) there are only 56
non-links left in /usr/sbin.


As of Wednesday the list is down to 51 non-link entries in /usr/sbin.

Almost half of them caused by freeipmi that I can see is currently FTBFS
in 42 (BZ#2340176).

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

Re: Will bin-sbin-merge migrate existing systems?

[Ian Laurie via test]

On 22/1/25 18:19, Adam Williamson wrote:

On Wed, 2025-01-22 at 12:39 +1100, Ian Laurie via test wrote:

On 22/1/25 12:05, Ian Laurie via test wrote:

Well I've just hit a related issue.  I just built a fresh VirtualBox
Rawhide Xfce made from
Fedora-Everything-netinst-x86_64-Rawhide-20250120.n.0.iso (blood
pressure still recovering from the dramas caused by the current
anaconda... Wayland?) and I am unable to install beesu.

The error looks related to the merge (beesu for me still isn't a link in
my old Rawhide instance... it's still in /usr/sbin).

rawhide$ sudo dnf install beesu
.
.
.
Running transaction
Transaction failed: Rpm transaction failed.
    - file /usr/sbin/beesu conflicts between attempted installs of
beesu-2.7-47.fc41.x86_64 and beesu-2.7-47.fc41.x86_64
rawhide$

Note that beesu is not yet installed.


I am assuming this is a real problem, so created a BZ:

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


It's because beesu (still) uses consolehelper, I've fixed a few things
for that already. There was a pattern for consolehelper which just
can't be used any more (/usr/sbin/foo was the real binary, /usr/bin/foo
was a link to consolehelper).


BZ#2339388 (beesu) is now fixed.

On my long-time running Rawhide instance, early Saturday my time, there
were 227 non-link entries in /usr/sbin.

As of now Monday (and with the fix for beesu) there are only 56
non-links left in /usr/sbin.

Not sure how useful it is to list the outstanding ones, but in case it
*is* useful here they are:

   43496 Dec  9 11:00 anacron
   32504 Aug  8 10:00 atd
  70 Aug  8 10:00 atrun
  63 Jul 17  2024 bmc-config
  169240 Jul 17  2024 bmc-device
  133344 Jul 17  2024 bmc-info
   36824 Jul 27  2024 charon-cmd
   24312 Jul 27  2024 charon-systemd
   76704 Dec  9 11:00 crond
 2107104 Jul 17  2024 dhclient
   33650 Jul 17  2024 dhclient-script
  531120 Jan  9 11:00 dnf5daemon-server
  483920 Dec 27 11:00 dnsmasq
   15656 Jul 18  2024 hfs-bless
   69896 Jul 18  2024 iodine
  135040 Jul 17  2024 ipmi-chassis
  66 Jul 17  2024 ipmi-chassis-config
  437680 Jul 17  2024 ipmi-config
   83832 Jul 17  2024 ipmiconsole
  143240 Jul 17  2024 ipmi-dcmi
   37576 Jul 17  2024 ipmidetect
  163824 Jul 17  2024 ipmi-fru
   20480 Jul 17  2024 ipmi-locate
 410 Jul 17  2024 ipmimonitoring
  336200 Jul 17  2024 ipmi-oem
  62 Jul 17  2024 ipmi-pef-config
  118200 Jul 17  2024 ipmi-pet
   32552 Jul 17  2024 ipmiping
  218696 Jul 17  2024 ipmipower
  113768 Jul 17  2024 ipmi-raw
  161144 Jul 17  2024 ipmi-sel
  194088 Jul 17  2024 ipmi-sensors
  66 Jul 17  2024 ipmi-sensors-config
   91720 Jul 18  2024 iptstate
   62360 Jul 18  2024 irqbalance
  376544 Jul 18  2024 iscsiadm
  293928 Jul 18  2024 iscsid
   20176 Jul 18  2024 iscsi-iname
  281280 Jul 18  2024 iscsistart
  165832 Jul 18  2024 iscsiuio
  287064 Jul 18  2024 iw
  440032 Oct 23 11:00 makedumpfile
 504 Oct 19 11:00 mount.vboxsf
   66616 Jul 19  2024 pptp
   24360 Jul 17  2024 rmcpping
7584 Jul 27  2024 strongswan
   98992 Jul 27  2024 swanctl
   62920 Jul 20  2024 usb_modeswitch
   27418 Jul 20  2024 usb_modeswitch_dispatcher
   49120 Jul 20  2024 userhelper
  720848 Oct 19 11:00 VBoxService
  261416 Jul 20  2024 visudo
  170080 Jul 20  2024 vpnc
 337 Jul 20  2024 vpnc-disconnect
  104880 Jul 20  2024 xl2tpd
   16408 Jul 20  2024 xl2tpd-control


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

Re: Will bin-sbin-merge migrate existing systems?

[Adam Williamson]

On Thu, 2025-01-23 at 17:17 -0500, John Mellor wrote:
> On 2025-01-23 2:51 p.m., Adam Williamson wrote:
> > On Thu, 2025-01-23 at 06:00 +, George R Goffe via test wrote:
> > > . . .
> > > 
> > > 2) Are we forgetting why we have the concept of statically linked 
> > > binaries?
> > What does that have to do with where they are?
> 
> If I may offer some insight:
> 
> In the Unix philosophy, everything in /sbin is statically linked.  
> Things in /bin may be statically linked, but more normally are dynamic.  
> The root user PATH normally has /sbin and /usr/sbin before the others, 
> while normal users have that reversed or even leave /sbin and /usr/sbin 
> out altogether.  This makes a difference when you are trying to recover 
> a system in the middle of the night. With tools like vi, sed, grep, 
> mount etc. being statically linked, there are less dependencies required 
> to get basic recovery tools working, increasing the likelihood that you 
> can get the system at least partially back up without having to 
> reinstall and lose mission-critical data.

Fedora has never subscribed to this philosophy. Statically-linked
binaries are discouraged in the packaging guidelines, without any kind
of exception for this purpose:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_statically_linking_executables

none of our packages containing the tools you mentioned, or any others,
are statically linked. We're a Linux distribution, not Unix.

> At least twice (once on Solaris and once on VMware), I've had to recover 
> a system with damaged filesystems spread across hundreds of drives and 
> still meet a 5-nines uptime guarantee. Reinstall is not an option in 
> these circumstances ever.  If you work out the numbers, I think that you 
> will agree that having standalone tool binaries is far more important 
> than saving a bit of disk on anything larger than a single-drive desktop.

The typical way to recover a Fedora system is with the recovery mode of
an installer image, or with a live image.
> 
> That thinking seems to have been lost in Fedora today, resulting in a 
> less recoverable platform.

It's not been "lost in Fedora today"; Fedora has never thought that
way.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Will bin-sbin-merge migrate existing systems?

[George R Goffe via test]

Howdy,

I just completed a "dnf upgrade" for this FC42 system and noticed the following 
message:

/usr/sbin cannot be merged, found /usr/sbin/VBoxService

This raises another issue (maybe). What about third party packages who seem to 
follow the policy for the contents of /sbin?

Best regards,

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

Re: [fedora-arm] Call for ARM testing: Kiwi-built ARM images

[Derek Enz]

Ok well unfortunately I cannot get either image to boot on my Raspberry Pi
5.

I was able to get an older image to work if that helps.


Derek Enz

On Thu, Jan 23, 2025 at 10:41 AM Adam Williamson 
wrote:

> On Wed, 2025-01-22 at 23:28 -0500, Sally A.haj wrote:
> > Hey Adam,
> >
> > I have tested Fedora-KDE-Desktop-Disk-Rawhide-
> > 20250121.n.0.aarch64.raw.xz on RPi4 and LibreComputer Alta boards, they
> > work just fine.
> >
> > The issue is with LibraComputer Alta board with Gnome, as the issue
> > seems related to mesa as it reported here
> > https://gitlab.freedesktop.org/mesa/mesa/-/issues/11892
>
> Thanks a lot for the testing! That issue doesn't look like it relates
> to how the images are built, so out of scope for the thing I'm
> concerned about here. I hope upstream can help fix it.
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
>
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Will bin-sbin-merge migrate existing systems?

[Kevin Fenzi]

On Thu, Jan 23, 2025 at 06:00:07AM +, George R Goffe via test wrote:
> Howdy,
> 
> I have several questions about this "movement".
> 
> 1) Why do this?
> 
> 2) Are we forgetting why we have the concept of statically linked binaries?
> 
> 3) When was this discussed? I ask this because I have experienced a "radio 
> silence" with regard to the list for the past 1-2 months. I received NO 
> emails from the list (digest mode) from 9 Dec, 2024 to 14 Jan, 2025 AND none 
> of my posts seemed to make it to the list. The "infra" group hasn't responded 
> either. Did yahoo mail get black listed? The group owner (Kamil Paral) has 
> responded though.

I responded to your ticket...

https://pagure.io/fedora-infrastructure/issue/12366

I looked at our logs and it shows emails are being delivered
to your provider. I cannot find any errors or rejects.

yahoo often blocks us. All it seems to take is one person marking a
mailing list that they confirmed signing up to as spam and they seem to
like blocking our entire domain for all users.

However, it doesn't seem to be the case here, I cannot find a failed
delivery to you from the test list.

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

Re: Will bin-sbin-merge migrate existing systems?

[Samuel Sieb]

On 1/23/25 6:04 PM, John Mellor wrote:


On 2025-01-23 5:32 p.m., Samuel Sieb wrote:

On 1/23/25 2:17 PM, John Mellor wrote:


On 2025-01-23 2:51 p.m., Adam Williamson wrote:

On Thu, 2025-01-23 at 06:00 +, George R Goffe via test wrote:

. . .

2) Are we forgetting why we have the concept of statically linked 
binaries?

What does that have to do with where they are?


If I may offer some insight:

In the Unix philosophy, everything in /sbin is statically linked. 
Things in /bin may be statically linked, but more normally are 
dynamic. The root user PATH normally has /sbin and /usr/sbin before 
the others, while normal users have that reversed or even leave /sbin 
and /usr/sbin out altogether.  This makes a difference when you are 
trying to recover a system in the middle of the night. With tools 
like vi, sed, grep, mount etc. being statically linked, there are 
less dependencies required to get basic recovery tools working, 
increasing the likelihood that you can get the system at least 
partially back up without having to reinstall and lose mission- 
critical data.


sbin being for static binaries is ancient history.  More recently it's 
for system (superuser) binaries.  I checked my sbin directory and the 
only statically linked binary there is "ldconfig".


Yes, its been broken for a lot of releases now.  The people who make 
these decisions are not admins with critical resources to keep flying.


This has nothing to do with Fedora.  As far as I can remember, sbin has 
never been for static binaries.  Maybe in ancient Unix systems, but I 
didn't have any consideration about that when using them at the time. 
The FHS even says the sbin is *system* binaries, not static.  Do you 
know of any distro that puts static binaries in sbin?  The only static 
binaries I can find on my system are ldconfig and the qemu static 
executables.


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

Re: Will bin-sbin-merge migrate existing systems?

[John Mellor]

On 2025-01-23 5:32 p.m., Samuel Sieb wrote:

On 1/23/25 2:17 PM, John Mellor wrote:


On 2025-01-23 2:51 p.m., Adam Williamson wrote:

On Thu, 2025-01-23 at 06:00 +, George R Goffe via test wrote:

. . .

2) Are we forgetting why we have the concept of statically linked 
binaries?

What does that have to do with where they are?


If I may offer some insight:

In the Unix philosophy, everything in /sbin is statically linked. 
Things in /bin may be statically linked, but more normally are 
dynamic. The root user PATH normally has /sbin and /usr/sbin before 
the others, while normal users have that reversed or even leave /sbin 
and /usr/sbin out altogether.  This makes a difference when you are 
trying to recover a system in the middle of the night. With tools 
like vi, sed, grep, mount etc. being statically linked, there are 
less dependencies required to get basic recovery tools working, 
increasing the likelihood that you can get the system at least 
partially back up without having to reinstall and lose 
mission-critical data.


sbin being for static binaries is ancient history.  More recently it's 
for system (superuser) binaries.  I checked my sbin directory and the 
only statically linked binary there is "ldconfig".



Yes, its been broken for a lot of releases now.  The people who make these 
decisions are not admins with critical resources to keep flying.

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

Re: Will bin-sbin-merge migrate existing systems?

[Samuel Sieb]

On 1/23/25 2:17 PM, John Mellor wrote:


On 2025-01-23 2:51 p.m., Adam Williamson wrote:

On Thu, 2025-01-23 at 06:00 +, George R Goffe via test wrote:

. . .

2) Are we forgetting why we have the concept of statically linked 
binaries?

What does that have to do with where they are?


If I may offer some insight:

In the Unix philosophy, everything in /sbin is statically linked. Things 
in /bin may be statically linked, but more normally are dynamic. The 
root user PATH normally has /sbin and /usr/sbin before the others, while 
normal users have that reversed or even leave /sbin and /usr/sbin out 
altogether.  This makes a difference when you are trying to recover a 
system in the middle of the night. With tools like vi, sed, grep, mount 
etc. being statically linked, there are less dependencies required to 
get basic recovery tools working, increasing the likelihood that you can 
get the system at least partially back up without having to reinstall 
and lose mission-critical data.


sbin being for static binaries is ancient history.  More recently it's 
for system (superuser) binaries.  I checked my sbin directory and the 
only statically linked binary there is "ldconfig".


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

Re: Will bin-sbin-merge migrate existing systems?

[John Mellor]

On 2025-01-23 2:51 p.m., Adam Williamson wrote:

On Thu, 2025-01-23 at 06:00 +, George R Goffe via test wrote:

. . .

2) Are we forgetting why we have the concept of statically linked binaries?

What does that have to do with where they are?


If I may offer some insight:

In the Unix philosophy, everything in /sbin is statically linked.  
Things in /bin may be statically linked, but more normally are dynamic.  
The root user PATH normally has /sbin and /usr/sbin before the others, 
while normal users have that reversed or even leave /sbin and /usr/sbin 
out altogether.  This makes a difference when you are trying to recover 
a system in the middle of the night. With tools like vi, sed, grep, 
mount etc. being statically linked, there are less dependencies required 
to get basic recovery tools working, increasing the likelihood that you 
can get the system at least partially back up without having to 
reinstall and lose mission-critical data.


At least twice (once on Solaris and once on VMware), I've had to recover 
a system with damaged filesystems spread across hundreds of drives and 
still meet a 5-nines uptime guarantee. Reinstall is not an option in 
these circumstances ever.  If you work out the numbers, I think that you 
will agree that having standalone tool binaries is far more important 
than saving a bit of disk on anything larger than a single-drive desktop.


That thinking seems to have been lost in Fedora today, resulting in a 
less recoverable platform.



. . .

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

Re: Will bin-sbin-merge migrate existing systems?

[Adam Williamson]

On Thu, 2025-01-23 at 06:00 +, George R Goffe via test wrote:
> Howdy,
> 
> I have several questions about this "movement".
> 
> 1) Why do this?

See the Change page.
https://fedoraproject.org/wiki//Changes/Unify_bin_and_sbin

> 2) Are we forgetting why we have the concept of statically linked binaries?

What does that have to do with where they are?

> 3) When was this discussed? I ask this because I have experienced a "radio 
> silence" with regard to the list for the past 1-2 months. I received NO 
> emails from the list (digest mode) from 9 Dec, 2024 to 14 Jan, 2025 AND none 
> of my posts seemed to make it to the list. The "infra" group hasn't responded 
> either. Did yahoo mail get black listed? The group owner (Kamil Paral) has 
> responded though.

There was a long discussion when this was first proposed, for F40, in
Dec 2023:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/OUNAAHIVSYMNXHJ2AMTE5FEPNLSB5RMZ/#OUNAAHIVSYMNXHJ2AMTE5FEPNLSB5RMZ

It was also initially approved for F40, but delayed twice to F41 (Feb
2024) then F42 (Aug 2024). That's why it's happening now, without a
*new* discussion.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: [fedora-arm] Call for ARM testing: Kiwi-built ARM images

[Adam Williamson]

On Wed, 2025-01-22 at 23:28 -0500, Sally A.haj wrote:
> Hey Adam,
> 
> I have tested Fedora-KDE-Desktop-Disk-Rawhide-
> 20250121.n.0.aarch64.raw.xz on RPi4 and LibreComputer Alta boards, they
> work just fine.
> 
> The issue is with LibraComputer Alta board with Gnome, as the issue
> seems related to mesa as it reported here
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/11892

Thanks a lot for the testing! That issue doesn't look like it relates
to how the images are built, so out of scope for the thing I'm
concerned about here. I hope upstream can help fix it.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Will bin-sbin-merge migrate existing systems?

[George R Goffe via test]

Howdy,

I have several questions about this "movement".

1) Why do this?

2) Are we forgetting why we have the concept of statically linked binaries?

3) When was this discussed? I ask this because I have experienced a "radio 
silence" with regard to the list for the past 1-2 months. I received NO emails 
from the list (digest mode) from 9 Dec, 2024 to 14 Jan, 2025 AND none of my 
posts seemed to make it to the list. The "infra" group hasn't responded either. 
Did yahoo mail get black listed? The group owner (Kamil Paral) has responded 
though.

Regards,

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

Re: Will bin-sbin-merge migrate existing systems?

[Adam Williamson]

On Wed, 2025-01-22 at 12:39 +1100, Ian Laurie via test wrote:
> On 22/1/25 12:05, Ian Laurie via test wrote:
> > Well I've just hit a related issue.  I just built a fresh VirtualBox
> > Rawhide Xfce made from
> > Fedora-Everything-netinst-x86_64-Rawhide-20250120.n.0.iso (blood
> > pressure still recovering from the dramas caused by the current
> > anaconda... Wayland?) and I am unable to install beesu.
> > 
> > The error looks related to the merge (beesu for me still isn't a link in
> > my old Rawhide instance... it's still in /usr/sbin).
> > 
> > rawhide$ sudo dnf install beesu
> > .
> > .
> > .
> > Running transaction
> > Transaction failed: Rpm transaction failed.
> >    - file /usr/sbin/beesu conflicts between attempted installs of
> > beesu-2.7-47.fc41.x86_64 and beesu-2.7-47.fc41.x86_64
> > rawhide$
> > 
> > Note that beesu is not yet installed.
> 
> I am assuming this is a real problem, so created a BZ:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2339388

It's because beesu (still) uses consolehelper, I've fixed a few things
for that already. There was a pattern for consolehelper which just
can't be used any more (/usr/sbin/foo was the real binary, /usr/bin/foo
was a link to consolehelper).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Will bin-sbin-merge migrate existing systems?

[Ian Laurie via test]

On 22/1/25 12:05, Ian Laurie via test wrote:

Well I've just hit a related issue.  I just built a fresh VirtualBox
Rawhide Xfce made from
Fedora-Everything-netinst-x86_64-Rawhide-20250120.n.0.iso (blood
pressure still recovering from the dramas caused by the current
anaconda... Wayland?) and I am unable to install beesu.

The error looks related to the merge (beesu for me still isn't a link in
my old Rawhide instance... it's still in /usr/sbin).

rawhide$ sudo dnf install beesu
.
.
.
Running transaction
Transaction failed: Rpm transaction failed.
   - file /usr/sbin/beesu conflicts between attempted installs of
beesu-2.7-47.fc41.x86_64 and beesu-2.7-47.fc41.x86_64
rawhide$

Note that beesu is not yet installed.


I am assuming this is a real problem, so created a BZ:

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

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

Re: Will bin-sbin-merge migrate existing systems?

[Ian Laurie via test]

On 22/1/25 09:47, Adam Williamson wrote:

On Wed, 2025-01-22 at 09:33 +1100, Ian Laurie via test wrote:

On 22/1/25 04:41, Adam Williamson wrote:

On Tue, 2025-01-21 at 14:23 +1100, Ian Laurie via test wrote:

For an existing Rawhide system, will regular updates migrate it to a
merged bin-sbin?  I am asking because it looks to me like it happened
already but my system still has a /usr/sbin directory.

Will an in-place upgrade of 41 to 42 merge bin and sbin?


Not exactly. Zbigniew decided that 'migrating' existing systems would
be too risky, so instead, they still have a separate /usr/sbin , but
everything in it should now be a symlink pointing to /usr/bin.

I have reservations about this design as it means pre-F42 upgraded
systems will differ significantly from F42+ fresh installs forever, but
we'll see how it works out.


OK small problem then, I still have a *lot* of stuff in /usr/sbin that
is not yet a link.  Is that expected and will change with more updates,
or has something gone wrong?

Partial listing to illustrate:

rawhide$ ls -l /usr/sbin
total 51384
-rwxr-xr-x. 1 root root   18984 Nov 20 11:00 abrt-auto-reporting
-rwxr-xr-x. 1 root root   39456 Nov 20 11:00 abrtd
-rwxr-xr-x. 1 root root  121776 Nov 20 11:00 abrt-dbus
-rwxr-xr-x. 1 root root1349 Nov 20 11:00 abrt-harvest-pstoreoops
-rwxr-xr-x. 1 root root8798 Nov 20 11:00 abrt-harvest-vmcore
-rwxr-xr-x. 1 root root   43560 Nov 20 11:00 abrt-server
-rwxr-xr-x. 1 root root   20392 Aug 29 10:00 accessdb
-rwxr-xr-x. 1 root root   16144 Jul 19  2024 accton
lrwxrwxrwx. 1 root root  19 Jan 16 15:25 addgnupghome ->
../bin/addgnupghome
lrwxrwxrwx. 1 root root  14 Jan 16 15:26 addpart -> ../bin/addpart
lrwxrwxrwx. 1 root root  14 Jan 16 15:26 adduser -> ../bin/adduser
lrwxrwxrwx. 1 root root  13 Jan 16 15:26 agetty -> ../bin/agetty
-rwxr-xr-x. 1 root root  135312 Nov 14 11:00 alsactl
-rwxr-xr-x. 1 root root   30138 Nov 14 11:00 alsa-info.sh


I'm not 100% sure, honestly. I think it might take updates.


Well I've just hit a related issue.  I just built a fresh VirtualBox
Rawhide Xfce made from
Fedora-Everything-netinst-x86_64-Rawhide-20250120.n.0.iso (blood
pressure still recovering from the dramas caused by the current
anaconda... Wayland?) and I am unable to install beesu.

The error looks related to the merge (beesu for me still isn't a link in
my old Rawhide instance... it's still in /usr/sbin).

rawhide$ sudo dnf install beesu
.
.
.
Running transaction
Transaction failed: Rpm transaction failed.
  - file /usr/sbin/beesu conflicts between attempted installs of
beesu-2.7-47.fc41.x86_64 and beesu-2.7-47.fc41.x86_64
rawhide$

Note that beesu is not yet installed.

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

Re: Call for ARM testing: Kiwi-built ARM images

[Brandon Nielsen via test]

On 1/21/25 2:52 PM, Adam Williamson wrote:

Hey folks! There is currently a proposal to switch Workstation images
to build with Kiwi:

https://pagure.io/pungi-fedora/pull-request/1419

It would be good to have some data on whether Kiwi-built images work
well on ARM before we switch Workstation.

The KDE images - both the live ISO and the disk images - are already
built with Kiwi, so if anyone wants to help out and has ARM test
hardware (don't do this in production!), it'd be great if you could
test deploying a recent Rawhide KDE image and see if it works OK. If it
doesn't, try a Workstation image (which are still built with the older
tools) and see if that one works.

Kiwi-built KDE disk image:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20250121.n.0/compose/Spins/aarch64/images/Fedora-KDE-Desktop-Disk-Rawhide-20250121.n.0.aarch64.raw.xz
Workstation disk image built with older tool:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20250121.n.0/compose/Workstation/aarch64/images/Fedora-Workstation-Rawhide-20250121.n.0.aarch64.raw.xz
Kiwi-built KDE live image:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20250121.n.0/compose/Spins/aarch64/iso/Fedora-KDE-Desktop-Live-Rawhide-20250121.n.0.aarch64.iso
Workstation live image built with older tool:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20250121.n.0/compose/Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20250121.n.0.iso

it'd be great if we could get results across some different hardware,
and especially from Raspberry Pi as that's the most common hardware.
Thanks!


The Kiwi-built KDE disk image works for me on a Raspberry Pi 4b+.
--
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Will bin-sbin-merge migrate existing systems?

[Adam Williamson]

On Wed, 2025-01-22 at 09:33 +1100, Ian Laurie via test wrote:
> On 22/1/25 04:41, Adam Williamson wrote:
> > On Tue, 2025-01-21 at 14:23 +1100, Ian Laurie via test wrote:
> > > For an existing Rawhide system, will regular updates migrate it to a
> > > merged bin-sbin?  I am asking because it looks to me like it happened
> > > already but my system still has a /usr/sbin directory.
> > > 
> > > Will an in-place upgrade of 41 to 42 merge bin and sbin?
> > 
> > Not exactly. Zbigniew decided that 'migrating' existing systems would
> > be too risky, so instead, they still have a separate /usr/sbin , but
> > everything in it should now be a symlink pointing to /usr/bin.
> > 
> > I have reservations about this design as it means pre-F42 upgraded
> > systems will differ significantly from F42+ fresh installs forever, but
> > we'll see how it works out.
> 
> OK small problem then, I still have a *lot* of stuff in /usr/sbin that
> is not yet a link.  Is that expected and will change with more updates,
> or has something gone wrong?
> 
> Partial listing to illustrate:
> 
> rawhide$ ls -l /usr/sbin
> total 51384
> -rwxr-xr-x. 1 root root   18984 Nov 20 11:00 abrt-auto-reporting
> -rwxr-xr-x. 1 root root   39456 Nov 20 11:00 abrtd
> -rwxr-xr-x. 1 root root  121776 Nov 20 11:00 abrt-dbus
> -rwxr-xr-x. 1 root root1349 Nov 20 11:00 abrt-harvest-pstoreoops
> -rwxr-xr-x. 1 root root8798 Nov 20 11:00 abrt-harvest-vmcore
> -rwxr-xr-x. 1 root root   43560 Nov 20 11:00 abrt-server
> -rwxr-xr-x. 1 root root   20392 Aug 29 10:00 accessdb
> -rwxr-xr-x. 1 root root   16144 Jul 19  2024 accton
> lrwxrwxrwx. 1 root root  19 Jan 16 15:25 addgnupghome ->
> ../bin/addgnupghome
> lrwxrwxrwx. 1 root root  14 Jan 16 15:26 addpart -> ../bin/addpart
> lrwxrwxrwx. 1 root root  14 Jan 16 15:26 adduser -> ../bin/adduser
> lrwxrwxrwx. 1 root root  13 Jan 16 15:26 agetty -> ../bin/agetty
> -rwxr-xr-x. 1 root root  135312 Nov 14 11:00 alsactl
> -rwxr-xr-x. 1 root root   30138 Nov 14 11:00 alsa-info.sh

I'm not 100% sure, honestly. I think it might take updates.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Will bin-sbin-merge migrate existing systems?

[Ian Laurie via test]

On 22/1/25 04:41, Adam Williamson wrote:

On Tue, 2025-01-21 at 14:23 +1100, Ian Laurie via test wrote:

For an existing Rawhide system, will regular updates migrate it to a
merged bin-sbin?  I am asking because it looks to me like it happened
already but my system still has a /usr/sbin directory.

Will an in-place upgrade of 41 to 42 merge bin and sbin?


Not exactly. Zbigniew decided that 'migrating' existing systems would
be too risky, so instead, they still have a separate /usr/sbin , but
everything in it should now be a symlink pointing to /usr/bin.

I have reservations about this design as it means pre-F42 upgraded
systems will differ significantly from F42+ fresh installs forever, but
we'll see how it works out.


OK small problem then, I still have a *lot* of stuff in /usr/sbin that
is not yet a link.  Is that expected and will change with more updates,
or has something gone wrong?

Partial listing to illustrate:

rawhide$ ls -l /usr/sbin
total 51384
-rwxr-xr-x. 1 root root   18984 Nov 20 11:00 abrt-auto-reporting
-rwxr-xr-x. 1 root root   39456 Nov 20 11:00 abrtd
-rwxr-xr-x. 1 root root  121776 Nov 20 11:00 abrt-dbus
-rwxr-xr-x. 1 root root1349 Nov 20 11:00 abrt-harvest-pstoreoops
-rwxr-xr-x. 1 root root8798 Nov 20 11:00 abrt-harvest-vmcore
-rwxr-xr-x. 1 root root   43560 Nov 20 11:00 abrt-server
-rwxr-xr-x. 1 root root   20392 Aug 29 10:00 accessdb
-rwxr-xr-x. 1 root root   16144 Jul 19  2024 accton
lrwxrwxrwx. 1 root root  19 Jan 16 15:25 addgnupghome ->
../bin/addgnupghome
lrwxrwxrwx. 1 root root  14 Jan 16 15:26 addpart -> ../bin/addpart
lrwxrwxrwx. 1 root root  14 Jan 16 15:26 adduser -> ../bin/adduser
lrwxrwxrwx. 1 root root  13 Jan 16 15:26 agetty -> ../bin/agetty
-rwxr-xr-x. 1 root root  135312 Nov 14 11:00 alsactl
-rwxr-xr-x. 1 root root   30138 Nov 14 11:00 alsa-info.sh

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

Re: Will bin-sbin-merge migrate existing systems?

[Steven A. Falco]

On 1/21/25 12:41 PM, Adam Williamson wrote:

On Tue, 2025-01-21 at 14:23 +1100, Ian Laurie via test wrote:

For an existing Rawhide system, will regular updates migrate it to a
merged bin-sbin?  I am asking because it looks to me like it happened
already but my system still has a /usr/sbin directory.

Will an in-place upgrade of 41 to 42 merge bin and sbin?


Not exactly. Zbigniew decided that 'migrating' existing systems would
be too risky, so instead, they still have a separate /usr/sbin , but
everything in it should now be a symlink pointing to /usr/bin.

I have reservations about this design as it means pre-F42 upgraded
systems will differ significantly from F42+ fresh installs forever, but
we'll see how it works out.


I'd be interested in manually converting my desktop machine when the time 
comes, because reinstalling is way too involved given all the customizations 
I've done.

Is it as simple as renaming /usr/sbin to /usr/sbin.old and soft-linking 
/usr/bin to /usr/sbin?  If so, it would be easy to try it out and easy to 
reverse if needed.

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

Re: Will bin-sbin-merge migrate existing systems?

[Adam Williamson]

On Tue, 2025-01-21 at 14:23 +1100, Ian Laurie via test wrote:
> For an existing Rawhide system, will regular updates migrate it to a
> merged bin-sbin?  I am asking because it looks to me like it happened
> already but my system still has a /usr/sbin directory.
> 
> Will an in-place upgrade of 41 to 42 merge bin and sbin?

Not exactly. Zbigniew decided that 'migrating' existing systems would
be too risky, so instead, they still have a separate /usr/sbin , but
everything in it should now be a symlink pointing to /usr/bin.

I have reservations about this design as it means pre-F42 upgraded
systems will differ significantly from F42+ fresh installs forever, but
we'll see how it works out.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Criteria proposal: reword beta upgrade package requirement footnote

[Kamil Paral]

On Thu, Jan 16, 2025 at 5:56 PM Adam Williamson 
wrote:

> But we *don't* only care about that. We *do* want to make sure that
> upgrade doesn't suddenly turn your KDE install into Workstation, for
> instance.
>

OK. What if we made it more explicit, since this is clearly one of the
major goals of this criterion? What about this:

~~
The upgraded system must identify as the same Edition/Spin and present the
same working environment as the system before upgrade (unless that change
is intentional).
The upgraded system must include any Fedora-built packages that were
installed before upgrade (unless those packages were expected to be removed
by an intentional packaging change [1]).
The upgrade process may also add packages that, in the new release, are
newly included in package groups that were installed before upgrade.

[1] E.g. a package is obsoleted by a different one; a package dependency is
no longer required; a package is dropped from a package group; a package is
retired and its dependencies can no longer be satisfied; etc.
~~

I'd also like to have the text above be moved from a footnote and be
included in the main criterion text instead (except [1], that could be a
footnote). The instructions seem to be too important to be hidden in a
footnote. We should use footnotes for clarifying, but not for hiding core
requirements.


> I phrased it as 'may' for practical reasons - I'm not sure all
> supported upgrade methods actually do this. If someone wants to check
> that both dnf system-upgrade and GNOME Software upgrades actually do
> this, we could make it 'must', I guess.
>

I expect this to be broken with the switch to DNF5, sadly, at least in my
limited experience. I'd love to have "must" in there, but that should
probably be a standalone discussion.
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Criteria proposal: reword beta upgrade package requirement footnote

[Adam Williamson]

On Thu, 2025-01-16 at 12:51 +0100, Kamil Paral wrote:
> On Mon, Jan 6, 2025 at 8:41 PM Adam Williamson 
> wrote:
> 
> > Hi folks! I decided it's finally time to knock this action item off my
> > todo list...
> > 
> > Last cycle, we had a proposed blocker[1] which relied on a footnote to
> > the Beta upgrade criterion which was added way back when we first set
> > up the Editions:
> > 
> > "The upgraded system must include all packages that would be present on
> > the system after a default installation from install media, plus any
> > packages the user previously had (minus any obsolete content)"[2]
> > 
> > We had a detailed discussion about this at the review meeting[3]. The
> > text does seem to cover the proposed blocker as written, but we didn't
> > think it was really meant to. Per sgallagh, the intent of this footnote
> > was "to guarantee that upgrades from F20 -> F21 would specify a
> > preferred edition and then guarantee that they would get everything
> > from the default install of that Edition plus keep whatever else was on
> > their system (i.e. don't reset them to a default install)".
> > 
> > At a subsequent team meeting[4], we talked about it again, and I
> > volunteered to do a rewrite. So, I propose we change it to:
> > 
> > "The upgraded system must include any packages that were installed
> > before upgrade, unless the package was obsoleted. The upgrade process
> > may also add packages that, in the new release, are newly included in
> > package groups that were installed before upgrade."
> > 
> 
> Sorry, I might still be confused by this discussion, so bear with me if I'm
> talking nonsense. But when reading "guarantee that they would get
> everything from the default install of that Edition plus keep whatever else
> was on their system", I'd modify the proposed text as follows:
> 
> "The upgraded system must include any packages that were installed before
> upgrade, unless the package was obsoleted."
> into
> "The upgraded system must include any user-installed packages that were
> installed before upgrade, unless the package was obsoleted."
> 
> This makes it clear that we care only about packages that the user
> explicitly installed on top of the system, meaning we don't care about
> default system packages, or dependencies for user-installed packages (that
> would answer Miro's question).

But we *don't* only care about that. We *do* want to make sure that
upgrade doesn't suddenly turn your KDE install into Workstation, for
instance.

> "The upgrade process may also add packages that, in the new release, are
> newly included in package groups that were installed before upgrade."
> into
> "The upgrade process must also add packages that, in the new release, are
> newly included in package groups that were installed before upgrade."

I phrased it as 'may' for practical reasons - I'm not sure all
supported upgrade methods actually do this. If someone wants to check
that both dnf system-upgrade and GNOME Software upgrades actually do
this, we could make it 'must', I guess.

> 
> This makes sure that you "get everything from the default install of that
> Edition", as originally specified (with the exception of default packages
> which were intentionally removed by the user, because it makes sense to not
> return them back on each upgrade -> let's talk just about new additions).

It doesn't really do that, though, or at least not clearly, because
it's talking about adding new packages from 'groups'. I added it mainly
because I know some upgrade mechanisms do do this, and it seemed a good
idea to explicitly cover in the criteria that it's OK.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Criteria proposal: reword beta upgrade package requirement footnote

[Kamil Paral]

On Mon, Jan 6, 2025 at 8:41 PM Adam Williamson 
wrote:

> Hi folks! I decided it's finally time to knock this action item off my
> todo list...
>
> Last cycle, we had a proposed blocker[1] which relied on a footnote to
> the Beta upgrade criterion which was added way back when we first set
> up the Editions:
>
> "The upgraded system must include all packages that would be present on
> the system after a default installation from install media, plus any
> packages the user previously had (minus any obsolete content)"[2]
>
> We had a detailed discussion about this at the review meeting[3]. The
> text does seem to cover the proposed blocker as written, but we didn't
> think it was really meant to. Per sgallagh, the intent of this footnote
> was "to guarantee that upgrades from F20 -> F21 would specify a
> preferred edition and then guarantee that they would get everything
> from the default install of that Edition plus keep whatever else was on
> their system (i.e. don't reset them to a default install)".
>
> At a subsequent team meeting[4], we talked about it again, and I
> volunteered to do a rewrite. So, I propose we change it to:
>
> "The upgraded system must include any packages that were installed
> before upgrade, unless the package was obsoleted. The upgrade process
> may also add packages that, in the new release, are newly included in
> package groups that were installed before upgrade."
>

Sorry, I might still be confused by this discussion, so bear with me if I'm
talking nonsense. But when reading "guarantee that they would get
everything from the default install of that Edition plus keep whatever else
was on their system", I'd modify the proposed text as follows:

"The upgraded system must include any packages that were installed before
upgrade, unless the package was obsoleted."
into
"The upgraded system must include any user-installed packages that were
installed before upgrade, unless the package was obsoleted."

This makes it clear that we care only about packages that the user
explicitly installed on top of the system, meaning we don't care about
default system packages, or dependencies for user-installed packages (that
would answer Miro's question).

"The upgrade process may also add packages that, in the new release, are
newly included in package groups that were installed before upgrade."
into
"The upgrade process must also add packages that, in the new release, are
newly included in package groups that were installed before upgrade."

This makes sure that you "get everything from the default install of that
Edition", as originally specified (with the exception of default packages
which were intentionally removed by the user, because it makes sense to not
return them back on each upgrade -> let's talk just about new additions).
This makes sure that our new installs don't diverge from upgraded systems,
e.g. by having a new feature just in a fresh install but not adding it into
an upgraded system.
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rtl8812au rtl88x2bu drivers

[Peter Robinson]

Hey,

Saw a note the the rtl8812au rtl88x2bu drivers were being builtin into
> the kernel for f42.  They are not in the 6.13.0* kernels and the github
> packages that worked for the 6.12.0* kernels now fail
>

There's  8812AU and 8821AU drivers, I don't see any of the b variants
referenced, but I've done a PR to enabled them in the Fedora kernel:
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3601

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

Re: Criteria proposal: reword beta upgrade package requirement footnote

[Miro Hrončok]

What about packages that used to be dependencies but are no longer so? The 
"unused dependencies" packages.

(Sorry if this email is misformated, I am not subscribed to this list, so I use 
the web interface.)
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: is /proc/net/wireless really gone?

[Onyeibo Oku]

Hi Peter,

On Sat, 4 Jan 2025 12:03:28 +
Peter Robinson  wrote:

> Yes, it has really gone, it's been deprecated since 2006.
> 
> I filed a bug report against bumblebee-status
> > (https://github.com/tobi-wan-kenobi/bumblebee-status/issues/1029).
> >  
> 
> Bumblebee should move to using the netlink (libnl) interface for
> reporting wireless status. I can provide more details on that ticket
> if it's needed when I'm back at my keyboard

> Peter

It's fixed! Bumblebee-status now queries iw directly
rather than '/proc/net/wireless'. Thanks a lot.

Regards
Onyeibo

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

Re: Criteria proposal: reword beta upgrade package requirement footnote

[pmkellly]

Looks good to me.

Have a Great Day!

Pat  (tablepc)


On Mon, Jan 6, 2025 at 2:41 PM Adam Williamson 
wrote:

> Hi folks! I decided it's finally time to knock this action item off my
> todo list...
>
> Last cycle, we had a proposed blocker[1] which relied on a footnote to
> the Beta upgrade criterion which was added way back when we first set
> up the Editions:
>
> "The upgraded system must include all packages that would be present on
> the system after a default installation from install media, plus any
> packages the user previously had (minus any obsolete content)"[2]
>
> We had a detailed discussion about this at the review meeting[3]. The
> text does seem to cover the proposed blocker as written, but we didn't
> think it was really meant to. Per sgallagh, the intent of this footnote
> was "to guarantee that upgrades from F20 -> F21 would specify a
> preferred edition and then guarantee that they would get everything
> from the default install of that Edition plus keep whatever else was on
> their system (i.e. don't reset them to a default install)".
>
> At a subsequent team meeting[4], we talked about it again, and I
> volunteered to do a rewrite. So, I propose we change it to:
>
> "The upgraded system must include any packages that were installed
> before upgrade, unless the package was obsoleted. The upgrade process
> may also add packages that, in the new release, are newly included in
> package groups that were installed before upgrade."
>
> The last sentence is included because we do do that on upgrade, these
> days, so the criterion should allow for it. What do folks think of this
> wording? Thanks!
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2309697
> [2]
> https://fedoraproject.org/wiki/Fedora_42_Beta_Release_Criteria#Upgrade_requirements
> [3]
> https://meetbot-raw.fedoraproject.org/teams/f41-blocker-review/f41-blocker-review.2024-09-09-16.01.log.html
> [4]
> https://meetbot-raw.fedoraproject.org/teams/quality/quality.2024-09-16-15.00.log.html
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
>
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: is /proc/net/wireless really gone?

[Peter Robinson]

Hi,


On Sat, 4 Jan 2025, 04:30 Onyeibo Oku,  wrote:

> Happy New Year everyone,
>
> I am getting an error message on my status bar (which depends on
> a manager called bumblebee-status). The message reads:
>
> [Errno 2] No such file or directory: '/proc/net/wireless'
>
> This has been the case for weeks. I assumed the issue would go away
> after subsequent updates but it persists. All the while, I cannot see
> the state of my wireless connections via the status bar.
>

Yes, it has really gone, it's been deprecated since 2006.

I filed a bug report against bumblebee-status
> (https://github.com/tobi-wan-kenobi/bumblebee-status/issues/1029).
>

Bumblebee should move to using the netlink (libnl) interface for reporting
wireless status. I can provide more details on that ticket if it's needed
when I'm back at my keyboard


> The maintainer thinks my wireless driver has issues. I, therefore, failed
> a corresponding report against the driver
> (https://github.com/clnhub/rtl8192eu-linux/issues/111).
>

The rtl8192 driver was the last one using it, that driver was dropped from
the kennel recently,

According to the driver maintainer, Fedora deprecated "Wireless
> Extensions" which is responsible for "/proc/net/wireless". While the
> decision does not affect the operations of the wireless driver (because
> I am able to access the internet through the device), tools
> that query network status via "/proc/net/wireless" appear to be
> affected.
>

All the tools that are packaged in fedora have long been migrated.

I even have a related report againt the kernel
> (https://bugzilla.redhat.com/show_bug.cgi?id=2334171). What is the way
> forward?
> What is the alternative to "/proc/net/wireless"?  Perhaps, someone here
> may have information that will be beneficial to the maintainers above.
>

Wireless-extensions have been deprecated since 2006, it's not properly
reported details on all sorts of things like standards like 802.11n and
newer and doesn't work at all with WiFi -7 and is due to be removed
upstream soon.

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

Re: GK107 10de:0fc1 Kepler regression: black screen when KMS enabled

[Sérgio Basto]

On Fri, 2024-12-27 at 17:32 -0500, Felix Miata wrote:
> I just installed xorg-x11-drv-nouveau-1.0.17-11.fc41 to see if it
> makes any
> difference, forcing its use via /etc/X11/xorg.conf.d/. It made no
> difference
> apparent to me, so I removed the config and the nouveau DDX rpm,
> which normally I
> don't have installed.

ah sorry , you report on drm nouveau , I though it was report to drv
nouveau (
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/ ) 


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

Re: GK107 10de:0fc1 Kepler regression: black screen when KMS enabled

[Felix Miata]

Sérgio Basto composed on 2024-12-27 17:49 (UTC):

> On Sun, 2024-12-15 at 18:15 -0500, Felix Miata wrote:

>> Felix Miata composed on 2024-12-13 16:25 (UTC-0500):

>>> https://gitlab.freedesktop.org/drm/nouveau/-/issues/385
>>> GK107 10de:0fc1 Kepler black screen when KMS enabled
>>> No local I/O is possible once KMS engages.

>>> 6.11.11-300.fc41.x86_64 produces the same problem as all other post-6.6 
>>> kernels.
>>> 6.6.63 in Tumbleweed is working just dandy. No distros' current kernels 
>>> behave any
>>> differently. There's been zero activity in that report other than from 
>>> myself. Can
>>> anyone here suggest anything I can do to generate interest (that does not 
>>> include
>>> me trying to bisect or build software) in providing a fix? Command line 
>>> option(s)
>>> perhaps?

>> I've updated
>> https://gitlab.freedesktop.org/drm/nouveau/-/issues/385 to indicate
>> appropriate uses of video= on kernel cmdline can enable normal use of vttys. 
>> All
>> displays are still put into sleep mode or into unsupported mode on X 
>> startup, but
>> Ctrl-Alt-Fn succeeds to switch to available vttys.

> Another option is use driver modesetting (man
> /usr/share/man/man4/modesetting.4.gz )  

As is evident in

and the first bug report comment, inxi makes it clear (at least to me) that the
modesetting DIX is my employed display driver.

> We already have a patch on xorg-x11-server package that defaults all
> GeForce 8 and newer to modesetting drive [1], chatgpt says: "Yes,
> modesetting for the GK107 GPU (NVIDIA Kepler, 10de:0fc1) is possible"

> [1]
> https://src.fedoraproject.org/rpms/xorg-x11-server/blob/e3a0a54473c7d63df39467bdf0b093fedb25a962/f/0001-xfree86-use-modesetting-driver-by-default-on-GeForce.patch
>  

I just installed xorg-x11-drv-nouveau-1.0.17-11.fc41 to see if it makes any
difference, forcing its use via /etc/X11/xorg.conf.d/. It made no difference
apparent to me, so I removed the config and the nouveau DDX rpm, which normally 
I
don't have installed.
# inxi -SG
System:
  Host: p5bse Kernel: 6.12.4-200.fc41.x86_64 arch: x86_64 bits: 64
  Desktop: TDE (Trinity) v: R14.1.3 Distro: Fedora Linux 41 (Forty One)
Graphics:
  Device-1: NVIDIA GK107 [GeForce GT 640] driver: nouveau v: kernel
  Display: unspecified server: X.org v: 1.21.1.14 driver: X: loaded: nouveau
dri: nouveau gpu: nouveau
  API: EGL v: 1.5 drivers: nouveau,swrast platforms: gbm,surfaceless,device
  API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 24.2.8 note: incomplete
(EGL sourced) renderer: NVE7, llvmpipe (LLVM 19.1.0 128 bits)
  API: Vulkan Message: No Vulkan data available.
# dmesg | egrep -i 'drm|veau'
[2.261249] ACPI: bus type drm_connector registered
[   18.696303] systemd[1]: Starting modprobe@drm.service - Load Kernel Module 
drm...
[   18.845111] systemd[1]: modprobe@drm.service: Deactivated successfully.
[   18.845377] systemd[1]: Finished modprobe@drm.service - Load Kernel Module 
drm.
[   41.193474] nouveau :01:00.0: NVIDIA GK107 (0e7010a2)
[   41.305918] nouveau :01:00.0: bios: version 80.07.42.00.08
[   41.306665] nouveau :01:00.0: vgaarb: deactivate vga console
[   41.308850] nouveau :01:00.0: fb: 2048 MiB DDR3
[   41.980572] nouveau :01:00.0: drm: VRAM: 2048 MiB
[   41.980582] nouveau :01:00.0: drm: GART: 1048576 MiB
[   41.980593] nouveau :01:00.0: drm: TMDS table version 2.0
[   41.982029] nouveau :01:00.0: drm: MM: using COPY for buffer copies
[   41.983529] snd_hda_intel :01:00.1: bound :01:00.0 (ops
nv50_audio_component_bind_ops [nouveau])
[   41.984783] [drm] Initialized nouveau 1.4.0 for :01:00.0 on minor 0
[   41.995961] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   41.995988] nouveau :01:00.0: [drm] Cannot find any crtc or sizes
[   42.041809] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   42.041832] nouveau :01:00.0: [drm] Cannot find any crtc or sizes
[   42.052868] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   42.052886] nouveau :01:00.0: [drm] Cannot find any crtc or sizes
[   62.076049] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   62.094316] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   70.404708] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   70.415815] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   70.426863] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
#

IME, the modesetting DIX works perfectly well on GeForce GPUs older than 8.

# inxi -GSaz --za
System:
  Kernel: 6.11.11-300.fc41.x86_64 arch: x86_64 bits: 64 compiler: gcc
v: 2.43.1-4.fc41 clocksource: tsc avail: hpet,acpi_pm parameters: ro
root=LABEL= ipv6.disable=1 net.ifnames=0 audit=0 selinux=0
noresume consoleblank=0 mitigations=off
  Desktop: IceWM v: 3.6.0 

Re: GK107 10de:0fc1 Kepler regression: black screen when KMS enabled

[Sérgio Basto]

On Sun, 2024-12-15 at 18:15 -0500, Felix Miata wrote:
> Felix Miata composed on 2024-12-13 16:25 (UTC-0500):
> 
> > https://gitlab.freedesktop.org/drm/nouveau/-/issues/385
> > GK107 10de:0fc1 Kepler black screen when KMS enabled
> > No local I/O is possible once KMS engages.
> 
> > 6.11.11-300.fc41.x86_64 produces the same problem as all other
> > post-6.6 kernels.
> > 6.6.63 in Tumbleweed is working just dandy. No distros' current
> > kernels behave any
> > differently. There's been zero activity in that report other than
> > from myself. Can
> > anyone here suggest anything I can do to generate interest (that
> > does not include
> > me trying to bisect or build software) in providing a fix? Command
> > line option(s)
> > perhaps?
> 
> I've updated
> https://gitlab.freedesktop.org/drm/nouveau/-/issues/385 to indicate
> appropriate uses of video= on kernel cmdline can enable normal use of
> vttys. All
> displays are still put into sleep mode or into unsupported mode on X
> startup, but
> Ctrl-Alt-Fn succeeds to switch to available vttys.


Another option is use driver modesetting (man
/usr/share/man/man4/modesetting.4.gz ) 

We already have a patch on xorg-x11-server package that defaults all
GeForce 8 and newer to modesetting drive [1], chatgpt says: "Yes,
modesetting for the GK107 GPU (NVIDIA Kepler, 10de:0fc1) is possible"

[1]
https://src.fedoraproject.org/rpms/xorg-x11-server/blob/e3a0a54473c7d63df39467bdf0b093fedb25a962/f/0001-xfree86-use-modesetting-driver-by-default-on-GeForce.patch

> -- 
> Evolution as taught in public schools is, like religion,
>   based on faith, not based on science.
> 
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> 
> Felix Miata

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

Re: Update has been bouncing of Bohdi for months

[Kamil Paral]

On Mon, Dec 16, 2024 at 2:24 AM Ian Laurie via test <
test@lists.fedoraproject.org> wrote:

> Someone who understands the mechanisms needs to take a look at:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-4e960d96d5
>
> It's been submitted to stable about 3 million times but keeps bouncing
> back.  The spam from it is driving me nuts :)
>

I tried to poke people in the #apps:fp.o Matrix channel.
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GK107 10de:0fc1 Kepler regression: black screen when KMS enabled

[Felix Miata]

Felix Miata composed on 2024-12-13 16:25 (UTC-0500):

> https://gitlab.freedesktop.org/drm/nouveau/-/issues/385
> GK107 10de:0fc1 Kepler black screen when KMS enabled
> No local I/O is possible once KMS engages.

> 6.11.11-300.fc41.x86_64 produces the same problem as all other post-6.6 
> kernels.
> 6.6.63 in Tumbleweed is working just dandy. No distros' current kernels 
> behave any
> differently. There's been zero activity in that report other than from 
> myself. Can
> anyone here suggest anything I can do to generate interest (that does not 
> include
> me trying to bisect or build software) in providing a fix? Command line 
> option(s)
> perhaps?

I've updated https://gitlab.freedesktop.org/drm/nouveau/-/issues/385 to indicate
appropriate uses of video= on kernel cmdline can enable normal use of vttys. All
displays are still put into sleep mode or into unsupported mode on X startup, 
but
Ctrl-Alt-Fn succeeds to switch to available vttys.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

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

Re: GK107 10de:0fc1 Kepler regression: black screen when KMS enabled

[Felix Miata]

> schrieb Felix Miata:

>> https://gitlab.freedesktop.org/drm/nouveau/-/issues/385
>> GK107 10de:0fc1 Kepler black screen when KMS enabled
>> No local I/O is possible once KMS engages.

> did you check the 6.13 series from Rawhide yet?

Do you have some special knowledge of change there that should encompass this?

> Caused by a ipu6 driver issue i had tested 6.13.0rc2 from F42 myself, and it 
> works.
> If there is a fix, you will find it in that kernel.

What is "ipu"? Intel® Infrastructure Processing Unit? If yes, does it apply to
NVidia GPUs? I can't fathom a connection. Does 6.13 have some radical change to
KMS/DRM since the initial failure in 6.7 that wasn't yet present in 6.8, 6.9,
6.10, 6.11 or 6.12.4?

# inxi -S
System:
  Host: p5bse Kernel: 6.12.4-200.fc41.x86_64 arch: x86_64 bits: 64
  Desktop: TDE (Trinity) v: R14.1.3 Distro: Fedora Linux 41 (Forty One)
# dmesg | grep -i edid
[   25.724264] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   25.757769] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   25.768783] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   68.010916] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   68.034183] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   76.308493] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   76.319709] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
[   76.330809] nouveau :01:00.0: drm: DDC responded, but no EDID for DVI-D-1
#
This has been the same since 6.7. I can't be more time specific as I didn't have
this GPU when the first of 6.7s appeared.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

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

Re: GK107 10de:0fc1 Kepler regression: black screen when KMS enabled

[Felix Miata]

Sérgio Basto composed on 2024-12-13 19:25 (UTC-0500):

> On Fri, 2024-12-13 at 16:25 -0500, Felix Miata wrote:

>> https://gitlab.freedesktop.org/drm/nouveau/-/issues/385
>> GK107 10de:0fc1 Kepler black screen when KMS enabled
>> No local I/O is possible once KMS engages.

>> 6.11.11-300.fc41.x86_64 produces the same problem as all other post-6.6 
>> kernels.
>> 6.6.63 in Tumbleweed is working just dandy. No distros' current kernels 
>> behave any
>> differently. There's been zero activity in that report other than from 
>> myself. Can
>> anyone here suggest anything I can do to generate interest (that does not 
>> include
>> me trying to bisect or build software) in providing a fix? Command line 
>> option(s)
>> perhaps?

> you can use LTS kernel 
> https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-6.6/

There's no need for the box to work at all. It's a multi- multiboot PC that 
exists
to confirm, detect, or deny bugs only. Having 6.6 available from there is nice, 
to
enable booting 41 without needing nomodeset, for whatever that's worth, so 
thanks
for that:

# inxi -GSaz --vs --za --hostname
inxi 3.3.36-00 (2024-09-04)
System:
  Host: p5bse Kernel: 6.6.64-200.fc41.x86_64 arch: x86_64 bits: 64
compiler: gcc v: 2.43.1-4.fc41 clocksource: tsc avail: hpet,acpi_pm
parameters: ro root=LABEL= ipv6.disable=1 net.ifnames=0 selinux=0
plymouth.enable=0 consoleblank=0 mitigations=off
  Desktop: TDE (Trinity) v: R14.1.3 tk: Qt v: 3.5.0 wm: Twin v: 3.0
with: kicker vt: 7 dm: 1: TDM 2: XDM Distro: Fedora Linux 41 (Forty One)
Graphics:
  Device-1: NVIDIA GK107 [GeForce GT 640] vendor: ZOTAC driver: nouveau
v: kernel non-free: N/A status: unknown device ID pcie: gen: 1
speed: 2.5 GT/s lanes: 16 ports: active: DVI-I-1,HDMI-A-1 empty: DVI-D-1
bus-ID: 01:00.0 chip-ID: 10de:0fc1 class-ID: 0300 temp: 38.0 C
  Display: x11 server: X.Org v: 21.1.14 compositor: Twin v: 3.0 driver: X:
loaded: modesetting alternate: fbdev,vesa dri: nouveau gpu: nouveau
display-ID: :0 screens: 1
  Screen-1: 0 s-res: 2560x2490 s-dpi: 120 s-size: 541x527mm (21.30x20.75")
s-diag: 755mm (29.73")
  Monitor-1: DVI-I-1 pos: top model: Dell P2213 serial:  built: 2013
res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 473x296mm (18.62x11.65")
diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400
  Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: primary,bottom model: Acer K272HUL
serial:  built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2
size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes:
max: 2560x1440 min: 720x400
  API: EGL v: 1.5 hw: drv: nvidia nouveau platforms: device: 0 drv: nouveau
device: 1 drv: swrast gbm: drv: nouveau surfaceless: drv: nouveau x11:
drv: nouveau inactive: wayland
  API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 24.2.8 glx-v: 1.4
direct-render: yes renderer: NVE7 device-ID: 10de:0fc1 memory: 1.93 GiB
unified: no
  API: Vulkan v: 1.3.296 layers: 2 device: 0 type: cpu name: llvmpipe (LLVM
19.1.0 128 bits) driver: N/A device-ID: 10005: surfaces: xcb,xlib
# ls -gGh initram* vmlinuz-6*
-rw--- 1 19M Sep 16 21:18 initramfs-6.10.10-200.fc40.x86_64.img
-rw--- 1 19M Oct  2 01:07 initramfs-6.11.0-63.fc41.x86_64.img
-rw--- 1 18M Dec 12 10:17 initramfs-6.11.11-300.fc41.x86_64.img
-rw--- 1 18M Dec 13 22:43 initramfs-6.6.64-200.fc41.x86_64.img
-rwxr-xr-x 1 16M Sep 11 20:00 vmlinuz-6.10.10-200.fc40
-rwxr-xr-x 1 16M Sep 14 20:00 vmlinuz-6.11.0-63.fc41.x86_64
-rwxr-xr-x 1 16M Dec  4 19:00 vmlinuz-6.11.11-300.fc41.x86_64
-rwxr-xr-x 1 15M Jan 30  2024 vmlinuz-6.6.64-200.fc41.x86_64
#
It's rather weird to see the timestamp on a freshly installed kernel built 4 
days
ago be over 10 months old. :?

> and here [1] it recommend use nvidia-470xx , for Fedora you have it in
> RPMFusion with akmods 

It's FOSS-only here. I never install proprietary drivers on my own Linux PCs.

> [1] 
> https://forum.endeavouros.com/t/nvidia-driver-is-not-loading/59648
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

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

Re: GK107 10de:0fc1 Kepler regression: black screen when KMS enabled

[Neal Gompa]

On Fri, Dec 13, 2024 at 4:25 PM Felix Miata  wrote:
>
> https://gitlab.freedesktop.org/drm/nouveau/-/issues/385
> GK107 10de:0fc1 Kepler black screen when KMS enabled
> No local I/O is possible once KMS engages.
>
> 6.11.11-300.fc41.x86_64 produces the same problem as all other post-6.6 
> kernels.
> 6.6.63 in Tumbleweed is working just dandy. No distros' current kernels 
> behave any
> differently. There's been zero activity in that report other than from 
> myself. Can
> anyone here suggest anything I can do to generate interest (that does not 
> include
> me trying to bisect or build software) in providing a fix? Command line 
> option(s)
> perhaps?

Testing with a Wayland environment (like KDE Plasma Wayland) to see if
it makes a difference would help. Among other things, that can help
pin down whether it's a specific interaction causing the problem or if
it's a more general one.



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

Re: GK107 10de:0fc1 Kepler regression: black screen when KMS enabled

[Sérgio Basto]

On Fri, 2024-12-13 at 16:25 -0500, Felix Miata wrote:
> https://gitlab.freedesktop.org/drm/nouveau/-/issues/385
> GK107 10de:0fc1 Kepler black screen when KMS enabled
> No local I/O is possible once KMS engages.
> 
> 6.11.11-300.fc41.x86_64 produces the same problem as all other post-
> 6.6 kernels.
> 6.6.63 in Tumbleweed is working just dandy. No distros' current
> kernels behave any
> differently. There's been zero activity in that report other than
> from myself. Can
> anyone here suggest anything I can do to generate interest (that does
> not include
> me trying to bisect or build software) in providing a fix? Command
> line option(s)
> perhaps?

you can use LTS kernel 
https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-6.6/

and here [1] it recommend use nvidia-470xx , for Fedora you have it in
RPMFusion with akmods 

[1] 
https://forum.endeavouros.com/t/nvidia-driver-is-not-loading/59648

> -- 
> Evolution as taught in public schools is, like religion,
>   based on faith, not based on science.
> 
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> 
> Felix Miata

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

Re: IPA Migrate test days

[Igor Jagec]

On Mon, 9 Dec 2024 at 12:25, Sumantro Mukherjee  wrote:

> IDM and Fedora QA team are running a test event for testing IPA to IPA 
> migrate feature.

Good stuff.

> The design document sums up the feature well enough[0]. If you are some with 
> experience
> with IPA ; feel free to jump to this test and submit your results[1]

Not yet, but I am willing to get my hands dirty. Is this something
like Active Directory for Linux?

> The wiki has the pre-req [2] ; feel free to reach out to us in case you have 
> any questions!

I got stuck with setting up the IPA servers. Is there an easy way or
template to set up the IPA servers? I asked ChatGPT and Gemini to help
me set this up, but both AI chatbots were not helpful, haha :D

> [0]https://freeipa.readthedocs.io/en/latest/designs/ipa_to_ipa_migration.html
> [1] https://testdays.fedoraproject.org/events/206
> [2]  http://fedoraproject.org/wiki/Test_Day:Test_Day:2024-12-09_IPA_migrate

Is it possible to do this test if you don't have a fully set-up
system? I mean, the users, the permissions, the DNS records... you
can't quite simulate all these unless you have the IPA in action and
now you want to test new stuff.
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fwd: Linux kernel 6.1.3 released

[Luna Jernberg]

Yeah i was too fast with Gmail search sorry for that

Den sön 8 dec. 2024 kl 17:33 skrev Felix Miata :
>
> Adam Williamson composed on 2024-12-08 08:02 (UTC-0800):
>
> > On Fri, 2024-12-06 at 21:57 -0500, Felix Miata wrote:
>
> >> 6.1.2. Are we sure Luna Jernberg is a human able to see and hear and not 
> >> an AI? I
> >> see wacko posting from Luna in various other lists, notably openSUSE, but 
> >> others
> >> as well, including Debian and Mageia IIRC.
>
> > Luna is a real person, yes. Please don't call others "wackos" here,
> > even if you suspect they're AIs.
>
> Clearly the postings referred to were wacko, not any person, in this case
> forwarding an email Luna did not originally author, 23 months old, referring 
> to
> 6.1.x kernels, to not only the test list, but multiple (6?) other recipients.
> --
> Evolution as taught in public schools is, like religion,
> based on faith, not based on science.
>
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
>
> Felix Miata
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fwd: Linux kernel 6.1.3 released

[Felix Miata]

Adam Williamson composed on 2024-12-08 08:02 (UTC-0800):

> On Fri, 2024-12-06 at 21:57 -0500, Felix Miata wrote:

>> 6.1.2. Are we sure Luna Jernberg is a human able to see and hear and not an 
>> AI? I
>> see wacko posting from Luna in various other lists, notably openSUSE, but 
>> others
>> as well, including Debian and Mageia IIRC.

> Luna is a real person, yes. Please don't call others "wackos" here,
> even if you suspect they're AIs.

Clearly the postings referred to were wacko, not any person, in this case
forwarding an email Luna did not originally author, 23 months old, referring to
6.1.x kernels, to not only the test list, but multiple (6?) other recipients.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

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

Re: Fwd: Linux kernel 6.1.3 released

[Adam Williamson]

On Fri, 2024-12-06 at 21:57 -0500, Felix Miata wrote:
> Adam Williamson composed on 2024-12-06 18:20 (UTC-0800):
> 
> > On Fri, 2024-12-06 at 08:46 +0100, Luna Jernberg wrote:
> 
> > > This one works better then 6.1.2 with kernel panics
> > > so you have more to package so we can test when you are awake :)
> 
> > Um, as the date on that email says, 6.1.3 came out in January 2023.
> > That's "six point one point three". The current kernel in Fedora 41 is
> > 6.11.11 - that's "six point eleven point eleven". Kernel 6.12 ("six
> > point twelve") is released upstream but not yet in stable Fedoras.
> > Rawhide is on a pre-release of 6.13 ("six point thirteen"), which is
> > not yet stable. I think you got confused between 6.1.3 and 6.13?
> 
> That email from Luna was a forward, sent to 6 other recipients besides this 
> one,
> originally sent by kd...@linux.kernel.org to 
> linux-kernel-annou...@vger.kernel.org
> in January 2023. It's body includes 3 URLs that include 6.1.3 and another with
> 6.1.2. Are we sure Luna Jernberg is a human able to see and hear and not an 
> AI? I
> see wacko posting from Luna in various other lists, notably openSUSE, but 
> others
> as well, including Debian and Mageia IIRC.

Luna is a real person, yes. Please don't call others "wackos" here,
even if you suspect they're AIs.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Fwd: Linux kernel 6.1.3 released

[Luna Jernberg]

and accidentally answered on the wrong email, i am just pretty burned out

Den sön 8 dec. 2024 kl 09:58 skrev Luna Jernberg :
>
> I am a real human i just did typo the number i did mean 6.12.2 and 6.12.3
>
> Den lör 7 dec. 2024 kl 03:57 skrev Felix Miata :
> >
> > Adam Williamson composed on 2024-12-06 18:20 (UTC-0800):
> >
> > > On Fri, 2024-12-06 at 08:46 +0100, Luna Jernberg wrote:
> >
> > >> This one works better then 6.1.2 with kernel panics
> > >> so you have more to package so we can test when you are awake :)
> >
> > > Um, as the date on that email says, 6.1.3 came out in January 2023.
> > > That's "six point one point three". The current kernel in Fedora 41 is
> > > 6.11.11 - that's "six point eleven point eleven". Kernel 6.12 ("six
> > > point twelve") is released upstream but not yet in stable Fedoras.
> > > Rawhide is on a pre-release of 6.13 ("six point thirteen"), which is
> > > not yet stable. I think you got confused between 6.1.3 and 6.13?
> >
> > That email from Luna was a forward, sent to 6 other recipients besides this 
> > one,
> > originally sent by kd...@linux.kernel.org to 
> > linux-kernel-annou...@vger.kernel.org
> > in January 2023. It's body includes 3 URLs that include 6.1.3 and another 
> > with
> > 6.1.2. Are we sure Luna Jernberg is a human able to see and hear and not an 
> > AI? I
> > see wacko posting from Luna in various other lists, notably openSUSE, but 
> > others
> > as well, including Debian and Mageia IIRC.
> > --
> > Evolution as taught in public schools is, like religion,
> > based on faith, not based on science.
> >
> >  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> >
> > Felix Miata
> > --
> > ___
> > test mailing list -- test@lists.fedoraproject.org
> > To unsubscribe send an email to test-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fwd: Linux kernel 6.1.3 released

[Luna Jernberg]

I am a real human i just did typo the number i did mean 6.12.2 and 6.12.3

Den lör 7 dec. 2024 kl 03:57 skrev Felix Miata :
>
> Adam Williamson composed on 2024-12-06 18:20 (UTC-0800):
>
> > On Fri, 2024-12-06 at 08:46 +0100, Luna Jernberg wrote:
>
> >> This one works better then 6.1.2 with kernel panics
> >> so you have more to package so we can test when you are awake :)
>
> > Um, as the date on that email says, 6.1.3 came out in January 2023.
> > That's "six point one point three". The current kernel in Fedora 41 is
> > 6.11.11 - that's "six point eleven point eleven". Kernel 6.12 ("six
> > point twelve") is released upstream but not yet in stable Fedoras.
> > Rawhide is on a pre-release of 6.13 ("six point thirteen"), which is
> > not yet stable. I think you got confused between 6.1.3 and 6.13?
>
> That email from Luna was a forward, sent to 6 other recipients besides this 
> one,
> originally sent by kd...@linux.kernel.org to 
> linux-kernel-annou...@vger.kernel.org
> in January 2023. It's body includes 3 URLs that include 6.1.3 and another with
> 6.1.2. Are we sure Luna Jernberg is a human able to see and hear and not an 
> AI? I
> see wacko posting from Luna in various other lists, notably openSUSE, but 
> others
> as well, including Debian and Mageia IIRC.
> --
> Evolution as taught in public schools is, like religion,
> based on faith, not based on science.
>
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
>
> Felix Miata
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Adding tests for Fedora Linux on VMware Workstation/Fusion

[Marko Jokinen via test]

i actually have to retract my previous post/answer since today i went on 
testing latest VMware 17.6.1 on F41 KDE and it seems it has improved alot on 
now with hands of Broadcom... installer is simple and easy it shows more 
details on process. the issue comes on VMNET and VMMON sinse those need to be 
signed if using secure boot, but there is fixed the modules as for now those 
are now included so just need to create signing keys and sign and import to 
kernel

what i did is created directory /etc/pki/vmware
sudo openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out 
MOK.der -nodes -days 36500 -subj "/CN=VMware/"

after that on current directory signing VMNET and VMMON
sudo /usr/src/kernels/6.11.10-300.fc41.x86_64/scripts/sign-file sha256 
./MOK.priv ./MOK.der $(modinfo -n vmmon)
sudo /usr/src/kernels/6.11.10-300.fc41.x86_64/scripts/sign-file sha256 
./MOK.priv ./MOK.der $(modinfo -n vmnet)

then import and reboot and sign
sudo mokutil --import MOK.der

the process is much simpler and actually fast and easy now to do
here is also really good broadom guide now how to do stuff install, reinstall 
remove and sign
https://bobcares.com/blog/could-not-open-dev-vmmon-no-such-file-or-directory-vmware/#:~:text=Cause%3A%20VMware%20may%20not%20have,Reinstall%20VMware%20Workstation%20or%20Player.
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fwd: Linux kernel 6.1.3 released

[Felix Miata]

Adam Williamson composed on 2024-12-06 18:20 (UTC-0800):

> On Fri, 2024-12-06 at 08:46 +0100, Luna Jernberg wrote:

>> This one works better then 6.1.2 with kernel panics
>> so you have more to package so we can test when you are awake :)

> Um, as the date on that email says, 6.1.3 came out in January 2023.
> That's "six point one point three". The current kernel in Fedora 41 is
> 6.11.11 - that's "six point eleven point eleven". Kernel 6.12 ("six
> point twelve") is released upstream but not yet in stable Fedoras.
> Rawhide is on a pre-release of 6.13 ("six point thirteen"), which is
> not yet stable. I think you got confused between 6.1.3 and 6.13?

That email from Luna was a forward, sent to 6 other recipients besides this one,
originally sent by kd...@linux.kernel.org to 
linux-kernel-annou...@vger.kernel.org
in January 2023. It's body includes 3 URLs that include 6.1.3 and another with
6.1.2. Are we sure Luna Jernberg is a human able to see and hear and not an AI? 
I
see wacko posting from Luna in various other lists, notably openSUSE, but others
as well, including Debian and Mageia IIRC.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

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

Re: Fwd: Linux kernel 6.1.3 released

[Adam Williamson]

On Fri, 2024-12-06 at 08:46 +0100, Luna Jernberg wrote:
> This one works better then 6.1.2 with kernel panics
> so you have more to package so we can test when you are awake :)

Um, as the date on that email says, 6.1.3 came out in January 2023.
That's "six point one point three". The current kernel in Fedora 41 is
6.11.11 - that's "six point eleven point eleven". Kernel 6.12 ("six
point twelve") is released upstream but not yet in stable Fedoras.
Rawhide is on a pre-release of 6.13 ("six point thirteen"), which is
not yet stable. I think you got confused between 6.1.3 and 6.13?
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: [Test-Announce]Propose to make Fedora WSL Blocking

[Peter Robinson]

On Wed, 4 Dec 2024 at 14:37, Stephen Gallagher  wrote:

> On Tue, Dec 3, 2024 at 10:54 PM Sumantro Mukherjee via test-announce
>  wrote:
> >
> > Hello All,
> >
> > As many of you might know, Fedora WSL is coming to Fedora Linux 42[0].
> > This will be a good starting point for many people and
> > blocking this artifact will help us ensure the experience is not broken.
> >
> > [0]https://fedoraproject.org/wiki/Changes/FedoraWSL
> >
>
>
> I think that needs a Change proposal of its own and I personally would
> prefer not to see that happen prior to F43, so we have at least one
> cycle to work out issues with producing and delivering it before we
> risk blocking the release for it.
>

I completely agree with this sentiment, I think we need to get the artifact
out there and get feedback for at least one release cycle before we move it
to blocking. There's a lot of unknown things here that I don't think are
best going straight to blocking on.

I personally now have the ability to test on WSL on both x86 and aarch64
and was disappointed to find out it wasn't official and will look forward
to this but there's a bunch of work for a bunch of teams so we need to be
pragmatic.

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

Re: [Test-Announce]Propose to make Fedora WSL Blocking

[Adam Williamson]

On Tue, 2024-12-03 at 23:10 -0500, Neal Gompa wrote:
> On Tue, Dec 3, 2024 at 10:54 PM Sumantro Mukherjee via test-announce <
> test-annou...@lists.fedoraproject.org> wrote:
> 
> > Hello All,
> > 
> > As many of you might know, Fedora WSL is coming to Fedora Linux 42[0].
> > This will be a good starting point for many people and
> > blocking this artifact will help us ensure the experience is not broken.
> > 
> > [0]https://fedoraproject.org/wiki/Changes/FedoraWSL
> > 
> > WDY'allT?
> > 
> 
> I'm not entirely opposed to the idea, but I think a reasonable prerequisite
> would be to have a method of automated testing for it. Do we have that for
> Windows?

100% this. I don't have one, and I really don't want to have to come up
with one, which would include figuring out whatever licensing hell is
involved. Does somebody else want to?
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: [Test-Announce]Propose to make Fedora WSL Blocking

[Stephen Gallagher]

On Tue, Dec 3, 2024 at 10:54 PM Sumantro Mukherjee via test-announce
 wrote:
>
> Hello All,
>
> As many of you might know, Fedora WSL is coming to Fedora Linux 42[0].
> This will be a good starting point for many people and
> blocking this artifact will help us ensure the experience is not broken.
>
> [0]https://fedoraproject.org/wiki/Changes/FedoraWSL
>


I think that needs a Change proposal of its own and I personally would
prefer not to see that happen prior to F43, so we have at least one
cycle to work out issues with producing and delivering it before we
risk blocking the release for it.

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

Re: [Test-Announce]Propose to make Fedora WSL Blocking

[Ahmed Almeleh]

I think it is good to have wsl for fedora its long overdue. I dont know
about automated testing on windows but from being qa volunteer I haven't
seen any yet

On Wed, 4 Dec 2024, 04:11 Neal Gompa,  wrote:

> On Tue, Dec 3, 2024 at 10:54 PM Sumantro Mukherjee via test-announce <
> test-annou...@lists.fedoraproject.org> wrote:
>
>> Hello All,
>>
>> As many of you might know, Fedora WSL is coming to Fedora Linux 42[0].
>> This will be a good starting point for many people and
>> blocking this artifact will help us ensure the experience is not broken.
>>
>> [0]https://fedoraproject.org/wiki/Changes/FedoraWSL
>>
>> WDY'allT?
>>
>
> I'm not entirely opposed to the idea, but I think a reasonable
> prerequisite would be to have a method of automated testing for it. Do we
> have that for Windows?
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Test-Announce]Propose to make Fedora WSL Blocking

[Neal Gompa]

On Tue, Dec 3, 2024 at 10:54 PM Sumantro Mukherjee via test-announce <
test-annou...@lists.fedoraproject.org> wrote:

> Hello All,
>
> As many of you might know, Fedora WSL is coming to Fedora Linux 42[0].
> This will be a good starting point for many people and
> blocking this artifact will help us ensure the experience is not broken.
>
> [0]https://fedoraproject.org/wiki/Changes/FedoraWSL
>
> WDY'allT?
>

I'm not entirely opposed to the idea, but I think a reasonable prerequisite
would be to have a method of automated testing for it. Do we have that for
Windows?

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

Re: kernel-6.12.1 breaks VirtualBox hosts by default

[drago01]

On Monday, December 2, 2024, Ian Laurie via test <
test@lists.fedoraproject.org> wrote:

> On 2/12/24 10:37, Scott Dowdle via test wrote:
> versa... but it isn't that difficult for a VirtualBox user to hold back
> on a kernel update until VirtualBox gets updated.  You'll get used to it.
>
> This is a lot more serious that the *routine* host kernel compatibility
> problems that happen in new kernel streams (that I am well used to).
> Those get fixed very promptly.
>
> I would be surprised if this gets fixed any time soon.


Well, there is a workaround which restores the old behavior and the
suggestion from the upstream thread of adding a modprobe snippet to the
virtual box rpm also sounds reasonable.


>
> --
> Ian Laurie
> FAS: nixuser | IRC: nixuser
> TZ: Australia/Sydney
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org
> /en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.or
> g/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infra
> structure/new_issue
>
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: kernel-6.12.1 breaks VirtualBox hosts by default

[Ian Laurie via test]

On 2/12/24 10:37, Scott Dowdle via test wrote:
versa... but it isn't that difficult for a VirtualBox user to hold back
on a kernel update until VirtualBox gets updated.  You'll get used to it.

This is a lot more serious that the *routine* host kernel compatibility
problems that happen in new kernel streams (that I am well used to).
Those get fixed very promptly.

I would be surprised if this gets fixed any time soon.

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

Re: kernel-6.12.1 breaks VirtualBox hosts by default

[Scott Dowdle via test]

On Sunday, December 1st, 2024 at 4:28 PM, Ian Laurie via test 
 wrote:

> On 30/11/24 18:50, Ian Laurie via test wrote:
> Not just me.
> 
> Upstream bug:
> 
> https://www.virtualbox.org/ticket/22248
> 
> Worth reading the kernel thread:
> 
> https://lore.kernel.org/kvm/zwqjusole6swa...@google.com/T/
> 
> This just makes life more difficult for a regular user.
> 
> --
> Ian Laurie
> FAS: nixuser | IRC: nixuser
> TZ: Australia/Sydney

It isn't uncommon for a new kernel to break VirtualBox, requiring it to need to 
be updated.  Should Fedora hold back a newer kernel for third-party software 
they don't ship?  I don't think so.  I use the native hypervisor that has been 
part of the Linux kernel since 2007 which doesn't break because of kernel 
updates.  I realize VirtualBox has some features that KVM doesn't have and vice 
versa... but it isn't that difficult for a VirtualBox user to hold back on a 
kernel update until VirtualBox gets updated.  You'll get used to it.

--
TYL,Scott Dowdle
(406) 750-3319 [cell]
(406) 994-3931 [work]
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: kernel-6.12.1 breaks VirtualBox hosts by default

[Ian Laurie via test]

On 30/11/24 18:50, Ian Laurie via test wrote:

Is this expected behavior with 6.12 or is it somehow specific to me?

Can't we have the module unloaded *by default* and have QEMU/KVM load it
as required?  Then unload it when the last VM exits? Seems useless
having it loaded all the time, especially since it breaks VirtualBox.


Not just me.

Upstream bug:

https://www.virtualbox.org/ticket/22248

Worth reading the kernel thread:

https://lore.kernel.org/kvm/zwqjusole6swa...@google.com/T/

This just makes life more difficult for a regular user.

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

Re: Kernel 6.12 Test Week Invitation

[Luna Jernberg]

Helping out a bit today, and will help out as much as i can during the week
thats coming

Den lör 30 nov. 2024 kl 14:12 skrev Sumantro Mukherjee :

> Hey All,
>
> I would like to invite all of you to participate in the Kernel 6.12
> Test week is happening from 2024-12-01 to 2024-12-08. It's
> fairly simple, head over to the wiki [0] and read in detail about the
> test week and simply run the test case mentioned in[1] and enter your
> results.
>
> As usual, the Fedora QA team will hangout at #fedora-test-...@libera.chat
> for questions and discussion.
>
> [0]http://fedoraproject.org/wiki/Test_Day:2024-12-01_Kernel_6.12_Test_Week
>
> [1]https://testdays.fedoraproject.org/events/205
>
> --
> //sumantro
> Fedora QE
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED 
> --
> ___
> users mailing list -- us...@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: 2024-10-14 - Fedora Quality Meeting - Minutes

[amit kumar]

Reply

On Mon, Nov 25, 2024 at 7:02 AM Adam Williamson 
wrote:

> (editor note: catching up with some old minutes, sorry)
>
> =
> # #meeting:fedoraproject.org: Quality
> =
>
> Meeting started by @adamwill:fedora.im at 2024-10-14 15:00:07
>
>
>
> Meeting summary
> ---
> * TOPIC: Roll Call (@adamwill:fedora.im, 15:00:11)
> * TOPIC: Previous meeting follow-up (@adamwill:fedora.im, 15:03:56)
> * INFO: "adamw to propose rewording of the beta upgrade criterion
> footnote about package sets" - I still did not get to this. I am a
> failure. will get to it soon, I promise (@adamwill:fedora.im, 15:04:50)
> * ACTION: adamw to propose rewording of the beta upgrade criterion
> footnote about package sets (@adamwill:fedora.im, 15:04:53)
> * TOPIC: Fedora 41 status (@adamwill:fedora.im, 15:10:32)
> * INFO: upgrade test day is ongoing -
> https://fedoraproject.org/wiki/Test_Day:2024-10-11_F41_Upgrade_Test_Day
> (@adamwill:fedora.im, 15:36:32)
> * INFO: virtualization and IoT test days happened last week -
> https://fedoraproject.org/wiki/Test_Day:2024-10-11_Virtualization and
> https://fedoraproject.org/wiki/Test_Day:2024-10-07_Fedora_41_IoT_Edition
> (@adamwill:fedora.im, 15:37:17)
> * INFO: virtualization test day had decent participation and a
> couple of bugs filed (@adamwill:fedora.im, 15:45:39)
> * INFO: IoT test week also had some good turnout and covered all
> the test cases (@adamwill:fedora.im, 15:46:03)
> * INFO: CoreOS test day happened at
> https://testdays.fedoraproject.org/events/198 and similarly results
> look good (@adamwill:fedora.im, 15:46:26)
> * TOPIC: Open floor (@adamwill:fedora.im, 15:46:35)
> * INFO: additional testing on the VMware / F41 bug reported at
> https://bugzilla.redhat.com/show_bug.cgi?id=2317048 would be great
> (@adamwill:fedora.im, 15:52:54)
>
> Meeting ended at 2024-10-14 15:55:17
>
> Action items
> 
> * adamw to propose rewording of the beta upgrade criterion footnote
> about package sets
>
> People Present (lines said)
> ---
> * @adamwill:fedora.im (63)
> * @bittin:matrix.org (17)
> * @lruzicka:matrix.org (9)
> * @derekenz:fedora.im (5)
> * @zodbot:fedora.im (4)
> * @conan_kudo:matrix.org (4)
> * @kparal:matrix.org (4)
> * @meetbot:fedora.im (2)
> * @frantisekz:fedora.im (1)
> * @nirik:matrix.scrye.com (1)
> * @amoloney:fedora.im (1)
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
>
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 39 end of life today (2024-11-26)

[Adam Williamson]

On Tue, 2024-11-26 at 08:07 -0800, Adam Williamson wrote:
> Hello all,
> 
> Fedora Linux fN is going end of life for updates and support on
> 2024-11-26 (today!).
> No more updates of any kind, including security updates or security
> announcements, will be available for Fedora Linux 39 after today. All
> the updates of Fedora Linux 39 being pushed to stable will be
> stopped as well.
> 
> Fedora Linux 40 will continue to receive updates until approximately
> one month after the release of Fedora Linux 41.

Correction: Fedora Linux 40 will continue to receive updates until
approximately one month after the release of Fedora Linux **42**.
Apologies for the mistake.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Adding tests for Fedora Linux on VMware Workstation/Fusion

[Derek Enz]

Yes that’s been my experience as well. VMware seemed kinda buggy. Not so
much on Mac OS X.

With Linux it’s one reason why I’ve reverted to Boxes.
It’s been awhile though and I am open to trying whatever we need to do.

Derek Enz

On Fri, Nov 22, 2024 at 7:46 PM Marko Jokinen via test <
test@lists.fedoraproject.org> wrote:

> VMware is a mess on Linux especially if you run secure boot enabled since
> you need to get and sign VMware modules and yhen hope all kernel packages
> matches that it can build it is no worth for VMware to use on Linux since
> there is so much easier ways and faster virt-manager and boxes...
>
> I have to agree on macOS and windows it is highly used one still, but not
> on linux
>
> Sent from Proton Mail Android
>
>
>  Original Message 
> On 11/23/24 00:35, Adam Williamson  wrote:
>
> >  On Fri, 2024-11-22 at 11:53 -0500, Neal Gompa wrote:
> >  > Hey folks,
> >  >
> >  > I'd like to ask if we could consider adding regular tests for running
> >  > Fedora Linux on VMware Workstation and VMware Fusion. Both products
> >  > are now available for use at no-cost for any purpose[1]. Notably,
> >  > VMware Fusion is the only reasonably supportable hypervisor for Fedora
> >  > Linux VMs on Apple Silicon Macs, and the Fedora KDE SIG *explicitly*
> >  > supports this use-case for Fedora KDE.
> >  >
> >  > (The other option is Parallels Desktop, but we don't have Parallels
> >  > guest tools in Fedora, and I'm pretty sure we can't because it uses
> >  > its own kernel modules and might not be fully FOSS.)
> >  >
> >  > Is there a path forward to adding it as a test-case, maybe even with
> >  > some automated testing?
> >
> >  It's already a test case:
> >
> https://fedoraproject.org/wiki/Test_Results:Fedora_42_Rawhide_20241120.n.0_Installation#Virtualization
> >  https://fedoraproject.org/wiki/QA:Testcase_Install_to_VMware
> >
> >  automating it is harder. openQA doesn't have a VMware backend, so we
> >  can't use our existing automation system for it as-is, someone would
> >  have to write one (not me). And even that would only test it on Linux,
> >  which arguably is a bit pointless as I'm not sure most people run
> >  VMware *on Linux*, it is much more commonly used on Windows or macOS.
> >  We have no kind of of framework at all for running automation on
> >  Windows or macOS at present, and I'm not really interested in building
> >  one. If anyone else is, though, fire away :)
> >  --
> >  Adam Williamson (he/him/his)
> >  Fedora QA
> >  Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> >  https://www.happyassassin.net
> >
> >
> >
> >
> >  --
> >  ___
> >  test mailing list -- test@lists.fedoraproject.org
> >  To unsubscribe send an email to test-le...@lists.fedoraproject.org
> >  Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >  List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> >  Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> >
> --
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Adding tests for Fedora Linux on VMware Workstation/Fusion

[Marko Jokinen via test]

VMware is a mess on Linux especially if you run secure boot enabled since you 
need to get and sign VMware modules and yhen hope all kernel packages matches 
that it can build it is no worth for VMware to use on Linux since there is so 
much easier ways and faster virt-manager and boxes...

I have to agree on macOS and windows it is highly used one still, but not on 
linux

Sent from Proton Mail Android


 Original Message 
On 11/23/24 00:35, Adam Williamson  wrote:

>  On Fri, 2024-11-22 at 11:53 -0500, Neal Gompa wrote:
>  > Hey folks,
>  >
>  > I'd like to ask if we could consider adding regular tests for running
>  > Fedora Linux on VMware Workstation and VMware Fusion. Both products
>  > are now available for use at no-cost for any purpose[1]. Notably,
>  > VMware Fusion is the only reasonably supportable hypervisor for Fedora
>  > Linux VMs on Apple Silicon Macs, and the Fedora KDE SIG *explicitly*
>  > supports this use-case for Fedora KDE.
>  >
>  > (The other option is Parallels Desktop, but we don't have Parallels
>  > guest tools in Fedora, and I'm pretty sure we can't because it uses
>  > its own kernel modules and might not be fully FOSS.)
>  >
>  > Is there a path forward to adding it as a test-case, maybe even with
>  > some automated testing?
>  
>  It's already a test case:
>  
> https://fedoraproject.org/wiki/Test_Results:Fedora_42_Rawhide_20241120.n.0_Installation#Virtualization
>  https://fedoraproject.org/wiki/QA:Testcase_Install_to_VMware
>  
>  automating it is harder. openQA doesn't have a VMware backend, so we
>  can't use our existing automation system for it as-is, someone would
>  have to write one (not me). And even that would only test it on Linux,
>  which arguably is a bit pointless as I'm not sure most people run
>  VMware *on Linux*, it is much more commonly used on Windows or macOS.
>  We have no kind of of framework at all for running automation on
>  Windows or macOS at present, and I'm not really interested in building
>  one. If anyone else is, though, fire away :)
>  --
>  Adam Williamson (he/him/his)
>  Fedora QA
>  Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
>  https://www.happyassassin.net
>  
>  
>  
>  
>  --
>  ___
>  test mailing list -- test@lists.fedoraproject.org
>  To unsubscribe send an email to test-le...@lists.fedoraproject.org
>  Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>  Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
>  
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Adding tests for Fedora Linux on VMware Workstation/Fusion

[Adam Williamson]

On Fri, 2024-11-22 at 11:53 -0500, Neal Gompa wrote:
> Hey folks,
> 
> I'd like to ask if we could consider adding regular tests for running
> Fedora Linux on VMware Workstation and VMware Fusion. Both products
> are now available for use at no-cost for any purpose[1]. Notably,
> VMware Fusion is the only reasonably supportable hypervisor for Fedora
> Linux VMs on Apple Silicon Macs, and the Fedora KDE SIG *explicitly*
> supports this use-case for Fedora KDE.
> 
> (The other option is Parallels Desktop, but we don't have Parallels
> guest tools in Fedora, and I'm pretty sure we can't because it uses
> its own kernel modules and might not be fully FOSS.)
> 
> Is there a path forward to adding it as a test-case, maybe even with
> some automated testing?

It's already a test case:
https://fedoraproject.org/wiki/Test_Results:Fedora_42_Rawhide_20241120.n.0_Installation#Virtualization
https://fedoraproject.org/wiki/QA:Testcase_Install_to_VMware

automating it is harder. openQA doesn't have a VMware backend, so we
can't use our existing automation system for it as-is, someone would
have to write one (not me). And even that would only test it on Linux,
which arguably is a bit pointless as I'm not sure most people run
VMware *on Linux*, it is much more commonly used on Windows or macOS.
We have no kind of of framework at all for running automation on
Windows or macOS at present, and I'm not really interested in building
one. If anyone else is, though, fire away :)
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Re: Problem rpm in f42

[Robert McBroom]

Tried to send the output to a file but I've forgotten how to capture error 
messages. Most are related to things that rpmfusion typically provides for 
codecs
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Results for F39 to F41 upgrades tests

[Kamil Paral]

On Mon, Nov 11, 2024 at 7:36 PM Lukas Ruzicka  wrote:

> Hello,
> as promised, I am sending the results of the upgrade tests from F39 to F41.
>
> *Test 1: Upgrade from F39 to F41 using Software*
> When Software is used to perform the upgrade, the mentioned applications,
> Camera and Ptyxis, *do not *get installed on the upgraded system, however
>

That matches my experience, I used gnome-software for my upgrade. We should
figure out what's wrong in gnome-software.
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SOLUTION: dbus start fails and logins are disabled

[George R Goffe via test]

Hi,

Well... I got lucky.

I did 2 things. #1 - add "selinux=0" to the grub boot parameter and "dnf 
reinstall '*dbus*'.


I'm relieved.

Best regards,

George...



On Sunday, November 10, 2024 at 08:40:51 PM PST, George R Goffe 
 wrote: 





Hi,

After a few upgrades over several days, I rebooted my system. 

There were quite a few error messages about dbus... failing.

I can not login now. I have tried other kernels but not the recovery kernel. 
Should I try the recovery too?

I just happened to have a Fedora Live system so I've booted that. It's working 
great.

The system looks "normal". I will be trying "selinux=0" on the cmdline of the 
grub entry. I have also reinstalled any dbus related packages.

A fresh install of Fedora of 
"Fedora-Everything-netinst-x86_64-Rawhide-20241021.n.0.iso" would possibly work 
but that's a LAST resort.

Any help, hints, tips, suggestions would be greatly appreciated.

Best regards,

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

Re: Fedora 41 Beta iio-sensor-proxy stopped working after dnf upgrade

[Patrick Lang via test]

I can confirm this as well on a MS Surface Go 2. It looks like it has also been 
reported in bugzilla. I'll watch these to see if someone submits a 
fix.

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

Cheers,
Patrick

On Sun, Oct 13, 2024 at 04:16:05PM -, manthony...@gmail.com wrote:
> I instaled Fedora 41 Beta workstation on a tablet and initially, 
> iio-sensor-proxy was working to update screen orientation.  The screen 
> rotated automatically as in previous Fedora releases and the screen 
> brightness updated based on the surrounding light levels.
> 
> However, after upgrading via dnf, iio-sensor-proxy no longer updates.  I 
> tried loading the original kernel from the beta install, but it still does 
> not work.
> 
> I installed the beta to another tablet and the same thing occurred.  The beta 
> install works correctly until the dnf upgrade.
> 
> I am new to this and not sure how to work out what part of the dnf update 
> caused this or whether/how this should be reported as a bug.  
> 
> Any help would be appreciated.
> -- 
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> 

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

Re: Problem rpm in f42

[Kamil Paral]

On Fri, Nov 1, 2024 at 8:51 PM Robert McBroom  wrote:

> The following packages have not been able to update for the last two
> weeks. There is no indication what is preventing the updates
>
> Skipping packages with conflicts:
>   libavcodec-free x86_64
> 7.0.2-6.fc42  rawhide  9.5 MiB
>   libavutil-free  x86_64
> 7.0.2-6.fc42  rawhide950.7 KiB
>   libswscale-free x86_64
> 7.0.2-6.fc42  rawhide587.3 KiB
> Skipping packages with broken dependencies:
>   ffmpegthumbsx86_64
> 24.08.2-1.fc42rawhide116.6 KiB
>   gstreamer1-plugin-libav x86_64
> 1.24.8-2.fc42 rawhide427.8 KiB
>   kf5-kfilemetadata   x86_64
> 5.116.0-4.fc42rawhide  1.2 MiB
>   kf6-kfilemetadata   x86_64
> 6.7.0-1.fc42  rawhide  1.3 MiB
>   qt6-qtmultimediax86_64
> 6.8.0-1.fc42  rawhide  3.2 MiB
>

DNF should be listing the dependency issues. Please look at the output, try
to guess the potential cause (if you can't, just pick one package from a
set of packages which are listed to have broken dependencies) and file a
bug in bugzilla for that package. Thanks!
-- 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Problem rpm in f42

[Robert McBroom]

On 11/1/24 5:25 PM, John Mellor wrote:

On 2024-11-01 3:51 p.m., Robert McBroom wrote:
The following packages have not been able to update for the last two 
weeks. There is no indication what is preventing the updates


Skipping packages with conflicts:
 libavcodec-free x86_64 
7.0.2-6.fc42  rawhide  9.5 MiB
 libavutil-free  x86_64 
7.0.2-6.fc42  rawhide    950.7 KiB
 libswscale-free x86_64 
7.0.2-6.fc42  rawhide    587.3 KiB

Skipping packages with broken dependencies:
 ffmpegthumbs    x86_64 
24.08.2-1.fc42    rawhide    116.6 KiB
 gstreamer1-plugin-libav x86_64 
1.24.8-2.fc42 rawhide    427.8 KiB
 kf5-kfilemetadata   x86_64 
5.116.0-4.fc42    rawhide  1.2 MiB
 kf6-kfilemetadata   x86_64 
6.7.0-1.fc42  rawhide  1.3 MiB
 qt6-qtmultimedia    x86_64 
6.8.0-1.fc42  rawhide  3.2 MiB 



Huh?  F42 is not even stable yet.  F41 was just released.  What did 
you expect?



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