<Jookia>output path `/gnu/store/aamhyadj7pwkbskylg88qlfxf50qdhaq-dmd-user-group.patch' should have sha256 hash `1lqymypixfiyb72d6bn24m06ry2q1ljnnv0qrc89pbb4z9azaa4d', instead has `0zygncr1z1nswmny2vl1havfqswm40vzj0vjvhf5yndavhzr267j'
<NiAsterisk>so I had a short try and then reflection on an email. problematic is that the list is on pastebin, that's all imo. diversity is a known issue and while it might not be a comfortable topic maybe this person really wants to address it and make something useful with it. my initial reaction was a bit bad and shocked to the public posting. but in analyzing things, it's okay in the end.
<Jookia>NiAsterisk: It's not okay since the results aren't de-anonymized- once that's fixed it's all good I guess?
<NiAsterisk>that was the issue, right. I got lost in my own writing with the email :/
<NiAsterisk>didn't send it, that's why I said I reflected on it with my friend
<Jookia>the 'net-tools' package is officially dead
<lfam>The problem is publishing a list of strangers by what you think their race and gender are.
<lfam>Oh, there's a ML setting that determines whether or not you receive your own emails. It tripped me up at the beginning too. I thought it would be annoying to get my own emails but then I could never reply to them with more detail and that was more annoying.
<lfam>The CHANGES file implies that 18.104.22.168 is just a security update. I would have pushed already but I know we like to put the CVE IDs in the commit message. I could create a bug and put that in the commit ID, and then put the CVE ID in the bug whenever it is issued. Or I could just push.
<mark_weaver>there's just one glitch: a link to the grub.cfg is not made in /var/guix/gcroots, so if you run "guix gc" it may delete the grub.cfg in the store as well as some things it refers to (e.g. the background image)
<mark_weaver>Jookia: --no-grub creates the boot directory? does it create grub.cfg in there?
<Jookia>Okay, so it *doesn't* create the /boot, that was just from me doing some hacking which made GRUB kinda work
<mark_weaver>Jookia: the easiest workaround for now is to just ask it to install grub, ignore the error that happens at the end, and then manually creating a link in /var/guix/gcroots to the grub.cfg
<Jookia>mark_weaver: I'm more interested in doing some fixing :P Do you think it'd be better for the grub-configuration record to have a 'install-mbr' flag? Or would it be better to allow a blank device entry and use that as a clue
<mark_weaver>Jookia: the relevant code is in guix/scripts/system.scm and gnu/system/grub.scm
<Jookia>I figured, I'm just wondering about design advice here. I'll just hack it for a while I guess
<mark_weaver>Jookia: I'm not sure whether --install-mbr is the flag we should add. in this case, we don't want to install grub at all. we only need the grub.cfg, right?
<mark_weaver>maybe we should just arrange for --no-grub to do that.
<mark_weaver>well, I'm really not sure what's the best approach, to be honest.
<Jookia>Perhaps, but I'd also like to specify that grub doesn't install itself in my system.scm
<Jookia>It will get annoying passing --no-grub every time I reconfigure
<mark_weaver>Jookia: actually, if you really want to do this right: on libreboot machines, instead of installing grub.cfg we should install libreboot_grub.cfg, and it should avoid doing things like loading grub modules. it should only have the menu items. it should be meant to work on the grub that was burned into the boot flash.
<myglc2>davexunit, alezost: re updatedb... I'm using locate to try to understand where things are in guix-land. So, in addition to, or maybe in place of, the typical updatedb ""once a day", triggering updatedb on each reconfigure, install, etc, might make sense.
<pizzaiolo>I might need you again in the next roadblock :P
<kristofer>anybody know about this "no boot file passed via --load"? it appears in /gnu/packages/linux-initrd.scm
<lfam>kristofer: For me it's in linux-boot.scm, not linux-initrd.scm. Are you on HEAD? The online copy of the manual doesn't seem to contain this yet, but in doc/guix.texi there is an explanation of "--load"
<mark_weaver>kristofer: I guess you meant gnu/build/linux-boot.scm ?
<mark_weaver>kristofer: it indicates that no --load argument was passed on the linux command line.
<mark_weaver>our initrd expects that command line argument to be there, and creates grub.cfg to include those arguments.
<kristofer>awesome, thanks. for root= should I always pass the label, or will the UUID work?
<mark_weaver>probably gnu/build/file-systems.scm is worth looking at as well.
<Jookia>I wonder what kind of code could be used to pass more data to device-mapper stuff- It's per-kind data so I'm not sure
<myglc2>Can I "roll-back" guixSD? INFO talks about it but I can't figure out how to invoke it.
<mark_weaver>myglc2: choose an older generation from the GRUB menu
<Jookia>Time to see if Libreboot and my changes can get me where I need to go
<myglc2>mark_weaver: Thanks. I did that and now 'booted-system -> system-8-link' and 'guix system list-generations" also shows the later system links 9, 10 & 11. So if I reconfigure now, does the system jump forward to system link 12?
<myglc2>mark_weaver: So I would say re-writing generations is generally not desireable on a multi-user machine since the same net effect can be achieved by reconfiguring the machine and this avoids the possibility of clobbering a user.
<myglc2>On a single user machine I can imagine someone saying I just want to go back to last week before this world of hurt started. But you could provide that function by reconfiguration also.
<lfam>I look at the system rollback as an emergency feature. For advanced stuff with generations, I would use the git history of the system configuration file.
<mark_weaver>lfam: that's a good thing to do when you mess up your config, but not a complete replacement for system rollback, because it wouldn't roll back the versions of the system-wide packages and services.
<mark_weaver>we should also have a "guix system --roll-back" command.
<mark_weaver>but in the meantime, you can select the old system in the GRUB menu each time you boot
<mark_weaver>but personally, I've never had need of more than emergency booting into an old generation and then reconfiguring.
<lfam>mark_weaver: I hadn't considered that caveat, thanks.
<kristofer>it would be super helpful if guix system init --no-grub would provide some feedback about the location of the kernel, ramdisk, and the arguments to pass the kernel efi stub
<myglc2>So this "guix system --roll-back" would nuke all of the state and store associated with the generation being rolled back from?
<mark_weaver>kristofer: it's all in the grub.cfg file that's generated
<mark_weaver>lfam: did you look to see if the Reproducible Debian project had a solution to this issue?
<mark_weaver>regardless, thanks for the investigation and bug report!
<lfam>mark_weaver: Yes. They said that it was not an issue for Debian since they don't build python bytecode but instead create it at install time. According to that, it is not a reproducibility issue within the scope of their project.
<lfam>I agreed that it would be silly to hardcode that timestamp in their packaging system. It is useful unless the specific interpreter is strictly linked to the non-reproducible leaf package, which is only the case for us and Nix. The bytecode is like memoized source code.
<lfam>So, if we had a writeable cache for users to put bytecode in, then we could do the same thing and not ship it. But I like what we did for python-2
<mark_weaver>I wonder if, instead of patching python, we could arrange for the timestamps on the python source files to be deterministic.
<mark_weaver>actually, I'm surprised that's not already the case.
<rekado>I wanted to debug the reboot/shutdown issues, but it's a little difficult. I don't know what to look for.
<NiAsterisk>rekado: No, i don't have a tunnel from localhost to the mailserver. It used to work like this. getmail works perfectly okay. sending email to mailinglists gives the same issue with the host address (for example: das-labor.org)
<civodul>rekado: fiddling with dbus-send like NiAsterisk suggested sounds like the right approach, but then i'm a bit weak of polkit/dbus stuff
<civodul>i switched to the 'manoj-dark' color theme, pretty cool
<mark_weaver>civodul: after updating my system to shepherd, my system kernel panics during boot, presumably because doing s/dmd/shepherd/ on my OS configuration was insufficient to make my two custom services dtrt :-(
<civodul>it's a bit fun cause you have to relearn the color codes
<mark_weaver>but I can't see any useful information on the screen. everything useful has scrolled off, and all that I see is a kernel backtrace.
<civodul>mark_weaver: bah, it can still panic if the initial config is wrong :-/
<civodul>not in other circumstances though (like 'herd load')
<mark_weaver>I'm on baby duty right now, so I can't investigate further right now
<mark_weaver>civodul: the reason my updated system panicked during boot turned out to be unrelated to my custom services. it was because I had (swap-devices '("/dev/disk/by-label/jojen-swap")) in my OS config, and /dev/disk seems to have gone away a while ago.
<mark_weaver>however, before the switch to shepherd, the result was simply that I had no swap.
<mark_weaver>with the recent updates, now it is a fatal error that results in a kernel panic during boot, and often the relevant error message cnanot be seen
<davexunit>the next GuixSD system I want to build is a home theather computer. I want to use a motherboard that supports libreboot and can reasonably decode high definition video.
<davexunit>I installed GuixSD on my current media computer, but it's really showing its age and it uses a proprietary BIOS.
<mark_weaver>hydra's load depends greatly on how many concurrent requests there are for substitutes that are not currently in the nginx cache. right now, there are 3, and that, together with 12 concurrent builds, brings the load up to about 13.
<NiAsterisk>why did I ever discover that GNUS is so good :/ now I want to fix it (again) to repair the msmtp issue.. and make the gnus config even longer. blergh
<myglc2>Houston, I am working on inflating my space suit for 'building from Git'. Iterating between adding a requirement and discovering by trial and error that 'user-package-module' is missing is a drag. INFO "7.2.1 Using the Configuration System" describes the ‘specification->package’ mechanism, but seems to kind of damn it with faint praise. Which approach should I be use?
<pizzaiolo>mark_weaver: any guides for partitioning with disk encryption and having swap as a paging file?
<mark_weaver>replacing the "foo" "bar" with the list of modules I gave above
<mark_weaver>pizzaiolo: the "guix system init" command will fail when installing grub, because grub will realize that /boot is on an encrypted disk and it won't be able to access its modules. you can safely ignore that error, because you have GRUB burned into the boot flash.
<mark_weaver>problems in the initial OS config are a major pain to deal with.
<mark_weaver>after you have a system you can boot into, updating the system is much easier, because if something is wrong and the system fails to boot, you can always boot into an earlier working system generation.
<NiAsterisk>mailing problem "solved" by destroying 4 out of 5 mailboxes I no longer needed and merged the aliases into the used mailbox and then moved from msmtp to that Gnus integrated method. I can mailz again :-]
<mark_weaver>I still don't see why this method should be frowned upon.
<efraim>I don't know that having your own repo/branch is frowned upon, but I know keeping it constantly rebased would annoy me
<pizzaiolo>mark_weaver: anywhere inside it? or in a specific place?
<mark_weaver>anywhere, as long as it's a "sibling" to things like (host-name ...) and (locale ...)
<davexunit>if you are just adding stuff on, you can use GUIX_PACKAGE_PATH, but if you want to modify the core, then you should use the git approach.
<pizzaiolo>mark_weaver: by sibling do you mean having the same amount of previous space?
<calher>Is it a long process to send recipes to the central repo?
<suitsmeveryfine>pizzaiolo: just add the init RAM code from the manual and modify that
<mark_weaver>sort of, assuming that it's properly indented. whitespace is not actually significant.
<nckx>mark_weaver, re: reinventing: as a distribution mechanism, yes (it would be nice to drop the tarball), but Nix-alike packageOverrides are a) just plain cool and b) IMHO more maintainable that a git fork.
<mark_weaver>nckx: you can say it's less maintainable, but I have actual experience in this matter.
<nckx>mark_weaver: sure, because the entire repo is now your config file. You're modifying it by hand, not programatically through a config function.
<suitsmeveryfine>pizzaiolo: then replace the example extra modules with your crypto modules as well as "hid-apple" (internal Mac keyboard) and "hid-generic" (external USB keyboard), unless they have finally been included by default
<mark_weaver>nckx: anyway, since packages are bound to scheme variables, and refer to other packages via those variables imported from specific modules, it's not really feasible for us to cleanly do something like you suggest in another way.
<pizzaiolo>calher: suitsmeveryfine and civodul also speak esperanto
<mark_weaver>sneek: later tell civodul: attempting to "guix system build" with a system that uses (locale "pt_BR.UTF-8") fails with "guix system: error: system locale lacks a definition", even though glibc-locales seems to include that locale.
<pizzaiolo>suitsmeveryfine: yeah, it's downloading things
<NiAsterisk>paroneayea: part of my (setq nnmail-split-methods '(("ml.gnu.bug-guix" "^\\\\(From:\\\\|Reply-To:\\\\|To:\\\\|Cc:\\\\|CC:\\\\|Resent\\\\|X-BeenThere:\\\\).*\\\\(bug-guix\\\\|bug-guix-request\\\\|bug-guix-bounces\\\\)@gnu\\\\.org")))
<myglc2>davexunit: Of course now I can't reproduce it. It was something ~ "command guix not found". But now that I did 'guix environment guix' on user glc3, when I ssh to glc, 'guix environment guix' works. Does that sound right?
<davexunit>myglc2: if 'guix' wasn't found, then your $PATH was wrong.
<davexunit>but I have to admit I have no idea what you've done.
<lfam>Here's my question on that topic. If I use Guix on a foreign distro to install rsync on a server, and put the Guix profile on that PATH in ~/.bash_profile, that rsync is not available to me when I tried to use that rsync server from my local machine. What is the right way to deal with that?
<myglc2>In this new account, glc3, I have not set anything AFAIK. .bashrc is stock.
<lfam>Ditto for other client / server software such as git and openssh
<sneek>civodul, mark_weaver says: attempting to "guix system build" with a system that uses (locale "pt_BR.UTF-8") fails with "guix system: error: system locale lacks a definition", even though glibc-locales seems to include that locale.
<sneek>civodul, mark_weaver says: presumably because I don't have that locale installed on my system right now. it's not in the USB installer image either.
<mordocai>Hello, i'm just starting to try out guix(current goal is to contribute a patch with some common lisp package updates) and tried guix environment guix and am getting this for downloading openssl: http://sprunge.us/TgIa. All the other downloads worked fine. Is this a bug or am I doing something wrong or ??
<wingo>a bit frustrating as it nukes the builddir and it takes quite some time to reproduce
<pizzaiolo>just tried to boot into GuixSD, had a kernel panic
<mordocai>I'm running guix on gentoo, and got this http://sprunge.us/IXji. I have more installed in gentoo, is that a missing dep for gawk or is something weird going on? Sorry for the noob questions, but i've just barely started using guix.
<calher>I do have a nonfree router. I don't have the $$.
<Jookia>You have a nonfree router- on an open network
<NiAsterisk>not everybody can afford all the things or go looking for them. I only found librecmc compatible routers when prices dropped and I consider the bloated router+modem ocmbination infront of it which I can't easily get rid of the biggest security threat.
<Jookia>NiAsterisk: This is true, but with a nonfree router I would at least try to secure it to reduce the attack surface. I still do this with my free router since defense in depth is a great idea
<calher>Jookia, I know this isn't very secure, but it's better than being a jerk who hogs bandwidth.