jaeger changed the topic of #crux-devel to: CRUX (https://crux.nu/) development channel | Logs: https://libera.irclog.whitequark.org/crux-devel/
SiFuh has joined #crux-devel
<jaeger> can contrib/glade build without docbook-xsl?
<jaeger> (in general, without hacking it up, I mean)
<beerman> i didn't try it, but some gnome software can be very weird with it
<beerman> i'd say, at this point, try it, adopt it
<farkuhar> what constitutes "hacking it up"? I have a 3-line snippet of vi commands that gets applied to the meson.build for one of my ports, in the event that gtk-doc is not installed. The absence of gtk-doc is supposed to trigger the appropriate meson setup option for contrib/glade (unless someone managed to install gtk-doc without its dependency docbook-xsl).
chrcav has quit [Ping timeout: 272 seconds]
chrcav has joined #crux-devel
<farkuhar> keeping in mind that meson setup options do not always have the expected effect, maybe contrib/glade is one of those projects that does require some hacking of the meson.build in addition to passing the option '-D gtk_doc=false'.
<farkuhar> jaeger: i just got a successful build of contrib/glade on a fresh install of CRUX 3.7, using http://ix.io/466F
<farkuhar> the only changes from what's currently in the repo are: adding three dependencies, and deleting one line from man/meson.build when docbook-xsl is not detected.
braewoods has quit [Quit: WeeChat 3.5]
<stenur> bad commit for bash, he is not even using it. [[ ]] not needed too. /sbin for normal user? And what if i overwrite XDG from somewhere else? via login.defs? mysterious commit really. you know it better.
<stenur> i personally feel sad that good code is more and more replaced. security relevant sysctls are not enabled by default, and there XDG is hammered into the global space. may it make him happy, and everyone else too.
<farkuhar> stenur: I vote for what jaeger wrote at 15:28 several days ago, "leave them commented, then, and let users decide if they want to change..." But why did you remain silent when jaeger asked if anyone found the PATH gatekeeping useful, since it seems you have strong concerns about /sbin for a normal user?
<SiFuh> PATH=$HOME/.bin:$HOME/.local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games
<SiFuh> Isn't having /sbin /usr/sbin important if you wish to do doas or sudo or su but not take the root's environment?
<SiFuh> Maybe rather than having them commented out you could use an /etc/examples folder for everything core based?
<SiFuh> stenur: I agree though with farkuhar and jaeger's comment
braewoods has joined #crux-devel
<jaeger> farkuhar: I worded that badly, I guess... was just wondering if docbook stuff was required but missing from the deps
<farkuhar> jaeger: the deps line was missing a few required ports ( xorg-libx{cursor,composite,inerama} ) but you can get away with not installing docbook-xsl if you allow the meson compile to pull the stylesheets from the internet during manpage creation.
<jaeger> Assuming that ever works, heh... its failure to do so was what prompted me to ask
<jaeger> SiFuh: is there a situation where removing that path gatekeeping causes a problem with sudo/doas?
<jaeger> regarding the docbook failure, I mean this:
<jaeger> I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
<jaeger> warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
<jaeger> Which in past experience has been a very common error
<SiFuh> jaeger: Not sure, that is why I used a question mark. I always thought that was the only reason for those to exist
<jaeger> Fair enough. I'm not aware of any issue, myself.
<jaeger> It's one of the first things I remove from a new install
<jaeger> For years
<SiFuh> I see. Every default installs always has it in their new user profile that I have seen
<jaeger> Well, if there are concerns about it I could certainly add back the removed lines with comments or something
<SiFuh> I honestly don't know. I just assumed it.
<jaeger> ok
<jaeger> All I know is it annoys me when I can't run 'sudo reboot' or similar :P
<SiFuh> So it appears my assumption was right. Debian does it differently though according to an article from 2010
<jaeger> o they ended up doing the same thing, more or less
<SiFuh> I always kept it since I though removing it would destroy my ability to do 'sudo reboot'
<SiFuh> sudo halt -p actually
<jaeger> Exactly the opposite and why I remove it, heh
<jaeger> Could still do 'sudo /sbin/reboot' of course but I got tired of typing the full path every time
<SiFuh> I use them in my fluxbox menu even though sometimes I go to click refresh/reset and I click reboot instead ;-)
<jaeger> oops
<SiFuh> All good, I divided the menus with spacers
<SiFuh> For beerman's XDG variables, I am fine with it even though I don't use them. It will only appear during install and can be erased easily during initial system configuration.
<SiFuh> The only thought I have is those who don't use Desktop Environments for GUI will probably be using Window Managers and they tend to get their settings from xinitrc/xsession and shouldn't really be in profile.
<jaeger> as a side note, it annoys me that upstreams are inconsistent with meson options being true/false or enabled/disabled :P
<SiFuh> Same
<SiFuh> on/off
<farkuhar> The manpage for doas.conf advises that it is "best to specify absolute paths. If a relative path is specified, only a restricted PATH will be searched." On my latest install I wrote each line in doas.conf using absolute paths, forcing me to remember what lives in /bin versus what lives in /usr/bin.
<farkuhar> By forcing the user to type absolute paths with sudo/doas, any issues arising from PATH gatekeeping in /etc/profile are circumvented.
<SiFuh> permit persist setenv { -ENV PS1="[$(tput setaf 1) $(hostname -s) $(tput sgr0)]> " } sifuh
<SiFuh> Is what I have
<jaeger> The whole "issue" with the gatekeeping is avoiding typing absolute paths
<jaeger> I use quotes as it's not a technical issue, just a preference
<SiFuh> FYI, OpenBSD is using /sbin and /usr/sbin in user PATH
<farkuhar> SiFuh, you're right about /etc/profile being an unconventional place for defining XDG variables. I wonder if beerman was thinking of the situation envisioned by elderK over in #crux, where it's desired to start a service as a normal user before logging into any graphical environment, and that service needs to know about XDG_RUNTIME_DIR and XDG_STATE_DIR.
<braewoods> i think that would normally be managed by a PAM module
<farkuhar> SiFuh, thanks for the links about how Fedora and Debian handle /sbin in the normal user's path. Interestingly, the manpage for efibootmgr (despite getting RedHat revisions) has an EXAMPLES section whose first entry implies that a normal user won't be able to use it to display the current settings. Without any PATH gatekeeping, that caveat is false.
<SiFuh> As I said above. I assumed but never looked into it... Until today
<farkuhar> braewoods: good observation. In fact stenur wrote for us a pam_xdg module that does just that.
<SiFuh> So it is affirmed, I take it?
<SiFuh> That su, sudo and doas require it?
<ivandi> hi, just installed 3.7-rc2, so far so good. but what is the point to have this XDG stuff in /etc/profile. zsh will not source it, other shells may or may not source/parse it, tcsh for example. if we want to preset user environment there is a PAM module for doing that pam_env.so
<ivandi> the mount point for efivars is /sys/firmware/efi/efivars, not efivar(f)s
<ivandi> it would be nice to have this in /etc/rc: /bin/mountpoint -q /proc || /bin/mount -t proc none /proc, same goes for sys. w/o it there is an error message when using dracut
<stenur> that change of him should be reverted, too, yes.
<stenur> but i went to second line and now adjust anything via remounting from the first entry in SERVICES of rc.conf
<stenur> # Really adhere all to /etc/fstab
<stenur> /bin/mount -a -O no_netdev -o remount
<stenur> like this i can share this in between systems, and /etc/fstab does it.
<stenur> (thanks to mapper this is mostly shared, too!)
<stenur> (i have "super tight" restrictions for /dev,/sys,/proc,/run)
<stenur> SiFuh: on OpenBSD there is no /etc/profile that is per se included! In skel/ the default for new users includes this path, but this goes to ~/.profile.
<stenur> hm, ok it is in the default that comes in via login.conf.
<stenur> There it is: /usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin
<stenur> Please compare this with what CRUX now has: /sbin:/usr/sbin:/opt/sbin:/bin:/usr/bin:/opt/bin
<stenur> that is no good
<stenur> Furthermore /etc/profile would now soil my $HOME by doing "[[ ! -e "$XDG_STATE_HOME" ]] && mkdir -p "$XDG_STATE_HOME"
<stenur> I mean, come on.
<stenur> Hm, $XDG_STATE_HOME is a new thing it seems, it came in with v0.8 of the Spec.
<jaeger> ivandi: oops, yeah, typo in the efivars line, thanks
<jaeger> As for the XDG stuff, I don't personally care too much, I'm going to customize my own systems how I want anyway... but where's the "proper" place to put it?
<farkuhar> jaeger: I vote for letting one of the pam modules handle the XDG variables. That should be broadly compatible, across a variety of choices for login shell and desktop environment.
<farkuhar> users can select to activate that pam module by the appropriate directive in pam's configuration directory, depending on whether they need the variables during an SSH session, a tty session, or just a graphical environment.
<farkuhar> ivandi: as for "what is the point to have this XDG stuff" (whether it's in /etc/profile or elsewhere), your comment on 2022-07-23 almost invited it: "small things like that cost nothing and make life easier for many users"
<jaeger> I've got no problem with it moving to pam instead, whatever works... does anyone have any complaints or concerns about THAT instead?