<mark_weaver>phant0mas: I said okay to pushing those patches, but then realized that the commit logs need some fixes. please wait until you get all the emails before pushing. <mark_weaver>phant0mas: I had commit log suggestions for all three commits, all now sent. <yenda>Is there any package for latex yet ? <yenda>ty, I searched for latex in the package list, maybe adding latex in the synospys could help ? <xentrac>weird, guix is compiling Bison *again* <xentrac>I think this is the third or fourth time <xentrac>it keeps failing because one or another source package has been removed from its previous URL, or because there's a temporary network failure, or because it's filled up the disk, or whatever <xentrac>I guess if any part of the build fails, it doesn't commit any of the previous build results? <xentrac>Maybe it's less deterministic than that <xentrac>Hmm, so after 18'41" it failed again in the same place as before, specifically <xentrac>starting download of `/gnu/store/5fsl6azm1imi4x69ajhl1yvb7n5frhf0-openldap-2.4.33.tgz' from `ftp://sunsite.cnlab-switch.ch/mirror/OpenLDAP/openldap-release/openldap-2.4.33.tgz'... <xentrac>ERROR: In procedure getaddrinfo: Name or service not known <xentrac>failed to download "/gnu/store/5fsl6azm1imi4x69ajhl1yvb7n5frhf0-openldap-2.4.33.tgz" from "ftp://sunsite.cnlab-switch.ch/mirror/OpenLDAP/openldap-release/openldap-2.4.33.tgz" <xentrac>now it could totally be that sunsite.cnlab-switch.ch is no longer a working host <xentrac>but I don't understand why that leads guix to rebuild GCC and Bison over and over again <xentrac>I'm pretty sure that past Guix build failures I've experienced were able to immediately fail where they failed before instead of computing for 19 minutes first. But maybe those were actually `guix pull` failures and I'm just confused. <xentrac>It's definitely compiling GCC again. This is so sad, you guys. <mark_weaver>xentrac: when a build succeeds, it is committed to the store and will remain there unless deleted by 'guix gc'. <xentrac>mark_weaver: Thanks! sorry I haven't gotten to that part of the manual yet <mark_weaver>however, if you have enabled multiple separate builds to happen in parallel, then if one fails then the others are immediately aborted (if started by the same 'guix' command) <xentrac>that would explain why it seems to sometimes compile new things before failing <mark_weaver>however, at some point we set the default number of concurrent jobs to 1 <xentrac>I haven't explicitly set a number of concurrent jobs, but I do see that all 8 of my "hyperthreads" are at 100% <mark_weaver>to set the number of concurrent builds to 1, pass --max-jobs=1 to each 'guix' command that does builds. <xentrac>I'll give that a try after this fails again :) <mark_weaver>(which is now the default, but you're using an old version) <mark_weaver>however, within each build, we *do* pass -j<N> to make to compile things in parallel <xentrac>however, all the processes I see in htop seem to be running out of /tmp/nix-build-gfortran-4.8.4.drv-0 <mark_weaver>having said that, there are multiple copies of 'gcc' and 'bison' compiled for each bootstrap <mark_weaver>if they have different hashes, then they are different derivations. <mark_weaver>if they have the same hash of some earlier attempt, that's when you can be sure that it's really the same derivation. <xentrac>I wonder if gcc might also be getting built sometimes as gcc and sometimes as, say, gfortran <xentrac>I think we can assume that it's more likely that I'm hallucinating all of this, including the laptop's existence, than that there is a hash collision <mark_weaver>well, yes, those are separate builds, although there is a lot of overlap between them. <mark_weaver>it's debatable whether we should have one 'gcc' package that has all the languages enabled, or separate packages. <mark_weaver>but for now, we're doing separate packages (although both C and C++ are provided by the same package, gcc) <xentrac>which results in redundant compilation? <xentrac>okay, then it's no big deal and actually probably represents progress <xentrac>I was mostly just worried that it indicated that it was not making progress <xentrac>Hmm, it seems to have failed a third time on OpenLDAP for the same reason <xentrac>weirdly it seems like a lot of the mirrors are down <xentrac>hmm, and ftp://ftp.lip6.fr/pub/linux/sunsite/ hasn't been updated since 2006 mostly? <xentrac>now it's building ATLAS from source. this is awesome! <xentrac>Hmm, it seems to have been stuck on this part for quite a while: starting download of `/gnu/store/96fy8dgs9p818zi63ypqw83xp10myi5a-psutils.tar.gz' from `ftp://ftp.knackered.org/pub/psutils/psutils.tar.gz'... <xentrac>Hmm, well, it still hasn't made any visible progress on psutils <xentrac>it's... blocked trying to read from a UDP socket connected to ip233.usw186.dsl-acs2.sea.iinet.com:fsp <xentrac>that's the weirdest way to do "FTP" that I've ever seen <xentrac>At this point it's been running for 43 minutes trying to fetch that file <xentrac>so I ^Ced the build process. it had fetched a bunch of other archives from different places <xentrac>I restrated it and now it's building bash <xentrac>well, it built a few more things, and now it's back to trying to read on a UDP socket connected to an FSP server on somebody's DSL line in Seattle <xentrac>I think I'll leave it like this overnight and see if it makes any progress >:) <xentrac>ah, it did in fact eventually time out: <xentrac>starting download of `/gnu/store/96fy8dgs9p818zi63ypqw83xp10myi5a-psutils.tar.gz' from `ftp://ftp.knackered.org/pub/psutils/psutils.tar.gz'... <xentrac>building of `/gnu/store/n0sdi0746nlmrpjs4m2k6vldyk7px6nw-psutils.tar.gz.drv' timed out after 3600 seconds of silence <xentrac>doesn't seem to be psutils_1.17.dfsg.orig.tar.gz from Debian <chipb>out of curiousity, anyone played around with using guix on 'vintage' distros such as centos5? <chipb>wasn't too difficult getting started by patching in an older glibc built for older kernel compatibility. <chipb>but I think I was seeing a bit of a snag using guix-built X11 clients. ***francis7 is now known as francis7-twin
***francis7-twin is now known as francis7
<tennix>i'm running guix on centos7 vagrant box <chipb>yeah, I would expect that to go a bit...smoother. <amz3>what goes smooth on an antic system? <ifur>my sudo is weird on guix to say the least gotto find out why hehe <amz3>davexunit: I have an idea for a non trivial use case for guix container: mozila addons website <amz3>there is mysql, elasticsearch and django <amz3>and various dependencies <davexunit>it seems extremely complicated to build it from source <amz3>since you agree, I'll start to package its dependencies, starting with python/django things <amz3>it's ok to put django in a django.scm ? <amz3>(I hope this time I will have time to test and publish my recipe last time Steap was too quick ;) <yenda->probably because django itself has a lot of packages in pipy <amz3>django has no dependency itself IIRC, but yes many things that are required like django-debug-toolbar <yenda->I am trying to package Leiningen, I don't think I'll be able to do it it's too complicated for me it's a bash that does stuff around when you exec it from /bin <amz3>yenda-: are you also working on guile clojure compat? <yenda->amz3: no I'm too newbie yet, it's just that I want to be able to do learn some clojure on guix too so I need leiningen <amz3>there is someone working on making it possible to run clojure with guile VM <yenda->amz3: that's nice, do you think guix can do leiningen job though ? <amz3>I don't know how it works exactly. With Python's pip I use virtualenv wrapper which installs packages locally. maybe leiningen has something like that <amz3>(Otherwise pip doesn't work with guix) <amz3>it's even possible to install packages locally using only pip <davexunit>though with 'guix environment' and our python packages the need for virtualenv and pip goes away :) <amz3>you still need packages, no? <amz3>yenda-: the proper way is to create packages for clojure software <yenda->amz3: for now I would like to use clojure on guix and even that I'm not sure how to do it :D <yenda->i thought leiningen would be the easy way but its not :( <davexunit>I think you need to get clojure to build first <davexunit>and see if you can run that on its own without any extra tools <yenda->at this point I'm looking at running a repl first <yenda->and be able to package a small project and run it <davexunit>it looks like you're trying to jump ahead when you don't have the basic foundation in place yet. <yenda->davexunit: well the thing is usually you just need to run lein.sh and you have everything you need to code in clojure <davexunit>that sounds like something that would make me vomit if I ran it. <davexunit>sounds like it downloads a ton of binaries that only god knows where they came from. <davexunit>and apparently more than I thought if he wrote this tool. <yenda->I just overlooked at it and it mostly do some path work <davexunit>can you get it to work without packaging it? <yenda->clojure and leiningen libraries yes <yenda->/bin/bash: bad interpreter: No such file or directory <yenda->shame on me it wasn't even the right script <yenda->that was the one I took from the nix package <yenda->i changed the path and It Just Works™ <ifur>on that, there should be a /usr/bin/env, more and more call that instead of bash directly (or anything) <yenda->packaging it might no be that hard after all <yenda->I guess if I replace the downloads by inputs <DusXMT>I agree with ifur, since people use the /usr/bin/env specifically for increased portability. For example, on FreeBSD, bash gets installed into /usr/local/bin/bash <yenda->davexunit: the install scripts is just an universal way to install it easely for anybody, but there is real packages for many distros including nix <davexunit>yenda-: all you need to do is package that script, it seems <davexunit>the gnu-build-system will patch the shebang to DTRT <yenda->but it will need the clojure.jar and leiningen.jar I assume. Maybe I can make them as inputs and deal with the build later <yenda->davexunit: it seems we have a problem in the jdk though <yenda->is it because we shouldn't use maven in guix ? <davexunit>in an ideal world, all of the necessary java packages will be in guix <davexunit>or otherwise easy to package via an automated tool <davexunit>but maven ought to work on guixsd in the way that it works on other distros <davexunit>and certificate checking works for other applications like git and icecat <yenda->On #leiningen they told me 'It seems like icedtea doesn't find/ship with any ca <yenda-> certs, which is the cause of it dying' <ifur>looking in the wrong place most likely <ifur>hmm, how many actually use guix you'd guess? <davexunit>we have had over 30 contributors since the project was started, I think <yenda->would be nice to fix icedtea having a working jvm would be nice <yenda->ty Oracle this piece is priceless anti-proprietary software propaganda :D <yenda-><hyPiRion> If that doesn't work, you could try out `export <yenda-> JAVA_OPTS='-Djavax.net.ssl.keyStore=/my/keystore'`, where <yenda-> /my/keystore is the location to the keystore on GuixSD <ifur>you only need to educated people on the alternative to propprietary software and the difference first, because out of ignorance they will assume that with ownership comes responsbility <ifur>and people won't retroactively care <mark_weaver>yenda-, davexunit: fyi, we lack a CA certificate store in the format expected by java programs, i.e. the jks (java key store) <mark_weaver>I don't know much about this, so I might have some details wrong. <yenda->the downside seems to be that we can't build maven stuff ? <mark_weaver>yenda-: my guess is that most java programs that need to check TLS certificates will fail for lack of a CA trust store in the format they expect. <yenda->mark_weaver: is it a guix problem or an icedtea problem ? <mark_weaver>the proper fix is to extend 'ca-certificate-bundle' in guix/profiles.scm to build the JKS based on whatever certificate packages are already included in the profile. <mark_weaver>however, it needs to be done in such a way that the JKS is only built if the user already has some java packages installed in their profile <mark_weaver>because building the JKS requires Java tools, and users who don't need Java shouldn't have to build+install it <mark_weaver>(especially since I'm not sure our Java packages even build successfully on non-Intel platforms) <mark_weaver>so, it needs to do something similar to what the 'gtk-icon-themes' and 'ghc-package-cache-file' procedures do. each uses some heuristic to determine if the user would want those things. <mark_weaver>in both cases, they look at the names of the packages. <mark_weaver>it's not a very satisfactory solution, but at present it's the best solution we have. <mark_weaver>the alternative: having *every* user need to install ghc, gtk+, and java, is unacceptable, especially since e.g. ghc isn't supported on MIPS at all. <mark_weaver>(ghc also involves downloading a pre-built binary of ghc, which entails putting our faith in yet another set of pre-compiled binaries) <yenda->damn that seems really cumbersome, I wonder how they deal with that on nix <mark_weaver>the easier, but lame-ass "solution" would be to simply make another package that installs only some fixed set of certificates in JKS format. <mark_weaver>so, right now we happen to have only one ca-certificates package: nss-certs, which are the certificates that come with NSS from Mozilla, the same set used by Firefox. <mark_weaver>however, the plan is to have multiple CA certificate packages, e.g. maybe one for cacert, and an easy way for users to create custom CA certificate packages with their self-signed certs. <mark_weaver>and of course some users might not actually want to trust the full set of CAs that Mozilla includes in their CA bundle. <mark_weaver>so, I'd like users to be able to install whatever set of CA certificates they want, and then all (or most) programs will trust that set of certificates. <yenda->I think I'm gonna go for the lame ass solution first <mark_weaver>the easy 'lame-ass' solution would mean that regardless of what certificate packages the user has installed, Java apps would ignore that and trust its own fixed set of CAs from Mozilla. <mark_weaver>but I'll probably resist incorporating the lame-ass solution into our upstream master branch. <yenda->it's just that I need it to work now <mark_weaver>that's fine, I would probably do the same in your position. <yenda->and then I'll grow up a proper solution from thee while still being able to work <mark_weaver>I have sometimes done similar things on my private branch of guix. <mark_weaver>at any given time I have several modifications that aren't yet ready to submit for inclusion. <yenda->the lame ass solution will probably still be hard because I don't even know exactly what these jks certificates are and what to do with them <mark_weaver>debian has a package to provide them. there's some java code that generates the JKS. <mark_weaver>you could even just copy the built JKS from debian for now, I suppose. <mark_weaver>before we had any CA trust store in guix, I simply copied /etc/ssl/certs from Debian to my GuixSD machine. <mark_weaver>yenda-: that's the package that does what we already have <yenda->I went for sid I guess it's more uptodate <yenda->I have icedtea installed but I don't have javac command available <yenda->it's written jdk and it's actually just a jre ? <davexunit>yenda-: there are multiple outputs of icedtea <yenda->but if I do guix package -i icedtea7 ? Isn't it supposed to give me the javac command <davexunit>in guix, we split packages into multiple "outputs" sometimes <davexunit>in the case of icedtea7, the jdk and docs use a lot of extra disk space that users just wanting the runtime do not need <wgreenhouse>I guess I could look at the config for the installer image <davexunit>wgreenhouse: can you explain more about what you mean? <wgreenhouse>davexunit: yes, I am hoping to use guix to build liveusbs with custom package loads. my ultimate goal would be to make custom run-from-RAM systems, in the style of TAILS or Tin Hat <wgreenhouse>davexunit: it's attractive that with guix, the liveusb could be used to build future versions of itself <davexunit>wgreenhouse: you are correct that you want to use 'guix system disk-image' <wgreenhouse>davexunit: cool, is the operating system definition for installer image in the guix repo somewhere? <mark_weaver>wgreenhouse: see 'installation-os' in gnu/system/install.scm <mark_weaver>also see section 6.1.5 (Building the Installation Image) of the guix manual <mark_weaver>wgreenhouse: I'm also interested in building TAILS-like systems using Guix. I'd be glad to see what you come up with! <davexunit>it's fantastic that guix provides a framework for a wide variety of projects <mark_weaver>you will likely discover limitations in our ability to create ready-to-run systems with our existing OS configuration system, and we should work through them. <wgreenhouse>mark_weaver: I guess another potentially useful feature for this would be a way to specify "persistence" (COW-to-disk) choices for parts of the live system <mark_weaver>e.g. I don't know that we currently have any way to populate home directories with custom files <wgreenhouse>ideally this would be from the kernel command line, like debian live does it as exploited by tails <mark_weaver>wgreenhouse: sure, makes sense. /proc/cmdline provides the kernel command line, and arguments are already extracted from that by our initrd code (in gnu/build/linux-boot.scm) <wgreenhouse>mark_weaver: could `configuration-template-service' in install.scm be a good guide for a dummy one-shot service that installs user stuff like custom dotfiles? <davexunit>wgreenhouse: maybe mark_weaver has additional thoughts, but I think the service layer is the appropriate place for manipulating files in home directories <mark_weaver>wgreenhouse: I'm not sure what's the best approach, but for now I would start with something similar to 'configuration-template-service' and we can always change it later if we find a better idea. <wgreenhouse>`user-skeleton-service' perhaps--a guixy counterpart to the traditional /etc/skel/ :) <mark_weaver>so, we currently have something to do that, in 'copy-account-skeletons' in gnu/build/activation.scm <mark_weaver>I haven't thought much about this, but off the top of my head: I'd guess that ideally we'd want those things to be configurable somehow in the 'user-account' records. <bavier`>ACTION is trying to build guix on old SLED 11 system <mark_weaver>but IMO it would be a mistake to block this work waiting for the ideal solution to be found first. <davexunit>mark_weaver: the issue I see is that /home/<user> isn't a place where we do atomic upgrades and rollbacks and things. it's stateful. <mark_weaver>well, /etc is also stateful, but there are stateless managed things inside of it. <mark_weaver>the same could be true of the user's home directory. there could be selected bits in there that are managed by guix. <davexunit>in my head I've designated the service layer to be the place to manage these things <davexunit>I did some thinking on this when I was trying to figure out how to populate .ssh/authorized_keys automatically <mark_weaver>I dunno, it seems a little hackish to me to put configuration having to do with a user account into a "service" whose job is just to populate the user's home directory with some files. <mark_weaver>but admittedly I haven't thought about it very long, so maybe with more thought I'd come around to your POV :) <mark_weaver>but I'll certainly agree that it's the way to do it with what we have today <wgreenhouse>re: user files persistence on an otherwise amnesic live system, I guess I could try to use stow :) <davexunit>mark_weaver: yeah, well maybe for this particular case it's not a good idea, but it certainly seems to be the way to go for things like making sure a db cluster is created in /var/lib/postgresql and other such things <davexunit>and the service layer is also trivially extensible, you can write whatever services you want. <wgreenhouse>okay, more pedestrian problem: I have an old Atom netbook with an Intel 945GM GPU, and my screen goes black early in the install image unless I pass "nomodeset" to the kernel command line <wgreenhouse>this seems to be something that broke around kernel 3.18 <wgreenhouse>probably therefore an upstream linux problem, I see it with non-guix liveusbs too <wgreenhouse>it's too bad as "nomodeset" means no i915 X server either <mark_weaver>wgreenhouse: you should probably create your own kernel package that uses linux-libre 3.14 (a long-term support release) <wgreenhouse>mark_weaver: yeah, afaict 3.14 is old enough :) thanks <mark_weaver>I've been meaning to make our kernel packages more flexible, and to add some LTS kernels. <mark_weaver>if you use one of his configs for 3.14, it should be close in spirit to what we have in our newest kernels. <mark_weaver>the 'wip-loongson2f' branch in our git repo includes a commit that adds a 'linux-libre-loongson2f' package, which mostly inherits from our main package. <mark_weaver>but in this case, you will want to completely replace the 'source' origin with one that gets a different version. just copy the <mark_weaver>'source' from linux-libre and change the version number and hash. <mark_weaver>and then set the 'kernel' field in your OS config to use that other kernel. <yenda->by what can I replace arch=`dpkg --print-architecture` ? <yenda->(still trying with certificates) <DusXMT>But I guess it might not be accurate in all cases, eg. 32bit Guix on a 64bit main system (not GuixSD) <DusXMT>I think I've realized why we have a /bin/sh; it's not really for the convenience of scripts, but to get the `system ()' call working (it executes "/bin/sh -c 'command'") <yenda->codemac: how are you doing with go ? <codemac>yenda-: hi! it's going well, it builds and everything, but mark_weaver (rightly) wanted me to tease some stuff apart into build steps with gnu-build-system. I'm also developing a go-build-system, but I should probably hold off on that. <mark_weaver>yenda-: why do you need to know the architecture to install CA certificates? <mark_weaver>uname -m is best avoided, since it's not deterministic (depends on the particular machine details) <mark_weaver>(%current-system) returns a nix system string, e.g. something like "x86_64-linux", but I don't see why you'd need it for this. <yenda>mark_weaver: it's the debian script to build certificates <yenda>i gave up and just took the certificates from a debian directly <yenda>now I'm looking at how to use them <wgreenhouse>in current guixsd, is it possible to achieve full disk encryption except for grub+kernels+initrds? <xentrac>chipb: I'm trying to run guix on Debian oldstable, but I don't think that's as hard as centos5 <xentrac>curl fails its tests and I don't know what to do about that: <xentrac>: user@debian:~; time guix package -i python-ipython python-numpy <xentrac>if this were a regular, non-guix build I think I would know what to do next: go into the build directory and rerun the test from the command line, possibly stracing and otherwise instrumenting various components until I figure out why the cookies aren't going into the cookie jar <xentrac>but I can't go into the build directory because it isn't there any more <amz3>there is an option for that <xentrac>I should probably already know what that option is, shouldn't I? :) <mark_weaver>wgreenhouse: at present, we lack the logic in our initrd (gnu/build/linux-boot.scm) to handle mounting an encrypted partition, so we do not yet support an encrypted root partition. <xentrac>I don't know where to start looking. (and I still haven't finished reading the manual! shame) <mark_weaver>xentrac: pass -K (--keep-failed) to any guix command that builds packages, and when a build fails the builx directory will be left in /tmp/nix-build-* <xentrac>there's also the meta-question of how this situation could arise. presumably this version of curl has compiled successfully from these exact sources with these exact dependencies and compilers on many other guix users' machines <mark_weaver>in there, there's a file with environment variable settings <mark_weaver>you may also need to chown -R the build directory to your user <mark_weaver>but you probably don't want to leave it around in /tmp, dunno. <xentrac>yeah, I'd hate for my /tmp directory to look like my kitchen counters <mark_weaver>xentrac: quite a few of our packages fail their test suites non-deterministically. <mark_weaver>often, attempting the rebuild again without any changes leads to success. <xentrac>it seems to be deterministic (it's failed this test four times in a row) <xentrac>although it's a little hard to tell, since as you can see from the gist, it takes several minutes to fail <amz3>xentrac: you run make check? <xentrac>hmm, seems like make test in the copied curl directory is failing every test with an "Illegal instruction" <xentrac>because now libtool is able to invoke /usr/bin/valgrind <xentrac>which is now the Debian /usr/bin/valgrind <mark_weaver>xentrac: you need to load the environment variable settings that are in the /tmp/nix-build-* directory <xentrac>I suppose being able to re-execute curl's `make test` in a little isolated compartment, like the guix builder does, has to wait on davexunit to finish making those containers more generally usable? <mark_weaver>even then, things might be somewhat different because now it's not in a build container, it can find things in /usr if it looks, etc. <davexunit>it won't be able to find any of that with 'guix environment --container' <xentrac>since I don't really want to pass arbitrary strings from web forms to an unaudited C++ executable running in my user account :) <xentrac>but if it's in a separate uid and can't talk on the network or access the filesystem, it might be an acceptable risk <xentrac>since it's a batch-mode input-output thing, I could probably actually do that already with guix <xentrac>anyway. that's probably enough for today :) <yenda>anybody tried watching HD video with VLC on guix ? <yenda>it seems like the GPU acceleration is disabled. CPU is at 100% and all frames are dropped <mark_weaver>yenda: I've been unable to get vlc to work correctly. I recommend using 'totem' instead. <mark_weaver>on my Libreboot X200 running GuixSD, totem can play HD video quite well, but then I have working graphics acceleration so your mileage may vary.