IRC channel logs

<g_bor>hello guix!

<g_bor_>I got a file in my git repository named gnu/services/cups.go.ooVhtj

<g_bor_>anyone knows what is that?

<g_bor_>I guess it is smoe lock, or similar.

<g_bor_>it is empty.

<janneke>g_bor_: it's a temporary guile compile'd .go

<janneke>possibly a failed or interrupted build or something

<ngz>Hello. How can I force re-building a package already in store? I tried guix build --check package, but it returns the store object.

<janneke>ngz: remove it from the store, e.g.: gc -d /gnu/store/cabba9e-foo-0.1

<ngz>So, I need to remove it from my profile, then remove it from the store, then build it again?

<ngz>This ought to be simpler.

<janneke>ngz: what's your use case?

<janneke>maybe you want `guix challenge?'

<janneke>ngz: the idea is that each build deliveres a bit-for-bit identical result

<efraim>ngz: because of grafts you'll probably want 'guix build foo --no-grafts --check'

<ngz>I suspect upstream changed their release tarball without updating their version. I would like to check if it still builds.

<ngz>And, if it builds, test the changes.

<ngz>That's my use-case.

<janneke>ngz: what you could do is add something to the version ("-1") or so, build and test and diff that?

<ngz>OK, I'm going to try this.

<ngz>I hoped I would not have to tweak the package definition.

<efraim>you can also check the upstream tarball with 'guix build foo -S --no-substitutes [--check]'

<ngz>-S get me the source, but doesn't try to actually build it, does it?

<efraim>no, but it can check if the source has changed

<ngz>OK

<ngz>It seems to re-use the stored zip and doesn't download it again.

<ngz>Same with the new package definition.

<efraim>what about with --check? that should force it to redownload

<ngz>I tried with --check

<ngz>It doesn't change anything.

<rekado>the package definition asks for a source with a particular hash. Have you checked the hash of the new tarball?

<rekado>you can also build a package with a different source tarball using “guix build --with-source=the-tarball”

<ngz>rekado: I tried --with-source, but I got "guix build: warning: transformation 'with-source' had no effect on grammalecte@0.6.5"

<rekado>make sure the tarball is named the same as the package and follows the conventions for version strings..

<rekado>(the “with-source” transformation is a bit too picky for my taste)

<brendyn>ngz: as rekado said, you'll need to name it something like grammalecte-0.6.5.tar.gz

<ngz>I don't choose how it is named

<ngz>Or do you mean I have to download it first, then rename it, then use that?

<brendyn>yes^

<ngz>Ewwww

<ngz>OK.

<brendyn>It's a bit weird i guess

<snape`>ngz: if you change the sha256sum to a fake one, it should re-download the source

<ngz>--with-source raises an error during the unpack phase, which seems unrelated to the hash

<ngz>snape: Indeed. It downloaded it again. So upstream modified the tarball in-place :(

<snape>ngz: it will download it even if it hasn't been modified though

<snape>you know it has been modified when the new hash is different

<ngz>I mean: I checked that the hash had changed

<snape>yeah ok :)

<ngz>Now, I have to tell upstream politely that they should not do that ever again...

<jlicht>g_bor[m]: I think a33652ee336ae9a5d2ab5fd54bf2397caec42a0e introduced a typo in guix.texi; defvr instead of defvar

<jlicht>not on my pc rn though, so can't be sure

<snape>jlicht: defvr is valid texinfo syntax :-)

<snape>but well it should end with a @end defvr I guess :/

<snape>so that's a mistake indeed

<jlicht>snape: yeah, I messed that up: I meant to say defvar instead of defvr

<civodul>Hello Guix!

<snape>civodul: o/

<rekado>Hi Guix!

<efraim>hi!

<rekado>I’d like to move the /gnu/store directory on berlin.guixsd.org to NFS. I’m a bit concerned about booting, though.

<rekado>Would I need to ensure that the NFS share is mounted by the initrd?

<efraim>i assume it'd have to be mounted before the hand-off to the kernel

<rekado>do you know how that would work?

<rekado>I could also just keep the system on the local disk and then bind mount the NFS thing onto the local mount point later.

<rekado>it’s just ugly, because it would not be clear exactly what software is used at runtime.

<efraim>i've never done anything like that before, but I think it would be easier(?) to set up tftp server and just netboot the whole server

<civodul>rekado: oh, i'm not sure whether/how we can make it work

<civodul>also NFS is slow, so it's probably a bad idea, no?

<rekado>it’s local

<rekado>the server has a dedicated storage array

<civodul>ok

<rekado>performance is acceptable after quite a bit of tuning.

<civodul>"acceptable" doesn't sound very good :-)

<rekado>I’d say it’s good enough.

<civodul>ok, sounds better ;-)

<civodul>anyway, i don't think we can mount the root FS as NFS

