IRC channel logs

2020-06-15.log

back to list of logs

<romulas>Good that mesa was updated, one more update to go:
<romulas>3ea6e46ea7881c656f7b4724639eaa4672d4e0e0b70869651e8f955ebae3d476 mesa-20.1.1.tar.xz
<dissoc3>im trying to write a package using the ant-build-system but i get the error: "error: unmappable character for encoding UTF8". there are some french characters. Im not really sure how to resolve this with guix.
<dissoc3>are there some locales i need to install for that?
<dissoc3>if so, is that system wide or package dependent?
<NieDzejkob>dissoc3: does it tell you a file name?
<dissoc3>NieDzejkob: yes. it says file name and line number. there are many
<NieDzejkob>dissoc3: could you unpack the source tarball locally and check what `file' says on some of these files?
<NieDzejkob>romulas: expect that to happen in around 6 weeks
<romulas>Got ya.
<romulas>I just hope it will be out by Navi 2.
<dissoc3>NieDzejkob: ISO-8859 text.
<NieDzejkob>dissoc3: I think that's the problem. Try adding a phase to treat the source with iconv
<dissoc3>NieDzejkob: okay. so like before build use iconv for converting?
<NieDzejkob>yeah, turn it into utf-8
<dissoc3>gotcha. thanks. i havent run into this before. was a bit lost but makes sense
<jsoo>speaking of rust versions, i am trying to build 1.4X and 1.40 keeps failing the validate-runpath steps.
<NieDzejkob>jsoo: I have working patches for rustc up to 1.44
<jsoo>NieDzejkob: oh heck yes. Do you think they might get into the savannah repo?
<NieDzejkob>jsoo: they are pending on a LLVM backport, and that was blocked until very recently on the staging merge. I'll clean them up and send them for review sometime in the next few days, you can grab them from https://github.com/NieDzejkob/guix/commits/rustup in the meantime.
<NieDzejkob>rust-1.44 isn't included but it builds and runs with a definition analogous to rust-1.43
<jsoo>NieDzejkob: Thank you
<romulas>Are you guys updates to LLVM 10 or directly to 10.1?
<romulas>*updating
<NieDzejkob>LLVM 10.0.0 is already packaged
<romulas>I see.
<NieDzejkob>mbakke: you mentioned that default LLVM got bumped to 10 on staging, but it's still 9 right now?!
<mbakke>NieDzejkob: ah no, I only bumped it for 'mesa', sorry for the confusion
<mbakke>NieDzejkob: I tried to get you to bump the default LLVM on 'master' meanwhile :P
<NieDzejkob>ah, that's how it went
<mbakke>LLVM and Clang can be patched/bumped freely on 'master' as long as Mesa is unaffected.
<NieDzejkob>that's a relief. For a moment I thought it's gonna have to wait another staging cycle
<mbakke>:-)
<NieDzejkob>romulas: so there's your answer. LLVM 10 by default RSN
<dufresnep161>Hi! Just installed Guix... and I cannot see numbers (even the one here:888) in Icecat 68.9.0esr
<NieDzejkob>ah, that's missing fonts
<NieDzejkob>try installing font-dejavu and/or font-liberation
<dufresnep161>hum... will try that
<NieDzejkob>you'll need to run fc-cache -fv after the installation for it to take effect
<NieDzejkob>(that step shouldn't be necessary, bug#26877 tracks this)
<dufresnep161>fc-cache-fv in root or my user?
<dufresnep>it worked, thanks a lot!
<jsoo>NieDzejkob: Nice work on the rust updates. thanks again!
<jsoo>For people more familiar with the rust ecosystem, what rustfmt and what racer goes with what rustc?
<jsoo>i packaged those long ago but they are really outdated and i'm not sure which source to get them from
*Bryophyllum -> zzz
<romulas>I wish gnu would base icecat on the latest firefox.
<clodeindustrie>morning, when running `guix system ini /etc/config.scm /mnt` does the command make some sort of cached copy of the config file?
<clodeindustrie>it crashed in the middle of the process because of something wrong in the file but even after fixing, I still get the same error
<clodeindustrie>mm
<clodeindustrie>Would having an existing /boot/efi mounted partition with stuff from windows10 on it be an issue for the `(bootload ....` command?
<clodeindustrie>looks like my `guix system init...` is crashing then
***catonano_ is now known as catonano
<clodeindustrie>it's definitely an issue with grub but I have not idea how to go about it
<clodeindustrie>I'm getting `initializing operating system under '#f'` and `/In procedure canonicalize-path: wrong type argument in position 1 (expecting string): #f`
<romulas>llvmpipe (LLVM 9.0.1, 128bits)
<romulas>Latest updates.
***njoseph_ is now known as njoseph
***wxie1 is now known as wxie
***wxie1 is now known as wxie
<apteryx>it's refreshing to see Guix build much faster with the new Guile baseline compiler! I could build the whole tree in 16m35s on my old Q6700 box.
<apteryx>wingo: thanks a bunch for that!
<clodeindustrie>ok so running `guix system init --bo-bootloader config.scm /mnt` still crashed, it's not the grub the issue then
<clodeindustrie>I would expect the script to display "Initializing operating system under '/mnt'" I had a look at the source code scripts/system.scm but no idea where the target is coming from
<apteryx>clodeindustrie: could you share your config on paste.debian.net?
<clodeindustrie>sure can
<clodeindustrie> http://paste.debian.net/1152115/
<clodeindustrie>I have been following this https://willschenk.com/articles/2019/installing_guix_on_nuc/
<clodeindustrie>so far so good, just up until I would say the end of running `guix system init config.scm /mnt`
<clodeindustrie>that's the error http://paste.debian.net/1152116/
<nixfreak>ok so I am trying build rust-nightly-src , in the file your supposed to use python x.py build but I get this error instead FileNotFoundError: [Errno 2] No such file or directory: '/home/nixfreak/build/rustc-nightly-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo'
<nixfreak>but that path exists ls -l /home/nixfreak/build/rustc-nightly-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo
<nixfreak>-rwxr-xr-x 1 nixfreak users 19744752 Jun 3 01:58 /home
<nixfreak>but that path exists ls -l /home/nixfreak/build/rustc-nightly-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo
<nixfreak>-rwxr-xr-x 1 nixfreak users 19744752 Jun 3 01:58 /home/nixfreak/build/rustc-nightly-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo
<nixfreak>I don't get it
<nixfreak>actually nm I think I figured it out now
<nixfreak>nope still same error , I will paste the full error
<nixfreak> http://pastebin.ws/a10ivo
<nixfreak>yeah I don't get it
<nixfreak>ok so I did a ldd on the path and found this libgcc_s.so.1 => not found
<nixfreak>I have gcc installed though
***wxie1 is now known as wxie
<nixfreak>I can't find libgcc in ~/.guix-profile/lib
<nixfreak>isn't libgcc supposed to be installed with gcc ?
***nikita_ is now known as nikita`
<clodeindustrie>mm
<clodeindustrie>my afternoon drama is solved after I did a guix pull just now
<clodeindustrie>how do I know what was updated during that pull?
<Barnet>hi everyone ;D hope you doing well ^^ im very new to guix system and trying to learn this beautiful os. i want to ask you which is the best,safest and most stable way to upgrade not only distro also packages ? guix pull follwed by guix package --upgrade is this right ? and some times after pull sudo guix system reconfigure /etc/config.scm
<janneke>Barnet: sounds about right; use sudo -E guix system reconfigure ...
<civodul>Hello Guix!
<janneke>hello civodul :-)
<Barnet>im also asking because last week i broke my system xD there was some issue with package upgrade and it couldnt build x265 i think it told me failed to build package and then i reconfigured my pc. then i couldnt boot in anymore and at this moment i dont know how to roll back so i installed it again ....
<Barnet>@janneke thanks
<Barnet>@janneke so do you mean sudo -E guix system reconfigure instead of sudo guix system reconfigure /etc/config.scm ?
<janneke>Barnet: yes, that's most probably what you want
<janneke>also, you should always be able to select and boot a previous (working) version of the guix system from the grub menu
<mothacehe>a
<Barnet>@janneke i see again thanks. yep i did this too but its my fault im searching for my main distro but with fsf standarts its very hard for me ....and then i want to decide
<mothacehe>Hey Guix!
<Barnet>which distro im going to run on a daily basis
<janneke>hey mothacehe :-)
<Barnet>Hi @mothacehe, how you doing ?
<civodul>howdy janneke & mothacehe!
<Barnet>howdy @civodul
<mothacehe>Barnet: fine thank you :)
<Barnet>@mothacehe great to hear
<cbaines>civodul, mothacehe morning :) Do either of you happen to know what revision of curiass is deployed on berlin?
<civodul>heya cbaines
<civodul>it's cuirass-0.0.1-31.2280ae1
<cbaines>Ok, thanks
<efraim>got a backtrace on guix weather against bayfront https://paste.debian.net/1152127/
<Barnet>to execute a sh. script what do i have to do ?
<mothacehe>efraim: oops that would be my fault (commit 4e05bbb093a17145fcabd48ea1d2c9cd7559084d)
<mothacehe>checking
<efraim>I figured since it was just committed I'd get a faster response here than on bug-guix :)
<Barnet>im asking because when im trying to execute it via terminal it says :No such file or directory so i have to edit the sh to another directory ?
<efraim>it sounds like either you have the wrong path to the script or it starts with a shebang that doesn't exist on Guix System
<efraim>what's the first line of the script?
<civodul>mothacehe: the #:job option of latest-builds is nice!
<civodul>(latest-builds "https://ci.guix.gnu.org" 10 #:job "inkscape-1.0.x86_64-linux")
<efraim>quassel 0.13.1 isn't compatable with qt-5.14, i'll see what others do
<efraim>i see debian hasn't rebuilt it since 5.12 (i think)
<efraim>ah, they have 5.14 in experimental, so not pushed yet
<mothacehe>civodul: thanks :) My idea is to have a list of images, then find the latest available image for download.
<mothacehe>And put everything under /latest as you suggested
<civodul>cool
<civodul>oh i hadn't even noticed "staging" had been merged, thanks mbakke! :-)
*guix-vits "ninja-style commits, lol"
<mothacehe>efraim: I just pushed a fix :)
<efraim>where in sys or proc can I check my CPU tempertaure?
<[df]>/sys/class/thermal/ I think
<efraim>I'm getting 94000 from /sys/class/thermal/thermal_zone0/temp so it looks like I need to try again with the thermal paste
<[df]>I don't know what it's 94000 of, hopefully not kelvin
<efraim>I assume its 1000ths of celcius
<jonsger>efraim: I think laptops tend to be higher on temp, so I wouldn't say 94° is a problem
<bonz060>In guix, can you rollback a specific package instead of a whole profile?
<janneke>you can use guix time-machine to install an earlier version of a single package, to create a new generation of a profile
<bonz060>janneke: How do you do that?
<lprndn>bonz060: it should look like "guix time-machine --commit=xxx -- package -i PACKAGE but I never used it so I might be wrong.
<lprndn> https://guix.gnu.org/manual/en/guix.html#Invoking-guix-time_002dmachine for more informations ;)
<bricewge1>“guix time-machine --commit=6a9659f5d8 -- install hello” failed with https://paste.debian.net/1152144/
<bricewge1>Looks like the time-machine has issue going back to guile 2.2
<efraim>jonsger: agree, but this one has a history of overheating. the 94 was minutes after powering it on and it since shut itself off
<clodeindustrie>is there a per-user equivalent of /etc/config.scm ?
<nckx>Morning all.
<janneke>Morning, nckx
<nckx>clodeindustrie: K…ind of. You can use a manifest for packages and shepherd supports running ‘user services’ if you start it manually at log-in. But nothing as holistic as the system level.
<clodeindustrie>right, was just curious, I'm the only one to use my machine anyway
<clodeindustrie>thanks
<janneke>civodul: pushed my post around 12; "someone" needs to push a button somewhere?
<Bryophyllum>o/
<janneke>\o
<mbakke>bricewge: I think that fails because the commit predates the time machine machinery
<civodul>janneke: it's automagic!
<civodul>or broken?
<civodul>it the "date" right in the .md file?
<janneke>that's what i thought
*janneke checks
<civodul>broken
*civodul looks
<janneke>=> date: 2020-06-15 12:00
<civodul>yeah for some reason the web site fails to build on berlin
<civodul>since yesterday afternoon it seems
<janneke>oh!
<civodul>(ice-9 eval) backtraces are terrible
*civodul reconfigures berlin
***dingenskirchen1 is now known as dingenskirchen
<Bryophyllum>I'm having a problem authenticating my checkout of the Guix repository. `make` is producing an error message that says that there's no rule to make target 'authenticate'.
<civodul>Bryophyllum: did you run ./bootstrap && ./configure first?
<civodul>that will create the Makefile
<Bryophyllum>civoul: I did only run ./bootstrap. Thanks, that worked. For everyone's information, I was merely following the manual
<nckx>dftxbs3e: You were unsubbed from guix-devel; free.fr rejected too many mails as ‘spam’. In case you didn't get that mail either.
<civodul>Bryophyllum: ah, i'll fix it
<nckx>Bryophyllum: Which section?
<Bryophyllum>nckx: Building from Git
<nckx>‘Then, run ‘./configure’ as usual.’.
<clodeindustrie>hey I have added a channel in /etc/guix/channels.scm, it shows up when I guix pull but breaks my /etc/config.scm when running `guix system reconfigure /etc/config.scm` What did I forget?
<nckx>clodeindustrie: We can't know :-) Please paste your channels.scm and the full error message to paste.debian.net or your favourite non-pastebin.com pastebin.
<clodeindustrie>oh thanks, but don't sweat, if it's not something obvious, I can at least try to investigate further before bothering everyone :D
<nckx>Sounds good. You'll learn more that way, and we're always here to help. The ‘#’ in #guix is a tiny little safety net.
*nckx → AFK to do summer things.
<civodul>janneke: post is coming but everything's just slow :-/
<janneke>civodul: thanks, well tbh the post itself started out real slow too
<janneke>;)
<civodul>heh :-)
<Bryophyllum>I'm still unable to authenticate the checkout: https://paste.debian.net/1152159/ :(
<nixfreak>Hello , I added libgcc.so.1 with /lib in the config.scm file but I'm still getting libgcc not found when I use ldd , libgcc_s.so.1 => not found
<janneke>Bryophyllum: try something like: git branch keyring origin/keyring
<bricewge1>How do you apply attched patches with emacs?
<Bryophyllum>janneke: That did the trick. Thanks!
<nixfreak>Here is the config.scm and ldd output http://pastebin.ws/13taky
<NieDzejkob>nixfreak: did you run reconfigure? also, what's the output of ls /lib and ls /lib64?
<nixfreak>reconfigure?
<nixfreak>I'm new sorry , I only did a guix pull cause thats what I used before
<nixfreak>to get libc to show
<civodul> https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
<civodul>janneke: ↑
<civodul>\o/
<nixfreak> https://termbin.com/929e
<janneke>civodul: \o/ ty! /me goes to advertise
<civodul>well done!
<nixfreak>I don't see any lib64 directory in ~/.guix-profile
<nixfreak>ok my bad I don't think I have done a single guix system reconfigure /etc/config.scm yet , running it now
<rekado_> https://github.com/andrewchambers/hermes/blob/master/doc/compared-to-nix-and-guix.md
<nixfreak>is it supposed to take a while to build kernel 5.4 ? building /gnu/store/zdxwphvp8mfp8rinpch8jv107y11b04s-linux-5.4.46.drv...
<efraim>is there a way to dynamically create the name in service-type or for provision in shepherd-service when creating guix services?
<civodul>rekado_: what's Hermes?
<civodul> https://github.com/andrewchambers/hermes is quite vague
<civodul>oh https://acha.ninja/blog/introducing_hermes/ has more info
<rekado_>I also don’t know
<efraim>wikipedia?
<rekado_>“no monads”
<civodul>yeah, the bits about "simplifying" suggest a misunderstanding
<civodul>"less code" is interesting
<civodul>Guix had "less code" 7 years ago
<rekado_>I guess it’s true that dropping the license, description, synopsis, etc fields is a simplification
<rekado_>also, there’s *more* code in each of the package definitions because there are no build system abstractions
<rekado_>the example in the blog post above is rather verbose when compared to a Guix package definition.
<rekado_>sh/$ is a nice touch, though
<civodul>right, and it feels like "old-style" lisp
<civodul>the post has "hermes build https://raw.githubusercontent.com/andrewchambers/hpkgs/f4393d/community/bash.hpkg"
<civodul>but that file has "use" and "import" directives
<civodul>how are they resolved?
<rekado_>relative to that file: https://github.com/andrewchambers/hpkgs/blob/master/prelude.hpkg
<civodul>ok
<civodul>so not relative to the URL above
<civodul>janneke: https://github.com/andrewchambers/hpkgs/blob/master/seed.hpkg shows a 76MB seed, can you believe it? :-)
<rekado_>tangentially related: I don’t get the appeal of musl. Can someone enlighten me?
<civodul>it's cool and not GPL? :-)
<rekado_>is it the consequence of the knee-jerk response to what people call “bloat” in glibc?
<rekado_>ah, GPL
<civodul>well, LGPL
<civodul>yeah, "bloat" maybe
<civodul>it seems to me less interesting than Clang, technically
<rekado_>“This binary seed itself contains a statically linked busybox and musl-gcc which is enough to bootstrap all the other software.” (https://github.com/andrewchambers/hpkgs)
<civodul>janneke: the seed above include musl, busybox, binutils, and gcc
<civodul>busybox provides a shell apparently
<efraim>why not use toybox instead of binutils if they're just looking at size
<civodul>didn't know toybox
<efraim>we have it packaged
<janneke>civodul: 76MB including gcc -- that's hard to believe...
<civodul>well, that's the compressed tarball
<janneke>our gcc-stripped-tarball-5.5.0/gcc-stripped-5.5.0-x86_64-linux.tar.xz is 18MB
<efraim>I can never remember which programs busybox and toybox aim to replace, but we probably shouldn't change the description to add "for those who dislike the following GNU utils"
<civodul>uncompressed tar is 233MiB
<civodul>it's better than what we had when we were using coreutils, tar, etc. i guess
<civodul>but far from the 60MB we're celebrating :-)
<janneke>anyway, i believe it's a big win when this gains mindshare
<civodul>yes
<civodul>it's good that they mention it
<civodul>and use the same terminology, explain how to rebuild it, etc.
<efraim>can you provision the same service more than once?
<janneke>efraim: like term-tty1, ... etc?
<efraim>basically,
<efraim>I guess I should see how to create the provision field so they don't clash
<janneke>yeah
<efraim>using term-tty1 as an example, I didn't want 3 services all named tty
<janneke>right :-)
<efraim>but I didn't want to define 3 different services, one for each
<apteryx>bricewge1: from Gnus, you move your pointer on the attachment, then use '|' git am RET (after having 'M-x cd your-guix-checkout' from the Summary buffer.
<bricewge1>apteryx: Thanks! I have found the 3 year old log where you were told this method. This is really useful.
<apteryx>bricewge1: haha!
<apteryx>efraim: busybox is basically a single binary that can replace bash + coreutils (more or less), supposedly useful for embedded devices.
<apteryx>In practice I find most embedded devices I've worked with amply capabale of running the "real" tools such as GNU Bash and GNU coreutils without any of the limitation (I've seen regexp support for Busybox commands behave differently (and not in a good way) for example).
<apteryx>Perhaps mothacehe knows more
<nikita`>efraim: yes, I'd avoid negative comparison like dislike. there's more positive structures to express the same
<nikita`>congrats for proceeding with the bootstrap :)
<mothacehe>apteryx: I think busybox is often used in embedded device for space considerations.
<mothacehe>With one binary you cover (poorly) what would be provided by hundrer of binaries from coreutils & friends.
<apteryx>as for glibc vs musl, I don't know much about the later, but I think the opinion that glibc is "bloated" is mostly historical. There used to be a eglibc project for embedded that was an effort to keep gilbc small, but that project has since been merged back into glibc itself.
<apteryx>Another popular reason to glibc is considered bloated by some is that it has support for the Hurd.
<nikita`>mothacehe: however there's also the 'crunched' approach we (or at least some of the *BSDs) are taking, when your base system includes the rescue set of binaries.
<nikita`>but yeah., busybox is tricky
<nikita`>and tricky to satisdy and detect
<apteryx>mothacehe: thanks for tipping in
*nikita` thinks about busybox specific glue code she wrote last year >.<
<nixfreak>is guix supposed to have a lib64 directory inside ~/.guix-profile ?
<NieDzejkob>nixfreak: mine doesn't. Why are you asking?
<efraim>It's not supposed to, we try to keep everything using lib
<nixfreak> error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
<nixfreak>failed to run: /home/nixfreak/build/rustc-nightly-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/nixfreak/build/rustc-nightly-src/src/bootstrap/Cargo.toml
<NieDzejkob>nixfreak: okay, but the linker ain't gonna look in ~/.guix-profile
<NieDzejkob>if you want to run downloaded binaries, your best bet is to make them available in /lib64
<NieDzejkob>you might want to look into, IIRC, directory-union
<nixfreak>ok so NieDzejkob , you must have your setup configured differently
<nixfreak>so how did you exactly build rust-nightly and build rustup ?
<NieDzejkob>I didn't need rust-nightly to build rustup
<NieDzejkob>what error did you get?
<nixfreak>sec
<nixfreak> ~/build/rustup$ cargo build --release
<nixfreak>error: failed to parse manifest at `/home/nixfreak/build/rustup/Cargo.toml`
<nixfreak>Caused by:
<nixfreak> feature `profile-overrides` is required
<nixfreak>this Cargo does not support nightly features, but if you
<nixfreak>switch to nightly channel you can add
<nixfreak>`cargo-features = ["profile-overrides"]` to enable this feature
<NieDzejkob>nixfreak: ah, that feature has since been stabilized
***cjpb0 is now known as cjpbirkbeck
<NieDzejkob>nixfreak: http://logs.guix.gnu.org/guix/2020-06-15.log#002002
<NieDzejkob>A license header like this one is non-free, right? https://github.com/lynn/z80golf/blob/master/src/Codes.h
<janneke>NieDzejkob: that's non-free
<janneke>you could try to contact the author about it, the wording used hints at at least some unawareness about licenses
<NieDzejkob>I'm not sure there's a huge chance of getting a response if the copyright line is from 2005 :/
<nixfreak>NieDzejkob is the commit pushed to master for rust 1.43 ?
<NieDzejkob>no, these patches are still WIP. That log is from 16 hours ago
<nixfreak>Ok , but still don't understand (be paient with me) how you got rustup to build by using the rust package from guix ?
<nixfreak>isn't guix only showing 1.39 ?
<nixfreak>I'll check the irc logs later thanks
<mothacehe>janneke: 4th position on HN, good job :)
<Bryophyllum>I modified the system.scm file (I'm just playing with source code for fun for now), `./pre-inst-env guix pull`, and `sudo ./pre-inst-env guix reconfigure system ...`, but there's no difference . Could the reason as to why doesn't use the cloned local guix repo be that I have channels configured?
***guix-vits is now known as bionicbeaver
<dustyweb>omg omg omg omg omg
<dustyweb>new release of dungeon crawl stone souuuuupu
<dustyweb>*works on making update for Guix*
<civodul>hey dustyweb!
<civodul>always interesting comments on HN: https://news.ycombinator.com/item?id=23528534
<dustyweb>civodul: heh...
<rekado_>civodul: very insightful. Upvoting.
<pushcx> https://news.ycombinator.com/item?id=23528119 is on the same theme
<civodul>yeah (i didn't know "gash" was a word)
<civodul>these comments are "interesting" in a sense
<samplet>It’s nice to know that “Gash” has a bad name like its friends “Guix”, “Bash”, and “Unix”. ;)
<Bryophyllum>civodul: My fears as well, yet I'm here learning how the bootstrap process works in Guix only because I'm so eager to configure my aliases globally rather than in say .bashrc, whereas it'd be x times simpler on NixOS, where it's the matter of appending a single option to a configuration file
<dustyweb>pushcx: replied to the gash one https://news.ycombinator.com/item?id=23528814
<rekado_>I know “gash” as a deep cut
<rekado_>and I think that’s perfectly appropriate for the project.
<civodul>samplet: heh :-)
<rekado_>(if you want to find sexual meanings in words it’s hard to find something that’s not a synonym for genitalia)
<dustyweb>rekado_: yeah
<samplet`>I suppose that’s true. I didn’t choose the name, but I don’t really want to change it, either. I always thought of it as being like “bash” in both sound and meaning.
<dustyweb>in my git checkout I'm seeing lots of "incompatible bytecode kind" messages... is when using ./pre-inst-env guix ... is there some cache I need to clear?
<dustyweb>maybe I should clear ~/.cache/guile/ccache
<dustyweb>?
<dustyweb>seems to be working fine despite the warnings tho
<janneke>mothacehe: nice, interesting read
<janneke>almost tempted to comment
<janneke>"if you're not into user freedom, there's already an excellent choice of software options"
<dustyweb>janneke: do it!
<janneke>dustyweb: thanks for the nudge :)
<pushcx>dustyweb: gnu has also had gimp as adolescent humor for a long time, so there's probably not a lot of folks reading the name w charity
<dustyweb>pushcx: yes, "gimp" is a problem :\
<dustyweb>that's true
<dustyweb>though that one's a problem for its ableism primarily imo
<dustyweb>I guess if you see that, maybe you could infer a sexist reading for gash, and that's a fair criticism for the GNU project in general... that said, when I saw "gash" it wasn't anywhere near the top of my head of interpretations
<dustyweb>it felt like searching for that slang reading to me, especially given the close parallel to "bash", but maybe I'm wrong
<lispmacs[work]>is there a way, if you are using manifest files, to specify to get a certain package from a certain commit of Guix?
<NieDzejkob>lispmacs[work]: info "(guix) Inferiors"
<dustyweb>aw, guess the 0.25.0 release of crawl isn't quite ready until the deb packages are generated. too bad.
<NieDzejkob>[unrelated] Any idea why ghc-7 uses a hodgepodge of alist-cons-{before,after} instead of modify-phases?
<rekado_>NieDzejkob: probably because it’s old
<leoprikler>Just so you know, the German translation of "guix script" news has a comma instead of a dot in "my-script,scm"
<janneke>rekado_: thanks for posting to hn!
<cbaines>Yay, someone has probably updated Cuirass on ci.guix.gnu.org, so https://ci.guix.gnu.org/api/queue?nr=1000 now works (at least some of the time) :)
***sputny1 is now known as sputny
*rekado_ just posted it to Reddit as well
<efraim>NieDzejkob: changing GHC to use modify-phases has been on my TODO list for at least 2 years now
<samplet`>NieDzejkob: I have started the “wip-haskell-updates” branch again and added GHC 8.8. We could make changes to GHC 7 as part of the larger Haskell update.
<rekado_>samplet`: would you be okay with me pushing a bunch of changes to wip-haskell-updates? I have primarily changes for the build system to remove references from the “doc” output and to move static libs to a “static” output by default.
<rekado_>the changes also allow us to build a statically linked Pandoc reducing the closure in the common case by about 3G.
<samplet`>rekado_: Yes. That would be fine. I started that branch with the intent of updating all the packages to their next LTS versions, but got a little side-tracked.
<s34n>I'm trying to install guixsd for the first time. It stumbles over a network connection.
<s34n>There was no part of the install that asked about network setup
<s34n>but it should be able to dhcp
<leoprikler>Are you doing a "graphical" installation or a manual one?
<leoprikler>If graphical, then there should be a point at which it is trying to recognize your connection – admittedly, that has rarely worked for me.
<leoprikler>For the manual case, the info (access it via C-M-F2) should contain everything you need
<apteryx>could someone clear up some confusion I have: To build a package that has a test suite to run... I must build it through the the binfmt (QEMU architecture emulation) service? But if a package doesn't need to "run" anything, it can be built by simple cross-compilation?
<NieDzejkob>QEMU binfmt (with --system) is considered equivalent to a native (say) arm board, but cross-compiling (with --target) is not. This means that apart from the program itself supporting cross-compilation, all the dependencies must too
<NieDzejkob>how do I retry a cached build failure?
<cbaines>NieDzejkob, guix gc --clear-failures can probably help
<apteryx>NieDzejkob: I see, thanks for explaining. What about test suites in a cross-compilation setting? Are they always disabled?
<apteryx>janneke: curious about the assymetry in 'herd start hurd-vm' and 'herd stop childhurd'. Is this intended?
<janneke>apteryx: ah, hmm. there is no asymmetry; the service has two names
<mjw>This is probably silly me not really getting "it", but do I really have to change all my scripts that use /bin/bash (instead of /bin/sh because they us some bashisms) to #! /usr/bin/env bash
<janneke>similar to ssh, sshd and ssh-daemon
<apteryx>janneke: ah, that's neat. I didn't even know we were using this kind of alias already.
<mjw>(and similarly for anything using /usr/bin/perl /usr/bin/gawk /usr/bin/...)
<janneke>apteryx: i sometimes try to convey a lot of information in a implicit compact way
<janneke>apteryx: i'm open to suggestions to improve it
<apteryx>Perhaps just explicitly mentioning that the service can be referred to by more than one name, for convenience.
<bionicbeaver>mjw: /run/current-system/profile/bin/env bash #:)
<s34n>isntall did a whole bunch of downloading, then building, then initializing, then more downloading, then prompted, "Press Enter to continue." Then nothing.
<s34n>Yes. I pressed Enter
<janneke>apteryx: yes, i'll have a look at that -- documentation should not be a series of puzzles
<mjw>bionicbeaver, you joke! But... I honestly was confused.
<apteryx>janneke: ah, no worries!
*apteryx goes trying out the childhurd service
<s34n>How long should I wait after "Press Enter to continue." before I think something is wrong?
<mjw>I assume there is a good philosophical reason for there being just /bin/sh and /usr/bin/env and nothing else. But... It feels so different/confusing.
<bionicbeaver>s34n: Hi. Is that in installer of Guix System?
<mjw>So I guess I had assumed there would be some binfmt service that would handle this automagically.
<s34n>bionicbeaver: yes
<s34n>it says bootloader is installed. Is it safe to reboot?
<bionicbeaver>s34n: IDK, i did "Manual" install some months ago.
<bionicbeaver>s34n: all that the Manual say: "At that point you can hit “OK” and installation will proceed. On success, you can reboot into the new system and enjoy." <- Probably it should show some "success" message?
<s34n>ah. it finally gave a system error about not being able to delete a directory with contents, then some other stuff, then the finish screen
<s34n>now it's rebooting
<bionicbeaver>s34n: if installation was successful: booting to Guix System is relatively slow. I'm usually Alt+Ctrl+L.Arrow and wait until the messages stop coming (included the famous: "error in finalizing thread: success". Then i'm switch back and login.
<s34n>hmmm. /everything/ seems very s..l..o..w
<civodul> https://status.nixos.org/ looks neat
<civodul>cbaines: ↑
<cbaines>are you just looking at the pretty colours :) or is there some bit of the information you're interested in?
<cbaines>oh, and if someone could have a go at restarting the cuirass-web service on berlin, that might be useful, I'm seeing 504's from NGinx
<civodul>first, the pretty colors :-)
<civodul>then, there's a Grafana and a Prometheus thing
<civodul>the latter seems to have interesting metrics of the kind you're looking at
<civodul>"channel_update_time"
<cbaines>ah, I completely missed the links at the top
<civodul>the "HowOldIs" page is a worth a look too
*civodul restarted cuirass-web
<cbaines>thanks, it works for me now :)
<civodul>we could do better in terms of monitoring
<cbaines>channel update time seems to be the time of the last commit
<cbaines>it seems a little odd to use Prometheus to track this
<NieDzejkob>evaluations are failing on CI. Looks like a problem with offloading
<janneke>civodul: interesting, i was just over at #nixos trying to nudge them ;-)
<janneke>but that's cool too
***link2xt[nm] is now known as link2xt
<apteryx>janneke: I deployed the hurd-vm service on my machine; ss -lt shows it listening on 127.0.0.1:20022, but 'ssh root@127.0.0.1:20022' says Name or service not known.
<apteryx>ah, that's not how to specify a port using SSH
<apteryx>;-)
<janneke>apteryx: try -p 20022
<janneke>yeah
<janneke>ssh command lines are about as terrible as git's
<apteryx>I'm in! :-)
<janneke>\o/
<janneke>what took you so long?
<janneke>:P
<apteryx>it was building tons of stuff
<janneke>apteryx: i was trying to be funny, i'm happy you tried and that it works!
<apteryx>haha, sorry, I fail at reading jokes on IRC (I'm slightly better at it in person).
<janneke>i forget to add smileys at times, that's a terrible idea on irc
<apteryx>indeed!
<apteryx>what's next for the Hurd on Guix? Is there a list of TODOs somewhere?
<janneke>apteryx: i haven't prepared a list yet
<janneke>but i guess we want to get hurd-vm services running on our build farm, and start fixing base packages
<janneke>currently, "guix build hello" does not succeed / fails when building coreutils-final
<apteryx>Are these VMs purely for experimenting with the Hurd, or are they intended to build stuff, for example?
<janneke>oh, and then there's lots to do before Hurd could be a first class option
<janneke>apteryx: they are totally meant to build stuff
<janneke>and do development, patch packages, fix bugs
<ngz>I wanted to test git send-email workflow instead of git format-patch + mail attachment. I'm wondering what the correct process is when dealing with multiple patches. In particular, the cover letter is send to bug-guix@gnu.org, but the actual patches are sent to a different address.
<apteryx>OK! In theory, using --target should be able to 'cross-compile' for Hurd, right? I guess we're just no there yet?
<janneke>apteryx: eh...i'm afraid i cannot follow you there
<apteryx>ngz: you would send the cover letter only to bug-guix, then upon receiving a confirmation email with the actual bug#, you would git-send the remaining patches to this email.
<janneke>the VM is entirely cross-built
<janneke>so, we can cross-build coreutils-final, and everything beyond that which is needed for guix
<ngz>apteryx: how would you do that, if I may ask? Isn't the cover letter created when sending the patch set?
<janneke>in fact, the cross build is more advanced than the native build
<janneke>but that's cheating, because the cross build does not run tests
<apteryx>I see! So it's useful to do native builds through a VM.
<apteryx>and for testing the integration
<apteryx>ngz: I guess you'd 'git format-patch --cover-letter' first to produce patch files
<janneke>apteryx: i guess they will go hand in hand for some time to come, i don't know
<janneke>it may depend on what people want to work on
<apteryx>then 'git send-email [your-options] your-cover-file'
<ngz>apteryx: OK. I was looking for a way to do it straight from git send-email, tho.
<apteryx>then 'git send-email [your-options] *.patch' or something
<apteryx>I haven't used that flow myself yet, though, as a disclaimer
<apteryx>Hopefully someone more 'in the know' will be happy to comment
<apteryx>janneke: OK!
<ngz>apteryx: OK. Thank you! I have a super-important patch introducing BurgerSpace, and I can't wait to test this workflow ;)
<apteryx>ngz: eh, have fun :-)
<apteryx>janneke: really neat to be able to play with the Hurd so easily on Guix. The last time I ran a Hurd VM was one from Debian. Thank you!
<bionicbeaver>+1
<janneke>apteryx: glad you like it
<janneke>Debian GNU/Hurd has been extremely helpful and it's still much more advanced
<janneke>i'm sure we can most work (if not all) on our own VM now
<romulas>GNU hurd guix is interesting too bad there are no videos of it on youtube
<romulas>Maybe in the future.
<lispmacs[work]>I just wanted to say congratulations on the progress with the reduced bootstrap binaries
<lispmacs[work]>janneke: ^
<janneke>lispmacs[work]: thank you!
<s34n>when I `guix package -u`, I'm told "guix package: warning: Consider running 'guix pull'"
<s34n>even if I just pulled
<bdju>s34n: try running `hash guix` to make sure you're using that new guix you just pulled