00:56 <farkuhar> considering that the crux 3.6 handbook kept it simple by only presenting one bootloader for each BIOS setting (UEFI or MBR), I thought it best to retain this structure for the 3.7 handbook.

01:01 <farkuhar> maybe it would have been more fair to demonstrate both syslinux and grub in the main text, rather than putting all the syslinux info in the appendix, but separating grub from syslinux based on the BIOS setting would have caused more confusion, imho.

01:05 <farkuhar> the other possible refactoring is to address only the MBR installation in the main text (both grub and syslinux), letting UEFI have its own wiki page, but given the ubiquity of UEFI it didn't make sense to refactor the text this way.

01:48 <jaeger> agreed, I'd say UEFI is the preferred way to go these days

01:52 <jaeger> I have no problem prioritizing UEFI over legacy booting

11:07 <farkuhar> hmm, that's an interesting idea, jaeger. So the main text might discuss only the UEFI installations of grub and syslinux, leaving for the appendix any less-common configurations like legacy boot, grub.cfg written by hand, and kernels with EFI stub?

11:12 <farkuhar> one downside of that presentation is the risk of having certain steps repeated in both the appendix and the main text, in order to give the reader a self-contained procedure without so many links between sections.

11:14 <farkuhar> I'll give it some thought today and see if that arrangement can be made to work.

13:44 <SiFuh> farkuhar: If going UEFI, why not skip the boot loader altogether and just put an entry in the UEFI using efibootmgr instead? Stick your grub and SYSLINUX in the appendix section?

13:48 <SiFuh> Here are some examples. https://dpaste.com/85776TBHA.txt

13:52 <farkuhar> SiFuh: that might work for first-time CRUX users (who have no experience with the previous layouts of the handbook), but anyone coming back to CRUX after a long hiatus might find it jarring to be told "compile your kernel with EFI stub enabled, or else jump to the appendix."

13:54 <SiFuh> Well it isn't the first time bootloaders changed in CRUX :-)

14:02 <SiFuh> I am imagining that the actual line is in the handbook :-P

14:05 <jaeger> I would suggest both UEFI and legacy in the main text since legacy is still extremely common... and instructions/simple setup for both bootloaders with more custom or non-standard whatever config in the appendix

14:06 <jaeger> or wiki

14:41 <SiFuh> jaeger: the most simple way I can think of for UEFI is jsut compile the kernel with EFI_STUB and use CMDLINE_BOOL for the command line options and just copy the kernel to and as %Partition%/EFI/BOOT/BOOTX64.EFI

14:42 <SiFuh> But anyway, not to worry, the handbook is in good hands.

18:21 <jaeger> jue: what do you think of the proposed handbook stuff?

18:21 <jaeger> Maybe we can push 3.7 out soon

18:49 <jue> jaeger: is fine for me, no objections

18:50 <jue> maybe we should give farkuhar write access to our wiki, would probably simplify the work a lot

18:52 <SiFuh> Agree

18:53 <jue> jaeger: and a big 'yes' to having 3.7 out soon ;)

18:59 <beerman> nice. meanwhile, i am compiling the rust 1.63.0 update and i already dropped rust-bin

19:00 <beerman> the user environment part of pam_env.so is deprecated 2 years ago, but it seems like pam_env will stay around to be able to read /etc/enviroment, i haven't commited that change yet but I'm postive to do it - any objections from you two?

19:07 <jue> no

19:10 <jaeger> jue, sure, ok by me

19:11 <jaeger> Regarding pam_env.so I would still leave everything commented and let users choose

19:11 <stenur> oh please no pam_env by default

19:11 <stenur> pam_env by default!! terrible!

19:18 <beerman> i am still conviced we should set the runtime dir

19:18 <jaeger> I would prefer not to set it by default but to offer commented sensible options

19:19 <stenur> people, why don't you use pam_xdg, and let people do what they want in their own .profile or whatever their shell is?

19:19 <beerman> do you have a reasoning for that or is it a gut feeling?

19:20 <jaeger> It's personal preference, not a gut feeling

19:20 <stenur> some via efibootmgr, the rest sourced from shell script

19:20 <stenur> sorry wrong channel

19:20 <jaeger> stenur: because beerman seems to hate everything you do or say

19:20 <stenur> interesting technical reason

19:20 <jaeger> There's nothing technical about that statement, obviously

19:21 <beerman> lol

19:21 <beerman> you know, there is a written statement by stenur inside flyspray that he tries to piss me off wherever possible?

19:21 <stenur> you currently modify a lot of places, global profile, there is a dumb_runtime_dir thing, now you think about that really terrible pam_env.

19:22 <SiFuh> Bahahahahaha

19:22 <jaeger> We tried the profile thing, people didn't like it. No big deal, it got reverted. Testing is what pre-releases are for

19:22 <beerman> that and the fact that he is so clueless about most things and no thanks, i don't want his stuff. if it were just me, i would've kicked him out a long time ago

19:23 <stenur> it is anyway bash only as far as i know.

19:26 <stenur> /etc/rc should have a working replacement for "/bin/cat /var/lib/urandom/seed > /dev/urandom" with 3.7 too, imho. The Linux random maintainer is unfortunately not willing to reenable that, even though it would be very easy (even non-kernel i would not take that long i think)

19:28 <beerman> jaeger: fine for the profile, i didn't mind that. I just have no idea why you would oppose to setting that env by default. it does no harm, and stuff uses it, like gnupg for example. but oh well, i am not fighting it anyway

19:31 <stenur> http://ix.io/3WPt is second stage file

19:32 <stenur> sorry people; btw XDG 0.8 does not yet contain paths for videos and such, but i can truly imagine this could happen if things continue; maybe try it and see your name on a standard document, beerman?

19:32 <SiFuh> The problem was that variables were being created when xorg wasn't launched

19:35 <stenur> i mean if you do not like pam_xdg, which is a stable thing that i also used on FreeBSD (ports) it seems, you could instead hack up dumb_runtime_dir, because to add the paths you only need a single call to pam_putenv(), and not that pam_env.so thing with all the masses of things it imposes on a system!

19:36 <stenur> it already _has_ one such call, you only had to duplicate that and use the needed other arguments, that is it.

19:44 <stenur> ah! now that SiFuh said it i see it for the first time for real what he said.

19:48 <stenur> I personally truly hope that CRUX gets through this hard time. I personally really love using it on my box. I have all i need, i know what happens here, there is no cruft, updates happen fast (usually).

19:48 <stenur> Ok now we sometimes get commits which turn it worse, or which just do something because of a single mind.

19:49 <stenur> But until know i have always been able to work it around.

19:50 <stenur> Or even liked it in the end, say gcc update, what else it was, hm... glibc? what broke krb5?

19:50 <stenur> in the meantime it is running just fine again.

19:50 <SiFuh> For myself krb5 is unneeded

19:51 <stenur> Horrors! to use a different distribution, but maybe Alpine or, but have not tried for years, Void. There was also trouble was it.

19:51 <stenur> No, i like it.

20:15 <SiFuh> jaeger: beerman: is there a common file or some common files the Xserver or the Xlogin client use like .xinitrc or .xsession?