IRC channel logs
2013-10-13.log
back to list of logs
<mark_weaver>well, turns out networking works on this new kernel, just not wireless.. <mark_weaver>civodul: what needs to be done to get hydra building MIPS N32 binaries? <mark_weaver>do we need a fast MIPS box, or would several slow MIPS boxes be sufficient? <mark_weaver>I know that djbclark mentioned having a fast MIPS box around. <mark_weaver>specifically he said that he has "a 72-processor mips64-based computer" <civodul>so yes, we could has djbclark for help ;-) <civodul>actually there's another thing: we need to be able to copy closures among machines <civodul>not very difficult, but that needs to be done <civodul>so first, there needs to be some authentication when copying in and out of hydra.gnu.org <mark_weaver>so right now, hydra.gnu.org doesn't talk to any other machines? it just does it all locally? <mark_weaver>I guess that 'ssh' would be sufficient for authentication when copying things between hydra and its build boxes. <mark_weaver>with the help of a new kernel, m4 is now built.. on to libtool :) <mark_weaver>civodul: do you know roughly when you will merge core-updates into master? <mark_weaver>the reason I ask is that I'd ideally like to get MIPS into core-updates before the next merge. <mark_weaver>I guess this 'm4' problem I ran into shows that impurities can result from the choice of kernel used to do the builds. <mark_weaver>the kernel and the precise processor type can affect the results of configure tests, for example. <mark_weaver>I guess we'll have to deal with those problems piecemeal though. <civodul>yes, the kernel and hardware are not under control <zacts>so how do I guix pull from source instead of binaries? <civodul>zacts: you mean the "guix pull" command? <civodul>actually "guix pull" has nothing to do with source/binary <zacts>oh, sorry. I was confused I guess.. <civodul>to build packages from source, use 'guix build --no-substitutes', for instance <zacts>due to the previous conversation about hydra being down and guix pull not working.. I think I misread.. <civodul>yeah, these are two real issues, but not related with each other ;-) <zacts>ok. do you guys plan to ever use a cdn? <civodul>well, isn't a network about delivering content? :-) <civodul>if you're thinking BitTorrent, yes, that'd make sense <civodul>we discussed p2p distribution with the GNUnet folks, but there's nothing concrete <zacts>but yeah a more decentralized, but still signed packages might be an option also.. <civodul>dunno, i have a hard time extracting the technical parts from the commercial prose <zacts>anyway, I can't wait to get started working on guix. <zacts>I'm learning scheme now, and I'm using emacs again <zacts>I need to learn how to use it though, but it's well documented <zacts>ok, 'guix pull' now gives this error: guix pull: error: build failed: builder does not have write permission to `/nix/store'; try `chgrp 1001 /nix/store; chmod 1775 /nix/store' <zacts>oh, let me do what that says <zacts>ok, I did that. Now I'm getting this error: zacts@raincity-$ guix pull <zacts>The following derivation will be built: <zacts> /nix/store/3c3l95vj3iqm89xsvxxjp7cismqh1dbs-guix-latest.drv <zacts>guix pull: error: build failed: build of `/nix/store/3c3l95vj3iqm89xsvxxjp7cismqh1dbs-guix-latest.drv' failed <gzg>zacts: Did you get that worked out ever? <zacts>I got guix installed and everything. but when I invoke 'guix pull' I get the above error. <mark_weaver>fwiw, if you get the 'guix' source directly from the git repository, then you needn't ever use 'guix pull'. I myself have never used 'guix pull'. <mark_weaver>it seems that there are some problems with 'guix pull' that need to be fixed. <mark_weaver>however, if you decide to build guix from its git repo, then I'd recommend first installing 'autoconf', 'automake', and 'libtool' using guix, to make sure you have new enough versions of those packages to bootstrap guix from git. *gzg has been considering just going the git route, since he's hoping start contributing relatively often. <zacts>mark_weaver: I used the git repo <mark_weaver>the other advantage of using git is that if you decide to make local changes to your recipes (or add new ones), that can be handled very gracefully with git. you can just make your own branch of guix and then periodically merge the upstream changes into your local branch. <zacts>I was going to then use v0.4 guix to install the needed dependencies for guix HEAD <mark_weaver>zacts: ah, good! then just checkout the 'master' branch, and then run 'make' in the top-level build directory. <gzg>Do I need to just run the bootstrap, to get the git pull working then -- or? <mark_weaver>and then you can either 'make install' again, or alternatively, just prefix every guix command with ./pre-inst-env guix ... <mark_weaver>gzg: the HACKING file in the top-level guix directory contains instructions for building from git. <gzg>mark_weaver: Okay cool, I'll check it out. :^) <mark_weaver>the main thing is that you'll need a relatively new 'automake'.. and probably it's a good idea to have new versions of autoconf as well. <zacts>mark_weaver: and then to update will I have to do this every time I git pull? <mark_weaver>follow each 'git pull' with 'make', and then you can immediately run ./pre-inst-env guix ... from that directory <mark_weaver>'make install' is only needed if you want to be able to run 'guix' without the './pre-inst-env' <mark_weaver>I myself never installed guix at all. I always use './pre-inst-env' <zacts>now, let's see if I can install local packages from source.. <mark_weaver>if you want a new automake/autoconf, I would recommend just using your current guix installation to do that. <mark_weaver>but if you already built guix from git, then I guess you already have what you need. <zacts>I've got it working now, thanks for the help! <zacts>I wouldn't mind contributing to the documentation, once I learn more about how it all works together.. <zacts>anyway, other than documentation and testing, what else can I, being a newbie, help with? <mark_weaver>zacts: docs and testing are extremely valuable in their own right, but beyond that: add new packages! :) <mark_weaver>if there are packages missing that you need, please let us know. even better, add it to guix yourself. there are lots of examples in guix/gnu/packages/*.scm <gzg>Any idea what package 'dot' may be a part of? I'm trying setup my git version and the make part of the build is complaining that I'm missing it. <gzg>zacts: Ah! Queer though -- I thought I had that installed prior. Maybe it's just time for me no take a nap though. :^) <gzg>Okay, bed-time... Peace y'all. AFK. <a_e>Any news on hydra? I see the error message has changed. <a_e>Now it looks like something that I sometimes get in my installation and solve by make clean; make... <civodul>Nikita and i took care of the upgrade <viric>by hydra, what instance of hydra is meant? <civodul>it went fine, but now we have Guix issues showing up there <viric>do you still use icecat? It seems it stagned at 17.0 <a_e>This is the long-term support version of firefox. <a_e>The current such version should be 24.0, released on September 17. <viric>but there isn't icecat 24.0, is it? <a_e>I have a recipe for icecat 17. <a_e>No, but firefox 24 is so recent that this does not worry me yet. <viric>ah, you mean that 24.0 is LTS, but not 23.0? <a_e>For the version history, see <a_e>Every 7 releases are extended support. <a_e>If I remember well, the recipe took about 6 hours to build. <a_e>In the end, it failed with <a_e>collect2: error: ld returned 1 exit status <a_e>make[3]: *** [libxul.so] Error 1 <viric>do you talk about a loongson2f system? <a_e>But I did not see what was missing; probably, I will have to disable parallel build so that the error messages do not get mixed up; and then wait 24 hours. <viric>a_e: don't you have the build log? <viric>wise people use Task Spooler <a_e>No, I did not redirect it. <civodul>a_e: builds logs are kept in $localstatedir <a_e>Great! But there are over 8000, 33 of which concern icecat. Which is the right one?! <a_e>Indeed, the latest failed build went the furthest... <a_e>There is a command line ending on <a_e>-L... -L... and so on, then -lgtk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lfreetype -lfontconfig -lgdk-x11-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lXt -lgthread-2.0 -L/nix/store/0qm1q7z83vpjl7vwrnc0wx5ngg3c07x7-freetype-2.4.11/lib -lfreetype -ldl -lrt <a_e>And then immediately <a_e>collect2: error: ld returned 1 exit status <a_e>It could at least tell us which library was missing! <a_e>dl and rt are in glibc. <viric>Maybe ld was killed by the OOMK <a_e>Unlikely. I have 8GB. <civodul>since it's a parallel build the actual error message could be intermingled above <a_e>civodul: Yes, but above everything looks fine. <a_e>I just went through all the -l..., and they should have been available through the inputs. <a_e>On Internet I just found the suggestion to add -Wl,-V to the CFLAGS. What do you think? <viric>maybe you can share the log here, for others to look? <a_e>Or CXXFLAGS for C++, I suppose. <viric>although I remember having sometimes such messages of failed ld, without any clue of what happened :) *Steap packaged libpeas last night, was an epic battle <viric>a_e: right, I can't see anything useful there :) <viric>at most: make[5]: [/tmp/nix-build-icecat-17.0.1.drv-1/icecat-17.0.1/security/nss/lib/freebl] Error 1 (ignored) <viric>Steap: all at gnome.org is a big pain <a_e>viric: "Cannot create directory: File exists" does not look dramatic. <a_e>And it is very far from the failure point. <viric>damn it, this conkeror thing is too emacs. Why does it mention "emacs and vi" in the main page? I don't see any 'vi' :) <a_e>Steap: With the new patch system, cmake does not patch any more. I suppose that the #:patch-flags '("-p0") line is not used any more. Could you maybe update your patches to work with the normal flag, which is -p1, I think? <a_e>civodul: Should we drop #:patch-flags? <a_e>Steap: Actually I just did it myself, will commit if everything compiles. <civodul>a_e: #:patch-flags no longer exists in core-updates, and should not be used any more <civodul>instead, there's a 'patch-flags' field in <origin> <Steap>a_e: btw, cmake works on x86_64 now <civodul>Steap: so if you really need -p0, you can put it in 'patch-flags' of <origin> <civodul>Steap: probably due to the 'ldd' fix <Steap>civodul: I guess the easiest thing to do is update the patch :) <mark_weaver>On MIPS N32, 'guix build bash' finished. I just had to disable one libtool test that failed and looked hard to fix. Other than that everything built fine. I'm currently building 'emacs'. <a_e>I just added a dummy directory in the patch so that it works with -p1. <mark_weaver>well, I'm currently running 'guix build emacs' that is. it's still building the dependencies. <a_e>Yes, I ended up choosing a non-guest nick. <mark_weaver>if so, I guess I should ask you what you think of using N32. <a_e>I am okay with it, as I posted a few days ago on the list. <a_e>(The message where I give the sizes of types, in particular in gmp.) <a_e>Sorry, not on the list, here in the chat. <a_e>We indeed have 64 bit word size for GNU multiprecision. <mark_weaver>right, N32 is somewhat analogous to the x32 ABI for Intel: it uses 64-bit registers and assumes a 64-bit processor, but to save memory (and cache) it makes pointers, ints, and longs 32-bit. <mark_weaver>a_e: which thread should I be looking at? You've posted quite a bit, but some of the threads I'm behind on. <a_e>Not on the mailing list, here on irc. <mark_weaver>oh right, I remember now. I just didn't realize it was you. <a_e>This is the advantage of being a guest ;-) <a_e>You need to guess from the topic of conversation. <civodul>a_e: that's actually a good authentication method :-) <mark_weaver>civodul: thanks, though in the end I didn't do all that much :) <a_e>civodul: Not very secure, I am afraid. But it gives plausible deniability. <a_e>Does hydra allow to search for files? <a_e>I need the package containing X11/extensions/xf86misc.h <a_e>Often, locate on my machine works, but I do not have all packages in my store. <civodul>a_e: ls /nix/store/*/X11/extensions/xf86misc.h :-) <civodul>the web interface doesn't offer anything like that <a_e>civodul: Thanks, good point! <a_e>Unfortunately, it takes ages. <a_e>kdelibs requires lots of X11 header files. In the end, it does not admit which ones it did not find, but just states that X11 is missing. <Steap>it would be nice to have something like "apt-file search" <a_e>Is there a way of making cmake more talkative? Or is there already a log file? <Steap>You'd like a verbose build ? <a_e>Actually, I also use "apt-file search" on my debian system to get potential guix package names... <Steap>a_e: I know it can be done :) <Steap>maybe we should have a #:verbose-build? option that would set the right environment variables/options for the various build systems we use <a_e>viric: You mean "cmake VERBOSE=1"? I am still in the configure phase. <viric>no, the most you have is cmake --trace <a_e>This essentially seems to copy line after line of the cmake script, without telling me if the <a_e>FIND_PATH succeed or not. <Steap>I don't think there is a config.log-like file in cmake <Steap>cmake is really utter crap, anyway <viric>well, the worst of it is that it quite works, and so, it spreads. <a_e>Very strange. It does not even seem to find libX11. <a_e>FIND_LIBRARY(X11_X11_LIB X11 ${X11_LIB_SEARCH_PATH}) <a_e>and the line following the IF is not executed. <a_e>Of course, I did add libx11 to the inputs. <a_e>It looks like I need to set X11_LIB_SEARCH_PATH, right? <Steap>by default, cmake modules look in /usr/lib and stuff like that <Steap>I don't know how you can do "--with-libx11=" in cmake <viric>in nixpkgs we usually set CMAKE_PREFIX_PATH to all build inputs paths, colon separated. something like that. <viric>That affects all FIND_LIBRARY and alike <a_e>So it does not even look in CPATH or LIBRARY_PATH? <Steap>viric: so you have to set CMAKE_PREFIX_PATH=/path/to/libx11 ? <viric>I don't remember. the manual says exactly where it looks at. <viric>Steap: no, the prefix path is expected to have /include, /lib, ... Then FIND_* looks at those places <viric>well, I only recall the concepts; I know it's in the cmake manual. :) <a_e>export CMAKE_PREFIX_PATH=$CPATH:$LIBRARY_PATH ? <Steap>but I guess it's because I'm used to try to make sense out of stuff <viric>Steap: CMAKE_PREFIX_PATH=1:2:3:4 ... then cmake looks at 1/lib, 2/lib, ... <viric>I prefer you to look at the manual looking for those strings, at what directories FIND_LIBRARY looks at, ... <a_e>viric: Okay. So nothing we can easily extract out of our existing paths. But something that could easily be constructed from the inputs. <viric>CMAKE_LIBRARY_PATH, ... things like that. <Steap>civodul: can I define a function inside the redefinition of a configure phase ? <viric>to me, autotools look also quite crazy :) <viric>the same can be said about cmake <Steap>all build systems suck, the autotools just suck less :) <Steap>Cmake is just an abomination <viric>all build systems suck, but tastes have a role. <a_e>So I suggest the following patch to guix/build/cmake-build-system.scm: <a_e>--- a/guix/build/cmake-build-system.scm <a_e>+++ b/guix/build/cmake-build-system.scm <a_e> (if (file-exists? "CMakeLists.txt") <a_e> (let ((args `(,(string-append "-DCMAKE_INSTALL_PREFIX=" out) <a_e> ,@configure-flags))) <a_e>+ (setenv "CMAKE_LIBRARY_PATH" (getenv "LIBRARY_PATH")) <a_e>+ (setenv "CMAKE_INCLUDE_PATH" (getenv "CPATH")) <a_e> (format #t "running 'cmake' with arguments ~s~%" args) <a_e> (zero? (apply system* "cmake" args))) <a_e> (error "no CMakeLists.txt found")))) <a_e>Does this look okay? It is enough to make kdelibs find X11. <Steap>I would not argue against it. <roelj>I'm wondering how I can integrate debian with guix. For example, I installed emacs with guix, and I'd like to run it without looking up the path its stored in in "the store". Now I'm making symbolic links to do this, but then I have to update all symbolic links every time I upgrade with guix. <roelj>What's the right way to do it? <a_e>If you installed it with "guix package -i", then it is in $HOME/.guix-profile/bin <a_e>I have the following in my .bashrc: <a_e>export PATH=$HOME/.guix-profile/bin:$PATH <a_e>export LIBRARY_PATH=$HOME/.guix-profile/lib <a_e>export CPATH=$HOME/.guix-profile/include <a_e>export MANPATH=$HOME/.guix-profile/share/man:$HOME/.guix-profile/man:/usr/share/man <a_e>export PKG_CONFIG_PATH=$HOME/.guix-profile/lib/pkgconfig:/usr/lib/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig <a_e>export PYTHONPATH=$HOME/.guix-profile/lib/python2.7/site-packages <a_e>export XDG_DATA_DIRS=$HOME/.guix-profile/share <roelj>That's exactly what I am looking for. <a_e>It is the job of "guix package" to look up the paths in the store and to update your personal profile. <a_e>roelj: With pleasure! <roelj>a_e: Hmm, how can I set the PATH for Gnome itself? <a_e>Why gnome? So far, there is essentially no gnome in guix. What do you mean by "PATH for Gnome"? <roelj>I'd like to run emacs by pressing Alt + F2 > emacs -fs in Gnome. <a_e>I do not know. It does not pick up the path from .bashrc? <roelj>It doesn't seem so. Oh well, I'll go and search first. <roelj>Thanks for your help. I really appreciate it. <a_e>Warning to all, especially civodul: I am pushing a patch that adds kde.scm, but there is not much kde in it yet... <mark_weaver>if you want to initialize environment variables for an entire X session, on a system that uses a session manager such as gdm3, then you need to put them in ~/.xsession <Steap>a_e: btw, do you think I should put libpeas in gtk.scm or in gnome.scm ? I'd go for gnome.scm, but I'm not sure <a_e>I think our final rule was to put everything from mirror://gnome into gnome.scm (except gtk+ itself, I suppose). <a_e>It is a bit messy at the moment. <mark_weaver>the pixman derivation picks up an impurity. at configure time, it checks to see if it's running on a processor that supports Loongson-specific SIMD instructions, and compiles accordingly. <mark_weaver>pixman is actually a case where it's *very* important for performance to use those Loongson-specific instructions if they are available. <mark_weaver>it makes a dramatic improvement in the speed of all graphics in X and cairo. <a_e>It has lots of --disable-mips-dspr2 and so on as configure parameters. <a_e>Those that I was told to use for qt ;-) <viric>mark_weaver: wasn't it you, improving pixman a lot? <mark_weaver>we're going to need to have some way to enable Loongson-specific compilation for some of these key packages. <mark_weaver>viric: no, it was one of the Gentoo MIPS guys. Matt Turner, maybe? <a_e>As long as we have only this one mips architecture, it does not actually matter. We could also wait for the first user on a non-loongson mips machine. <a_e>And solve the problem only then. <mark_weaver>a_e: did you see my message about SSE2 being available on all x86_64 processors? <a_e>Yes. I just did not act on it so far, but I kept it in my inbox. <mark_weaver>I expect that it makes a significant difference on Qt rendering performance. <mark_weaver>ideally, these packages would be modified to detect the processor type at runtime and then dynamically choose the right optimized code. <zacts>I just saw hundreds of hot air balloons <zacts>I tried to find a gnu / penguin / daemon balloon, but the closest I found was a spiderman pig. <zacts>and now I'm having a coffee, and getting back to hacking on guix <zacts>@ the same time I'm doing homework <zacts>would zsh be difficult to add to guix? <mark_weaver>does zsh use the usual ./configure && make && make check && make install ? <zacts>mark_weaver: I don't see any documentation on how to add a package, maybe I could also add documentation when I do it.. <a_e>Easier yet, add a (define-public zsh ...) to some existing file. If there is a place where it fits. <a_e>I referenced the slides, which are probably less useful than the full talk. <a_e>"Full" as in a video with explanations. <a_e>But the packages I explained are now in guix, so it should not be too difficult to follow. <a_e>My advice would be to start with a simple gnu package, as these follow the gnu build standards ;-) <a_e>Others are usually more difficult, and one never knows beforehand which problems will pop up. <a_e>The packages in oggvorbis.scm were rather easy to package, and there are more in the family. <a_e>speex and theora, for instance. <a_e>I think that would make a good starting point. <zacts>a_e: for source builds does guix fetch from remote locations a la bsd ports, or does the entire package manager store the distfiles? <a_e>I do not quite understand your question. <zacts>a_e: hm.. sorry. I'm kind of multitasking a bit. <zacts>does guix fetch distfiles from various remote servers, compare it to a hash, and then install it? <mark_weaver>it fetches the source code from various remote servers, and compares with a hash that's stored in the recipe. <mark_weaver>recipes can then be added to hydra.gnu.org, which builds binaries automatically <mark_weaver>guix-daemon will, by default, look for prebuilt binaries on hydra.gnu.org, if they match exactly (same hash, which means same recipe and precisely the same inputs) <mark_weaver>if you prefer to build everything from source on your own machine, then you can pass --no-substitutes to the guix-daemon. <mark_weaver>(though you can't avoid fetching the binary bootstrap tarballs as a starting point) <mark_weaver>I'd like to come up with a process for producing your own bootstrap tarballs from diverse starting points, as a way to defeat Thompson viruses, but that's another project. <zacts>mark_weaver: oh interesting.. <zacts>so do these hashes reduce the need for signed packages? <zacts>I'll check out Wheeler's thesis <mark_weaver>well, we really should try to check the signatures before adding the hashes to guix. <mark_weaver>I should mention that currently, the binary substituter does not do any kind of authentication on the binary packages it receives from hydra. <mark_weaver>so if you worry about security (as I do), then it's best to use --no-substitutes for now <mark_weaver>but we have a good plan for this that's superior to any other GNU/Linux distro I know of. <zacts>I generally prefer binary packages, unless I want to fine tune them, or use them on an ssh server. <mark_weaver>once we've purged all the "impurities" from all of our package builds, then builds should be reproducable in the sense that anyone who does them will get precisely the same output, bit-for-bit identical. <zacts>I would like to see pure user installs, without needing root, so I can use guix to download and build packages on ssh servers.. <mark_weaver>so that means that our binary builds will be independently verifiable by anyone who cares to check them. <mark_weaver>yeah, that would be nice. it's certainly doable on the hurd. the problem on linux is that only root can mount filesystems. and setting up the pristine build environments free from impurities requires setting up a chroot with bind mounts, a private namespace, etc. <mark_weaver>note that the actual build processes are done using the guix-builder* users. <zacts>mark_weaver: why not use fuse in some way? <viric>mark_weaver: linux currently has USER_NS <mark_weaver>I don't know much about FUSE, but I doubt it allows arbitrary unprivileged users to create mount points and do chroots, does it? <mark_weaver>anyway, we don't need a new filesystem here. we just need the ability to make bind mounts and chroot, and ideally also private namespaces. <mark_weaver>FUSE does _some_ of what the Hurd can do, but not all :) <zacts>there must be a way on a linux based system to allow for the illusion of user level chroots.. <zacts>I mean at least for guix purposes <mark_weaver>the problem with chroots on standard POSIX systems is that they could be a potential security hole in the presence of setuid binaries. <mark_weaver>because some setuid programs look for configuring in /etc/ <mark_weaver>consider 'sudo' for example. it looks in /etc/sudoers to decide whether you can be root or not, and whether you need to type in a password or not. <zacts>bsd jails are one solution for that, I believe. but they need root for setup.. <mark_weaver>so if you can chroot in such a way that /etc/ is under your control, but sudo is still visible, then you can get root. <zacts>I wonder how pkgsrc accomplishes this.. <viric>that's why USER_NS came to existence <zacts>they allow for complete non-root bootstrapping and installing of packages. <mark_weaver>zacts: it's easy enough to build and install packages as non-root if you don't need to set up a pristine build environment. <mark_weaver>but the special features of Guix depend on building in a pure environment. <zacts>pkgsrc is _supposedly_ portable to many different OS <viric>that reminds me of some projects pretending the same, and having that outcome ;) <zacts>yes, I'm not a big pkgsrc fan <zacts>I'm interested in package managers though, and guix definitely looks way cool. AND I love (scheme). <viric>looks like the right place to be <zacts>a_e: yeah, but this should be added to a non pdf file imo <a_e>You mean, you will need a new file for zsh? <a_e>Sorry, what should be added where> <zacts>the documentation for adding packages should be made more accessible <zacts>not a just a random pdf, linked on the homepage, but maybe a section on a wiki or info doc or something.. <a_e>There is a section in the handbook on conventions, but no tutorial currently. <mark_weaver>zacts: yes, better documentation would be most welcome :) <a_e>"package conventions", I mean. <zacts>mark_weaver: yeah, and that's where I think I can first contribute the most <mark_weaver>zacts: though first you need to learn how to do it yourself :) <zacts>and I have English on my mind, because I'm taking an English class this semester, and I'm documenting perl modules. <mark_weaver>so you should probably start by adding packages, and get some experience there before trying to teach others. <zacts>mark_weaver: well, for sure. that is the plan. :-) <mark_weaver>anyway, I have to go afk for a while. happy hacking! <zacts>and all of my doc will be peer reviewed also.. <davexunit>I am finally starting to play around with guix. I just compiled it successfully. <davexunit>a small nitpick: after building, when I run make status I see quite a few untracked files <zacts>doesn't guix have garbage collection? <davexunit>yeah I have files in po/ and nix-setuid-helper <civodul>Steap: yes you can define an internal function inside the redefinition of a phase <a_e>Did you read my disclaimer? <a_e>Nothing works, actually ;-) <a_e>But at least we advanced the cmake build system. <Steap>civodul: how ? I can't use "(define ...)" *zacts grepped through guix package --list-available <civodul>Steap: you can use (define ...) or (let ((f (lambda ...))) ...) <zacts>ok, I'm going to try to port zsh to guix. <Steap>actually, define is forbidden :) <civodul>which means that you can have (lambda* (args ...) (define (foo x) ...) ...) <civodul>but not (lambda* (args ...) (display "hello") (define (foo x) ...)) <civodul>at any rate you can always use let or let* <civodul>davexunit: i don't think we want all of /po though <zacts>ok, so which .scm file should I use as a reference when attempting to port zsh? <davexunit>and there were things that didn't match *.mo and *.gmo that were there after running make <zacts>ok, I don't feel I know enough scm to create a zsh.scm file from scratch. I can kind of get the gist of what is going on.. <zacts>but, I may ask questions either here or on #scheme.. <zacts>but, I'm getting thru the little schemer this week, and I'm going to read 'scheme and the art of programming' <a_e>Follow the almost tutorial of my slides! <a_e>Start by copying indent.scm to zsh.scm. <zacts>sorry. I completely spaced that out.. <a_e>Add zsh.scm to gnu-system.am. <a_e>./preinst-env guix build zsh <a_e>With lots of luck, that is all. <zacts>a_e: I expect you to help me the entire way through this, and I mean every single scheme phrase I type and emacs command. <davexunit>is there a list of priority applications that need to be packaged for guix? <a_e>Whatever you like. As I said above, I expect speex and theora to be easy to package. <davexunit>I know that I would find tons of things to package if guix was my main package manager, but since it's not... <a_e>zacts: It could make sense. But not tonight. <zacts>but on a serious note, I do think that I can handle indent.scm <zacts>a_e: so all of the guix developers use ./preinst-env because of common git pulls? <civodul>davexunit: po/ is for message catalogs <civodul>davexunit: make it your main package manager :-) <davexunit>a_e: I was going to try my hand at libtheora. <davexunit>debian has 5 packages for libtheora: libtheora0, libtheora-dev, libtheora-doc, libtheora-dbg, and libtheora-bin. in guix would this just be one package instead? <zacts>a_e: this tutorial is really great <a_e>zacts: You can also do "make install" and "guix build ..."; the ./preinst-env just works without installation. <a_e>zacts: Thanks, good you find it helpful! <a_e>davexunit: Yes, one package is normally enough; we are so much easier than debian! <zacts>I don't know what to use as a url for sourceforge based mirrors.. <a_e>grep sourceforge gnu/packages/*.scm <a_e>Then look at one example which has mirror://sourceforge in it. <a_e>The exact file name is a bit tricky to find out, but with a bit of exercise, it becomes easy. <a_e>On the sourceforge download page, look at the "direct link", which encodes the path. <a_e>You just need to strip off the decoration around it. <davexunit>okay. putting that on the list of things to package. <zacts>a_e: how do I specify the MIT-like zsh license? <a_e>Either x11, or x11-style (the latter is a function, see an example). <a_e>All licenses are in guix/licenses.scm. <zacts>(license (x11-style "file://<whatshouldIputhere")) ? <zacts>I'm reading both your pdf and the x11-style in licenses.scm <a_e>grep x11-style gnu/packages/*.scm <a_e>I always copy and paste from existing packages... <zacts>file:// is relative to the packages source directory I guess <zacts>#:renamer (symbol-prefix-proc 'license:)) <zacts>(license (x11-style "file://LICENSE" "See LICENSE in the distribution")) <zacts>and that is my last question for now, sorry to bother you guys.. <a_e>If you keep the renamer for the moment, you need to write license:x11-style instead of x11-style. <a_e>Or, as in w3m.scm, you can use #:select. <a_e>Otherwise, there tend to be "duplicate" symbols between the zlib package and the zlib license. <a_e>If you import at the same time (guix licenses) and (gnu packages compression). <a_e>#:select is preferred nowadays, I have been told... <davexunit>civodul: do you think that the define-record-type* could ever make it into guile's (srfi srfi-9 gnu) module? <civodul>i want to make it even fatter though <davexunit>I think it's really elegant, but when I tried to read the source to the macro I had no idea what I was looking at. :P <davexunit>what is the difference between inputs and propogated inputs? <a_e>When a user installs a package, the propagated-inputs become installed automatically. <a_e>This can be useful if something needs to link to another dynamic library. <davexunit>so regular inputs would be for something that is only needed to build but not run? <zacts>a_e: almost done, thanks for the help. next I guess will be a peer review of my patch and hopefully a push into the official git repo. <a_e>Normally, patches are sent to guix-devel. <a_e>davexunit: Not necessarily. For instance, pari-gp depends on readline. But the guix build system sets the runpath, so if you do ldd on the gp binary, it points to something explicit in /nix/store/...readline... <a_e>So it looks like my previous explanation was wrong... <a_e>Another example where propagated-inputs are needed: mpfr.h includes gmp.h. So a user who wants to develop with mpfr necessarily needs the header files of gmp, so gmp is a propagated input of mpfr. <a_e>If in doubt, use normal inputs first. <davexunit>I'm copying most of my libtheora package from the libvorbis package that uses propogated inputs <a_e>There when you look at /nix/store/...libvorbis.../lib/pkgconfig/vorbis.pc, the field "Requires: ogg" tells you that you need a propagated input. <davexunit>do most packages do checksums in the form of sha256 base32 ? <a_e>Either just keep a wrong checksum. Then the download will fail and give you the checksum of what you downloaded. <a_e>Or get the file separately, and use "guix download file:libtheora..." to put it into the store and obtain the hash. <zacts>If I were to port guix to Gnu/kFreeBSD how would that be separated / abstracted out in the git repo? <davexunit>I'm looking through the docs and HACKING, but I don't see a workflow for testing out a new package. <zacts>davexunit: I don't either, that would be useful <davexunit>oh wiait, I can just use the preinstalled environment <a_e>./preinst-env guix build zsh <a_e>./preinst-env guix package -i zsh <a_e>guix package --roll-back <zacts>which pastebin should I use for this channel. make is throwing an error. <davexunit>guix/packages.scm:484:16: In procedure expand-input: <davexunit>guix/packages.scm:484:16: Throw to key `match-error' with args `("match" "no matching pattern")'. <davexunit>I defined the package and exported it. I can search for it with ./preinst-env guix package -A libtheora <zacts>the last one is the error I got <a_e>zacts: Syntax error; not <a_e>( is the function application <a_e>license:x11-style is the (renamed) function name. <a_e>"file://..." and "See..." are the two function arguments. <zacts>I understand that ( is function application <a_e>Then one ) closes the function evaluation, one ) closes the license field; you miss one of them here. <a_e>Consequently, there will be one too many at the end. <zacts>or you could use a higher-order function like ((a-func-returning-func) args..) <a_e>davexunit: Can you post your package and error message? <mark_weaver>zacts: you must have mis-matched parentheses. what editor are you using, btw? <a_e>Looks like another syntax error. A lack of parentheses at the end, probably. <mark_weaver>emacs should show you the matching open paren when you close a paren. <zacts>is there an emacs mode or marmalade package I can install to help me with this? <zacts>I'm coming from vim, so my emacs foo isn't the best yet <mark_weaver>well, paredit is great but there's a steep learning curve so it'll be difficult at first. <mark_weaver>before I used paredit, I would do things like delete a close paren and then add it back to watch emacs highlight the matching open paren, to make sure it's what I expected.. <zacts>ok, I'll check it out. but for now how can I highlight unbalanced parentheses? <gzg>If there is no means to check in a package, is there a way to skip the process in the gnu-build-system? *gzg is packaging dhcpcd and it doesn't appear to have any such phase in the build process. <a_e>gzg: Add #:tests? #f as an argument. And add a comment. <mark_weaver>another trick is to autoindent the file and see where the indentation doesn't match what you expect. <mark_weaver>(or where it suddenly changes to being wrong).. and then undo the auto-indent. <a_e>Sometimes, it is called differently. Then use #:test-target "test", for instance. <mark_weaver>or just try auto-indenting individual lines using TAB. <a_e>See vpnc for the first case. <gzg>a_e: As say "(arguments `((#tests? #f)))"? <mark_weaver>but really, my method (before paredit) was just to pay close attention to what open paren was highlighted when I type the close parens. <mark_weaver>and you can always go back and delete a bunch of close parens and then re-add them while watching the highlighted open parens. <a_e>gzg: Without parentheses around (#:tests? #f), and : between # and tests?. <zacts>m-x package-install rainbow-delimiters <a_e>Unlike inputs, arguments is not a list of pairs; it is just a list with an even number of entries, alternately a #:... and its value. <mark_weaver>but paredit is very highly recommended, if you're willing to spend some time learning how to use it properly. <gzg>a_e: Ah, I was also missing an colon between the pound and test, so that didn't help. :^) <gzg>So my expression now gets to the build process, but is complaining that "install: cannot create directory '/var': Permission denied" ...? I'm in the ./pre-inst-env if that makes a difference. <a_e>No it should not make a difference. <a_e>Maybe a problem with the software you package. <a_e>It might not honour the "--prefix=/nix/store/..." option that guix passes to the configure process. <mark_weaver>gzg: everything needs to be installed in /nix/store/*-zsh-*/ <mark_weaver>gzg: if it's not honoring the --prefix= argument to configure, then you might need to add additional arguments. <a_e>davexunit: It looks good. <a_e>In synopsis, do not repeat "libtheora". Just "library implementing...". <zacts>how can I get a sha256sum in base32? <gzg>davexunit: Are you starting to package things for guile-2d, or unrelated? :^P <gzg>zacts: "guix hash thing.tar.gz <a_e>davexunit: Maybe try "make clean; make" <davexunit>a_e: I just copied the libvorbis package definition and modified it for theora. <gzg>Or really any file archive. <davexunit>I started the guix daemon. did I forget an additional step? <a_e>Can you build other packages? <davexunit>sorry, I forgot an important word in one my last messages <gzg>mark_weaver: What, should I manually try to just add it as a configure flag through arguments -- or something else? <davexunit>it should have read: it happens with any package <a_e>Okay. Did you start the daemon with "guix-daemon --build-users-group=guix-builder"? <mark_weaver>gzg: you need to find out how to get it to install that /var stuff into /nix/store/*-zsh-*/var/ instead. <a_e>And created the user etc. before as described in the documentation? <a_e>It is also a bad idea to start several daemons. Kill the daemons first. <gzg>mark_weaver: Okay, made a note of it. :^) <mark_weaver>gzg: you could try building 'zsh' outside of guix, and doing 'make install' as an unprivileged user, and try to get it to install everything in some directory in your home dir, say ~/my-test-install/ <a_e>zacts: Nice! Does your zsh work also? <mark_weaver>and once you figure out all the options you need to pass to ./configure to make that happen, then you can add those to the package description. <zacts>mark_weaver: was that for me? <mark_weaver>(I'm not sure if that'll save you time, but it's an idea) <zacts>gzg are you working on zsh also? <gzg>mark_weaver: Okay, now I'm confused... <mark_weaver>gzg: sorry, in everything I wrote, replace 'zsh' with whatever package you're working on :) <gzg>mark_weaver: Okay gotcha -- I would've asked, but I was going to look into it first. :^P <mark_weaver>for packages with simple build systems, it's possible that you might have to modify some of the files first. <a_e>gzg: Daemons! That is tricky. <a_e>I did not try any so far. <gzg>mark_weaver: Yup, ethtool is done and libnl is on it's way. <zacts>a_e: what commands do I run again to test this? ./pre-delim guix build zsh <zacts>is trying to fetch from hydra <gzg>a_e: Yeah, I'm going to give it the ol' college try; I just want to write a generalized "network.scm" so I can get wicd eventually going. :^) <a_e>Try ./pre-inst-env guix build -n <mark_weaver>gzg: see 'zip' in gnu/packages/zip.scm for an example where a hardcoded "/usr/local" in a Makefile had to be changed to the right thing. <a_e>first; this will tell you what it is trying to do. Maybe donwload inputs from hydra first. <a_e>If you do not want this, you need to pass --no-substitutes to guix build. <mark_weaver>gzg: that's a case where there's no normal 'configure' phase, so the configure phase was simply replaced by editing the Makefile. <mark_weaver>alternatively, you can also pass --no-substitutes to guix-daemon