IRC channel logs

<nckx>(Still think it's the right thing, mind you, something something opinionated bastard.)

<pkill9>it would be good if it gave a warning that the graft failed to be applied, like --with-source does if it doesn't get applied

<nckx>Aurora_iz_kosmos: Aha! That might actually be a bug, if I understand search paths correctly.

<tao[m]>I'm seriously thinking of returning to the Guix fold but my NixOS + home-manager setup is perfect and I know Guix still doesn't have anything like home-manager

<nckx>pkill9: Yah, was about to type that. It should warn the user.

<nckx>tao[m]: Not yet. How's your Guile? 😇

<Aurora_iz_kosmos>Also, setting GIO makes a few other programs not from Guix crash.

<Aurora_iz_kosmos>Like tilix.

<pkill9>Aurora_iz_kosmos: gedit does because it propagates dconf which propagates glib which has search paths specified in it's package deifnition

<nckx>M-hm. If IceCat handles XDG_* ‘itself’ that's a valid reason to add it.

<nckx>That would be a good first patch IMHO if anyone's itching…

<Aurora_iz_kosmos>nckx: It tries to handle it itself and fails.

<Aurora_iz_kosmos>(As in, it does set some vars in the wrapper-script it has, but it doesn't work.)

<nckx>Interesting.

<rekado_>bioconductor packages should now be up to date

*rekado_ will rerun guix refresh to catch late updates tomorrow

<sirgazil>Aw, more delayed messages to the lists...

<nckx>Holy hell rekado_. You are a machine.

<nckx>sirgazil: Ah, I thought it was something on my end.

<PotentialUser-18>Hi friends, I'm trying to get guix working nicely on Ubuntu 19.04 and I'm running into some trouble with substitute telling me it's failed to install locales. Here's a pastebin https://pastebin.com/raw/Ag92fx43 Anyone have any ideas? I installed guix from the recommended shell installer script found here. https://www.gnu.org/software/guix/manual/e

<PotentialUser-18>n/html_node/Installation.html

<dftxbs3e>PotentialUser-18: I'm having the same issue, it doesnt seem to be a trouble for anything

<dftxbs3e>just the warning

<reepca>PotentialUser-18: It's possible that message is coming from the daemon's end, and GUIX_LOCPATH isn't defined in its environment yet.

<nckx>☝

<PotentialUser-18>'sudo systemctl restart guix-daemon' doesn't fix the warnings, although admittedly I'm a bit out of my depth here

<nckx>PotentialUser-18: I'm not familiar with systemd, but you have to somehow pass the variable to the daemon.

<dadinn>hi all

<nckx>dadinn: o/

<dftxbs3e>hello!

<dftxbs3e>still trying to bootstrap powerpc64le heh

<dftxbs3e>guix is quite slow to compile

<dftxbs3e>let alone the bootstrap-tarballs package

<nckx>uix calls GCC just as fast as any other package manager, we just call it more often. ;-)

<dftxbs3e>nckx: "make[2]: Entering directory '/tmp/guix-build-guile-2.2.4.drv-0/guile-2.2.4/bootstrap'" - wont use parallel compilation

<dftxbs3e>so it's quite slow : - (

<nckx>Hum. Shame. Oh well. How many Guix's could you bootstrap in parallel on that thing, if I might ask.

<dftxbs3e>nckx: ? what do you mean

<nckx>‘4 cores per package’. Neat.

<nckx>Have you been bootstrapping since yesterday?

<dftxbs3e>Trying to

<dftxbs3e>Had several runs of several hours

<dftxbs3e>on a 16 cores, 32gb ram, ssd machine

<dftxbs3e>amd64

<nckx>OK, that's frustrating without -j.

<dftxbs3e>right now it's fine

<dftxbs3e>it was just a particular step

<dftxbs3e>that was 1 core only

*nckx wonders if it's just caution or if there were real bugs with parallel compilation.

<dftxbs3e>probably caution or the build dependency graph is the bottleneck

<nckx>Re: ‘multiple runs’: which problems did you hit?

<dftxbs3e>nckx: missing archives that it cannot find in the /guix/store

<dftxbs3e>running again solves it, or using a different git revision

<dftxbs3e>because I'm running on a patched core-updates

<dftxbs3e>I *need* to

<nckx>Ah, because of the 128-bit thing?

<dftxbs3e>because bootstrap-tarballs wont build without GCC 6.2 and up

<dftxbs3e>yes

<nckx>Got it.

<dftxbs3e>so there's some guix bugs

<dftxbs3e>because it's an unstable version

<dftxbs3e>It's a bit fuzzy to report

<dftxbs3e>usually cleaning the environment and everything then re-doing it fixes it

<dftxbs3e>it did once

<samplet>dftxbs3e: I am very impressed that you are still working on this.

<dftxbs3e>I'm guessing there's a store corruption error

<dftxbs3e>samplet: well man, I got to run Guix on the Talos II!

<nckx>dftxbs3e: Sounds like an interesting (techie) blog post if you feel like it near the end ☺

<esper0s>man talos seems so sweet

<samplet>A worthy goal, for sure.

*nckx wants.

<dftxbs3e>nckx: I havent got a blog

<nckx>dftxbs3e: No, but Guix does!

<dftxbs3e>pff - guix failed again

<nckx>And TALOSen running Guix would be big news.

<esper0s>i wonder why doesnt system76, purism and ibm all collaborate

<esper0s>if they joined forces we could actually speed up the process of opening up firmware and hardware

<esper0s>but that would be wishfull thinking

<dftxbs3e>"error getting attributes of path /gnu/store/j4npmp...-mpc-1.1.0.tar.gz: No such file or directory"

<nckx>esper0s: Yeah, I want a free pony too ☹

<dftxbs3e>esper0s: not entirely sure it's in reach for IBM to produce laptop grade CPUs yet

<esper0s> https://www.youtube.com/watch?v=HtUH9z_Oey8

<esper0s>--> strawberry fields forever by the beatles

<dftxbs3e>what can we do about these /gnu/store corruption errors?

<dftxbs3e>on core-updates

<nckx>dftxbs3e: Is it actually corruption?

<dftxbs3e>nckx: well what else can it be?

<nckx>dftxbs3e: Does the file exist?

<M4R10zM0113R>I'm pretty sure I need to customize the initramfs myself in order to make my idea a reality, but... How do I go about switch_root into shepherd?

<dftxbs3e>nckx: nope

<M4R10zM0113R>Is it anything special or is it just simply the same switch_root /mnt/new_root

<nckx>M4R10zM0113R: Have you looked at (gnu build linux-boot)? There's a Schemey switch-root in there.

<dftxbs3e>nckx - samplet: I can write a blog post at the end if you wish

<nckx>dftxbs3e: As a quick hack, does ‘grep /gnu/store/…mpc….tar.gz /gnu/store/*.drv’ return anything?

<nckx>dftxbs3e: I fully understand if keeping notes or writing a whole post at the end is extra effort you can do without, but it would be cool.

<dftxbs3e>nckx: the mpc targz doesnt exist, so how do you want it to work here?

<dftxbs3e>nckx: thankfully my memory is quite good so it's about writing _just_ after the fact and it'll be fine

<nckx>dftxbs3e: You're grepping the .drv files in the store for any mention of that path.

<nckx>Doesn't mean it has to exist.

<nckx>But there's an off chance that there's a dependency loose somewhere and you can ‘guix build <that .drv file>’ to produce the tarball.

<nckx>You can also ‘guix download <tarball URL>’ if you can find it.

<dftxbs3e>nckx: sorry I confuse grep arg order

<nckx>These are all silly trivial ideas but I don't have any better ideas.

<dftxbs3e>nckx: yes it does exist

<nckx>I've never bootstrapped an entire architecture before ☺

<M4R10zM0113R>nckx: is it a package...?

<dftxbs3e>nckx: o_O I'll paste you the log because it's really weird

<dftxbs3e>nckx: http://dpaste.com/0NAMJAC

<dftxbs3e>with guix download

<dftxbs3e>guix download mirror://gnu/mpc/mpc-1.1.0.tar.gz

<nckx>M4R10zM0113R: It's a Guile procedure. Since I don't know your background or exactly what you're trying to do: you do know that the Guix initrd is a Scheme programme, not the usual busybox+shell scripts? It only contains a handful of packages, and those are things like e2fsprogs and cryptsetup.

<nckx>dftxbs3e: Er. That's a new one. I'm stumped.

<dftxbs3e>nckx: FYI, I ran guix gc at some point

<nckx>It works here, so I guess we're in weird bootstrapping/crossbuilding bugs territory.

<dftxbs3e>nckx: try with core-updates

<nckx>dftxbs3e: That should'n hurt.

<dftxbs3e>I'm on that branch so

<nckx>I'll give it a try, but this is just a poor old ThinkPad with 4 fake cores…

<dftxbs3e>nckx: btw I'm running guix download on amd64, no bootstrap specific stuff

<nckx>Oh.

<dftxbs3e>the build of bootstrap-tarballs failed but then I'm running this command independently of the rest

<nckx>Well, I'm bootstrapping (in the boring && ./configure sense), let's see how long it takes. My core-updates worktree was months out of date.

*nckx goes AFK to heat up some soup while their laptop heats up.

<dftxbs3e>:D

<reepca>nckx: garbage collection *could* in theory hurt if there are obfuscated references. For example, if contents get compressed, encrypted, split up, etc. Certain gcc optimizations used to cause it, for example.

<dftxbs3e>I ran the build on another machine where guix gc was NEVER ran

<dftxbs3e>it's pending

<nckx>reepca: I thought we patched GCC for that specific problem, but super great point.

<samplet>That would be an exciting bug for a Sunday night.

<reepca>nckx: aye, but packaging guix stuff has taught me that build processes can and will do literally anything I'm not expecting

<dftxbs3e>samplet: aha glad to cause some

<nckx>reepca: But unless I'm missing something that would still result in a ‘consistent’ (just not semantically correct) store & wouldn't cause the download to fail in that weird way.

<samplet>GNOME 3.30 works well, so hopefully we can merge it in soon. :)

<nckx>reepca: Yeah, IME you develop an intuition for ‘best not do x just now…’ even when you don't know exactly what could go wrong 😃

<nckx>(Guix 1.0: What Could Possibly Go Wrong, if we did the release name thing.)

<reepca>nckx: true, it shouldn't cause the download to fail like that

*nckx 's partner just complained that the CPU fan woke them up :-/ Downclocking a bit…

<reepca>unless something the downloader depended on ended up not referenced and got gc'ed, but I'm pretty sure that downloader in particular is a Builtin™.

<nckx>It's also a incorrect error message if that were the case, but hey, Unix.

<nckx>(Gut tells me this won't be reproducible anyway.)

<dftxbs3e>nckx: if you want to get a shell on my VM you can

<dftxbs3e>You'll need to establish a reverse shell

<dftxbs3e>I can't open ports

<dftxbs3e>so you'll have to provide me with ip:port for a machine and I'll forward you my local 22 port to some other port

<dftxbs3e>and then you can connect with ssh user@127.0.0.1 -p port

<nckx>dftxbs3e: Thanks, but I was hoping to go to bed in 15 minutes or so… Sorry.

<dftxbs3e>nckx: heh I can keep the machine in the same state for tomorrow : - )

<nckx>Not sure you'd want sleepy nckx mucking about on your box anyway.

<dftxbs3e>It's a VM, so you'd be able to do anything you want I don't mind

<dftxbs3e>besides running a 0day vm escape exploit..

<nckx>dftxbs3e: If you have the time I'd report this to the ML, with the error message and any other info you might have.

<dftxbs3e>nckx: I'll try to gather useful debugging elements.. like my history

*nckx hides the shoe box with 0days.

<dftxbs3e>aha

<nckx>dftxbs3e: Also, are you coordinating with Tobias Platen in any way? They were also working on PowerGuix last I heard. That's completely optional, of course.

<dftxbs3e>nckx: well havent messaged them but I read some of their findings and basing off that

<dftxbs3e>I probably should.

<nckx>Great!

<reepca>oh, I just went back through the conversation history and realized the error message wasn't from building a derivation... whoops

<nckx>reepca: The derivation gave a similar error IIRC, but the last paste is indeed ‘guix download’.

<M4R10zM0113R>do I have to do (service slim-service-type) if I want SLiM?

<nckx>./pre-inst-env guix describe | Git checkout: | repository: /home/nckx/guix/.git/worktrees | branch: core-updates | commit: db65a4fd914be10f9170cb8ad049e15eefefd5a9

<nckx>OK, here goes nothing…

<nckx> http://dpaste.com/001J9QM

<nckx>Sadly: something.

<dftxbs3e>reepca: output of "./pre-inst-env guix build --target=powerpc64le-linux-gnu bootstrap-tarballs" - http://dpaste.com/0KFWD97

<samplet>M4R10zM0113R: Yes, but you will have to remove GDM, too.

<samplet>dftxbs3e: Did you try deleting that file using “guix gc -d ...”?

<samplet>(Sorry, I’m only half paying attention.)

<dftxbs3e>samplet: I used guix gc earlier but the file doesnt exist now

*nckx runs build bootstrap-tarballs.

<dftxbs3e>samplet: output of "guix download mirror://gnu/mpc/mpc-1.1.0.tar.gz" http://dpaste.com/0NAMJAC

<samplet>dftxbs3e: There’s also “guix gc --verify=repair,contents”.

<dftxbs3e>samplet: running that now

<dftxbs3e>now.. I get http://dpaste.com/2JN3X6B - for ./pre-inst-env guix build --target=powerpc64le-linux-gnu bootstrap-tarballs - on a fresh machine with core-updates + https://lists.gnu.org/archive/html/guix-devel/2019-03/txtqohIhmIeIy.txt patch

<dftxbs3e>samplet: thank you, that repaired it

<samplet>Cool.

<samplet>dftxbs3e: Were you able to compile something simple, like “hello”?

<dftxbs3e>samplet: before your command repaired it?

<dftxbs3e>or on that fresh machine

<dftxbs3e>yup

<samplet>dftxbs3e: Either, before trying the bootstrap tarballs.

<dftxbs3e>./pre-inst-env guix build --target=powerpc64le-linux-gnu hello - works

<samplet>That’s good.

<reepca>dftxbs3e: could you re-run that gmp build with --keep-failed, then paste /tmp/guix-build-gmp-6.1.2.drv-0/gmp-6.1.2/config.log (that path may be a little different than what I say)?

<dftxbs3e>reepca: sure

<davexunit>has anyone installed built coreboot with a guix system? I'm wondering if I really need to be build their special gcc toolchain or if I can just use guix.

<davexunit>s/installed//

<samplet>davexunit: I’ve worked with coreboot and Guix, but it was a while ago. Let me look at my notes about it.

<dftxbs3e>reepca: http://dpaste.com/3627KDN

<nckx>samplet: I'm also very interested in those notes. Any chance they can be published?

<dftxbs3e>reepca: "/gnu/store/h32ick5vi3d013bhcmga02z2rkz9aq16-gcc-cross-powerpc64le-linux-gnu-7.4.0/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory "

<M4R10zM0113R>wait... gdm?... I don't see it on config.scm... is it part of the desktop module or something?

<reepca>M4R10zM0113R: it's in %desktop-services I believe

<samplet>davexunit, nckx: It looks like I built coreboot by building their special toolchain and just building outside of the store. I did try to build it in the store, but parts of it use Ada. I made a GNAT package, but it is very ugly, and GNAT is not bootstrappable, so I never sent it in.

<M4R10zM0113R>reepca: base-services%? Is there more than config.scm I need to look on?

<nckx>samplet: Yeah, that libgfx GNAT dependency… seems like you got about as far as I did.

<nckx>Building things outside of Guix feels so tedious now.

<dftxbs3e>nckx: I may even start using guix for CI :P

<dftxbs3e>Once it's ported to powerpc64le it's going to be perfect

<nckx>Also make sure to back up your precious ~/project-foo directory because their ain't no way your ever reproducing that again.

<nckx>*you're, and with that it's officially time for me to go to bed.

<nckx>o/

<dftxbs3e>good night!

<davexunit>samplet: okay, good to know. thanks.

<samplet>M4R10zM0113R: GDM is not in %base-services. You could try to add SLiM to that, but I don’t know if it would work without the rest of %desktop-services (I’ve never tried).

<davexunit>the official coreboot docs say not to use your host's toolchain because it's not "reproducible"

<davexunit>little do they know that I use guix ;)

<davexunit>but yeah, the lack of a gnat package is a blocker so I'll just build their toolchain.

<samplet>davexunit: I got nervous about changing toolchains because stuff like memory timing is finicky. I could see how changing compiler versions could break boot firmware.

<samplet>dftxbs3e: It looks like the C++ cross-compiler can’t find “stdlib.h”. What could that mean?

<dftxbs3e>samplet: well if I knew about Guile :S

<dftxbs3e>I never wrote anything functional so that's vodoo to me

<dftxbs3e>I don't even get how I should be reading the code

<dftxbs3e>From top to bottom or bottom to top? :S

<samplet>dftxbs3e: What are you looking at now? I was talking about the paste you just sent.

<dftxbs3e>samplet: nothing more, to fix that missing header issue

<dftxbs3e>I can't understand the package scripts

<dftxbs3e>to fix

<samplet>Ah okay.

<M4R10zM0113R>does it matter what the services %*-services is named?

<samplet>M4R10zM0113R: They are defined by Guix. The %base-services list contains basic services like TTYs and the Guix Daemon. The %desktop-services list contains all of those plus services for desktops, like (IIRC) eudev and GDM.

<reepca>dftxbs3e: what does '$(/gnu/store/516li48bmfm2jyp94hykcabixqwpm7vc-gcc-cross-powerpc64le-linux-gnu-7.4.0/bin/gcc -print-prog-name=cc1plus) -v' say?

<dftxbs3e>reepca: ohh sorry, I'll run that now

<dftxbs3e>reepca: not found

<dftxbs3e>kssmqhhizk346aswsm3mqwipax15lnf2-gcc-cross-sans-libc-powerpc64le-linux-gnu-7.4.0/ exists tho

<samplet>They are all powerpc-blah-gcc.

<samplet>The binaries, that is.

<dftxbs3e>samplet: right

<reepca>ah, then one of those instead of just 'gcc' I guess

<dftxbs3e>reepca: your command waits on stdin

<reepca>did you include the -v outside of the $()?

<dftxbs3e>reepca: yes

<reepca>oh, yeah, just tried it, guess it does, feel free to C-c that

<reepca>it prints out stuff before that though, right?

<dftxbs3e>reepca: http://dpaste.com/3RVFMWN

<dftxbs3e>yup

<dftxbs3e>reepca: if you want a shell on the machine..

<samplet>dftxbs3e: I see in “gnu/packages/cross-base.scm” that it should be setting “CROSS_CPLUS_INCLUDE_PATH” to fix this. I don’t see that variable in “config.log”, though.

<dftxbs3e>samplet: in core-updates?

<samplet>Yup.

<samplet>Oh, but it might only be when building GCC.

<reepca>IIRC for gcc >= 6 we had to switch from C_INCLUDE_PATH to CPATH or something...

<samplet>Okay. On master, if I cross compile GMP for ARM, it sets “CROSS_CPLUS_INCLUDE_PATH”.

<se-sm-ca>anyone else using dwm? I get it to start but the default key combo to launch a terminal seems to do nothing. Where is the config for dwm located or do I have to generate my own?

<samplet>reepca: Good memory: <http://bugs.gnu.org/30756>.

<dftxbs3e>samplet: when I tried master, I got another error when bootstrapping heh

<dftxbs3e>can you give a patch to apply on core-updates?

<samplet>dftxbs3e: Not yet. I’m just trying to figure out what should be happening and then work back. You definitely need to be on core-updates.

<dftxbs3e>samplet: okay, thank you so much

<reepca>Hm, in magit the passphrase prompt is showing up in the magit-process output... anyone else experience that?

<samplet>dftxbs3e: This is getting too tricky for me. It looks like we stopped using CPLUS_INCLUDE_PATH in favour of just CPATH (don’t ask me why – that bug report is complicated). For whatever reason, g++ is not happy with this when compiling GMP.

<samplet>When building GCC, we now manually set CROSS_CPLUS_INCLUDE_PATH.

<samplet>We could try setting that for GMP.

<dftxbs3e>samplet: how do I do that?

<samplet>dftxbs3e: Just making a patch.

<dftxbs3e>samplet: awesome

<samplet>dftxbs3e: Try this <https://paste.debian.net/1081641/>.

<dftxbs3e>samplet: Thanks! Doing now!

<dftxbs3e>samplet: hehh let me paste output

<dftxbs3e>samplet: http://dpaste.com/1R430NY

*samplet looks nervous.

<samplet>Ah. Whoops!

<dftxbs3e>samplet: what does that mean? Aha

<samplet>dftxbs3e: Found the problem. Just a sec.

<dftxbs3e>samplet: coool :D

<samplet>dftxbs3e: Where it says “#:key inputs” put “#:key inputs target”, and replace “(%current-target-system)” with “target”.

<dftxbs3e>samplet: okayy

<samplet>dftxbs3e: Also, that paste looked very different than <http://dpaste.com/2JN3X6B>. Are you sure you ran the same command? (Look at where it says “set-paths”.)

<dftxbs3e>samplet: yup

<dftxbs3e>samplet: it's going now!!! thanks so much'

<dftxbs3e>building gmp full speed

<samplet>\o/

<dftxbs3e>and tests are passing and passing, some are left but looks good so far!

<dftxbs3e>and successfully built and tested!

<samplet>dftxbs3e: Does the next library fail with the same problem?

<dftxbs3e>samplet: currently going, no error yet :P

<samplet>dftxbs3e: Now I’m excited!

<dftxbs3e>samplet: me too :D

<dftxbs3e>samplet: ohh and the command may have been slightly different, removing --keep-failed

<dftxbs3e>ahh it's rebuilding guile I think

<dftxbs3e>That one takes a _long_ time

<dftxbs3e>rebuilding or building a different version

<dftxbs3e>I think guile is bootstrapped by an interpreted compiler..

<dftxbs3e>like a compiler in guile, interpreted by guile

<dftxbs3e>which makes it slow

<dftxbs3e>samplet: still going..

<samplet>dftxbs3e: Yeah... Guile and GCC are bootstrap binaries, and they both take a while to build.

<reepca>Apparently /var/cache/ddclient/ddclient.cache is owned by... sshd?!?!?

<reepca>That's a plot twist right there

<reepca>explains why it's been failing to start

<reepca>or at least, the group is sshd... the user is apparently a user that doesn't exist anymore (just shows up as a pid). Weird.

<reepca>(er, uid)

<dftxbs3e>samplet: ehhh it began compiling the same guile, AGAIN

<dftxbs3e>isnt there a dependency loop?

<samplet>reepca: I’ve seen that before. It happens when you have a user, delete a user, and then add the same user again. The names will be the same, but the IDs may differ.

<samplet>We have the same problem with GDM.

<reepca>samplet: I suppose something changed about the way uids are decided between reconfigures?

<samplet>reepca: Something like that. I never looked into it.

<samplet>dftxbs3e: No loop.

<dftxbs3e>samplet: also "./configure: line 7314: hostname: command not found" on pre-configure in guile-2.2.4

<samplet>dftxbs3e: It might just be a slightly different Guile (like statically-built or something).

<dftxbs3e>it looks like hostname not found doesnt bother configure

<dftxbs3e>it's treated as non-fatal

<samplet>It’s probably okay, yeah.

<dftxbs3e> https://www.youtube.com/watch?v=rWzABnQHZ8g amazing music :D

<dftxbs3e>samplet: finally built guile!

<samplet>dftxbs3e: Cool! What’s next?

<dftxbs3e>samplet: gettext-minimal which just built and now m4

<dftxbs3e>samplet: m4 just finished and now gmp 6.1.2 again..

<dftxbs3e>and now perl!

<dftxbs3e>perl built

<dftxbs3e>damn this machine is quite fast

<dftxbs3e>expat

<dftxbs3e>and few others that built in less than a second, I couldnt even see

<samplet>So far so good....

<dftxbs3e>I got a 16 cores VPS from Digital Ocean to do this

<dftxbs3e>It's surprisingly fast

<dftxbs3e>gettext now (not minimal)

<dftxbs3e>gettext-tools

<dftxbs3e>the one I couldnt see was acl

<dftxbs3e>grep

<dftxbs3e>m4 again

<dftxbs3e>coreutils

<dftxbs3e>gmp AGAIN

<samplet>Third time’s the charm, as they say.

<dftxbs3e>bzip2

<dftxbs3e>aha

<dftxbs3e>build logs are so fast some times I can't even see what it compiles

<samplet>Let’s just be grateful for that. :)

<dftxbs3e>gzip, libsigsegv and now gawk

<dftxbs3e>perl again

<dftxbs3e>patch!

<dftxbs3e>attr

<dftxbs3e>perl AGAIN

<dftxbs3e>acl

<dftxbs3e>diffutils

<dftxbs3e>pkg-config

<dftxbs3e>why does the bootstrap tarball contain all that?

<dftxbs3e>or that's build dependencies..?

<dftxbs3e>and it's again on coreutils

<samplet>dftxbs3e: Mostly dependencies. They do include patch, diffutils, gzip, and gawk.

<samplet>There’s a pretty fun read on the bootstrap process in the manual.

<dftxbs3e>samplet: oh? I thought I read it all

<samplet>dftxbs3e: Chapter 12 “Bootstrapping”.

<dftxbs3e>samplet: well yeah I read that

<dftxbs3e>make built with make, the irony :D

<dftxbs3e>funny seeing ram disk cache increase over tar tests with sparse files

<dftxbs3e>yellow bar in htop left and right

<dftxbs3e>it's even building bash

<apteryx>dftxbs3e: you could inspect some graphes if you wanted to widen your view of what's going on :-)

<apteryx>graphs* as generated by `guix graph'

<apteryx>(and rendered using dot from graphviz)

<dftxbs3e>apteryx: I should try that yes, I've saw some nix presentation videos where they showcased some

<dftxbs3e>apteryx: is there a way to generate a graph for something that's going to be cross compiled to some target?

<dftxbs3e>hm apparently it wont work for things like "bootstrap-tarballs"

<dftxbs3e>or I'm bad at using dot

<apteryx>dftxbs3e: I think for this kind of special build you could graph the derivation (.drv) file produced by guix build -d

<dftxbs3e>apteryx: ah okay, well I'll try that when the build is finished, I don't want to disturb too much. Thanks.

<apteryx>guix graph -t derivation `guix build -d -your -other -options some-package`

<dftxbs3e>nice

<dftxbs3e>funny how my 4 cores laptop managed to get synchronized in the build process with the 16 cores vps

<dftxbs3e>they're both building the same things at the same speed... even tho one has 4 cores on a mobile cpu and the other has 16 cores on a server cpu ...

<dftxbs3e>laptop's ssd is probably faster though. nvme

<dftxbs3e>the laptop even managed to take significant progress ahead of the vps

<dftxbs3e>o_O

***PotentialUser-29 is now known as wql5

<samplet>dftxbs3e: How’s it look?

<igq>hey, anyone here use syncthing? I'm trying to install it and my build fails in the 'increase-test-timeout' phase due to what seems like a failing golang test.

<brendyyn>i use it but have never had that issue

<g_bor[m]>5532 yyy78v07821''''''',,,,,,,nú h0 0vhgz5u7*5j8,9615c54y

<g_bor[m]>m 6núllllőál4ő

<TurBo_biT>Hi all

<TurBo_biT>guix is like gentoo in the "installation" of packages compiling it?

<reepca>TurBo_biT: sort of, it's possible to transparently get pre-built binaries from a trusted substitute server, but falling back to compiling from source automatically is always an option.

<reepca>on a different note, I found out what was up with magit: openssh 8.0 changed the way their password prompt is printed, so I need to update magit accordingly

<ison[m]1>I'm trying to repair a store item but it doesn't seem to do anything. I am getting corrupt video after an update (screen looks totally scrambled) and I have determined the problem is in mesa, the libGL.so.1 library. When I run "guix gc –check" on the derivation it says the output differs from the one in the store. So then I try to use "guix gc –repair" and it finishes in 2 seconds and only outputs the store path. It doesn'

<ison[m]1>seem like it builds anything. When I try –check again it still says it differs.

<TurBo_biT>thx reepca

<TurBo_biT>are you thinking about give support to Power architecture?

<reepca>ison[m]1: when you say "the derivation", do you mean the /gnu/store/...-mesa-XXX path or the /gnu/store/...-mesa-XXX.drv path?

<ison[m]1>reepca: the .drv path (obtained by running guix gc –derivers on the other path)

<reepca>the latter is "the derivation", but it's a description of how to produce the store path that contains libGL.so.1

<reepca>it's not clear how to repair a derivation, as the only bookkeeping the store keeps about it is the hash. Repairing a derivation's outputs is just re-running the build. But the derivations themselves are crafted by the client-side guix code and transferred as-is to the store.

<reepca>you could try gc'ing the derivation and then running guix build -d mesa (or whatever the proper package name is) and that should re-send all necessary derivations that aren't already there

<ison[m]1>reepca: well I tried both paths actually, I only assumed I had to provide the .drv path because when I did the other one it didn't give any output at all

<ison[m]1>reepca: I basically just want to keep the new build that –check does and replace the old one, but it seems like it just reports that it differs and that throws it away

<reepca>I can't seem to find options called --check or --repair for 'guix gc', there's --verify=repair and there's 'guix build --check'.

<ison[m]1>right, I'm using guix build –check. There's also a guix build –repair

<reepca>ah, okay. so you ran 'guix build --repair mesa' and nothing seemed to happen?

<reepca>(apologies if I seem slow about this)

<ison[m]1>Right, there's no output at all and it finishes instantly. However, with –check it actualy takes a few minutes and I can see the build output

<reepca>hmmm. Well the issue there is that "repairing" a store path only happens if its hash doesn't match what's registered in the database. Since nothing is happening, presumably the hash does match. So the output isn't "corrupt", but as you discovered with --check, its output is nondeterministic (a second build produced different results). But the daemon has no way of knowing which is the "right" one, as the existing one is already known to

<reepca>be a valid result of building that derivation.

<ison[m]1>So is there no way for me to just re-build the item in the store then (and keep the re-build)?

<reepca>it'd basically be rolling the dice a second time, with no guarantee that it would be any better. Do we know anything about what specifically in libGL.so.1 is the problem?

<donofrio>need advice..... we are restricted to /app directory only to install and house our stacks (linux folks keep rest of OS and root) I have root for a hour as needed - I'd like to know how to make /app "root" for guix what switch do I feed installer to get this to work or do I simply need to compile from source (host os's are suse, redhat, aix7)

<ison[m]1>reepca: I wish I could narrow it down more, but there are no errors. It's just corrupt video. Even the log-in screen is corrupt (it just looks like weird lines all over the screen). I'm sure it's that library though because if I run something with LDPRELOAD to my previous working version of libGL then it works.

<reepca>donofrio: first important piece of information, if you can't secure consistent write access to /gnu/store for the daemon and you put the store somewhere else in the filesystem, the hashes of store items will differ and you won't be able to get most binary substitutes

<donofrio>I could push them for that or could I just symlink it so /app would be / making that work? cause the host os doesn't care about that gnu directory

<reepca>the store directory can't be a symlink, as all paths get canonicalized. What do you mean by making /app "root" for guix? Making it the installation prefix?

<donofrio>worse case linux folks can make the ln -s /app/gnu/store /gnu/store ?

<reepca>it would still internally be resolved to /app/gnu/store, and the hash part of store paths would be computed based on that.

<str1ngs>symlink won't work use a bind mount

<donofrio>what I mean by /app as root is we have full access to /app and not much else.....so we've been using ansable and static releases version file to pull apache pcre openssl and php or jboss, but this get stale too quickly to keep up with the vulnerability so I found this project and it seems like the perfect answer to our package needs we currently have no package concept for the /app structure

<reepca>if you could convince the linux folks to bind-mount /gnu/store to /app/gnu/store, substitutes would be available.

<ison[m]1>What about adding a users with home directory inside /app?

<reepca>you'll have to install from source, though, I believe, as you don't have access to /var, which the installer would try to write to by default

<reepca>ison[m]1: could you elaborate? I'm not sure what you mean.

<ison[m]1>reepca: well i guess I'm not sure exactly what his situation is. If he can get the admin to install guix normally (with store in /gnu/store) then he could manage everything without needing root access just by having a user in /app

<donofrio>ok if I compile from source will I be able to repoint /gnu/store to /app/gnu/store?

<M4R10zM0113R>wouldn't linking work?

<donofrio>what I was saying is we mightbe able to get another directory created to a mount to make /gnu/store owned by us along with /app or as suggested a mount of /gnu/store from /app or something like that?

<donofrio>linking what is that command?

<donofrio>I only know off top of my head 'ln -s'

<reepca>M4R10zM0113R: if you're referring to symbolic linking, no, the store directory is canonicalized (symlinks resolved) prior to computing hashes and such, so substitutes wouldn't be available.

<reepca>ison[m]1: true, but it would require the admin to be okay with the guix daemon constantly running as root

<donofrio>so I just need to request that /gnu/store is owned by us and I should be alright with stock installer script?

<donofrio>thought is ran as user? (thought I read that on the webpage?)

<reepca>donofrio: not exactly, assuming the daemon won't be allowed root access, you'll need a localstatedir other than /var, so guix will have to be configured for that.

<donofrio>felt like WSL for everything else (usermode = gnix?)

<donofrio>that /var might not work out so smoothly...the host os owns /var

<reepca>donofrio: aye, so if you download a source release you can run ./configure --prefix=/app and localstatedir will default to /app/var.]

<ison[m]1>reepca: It just sounds to me like there's a misconception here. He's saying that he can request /gnu/store be owned by his user, so it sounds to me like he can get Guix installed normally, with the daemon running and all, and he's just not sure that he can install packages without root

<ison[m]1>donofrio: Are you aware that once Guix is installed under root normally that you can still install and update packages as a normal user without root privileges?

<reepca>ison[m]1: ah, that does seem possible

<donofrio>what about /var?

<donofrio>I'm not concrned if I have to compile - do it all day at work lol

<ison[m]1>donofrio: well assuming you have Guix fully installed the normal way then the daemon should take care of all that. Basically there is a guix daemon which has root access and you can communicate with that daemon to build and update your packages without you having root access yourself

<donofrio>my daily driver desktop = tinyurl.com/donofrioworkdesk fwiw (offtopic just figured I'd share)

<donofrio>we have systemd access so why do I need root? and what I mean by systemd access is I make the start and stop scripts and linux folks make it systemd'd for us to start and stop being our service accounts

<donofrio>am I correct that guix provides usermode like unix on linux? (probably over simplifed but that is how this feels right now?) course only heard about this great project yesterday from slashdot

<reepca>I'm not sure what you mean by "usermode like unix". Regarding systemd, the guix installer puts a service file for the daemon in /etc/systemd/system, from which it will be automatically run as root by systemd. Using guix after that point does not require root for anything but the daemon.

<donofrio>ok should be alright we'll make it work....so only way to fix /var is to compile? would like it to user /app/gnu/var or something like that

<reepca> /var is only used by the daemon, so as long as it's okay for the daemon to run as root it's okay for it to use /var.

<donofrio>ok kewl....

<donofrio>any other suggestions I'm open and will lurk here forever now ;)

<ison[m]1>donofrio: Sorry, it just sounds like there might be some confusion here. So just to be clear the "normal" way to do this is to have Guix installed as root, with the guix-daemon running (perhaps your admin can take care of this part). Then once that's done any user on the machine can install their own per-user packages (which I assume is what you mean by the usermode).

<donofrio>ye sthat is what I mean

<ison[m]1>Cool, so if that works for you then basically you can just do the standard installation of Guix (or have your admin do it) and that should be it

<ison[m]1>It shouldn't require anything special

<donofrio>we live in /app compile make there do everything there (systemd/sudo needed to start apache and jboss/tomcat) but as I said everything is compiled now from static version files from ansible, would like to be able to say gnix upgrade apache and it would upgrade apache in /app

<donofrio>if the balk, if this where I use --prefix to compile to keep everything within /app (in that /gnu/store and /var would all be in /app?)

<donofrio>the = they

<donofrio>if = is

<donofrio>well the second one is if

<donofrio>tired but excited so typing gets bad lol

<marusich>If you put the store (/gnu/store) in a different location, then you will not be able to use the pre-built substitutes from the Guix build farm.

<donofrio>want all ablities that I can leverage....

<donofrio>just know linux folks do not like us outside of /app

<marusich>You can still build the software from source, but it will be slow if you put the store in a non-standard location.

<marusich>If you can set up your own build farm, you could also publish your own substitutes for your custom store path (e.g., /app/gnu/store)

<marusich>By the way, the reason you can't use the build farm's substitutes in that case is because the store prefix ("/gnu/store") is one of the many factors which determines the hash in a derivation's output path.

<marusich>If your store prefix doesn't match the one used by the build farm, the store paths you build will never look like the ones published by the build farm; they will all have different hashes.

<marusich>So, every time Guix asks the build farm, "Do you have a substitute for this store item?" the answer will be "no"

<reepca>on an unrelated note, current emacs-magit checkout fails to build because it expects to find libgit, and all we have is libgit2...

<buenouanq>2 things I'm going to attempt to package this week: gmusicbrowser and ibniz

<buenouanq>wish me luck (-‿‿ - )

<dddddd>good luck, buenouanq!

<reepca>actually I might have that wrong and the error message is just misleading

<dddddd>ibniz seems cool, indeed. Didn't know about it.

<buenouanq>dddddd: it's the coolest

<buenouanq>viznut is a cool guy, his whole blog is worth reading

<reepca>oh huh, yeah, looks like it depends on a separate package containing elisp bindings for libgit2, but it's just called 'libgit'

<dddddd>buenouanq, thanks! I'll take a look.

<civodul>Hello Guix!

<efraim>hi!

<efraim>librsvg@2.40.20 doesn't build for me unless I add python-2 to native-inputs

<civodul>efraim: works for me on 746ac457cc2748152a3a39d4296972fa20f19741 (x86_64)

<efraim>civodul: fails on bayfront without

<civodul>which commit?

<efraim>mouse click isn't working for me, a321312e3

<civodul>given the number of dependents, we'd have noticed no? :-)

<civodul>hmm i don't have that one

*civodul pulls

<efraim>I would think so

<efraim>same with mariadb, turns out it was a timeout issue, it finally built correctly on bayfront

<efraim>error is that gobject-introspection doesn't carry python-2 into the build environment but tries to use it during the build phase

<civodul>so it should be deterministic

<civodul>could you compare the build logs?

<efraim>yeah, i'll try to

<efraim>built without problem on my local machine without python-2 added :/

<civodul> https://berlin.guixsd.org/log/njs2wakckxadc3iqnnrhvkkf2qr3v1zk-librsvg-2.40.20

<efraim>log isn't local on bayfront, rebuilding

*efraim goes afk for a bit :/

*civodul tests the GCC 9 patches by carldong

<ZombieChicken>So there is officially ARM support now?

<ZombieChicken>or is that just the package manager?

<jonsger>ZombieChicken: no also for the distribution itself

<ZombieChicken>didn't see a link to a download for it on the page

<ZombieChicken>but neat. I may give GuixSD another go if the new installer is actually tolerable

<efraim>The Guix System image for ARM is per device, so we don't often pre-build them

<ZombieChicken>ok

<civodul>i wonder if we could provide an AArch64/UEFI image

<civodul>not sure if that'd be useful

<efraim>It might be, it should work out of the box on the overdrives

<efraim>I wonder if we could split the u-boot and OS images, u-boot can boot UEFI

<efraim>I bet vagrant would know

<rekado>Hi Guix, what up?

<civodul>hi rekado!

<civodul>i'm doing a round of patch reviews

<rekado>me too!

<civodul>it seems this hasn't happened in a while :-)

<civodul>cool!

<rekado>I really wanted to do this this week, but with only the 2GB RAM laptop here I haven’t been able to build anything locally.

<rekado>for the bioconductor updates I used berlin as a development machine…

<rekado>now I’m back in the office and use my workstation for that.

<civodul>yay

<civodul>so your Librem broke?

<rekado>it’s been in a broken state for a long time

<civodul>bah

<rekado>since I had to buy the extended warranty (because it’s for work) I got an offer to send it in for repairs

<rekado>I just delayed it as long as I could … and finally gave in.

<rekado>it has accumulated quite a few problems that I hope can be fixed

<civodul>RAM issues?

<rekado>broken speakers, broken microphone wiring, display backlight flicker (since day 1), etc.

<rekado>I had RAM issues on the first day but met a Purism sales rep at FOSDEM just a few days after receiving it, and they swapped it out right there.

<rekado>the backlight flickering was the worst. It got very bad whenever the thing was on battery

<rekado>so I always had it plugged in

<rekado>which isn’t good for the battery, so now the battery is so bad that it shut down when it’s at 45%

<rekado>I’m now using my partner’s T60, which has a chipset that doesn’t support more than 3G RAM.

<rekado>Emacs seems to be using again more RAM lately, so just Emacs + Guix + GNOME usually exhaust all memory ¯\_(ツ)_/¯

<civodul>uh

<civodul>well GNOME is hungry, try ratpoison ;-)

<civodul>(Guix is hungry too, but hey, it's so great!)

<rekado>GNOME is actually great too.

<rekado>I know, I know, but hear me out…!

<ZombieChicken>rekado: Do you know if those issues with the Librem are normal?

<ZombieChicken>been thinking of getting one at some point, and would like to know if it's a quality issue or not

<rekado>when GNOME works it really works well and you don’t have to tap into tribal knowledge to connect to an external display…

<rekado>ZombieChicken: there are a couple of forum posts about the backlight problem and the support people there don’t really seem to know what’s causing it.

<rekado>they suggest kernel options (which don’t work), reseating the display connector (which didn’t help), installing blobby Linux (which I didn’t do), reflashing coreboot (just no), etc.

<civodul>rekado: yeah i've "used" GNOME a lot for testing purposes and i find the integration work to be pretty impressive

<rekado>I do think that it’s a quality control issue, because some machines are just fine.

<rekado>civodul: what I like least about GNOME is that I don’t understand how it works.

<rekado>but that one’s on me.

<civodul>yeah the downside is that plumbing is extraordinarily complex

<civodul>plus you have all this C OO code, with D-Bus, with async signals, topped with Vala and JS

<civodul>that's a complex beast

<rekado>ZombieChicken: I think for the very high price it’s a little disappointing. On the other hand I really appreciated not having to muck about with BIOS hacks to make a Linux-libre compatible Wifi card work.

<rekado>civodul: yeah, the complexity makes it hard for me to understand how to debug things.

<rekado>and that’s pretty frustrating.

<civodul>diving into gnome-shell + gdm + localed/systemd just to debug the gdm keyboard layout issue was... interesting

<efraim>I've heard the build quality goes up dramatically as they have more revisions of the hardware

<cbaines>Quick g-expressions question, I'm seeing things like (quasiquote ((test unquote 1))) be generated. This looks wrong and invalid to me, but it actually seems to work, so now I'm a bit confused?

<ZombieChicken>rekado: Yeah. ANything like that will have some problems, but if it's backlight is generally unreliable on battery, that is a serious problem

<ZombieChicken>any hardware problem is an issue, really. Software can be fixed, whereas hardware is a much different issue

<ZombieChicken>the price is kind of to be expected; it's a new market and a new idea without the economies of scale you get from Dell, HP, et al.

***daviid is now known as Guest84852

<rekado>ZombieChicken: I found the production quality to be sub-par. This is the Librem 13v2. I hear they’ve got newer revisions now.

<civodul>cbaines: yes

<civodul>:-)

<civodul>cbaines: it's like `((test . ,1))

<rekado>on the board they used an excessive amount of white glue to fix cables and thin wires

<ZombieChicken>rekado: Thanks for giving me the revision number. Gives me something to guage things by

<rekado>the microphone wires that connect the microphone to the kill switch, for example, are really thin and only held together by the glue

<rekado>so there was lots of noise on the mic until the wire just came off…

<ZombieChicken>yeah, they're apparently on rev4

<cbaines>civodul, I get that, as that's literally the input I gave. I was just expecting (quasiquote ((test (unquote 1)))) or something similar

<rekado>I think roptat has the 13v3(?) and AFAIK there have been no major issues with that machine.

<cbaines>with brackets around the unquote

<ZombieChicken>good to know. Thanks

<roptat>It's a 15v3

<roptat>No major issue, I'm happy with it :)

<civodul>cbaines: `(a . ,b) = (quasiquote (a . (unquote b))) = (quasiquote (a unquote b))

<civodul>dotted syntax is not my favorite feature

<cbaines>civodul, ah, right, thanks, that makes sense. I was wondering where the . went.

<civodul>yeah it's confusing

<civodul>i think we should get rid of the dot in Guile 42 maybe?

<civodul>rekado: regarding 1.0.1, it looks like the story will be: new shepherd release with fix for wpa_supplicant PID file issue, address other installer issues (which are rather minor), and go ahead

<civodul>how does that sound?

<civodul>now is the time to report bugs!

<rekado>civodul: I thought you suspected that the PID file problem wasn’t the culprit after all?

<rekado>civodul: I’d really like to unbreak i686 as well.

<rekado>that was one of Mark’s bug reports

<civodul>rekado: i got evidence that the PID file problem is the culprit: https://issues.guix.info/issue/35550#14

<civodul>however mumi ate half of this message

<civodul>could be because it's lunch time

<civodul>full story at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35550#46

<civodul>rekado: re "unbreak i686", you mean Rust, right?

<rekado>it’s actually Debbugs eating half of the message :( Its SOAP API returns only part of some messages. It’s a known bug.

<rekado>I think I’ll switch from the SOAP service to shamelessly fetching messages via the Debbugs web interface. Bleh.

<rekado>civodul: right, Rust. Yes.

<rekado>but I don’t see a clean way forward other than to include a Rust binary for i686, thus skipping compilation of the first Rust with mrustc.

***pflanze_ is now known as pflanze

<civodul>bah

<civodul>we should ping Danny to know what he thinks

*civodul goes for lunch

<rekado> Danny was the one who reported this problem to upstream; upstream doesn’t seem to know what causes the problem.

<kabo>hmm, I'm unable to start firefox after downloading it...

<kabo>bash: ./firefox: No such file or directory

<kabo>uname -a : Linux guix 5.0.10-gnu #1 SMP 1 x86_64 GNU/Linux

<kabo>file firefox

<kabo>firefox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.26, BuildID[sha1]=eff0a761405f465fc60945a360d29265eefff01a, stripped

<brendyyn>Yeah it's that linker nonsense.

<kabo>output from ls

<kabo>-rwxr-xr-x 1 manager users 14712 May 5 10:40 /home/manager/Downloads/firefox/firefox

<kabo>it looks like an executable file to me...?

<brendyyn>you are on Guix system?

<kabo>yup

<brendyyn>foreign binaries won't work. see the path to ld-linux.

<kabo>ah, ok

<brendyyn>I think there is a program that can relink binaries, but im not sure if itd work

<kabo>hmm, at least I know I'm not crazy now :D

<brendyyn>I had the opposite problem when I tried running a guix build package on debian

<brendyyn>the "no such file or directory" thing doesnt refer to the firefox binary i think, but that linker stuff

<kabo>ah, I see

<rekado>you can link the glibc package’s ld-linux…so to /lib64

<kabo>I ran patchelf --set-interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2 ./firefox

<kabo>now I get ./firefox: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

<rekado>kabo: this will just be the first of many such errors. This binary was linked on an FHS system. Guix does not follow the FHS, so the libraries won’t be where the “firefox” binary expects them to be.

<kabo>ok

<kabo>so I need to build it from source if I want it to work?

<rekado>kabo: building from source would probably be better. I think ArneBab had an unfinished Guix package definition for Firefox.

<kabo>hmm, I've run guix install nss-certs but I keep getting certificate not valid errors

<kabo>what else do I need to install?

<rekado>have you set up the environment variables?

<rekado>see the application setup section in the manual

<kabo>I'm on guix system, so not a foreign dist

<kabo>and I'm getting cert errors with wget, in the browser, everywhere

<rekado>oh, okay

<rekado>that’s not normaly

<rekado>*normal

<kabo>and I can't install le-certs because of #35561

<rekado>did you use the installer to install the Guix system?

<rekado>I’m asking because there was this bug that caused the installed system to not include the base packages.

<kabo>ah, yeah I read about that one and did not select any extra packages

<kabo>thus getting the base packages

<kabo>then I ran guix install nss-certs afterwards

<kabo>do I need to run that as root or something?

<rekado>no

<rekado>I have nss-certs in the “packages” field of my operating system configuration.

<rekado>I didn’t need to set up any variables myself.

<kabo>/etc/config.scm?

<kabo>I haven't touched that file

<kabo>I need to go to bed

<kabo>Maybe I'll give guix another shot once 1.0.1 is out

<civodul>kabo: you can see how to fix the issue by reading https://www.gnu.org/software/guix/manual/en/html_node/Guided-Graphical-Installation.html

<civodul>or you can wait until 1.0.1 if you prefer :-)

<brendyyn>Can Icecat use mozilla sync?

<efraim>Yes

<brendyyn>ok im trying it out

<rekado>python2-ipython has broken tests.

<rekado>I feel that we need better processes when updating Python packages to make sure the Python2 variants that we still have don’t all break.

<brendyyn>I'm glad to see somebody that doesn't just want to throw python2 in the bin.

<rekado>oh, I *do* want to throw it away, but Python 2 is still on life support, so we should make sure our Python 2 packages can actually be built.

<brendyyn>Kovid Goyal doesn't want to throw it in the bin :/.

<rekado>Calibre…?

<brendyyn>yep

<brendyyn>He basically takes maintaining python2 packages himself, and python2 for windows, however there is some python3 stuff being merged in to the calibre repo from another developer, so their may be hope

***PotentialUser-31 is now known as desttinghim

<wednesday>rekado: Well python2 end of life is meant to be next year right? ha

<efraim>looks like gst-plugins-base FTBFS on armhf

<dadinn>how do i define key file for a LUKS mapped device in the system configuration?

<abbiya>is there any way to delete environments?

<abbiya>if thats a thing to be done

<brendyyn>abbiya: what do you mean?

<brendyyn>you mean the software that was build after you made an environment?

<abbiya>i am not sure

<abbiya>yes

<brendyyn>you can run `guix gc' to clean up any software that isn't referenced by a profile

<abbiya>guix gc --list-roots

<abbiya>is listing 12 profiles

<abbiya>how do i know what is what

<brendyyn>when you create an environment there will be a GUIX_ENVIRONMENT variable

<brendyyn>but does it matter?

<brendyyn>if you just run guix gc it will clean up everything

<dftxbs3e>samplet: Hi! - Next error "powerpc64le-linux-gnu-ld: /tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.28.drv-0/build/libc_pic.a: error adding symbols: archive has no index; run ranlib to add one"

<abbiya>thanks brendyyn

<dftxbs3e>samplet: on glibc - uploading log in a min

<civodul>abbiya: in general, all you need to do is to run "guix gc" periodically or, say, "guix gc --delete-generations=1m" to first delete profile generations that are more than one-month old

<brendyyn>abbiya: guix gc can take a list of paths, if you find the relevant paths then itll just clean up those things

<dftxbs3e>samplet: http://dpaste.com/2SBNCHC

<brendyyn>but generally nobody is bothered about such things, what does it matter if there is a bit of junk laying around for a bit?

<abbiya>i tried doing something like guix environment php

<abbiya>it failed after getting some packages

<abbiya>i am thinking that guix env is something like virtualenv

<brendyyn>abbiya: there is nothing to wory about with such failures

<abbiya>so wanted to delete the failed environment

<abbiya>ok

<brendyyn>Guix can fail all day long and it will all be fine

<abbiya>how are each env created different from each other

<brendyyn>They are simply a directory in /gnu/store

*rekado enables SELinux on the Fedora workstation to test the daemon policy

<abbiya>can we name those env ?

<brendyyn>then they are instatiated in your bash terminal by setting PATH, etc..

<abbiya>Say, i want to develop a php app. can i use guix env for that ? (without messing my host os packages)

<brendyyn>yes

<abbiya>can i also have different versions of envs ? like py2.7 and 3.0

<brendyyn>You can for example create a manifest.scm, which is a list of all the exact software you neet

<brendyyn>yes you can have all the versions of everything you want

<brendyyn>then this manifest can be used to instantiate your environment on the spot, and it will not affect anything outside that terminal.

<abbiya>host sees all the environments and their programs as normal things that are available in its path

<abbiya>outside that terminal ?

<abbiya>if i move out that terminal, can i see access the env ?

<abbiya>*still

<abbiya>sorry about all these questions

<brendyyn>well its all publicly viewable in the /gnu/store, but `guix environment' will not touch any environment variables outside the terminal you are running

<abbiya>oh

<abbiya>ok

<brendyyn>its just like if you run export FOO="cheese", you cannot see it in another terminal

<abbiya>yeah

<abbiya>why is golang not packaged for guix ?

<brendyyn>but you could easily make it so by running `env' and then copying the values, and setting them, if you lik

<brendyyn>it is

<samplet>dftxbs3e: Not sure. Sorry. Maybe take a closer look at “libc_pic.a”. We would need to know more precisely how it is broken.

<brendyyn>guix package --show=go

<abbiya>i see it now

<abbiya>so i can create a env just with go and write a program, compile & execute it

<abbiya>without touching my host

<brendyyn>yep, i mean its all just files in /gnu/store at the end of the day, however because it all neatly separates the environment, then what you say is essentially true

<abbiya>how to install a package with a version

<brendyyn>like package@version

<abbiya>upper cut

<brendyyn>and : is for outputs

<brendyyn>sometimes packages are split in to outputs, such as one containing binaries and another containing documentation.

<abbiya>what if my host already has some package like latest go

<abbiya>and i create a go env with some older version of go

<abbiya>with guix environment go@1.4.3

<abbiya>how it works then

<brendyyn>the same as always

<abbiya>i am seeing the host go

<brendyyn>have you looked at the files in /gnu/store/ look like? they all have paths with sha256 hashes, so there is no way there will be any conflict

<brendyyn>you may want --ad-hoc

<abbiya>i think i should use --pure

<brendyyn>guix environment go, will build an environment with all the dependencies for go it's self

<abbiya>my host machine also has go

<abbiya>after guix env

<brendyyn>"Build an environment that includes the dependencies of PACKAGE and execute

<brendyyn>COMMAND or an interactive shell in that environment"

<abbiya>if i check which go

<abbiya>i get the binary from host

<abbiya>not from guix store

<brendyyn>--ad-hoc include all specified packages in the environment instead

<brendyyn> of only their inputs

<abbiya>awesome

<abbiya>--ad-hoc is awesome

<brendyyn>usually you dont need --pure.

<abbiya>ok

<abbiya>cant wait to learn more about guix and containers

<abbiya>and use guix whenever i can

<brendyyn>abbiya: you may want to read through the blog posts on the guix home page, and of course the manual is very useful

<abbiya>sure

<abbiya>what else can guix do

<brendyyn>guix pack can make relocatable programs that can be installed with docker

<brendyyn>I haven't heard of anyone using it seriously to deloy anything yet, but it's already quite cool.

<brendyyn>guix pack is a good example of where guix's design gives you certain awesome things for free.

<abbiya>can guix be used not only as package manager also as software manager ?

<brendyyn>what is a software manager?

<abbiya>i dont know what to call it

<brendyyn>do you mean manage configuration?

<abbiya>like installing different versions of firefox

<abbiya>something like that

<brendyyn>isn't that what a package manager does?

<abbiya>yeah

<brendyyn>Then i'm not sure what you are asking.

<abbiya>in near future can guix replace the software center apps in linux ?

<brendyyn>Do you mean things like docker and flatpak etc?

<abbiya>yes

<abbiya>also guix is based on nix ?

<wednesday>guix already does that sorta stuff, and yes

<abbiya>nix has different versions of firefox

<abbiya>but guix does not

<brendyyn>I think it is already a good foundation from which those things can be replaced, however that realisation is not in the near future

<abbiya>why?

<brendyyn>Guix has Icecat.

<rekado>“based on nix” —> it implements the same ideas and reuses a small component of nix (the daemon)

<abbiya>re implements or using nix ?

<abbiya>ok

<brendyyn>civodul himself has a Nix hacker who decided to go rouge and make something new in Guile Scheme.

<rekado>it does not use nix. It contains a modified copy of the nix daemon.

<brendyyn>was*

<rekado>heh, go rogue

<abbiya>nix uses haskell ?

<abbiya>c++

<rekado>different part of nix are written in different languages.

<rekado>the daemon is written in C++

<abbiya>whole guix is written in guile ?

<rekado>yes, with the exception of the daemon (it’s being rewritten in Guile as part of a student project)

<civodul>see the programming language stats at https://www.openhub.net/p/gnuguix/ :-)

<brendyyn>According to Github it is 96.1% Scheme

<abbiya>thanks for info. i will start my scheme learning with guile

<samplet>Nix uses a custom language to generate Shell scripts that get run by the daemon. Guix uses Guile to generate Guile scripts that get run by the daemon.

<abbiya>ok

<abbiya>muchas gracias all. bye

*samplet gazes at “wip-build-systems-gexp” longingly.

<samplet>rekado: Should I bother with the GNOME 3.30 updates or will they just be clobbered by 3.32 updates?

<rekado>samplet: I don’t know.

<rekado>I would love to get to 3.32 quickly, but look at how long it took for the 3.28 upgrade to get merged.

<rekado>I had this done in late 2018.

<rekado>I think it makes sense to make sure that 3.30 is consistent and merge it as soon as feasible.

<civodul>samplet: re wip-build-systems-gexp, we should get that done! want to work on it?

<rekado>it’s fine to wait a little longer for 3.32

<bgardner>Good morning Guix; I'm working on building a package here and I'm having trouble with a dependency. The package depends on BDB and I'm getting "db.h" not found. My environment is "guix environment guix --ad-hoc=bdb" but I don't seem to have a proper INCLUDE set up based on "guix package --search-paths". Any advice on the proper way to proceed?

<brendyyn>whats wip-build-systems-gexp all about?

<civodul>it's about using gexps all the way down

<civodul>in "build systems"

<rekado>bgardner: you’ll also need gcc-toolchain

<brendyyn>what about in package definitions?

<bgardner>rekado: Referred to in the ad-hoc args?

<rekado>bgardner: yes, either that or install the toolchain.

<bgardner>rekado: Got it, thank you for the help!

<rekado>bgardner: would it make sense to write a Guix package definition instead of performing the build manually?

<civodul>brendyyn: yeah that too :-)

<samplet>rekado: Okay. It’s kind if awkward timing to push unstable GNOME updates on new 1.0 users. Should it go through staging again?

<brendyyn>civodul: did you solve the design problem? i think the issue was losing the power of giving inputs names

<wednesday>civodul: is there a benefit to only using gexps? heh

<samplet>(I am tempted to ask a few people to test the branch and then just merge it into master directly....)

<samplet>civodul: Kinda! I also need to find my way back to Gash, so we’ll see.

<rekado>samplet: the 3.30 upgrade includes an upgrade of glib, which is expensive enough to go to core-updates even.

<rekado>the glib upgrade could be disruptive

<civodul>samplet: cool! i have uncommitted changes to that branch from when i tried to resume work on it

<samplet>rekado: Ah right. I keep thinking of GNOME as the GNOME parts and not the GTK/GLib parts.

<samplet>That makes sense.

<rekado>the glib upgrade was necessary for some GNOME parts unfortunately.

<rekado>ugh, SELinux doesn’t like hardlinks. It’s confused to see that the policy for /gnu/store/.links/… is different from /gnu/store/…-guix…/bin/guix-daemon

<rekado>oh well.

<samplet>civodul: Good to know. I’ll be sure to ping you if I look into it.

<samplet>rekado: Okay. Thanks for letting me know the plan. Is it too soon to rebase on “core-updates”? It might make further testing more frustrating.

<rekado>we’ll have to test the thing on core-updates anyway, so we might as well do this now.

<rekado>we first should merge master (or staging?) into core-updates

<civodul>rekado: i've prepared this post: https://gitlab.inria.fr/guix-hpc/website/blob/f74fe8d474f91aeb5dc52599fd69c3e26dc4a6f5/posts/gnu-guix-1.0.0-released.md

<civodul>thoughts? :-)

<rekado>civodul: if you mention “OpenFOAM” do you think “TensorFlow” could also be mentioned?

<rekado>“benefiting from the benefits of Guix” sounds a bit funny.

<rekado>the rest is good!

<civodul>rekado: definitely

<bgardner>rekado: Um, I am building a guix package - that's why I needed the guix environment. Did I misunderstand?

<bgardner>rekado: And I have gcc-toolchain in & it added a CPATH that points to where db.h is, but I'm still getting an error on './pre-inst-env guix build <package>'. Hmm.

<rekado>bgardner: you misunderstood

<rekado>bgardner: nothing you do in your environment affects “guix build”

<rekado>that’s by design.

<rekado>can you show us the package definition?

<bgardner>rekado: Right, understood.

<bgardner>Sure, one moment

<bgardner>rekado: https://www.paste.org/98517

<rekado>(with SELinux enabled “guix gc” is extremely slow)

<dadinn>hmm, there seems to be no package for zfs kernel modules... any plans for such?

<roptat>isn't there a licensing issue?

<dadinn>roptat: it is a kernel module

<roptat>I think I remember its license is incompatible with the kernel's license, wich makes it impossible to redistribute it in binary form

<rekado>bgardner: the problem is with makedefs.

<dadinn>roptat: it is in the Debian repos... you have to build it yourself, binaries are not distributable due to licence incompatibility...

<rekado>bgardner: that’s how postfix looks for headers

<rekado>bgardner: it looks for db.h in /usr/include/db/db.h, which doesn’t exist in the build container.

<roptat>dadinn, then we'd need a way to disable substitutes for some packages...

<rekado>roptat: we have that.

<roptat>oh

<rekado>#:substitutable? #f

<roptat>I see

<roptat>so nothing prevents us from packaging zfs then?

*rekado doesn’t know

<dadinn>roptat: sorry, can you remind me what subsitutes mean? Is it to keep the binary builds of packages in a central repo?

<roptat>yes

<dadinn>so it's kinda like Arch AUR?

<roptat>not exactly

<rekado>a binary substitute is a binary that you can download as a substitute for a local build.

<dadinn>and if #:substitutable? #f then it must never get uploaded/stored?

<brendyyn> https://github.com/alcarithemad/zfsp

<brendyyn>"ZFS, in Python, without reading the original C"

<brendyyn>port this to guile

<brendyyn>then bob's your uncle

<roptat>with guix, you get package recipes that are built locally, but because most packages are reproducible, you cannot differentiate between a local build or a build from another computer or a build farm, substitutes are what we call downloads of build results (binaries) from someone else's computer (usually, the official build farm)

<roptat>I assume #:substitutable #f makes guix not even try to look for substitutes from any substitute url it knows of (or makes it unavoidable when publishing substitutes)

<efraim>My understanding is that with #:substitutable #f and maybe also #:local-build #t it should be ok

<roptat>unavailable*

<dadinn>brendyyn: who is bob? :)

<rekado>your uncle

<bgardner>rekado: Sure, and I experimented with modifying makedefs on the fly, but I don't have a source for the equivalent of (which x), but for the db.h file. Is there a guix-y way to do so?

<dadinn>ah, didn't know... but my family is complicated anyway :P

<rekado>bgardner: (string-append (assoc-ref inputs "gdb") "/include/db.h") or similar

<civodul>rekado: BTW, your thoughts about the title of the article: okay? pretentious?

<rekado>civodul: I think it’s just the right amount of pretentious to be read.

<brendyyn>civodul: I think you should have confidence because you've done great work that is currently underutilised.

<civodul>ok, thanks for reassuring me :-)

<bgardner>rekado: Got it, thanks - I'll give it a go

<brendyyn>Oh, so Guix's package definitions are what one calls an "API"?

<civodul>yeah

<civodul>so: https://guix-hpc.bordeaux.inria.fr/blog/2019/05/gnu-guix-1.0-foundation-for-hpc-reproducible-science/

<bgardner>rekado: I found that (string-append (assoc-ref %build-inputs "bdb") "/include") worked best, does that seem reasonable?

<rekado>where do you use this? If in a build phase please use (lambda* (#:key inputs #:allow-other-keys) …) to bind “inputs”.

<rekado>%build-inputs is magic; it’s better to be explicit and capture “inputs”.

<bgardner>rekado: Understood, I'll switch to that

<maddo>is this the ungoogled-chromium https://github.com/Eloston/ungoogled-chromium for privacy conscious users?

<amz3>regarding guile-pfds, I forgot to tell in the bug report that I have sent several mails to upstream to have feedback on the patch

<amz3>without response

<amz3>The maintainer is not responsive for several months

<amz3>sadly.

<mitescugd>anyone else had problems building plugins for bitlbee? the plugin doesn't appear. I've configured bitlbee with `--plugins=1` and `--plugindir=$GUIX_PROFILE/lib/bitlbee`, and the compiled plugin is there. I'll also ask around #bitlbee as a last resort, but maybe someone has a quick fix already. :)

<dongcarl>Any progress on packaging Guix for Debian?

<vagrantc>if so, it's very stealthy

<vagrantc>if someone wants to dive into packaging guix for debian, i can certainly provide review and suggestions

<vagrantc>to do it properly, it would require packaging some additional guile libraries in debian ...

<vagrantc>guile-git and guile-ssh, if i remember correctly

<vagrantc>if someone more guile-savvy wanted to work on those, i can help with the specifics of debian packaging

<vagrantc>you can also subscribe to the bug in debian: https://bugs.debian.org/850644

<vagrantc>there's also a way to cheat that would be much easier; packaging a downloader that downloads the guix binary distribution ... but would be cleaner to build from source

<dongcarl>vagrantc: I see... I will definitely subscribe to the bug, might attempt it if I get some time on my hands

<reepca>hm, denemo wants a specifically 3.0 gtksourceview, but currently it's just using the latest (which is now up to 4.x), so the build fails.

<vagrantc>dongcarl: looks like recent versions of guix require even more guile-* dependencies

<rekado>reepca: we have a gtksourceview-3 package.

<reepca>rekado: yup, just confirmed that it builds successfully with that as input

<vagrantc>dongcarl: guile-gcrypt, guile-sqlite3, guile-ssh, and maybe updated guile-json packages for guile 2.2

<vagrantc>dongcarl: according to https://www.gnu.org/software/guix/manual/en/html_node/Requirements.html ... i don't see corresponding debian packages for those..

<rekado>nckx: I think I’ve asked this before but I don’t remember the answer: are the Overdrive boxen you have ready to be used as build nodes for Berlin?

*dongcarl wishes debian had importers

<abbiya>does guix cache packages ? it seems to download each time

*dongcarl is curious about what rekado and nckx is up to

<vagrantc>dongcarl: there are importer-like things for specific languages in debian

<vagrantc>don't know if any exist for guile

<dongcarl>vagrantc: I'll check it out. So if I'm understanding correctly, the steps to completion are: 1. Package Guix dependencies in debian 2. Package Guix in debian, correct?

<vagrantc>dongcarl: from a birds-eye summary, sure :)

<amz3>ah! I got my impossible project going: packaging snowball stemmer, the true, the unique, the only.

<amz3> https://git.sr.ht/~amz3/guix-amz3-channel/tree/484725b904339843c0d889b7208c2e7a433d8763/amz3/language.scm#L71

<amz3>upstream doesn't have .pc, configure or shared lib steps every distro has to re-invent the wheel

<amz3>s/steps/target/

<amz3>the rest of the story is that it was forked in xapian search engine.

<cyris212>Does someone have a working packer template for GuixSD 1.0 yet?

<yrk>is the awesome wm on guix?

<yrk>that is, guix sd?

<yrk>ah, https://www.gnu.org/software/guix/packages/A/page/2/... sorry. should have searched first.

<yrk>apoligies for the noise

<cbaines>cyris212, have you seen https://github.com/ofosos/guix-packer ?

<cbaines>It's a little out of date, but I've been hacking around with it with some success.

<cbaines>I did try updating it for 1.0 today, but for some reason, packer kept getting stuck before completing.

<g_bor[m]>Hello guix!

<g_bor[m]>Still trying to find out this openssh not starting on boot issue.

<g_bor[m]>Can I get some more logging from shepherd?

<davexunit>has packer been packaged for guix?

<g_bor[m]>I see nothing except the service could not be started.

<davexunit>I wanted it a couple years ago but we didn't have the Go support we have one.

<cyris212>cbaines: Thanks, I will let you know once I get it to work with 1.0.0

<cbaines>davexunit, I threw together a package definition that works https://git.cbaines.net/guix/commit/?h=packer&id=217e48e9edb7a08c2d3c03fc9b273ef16348714f

<davexunit>cbaines: ah but it's not upstream yet/

<davexunit>I use packer all the time at work for building AMIs

<g_bor[m]>I added debug loglevel to sshd,and when I start manually, i have debug output in /var/log/debug, but it seems that on the failed start attempt sshd does not get to the point to log to syslog.

<cbaines>davexunit, yep, including the source of all the dependencies makes it easy to build a initial package defintion, but it's a bit of work to build a proper one

<davexunit>cbaines: ah, got it. needs unbundling.

<cbaines>indeed

<davexunit>ah, good ol' Go.

<davexunit>new and ancient at the same time.

<nckx>yrk: Glad you found it by yourself, but don't be *too* afraid to cause a little noise here. It beats not asking at all.

<cbaines>cyris212, great :)

<nckx>dongcarl: Re: the Overdrives: I'm still fighting them, I'm afraid. Despite 8 GiB of RAM, running ‘guix pull’ or ‘guix install’ causes it [sic] to be OOM-killed (if I'm lucky) or freezes the box (if I'm less so). I'm away from home for a short while, so I can't press the power button :-/

<nckx>I don't understand why this only affects me; hope to find out soon.

<rekado>nckx: very strange :(

<rekado>nckx: are you running Guix on top of whatever system they came with? Or have you installed the Guix System on it?

<nckx>rekado: This is on Guix System.

<rekado>hmm

<nckx>Borg'ing openSuse went fine.

<rekado>g_bor[m]: Please send your findings to https://issues.guix.info/issue/33299

<rekado>nckx: you’ve got two of them, right?

<rekado>does it happen on both of them?

<nckx>Yup, & they're both locked up at the moment (my fault for keeping them in sync a bit too much, should have kept one as a spare).

<nckx>I was a bit too eager when installing Guix System ‘worked’.

<nckx>(No, they don't respond on ttyACM either.)

<rekado>there’s no rush, but I’d love to figure out how Guix can eat all the memory.

<rekado>if you could post a summary to guix-sysadmin some day I hope we can investigate this together

<nckx>I fully intend to when I can give you more info than ‘it broke and now I can't ping it’, rest assured ☺

<nckx>All I have now is half an OOM backtrace with all the good stuff scrolled away. 🤷

*nckx → AFK.

<PotentialUser-85>hi

***janneke_ is now known as janneke`

<nckx>PotentialUser-85: Welcome ☺

<reepca>anyone familiar with the emacs packaging scene feel like packaging libgit (elisp bindings to libgit2)? Apparently current magit checkouts need it, but the current magit in guix is broken due to an openssh upgrade (changed password prompt isn't recognized by magit). I'm really lost on how to package emacs-libgit.

<reepca>It's got a git submodule it uses and it seems like none of gnu-build-system, cmake-build-system, or emacs-build-system work by themselves.

<rekado>reepca: git submodules can be added as native inputs

<rekado>reepca: or maybe you can do a recursive git-fetch

<dongcarl>nckx: What are overdrives? I feel like I'm missing context

***nand1_ is now known as nand1

<rekado>“Overdrive 1000” (would be even better if they were named “Overdrive 2000”) is an aarch64 development box.

<vagrantc>dongcarl: softiron overdrive is an aarch64 (64-bit arm)

<nckx>dongcarl: Oh, sorry, i mispinged.

***dddddd_ is now known as dddddd

<nckx>There's an Overdrive 3000 so I guess 2000 is a reserved number.

*rekado remembers that “2000” naming craze in the 90s

<nckx>I'm using the overdrive.scm from the maintenance repo by the way.

*nckx does too, but maybe marketing droids don't share our sense of humour.

<nckx>Apart from guix crashing, they're ready to use!

<reepca>rekado: actually it looks like the initial definition generated by the importer downloads a release that includes the submodule already, I'm just lost as to what sort of build system it's supposed to have. When I make it cmake-build-system, it succeeds but doesn't install the elisp parts, and when I make it emacs-build-system, it succeeds but doesn't install the actual C bindings.

<cyris212>Is there some kind of http client shipped with the GuixSD installer?

<reepca>cyris212: 'guix download' should work for fetching stuff

<cyris212>I need to fetch the config.scm from a webserver...

<civodul>i think there's also wget, and if not, you can run "guix install wget"

<cyris212>civodul: Good point, I will try this. Thank you.

<vagrantc>i've started sometimes using guix download to download things i that i probably don't want indefinitely, but might want to persist across reboots or something ... and then they'll eventually get garbage-collected :)

<cyris212>vagrantc: that is actually an interesting approach :-)

*vagrantc wonders if guix download --root= works

<dongcarl>I'm wondering what the policy is for bumping the default gcc (say to 8 or 9) to support additional architectures?

<jayspeer>hello

<rekado>dongcarl: we do this on core-updates and then see how many packages fail to build.

<jayspeer>assuming there are poeple™ here that use gnu shepherd, can someone™™ point me to some resources how to define new service? I'm trying to have mpd started by my users shepherd

<rekado>jayspeer: have you looked at the shepherd manual?

<jayspeer>rekado: yes, I'm havind trouble with "#:start"

<jayspeer>I'm not really sure what's supposed to be there

<rekado>ah.

<rekado>you need a service constructor there.

<jayspeer>I don't really get them tbh :/

<jayspeer>Is it just wrapper around string?

<rekado>if you have the guix sources take a look at gnu/services/cuirass.scm, for example

<rekado>the definition of cuirass-shepherd-service returns a list of one shepherd service.

<vagrantc>is it plausible to have architecture-specific "default gcc" ?

<jayspeer>rekado: thank you

<rekado>the start field uses make-forkexec-constructor, where the first argument is a list consisting of the command followed by arguments

<vagrantc>risc-v for example, would require at least gcc 7, if i'm remembering correctly

<rekado>jayspeer: this may be too much for your service, but you can find other examples in gnu/services/

<vagrantc>or rather risc-v 64-bit (a.k.a. riscv64)

<dongcarl>vagrantc: Right

<dongcarl>That's what I'm trying to support

<dongcarl>riscv64

<dongcarl>I wish there were some way to specify the toolchain configuration for gnu-build's in Guix

<dongcarl>Like: I want gcc 8 with glibc 2.27 and linux-libre-headers 2.19

<rekado>dongcarl: you can add these things to your package and Guix will use them (gcc at least)

***paroneayea is now known as dustyweb

<civodul>you can also set #:implicitl-inputs? #f and specify everything

<civodul>err, #:implicit-inputs?

<rvgn>Hello Guix!

<civodul>hi!

<kabo>civodul: the fix at https://www.gnu.org/software/guix/manual/en/html_node/Guided-Graphical-Installation.html#Guided-Graphical-Installation doesn't work

<kabo>because of https://lists.gnu.org/archive/html/bug-guix/2019-05/msg00102.html

<dongcarl>rekado: civodul: Right, that's what I've been doing. Might contribute some helper functions for others who want to attempt things like this

<rekado>kabo: what happens if you also fetch letsencryptauthorityx4.pem with guix download?

<kabo>I dunno

<kabo>nckx helped me getting x3.pem

<kabo>then went to bed

<kabo>this must be affecting other users as well?

<rekado>civodul actually worked around this by adding the former x3.pem files to the cache.

<rekado>I’m surprised to see that this isn’t helping.

<rekado>(did the LetsEncrypt people really just change these files in place?)

<kabo>is there a local cache on my laptop I need to clear or something?

<kabo>yeah, that's what nckx said

<kabo>the change was line breaks

<kabo>someone opened the file on a windows machine it seems

<nckx>o/

<dongcarl>nckx: what does that mean?

<nckx>kabo: Are you not able to download these files another way? With curl or wget and then using ‘guix downlad file://…’, for example.

<nckx>dongcarl: What?

<kabo>that seems like it would still result in a hash missmatch, would it not?

<dongcarl>"o/"

<kabo>I think it's a man waving

<rekado>o/\o

<dongcarl>Ah...

*dongcarl is out of the loop

*rekado –> zzzZ

<nckx>dongcarl: And I thought I was bein' old-school by not using unicode for that.

<donofrio>does guix contain it's own kernel? (not the standalone version I mean) also does this have libraries for powerpc compiling?

<nckx>kabo: OK, I remember your problem now.

<kabo>yeah, tested it now, still get hash mismatch

<kabo>am I really the only one with this issue?

<nckx>kabo: Apparently so.

<kabo>if a file got changed in place wouldn't that affect everyone?

<kabo>either the file did get changed, and everyone should experience this issue, or I'm somehow not receiving the right hash

<nckx>kabo: It would. So either your pull{ing,ed} guix is asking for something odd/outdated, or everyone else is using binary substitutes and you're not.

<kabo>or everyone else is not doing any hash validation

<nckx>kabo: Validation isn't optional, so that's not it.

<kabo>ok

<kabo>ok, I'm gonna do a clean install for the umpteenth time

<nckx>kabo: I'm uploading the files to my site, if you want to try that. Should be only 2 more.

<nckx>No, it's not a solution and it doesn't scale, but 🤷

<kabo>doing a clean install, with gnome, and not selecting nss-certs

<nckx>OK.

<kabo>will attempt the proposed fix the first thing I do to get the nss-certs in there

IRC channel logs

2019-05-06.log