text:
IRC channel logs

back to list of logs

<drakonis>i'll look into it
<civodul>thanks, drakonis
<str1ngs>awww I might have confused the issue I thought CAS as needed for ipfs. that's even better
<str1ngs>at least interns of implementing IPFS
<drakonis>"Content-addressed derivations: RFC 62 is necessary for using IPFS to its full potential, so we’ll be working with existing community efforts towards content addressibility."
<drakonis> civodul this is relevant, as they're the folks implementing CAS
<drakonis>okay so, things that have taken place after flakes, there's support for having multiple stores at once
<drakonis>multiple types
<civodul>how does that relate to CAS? :-)
<civodul>i think it's important to distinguish the PR stuff from the actual technical stuff that might be relevant to Guix
<civodul>"multiple types" sounds like something we already have for instance ;-)
*civodul -> zZz
<drakonis>cool, night.
<bavier[m]1>jonsger: feel free to pick up/expand on that anbox stuff. There's still some work to do before it's usable. I thought with the guix-on-phone work happening that it would be nice to have.
<PotentialUser-61>guix import nix just hangs forever
<apteryx>what does strace says?
<guix-vits>apteryx: "PotentialUser-61 has quit"
<apteryx>eh, too bad.
<ryanprior>Anybody know what the defaults are for max cores and max build jobs when you `guix pull`?
<ryanprior>(`guix help pull` does not say and I'm not familiar enough with the CLI codebase to know where to look for default values)
<apteryx>(parallel-build-jobs) from (guix build utils)
<apteryx>the number of logical cores
<apteryx>if you have a 12 physical cores + 12 hyperthreading cores, that gives you 24 cores
<ryanprior>So it defaults to using every available logical core?
<ryanprior>Okay got it. I've seen some pretty sad slow builds sometimes that only use 1 of my 8 logical cores so I wondered if that was because of a Guix default or what.
<ryanprior>Specifically I remember I built alacritty earlier today and it was using 1 core. That's a Rust app and I don't know anything about the Rust toolchain and don't want to spend the energy to learn right now X.X
<apteryx>some packages have broken parallel builds and are built using a single process
<apteryx>they are rather rare
<str1ngs>if (parallel-build-jobs) is logical cores does that mean there are a max of 24 jobs using one core?
<str1ngs>or to rephrase that means you can have as many jobs per logical cores. which is not the same as --cores=$(nproc)
<Gooberpatrol66>Will a regular bash script work if called by mcron?
<str1ngs>ryanprior: try with guix build alacritty --cores=$(nproc) --max-jobs=1 see if that improves things.
<str1ngs>ryanprior if that helps you might want to add export GUIX_BUILD_OPTIONS="--cores=$(nproc) --max-jobs=1" to ~/.bashrc
<guix-vits>Gooberpatrol66: `info mcron`, 3.2.1: Seems it can -- (system "my-program")
<Gooberpatrol66>just wondering if there were any issues with file paths on guix that i needed to be aware of
<guix-vits>Gooberpatrol66: A primer, please?
<Gooberpatrol66>so if i make mcron call "", and just has a single "ls" command in it, "" will know where "ls" is located in /gnu/store, just as though i had logged into my user account, opened a shell, and executed myself
<guix-vits>Gooberpatrol66: Guix Manual, 9.8.2: an example of '#:user "charlie"'.
<guix-vits>So, it should work if U specify Ur user.
<ryanprior>Manually specifying 8 cores and 1 job does indeed peg my CPU at 800% str1ngs :)
<ryanprior>Another question that came up the other day: I found a circular dependency in a golang package I'm working on (gohugoio/hugo) It depends on gohugoio/testmodBuilder, which in turn depends on gohugoio/hugo.
<ryanprior>Do we have any way of dealing with circular deps? Or do I need to do something clever like create a source-only package for Hugo that the testmodBuilder relies on, which then in turn the main Hugo package can rely on?
***drakonis is now known as drakonis-
<str1ngs>ryanprior: I hope 800% is good thing :thumbsup:
<efraim>ryanprior: in that case I'd mark testmodBuilder as source-only with a note it only being used to test hugo, which it does when building hugo
<civodul>Hello Guix!
<janneke>hello civodul!
<mothacehe>hey civodul & janneke!
<civodul>hey mothacehe :-)
<civodul>are we building i586-gnu derivations yet? :-)
<mothacehe>heh, I guess we try but they fail
<civodul>ah, the daemon issue probably
<mothacehe>yes + cached failure
<mothacehe>but the Cuirass UI should be must faster displaying that nothing was built
<janneke>hello mothacehe
<civodul>i'm looking at the issues with childhurd, janneke
<civodul>there's something weird with qemu port forwarding: you can successfully connect to the guest before there's anything actually listening in the guest
<civodul>and somehow qemu seems to buffer what you write there and eventually delivers it
<civodul>but... not always
<janneke>i tried your patch set on another laptop, tried hurd restart hurd-vm and herd status hurd-vm .. it doesn' work for me :-(
<civodul>then maybe there's a difference between bare-bones and my laptop config that has an influence
<civodul>for testing i use my laptop config, which has X, so i can run vncviewer
<janneke>yeah, i'm also using my laptop config
<janneke>so it would be so great if childhurd in a guix vm worked, then we test/run the same thing
***apteryx is now known as Guest40591
***apteryx_ is now known as apteryx
<peanutbutterandc>(while I'm searching elsewhere too) does anybody know if there's a function like (glob "/path/to/asdf*") that would expand to "/path/to/asdf-3.3" in guile?
<guix-vits>peanutbutterandc: scandir?
<guix-vits>(ice-9 ftw)
<guix-vits>peanutbutterandc: (maybe not what U want)
<peanutbutterandc>guix-vits, I see. Thank you. I wanted something more like from python (but this works too. Thank you. For now I'll just go with hard-coded name)
<guix-vits>peanutbutterandc: (system "") with something of (ice-9 popen)?
<peanutbutterandc>guix-vits, hahahaha! :D
<guix-vits>* glob
<peanutbutterandc>guix-vits, lol I just wanted to do some guix packaging.
<civodul>in Guix you would use 'find-files', which supports regexps (not glob patterns)
<peanutbutterandc>civodul, Hello there! Yes, I think that is what I'll use. I was just wondering if there was something easier (as it's just one binary. Guess I'll just (car) from that list). Thank you
<efraim>where is the 3.3 from? could you use (package-version other-package) to get it?
<leoprikler>peanutbutterandc: (find-files dir "asdf-.*")?
*guix-vits giggles "third"
<jonsger>mothacehe: is it a known bug that an evaluation on CI doesn't show all jobs, whether they are failed, succeded or scheduled?
<mothacehe>jonsger: only jobs that do trigger a build (and which failure is not cached) are shown
<peanutbutterandc>wow. so many people are here to help. sorry I was away
<peanutbutterandc>efraim, yes, version number (3.3)... with the revision truncated (3.3.1) so yeah.... I can't do that
<efraim>peanutbutterandc: (version-major+minor (package-version other-package))
<peanutbutterandc>leoprikler, Hmmm... that seems to work! (I'll have to (car) though) Thanks!
<leoprikler>because find-files returns a list, yes
<peanutbutterandc>efraim, Ooooh! Cool! (guix utils) seems to have all the gems! I'll go for this one, perhaps! Thank you!
<peanutbutterandc>leoprikler, Yes. I remember, in GIMP, if I'm writing a plugin via scheme-fu (tinyscheme) I have to (car) on everything
<peanutbutterandc>I wonder if GIMP could use guile
<peanutbutterandc>that would be awesome
<PurpleSym>civodul: Found the issue with port-ascii-armored?. Fix see #43699.
<civodul>awesome, thanks PurpleSym!
<peanutbutterandc>okay... this does NOT seem like the correct way to add further arguments to an inherited package: (the wrap-phase did not work at all). What am I doing wrong? o.O
<Brendan[m]2>gimp can use guile, its just noone wanted to do that as a project. they always said sure , just send the patches and you will be the one to maintain it ;)
<peanutbutterandc>Brendan[m]2, I wish my scheme-fu (and C-fu) skills were that great...
<Brendan[m]2>perhaps one could implement tinyscheme as a language in guile
<peanutbutterandc>Brendan[m]2, lol. I still need to go through SICP. But I'll put this on my list of things to do someday when I get competent enough and nobody else has gotten around to doing it. :D
<peanutbutterandc>Now, regarding that thing: It seems that that is the way to add further arguments to an inhertied package (guix edit goffice)... so there must be something else going on here. *looking*
<guix-vits>Are anyone get that:
<guix-vits>`emacs`, M-x shell, guix pack TAB
<guix-vits>-| "Error in evaluating guile expression ..." ?
<civodul>guix-vits: yeah
<civodul>i thought it was due to my settings, but maybe not
<civodul>janneke submitted a patch to emacs-guix recently and i think we never got an answer
<civodul>might be related
<janneke>civodul: it took a while, but they picked it up: d246b2c elisp/misc: Update Emacs path if needed
<civodul>janneke: oh great!
<janneke>..but i think this is unrelated; i wrote a patch for guix-set-emacs-environment
<civodul>ah ok, my bad
<janneke>well, "unrelated" is too black/white: there's the "emacs-guix" relation ;)
*civodul .oO it'd be interesting if a guest's shepherd services could somehow be visible to the host
<Brendan[m]2>in #~(foo '#$bar), what effect does the ' have?
<mothacehe>janneke: I added support for compressed qcow2, and added a hurd-barebones.qcow2 image to the CI.
<mothacehe>Size goes from 1.5G -> 366M
<janneke>mothacehe: terrific!
<janneke>mothacehe: mental note to tell mihi about qcow2 compression for the hurd
<mothacehe>we also need to update the hurd-vm service
<mothacehe>so that it uses qcow2 format to save some space on berlin
<janneke>in progress? ...
<mothacehe>in progress means that it is evaluating if new builds are required
<janneke>mothacehe: ah, right -- guess we'll be seeing a hurd-vm update some time soon
<janneke>mothacehe: okay..could still compute => 0 then?
<mothacehe>but as long a 43668 is not fixed it will still be 0 I guess
<civodul>janneke: i've pushed wip-childhurd with a fix for unreliable startup
<civodul>works for me on bare-bones + hurd-vm-service
<civodul>lemme know!
*janneke goes to try civodul's new fix
<janneke>civodul: sure!
<civodul>what's annoying is that when you change secret-service.scm, you end up rebuilding the image of the childhurd inside the VM
<civodul>that takes quite some time and space
<civodul>(and my laptop becomes dog slow for a minute or so as the image is written to disk)
<janneke>yes, that's terrible
*janneke reading patches
<janneke>ah, so the suspect is a qemu port-connect race --- that makes sense
<janneke>moving to the end of the service list is also smart
<civodul>yeah i was seeing those "generating keys" messages followed by "receving files"
<civodul>not very efficient
<jlicht>hey guix!
<jlicht>civodul: I found a workaround for my spooky "/" permissions in a guix system container yesterday at #43673.
<jlicht>What _is_ the default set of permissions for "/" anyway? I went with 755, but I found it hard to find a sane default anywhere
<xelxebar>Cool, looks like Nix is getting support for IPFS as a "provider of source/build artifacts."
<xelxebar>I guess this means that upstream sources and well as build substitutes can use (or fallback to?) IPFS.
<nckx>Good morning, Guix'x.
<nckx>jlicht: 755 sounds pretty sane to me. Or rather: anything else does not.
<jlicht>hello nckx! it's good 'ol lucky 777 right now for some reason
<OriansJ`>nckx: 750 with the group being users is a good way to prevent system services from accessing certain programs they shouldn't need to access (assuming one doesn't have something like selinux or apparmor running)
<jlicht>honestly, I'm happy with anything that makes sshd happy ;-)
<OriansJ`>jlicht: most programs complain because their programmers were too lazy to think through what the implications would be if say nginx or apache spawned them because of a carefully crafted POST or GET request.
<nckx>OriansJ`: Honestly that sounds like a risky choice that will work until it doesn't, but more due to sloppy programming than a hard need, indeed. I have encountered daemons that barfed when they couldn't open / after I'd restored a back-up badly.
<nckx>Is FILE_OFFSET_BITS a temporary thing until (say) a core-updates merge? Or more boilerplate to remember?
***trava9626 is now known as travankor
<jlicht>unrelated, but is there anyone using Emacs 28-to-be native compilation on their guix system?
<PurpleSym>Is `guix archive --export` broken? It says “guix archive: error: corrupt input while restoring archive from #<closed: file 7f27c396e150>” on two of my machines.
<str1ngs>PurpleSym: do you have trust setup?
<PurpleSym>You mean a signing key in /etc/guix? Yeah. It worked previously.
<str1ngs>does the error happen on --export or --import? the error kinda implies --import
<str1ngs>you need more then just a signing key you need to authorize the public key on the importing end.
<PurpleSym>No, it’s export. Piping to /dev/null right now.
<str1ngs>ahh ok then this would not be a trust issue
<str1ngs>PurpleSym: are you using guix system?
<PurpleSym>No, foreign distro.
<str1ngs>have you guix pulled as root lately?
<str1ngs>on foreign I like to try and keep my guix describe on par if I can. ie guix describe as user then guix pull --commit=<hash> as root
<str1ngs>that should ensure guix daemon is upto date IIRC.
<PurpleSym>Yeah, 1 or two commits apart maybe. This was never an issue and the daemon protocol rarely changes, right?
<str1ngs>also after guix pull as root do a systemctrl daemon-reload the restart guix-daemon
<str1ngs>rarely changes is not quite the same as never changes of course :)
<civodul>jlicht: 755 for / sounds good to me
<civodul>PurpleSym: there are been changes recently regarding export
<civodul>foreign distro?
<civodul>i think you have to make sure root's guix-daemon and guix are in sync
<civodul>actually just "guix pull" as root should give you that
<str1ngs>thanks civodul that was the reason I mentioned updating the daemon. but I was'nt sure what the exact changes where.
<str1ngs>all I know is the changes made things faster! :P
<PurpleSym>I restarted guix-daemon and retried with root’s guix, same issue.
<civodul>PurpleSym: so "guix archive --export something >/dev/null" is failing, right?
<civodul>would be great if you could strace -p $(pidof guix-daemon) -f and try again :-)
<PurpleSym>Yup. I can actually see an error in the daemon log: guix-daemon: nix/libutil/ virtual nix::BufferedSink::~BufferedSink(): Assertion `!bufPos' failed.
<civodul>right, but there must be something before that
*civodul knows two debugging tools: strace and pk
<PurpleSym>Hm, +++ killed by SIGABRT (core dumped) +++ looks suspicious.
<divoplade>Hello guix! I have watched the recent FOSDEM "Universal package & service discovery with Guix A universal functional package manager and operatin..." (I guess it was truncated from operating system), by Pierre Neidhardt and I am glad to see someone talking about data as linked data! I am myself trying to implement the Solid authentication protocol ( in guile with Nettle, and it's not that
<PurpleSym>gdb backtrace:
<str1ngs>divoplade: hello, you message got truncated.
<divoplade>So I was saying that there is a recent FOSDEM video by Pierre Neidhardt, and he mentions data as linked data
<jlicht>don't click the gnuguix-drive thing, in case it wasn't clear
<jlicht>they've been spamming mailing lists for emacs, replicant and possibly more as well :/
<divoplade>And I just wanted to say that I'm trying to implement the solid authentication protocol in guile with nettle
<divoplade>This would be a great platform for publishing reviews and stuff I think
<divoplade>For the message truncation, is it because of the server or my client? I'm using srain (within guix, of course ;)
<str1ngs>divoplade: that solid in guile looks interesting. I'd like to add this to nomad at some point.
<divoplade>For now this is mainly me trying to combat undefined behaviour while crossing the scheme / C interface of nettle
<divoplade>(I mean, I am writing an interface between nettle and guile, and I have a lot of trouble, but I progress!)
<str1ngs>divoplade: would gcrypt work in place of nettle?
<divoplade>Maybe, but I've never used it and I could not find documentation for the interface
<civodul>+1 Nettle is a great library but gcrypt already has bindings:
<divoplade>Yes, I found it
<str1ngs>thing with gcrypt it is has bindings
<str1ngs>duh as civodul mentioned :(
<civodul>divoplade: there's a manual in there, it's incomplete but hopefully a reasonable starting point
<divoplade>I just need RSA and ECC signatures with SHA256, SHA384 and SHA512 (with and without PSS for RSA)
***ChanServ sets mode: +o civodul
<divoplade>I'm puzzled that nettle does not seem to find RSA + SHA384 interesting, even if it's an official JWT algorithm for signing
<divoplade>I will try to use it
<civodul>you're aware of ?
<civodul>divoplade: ↑
<divoplade>Yes, and it does not support RSA or ECC according to its readme
<civodul>it's under development though, i think it's very recent
<civodul>you should talk to them
<roptat>still waiting for a review for my groovy update :)
<roptat>if anyone is interested ;)
<roptat>and listening ^^
<civodul>roptat: we'll get there
<civodul>in the meantime, i think you have other issues reviewed and waiting for you :-)
<civodul>gotcha! ;-)
***ChanServ sets mode: +o nckx
*sneek roar!
*sneek roar! roar!
<raghavgururajan>Hello Guix!
<jlicht>sneek, you okay there buddy?
<roptat>civodul, ouch ^
<civodul>think of the feeling of relief when applying years-old patches
<raghavgururajan>sneek, botsnack
<apteryx>raghavgururajan: hi there!
<roptat>I never saw these reviews!
<civodul>c'mon! ;-)
<roptat>I receive too many email
<apteryx>roptat: is your email client configured to filter on the return-path ?
<roptat>no, I receive everything in my inbox
<roptat>and that's it
<civodul>do you remember that you actually wrote a DNS client in Guile?
<civodul>that's cute
<civodul>i'm sure we could do something nice with it :-)
<roptat>systemd has systemd-resolved, so we could have guile-dns :p
<civodul>and an mDNS implementation
<jlicht>I might be wooshing here, but I would think guile-dns would rather be a dns server
<apteryx>roptat: ah, that's :-P. I use this in my .gnus.el: Works great.
<apteryx>It puts every list mails in their own folder but leaves things addressed to me explicitly go to my INBOX
<apteryx>that makes it less likely that I miss these.
*civodul has too many folders
<roptat>I remember reading the RFC very carefully to build that dns client
<roptat>but that it didn't work in the test environment for some reason
<roptat>knot is running well though
<roptat>oh and maybe we should give more priority to the license issue. for the manual, I'm still missing approval from 3 people: one German, two Russian
<roptat>and we have to fix that issue with the guix.*.po and guix-package.*.po, that are attributed to you or the FSF
<civodul>can you ping the 3 remaining translators?
<civodul>po/guix/*.po has "Copyright (C) 2018-2020 the authors of Guix (msgids)"
<civodul>pl.po has "Copyright (C) 2016 Free Software Foundation, Inc.", which is quite an innovation
<roptat>civodul, I think they should all say "Copyright (C) 2012-2020 the authors of Guix (msgids)" (2012 being the start date of Guix, right?)
<roptat>and keep individual translators under that too, of course
<roptat>I know we can change the copyright when it says "copyright Ludovic", if you agree, but for the FSF, I'm not sure we can do that. Should we ask them for permission or something?
<civodul>roptat: we can definitely change "copyright Ludovic" to "copyright the authors of Guix"
<civodul>the same goes for the FSF: none of us assigned copyright to the FSF, AFAIK
<civodul>the FSF is not a copyright holder on Guix
<civodul>so the "copyright FSF" line is wrong, probably copy/pasted from another project
<roptat>some translators have, and may be also contributors to Guix, so I don't know
<roptat>also I found where the wrong license comes from, the package name for the manual is "guix", instead of "guix manual", but changing that I get this line: This file is distributed under the same license as the guix manual package.
<roptat>which is weird :/
<civodul>oh well, that line is probably good enough
<roptat>ok, I just pushed a fix for that :)
<roptat>I see our po/guix/Makevars is also wrong
<roptat>COPYRIGHT_HOLDER = Ludovic Courtès
<roptat>I think that's the reason why I did that too for the manual
<civodul>oh ok, that's the reason
<civodul>MSGID_BUGS_ADDRESS is also wrong :-)
<civodul>hasn't been touched since 2012-06-29
<roptat>should be bug-guix@ right?
<roptat>ok, fixed :)
<roptat>need to go, I'll be back in 30 mins
<rndd>hi everyone!
<rndd>can i use regex to substitute strings in snippets?
<ryanprior>@rndd yes you can use pretty much any Guile in snippets. However, depending on the use case it might be more idiomatic to create a build step to do the substitution.
<ryanprior>rndd: here's an example from the codebase
<rndd>ryanprior: thanks
<ryanprior>yw :)
<rndd>ryanprior: what does mean "blob" term?
<rndd>i see it from time to time
<roptat>I'm back
<ryanprior>@rndd a blob is a compiled, obfuscated, or otherwise obscure file for which there is no source provided.
<rndd>where i can find partprobe command?
<str1ngs>rndd: parted
<rndd>str1ngs: ohhhh
<rndd>thank you
<str1ngs>rndd: you are welcome
<user_oreloznog>Hi roptat :-) Thanks again for your answer about contribution on guix-devel
<roptat>oh that you! :)
<user_oreloznog>roptat: yes ;-)
<user_oreloznog>Is a good candidate for starting to work ?
<roptat>that's our current version
<roptat>although it's starting to be a bit old
<user_oreloznog>I've never contribute to a LL, It would be teh 1st time :-)
<roptat>also, FS :p
<roptat>as in Free Software
<roptat>oh, and if you feel more confident in French, you can use any language here, so feel free (you'll get less answers, since we don't all speak French)
<user_oreloznog>OK , good to know ? Penses-tu que je puisse commencer à m'entaîner avec ce fichier .po ou bien avec un autre ?
<roptat>tu peux utiliser ce que tu veux. une fois que tu as une contribution dont tu es fier, tu l'envoie au robot
<roptat>ensuite il te répond qu'il a rejeté tes changements et il te dit pourquoi, tu corriges et tu réessayes :p
<user_oreloznog>Ah... Je pensais justement utiliser celui que j'ai mentionné plus haut pour me faire la main. Ce n'est pas grave s'il commence à être un peu vieux ?
<roptat>non de toute façon on n'a pas plus récente pour le moment
<roptat>ah et tu peux utiliser offlate, c'est un petit logiciel que j'ai fait, il permet d'automatiser un peu la récupération et l'envoie des traductions
<roptat>il marche pas encore avec weblate par contre :/
<roptat>mais pour le TP, il marche bien
<user_oreloznog>Penses-tu que j'arrive à trouver un fichier .po pour me faire la main ? En aurais-tu un à me conseiller ?
<user_oreloznog>Plutôt noob ;-)
<roptat>tu peux essayer avec guix-packages, il n'est qu'à 10%, donc toute amélioration est vraiment bienvenue
<roptat>ah mais non tu peux pas, il m'est attribué
<roptat>je suis sensé travailler dessus ^^'
<roptat>bah guix-manual, de toute façon je travaille pas dessus en ce moment, tout ce que tu y feras sera utile pour la suite
<user_oreloznog>Ok, donc je peux donc m'entraîner sur ?
<roptat>yes, je te laisse la main dessus :)
<user_oreloznog>Super ! ça va être mon 1er essai !
<user_oreloznog>ça fait longtemps que je suis pas allé sur diaspora*
<roptat>ah et sinon tu peux aussi t'inscrire sur la liste de et faire un petit coucou
<apteryx>our tensorflow is in need of a major update
<user_oreloznog>roptat: OK ;-)
<civodul>apteryx: i vaguely remember rekado saying something about a Tensorflow upgrade along the lines of: "this is hopeless"
<roptat>but which kind of hopeless? maven-hopeless or scala-hopeless? :p
<apteryx>civodul: yeah I remember it too, I think it had to do with changing their build system to Bazel or something
<civodul>nothing's really hopeless to roptat :-)
<civodul>apteryx: yeah, Bazel is the only supported build system
<civodul>i think we're relying on a CMake-based thing that's no longer available
<janneke>hehe, go roptat!
<roptat>er... no, not bazel
<civodul>as if it could be more difficult than Maven :-)
<ryanprior>What's the issue with bazel in a nutshell?
<civodul>it doesn't fit in a nutshell
<roptat>too many dependencies
<civodul>also it depends on itself
<roptat>yeah but that's only a build system, we can always simulate that (if we know how it's supposed to work) like we do for maven
<joshuaBPMan>Hey guix, my guix deploy is failing...
<joshuaBPMan>guix deploy: error: failed to deploy locke-lamora: no matching pattern
<joshuaBPMan>I'll send a pastbin in a second...
<ryanprior>Does bazel-to-cmake not work anymore?
<civodul>roptat: yeah it's easy, we just need to add a Bazel frontend to Guix and we're done
<str1ngs>janneke: hello, emacsy should support multiple minibuffer. but minibuffer is a global binding and hard coded in (emacsy minibuffer). I'm debating making it a fluid or a parameter. let me know what you think would work best. this would be something I change later down the road. First I need to redo all the tests because there are many cases tests pass but they should'nt due to check.scm.
<roptat>easy :)
<ryanprior>(looking at Bazel's WORKSPACE) yep that's a lot of deps
<ryanprior>Speaking of which though, I'm making some progress cutting the gordian knot of javascript build systems. I'm convinced there's a way out but it's gonna be an adventure.
<ryanprior>I use javascript for work so I'm much more motivated there than in the java/bazel realm :)
<ryanprior>Anyhow I packaged quickjs in guix now, there we've got a fully compliant JavaScript ES2020 runtime with no dependencies other than gnu-build-system.
<ryanprior>I've also packaged (but not submitted upstream yet, will do soon) esbuild, which has only go-build-system and golang x/sys dependencies. It bundles javascript and typescript, like webpack.
<ryanprior>So between those two I hope to be able to clean up the nodejs bootstrapping story and upgrade our node package.
<ryanprior>I also hope to use esbuild to boostrap Rome, a js dev swiss army knife which aims to replace webpack, ESLint, Babel, Prettier, and Jest.
<ryanprior>Then that should open up a lot of js packages: we can scrape out their dependencies on things Rome replaces and package them.
<ryanprior>I'm hoping to create a rome-build-system to automate that.
*leoprikler wonders if rome-build-system will take more than a day for a given package.
<ryanprior>I will include an #:in-a-day? keyword argument which guarantees this
<ryanprior>Rome only dependencies are node and typescript. Typescript, of course, is written in typescript. But esbuild will hopefully let us short circuit that and get productive.
<jonsger>nice progress ryanprior !
<jlicht>ryanprior: no way, that is amazing news!
<janneke>str1ngs: that sounds like a good idea either way; i'm a bigger fan of parameters, although i feel civodul is becoming less and less enthousiastic about dynamic binding in general (the same holds for fluids i guess)
<jlicht>once we have esbuild, we might even be able to properly build node versions > 10.
<janneke>str1ngs: i'd just take the easiest step for you, first -- and like you say, changing it is probably trivial once you gained some experience with that first choice
<ryanprior>jlicht: yes, once I finish my current epic (packaging Hugo, which also depends on esbuild) my next goal is node 13.
<ryanprior>err node 12, I guess that's still the latest stable
<jlicht>easy there cowboy ;-)
<str1ngs>janneke: thanks for the feedback. I guess dynamic bindings are nice in the context of emacsy. what would be a better design paradigm do you think? also I made some progress in regards to GTK widget and emacsy buffer synchronization. see if you ever revisit guixmax. I'll try to pass my experience over to you. I think even more
<str1ngs>granular control can happen but it's alot more work and I don't want to replicate emacs ... quite yet.
<ryanprior>yeah I'm trying not to look into that too much. still lots of work to do on Hugo X.X
<ryanprior>Look how close I'm getting though! ':D
<jlicht>ryanprior: is this automatically generated? Either way, "nice"
<ryanprior>nope :|
<janneke>str1ngs: yeah that's the thing, a growing dislike for a feature does not always present an easy alternative, so tbh: i don't know ;-)
<nly>how do you add global directives to nginx conf?
<janneke>good to know about your minibuffer...some time soon nomad will already be a better guixmax than guimax itself :-P
<str1ngs>janneke: <widet-entry> turns a GtkEntry int a minibuffer I use it for the browser URI bar. the main minibuffer still uses GtkSourceView.
<jlicht>ryanprior: It is civodul who is now proposing a patch to add `cc` with his --with-toolchain patch series though, so you might want to revise your README
<janneke>str1ngs: ah, i see
<ryanprior>Oh dang I been following that, I will definitely update my readme after educating myself on with-toolchain
<ryanprior>**haven't been following
<str1ngs>janneke: but <widet-entry> is much more isolated and refined then how <text-buffer> and the main <minibuffer> are handled. widget synchronization is not easy.
<jlicht>ryanprior: omg esbuild seems to work with typescript! It doesn't seem to do any actual typechecking, but who cares :D.
<str1ngs>that's the spirit! lol
***daviid is now known as Guest14680
***Guest14680 is now known as daviid
<PotentialUser>Hi, im trying to add a printer with lp, i already added and configured cups in my config.scm and installed escpr, but when listing drivers with lpinfo i can only find 2 epson drivers, what should i do?
<PotentialUser>oh, nevermind, the cups web front end just detected it
<nckx>PotentialUser: Just in case: ‘installing’ printer drivers with ‘guix install’ doesn't add them to your system; you need to add them to (service cups-service-type (cups-configuration (extensions (list <here>)) ...)) in your system .scm.
<nckx>If you did so: disregard.
<PotentialUser>yeah i did that, but epson only lists 2 drivers still
<PotentialUser>and yes i reconfigured
<nckx>Same here: 9-pin and 24-pin series 😳
<rekado>re tensorflow: not everybody uses or even wants to use version 2.x; there’s a more recent version of 1.x, which we could upgrade to.
<nckx>Is that a literal serial/parallel D-port...
<rekado>it’s just a lot of busy work, made more complicated by the fact that the contributed CMake stuff has been removed.
<PotentialUser>i would use the generics to see if they work but i dont know what "kind" of print do i have
<PotentialUser>i guess the post-script one?
<rekado>there are third-party projects that provide a CMake build system for tensorflow, and there are experimental converters of Bazel stuff to CMake.
<rekado>like this one:
<rekado>it doesn’t work on the Tensorflow build system, though
<nckx>PotentialUser: How old is this printer? And how is it connected?
<nckx>Drivers have been deprecated for a while, although some old/USB printers still need them.
<PotentialUser>through USB, its a stylus tx300f so i guess kinda new
<nckx>Hmph, I've never owned an Epson, dunno what ‘ESC/P-R’ is supposed to mean.
<nckx>PotentialUser: Despite the USB, try ‘Generic’ → ‘IPP Everywhere’. It's what every single printer should be using according to CUPStream. Drivers are going away, although it's moving slowly.
<PotentialUser>lets see
<PotentialUser>if that doesnt work i will see if there is any ppd in the debian package
<nckx>(Background: first few paragraphs of
<nckx>PPDs have been deprecated for a long while, but probably won't go away soon.
<nckx>They're just text files with printer metadata that point to executables, they're not drivers (also deprecated) in themselves. You'll still need to package the driver if needed.
*nckx updates escpr to 1.7.7 in the meantime.
<PotentialUser>hmmm, yeah the IPP driver doesnt seem to work
<PotentialUser>can you make an issue about the escpr package in the tracker?, i dont really have access to my mail right now
<nckx>What's the exact bug? E.g., are there more model names available under ‘Epson’ on other distributions?
<PotentialUser>i would assume, i had no problems searching from drivers in artix
<nckx>But how did you search?
<nckx>Using the same CUPS manufacturer+model list?
<nckx>Or some wizardly tool?
<PotentialUser>hmmm, now that i look at it i had 2 packages installed
<PotentialUser>epson-inkjet-printer-escpr 1.7.7-1epson-inkjet-printer-escpr2 1.1.12-1
<PotentialUser>epson-inkjet-printer-escpr 1.7.7-1 and epson-inkjet-printer-escpr2 1.1.12-1 *
<nckx>PotentialUser: It would be helpful if you could say which one is actually needed. And 1.7.7 is currently being a pedantic dork about autotools versions.
<nckx>‘Fine 😒’ --
<PotentialUser>sorry, im looking into the details right now give me a moment
<nckx>NP. I just found a Epson-Stylus_Office_TX300F-epson-escpr-en.ppd in escpr-1.
<nckx>That's probably it?
<nckx>So no need to package v2, just a bug in our(?) v1. OK.
<PotentialUser>Ohhh, thats probably it
<PotentialUser>how do i use it?
<nckx>Er... well, the CUPS Web UI allows you to manually ‘upload’ a PPD file and it would be copied to /etc/cups, so you could ‘guix build escpr’ to get the store path & do so. That might still break later, dunno.
<nckx>I *think* the actual bug is that our escpr package installs PPDs to /share/ppd/epson-inkjet-printer-escpr/<foo>.ppd instead of /share/cups/model/<vendor>/<model>.ppd.
<nckx>So they don't show up in the list.
<nckx>☝ guess.
<nckx>I'll test whether moving them fixes that, which would be the much safer option.
<PotentialUser>That would be so nice, if you get any results tell me i will be connected, if there are no results i will try the guix build thing
<nckx>OK. If I don't get them to show up in the UI before I go to bed I'll let you know and open a bug report.
<nckx>PotentialUser: Pull and reconfigure and sudo herd restart cups and try again.
<PotentialUser>Nice!, will do
<nckx>It fixes the problem of models not being listed. Whether it prints you'll have to tell me.
<nckx>(The model ‘names’ are horribly long & noisy, but I think that's Epson's choice.)
<PotentialUser>you should probably go to bed btw, my internet is not that good so it will take a while until i can actually test the fix
<joshuaBP`>man, I'm having a really tough time getting guix deploy to work.
<joshuaBP`>Failed to read private key: /home/joshua/.ssh/id_rsa
<joshuaBP`>I'm not certain how that is my error message. I am running guix deploy as my regular user, which can read that file.
<nckx>PotentialUser: Don't rush. I'll be up for at least another half hour and can always read the backlog tomorrow. If the drivers themselves don't work, I can't do much more than open a bug for you.
<PotentialUser>nckx uhhh reconfigure didnt gave any output for a while so i re-ran it with --debug 4 and there is a LOT of "acquiring/downgrading write/read lock on /var/guix/temproots/numbers"


Content-Type: application/http; msgtype=response

WARC-Identified-Payload-Type: text/html

WARC-Type: response

text:
IRC channel logs

back to list of logs

<civodul>pkill9: it shows everything but there are some things it doesn't know in advance
<civodul>in those cases, it displays it another time later on
<pkill9>why doesn't it know them in advance?
<pkill9>sometimes it only shows a few things
<pkill9>like red-eclipse
<pkill9>only shows 33mb will be downloaded
<pkill9>but it's almost a gig in total
<lfam>The red-eclipse store item is 1 gigabyte, but Guix only reports it as 33 megabytes?
<pkill9>no, it only reports the first few dependencies
<pkill9>i just said it for effect
<pkill9>basically it means you can't see how much will be downloaded
<pkill9>and that was a good example of the discrepancy
<roptat>how would I start the shepherd in my chroot?
<roptat>looks like I managed to run it, though every service is failing
*lle-bout still hasnt done CVE entries, hopes people will help but also wants to work on other things and ignore CVE entries for now
<lfam>Alright lle-bout
<lfam>I'm going to take care of patching the `patch` package
<lle-bout>lfam: thanks! honestly not sure how to do this /stable thing, it froze my motivation because it requires me to understand someone else's undocumented work
<lfam>I understand what that's like: getting stuck because you are struggling to understand something
<lfam>I think we all experience it
*lle-bout acknowledges
<lle-bout>It's a bit tiring to spend most of your GNU Guix contribution time organizing changes in an incremental manner so that they can be committed individually, some times I spend more time thinking about that commit story than the actual changes to the code. I feel like that's a bad thing. I feel like maybe there's a way to accodomate that need for documentation of individual changes without that phenomenon
<lfam>Sometimes I do this kind of work during code review, on behalf of the contributor
*lle-bout reboots
<pkill9>nice to see lagrange is in guix now
<lfam>lle-bout: Welcome back
<lfam>I thought about your comment for a few minutes
<lle-bout>pkill9: there was a duplicate patch submitted
<lle-bout>pkill9: not sure which one's best but yeah, I bothered with unbundling and the merged one didnt
<lle-bout>lfam: hey, what do you think about it?
<pkill9>oh hmm
<lfam>It reminds me of a discussion I had with another person recently, about how the package synopses and descriptions can feel so hard to write after getting the package working
<lle-bout>I am thinking the first troublesome task of having to duplicate the 'what' of changes maybe it could be fully automated? I heard s-diff something from ludo one day?
<lfam>It's hard to change tasks from coding / packaging to what is basically writing documentaiton
<lfam>And, I think that making "good" Git commits is a form of writing documentation
<lfam>It explains the work
<lfam>The what could be automated in many cases
<lle-bout>lfam: I would say most the effort is not spent on documentation but rather on duplicating the 'what'
<lfam>But, in general, I recommend approaching these things as a different kind of work. Maybe it requires a break after the real coding part
<pkill9>there was a privilege escalation in sudo that time, how much do people really need to use sudo anyways
<pkill9>why not just swithc to another tty and run as root there
<lfam>I don't think that a nice changelog-style commit message merely duplicates the "what".
<lfam>It's invaluable in understanding the commit
<lfam>In some cases, it could be automated, but that doesn't mean it's the same thing
<lle-bout>lfam: for example, when adding a patch to a package, I spent most the time writing the commit message and with git
<lfam>Okay, but how much time are we talking about? One or two minutes?
<lfam>I think that the majority of the time wil be spent analyzing the problem, finding the patch, and making sure it has the desired effect
<lle-bout>lfam: I never measured but it wouldnt surprise me if it's more
<lfam>The case of adding patches to packages can definitely be automated
<lfam>I have a little script that writes linux-libre updates Git commits for me
<lfam>But, all these commit messages are exactly the same. "Add file, add it, use it"
<lle-bout>I am thinking that why do we have to automate generating commits etc. Can't we find a way to make it easier all the time for everything instead of having to write scripts to automate the same kind of stuff in different ways.
<lfam>Anyways, my point was that this kind of thing is a different type of work from programming. And thus should be treated differently. Maybe one takes a break before tackling it
<pkill9>there is a commit template used in emacs
<lfam>Well, certain types of commits are always the same (like adding a patch to a package). But other types of commits require some judgement from the author
<pkill9>with that emacs package
<lfam>I don't think we can discount this "human factor"
<lfam>Remember, the commit messages are there to help other people understand what was done without having to read all the code changes
<lle-bout>What I am saying in general is that I like to be creative, and I hate to feel like a robot
<lfam>Yes, I understand. I don't think we disagree. That's what I mean when I talk about "different types of work"
<lfam>It's why I often just handle this work on behalf of contributors, rather than making them do it
<lfam>In fact, writing their commit messages can be an integral part of review. If I can't understand the commit enough to write a good commit message, then I don't understand the commit at all
<lle-bout>I understand
<lfam>I would say, it's fine to not want to do this stuff, and it's fine to ask other people to do it. It's also fine to work on automating it, to the degree that is possible
<lle-bout>I like writing documentation but I hate feeling like I do redundant or robot work
<lle-bout>I feel empowered to write documentation when I understand how things actually work fully
<lfam>Do you have any ideas about how the workflow could be improved for you?
<lle-bout>I am not sure, it's got to start from feelings when doing it, maybe I am not the only one having those probably, I am thinking creating some kind of yas snippet that uses s-diff or something would be huge help already.
<lfam>It would be great to take advantage of s-expressions
<lfam>So much information is available to the computer with a language like Scheme, and we shouldn't hesitate to use it
<lfam>Really, a huge proportion of submissions need their commit messages rewritten, so there is a lot of room for improvement
*lfam finds himself restoring a "proof of concept" Git repo from 4 year old backups
<lle-bout>I feel like so many things conflict with the functional package manager idea in all Free Software that we spend time having to force it into the functional package manager model a lot, I feel like many theoretical problems are not fully identified and many workarounds are present in GNU Guix all over the place, when someone finds the Right Way to do something I feel like often it's not shared very widely even among committers.
<lfam>That's interesting
<lfam>It sounds like a FOSDEM talk :)
<lfam>Please elaborate
<lle-bout>I am thinking we miss some kind of packaging guidelines document for many kinds of packages, other people have suggested it before
<pkill9>i agree
<lle-bout>One recent example is the /stable thing, another is the GUIX_PYTHON_PATH thing, not sure what it solves, how are we going to incorporate it into GNU Guix
<pkill9>what's the /stable thing?
<lfam>foo/stable should be documented
<lfam>I'll write the docs when I deal with `patch`
<lfam>pkill9: It's a way to deliver security updates for core packages, in situations that are not really graftable
<lfam>It's something that requires some judgment about the security vulnerability, and some knowledge of how the package is used
<lfam>The crux of the matter is that grafts happen after building, so they don't affect what happens while building
<lfam>For example, there are some unfixed vulnerabilities in our package of the `patch` program
<pkill9>patch has vulnerabilities?
<lfam>Now, they may not be exploitable in the build environment, because we control exactly which patches are applied, there is no network access, and the environment is sandboxed
<pkill9>i assume something to do with malicious patches?
<pkill9>maliciously-written patches
<lle-bout>pkill9: To be less abstract for me, it's a mechanism that allows to discriminate between use during build and use by the end users, /stable package variants would be used by GNU Guix itself during builds where security is less critical, and the regular package would be used by everything else, this allows to reduce dependents of the regular variant so it can be updated freely without too many rebuilds
<lfam>But, since `patch` is a core part of how all packages are built in Guix, we cannot just update the package as normal
<lfam>Normally, we'd use a graft to deal with this situation
<lfam>But, since the vulnerabilities do not apply to the bulk of the use cases, there's no point
<lfam>Instead, we can leave alone the `patch` used in the build environment, and make a new package that you'd get from `guix install patch
<lfam>It's important to fix what you get with `guix install patch`, since that is what a human will use to apply whatever random patches they find online
<lfam>It's a very special situation in Guix, and we've basically ignored it in the past
<lfam>The reality is that "applying patches" is a security disaster
<lfam>It's only something you can consider safe in a situation like the Guix build sandbox
<lfam>All of these original Unix tools are like that
<lfam>But, we should still apply fixes as they are announced, despite the quixotic nature of the entire effort
<lle-bout>I feel like the review process is confusing because the way reviews are handled differs from committer to committer and there's no authority document for best practices.
<lfam>Hm, there are packaging guidelines in the manual
<lle-bout>Otherwise without such authority document, the only way to gather such knowledge would be through reviewing but since reviewing varies from committer to committer you only get confusing information
<lfam>The reality is that task requires judgment and discretion that can only be learned from experience
<lle-bout>Maybe we need to write more
<lfam>I don't think we should try to make a set of rules that a submission can either pass or not
<lle-bout>Texinfo has been a barrier for me too
<lle-bout>lfam: I didnt mean that
<lfam>Okay. I agree that the guidelines should be improved
<lfam>There is a lot of implicit knowledge that Guix old-timers have in their heads
<lle-bout>Texinfo as in writing in texinfo
<lle-bout>Lots of implicit yes
<lfam>For texinfo, I just copy what's already there. If it builds, I figure it's okay
<lfam>Texinfo has been identified as a barrier to contribution many times over the years, across all of GNU
<lfam>The question of why GNU uses texinfo instead of HTML has been argued since HTML was invented :(
<lfam>To be honest, I think it's a mistake to avoid HTML for this
<lle-bout>I wouldnt find HTML better but I probably just need to learn Texinfo
<lfam>Like, texinfo is fine. It is well-suited to the task. But it's a barrier, and it didn't catch on outside of GNU
<lfam>I was reading these arguments from the mid-1990s recently
<lfam>Well, at least HTML is popular
<lfam>It lacks a lot of nice things that Texinfo has. Texinfo is closer to normal writing, by a lot
<lle-bout>I can't write raw HTML in an efficient way for documentation, maybe Commonmark (Markdown) but that's it, or plain text
<lfam>Plain text isn't really suitable, since it lacks the formatting capabilities
<lle-bout>I like that Texinfo is a nice middleground between Markdown and verbose HTML
<lle-bout>verbose HTML or maybe even LateX
<reily>ORG is a decent option, which can export to just about any other format, and is familiar to Emacs users, which I would image is a pretty decent overlap with Guix users.
<lfam>I'm surprised Guix doesn't use org :)
<lfam>It's surely because you have to use texinfo in order to be a GNU project
<lle-bout>I don't think GNU Guix should adhere to GNU programming guidelines at all times, especially if those don't make sense to GNU Guix itself and it's contributors.
<reily>Just export to Texinfo from org :p
<lfam>Well... maybe you get your wish one day lle-bout
<lfam>I'm not sure the dictatorial nature of GNU will continue for much longer
<ryuslash>I like Texinfo, at least for reading, I haven't done much writing. I can't bring myself to write in anything other than org, though... I've heard good things about AsciiDoc too
<ryuslash>although so far even org-mode doesn't have as nice a reading experience as Info-mode in my opinion :)
<lle-bout>Additionally, I value that contributors come with their skillsets and that I feel like striving to make use of these skillsets without enforcing that those contributors learn too many things in a way that creates a barrier to contribution.
<lle-bout>E.g. people not knowing Texinfo wanting to write documentation being barred, people not using GNU Emacs being barred because all tooling for GNU Guix exists only there and doing it outside of GNU Emacs feels like a nightmare often
<lfam>I've never used Emacs
<lfam>I don't know, it's not a "nightmare"
<lfam>It's definitely a situation of "give and take" between submitters and reviewers
<pkill9>i like the idea of emacs but it feels like it has a steep learning curve
<pkill9>but maybe I shouldn't be intimidated, i'v elearnt to use guix, lol
<lle-bout>My statements are probably hyperbolic but I just want to outline the idea
<pkill9>well, to make packages
<lfam>I agree that there are barriers to contribution
<lle-bout>I don't know how I'd do to contribute to GNU Guix without GNU Emacs that I had to learn specially for GNU Guix
<lfam>I would call them "hurdles", which has less of a pejorative connotation
<lfam>I mean, contributions require strong Unix skills, and medium Git
<lfam>It's not unreasonable that people who want to contribute should know how to use a Unix system at the command line
<raghavgururajan>I see texinfo as a meta-format, where you can then export to any different formats like html, pdf epub etc.
<lfam>Ultimately, there are skills required to use Guix, and they largely overlap with the skills required to contribute
<lfam>I'd like for Guix to be easier to use. We really need a package management GUI
<lfam>But for now, it requires a strong grasp of command-line operation, things like enviroment variables, permissions, service management, etc
<lfam>It's not for beginggers
<lle-bout>lfam: I think many things in GNU Guix can be done without a lot of knowledge and that's also really attractive for including more people within the project, but the barriers prevent it somehow.
<lfam>I do see myself as exceptional in some ways, in terms of learning how to use Unix (it's been over 15 years)
<raghavgururajan>> lfam: I'd like for Guix to be easier to use. We really need a package management GUI
<raghavgururajan>+1. In far future, once I get good at programming, I am planing to do this using GNUstep.
<lle-bout>raghavgururajan: does GNUstep work?
<lfam>I mean, even configuring services on Guix seems wizard-like to me
<lfam>It's why I use Debian and enjoy systemd / journald
<raghavgururajan>lle-bout: In Guix? No idea. I was looking at GNUstep one day and like it.
<lfam>There's a lot for us to learn from systemd
<lfam>I couldn't go 100% Linux until Debian adopted systemd, because service management was too arcane
<lfam>Systemd really understand how to design a UI
<lle-bout>raghavgururajan: I never saw any program use it
<lfam>Systemd has complex areas, but the simple things are very simple
<reily>ONe thing I really miss from systemd is being able to easily get logs for services
<lfam>Integrated service management and logging
<raghavgururajan>lle-bout: Not many software use GNUstep. If my attempt with it fails, then I might to turn to gtk.
<lfam>It just works, the way you want
<lfam>lle-bout: You should write your ideas out some more, before you forget them. Before you know it, you will have Stockholm Syndrome
<ryuslash>speaking of things that are simple in Systemd, does Guix (Shepherd?) have any concept of user services?
<lfam>Kind of, ryuslash
<lfam>You can run Shepherd as your user, but it's completely disintegrated from the system. There is not even a way to start your user's shepherd at boot
<ryuslash>lfam: that sounds less than optimal
<reily>You can run a separate shepherd service as a user. There are some utilities that attepmt to integrate this, such as guix-home, but they are still very alpha
<lfam>Here's a good example of implementing it, ryuslash:
<lle-bout>lfam: It's difficult to transform feelings into precise factual problems
<lfam>lle-bout: Feelings are valuable
<lfam>You can just write your feelings
<ryuslash>thanks for the links :)
<lfam>In the long run, we want this stuff to be as integrated and sophisticated as systemd. But, we have work to do
<lfam>Guix is not an "anti-systemd" distro, by any means
<lle-bout>About GNU Shepherd, the way I run it as my user is bad because somehow it's run with a different version of GNU Guile and all existing .go wont load.
<lfam>That's weird :/
<lfam>And sad
<lle-bout>I use .desktop autostart files but it does the same thing with .bash_profile
<lfam>It doesn't happen for me, but I guess I update my user profiles along with the system profiles, at least for major updates like Guile
<lle-bout>I also do that, I don't have anything in my user profile
*lfam looks at their Guix System machine
<lfam>Hm, my Guile is just /run/current-system/profile/bin/guile
<lfam>How could it be finding some different version of Guile? I don't know
<lfam>One of many problems that should be fixed before we can call it "user friendly"
<lle-bout>lfam: it seems my GNU Guile is 3.0.5, and GNU Shepherd is compiled against 3.0.2
<lfam>I see
<lle-bout>I didnt do anything to get such newer GNU Guile
<lfam>3.0.5 is the current version of Guile in Guix
<lfam>But yes, sheperd depends on 3.0.2
<ryuslash>lle-bout: I don't suppose this is about uprading your guix daemon, right? (I'm not very knowledgeable about Guix yet :)
<lle-bout>lfam: the shepherd script starts GNU Guile 3.0.2
<lfam>Well, my approach is very crude
<lfam>Whenever the system reboots, I log in over SSH and do `[ -z $(pgrep -U $(id --user) shepherd) ] && shepherd` and then close that virtual terminal
<lle-bout>but somehow all .go get rejected and basically starting GNU Shepherd means wasting time with stat etc.. at startup checking .go files then basically recompiling every guile object somehow..?
<lle-bout>(in memory)
<lfam>It's bogus
<lfam>With systemd, it just works, and there is even `loginctl --enable-linger` if you want it
<lle-bout>As Andrew Tropin said, we must get some PAM stuff to start GNU Shepherd at login
<kozo[m]>May I have a 2nd set of eyes? I don't know what is weird about this command. If I remove --container it works fine.
<kozo[m]>guix environment --container --network --preserve="^DISPLAY$" --ad-hoc firefox -- firefox
<kozo[m]>guix environment: error: mount: mount "/home/guix" on "/tmp/guix-directory.yhqH8l//home/guix": Invalid argument
<lfam>Does /home/guix exist?
<lle-bout>kozo[m]: as a workaround, add --no-cwd
<kozo[m]> [lle-bout]( Thanks. It gives me another error but a good error
<kozo[m]>That worked
<lfam>This reminds me of <>, which is a blocker for the upcoming release
<lfam>Release blockers: <>
<raghavgururajan>Shouldn't it be /home/user/guix?
<kozo[m]>guix@zippy ~$ pwd
<raghavgururajan>Ah okay. Never mind!
*raghavgururajan thought it was cloned guix repo
<kozo[m]>At least it's on the radar or smart people
<lfam>I'm not sure which smart people you're talking about :)
<lfam>We are all smart after we learn :)
<lfam>And we all begin as babies!
<lle-bout>Let's say people have varrying interests and obsessions which make them learn and be good at different things.
<kozo[m]>So my other error was solved by exposing my Xauthority file so this works for me
<kozo[m]>guix environment --container --no-cwd --network --expose=/home/guix/.Xauthority --preserve="^DISPLAY$" --ad-hoc firefox -- firefox
<lfam>Oh nice, so that works?
<lfam>I wonder if we could copy that example, but use Icecat, to fix 47097
<kozo[m]>Let me try icecat
<lfam>I don't really want to focus on that bug... I hope someone else fixes it :)
<lfam>Absolutely lle-bout
<kozo[m]>swapping firefox with icecat works for me. Fonts are messed but it runs
<lfam>The fonts!
<lfam>Somebody just hit that issue again!
<lfam>And I marked the email as read and archived it again
<lfam>I wish we would just hardcode some fonts and be done with it
<lle-bout>lfam: I am thinking we need some better mechanism here, some kind of package parameters but better
<kozo[m]>While on the topic of fonts If you are trying to use Duolingo with Firefox or Icecat, you need to use FONT-GOOGLE-NOTO
<lfam>lle-bout: You mean for fixing Icecat's missing fonts?
<kozo[m]>Hopefully that saves someone time
<lle-bout>lfam: and lots of other things, yes, fonts are some kind of external state which the user must provide or Icecat package shouldnt even install
<lfam>Is that because noto has full Unicode coverage kozo[m]? Like, other fonts are missing glyphs for all the languages?
<lfam>I think it makes sense for `guix install icecat` to give a working browser. However it's achieved is not as important
<lfam>If it was a rare problem, I'd feel differently
<lfam>But it gets reported constantly
<kozo[m]>Not all the fonts, it specifically fixes Japanese. Though when looking for that answer, it sounds like it has knowledge of glyph type characters for Japanese and Chinese
<lfam>IIUC, the point of noto is that it has *everything*
<lfam>That is why it was created
<lfam>It's like the corporate edition of GNU Unifont
<lle-bout>/.icecat-real:75): Pango-WARNING **: 02:07:30.548: failed to create cairo scaled font, expect ugly output. the offending font is 'DejaVu Sans 9.9990234375'
<lle-bout>After: guix environment --pure --container --expose=$HOME/.Xauthority --no-cwd --network --preserve='^DISPLAY$' --ad-hoc icecat font-google-noto hicolor-icon-theme font-dejavu -- icecat
*lfam afk
<kozo[m]> [lfam]( SEe you
<kozo[m]> [lle-bout]( Running that command I get the same error except it says Sans 11
<lle-bout>I also get those: (/gnu/store/yww6abq4cly81a94ynirvql6rx3b22yg-icecat-78.9.0-guix0-preview1/lib/icecat/.icecat-real:336): Pango-WARNING **: 02:15:56.977: font_face status is: file not found
<lle-bout>(/gnu/store/yww6abq4cly81a94ynirvql6rx3b22yg-icecat-78.9.0-guix0-preview1/lib/icecat/.icecat-real:336): Pango-WARNING **: 02:15:56.977: scaled_font status is: file not found
<lle-bout>not sure what file is missing
<lle-bout>strace gives little clues
<apteryx>rekado: by the way, thanks for the xpath clues you provided some time ago; they were used as part of the recent go importer update
<apteryx>lle-bout: by the way, DISPLAY is already a precious variable in pure environments, so you don't need to explicitly preserve it
<apteryx>see (guix scripts environment) for the full list.
<PotentialUser-15>Hey, I'm trying to install Samba but whenever I run samba-tool, Python throws an error after failing to import the talloc module. Any advice? Brand new to guix, here
<PotentialUser-15>Is this the right place for general Guix package support?
<lfam>Yes PotentialUser-15
<lfam>I don't know the answer to your question though. Stick around and I'm sure someone will have some advice
<PotentialUser-15>All good, I managed to fix it by explicitly setting the PYTHONPATH environment variable
***iyzsong-- is now known as iyzsong-w
<Frosku>How can I set a /sys file's contents on bootup? (brightness for laptop)
<BlackMug>hi there
<BlackMug>can i request for free packages which can be added to guix ? like i send package request in guix bugs ?
<BlackMug>(not me adding the package, just a request)
<BlackMug>though it outdated
<BlackMug>some of the packages already shipped
<BlackMug>hmm yeah seems like that wishlist is like dropping the coin in the water and say your wish...
<abcdw>hi guix!
<tissevert>hello guix!
<abcdw>long actions like delete-generations is a little missaligned in guix system --help, do we need to realign all other action's docstrings?
<avalenn>hello guix!
<lfam>That would be great abcdw
<abcdw>lfam, good, will send a patch.
<mothacehe>hey guix!
<civodul>Hello Guix!
<mothacehe>hey civodul!
<abcdw>hello mothacehe, civodul!)
<abcdw>lfam: Sent the patch
<efraim>hello guix!
<mothacehe>hey efraim!
<civodul>mothacehe: what's the status of adding "dover" as an aarch64 build machine?
<civodul>i see Andreas committed changes to the config, which looks like we're getting there, right?
<mothacehe>he had problems with Cuirass package for aarch64
<mothacehe>but I "solved" them by disabling tests on this arch
<mothacehe>seems there's a transitory fiber related issue
<mothacehe>on aarch64
<mothacehe>anyway I guess it shoud work now. The wip-dover branch also seems fine.
<mothacehe>we just need to authorize the dover wireguard public key on berlin
<civodul>oh nice
<mothacehe>civodul: about Andy's Guile read implementation: does this mean we can get rid of suspendable ports dance in Fiber?
<wingo>mothacehe: the default ports implementation is still the C one, i.e. not suspendable
<civodul>Fibers relies on suspendable ports
<wingo>so you do need to "turn on" suspendable ports to get suspendable "read"
<civodul>but read in Scheme means we no longer have to call read in a thread or whatever crazy thing we had to do in Cuirass :-)
<civodul>which is pretty cool
<mothacehe>yeah that's great! thanks wingo :)
<civodul>mothacehe: one thing i'd like to do but i'm not sure we can is adding a "guile" jobset
<civodul>it would track both the 'guix channel and the Guile repo (not a channel)
<civodul>and the Guile repo would would provide a guix.scm file
<civodul>or a manifest
<mothacehe>civodul: mmh that's tricky I haven't thought about this use case yet
<mothacehe>we could maybe have a new build type "package-from-git" that takes as argument a package name and a git url
<mothacehe>but that sounds hacky
<civodul>mothacehe: maybe we just need a way to specify non-channel inputs?
<wingo>or synthesize a channel from a git repo with a guix.scm
<mothacehe>the new evaluation mechanism is built around channels
<mothacehe>it does the same thing as "guix pull" roughly
<civodul>wingo: yeah, that could also work
<mothacehe>so having non-channel inputs seems complex
<mothacehe>yeah having an extra channel providing a "guile-master" package could work
<civodul>non-channel inputs would trigger builds but wouldn't be passed to "guix pull"-y code
<civodul>actually a 'guile-master' package isn't enough because it wouldn't be rebuilt when something's pushed to Guile
<mothacehe>mmh right
<mothacehe>i need to think more about that, but that sounds like an important feature
<mothacehe>unrelated: I fixed system tests with: fc37346f
<mothacehe>the current-guix-package scope was wrong
<civodul>oh, great that you found out!
<mothacehe>let's see what the coverage now :)
<mothacehe>we already have guix, tarball and images subsets at 100% coverage
*civodul tries "guix weather -m etc/release-manifest.scm"
<civodul>looks like we're missing cross-compilation jobs, like /gnu/store/76cz0iwrx9g5rpbplfvcg09aqi2ipql7-guile-3.0.2.drv (x86_64 to powerpc-linux-gnu)
<mothacehe>indeed, some red circle for powerpc stuff here:
<civodul>ah, i'll look into it
<civodul> <- just saw the percentages, neat :-)
<civodul>i think we could even drop decimals
<mothacehe>yeah vincent also proposed it, will do
<civodul>hmm i can't locate the jobs corresponding to cross builds in the interface
<civodul>also the .drv above is missing from berlin; it could have been gc'd, but it could be that it just wasn't computed
<mothacehe>the jobs are sorted alphabetically in the dashboard, so its possible to find the powerpc jobs but very tedious
<mothacehe>the search is operating on nix_name so we cant use it to find those jobs
<efraim>I've only looked at it on my phone, if I hover with the mouse can I see what it is?
<roptat>hi guix!
<mothacehe>nix_name = "gcc-7.5.0", job_name = "powerpc64le-linux-gnu.gcc.x86_64-linux.x86_64-linux"
<mothacehe>efraim: yes it shows the job_name on hover
<mothacehe>and opens the related build on click
<mothacehe>maybe I should add a filter input to the dashboard
<civodul>hey roptat!
<civodul>mothacehe: through the search box i couldn't find it
<mothacehe>yeah see the nix_name vs job_name explanation above
<civodul>ah ok
<civodul>BTW, from an accessibility viewpoint, it might be best to use blue/red rather than green/red for the dots
<mothacehe>yes! I expect it will be one of the conclusions of the accessibility report
<mothacehe>but i should maybe anticipate it
<roptat>finally got my DNS back up, but my server is still down :/
<civodul>roptat: oh, what went wrong?
<roptat>it doesn't boot anymore
<roptat>it's my arm server, I tried booting older generations, but none of them works, it's stuck at "Starting Kernel..."
<roptat>so I suspect something changed in u-boot that it doesn't like, because I kept all my generations from the first one, and none of them boots
<roptat>now, I just learned that this message is from the compressed kernel wrapper that tells it's decompressed the kernel and is now running it
<roptat>meaning that whatever u-boot did, the kernel probably doesn't like, whichever version it is
<roptat>I believe it used to work with u-boot 2020.10, and now fails with 2021.01, but I can't guarantee, as it doesn't reboot very often
<roptat>the server is at my parents' house, so I spent the week-end bugging them, and managed to make them install a foreign distro on the SD card (I still have the guix system on the disk)
<roptat>so I have ssh access to the foreign distro, but I'm pretty sure if I just reinstall guix on the disk, I'll have the same issue again
<roptat>found out that getting a serial console is very hard on windows...
<civodul>roptat: d'oh, not great
<civodul>perhaps vagrantc would know if something changed in u-boot
<roptat>civodul, and at the same time my backup server (for email) crashed because of an hypervisor issue (a bug in qemu apparently) ^^'
<roptat>great timing!
<roptat>it's up now, but since it was also my secondary for DNS, it couldn't connect to the primary to get the zone info, I'm just getting all the emails from the week-end now
<roptat>I'll ask on help-guix I suppose
<qyliss> /go
<BlackMug>hi there
<BlackMug>how can i add my own repo to guix? i couldnt find that (tried) in guix manual
<tissevert>do you mean setting your own channel ?
<BlackMug>yeah like adding repo to debian you will add https repo to sources.list and add the key to it and done
<BlackMug>how to do that in guix?
<BlackMug>fedora/dnf same thing if i remember correctly
<roptat>BlackMug, do you mean substitutes for packages that are in guix, or for defining new packages that are not in guix yet?
<BlackMug>packages are not in guix yet
<roptat>that would be a channel, it's documented I think, let me find the page in the manual
<BlackMug>ok , wonder why not guix using common stuff used by decades from main distros like debian fedora...
<roptat>because it doesn't match our packaging model
<BlackMug>no i mean stuff like sources.list , interfaces..etc
<roptat>well, we use channels.scm
<roptat>^ if you want to use an existing channel, instead of creating a new channel
<roptat> sources.list is a mix of package definitions and substitutes for instance, we split the two concepts, so channels add more package definitions, and substitute servers provide substitutes for them
<roptat>you define channels in ~/.config/guix/channels.scm (one per user), and you allow substitute servers with "guix archive" by allowing their public key
<roptat>(and you can specify more servers on the command line and on guix daemon invocation, though it won't download anything that's not present on the servers you accepted the keys)
<roptat>I don't feel like I'm being very clear ^^'
<BlackMug>i see, isnt easy but not bad
<BlackMug>roptat correct me if im wrong: to have full upgraded guix one need to run guix pull , guix upgrade , sudo guix system reconfigure /etc/config.scm am i right?
<brendyyn>There is no such thing as propagated-native-inputs?
<roptat>brendyyn, no, I don't think it makes sense?
<brendyyn>roptat the idea would be all dependant packages would have the native-inputs intersected
<roptat>BlackMug, I'm not entirely sure which guix is run with sudo
<brendyyn>i thought thats what propagated inputs did in addition to making them go in to the profile
<roptat>I think it's correct, you could check with "sudo guix describe" it should tell you the same as "guix describe" as user
<efraim>does anyone have a router os-config for guix I can use as a starting point?
<roptat>brendyyn, oh, then propagated-native-inputs would not go to the profile, but it would still be propagated in dependent packages?
<brendyyn>roptat is it not ok for native inputs to go in the profile?
<roptat>BlackMug, then that should be correct :)
<roptat>brendyyn, no, it's another architecture
<roptat>well, when you cross-compile
<roptat>that's why we keep build-only dependencies in native-inputs
<brendyyn>in some cases its normal to have 32bit libs, like alsa pipewire. or is that the same "architecture" ?
<roptat>I guess you could have 32bit libs (I don't think we do), but you need to specify that explicitely
<roptat>native-inputs is for cross-compilation, you don't want armhf binaries in your x86_64 profile
<brendyyn>true. just wondering.
<roptat>civodul, any idea about "cannot pivot old root directory"? from inside a chroot?
<roptat>found a workaround, apparently systemd was interfering
<roptat>I see u-boot was updated, so I should be able to run guix pull now, and build with the newer u-boot
<felipebalbi>does one need to be subscribed to guix-patches in order to be able to send patches? I've sent a patch several hours ago but still can't see it in the archives.
<brendyyn>felipebalbi: no but if its your first time i think it will go in a queue to be checked for spam by a human. so maybe within a day itll go through the first time, and then you can post as much as you want
<felipebalbi>brendyyn: understood, thank you :-)
<nefix>Hello! Is it possible to add services to a Guix env?
<felipebalbi>another question: what's the correct way to ensure I have pdftex and texi2dvi as native-inputs for a package? I tried adding a package that requires it for building documentation, but it always failed with a permission problem on a file that was read-only. guix tried to write to it
<roptat>felipebalbi, it can happen when it's from a git repository, the files are all read-only
<roptat>you can add a phase to make them read-write, then you shouldn't have any issue
<felipebalbi>roptat: thanks, I'll try to find out how to do that :-)
<ekaitz>hi, i sent a patch a couple of weeks ago and I didn't get any answer
<ekaitz>did anyone have the chance to make a superficial review?
<nefix>Also, does nix-import work? When I tried to use it, it hang and never ended
<ekaitz>or is it blocked for a reason?
<nefix>`guix import nix`*
<brendyyn>ekaitz: you might be able to simplify it by using #:configure-flags instead of setenv
<brendyyn>not sure if cmake-build-system has that
<rekado>ekaitz: this looks pretty okay to me. I’ll apply it in a few minutes with a few changes.
<ekaitz>i tried extremely hard to solve it
<ekaitz>but cmakeflags don't work as expected
<rekado>brendyyn: oh, right, the cmake-build-system does have a knob for that.
<ekaitz>rekado: i didn't find how to solve, if you give me some clues, I'll fix it
<civodul>roptat: that error message must come from a failed pivot_root(2) call (in the daemon?), but i can't tell much beyond that
<roptat>civodul, thanks, I found a workaround
<rekado>ekaitz: I think you can use “-DCMAKE_EXE_LINKER_FLAGS”, but you don’t need to revise it. I’m working on it now.
<ekaitz>rekado: I want to learn for the future, but it's fine! thank you for fixing it :)
<rekado>nefix: the nix importer was perhaps useful in the early days, but in recent years I haven’t heard of even one successful application of the nix importer. I think it’s just broken.
<nefix>rekado: oh :( Thanks!
<rekado>ekaitz: some more comments: I would move the arguments field below the build system, because conceptually these are arguments for the build system, so mentioning the build system first feels right to me.
<rekado>the unquotes (“,”) don’t need to align and it feels odd to do that
<rekado>we don’t call things “open source” (or “free software” for that matter) in descriptions
<ekaitz>ok! thanks, do you want me to fix it myself?
<rekado>because all software in Guix is free software (or “open source”)
<rekado>ekaitz: only if you want to do that :)
<rekado>I don’t mind changing these things myself as part of the review
<ekaitz>me neither, maybe it's faster if you do it, so I don't need to share it with you again and all that
<ekaitz>but I don't mind doing it
<rekado>oh… I’m not a fast person.
<terpri>out of curiousity, is it possible in practice to assign copyright to the fsf for guix contributions, despite it not being required? (one'd still get credit via the commit info after all)
<rekado>but we can indeed avoid another round-trip by email ;)
<rekado>terpri: I don’t know how that would work
<terpri>rekado, same, i don't recall anyone trying it
<lubrito>Hi cbaines_
<rekado>ekaitz: what copyright line should I add to graphics.scm for you?
<ekaitz>rekado: oh! I forgot it! There's my copyright line in engineering.scm already.
<ekaitz>my nick is my actual name, so you'll find it
<terpri>there are only 20 FSF copyright lines afaict, mostly copied files, patches, etc.
<lubrito>cbaines_ I think I'm almost there, but I think that the code is not the prettiest. Can you see what I've got until now and tell me if I am in the right path?
<lubrito>what could be a good way to share a screenshot of the current json output?
<cbaines_>lubrito, hey, I can have a look a bit later, would be be able to email with what you've got so far, and I'll take a look when I can?
<rekado>ekaitz: okay, I’ll copy it from there.
<cbaines_>For context, this is Outreachy and Guix Data Service related
<ekaitz>rekado: thank you for your time
<rekado>ekaitz: nah, sorry for letting your patch sit in the queue for so long! You know how it is… :)
<rekado>I’ll push the addition of openvdb in a moment (after moving away some commits I had been working on)
<ekaitz>the Blender fix should be easier but it takes ages to compile... I had a good time with it
<terpri>lubrito, paste a .ppm or .xpm maybe ;)
<ekaitz>also, i'm currently updating freecad and guess what? ages to compile again haha
<rekado>ekaitz: I’ll just trust you that it builds. I’ll leave it to the build farm to prove us wrong :)
<rekado>ekaitz: you added libxxf86vm to the inputs; is that related to the addition of openvdb?
<rekado>if so: how?
<ekaitz>I checked nix package and they had that as an input
<rekado>that’s … not sufficient to justify it ;)
<ekaitz>yeah, true
<ekaitz>let me compile it without it, maybe we don't need it
<rekado>if you happen to rebuild blender anyway perhaps you could remove that input.
<rekado>thank you
<ekaitz>i'll do it now, so we'll know in half an hour :S
<rekado>if it’s too much to build blender on your machine: we could push the commit to wip-blender and have the build farm work on it.
<rekado>I’m sure it won’t mind.
<rekado>it may still be useful to add that input, but I’d rather add it in a separate commit with its own justification.
<ekaitz>don't worry, i'll build it myself and I'll dig on blender docs to see if it's necessary
<rekado>otherwise our future selves might misremember the reason to add it in a commit to enable the voxel remesher.
<rekado>okay, thanks
<ekaitz>it's probably needed for video editing but nothing else
<rekado>the openvdb addition is now pushed as commit f53ec9d99b
<rekado>(FWIW: I use the blender sequence editor and hadn’t noticed any missing features there)
<ekaitz>yeah, sometimes they are hidden missing things like the voxel remesher
<ekaitz>it's only one specific option, if you don't use it you don't notice
<ekaitz>it's listed here:
<ekaitz>but I need to find why is it needed
<sss2>hi all, after recent update evolution do not see acounts (email accounts, dav accounts)
<ekaitz>rekado: it looks like a basic dependency for blender that includes the XF86 video mode (which I don't know what it is)
<ekaitz>it is compiling right now (20%) but the configure step said XF86VMODE was on even with the dep removed
<ekaitz>maybe we are propagating it from other of the outputs?
<ekaitz>in fact, there are some other libs missing from the list i shared
<rekado>yes, perhaps it’s due to propagation
<rekado>if it’s explicitly checked for then it should be an input.
<rekado>but it would be better to put that change in a separate commit, because it’s really unrelated.
<ekaitz>ok, I'll prepare a separate commit with all the libs that are supposed to be an input
<ekaitz>when it compiles I'll confirm that the voxel remesher works without it
<ekaitz>(it probably will)
<rekado>ekaitz: thank you
<ekaitz>rekado: worked, so libxx86-vm not needed for the voxel remesher, sorry for the mess
<ekaitz>i'll prepare a new (separate) commit with all the deps when this merge is done
<kisaja[m]>Is somebody working on libreoffice 7.1, we now have 6.4
<civodul>roptat: are you done with changes to Guile-Git? i'd like to cut a release
<civodul>i remember we discussed folders last time
<roptat>civodul, right, I was having issues finding my way around the GC, so I can't do better than what I have on my branch
<civodul>roptat: does your branch have additional things compared to 'master'?
<mdevos>Hi #guix
<felipebalbi>hey mdevos :)
<roptat>civodul, yes
<civodul>roptat: right, silly me
<mdevos>Is v3 of the IPFS service definition good? <> It has been twelve days now without comments
<civodul>roptat: merged!
<civodul>mdevos: oops, my bad, i hadn't seen it
<civodul>lemme see
<roptat>civodul, pretty cool, thanks :)
<dongcarl>mjw: Do you remember how you solved this problem?
<lfam>Does anybody know where the 'core' file is found on Guix System after a segfault?
<mdevos>lfam: I don't ever have seen 'core' files on Guix System, even though I've seen a few segfaults
<mdevos>I think you need to manually ‘enable’ core files somewhere
<lfam>I don't know very much about this stuff...
<lfam>`make update-guix-package` segfaults, and ludo asked me to send the core file
<lfam>I don't know if it actually is dumping the core or not though
<mdevos>Maybe <> helps?
<mdevos>Or <>
<lfam>Thanks mdevos
<lubrito>hey, I sent an email to but it didn't show up until now. I'm already subscribed to the mailing list.
<lubrito>does the email have to be accepted or something?
<mdevos>I think the first e-mail has to be accepted, but subsequent don't. At least that's the case for some other mailin lists;
<lubrito>I see. Thanks
<myglc2>Hello! I need to run multiple octoprint (python) instances. Each uses 1 USB port. Suggestions?
<myglc2>I'd like to make them part of the sys fig & have them run at startup.
<roptat_>lubrito, it has to be reviewed by a human first, so it can take up to a day. Following emails will go through immediately
<roptat_>myglc2, it sounds like you want to create service, that's how you'd get something to run at startup. I don't know octoprint, but here are a few examples that might help: (to run iproute2 at startup, it works because the commands terminate), and
<roptat_>(slightly more complex, but it runs a daemon)
<myglc2>roptat, Thanks!
<apteryx>for security, is it better to run a service under its own user, or is 'nobody' good enough?
<lle-bout`>apteryx: not sure if nobody is treated specially but basically different user offers better granularity for data directories and such, I am not sure if there's conventions for changing uid after starting and keeping file descriptions to things opened before, not sure. So in my opinion, it's better one user for each especially if there's data directories, then also all processes running under the same user can read each other's memory
<lle-bout`>given they got SYS_PTRACE capability.
<lle-bout`>So if multiple services run under nobody they can read and affect each other's memory using SYS_PTRACE capability.
<lle-bout`>There's no isolation between those services basically, in that case.
<lle-bout`>A compromise of one such service means compromise of all other service's data etc.
<mjw>dongcarl, sorry no. That is too long ago.
<dongcarl>No worries :-)
<mjw>dongcarl, It might be that was on RHEL7 and it just had too old a kernel
<dongcarl>mjw: I think you're right, I'm debugging for my colleague and he encountered the problem with 4.4 kernel, and it dissappeared with 5.0
<dongcarl>Perhaps someone knowledgeable knows what change between 4.4 and 5.0 Guix depends on for the /dev/pts bind mount...
<mjw>RHEL7 is 3.10 btw. But has lots and lots of backports
<dongcarl>Yeah... Smells like a kernel version problem to me :-)
<apteryx>lle-bout`: I see, good points, thanks!
<lfam>Do we have any "Git forge" type things packaged in Guix?
<lfam>Like, gitlab, pagure, gitea
<lfam>Or, at least work in progress?
<efraim>I might, let me check
<efraim>Looks like all the gitea stuff I had I couldn't make work with a service
<efraim>And the not working container
<FennecCode>I'm having trouble installing MongoDB, and also having trouble even finding its service or package definition. Is it still available in Guix?
<lfam>I see efraim. So you have packages, but not a working service?
<lfam>I guess we should wait for the go-build-system overhaul before adding Gitea, in any case. But, I think we should consider prioritizing a "forge" package
<lfam>FennecCode: We removed MongoDB recently. There were unpatched security vulnerabilities and the fixed versions are not free software anymore (they changed their license)
<lfam>Sadly we had no choice
<lfam>Maybe the old packages are in guix-past:
<lfam>Or, could be added there
<FennecCode>Shoot, that's awful. I had no idea they changed licenses. That's incredibly frustrating. 🙁
<FennecCode>I'm just running this locally on my machine for a class, so an old version with some security holes is actually good enough for my use case. I'll check that out. Than you 🙂
<lfam>You could always use `guix time-machine`. We will still have substitutes for this stuff, since it was only removed about a month ago
<efraim>It was a while ago so I don't remember what the problem was. It works when launched through the shell script though
<jorts>Good morning Gweeks.
***jorts is now known as nckx
<lfam>Howdy jorts
*nckx squeaks.
<efraim>Probably need to go through all the sources and figure out where it was calling random binaries in /usr/bin or something
<lfam>Nix has a service for it, fwiw
<lfam>We definitely need to overhaul the go-build-system before embarking on long-term maintenance of complex Go software, IMO
<avalenn>lfam, I agreee. It is on my todo-list also but time is scarce.
<lfam>Of course :) Time is the most scarce resource
<civodul>lfam: the JS-heavy forges are more or less a lost cause
<lfam>In what sense?
<roptat_>lfam, not a forge, but I have gitile (which is down with my server :/)
<civodul>lfam: because of the "JS dystopia", to quote dustyweb
<lfam>You mean, Guix can't package them, because we can't package JS?
<civodul>but yes, Gitile is the future!
<lfam>Like, from a practical perspective?
<civodul>lfam: exactly
<civodul>well, more or less, we can and do package some bits
<civodul>and there are a few exceptions, too
<FennecCode>lfam: How would I go about using time-machine for loading a service in my system config file? Would I point to the reference to a prebuilt package or something? I'm a little unclear on how I might use this for referring to a service definition that no longer exists... It seems like what I want, I'm just not familiar with how to use it 😅
<roptat_>we could, but we're missing some tooling to make it a bit more practical
<roptat_>and it's not easy in terms of bootstrapping
<FennecCode>Also, sorry to break up conversation. I just need this for class relatively soon. GitTea stuff is important 😅🙂
<lfam>FennecCode: This is crude, but I'd use time-machine for everything: `guix time-machine --commit=old -- system reconfigure /etc/config.scm`
<civodul>roptat_: jlicht et al. made impressive breakthroughs with the npm importer, but really building from source is pretty much out of reach:
<lfam>Well, it leaves us without many options, right?
<roptat_>civodul, that's older than my own attempt
<FennecCode>Oh, yikes... Yea, I could just do that for as long as I need MongoDB, which is just a week or so
<lfam>I think the FSF's insistence on "no javascript at all" is... misguided
<lfam>FennecCode: Maybe you could use it to build a VM image for your schoolwork
<lfam>`guix system image config.scm ...`
<lfam>But, we should try to have something "in our pocket" in this regard
<lfam>That's re: a forge
<FennecCode>Ifam: Good idea! How do I invoke that with time machine, though?
<lfam>`guix time-machine --commit=$old -- system image config.scm`
<roptat_>FennecCode, you can invoke any guix command with the time machine, so guix time-machine --commit*... -- system image config.scm
<roptat_>just omit "guix" after --
<FennecCode>This is exactly what I need! Thank you all a bunch 😊
<lfam>Don't hesitate to come back if you get stuck
<FennecCode>Thank you. I appreciate it a lot 😊
<civodul>lfam: it's more about our own (Guix's) will to build from source
<roptat_>I noticed there's u-boot 2021.04 in guix now, so I ran guix pull on the server, it's still running, hopefully I'll be able to reconfigure before going to bed
<lfam>civodul: I'm looking here:
<lfam>I'm optimistic that we could do the work to our own standards with Gitea
<civodul>could be, i haven't looked at it
<lfam>And also for Pagure
<roptat_>if that doesn't work, I'll reflash the foreign u-boot, reconfigure with u-boot 2020.10 and hope it works
<lfam>I think any of us these options would be achievable for us, from a technical perspective
***cbaines_ is now known as cbaines
<roptat_>oh, also I got a new machine at work, and tried to install guix on it (foreign distro)
<roptat_>although I'm pretty sure I said "yes" when it asked me if I wanted to use substitutes, it didn't add the public key to the acl
<roptat_>(I did it manually)
<lfam>Hm... can you report a bug?
<lfam>We need to look into this for the new release
<roptat_>ah, I still had the terminal opened. After I typed yes, I got: /home/roptat/ line 445: /root/.config/guix/current/share/guix/ No such file or directory
<roptat_>didn't pay attention and went ahead with running guix after it told me everything was installed
<lfam>So, the key was missing from the tarball?
<lfam>That's the 1.2.0 tarball?
<roptat_>I think so
<roptat_>yes: guix-binary-1.2.0.x86_64-linux.tar.xz
<lfam>Hm, the file exists in the tarball's store, where it is expected
<lfam>So, something went wrong creating the /root/config/guix/current directory...
<lfam>I made a typo
<lfam>Should have been /root/.config/guix/current
<roptat_>indeed, when I used guix later, it told me it couldn't access /var/guix/profiles/per-user/roptat, and I had to create it myself
<roptat_>(which I did)
<roptat_>so I can believe something went wrong in there
<lfam>It would be great to test with a current version of and a current tarball:
<lfam>Well, that's the aarch64 tarball, oops
<lfam>I don't see where the x86_64 tarball is...
<roptat_>I can spawn a VM of a foreign distro later, and try that
<lfam>I'm curious, does /root/.config exist?
<lfam>Maybe the installer script assumes that ~/.config exists
<roptat_>oh, it didn't exist when I ran the script
<roptat_>now it does
<lfam>Hm, it does mkdir-p ~root/.config, more or less
<roptat_>but I ran guix pull as root, so that might have created it
<lfam>But, the rest of the path is missing?
<roptat_>now it's present
<roptat_>I used the latest version of that script
<roptat_>and it's present in /var/guix/profiles/per-user/root/guix-current-1-link/share/guix
<roptat_>actually on my first run of the script I got "[1618245242.243]: [ FAIL ] A previous Guix installation was found. Refusing to overwrite."
<roptat_>that was because I had created /gnu to mount another partition on it
<roptat_>I removed the directory and ran the script again, which worked except for the authorize thing
<rekado>roptat: for my installation on an AWS EC2 instance I had to patch the script to be able to install into an empty /gnu (a mount point for a separate volume)
<rekado>so perhaps we can make the script relax a bit and have it accept an empty /gnu directory
<roptat_>rekado, sounds good
<roptat_>so, I suppose it could not have had an effect, right?
<reily>Hello, Im having a bit of trouble configuring elogind and upower on my laptop that is running guix system. The system reconfigures fine, but it doesnt seem like the configuration takes effect with regard to idle time (from elogind) and auto power off (from upower). the relevant part of my configuration is available here: Is there anything obvious I am missing?
<roptat_>reily, did you reboot?
<reily>roptat: yes, I have tried several times.
<roptat_>can you share the configuration?
<reily>roptat_: here is the full config
<roptat_>it looks correct at first glance
<roptat_>sorry, I need to go, if nobody can help you, you might have more luck sending an email to (it might take some time for a human to validate your message if it's your first time, but you don't need to be subscribed, and answers will go through immediately)
<Lycurgus>i used nix about a decade ago and dropped it but am intrigued to find this
<Lycurgus>well nixos
<lfam>Welcom Lycurgus
<lfam>I mean, welcome :)
<Lycurgus>is there a commercial interest that has glommed on yet, a la canonical?
<lfam>Like, a commercially-backed version of Guix? As Ubuntu is to Debian?
<lfam>Or, are there commercial sponsors of Guix itself?
<Lycurgus>well a driver of commercial level quality, so such an entity actually using not just sponsoring
<lfam>No, not really. There is a project called PantherX, but it's not "ready yet", if I understand correctly
<Lycurgus>sponsoring can mean a check for a hunderd buck or permission to use a marque
<lfam>There is some backing from the scientific computing / HPC world
<Lycurgus>got it
<hpfr>semi-OT question: why are some messages on mailman displayed with html blockquote lines rather than > for quotes? e.g.
<lfam>Presumably it's a difference in how the sender's email client "quotes" things
<hpfr>does mailman understand html email?
<hpfr>I assumed everything was plaintext
<lfam>Maybe someone else knows the answer
<civodul>hpfr: you can send HTML mail and Mailman will display correctly in the on-line archive
<civodul>that said, i'd recommend turning off HTML for mailing list posts
<hpfr>yup I do, I was just curious how mailman did the blockquotes for some emails
<jeko>Yooo Guixters !
*hpfr waves
<hpfr>I bit the bullet and downloaded the mbox, turns out it's a plaintext email. I'm comparing it with an email that mailman displays with ">" now, mailman must use some kind of header encoding info to prettify these
***mood_ is now known as mood
<hpfr>ok, I'm 90% sure it does this to format=flowed emails. cool 😅
<rekado>I’d like to send format=flowed emails. Don’t know if mu4e can be configured to do that.
<civodul>oh, new blog post:
*kmicu throws mu4e-compose-format-flowed at folks
*rekado catches it
<rekado>kmicu: thanks!
<morgansmith>efraim: Thanks for committing my patch! Is there a reason you didn't close the bug? (47325)
*raghavgururajan peeps-in
<jackhill>wooo, awesome work Chris and Léo!
<rekado>this is excellent news
<rekado>now we just need to buy some build farm hardware (and figure out a way to host the machines)
<nij>How does my emacs know where the package (fetched via guix) is?
<rekado>via the EMACSLOADPATH shell/environment variable
<nij>Does guix set that automatically for me? Or I should set it manually?
<morgansmith>sometimes you have to log out and log back in because it does it in your profile but ya it should all be automatic
<rekado>when the “emacs” package is installed in a profile then that profile’s etc/profile file should include the variable.
<rekado>the usual GUIX_PROFILE=/path/to/.guix-profile followed by source $GUIX_PROFILE/etc/profile takes care of this.
<morgansmith>How do we do the current build farm hardware? I'm very tempted to purchase some talos hardware for myself and I'm wondering if I could use it to expose some substitutes
<nij>I tried to turn on my machine with guix to check.. but unlike yesterday, it doesn't load the GNU system correctly this time.
<nij>... Unable to load firmware: rtl_nic/rtl8168g-3.fw (-2)
<nij>Weird! It was working yesterday.. I wonder why.
<rekado>morgansmith: build farm hardware needs to be accessible via SSH by the head node of the build farm; it also needs to run a service to be hooked up to Cuirass.
<jeko>Adding (use-modules (gnu packages gettext)) to my package definition generate the following backtrace :
<jeko>In srfi/srfi-1.scm:
<jeko> 586:29 19 (map1 (#<package emacs-flycheck-guile@0.2 gnu/packag…> …))
<jeko> 586:29 18 (map1 (#<package emacs-multiple-cursors@1.4.0 gnu/pa…> …))
<jeko> 586:29 17 (map1 (#<package emacs-magit@2.90.1-6.7f486d4 gnu/pa…> …))
<jeko> 586:29 16 (map1 (#<package emacs-ggtags@0.9.0 gnu/packages/ema…> …))
<jeko> 586:29 15 (map1 (#<package emacs-projectile@2.3.0 gnu/packages…> …))
<jeko> 586:29 14 (map1 (#<package guile-readline@3.0.2 gnu/packages/g…> …))
<jeko> 586:29 13 (map1 (#<package guile-colorized@0.1 gnu/packages/gu…> …))
<jeko> 586:29 12 (map1 (#<package guile-hall@0.3.1 gnu/packages/guile…> …))
<jeko> 586:29 11 (map1 (#<package guile-spec@0.1.0-4.7524b6f jeko-pac…> …))
<jeko> 586:29 10 (map1 (#<package git@2.31.1 gnu/packages/version-con…> …))
<jeko> 586:29 9 (map1 (#<package nss-certs@3.59 gnu/packages/certs.s…> …))
***ChanServ sets mode: +q *!*@2a01:e0a:25f:d8f0:90e2:9613:c656:d1f
<rekado>jeko: please use a paste site
<rekado>lle-bout[m]: I wonder if the reproducibility problem you encountered is a variant of this:
***ChanServ sets mode: -q *!*@2a01:e0a:25f:d8f0:90e2:9613:c656:d1f
<nij>Ooops.. retried many times. It seems that my machine with GUIX dies.
<nij>It was running ok yesterday. But now it's stuck after "This is the GNU system. Welcome."
<jeko>I guess I can't delete my message ? 😶
<rekado>nij: failing to load firmware (blobs?) should not be fatal
<nckx>jeko: You can't delete IRC messages. It's not a big deal, but use a paste site next time :)
<morgansmith>rekado: what kind of upload would one need to be useful? I've got 15Mbps. I could ask my boss to put it at work though maybe. Also how does trust work? Do you just rely on people challenging the server?
<nij>rekado: I dunno. It's stuck there, and didn't proceed.
<lfam>nij: What kind of computer is it?
<rekado>morgansmith: I have no idea about minimum network requirements. I don’t think it matters too much to be honest.
<nij>It's a lenovo B50-80.
<rekado>nij: if you hit return a few times do you see a login prompt?
<nij>rekado LOL yes
<lfam>jeko: Maybe a module import cycle?
<nij>Problem solved.. so what's that problem?
<rekado>did you expect a graphical user interface?
<rekado>e.g. gdm?
<rekado>I have spent some frustrated hours with gdm failing to start. Perhaps that’s what you’re experiencing.
<jeko>lfam: something like gettext requires a module I imported which also requires gettext?
<morgansmith>rekado: are substitutes provided to users by head node or by the machine that built it?
<nij>rekado: no i didn't
<nij>I started with a bare-bone template config.scm.
<nij>And was careful not to add any graphical UI stuff
<morgansmith>rekado: sorry if I'm pestering you with questions :P is our setup well documented somewhere?
<rekado>morgansmith: the head node orchestrates the builds and serves the substitutes. The builders need to provide the build results.
<lfam>jeko: Yes, perhaps something like that
<rekado>morgansmith: it’s documented in the sense that our infrastructure is code.
<rekado>morgansmith: see the hydra directory at
<rekado>berlin.scm is the head node at
<morgansmith>rekado: oh ok. So upload wouldn't be an issue. Now I'm just wondering about trust. Like if I did start making substitutes for you guys, would you accept them?
<nij>How does guix work with common-lisp packages?
<nij>Usually I'd just `ql:quickload` a package.
<nij>But that doesn't work on guix cuz the cl-packages aren't installed in the default folders.
<jeko>lfam: Ok, I will look after something like that
<rekado>morgansmith: I fell out of the loop and no longer know how the current incarnation of Cuirass handles builds, so I can’t answer the question well enough.
<jeko>lfam: thanks for the clue
<lfam>morgansmith: The question of trust is handled as you'd expect, on a case by case basis
<nij>So.. anyone knows how to use ql:quickload properly in guix?
<jeko>is there a way to populate a Guix image with pre-defined files (emacs conf, scripts)?
<jeko>oh I can see skeletons in the reference !
<rekado>jeko: the special-files-service-type could be used for that.
<rekado>jeko: oh, or skeletons, sure :)
<rekado>nij: I don’t use Common Lisp, so I can’t help with that, I’m afraid.
<nij>no worries :)
<morgansmith>so I see a few mentions of gradle here and there but I couldn't find a definitive answer. Do we not support gradle because it can't be bootstraped? I honestly don't know what gradle is. Just want to build a package :P

warcinfo:
isPartOf: CC-MAIN-2021-43
publisher: Common Crawl
description: Wide crawl of the web for October 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-180
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/