<rekado>right

<civodul>we'd have to use the in-kernel NFS i suppose

<civodul>but that needs experimentation

<snape>what's the point of using NFS if the storage array is local?

<rekado>the setup looks like this: dumb storage array <--> dedicated head –(NFS)–> berlin

<rekado>the head runs RHEL7, because that’s what we get service for.

<rekado>by “local” I mean that the NFS connection only goes through the rack router.

<snape>understood

<snape>so the point is to get more storage?

<rekado>yes

<rekado>post RAID it’s about 37T

<snape>rekado: what would happen if there is a network issue, or if the RHEL7 machine is rebooted? Wouldn't that cause Cuirass IO to hang?

<rekado>it would.

<snape>(thus making it innaccessible)

<rekado>the machine should be serviced together with the berlin.guixsd.org head node.

<rekado>the storage extension (i.e. storage array + head server) is considered part of the berlin head node.

<rekado>if you have ideas to simplify this setup I’d be very happy to hear them.

<rekado>I’m not particularly happy with using NFS and all that.

<snape>rekado: what about plugging the dumb storage array to berlin, with a SATA interface?

<rekado>IIRC the storage array is connected to the storage head redundantly via two 12GB SAS HBAs.

<rekado>we don’t have those adapters in the berlin server itself.

<rekado>(but I have to be honest here and say that I’m not the hardware professional here; I left the details to my colleague.)

<rekado>another minor obstacle was that GuixSD network configuration is a little limited at the moment.

<rekado>setting up things like redundant bond interfaces is not covered by the configuration syntax.

<rekado>I’ll ask if we could move the HBAs to berlin and connect the array directly.

<snape>if they are redundant, you probably need only one of them

<snape>and it'll be local, so GuixSD network limitations won't be an issue

<rekado>they have to be configured to be redundant.

<rekado>but yeah, networking would not matter when it’s directly attached.

<snape>to me it would be a better solution, because it would avoid depending on RHEL7 and on networking

<rekado>yeah

<rekado>it’s embarassing how much I’ve forgotten about this setup… It’s been unused for much too long, waiting for me to find time to test it.

<mbakke>Mmmm.. HBAs... Storage arrays.. Smells like BeeGFS.

<mbakke>I suppose NFS can work, if the kernels are copied to /boot.

<rekado>we’d need to check if the HBA drivers are part of linux-libre.

<rekado>colleague says we need multipathd support in GuixSD to configure multipath access to the disks.

<mbakke>multipath is present, but no service atm.

<rekado>okay

<mbakke>I doubt any HBA adapters require firmware to run. All drivers in the kernel are free.

<rekado>good good!

<rekado>guess I’ll install GuixSD on the storage head next to see if it all works.

<rekado>if it does we can just move the HBA cards to berlin

<mbakke>Ooh, exciting :)

<rekado>and then use the former storage head as yet another build node.

<rk4>what happens in a world where you don't have a multipathd and just use dmsetup directly to setup the multipath targets?

<rekado>I guess that depends on the interpretation of the word “just” ;)

<rekado>jlicht: have you pushed a fix for the syntax error in a33652ee336ae9a5d2ab5fd54bf2397caec42a0e?

<rekado>it breaks “guix pull” because people can’t build the manual

<rekado>oh, I meant g_bor.

<jlicht>rekado: No I did not. I could, though, in ~3 hours time ;)

<rekado>I’ll do it.

<jlicht>nice

<rekado>done

<thomassgn>Hey! reading up on mcron syntax and I'm wondering about the timing/first argument to the job command: How do I make something run every 5 mins?

<thomassgn>I mean there's '(next-minute-from)' which will give me an execution I guess in 60 secs. But how do I make it reocur? Or would it reocur every minute, or every day at that minute? Seeing as it translates into unix time the last seems unlikely...

<thomassgn>derp, next pages has my questions as headings... :)

<g_bor>hello guix

<rekado>the HBAs seem to work just fine with linux-libre.

<rekado>I can see the storage array as /dev/sdb and /dev/sdc

<rekado>haven’t tried multipath, but this seems okay.

<rekado>I’ll move the cards to berlin.guixsd.org after my vacation.

<rekado>I like how things just work with linux-libre.

<g_bor>rekado, civodul: Can we discuss the second GSoC evaluation?

<civodul>g_bor: yup, let's do as usual :-)

<janneke>i have a package that adds a modified m4 to its propagated-inputs

<janneke>(m4 configured using the "experimental" --with-changeword feature from 1995)

<janneke>now, "sometimes" my environment works, but sometimes another package seems to pull in the plain m4 and that one wins

<janneke>advice?

<janneke>i used to ignore this problem, as the m4-changeword package alsways came later and seemed to "win"

<snape>janneke: you can use 'guix environment' to force the environment to be correct :-)

