IRC channel logs


back to list of logs

<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?
<buenouanq>sounds dangerous
<kadintrooper>I trust the binary
<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
<catonano>I ind make in that environment
<catonano>I find
<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.
<rekado_>it just interprets 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>Invoking Guile.).
<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?
<rekado_>ACTION shrugs
<Apteryx>Looks like I should ask Ludovic, he's the one who last changed that line ;)
<Apteryx>See commit: dadee6cd6e775741d85e8b968e7f1ce3123385a4
<Apteryx>Apparently it is so to "avoids
<Apteryx> annoying messages about auto-compilation, and avoids permission denied
<Apteryx> issues when running without write access in the usual places.
<civodul>Hello Guix!
<Apteryx>Hi civodul!
<Apteryx>I've just sent the manpages database hook patch :)
***jonsger1 is now known as jonsger
<Apteryx>(to guix-devel)
<civodul>Apteryx: excellent, thanks!
<civodul>guix-patches would have been even better ;-)
<civodul>i'll look into it
<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!
<Apteryx>Thanks for looking 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_>if you have a git checkout
<catonano>rekado_: ah of course. Thanks
<rekado_>ACTION goes afk
<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.
<civodul>interesting article about the review process:
<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>oh dear:
<wingo>ERROR: Wrong type to apply: #<unknown-type (0x24f . 0x7fa3b00e1d68) @ 0x7fa3b0697318>
<wingo>that is bad!
<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?
<civodul>that would use the 2.0 guile-ssh
<wingo>hey civodul what protects the gnutls session data (the pair)?
<wingo>i can download http just fine for this file, not https
<civodul>with ./pre-inst-env guix download?
<civodul>hmm, works for me
<civodul>did you install guile2.2-gnutls?
<wingo>i don't know :)
<wingo>i mean i just built it and it downloaded a thing, which was a bit surprising
<civodul>what is "it"? i'm lost :-)
<civodul>ah ok
<wingo>anyway what protects the gnutls session data?
<wingo>to me it looks unprotected
<civodul>a weak hash table
<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>heh :-)
<civodul>i've noticed that with guile-ssh
<civodul>i guess you end up with a guile-2.2 process that indirectly dlopens libguile-2.0
<civodul>and then bad things happen :-)
<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
<wingo>anyway, whatever :)
<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>oh dear :)
<civodul>it actually works! :-)
<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
<civodul>wingo: i like the name
<civodul>reminds me of good hacking time
<wingo>me too
<civodul>that sounds exciting anyway!
<wingo>& conjures up the idea of an disorderly feast
<bobpollaco>Is the evolution package missing??
<civodul>hello bobpollaco!
<civodul>bobpollaco: looks like it, yes:
<civodul>but you can help!
<davexunit>wow people still use evolution?
<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
<Apteryx>sneek: later tell quiliro: by guix repo, I meant this: (i.e., the source code of Guix itself and the packages recipes).
<sneek>Got it.
<Apteryx>sneek: botsnack
<catonano>how do i make the networkk available to the machine runniing in Qemu ? I remember there were some discussions about this ?
<catonano>I get a
<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>efraim: Oh no :(
<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
<civodul>hey lfam!
<civodul>lfam: so, core-updates!
<lfam>I didn't make the keyring yet, sorry :)
<civodul>ah, np :-)
<lfam>Yeah, so...
<civodul>the hydra UI is terribly slow
<civodul>ok, not news to you :-)
<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
<civodul>i think it's ok
<civodul>but then i haven't checked armhf
<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
<civodul>ACTION has to go
<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:
<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
<catonano>or something
<catonano>lfam: what are code reviews ?
<lfam>catonano: It's the practice of some of us reading and criticizing another person's code before merging it into the main codebase
<lfam>I took that quote from a comment on the article civodul shared earlier:
<catonano>ah ! Thanks
<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
<lfam>That's armhf
<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
<catonano>what is the lsh service ?
<janneke>catonano: it implements sshd
<catonano>janneke: thanks
<lfam>We also have services for OpenSSH and dropbear
<gianl>Installing guix as we speak. Very nice indeed as a piece of software.
<gianl>(guixsd that is)
<drev>I am on guixSD. Very happy about everything, I have just tried installing git with
<drev> guix package -i git
<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
<lfam>On GuixSD, that is
<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
<civodul>efraim: i think i should upload the aarch64 binaries at "" to
<civodul>provided the signatures match
<civodul>is that ok?
<civodul>incidentally that was causing a Guix build failure:
<rekado_>hmm, icecat from core-updates just crashes
<civodul>like that of master, but more?
<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>any hints from the backtrace?
<rekado_>I haven’t looked at it yet
<rekado_>well, there’s no backtrace
<rekado_>need to run it in gdb
<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_>hmm, strace isn’t very helpful
<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_>oops, crashed again
<rekado_>I just tried to open a new URL :-/
<rekado_>I also note that after updating to core-updates my laptop’s Fn keys no longer work.
<rekado_>ACTION —> zzZ
<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
<civodul>yes, that's how i noticed it
<lfam>~2x speedup building the source of linux-libre using 4 threads for xz
<civodul>lfam: pretty cool :-)
<civodul>i understand your motivation ;-)
<lfam>My poor disk!