<svetlana>OrangeShark: wmaker is not in the list of guix packages, either. <OrangeShark>svetlana: it is called windowmaker on the package list <remo3>I've searched the manual for a while now, but I can't find the answer to this question: why is it that when I run "guix package --list-installed", I only see a tiny number of packages (the ones I've installed after the initial system init)? Where are all the system resources? <sprang>is there a todo/task list for Guix other than the bug database? ***jsgrant` is now known as joshuasgrant
<joshuasgrant>ACTION is attempting to update Racket from 6.1.1 to 6.2, and noticed that there is still no openssl made available to it in the package build, which is needed for "raco pkg" to work. <joshuasgrant>I'm not exactly what would be the best way to make the system see that openssl is installed with it, via the build. It wouldn't be a build input I know. <rekado->joshuasgrant: if it needs openssl it should be added as an input. <joshuasgrant>rekado-: Ah, I'm starting to recall now; Was I mixing up inputs with build-inputs? <joshuasgrant>ACTION needs to spend a fair amount of time over this weekend rereading some of this documentation; It's been a number of months since I've even really touched Guix. :^P <joshuasgrant>I just added (gnu packages tls) to scheme.scm, and trying to do a './pre-inst-env guix build racket' it's popping out the message "WARNING: (gnu packages scheme): `openssl' imported from both (guix licenses) and (gnu packages tls)". I then removed the tls package line and it said it was invalid to use licenses' openssl basically. <joshuasgrant>It's currently building, with that double import. Is that okay ... or? <joshuasgrant>I might just leave it run to build, and go afk for a bit. This is my really low-end laptop, so it's going to take sometime anyways. I just want to make sure this is the actual reason 'raco pkg' isn't working and do it up proper later today or tomorrow on my main rig. <joshuasgrant>Yeah, I'm going to go that route and stop chan-spamming by thinking out loud in here. Thanks rekado- for the help; BBL. o/ <rekado->openssl is both a package and a license. <joshuasgrant>rekado-: You caught right as I was leaving my comp... :^I Is that a prefered option than double importing? <taylanub>joshuasgrant: I think one should never double import. one could say it works incidentally. <taylanub>and more generally, warnings should usually always be resolved <joshuasgrant>rekado-: Oh well that's not exactly pretty then, sharing the same "openssl" name here. <rekado->joshuasgrant: why? You can just prefix the license import with "license:". <rekado->take a look at other package modules. <taylanub>joshuasgrant: change e.g. the (guix license) import to ((guix license) #:prefix l:), then rename all 'foo' license variable references in the file to 'l:foo' <rekado->(which also is a package and a license name) <joshuasgrant>Sorry, I probably shouldn't even be attempting this atm ... burning the midnight oil and all that. <taylanub>IIRC there was some talk of renaming all license variables to 'license-foo' at the place they're exported, so one doesn't frequently need to mess with this, dunno if/when it will be done <joshuasgrant>taylanub: That seems like a pretty good solution actually, if this renaming method is currently used fairly often. But yeah, so long as it currently works I'll be happy either way. :^) <joshuasgrant>I guess one could also do (guix legal) then 'license-whatever, that helps avoid that ugly double line of (license license-whatever) to (legal license-whatever). But that's just uneducated/knowledable sleep-deprived spitballing at this point. <joshuasgrant>Well I'm getting an error, but I'm going to tell it to bugger off for the time being and take a nap or something and finish hopefully finish it off rested. Thanks rekado- & taylanub you were a lot of help! :^) <yenda>I added python2-ansible but there is like 10 other packages I had to add to make it work to I submit it all at once ? <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, daviid says: thanks, din't get that, there was a pending for approval in my own savannah account, my bad. tx <yenda>guix lint says that the package description should start with uppercase or digit. Is it true when it starts with a package name ? "bcrypt password hashing and key derivation" <civodul>yenda: it should be one or more sentences <civodul>so there could be exceptions, but it should be really really rare :-) <jsgrant>Well, I built 6.2 with openssl as an input ... and I've gone from it not finding v2 or v3, to saying "ssl-connect: requested protocol not supported". <jsgrant>Ah, evidently it's just version weird. <jsgrant>Well, I think I'm going to try again at that nap, wake up and just file a patch for updating to 6.2 and work on getting openssl working proper a bit later. o/ <joshuasgrant>People are somehow always able to get me, before I turn monitors off. :^I ***francis7 is now known as gnuuser
***gnuuser is now known as gnuser
***gnuser is now known as francis7
***francis7 is now known as fchmmr
***fchmmr is now known as francis7
<rekado_>I wrote a package importer for CRAN (for R packages). <rekado_>I convert the HTML to SXML and then do ugly sxpath + sxml-match things on it. <rekado_>Now I wonder if it would have been smarter to try to download the package, unpack it, and then parse the DESCRIPTION file instead. <amz3>(I'm wondering how sxpath and sxml-match works...) <rekado_>to get the tarball location, though, I have to parse the HTML anyway, so maybe I should just leave it as it is. <davexunit>rekado_: I think something that works is a lot better than not having it at all. :) <rekado_>amz3: the Guile manual is pretty bad when it comes to sxpath. I actually have a documentation patch that I forgot about ... <davexunit>yeah, the guile manual needs much improvement there. <rekado_>oh, we don't have an r-build-system yet. Need to write this first. <davexunit>this reminds me that I need to write a rubygems.org importer <rekado_>amz3: the best way to learn about sxpath is by reading SXPath-old.scm, which contains a test suite. <rekado_>without examples the inline documentation is pretty hard to understand. <rekado_>I should take some time to polish my patch and write another to improve the docs there. <rekado_>sxml-match is well-documented, though. <davexunit>I keep going back and forth on this, but once again I am unsold on the viability of using .gem archives from rubygems.org <davexunit>I tried to change the ruby-useragent gem to use its offical .gem archive, but it doesn't include a Rakefile so I can't run its test sutie <davexunit>running test suites just doesn't seem to be a thing that the Ruby community encourages non-developers to do. <rekado_>with tarballs published on github we also make a case-by-case decision. Sometimes the tarballs are crap, then we take the repo. <rekado_>gems are like tarballs, in my opinion. <davexunit>I don't feel comfortable having every single Ruby package be sans a test suite <davexunit>ruby devs don't make releases like everyone else does <davexunit>gem archives are convenient, but if they're missing things then what's the point? <amz3>maybe you can provide a patch upstream to add the test suite <davexunit>amz3: yes, but what I need is data that can tell me if this is a widespread problem or not <davexunit>it seems that *no one* besides us wants to do this <davexunit>I'll ask on #ruby, but I expect to be flamed instantly like the last time I went there for help. <amz3>how do people package ruby for debian? <davexunit>amz3: I doubt debian is running test suites in an automated fashion ***bmpvieira_ is now known as bmpvieira
<yenda>I'm digging out a projects with package management hell :D Guix NEEDS to take over the world and take npm/pip/bower and co to the grave ! <yenda>install packages with pip -> missing c libraries <yenda>install c libraries -> reinstall libraries with pip <yenda>web interface fail ? oops need npm to download js libs <yenda>install nodejs for a python web project <davexunit>with the proper guix build systems and package importers in place, it will start becoming realistic to use guix in place of all those language package managers. <civodul>rekado_: congrats on the R importer! ***init is now known as E4xoi
***E4xoi is now known as y
<codemac>Question for packagers here. I've been getting golang packaged in guix - and I'm running into an issue: 'go: error while loading shared libraries: libgcc_s.so.1' during the build stage of the package. Any help on how to set up shared libraries? This is my first package not using gnu-build-system :) <davexunit>codemac: hmm, I don't know what go's build system looks like. so, it's failing during linking? <davexunit>paroneayea, paron_remote: congrats on your award! <codemac>davexunit: it's a totally custom build environment. I've gotten the 'go' binary to get fully built, but when it then goes to run 'go' on later .go files, it fails with not being able to link against libgcc_s.so.1 <davexunit>codemac: you should post the code you save so far to paste.lisp.org <codemac>It's a very shitty pile of crap while I get it working, so I apologize for the bruteness of it. <davexunit>codemac: you're likely missing environment variables. <davexunit>the implementation of the gnu-build-system might give you clues <codemac>I set my LIBRARY_PATh to something I think should work, but I'd really appreciate any tips. Yeah, I've been reading that a bit more this morning :) <codemac>the key is the line that calls "all.bash" that does all the building for go <davexunit>codemac: to better investigate these issues, I like to use 'guix environment' to create a similar build environment to what the guix daemon is using. <davexunit>so I would extract the go source to a directory <davexunit>or maybe just 'guix environment go', but use caution ;) <codemac>I was trying this last night and I wasn't using that <davexunit>basically, I'd try to construct an environment that gets you the go dependencies *and* some debugging tools <davexunit>you can use strace to watch for the 'stat' calls that the build system makes when looking for libgcc <davexunit>I'm afraid I don't have any specific advice to offer you, but working on it from outside of a daemon process will allow you to iterate faster <davexunit>you could add packages like strace and whatever else you want to the package definition temporarily so your purified environment has everything you need <codemac>ahh - it's only looking in glibc's /lib <codemac>my LIBRARY_PATH includes gcc-lib, binutils lib, and glibc's lib, but it's only searching glibc.. <codemac>could that be the ld-linux hack I do? hmm. need to read gnu-build-system more <codemac>yea, LD_LIBRARY_PATH=$LIBRARY_PATH ./go worked <codemac>LD_LIBRARY_PATH being set though means that somehow the right paths aren't being embedded in the go binary? It seems only the glibc one is propagating, but I don't know how ld-linux really works <codemac>yeah - it looks like the 6c/6l/6g compiler suite uses this ld-linux.so with it's elf implementation. Not sure how to embed multiple directories to load from into the go binary itself :/ <phant0mas>cross-building it for the hurd fails with libc evaluating to #f in the configure phase <phant0mas>this damn perl, causing me problems everywhere <codemac>hm i'm really lost on how to embed library paths correctly with golang :/ because the ld-linux-blah in glibc doesn't know about libgcc_s.so, I'm not sure how to fix it without forcing ld_library_path env variables which won't work <codemac>I've been looking at the nix package for inspiration, but I can't figure it out <civodul>codemac: oh you're trying to package Go? <codemac>civodul: trying is the operative word lol <civodul>if you look at gcc.scm for instance, you'll see there are hacks so that it always passes the right -L pointing to libc (for crt*.o) and to its libdir (for libgcc_s) <civodul>phant0mas: you're not building natively? <phant0mas>but I have problems with perl both when cross-building it and natively building it <civodul>phant0mas: but you mentioned "cross-building"? <codemac>it seems that go doesn't embed the rpath you specify during it's build <codemac>or something, it's a bit confusing right now, I haven't fully figured out the bug <civodul>well i can't really help with debugging right now, but it seems you're on the right track :-) <phant0mas>I thought that maybe the problem with failing to cross-built, has some connection with failing to natively build it :-) <phant0mas>but in the native issue, the problem is probably a patch missing <civodul>phant0mas: if you look at commencement.scm, there's perl-boot0, which is built very early on GNU/Linux <civodul>because it's needed to build the first linux-headers <phant0mas>I know, but we don't need it that early on hurd <phant0mas>the hurd guys are using perl 5.20.2, so I will try with that version natively <phant0mas>and the debian patches don't seem related to our problem <civodul>you need to identify why it ends up being built <civodul>how much of commencement.scm builds currently? <civodul>for instance, guix build -e '(@@ (gnu packages commencement) gcc-boot0)' succeeds? <civodul>oh wait, texinfo-boot0 also depends on perl-boot0 <phant0mas>I have identified what causes perl to be built