<sprang>when I do 'guix package -u' I see a bunch of packages marked for upgrade that don't seem to have changed (e.g. cmus 2.7.1 → 2.7.1) <sprang>these get downloaded again, which seems unnecessary... what am I missing? <fps>sprang: their version hasn't changed but maybe some dependency changed <fps>maybe guix package -u should show the input hash, too <fps>which has changed very likely <piyo>fps: I would like to see which dependencies change on these same version update ... Currently I get emacs 24.5 -> 24.5 git 2.5.0 -> 2.6.3 uh emacs doesn't depend on git does it? <lfam>note: source file ... newer than compiled ... <lfam>That should go on a t-shirt <piyo>;-) at least its checking for you <sprang>paroneayea: my clock was reset to 1970 after rebooting too (X200)... first time that's happened. I just reconfigured for the first time in a few weeks. <efraim>how do I reset my guix checkout so its using automake-1.15 instead of automake-1.14? <amz3>efraim: you might be able to edit guix autoconf file to use automake 1.15... <efraim>i thought about that, not sure its a good idea <piyo>more offtopic from me but, autoconf version numbers are getting close to emacs levels of minorness <efraim>it could be worse, look at openssl <piyo>"Early versions of GNU Emacs were numbered as "1.x.x," with the initial digit denoting the version of the C core. The "1" was dropped after version 1.12 as it was thought that the major number would never change, and thus the major version skipped from "1" to "13". A new third version number was added to represent changes made by user sites.[6]" <piyo>i dont know openssl, but it sounds like yet another oddball <rekado>IcedTea8 was successfully built. <rekado>will try the unreleased icedtea9 next. <rekado>only problem is that I cannot easily download the tarball with Guix because the Guix HTTP client is stricter than wget. <fps>rekado: there's a bug report about it, already. it's about a ETAG header right? <fps>it's guile's http client really <fps>i can't find the bugreport though. <fps>sneek: later ask civodul: do you remember the guile but report about too strict parsing of headers (re ETAG) <fps>sneek: later ask civodul: *ask <fps>sneek: good bot! botsnack! <rekado>fps: yes, there's a bug report about it. <rekado>I should let the admins of icedtea.classpath.org know that this is broken. <rekado>unfortunately, we don't have a hg-fetch procedure yet, so I cannot just download the repository. <rekado>I really like how much simpler the build recipe for icedtea8 has become. <rekado>I'm now trying to simplify our previous icedtea packages. <rekado>I wonder if we should provide an internal wrapper around the "jar" tool to make sure that "jar" archives are reproducible (i.e. without timestamps). <rekado>or we could patch fastjar (already found the lines that need patching) and use that instead of the JDK's jar tool. We'd then have to make sure that when jar archives are built we use the patched fastjar instead of the JDK's jar tool. <rekado>oh, there is no icedtea9 because there's no jdk9. Oops. <rgrau>Every 'guix pull' takes forever, no matter how long I did the last 'guix pull' before. Isn't it supposed to just download latest guix (with new recipes) and update what's to update? . It seems it's recompiling everything every time. (bout 500 files every time) <rgrau>ah, it may be compiling the recipies... still. kinda slow <davexunit>this is the simplest thing that works every time, but we all recognize that there's much to improve from here. <rgrau>all packages in the system? Is there a way to (or, does it makes sense) do something like 'apt-get update', so that next packages I get are updated, but I don't have to recompile everything? <davexunit>'apt-get update' is entirely different from how guix works <davexunit>but yes we would like a more incremental update approach <davexunit>it's just not clear how that should work yet <davexunit>I don't use 'guix pull', I just use my own git checkout <rgrau>your git checkout to get the new versions of the recipies from there, I guess... <davexunit>and then I symlink ~/.config/guix/latest to that git repository <davexunit>and then all the guix tools use my git checkout <rgrau>regarding how fundamentally different it is 'apt-get update' from getting latest versions of gnu/packages/*.scm, is there anywhere where I can find docs on the internals of guix? I'm missing some parts there <rgrau>s/internals of/design behind/ <fps>rgrau: guix pull just updates guix and the package recipes. the compilation is just compiling the scheme files to a bytecode. it does not update installed software <davexunit>we need to do better with our messaging. there's someone on guix-help that after many messages still doesn't understand why we would build our own Java binaries from source. <davexunit>we need something that clearly explains why using pre-built binaries negates our goal of reproducibility <rekado>davexunit: I'm at a loss here. I don't know how this misunderstanding came about. ***marxistvegan_ is now known as marxistvegan
<rekado>Debian also rebuilds jars and does not just fetch them from Maven. <davexunit>why would someone refuse to use binaries that came from anywhere but maven? <davexunit>and I guess we are also duplicating the work of the Scala people -_- <rekado>bah, I thought I'd package up gradle (yet another Java build tool), but of course it must use gradle to be built. <rekado>but I don't need to bother at this point because it's actually written in Groovy, so I'd first have to package Groovy... <rekado>Java is a joke where the punchline is Java. <davexunit>maybe I'll throw this idea out here, I suspect it's either already done by software I don't yet know of, or is a dumb idea. <davexunit>I'm interested in how to best handle secret management for automated system deployments. <davexunit>you know, the state that the Guix configuration system cannot do anything with because it would be a security issue. <davexunit>how does one provision secret keys onto a large number of GuixSD machines in a secure way? <davexunit>I thought of an application that uses a simple client/server model to store an arbitrary number of encrypted secrets, decryptable only by those who are authorized to use them. <davexunit>and via a client you could say something like "please retrieve the encrypted secrets that I have tagged with 'web-server-keys'" <davexunit>the server would *never* encrypt or decrypt secrets. <sneek>Welcome back civodul, you have 3 messages. <sneek>civodul, lfam says: I remember you sharing a link that describes Nix's analogue of `guix graph`. I seem to remember it involved scraping the recipes. I just can't find the message now. Do you remember the link? <sneek>civodul, fps says: do you remember the guile but report about too strict parsing of headers (re ETAG) <cehteh>its more about passing security tokens to client <cehteh>ugly to set up, but when it works its nice <rekado>ha, and groovy also needs gradle to be built. It's perfect. <rekado>hmm, there's a Gentoo ebuild for Groovy that sidesteps the need for gradle. It's a little messy, but it's good to see that it works. <davexunit>would anyone be willing to try a little experiment for me? trying to reproduce a bug in the new version of Guile. <davexunit>guix environment --ad-hoc guile-next -- guile <davexunit>an error that will make you question your sanity <rekado>I get this: No variable bound to u32vector-set! in module (guile) <davexunit>rekado: that's what I get, thanks for confirming. <davexunit>I filed a guile bug report about this last night <davexunit>both good and bad to know that it's not just me. <rekado>I didn't see this on my machine. <mark_weaver>civodul: I fixed the 'fuse' source URI in 826244f01a, which is included in evaluation 108602 on hydra, but that evaluation still uses the old derivation /gnu/store/kvq9rcc4a0dn5bcigyklzzakfmjwyf85-fuse-2.9.4.tar.gz.drv which includes the incorrect source URI, so all the builds that depend on 'fuse' are still failing even when I explicitly restart them. any idea how to fix this? <mark_weaver>since it's a fixed-output derivation, does that mean that the *.drv filename in the store doesn't change even when the URI changes? if so, how is that handled when the URI changes? <mark_weaver>maybe the expedient solution is to run "guix download" on hydra and maybe use "guix gc -D" to delete the outdated *-fuse-2.9.4.tar.gz.drv on hydra <mark_weaver>well, I did "guix download", but I guess the gc will take a while <civodul>davexunit: i get the u32vector-set! error too! <civodul>mark_weaver: either 'guix download', or clear the failed build <mark_weaver>civodul: I guess that clearing the failed build would be insufficient, because the *.drv file still contains the old source URI, or no? <mark_weaver>also, restarting builds via the web interface seems to clear failed builds. <civodul>mark_weaver: actually fixed-output derivation failures aren't cached <civodul>doesn't "restart dependency-failed builds" suffice? <mark_weaver>civodul: I try to avoid using "restart dependency-failed builds" when the number of builds to restart is manageable, because it restarts a lot of builds that are almost certain to fail again anyway. <mark_weaver>civodul: does the filename of a fixed-output derivation depend on the builder, or only the resulting output hash? <mark_weaver>if the *.drv filename depends only on the output hash, that seems to me to be a design flaw <mark_weaver>actually, I take that back. I guess that's the way it has to be, so it's not a design flaw. <civodul>mark_weaver: the .drv file name depends on everything, as with other .drvs <civodul>thus, in the case of fixed-output derivations, there can be several .drv mapping to a given store item <fps>rekado: what was that cool fx board thingie called again? <rekado>can't use it right now because there's no way I can build OpenJFX. <rekado>that needs gradle, which needs gradle and groovy, which needs gradle. <rekado>I'll see if I can put together a different toolchain for this board. <rekado>in the end it just uses GCC to compile patches, so this should be manageable. <efraim>I have a massive python patch-set building up on my computer <rekado>for this axoloti board I'll need a cross-compiler toolchain for ARM. <rekado>do we have something that works reliably? <davexunit>civodul, rekado: reminds me that our AVR toolchain is still busted :( <swedebugia>its really good and we have git:send-email packaged I just saw & installed <rekado>davexunit: I wonder why xgcc-armhf passes both binutils and libc, but xgcc-avr only comes with the binutils. <rekado>AFAIR I needed to install the avr libc anyway, so maybe it should be part of xgcc-avr. <davexunit>rekado: but even with the avr-libc, we are missing a lot of libgcc.a files for supported chips <davexunit>I don't have the data, but I checked the debian system on my novena and we were missing a ton of stuff for an unknown reason. <davexunit>it isn't clear why that happens, and tweaking our gcc build is surprisingly difficult