<rekado>on 2016-05-05 is the next Open Tech Summit in Berlin. I wonder if I should submit a Guix talk proposal. I think it should be different from my last talk there. <rekado>I updated the icedtea-7 package yesterday but it seems that hydra hasn't yet started building it. ***kelsoo1 is now known as kelsoo
<ng0>i'll be at open tech summit too i think.. we have an open panel / talk in onionspace on 6th. <ng0>also, good thing guix exists.. debian backports are not ready for letsencrypt. <ng0>or it is functional and i forgot about apt-get -t switch <rekado>for some reason I cannot get a binary for icedtea-7. <ng0>sneek: later tell Jookia contact me in psyc://psyced.org/@libertad about the git repo for guix-outside-of-guix thing, i'll have the server ready soon. <iyzsong>I can't reproduce the test failure of i686 glib on my laptop... <wingo>iyzsong: what is the status of gnome-updates? <iyzsong>no, I think I have to disable the one glib test and waiting for rebuild again. <iyzsong>it's a simple task with the help of 'guix refresh', and the bettleneck is my slow machine and our unstable hydra :-) <wingo>are there mirrors of hydra.gnu.org now? <wingo>ah, i think my guix installation is not using mirrors <wingo>tfw you run guix package -u --no-substitutes <wingo>then you run guix package --no-substitutes -u and then it prints out "substitute: " and sits there for a while <ng0>the most recent typo i have very often is guix clone and guix push <ng0>debian is plain confusing. if i have git-core and i want git-daemon for git://, do i install git-daemon-sysvinit or git-daemon-run or both? <ng0>i just don't get their blend of init <civodul>ACTION prepares to dive into 159 unread Guix messages <df_>it would appear that the first is a script for sysvinit and the second a script for runit <df_>so given that the default init is systemd... neither? <df_>I suspect git-daemon-sysvinit will work if you're running systemd <ng0>the readme in /etc/init.d/ has a reference to sysvinit <ng0>and being used to sysvinit from back then on other systems, i am confused. <df_>ACTION is a stubborn holdout who runs debian with sysvinit for now <ng0>i'll just try sysvinit. <ng0>at least -sysvinit created a gitdaemon user etc ***orly_owl_ is now known as orly_owl
***parabool_ is now known as parabool
<koosha>I decided to install guixsd , but first I want to know how much will be needed to download during the installation . Thank you . <koosha>what should I download at all (during installation) ? <bavier>koosha: it depends on what packages you put in your operating system declaration <bavier>we typically recommend doing a "barebones" install at first <ADFENO>It really depends if you choose to allow GuixSD to use the build farm substitutes/built packages, and if the buid farm has a substitute/built package that has made to your archtecture, and also depends on what bavier is saying right now. :D <bavier>and installing packages later as a user once you've got guixsd installed <koosha>Thank you . what is "barebones" ? <bavier>koosha: see section 7.2.1 in the manual <bavier>which doesn't install a desktop environment <ADFENO>Barebones is a simple installation. It has the minimal packages needed. :D <koosha>Yes , I don't need such a graphical enviroment . Yes I'm using i3 with debian . <koosha>okay , so if I do a "barebones" install m how much will it be (for downloading) ? <bavier>koosha: a few hundred MB probably <wingo>guix should keep a scorecard <wingo>like, how many times have you rebuilt `tar' <wingo>you could be awarded with badges <wingo>maybe you could unlock an achievement and get a faster hydra }:-) ***jluttine_ is now known as jluttine
<bavier>quite a reaction on the ML regarding command-line interface <bavier>maybe we'll get a really nice shed out of the deal <taylan>the more I think about it, the more it makes sense to me to call package install/remove operations profile add/remove operations instead, but I'm prohibiting myself from getting a strong opinion :P <bavier>it sure would be nice if guix-daemon had some ccache support <davexunit>would probably result in nondeterministic builds <bavier>possibly, but ccache can be configured pretty conservatively <bavier>anway, might be a fun experiment <bavier>it would be like an additional level of memoization, like the store is for package builds <efraim>I haven't used ccache much, would it be useful to add to some packages like qt? <bavier>efraim: I use ccache at work a lot, where it works quite well <bavier>efraim: how do you mean "add to some packages"? <rekado>this is confusing; guix insists on building derivation /gnu/store/x4iqch8zv1mawhrqmiz4hhw6b92aqfgp-icedtea-2.6.5.drv locally even though it is available on hydra. <bavier>efraim: it'd need daemon support, in order to have cache results shared between builds <bavier>unless qt does funny stuff and recompiles source in its build <wingo>bavier: what cases would ccache work on that are not already caught by guix? <bavier>wingo: I was thinking for speeding up repeated builds of the same package <wingo>but if the inputs are different, would that work? <wingo>i mean, you only build a {package + inputs} once <wingo>unless the build fails of course <bavier>wingo: that's the case I'm considering <wingo>or you are checking to see if a build is reproducible <bavier>e.g. while working on a package and debugging the packaging <wingo>ah, like for webkit with patches or something <bavier>davexunit: I know there are smarter ways, but sometimes things just happen <wingo>to me it makes sense in a way, but the thing is that if you are building a proper package with patches then your --prefix is different every time <wingo>so ccache would detect the build as "different" i think <wingo>b/c usually prefix is passed to the build somehow afaiu <bavier>wingo: ccache has a fallback mode that checks the contents of the preprocessed source <bavier>and would match that in most cases I think <wingo>would it if PREFIX were defined as some kind of cpp var? <wingo>maybe with standard gnu builds supporting make install PREFIX=... <wingo>but i thought usually PREFIX ended up forming part of a cpp var <wingo>i guess the gnu thing is make install DESTDIR=... <rekado>something happened to my guix. I think my bootstrap binaries are broken. <rekado>it wants to build everything from source. <rekado>I didn't know this would happen. <rekado>downloaded the binary release tarball, resetting the timestamps and permissions <bavier>davexunit: I didn't mean to come off harsh; 'guix environment' is great, and I've used it to much fruition in this case, but still some silly issues in my guile code has made me rebuild this package several times, multiple hours of build each time <civodul>rekado: are you sure you correctly diagnosed the problem? <rekado>yes, the binaries have wrong timestamps and wrong ownership <civodul>the binaries in gnu/packages/bootstrap? <civodul>timestamps and ownership don't matter, but execution bits do <rekado>got the execution bits fixed (they were off), but it's not enough. <civodul>re icedtea, "./pre-inst-env guix build icedtea@2.6 -n --no-grafts" suggests there's no substitute for icedtea itself <rekado>I also get no substitutes for gcj <civodul>scheme@(guile-user)> (has-substitutes? s "/gnu/store/qrgb882bqcp01xn6pi18b68flyj1w6mc-gcj-4.9.3") <civodul>scheme@(guile-user)> (has-substitutes? s "/gnu/store/yjjwrzhczc234l450flbhhwnjc12yw8i-gcj-4.9.3-debug") <civodul>that is, mirror.hydra.gnu.org has a substitute for gcj's "out", but not for its "debug" <civodul>so if you type "guix build gcj", which builds all the outputs, it wants to build from source <civodul>whereas if you type "guix build icedtea@2.6", which needs only gcj:out, it downloads it