@adamw@fosstodon.org avatar

adamw

@adamw@fosstodon.org

Fedora QA team lead. If Fedora isn't working, it's probably my fault! he/him/his

This profile is from a federated server and may be incomplete. Browse more on the original instance.

mcdanlj, to fedora
@mcdanlj@social.makerforums.info avatar

I'm on 40, and I'm now seeing a lot of "No video with supported format and MIME type found" errors.

I don't have mozilla-openh264 installed, so I guess that might make sense? Let's fix that...

# rpm-ostree install mozilla-openh264<br></br>...<br></br>error: Could not depsolve transaction; 1 problem detected:<br></br> Problem: package noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from @System conflicts with openh264 provided by openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264<br></br>  - package openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264 obsoletes noopenh264 < 1:0 provided by noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from @System<br></br>  - package mozilla-openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264 requires openh264(x86-64) = 2.4.0-2.fc40, but none of the providers can be installed<br></br>  - conflicting requests<br></br># rpm -qa | grep noopenh264<br></br>noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64<br></br># rpm-ostree install --uninstall noopenh264 mozilla-openh264<br></br>error: Package/capability 'noopenh264' is not currently requested<br></br>

There's clearly something I don't understand here. I don't know how noopenh264 is installed but not requested and still causes a conflict. I must be alone in having this problem based on lack of bugs that I can find in RH's bugzilla.

I don't think I saw this problem on Silverblue 39, but I was using that for only a few days before rebasing on 40, and was previously on my "classic" Fedora 39 installation where it definitely wasn't showing up with the rpmfusion packages installed.

adamw,
@adamw@fosstodon.org avatar

@mcdanlj we're aware of this, but it's awkward - https://pagure.io/workstation-ostree-config/pull-request/508 . this kind of awkwardness is a lot of the reason the atomic desktops still aren't more prominently pushed yet, we know there are still some awkward edges to sand off.

adamw,
@adamw@fosstodon.org avatar

@mcdanlj @garrett @notting that's an interesting idea, not sure I've heard it floated before...not sure who to pass it on to, maybe mcatanzaro or @siosm ?

dwarf, to KDE
@dwarf@borg.social avatar

Hmm. It seems I ran into an issue with Fedora 40 and KDE 6 after today's update. Am I the only person with this issue?

When I run systemsettings, I get the following error:

$ systemsettings
systemsettings: symbol lookup error: /lib64/libKF6KCMUtils.so.6: undefined symbol: _ZN32KCategorizedSortFilterProxyModel16staticMetaObjectE

I guess it could be related to the following?:

Problem 1: package telegram-desktop-4.16.8-1.fc40.x86_64 requires libQt6Core.so.6(Qt_6.6_PRIVATE_API)(64bit), but none of the providers can be installed
  - package telegram-desktop-4.16.8-1.fc40.x86_64 requires qt6-qtbase(x86-64) = 6.6.2, but none of the providers can be installed
  - cannot install both qt6-qtbase-6.6.2-7.fc40.x86_64 and qt6-qtbase-6.7.0-3.fc40.x86_64
  - cannot install the best update candidate for package telegram-desktop-4.16.8-1.fc40.x86_64
  - cannot install the best update candidate for package qt6-qtbase-6.6.2-7.fc40.x86_64
 Problem 2: problem with installed package 
  - package telegram-desktop-4.16.8-1.fc40.x86_64 requires libQt6Gui.so.6(Qt_6.6_PRIVATE_API)(64bit), but none of the providers can be installed
  - package telegram-desktop-4.16.8-1.fc40.x86_64 requires libQt6Widgets.so.6(Qt_6.6_PRIVATE_API)(64bit), but none of the providers can be installed
  - cannot install both qt6-qtbase-gui-6.6.2-7.fc40.x86_64 and qt6-qtbase-gui-6.7.0-3.fc40.x86_64
  - cannot install the best update candidate for package qt6-qtbase-gui-6.6.2-7.fc40.x86_64

adamw,
@adamw@fosstodon.org avatar

@dwarf telegram-desktop appears to come from rpmfusion; it looks like it has not been rebuilt for qt 6.7, which is the current version in Fedora 40. this should be reported as a bug at https://bugzilla.rpmfusion.org/ if it is not already.

where did you see that error message? was it related to upgrade from f39 to f40 with telegram-desktop installed? if so it's possible that resulted in an incomplete upgrade, yes. try removing telegram-desktop and doing a system update.

adamw,
@adamw@fosstodon.org avatar

