IRC channel logs
2015-07-07.log
back to list of logs
<codemac>davexunit: I exported the autoreconf -ivf rule for myself - was wondering the best way to patch this so I could send it to guix-devel? I'm thinking two patches, one that exports it, and on eth at changes a substantial (albeit not complete) number of packages. <mark_weaver>codemac: I'm not sure it's worth exporting it, because for any given package (when you know which of those scripts to run), it's trivial. <mark_weaver>typically it is: #new file: gnu/packages/patches/libwmf-CVE-2006-3376.patch <mark_weaver>#new file: gnu/packages/patches/libwmf-CVE-2009-1364.patch <mark_weaver>#new file: gnu/packages/patches/libwmf-CVE-2015-0848+4588+4695+4696.patch <mark_weaver>typically it is: (add-after 'unpack 'bootstrap (lambda _ (zero? (system* "autoreconf" "-vfi")))) <mark_weaver>and using it from (guix build gnu-dist) means adding that module to the list of modules imported by the build system, which takes even more lines than adding that one. <davexunit>mark_weaver: perhaps such a procedure could be exported from the (guix build-system gnu)? <davexunit>that way there's no extra import. just (add-after 'unpack 'bootstrap autoreconf) or something <codemac>I think it be in (guix build-system gnu) <codemac>or should it be in guix build gnu-dist, and just rexported by guix build-system-gnu? <codemac>well - the implementation of autoreconf *isn't* a one liner, whereas all the system* calls are <mark_weaver>in any case, if we added it to any of the common modules, it would force a full rebuild of *everything*, so it would have to be done in the core-updates branch. <mark_weaver>codemac: it's a one-liner when you know the package and know what command is needed. the more complex procedure is only needed when you don't know anything about the package and need to hunt around heuristically for a script that looks like the right one. <mark_weaver>if you change *any* of the modules that are automatically imported by build scripts, then *everything* will need to be rebuilt. <mark_weaver>if you put it in a different module, then you'll need to customize the set of imported modules, which takes more lines than just writing the thing. <mark_weaver>the thing is, unlike the other build phases, where the GNU build system specifies a standard set of commands to build and install software from a tarball, there is no standard command to bootstrap the raw source from the repo to prepare it for a call to configure. it depends on the package. <codemac>I understand that, I used to do a lot of packaging for archlinux <codemac>My patch is more -'s than +'s, I don't think it's a huge deal though either way <mark_weaver>I get the impression that some part of what I've written above is not being understood. <mark_weaver>but maybe I'm the one who fails to understand. can you show me to your proposed patch? <codemac>sure, you may understand everything and I may just be dense <mark_weaver>for example, look at the 'git-modules' package in emacs.scm <mark_weaver>see those #:modules and #:imported-modules arguments? <mark_weaver>that's what you need to do to add another module to the set of imports available to the build phases. <mark_weaver>and that's to save one self-explanatory line to call "autoreconf -vfi" <mark_weaver>now, the only way to get around that is to put this procedure in one of the modules that is imported in build scripts by default. <codemac>yes - I added it to guix build-system gnu <mark_weaver>which would be (guix build gnu-build-system) or (guix build utils). <codemac>so yeah, it's +23 -45.. I understand your hesitations around it though, just learning how to package things and ran into this corner of packages <codemac>I'm just learning now how to set up a development version of guix to do that :) I may have messed some up, I was just pasting it so you could get an idea of what the change looked like. <mark_weaver>I think it won't work as you have it, and anything that works without adding those 5 lines of #:modules and #:imported-modules overrides would entail a full rebuild of the entire system. <mark_weaver>but if you find a patch that actually works and looks like a net benefit, let me know :) <amz3>davexunit: it's still an achievement :) <rekado->davexunit: re CWL: looking at the example workflows it looks a lot like CWL is more about specifying input and output *files* and pipelines. <rekado->I don't think it operates in the same domain as Guix. <rekado->the Docker-part of it does, but that seems to be orthogonal. <rekado->I see that an "engine" can have a "DockerRequirement" and that would reference an image. <Jookia>you know it's good because it's 'common' and abstract and useless in domain-specific situations <rekado->If someone was motivated they could probably add a "GuixRequirement" with a reference to a Guix closure, or something. <rekado->the rest stays the same as it is really just pipelines. <rekado->davexunit: at least that's what a cursory look at the "workflows" repository tells me. <rekado->there is, of course, the danger that the popularity of Docker makes people only use "DockerRequirement" and Docker images ... and then using CWL is equivalent to just using Docker + (somewhat standardised) scripts. <rekado_>so, texlive-texmf took 207 minutes to build on NFS. I don't know if this is good or bad. What are build time values on your systems? <rekado_>profile building seems a little faster without deduplication. It's down to about a minute. <phant0mas>well my connection has some small problems today :P <civodul>this wip-container stuff is awesome! <phant0mas>hey civodul, the rest of the binaries where should be placed? <davexunit>civodul: hey civodul. thanks for playing around with wip-container. <davexunit>we'll see how many problems I can fix by friday ;) <davexunit>ACTION pushed a small, but convenient, change to the ruby build system <civodul>davexunit: few (if any) are really blockers though! <civodul>ph4n70m4s: if you look at bootstrap.scm, you'll see it tries to download them from alpha.gnu.org <civodul>for now, could you host them somewhere else? <civodul>i *think* you can also use a file name in the 'source' field <davexunit>civodul: yesss thanks for telling to how to get the clone syscall id for other platforms. <mark_weaver>civodul, phant0mas: either an absolute pathname or maybe a file URL. I've definitely used one of those in the past. <phant0mas>btw when bootstrapping, GUILE_LOAD_PATH is not getting set <mark_weaver>phant0mas: what stage of bootstrapping are you talking about? <mark_weaver>I don't remember having any problems with that when bootstrapping mips64el or armhf <phant0mas>when running make check, many tests fails at out/bin/guile --version~% <mark_weaver>you are running this in a Debian Hurd system, using Debian's guile package? <phant0mas>I am running make check on a debian hurd system <phant0mas>the bootstrap guile (which is a the static guile I have built before) runs fine <mark_weaver>one issue: there might be problems with the source directory having such a long absolute pathname. <civodul>davexunit: ooh i managed to use 'guix container exec'; i was passing the wrong PID <mark_weaver>well, I don't know what the shebang limit is on hurd. <civodul>mark_weaver: i believe there's no such limit <phant0mas>tried to run the untared version of guile in test-tmp/store/...guile-bootstrap it couldn't find ice-9 <mark_weaver>well, I don't have time to look into this right now, alas. <mark_weaver>(although I'm not certain that I ran "make check" at this stage) <mark_weaver>some of the test modules hardcode the names+versions of some of the bootstrap tarballs, as I recall. <mark_weaver>I remember having to tweak them to cope with the fact that some of the armhf bootstrap tarballs have newer version numbers than on the other platforms. <mark_weaver>probably there needs to be a case added there for hurd <mark_weaver>sometimes I think we should just remove the version numbers from those filenames. <phant0mas>yes, I already changed some parts of bootstrap.scm to add a case for hurd and the newer guile <mark_weaver>phant0mas: right, but did you change tests/packages.scm as well? <davexunit>civodul: okay, thanks. I'll have to better handle that error. <davexunit>in fact, my code should skip joining the namespace if it already belongs to it, so there's a bug to fix! <crocket>Can I automate installation of any package on GuixSD? <crocket>Some ArchLinux packages simply can't be installed automatically by SaltStack. <davexunit>guix doesn't use interactive commands that prevent automation, if that's what you were after. <davexunit>Emacs' ruby-mode pretty much always does the right thing, so you shouldn't see many egregious style errors in the meantime. <crocket>Do you know that pacman prompts choices among several backends? <davexunit>crocket: I haven't used pacman in a couple of years now. <crocket>I guess guix is a more stable base for completely automating system configuration. <crocket>It requires recompilation for every kernel update. <_`_>Hrm since zfs has been mentioned a few times, I'll ask the question I've been meaning to ask for a while here <_`_>zfs/spl can't be packaged for guix right? CDDL isn't GPL compatible afaik. <davexunit>crocket: not sure about zfs as I've never used it. <_`_>well can't be *shipped* is probably better worded <civodul>phant0mas: ooooh, please look at guile-relocatable.patch <civodul>phant0mas: we use it to allow the bootstrap Guile to find its modules <civodul>phant0mas: but /proc/self/exe is Linux-specific; could you check on #hurd what mechanism we should use? <civodul>phant0mas: well the Hurd has /proc as well, but maybe it's not mounted on your machine? <crocket>Common Development and Distribution License <_`_>that's a question for #zfsonlinux but the answer is no <civodul>zfs being CDDL prevents it from being used as a Linux kernel module <davexunit>civodul: thanks for all the feedback. I know that must've been a real chore. <crocket>It seems I'd have to use btrfs if I don't want to maintain zfs on linux. <davexunit>civodul: I'll get the easy stuff (before gnu/build/linux-container.scm) into master and then tackle the hard stuff. <_`_>civodul: so anything using a free license (regardless of compatibility) from that list is okay? <davexunit>_`_: it just has to be compatible with its dependencies and such. <davexunit>but yes, if the FSF has approved it, we're good. <crocket>Can guix automate third party guix packages? <crocket>Can guix automate installing third party guix packages? <crocket>There could be third party repositories.... <davexunit>export GUIX_PACKAGE_PATH=/path/to/my/extra/package/modules <crocket>Can I host a third party guix repo on my machine or a remote machine? <davexunit>our repos aren't like debian or arch or whatever <davexunit>they are just scheme objects living in scheme source files on your local machine <crocket>How do I add remote 3rd party repos? <civodul>you download them and add them to the GUIX_PACKAGE_PATH env. var. <crocket>It seems I need a mechanism for downloading it automatically. <mark_weaver>crocket: the issue is that there's no stable interface for making packages, similar to how Linux doesn't provide a stable interface for writing drivers. <mark_weaver>so in that sense Guix is designed to be monolithic, with all packages included within. <mark_weaver>maintaining guix packages out of our tree faces a similar maintenance burden to maintaining drivers for linux (the kernel) outside of the Linux source tree. <mark_weaver>crocket: is the issue that you want to support non-free software in Guix? <mark_weaver>I don't run non-free software, but for my own private modifications and additions to Guix, what I do is to maintain a private branch in git and periodically rebase it on upstream. <davexunit>>don't upgrade it when security patches are released <nukke>would it be possible to run Guix on a laptop with an Intel wireless card? <nukke>rather, is it possible to use the proprietary Intel drivers? <davexunit>nukke: guix doesn't come with the nonfree firmware required. <nukke>it's possible to remove the stupid whitelist in the BIOS, but I'm incredibly lazy :( <nukke>I have a spare T60 with an Atheros card, but I don't have a spare HDD for it, so I'm stuck with this non-libre W530. <davexunit>understood. a lot of people are in your position. <davexunit>it would be very easy to use a freedom compatible card otherwise. <nukke>a quick google search yields no modded BIOSes so eh... omdding the BIOS requires Windows tools, which is what annoys me. <davexunit>a usb wifi dongle would work, but would take up a usb port <civodul>i use the ThinkPenguin wifi usb dongle <sneek>civodul, you have 1 message. <civodul>phant0mas: there doesn't seem to be any useful hint <phant0mas>civodul: we may be able to work around using what they did in [LLVM]/lib/Support/Unix/Path.inc <civodul>i doubt it: in our case it's a static executable <civodul>but you should double-check with #hurd what they think of this particular trick <phant0mas>another option would be to do a hack with argv[0] when on hurd, and hope the force is strong with us :P <paron_remote>I wonder how hard it would be to kick guix up and running with that <civodul>phant0mas: actually no, i remember now: nix/libstore/build.cc uses basename(builder) as argv[0], not the absolute file name, so that doesn't work