<codemac>question about package version resolution. There is a package 'blah-0.8' and then I made my own personal package called 'blah-0.8.git'. <codemac>the version resolver always pickes 0.8.git, even when I specify `guix package -i blah-0.8` <codemac>is there any way to be more exact in picking my versions with guix package? <lfam>Does anyone have advice about strace-ing a guix build process? Or some other type of tracing? Simple running `guix build` doesn't show much since it is just talking to the daemon. <lfam>I'm trying to figure out where one program is looking for another <python476>alright, archlinux AUR has guix, I'll learn it within arch, that will ease the transition <python476>for a reason guix package -i guile fetches linux-libre, I guess one needs his headers <lfam>python476: Also, if that was the first Guix package you installed, you also pulled in the whole build system that you will need for Guix. <xd1le>lfam: yeah i think python476 used the aur package (instead of doing the <xd1le>binary installation) which iirc builds guix <lfam>When I add python-pbr as a native-input to my package, the stack overfloweth <lfam>Ah, pbr and mock depend on each other. <marusich>I'm having trouble using geiser to find the place where certain procedures (or anything, really) are defined. For example, in $guix_git_repository_root/gnu/packages.scm, it seems that a procedure named "define-record-type*" is used to, I imagine, define records; however, I cannot for the life of me convince geiser to tell me where that is defined. How do I do that? <rekado>lfam: you can attach strace to the pid of the daemon with "-p"; as it forks you should also use "-f". <efraim>after running for 5:45, gccgo-5 failed at validate-runpath :( <efraim>cgo, go and gofmt tried to find libgo.so.7 in glibc-2.22/lib instead of gccgo-5.2.0/lib <efraim>I'll see about fixing that later and try building again tonight <rekado>you need to create an account and then click on "create event" to submit a talk proposal. <rekado>make sure to select "GNU Guile devroom" from the list of tracks. <rekado>the latest version of guitarix now requires webkit :( <lfam>From guitarix-developer: You need now webkit-1.0 to build guitarix. It's needed for the online preset browser. <lfam>Couldn't they just let you use a regular web browser? <rekado>it's possible to disable this but only if you choose not to build the standalone version. <lfam>I know about (package-with-python2). I'm curious about what setting (#:python ,python-2) does. Does that only affect the python interpreter, or does it also change everything like (package-with-python2)? <rekado>lfam: it makes the build system use python-2. <rekado>for waf-build-system that's sometimes needed because the wscript is written with python2 syntax. <lfam>@ build-succeeded /gnu/store/fbvkj6pafgasl7g97qnxiv0hzy5flgkk-lets-encrypt-0.0.0.dev20151108.drv <xd1le>just saw your gnunet talk, pretty nice! <xd1le>civodul: question, can the manifest file specify versions? <xd1le>and can it for example automatically generated from the current profile? <civodul>the manifest refers to variables, so 'gcc' is just a normal variable <civodul>so if it refers to variables defined in Guix itself, as in this example, it's not specifying version <civodul>you would need to also specify the Guix commit being used if you wanted to be precised <xd1le>because you know that person at the end who asked about sending his <xd1le>wouldn't it a different environment if they used the manifest file, but <xd1le>with a different guix commit to the one he used? <xd1le>as in terms of system reproducibility <xd1le>so i think the solution would be to also have all the recipes of the <rekado>...and a short way to get the recipes of the packages is to fetch the git repo and check it out at the specified commit. <rekado>there are different degrees of reproducibility. <rekado>to me a manifest is only a convenient way to specify a lot of packages in one go. <xd1le>rekado: yes make sense, thanks. <xd1le>i was also thinking about keeping it in a dotfiles repo to reproduce the <xd1le>so it's easy because can just track a specific guix commit to reproduce <xd1le>everything (or at least to the reproducibilty level that guix provides) ***ttuegel_ is now known as ttuegel
<rekado>karhunguixi|w: I don't think so. <fps>ubuntu has a nonfree unrar, maybe you can patchelf it <fps>oops, mybad. ignore that.. <rekado>there has been a free project to decompress rar files, but IIRC it's for much older versions of the format. <fps>btw: orthogonal question [not related to free/nonfree] <fps>let's say i download a binary deb and all of its dependencies.. <fps>for quite a few of them it should be possible to make them work bending rpaths around with patchelf, no? <fps>and that process might even be automated somewhat.. <mark_weaver>fps: please stop promoting non-free software on this channel <mark_weaver>and the last question is not orthogonal. why would you need to use a binary package if it's free software? use the source. <fps>'cause it might be easier than building from source.. but it was just a thought. <mark_weaver>bah, that's giving up. we are dedicated to building things from source code whenever possible. <davexunit>ah, a docker conversation to start my morning. :) <civodul>xd1le: another thing that can be done is to export the bits of the profile (sledgehammer approach) <davexunit>civodul's latest talk gives some good insight into why docker is ultimately unsatisfying. <mark_weaver>that was in response to a question about the feasibility of importing .deb binary packages directly and using patchelf to fix them up, supposedly because "it might be easier than building from source". <mark_weaver>(although I suspect his real motivation was to import non-free software) <davexunit>ah, yes, well we certainly wouldn't do that. <davexunit>now, taking a deb *source* package and attempting to generate a guix package expression based on it... that might bear some fruit. <fps>i agree that that would be even better :) and in some cases simpler and in others harder.. <fps>oh, here's another take on the issue that might even bare more fruit and would improve packaging adoption: scheme is the simpler language to process <fps>how about making a scm -> source deb compiler <fps>then people might package for guix instead and debs would fall out <fps>and also compile to AUR and rpm. <fps>though that kind of smells like the xkcd about competing standards <rekado>I cannot see either side would be interested in this. <rekado>arch people prefer their PKGBUILD files, RPM people already have their spec files (with macros upon macros) and the tools to build their RPMs; Guix package variables are not very useful if they are just used to refer to dependencies by name. <davexunit>people ask us frequently "why don't you just use the packages from debian, npm, rubygems, etc.?" <rekado>Guix package variables are powerful because they don't just *name* dependencies. <rekado>inputs are actual package values. <rekado>so you end up with a complete graph. <civodul>mark_weaver: i wonder if we should apply security fixes to the version-0.9.0 branch <civodul>it seems like it wouldn't cost much to do so <mark_weaver>civodul: several of the other updates I've done recently have been for security updates as well. <mark_weaver>whereas on a stable branch like that, it would be better to apply minimal patches to the existing version. <mark_weaver>but I agree that it would be good to have a stable branch <mark_weaver>speaking of security updates, the mit-krb5 security updates are taking longer to build out than I expected. "guix refresh -l mit-krb5" estimated 179 dependent packages, but then it required over 2300 rebuilds. <civodul>mark_weaver: yes, i was thinking of the wpa_supplicant patch specifically, which is "minimal" in this sense <civodul>well, we definitely need to think about it <mark_weaver>anyway, if you'd like to cherry-pick some of these for the 0.9.0 branch, feel free! <mark_weaver>one thing: IMO, we shouldn't maintain a stable branch unless we take on the responsibility of making sure that all important security updates are backported to it. <civodul>maybe i'm underestimating what it would take <civodul>because as you say, sometimes it's more than just cherry-picking commits <mark_weaver>right now, I only look at the master branch, and if the version there is new enough to not need an update, I consider it "done". <civodul>like if we want to fix Git without upgrading it <mark_weaver>I'm a bit overloaded at the moment. I don't think I can afford to take on more responsibility with security updates right now. <mark_weaver>but I agree that a stable branch would be good to have <davexunit>I think we need to formalize a process and have more than just poor Mark handling security updates. <davexunit>it would be nice to somehow have a queue of known security issues or something <xd1le>civodul: sorry, i need to fix my notification system (for irc). what do you <xd1le>mean by exporting parts of the profile? <civodul>xd1le: i mean "guix archive --export $(readlink -f ~/.guix-profile)" <civodul>that produces a (big) archive containing the actual bits of the profile <mark_weaver>I often think that texlive-texmf should be non-substitutable. <xd1le>civodul: ah yes i thought that's what you meant. yes that seems rather <xd1le>uglier compared to a simple manifest file, but possibly more accurate in its reproducibility <mark_weaver>I live within a 20-minute bike ride to hydra.gnu.org, and yet it takes me *much* longer to download texlive-texmf from hydra than to build it myself, consistently. <mark_weaver>although I guess that many armhf systems won't be able to build it locally... hmm <civodul>mark_weaver: you could go there by bike and copy it on a USB key: higher latency, but higher bandwidth :-) <civodul>seriously though, i admit it's a problem <mark_weaver>fps: I suggesting using the output of "git describe" <mark_weaver>there was a discussion on guix-devel recently about how best to do this, and this approach was agreed on, as I recall. <fps>mark_weaver: thanks for the tip. will check the ML <rekado>doesn't git describe only work with tags? <rekado>for those projects where there are no tags we agreed to use version + revision int + commit <fps>well, there's basically just a commit revision <rekado>e.g. 1.0.1.1.cafebabe for version 1.0.1 with Guix package revision 1 and hash "cafebabe" <mark_weaver>fps: okay, then you better put the date first in YYYY-MM-DD format, so that versions sort properly. <mark_weaver>as long as the versions sort properly, that's the important thing. <fps>interesting: the packaging itself is not versioned. and isn't that a problem? <fps>or rather: only implicitly by the version of guix itself.. hmm <mark_weaver>fps: if there are no version numbers at all in the upstream project, then I guess you'd better use the date followed by the git commit hash <mark_weaver>where the date has FULL-YEAR before month before date. <fps>mark_weaver: ok, yeah. YYYY-MM-DD, like you mentioned <civodul>davexunit: BTW, people really liked --container when i demoed it :-) <civodul>security people want a POLA shell or something like that now <fps>is hydra slower than usual? ;) <taylan>getting timeouts on the website, yeah <mark_weaver>yes, but it's not that unusual. hydra is overloaded, and in need of a replacement <taylan>are the donation links and such up yet by the way? <fps>ok, a more productive question: i'm on guixsd and wanted to add the package to gnu/packages/audio.scm. so i cloned the guix repo, hacked the file, and used guix package -L /path/to/guix/clone -i swh-plugins-lv2 <fps>but that didn't work. do i have to build the guix checkout? <fps>ah right, i suppose so, so i can use pre-inst-env <taylan>fps: you want to use ./pre-inst-env, yeah <mark_weaver>fps: no, do this instead: ./pre-inst-env guix build -K swh-plugins-lv2 <taylan>./pre-inst-env guix build [-K] the-package <fps>rihght, and i asked that befor. i need to use guix environment guix to get an environment to build guix :) <fps>oops, not -K, it was -L ;) <taylan>well you can satisfy the dependencies manually; they aren't so many <davexunit>if you have guix already setup, then 'guix environment guix' is the easiest way <taylan>'guix build -K' *k*eeps failed builds in /tmp <taylan>fps: if you don't have any existing guix installation, you can 1. satisfy the deps manually on your system, or 2. install guix via the binary tarballs <taylan>fps: the README lists the dependencies <fps>taylan: i'm on guixsd :) <taylan>well then you're set for using 'guix environment', no? <fps>taylan: right, i was confused about having -K in my own message, since my reading skills suck.. my bad <rekado>I'm having trouble supporting R users who use Guix R on CentOS. <rekado>we have only very few R packages, so users want to install them with install.packages() in R. <rekado>but there are also those that provide bindings to libraries, e.g. the xml2 package. <rekado>when I do install.packages("xml2") in R, the system GCC is used to build the package. <rekado>at the end R tries to load the built library but fails. <rekado>the very same library can be loaded with the system R. <rekado>is it enough to swap out the compiler toolchain (e.g. by installing gcc-toolchain), or will there be other issues? <rekado>AFAIU I need to ensure that the linker links against the Guix glibc instead of the system libc. <rekado>is it okay if the stuff users build links against system libraries at all? <rekado>or would I need to ensure that users have all dependencies in their Guix profile and not the system libs at all? <rekado>(I don't mind if things break after an update in this case; my goal is to make sure that Guix R can actually be used.) <mark_weaver>rekado: if you use gcc-toolchain, then it will ensure that guix libc is used. <mark_weaver>rekado: especially since civodul is not here, maybe best to ask on the ML? <mark_weaver>I think probably the right answer is to package a lot of R packages, and if possible, make a "guix import" command for R packages <rekado>we have a guix import command for R stuff (the CRAN importer) <rekado>but unfortunately lots of users also get R packages from bioconductor. <rekado>I'm planning to write an importer for bioconductor as well. <mark_weaver>I would say that "install.packages" should be rigged to automatically operate in an environment where 'gcc-toolchain' is available (with PATH, CPATH, and LIBRARY_PATH set appropriately), but it occurs to me that in general, you'll also need other packages available, e.g. libxml2 in this case? so I don't know a good answer other than to package things up. <rekado>one obvious solution is for users to install the dependencies they need (e.g. libxml2) into their guix profile, in addition to the compilers, and only then run install.packages(). <rekado>it's almost simpler to just package the R packages directly. <rekado>we still have some problems with our GCC variants. One issue is that gcc-toolchain gives us GCC 5.x, but gfortran is only at 4.9.3. Another is that installing gfortran along with gcc-toolchain results in uncountable conflicts of header files. <rekado>that's what prevented me from fixing the issue for our users yesterday. <rekado>can we link all gcc variants somehow? It makes sense to keep them all at the same version. <efraim>right now all the different compilers are built separately <mark_weaver>hmm, we should just add (define-public gfortran-5 (custom-gcc gcc-5 "gfortran" '("fortran"))) to gcc.scc <mark_weaver>I think that's the only problem.. assuming it builds... <efraim>speaking of which, gccgo-5 failed at the checking-links stage for me this morning <efraim>/gnu/store/za0b1cw7i7sr5mipjqj5w5g4rj2yyasw-gccgo-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cgo: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib") <efraim>validating RUNPATH of 11 binaries in "/gnu/store/za0b1cw7i7sr5mipjqj5w5g4rj2yyasw-gccgo-5.2.0/bin"... <efraim>/gnu/store/za0b1cw7i7sr5mipjqj5w5g4rj2yyasw-gccgo-5.2.0/bin/go: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib") <efraim>/gnu/store/za0b1cw7i7sr5mipjqj5w5g4rj2yyasw-gccgo-5.2.0/bin/gofmt: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib") <rekado>efraim: where is libgo.so* in the output? <rekado>that directory needs to be in the RUNPATH. <rekado>you might have to add to LDFLAGS something like this: (string-append "-Wl,-rpath=" out "/lib") <rekado>efraim: also look at the patches like gcc-libvtv-runpath.patch <mark_weaver>I don't know how best to do that for gccgo though. the gcc build system is more complex than most. <rekado>all these gcc-*-runpath patches add the libdir to the RUNPATH. <efraim>I started with just copying gccgo-4.9(?) and redifining the gcc input use gcc5 with bininputs as an added input <efraim>the real problem was the build took almost 6 hours <efraim>so I think I can say my machine is about as powerful as the mips64el hydra build machine :) ***fchmmr is now known as francis7
<fps>hmm, i ran guix gc as user and as root. but still i have some xfce files in my store.. <fps>i once had xfce4-terminal installed, but not any more <mark_weaver>fps: you probably need to remove the old profiles where you had xfce4-terminal installed. <fps>mark_weaver: oh, old generations of the system config? <mark_weaver>old generations of both the system config and your user profiles. <mark_weaver>deleting old system profiles currently requires removing symlinks from /var/guix/profiles <mark_weaver>and then doing another "guix system reconfigure" so that the old profiles will be removed from your grub.cfg, and then another 'guix gc'. <fps>i can basically rm /var/guix/profiles/system-* if i want to get rid of them all except for the curret one? <fps>note the "-" :) not deleting all of them :) <mark_weaver>(i.e. the one that /var/guix/profiles/system points to) <fps>mark_weaver: oh i thought "system" without suffix was the most recent one.. <fps>oh that links to -17 <fps>may i ask for the reason for the double chaining? i.e. why doesn't system point to that place in the store directly? <mark_weaver>more information is preserved. the currently-selected generation is immediately apparent. <fps>ok, makes sense. ty again <rekado>matplotlib makes me sad. propagated-inputs makes me sadder. <bavier>andreoss: it can take some time, depending on which checkers you're running <roelj>How can I evaluate a Guix expression in directly in Emacs (with Geiser)? <andreoss>i guess you need to type REPL something like (use-modules (gnu packages)) <roelj>What if 'use-modules' is undefined? <roelj>Right. I do have a problem then: Symbol's definition is void: use-modules <mark_weaver>there is no such thing as a "guix expression". it's just guile code, but you need to have the needed modules imported to get access to the usual macros and so on. <roelj>Oh I'm dumb. I C-x C-e'd it instead of typing it in the REPL directly. <andreoss>roelj: C-x C-e should be redefined in geiser-mode <roelj>Yes, somehow I had to explicitly run 'M-x geiser-mode' in the buffer. Even after 'M-x run-geiser'. <andreoss>you probably want paredit-mode and eldoc-mode also <roelj>Thanks, I will look into these. <roelj>Now I get: no code for module (gnu packages). I guess I'm missing a path in my load-path. <fps>if so, just do M-x guix-edit some_package <fps>then switch to the *Guix REPL buffer <roelj>Thanks though, this is another reason to switch to GuixSD once I packaged all things I need. <roelj>Somewhere I've got a syntax error, but I can't find out where because I can't see it, and I'd like to get some more information than the line containing '(package'. <fps>roelj: do you have the error message handy? <mark_weaver>the 'package' macro is exported by the (guix packages) module. <andreoss>would be really nice if someone shared the proper .emacs.d for guix hacking <mark_weaver>if you haven't imported that module, you can't use that macro successfully <fps>the indentation in my emacs still sucks even on guixsd <fps>M-x untabify gets old and it looks weird.. <mark_weaver>roelj: so just add the absolute path to the top-level git source directory to the front of %load-path and %load-compiled-path variables <mark_weaver>(set! %load-path (cons "/path/to/guix-git-checkout" %load-path)) <mark_weaver>and then you should be able to import those modules. <fps>roelj: it's nice enough to tell you that it's the "source" expression if i read that right.. one moemnet. installing emacs in nix, to check out the indentation <fps>which tells you a lot about where you gone wrong <fps>instead of counting brackets manually <roelj>fps: Thanks a lot. How did you know it was in (source ...) ? <fps>gnu/packages/fonts.scm:39:2: source expression <fps>beginnign of your error message <roelj>I was put off by line 39, which really is the line containing ' (package' <fps>you missed one bracket :) <fps>is there an emacs command to "unfold" lisp code? <fps>so every list starts indented on a new line with the opening bracket and the first element? <fps>and the corresponding closing bracket alone on the corresponding indentation level? <mark_weaver>I'm not aware of anything that does that. maybe you're looking for a pretty-printer <fps>then the tree structure is readily apparent <fps>mark_weaver: possibly.. <mark_weaver>putting closing brackets on lines by themselves is widely frowned upon in the lisp community. <fps>and they are wrong :) <fps>that was tongue in cheek though. can't argue about taste <fps>at least productively <davexunit>it's not an objective thing, but the C-style brace thing is not what lispers do <fps>maybe i underestimate pretty-printers though and they would make the tree structure apparent enough as well <mark_weaver>I don't think close parens on their own lines are the least bit helpful in seeing the tree structure. if the code is indented properly (which can be done by an auto-indenter or pretty-printer), then you can see where a block ends easily based on the indentation. <mark_weaver>I can understand why some people like to see the open paren and close paren lined up with each other in the same column, but that's just an aesthetic preference. <mark_weaver>if you the close paren that would have been alone is at the end of the previous line instead, then you just look for the first line that's indented less than the opening. <davexunit>The reproducible-builds.org twitter account shared civodul's "reproducible builds: a means to an end" post. <mark_weaver>and there are far fewer useless lines, leading to more compact code. <roelj>I installed a new font package in Guix. Now, how can I set the font in Emacs to a font installed by that package? (Emacs cannot find the font). <mark_weaver>roelj: you might need to run "fc-cache -f", and you might need to restart emacs, dunno. <roelj>So, after restarting Emacs, it should be able to find the font automatically? <roelj>That worked for Inconsolata btw. <mark_weaver>yeah, my knowledge of font handling is quite weak as well <fps>wow, for some reason the guix installer likes to crash in a kvm using libvirt.. hmm <fps>i.e. guix system init myconfig /mnt likes to freeze the whole vm <fps>maybe vnc is just not updating, but the vm uses 100% cpu <fps>let's sit it out for a while.. <fps>nah, it sits there busy looping on something.. weird. <fps>let's disable the sound device.. <fps>probably a qemu/libvirt problem.. hmm <fps>hmm, doesn't happen with ubuntu guests though.. <fps>let's try the e1000 pci adapter instead of virtio :) <rekado>with paredit and parenthesis highlighting and the sexp-* movement commands in Emacs I never felt the need to break up clusters of parentheses. <davexunit>what's funny about this game (and other games by the same author) is that it uses XML as a scripting language for describing bullet patterns <fps>um, that's an odd choice :) <civodul><define><identifier>fibo</identifier><parameters><parameter><identifier>n</identifier></parameter></parameters>… <davexunit>totally bonkers, but reading the xml files has been an inspiration for doing something similar but which Scheme <fps>i have a feature request :) <fps>can you make the grub timeout on the installer cds much longer? <fps>actually, no, ignore that. that's not helping me. i suck <civodul>i imagine you could write a couple Scheme macros to do that <davexunit>I've done something along these lines before <davexunit>some effort needed for doing things in a purely functional way. <civodul>ACTION looks for a volunteer for bugs.gnu.org/21879 :-) <bavier>I do on occasion, but not on top of debian <civodul>do you know if it embed libpython, or if it invokes ‘python’? <bavier>the traceback looks like it's loading system python modules, which is perhaps not intended <civodul>but then i wonder if it just did an execlp("python") and ended up running /usr/bin/python <civodul>or if it’s actually linked against libpython and just gets the wrong .py files <detrout>why does guix package -i <pypi python package I tried added> end up trying to reinstall things like linux & coreutils? <detrout>running on debian from guix src directory <remi`bd>is it the first package you install with Guix? <detrout>though that was before updating from 0.8.3 to 0.9.0 <detrout>i may not have installed something since having done the git pull <detrout>does guix package look at the timestamps in the guix source tree? <efraim>civodul: depending on time, i can try to look at weechat on debian tomorrow <detrout>oh i packaged guile-json for debian and its currently sitting in NEW waiting for approval by debian ftp-master <remi`bd>detrout: each package in Guix uses specific versions of each of its dependencies <detrout>i'm not sure why make seemed to want it. Also guile-json hasn't changed since 2013 <remi`bd>if your pypy module directly or indirectly depends on a specific version of coreutils, this specific coreutils must be built <efraim>remi`bd: for the initial building from git <efraim>from a git checkout for hacking on it <efraim>for adding/updating packages, working on the system, etc. its easiest with a git clone of the repo <efraim>and part of building from the git repo, it wants you to have guile-json <efraim>anyway, I have to go to bed now, midnight here <efraim>and its time for another 6 hour build of gccgo-5 <detrout>remi`bd: if you were mentioning my question, my first pass django package just dependend on setuptools. Which has no further dependencies. <detrout>though that's wrong and i need to go list more dependencies. <detrout>Is there a way to specify a required version? E.g. foo might require django >= 1.8, django < 1.9 <remi`bd>you can specify for an input which derivation you want <detrout>so you can request a specific version, but not a range? <remi`bd>it’s more than a specific version, it’s a specific build <remi`bd>but I imagine it’s not what you want <detrout>that'd be especially bad for the django example i used <detrout>you want to easily get the point updates, but have a way of stopping and checking before upgrading to the next significant release <detrout>(And they're pretty good about keeping API compatibility within a particular major release. (e.g. 1.8.x) 