@dwarf it looks like qt 6.7 only recently went stable as part of https://bodhi.fedoraproject.org/updates/FEDORA-2024-c9a2438d21 . so I guess maybe that update got incompletely applied on your system because of telegram-desktop. same advice applies, remove telegram-desktop and run another system update. when telegram-desktop is rebuilt in rpmfusion you can reinstall it, or just use a flatpak as you said. sorry for the trouble!

bluca, to random
@bluca@fosstodon.org avatar

v256~rc1 is out! You know the drill, download it, run it, find all the bugs and report them - possibly to somebody else, I'll be at the nearest pub

https://github.com/systemd/systemd/releases/tag/v256-rc1

adamw,
@adamw@fosstodon.org avatar
adamw,
@adamw@fosstodon.org avatar

@bluca @pid_eins well, I think there are two problems, but it's the missing kmod library that breaks boot 100% of the time. the problem with dracut's hook directory being read-only is a real thing, I'm pretty sure, but it doesn't seem to prevent boot, at least on a simple VM install (I can certainly imagine it might do so in other cases). edit: I filed https://github.com/systemd/systemd/issues/32511 for the read-only hooks issue.

cassidy, (edited ) to fedora
@cassidy@blaede.family avatar

TIL Fedora is packaging a web browser app I developed for elementary OS, stopped updating over three years ago, and marked as end-of-life two years ago—yet it happily shows up in Fedora 40 if you search my name. It crashes on launch, so it doesn’t even work…

WHY??

Edit: I guess the package is being EOL'd in Fedora due to it no longer building and this thread, huzzah! My recommendation to distros: don’t package random apps and then not maintain them/communicate with upstream.

adamw,
@adamw@fosstodon.org avatar

@cassidy because it's packaged by a contributor who has not orphaned it, and it was successfully built in all mass rebuilds up to f39.

it failed the f40 mass rebuild, which starts a kind of clock which will eventually get it kicked out if nobody fixes it, but only somewhere around the f43 cycle. per https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ , this can be sped up substantially by "any interested party" by following steps 3, 4 and 5 on bug https://bugzilla.redhat.com/show_bug.cgi?id=2261079 , so you might want to do that.

adamw,
@adamw@fosstodon.org avatar

@cassidy @carlwgeorge uh, I feel like you're unfairly conflating mine and Carl's replies there. I didn't say you were attacking anyone, or anything about excuses, or fairness, or appropriateness. I just answered your question of why this was the case (by referring to the policies on retiring packages), and explained how it can be sped up, then I went ahead and did that for you. I hope that was useful.

tehstu, to fedora
@tehstu@hachyderm.io avatar

Anyone happen to know if 40 adds 5 support?

adamw,
@adamw@fosstodon.org avatar
fedora, to fedora
@fedora@fosstodon.org avatar

Fedora Linux 40 is HERE! Check out all our latest variants for desktop, server, and more.

New features include:

  • @kde Plasma 6
  • @gnome 46
  • Fedora Atomic Desktops (rebrand for Silverblue et al)
  • PyTorch / ROCm
  • And more!

Learn more and try Fedora 40 today! https://fedoramagazine.org/announcing-fedora-linux-40/

#Fedora #Linux #OpenSource #Gnome #KDE

adamw,
@adamw@fosstodon.org avatar

@fedora "You will literally be swapping to newer and newer container images when you update rather than managing independent packages and dependencies." isn't quite right. IoT was already an atomic release. But it's switched from the original ostree technology to the new bootable OCI container approach. the ultimate user experience is much the same or improved, but the implementation is actually pretty different.

adamw, to fedora
@adamw@fosstodon.org avatar

today:

WagesOf, to linux
@WagesOf@gamepad.club avatar

So, uh people, can you tell me what in the blue fuck happened to the installer on ?

adamw,
@adamw@fosstodon.org avatar

@WagesOf um, some more context/detail would be nice? are you saying the installer changed in some way that surprised you? and what's up with your wifi, exactly? fedora certainly does usually work just fine on intel wifi out of the box, I am using it right now on a Dell XPS 13 (9315)...

adamw,
@adamw@fosstodon.org avatar

@WagesOf well, the design is intended to be 'hub and spoke', not a wizard, though it got a bit...messy over the years as bits got glued on by people who aren't UI designers. there was rather a lot of work done on it at the time, https://fedoraproject.org/wiki/Anaconda/UX_Redesign if you're interested, also https://mairin.wordpress.com/2011/06/16/making-fedora-easier-to-use-the-installer-ux-redesign/ .

adamw,
@adamw@fosstodon.org avatar

@WagesOf the buttons at top left are 'done' buttons not 'next' buttons, they only appear on 'spoke' windows to return you to the 'hub'. iirc the different placement is partly to make it clear that they are not 'next' buttons in a wizard flow.

