IRC channel logs

<zacts>lo

<rgc>hi. can I install (or search at least) for an older version of a package in guix? 'guix package -s foo' only gives me latest version of foo

<rgc>gnight!

<civodul>Hello Guix!

<phant0mas>good morning guix

<phant0mas>I am starting to think that I should create a different recipe for libpthread

<phant0mas>where I will configure and build it there and then I will add the resulting folder in the cpath at glibc

<civodul>phant0mas: sure, but ISTR from a discussion with youpi that building it as a glibc add-on allowed "more stuff to work", so to speak

<civodul>so you should check with them what the tradeoffs are

<phant0mas>ok

<civodul>phant0mas: also don't hesitate to email the latest problems that you've had

<civodul>(if you haven't done already)

<phant0mas>I won't hesitate :-) I just want to try and do some search first

<phant0mas>my question is ,how do I pass flags to libpthread configure when it is invoked from the glibc configure?

<civodul>aah, ok

<civodul>lemme see

<civodul>which flags?

<phant0mas>--build=i686-pc-gnu ac_cv_lib_ihash_hurd_ihash_create=yes

<civodul>isn't it enough to pass them to the top-level configure?

<civodul>normally all the flags are passed down to sub-dir configures

<phant0mas>hm..Now that I think about it I only pass --target in the crossbase recipe

<phant0mas>not build

<phant0mas>let me try

<civodul>also, you need to build libhurd-ihash before you can build libc

<phant0mas>the second flag I pass is to stop configure from asking about it

<phant0mas>I added build but still getting

<phant0mas>configure: WARNING: you should use --build, --host, --target

<phant0mas>checking build system type... Invalid configuration `dummy': machine `dummy' not recognized

<civodul>indeed, "dummy" is no good

<civodul>i understand why you pass ac_cv_lib_ihash_hurd_ihash_create=yes, but i think you can't avoid building libhurd-ihash

<civodul>(IIRC)

<civodul>in Nixpkgs i had a "hurd-minimal" package for that

<phant0mas>I am checking it now

<civodul>yeah: https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/gnu/default.nix

<civodul>search for "This intermediate Hurd"

<phant0mas>ok

<phant0mas>civodul: If I understood well I should create a minimal hurd in hurd.scm with "libihash", "libstore" and "libshouldbeinlibc" so I can have the needed libs for building glibc and parted later

<phant0mas>am I right?

<phant0mas>starting with that

<phant0mas>libihash built succesfully

<civodul>phant0mas: yes, right

<phant0mas>libihash built pretty straight forward

<phant0mas>for now that's what I need to build libpthread

<phant0mas>lets try building glibc wiith it ,again now

<d4j4443>I've cloned guix from git. While trying to install a package, I get build error: getting attributes of path `/dev/kvm': No such file or directory. Suggestions?

<rgrau>have you followed any steps to install it, or using ./pre-inst-env ?

<d4j4443>I'm using ./pre-inst-env.

<rgrau>I only found kvm errors when trying to build the distro

<rgrau>have you tried to build (or install ) 'hello' ?

<rgrau>it's the most basic package in guix

<rgrau>anyway, here it goes: http://puntoblogspot.blogspot.com.es/2014/02/guix-tutorial.html (shameless plug)

<d4j4443>I've tried a bunch of packages. It always fails with the mentioned error after it lists the things that will be built.

<d4j4443>Thanks for the link. I'm familiar with guix and have been using it quite a while. However, I've never seen the mentioned error.

<d4j4443>rgrau: Could you run 'make check' on HEAD, by the way? One test fails for me.

<rgrau>no guix in this box .... :/

<d4j4443>No problem.

<civodul>/dev/kvm?

<civodul>aah right

<civodul>probably new

<civodul>d4j4443: can you just create that device?

<civodul>char device, 10, 232

<d4j4443>civodul: I don't understand your instructions. Could you refer me to a manpage or something?

<civodul>d4j4443: mknod /dev/kvm c 10 232

<civodul>mknod(1) creates "device files"

<d4j4443>It wasn't needed before. Why is it needed now?

<civodul>d4j4443: that's from yesterday's daemon update, i think

<civodul>the goal being to be able to use KVM in the build env, i suppose

<civodul>ttyl!

<d4j4443>civodul: I'm a bit busy with something else. So I can't run the above command right now, but will do asap.

<phant0mas>civodul: did you check my email?

<mark_weaver>civodul: have you noticed that when guix is built to use guile 2.0.10, deprecation warnings are sometimes issued when building packages that need to be downloaded?

<d4j4443>civodul: What do 10 and 232 mean?

<civodul>mark_weaver: i've seen that, but it vanished when setting GUILE_WARN_DEPRECATED=detailed

<civodul>well i didn't investigate further

<mark_weaver>d4j4443: those are the major and minor device numbers

<civodul>phant0mas: yes, on moment please :-)

