<atw>I emailed help-guix a while ago, but haven't seen it show up in the archive just yet. I don't suppose anyone's gotten it?
<zero21>ops dont worry looks like it has to be root only after all
<PotentialUser-69>If GuixSD uses Sheperd as the init system why does is systemd in /etc/fstab?
<lfam>PotentialUser-69: I don't see that in my /etc/fstab, but I'd guess it's a side effect of using elogind in some GuixSD configurations. elogind is a fork of systemd's logind that helps us use GNOME without systemd
<PotentialUser-69>yeah, IDK...I just ran "locate systemd" and my terminal spit out screens full of systemd directories.
<buenouanq>and I would like to know what I can do to give a proper analysis of it for you real devs
<buenouanq>last night it was suggested doing a fresh install (system init) from the supplied and verified image without doing any sort of pull or update
<lfam>Basically, a bug report should say what you expected to happen, what happened instead, and any details that could help reproduce the system. So if it's reproducible from a fresh install, or especially with `guix system vm-image`, that helps a lot
<buenouanq>what can I put in the bootloader field if I know I'm going to be initing it with --no-bootloader ?
<str1ngs>buenouanq: can you just leave that field out?
<buenouanq>No, it's a required one - I need it either not to be, or like a dummy bootloader that doesn't do anything. The latter option would be nice because then you wouldn't have to remember --no-bootloader.
<str1ngs>I think --no-bootloader is the best way. since the target system could be a real system or VM. so --no-bootloader act's as a switch as it's intended
<buenouanq>right, I don't mean that that flag should be gotten rid of
<catonano>I received some highly valuable feedback. I appreciate that
<ng0>hi. how do you feel about a patch that adds fish-guix into our etc directory in the guix repo? I don't feel like maintaining it anymore, and I don't see myself fixing the general fish integration (installing extensions via guix) any time soon. It's on my list, but I think in the meantime people would benefit more from something they can simply copy from the directory.
<ng0>I'd relicense it to public domain, so that it can be integrated (unless BSD-3 + GPL3 are compatible, didn't check in a long time)
<ng0>there's lots of todo's in fish-guix, including a rewrite, but I think it's better this way
<fps>there seems to be a bug in the handling of bug-guix. reporting a single bug by sending a mail to the ml causes a subscription where you get mails about all bugs
<fps>i don't want to send another bug report. i just unsubscribed ;)
<nckx>If you're feeling lucky, patient, or both, there's always ‘ls /gnu/store/*/*bin’ which I use more often than I care to admit. It only works if it's something that's already [likely to be] installed, of course.
<clacke[m]>I know the difference, and I still thought it was in binutils. But if debian has it in libc, it should be there in guix too. :-)
<clacke[m]>fun tip: 'printf "%s\\n" /gnu/store/*/*bin/blah' is faster than ls if you have many hits, because ls stats every hit. :-)
<nckx>clacke[m]: All right. My search engine ‘helpfully’ autocorrected ldd to ld until I noticed, just double-checking.
<clacke[m]>fun tip: `'printf "%s\\n" /gnu/store/*bin/blah'` is faster than ls if you have many hits, because ls stats every hit. :-)
<nckx>I'm going to... try to remember that. Thanks.
<nckx>I subscribed to the HPR feed last week, after thinking ‘I should subscribe to the HPR feed this week’, but it's a bit... much. I'll have to filter it somehow to get rid of the gaming on Windows stuff etc.
<jlicht>would it be okay if I rebased my and Jan's work on the npm importer + node build system and push them to a branch on guix' git repo (e.g. "wip-node-build-system")? I would like to get it into a mergable state so people can at least properly hack it. I would also love to co-mentor a potential GSoC student if they choose to continue work on this as well :-)
<ng0>okay, I have sent patches to remove fish-guix and add the completions to Guix. Could anyone using Fish look into the patch set in the next days if it works for them?
<jlicht>guixbuilder: it might, but in that specific snippet you have two ")" too many at the end. If you want to share code snippets, you can use a service like paste.debian.net and just share the whole package recipe as-is.
<nckx>guixbuilder: Even better is to replace that ‘0.5’ using (I think) version-major+minor. Examples abound in the source tree.
<marusich>buenouanq, regarding the problem of ssh-daemon not starting, do you use static-networking-service-type in your operating system declaration?
<marusich>mlin, to donwgrade a package, you can do any of the following: (1) use 'guix package --roll-back' or 'guix package --switch-generation' to revert to a prior generation of your profile that uses the desired version of the package, or (2) change the package definition so that it builds the older version, and then install it with "guix package -i"
<atw>hmm. sorry about that. maybe graphically logging in via your login manager (slim/sddm/gdm) isn't running your xinitrc? You could test this by putting something like "touch /tmp/test" in the xinitrc, logging in, and seeing if the file is created
<jlicht>pkill9: guix-nonfree only includes some (nonfree!) extra packages for guix. So all packages from the normal guix repo should be unaffected an therefore still available from the 'normal' guix build servers
<pkill9>jlicht: i should've been more specific, the readme in that repo explains how to install a custom GuixSD, which I think uses the nonfree Linux kernel, i was wondering if official Guix build substitutes could be used with that custom build of Guix
<ng0>yes. though this is not official guix material and will not receive support inside Guix.
<jlicht>guixbuilder: I do not get the error you are talking about when using your package recipe btw. My build complains about pkg-config being missing, so you could try to add pkg-config to the `native-inputs' of your package.
<ng0>pkill9: for some modifications it will be good to have an offloading machine, but in general it just works
<jlicht>guixbuilder: and finding out which depencies are required is usually a combination of reading the documentation of the package you are trying to build, some trial and error and indeed sometimes a hamfisted approach of just including everything referenced in the build scripts of the package.
<ng0>you only get substitutes from the "official" buildfarm for substitutes it builds
<ng0>the moment you change something you will have local builds
<ng0>for example my st-full package is build, not (yet) from substitutes
<ng0>and if I will ever get substitutes for it, it will be from my own substitutes server
<jlicht>guixbuilder: It means that there is no module for (gnu packages libwnck) ;-). If you were to issue `guix package --show=libwnck', it shows among other things the location of the package
<jlicht>in libwnck's case, the location is (gnu packages gnome), so if you have that module imported, you can just refer to the `libwnck' library by name.
<jlicht>in case it is not clear: guix modules are guile modules, which can each define and export many (or one, or none) gnu guix packages. There is usually some sort of 'theme' to each module, but this is more of a convention than a technological choice.
<jlicht>guixbuilder: not that I can see, no. You should take care to import the right modules for each of the mentioned packages though. For exapmle, the desktop-file-utils package is located in the (gnu packages freedesktop modules), which you did not yet import.
<amz3>mlin: that said, there is bug about chromium in debbugs
<mlin>amz3: wow. I don't use Chromium - due to it being mostly non-free, but I would like to use Firefox 57 since I don't mind it much
<ng0>mlin: that reminded me, I do have firefox but I only started it as a base for torbrowser, which referencing the message exchanges I had with torproject can be shipped as torbrowser when I get there. modern browsers are difficult, painful. but I like pain and the challenge. it's just not moving very fast because I need time, and I've settled on Thunderbird first (to patch it to a state where it can be included,
<ng0>if at all, recent developments etc etc, long story)
<ng0>I do not have a working firefox, which is why I can talk about this ;)
<nckx>pkill9: If you've already read the manual and still don't understand, that means the manual needs improvement. Please don't hesitate to suggest improvements. New perspectives are invaluable and hard to fake.
<Apteryx>nckx: I know the feeling. You can write patches too, even better.
<Apteryx>nckx: by the way, most of your emails are flagged by gmail as spam :/.
<Apteryx>Big G's interface unhelpfully says: This message has a from address in tobias.gr but has failed tobias.gr's required tests for authentication.
<nckx>Apteryx: Thanks. So yeeeah... I'm aware of that. Short answer: DMARC. Long answer: it's a deliberate decision to disallow forwarding the way (amongst others) gnu.org does it. I might revisit that decision; I've mellowed with age.
<nckx>The only reason I haven't is that it disproportionately affects Gmail, which I despise, which is nice.
<Apteryx>I see. I once started reading about how to manage my own SMTP server... and then found out about all the modern anti-spam technologies and their requirements... I think reverse DNS was one... which didn't seem like it'd do well with my host being resolved through dyndns.
<Apteryx>if you have a GuixSD config somewhere setting a SMTP server up I'd be interested in taking a peek.
<nckx>Thinking about it some more: the only way to stop that would be publishing a policy of ‘forging e-mails from my domain is A-OK’, which I'm not willing to do... :-/
<nckx>Apteryx: my entire mail set-up is GuixSD. Ask me again in February.
<nckx>^ well, almost. There's a hilarious bit where e-mails get sent from Paris to a FreeBSD box in Miami to be signed and straight back to Paris before they're sent because I'm too lazy^Wbusy to finish packaging dkimproxy. But otherwise it's not that horrible. Thanks!