<ozzloy>where is guix's ... derivation file? the scheme source code defining how guix is built? i have guix.git and the guix.git/guix.scm doesn't look like it <ozzloy>is there a build-system that includes "autoreconf -i" first? i'm building skribilo from git which seems to require it <mark_weaver>no, you always need to add that as a separate phase. there are many examples in gnu/packages/*.scm, if you search for autoreconf <ng0>hm.. which make clean is needed to remove the .po files? <ng0>those are keeping me from rebasing regulary <ng0>I haven't figured out how to resolve the conflict (unstagged files) with rebase which happens when you have the .po files from the make in the git checkout. <efraim>i don't think that's happened to me before <ng0>created a branch, worked on a file, did the my.guixbuildworld() { make clean-recursive ; ./bootstrap; ./configure --localstatedir=/var/lib ; make }, try to switch to a new branch or anything afterwards. ... first time this happened to me <ng0>forgot that i added and commited <rekado_>wingo: I noticed the same. Especially when there are a lot of libraries that are to be loaded, the searching can take a long time. <efraim>ng0: I only run make-clean when make fails, so maybe 2-3 times a month <ng0>i forgot this directory had actually unstagged changes <ng0>some more minutes and I have an example :) <ng0>perl-curses is a bit special btw... I need to figure out what gentoo does what I don't do yet, because their package succeeds while mine doesn't even when I set all the environment variables. <ng0>but as psycion needs a fix to work again this has lower priority. <ng0>i guess that's more of a git problem than a guix problem and theoretically - I did not pay attention - might've started with a version upgrade of git. <ng0>would like to resolve this before I start hacking on services and distribution etc.. but I have an appointment soon. <ng0>maybe this is really git related and an internet search helps me <ng0>well i can stash and stash drop.. but that's not a fix to a weird glitch. <ng0>maybe even git clean -df <ng0>and git stash; git stash drop sounds works, but I'd like to avoid having unstagged files without doing anything at all. <ng0>I think I'll just add "git diff | git apply --reverse" to my worldbuild function. <wingo>rekado_: interestingly it is O(n^2) <wingo>because linking to each library adds a path to the list <wingo>and at runtime each dynamically linked library searches through that list (the rpath) until it finds the library <rekado_>ng0: you probably don't need the po changes, so if they are in the way you can stash them and drop the stash or reset the po directory <rekado_>looking at the output of "guix size /gnu/store/....-r-3.3.0" I see a lot of duplicates with different hashes. <rekado_>two variants of guile-2.0.11, two versions of libgcrypt, two variants of the same xz version, more than one bzip2, readline, ncurses, libunistring, gmp (3 variants), pkg-config, and many more. <rekado_>guix graph doesn't show me these variants. Where do they come from? <rekado_>(would be nice to have a "guix graph" for store items) <civodul>rekado_: the two Guile variants drag in two libunistrings, readlines, ncurses, etc. <civodul>i've noticed that on a few occasions <civodul>the variants are (@@ (gnu packages commencement) guile-final) and (@ (gnu packages guile) guile-2.0) <civodul>and it sucks that we sometimes end up with these two <civodul>'guix graph -t references r' would show you all that ***foobarry_ is now known as foobarry
<thomasd>Can someone comment on a package I've made, or should I just send a patch to guix-devel rightaway? <thomasd>thing is, the only up-to-date version of the library (GCTP) that I could find, is contained in the source of another library. <thomasd>So my package downloads the bigger library (HDF-EOS5), and surgically removes everything but the contained GCTP... <civodul>so GCTP is no longer maintained separately? <civodul>just leave a comment in the code to explain the situation, and that'll be fine <ehiggs>has anyone had any joy running guix on osx ? <civodul>ehiggs: Guix only runs on systems that glibc supports <thomasd>civodul: yes, seems like it (or lacking server maintenance at NASA and USGS) <efraim>"The NSS test suite takes over 28 hours on Loongson 3A (MIPS)" <ng0>i realize that i don't them, it was just imn the way <ifur>civodul: hi, got a reply from the lhapdf people, apparantly they are doing it this way now because all of the pdfsets would be in the GB range :) <ifur>civodul: basically what is needed is an importer for lhapdf pdfsets <ifur>this is of tremendous importance to high energy physics and theoretical physicists in phenomenology <ifur>could someone do this? because atm an importer is a bit above my skill level as i've barely been coding for a week :S ***pksadiq` is now known as pksadiq
<thomasd>is there a clean alternative to 'export LD_LIBRARY_PATH=~/.guix_profile/lib:"$LD_LIBRARY_PATH"?' ? <thomasd>(to guarantee that libs from my guix profile are found at runtime) <iyzsong>thomasd: that's dangerous, what need it? <thomasd>say I'm compiling code that links -lfoo, where libfoo is in my guix profile, how do make sure libfoo si found at runtime? <thomasd>other than adding Wl,-rpath=$HOME/.guix-profile/lib <jlicht>thomasd: guix environment should have a flag that takes care of 'hiding' your host libraries, no? <iyzsong>dunno. 'guix environment' is my first choice. And since pkg-config reports full '-L' paths for most libraries, I don't need to add the RPATH myself. <ng0>I want to write git-daemon service. Now the current choice of files, networking.scm is the only one which comes close. I know I can go ahead and create a new file, but as it is a networking connected daemon for giving access to repositories it would make sense.. otoh, we don't have many vcs daemons yet, so creating vcs.scm makes more sense. <iyzsong>maybe 'version-control.scm'? same as in the gnu/packages. <mark_weaver>thomasd: use the 'gcc-toolchain' package, which includes 'gcc', 'glibc', 'binutils', and crucially something called 'ld-wrapper'. <mark_weaver>thomasd: ld-wrapper arranges to automatically add rpaths to the linker command lines, so that the built executables can find their shared libraries <mark_weaver>thomasd: so, I recommend removing 'gcc', 'glibc', and 'binutils' from your profile, and adding 'gcc-toolchain' in its place. <mark_weaver>you should not need LD_LIBRARY_PATH, and it would be good to avoid using it <thomasd>mark_weaver: that did it... I missed that memo <ng0>there's a probability that the last message to help-guix can be solved by adding toolchain to the profile. All just work in progress :) <ng0>what is ^L in the files and why is simply typing ^L not equal to it? <ng0>for example in networking.scm <ng0>additionally, is it needed, and how do i enter this? <ng0>some kind of control sequence or limiter? <Tsutsukakushi><kmicu> Tsutsukakushi: I told ya so… security is not a priority here. Fell free to try to improve security in Nix world, but you are better off with Guix. They even don’t trust compilers w/o bootstrapping from the source option :) <jlicht>ng0: I always thought it was some kind of page break character <pksadiq>ng0: In Emacs elisp, it is used to devide code page by page. Use C-q C-l to insert ^L <rekado_>most references are retained in "R_HOME/bin/libtool", which is used by R CMD LINK. <ng0>thanks all :) I try to see that I get my first service done <rekado_>I'm not sure if R really needs the values defined therein for compilation of R packages. <rekado_>(i.e. when users run "install.packages()" or similar) <ng0>ifur: maybe mention it to the guix-devel list, in case it does not get picked up here? <civodul>ifur: as a volunteer i would not offer to spend my evenings on it <civodul>maybe we should set up Guix consultancy or something ;-) <civodul>that said, you could indeed email guix-devel or help-guix, if you want to get some feedback <ng0>maybe it's also a good thing to start learning more guile.. i learn while I work towards something I can not yet achieve but want to achieve :) <civodul>rekado_: it's unlikely that R requires Texinfo and Binutils at run time <civodul>i would simply "grep -r texinfo $(guix build r)" to see where they come from <rekado_>civodul: R keeps a reference to Texinfo for tex2dvi. <rekado_>most of these references are kept in R_HOME/etc/Renviron and R_HOME/bin/libtool. <rekado_>I don't know when it is needed. I've never used R CMD LINK myself. <rekado_>but that's why we have references to ld-wrapper, for example <rekado_>because R comes with features to link binaries to the same libs it is linked to <civodul>another option would be to use late bindings for these things, i.e., to have R search for them in $PATH <civodul>but maybe that would create other complications <rekado_>yeah, that's what I'm worried about. <rekado_>I wouldn't like to break "install.packages" more than it already is. <rekado_>I'll try setting up a profile with GCC, gfortran, and a couple of libs to see if I can use "install.packages"; then remove some of the references and see if it still works. <rekado_>600+MB for R is a little too big for my taste and I'd very much like to cull references <civodul>it's big, but OTOH, if these features are commonly used, there's not much we can do <ng0>the longer I read the sources, the more logical it gets.. it's like reading a well written book :) <ng0>there's no syslog service yet, right? <ng0>there is. thanks for asking questions before greping :) <rekado_>speaking of references: I see that we haven't yet cleaned up the references retained by Perl in lib/perl5/5.22.1/x86_64-linux/Config_heavy.pl <ng0>I can only test service in setting up a VM which uses them, or how does everyone test them? <ng0>*which uses this branch <janneke>how do you all feel about logrotate? <civodul>we have GNU Rottlog, but it's somewhat GNU bitrot currently <janneke>ACTION has only been on GuixSD now for 2weeks now <civodul>i'm not managing, and this is problematic <janneke>this download-tarball-by-hash thing is really amazing <civodul>ng0: in your help-guix message, i don't see a description of the locale problem mentioned in the subject <ng0>I'm trying if gettin gcc-toolchain into profile fixes it <ng0>the problem is that locale does not get picked up, all applications fall back to C or something very incompatible with my system <ng0>while the locales for guix are installed and exported <ng0>i think the description is more or less the paste of the started weechat.. it's hard to describe <joshuaBPMan_>Hello, I've written a blog post about my attempt at dual booting with guix. Since I really don't understand guix, I couldn't really get it to work. But ya'll might like reading the blog. <adfeno>joshuaBPMan_: GuixSD image isn't a CD image??? <adfeno>Strange... I always thought it was. <civodul>joshuaBPMan_: thanks for your feedback; there are "known limitations" about dual-booting with GuixSD <civodul>i think this is your main grief, no? <civodul>i'm tring to find bug reports in the rant :-) <civodul>also, the post says "Guix" when it's really talking about "GuixSD", which can be confusing <adfeno>The blog post is really interesting in regards to what we must yet work out to fix in GuixSD... Thanks, joshuaBPMan_ :D <efraim>guix vs guixsd, the two do blend together <adfeno>Yes, but Guix is a package maanger. <civodul>right, and it has known of the problems mentioned in the post <adfeno>GuixSD is the system distribution specially designed to work with that package manage. <ng0>wtf... i really need to fix this openrc service <ng0>guix-daemon crashed / hicked up / wahever and now it was using a local git checkout i was in as --substitute <rekado_>joshuaBPMan_: someone else previously reported the problem with the mouse axis on Apple hardware. <rekado_>I think you may have gotten some help here to sort this out if you had asked here. <rekado_>It also seems to me that a lot of the problems you mention in your blog post are unrelated to "the horror of Guix". <rekado_>like deleting GRUB, shrinking the partition but not the file system, sitting through an installation of Arch just to get GRUB back, not switching to dvorak (which works just fine in GuixSD), ... <adfeno>I have read somewhere that you can tell GuixSD not to install it's copy of GRUB... Although I don't know how to do it in practice when installing GuixSD. <ng0>shouldn't --substitute be one of the default substitute servers? <adfeno>Yeah... Everytime you make new partitions, watch out for changes in their UUID, positioning in the disk device, and position in the way in which all the system distributions recognize them. I have faced this issue with other distros too, not just GuixSD. <ng0>with the last host system update it defaulted to some dir /gnu/store/ <adfeno>(Actually... What am I saying just now??? I haven't even installed GuixSD yet... I'm planning to) :D <ng0>recommendation to use our guix on gentoo package from the overlay: 10/10 if you like frustrating weird things. <kensington>wingo: i was wondering if you might have any idea how to debug loginctl lock-session (if that is even known to work, i am not using guix to test that) <civodul>kensington: "loginctl lock-session" says "Failed to issue method call: Access denied" on GuixSD, so it may well be broken here as well <kensington>civodul: i was able to solve that one - it needed a newer org.freedesktop.login1.conf from systemd upstream <kensington>so i apparently have permission now, but then, nothing <civodul>kensington: interesting; could you open an issue in the elogind repo with info about that .conf file? <ng0>ACTION ditches gentoo as soon as libgcrypt-1.7.1 is merged. <ng0>>.< no fun to debug your daily system <ng0>the one who rages on about gentoo? <kensington>actually i see a few familiar gentoo names here, maybe it's a sign to try guix :-) <ng0>ah... i did not recognize your name at first. <ng0>ther server still runs musl-hardened though <ng0>just awful to debug my guix on gentoo as i am very bad with openrc. <optikalmouse>I'm stuck on a step, I'm trying to set up GUIX within a cloud9 ide <sneek>optikalmouse, you have 1 message. <sneek>optikalmouse, jlicht says: You are correct in assuming that an npm package that is simply copied over could also just be installed from tar.gz. The general problem is that these sources often include and make use of generated and/or minified files, and as such are not the preferred source <optikalmouse>`mv var/guix /var/ && mv gnu /` <-- I'm stuck on this,mv: cannot move ‘gnu’ to ‘/gnu’: Operation not permitted <rekado_>optikalmouse: it could, but then you cannot use binary substitutes. <rekado_>optikalmouse: do you not have root access? <optikalmouse>you have rudimentary root access with cloud9, I'm running sudo <rekado_>optikalmouse: note that the guix-daemon should run as root. <optikalmouse>do I change the store location by passing an option to the guix-daemon? <rekado_>optikalmouse: no, the store location is changed at configure time. <rekado_>I'm not sure if you can use the binary installation method. <rekado_>I think you may have to build from source. <optikalmouse>*sigh* ok. ok, that's cool I was just hoping to get to writing packages and testing them rather than playing with installs/compiles <rekado_>it's a lot easier when you have full root access. <rekado_>you can install Guix on your machine on top of another distribution. <rekado_>it's pretty much self-contained and won't mess with your distribution <optikalmouse>and I have to compile/install guile, yay. silly cloud9 vm but at least it's free and not taking up RAM on my work machine (already running a 10GB RAM machine for work stuff) <ng0>til: interrupting guix package -i can sometimes do weird stuff on my personal problematic setup. <ng0>my init script for guix is problematic. hang for a long time. that's "normal" when stopping it, but not when running it. <janneke>i have `built' GNU rottlog (bash logrotate scripts) <janneke>anyone experience with running/setting up mcron? <ng0>civodul: getting gcc-toolchain into profile did not fix the locale being wrong. <ng0>i think so far this problem apeared only with non-terminal applications and weechat <ng0>to some extent also terminal applications like powwow <thomasd>ACTION accidentally triple-mailed guix-devel :S <rekado_>thomasd: I saw your mail. What is the difference between the library as part of the tarball you use and the Debian copy? <ng0>google lists are awful. ... inbefore I send a 1000 pages "take me off your mailinglist!" in different shades of rage printed out and sent to google. <ng0>when not even unsubscribe works. <ng0>wrong list.. oh. well.. too many lists. <thomasd>rekado_ : I timed out there. I believe the contents of my package correspond to Debian's libgctb-dev 1.0.1 <thomasd>Though the source package there only contains .c and .h files. I would have to add patches to build it (e.g. autotools -- just like the Debian patches). <lfam>Gah, sorry that 9f44dfc077 (build: Update list of libxslt patches.) was necessary <ifur>ciodul: no offence, but you are also an academic using guix for your career, so colunteer hardly covers it. That being said, point taken and fully agree. <sankey>first time user here, how do i fix "package not found" when I try to install a package which i know exists <sankey>the package is "vdirsyncer", and i see it right here: <bavier>sankey: do you have the latest version of guix? <sankey>hm, perhaps not...is that done with guix pull? <bavier>i.e. the source you're looking at on savannah might not match up with the version of guix you're running <bavier>sankey: try `guix package --show=vdirsyncer` <bavier>sankey: yes, you should run `guix pull` occasionally <sankey>set up guix on this machine months ago <sankey>it's quite possible i never ran guix pull ever, so perhaps the guix distribution tarball itself is older than 6 months <sankey>but i feel like it has been less than 6 months since i set it up initially <mark_weaver>security holes are being discovered very frequently, many times per week. if you don't keep your software up-to-date, you're asking to get hacked <sankey>good point, but i never even installed or used any software in guix until today <sankey>i just set it up and...forgot about it