<civodul>janneke: we'd need to see the package definition, but there's an m4 as an implicit input

<civodul>so it could be the root of the issue

<rekado>snape: I think this is for a package definition.

<janneke>civodul: yes, i'm afraid the implicit input is problematic -- how could i replace that?

<rekado>janneke: this is the gnu-build-system, right?

<civodul>janneke: see package-with-explicit-inputs

<snape>oh ok

<janneke>rekado: yes

<janneke>civodul: thanks!

<janneke>oh, that may be handy for bootstrapping too!

<civodul>prolly :-)

<janneke>i've been working mainly with vagrant to get mes packaged for Debian testing, also because i'm a bit stuck with the mes bootstrap

<janneke>so, i have glibc-2.3.6 and gcc-4.1.1; but i cannot seem to get gcc-4.7.4 built

<janneke>ACTION tried many, many things

<civodul>hmm

<janneke>now that 0.15 is released, i'm wondering how to get this going, how to best get "help"

<civodul>yup!

<civodul>janneke: what kind of build error do you get?

<civodul>on gcc

<janneke>civodul: the most common is: ../.././libgcc/libgcc2.h:157: error: unable to emulate 'TF'

<civodul>oh right, no idea what this can possibly mean

<civodul>did you try asking on the gcc/binutils mailing lists?

<janneke>neither does google, so i tried upgrading glibc, binutils, whatnot

<janneke>no, not yet

<janneke>i just setup an i686 guix VM in the hope it would be a cross-build thing, but i get the same error

<janneke>however, i'm not sure if/how we can integrate this bootstrap into Guix

<civodul>were they released at around the same time?

<civodul>re integration in Guix, i'd really like to avoid having separate dependency graphs from ARM vs. Intel

<janneke>civodul: no, gcc-4.7.4 is much later

<civodul>but it sounds like it's too ambitious

<janneke>civodul: yes, i was thinking that too

<civodul>janneke: oh right, ofc

<civodul>maybe try adding gcc 4.3 in the middle?

<civodul>janneke: so we need to discuss on the list integration strategies, i think

<janneke>having a "full source" (or as i start to call it: "reduced binary seed" bootstrap) seems nice in a way, i don't want to create+maintain a parallel bootstrap path for x86...

<janneke>civodul: yes, that could work...i tried upgrading glibc but got stuck on 2.3.6 (2.4 won't build)

<janneke>i haven't tried upgrading gcc past 4.1.0 -- (gcc-4.7.4 advertises that it can be built with gcc-2.95)

<civodul>ok

<thomassgn>I'm trying to get some text from upower to make decisions in a cronjob, but I keep getting an error on 'ungexp' being an unbound variable. But Idk what ungexp is, it is unused in my code and I can't find it's definition in guix sources... Here is the code: https://paste.pound-python.org/show/7YWKxgJKc3gAQOPN3SQd/

<jlicht>thomassgn: `ungexp' is #$ in your code, probably

<jlicht>See https://www.gnu.org/software/guix/manual/en/html_node/G_002dExpressions.html for some more details regarding the use of G-expressions (which is what some of the mcron examples use)

<jlicht>the (simplified) version is that anything that uses ungexp is meant to be written to a file

<thomassgn>jlicht: ah, ok. I so I trimmed it down to just run the (execl... expression, still have that error, but do I understand correctly that I should redirect the output to a port? e.g. stdin or a different file?

<thomassgn>I should try to read the gexps again, they are just so hard to understand.

<g_bor>janneke: Have a look at this: https://mirrors.edge.kernel.org/pub/linux/devel/gcc/float128/libc-float128-14.patch

<jlicht>thomassgn: I found it 'easiest' to pass my gexps to to `gexp->script' to get a handle on it. See the example under `gexp->script' for something you should be able to play around with

<janneke>g_bor: thanks for helping...what should i see?

<g_bor[m]>It seem that in glibc floating point emulation was removed at some point. Most probably your unable to emulate TF comes from there.

<janneke>finally got subscribed to gcc-help -- not GNU infrastructure, not mailman but something else

<g_bor[m]>I could not find yet where this happened exactly, but this patch seems to add floating point emulation support.

<janneke>g_bor[m]: that seems probable

<janneke>ah!

<janneke>so, having a glibc > 2004-05-13 could help

<janneke>i have glibc-2.3.6 but failed to compile anything newer -- i tried 2.4, 2.5, 2.6, 2.12 whatnot

<janneke>i'm getting lost in "linuxthreads" or pthreads :-/

<g_bor[m]>I will have a look at commit logs when support was removed.

<janneke>hmm, i have glibc-2.3.6 which is from 2005-11-03

<janneke>anyway, your help is *much* appreciated, this seems way over my head -- all the possibilities

<thomassgn>jlicht: Thanks for the pointers.

<thomassgn>those pages are difficult, I fine with not getting an answer: why does '(execl #~(string-append #$upower "/bin") "upower" "-e")' complain about ungexp while: '(shell #~(string-append #$bash "/bin/bash"))' for my user in my guixsd config work? I don't get the difference (which is fine, I'll rub my head some more on the gexps).

