<bavier1>python's os.path.expanduser() doesn't seem to work properly in the buidl chroot <bavier1>well, pytest isn't helping matters either <quiliro>What software does GuixSD have to translate....I cannot find apertium <bavier1>quiliro: guix doesn't package apertium yet, but it seems like a useful program <quiliro>bavier1: oh...thank you for telling me....i would like to contribute....but i would like to know how ***Piece_Maker is now known as Acou_Bass
<Apteryx>quiliro: My best advice is to clone the guix git repo, and then pick a commit which says "Add *something*" and study how it was done; then base your new package work on that. <Apteryx>Getting a well configured emacs/geiser will help you in that task too! I also use rgrep in emacs a lot to find things other examples of how to use a function. <Apteryx>Finally the "Guile Reference" info manual is a useful reference for Scheme related questions, although you shouldn't require much of Scheme knowledge to simply write a package definition. <kadintrooper>If I wanted to install a binary file how would I go about doing that? <kadintrooper>Ooh another issue, emacs tries to build pdf-tools but it complains about the make command not being found <kadintrooper>Even if I launch emacs from within a guix environment that contains make <kadintrooper>Anyone know of a way to expose the make command to emacs so that I can build pdf-tools? <catonano>kadintrooper: i I do guix environment emacs-pdf-tools <rekado_>kadintrooper: we have a package for pdf-tools. <rekado_>just install that instead of building pdf-tools yourself. <Apteryx>Observation: When I rebase my guix branch on top of origin/master, and run "guix environment guix", Guile recompiles the modified source files (it takes some time) and prints notes like "note: source file /home/maxim/.config/guix/latest/gnu/packages/xnee.scm". <Apteryx>Question: Why do successive "guix environment guix" seems to recompile everything again? I thought Guile was caching the compiled versions in my home dir. <Apteryx>I know the actual fix for this is to run "make", I'm just curious as to why the "JIT" compiled .go files cannot be re-used instead of being recompiled at each "guix environment" invocation. <rekado_>Apteryx: when you rebase the timestamps change <rekado_>and I think it doesn’t compile them. <Apteryx>rekado_: I understand why it should happen once. I don't understand why it happens (seemingly -- it takes about the same time as the first time) for successive runs as well. <Apteryx>rekado_: From Guile Reference manual, section 6.17.5 Compiling Scheme Code: "By default, Guile automatically compiles any files <Apteryx>it encounters that have not been compiled yet (*note ‘--auto-compile’: <Apteryx>And, about --auto-compile: "Compile source files automatically (default behavior)." <rekado_>Apteryx: look at the shebang of scripts/guix <Apteryx>Oh. That explains it. Any reason for this? <Apteryx>Looks like I should ask Ludovic, he's the one who last changed that line ;) <Apteryx>See commit: dadee6cd6e775741d85e8b968e7f1ce3123385a4 <Apteryx> annoying messages about auto-compilation, and avoids permission denied <Apteryx> issues when running without write access in the usual places. <Apteryx>I've just sent the manpages database hook patch :) ***jonsger1 is now known as jonsger
<civodul>guix-patches would have been even better ;-) <Apteryx>OK. I was under the impression that guix-patches was for packages, and guix-devel for guix things. But I've been lazy to catchup with guix-patches anyway, I should get into it! <catonano>how do I create a virtual machine image thhat runs core-update GuixSD ? <rekado_>catonano: you switch to core-updates in git and then run “guix system disk-image …” <rekado_>janneke: about the recursive importer: for a long time I wanted to factor out the recursion part of the CRAN importer, but I haven’t really found enough time to do it. <rekado_>janneke: do you think it would be helpful for the npm importer? <rekado_>it takes a package, extracts a list of unpackaged dependencies (using the upstream names), and then turns that into a stream of packages. <rekado_>it relies on memoization; it doesn’t try to keep track of what packages it has already visited. <rekado_>it would just re-import the package, but thanks to memoization that doesn’t result in extra work. <rekado_>other importers would need to do the same. <thomasd>for me, the issue is mostly that reviewing doesn't immediately benefit me. So given the choice between packaging something I urgently need, or reviewing, I always do the first <thomasd>good intentions to change this notwithstanding <wingo>ERROR: Wrong type to apply: #<unknown-type (0x24f . 0x7fa3b00e1d68) @ 0x7fa3b0697318> <wingo>anyone seen something like that with guix on guile 2.2? <wingo>i am guessing it is a prob with the gnutls binding... <civodul>wingo: do you have a stale nix/scripts/offload or something? <wingo>hey civodul what protects the gnutls session data (the pair)? <wingo>i can download http just fine for this file, not https <wingo>i mean i just built it and it downloaded a thing, which was a bit surprising <wingo>anyway what protects the gnutls session data? <civodul>are you sure there's not some for-2.0 .so being used? <wingo>no i am not sure, as i get these warnings as well: <wingo>;;; WARNING: loading compiled file /home/wingo/.guix-profile/lib/guile/2.0/site-ccache/gnutls.go failed: <wingo>;;; ERROR: In procedure load-thunk-from-memory: No such file or directory <wingo>so i guess there is guile-gnutls for 2.0 in my load path <wingo>does that sound like the right diagnosis? <wingo>it's a wonder anything works, then :) <civodul>i guess you end up with a guile-2.2 process that indirectly dlopens libguile-2.0 <wingo>i wonder if there is something we should do to prevent that from happening <wingo>civodul: fwiw it is still not obvious to me what protects the pair in gnutls sessions <wingo>it's in a c structure wrapped by a smob <wingo>the c structure afaiu is allocated by gnutls, right? <wingo>i don't see anything about weak references / markers etc in the build/smobs code but i could be missing sth <wingo>i.e. the session data allocated in scm_gnutls_make_session <janneke>rekado_: possibly...i didn't really look into the recursive part of the importer <janneke>npm has `dependencies' and `devDependencies'; the latter is where the ridiculous amount of packages including circular dependencies come from (i think/hope) <janneke>afaiu, `devDependencies' are sometimes more than what's strictly required for build <quiliro>Apteryx: thank you for the tip....By the guix repo, you mean all the packages or just the guix package? <janneke>so i'm not sure if it's too early for npm to use a generic recursive import strategy <rekado_>janneke: I see. Thanks for explaining. <janneke>`need more info' is what i'm trying to say, i think ;-) <rekado_>I guess it wouldn’t hurt for me to break out the recursion features into a module that could be used by other importers. This doesn’t mean they all *have* to use it. :) <janneke>rekado_: the `stream of package's is useful <janneke>when importing a list of npm packages, you'll have to import them one by one, adding the output of each of them and run make in between to avoid getting duplicates <wingo>ACTION has no idea how to build guix + guile 2.2 without the gnutls for 2.0 binding <civodul>wingo: re GnuTLS, i had to check, i'm sure you'll find it funny: <civodul>wingo: SCM_SMOB_MARK (scm_tc16_gnutls_session, mark_session, session) <wingo>yep, looks like no problem then <civodul>at some point we'll have to drop 1.8 support in there and use a weak hash table or something <civodul>maybe we can even do that without dropping 1.8 support <civodul>an interesting exercise in supporting decades of Guile versions :-) <wingo>btw i almost have a sandbox. when that's done i'll start on a little PoC for making a guix channel (or at least just a git repo) out of potluck packages <wingo>wdyt of the name "potluck" for these things <wingo>and eventually ditching the name "guildhall" i guess <wingo>anyway can change the name later too <wingo>& conjures up the idea of an disorderly feast <bobpollaco>I was to giving it a try... but I don't know how to build things yet... <bobpollaco>I've installed the evolution-data-server, but I'm missing the evolution package <catonano>how do i make the networkk available to the machine runniing in Qemu ? I remember there were some discussions about this ? <catonano>Warning: vlan 0 is not connected to host network <lfam>catonano: You can get the QEMU guest system online with '-net user -net nic,model=virtio', subject to some conditions. <lfam>catonano: ICMP (ping) doesn't work, and the host system won't be able to access the guest. <lfam>And you'll need to be using a kernel that supports KVM / virtio, if I understand correctly <efraim>guix gc grabbed too much of my system, lost profile/make, time to re-./bootstrap <lfam>You should symlink the environment profile to /var/guix/gcroots to protect it <civodul>efraim: what kind of profile was it? <civodul>things that are live cannot be gc'd, or that's a serious bug <lfam>I didn't make the keyring yet, sorry :) <efraim>make wasn't cutting it, so i did './pre-inst-env guix environment guix -- make' and i got: /bin/bash: /gnu/store/8282hbljfasgg3cv5qf7a53ahfvh2z6r-profile/bin/mkdir: No such file or directory <civodul>but that makes it hard to know what the status is <lfam>civodul: Yeah, true. I think the status is "basically ready" for Intel-compatible systems. Armhf may be lagging behind, not sure <civodul>efraim: that could be because Makefiles recorded a past absolute file name for 'mkdir' <civodul>lfam: yeah, from Marius' message there were a handful of "leaves" not building <efraim>the first time it happened to me was when debian switched from autoconf-1.14 to 1.15 and I didn't realize I needed to rebootstrap the repo <civodul>i'll check some more core-updates tonight <efraim>it must've been more than a month ago, i ran my normal 'guix package -d 1m' and then 'guix gc -F 50G' and I must've lost that specific make <lfam>efraim: By the way, I left my computer building tar overnight based on this diff, but I ran out of space in TMPDIR so I'm not ready to report the results: http://paste.lisp.org/+7CLN <lfam>efraim: The bootstrap xz doesn't support threading, but it also doesn't complain about the superfluous option, so that's nice <lfam>And maybe I forgot to change cvfa to cvf <efraim>the online manpages are from different ages and versions, i found 'there is no multithreading' and 'we have multithreaded packing but not unpacking' <lfam>efraim: I tried it and threaded decompression is not supported yet. It does seem to be planned, however <efraim>the compressing would be nice, compressing the tarballs after patching them seems to take forever <lfam>Once I build up to `tar` with my patch, I can benchmark it <lfam>I guess I need to start over with 'cvf', though :( <Apteryx>Q: By what mechanism do Guix make emacs packages visible to Emacs? I've packaged some emacs software but it doesn't seem to be picked up. The .elc files are under: /gnu/store/clv8k6n8j6pgf0jy3sl747zp6n2falwb-emacs-dvc-1.0.0/share/emacs/site-lisp/dvc/. <lfam>efraim: Also, I found a way to check if an xz archive was created with multiple threads. Use `xz --list foo.xz`. If the "Blocks" column is greater than 1, bingo <lfam>efraim: For very small archives, xz might use a single thread anyways <efraim>yeah, i saw that in the man pages also <lfam>Interesting, cvfa doesn't work at all for me with Debian's tar <lfam>Oh, I guess it's the difference between -cvfa and cvfa <lfam>The linux-libre archives are created with multiple threads, so whenever it's implemented in xz, things may get faster :) <lfam>I mean, whenever multithreaded decompression is implemented in xz <lfam>"From a whole industry perspective code reviews are still at the "alpha" stage. They can produce spectacular but isolated results. In very many cases, code reviews crash, randomly reboot, are delivered late and incomplete while requiring overtime." Haha ***jonsger1 is now known as jonsger
<catonano>Apteryx: did you install such emacs packages ? Or did you ust create them ? <catonano>Apteryx: if you installed them, you should find them at <lfam>catonano: It's the practice of some of us reading and criticizing another person's code before merging it into the main codebase <efraim>i opened it on my phone, haven't gotten a chance to read it yet <lfam>core-updates: building of `/gnu/store/j3zr18f0kcg7c4qvvvpk6zib5i9y902j-guile-2.2.0.drv' timed out after 10800 seconds of silence <efraim>that one took about 6 hours on my aarch64 board <lfam>efraim: Do you think I should restart it, or change the max-silent-time first? <efraim>i think we set it to 3 hours when I said it took forever, i think/hope restarting it should be fine <lfam>We also have services for OpenSSH and dropbear <gianl>Installing guix as we speak. Very nice indeed as a piece of software. <drev>I am on guixSD. Very happy about everything, I have just tried installing git with <drev>while everything seems to succeed, I still can't find the git binary. <drev>Interestingly in /gnu/store/<hash>-git-2.11.0/bin I can definitely see the git executable <drev>Am I doing something wrong in installing? How I can further analyze what's going on? <lfam>drev: Did you run `guix package -i git` as the same user you are now trying to use Git as? <lfam>drev: Guix package management is per-user <buenouanq>if you're suing into that user, you will have to do so as a login shell (su -) <buenouanq>and you may also have to add something to a file like ~/.bashrc <lfam>drev, buenouanq: It shouldn't be necessary to add anything to ~/.bashrc just to get a program on $PATH <buenouanq>lfam: what are the warnings it sometimes gives after installing something about then? <lfam>buenouanq: Those are suggestions about setting package-specific search paths and other variables. But $PATH is set up automatically on GuixSD ***jonsger1 is now known as jonsger
<rekado_>hmm, icecat from core-updates just crashes <rekado_>it starts to search for current versions of addons and then crashes right away. <rekado_>I can’t even get it to show anything. <civodul>could it be that it's loading a second libc or something? <rekado_>that’s weird… I just started the old icecat (to get something done) and then started the new icecat in strace … and it didn’t crash. <rekado_>ah, I think that’s because it reuses the old icecat’s process. <rekado_>closing the old icecat and starting the new one leads to the same crash. <rekado_>I just get a segfault upon trying to restore my session. <rekado_>it’s fine when starting with “--safe-mode”, so I guess it’s an addon. <rekado_>I also note that after updating to core-updates my laptop’s Fn keys no longer work. <efraim>civodul: i think thats a good idea, don't want me hosting the binaries to be the sole source of aarch64-linux bootstrap binaries <efraim>also I think it only downloads the binaries during the 'make' phase, which should cause building guix in a container to fail <lfam>~2x speedup building the source of linux-libre using 4 threads for xz