IRC channel logs

<civodul>crap, we don't have gcc.info installed

<mark_weaver>someone has recently started launching denial of service attacks of increasing sophistication against my humble server :-(

<atheia>:-(

<civodul>mark_weaver: ouch

<mark_weaver>civodul: interestingly, I have gcc.info 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 gcc.info 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> http://paste.lisp.org/display/141997/raw

<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 http://paste.lisp.org/display/141999/raw

<phant0mas>maybe I am missing something

<civodul>mark_weaver: actually it's just gcc-final that lacks gcc.info

<civodul>blech

<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>:-)

<civodul>the main reason for installing gcc-final is to avoid duplication

<mark_weaver>hehe

<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.

<civodul>well

<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

<civodul>ok!

<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? http://paste.lisp.org/display/141997/raw

<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

<mark_weaver>okay

<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 ?

<phant0mas>yes

<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> http://paste.lisp.org/display/142002/raw

<phant0mas>which commit?

<phant0mas>let me fetch the upstream

<civodul>ok

<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

<civodul>yes

IRC channel logs

2014-04-11.log