<brendyn>Does anyone know of any tutorials for setting up emacs for email and synching mailing list archives somehow?

<snape>thomassgn: because your user config contains (guix gexp) maybe?

<snape>brendyn: it depends on your mail client

<brendyn>well i use thunderbird at the moment

<snape>I meant your Emacs mail client

<brendyn>I just want to use something that doesn't make me want to hang myself

<brendyn>Last a tried was gnus

<snape>I use mu4e

<snape>those are the two main clients

<snape>thomassgn: you shouldn't use gexps in your mcron job anyway, unless it's already within your Guix config

<brendyn>do you subscribe to the mailing lists and have thousands of emails coming through your inbox?

<brendyn>i unsubscribed because it was too much to handle, but now i cant reply to messages on the list since they are not in my inbox

<brendyn>it'd be nice if i synch them directly from the list instead of flooding my email

<snape>I use a free provider to collect the mailing list emails

<snape>and my mail server to send them

<snape>thomassgn: if you want to understand mcron, you should try to get something that works without gexps first :-)

<brendyn>sounds like a lot of trouble

<snape>brendyn: you can download the archives

<snape>and then import them into your mail client

<snape>the problem is that sometimes the format needs to be converted

<snape>(depending on your mail client)

<brendyn>i guess ill just subscribe to all the mailing lists again

<thomassgn>snape: :-) yes. But how'd I get a hold of upower's path then? I guess I could hardcode /run/current-system... or use execlp or something. But idk. isn't this what the gexps are for?

<snape>thomassgn: it's a workaround, the best way is to use gexps of course

<snape>instead you can install upower

<snape>and get it from its location (/run/current-system, or ~/.guix-profile/bin...)

<thomassgn>mm, allright, until I grok gexps then... :-)

<thomassgn>thanks

<snape>yw

<jackhill>what's the recommended way to clean up old links in .config/guix ?

<gnoom>Hello, my 'guix pull' segfaults on my raspberry pi 3B+ with 1GB RAM. On the first run in complained a lot about heap allocations failing, and now it segfaults every time, probably when memory is full again. Is there a way to make 'guix pull' use less memory, or something else I can try?

<brendyn>gnoom: It's a known problem at least. I would have thought it would work within 1GiB though.

<brendyn>I suppose you could add swap?

<gnoom>I've tried that up to 8GB

<gnoom>Only took longer to crash

<brendyn>then i don't know

<snape>gnoom: what version of Guix is it?

<brendyn>its known that guix pull takes a lot of ram. not sure about heap allocation failure in paticular though

<gnoom>it's 0.15.0

<gnoom>Allright, thanks. Does it make sense to use guix without being able to pull? I'm just trying it out.

<rekado>it should not take more than 1GB.

<rekado>you might have more luck pulling a slightly older version for which substitutes are available.

<rekado>the latest versions of Guile use more RAM than we would like.

<rekado>there’s no way to control memory usage of Guix, because that’s up to Guile.

<rekado>we hope that this will be dialed back down in future releases of Guile.

<gnoom>I'll see if I can make 0.14 work then. Thanks!

<rekado>0.14 also uses Guile 2.2.

<rekado>by “slightly older version” I meant “not the latest version on the master branch”.

<rekado>“guix pull” defaults to downloading and compiling the latest version that is available on the master branch.

<rekado>we automatically build binary substitutes for many parts of the “guix pull” procedure, but they may not be available for the latest version.

<rekado>you can use “--commit=abc…” to specify an older commit.

<cehteh>.o(would be nice to have a --tag=... and then the build farm tag (and pin) things which are fully available, also tag releases)

<gnoom>Aaaah, ok, that makes sense, I'm tring an older commit now.

<rekado>cehteh: AFAIK “--commit” also accepts tags. But we only tag commits manually (usually for releases).

<rekado>cehteh: I think git tags are the wrong tool for this feature, but a feature like this would be useful.

<jonsger>ACTION wonders a little how to package "guix offload" correctly...

<kkebreau>I've been sitting on some chemistry packages I worked on for use during my internship...

<kkebreau>A little polishing and it could be ready for Guix master.

<kkebreau>s/it could/they could/

<cehteh>rekado: tags for releases are fine, but branches/staged buils for ongoing things would be nice

<cehteh>proprosed->latest->available->stable->stale :) the names are arguable

<cehteh>some voting system for packages would be nice too, sometimes builds and passing tests is not enough for a useable/working package

IRC channel logs

2018-07-09.log