<lyr3>Anyone uses custom Windows manager? I usually use startx to (boot) them but for that I need to add a file to X to read <lyr3>Xwrapper.conf under /etc/X11/ <lyr3>but as you guys know its read-only. <lyr3>How do I add it through main .scm? <lyr3>It seems that skeleton might be what I am after <rekado_>lyr3: I have an executable ~/.xsession that starts the window manager. No need for a wrapper or anything. <lyr3>So xsession acts as .xinitrc/.profile. great lemme try <civodul>this 'guix system vm' issue is really a problem <civodul>any volunteer to bisect like Mark suggests in this thread? :-) <snape>civodul: I'll try, during my lunch break :) <roptat>so I've started to implement a bittorrent library in Scheme. I can now parse .torrent files. Next is asking a tracker for peers <roptat>now for guix, I see how we could share store items, but it looks a bit difficult for people who don't have it already to find the files <roptat>you're supposed to know the infohash, which is a sha1 hash of some information that depends on the content of the file <roptat>with the infohash, you can ask a tracker for peers or participate in the DHT and ask other nodes for peers <roptat>so we need a way to tell a user what the infohash of a package archive is <civodul>roptat: that part is what the "narinfo" URLs do in 'guix publish' <civodul>i suppose you could reuse the same thing, or something similar <civodul>in fact, you could keep publishing narinfos over plain HTTP, and publish nars over Bittorrent <roptat>yes, the idea is to publish nars over bt, but to find them we need to know the infohash <civodul>now, sha1 is inconvenient because internally the daemon keeps sha256, not sha1 <civodul>you could add the "infohash" thing to the narinfos that 'guix publish' produces <roptat>we also need to make sure we download the right thing, so narinfos are still necessary anyway <roptat>it's like downloading from an untrusted substitute server <civodul>right, but narinfos are exactly what you need, no more no less <roptat>I need to know more about narinfos <roptat>is it possible to add an "InfoHash" field? <civodul>we'll have to double-check if there's a drawback <roptat>sure, I still need some time to have a working bt peer anyway <civodul>i suppose your PhD had become boring? ;-) <Rukako>hm, there isn't a list of guile libraries, is there? <catonano>Rukako: the most reliable I know is the list of guile packages in Guix <catonano>Rukako: for example, that page doesn't show guile-redis, while it's among the pacages in guix <civodul>Rukako: in case you can't find what you're looking for in Guix or on that page, you can always ask here <civodul>that's the ultimate knowledge database :-) <civodul>roptat, snape & co: how would you translate "bundle" (as in "application bundle") in French? <roptat>pack, lot, or something with "embarqué" <roptat>I usually translate "bundled libraries" by "bibliothèques embarquées" if that can help <civodul>i had overlooked that "pack" is also a "French" word <jonsger>civodul: at least in the rugby vocabulary :) <civodul>also for things that contain milk actually :-) <roptat>although "lot" is more used in that case <roptat>like "un lot de 3 boîtes" or "un pack de 3" <roptat>I like "lot applicatif" but that may be hard to understand <roptat>there's also "groupe" or words from that family that you can use <civodul>"lot applicatif" is nice, i think it conveys the idea of "application bundle" very well <civodul>it may sound weird to readers, but they'll get used to it :-) <efraim>hmm, some dbus services are in %out/share/dbus-1/system-services and other in %out/share/dbus-1/servies <IntoxicatedHippo>I'm back with a new weird issue: `guix package -m ...` errors on one machine and works fine on another, I have almost exactly the same os config on both and the same packages installed <IntoxicatedHippo>failed to create path for auto-compiled file "guix_package_manifest.scm" <roptat>IntoxicatedHippo: do you use the same guix version? <roptat>(did you run guix pull roughly at the same time?) <roptat>maybe check that ~/.cache/guile/ccache is writtable for your user <roptat>I can't really help you more than that though :/ <IntoxicatedHippo>yes but it seems like I've somehow ended up with a version of guix from December 2017 on one machine <IntoxicatedHippo>Is anyone doing gpu passthrough on GuixSD, so far my attempts have been unsuccessful <thomassgn>how can I add a dictionary for aspell or hunspell? I need to somehow access the 'aspell-dictionary' meta-package or what to call it, but it is declared with '(define* (aspell-dictionary', i.e. not public. I'm trying with '(use-module (gnu packages aspell) #:select (aspell-dictionary))' but I just get errors that aspell-dictionary is not a binding in 'gnu packages aspell' <thomassgn>Ok, so I can get at them with (@@ ... as explained in 'Using Guile Modules' a bit further down. <civodul>thomassgn: i'd very much invite you to add those dictionaries in Guix proper :-) <thomassgn>civodul: I will, just need them today for myself :) <thomassgn>There's potentially a bug in the aspell-dictionary procedure. It adds a prefix with aspell6- to dl urls, but for some language, like norwegian, the dict is only aspell-; assuming this is to separate versions of aspell and don't know if all language need it or not. Don't know how to fix it, or if it should be fixed. But will need to figure it out to get the norwegian dictionary into guix anyway. <snape>civodul: I did the bisection and replied on the ml. <civodul>thomassgn: we can make the prefix a parameter if necessary <civodul>if you're unsure how to do that, you can send the details to help-guix <civodul>and we'll figure out together what needs to be done <jlicht>amazing blog post on the new-and-improved guix pack, civodul! <nckx>ACTION idly wondered what exactly HexChat's ‘Send system info’ sends & queried a search engine. Near the top of the list is a link to... #guix. Wow. <nckx>Seems to be fairly consistent across instances, too. Nice. <apteryx>I'm currently installing Guix on an Arch 2011 system (with kernel Linux 2.6.39) :D <apteryx>civodul: OK :) we'll see. It'll at least battle-test our guix-install.sh script. <apteryx>guix pack question: I guess it's not yet possible to do something like 'guix pack -S /usr/local/bin=bin gnupg' ? <dustyweb>I forget, do we know of someone starting an attempt of packaging git-annex? <apteryx>I guess tar would try to extract a symlink at /usr/local/bin and fail since it already exists; or worst, overwrite it? <cbaines>dustyweb, I'd also like a package for it, but I haven't got around to starting one yet. The binary releases do work on GuixSD though. <dustyweb>cbaines: yes, that's what I've been using <jlicht>dustyweb: I currently use the binary releases as well <dustyweb>kinda bugs me that I don't have "the real thing" though <dustyweb>looks like our cabal file parser barfs on git-annex <dustyweb>has a Custom-setup field that our parser doesn't expect <cbaines>Is anyone else having problems with guix system container? <cbaines>I can't get a container for the bare-bones example to start, the udev service doesn't seem to work <cbaines>In procedure open-file: No such file or directory: "/run/booted-system/kernel/lib/modules/4.4.121-gnu/modules.devname <civodul>cbaines: do you know where that message comes from? <cbaines>I believe it's something in the start gexp for the udev service <civodul>cbaines: actually it's probably (gnu build linux-boot) <civodul>weird that this file doesn't exist though <cbaines>This is the line that precedes it: herd: exception caught while executing 'start' on service 'udev': <apteryx>oh, I can't test the guix-install.sh very far because my gnupg (installed using a pack) says: FATAL: kernel too old <snape>apteryx, then you can downgrade gnupg :) <apteryx>yes I'll try using version 1 instead of 2 :) <apteryx>hmm, version gpg from gnupg@1.4.22 is also unhappy about the kernel ***lainon is now known as lain0n
<apteryx>yeah, not just gpg, also git, perl, anything I try running. <chewzerita>Any way to make a `guix pull` faster? (read: download binary instead of compile) <nckx>Isn't ‘kernel too old’ a glibc error? <nckx>I.e. it will affect almost anything using that version (maybe feature) of glibc? <bavier`>chewzerita: 'guix pull' has gotten faster lately due to some work in that area <chewzerita>bavier`: yeah i noticed that the output of the command is slightly different now compared to what it was <antelope>I did some settings, but they do not apply, I'm using awesome <antelope>in other distributions I only added in .xinitrc and launched applications in guix, how is it done? <antelope>install 'privoxy' where I must configure so that functions with 'tor' <pkill9>bavier`: so `guix pull` is going to support substitutes ? <rekado>apteryx: it’s a glibc/kernel problem. <rekado>apteryx: why do you still use 2.6.39? <rekado>we have a patch for glibc on core-updates (I wonder when this will be merged), but that’s only to make it work with RHEL 6 kernels. <civodul>rekado: i think we should pay more attention to core-updates <civodul>apparently there aren't any major issues <apteryx>rekado: it's some image that is used in production, they have reasons to stick to it apparently <apteryx>(one is that the hardware which must use it is fixed for very long periods of time, another one is certification being expensive) <civodul>apteryx: you may have to switch to an older glibc if you really want to support it <civodul>the daemon may still not work though, not sure <civodul>is it supposed to be /bin/sh or /bin/bash inside? <civodul>yeah i imagine you'd rather focus on other things but... :-) <apteryx>the shebang says "#!/bin/bash", so Bash :) <vagrantc>so, for some reason, fighting with the pine64+, the initrd didn't include ext4 module... but when explicitly requesting it, it actually booted with rootfs on usb... <vagrantc>still haven't figured out how to get ext4 recognized <vagrantc>is there a configuration option to force the ethernet speed? there's a bug on some pine64+ boards where they only reliably work at 100Mbit