Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
On 6/5/24 4:57 PM, Michael J Gruber wrote: Doesn't this prove that it's really a VirtualBox problem, not a Fedora problem? I mean, we still want Fedora to run "everywhere", but the previous discussion indicated a "Fedora problem", and your observations put things into perspective. Virtual machines have to sneak out of their virtual existence and interact with the real world now and then, or they would be pointless, so virtualization is ultimately a fudge. The graphics side of it being the most complex part of the fudge. I agree it is the task of the virtualization engine to keep up with guests developments and keep the fudge working, but Xorg works, and Wayland doesn't, and as a user I don't really care who is at fault. If there were a little more give and take there could be fewer problems. As I understand things, the rush to run Anaconda in Wayland is going to break workflows because many folks DL the Everything-Netinstall ISOs and use it to install anything. Since the move to Wayland is unnecessary, it seems like it could be delayed until Wayland is better supported by the wider ecosystem. Of all things, the installation mechanism should be chosen to be as broadly compatible with as much as possible, and frankly Wayland is currently not that. That said, if my whole life was Linux, I would move to a QEMU/KVM only workflow, but I still have one pesky Win box in my life that I can't get rid of (at work) so VirtualBox for me still makes sense. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
On 6/4/24 6:56 PM, Neal Gompa wrote: The most recent issue is that it's unbearably slow and sometimes suffers serious graphics corruption unless 3D acceleration is turned on. Current best practice appears to be that 3D must be turned off. With it on, nothing works, not even an Xorg session. However, it is fickle, depending on the GNOME stack, there have been times when 3D on was better. With 3D off, and GNOME in an Xorg session, it almost works. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
On 6/4/24 6:34 PM, Hans de Goede wrote: What exactly is not working for you when you run a GNOME Wayland session inside a VirtualBox guest ? Hi Hans, Sadly in my case I suffer the full range of problems, blocky massive empty cursor, Old TV style loss of horizontal sync (video buffer overlap problem apparently) basically I have all the issues outlined below with screen shots shown, topics posted relate to Ubuntu but I have the issue on Fedora (in my case, host is Fedora-Xfce-40 and guest is Fedora-GNOME-40): https://forums.virtualbox.org/viewtopic.php?t=110882 https://forums.virtualbox.org/viewtopic.php?t=110982 https://www.virtualbox.org/ticket/21955 The above links have many other links, but see comment 22 on the ticket. On my recent failed attempt for a GNOME VM under VirtualBox, I converted the VM to QEMU/KVM via a raw image (not a difficult procedure). Under QEMU/KVM the exact same VM install works flawlessly. So it wasn't that my installation went wrong. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
On 6/1/24 1:04 AM, Adam Williamson wrote: On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote: To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general. GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism. One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc). If Anaconda is to be Wayland, my concern is that it may make all DEs uninstallable, even ones like Xfce far removed from Wayland. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Celestia from Fedora due to licensing issues
On 3/21/24 03:36, Mattia Verga via devel wrote: I will be following the procedure for completely removing a package [3], however there are a couple of things that I'd like to ask: I think the Astronomy Labs version of Fedora ships with Celestia so their group will needs a heads up. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
DNF5 ~ how to "remove --oldinstallonly" ?
I have my dnf configured with installonly_limit=6 and now and then find it useful to get rid of old kernels (for example after a move from Fedora n to n+1). I know in the early days of DNF5 you couldn't do this, but can you do it now? -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Does splint work for anyone?
On 2/10/24 05:06, Stephen Smoogen wrote: I was trying out the splint program on some code and found that it doesn't seem to work on any recent release due to changes in various header files I tried using splint many years ago in connection with embedded programming, and even though the GCC based embedded compiler I was using was several major version numbers behind what was natively in Fedora, I found splint to be hopelessly behind the times and utterly unusable. I don't know why it is even packaged in Fedora. I wish I had the skills necessary to bring it up to date but I don't. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Test-Announce] Kernel 6.7 Test Week is underway!
On 2/2/24 10:48, Leigh Scott wrote: Thanks for holding the push to testing, I have managed to patch nvidia 545.xx and 550.xx so 470.xx is also patched. I think it is ok to push the new kernel to testing, the legacy nvidia drivers shouldn't hold up the new kernel. Thank you for doing this fix so quickly, it is greatly appreciated. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planned un-retirements of Pantheon DE related packages
With elementary OS / Pantheon desktop upstream having made progress with supporting newer versions of GNOME (i.e. support for newer versions of libsoup, webkitgtk, gcr, etc.), it is now again possible to build the Pantheon desktop components on Fedora 38+ (after I had retired them from Fedora 37+). I am currently working on package re-reviews and un-retirements. Although I don't use Pantheon, I love one of its components, specifically elementary-code. The ability to open any directory as if it were a project can be really useful sometimes (especially ~/bin full of shell scripts). I am still using elementary-code-6.2.0-2.fc37 which interestingly does actually work on 37/38/39 and even Rawhide. Looking forward to an update. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Are we sticking with exa or moving to eza in EPEL?
I realize exa is still in the EPEL9 repos, was wondering if there is an intention to move to its replacement eza as was done in F39 and F40? Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: KDE Plasma 6 (System Wide)
On 9/18/23 07:48, Kevin Kofler via devel wrote: SDDM was switched to Wayland for F38 and newer. If you want it to use X11, you have to edit /etc/sddm.conf and set: [General] DisplayServer=x11 *sigh* Well... setting DisplayServer=x11 works, the greeter works properly now. Thanks. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: KDE Plasma 6 (System Wide)
On 9/14/23 10:13, Adam Williamson wrote: There is https://bugs.kde.org/show_bug.cgi?id=427060 and https://bugs.kde.org/show_bug.cgi?id=449331 which is marked as a dupe of it. Later comments on 427060 indicate some folks still have issues with this. My personal bugbear that I'd really like fixed is: https://bugzilla.redhat.com/show_bug.cgi?id=2016563 https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/26 I created a VirtualBox KDE instance using: Fedora-Everything-netinst-x86_64-39_Beta-1.1.iso. System was updated with updates-testing enabled. There are problems even before you login. The mouse pointer works in reverse in the greeter, vertical bar over the background, then an arrow pointer when you hover over the password entry area. After logging into a Wayland session the mouse weirdness continues with random (it seems) pointers... sometimes an arrow pointer and sometimes a vertical bar to select text, but not coinciding with where the cursor is. With text in KWrite, and the cursor being an arrow when it should be a vertical bar, there is a big offset, so you end up selecting the text on the line below the line you want. After logging out it was a chore trying to select X11 because the offset was present in the greeter (I don't believe I have experienced that before) and you were trying to go lower than the screen to try and select X11 from the drop-down. Once in the X11 session everything just works like it should. Logging out of X11 and back to the greeter things go weird again. I didn't think the greeter used Wayland? So there may be something else going on. I cannot swear to it, but I don't think I've noticed problems in the greeter before. As Adam posted, the offset problem already has a bug for it. Wayland is certainly unusable in VirtualBox, but now even the greeter has issues, and I think that's newish. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: KDE Plasma 6 (System Wide)
On 9/14/23 09:48, Neal Gompa wrote: On Wed, Sep 13, 2023 at 7:45 PM Ian Laurie wrote: I'm an Xfce user so my care factor is minimal. I've not tried Plasma on Wayland in the 39 branch yet but I do intend to. Would you please report this to bugs.kde.org if it shows up in Fedora 39 KDE Beta? https://bugs.kde.org/enter_bug.cgi?product=kwin=wayland-generic I'll try to do this Saturday my time. I'll also report results here. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: KDE Plasma 6 (System Wide)
On 9/14/23 05:58, František Šumšal wrote: I second this as well. I tried to use Wayland with Plasma, but there's a weird issue where with a multi-monitor setup, switching focus from I have repeatedly tried Plasma on Wayland as VirtualBox guests and it simply doesn't work. There is a weird 10 to 20 pixel offset between the visible mouse pointer and what the GUI thinks is being pointed at... which makes the GUI unusable. I've reported this problem in the deep dark past somewhere but nothing was done about it. I've seen the problem as recently as F38 during its beta period. Plasma on X11 works as expected. I'm an Xfce user so my care factor is minimal. I've not tried Plasma on Wayland in the 39 branch yet but I do intend to. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Can we squeeze coreutils-9.4 into Fedora 39?
On 8/31/23 02:11, David Cantrell wrote: I personally agree that this is enough of a change to warrant consideration for Fedora 39, but I want Fedora QA to weigh in. As per Adam's input I've created [1] and suggested to backport the specific patch as a freeze exception. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2236321 -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Can we squeeze coreutils-9.4 into Fedora 39?
On 8/31/23 05:45, Adam Williamson wrote: well, the question is not so much how useful is *this* change, but what *other* changes does coreutils 9.4 introduce. During Beta freeze, it would be much safer to just backport this specific change. This is clearly not a Beta blocker, but you can propose it as a Beta FE... OK I have filed a BZ [1] and a freeze exception request against it, hopefully I've done it correctly. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2236321 -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Can we squeeze coreutils-9.4 into Fedora 39?
coreutils-9.3 brought changes to the behavior of the -v option which broke some of my automation scripts. Because of this I have been blocking updates to coreutils in Rawhide and Fedora 39. and I'm running coreutils-9.2-4.fc39.x86_64. This change in the -v option has been reverted in 9.4 (released 2023-08-29). From [1]: ** Changes in behavior 'cp -v' and 'mv -v' will no longer output a message for each file skipped due to -i, or -u. Instead they only output this information with --debug. I.e., 'cp -u -v' etc. will have the same verbosity as before coreutils-9.3. If it's too late to get 9.4 into 39, is it possible to locally include this specific reverting patch? [1] https://github.com/coreutils/coreutils/blob/master/NEWS -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Replacing DNF with DNF5: changes reverted and helping steps
On 8/8/23 03:59, Nicola Sella wrote: Hi all, As discussed[1] DNF will not be obsoleted in fedora 39. The side-tag with the reverted changes was merged[2,3] just now. You can now try the new packages by upgrading to the newer version of DNF5 (dnf5-5.1.1-1.fc39) which will not obsolete DNF (dnf-4-16.2-2.fc39) anymore. Note that, if you install the packages from the side-tag, DNF might not be installed because it would be obsoleted by DNF5-5.1.0, from rawhide repositories. Therefore, if you want to upgrade and use DNF < 5 on your rawhide system, here are some steps that should help you. 1. If you intend to install the new packages from the side-tag, you might want to exclude rawhide repositories. You have two options: a. First, upgrade the system to the latest packages in the side-tag: $ dnf5 upgrade \ --best --releasever=39 \ --disablerepo=* \ --enablerepo=side-tag --repofrompath=side-tag,'https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/ <https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/>' Then, install DNF: $ dnf5 install dnf \ --best --releasever=39 \ --disablerepo=* \ --enablerepo=side-tag --repofrompath=side-tag,'https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/ <https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/>' b. You can achieve the same goal in one step: $ dnf5 install "dnf < 5" \ --best --releasever=39 \ --disablerepo=* \ --enablerepo=side-tag --repofrompath=side-tag,'https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/ <https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/>' 2. If you would rather not use the side-tag OR you are updating after the packages are available in rawhide, you should have no issues. The same two options follow: a. Upgrade and install: $ dnf5 upgrade --best $ dnf5 install dnf --best b. Or, with the one-liner: $ dnf5 install "dnf < 5" --best Please, don't hesitate to reach back if you cannot install the newest packages, I think you may need a --nogpgcheck in there to allow it to work. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
On 6/22/23 19:01, Matthew Miller wrote: Sure, but... that's the _opposite_ of the direction things are going. Awesome post. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Test upgrades from F37 to F38 - it will take you just a minute
On 2/24/23 10:17, Ian Laurie wrote: On 2/22/23 20:30, Miroslav Suchý wrote: Do you want to make Fedora 38 better? Please spend 1 minute of your time and try to run: Looked good here, just some downgrades as follows: Downgrading: fwupd x86_64 1.8.10-1.fc38 fwupd-plugin-flashrom x86_64 1.8.10-1.fc38 fwupd-plugin-modem-manager x86_64 1.8.10-1.fc38 fwupd-plugin-uefi-capsule-data x86_64 1.8.10-1.fc38 inxi noarch 3.3.24-2.fc38 mock-core-configs noarch 38.1-1.fc38 Took it a step further, did an actual upgrade on a bare metal system, Fedora 37 Xfce to Fedora 38, worked fine. Dell Precision T5610 2 x Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz (8 cores total) NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1) Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Test upgrades from F37 to F38 - it will take you just a minute
On 2/22/23 20:30, Miroslav Suchý wrote: Do you want to make Fedora 38 better? Please spend 1 minute of your time and try to run: Looked good here, just some downgrades as follows: Downgrading: fwupdx86_64 1.8.10-1.fc38 fwupd-plugin-flashromx86_64 1.8.10-1.fc38 fwupd-plugin-modem-manager x86_64 1.8.10-1.fc38 fwupd-plugin-uefi-capsule-data x86_64 1.8.10-1.fc38 inxi noarch 3.3.24-2.fc38 mock-core-configsnoarch 38.1-1.fc38 Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Hints for manual upgrading from CentOS 8 Stream to CentOS / Alma / Rockey 9
On 2/9/23 07:38, Richard Shaw wrote: I know upgrades are not supported but its for a small home server that really only does two things: For a home server you can use RHEL, the real deal, why mess with downstream rebuilds? Just a thought. Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Rawhide with kernel-6.2 requires VBox SVGA video mode to boot in VirtualBox
I've not been able to boot Rawhide in VirtualBox with any 6.2 kernel. Last good kernel was kernel-6.1.0-65.fc38.x86_64. My host is Fedora 37 all updates applied. Experimentation reveals that I can get my VMs to boot with a 6.2 kernel if I use the old "VBOX SVGA" display setting rather than the "correct" "VMSVGA" setting. The old setting produces a configuration alert with Linux systems (although it does work). This feels like a kernel problem to me rather than a VirtualBox problem at this point. Anyone else seeing this, I can't be the only one? Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 37 compose report: 20221108.n.0 changes
On 11/9/22 01:18, Fedora Rawhide Report wrote: OLD: Fedora-37-20221107.n.0 NEW: Fedora-37-20221108.n.0 [big snip] This seems to have all the gnome fixes, plus a load of KDE fixes, and the 6.0.7 kernel shouldn't this be a release candidate? -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Karma for OpenSSL needed
On 11/2/22 04:22, Dmitry Belyavskiy wrote: Dear colleagues, I've just pushed the updates for OpenSSL fixing 2 CVEs evaluated as HIGH. Could you please check the freshly pushed builds to get necessary karma ASAP? Are we not fixing Fedora 35? It won't be EOL until mid December (delays in 37 pushed it out a few times). -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Qt update and packages rebuild
On 10/4/22 08:16, Germano Massullo wrote: There hasn't been a qt update in CentOS Stream 8 or 9 since May 2022, so you'll have to give more information. I double checked and I found out the origin of my misunderstanding. I wrote everything in this comment https://bugzilla.redhat.com/show_bug.cgi?id=2129662#c8 I guess the issue here is that if a package is in EPEL9, but not in EPEL9-NEXT, and it can install, then "sudo dnf install keepassxc" is going to work just fine, and back when I did it, it did. As a an unrelated issue, running "sudo dnf upgrade" from the command line, as I like to do, in GNOME results in gnome-shell crashing quite often, leaving updates in an indeterminate state and a possibly a corrupted database, so one is forced to use gnome-shell when in GNOME. However gnome-shell doesn't inform you of an updates conflict, so my problem may have dated back to May for all I know. I became aware of the QT conflict when I used the command line to do updates from a virtual console, but the issue could have been there from any time in the past. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
On 9/12/22 22:59, Miroslav Suchý wrote: Do you want to make Fedora 37 better? Please spend 1 minute of your time and try to run: I have updated 5 native systems running Fedora 36 (all running Xfce) to Fedora 37 as follows: (1) ASUS G750JS 1 x Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) NVIDIA Corporation GK104M [GeForce GTX 870M] (rev a1) (2) Dell Precision T5610 2 x Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz (8 cores total) NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1) (3) Dell Precision T3600 Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz (8 cores total) NVIDIA Corporation GF119 [NVS 310] (rev a1) (4) Dell Optiplex 3040 1 x Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz Intel Corporation HD Graphics 530 (rev 06) (5) Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) All working fine. I have one more native system to convert, which is the exact same H/W platform as (5) above (but with less memory), which I will do after release. Upgrades were performed around the time of the updates-testing activation point (long before the beta was released). I recall some non-show-stopping complaints from dnf, but the upgrades happened without a blocking incident and all machines are functioning normally now. Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/16/22 06:36, Hans de Goede wrote: Hi, On 6/15/22 07:01, Ian Laurie wrote: On 6/12/22 14:34, Sérgio Basto wrote: On Sun, 2022-06-12 at 13:59 +1000, Ian Laurie wrote: On 6/12/22 11:20, Ian Laurie wrote: On 6/12/22 09:46, Ian Laurie wrote: On 6/12/22 00:58, Hans de Goede wrote: Hi, On 6/11/22 01:02, Alexander G. M. Smith wrote: On 2022-06-08 15:00, Alexander G. M. Smith wrote: Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? [...] The weird thing is that it works on other CPUs, an AMD Athlon X2 and an Intel 10th generation i5-10500H. Just my Ivy Bridge Intel i7-4820K has the problem. I did try the kernel boot parameter mitigations=off, in case the Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't work. One more data point. It fails on an Intel i5-750 too. Same broken data connections and failed checksums. My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root in a console (thus no networking is between keyboard and computer - pipes often fail). My server snapshot fails to get through the complete dnf upgrade on kernel 5.17.13, works fine if booting the host with the earlier kernel 5.17.11 (using the GRUB boot menu to pick the older OS). So, should we report this to VirtualBox? They seem like the most appropriate people. Kernel people would be a possibility? Found a relevant bug report: https://www.virtualbox.org/ticket/20976 And a forum discussion: https://forums.virtualbox.org/viewtopic.php?f=7=106071 Though they don't know that it only happens on certain CPUs (or motherboards or ?). I'll add some notes about that there. Note the rpmfusion VirtualBox packages now include this fix: https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 See: https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 Which is supposed to fix this. Regards, Hans I'm currently running this version, with the 5.18 fixes, but it's not working with kernels 5.17.12/13 or 14. A person reporting success with 5.18.3 reported not having problems with the 5.17 kernels, so maybe there are multiple issues (has been suggested it may be CPU/chipset related). I have not yet tried it on 5.18 but I certainly will today. Ian If I understand Sérgio's comment #15 correctly, the 5.18 kernel fixes don't address the CPU issues possibly created by CVE-2022-1789 fixes, so there is probably no point in me trying an early 5.18. So the CPU issues are common to both later 5.17 and 5.18. Sadly all my hardware here falls under the broken category: [1] ASUS G750JS 1 x Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) NVIDIA Corporation GK104M [GeForce GTX 870M] (rev a1) Fedora 36 [2] Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) Fedora 36 Since it was going to cost me nothing but time, I tested kernel-5.18.3-200.fc36.x86_64 with my existing VirtualBox-6.1.34-4.fc36.x86_64 (RPMFusion updates-testing) and to my astonishment it seems to be working. On both platforms mentioned above. So maybe my understanding about the CVE fixes was not correct. Or something got fixed between 5.18.2 and 5.18.3 ? Anyway the 5.18.3 Fedora kernel on Koji with the latest VirtualBox from RPMFusion still in testing seems to be working on 2 h/w platforms that were previously failing from 5.17.12. thank you for the feedback , yes you understand me well, but I hadn't made tests with kernel-5.18.x After read this thread this afternoon , I realize that I also have one Intel(R) Core(TM), I have the i5-9300H CPU and I noticed have network issues with kernel-5.17.12. so I downgrade the kernel kernel-5.17.9- 200.fc35.x86_64 and I confirmed that I hadn't the issues with network. So I was also affected by kernel-5.17.12, but just had weird network issues ... So now, I not sure anymore if we have 2 issues or if it all the same i.e. kvm mitigations which was in first place on kernels 5.18, or even if virtualbox kernel-5.18 patch is unrelated. The important for me is kernel-5.18 patch for virtualbox don't have regressions . Sérgio, Now that 5.18.3 & 5.18.4 are working as VirtualBox hosts, we seem to have problems with 5.18.x as a guest. For me, 5.18.x kernels are not seeing the network interface. I am seeing this with 5.18.3 and 5.18.4 in the guest, regardless of the outer host. In fact I am seeing this on both Linux and Windows 10 hosts. This is due the e1000 nic driver accidentally being disabled in the 5.18 kernels. This is fixed in 5.18.4-301 / 5.18.4-201 / 5.18.4-101 Regards, Hans ___ devel mailing list -- devel
Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/12/22 14:34, Sérgio Basto wrote: On Sun, 2022-06-12 at 13:59 +1000, Ian Laurie wrote: On 6/12/22 11:20, Ian Laurie wrote: On 6/12/22 09:46, Ian Laurie wrote: On 6/12/22 00:58, Hans de Goede wrote: Hi, On 6/11/22 01:02, Alexander G. M. Smith wrote: On 2022-06-08 15:00, Alexander G. M. Smith wrote: Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? [...] The weird thing is that it works on other CPUs, an AMD Athlon X2 and an Intel 10th generation i5-10500H. Just my Ivy Bridge Intel i7-4820K has the problem. I did try the kernel boot parameter mitigations=off, in case the Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't work. One more data point. It fails on an Intel i5-750 too. Same broken data connections and failed checksums. My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root in a console (thus no networking is between keyboard and computer - pipes often fail). My server snapshot fails to get through the complete dnf upgrade on kernel 5.17.13, works fine if booting the host with the earlier kernel 5.17.11 (using the GRUB boot menu to pick the older OS). So, should we report this to VirtualBox? They seem like the most appropriate people. Kernel people would be a possibility? Found a relevant bug report: https://www.virtualbox.org/ticket/20976 And a forum discussion: https://forums.virtualbox.org/viewtopic.php?f=7=106071 Though they don't know that it only happens on certain CPUs (or motherboards or ?). I'll add some notes about that there. Note the rpmfusion VirtualBox packages now include this fix: https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 See: https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 Which is supposed to fix this. Regards, Hans I'm currently running this version, with the 5.18 fixes, but it's not working with kernels 5.17.12/13 or 14. A person reporting success with 5.18.3 reported not having problems with the 5.17 kernels, so maybe there are multiple issues (has been suggested it may be CPU/chipset related). I have not yet tried it on 5.18 but I certainly will today. Ian If I understand Sérgio's comment #15 correctly, the 5.18 kernel fixes don't address the CPU issues possibly created by CVE-2022-1789 fixes, so there is probably no point in me trying an early 5.18. So the CPU issues are common to both later 5.17 and 5.18. Sadly all my hardware here falls under the broken category: [1] ASUS G750JS 1 x Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) NVIDIA Corporation GK104M [GeForce GTX 870M] (rev a1) Fedora 36 [2] Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) Fedora 36 Since it was going to cost me nothing but time, I tested kernel-5.18.3-200.fc36.x86_64 with my existing VirtualBox-6.1.34-4.fc36.x86_64 (RPMFusion updates-testing) and to my astonishment it seems to be working. On both platforms mentioned above. So maybe my understanding about the CVE fixes was not correct. Or something got fixed between 5.18.2 and 5.18.3 ? Anyway the 5.18.3 Fedora kernel on Koji with the latest VirtualBox from RPMFusion still in testing seems to be working on 2 h/w platforms that were previously failing from 5.17.12. thank you for the feedback , yes you understand me well, but I hadn't made tests with kernel-5.18.x After read this thread this afternoon , I realize that I also have one Intel(R) Core(TM), I have the i5-9300H CPU and I noticed have network issues with kernel-5.17.12. so I downgrade the kernel kernel-5.17.9- 200.fc35.x86_64 and I confirmed that I hadn't the issues with network. So I was also affected by kernel-5.17.12, but just had weird network issues ... So now, I not sure anymore if we have 2 issues or if it all the same i.e. kvm mitigations which was in first place on kernels 5.18, or even if virtualbox kernel-5.18 patch is unrelated. The important for me is kernel-5.18 patch for virtualbox don't have regressions . Sérgio, Now that 5.18.3 & 5.18.4 are working as VirtualBox hosts, we seem to have problems with 5.18.x as a guest. For me, 5.18.x kernels are not seeing the network interface. I am seeing this with 5.18.3 and 5.18.4 in the guest, regardless of the outer host. In fact I am seeing this on both Linux and Windows 10 hosts. Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-
Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/12/22 11:20, Ian Laurie wrote: On 6/12/22 09:46, Ian Laurie wrote: On 6/12/22 00:58, Hans de Goede wrote: Hi, On 6/11/22 01:02, Alexander G. M. Smith wrote: On 2022-06-08 15:00, Alexander G. M. Smith wrote: Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? [...] The weird thing is that it works on other CPUs, an AMD Athlon X2 and an Intel 10th generation i5-10500H. Just my Ivy Bridge Intel i7-4820K has the problem. I did try the kernel boot parameter mitigations=off, in case the Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't work. One more data point. It fails on an Intel i5-750 too. Same broken data connections and failed checksums. My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root in a console (thus no networking is between keyboard and computer - pipes often fail). My server snapshot fails to get through the complete dnf upgrade on kernel 5.17.13, works fine if booting the host with the earlier kernel 5.17.11 (using the GRUB boot menu to pick the older OS). So, should we report this to VirtualBox? They seem like the most appropriate people. Kernel people would be a possibility? Found a relevant bug report: https://www.virtualbox.org/ticket/20976 And a forum discussion: https://forums.virtualbox.org/viewtopic.php?f=7=106071 Though they don't know that it only happens on certain CPUs (or motherboards or ?). I'll add some notes about that there. Note the rpmfusion VirtualBox packages now include this fix: https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 See: https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 Which is supposed to fix this. Regards, Hans I'm currently running this version, with the 5.18 fixes, but it's not working with kernels 5.17.12/13 or 14. A person reporting success with 5.18.3 reported not having problems with the 5.17 kernels, so maybe there are multiple issues (has been suggested it may be CPU/chipset related). I have not yet tried it on 5.18 but I certainly will today. Ian If I understand Sérgio's comment #15 correctly, the 5.18 kernel fixes don't address the CPU issues possibly created by CVE-2022-1789 fixes, so there is probably no point in me trying an early 5.18. So the CPU issues are common to both later 5.17 and 5.18. Sadly all my hardware here falls under the broken category: [1] ASUS G750JS 1 x Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) NVIDIA Corporation GK104M [GeForce GTX 870M] (rev a1) Fedora 36 [2] Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) Fedora 36 Since it was going to cost me nothing but time, I tested kernel-5.18.3-200.fc36.x86_64 with my existing VirtualBox-6.1.34-4.fc36.x86_64 (RPMFusion updates-testing) and to my astonishment it seems to be working. On both platforms mentioned above. So maybe my understanding about the CVE fixes was not correct. Or something got fixed between 5.18.2 and 5.18.3 ? Anyway the 5.18.3 Fedora kernel on Koji with the latest VirtualBox from RPMFusion still in testing seems to be working on 2 h/w platforms that were previously failing from 5.17.12. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/12/22 09:46, Ian Laurie wrote: On 6/12/22 00:58, Hans de Goede wrote: Hi, On 6/11/22 01:02, Alexander G. M. Smith wrote: On 2022-06-08 15:00, Alexander G. M. Smith wrote: Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? [...] The weird thing is that it works on other CPUs, an AMD Athlon X2 and an Intel 10th generation i5-10500H. Just my Ivy Bridge Intel i7-4820K has the problem. I did try the kernel boot parameter mitigations=off, in case the Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't work. One more data point. It fails on an Intel i5-750 too. Same broken data connections and failed checksums. My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root in a console (thus no networking is between keyboard and computer - pipes often fail). My server snapshot fails to get through the complete dnf upgrade on kernel 5.17.13, works fine if booting the host with the earlier kernel 5.17.11 (using the GRUB boot menu to pick the older OS). So, should we report this to VirtualBox? They seem like the most appropriate people. Kernel people would be a possibility? Found a relevant bug report: https://www.virtualbox.org/ticket/20976 And a forum discussion: https://forums.virtualbox.org/viewtopic.php?f=7=106071 Though they don't know that it only happens on certain CPUs (or motherboards or ?). I'll add some notes about that there. Note the rpmfusion VirtualBox packages now include this fix: https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 See: https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 Which is supposed to fix this. Regards, Hans I'm currently running this version, with the 5.18 fixes, but it's not working with kernels 5.17.12/13 or 14. A person reporting success with 5.18.3 reported not having problems with the 5.17 kernels, so maybe there are multiple issues (has been suggested it may be CPU/chipset related). I have not yet tried it on 5.18 but I certainly will today. Ian If I understand Sérgio's comment #15 correctly, the 5.18 kernel fixes don't address the CPU issues possibly created by CVE-2022-1789 fixes, so there is probably no point in me trying an early 5.18. So the CPU issues are common to both later 5.17 and 5.18. Sadly all my hardware here falls under the broken category: [1] ASUS G750JS 1 x Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) NVIDIA Corporation GK104M [GeForce GTX 870M] (rev a1) Fedora 36 [2] Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) Fedora 36 -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/12/22 00:58, Hans de Goede wrote: Hi, On 6/11/22 01:02, Alexander G. M. Smith wrote: On 2022-06-08 15:00, Alexander G. M. Smith wrote: Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? [...] The weird thing is that it works on other CPUs, an AMD Athlon X2 and an Intel 10th generation i5-10500H. Just my Ivy Bridge Intel i7-4820K has the problem. I did try the kernel boot parameter mitigations=off, in case the Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't work. One more data point. It fails on an Intel i5-750 too. Same broken data connections and failed checksums. My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root in a console (thus no networking is between keyboard and computer - pipes often fail). My server snapshot fails to get through the complete dnf upgrade on kernel 5.17.13, works fine if booting the host with the earlier kernel 5.17.11 (using the GRUB boot menu to pick the older OS). So, should we report this to VirtualBox? They seem like the most appropriate people. Kernel people would be a possibility? Found a relevant bug report: https://www.virtualbox.org/ticket/20976 And a forum discussion: https://forums.virtualbox.org/viewtopic.php?f=7=106071 Though they don't know that it only happens on certain CPUs (or motherboards or ?). I'll add some notes about that there. Note the rpmfusion VirtualBox packages now include this fix: https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 See: https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 Which is supposed to fix this. Regards, Hans I'm currently running this version, with the 5.18 fixes, but it's not working with kernels 5.17.12/13 or 14. A person reporting success with 5.18.3 reported not having problems with the 5.17 kernels, so maybe there are multiple issues (has been suggested it may be CPU/chipset related). I have not yet tried it on 5.18 but I certainly will today. Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/6/22 20:25, Paul Black via devel wrote: On Sat, 4 Jun 2022 at 05:17, Ian Laurie wrote: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? I do and on two different machines (one a Lubuntu guest and the other with CentOS 7). 5.17.11 works fine on both. I tried 6.1.35 which has fixes for 5.18 - https://www.virtualbox.org/ticket/20914 - but that was no different. With 6.1.97, the problem seems harder to trigger but not impossible. Problem persists with 5.17.13, for VirtualBox users seems the last usable kernel is 5.17.11. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/4/22 14:17, Ian Laurie wrote: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? When I first started to see problems on my first host I blamed my SSD drive, memory etc until I noticed the same problems on another host system. The 2 hosts are running very different h/w (one is an ASUS laptop the other an Intel NUC). Long story short I can fix all the problem on both hosts by booting kernel-5.15.11. Weirdness examples... (1) If you boot Fedora 36 Cinnamon guest, login, launch a terminal and just drag it around the screen... Cinnamon crashes. Sometimes the terminal accepts text, sometimes not requiring the VM to be terminated the nasty way. (2) GNOME... similar to above but you get knocked back to the greeter. (3) Xfce... if you run updates, a lot of the downloads have hashes that don't match, requiring re-download. This happens in Cinnamon also. (4) Any GUI... if you run TOR browser it crashes quickly with error 139 usually, or randomly some other error. I am not blaming the kernel, the issue could be a kernel change VirtualBox isn't compatible with. But since I have this on 2 host was wondering if others are already some way along in working out the problem. Sorry, typo, should be "I can fix all the problems on both hosts by booting kernel-5.17.11". -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
VirtualBox and HOST kernel-5.17.12 weirdness
Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? When I first started to see problems on my first host I blamed my SSD drive, memory etc until I noticed the same problems on another host system. The 2 hosts are running very different h/w (one is an ASUS laptop the other an Intel NUC). Long story short I can fix all the problem on both hosts by booting kernel-5.15.11. Weirdness examples... (1) If you boot Fedora 36 Cinnamon guest, login, launch a terminal and just drag it around the screen... Cinnamon crashes. Sometimes the terminal accepts text, sometimes not requiring the VM to be terminated the nasty way. (2) GNOME... similar to above but you get knocked back to the greeter. (3) Xfce... if you run updates, a lot of the downloads have hashes that don't match, requiring re-download. This happens in Cinnamon also. (4) Any GUI... if you run TOR browser it crashes quickly with error 139 usually, or randomly some other error. I am not blaming the kernel, the issue could be a kernel change VirtualBox isn't compatible with. But since I have this on 2 host was wondering if others are already some way along in working out the problem. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possible regression in GNOME in Fedora 36 Branched 20220401.n.0
On 4/4/22 10:09, Brandon Nielsen via devel wrote: On 4/3/22 6:45 PM, Ian Laurie wrote: I noticed in VirtualBox with GNOME and 20220401.n.0 that if I resized the VM window when logged into GNOME it slammed me back to the greeter, apparently without killing my login session. I still had a VM from a week ago based on the 1.2 cut, but it was fully updated about a week ago. This VM did not exhibit this issue, but after running latest updates today, it did. I don't know how important VirtualBox is in the grand scheme of things, and don't have an easy way to test this quickly in QEMU/KVM. But if someone else could check this out and can confirm the same, then we need a BZ ticket for it I think. I logged this as a warning for now: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Installation I'm pretty sure I have seen the same in Gnome Boxes, but I haven't had a chance to look into it. It doesn't seem to happen every time. I've done some playing and it looks like it is the first resize after the first login after a boot causes it. After that it doesn't seem to happen (or it is very infrequent if it does). -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possible regression in GNOME in Fedora 36 Branched 20220401.n.0
On 4/4/22 10:00, Samuel Sieb wrote: On 4/3/22 16:45, Ian Laurie wrote: I noticed in VirtualBox with GNOME and 20220401.n.0 that if I resized the VM window when logged into GNOME it slammed me back to the greeter, apparently without killing my login session. What video device does VirtualBox provide to the OS? That machine is at another location, but I am 99% sure it would be VMSVGA with 3D Acceleration turned off (which is the default). I believe VMSVGA emulates a VMware SVGA graphics device. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Possible regression in GNOME in Fedora 36 Branched 20220401.n.0
I noticed in VirtualBox with GNOME and 20220401.n.0 that if I resized the VM window when logged into GNOME it slammed me back to the greeter, apparently without killing my login session. I still had a VM from a week ago based on the 1.2 cut, but it was fully updated about a week ago. This VM did not exhibit this issue, but after running latest updates today, it did. I don't know how important VirtualBox is in the grand scheme of things, and don't have an easy way to test this quickly in QEMU/KVM. But if someone else could check this out and can confirm the same, then we need a BZ ticket for it I think. I logged this as a warning for now: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Installation -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: slowing down the stalled request process
On 3/31/22 02:43, Gary Buhrmaster wrote: [snip] (*) And while a month seems better, I also see that timeframe being frustrating to others who want to use those packages, or to build dependent packages. No great answers. This comment is only loosely related to this thread, but as just an end user I would rather get a "no can do" or a "can do later" on an EPEL request rather than no response at all. I have two EPEL 9 requests outstanding with no response now for a week short of 4 months. Both packages are in EPEL 8 so I considered the requests very reasonable. I can understand that RHEL 9 changes may have introduced "difficulties" but some response, any response, would be nice. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
On 3/16/22 01:13, Vitaly Zaitsev via devel wrote: On 15/03/2022 01:25, Ian Laurie wrote: Sadly it's not able to boot graphically, but I think the issue is with my RPMFusion NVIDIA drivers. I can login fine to a virtual console however, and lightdm is running, just not working. The startx command also fails. 1. You need to disable UEFI Secure Boot or configure akmods to automatically sign all built kmods (no documentation available yet). 2. On 470xx drivers branch you must disable Wayland on GDM (Fedora 36 system-wide change). NVIDIA support Wayland only on 495.xx branch or newer. As an 470.xx NVIDIA drivers maintainer, I think I should disable Wayland support on our side during the package installation. Thanks for that info. I'm running Xfce so I have lightdm not gdm. In my case it was UEFI enabled in the BIOS, but this would have been the case with fc35 as well so I'm a bit perplexed why previously with Fedora 35 it "appeared" to work but failed miserably in Fedora 36. Also after the upgrade to 36, I was able to get graphics by booting the last 35 kernel. Maybe the NVIDIA drivers were never working as such before, but somehow it was gracefully "falling back" to default drivers with the old kernel but not the new one? No idea what was happening. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
On 3/12/22 04:43, Miroslav Suchý wrote: Do you want to make Fedora 36 better? Please spend 1 minute of your time and try to run: I've done 2 upgrades from 35 -> 36 (real, not tests) on native systems. On one, as explained earlier in this thread , I had to migrate VirtualBox from the Oracle version to the RPM Fusion version, and also ditch the RPM Fusion NVIDIA drivers which were preventing a boot to a graphical greeter (and also breaking the startx command), presumably because of a comparability issue with the 5.17 kernel. On the second system it just worked without fiddling. The systems were as follows: [1] Dell Precision T5610 2 x Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz (8 cores total) NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1) [2] Dell Optiplex 3040 1 x Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz Intel Corporation HD Graphics 530 (rev 06) Both systems are relatively legacy unfortunately, but still looking good here. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
On 3/15/22 11:25, Ian Laurie wrote: On 3/14/22 20:55, Vitaly Zaitsev via devel wrote: On 14/03/2022 10:49, Ian Laurie wrote: Yeah I'm thinking I should, and not just because of this. Mainly for on-time kernel support. Also, since Fedora 36 the NVIDIA and VirtualBox kmods can be automatically signed after the build to support UEFI Secure Boot. I decided to go for it on my server/workstation at work and upgrade to 36 (after moving to RPMFusion's VirtualBox). Sadly it's not able to boot graphically, but I think the issue is with my RPMFusion NVIDIA drivers. I can login fine to a virtual console however, and lightdm is running, just not working. The startx command also fails. If I boot my last fc35 kernel-5.16.14-200.fc35.x86_64 everything works with the GUI.. Getting rid of the NVIDIA stuff has fixed things for now, I can boot graphically with the fc36 kernel. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
On 3/14/22 20:55, Vitaly Zaitsev via devel wrote: On 14/03/2022 10:49, Ian Laurie wrote: Yeah I'm thinking I should, and not just because of this. Mainly for on-time kernel support. Also, since Fedora 36 the NVIDIA and VirtualBox kmods can be automatically signed after the build to support UEFI Secure Boot. I decided to go for it on my server/workstation at work and upgrade to 36 (after moving to RPMFusion's VirtualBox). Sadly it's not able to boot graphically, but I think the issue is with my RPMFusion NVIDIA drivers. I can login fine to a virtual console however, and lightdm is running, just not working. The startx command also fails. If I boot my last fc35 kernel-5.16.14-200.fc35.x86_64 everything works with the GUI.. Welcome to zuke Running Fedora release 36 (Thirty Six) kernel-5.16.14-200.fc35.x86_64 #1 SMP PREEMPT Fri Mar 11 20:31:18 UTC 2022 zuke$ rpm -qa | grep nvidia kmod-nvidia-470xx-5.16.10-200.fc35.x86_64-470.103.01-1.fc35.x86_64 kmod-nvidia-470xx-5.16.11-200.fc35.x86_64-470.103.01-1.fc35.x86_64 kmod-nvidia-470xx-5.16.12-200.fc35.x86_64-470.103.01-1.fc35.x86_64 kmod-nvidia-470xx-5.16.13-200.fc35.x86_64-470.103.01-1.fc35.x86_64 xorg-x11-drv-nvidia-470xx-kmodsrc-470.103.01-3.fc36.x86_64 xorg-x11-drv-nvidia-470xx-libs-470.103.01-3.fc36.x86_64 akmod-nvidia-470xx-470.103.01-2.fc36.x86_64 nvidia-settings-470xx-470.103.01-2.fc36.x86_64 xorg-x11-drv-nvidia-470xx-470.103.01-3.fc36.x86_64 kmod-nvidia-470xx-5.17.0-0.rc7.116.fc36.x86_64-470.103.01-2.fc36.x86_64 kmod-nvidia-470xx-5.16.14-200.fc35.x86_64-470.103.01-2.fc36.x86_64 zuke$ -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
On 3/14/22 20:55, Vitaly Zaitsev via devel wrote: On 14/03/2022 10:49, Ian Laurie wrote: Yeah I'm thinking I should, and not just because of this. Mainly for on-time kernel support. Also, since Fedora 36 the NVIDIA and VirtualBox kmods can be automatically signed after the build to support UEFI Secure Boot. Yup. Consider it done. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
On 3/14/22 19:15, Vitaly Zaitsev via devel wrote: On 14/03/2022 04:39, Ian Laurie wrote: Problem: package VirtualBox-6.1-6.1.32_149290_fedora33-1.x86_64 requires libvpx.so.6()(64bit), but none of the providers can be installed Use VirtualBox from the RPM Fusion repository. Yeah I'm thinking I should, and not just because of this. Mainly for on-time kernel support. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
On 3/12/22 04:43, Miroslav Suchý wrote: dnf --releasever=36 --setopt=module_platform_id=platform:f36 \ --enablerepo=updates-testing \ $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \ --assumeno distro-sync For me the only error I received was: Error: Problem: package VirtualBox-6.1-6.1.32_149290_fedora33-1.x86_64 requires libvpx.so.6()(64bit), but none of the providers can be installed - libvpx-1.10.0-2.fc35.x86_64 does not belong to a distupgrade repository - problem with installed package VirtualBox-6.1-6.1.32_149290_fedora33-1.x86_64 (try to add '--skip-broken' to skip uninstallable packages) -- Ian Laurie ilau...@bigpond.net.au ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 cryptsetup fails to mount veracrypt volume with kernel 5.11.3, worked in 5.11.2
Just FYI kernel 5.11.5 still doesn't work for me, 5.11.2 does work. Didn't check 5.11.4 however. On 3/10/21 7:50 AM, Ian Laurie wrote: Thanks Milan, turns out our generated passphrase is exactly 64 bytes long. If your passphrase is longer than 63 characters, please read https://gitlab.com/cryptsetup/cryptsetup/-/issues/627 (And try 5.11.4 kernel.) If not, please report this upstream (or to bugzilla) with more info. Milan -- Ian Laurie ilau...@bigpond.net.au ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 cryptsetup fails to mount veracrypt volume with kernel 5.11.3, worked in 5.11.2
Thanks Milan, turns out our generated passphrase is exactly 64 bytes long. If your passphrase is longer than 63 characters, please read https://gitlab.com/cryptsetup/cryptsetup/-/issues/627 (And try 5.11.4 kernel.) If not, please report this upstream (or to bugzilla) with more info. Milan -- Ian Laurie ilau...@bigpond.net.au ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 34 cryptsetup fails to mount veracrypt volume with kernel 5.11.3, worked in 5.11.2
Fedora 34 with latest updates (kernel-5.11.3-300.fc34.x86_64) won't mount Veracrypt volumes. I can boot with the previous kernel 5.11.2 and it works fine. kernel-5.11.3-300.fc34.x86_64 cryptsetup-2.3.4-2.fc34.x86_64 Commands I'm using are: sudo cryptsetup open /dev/sdb1 vcvolume --type tcrypt --veracrypt --tcrypt-hidden sudo mount /dev/mapper/vcvolume $HOME/secure If I install and use Veracrypt I can mount the volume on 5.11.3 (presumably because it's not using the kernel mechanisms to do it). -- Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unable to install using Fedora-Everything-netinst-x86_64-34-20210213.n.0.iso
Sorry, fixed, I'll send just plain text. Ian On 15/02/2021 5:18 am, Kevin Fenzi wrote: On Sun, Feb 14, 2021 at 12:24:12PM +1100, Ian Laurie wrote: Hey Ian... would it be possible for you to adjust your mail client to send text and html instead of just html? Many on this list expect the text part of emails to be readable. Thanks. ;) As for the perf error, there was a thread on it on the test list: https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/SXMEEBXPIYXEMNZKJO3STBLW6MKK4SWA/ It should get fixed tomorrow. Thanks for testing things! kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Ian Laurie ilau...@bigpond.net.au ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unable to install using Fedora-Everything-netinst-x86_64-34-20210213.n.0.iso
Tried KDE. Part way through the installation got the following
error:
"The following error occurred while installing the payload. This is
a fatal error and installation will be aborted.
DNF error:Error in POSTIN scriptlet in rpm package
xorg-x11-fonts-ISO8859-1-100dpi"
Ian
On 14/02/2021 1:29 pm, Ian Laurie
wrote:
It looks like the perf-5.11.0-0.rc7 dependency issue was caused by
selecting the "C Development Tools and Libraries" option on the
right side, so presumably MATE would have worked without that
selected.
--
Ian
On 14/02/2021 12:24 pm, Ian Laurie
wrote:
I tried testing out
Fedora-Everything-netinst-x86_64-34-20210213.n.0.iso with an
Xfce and MATE install, both failed.
I've attached screen shots of the error my software selection
gave me for each attempt.
--
Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
Ian Laurie
ilau...@bigpond.net.au
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Unable to install using Fedora-Everything-netinst-x86_64-34-20210213.n.0.iso
It looks like the perf-5.11.0-0.rc7 dependency issue was caused by selecting the "C Development Tools and Libraries" option on the right side, so presumably MATE would have worked without that selected. -- Ian On 14/02/2021 12:24 pm, Ian Laurie wrote: I tried testing out Fedora-Everything-netinst-x86_64-34-20210213.n.0.iso with an Xfce and MATE install, both failed. I've attached screen shots of the error my software selection gave me for each attempt. -- Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Unable to install using Fedora-Everything-netinst-x86_64-34-20210213.n.0.iso
I tried testing out Fedora-Everything-netinst-x86_64-34-20210213.n.0.iso with an Xfce and MATE install, both failed. I've attached screen shots of the error my software selection gave me for each attempt. -- Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rawhide hangs booting 5.11.0-rc2
I've managed to find and fix the bug which is causing this today, and I have posted a patch fixing this upstream, so hopefully the fix will make 5.11-rc4 (otherwise it should be in -rc5). No need to file a bug and I suggest just sticking with 5.10 until this is fixed in the 5.11 rc-s. Regards, Hans Hi Hans, I did file a bug report against rc2 but I suspect it may be a different issue, most of the crashes that appeared in the abrt mechanism were not reportable. FWIW here it is: https://bugzilla.redhat.com/show_bug.cgi?id=1914598 But I think it's a different issue. -- Ian Laurie ilau...@bigpond.net.au ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Rawhide hangs booting 5.11.0-rc2
I just updated a VirtualBox Rawhide guest with latest updates which included the 5.11.0-rc2 kernel and the system hangs on boot (pic attached). The system was updated a few days ago so was reasonably up to date before today. Booting the previous kernel 5.10.0-rc6 still works OK. In case something weird happened in the update, I reverted to a backed up copy of the vm (also reasonably up to date) and updated kernel* and rebooted with the exact same results. Is anyone else seeing this problem with VirtualBox guests? -- Ian Laurie ilau...@bigpond.net.au ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
