IRC channel logs


back to list of logs

<g_bor>hello guix!
<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>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>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!
<rekado>I’d like to move the /gnu/store directory on 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
<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
<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>so the point is to get more storage?
<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 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>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.
<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.
<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 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>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
<janneke>now that 0.15 is released, i'm wondering how to get this going, how to best get "help"
<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)
<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:
<jlicht>thomassgn: `ungexp' is #$ in your code, probably
<jlicht>See 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:
<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>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... :-)
<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