<r0ni>
what is the criteria for apps being configured to use /usr/etc? is there a certain type of app? its contents doesn't seem to fall into a catagory by my viewing
<r0ni>
it appears to me to be bad --sysconfdir configs in ports, but i'm unsure if it's intended
<r0ni>
i mean in bsd they use /usr/local/etc but there is a clear seperation between system and userland as well
<ukky>
Probably this is related to how the developers of specific package see it as default.
<ukky>
For example, Pkgfile for opt/irssi does not specify --sysconfig, that's probably why config files for irssi end up in /usr/etc in CRUX.
<r0ni>
yeah if you do --prefix=/usr it can end up in there, but it just feels like it shouldn't be
<r0ni>
i was just curious more or less, i've like 5 configs in there and some xdg/autostart stuff, which again, belongs somewhere else, i'll chock it up to bad configs in ports
<ukky>
I agree with you that adding '--sysconfdir=/etc' to all packages in question would make a better looking filesystem layout.
disapper3nce has joined #crux
disapper3nce has quit [Client Quit]
groovy2shoes has quit [Quit: Leaving]
disapper3nce has joined #crux
disapper3nce has quit [Client Quit]
lavaball has joined #crux
<r0ni>
forgive me for I have sinned
<SiFuh>
You use Windows now?
<r0ni>
no, i installed elogind lol
<r0ni>
interesting side-effects... pulsseaudio starts right up booting xfce, and i now have shutdown/suspend menu options working
<r0ni>
the latest whiskermenu release requires either elogind or systed and accountservices... so naturally I had to see if I could get it building
<r0ni>
(yes, of course, it works)
<r0ni>
but seeing as a plugin has the deps and not the desktop, i'm leaving the plugin at the last version and I don't plan on adding these to my repo, as I feel providing elogind is a bit much for a xfce based repo
<SiFuh>
I named it Crematoria after The Chronicle's of Riddick.
<r0ni>
so many daemons!
guido_rokepo has joined #crux
farkuhar has joined #crux
<farkuhar>
r0ni: from ppetrov^s review you might recall this quote, "there are some peculiarities that I find nice. For example, there's a /usr/etc folder, leaving /etc only for the most important system stuff." Here ppetrov^ appears to imply that populating /usr/etc was intentional, but you're saying it's the result of running ./configure with only a subset of the supported arguments?
DanDan has quit [Ping timeout: 246 seconds]
<r0ni>
ti doesnt appear to me that theres any clear seperation... things that should be in /etc/xdg/autostart are in both /etc/xdg/autostart or /usr/etc/xdg/autostart tells me that something isn't quite right here
<r0ni>
a few conf files for 'mc' and some gnome-keyring files and thats it... just seems mistaken, this isn't like what freebsd does, and it's like nothing I've seen.
<r0ni>
Again, I have literally no idea if it's intentional or not... I checked the wiki and there isn't any mention I can find, which is why i inquired here
<farkuhar>
r0ni: The inconsistency among the ports makes your explanation (maintainer laziness) more plausible than ppetrov^s (deliberate attempt to mimic *BSD separation between base and third-party).
<farkuhar>
Now if we wanted to implement such *BSD separation more consistently, it shouldn't be too hard to do so. Do you anticipate any benefits, say if someone has /usr and / on physically different partitions?
<farkuhar>
One scenario that might benefit is if someone has different UPGRADE directives in pkgadd.conf, one for /etc and another for /usr/etc. With UPGRADE ^etc/.* YES but UPGRADE ^usr/etc/.* NO they won't have to run rejmerge to incorporate any changes in core ports, but overwriting the config of opt,xorg,contrib ports will require rejmerge.
<r0ni>
personally, i'd think anything in core/opt should be /etc and if wanting separation, everything else goes in /usr/etc(or /usr/local/etc, like bsd), this way there's no question what the system ships with and what is extra/user added. But I also wonder how many linux apps would fail in that scenario
<r0ni>
i already think crux is more bsd-like than other linux distros, but seperation of that nature is more bsd than linux. While not bad, I feel it a totally different approach than currently in use
<r0ni>
in freebsd for example, the entire ports tree uses /usr/local and only the shipped system uses the main heirarchy
<r0ni>
i do think that type of separation could be nice, but I'd think a different approach to core would be needed then. if core is to stay stable, updates shouldn't be part of ports, but only additional user added ports should change in that situation. But that's just not the way linux is designed or packaged. I'm not saying it's impossible, but it doesn't follow the same mold that it exists in already
<farkuhar>
The *BSDs do follow a more regular release schedule than has recently been the case for CRUX. If we went with, say, the OpenBSD practice of a new release every six months, then the core ports could remain frozen at whatever version they had at the six-month mark, receiving only backported security patches if anything is discovered before the next CRUX release.
<farkuhar>
But if I'm reading r0ni correctly, it might be wise to handle those core security patches through a different mechanism than ports/Pkgutils, if "core is to stay stable".
<r0ni>
yes, that's what i'm thinking, maybe a point release type system
<r0ni>
CRUX doesn't need to change though, it's great the way it is. But that could be a path taken if devs are so inclined to do so
<r0ni>
i'm going to stumble off for a bit of rest now... it's back to school season, no real rest for me
<farkuhar>
r0ni: thanks for your input. I agree we should continue the discussion, and eventually record the consensus opinion in the Pkgfile manpage or the Handbook.
<ukky>
there are two issues/questions here. 1) whether do we keep both /etc and /usr/etc, or switch to single /etc; and 2) if we keep both, how do we unify ports when core framework uses /usr/etc but some plugin for that framework uses /etc instead, like the case with /etc/xdg/autostart
<farkuhar>
ukky: despite the praise that ppetrov^ expressed for a BSD-style separation, I think it would be less of a hassle to switch to a unified /etc. The potential benefits of a separation, for users who mount /usr and / on different physical volumes, are not worth the frustration of working against the established customs for Linux packaging.
<farkuhar>
As for the fine-grained control available in pkgadd.conf, we already ship a pkgadd.conf with good examples of how to override earlier directives with subdir-specific UPGRADE rules.
<cruxbot>
[contrib.git/3.7]: libsoup3: adopted
<ukky>
I agree, single /etc would be easier to maintain and is less prone to errors at runtime
<cruxbot>
[core.git/3.7]: coreutils: update to 9.4
jue has quit [Ping timeout: 246 seconds]
<ukky>
jaeger: grub-efi from ISO cannot find 'unifont.pf2' font when option --fonts='unifont' is specified to grub-install. ISO has unifont.pf2 file in /usr/lib/grub/fonts/, but searches only in /usr/share/grub/. Original 3.7 ISO has the same issue.
<jaeger>
Under what circumstance is it required to pass --fonts to grub-install?
<ukky>
On my first CRUX install, with UEFI boot, grub-efi did not display menu, so I installed ascii.pf2 in /boot/grub/fonts via --fonts='ascii', then added GRUB_FONT="/boot/grub/fonts/ascii.pf2". This fixed the boot.
<farkuhar>
ukky: by appending /usr/etc to XDG_CONFIG_DIRS you can have both locations coexisting peacefully, if the freedesktop spec is to be believed. Meanwhile Arch has a fascinating table of software with full or partial support for the base directory spec: https://wiki.archlinux.org/title/XDG_Base_Directory
<jaeger>
Hrmm, interesting. I'll have to look into it, I've never needed to specify that
<ukky>
jaeger: This might not be an issue on my second CRUX install (Dell R620), or third (Dell 5820). It is easy to fix, but current grub-install does not install any pf2 font in /boot/grub/fonts directory.
<ukky>
farkuhar: /usr/etc/xdg/ vs /etc/xdg/ is not an issue for my setup (using WM)
<ukky>
jaeger: as a test, I will try to boot Dell R620 in UEFI mode, with no pf2 files in /boot/grub/fonts and see if grub-efi properly displays menu.
<jaeger>
ok
<ukky>
but I can report that grub-install warns about missing font: grub-install: info: cannot open `/usr/share/grub/unicode.pf2': No such file or directory.
<ukky>
jaeger: Text menu in grub-efi is fine on Dell R620, UEFI boot mode, using onboard graphics. Grub has no pf2 fonts installed in /boot/grub/fonts/.
<r0ni>
so based on that handbook ref page linked above system daemons > /etc , and conf files for user apps is /usr/etc . I've no doubt got some ports to change in xfce repo
chrcav has quit [Quit: leaving]
<SiFuh>
r0ni: user apps configurations in /usr/etc is a pain in the rectum
<r0ni>
the only issue i have with it is that it just seems like a odd place, generally /usr/local would be for this situation
<SiFuh>
r0ni: Yeah I agree. For me I always say core should be in / opt should be /usr and contrib and user portsshould be in /usr/local/
<jaeger>
ukky: what's your exact process for installing grub and generating the config file? I just did a fresh install and grub-install does not mention fonts at all. Also the menu works.
<ukky>
jaeger: Use 'grub-install -v' to see warning regarding 'unicode.pf2' font
<ukky>
full command: sudo grub-install -v --target=x86_64-efi --efi-directory=/boot/efi/ --bootloader-id=CRUX | tee log.txt
<jaeger>
Ah, I think --efi-directory may be the cause here
<jaeger>
Well, maybe not, if it complains about lib rather than share but NOT /boot/efi
<jaeger>
Here's every mention of 'font' in my grub-install log: http://ix.io/4EWA
<farkuhar>
r0ni: no need to overwork yourself trying to make the xfce repo follow so faithfully the /etc versus /usr/etc distinction as laid out in the handbook. Given that a "foolish consistency is the hobgoblin of little minds," a bigger mind like yours can get away with breaking rules.
<jaeger>
grub-install -v /boot/efi 2>&1 | tee grub-install.log
<r0ni>
farkuhar: well of course rules are meant to be broken ;) but I'd still like to look into it. One could argue that a desktop envir is a system level item though, still I ship a lot of libraries and such and some may deserve /etc while others don't
<ukky>
jaeger: Do you have /usr/share/grub/unicode.pf2 ?
<farkuhar>
r0ni: even some of the ports you might consider "system daemons" end up putting their config files under /usr/etc: davfs2, at-spi2-core, lm_sensors, mailx, ... So we'd be guilty of hypocrisy if we held your xfce repo to a higher standard of consistency.
<jaeger>
No, doesn't seem to exist
<jaeger>
Yet the menu still works fine
<jaeger>
grub-mkconfig seems to find /usr/lib/grub/fonts/unifont.pf2 just fine and uses that in the generated config file
<r0ni>
farkuhar: I honestly never gave it any thought, jaeger's portdb gave me all green lights so I assumed everything was golden anyway, but it's something to consider for the next release of xfce
<ukky>
jaeger: Grub displays menu fine on Dell R620. But on my Gigabyte GA-7PPSH motherboard with nVidia Quadro K2000 grub has issues, I had to create local grub-efi port and modify Pkgfile.
<jaeger>
lines starting with "if [ x$feature_default_font_path = xy ] ; then" show it finding and using unifont.pf2
<jaeger>
Can you upload the automatically generated config from the host where it doesn't work?
<ukky>
My grub-efi is modified on the system which does not display grub menu. I might have some logs saved, will check what I have.
<jaeger>
You were testing with a modified port from the start?
<farkuhar>
r0ni: the unofficial portdb is just running prtverify behind the scenes. And prtverify doesn't try to guess whether a port is a system daemon or not, so it allows both /etc and /usr/etc to appear in the footprint, no warning issued.
<ukky>
jaeger: Initially I used original grub-efi port. But when grub failed to display the menu, I started to investigate and found that using ascii.pf2 as a font fixed the issue.
<jaeger>
Can you generate a grub config file using the unmodified port?
<jaeger>
I'd like to see what it does with regards to font selection
<ukky>
This would be complex to reproduce. This is my main system. I probably have to remove /boot/grub directory, as I already have extra font files there, plus remove custom /etc/defaults/grub
<jaeger>
Are you using an encrypted or otherwise unknown-to-grub filesystem on that host?
<ukky>
Yes, all partitions are encrypted, except for /boot and /boot/efi partitions
<jaeger>
Ah, ok. That's why, then. grub would use /usr/lib/grub/fonts/unifont.pf2 if it could read that partition and find it
<jaeger>
Since it can't, it tries to copy unicode.pf2 from the other path
<ukky>
I see this: font="/usr/lib/grub/fonts/unifont.pf2"
<jaeger>
(when the config is generated)
<jaeger>
Er, no, that doesn't make sense... when the config is generated it CAN see the font path
<jaeger>
But not during boot
<ukky>
But are we talking about grub-install, or grub accessing /usr at boot?
<jaeger>
Both
<jaeger>
Now that I know you're using an encrypted system I'll compare to what I'm doing on my laptop
<jaeger>
The font *must* be in the EFI partition in that case
<ukky>
Shouldn't /boot/grub be self-sufficient at boot
<jaeger>
Not if it's encrypted
<jaeger>
On my encrypted systems only /boot/efi is unencrypted, for reference
<ukky>
/boot/grub is not encrypted on this setup
<jaeger>
ok, yeah, I have fonts/unifont.pf2 in a memdisk tar that I use
<jaeger>
But in your case /usr/lib/grub/fonts *is* on an encrypted partition, so it can't find the default font location
<ukky>
This issue then should be reproduced with separate /usr partitions then.
<jaeger>
Only if they're encryped
<jaeger>
grub wouldn't care if it's separate
<ukky>
ok
<jaeger>
Anyway, in your case maybe symlinking /usr/lib/grub/fonts/unifont.pf2 to /usr/share/grub/unicode.pf2 would be sufficient?
<jaeger>
Then grub-install would be able to copy it properly
<ukky>
Well, my local grub-efi port copies ascii.pf and unicode.pf2 into /boot/grub/fonts/
<jaeger>
I get that... but I don't have a system set up the same way you do to test
<jaeger>
It wouldn't be hard to test without rebooting... remove unicode.pf2 from /boot/grub/fonts temporarily, add the symlink, run grub-install
<jaeger>
See if it copies unicode.pf2 into /boot/grub/fonts
<ukky>
Will try this
<jaeger>
If that works I'll add the symlink to the port
<ukky>
I will remove my local grub-efi port, rename /etc/default/grub, reinstall original, create symlink, then do 'grub-install -v'
<jaeger>
OK, thanks. I just tested on a non-encrypted system and grub-install DOES copy it to /boot/grub/fonts, for what that's worth