IRC channel logs

2020-07-01.log

back to list of logs

<roptat>civodul: I think it's source-only
<LeonLainDelysid>Hello! I'm guessing other people have asked this question already, but… I wanted to use gcc and g++, but the Guix package manager doesn't have them. Why is that? Guix doesn't provide them?
***jonsger1 is now known as jonsger
<roptat>LeonLainDelysid, try gcc-toolchain
<roptat>civodul, they don't adhere to the same standard as we do, they only take care of OCaml packages, so the result depends on what is present in the system
<roptat>yes
<roptat>I think it's in the same package
<LeonLainDelysid>OK, great! I'll try that.
<roptat>the thing with the gcc package is that it doesn't work without other stuff, so we disabled gcc (so users don't panick when they install it and it doesn't work) and provide gcc-toolchain, which is a bundle of gcc and the things it needs
<LeonLainDelysid>Why isn't the package named "gcc"? Because the gcc-toolchain package has both the C and C++ compilers? It's like a more general name for them bundled together?
<civodul>roptat: i see, thanks!
***jonsger1 is now known as jonsger
<LeonLainDelysid>Oh, OK.
<roptat>civodul, why the question?
<civodul>LeonLainDelysid: https://guix.gnu.org/manual/en/html_node/The-GCC-toolchain.html has some info
<civodul>roptat: i'm working on the "related work" part of the post on commit authentication that i pushed recently :-)
<civodul>so i'm refreshing my mind about what they do
<roptat>what related work?
<roptat>I haven't followed that very closely ^^'
<LeonLainDelysid>Thanks!
<civodul>roptat: you're missing out! ;-) https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/commit-authentication.md
<roptat>I've been working on java stuff instead :p
<civodul>impressive stuff BTW!
<civodul>did you share with Hervé of Maven, whom we met at the R-B summit?
<mbakke>civodul: s/we can them/we call them/
*mbakke reads further
<roptat>oh no, I haven't
<rekado_>civodul: “Git [-is] now relies”
*civodul takes notes
<civodul>roptat: https://github.com/ocaml/opam-repository/blob/master/packages/batteries/batteries.3.0.0/opam contains the MD5 of a generated tarball, which i find interesting in at least two ways :-)
<roptat>mh... right
<mbakke>civodul: the note about Savannah being HTTPS reads a little awkward, a simple fix is to s/not impossible/it is not impossible/ -- there is probably a better way to formulate it though
<mbakke>civodul: s/a Guix developer takes reponsibility asserts/a Guix developer asserts/ ?
*mbakke lols at "patches carved into stone tables"
<civodul>:-)
<civodul>mbakke: perhaps just dropping the "not impossible" bit
<mbakke>that works
<mbakke>civodul: maybe the channels.scm hyperlink should have ?id=<commit> so it stays working for a long time
<civodul>yes, good point
<NieDzejkob>I guess I'll leave the build running overnight, it's at mes-boot-0.22 now. I've sent the patches to #42146
<mbakke>civodul: lacking a punctuation after "without having to be an expert"
<mbakke>civodul: so 'guix describe' only prints the introduction for third-party channels?
<civodul>mbakke: no, for all of them
<civodul>why?
<civodul>(well, once https://issues.guix.gnu.org/42048 is applied)
<mbakke>civodul: ah, right; I was expecting to see it in the later 'guix describe' "screenshot" :-)
<civodul>ah yes :-)
<mbakke>civodul: phew, that was quite a ride, but great read :-)
<civodul>mbakke: i'm afraid of ending up with something too long and hard to read
<civodul>but there's a lot to be said and i don't feel like splitting it
<civodul>maybe it's also a therapy for me ;-)
*civodul -> zZz
<civodul>night!
<mbakke>it's great to have this stuff documented, I think splitting it up in sections as you've done works fine, most users are just interested in the first part
<mbakke>gn!
<mbakke>so, uh, does anyone know how to create an LVM volume group backed by a regular file? :P
<NieDzejkob>there was some command to manually set up a /dev/loopN
<nckx>losetup?
***sputny1 is now known as sputny
<mbakke>ah yes, /me tries
<mbakke>dd if=/dev/zero of=fakevg bs=1G count=21 takes forever, maybe I should have used a smaller
<mbakke>(I need a 20G volume group to test something and don't feel like repartitioning)
<mbakke>a smaller *bs
<mbakke>I'm gonna put my wifi to the test by live-migrating a virtual machine backed by DRBD to my laptop, but Ganeti only supports DRBD on LVM volume groups
<NieDzejkob>mbakke: I usually do truncate -s whateverG my.img, that way it creates a sparse file
<mbakke>NieDzejkob: that sounds way smarter
<mbakke>dd still not finished lol
<mbakke>poor SSD must be wondering why I'm writing zeros at snail speeds
<nckx>mbakke: Why are you writing 20GB of zeroes? Compressibility?
<mbakke>nckx: it was my first thought on how to create a 21G file :P
<nckx>Wouldn't a sparse file—oh.
<mbakke>i cancelled it and used truncate, now I've already pvcreated the thing
<nckx>Good thing you didn't need a bigger image.
<nckx> https://ci.guix.gnu.org/jobset/wip-desktop — this is going to ‘evaluate’ for hours and then fail with an empty log file, and I wonder why.
<nckx>(Watch, now it'll succeed; but I won't even mind.)
<blendergeek>How can I use a nitrokey with GNU Guix? I can't find a nitrokey package for Guix, so I tried to manually add a udev rule but I'm not having any luck. Has anybody already solved this problem?
<clodeindustrie>hey guys what's the difference between /root/.guix-profile and /run/current-system/profile ?
<clodeindustrie>I have the first one as GUIX_PROFILE in my bashrc but only the second one load properly my extra channels
<nckx>clodeindustrie: /root/.guix-profile is root's (user) profile, /run/current-system/profile is the system (operating-system) profile, both are just profiles.
<nckx>Why set GUIX_PROFILE in your .bashrc?
<nckx>Profiles don't load channels, Guix does (and guix must not be installed in either profile!), so I don't know what you mean.
<nckx>‘type -p guix’ should return ‘$HOME/.config/guix/current/bin/guix’. That's guix's private profile, updated by ‘guix pull’, and that's what ‘loads’ channels.
<nckx>Correction: guix is installed in /run/current-system/profile/bin/guix, but you only use it once: when the user first runs ‘guix pull’. Any custom channels will be applied only after doing so.
<clodeindustrie>weird, why have I done that? I can't remember
<clodeindustrie>my issue (apart from setting GUIX_PROFILE in .profile) is that when I sudo su and then guix system reconfigure /etc/config.scm my extra channels are not loaded
<clodeindustrie>and it complains
<clodeindustrie>often I think I have to manually guix pull before I can reconfigure
<NieDzejkob>you shouldn't need a profile for root
<NieDzejkob>Try sudo guix system reconfigure /etc/config.scm, without su in between
<clodeindustrie>it's working fine...
<clodeindustrie>ok so I don't need to do anything from root when it comes to managin my GUIX system then ?
<clodeindustrie>I can do it all from my own user with sudo?
<clodeindustrie>and I don't need to export a GUIX_PROFILE in root
<clodeindustrie>?
<clodeindustrie>I need to read up on profiles in the doc...
<NieDzejkob>yeah
<clodeindustrie>thanks!
<blendergeek>I'm having trouble with my config.scm file.
<blendergeek>It is here: https://pastebin.com/rvh4yU5v
<blendergeek>I get the following error message when I try to reconfigure.
<blendergeek>guix/ui.scm:1949:12: In procedure run-guix-command:
<blendergeek>In procedure service-kind: Wrong type argument: #<<computed-file> name: "41-nitrokey.rules" gexp: #<gexp (begin (use-modules (guix build utils)) (define rules.d (string-append #<gexp-output
<blendergeek>out> "/lib/udev/rules.d")) (define file-copy-dest (string-append rules.d "/" #<gexp-input "41-nitrokey.rules":out>)) (mkdir-p rules.d) (copy-file #<gexp-input #<origin "https://raw.githubusercontent.com/Nitrokey/libnitrokey/21753f0df1739f15f961d86a054bd75e66c86142/41-nitrokey.rules" #<content-hash sha256:03caw4w69d2cfnbafjcrh2vkvzpyjx3j0gzq0vhf9q6jhviy0k83> () 7f198b0a61e0>:out> file-copy-dest))
<blendergeek>7f1989d56510> guile: #f options: (#:local-build? #t)>
<NieDzejkob>blendergeek: have you seen the udev-rules-service example in (guix)Base Services?
<blendergeek>Yes. I am trying to copy from it. But I can't figure out how to make it work.
<NieDzejkob>blendergeek: well, the config you pasted doesn't use udev-rules-service at all
<NieDzejkob>you currently have a "computed-file" object, you need to feed it through a service
<NieDzejkob>udev-rules-service can do it for you
<blendergeek>That seems to have worked!
***catonano_ is now known as catonano
***sneek_ is now known as sneek
<Blackbeard>hello guix :)
<Blackbeard>I've not been around recently, I had been really busy with my thesis :(
<Blackbeard>but I hope to be free by august
<Blackbeard>I saw the widelands patch was closed, that was nice :) thanks to everyone
<lispmacs>what exactly should I install to get a Java runtime environment?
<lispmacs>which package has the JVM?
<raghavgururajan>lispmacs: IIRC, jvm is non-free.
<raghavgururajan>lispmacs: If you want JDK, use packages openjdk and/or icedtea.
<raghavgururajan>lispmacs: You may get free implementation of JVM in OpenJDK package.
<lispmacs>raghavgururajan: thank you
<lispmacs>i was remembering from Debian I think, were there was a JRE package separate from the JDK, but might just be remembering wrong
<dissoc>is there an easy way (command?) to show where in the store a package is installed?
<efraim>readlink $(which bash)
<dissoc>okay cool. that's better than what i have been doing
<dissoc>i guess what im confused about is im writing a package that requires jemalloc. but im not sure what path to use. im guessing it would be something like (assoc-ref inputs "jemalloc") but how to get path of libjemalloc.so?
<dissoc>okay i think i figured out a way to find it but i had to follow the directories in the .drv files
<raghavgururajan>sneek, later tell nckx: Could you please build the package ao, using HEAD at https://git.disroot.org/raghavgururajan/guix-wip-desktop.git ? Thanks!
<sneek>Okay.
<efraim>dissoc: (string-append (assoc-ref inputs "jemalloc") "/lib/libjemalloc.so") is what I'd use
<dissoc>efraim: thanks what i ended up with. i just didnt know how to know to find it in /lib/libjemalloc.so from the inputs.
***apteryx is now known as Guest83291
***apteryx_ is now known as apteryx
<zimoun>civodul: morning coffee and reading your therapy https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/commit-authentication.md Nice read! Well, there are some typos but nckx, mbakke and rekado addressed some, if not all. :-) And I do not know if it does not deserve s split into 2 posts, publish at the same time: part 1 authentication, part 2 downgrade attacks and rest. Thank you for having written that down.
<zimoun>sneek: later tell civodul: morning coffee and reading your therapy :-)
<zimoun> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/commit-authentication.md
<zimoun> Nice read! Well, there are some typos but nckx, mbakke and rekado
<zimoun> addressed some, if not all. :-) And I do not know if it does not
<sneek>Will do.
<zimoun> deserve s split into 2 posts, published at the same time: part 1
<zimoun> authentication, part 2 downgrade attacks and rest. Thank you for
<zimoun> having written that down.
***ChanServ sets mode: +b *suck*!*@*
***guixsucker was kicked by ChanServ (User is banned from this channel)
<g-u-i-x-s-u-c-k>sneek, later tell nckx: I am unbannable, you ripe cunt!
<sneek>Got it.
<efraim>trolls gotta troll I guess
<raghavgururajan>Hey! If you are reading this: Do not confuse free speech with hate speech. If you have something to say, then just say it. No one here is gonna ban you, if you conduct yourself in a rational manner. Stop this non-sense of yours.
<raghavgururajan>nckx: Sorry dude! You are doing your best.
<NieDzejkob>sneek: later tell civodul: The message above got split, see http://logs.guix.gnu.org/guix/2020-07-01.log#095627
<sneek>Okay.
<civodul>'lo Guix!
<sneek>civodul, you have 2 messages!
<sneek>civodul, zimoun says: morning coffee and reading your therapy :-)
<sneek>civodul, NieDzejkob says: The message above got split, see http://logs.guix.gnu.org/guix/2020-07-01.log#095627
<efraim>looks like we may finally have a vim upgrade to the 8.2.0700 range
<zimoun>Hi civodul!
<civodul>hey
<zimoun>I have screwed up with sneek but I have read https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/commit-authentication.md
<zimoun>really cool!
<raghavgururajan>sneek, later tell nckx: I have built ao myself. Could you please build mesa? Thanks!
<sneek>Got it.
<zimoun>civodul, does gitlab.inria.fr run Guix? I mean .gitlab-ci.yml uses guix commands, from where Guix comes from?
<efraim>only 2 packages using mysql directly
<civodul>zimoun: the "gitlab runner" is on a Guix System machine, guix.bordeaux.inria.fr
<civodul>thanks for reading the post, BTW!
<zimoun>cool for the "gitlab runner", so each time a commit is pushed, "guix lint" is run which means that if origin is git-fetch then it is pushed to SWH. Awesome!
<efraim>I have a package for dbxfs, a fuse implementation to connect to dropbox.
<efraim>I'm pretty sure it's ok for guix
<efraim>i'll send it as a patch first
<efraim>I love tig for tracking down changes in repositories. using it now to work on upgrading vim
<civodul>zimoun: yup
<civodul>i think Guix is one of the main users of the "save" API :-)
<zimoun>civodul: yes, surely! :-) Hum? on the other hand, it will be hard to push packages with url-fetch to SWH because they will not listen "all" the channels around. Maybe we could propose to "save" URL pointing sources.json and maybe that their WebApp saver accept drop of sources.json file. Adding on our side someting to return sources.json for a given package, maybe under etc/.
<janneke>civodul: just a headsup on the childhurds: i have identified an offloading problem with sqlite3 locking and testing a fix from debian
<nckx>sneek: Hm, any 14-year-olds pop by in my absence?
<sneek>nckx, you have 3 messages!
<sneek>nckx, raghavgururajan says: Could you please build the package ao, using HEAD at https://git.disroot.org/raghavgururajan/guix-wip-desktop.git ? Thanks!
<sneek>nckx, g-u-i-x-s-u-c-k says: I am unbannable, you ripe cunt!
<sneek>nckx, raghavgururajan says: I have built ao myself. Could you please build mesa? Thanks!
<nckx>raghavgururajan: Will do.
<janneke>nckx: i think that i know what you mean...but the 14yo me would not have understood that with much kindness
<janneke>eh, and first: good morning nckx :-)
<nckx>Morning! I don't understand the 14-y-o-me part. I do think guix-sucks is genuinely lonely and just looking for attention/approval.
<janneke>nckx we want #guix to be welcoming, right? also to all sane 14yo people hanging out here?
<nckx>janneke: Yes.
<janneke>if i remember back to when i was 14yo, just playing with computers for ~2y, i was very insecure
<janneke>i would like to be careful to avoid making it a habit of speaking negatively about a certain group of people
<Kimapr>i was 14yo a few weeks ago
<janneke>Kimapr well done!
<nckx>Kimapr: My belated congratulations.
<Kimapr>dunno if i'm sane though
<nckx>It's fine if you are but I wouldn't aspire to it.
<janneke>i hated it when people would assume i was no good, and a trouble maker, because possibly some of my fellow age-comerades were
<janneke>Kimapr: what do you mean?
<civodul>janneke: oh good, i didn't know there was a problem actually
<janneke>civodul: me neither...i was just "waiting" and imagining what the next step would be in berlin...so, we're going to offload eh, hmm...has that been tested? let's see...
<janneke>that was before i saw mothacehe's bug report, which i'm actively trying to ignore -- "works for me"
<janneke>ugh
<Kimapr>i mean i'm using a package manager that manages all the system in lisp, how would i be sane
<Kimapr>recently moved my user directory to another partition
<janneke>Kimapr; good, in that case i have no idea what you're talking about ;-) :-)
<janneke>oh?
<Kimapr>2 directories refused to move with mv
<Kimapr>had to move them with cp and rm -rf
<janneke>interesting...
<nckx>Kimapr: (What) did it say (anything)?
<Kimapr>but then ownerships screwed up (did that as root)
<Kimapr>it said something can't delete the target
<nckx>Kimapr: Use sudo cp -a (for ‘archive’) for that. It preserves everything I care about, at least.
<nckx>janneke: Happened to me when I was that age, my reaction was to prove them all wrong. Different streeps for different peeps. I'm envious of any 14yos here: they're ridiculously far ahead of me at 14 (and with much better taste).
<nckx>mbakke, NieDzejkob: Is there a bug for that offload EOF annoyance yet?
<raghavgururajan>nckx: o/
<raghavgururajan>nckx: Sorry, I just found out that I need ffmpeg before mesa.
<nckx>raghavgururajan: Started. On 64a2483e084baf57d1690765bf6dc68c9897d9c9.
<raghavgururajan>nckx: ffmpeg requires mesa anyway.
<raghavgururajan>Oh is that hash for mesa or ffmpeg?
<nckx>That's the git commit (‘temp’ branch).
<raghavgururajan>Ah Okay
<mbakke>nckx: https://issues.guix.gnu.org/issue/41625 -- debugging welcome :)
<janneke>nckx nice!
<janneke>and yes, i agree
<nckx>mbakke: Thanks. I'll try to reproduce it. It's weird how it never happens at a ‘good time’ for debugging 😉
<raghavgururajan>nckx: Just letting you know that `./pre-inst-env guix build ffmpeg --dry-run` gives /gnu/store/fycy2yhiibiwwrrsakrbc2npz7inq3mx-mesa-20.0.8.drv
<nckx>raghavgururajan: Yep. That mesa is ready. The ffmpeg graph is still building (currently vala and xorg-server).
<nckx>raghavgururajan: I'm AFK for an hour, I'm sure it will be done before then (but remember that Guix caches 404s).
<mbakke>nckx: indeed, somehow opportunities to debug the tools you need for work tend to present themselves at the worst possible times :-)
<raghavgururajan>nckx: Thank you!
<raghavgururajan>nckx: I still get that mesa will be built.
<janneke>hmm, the hurd locking patch made it worse, somehow
<janneke>root@guixygnu ~# guix build -e '(@@ (gnu packages commencement) gnu-make-boot0)'
<janneke>guix build: error: setting synchronous mode: unable to open database file
<janneke>these sqlite error messages are terrible
<nckx>raghavgururajan: I can only say that /gnu/store/fycy2yhiibiwwrrsakrbc2npz7inq3mx-mesa-20.0.8.drv & /gnu/store/3981ci7890wcy8cv9cv2c6d7n1g64fa5-ffmpeg-4.3.drv have been built, and that https://guix.tobias.gr/nar/lzip/bvlp7p7ca3a00pnyhb5ak0051ah0625z-mesa-20.0.8 & /9m5csfqdb21yjqig57d57kmlvibfdmcf-ffmpeg-4.3 return sweet #content.
<nckx>sudo rm -r .cache/guix/substitute/* /var/guix/substitute/cache/* just in case.
<nckx>raghavgururajan: Can you confirm success or failure after trying that? Thanks.
<efraim>new vim! come and get it!
<civodul>\o/
<nckx>civodul: Thank you for spending the time to implement GPG stuff ‘natively’. The speed at which the octothorpes swoop past is so nice.
<janneke>"someone" knows anything about the Hurd and file locking "file_lock" / "flockIoFinder"?
<civodul>nckx: heh, yw :-)
<civodul>janneke: not me!
<janneke>civodul: guess i'll open a bug to discuss it
<janneke>it seemed to be just lifting a patch from debian, but some looking + thinking seems to be necessary
<janneke>what a terrible code base :-(
<civodul>sqlite or the Hurd?
<nckx>The Hurd?
<janneke>sqlite
<nckx>Phew.
<janneke>#ifdef me harder
<civodul>i like their "LTO-by-hand" trick :-)
<civodul>i pushed an update to https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/commit-authentication.md if anyone feels like taking a stab at it
<nckx>civodul: BTW, is there a secret rendered URL for drafts? I tend to spot more typoes in published posts 🙂
<raghavgururajan>nckx: Oh! For me `./pre-inst-env guix build ffmpeg --dry-run --substitute-urls=https://guix.tobias.gr` still gives The following derivation would be built: /gnu/store/fycy2yhiibiwwrrsakrbc2npz7inq3mx-mesa-20.0.8.drv
<nckx>Did you clear your caches?
<nckx>And does it actually start unpacking without --dry-run?
<raghavgururajan>caches? How do I clear that? Sorry, I never done this before.
<nckx>Maybe *waves hands* graft weirdness causes misleading messages.
<nckx>raghavgururajan: See above 🙂
<nckx>sudo rm -r ~/.cache/guix/substitute/* /var/guix/substitute/cache/*
<raghavgururajan>nckx: Yay! it works now. Thanks s omuch
<nckx>Superb.
<raghavgururajan>nckx: Btw, any luck with cuirass?
<nckx>raghavgururajan: No. But I don't use it myself, don't have time to dive deeply into yet another thing…
<nckx>So if anyone knows why evaluations (https://ci.guix.gnu.org/jobset/wip-desktop) would take hours and then fail with an empty (+truncated gzipness) log file I'd be grateful for the help.
<raghavgururajan>nckx: Cool!
<raghavgururajan>Ah I understand.
<raghavgururajan>nckx: Could you also build ffmpeg-3.4 and frei0r-plugins please?
<raghavgururajan>I believe the latter is required by the former.
<nckx>I (rightly) mock my own 500-line bash-in-a-loop CI system but Cuirass isn't making a strong case to switch :-/
<raghavgururajan>Hmm.
<nckx>raghavgururajan: Will do, on commit 64a2483e0.
<raghavgururajan>Thanks!
<nckx>raghavgururajan: Done.
<raghavgururajan>Awesome!
<mothacehe>nckx: Maybe you could try to run the evaluation "by-hand" (outside of Cuirass), and see if you have a more complete backtrace.
<mothacehe>I sometimes do it that way: https://paste.debian.net/1154634/\
***ChanServ sets mode: -b guix-sucks!*@*
***ChanServ sets mode: -b *suck*!*@*
<nckx>Thanks. When I have time.
<civodul>nckx: unfortunately no, there's no secret rendering
<civodul>but i agree with you
<zimoun>nckx, civodul: but it is easy to locally build the website and do the rendering at localhost:8080, isn't it?
<civodul>yeah
<civodul>still more work than opening a URL
<nckx>That still won't render drafts by default, though, right? (= more manual work)
<nckx>I'm not complaining by the way, was just wondering.
*nckx → AFK.
<zimoun>agree on drafts/ -> posts/ for local rendering
<terpri>solaar (logitech device manager) build broken :/
*terpri investigates
<janneke>oh well, at least my patch has some effect; sometimes i add or edit something and nothing happens
<nckx>Was #42153 mangled by our list or their MUA? https://issues.guix.gnu.org/issue/42153/attachment/0/2/0 looks like emacs to me.
<nckx>zimoun: Thanks for the mail, I'll take a look.
<zimoun>nckx: it is tiny. :-)
<nckx>terpri: add-before 'check 'setenv-PATH → add-before 'install 'setenv-PATH
<nckx>If it runs earlier one doesn't even need to override 'build.
<civodul> https://guix.gnu.org/blog/2020/securing-updates/ !
<janneke>civodul: \o/
<nckx>civodul: vulunerabilities → vulnerabilities (sorry, told ya 😛)
<civodul>ah!
<civodul>fixed, thanks :-)
<zimoun>civodul: really nice!
<civodul>it's a relief anyways :-)
<raghavgururajan>nckx: While package libvideogfx, I got lot of errors during build. https://paste.debian.net/plain/1154654
<raghavgururajan>I managed to fix some by patching via new phase.
<raghavgururajan>I still get some couple of errors. Any ideas on how to solve them?
<raghavgururajan>When you apply it in video.scm and build it, you will some ffmpeg related errors.
<raghavgururajan>*see some
<leoprikler>try building it against ffmpeg n0.9.3
<leoprikler>that's about as old as this library
<raghavgururajan>leoprikler: Do we have that?
<leoprikler>(you can alternatively try 1.0.8, 1.1.6, 1.2.3 or 2.0.1)
<leoprikler>Not afaik
<raghavgururajan>I searched got only 3.4 as oldest available.
<raghavgururajan>Oh
<leoprikler>you can jump back to 2.1.1 with git
<leoprikler>That should have been available back in 2014
<leoprikler>2.1.3 might also work
<leoprikler>(assuming they built against 2.1)
<raghavgururajan>> ‎leoprikler‎: you can jump back to 2.1.1 with git
<raghavgururajan>You mean by changing the version field in the package-definition?
<leoprikler>Not quite – I mean looking at the older package definitons of ffmpeg and copying them into guix.
<leoprikler>But perhaps just changing the version might work, I haven't looked that deeply into ffmpeg
<efraim>I'd check debian and see if they've managed to drag the package forward some
<janneke>ugh... "tclsh ./tool/mksqlite3h.tcl . >sqlite3.h"
<raghavgururajan>I am gonna try that after my sleep.
<janneke>that's about ~100 dependencies...terrible
<efraim>I don't see libvideogfx or anything like it in debian
<terpri_>nckx, that helped, but solaar has a "def async" which won't fly after PEP 492 :)
<terpri_>i just borrowed a mouse from my roommate, will tinker with this later (might be fixed upstream already)
<janneke>hmm, could it be that our cross-built make is broken?
<janneke>i'm seeing "#f/bin/sh" not sure where that's coming from
<NieDzejkob>I'm doing "guix graph --type=references glibc | xdot -" and "guix graph --type=references gcc-toolchain | xdot -" and while both of them contain glibc-2.31-debug, it depends on gcc-cross-boot0-7.5.0-lib only in the latter graph
<NieDzejkob>why is this? If grafts are involved, how do I tell 'guix graph' to ignore these?
<leoprikler>NieDzejkob: because those are two different glibc inputs
<leoprikler>glibc for gcc-toolchain has a bunch of dependencies injected
<leoprikler>look at %bootN-inputs
<NieDzejkob>ah, thanks
<raghavgururajan>nckx: Could you build this please? https://paste.debian.net/plain/1154666
<raghavgururajan>nckx: I will check once I wake up. Thanks!
<raghavgururajan>If tests fails, just #f for now.
<raghavgururajan>I just wanted to check this version for ligvideogfx
<raghavgururajan>*libvideogfx
<leoprikler>Can't you build old ffmpegs on your own?
<leoprikler>They're not that big imo
<pkill9>has there been any suggestions and/or discussion about adding extra metadata for packages for things like issues pages, mail addresses, etc?
<pkill9>I think that would be sweet
<pkill9>e.g. a record for the package's issues page
<pkill9>or bug reporting email
<pkill9>and other emails like for feature suggestions
<leoprikler>Those would have to be super optional, though, because home-page is already nonexistant with most software out there
<pkill9>yea
<pkill9>it wouldn't be mandatory
<pkill9>since not all packages have mailing lists
<leoprikler>And also those things should ideally be reachable in O(1) clicks after accessing their homepage
<pkill9>but it would be so helpful, because then you could have a script for sending bug reports that handle the URLs
<pkill9>or email address, or whatever
<leoprikler>you mean something like (@ (guix utils) report-upstream-bug!)
<leoprikler>dunno, sounds more like a recipe for abuse imo
<pkill9>I wouldn't have the script be in Guix
<pkill9>but for external tools that could be created
<pkill9>I guess it *might* be abused, but meh
<pkill9>you could already abuse all the github URLs/homepages now
<pkill9>since they all use the same format for the github issues page
<pkill9>I might make a tool for that actually
<pkill9>just fo rthe packages with github URLs either in the homepage or the source
<pkill9>also gitlab
<dustyweb>hi hi
<atw>hello dustyweb
<vagrantc>dustyweb: perhaps against my better judgement i got in on the mnt/reform ...
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, lfam says: It's a good question. The most recent discussion on the subject is here, please chime in: https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00260.html
<atw>whoops, gotta run back to work
<dustyweb>vagrantc: whee! at least there will be a number of us guix folks, better judgement or not :D
<vagrantc>dustyweb: the final point that convinced me was using standardized lifepo4 battery cells :)
<dustyweb>vagrantc: :)
*dustyweb running "guix system vm" for the first time in ages
*vagrantc has strong affinity for certain battery chemistries
<dustyweb>goal for this month: move all my servers over to GuixSD
<dustyweb>and use guix deploy
<janneke>dustyweb: that's great; i just deployed another new server today
<dustyweb>janneke: cool :) doing anything special with your servers? how are you setting them up?
<bandali>hey folks, anyone else having trouble using their Technoethical N150 with recent linux kernel versions?
<jonsger>vagrantc: you ordered the MNT Reform? those standard 18650 cells impressed me :)
<pkill9>vagrantc: nice, i'd like one of those
<janneke>dustyweb: not really -- it depends; this one was a debian box => guix pull and reconfigure with ~bare-bones.scm + a static IP; then
<janneke>deploy from remote
<janneke>i have just 3 servers like that now, but it's just so nice :-)
<mwelt>Hi all! Unfortunately I am unable to install the rust toolchain via rustup setup. And the rust packages available in guix repository are ..uhm.. somewhat old?
<mwelt>Has anyone experience using rust on guixSD
<NieDzejkob>Actually, I was about to merge the patches for rust 1.44
<mwelt>NieDzejkob: Sounds absolutely great :) Am I able to install rust language server an such things as well? Did not find corresponding packages.
<mwelt>NieDzejkob: Do you have any idea why https://sh.rustup.sh downloads the wrong binary for guix? At least this is what I assume after getting "The file rustup-init
<mwelt>does not exists, or could not be executed"
<NieDzejkob>mwelt: because /lib doesn't exist, at all
<NieDzejkob>you could create it with special-files-service-type
<NieDzejkob>though note that due to a bug, deleting it from your config or rolling back a generation won't automatically delete it
<mwelt>NieDzejkob: I would prefere the ideomatic guix way to install and handle rust. If that is to install rust + cargo via package system - great. As long as I have some way to install rls
<mothacehe>looking at our berlin build farm, I observed that "berlin" itself has guix-daemon max-build-jobs options set to "20" but all other build node have this option unset, which means "1" unless I'm wrong. Is this a voluntary? Some offloading limitation maybe?
<mothacehe>*nodes
<mwelt>NieDzejkob: ok rls doesn't install without rustup, i.e. I have to use this ominous special-files-service-type, but I haven't a clue whicht directory I actually have to link to /lib?
<NieDzejkob>mwelt: (service special-files-service-type `(("/lib64" ,(file-append glibc "lib")))) should work.
<NieDzejkob>Unfortunately, there is no perfect way of installing rust on guix :/
<mwelt>NieDzejkob: I see. Just stumbled across an old nix issue, they had to actually patch rustup for their purposes, since rustup seems to interact with quite a few things, nixOS doesn't have. So I guess it's quite the same for guix then.
<NieDzejkob>the rust packages should get updated to 1.44 relatively soon, but tools like rustfmt, clippy or rls are still missing, and packaging them will take more time than I have to spare right now
<mwelt>That is unfortunate, since I started really loving guix, but w/o rust I am not able to keep it I think.
<NieDzejkob>right now I'd recommend adding the special-files-service-type hack to your config and using rustup
<NieDzejkob>it'll get better over time :)
<mwelt>NieDzejkob: I definitely try the special-files-services-type workaround - actually right now :)
<mwelt>NieDzejkob: If my guix knowledge improves, I am glad to help with packaging rls, clippy and rustfmt
<rndd>good day (or night) everyone! whanted to ask - can i see log of installation process during installation?
<mwelt>is there an easy way to source ~/.guix-profile/etc/profile in fish shell?
<leoprikler>pipes are your friend :)
<leoprikler>mwelt: guix package --search-paths -p ~/.guix-profile -p /run/current-system/profile?
<leoprikler>I think the problem is, that $GUIX_PROFILE/etc/profile uses quite bash-specific syntax
<rndd>oh, sorry, i asked question wrong. i meant - can i see log of building process when installing package
<rndd>sure, i can see log, but can i get more info about each phase
<leoprikler>IIRC all guix commands should obey --verbosity=LEVEL
<janneke>it gets weird; an unpatched, natively-compiled sqlite3 with CFLAGS=-DSQLITE_LOCK_TRACE=1 seems to behave just fine
<janneke>...but that's with the other upstream source flavour
<ryanprior>rndd: you can see a log of the building process by running `guix build <package>`
<ryanprior>Then after you've built it & viewed the log, you can `guix install` it and it will use the already-built package.
<rndd>good day (or night) everyone! whanted to ask - can i see log of installation process during installation?
<rndd>0_0
<rndd>ryanprior: thanks
<ryanprior>If you've already built it & want to build it again to see the log, you can use `guix build --check`
<rndd>i will try it
<lfam>Or `guix build --log-file`
<ryanprior>Ooh good one, I hadn't noticed that before lfam :)
<rndd>hmmmm
<rndd>okay
<rndd>lfam: thank you
<pkill9>i wish guix would let you not use = in guix command line flags
<lfam>What do you mean?
<ryanprior>ie `--do-not-upgrade ungoogled-chromium` doesn't work, you must write `--do-not-upgrade=ungoogled-chromium`
<lfam>I see
<lfam>What's the problem with it?
<dustyweb>hm
<lfam>The way that options are handled in Guix is a GNU convention IIUC
<lfam>When it starts to get hard is a good reminder that we need a GUI
<lfam>:)
<raingloom>has anyone tried building something like that Python package that creates a GUI from an argument spec?
<ryanprior>I don't know if I'd want to use that GUI. Unless the CLI is quite simple, a hyper-literal GUI that just provides a mouse interface for every option is not a good experience.
<lfam>It's true. It needs to be hyper simplified to address the use case of most desktop users
<lfam>It should just install and remove packages, and update all installed packages
<raingloom>no profile support?
<ryanprior>I've been trying to get up my courage to build a Guix backend for the elementary OS AppCenter.
<ryanprior>raingloom: hypothetical PRs are welcome for this hypothetical GUI =P
<lfam>I feel like the use of multiple profiles is already quite advanced. It could be supported but hidden behind an "advanced mode" switch
<lfam>In any case, the person that does the work will be able to make the decisions
<ryanprior>I don't think it needs to be "advanced," but I do think I'd want to design around specific workflows. Profiles aren't part of the "manage/update my system" workflow. They'd be part of a separate "manage execution environments" workflow.
<lfam>To me, a GUI is not a good fit for that, because it obscures the scope of the environment
<lfam>Whereas it's clear when you do it in a terminal
<ryanprior>That doesn't seem obvious to me, my gut feeling is that a GUI could expose the scope of the environment just fine if you make that a design goal.
<raingloom>lfam: such switches are a bad idea according to the Elementary Human Interface Guidelines
<lfam>And I think that "environments" as a concept are really obscure and difficult. This ends up being the root of so many usability bug reports
<lfam>Okay raingloom. But this is Guix, not Elementary. Anyways, like I said, whoever does the work can choose what to do
<raingloom>lfam: i'm aware, but they have good guidelines.
<lfam>Guix relies heavily on environment variables, and we get bug reports and complaints about them almost every day
<lfam>For example... locales!
<lfam>Almost nobody who uses GNU/Linux understands how environment variables work
<lfam>It's a big problem for Guix
<civodul>these are broad statements :-)
<lfam>I know :)
<ryanprior>The locales story is bewildering. We need some kind of bash plugin or something to deal with that imo. It exposes a usability issue that isn't totally the fault of Guix or of Bash, but between the two of them the blame is shared.
<lfam>I would place the blame on the entire ecosystem
<lfam>The solution is quite simple
<civodul>yeah but then we're not going to make much progress, comrades :-)
*jonsger does not understand cmake ^^
<lfam>But every single time a tutorial explains how to elevate privileges, it tells you to use `sudo` or `su -`, and that is incorrect
<lfam>The distinction between login and non-login shells is super obscure but unfortunately fundamental to how this works
<civodul>true
<lfam>So we get a stream of complaints about locales
<ryanprior>I've noticed that `sudo -E` doesn't seem to work well with Guix
<civodul>lfam: how does that relate?
<civodul>we're all tired of locale issues
<civodul>but the thing is to come up with a better solution :-)
<lfam>Yes :) I'm just not sure what it is
<lfam>People have been trained to use the available tools incorrectly
<jonsger>lfam: what should once use instead of sudo or su -?
<lfam>My broader point is that "managing environments" is something that many users don't do
<lfam>jonsger: `sudo --login` and su --login`
<civodul>i think it's not necessarily helpful to determine what fraction of the blame goes to users, to Guix, to Bash, and whatnot ;-)
<lfam>Sometimes `sudo -E` if you know that's correct
<lfam>Yes, you're right civodul
<lfam>I'm frustrated because we've been trying to solve this problem for years
<civodul>guix keeps track of what user env should be set to what value, which is an advantage compared to many tools
<civodul>for example, "guix environment" just works, roughly
<lfam>Right! Unless people set environment variables in ~/.bashrc. And there are a lot of reasons to do that
<ryanprior>Oh I'm not saying we should determine % blame or anything. I'm saying by taking the system as a collection of components that collectively share the blame we can begin to change the whole system to deliver a great experience.
<civodul>lfam: yeah
<civodul>lfam: so far my inclination was to tell people about login vs. non-login shells
<civodul>but that's not very effective
<civodul>so if we can find a hack that Just Works, perhaps that's the way to go
<ryanprior>I've had to configure or hack a bunch of things in my system to explicitly use login shells
<lfam>Interesting!
<lfam>I'm curious what sort of things were doing otherwise
<ryanprior>The pantheon terminal application runs a non-login Bash shell by default, and isn't configurable, so I created a script called `bash` that runs `exec bash -l` and put that on the PATH for when terminal launches.
<raingloom>ryanprior: why not patch the package?
<lfam>Hm, I think that's a case where you'd normally want a non-login shell, right? The login shell is run at login and everything else would inherit its environment
<ryanprior>elementary OS has a launcher daemon that runs GUI processes for you and it doesn't inherit from a login shell.
<lfam>I see
<ryanprior>raingloom: I might patch the package, but at the time I wanted a quick fix and I haven't gone back and submitted anything upstream yet. Will add a note to do so though.
<ryanprior>Then I had a similar issue with Emacs
<raingloom>what i miss the most is nested GUI sessions like Plan 9's rio. i wanna be able to have separate environments on separate workspaces. tried packaging wio but it doesn't work yet.
<ryanprior>I solved that by patching my .desktop file to use Exec=bash -lc "env XLIB_SKIP_ARGB_VISUALS=1 emacs"
<ryanprior>(that env variable is necessary with gala, the pantheon window manager, otherwise Emacs crashes during startup)
<raingloom>on the topic of "weird Guix things", could someone look at bug 41927? i've been trying to figure it out for a while.
<mwelt>After installing gcc-toolchain none of the gcc-x.x.x-lib/lib libraries are symlinked to GUIX_PROFILE/lib, what am I missing here?
*janneke has a nice sqlite lock trace log that shows some fishiness on the hurd
<NieDzejkob>mwelt: so `guix package -I` lists gcc-toolchain, and it's not present in ~/.guix-profile/lib?
<rekado>pkill9: I feel the same. I’m used to not providing “=” between option and argument.
<NieDzejkob>raingloom: hmm, I don't know. I guess you could add some printfs to the source to figure out when it's going wrong...
<mwelt>NieDzejkob: It lists gcc-toolchain. I was under the impression this actually includes gcc itself?
<NieDzejkob>it should
<NieDzejkob>mwelt: could you paste exactly what you're seeing in your terminal? I find that it's a good way to look for hints in troubleshooting...
<civodul>rekado: maybe we should fork srfi-37 and provide argp-style functionality on top of it
<civodul>s/maybe/probably/
<mwelt>NieDzejkob: ./msg to not get kicked for spamming c&p
<NieDzejkob>mwelt: ah, hmm. I don't see libgcc in gcc-toolchain's lib
<NieDzejkob>mwelt: do you need libgcc for something, or is this a step in debugging something larger?
<mwelt>NieDzejkob: it's actually in the package gcc-x.x.x-lib/ which should be a dependency of gcc-toolchain, shouldn't it?
<pkill9>is there a way to get all the fields of a guile record? e.g. all the fields that canbe set
<pkill9>can be*
<NieDzejkob>mwelt: not all dependencies show up in your profile
<mwelt>NieDzejkob: rustup complains about not finding libgcc after the magic special-file-service-type trick.
<NieDzejkob>mwelt: ah. it won't look in your guix-profile anyway...
<mwelt>NieDzejkob: nice :) 2 hrs for a waste ...
<mwelt>So am I able just to link up a few more things to /lib64?
<NieDzejkob>yeah, I should've guessed that it was related...
<pkill9>specifically, I want to get a list of all the settings available in a configuration
<pkill9>a service configuration*
*civodul pushes https://issues.guix.gnu.org/42048
<NieDzejkob>mwelt: let me experiment with the syntax a bit
<NieDzejkob>civodul: yay!
<mwelt>pkill9: I am a complete guix noob myself, but if guix uses guile records, the last procedure described here might be of help: https://www.gnu.org/software/guile/manual/html_node/Records.html
<NieDzejkob>it builds some stuff on top of guile records, but this should work
<mwelt>NieDzejkob: As far as I understand the documentation of special-files-service-type, there isn't an easy way to just link up all files in a given directory.