IRC channel logs


back to list of logs

*davexunit tries to hack on 'guix publish' again
<davexunit>(after seeing it mentioned several times in the roadmap that ludo posted on the ML)
<jxself>What is it supposed to do?
<davexunit>jxself: it creates a web server that exposes a Hydra-compatible API
<jxself>Ah, OK.
<davexunit>so you can fetch binaries from someone's guix :)
<davexunit>if all goes well, it will be an integral part in our Hydra replacement.
<davexunit>if only I could get over this "invalid end-of-file marker" error when pulling in the substitute
<davexunit>something isn't quite right
<jxself>Perhaps there is an invalid end-of-file marker? :)
<jgrant>davexunit: By far, one of the coolest potential features for Guix. :^)
<davexunit>I think I see the problem now, finally.
<davexunit>props to ludo for telling me to use strace on it
<bavier>I thought the new cpan importer would help in packaging hydra, but now with `guix publish` coming along, that might not be necessary ;)
<davexunit>it looks like, since the substitute is uncompressed, that it interprets the end-of-file marker from some scheme code
<davexunit>bavier: there's still a bunch of work to replace hydra, so having hydra available in guix is still very worthwhile.
<jgrant>Is there an eventual goal to replace Hydra proper, with a Guile-based solution generally?
<davexunit>guix publish exposes a small piece of Hydra's HTTP endpoints, only those useful for substitutes.
<davexunit>jgrant: yes.
<davexunit>that's the long term goal.
<jgrant>davexunit: Okay, yeah. So up there with the nebulous and hopeful goals of getting "all of Guix in Guile"? :^) (ie: too the Nix daemon)
<davexunit>it's not all that nebulous: the daemon and hydra need to replaced. then we'd be running 100% on Scheme.
<jgrant>davexunit: Nebulous in that seems like approximately like "a lot of work" but not really quantified on my end as how much doing such things would be. But yeah, gotcha, ultimately it's "only these two things" but it seems like somewhere from a pain to a monster to actually re-implement.
<davexunit>Hydra will be easier to replace, for sure.
<jgrant>Well, as always excited to see how such things are trudging along in this camp. I'm hoping by the end of the year, I'll be a bit less useless and be able to start working on thing that are not just packages.
<davexunit>hmmm, looks like we have no existing usage of bzip2 for compression...
<davexunit>that's what Hydra uses, so I guess I'll have to figure that part out...
<jgrant>Not to say packaging is useless, but within the frame of my day to day computing -- the only stuff missing is CL based applications, which I'd need to be able to figure some factor of a build system for it... which is a bit past my skill-level currently.
<jgrant>Stumpwm is certainly up there of big packages Guix is missing for me to fully make the switch, but too being dependent on this non-existent build-system for dependencies, I see being a bit problematic atm to persue more seriously.
<davexunit>a-ha, looks like I don't have to do that. (guix utils) has compressed-port and decompressed-port, awesome!
<davexunit>jgrant: does stumpwm have it's own special build system?
<davexunit>or do you need sbcl + a common-lisp-build-system?
<jgrant>davexunit: No, but it depends on clx and cl-ppcre which I think needs somefactor of asdf iirc.
<davexunit>hmm, okay.
<jgrant>davexunit: But yeah, the lack of workable implementation is a problem.
<jgrant>SBCL, Clisp, or otherwise.
<davexunit>yeah, getting support for a new language can be tricky
<davexunit>I want to get the ruby-build-system up to snuff, but ruby packages are insane and I have no idea how to build them in any sensible way.
<davexunit>one package I saw had a build script that assumed you were in a git repo
<jgrant>davexunit: Yeah, that's a little suspect.
<jgrant>Was it a well known package?
<davexunit>but I can't remember which one
<davexunit>it just reaffirms my biases against ruby programmers.
<davexunit>while I programmed in ruby professionally for a couple of years and generally like the language, the community does some boneheaded things whilst thinking that they are more advanced than everyone else.
<jgrant>davexunit: I was going to say, I assume you had some history there remembering you did someactor of webdev (at least historically).
<davexunit>but when I can't build a gem from your source releases... there's a problem.
<davexunit>"just use"
<jgrant>There seems to be a slightly larger contingency of "douchebaggery" in the webdev community than other facets of compsci ... that being said, it's relatively bad wherever. The ego is always present, nearly, it seems.
***handheldCar is now known as grasshopprWhoppr
<civodul>Hello Guix!
<civodul>bavier: there's an unbound-variable warning in a 'match' form in cpan.scm
<civodul>i'm not sure what the intent is, so i leave it up to you
<rekado_>hmm, a lot of the java tests fail because uname cannot be found. That's odd because coreutils/bin is in the PATH.
<rekado_>With Emacs installed through Guix on Fedora I get this error upon starting Emacs: "Error (initialization): User rekado has no home directory"
<rekado_>--debug-init doesn't make any difference.
<rekado_>HOME is set, of course, and it does work fine with the stock Emacs 24.3 (Fedora 20) and with a self-compiled 24.4 in /usr/local
<iyzsong>heh, that's fun :-
<iyzsong>I can reproduce the error with 'env -i USER=not-exist TERM=$TERM $(which emacs)'
<rekado_>I wonder if this is because I'm using sssd with LDAP authentication.
<rekado_>this is on my workstation in the office where we all authenticate against AD.
<rekado_>on my private machine Emacs works fine.
<rekado_>on this workstation there is no local user account with this name.
<civodul>quick poll: "GNU Software Distribution" (GSD)
*civodul likes
<civodul>howdy, davexunit
*civodul reiterates the poll
<civodul>quick poll: "GNU Software Distribution" (GSD)
<davexunit>hey civodul
<davexunit>that sounds fine. it's a technical, sterile name.
<rekado_>to be parsed as "(GNU) (Software Distribution)" not "(GNU Software) (Distribution)"
<davexunit>kind of plays on BSD
*rekado_ likes it
<davexunit>it certainly feels uncontroversial.
<davexunit>I was partial to NotYourAverageOS or BetterThanThatOtherOS, though.
<davexunit>or ICan'tBelieveIt'sNotNixOS
<effa>Much better :-)
<civodul>"sterile name" :-)
<davexunit>I like that it just says what it is: a distribution of GNU software
<effa>What about "Funky GNU", with Funky as funky and as functional :-)
<civodul>davexunit: actually it's a GNU distribution of software, i think
<civodul>but yeah
<civodul>purely descriptive
<davexunit>hehe I was about to make that correction
<davexunit>but you beat me to the enter key
<civodul>let's see what rms says
<davexunit>brace for disappointment, but let's hope it works out.
*rekado_ actually likes the name *very* much
<davexunit>yeah, I'm liking it, too.
<davexunit>you can just call it GSD, like how people say BSD.
<rekado_>"BSD has ports, GSD has Guix."
<davexunit>and there's the tag line
<civodul>sounds good to me
<civodul>and in 30 years, people will refer to *GSD to denote a family of OSes by people who don't go together well
<davexunit>dibs on FreeGSD
<rekado_>YES! I know why the java tests fail: the test harness *replaces* the PATH with "/usr/bin:/bin:/usr/sbin:/sbin", so none of the tools used in the test scripts are found.
<civodul>good catch!
<civodul>i share your enthusiasm
<civodul>(sounds like a Frenchism)
<davexunit>rekado_: good catch!
<rekado_>if only there was a convenient way to reuse and resume a previous build ...
<davexunit>rekado_: I have used 'guix environment' to make it easier to debug such things
<davexunit>you still have run the full build again when you use 'guix build', but you get to debug in a place where you don't have to start over every time.
<davexunit>the --keep-failed flag for 'guix build' works, too, but I've had an easier time using 'guix environment'
<rekado_>I have been using 'guix environment' and '--keep-failed', but I'm repeatedly running into weird problems that I haven't yet tried to analyse/fix.
<davexunit>oh :(
<davexunit>'tar xf $(guix build -S foo) && guix environment foo' worked well for me when debugging issues with guile-sdl.
<rekado_>you'd still have to manually patch the sources, though, right?
<davexunit>hmmm... yeah. you would.
<rekado_>I have a lot of stuff going on in additional phases and it's rather annoying to have to translate all that to bash.
<davexunit>nix-shell has a bit of an upper hand here, because the build recipes are written as bash functions, they can just call the functions that do the patching and such.
<davexunit>rekado_: when you say patch, do you mean apply patch files or do some dynamic patching in build phases?
<davexunit>the former would be taken care of using my method, but the latter wouldn't be.
<civodul>rekado_: i typically use --keep-failed, and then cd /tmp/nix-build* && source environment-variables
<rekado_>davexunit: I meant the latter.
<davexunit>I guess --keep-failed would give you what you need, roughly.
<davexunit>I have problems with sourcing environment-variables because the files are owned by a guix user
<davexunit>so it's a pain to have to chown everything first
<rekado_>same here; I chown them first (which takes quite a long time)
<civodul>ah right, i always "chown -R ludo /tmp/nix-build*" first
<civodul>which is admittedly boring
<iyzsong>+1 for GSD, but I like Guixotic too. so it will be GSD 1.0 (codename Guixotic), great!
<civodul>good, it seems to be unanimously appreciated so far
<taylanub>agree, that's a good choice, if rms approves. no chance of getting misinterpreted as "yet another 'Linux' distro"
<bavier>I like GSD too.
<davexunit>finally some consensus around here :)
<dfh>I like GSD too :)
<serhart>GSD sounds good to me too :D
*DusXMT likes it as well
<DusXMT>It's almost like when we used to call it `The GNU Operating System', except without the `The'
<jxself>Saw it on where Stefano Zacchiroli said "more than 80% of Debian packages can be build-reproduced bit-by-bit"
<jxself>In unstable, I left out.
<civodul>the upstream work done here will be beneficial to everyone
<bavier>how does #:substitutable #f work with dependent packages? E.g. If I want to install python-numpy, does it need to be built locally because atlas (which it depends on) isn't substitutable?
<bavier>I'll ask my question again, now that civodul is here ;): how does #:substitutable #f work with dependent packages? E.g. If I want to install python-numpy, does it need to be built locally because atlas (which it depends on) isn't substitutable?
<civodul>which is arguably surprising
<civodul>it doesn't "propragate"
<bavier>civodul: good to hear
<bavier>I was hoping that would be the case
<DusXMT>Not substituable? Licensing issues?
<bavier>DusXMT: for atlas it's a performance issue
<DusXMT>bavier: it compiles with -march=native?
<bavier>no, it runs a bunch of benchmarks to tune its code for the cpu.
<mark_weaver>civodul: core-updates is fully built on x86_64 and i686. fwiw, I don't think we need to wait for mips before merging. it might or might not be worth waiting to fix some of <>. wdyt?
<mark_weaver>actually, most of those new failures are ultimately due to the ninja failure, which is now fixed in master. (qt build-depends on ninja)
<civodul>mark_weaver: yay!
<civodul>mark_weaver: if "make assert-binaries-available" passes, then we can merge
<mark_weaver>I'm a bit reluctant to merge it myself, since I'm afraid git's auto-merge might not properly adapt some of the recent changes in master to core-updates.
<civodul>yeah i can do it if you want
<mark_weaver>that would be appreciated :)
<mark_weaver>"guix package" just gave me this warning: "find-files: /home/mhw/.guix-profile/xml/: No such file or directory"
<mark_weaver>what's that about?
<mark_weaver>(it was after building a new profile; I had just removed glibc:locales)
<civodul>mark_weaver: it's about the libxml2 search path
<civodul>it probably shouldn't happen though
<mark_weaver>texlive fails to build on ARM. configure fails because it can't successfully link to -lgd. the reason is that libgd depends on libjpeg and fontconfig, and those libraries are not getting linked in to the test program that configure creates. not sure why we're not seeing this on the other platforms.
<civodul>maybe a configure script somewhere determined that it cannot build share libs, and another configure script down the path determined that it cannot use the lib because it's not shared, etc.
<mark_weaver>gd lacks a .pc file. file includes -ljpeg and -lfontconfig in 'dependency_libs', but that's not getting included in the test program link.
<civodul>because the test program doesn't use libtool
<civodul>if exists and has the right NEEDED, there's no problem
<civodul>if it doesn't (there's only libgd.a), then boom
<mark_weaver>how do I see the NEEDED in
<mark_weaver>got it. indeed, does not include those libraries in it's NEEDED
<mark_weaver>at least not on ARM. I see that jpeg and fontconfig _are_ in NEEDED on my i686 build of
<civodul>objdump -x |grep NEED
<mark_weaver>FYI, I'm now running 100% core-updates on my libreboot x60, and I also updated nginx on hydra to run from core-updates.
*bavier really wants to get some hardware to run GSD on...
<mark_weaver>I like GSD too, btw :)
<mark_weaver>civodul: when comparing the build logs of gd on i686 vs armhf, I see this difference in the configure output:
<mark_weaver>-checking how to recognise dependent libraries... pass_all
<mark_weaver>-checking how to recognise dependent libraries... pass_all
<mark_weaver>+checking how to recognise dependent libraries... file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )
<mark_weaver>pass_all is used on i686, and the file_magic thing is used on armhf
<civodul>uh, not sure what that means
<civodul>re merging, we lack bootstrap-tarballs on mips:
<civodul>(just restarted it)
<civodul>i'll check tomorrow morning
*civodul -> zZz
<mark_weaver>sneek: later tell civodul: I cancelled because that was for from a very old evaluation of core-updates. is the one you want, I believe.