pitillo changed the topic of #crux-arm to: CRUX-ARM 3.8 Released! - http://crux-arm.nu/Documentation/ReleaseNotes3-8 | Logs: https://libera.irclog.whitequark.org/crux-arm/
_whitelogger has joined #crux-arm
<r0ni> i'm pretty sure the gpgme port in opt-arm64 can be removed now... gpgme 2.0 seems to build cleanly for me, I don't recall there being any footprint issues either
<r0ni> and i dunno what i did, but my arm64 system started booting and acting normal again randomly... must have been a bad package hosing it... seems good now though i have no idea what the fix even was lol
<cruxbridge> <pitillo (@pitillo:crux.nu)> Checking gpgme atm
<cruxbridge> <pitillo (@pitillo:crux.nu)> What happened with your system?
<r0ni> dunno, there was odd delays booting, it was stalling, verbose boot didn't provide any clues, nothing failing, just taking a real long time to give me a login prompt... could have been my unfinished elogind setup tho, i did fix that along the way, but something was stalling it for a minute at the end of bootup
crux-arm-bot has joined #crux-arm
<crux-arm-bot> [ opt-arm64/3.8 ]: gpgme: removed overlay
crux-arm-bot has left #crux-arm [#crux-arm]
<r0ni> works fine now though, so i'll chalk it up to me half implimenting elogind
<cruxbridge> <pitillo (@pitillo:crux.nu)> Strange, so not related to kernel, something was delaying the boot, probably a service blocking or directly rc
<r0ni> i'm thinking dbus/elogind issue
<cruxbridge> <pitillo (@pitillo:crux.nu)> It’s possible
<r0ni> dbus must start before elogind and i was missing a pam rule so it had to be it
<cruxbridge> <pitillo (@pitillo:crux.nu)> That has sense
<r0ni> if i didn't have to work today, i'd get on checking lxc but that has to wait for another day sadly ;(
<cruxbridge> <pitillo (@pitillo:crux.nu)> Just bit by bit…
<r0ni> heh thats all we can do, (until I find a way to make money by not leaving the house ;)
<cruxbridge> <pitillo (@pitillo:crux.nu)> I’m using directly containers on the M4 but the odroid is running LXC like a charm