IRC channel logs


back to list of logs

<phant0mas>good morning guix
<mark_weaver>hi phant0mas
<civodul>Hello Guix!
<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
<ph4n70m4s>it will open in 3 hours
<civodul>ah okay, perfect
<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
<civodul>i can do that
*civodul has to go
<ph4n70m4s>mark_weaver: I placed libpthread as an input
<ph4n70m4s>like you told me
<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>is that right?
<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?
<mark_weaver>(if you ever used a Debian-derived distro)
<mark_weaver>basically, as often as you want updated packages.
<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>could you make a symlink instead of copying it?
<mark_weaver>worth a try, I think.
<ph4n70m4s>I will
<ph4n70m4s>le tme see
<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.
<mark_weaver>(sorry for the flip-flopping :)
<ph4n70m4s>no worries :-)
<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>I named the input libpthread
<mark_weaver>i guess so, yes
<ph4n70m4s>mark_weaver: any idea why it won't recognize my input and keeps giving me ERROR: In procedure memoize-variable-access!:
<ph4n70m4s>ERROR: Unbound variable: %inputs
<ph4n70m4s>here is my input
<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
<ph4n70m4s>ok one sec
<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
<ph4n70m4s>it's without (copy....)
<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>obviously, any advice civodul gives trumps mine :)
*mark_weaver goes afk for a while. happy hacking!
<civodul>heh :-)
<rigelk>hi civodul :)
<ph4n70m4s>civodul: the glibc recipe is getting bigger and bigger :P
<civodul>hey rigelk
<civodul>ph4n70m4s: not really surprising but hey ;-)
<civodul>do you want to copy/paste it somewhere for discussion?
<rigelk>civodul: he has pasted it here
<rigelk>(just before you joined ;)
<ph4n70m4s>applying what mark suggested now
<ph4n70m4s>it's work in progress
<ph4n70m4s>just got a ERROR: In procedure copy-file: Permission denied
<ph4n70m4s>civodul: any suggestion on this
<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?
<civodul>so that's it :-)
<ph4n70m4s>I think we have another problem now, it recopies everything in the libpthread folder
<ph4n70m4s>let me check the folder
<ph4n70m4s>yep it recopies everything
<ph4n70m4s>take a look
<ph4n70m4s>actually it isn't even downloading libpthread
<ph4n70m4s>because the hash is the wrong one
<ph4n70m4s>and it should give me an error when trying to download it
<civodul>ph4n70m4s: indeed, the 'libpthread' subdir contains glibc, not libpthread
<ph4n70m4s>yep I had a typo
<ph4n70m4s>now getting In procedure mkdir: Permission denied
<ph4n70m4s>I have an idea
<civodul>good :-)
<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>yes, had some assembler errors though
<ph4n70m4s>I am looking into that
<civodul>i686 or x86_64?
<ph4n70m4s><braunr> ph4n70m4s: something is trying to compile as an x86-64 object, while the hurd is i386 only
<ph4n70m4s>having a look into the config files first
<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 I got another idea
<ph4n70m4s>making libpthread a different package
<ph4n70m4s>without config/building/install phase
<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?
<ph4n70m4s>just give me a sec
<ph4n70m4s> <-- build log, it's not all because in it's most part it's just copying files
<ph4n70m4s> <-- the full definition
<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>fixed it
<ph4n70m4s>but still copies the same
<ph4n70m4s>the problem must be elsewhere
<ph4n70m4s>i will create a libpthread folder, chdir in it
<ph4n70m4s>and the copy the things in it
<ph4n70m4s>let's try that
<ph4n70m4s>now it justs ignores me...
<ph4n70m4s>like it doessn't exist
<civodul>ph4n70m4s: in libpthread's origin, can you add (file-name "libpthread") so it's easier to differentiate its directory?
<civodul>(see libwebsockets.scm)
<ph4n70m4s>one sec
<ph4n70m4s>it worked
<ph4n70m4s>at least it downloaded the file