IRC channel logs


back to list of logs

<ng0>I think I'm supposed to manually invoke libtool install
<ng0>but I'll do that tomorrow
<elpogo>thanks efraim. i found an ugly solution
<reepca>Hm, which package (if any) provides the "at" command?
<Apteryx>reepca: do you have access to a debian system? there's a nice apt-file utility which queries a database of files provided by all the packages in Debian, or so I understand.
<Apteryx>Otherwise I'm afraid the next best tool might be your favorite search engine.
<reepca>looks like the debian package is just named "at"
<Apteryx>available here:
<Apteryx>We don't seem to have it in Guix
<efraim>I loaded armbian on my odroid, vm.swappiness was set to 0
<efraim>No wonder I was having OOM issues while building packages
<bavier1>package beta release of software, or include 2 configuration and 4 security patches?
<efraim>Tough choices
<efraim>reepca: is 'at' a bash built-in?
<reepca>efraim: nope
<pmikkelsen>good morning guix
<ng0>did cd1ad27e6cdf90230d07efc18a8fcfe45494aad0 fix elogind? I want to update later today
<ng0>(gnu: elogind: Use itself as the cgroup controller.)
<civodul>Hello Guix!
<ng0>Yesterday at a walk in the park I learned that explaining the importance and general idea of reproducible builds can best be explained with reproducible science.
<ng0>at least to an academic person
<efraim>I'm looking at dlang and gdc, and GCC doesn't have a 'd' language option
<civodul>ng0: although reproducible science is broader, and some might consider bit-reproducible builds to me a "detail" in this big picture
<civodul>efraim: i think the D frontend (GDC) was only recently included in GCC proper
<civodul>i don't remember if it's GCC 7 or 8
<efraim>I tried 7 and got nothing
<efraim>Debian packages lists it for 4.6 through 7 but their are down atm
<ng0>yes.. but I tried with software before and explaining how it all works. they understood that part aswell, but they didn't understand why it's important for them because "why bother, for most people if you don't care beyond 'it just works'"
<ng0>the general concept was received though :)
<efraim>civodul: I have some old macbooks with 64 bit chips and 32 bit efi implantations, do we have an easy way to specify a 32 bit bootloader?
<ng0>civodul: I assume you can log into your system again with the commit you made yesterday?
<civodul>efraim: not really, but we could add it, like adding a grub-efi32 package or something
<civodul>or maybe grub has an "efi32" target?
<civodul>ng0: yes, that fixed it!
<efraim>Probably #:system i686 could work
<ng0>thanks :)
<civodul>efraim: either that or look for the right configure flag in grub
<efraim>I looked around grub's, I have a longish post to the mailinglist coming some time next week about default and arch-specific grub packages
<qumak>while on the topic of grub.. is there a good way to regenerate my grub.cfg when doing a system reconfigure without having it try to run grub-install? system reconfigure seems to have custom magic, as the resultant grub.cfg != grub-mkconfig output
<qumak>(of course it _has_ custom magic, i guess my point is guixSD doesn't output the intermediate representations normally found in e.g. /etc/grub.d, so atmafaik the only way to generate a proper grub.cfg wrt my guix system generations is to run reconfigure without the --no-grub flag, even though it fails trying to install grub on a partition instead of a drive)
<efraim>It seems armbian is heavy on armv7, so not entirely a good base for guix on $distro on aarch64
<civodul>qumak: yes, "guix system reconfigure" is currently the only way to generate grub.cfg
<civodul>is this a hindrance for you?
<qumak>i guess what i'm asking is whether there's a way in my setup to run that without it failing, while still generating the new config
<qumak>right now it generates it but fails and i feel weird asking it to do something i know it cannot do each time just to get the grub.cfg heh
<qumak>(to be specific, i'm directly loading the grub.cfg from the drive's primary grub which is not managed by guixSD - inspired by )
<civodul>qumak: so you want to generate grub.cfg, but you don't want to use it?
<civodul>ACTION is confused
<qumak>i do use it, but i just need it updated, don't need to install grub itself anywhere
<civodul>qumak: could you email, with details about what you want to achieve and why the current situation is unsatisfactory?
<civodul>email can be better when discussing non-obvious things
<civodul>GDB 8.0.1 gained support for... alpha*-*-kfreebsd*-gnu :-)
<jonsger>civodul, it was removed :)
<civodul>oh i misread then, too bad :-)
<jonsger>civodul, maybe because no one use that. it's exotic^3
<civodul>i don't think GNU/kFreeBSD ever ran on alpha
<efraim>Pretty sure not, but some of the more exotic architectures on BSD use GNU tools since they don't always have BSD licensed tools
<jonsger>civodul, fastest computer on the world uses alpha :)
<efraim>Do we have zram support?
<civodul>jonsger: which one?
<civodul>though it's not entirely clear how close it is to Alpha
<efraim>I'm on my phone ATM, high level question about grafting: it takes /gnu/store/foo... and replaces it with /gnu/store/bar... and that's it? No additional modifications?
<civodul>efraim: correct
<civodul>it also works on file names and symlinks
<ng0>Do we want to depend on an unofficial (but versioned) mirror for the Noto font set? I've just added the Noto series to my server, since I have them all anyway, copy-pasting and checking guix packages for them until I'm done
<ng0>it could be a fallback when Google decides to update in place (like almost every font out there...)
<ng0>I guess Nix doesn't package the single font packages of them and I don't know any other system that does
<ng0>or maybe debian does
<ng0>that's btw
<Apteryx>woohoo! After 3 days of building stuff my GuixSD finally is up-to-date ;)
<ng0>ah, at least centos, fedora, mageia, redhat and debian provide the noto fonts in single packages
<civodul>Apteryx: oh, 3 days of building stuff?
<civodul>that sounds bad
<Apteryx>yes, well I had to guix pull twice to get ahead of some issues (got the libcap thing), and everytime it had to biuld everything it seems. coreutils, bash, Guile, gcc, glibc, linux, etc!
<Apteryx>But now I've added bayfront and berlin substitute servers to my config, hopefully next time it will find substitutes!
<ng0>I think I should remove my substitutes cache.. it's also located in berlin, and with it's just pointless for me.
<civodul>davexunit: a nix-shell use case:
<davexunit>civodul: is it one that 'guix environment' can't handle?
<civodul>davexunit: no, it can deal with it
<civodul>there's this extra 'sethupHook' thing that we currently don't have
<civodul>but it's something the <environment> record can add
<civodul>anyway, looks interesting
<davexunit>civodul: ah, yes. that would be where we would use shepherd services
<davexunit>which will be much more powerful
<davexunit>no I just have to... uh... write it
<davexunit>civodul: also, your paper of gexps is awesome.
<davexunit>I haven't finished reading yet, but I've learned a thing or two already.
<civodul>heh, thanks!
<catonano>I want to write on a mailing list asking for help on how to write a service for Trytond. Which is the appropriate mailing list ? The help one ? Or the dev one ?
<Apteryx>I wouldn't loose sleep over it; I think either would work.
<bavier>should guix be trying to patch packages' "check for updates" functionality?
<bavier>e.g. I noticed the latest icecat has such a button in its "About" dialog
<civodul>heya wigust :-)
<civodul>ACTION made the nickname/real name connection
<wigust>civodul: o/
<civodul>many guix seem to be on vacation or something these days
<civodul>or busy catching up after vacation, who knows?
<Apteryx>does ti mean the number of patches go down, or up?
<civodul>maybe it goes down, but more importantly, there are fewer people to review them
<Apteryx>I see. I should get started!
<civodul>yup :-)
<catonano>civodul: I started reading your gexps paper in the morning but then I had to go. I'll keep reading in the next few days. But I'm busy, in these days. There are a couple of exceptional events for me in september/october
<catonano>still, I'd LOVE to be able to deploy a decent Trytond service (I posted on guix dev about that)
<civodul>catonano: if there are patches pending review or something, make sure to ping people
<civodul>or if you were asking for help
<catonano>I am asking for help, no patches yet
<catonano>civodul: I'll keep that in mind, thanks
<civodul>catonano: ah ok, but you're welcome to ping people anyway ;-)
<civodul>i may have overlooked your message
<catonano>civodul: I wrote it only a few minuutes ago :-)
<catonano>civodul: I guess we can say that I'm pinging you (and everybody else here) right now :-)
<civodul>ah ha, i see!
<Apteryx>civodul: any suggestion as to where to look in the code to add some new command to make btrfs more discoverable during boot? I guess something related to initrd?
<civodul>what do you mean by "make btrfs more discoverable"?
<Apteryx>I think I need this to run before attempting to mount the partitions: btrfs device scan
<Apteryx>If I have a raid made up of multiple disks it will autodiscover that and make the array visible.
<civodul>there's a hook in the initrd thing to run a comment
<civodul>*a command
<Apteryx>You mean configurable directly at the operating-system definition?
<civodul>if you look at raw-initrd in (gnu system linux-initrd)
<civodul>there's this #:pre-mount thing
<civodul>this is where you could plug your command
<civodul>though this is currently inconvenient
<Apteryx>OK. Thanks for the pointer. I'll start investigating from there.
<CharlieBrown>How do I automatically start the guix daemon in my rc script?
<CharlieBrown>do i need to put an & after the commmand?
<CharlieBrown>rn i have
<CharlieBrown>ACTION posted a file: rc.local (0KB) <>