<mark_weaver>civodul: for me, it didn't vanish, but the environment variable setting had no effect, presumably because it wasn't propagated to build environment.

<civodul>ah you mean inside the build environment?

<civodul>blech

<mark_weaver>that's my guess anyway

<mark_weaver>civodul: can tzdata be updated in master, or only core-updates?

<civodul>master!

<mark_weaver>thanks!

<mark_weaver>damn, in my haste I pushed the tzdata updated with only the summary line in the commit log. sorry :-(

<civodul>heh, that's ok ;-)

<d4j4443>civodul: If the 'guix authenticate' change is a blocker and you have time to test it yourself, feel free to do so. I suspect that it'll take me quite a while.

<d4j4443>I have to install a bunch of packages, then install Nix, then test using 'signString', then send a patch to the list.

<d4j4443>mark_weaver: But what do 10 and 232 mean?

<mark_weaver>d4j4443: in the kernel, there is a table of major device numbers. each one corresponds to code in the kernel that implements that device.

<mark_weaver>the meaning of the minor device numbers depend on which major device number is used, but often they select which specific device, e.g. for SCSI devices they would encode the ID number.

<civodul>phant0mas: i've shamelessly put bug-hurd in the loop :-)

<d4j4443>Okay, but why these particular values, not something else? Where can I read more about this?

<civodul>d4j4443: i'll se what i can do

<civodul>(in between two Guile releases :-))

<mark_weaver>d4j4443: https://www.kernel.org/doc/Documentation/devices.txt

<d4j4443>civodul: I mean I could try so myself. No worries. For now, I'm going to assume that you're not working on it.

<civodul>d4j4443: i'll look

<mark_weaver>d4j4443: btw, that file is also in the linux source tree

<d4j4443>civodul: So, should I stop thinking about it? No pressure, just trying to understand the situation.

<d4j4443>mark_weaver: Thanks.

<d4j4443>It seems that mknod solved the issue.

<davexunit>xb

<davexunit>oops, sorry

<civodul>d4j4443: actually i thought you had posted a patch for me to test, but actually no?

<d4j4443>No.

<d4j4443>I made some (untested) changes locally, but I doubt it'll work.

<d4j4443>Basically, I replaced 'data' with (bytevector->hash-data (base16-string->bytevector (string-trim-both (get-string-all (standard-input-port)))))

<d4j4443>Perhaphs I should use pipes instead.

<d4j4443>Perhaps*

<phant0mas>civodul: I will reattach the log files so the hurd guys can see them as well

<d4j4443>I'm wondering if I'm being an idiot for using --no-substitutes since my machine may be already be backdoored.

<mark_weaver>d4j4443: I don't think so

<civodul>d4j4443: you're talking about changes needed so 'guix authenticate' can work when called from Crypto.pm?

<d4j4443>Yes.

<civodul>ok

<civodul>i can do them, but maybe not today

<civodul>we'll see

<d4j4443>Please let me know if you do, so either my or your time won't be wasted.

<civodul>yes, sure

<d4j4443>Thanks.

<mark_weaver>GNU fdisk depends on guile-1.8.

*mark_weaver adds to his TODO list :)

<civodul>heheh :-)

<mark_weaver>GNU Parted fails to build in core-updates.

<mark_weaver>ui.c:1477:41: error: 'CPPFunction' undeclared

*mark_weaver goes afk for a while.

<civodul>mark_weaver: i just noticed commit 3fd01b171a74d28dc8e48b9ee5f2d0e9a3915fb8 in nix (for the daemon)

<civodul>looks like what we wanted, re /dev

<mark_weaver>nice!

<phant0mas>civodul: and till we find a solution to my problem I started working on renaming the linux glibc to glibc/linux and the macro you suggested

<civodul>ok

IRC channel logs

2014-03-20.log