IRC channel logs


back to list of logs

<davexunit>good evening, guix.
<davexunit>rekado_: looks like reproducible science with guix has some arguably more popular competition:
<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.
<davexunit>codemac: that sounds fine.
<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>blah, sorry
<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>ah, mark_weaver makes a good point.
<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>*it should be in...
<codemac>or should it be in guix build gnu-dist, and just rexported by guix build-system-gnu?
<mark_weaver>this is a one-liner.
<mark_weaver>I just don't think it's worth it.
<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>so that's 5 extra lines right now
<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
<mark_weaver>codemac: did you test this patch?
<mark_weaver>did you try building any of those packages?
<mark_weaver>(that you changed)
<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.
<rekado->Jookia: common workflow language.
<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>Hello Guix!
<civodul>this wip-container stuff is awesome!
<phant0mas>hey civodul, the rest of the binaries where should be placed?
<phant0mas>I mean the bootstrap tarballs
<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
<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: that's good, at least. :)
<davexunit>civodul: yesss thanks for telling to how to get the clone syscall id for other platforms.
<civodul>haha :-)
<mark_weaver>civodul, phant0mas: either an absolute pathname or maybe a file URL. I've definitely used one of those in the past.
<phant0mas>I used the absolute pathname for now
<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>I don't understand
<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>after unpacking bootstrap guile
<phant0mas>it runs a sanity check
<phant0mas>and this check fails
<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.
<phant0mas>but when I
<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>but I didn't run into this problem
<mark_weaver>(although I'm not certain that I ran "make check" at this stage)
<phant0mas>well I have 20 tests that fail...
<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>e.g. search for "armhf" in tests/packages.scm
<mark_weaver>probably there needs to be a case added there for hurd
<mark_weaver>phant0mas: ^^
<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
<phant0mas>will the the tests and be back
<mark_weaver>phant0mas: right, but did you change tests/packages.scm as well?
<phant0mas>no :P
<mark_weaver>(the redundancy is not ideal)
<davexunit>civodul: okay, thanks. I'll have to better handle that error.
<phant0mas>will check the tests and be back
<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>crocket: 'guix package -i <package>'
<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.
<davexunit>sorry folks
<davexunit>meant to send that to another channel :)
<crocket>davexunit, Did you use pacman?
<crocket>Do you know that pacman prompts choices among several backends?
<davexunit>crocket: I haven't used pacman in a couple of years now.
<davexunit>I went from Arch to Debian to GuixSD.
<crocket>I guess guix is a more stable base for completely automating system configuration.
<crocket>Does it offer zfs, thougH?
<crocket>ZFS on Linux is a pain in the ass.
<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
<crocket>Does guix refuse CDDL packages?
<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?
<davexunit>what is CDDL?
<crocket>Does Guix offer remote management?
<crocket>CDDL is a license.
<crocket>Common Development and Distribution License
<civodul>crocket: it's a free license, so it's fine for Guix:
<crocket>Will linux accept zfs in its code?
<davexunit>that's not a question for us.
<_`_>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>davexunit: sounds good
<_`_>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.
<_`_>Alright thanks
<crocket>Can guix automate third party guix packages?
<crocket>Can guix automate installing third party guix packages?
<davexunit>crocket: yes.
<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>Is it completely centralized?
<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.
<mark_weaver>(or you could merge upstream into it if you prefer)
<phant0mas>sneek later tell civodul
<davexunit>the Docker folks sure take security seriously
<davexunit>>bundle openssl
<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.
<davexunit>you'd have to find + load it yourself.
<nukke>it's possible to remove the stupid whitelist in the BIOS, but I'm incredibly lazy :(
<nukke>I guess I'll just do that.
<davexunit>nukke: that's what I did to my thinkpad.
<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>the whitelist is a real shame.
<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>gotta run. happy hacking.
<nukke>alright, see you later!
<davexunit>a usb wifi dongle would work, but would take up a usb port
<davexunit>anyway, later!
<civodul>i use the ThinkPenguin wifi usb dongle
<sneek>civodul, you have 1 message.
<sneek>civodul, phant0mas says:
<civodul>it works nicely, and without blobs
<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/
<phant0mas>until we have a more permanent solution
<civodul>i doubt it: in our case it's a static executable
<phant0mas>just thought about it as well
<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> and
<paron_remote>I wonder how hard it would be to kick guix up and running with that
<civodul>phant0mas: that might work, yes
<civodul>phant0mas: actually no, i remember now: nix/libstore/ uses basename(builder) as argv[0], not the absolute file name, so that doesn't work