IRC channel logs


back to list of logs

<ng0>the definition of 'maintainer' is so blury sometimes.. I could add myself to AUTHORS for gnunet as maintainer for both Guix and Gentoo, but in both cases the work is done collectively, it just happens that I pay attention to the packages and care for them.
<bavier>maintainership is certainly a spectrum
<ng0>I invested more than a year in the work on gentoo, so I could claim maintainership for that at least.
<ng0>so my example is wrong.. how do I add to the GUILE_LOAD_PATH guix constructs? : and :+: wasn't working.. this is what I have
<ng0>what I don't understand is why the GUILE_LOAD_PATH is added twice in itself.
<ng0>some commit added this, but why?
<ng0>and am I supposed to add my extension before those 2 repetitions or afterwards?
<ng0>haha used the wrong variable.. ouch
<ng0>can't figure out why it's still failing.. I've sent my latest changes to svn. If someone wants to build gnunet from svn, I'd appreciate some input why the expression fails to evaluate. I'll read the backlog, will go to bed soon
<lfam>Wow, the NSS test suite is a long one :)
***atw` is now known as atw
<ZombieChicken>GuixSD uses Grub2 by default, correct?
<rekado>ng0: I don’t understand. Where is the GUILE_LOAD_PATH added twice? What commit added this?
<rekado>what expression fails to evaluate?
<ng0>rekado: the instructions I wrote there use the variable of GUILE_LOAD_PATH Guix normally throws at you, with the change of added $GNUNET_SVN_PATH
<ng0>adding it at the start of it didn't change that the expression fails somehow.
<ng0>I fail to see why
<rekado>I’ve read this but I don’t see GUILE_LOAD_PATH being set twice
<rekado>and what does “the expression fails somehow” mean?
<rekado>how does it fail?
<civodul>Hello Guix! :-)
<ng0>what does the piece at the end of the real paths do then?
<rekado>ng0: what piece?
<ng0>you set some paths.. then you add ${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH .. I get the last one, but when I echo my $GUILE_LOAD_PATH, I get what I describe as 2 times the same value.
<janneke>Hi civodul!
<rekado>ng0: this is a Bash feature. See “Shell Parameter Expansion” in the bash manual.
<rekado> If PARAMETER is null or unset, nothing is substituted, otherwise
<rekado> the expansion of WORD is substituted.
<rekado>this means: if GUILE_LOAD_PATH is unset: do nothing.
<rekado>if GUILE_LOAD_PATH is set, add a colon, then add the value of GUILE_LOAD_PATH
<rekado>GUILE_LOAD_PATH is only appended once.
<ng0>ah, thanks
<ng0>i knew it is bash, i had no idea where to searhc
<rekado>I found the section on parameter expansion very useful. There are lots of interesting expansions that one can use in scripts.
<ng0>the only time I really use bash is in the subset of bash which is ebuild and eclasses.
<ng0>but maybe i should read this
<ng0>maybe what I had before didn't translate well into the module kind, so I need to remove some modules..
<ng0>I don't see why it would fail
<ng0>or maybe this is the wrong approach and I need to add this to $GUIX_PACKAGE_PATH .. i just though guix build --expression would work just like that
<civodul>ng0: i haven't really followed, but make sure to read and in particular footnote 23
<civodul>maybe it answers some of your questions
<efraim>civodul: is there a way to generate just tar for the bootstrap binaries or do I need to I need to make a whole new set of bootstrap-tarballs
<civodul>efraim: "guix build static-binaries-tarball" produces the tarball that contains coreutils et al.
<ng0>civodul, it's about what I moved this file to
<civodul>is that what you want?
<civodul>ng0: right, so see the footnote 23 above, i'm guessing this will explain the problems you're experiencing
<efraim>yeah, I'll try that instead of 'guix build bootstrap-tarballs'
<ng0>but GNUNET_SVN_PATH is set to for example /home/alice/src/gnunet/svn/, and this is used for the GUILE_LOAD_PATH.. so gnunet is in svn/gnunet/ and the file to load is in that folder. you're telling me I got the root wrong? svn is the root, not gnunet? damn.
<ng0>so obvious
<efraim>tar-1.27 is supposed to be good?
<ng0>yet so obvious to get wrong
<ng0>no, still fails with svn/gnunet as the root for guile_load_path.
<ng0>oh.. okay I will read some more.
<efraim> looks like vc only supports x86 and x86_64
<efraim>sneek! come back!
<jmd>I just built a disk-image, but it doesn't seem to boot :(
<ng0>so I moved gnunet_svn_path which is part of guile_load_path up to the very directory of gnunet in svn, renamed module to gnunet-guix-env, yet it still does not load when I try to load guix build --expression="(@ (gnunet-guix-env) gnunet-svn)", get the same failure
<civodul>roelj: what happened to the --list-generations patch your submitted a while back? :-)
<ng0>I think I should revert to what I had before.. this is obviously not working.
<ng0>unless someone can spot an obvious error..
<ng0>read parts of the guile documentation, i don't see a mistake on my side.
<jmd>Trying to boot from the usb installer, I get the error message: error: no such device: gnu-disk-image
<jmd>error: file `/gnu/store/....linux-libre-4.8/bzImage' not found.
<rekado>I tried cross-compiling for armhf on x86_64 but sadly it doesn’t even get past building the bootstrap “make”. I thought cross-compiling for armhf should work fine.
<civodul>jmd: the error message comes from what?
<civodul>GRUB? kernel? initrd?
<efraim>rekado: did you try --system or --target? iirc for --system you have to be able to build it natively
<rekado>I tried --target
<rekado>one problem is that hydra no longer has substitutes for the cross base packages
<ng0>libxt seems to be impossible to update..
<ng0>--fallback doesn't work
<efraim>hmm, I thought it should just work
<ng0>with --fallback I get 410 gone
<ng0>guix substitute: error: download from '' failed: 410, "Gone"
<civodul>ng0: if you pass --fallback, it will fall back to building from source
<civodul>it's annoying that many things are gone, though
<ng0>i passed fallback
<jmd>civodul: Do we know why that happens?
<civodul>jmd: could you answer my question first? :-)
<civodul>jmd: also, are you building an image of gnu/system/install.scm? unmodified?
<jmd>civodul: I think it's comming from grub.
<efraim>ng0: to check, i normally call it 'guix build --fallback foo'
<jmd>But I'm suspecting now that the medium on which I have it is dodgy. Trying another one.
<ng0>as I said, I passed fallback. libxt can't be build.
<ng0>I shouldn't need to update the buildserver to make it succeed in building what client passes it, but recently I experienced builds where I doubt that independency..
<rekado>ng0: “can’t be build” as in “the build fails” or “due to some other error”?
<ng0>410 gone.
<rekado>you’re using offloading, right?
<civodul>ng0: normally "guix build libxt --fallback" works; it definitely does here
<civodul>maybe --fallback isn't passed to the build machine though, when offload
<civodul>can you try "guix build libxt --fallback --no-build-hook"?
<ng0>that should be in one of the offloading bugs i reported if it isn't passed.
<ng0>as i suspected this works
<ng0>so there's a chance i reported this before
<jmd>civodul: I was right. That USB stick must be faulty.
<ng0>Is cuiras usable for building branches / repositories of guix already? I think I'd like to run my local hydra substitute..
<ng0>would solve the offloading problems among other things.
<ng0>well "solve"
<civodul>i don't remember seeing a bug "--fallback is not honored when offloading is enabled"
<civodul>fixing this bug would be even better :-)
<ng0>they were not all bugs. some are just on th devel list
<ng0>i think i found it. i should split this bug.
<ng0>no. thiswas not reported. I will open a bug tonight
<ng0>there is thread:0000000000004370 August 24 [4/4] ng0, GNU bug Tracking System; bug#24168: Offloading builds does not honor --keep-failed (inbox replied unread)
<civodul>right, but --keep-failed is another story
<ng0>keep-failed and keep-going.
<ng0>that's why i should have separated the bug.
<ng0>if that's a feature of debbugs, someone should do it. I've seen merges, but not separations
<ng0>i think i'll report it now so i don't have to write it down to remind me of it.
<civodul>make it concise and to-the-point :-)
<ng0>I'll do it anyway, but: when I run my GuixSD from a git checkout and I checkout a branch where I apply patches which add a new service and this service is in testing stages but not so broken or untested that it blocks the boot process, I should be able to just deal with it and/or rollback, right?
<ng0>civodul: regarding debbugs package: I have no realistic way to test it. it succeeds, but there are no tests, it just succeeds so far. I wanted to leave it up to debbugs running sys admins to test this, that's I called it [PATCH][WIP]
<civodul>ng0: maybe there's a command you could try to run or something?
<civodul>as i wrote, if reviewers have choice between a WIP-labeled patch and another one, they'll always choose the non-WIP ;-)
<civodul>so we need to have some confidence that it's simply ok, not necessarily perfect
<ng0>no idea..
<ng0>and even if, it'll be a thing I'll do after the services
<ng0>so if someone wants to continue or check what I did there, I'll get back to it in maybe 4 weeks
<wingo>what's the solution to 410 GONE errors from the mirror?
<wingo>--fallback i guess
<civodul>i'm trying to see how we got there
<civodul>seems there's been too much GC recently...
<rekado>I thought this is related to errors in hydra’s filesystem which necessitated more GC
<ng0>I don't know when enough is enough... I recently collected ~60 GB garbage of 3 months. Is there a point where filesystem says "noooooo"? anyone ever reached that with guix?
<efraim>dave said that at 1.5TB he hit the inode limit in ext4
<cehteh>for guix you most likely want to create ext4 with some bonus inodes :)
<cehteh>lots of hardlinks in the store
<ng0>ext is the only supported format so far for SD right? I used xfs for a long time.
<ng0>i mean when you set up the system the lazy way.
<efraim>afaik ext4 is the only supported filesystem for the store
<ng0>why? does it need some API for filesystems for some element of store / core?
<efraim>people have run into issues with the store on btrfs, even without compression, and none of the others are tested
<ng0>okay, so hardcoded or can I go ahead and setup a system to try the other format(s) jus tfor fun?
<rekado>too many failures on hydra since the latest changes.
<ng0>I'll try to run my local cuiras / hydra replacement with xfs. I think I'll look into this in november.
<rekado>pulseaudio failed on mips.
<rekado>civodul: would you agree to increase the timeout for “guile-next”? It fails on armhf with a timeout during bootstrap.
<ng0>I hope the free parts of intel gpu drivers for linux still support 1997 produced on-board cards
***Digitteknohippie is now known as Digit
<civodul>rekado: i hereby agree!
<civodul>efraim: re ext4 in GuixSD, see
<civodul>the cost of having our own libblkid :-)
<wingo>had to patch the cups package. it rebuilds everything :P
<rekado>civodul: excellent! I’ll prepare a patch.
<rekado>I’ll push the patches to add ghc-pandoc-citeproc now. They are very simple and “guix lint” is okay with them.
<jmd>The guile which is in the disk-image ... is it a regular guile or is it a cut down version?
<fps>now that pastee is gone, what should be use?
<fps>anyways, i get an error during guix system reconfigure:
<snape> I think
<fps>possibly because my system is so old that init is still called herd :)
<fps>fps@cherry 03:24:31 ~ $ which herd
<davexunit>that's the new name
<davexunit>deco would be the old init client
<fps>oh hmm, ok
<fps>oh right..
<fps>making '/gnu/store/cj30zcz7zcr9mnvmjr9nczrl7973gwxg-system' the current system...
<fps>guix system: warning: while talking to shepherd: No such file or directory
<fps>hmm, rather nondescript error. is a socket not open? or a pipe?
<fps>seems to be a warning only anyways
<quigonjinn>fps: are you running it as root?
<fps>sudo guix system reconfigure /config.scm
<quigonjinn>fps: alright. because i had the same error in the past, trying to run sheshperd as a user
<fps>good to know
<fps>it seems though there's no shepherd running at all?
<fps>at least ps aux | grep shep tells me nothing
<fps>hmm, dmd seems to be pid 1
<fps>i wonder if the transaction to make the new generation the OS succeeded?
<fps>seems so..
<fps>fps@cherry 03:39:29 ~ $ ls /var/guix/profiles/system -l
<fps>lrwxrwxrwx 1 root root 33 Oct 6 15:30 /var/guix/profiles/system -> /var/guix/profiles/system-17-link
<fps>fps@cherry 03:39:31 ~ $ ls /var/guix/profiles/system-17-link -ld
<fps>lrwxrwxrwx 1 root root 50 Oct 6 15:30 /var/guix/profiles/system-17-link -> /gnu/store/cj30zcz7zcr9mnvmjr9nczrl7973gwxg-system
<fps>i guess it should be safe to reboot then
<fps>we'll seee
<fps>sudo reboot fails, too :)
<fps>ok, hard resetting the box..
<davexunit>an example of the mindset we need to work to change:
<davexunit>where reproducibility is deemed "not worth the effort"
<davexunit>or rather a "wasted effort"
<fps>davexunit: it's always a trade off. reproducibility has a cost associated with it. some people are not willing to pay it. they might possibly change their mind when informed about the benefits better, but some will not, as in their cost-analysis it still doesn't pay
<davexunit>those people are wrong :)
<fps>hah, no, they just don't assign the same value to different scenarios as you do :)
<davexunit>I think they are very misguided if they don't value this.
<fps>let's take a more extreme example: people using a completely non-free operating system like windows for the sole reason that a single non-free app doesn't exist on a free platform
<fps>in your value cosmos that's completely insane behaviour
<fps>in theirs it totally makes sense
<fps>and if you calculate the expected reward using the completely different value systems they might have done the right choice for them
<fps>there's no absolute right or wrong when it comes to free software, reproducibility, etc.. it all comes down to the individual
<fps>target people who care
<fps>not the ones that don't
<quigonjinn>fps: it's a pity, that many people in the free software movement, overlook the issue though
<fps>bootstrapping compilers?
<fps>isn't there maybe a workaround for this?
<fps>trace the development of ghc back in time. once there was a bootstrapped compiler
<davexunit>fps: that just gives you an extremely brittle tower of babel
<davexunit>guile does this right by bootstrapping with an interpreter written in C.
<davexunit>no long chain of bootstrapping from old versions that will probably break all the time
<fps>true, that makes it easier :)
<quigonjinn>and the actual problem, is that since people have not already taken the matter into consideration, it will be more difficult to take care of, in the future
<davexunit>yes, that is one of the big problems.
<fps>hmm, about the brittleness of the tower of bable
<fps>if every step is reproducible, there's no problem
<fps>it might just take a little longer to bootstrap
<davexunit>the problem is depending on old software that is no longer maintained
<davexunit>it will bit rot
<fps>it just needs to function in the old environment
<davexunit>as time moves on, compilers get upgraded, etc. problems *will* arise in old software
<davexunit>and the maintenance burden will just continue to grow
<fps>well, if you know how to assemble the first vm that builds the first ghc from archived old tarballs
<fps>and then go step by step, that will not suddenly break
<fps>that's why i said: if every step is reproducible
<fps>there will be no bit rot
<davexunit>yes, there will.
<fps>then the step is not reproducible
<davexunit>you misunderstand.
<bavier>fps: the oldest ghc "source" available does not build with any gcc's newer than, IIRC, 3.8
<davexunit>as guix moves on and updates packages, like the base compilers used to build everything, problems *will* arise in the old software.
<fps>bavier: so? make creating a system that has a 3.8 gcc in it part of the build
<fps>with virtualization and emulation we can make every step reproducible
<davexunit>that will work... for one version of guix.
<fps>you might have to freeze e.g. the used qemu versions, etc..
<davexunit>but when the core packages change or the build system scripts change there is potential for things to break.
<davexunit>yes, do you now see why this is untenable?
<rekado>fps: this is too brittle in the long run
<davexunit>the list of software that must be frozen grows and grows
<fps>no, it's just not easy to do with current guix
<davexunit>for each compiler
<rekado>you end up having to maintain too much software
<davexunit>it's not easy to do for anything.
<davexunit>this is a task that cannot be automated. you put great burden on the humans maintaining the package tree.
<rekado>it is really easier to implement separate bootstrap code
<bavier>you'd end up needing to create a backwards chain from the bootstrap binaries to the legacy-support packages so that you could even start slowly building up to the current
<fps>oh i see. well, true, it might be more work than fixing the compiler build
<fps>the advantage is you don't need to know much about the compiler to do this
<fps>for fixing the compiler you need to be a compiler nerd
<fps>*compiler build
<fps>so which one is easier depends on the skillset :)
<fps>ok, gotta go, hf :)
<wingo>fml it wants to rebuild libreoffice too
<civodul>wingo: --do-not-upgrade=libreoffice, or wait until binaries are available (pro tip! :-))
<bavier>I think wingo had locally patched the cups package
<civodul>rekado, bavier: speaking of which, i talked to a Debian + repro-build + GHC developer at ICFP, who didn't feel that GHC bootstrapping was much of a problem
<civodul>was kind of off-putting to me
<bavier>the first step is denial :)
<bavier>yeah, that's unfortunate
<rekado>civodul: what's the thinking there?
<civodul>they did understand the problem, obviously, but considered it wasn't really worth fixing
<rekado>you say "repro-build ... developer"
<civodul>essentially "resources" would be "better spent" on other parts of GHC
<civodul>nobody wants to pay for a 2nd compiler implementation, essentially (which i can understand, but...)
<civodul>and also, they were stating that Debian and Fedora have their own bootstrap paths started long ago
<davexunit>why does it work well for guile but not anyone else?
<bavier>I noticed this in the part of the debian-reproducible meeting I watched on Friday, that debian's idea of reproducibility does not preclude binaries
<civodul>and that it is "unlikely" that both Fedora and Debian binaries would be compromised at this point
<civodul>bavier: interesting
<davexunit>but there's more reasons to have reproducibility!
<civodul>binaries are 100% reproducible!
<bavier>I think their idea of reproducibility is more close to our "--rounds" builds
<civodul>well, bootstrapping is different from reproducibility, strictly speaking
<davexunit>so it seems we are on an island of our own, even within the reproducible builds world.
<civodul>more or less, not that much maybe
<civodul>we did talk about bootstrapping at the RB summit last year
<civodul>and some people were receptive
<bavier>we should get
<bavier>'s subtitle seems to suggest an interest in bootstrapping: "Provide a verifiable path from source code to binary."
<davexunit>"this particular path starts and ends with the binary"
<bavier>"we bootstrapped from source a long time ago, trust us!"
<rekado>I'd really like to see more languages implemented using Guile.
<rekado>it's okay to be slow
<drakonis>this is a question for the folks running spacemacs, has anyone actually made a guix layer for it?
<efraim>I checked the aria2 reproducible issue I found against Debian, they already have it marked reproducible and don't have a patch for the timestamp issue
<bavier>efraim: I think debian uses faketime in their builds to skirt around that particular issue
<efraim>Ah, that would make it not arise
<Phlogistique>maybe there should be some kind of hierarchy: some software is non-free, some is free but non-reproducible some is reproducible but not bootstrapable (i.e. from at least two different bootstrap paths), and only the software that is free, reproducible AND bootstrapable from at least two different bootsrap paths can be considered really free
<ng0>hrm.. that's a bad diversion in the efforts of reproducibility then, or is guix just working on another interpretation than debian and fedora?
<ng0>how do I just log out of gnome? I need to change back to awesome.
<ng0>is there some binary I can call directly?
<janneke>slim, X ?
<ng0>I am in gnome and I can't log out of it to come back to slim, to log back into awesome.
<ng0>gnome just provides reboot and power off so far..
<avoine>killall gnome-session?
<ng0>I think that would leave tohers running.. but I'll try
<htgoebel>ng0: Hi.
<avoine>it must be because policykit is not running
<ng0>but gnome-session / gnome-session-binary process does not exist
<ng0>so I'm trapped in a gnome.
<civodul>bavier: yeah for! ;-)
<htgoebel>ng0: Did you read my path for the manual reagrding inputs for Python packages?
<janneke>civodul: bavier: 404?
<ng0>no, i noticed the thread but can't follow it all. why
<efraim>Same 404
<ng0>I'm busy with other things and will catch up
<htgoebel>civodul, ng0: I have a knot in my head regarding where to but the inputs required for testing of Python modules …
<ng0>mostly fixing up the gnunet- and psyced-service
<janneke>ACTION kinda likes bootstrapx0rz
<htgoebel>… Python code is platform independent (except for extension modules) …
<paroneayea>texlive-texmf, you old nemesis
<civodul>janneke: that was just a suggestion
<htgoebel>… now the test-inputs could go into "inputs" instead if "native-inputs"? Would this be correct?…
<htgoebel>… and only for extension modules they would be "natiive-inputs", since one would need the native implementation for the test.
<htgoebel>… So we would distinguish by the type of python module
<htgoebel>… Same as for Java: most .jars are platform independent
<htgoebel>… I know, something is wrong in this thoughts, but what?
<ng0>I think we should point out in the manual the results of the thread from May which explains how to log out of gnome...
<ng0>oh, this is default? wow.
<ng0>what a terrible choice
<ng0> if only we could add extensions.
<janneke>civodul: ah!
<janneke>bavier: shameless bootstrapping plug:
<ng0>gsettings did it.. I think this should be added as an option to gnome-desktop-service ... show-logout? #t #f and then just execute gsettings line.
<janneke>wonder what you're aiming for wrt bootstapping
<civodul>janneke: this is awesome!
<civodul>i missed this report on Mes, this is impressive!
<civodul>the C compiler is the key part for me
<ng0>nice :)
<RichardPaulBck[m>Hello! Is it possible to create an guix package from an autotools project yet?
<paroneayea>is there a way to find out what's trying to upgrade texlive and stop it? ;)
<paroneayea>I know how to --do-not-upgrade
<paroneayea>but not how to find out "what in this --upgrade wants to do texlive"
<janneke>civodul: thank you
<janneke>civodul: i could do with some guidance, perspectives
<janneke>note that mes can currently only compile something like: 'int main () { puts ("hello world"); };
<civodul>that's a good start ;-)
<janneke>sure, thank you
<civodul>janneke: did you look at nyacc?
<janneke>possibly guile-user is not the best place to annouce this...
<janneke>civodul: first time i hear of it...
<civodul>nyacc was developed by another great Guile hacker
<civodul>it can parse all of C99 IIRC
<civodul>was announced on guile-user some time ago
<janneke>that could be helpfull, i'll have a look!
<janneke>although parsing is the least of our problems i suspect.
<paroneayea>whoa janneke
<janneke>paroneayea: :-)
<janneke>paroneayea: i could do with some help or support, can you get me some? ;-)
<paroneayea>janneke: unfortunately I'm in the same boat! though if interested potential help comes along I'll point them your way :)
<janneke>paroneayea: yes, that's kinda what i meant to ask for
<janneke>(and whoa also helps :-D)
<bavier>janneke: I appreciate your efforts on mes
<bavier>I've been toying with ideas myself
<janneke>bavier: nice! ideas like...?
<bavier>I've been trying to minimize the assembly/hex part, which of course adds another layer
<ng0>mes looks like a huge deal when this works out :)
<bavier>lately I've been studying the many "esoteric" languages, many of which focus on small implementations
<bavier>but my goal is the same, a c compiler that could bootstrap guile
<janneke> feeling exactly IF/WHEN it works out :-/
<janneke>bavier: great!
<janneke>bavier: my goal is also to have a minimalistic asm/hex part...
<bavier>janneke: I don't mind working on parallel with you; helps with thompson-attack avoidance
<janneke>but i really want to attempt to go via a minimal LISP/scheme
<ng0>I think that's everyone on every big project thoughts :) .. even if it doesn't work out, it will help in the big picture to work out
<ng0>the important thing is to keep going, with reflection :)
<janneke>bavier: sure thing
<janneke>parallel or together...both can be inspiring and helpful
<bavier>janneke: I'm currently working on a variation of the FALSE language that adds higher-order functions and lists
<bavier>a minimalist Joy language, basically
<bavier>if things work out the way I hope, the asm would be just a few hundred lines
<janneke>do you use a VM?
<bavier>it'd be an interpreter
<janneke>minimal VM + simple language -> Scheme -> C compiler would be great too
<janneke>going from hex straight into lisp is not a requirement, i just would very much like to find the shortest path into lisp/scheme
<bavier>and from there, write a C++ compiler in guile to bootstrap gcc ;)
<bavier>ACTION afk
<ng0>RichardPaulBck: I think automatic package creation is not possible (yet)..
<janneke>ng0: RichardPaulBck[m: i think it's possible allright, but i don't think someone coded it already
<ng0>I did not exclude that possibility :)
<janneke>what i did for Cuirass, was to modify a package description's source field to track a git branch
<janneke>you'd only need to add name, gnu-build-system, description, synopsis, and licence fields ... that should be trivial
<ng0>so building a complete branch hydra style already works? I'd like to let one computer in my network let build everything to detect packageswhich lead to errors / different results with the nth build. somethoing I'd like to do next month
<janneke>possibly...a complete branch of what? and what's `hydra style'?
<janneke>ACTION is showing their ignorance
<ng0>just building branch of guix git checkout.. as far as I followed it, this is what cuirass was out to replace, right?
<janneke>yes, Cuirass can do that
<janneke>i added tracking of a single package's git too
<janneke>what Mathieu did is really minimal, but amazingly functional for that
<ng0>I don't know who said it earlier, but I think to just reduce people who use systems like MS Windows to 'they don not care' is a very hard generalization and makes it too easy and too much differing from the situation out there. Sometimes job/university puts the pressure of using a system to run an application where there is no replacement on you. Or sometimes administration of cities are so much sleepy panda that they forget to support anything other than i
<ng0>pretty surry this got cut off
<janneke>yeah, well any judgement you volunteer only defines you, never the subject
<df_>it did
<df_>"they forget to support anything other than i"...
<ng0>okay, there was a comment on internet explorer monoculture cities :) and that it's more the task of work within fsf/fsfe to address this
<df_>I think there's a country, maybe s. korea? where pretty much everything like that requires IE
<df_>because of some crypto plugin
<ng0>public transportation unions etc here are big in open street maps (but not funding it afaik), and switched from windows to some GNU system in their infoscreens etc
<ng0>union for the lack of a translation right now and need to look for the noodles
<efraim>In execvp of tar: No such file or directory error in make-boot0 :(
<drakonis>what will cuirass take as a build input and output?
<drakonis>rather, only scheme files as input and will it output only the compiled packages?
<drakonis>instead of other package formats?
<htgoebel>ng0: Is there an easy way to build all packages (or a list of packages) without installing a service like Cuirass? I "just" need to build all these python packages I taught :-\\
<bavier>htgoebel: give the list of package names to 'guix build'
<ng0>yes, it should even be in the documentation, read it yesterday
<htgoebel>bavier: But how will I get the logs of the failed build then?
<bavier>htgoebel: 'guix build --log-file foo'
<htgoebel>bavier: Even if the build fails? I never succeded in this, but fill try. MOMPL
<bavier>there's also a '--keep-going' option so that the builds don't stop on the first failed build
<bavier>htgoebel: yes, --log-file works for failed builds too, IIRC
<ng0>If I need to 'replace' out with 'debug', and only building 'debug' as output, will it be only an extension of 'out' or is it just the stripped symbols?
<bavier>ng0: usually just the symbols
<efraim>if you're doing the actual building you end up with all the outputs
<ng0>I build out now with -O0 -ggdb, but for the current state I have the file in, it is desired to have it all in one go
<ng0>currently it's a limited guix package -f guix-env.scm
<paroneayea>cwebber@oolong:~$ guix package --upgrade --fallback
<paroneayea>guix package: error: build failed: querying path in database: database disk image is malformed
<paroneayea>what do I do? :(
<bavier>that doesn't sound good
<paroneayea>it really doesn't
<htgoebel>bavier: This does not work for me :-( I added a '#f' to some build-phase, maing the build fail.
<htgoebel>Then "guix build ABC" (which fails) and then "guix build ABC --log-file" tries to build again.
<htgoebel>It does not access log of the build just failed. :-(
<paroneayea>does this mean my state db is corrupt? :(
<paroneayea>oh shit
<paroneayea>[326237.878498] EXT4-fs error (device dm-0): htree_dirblock_to_tree:1000: inode #28738259: block 114829291: comm mu: bad entry in directory: directory entry across range - offset=0(3698688), inode=3063977346, rec_len=42136, name_len=146
<bavier>htgoebel: try 'guix build --log-file ABC' instead?
<htgoebel>bavier: Of course I did :-) Same result
<bavier>htgoebel: :) just checking, hmm..
<bavier>htgoebel: I'll add that to my todo list
<htgoebel>bavier: interestingly there actually is a logfile in /var/log/guix/drivers.
<efraim>i think vc should also be marked as #:substitutable? #f, it looks like it tunes itself for the cpu
<bavier>efraim: can we force it not to?
<efraim>possibly, i'm working on the fail to build parts of it atm
<htgoebel>bavier: As a work-around I will filter the full output of guix build for success and failure. This will be okay for now.
<ng0> , , , came in via gentoo advisory list. anything relevant for us?
<efraim>looks like we don't have apache
<ng0>isn't it just httpd i nguix?
<efraim>yes, and nginx
<efraim>ah, i see httpd is from apache
<efraim>we're at 2.4.23, so based on the ranges we should be fine
<ng0>ok. thanks for checking
<wingo>is danny milosavljevic here
<ng0>isn't danny dvc?
<ng0>or d4n1
<civodul>dvc is David, not Danny
<civodul>dunno if Danny is around
<wingo>sometimes when i change a service, it updates the herd. sometimes not. weird
<wingo>i haven't been able to get a feel yet for when this happens
<jmd>civodul: That tzdata change: Is there any reason why it cannot go on the master branch? There are very few dependencies so far as I can see.
<civodul>jmd: "guix refresh -l tzdata" reports 1026 dependencies
<civodul>wingo: what do you mean by "updates the herd"?
<jmd>civodul: Hmm. ok core-updates then.
<rekado>ng0: I think you can make the log out button appear by pressing Alt when the menu is displayed
<civodul>oh, CUPS!
<civodul>ACTION processes backlog backwards
<wingo>civodul: i mean, reloads the service definition in the herd
<wingo>text-file* mentioned in manual but not in code
<paroneayea>looks like my hard drive is mid-failure
<paroneayea>not a great time for this.
<wingo>aw bummer :(
<paroneayea>luckily, I did run a backup 3 weeks ago. unluckily, I normally have a nightly backup system, but that's down
<paroneayea>so I don't have a nightly backup.
<paroneayea>better than no backup
<paroneayea>I'm probably going to spend the next day or so packaging dirvish and making a guix service for it
<paroneayea>it might be a bit of a hacky service.
<paroneayea>but I need to fix this situation.
<bavier>paroneayea: cool, it'd be nice to have services for some of our other backup tools too
<paroneayea>bavier: are there other backup tools currently in guix?
<bavier>paroneayea: duplicity, unison, par2cmdline, hdup, rdup, btar, rdiff-backup, libchop, borg, attic
<ng0>I'd like to have ~1000 euro to invest in new harddrives :/ old-age failures are annoiyng
<rekado>I just switched to borg.
<bavier>maybe others
<bavier>paroneayea: see gnu/packages/backup.scm
<rekado>ng0: EUR 1000? How many TB do you need?
<paroneayea>bavier: oh
<paroneayea>bavier: I wonder, do any of those do "incremental" backups, the way dirvish does?
<bavier>paroneayea: duplicity and borg for sure
<paroneayea>dirvish uses hard links to only back up the files that have changed
<paroneayea>bavier: ok, cool. I'll look. dirvish is just perl scripts wrapping rsync with an expiration tool iirc
<paroneayea>so, it's not super fancy
<rekado>borg is pretty nice.
<ng0>rekado: some offline harddrives, some 24/7 running ones, some downsizing, all in all maybe around 10 TB? I don't count..
<wingo>if i change the "start" field of a service definition
<bavier>duplicity uses rsync too
<rekado>does incremental backups and you can backup to the same “repository” but with different prefixes.
<wingo>from like (make-forkexec-constructor ...) to wrap it in a begin or something
<rekado>so you can easily prune the backup by prefix
<ng0>i'm glad it's getting less data to save now :)
<wingo>it doesn't treat that service instance as being different, even though the code is different.
<ng0>i had backups in backups in backups in backups etc of years..
<wingo>or at least reconfiguring the system doesn't tell the herd to reload its definition
<rekado>ng0: I only have 1TB for archiving (two disks, RAID1)
<rekado>I’m fond of deleting data.
<wingo>when does guix tell the herd to reload, i wonder...
<ng0>I started deleting after years oftrying to sort..
<fps>i'm still wondering why this "sudo guix system reconfigure /config.scm" gives me this error:
<fps>i tried to find out which system.scm is meant in the backtrace [i suppose it's the one relative to sudo which guix?
<wingo>fps: earlier you were switching from a system that had dmd, right?
<wingo>did you manage to do that or are you still running dmd?
<fps>wingo: i'm still running dmd.
<fps>i figured the process was still called dmd :)
<paroneayea>rekado: cool
<paroneayea>good to know
<wingo>then check the release notes from the guix release that switched the name to shepherd
<wingo>the process changed names
<wingo>i think you have to reboot for that one
<fps>wingo: i thought the switch happened, because i checked whether the profile mentioned in the output was the current system profile
<fps>which seems to be the case..
<fps>i think i did reboot. but i'll try again
<wingo>good luck :)
<fps>right, i remember having rebooted, since i had to swtich to VT and do ctrl-alt-del instead of sudo reboot
<fps>yep, sudo reboot still throws the same error:
<fps>error: connect: /var/run/shepherd/socket: No such file or directory
<ng0>well 1000 because new harddrives are bigger.. those 6 and 8 TB ones :) sorry for derrailing, I'm on the phone and can't really follow
<civodul>wingo: 'guix system reconfigure' restarts only services currently stopped
<civodul>fps: are you reconfiguring from a dmd-era GuixSD?
<fps>civodul: yes
<civodul>so at worst you can always do a hard reboot :-), but otherwise just symlink /var/run/dmd to /var/run/shepherd (IIRC)
<fps>civodul: hard reboot twice didn't help..
<fps>i'll try syslinking
<civodul>wait, hard reboot should be enough
<civodul>what does "cat /proc/1/cmdline" show?
<fps>/gnu/store/5i87jzm90nw8j692y7z1j2qfx16h6ni3-guile-2.0.11/bin/guile--no-auto-compile/gnu/store/i4s7scak8pphwph2iggyspdz8gd8i7mr-dmd-0.2.01/bin/dmd--config/gnu/store/dkrrd07ylsxdryxkikmxhzyd8ljj0yvp-dmd.confbash: __git_ps1: command not found
<fps>ignore the git prompt thingie at the end ;)
<civodul>so it's still running dmd
<civodul>so you have the reverse problem
<fps>civodul: yeah, i get an error during reconfigure, too.. did you see the paste from before?
<civodul>the reconfigure error is harmless: it tries to talk to the shepherd to upgrade services, but the shepherd is not running yet
<civodul>oh wait, actually it didn't upgrade grub
<civodul>so you can do the symlink thing and then re-run 'guix system reconfigure'
<civodul>that Should Be Fine
<fps>thanks. doing that right now
<fps>that locked up the box hard :)
<wingo>civodul: thank you for that reconfigure trick! :)
<fps>maybe i should just rescue the config.scm and just reinstall guixsd from an installer
<ng0>I still need to ./configure --localstatedir=/var when I run the system from a git checkout right? Sometimes i make clean and the .po get cleaned
<fps>did it again from VT, got a kernel panic. snapped a pic
<ng0>I mean.. I can't damaged anything. I did this on first change. so it should just work
<ng0>running a system from git is strange at first.
<fps>sadly my camera sucks
<fps>it seems dmd just dies when asked to do dirty things like roleplaying as shepherd :)
<civodul>i forgot the details of the transition
<fps>i can just install a new system, no prob. so no worries, unless you want to find out for your peace of mind :)
<civodul>fps: you found a bug in 'guix system reconfigure'
<civodul>just looking at it now
<civodul>it shouldn't stop when the shepherd is unreachable
<fps>civodul: glad, i could help :)
<ng0>hm.. I like outsourcing jobs I work on but can't focus fully on to people who are really interested in seeing it ready tomorrow, but I think in the case of uclibc-ng it's one of the few were I'm really the only interested person working on it
<civodul>fps: could you pull and try again?
<fps>civodul: sure
<fps>civodul: sudo guix pull && sudo guix system reconfigure... ?
<fps>or should i first get a git checkout?
<ng0>like, what happened to musl? isn't that package ready or did the discussion just pause? musl is not uclibc-ng, uclibc-ng is more compatible to gcc
<civodul>fps: 'guix pull' as root
<civodul>ng0: good question, i wonder what happened with musl
<ng0>should I comment at the patches? I'd like to just comment.. whoever needs details can please use the archive we keep, for context :)
<ng0>just to bump attention to it.
<fps>civodul: new error :) will try with the symlink now
<fps>civodul: same error with the symlink. i guess that's good..
<civodul>fps: could you send the output of: cat `guix build --log-file /gnu/store/g3lczpayfk7b77aws2cx02x4j9qj63n6-grub.cfg.drv`
<ng0>I don't get icecat.. is it just hedlund doing all the work? the discussion list looks like at least 5 more people in the last months, but yeah building firefox is hard, but discussion delays releases and cves etc add up
<ng0>whoever said palemoon is just one person I don't get that either, the (new?) github repository has further contributions by at least 30 people
<civodul>fps: er, rather: bzcat `guix build --log-file /gnu/store/g3lczpayfk7b77aws2cx02x4j9qj63n6-grub.cfg.drv`
<fps>fps@cherry 11:14:14 ~ $ bzcat `guix build --log-file /gnu/store/g3lczpayfk7b77aws2cx02x4j9qj63n6-grub.cfg.drv`
<fps>bash: __git_ps1: command not found
<fps>seems to be empty.. i'll fix my prompt right now ;)
<fps>yep, empty..
<civodul>well i'm clueless
<civodul>is it reproducible?
<civodul>we'd need to check your config etc. i suppose
<civodul>ACTION -> zZz
<civodul>good night/day!
<fps>civodul: night. thanks for your help :)