adamw,
@adamw@fosstodon.org avatar

@WagesOf the 'why' was basically "make it so you don't have to go through all these screens if you don't want to" - the old old UI made you look at all this stuff about timezones and whatever that maybe you didn't care about. the real idea with the hub and spoke design was that most people would not need to visit more than one or two of the 'spokes'.

adamw,
@adamw@fosstodon.org avatar

@WagesOf ironically we wound up with the most popular image (workstation live) suppressing most of the 'optional' spokes entirely, which makes the benefit of the design kinda unclear because you wind up having to use most of the spokes that are actually there...

qlp, to debian
@qlp@linh.social avatar

Debian users who are using testing, unstable or experimental may want to be wary of the compromised version of xz. This is tied to the same notification that went out for Fedora 41, some Fedora 40 and Rawhide users.

https://lists.debian.org/debian-security-announce/2024/msg00057.html

adamw,
@adamw@fosstodon.org avatar

@qlp
The issue was actually discovered by a Debian dev (thanks!) and certainly does affect any branch of Debian where 5.6.1 showed up.

So far the consensus seems to be that the exploit probably didn't work in 5.6.0, but you should still downgrade any 5.6.0 install for safety.

qlp, to fedora
@qlp@linh.social avatar

Good news!

No, it's not a Dacia Sandero. But, I was able to boot off of the KDE spin of Fedora 40 Beta ISO on my Microsoft Surface Pro 3 without any modifications!

#Fedora #Linux

adamw,
@adamw@fosstodon.org avatar

@qlp so the F40 image booted OK for you with no workaround needed any more? It should have done, but someone posted on discourse that they still had trouble with a surface pro 5, so I'm trying to triage...thanks!

maxamillion, to random
@maxamillion@fosstodon.org avatar

I've renewed my enjoyment of writing bash scripts, it's super fun. 🙂

adamw,
@adamw@fosstodon.org avatar

@maxamillion
It's okay. There are support groups for people like you.

adamw,
@adamw@fosstodon.org avatar

@maxamillion don't worry, if it gets really bad you can get a job as a dracut maintainer.

adamw,
@adamw@fosstodon.org avatar

@maxamillion backs away slowly

adamw,
@adamw@fosstodon.org avatar

@vwbusguy @maxamillion aaaaaaaaaahhhh make it stop

adamw, to random
@adamw@fosstodon.org avatar

today's embarrassing workflow confession: I just now switched to using git remote add instead of manually editing .git/config, which I've been doing for I think about a decade at this point

qlp, (edited ) to linux
@qlp@linh.social avatar

With a little of spare time this morning, I was able to (finally) install Fedora 39 on my Microsoft Surface Pro 3 with Secure Boot enabled using a bootable USB stick with an older version of BOOTX64.EFI. [1]

I had to temporarily disable TPM in order for the system to boot after the install. Resetting the Secure Boot keys to Microsoft and Third-Party keys and re-enabling TPM [2] after installing the latest updates allowed me to boot back into Fedora with both TPM and Secure Boot enabled.

Since I still wanted a computer that ran KDE Plasma, I went with the KDE spin.

The Surface is definitely a bit tired and slow, but still very usable for browsing the web and editing documents.

Links:
1: https://discussion.fedoraproject.org/t/install-media-dont-boot-in-uefi-mode-on-certain-motherboards/71376

2: https://discussion.fedoraproject.org/t/gnome-software-update-boot-error-grub-core-commands-efi-tmp-c-unknown-tpm-error/75009

adamw,
@adamw@fosstodon.org avatar

@qlp we're hoping this stupid boot bug will finally be fixed in the final release of f40, but it depends on secure boot signing timeframes...

b0rk, (edited ) to random
@b0rk@jvns.ca avatar

if you have your current git branch in your shell prompt, what do you use to set it up?

so far I know about

adamw,
@adamw@fosstodon.org avatar

@gnomon @b0rk i did not realize this was a stealth poll! add one to built-in, then. :P

  • All
  • Subscribed
  • Moderated
  • Favorites
  • anitta
  • hgfsjryuu7
  • DreamBathrooms
  • vwfavf
  • magazineikmin
  • thenastyranch
  • InstantRegret
  • Youngstown
  • slotface
  • ngwrru68w68
  • rosin
  • khanakhh
  • kavyap
  • PowerRangers
  • Leos
  • cubers
  • tester
  • osvaldo12
  • everett
  • GTA5RPClips
  • ethstaker
  • Durango
  • mdbf
  • normalnudes
  • tacticalgear
  • cisconetworking
  • modclub
  • provamag3
  • All magazines