<jaeger>
ok, clean install tests and upgrade tests (3.6->3.7 and 3.7->3.7) went fine here
SiFuh has quit [Ping timeout: 260 seconds]
SiFuh has joined #crux-devel
<SiFuh>
jaeger: Anyone made sure this time that all the 3.6's have been changed to 3.7?
SiFuh has quit [Ping timeout: 252 seconds]
SiFuh has joined #crux-devel
<farkuhar>
Upgrade using -rc4 went fine on a 2015 HP laptop
<farkuhar>
I noticed however that the ISO still provides xorg-libxfont, which has recently been removed from the repo. It would save a trivial amount of space to delete this package from the ISO for the actual 3.7 release.
<SiFuh>
Good catch
<ivandi>
just noticed that upgrading from 3.6 to 3.7 doesn't install dumb_runtime_dir package. this package is in 3.7 core
<farkuhar>
ivandi: Good catch. The machine I just upgraded already had pam_xdg (from contrib), so I wouldn't have missed any of the functionality provided by dumb_runtime_dir. Even so, I don't think the setup program tests for the presence of pam_xdg when deciding which packages to install (and I didn't have "pam_xdg: dumb_runtime_dir" in /etc/prt-get.aliases), so you're correct that it should have been injected.
<ivandi>
the setup-helper script does not check for pam_xdg and does not inject dumb_runtime_dir
<ivandi>
i do not understand why dumb_runtime_dir is in core
<ivandi>
imho it belongs to opt, is there anything in core that needs XDG
<stenur>
Well ideally XDG stuff is set during login
<stenur>
The /run/USER directory should be available by then, too
<stenur>
I mean i _could_ create a CRUX-only pam_xdg_crux that is a bit smaller by reaping out creation of /run as such, as that is created by /etc/rc. But then again
<stenur>
-rw-rw---- 1 ports ports 7399 Aug 2 16:46 /x/balls/pam_xdg/pam_xdg-0.8.1.tar.gz
<stenur>
-rw-rw---- 1 ports ports 6320 Aug 2 16:48 /usr/ports/built/pam_xdg/pam_xdg#0.8.1-1.pkg.tar.xz
<stenur>
-rwxr-xr-x 1 root root 14216 Aug 2 16:48 /lib/security/pam_xdg.so*
<stenur>
This is not the world. At the moment it is hard to believe there will be any future changes, it could also be integrated as a C file like start-stop-daemon.
<stenur>
-rw-r----- 1 steffen steffen 16294 Aug 2 15:26 ../toolbox.git/pam_xdg.c
<stenur>
-rw-r----- 1 steffen steffen 3181 Aug 2 00:22 ../toolbox.git/pam_xdg.8
<stenur>
But if the situation prevents this then so it may be.
<beerman>
i think i got something to test rc4 on today
<stenur>
coincidentally, i just got message my data volume is out, thirty seconds ago.
<jaeger>
ok, the dumb_runtime_dir thing is an easy fix, at least
<jaeger>
SiFuh: we try to every time, of course... but nobody's perfect, heh
<SiFuh>
jaeger: :-) I already had checked on the rc3 version
<jaeger>
I'll fix setup-helper and remove xorg-libxfont
<jaeger>
argh... I wish inkscape didn't break with every single poppler update
<beerman>
me too..
<ivandi>
beerman: egl-wayland signature mismatch in 3.7 ports
<beerman>
ivandi: noted
<ivandi>
are md5sums still used. pkgmk creates them by default. probably PKGMK_IGNORE_MD5SUM should default to 'yes'
<beerman>
jaeger: during setup while selecting bootloaders, it looks like its just throwing some bash syntax errors inbetween menues just after hitting enter. it goes on though, so not fatal
<beerman>
it doesn't do that with selecting depending packages for the bootloader selection
<jaeger>
hrmm, ok
<beerman>
maybe its me on that hardware, we will see
<jaeger>
I see it, though it disappears quickly... will look into that as well
<farkuhar>
Speaking of bash syntax errors, the 2022-07-26 commit to core/bash/profile introduced the "bashism" [[ ]]. But /etc/profile is also sourced by dash, which doesn't recognize this syntax for tests. Previous versions of /etc/profile were more careful to avoid bash-specific syntax.
<jaeger>
grep: stray \ before :
<jaeger>
I wondered about that change to /etc/profile but forgot to check it more
<jaeger>
It's this line: pdeps=`grep "^$f\:" $depsfile|sed "s|^$f: ||g"`
<jaeger>
that \ is superfluous and now causes the warning
<jaeger>
I'm guessing that changed with the latest grep update
<beerman>
jaeger: i have been hitting weird kernel issues while installing rc4. but it might be the hardware i am using so i am currently trying alpine. so far, this seems to run
<jaeger>
What kind of issues?
<beerman>
is there anything special needed to boot on an older hp 19" server?
<jaeger>
Hard to answer that, I don't know anything about that particular server
<beerman>
uhm.. kernel message read something like "kernel dazed and confused, [..] trying to continue" - and some ext4 errors though drives seem to work ok
<jaeger>
My tests have been on virtualbox and libvirt/qemu virtual hardware as well as a ryzen physical system
<beerman>
old, but i saved it from the press for this purpose and it fails
<jaeger>
I don't see anything special in that list, 5000 series xeons and ddr3 are old and established... I haven't used HP's smart array cards much but they've been around a long time so I'd expect them to work
<beerman>
weird, since alpine doesn't seem to have the same issue with it
<jaeger>
Is there any indication if there's a specific pci device or kernel module causing the message?
<jaeger>
Or more specifically, what's generating the NMI
<beerman>
i'd bet on the raid controler, but it has been in use till recently but the usecase moved somewhere else, unless i managed to damage something durin the transport i'd like to think this one works
<jaeger>
Because the 'dazed and confused' message comes from an NMI
<jaeger>
Can it be disconnected temporarily to see if the message goes away?
<beerman>
doesn't look like it can, at least i didn't find anything
<jaeger>
I have some older Dell servers I can test on that are of the same generation, though of course won't have the exact same hardware
<beerman>
alpine just runs and i am on my way to setup lxc on it to at least virtualize crux
<beerman>
when i get there, i'd try to take whatever alpines kernel config is and build a iso with it
<beerman>
or the error returns again :D it also seemed to flake out when i started writing data onto the harddrives
<jaeger>
another option would be to install crux from the alpine media and also use the alpine kernel config, I guess
<beerman>
heh, nifty idea, i'll maybe try that
<beerman>
first time i installed alpine outside docker, the setup is pretty straight forwards
<jaeger>
I have a single alpine VM here to run an NTP server, was just curious about it a while back and it's stuck around
<beerman>
from my experience within docker containers i can say that i like it
<jaeger>
I have a coworker who was a huge fan of alpine containers and then was very confused when he couldn't run dynamic executables he wrote there in glibc-based containers
<beerman>
lol
<beerman>
yeah, thats a thing to keep in mind for sure ;)
<jaeger>
We still do use mostly alpine containers for all our golang stuff, I think
<jaeger>
any objection to me reverting that test change in /etc/profile before the release?
<jaeger>
(the bash-specific [[ ]] I mean)
<beerman>
oh sure, if its problematic with dash its easy to rewrite that
<jaeger>
yeah, simple fix, just asking since I think you made that change
<beerman>
yep true
<beerman>
at least i think so, can't remember each things without looking through git history :D
<jaeger>
:)
<beerman>
ok, so ilo reports error 0x12, for which they say update the controller firmware or replace the controller
<jaeger>
charming
<beerman>
but since alpine just seems to work i am tending to believe something is missing. not that it matters, its probably pretty obscure thing to do anyway (installing CRUX on the proliant that is)
<beerman>
heh alpine comes with doas instead of sudo, neat
<jaeger>
ok, looking at git, *I* made the change but it was copy/paste from your suggestions :D
<jaeger>
I would guess it's one of 3 things: 1) kernel option difference, 2) firmware available, 3) microcode update
<beerman>
yep, i agree
chrcav has quit [Quit: Lost terminal]
girafe has joined #crux-devel
<jaeger>
that was fun, power outage for a couple hours