adamw

adamw, 2 months ago

@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...

adamw, 2 months ago

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

adamw, 3 months ago

@sprocket there's an interesting kinda nexus with default apps on silverblue: the team doesn't want to ship too many things "baked in" as RPMs, I think, in case you don't want them, or want to use a flatpak instead (it's a bit awkward to override a baked-in RPM with a flatpak). but with current policies they can only include Fedora Flatpaks as default flatpak apps, and I don't think we have a Fedora Flatpak build of LO. IMBW, but I think that's the crux...

adamw, 4 months ago

@leochavez rawhide is going to be like that pretty much every day, I'm afraid. it's a development version, it's where we do...development. :D

in a few days you'll get an update to nearly every installed package because of the mass rebuild, so look forward to that!

adamw, 4 months ago

@fedora for anyone who prefers text to video, or needs it:

https://fedora-arc.readthedocs.io/en/latest/dist-git-move/index.html

adamw, 4 months ago

@dhry uh. where did you get this fedora environment from? edit: is it silverblue?

adamw, 4 months ago

@dhry ah. then the intended way to install extensions is via extensions.gnome.org using the pre-installed firefox, I believe. there's also a couple of flatpaks you could install that claim to do extension management, I've no idea if those work.

if you really have to overlay packages on silverblue, https://docs.fedoraproject.org/en-US/iot/add-layered/ is the way to do it. I don't know if overlaying gnome-shell-extensions works, I've never tried it.

adamw, 4 months ago

@dhry flatpak names are usually something like org.gnome.Extensions , they don't look like package names.

adamw, 4 months ago

@dhry in general, using an atomic env like #silverblue 'properly' is a bit different from using a traditional packaged distro, it takes a minute to read up on docs or forums and get used to the differences. if it seems like too big of a leap you might just want to try Workstation for now?

adamw, 4 months ago

(yes, I did manage to get a CentOS 6 system installed, on a network, and configured with working yum repos for the base system and EPEL. I was surprised too!)

adamw, 4 months ago

@smxi
So what other modules do you have workarounds for? I'm trying to see if there is something practical I can do in current fedora to improve any issues.

adamw, 4 months ago

@smxi OK, thanks. File::Find and File::Copy are both required by perl currently - https://src.fedoraproject.org/rpms/perl/blob/rawhide/f/perl.spec#_285 and line 287 . they have both been there since at least F38, the oldest current release - https://src.fedoraproject.org/rpms/perl/blob/f38/f/perl.spec#_269 .

File::Spec::Functions is not there, I'll see if I can find out why not.

edit: that was incorrect, File::Spec::Functions is required by perl, see followup.

adamw, 4 months ago

@smxi @Perl @mjgardner oh, I see, so you're saying you'd prefer for all the core modules to be in a single package rather than split into subpackages and required by perl?

I think the main reason they aren't - if I understand this 'dual life' thing correctly - is that we want to ship the newer versions from CPAN. I might be getting that wrong, though.

adamw, 4 months ago

@smxi I don't 'have' to defend anything here, i'm not on work time. :P I just look for places where folks are having trouble to see if there is something we can improve. I am trying to understand if there is something we can change in fedora now that would help.

As I linked further upthread, AIUI, the current intent in Fedora is that all core modules should be required by the 'perl' package. if there are any that aren't, I will look into that. if there is something else, I'd like to hear it.

adamw, 4 months ago

@smxi @mjgardner okay, so looking across RHEL and Fedora: the last remaining not-EOL thing which has the old setup - where 'perl' did not require core modules, but 'perl-core' did - is RHEL 7. RHEL 7 is EOL in June 2024. Fedora since 27 and RHEL since 8 have had the 'perl' package require the core modules. So, again IIUC, we did in fact "stop this stupid behavior". is there still some remaining stupid behavior that I am missing?

adamw, 4 months ago

@smxi @mjgardner I meant that RHEL has that overall design now - I didn't look into exactly the modules you listed on every branch yet, sorry, it's honestly kinda tiresome to do for RHEL since I don't really work on RHEL much. I'll keep digging.

adamw, 4 months ago

@smxi @mjgardner I just checked EL 8 (using centos stream because I don't have RHEL entitlements set up...)

as in Fedora, File::Spec::Functions is part of perl-PathTools, and perl-PathTools is required by perl. so just doing dnf install perl and then running inxi should work.

I did dnf install perl and then perl -e 'require File::Spec::Functions;' and it worked fine.

adamw, 4 months ago

@mjgardner
My point is that he never had to make changes even for the older Fedora releases, at least in the concrete cases I can see here in the inxi source and Fedora history. He was adding upstream workarounds for dependencies the Fedora packager left out of the Fedora inxi package, basically.
@smxi

adamw, 4 months ago

@mjgardner @smxi that's exactly what I'm saying he could do.

let's get in the Magic Git Time Machine and I'll show you what I mean!

the workaround I'm looking at is:
https://github.com/smxi/inxi/blob/master/inxi#L1591
it was added in 5234e390 in December 2020.

it seems smxi was fixing things a bit behind, because perl-File-Find was added as a dep in Fedora in April 2020:
https://src.fedoraproject.org/rpms/inxi/c/24b618a

but before that, the fedora looked like this:
https://src.fedoraproject.org/rpms/inxi/blob/745c1f6c9cc545213a840b79b25987c8ef71600f/f/inxi.spec

adamw, 4 months ago

@mjgardner @smxi but he does care about Fedora! he's specifically adding workarounds upstream for it, and then complaining about how he had to do that.

I'm saying that he doesn't have to. He can just write inxi the way he wants to: by assuming that all perl core modules will always be available, and not adding any workarounds to consider the possibility that they won't. if that causes any problems on fedora, he should tell fedora to fix it, because it's our problem.

adamw, 4 months ago

@mjgardner @smxi I am fixing the problems in the Fedora inxi package, and writing a PR for inxi upstream which dumps all the onerous workarounds intended to accommodate core modules not being present on a Fedora system that's trying to run inxi, because that simply is not a thing upstream should ever need to worry about.

i'm currently at the stage of building a package with those changes in it and installing it on a completely stock f39 VM to check it works as intended.

adamw, 4 months ago

@smxi @mjgardner @Perl that use case is fine. As I said, if you want to run inxi standalone on Fedora or EL, it seems reasonable to expect you to run "dnf install perl" first. If you do that, on EL 8 and later or Fedora 28 and later, it will work fine (but I am going to test it with my PR to double check this). If someone doesn't run "dnf install perl" before trying to run a perl program, that seems like that person's problem and nobody else's. :)

adamw, 4 months ago

@smxi @mjgardner @Perl the only potentially tricky case is EL 7, which still had the old setup where "dnf install perl" doesn't get you the perl core modules. I can add some code that handles that specific situation and tells the user what to do (dnf install perl-core).