IRC channel logs
2014-03-10.log
back to list of logs
<civodul>phant0mas: did you register and everything on google-melange? <ph4n70m4s>civodul: just finished for today my courses at the university <ph4n70m4s>google melagne hasn't opened yet for students <mark_weaver>civodul: btw, for the last few days, I've been bootstrapping core-updates on MIPS, to make sure everything is good there. (I've also been bootstrapping that with /gnu/store, even before you made it the default). <mark_weaver>however, I cherry-picked some commits from master that have not yet been merged into core-updates, and upgraded libgc-7.2d to 7.2e in the build I'm doing. <mark_weaver>it would be good to merge master into core-updates. right now, core-updates contains some important security problems (e.g. the bad gnutls) and is unbuildable (bdw-gc has bad URLs). <mark_weaver>(I'm willing to do it if you like, although I'm not 100% sure that I'd do the job competently) <civodul>mark_weaver: ah right, we should merge into core-updates <ph4n70m4s>mark_weaver: I placed libpthread as an input <ph4n70m4s>and now I am trying to create a folder named libpthread and copy everything in there <ph4n70m4s>I am trying to understand how can I say copy the insides from that input into that folder? <mark_weaver>well, first of all, does it need to be copied? could it be a symlink? <ph4n70m4s>it needs to be built, but I though you told me yesterday that that couldn't happen in the downloaded folder <rigelk>hi #guix :) i was wondering, how often should one use 'git pull' ? <mark_weaver>if it needs to be built separately, then indeed you'll have to make it a separate package. <mark_weaver>I had a vague recollection of glibc addons being tarballs that you just unpacked into a subdir of the glibc source tree before building glibc, but I might be misremembering. <mark_weaver>the downloaded folder will be immutable, but if you use a separate build directory, that should be okay, no? <mark_weaver>rigelk: well, it's like "apt-get update". how often do you do that? <rigelk>ok ; i'm just not used to versionning systems ^^' <ph4n70m4s>mark_weaver I just need to unpack it in the glibc source folder, pass --enable-add-ons and it should work <mark_weaver>I mean, there's a 'copy-recursively' procedure (search for it in gnu/packages), but if a symlink works that seems a bit better. <mark_weaver>hmm, well, unless it needs to be patched or substituted, which might be the case. <mark_weaver>ph4n70m4s: I changed my mind: better use 'copy-recursively' <mark_weaver>the reason is that there are various things that go around patching and substituting hardcoded paths, shebangs, etc, and they probably won't follow the symlink. <ph4n70m4s>now let me find some examples on copy-recursively <mark_weaver>it's very simple: (copy-recrusively <source> <destination>) <ph4n70m4s>so where <source> I will put (assoc-ref inputs "libpthread") ? <ph4n70m4s>mark_weaver: any idea why it won't recognize my input and keeps giving me ERROR: In procedure memoize-variable-access!: <ph4n70m4s>and I add to a phase before configure (copy-recursively (assoc-ref %build-inputs "libpthread") ".") <mark_weaver>it would be better if you include the entire recipe, rather than tiny excerpts of the bits you think are relevant. <mark_weaver>that bit doesn't even include the reference to %inputs <mark_weaver>ph4n70m4s: anyway, the way it's normally done in phases is that the inputs are passed into the procedure as a keyword argument. <mark_weaver>so the phase might be something like (lambda* (#:key inputs #:allow-other-keys) (copy-recursively (assoc-ref inputs "libpthread") ".")) <ph4n70m4s>mark_weaver: sorry for the delay, I had to get something for my sister <ph4n70m4s>have a look when you have some time to my recipe, till now <mark_weaver>ph4n70m4s: a few comments: I forgot it in the code I suggested, but the call to 'patch' should include the "--batch" option. <mark_weaver>in your unpack phase, I'd add 'inputs' after #:key (alongside 'source'), and then use copy-recursively in there to copy in the libpthread add-on <mark_weaver>(I'm assuming here that you're correct that it's really needed, although it would be nice to find out if it truly is) <ph4n70m4s>I will find out and be back with a good answer <mark_weaver>maybe the apply-patch phase should also accept 'inputs' as a keyword argument, and then use it instead of %build-inputs. *mark_weaver goes afk for a while. happy hacking! <ph4n70m4s>civodul: the glibc recipe is getting bigger and bigger :P <civodul>ph4n70m4s: not really surprising but hey ;-) <civodul>do you want to copy/paste it somewhere for discussion? <ph4n70m4s>just got a ERROR: In procedure copy-file: Permission denied <ph4n70m4s>the part of my code causing the error with the error <ph4n70m4s>I am doing something wrong with the folder I am pointing at <ph4n70m4s>no the folder is right I just don't have permissions to write <civodul>ph4n70m4s: what does ls -l "/nix/store/vk7fij36hdyyyx42yz7gj5vgi1n4l28l-git-checkout/CONFORMANCE" show? <ph4n70m4s>-r--r--r-- 1 root guix-builder 6522 Jan 1 1970 /nix/store/vk7fij36hdyyyx42yz7gj5vgi1n4l28l-git-checkout/CONFORMANCE <civodul>so where does that permission denied comes from? <ph4n70m4s>when it finishes copying files from glibc, and it starts to copy the files from the libpthread I get this error <ph4n70m4s>this line causes the error (copy-recursively (assoc-ref %build-inputs "libpthread") ".") <civodul>ph4n70m4s: i think that's because ./CONFORMANCE already exists (was just copied from glibc) <civodul>do you instead want: (copy-recursively (assoc-ref inputs "libpthread") "libpthread") ? <civodul>i think the add-on must be in a subdir no? <ph4n70m4s>I think we have another problem now, it recopies everything in the libpthread folder <ph4n70m4s>actually it isn't even downloading libpthread <ph4n70m4s>and it should give me an error when trying to download it <civodul>ph4n70m4s: indeed, the 'libpthread' subdir contains glibc, not libpthread <ph4n70m4s>now getting In procedure mkdir: Permission denied <civodul>ph4n70m4s: BTW, you might want to email guix-devel and bug-hurd about your intentions for GSoC <civodul>well, everyone knows you now, but still ;-) <ph4n70m4s>yep, you are right, I just have to write a roadmap and I will send it to the mailing lists with my intentions <ph4n70m4s>most of it has already been discussed here so it shouldn't take me much time :P <ph4n70m4s>but I will do it tomorrow , today I want to find out how to fix this error <civodul>as a starter, did you try building it without libpthread? <ph4n70m4s><braunr> ph4n70m4s: something is trying to compile as an x86-64 object, while the hurd is i386 only <civodul>well anyway, it was just to get an "it almost works" feeling ;-) <civodul>so does libpthread get copied correctly now? <ph4n70m4s>keep getting an error that mkdir has no permission, which I shouldn't <ph4n70m4s>but with this way it would be simpler to apply a patch <ph4n70m4s>and by adding it to the inputs, it would be added to cpath <ph4n70m4s>and it would work without having to worry about it <civodul>it can't really be a package since there's nothing to build <civodul>could you copy/paste the full definition and build log? <civodul>ph4n70m4s: (copy-recursively (assoc-ref %build-inputs "libpthread") "/libpthread") <civodul>that should be "libpthread", not "/libpthread" <civodul>also you can use 'inputs' here (the lambda's parameter) instead of '%build-inputs' (the global var) <ph4n70m4s>i will create a libpthread folder, chdir in it <civodul>ph4n70m4s: in libpthread's origin, can you add (file-name "libpthread") so it's easier to differentiate its directory?