IRC channel logs


back to list of logs

<phant0mas>zacts: :-)
<zacts>lo #guix
<civodul>Hello Guix!
<civodul>crap, we don't have installed
<mark_weaver>someone has recently started launching denial of service attacks of increasing sophistication against my humble server :-(
<civodul>mark_weaver: ouch
<mark_weaver>civodul: interestingly, I have on my YeeLoong, which is currently running based on core-updates not long before it was merged into master (with several more recent commits cherry-picked)
<mark_weaver>(I'm still waiting for the YeeLoong to finish building the packages I need from current master)
<mark_weaver>specifically, it seems that was installed properly in 1eefbb2693f0f29f8f095af9f067240b85e735aa
<phant0mas>civodul: when I try to do (lambda _ (zero? (system* "patch" "-p1" "-i" (assoc-ref %build-inputs "patch/hurd-minimal"))))
<phant0mas>I get ?: 0 [system* "patch" "-p1" "-i" #f] ERROR: In procedure system*: ERROR: Wrong type (expecting string): #f
<phant0mas>but why? I have the patch as a native input and it should associate it to the input
<phant0mas>I am using the source from git for hurd, so I can have the latest additions
<mark_weaver>so gnu/packages/patches/hurd-minimal.patch exists? (I'm not sure off-hand what would happen if it didn't)
<mark_weaver>btw, you should always pass "--batch" as an argument to 'patch' within recipes, although that's not the problem here.
<mark_weaver>phant0mas: ^^
<phant0mas>yes it exist , I made a make clean and make -j4
<phant0mas>I am waiting
<phant0mas>still nothing...I am using the same method in base.scm and it works just fine
<mark_weaver>and you ran the failed build with ./pre-inst-env ?
<phant0mas>yes, here is the error output
<phant0mas>maybe I am missing something
<civodul>mark_weaver: actually it's just gcc-final that lacks
<mark_weaver>so it just depends on which 'gcc' gets picked up when we do "guix package -i gcc", and that's non-deterministic, right?
<civodul>yes, but i use gcc-toolchain, which uses gcc-final
<civodul>but yeah, we must do something about that non-determinism
<mark_weaver>and I suppose that I should really be using gcc-final. presumably the one I'm using is inferior in some way, or loading a separate copy of glibc.
<mark_weaver>could we simply not export the ones that shouldn't be installed by users?
<civodul>actually both use the same libc
<civodul>mark_weaver: not really, they still have to be exported
<civodul>because for instance, gcc-final cannot be cross-compiled
<civodul>whereas gcc-4.8 can
<civodul>what i had in mind was to special case stuff in %final-inputs, in 'guix package'
<civodul>though i've never found it very appealing either :-)
<mark_weaver>other than not being able to cross-compile gcc-final, what's the difference between it and the other one? what's the advantage to using gcc-final?
<mark_weaver>I suppose another possibility would be to change the names of the non-final versions of packages.
<mark_weaver>we already have things like "make-boot0". I'm not sure why we don't do something similar for the other non-final packages.
<phant0mas>still the same...
<civodul>mark_weaver: (@ (gnu packages gcc) gcc-4.8) is a GCC built with gcc-final
<civodul>so it's "post-final"
<civodul>the main reason for installing gcc-final is to avoid duplication
<phant0mas>civodul: thnx for the patch, I had already made my own but yours is way more elegant :P
<phant0mas>but the problem is that it won't find it
<civodul>make-boot0 is private
<civodul>phant0mas: try the patch :-)
<civodul>that should disable attempts to link a program
<mark_weaver>well, why not rename the duplicate packages that users shouldn't install directly, is what I mean.
<mark_weaver>when I wrote "final" above, I meant "really final" :)
<civodul>you mean renaming the "post-final" ones?
<mark_weaver>I mean renaming all the ones that "guix package -i" and "guix build" should not use.
<mark_weaver>(it's not clear to me why we have so many versions of 'gcc', or why we have a "post-final" one that's not used to build most of our packages)
<civodul>the difficulty is that (@ (gnu packages gcc) gcc-4.8) also happens to be the "abstract" recipe for gcc
<civodul>things in base.scm just inherit from it
<civodul>because of the above
<mark_weaver>hmm. well, I have to go afk for a while. ttyl!
<civodul>base.scm bootstraps the distro, so it has to tweak all the base packages, like glibc and gcc
<phant0mas>civodul: I get [system* "patch" "-p1" "-i" #f] ERROR: In procedure system*: ERROR: Wrong type (expecting string): #f
<phant0mas>that's why I can't try the patch
<phant0mas>I have added the patch to gnu-system-am
<phant0mas>can you have a look at my recipe?
<mark_weaver>civodul: what would happen if 'native-inputs' contained an entry of the form ("foo" #f)? I can't help but suspect that his (search-patch "hurd-minimal.patch") is failing to find it, and returning #f.
<mark_weaver>phant0mas: although this is not the problem, can you please insert "--batch" as an additional argument to "patch" before the "-i" ?
<phant0mas>mark_weaver: I already did that I just resent the previous link :-)
<civodul>mark_weaver: "guix build" would give an "invalid input" error
<phant0mas>the patch is in the gnu/packages/patch folder
<phant0mas>as it should
<mark_weaver>civodul: okay
<phant0mas>and I added the patch to gnu system-am
<civodul>phant0mas: put the patch in the 'patches' field of 'origin' (grep for examples)
<mark_weaver>you mean gnu/packages/patches ?
<civodul>phant0mas: and remove the two lines starting before "(alist-replace"
<mark_weaver>yeah, I was going to ask why you didn't do it the standard way.
<phant0mas>because I am using the git source
<phant0mas>let me try again
<phant0mas>'patches' cannot work with source from git, because it assumes a tar file
<phant0mas>and it finds a folder
<phant0mas>I had the same problem with glibc, and I did it the hard way and it worked
<phant0mas>why won't it now?
<civodul>phant0mas: can you paste the log?
<civodul>i thought i fixed this during core-updates
<phant0mas>which commit?
<phant0mas>let me fetch the upstream
<civodul>hmm 'patch-and-repack' in packages.scm seems to do the proper check
<civodul>are you using current master?
<phant0mas>my branch was left a bit behind :P
<phant0mas>merging master with mine
<phant0mas>merged my branch with upstream
<phant0mas>let it rebuild the toolchain...
<civodul>phant0mas: you might want to use substitutes (see "Substitutes" in the manual)
<civodul>zacts: just pushed Mosh
<Fulax>civodul: could you share the dmdconfig file you use to start the services in the qemu vm? I think it is not included in dmd distribution
<civodul>Fulax: of course it's included :-)
<civodul>it's generated from (gnu services dmd)
<civodul>you can boot the VM and do search for /gnu/store/*-dmd.conf
<Fulax>civodul: thanks :-)
<Fulax>(oh, the generated file misses pretty printing)
<civodul>yeah, it's not optimized for human beings
<Fulax>ah right, (gnu services dmd) is in guix, not in dmd's git