<NiAsterisk>wow. I know why I disabled join/quit/part for a long time <NiAsterisk>I am looking at the checks kyotocabinet runs.. that's a long list.. is it really necessary to run additional functionality tests on top of that? <lfam>Can anyone say if this is expected? <Jookia>NiAsterisk: Depends- running checks makes sure the software works <NiAsterisk>I hope to find the lines where they explain how to run the examples <NiAsterisk>and then htere's a long list of tests and examples running, which should be enough <mark_weaver>lfam: disabling parallel builds/tests merely inhibits the addition of -j<N> in the call to 'make'. <mark_weaver>it's possible that guile-ssh's build system is adding that flag on its own in a recursive call to make, dunno. <lfam>I looked at the hydra pages for each arch. The build history seems flaky <lfam>I'm going to send the libssh / libssh2 patches and we can deal with guile-ssh separately <NiAsterisk>oh. run ./configure with lzma, lzo or zlib? If gnu-build-system just picks the default, it's zlib, otherwise I can pass for example lzo which is GPL licensed <NiAsterisk>or does it not matter? i personally don't care that much. <Jookia>NiAsterisk: it probably doesn't matter <mark_weaver>NiAsterisk: I would just let it use its default, unless you have good reason to see an advantage to another choice. <mark_weaver>(I have no idea how this will affect the resulting software functionality) <mark_weaver>if someone later cares, they can propose a patch to change it :) <Jookia>Time to test my patches against my rebased and rebuilt GuixSD <NiAsterisk>was there something to point out in the definition which architectures are compatible? <lfam>mark_weaver: patches sent to the list <NiAsterisk>there's exmaples/Makefile and it can build and run 6 or so example databases, read write open close etc.. I can append this 2nd build to the build arguments, right? <NiAsterisk>i'll grep the packages.. should be something to find this night <detrout>Is there a recomended way to refresh guix patches? <lfam>mark_weaver: I accidentally sent the wrong version of the patches <NiAsterisk>detrout: updating to a new version in the package file? <lfam>Actually, I think the patches are good, but the annotation is wrong <lfam>detrout: Check `guix pull` in the manual. That will update you to the latest package definitions and guix tools <detrout>NiAsterisk: Yes. e.g. I'd like to use python 3.5 but the patches are against 3.4 <detrout>lfam: but what if guix master is still out of date... ;) <lfam>Then you'll need to update the packages and send your patch to guix-devel@gnu.org ;) <detrout>so with debian you have the source tree checked out and your out of date patches in debian/patches <detrout>you try to apply it, fix the patch, and then do quilt refresh to update the patch <detrout>wasn't how you had the source tree to try to apply the patch against with guix and its daemon. <lfam>mark_weaver: 2nd try sent <lfam>Oh, you mean patches on the upstream source <lfam>Yes, you'd need to adjust the patch on upstream's source, and then try rebuilding locally from a git checkout of Guix <lfam>So, you'd clone our git repo, build from source, make your changes and commit, and then `./pre-inst-env guix build foo` <lfam>The `./pre-inst-env` exports a bunch of environment variables that mean you use the Guix tools and packages in the git repo <NiAsterisk>this is bad to grep.. how would I search for a package which runs 2 cmake based builds? <lfam>But if you build from git correctly, you share the store and associated metadata in /var/guix <mark_weaver>detrout: when building from source code, make sure to pass --localstatedir=/var to ./configure <lfam>NiAsterisk: Sounds like a job for Scheme <detrout>mark_weaver: Hm? what is the purpose of that? <lfam>That will ensure you can share the store and metadata with the "system" Guix <NiAsterisk>I mean, runs the normal job, and afterwards runs one again with examples/Makefile, which runs make test <mark_weaver>detrout: the sqlite database of stored packages are in localstatedir. if you already have a guix install, you need to ensure that the newly build guix looks in the same place for that database. <NiAsterisk>the examples one runs a set of practical tests in addition to the ones by the main make <detrout>oh i understand ... when you build guix out of git you need to point it at the installed files. <mark_weaver>and there are some other things in there besides the database too <detrout>If one were to uninstall guix, should /var/guix disappear? <lfam>Jookia: I believe detrout is working on an out-of-tree Debian package for Guix <mark_weaver>detrout: if you wanted to purge everything related to guix from a system, then /gnu, /var/guix and /var/log/guix would be the things to delete. <xd1le>in case my message was lost in that freenode reconnection stuff, anyone know how to handle starting X for window managers? <Jookia>/var/guix is linked to /gnu in a way so if you keep the store you should keep /var/guix <lfam>NiAsterisk: Sounds like a big yak <mark_weaver>xd1le: at present, the only supported way to start X on GuixSD is to use the 'slim-service' <xd1le>mark_weaver: ah sweet, is there an example somewhere? <mark_weaver>xd1le: just add (slim-service) to your services. it's included in %desktop-services. see gnu/system/examples/desktop.tmpl for an example desktop OS configuration file. <mark_weaver>detrout: as Jookia hinted at, if you delete /var/guix then /gnu/store will be considered invalid, and you might as well blow it away as well. <xd1le>mark_weaver: thank you, so something like (services (slim-service)) ? <NiAsterisk>lfam: you know any easy solution? otherwise I'll just spend some time looking at guix packages and see how to solve what I thought of <detrout>I was only wondering wanted do dpkg --purge guix (equivalent of make uninstall) <lfam>NiAsterisk: I don't totally understand the problem. Could you solve it by adding a phase with (modify-phases ...), and then manually invoking some command in that phase? <mark_weaver>xd1le: a few things: (1) the 'services' field wants a *list* of services, and (slim-service) only returns a single service. (2) you need more services than that, %base-services at the very least, so (services (cons* (slim-service) %base-services)) <mark_weaver>but you should probably look at the other things present in %desktop-services, which is defined in gnu/services/desktop.scm <NiAsterisk>possibly.. I'll try. but maybe tomorrow is a better time. <NiAsterisk>the thing was, I was told just make check is not enough for databases, I should run practical tests <lfam>NiAsterisk: Do you mean that you want to add tests that we create? <lfam>I'd rather just run upstream's tests <lfam>It seems like a lot of work to make our own test suite, if that's what you mean. <mark_weaver>detrout: I'm not sure if "dpkg --purge guix" should remove the entire store. that might be considered somewhat analogous to "dpkg --purge postgresql" deleting the databases. <xd1le>mark_weaver: ah i see, so desktop service is appropriate even if just running a window manager? <mark_weaver>detrout: are you working on a Debian package for Guix? <NiAsterisk>no.. there's make which includes a couple of functionality tests (lots of them), and that's what for example gentoo only does, and then there's examples/Makefile in thesource which provides practical oriented tests. i don#t know kyotocabinet so i can't judge <xd1le>e.g. i see that ntp is not in base services <detrout>worked on, and am curently running it. <detrout>though apparently my postrm script is incomplete <lfam>NiAsterisk: In that case, I'd say we could run them. <mark_weaver>detrout: are you a Debian developer? do you expect to be able to get this in upstream Debian? <detrout>mark_weaver: Yes I am a Debian Developer. No I don't think it can go into Debian <lfam>NiAsterisk: If you do a search like this in gnu/packages, you will find some examples of what to do: `grep -rI -A10 modify-phases | less` <detrout>As I understand it, Debian wants to build from source, and there are 4 binaries and one archive downloaded directly from guix. <mark_weaver>detrout: please pass --localstatedir=/var for compatibility with the Guix installed by our binary installer. <Jookia>mark_weaver: Maybe I should probably submit a patch setting this to default, I brought it up on the mailing list a while back and people seemed to think something needed to be done <NiAsterisk>lfam: i know something about modify phases by now, but what I think about is, I run the main make, then I run the make of the tests, and when both finish I let the actual build finish, in theory <detrout>mark_weaver: currently with that rules file i have a /var/guix directory. dh_auto_configure sets a lot of options magically <mark_weaver>Jookia: i suspect that civodul will object, but feel free to try <mark_weaver>detrout: even if you don't use binary substitutes, everything built by Guix ultimately starts from bootstrap binaries that we provide. no part of the host system is *ever* made available in the build containers. <Jookia>mark_weaver: Are the bootstrap binaries downloaded when building Guix from source? <mark_weaver>Jookia: they are included in the source tarball, except for guile which is downloaded by 'make'. <Jookia>interesting. and these binaries aren't reproducible? <detrout>mark_weaver: and the hasehs of the boostrap binaries are used to compute the hashes in the /gnu/store/<hash>-package names? <mark_weaver>detrout: yes, if the bootstrap binaries change, then the hashes of everything else will change as well. <detrout>Yeah. that's probably the reason why getting guix into debian will be hard <detrout>the hard answer is since everyones trying to build reproducable binaries, maybe it'd be possible to rebuild them from debian components and get the same hash <mark_weaver>Jookia: that's a good question. I can tell you that the guile bootstrap is not reproducible, because guile's macro expander is not yet deterministic (still working on fixing that). as for the other bootstrap binaries, I don't know. <Jookia>mark_weaver: Does it really hash the binaries, can I note make the bootstrap binaries and replace them? <mark_weaver>but we certainly would like to have a documented method to produce all of the bootstrap binaries deterministically from a diverse set of starting systems. <lfam>Indeed, that would be a nice side project <mark_weaver>there's no way to change them at all without changing all the hashes on top <Jookia>Hmm, will that mean a full rebuild once the binaries are reproducible? <mark_weaver>we haven't changed the bootstrap binaries in a long time <lfam>Maybe we should have tracking bugs reports on making each one reproducible <lfam>I'd be willing to help work on this <mark_weaver>the current bootstrap binaries for x86_64 and i686 are from 2013-11-10 <lfam>It would be really cool if we could do it <lfam>I'd probably need a faster computer if I was going to really try this <lfam>I don't think I could do it on my own. Or at least, it wouldn't be efficient. Hopefully at least one other person will be motivated to help <lfam>I'll review the archives first <Jookia>lfam: I'll help on ARM and x86_64 but I don't know how <lfam>We have to bootstrap our knowledge too ;) <lfam>It might be worth it to try to upgrade diffoscope to the latest version <lfam>I looked into that recently and it was really involved <detrout>So ... why might guix not be able to find one of the declared patches? In the python source block it's not able to find python-3-deterministic-build-info.patch, but it can find the other patches. <NiAsterisk>hm.. (add-after 'somethingbla (lambda _ (zero? (system "make" "someplace thing" "where the examples/Makefile is")))) reads like theoretical code which could run after a make to make again? <lfam>NiAsterisk: (add-after 'check 'something ...), otherwise looks like a good start <paroneayea>detrout: when's the last time you ran ./bootstrap.sh && ./configure? <paroneayea>it looks like the patch is listed in gnu-system.am... <detrout>paroneayea: I copied the define-public python version 3.4.x block to a new file, and updated the version and hash <detrout>I did GUIX_PACKAGE_PATH=(path) guix package -i python-3.5.1 to install the new version <NiAsterisk>lfam: hm. so I need to squeeze this (make, make check (which runs tests)) in after make check and before make install of the binaries. looks like this should work <detrout>if python-3-deterministic-build-info.patch isn't commented out guix package -i python3.5.1 fails with error <patch name>: patch not found <detrout>but the baffling thing is it find the other patches. and they seem to be in the same directory. gnu/packages/patches <mark_weaver>detrout: is python-3-deterministic-build-info.patch in there too? <mark_weaver>are you running a copy of guix that you installed with "make install"? or are you using ./pre-inst-env to run it directly out of the build directory? <detrout>i installed 0.9.0 and then I updated my source tree. <detrout>so it may be looking at the installed source tree.... <mark_weaver>detrout: does ~/.config/guix/latest exist? if so, where does it point? (it would be a symlink) <mark_weaver>detrout: the profile is created the first time you install a package with "guix package -i" or similar <xd1le>i can't git clone from anywhere, it keeps saying "Problem with the SSL CA Cert" <xd1le>funny thing is it worked fine yesterday <xd1le>the only thing notable i did i think was run `guix gc` <mark_weaver>xd1le: for the git in Guix, the GIT_SSL_CAINFO environment variable needs to be set to point to a single-file bundle of CA certificates. <detrout>mark_weaver: guix package -i bash and it's defaulting to using /var/guix/profiles/per-user/<username>/guix-pofile/bin <mark_weaver>on GuixSD, or on Debian (or derivative) systems, it should normally be set to /etc/ssl/certs/ca-certificates.crt <mark_weaver>detrout: ~/.guix-profile should be a symlink pointing to /var/guix/profiles/per-user/<username>/guix-profile <lfam>It does happen automatically <mark_weaver>detrout: the ~/.config/guix/latest symlink is created by "guix pull". it normally points to a directory in /gnu/store which the result of building the latest guix from git. <detrout>I do have a .guix-profile/bin, I don't yet have a ~/.config/guix/latest <detrout>but then I haven't run guix pull. I did git pull ; make <mark_weaver>detrout: when that symlink exists, 'guix' mostly ignores the code that you installed with "make install" and uses the copy that was built by "guix pull" instead. <mark_weaver>on the client side, anyway. guix-daemon would still be the version that you installed at "make install" time, but that can be old. <mark_weaver>the daemon is very generic. even a very old daemon can build the latest versions of packages. <xd1le>mark_weaver: yes your are correct, it is set to /etc/ssl/certs/ca-certificates.crt. however /etc/ssl is a symlink to /run/current-system/profile/etc/ssl which doesn't exist <mark_weaver>detrout: a hack that some of us do is to manually create the ~/.config/guix/latest symlink to point to our built git checkout. <detrout>I was wondering if in an ideal case the compiled guix scheme code should go into /gnu/store or /usr/share/guile/site/2.0/guix <xd1le>not even /run/current-system/profile/etc exists <mark_weaver>xd1le: you need to add nss-certs to the 'packages' field of your OS config to include the CA certificates from Mozilla. <mark_weaver>and then rerun "guix system reconfigure" and then the certificates will be there. <mark_weaver>detrout: "guix pull" is roughly analogous to "apt-get update". <mark_weaver>if you never run "guix pull" (and don't run guix from an up-to-date git checkout), then you'll be using old packages, e.g. missing security updates since the last release. <xd1le>mark_weaver: thanks, i shall try that. any idea why git cloning worked before though? <detrout>so you use the symlink trick instead of adding your guix clone to GUIX_PACKAGE_PATH? <mark_weaver>adding an entire git checkout to GUIX_PACKAGE_PATH is probably a bad idea. <mark_weaver>if you want to run guix from git, then either do the symlink trick or use ./pre-inst-env <detrout>yes after doing that guix package stopped working <lfam>detrout: GUIX_PACKAGE_PATH should point to package definitions only, rather than a full Guix code base. <detrout>Ah... but you need to build your git checkout correctly. <detrout>Hm one flaw with my setup is many messages about how .config/guix/latest/*.scm is newer than /usr/share/guile/site/2.0/gnu/packages/*.go <lfam>That's not unique to you <lfam>Of course, my paths are different, but those warnings are really noisy on my systems <detrout>well at least its good to know its not just me. <lfam>I only experience it when working out of git <lfam>I end up rebuilding my git checkout more than I would, to silence the warnings ***vimuser is now known as emacsuser
***emacsuser is now known as vimuser
<xd1le>hey why do i have to do `(packages (append (list nss-certs tcpdump) %base-packages))` instead of just doing `(packages (append '(nss-certs tcpdump) %base-packages))`? <mark_weaver>xd1le: '(nss-certs tcpdump) is literal list of two *symbols*, whereas (list nss-certs tcpdump) constructs a list of two package objects. <mark_weaver>xd1le: in (list <expr> ...), <expr> is a Scheme expression that will be evaluated, and the values of those expressions are put in the list. <mark_weaver>xd1le: in '(<data> ...), <data> is raw scheme data that is not evaluated <mark_weaver>'nss-certs' and 'tcpdump' are scheme variables, which are bound to package objects. <mark_weaver>another example: (list (+ 1 2)) returns a list of one element: the number 3. <mark_weaver>'((+ 1 2)) is also a list of one element, but that element is itself a list of three elements: the symbol +, the number 1, and the number 2 <mark_weaver>xd1le: anyway, I suggest this: (packages (cons* nss-certs tcpdump %base-packages)) <marusich>Is ftp.mozilla.com responding to anyone? I'm trying to run guix system reconfigure and it failed after 5 hours because of a 1-hr timeout waiting to download a tarball from ftp.mozilla.com :( <marusich>Sure enough, when I run "ftp ftp.mozilla.com" to test, it does not connect. Not sure if it's down or if it's my local network preventing me from connecting. <marusich>So, the package definitions are pretty old... <marusich>I'm surprised that I can't connect to ftp.mozilla.com even though you can, though. <marusich>"trying to build v0.8.3" = I built guix v0.8.3, and then used the package definitions from it to try to run guix system reconfigure <marusich>I am on a quest to figure out why my network card does not work when I run "guix system reconfigure" using the most recent version of guix (and its tools/pacakge definitions). I haven't been able to figure out why, so I was hoping I could slowly bisect the git history to find out what change caused it. It's not going well. <mark_weaver>marusich: it's probably either the kernel or wpa-supplicant <marusich>Maybe I can limit my bisecting to those two <marusich>Do you mean, do the "guix system reconfigure", and then "roll back" just one of those two package? <mark_weaver>bisecting guix as a whole over a long period is going to be a very expensive operation. <mark_weaver>marusich: no, I mean to run guix from a git checkout where the recent updates for linux and wpa-supplicant have been reverted. <mark_weaver>so those two packages are rolled back to the versions when wireless worked for you <marusich>I've discovered that for various unfortunate reasons, the old versions do not build easily like the new versions <marusich>How can I roll baack just the kernel, for example, after doing "guix system reconfigure"? <mark_weaver><marusich> I've discovered that for various unfortunate reasons, the old versions do not build easily like the new versions <marusich>And when you say run guix from a git checkout, do you mean that I should set up a git repo, build it, and then from there run something like "sudo ./pre-inst-env guix system reconfigure my_configuration.scm"? <marusich>marusich, well, for example, if you try to build v0.8.3 without specifying the right libgcrypt prefix, it will fail; a later commit auto-detects that, so you have to find the prefix and supply it yourself or cherry-pick the patch <mark_weaver>marusich: if you're bisecting the git history now, you're doing something similar, no? <marusich>In addition, assuming you get it to build, the package definitions for anything referencing freedesktop.org will not work out of the box, since they redirect to https now <marusich>So yeah, bisecting over all the things is pretty impractical <mark_weaver>okay, so the only difference is that instead of trying to bisect the entire history, just check out current master and then selectively revert the patches that update linux and wpa-supplicant. <mark_weaver>marusich: in the case of bad URLs, the easy workaround is to run "guix download <URL>" on the new URL and then try again. <mark_weaver>"guix download <URL>" downloads the file and adds it to /gnu/store <xd1le>mark_weaver: thanks i understand, thanks for the full explanation <mark_weaver>and then, when you ask to build the package, guix-daemon will see that the file is already in the store and not download it again. <marusich>Just to double check: it should work if I get a local git checkout, built it, and then run "sudo ./pre-inst-env guix system reconfigure my_configuration.scm", right? <marusich>OK. I'll see if I have better success working backward with just the kernel changes <marusich>because this 5-hr iteration thing is not really working out <marusich>If I just change package definitions, is it necessary to rebuild the guix checkout? that takes like 15-30 minutes on my laptop <mark_weaver>marusich: "make" should be sufficient in almost all cases, and it only rebuilds the files that were changed. <mark_weaver>it's not strictly necessary to compile the scheme code in guix, no <marusich>so i should make my changes to the package definitions, then run "make" again. <mark_weaver>once you build a git checkout once, then if you only change a few files, subsequent "make" runs are very fast, even on older hardware. <mark_weaver>but first, checkout current master and pull from us. <marusich>That makes sense. It's probably too paranoid, if I'm just changing package definitions, to run "make check" also, I presume? <mark_weaver>marusich: you can just use the "git revert" command to revert the linux-libre updates, starting from the most recent update and working backwards. <mark_weaver>it's good to run it from time to time to see if there are some problems that should be reported to us, but no need to do it when just changing package definitions. it doesn't check package definitions anyway, only the core facilities of guix. <mark_weaver>marusich: btw, I think it's incorrect to say that bisecting over all of guix is impractical. it's expensive when bisecting over a long period, but even then it's certainly doable even with a single non-ancient laptop. <mark_weaver>bisecting over a shorter period, e.g. a few weeks, would be quite practical. <xd1le>mark_weaver: ugh the guix system reconfigure seems to be stuck at downloading ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_19_2_RTM/src/nss-3.19.2.tar.gz <xd1le>for example, i'm trying to wget that and it's hanging at "Connecting to ftp.mozilla.org..." <xd1le>if i can't use git then i can't do a lot of things <Jookia>Oh wow my patches break 'guix system init' and I didn't realize -_- <rekado>I'm curious about using shepherd as a user service manager. <rekado>does anyone have an article on their use of shepherd? <Jookia>Okay this is really weird, without patches I still get a weird thing happenign: "guix system: error: failed to register '/gnu/store/dpak7jzc95i2yc9jwfgnbjnqnvrp38zi-bash-static-4.3.42' under '/mnt/root'" <marusich>mark_weaver, you're probably right. It would have helped if I had known I could use guix download (which I do now, thank you!), since I spent about two days just restarting failed "guix system reconfigure" commands because of a broken URL or two. <Jookia>so apparently it works if i run it in pre-inst-env <xd1le>okay so nss version 3.19.2 uses a ftp:// source uri, but latest version 3.21 uses a https:// one, which works. so the question is, how can i make the source field of version 3.19.2 point to the https uri so that it downloads correctly when doing guix system reconfigure? <xd1le>and also, how do i hash the tarball so that i know it's the same thing? <xd1le>i guess guix will not proceed if it's different anyway, but i want to manually check just in case anyway <xd1le>(i'm guessing they removed the ftp:// downloads.. :( ) <xd1le>as in, i know how to access the current nss version, i think, but not the previous version 3.19.2 <xd1le>do i just have to make a new nss package object that is basically 3.19.2 but with the different uri? <xd1le>but that would then override the default nss to version 3.19.2 instead of 3.21 on the system, which i don't want of course <xd1le>so like, i only want it to override if anything needs nss version 3.19.2 <rekado>as I'm working on shepherd I think the xfce shutdown bug is due to shepherd respawning services <xd1le>perhaps this may affect other packages too <rekado>xd1le: use "guix download" to download into the store and compute the hash. <Jookia>i suppose it's a good protocol to have though :\\ <rekado>oh, new ardour release. Updating <xd1le>yep it's the same thing, now how would one fix that? <NiAsterisk>so the way I have kyotocabinet now, "./pre-inst-eng guix lint" seems to stop responding <rekado>NiAsterisk: when "guix lint" doesn't say anything that's a good thing. <rekado>did you mean (replace 'check (lambda ...))? <rekado>also, the description is really short. <rekado>the synopsis sounds odd. I would leave off the "straightforward". <rekado>in the synopsis this doesn't make much sense. <rekado>I suggest making the synopsis as clear as possible and go into more detail in the description. <rekado>rekado: re user shepherd: run "shepherd" first before using "herd"! <NiAsterisk>rekado: I have no clue about this database, therefore no description. the synopsis is not the problem, it did build before <rekado>I was just reviewing your package. <NiAsterisk>there's a thread on the devel list about it, I am just trying to add in a second make which runs in examples which will build and run additional tests <rekado>I didn't say that this is the reason for build problems (didn't see you mentioned build issues) <rekado>add-after takes three arguments: phase name, phase name, lambda <rekado>replace works the way you tried to use "add-after" <NiAsterisk>thanks! anyone else: but why replace when I don't replace something but just add something after the first make check? I try to insert a second make with a different makefile after make check and before make install <Jookia>or is freedesktop down in general <NiAsterisk>pinging annarchy.freedesktop.org (ftp.) takes time <NiAsterisk>so in this case, why would I choose (replace) over (add-after) ? seen purely linguistic, add-after makes more sense. <xd1le>can anyone pull from the repo or access cgit? <efraim>git fetch worked for me just now <efraim>git push hung on sending emails about 15 minutes ago <wingo>i was just able to push fwiw <rekado>NiAsterisk: oh, if you want to add a phase after 'check you should do (add-after 'check 'build-examples (lambda ...)) <rekado>sorry, I misunderstood what you wanted to achieve (was in a rush) <rekado>note that "add-after" takes the name of the phase after which you want to add a new phase, then the new phase's name, then the procedure that is performed during this phase. <rekado>I wrote this earlier, but I think I didn't express myself clearly enough. <NiAsterisk>I'll try and see if it's enough to get something now. thank you <xd1le>efraim, wingo: thanks, works for me now again too <NiAsterisk>Hmm... so this fails. I'm still not the guile expert, but calling make -f examples/Makefile inside (arguments) in #:phases in (modify-phases %standard-phases), that should work theoretically. iirc I need to add the #:make-flags part to this, my gutfeeling is that I need to construct what I want to do in another way then.. <xd1le>omg i just see now that marusich was having the same problems that i have right now! <xd1le>sneek: later tell marusich: mark_weaver didn't use ftp there though, that's a https url. i had a similar ftp.mozilla.org issue (see the logs), and it seems as though their ftp has been decommissioned: <https://bugzil.la/1250774>. However, they seem to have replaced it with https, so if you just change the ftp:// at the start to https://, it should hopefully work and have the same hash (use guix download to check if it's the same correct <xd1le>hash). I'm about to ask a question to help-guix@gnu.org about how to override the source uri of just an old version of a package, so look out for that if it helps you. <efraim>xd1le: I think he'll only get the first half of that message <xd1le>sneek: later tell marusich: ...hash). I'm about to ask a question to help-guix@gnu.org about how to override the source uri of just an old version of a package, so look out for that if it helps you. <xd1le>i typed it all in one go, i guess irc splitted it up? <xd1le>or possibly just my irc client.. <xd1le>well i have to head, see you! <rekado>NiAsterisk: "so this fails" --- how does it fail? <NiAsterisk>with partial, I mean, the checks of the main make did run and throw no errors <efraim>oxygen-icons5-5.19.0.tar.xz is 222MiB <NiAsterisk>the best mistakes you fail see after staring at it for too long <NiAsterisk>I hope when time passes amd I looked at more code I stop asking so many questions. <wingo>ACTION wonders why his gtk-doc build is failing <wingo>all i wanted to do was get my backlight buttons working :P <efraim>NiAsterisk: I don't think I would bother with checking the examples, that seems more like a developer and less like a packager thing to do <NiAsterisk>efraim: i would not. but I was asked to do so :/ otherwise the package works. the package that will put it to its test is panopticon, which will be packaged by me öater when I have resolved communication with the developer or managed to write an import for rust cargo. <NiAsterisk>my take is.. if the db package is broken, someone with expertise in it should use it and file a bug <efraim>I would try disabling that test specifically and seeing if that makes 'check-examples work <efraim>then you can see if you're in the wrong folder or if its just that test <NiAsterisk>I added the examples/ test, the normal run is just make check <NiAsterisk>the examples/ is another Makefile just for tests <NiAsterisk>where the normal makefile already has functionality test <NiAsterisk>you can take a look at it at fallabs.com/kyotocabinet/ <NiAsterisk>i also have almost no idea how to describe it in a better way, I just need this as a dependency. <NiAsterisk>From my point of view, using the patch i did send on this (with 2 additional comments) will work, somebody with more knowledge about databases can later fix the description, because it's just not my interest and mainly because it's not easy to find out after looking at the website and tarball. it's a database.. I need it for a program which relies on it. I will notice if it's broken and file a bug report <NiAsterisk>myself. it builds with failure and gives no error if I don't try what I currently try to do (letting the examples run with it). <NiAsterisk>of course I would look into what it actually does and how it can be described, but right now that's not my focus and my knowledge in databases is like a basic administration usage of mysql. <NiAsterisk>i'll add my thoughts and explanations to the thread which already has a working kyotocabinet attached. <rekado>NiAsterisk: part of our jab as packagers is to make sure users understand what a package is used for. <rekado>so the description is quite important. <rekado>maybe you snatch a nicer description from a similar package for Debian / Arch...? <NiAsterisk>hm. it's a database used for $bla and it does $bla. like that. okay i'll read into that <NiAsterisk>i'll submit that in a few hours, need to go to the hardwarestore. <NiAsterisk>thanks for pointing that out again, i thought it was rather clear to people who know about DBs <rain1>is there a guix package definition for this? <amz`>rain1: no, there is no package definition for it ***_hubertus84_ is now known as _hubertus_
<_hubertus_>daemon only say "unexpected Nix daemon error: interrupted by the user" <rekado>_hubertus_: do you see any other output, not by the daemon but by "guix system"? <rekado>_hubertus_: are you using libreboot? <rekado>did you previously start virtual machines successfully on this machine? <_hubertus_>so... I have virtual (qemu) fedora where I try to build image of guixsd usinf guix system vm-image <amz`>_hubertus_: you run guix system vm-image inside qemu? <_hubertus_>it is only way to build virtual drive image for guixsd. On gnu.org you can only download file to create bootable USB <_hubertus_>I would like to see guixsd in some safe environment. Thats why I try to buil qcow2 image from guix app <rekado>_hubertus_: can you not just boot a virtual machine from the bootable USB? <rain1>output path `/gnu/store/4yrspg3v9r26j6n4cfrxnjdkiz1c44m5-guile-gnome-platform-2.16.4.tar.gz' should have sha256 hash `020wz5w8z6g79nbqifg2n496wxwkcjzh8xizpv6mz0hczpl155ma', instead has `1hqnqbb2lmr3hgbcv9kds1himn3av6h0lkk0zll8agcrsn7d9axd' <rain1>iwas about to ask which package is guile-gnome-platform-2.16.4 <rain1>but i've realized that its my one <fhmgufs>What are the criteria to decide whether to use the gnu build system or the glib-or-gtk build system? <fhmgufs>Is glib-or-gtk needed every time a package uses GSettings or Gtk+? <fhmgufs>Why isn't that included in the normal gnu build system? <rain1>this package needed g-wrap so i provided it as a dependency <rain1>but then it complained about not having libffi <rain1>so I've added libffi: But shouldn't it be a transitive dependency that g-wrap provides? <rekado>_hubertus_: I just did this successfully: qemu-kvm -hdb guixsd-usb-install-0.9.0.x86_64-linux <rekado>this boots up GuixSD from the USB image as /dev/sdb <rain1>If you were to create a new gui program for guix, what language and library would you use? <rain1>i thought guile + guile-gnome but it's not ready yet <davexunit>using another language negates the benefits of the unified Guix API. <fhmgufs>I also was thinking about that. Is there an alternative to guile-gnome? <fhmgufs>Or is there a Gtk+ 3 version of that? <rain1>oh I cannot make a guix package for guile-gnome <rain1>I may trying asking the maintainer for help <davexunit>right now there's only a single person working on guile-gnome <davexunit>so rather than looking for ways around guile-gnome, it would be better to help guile-gnome improve. <fhmgufs>:) If I would know how to use scheme I would do it. <fhmgufs>Sorry for my English. I meant: If I knew hot to use scheme I would do it. <rain1>I hope we can get it working ^^ <rain1>something I'd like to ask about is <rain1>I was having a look at similar/related packages to help <rain1>they do this thing about: Install modules under $out/share/guile/site/2.0. <rain1>I wonder if guile-gnome needs to do that too (copying that bit of package code didn't fix anything but maybe it is necessary anyway) <fhmgufs>Is there a known reason why a Gtk+ application fails to start with <fhmgufs>GLib-GObject-CRITICAL **: g_object_new: assertion 'G_TYPE_IS_OBJECT (object_type)' <civodul>mark_weaver, davexunit: re mirroring Hydra, i was thinking we could use the code in 'guix publish' to pregenerate all the signed narinfos + nars and send that to a dumb HTTP server <efraim>there's also the guile-ncurses option, although many people don't consider TUI to be GUI <rekado>fhmgufs: are you sure this is the *reason* why the application fails to start? I've seen similar messages for other applications that do in fact start. <rekado>it might be worth taking a closer look with strace or similar. <rain1>it could be nice to store packages on there maybe <rain1>(because it's distributed so anyone can contribute bandwidth/storage) <civodul>rain1: i don't know much about it but yes, it could be an option <rain1>its a bit experimental though, so maybe too soon to think about something like that <fhmgufs>rekado: I've already done this. The reason is a segmentation fault, but this is because of that failure. <efraim>i tried to package obconf and forgot to put openbox as an input <rain1>./configure doesn't exist, I think I have to do autoconf autoreconf (a bunch of stuff i don't know..) <rain1>is there a guix build system or modification to the usual gnu-build-system that does those parts? <rain1>(I'm trying to make a version of the guile-cairo package which uses the latest git head) <rain1>maybe I would try to just add the command ./autogen.sh --prefix=/opt/guile-cairo with a different prefix <mark_weaver>civodul: pregenerating them would be a step in the right direction, but really the nars should be created on the slaves. we should be offloading as much work as possible from the master to the slaves. <daviid>rain1: you could ping the configure.ac version to 1.10.0-dev, then run ./autogen.sh, then run make dist, then use the tarball to create the guix package, imo <rain1>ah i think im in over my head a bit <civodul>mark_weaver: agreed; i'm just thinking about a solution that could be deployed quickly <civodul>this one doesn't need rotating keys or anything ***marxistvegan_ is now known as marxistvegan
<flat13>hi, I am installing guix right now, I have a /boot(vfat) swap and everything-else BTRFS partition. I wanted to make a new subvolume, to install Guix on that, but there is no btrfs tools isntalled on the live-usb and guix package -s btrfs-progs or just guix package -s btrfs does not seem to return anything <_`_>it's not fully packaged *yet* afaik, someone's working on it <flat13>so I will have to download and compile the source myself now, right?(or just boot into my previous OS) <flat13>but actually it looks like there is btrfs-progs-4.4 on Hydra <mark_weaver>flat13: after you start the cow-store service, you could run "guix pull" and "guix package -i btrfs-progs" from the USB installer. <flat13>I need to specify root for that, but I wanted to make a new subvolume to try out the distro, possibly getting rid of the old one with old distro, but I have to mount first to make the subvolume. I booted in gentoo already anyways, thanks! <mark_weaver>okay. the next Guix release will include btrfs-progs in the USB installer, iirc. <flat13>that would be really handy, given its growing popularity! <mark_weaver>wingo: I upgraded my Thinkpad X60 to the media-updates branch, and now I'm seeing rendering errors in IceCat :-( <mark_weaver>I wonder if the latest xf86-video-intel release is less buggy <flat13>by the way, inb4 maybe my question is stupid because of "Church of Emacs" and all that, but why is there no Vi / Vim on the USB install image? <efraim>do we at least have nano on the image? <flat13>but it seems weird to include nano and exclude vi/vim, at least for me ***nckx|offline is now known as nckx
<efraim>our vim is an unpatched 7.4, truthfully it needs some work <efraim>but I would prefer that for configuring the install <davexunit>I would prefer if emacs-no-x was on the image :) <efraim>the answer is clear, we're going to need to sell 16GB usb sticks with tons of packages on them so we can include all the editors and DEs ;) <rain1>It would be nice to have something like paredit in zile <rain1>that keeps brackets balanced <flat13>not really, just the really popular tools like vim or 'clear'(just noticed that) should be available before the user can actually start installing stuff he wants. <flat13>DE can be installed in chroot, right? <efraim>when I switch my laptop over I'm going to need to install apt-file on another machine <mark_weaver>flat13: why would 'clear' be useful in the USB installer? <flat13>to clear the screen. I just 'cat'ed 1 of the configs, now I want to get rid of that <rain1>When I was installing guix I catted a weird timezone file <rain1>and then letters became weird symbols <rain1>I couldn't fix it so I had to switch to a different framebuffer <rain1>I'm not sure clear fixes this though, maybe reset does <rain1>but I think balanced brackets is much more important <rain1>people shouldn't have to edit a scheme file without something that magically makes it valid <rain1>if I can figure out some way to get zile to do that it could save hours overall <mark_weaver>yeah, I used vim as my primary editor for many years, but I wouldn't want to edit scheme code with it. <mark_weaver>still, for those users who are accustomed to vim, I can sympathize with them wanting their editor of choice. <mark_weaver>flat13: you can install packages on the USB installer (preferably after starting the cow-store, so that the ramdisk doesn't get too full) <efraim>can we enable cow-store by default? <davexunit>efraim: no because the target disk isn't mounted and we wouldn't know where the mount point is <efraim>i'll add it to my to-do list, see if we can get that as a hint into the motd <mark_weaver>"guix size vim" shows some surprising runtime dependencies. things like 'gcc' (not just gcc-lib), 'make', and 'guile'. <mark_weaver>could use some investigation, for someone who cares. <paroneayea>does beamer come in that enormous texmf package? <davexunit>I struggled a lot to get a beamer setup working <davexunit>I had to hack something that I don't remember anymore <davexunit>I believe I ended up throwing texmf into my profile which is a bad idea. <paroneayea>davexunit: put it in a guix.scm environment file ;) <paroneayea>ACTION sets up environment, garbabge collects, sets it up, gc <paroneayea>anyway yeah maybe I should make a profile just for texmf :) <davexunit>it will take a long time to generate that profile <paroneayea>or is system and home profiles the only ones protected <paroneayea>there don't seem to be many tools for checking out and managing the profiles I have as a user or on my system <davexunit>paroneayea: making a new profile with 'guix package' should register it as a gcroot <paroneayea>davexunit: interesting. How do I "unregister" one? <davexunit>paroneayea: delete the link in /var/guix/profiles <davexunit>there's some sub-directories to look through in there <paroneayea>guix package --profile=/home/cwebber/guix-profiles/test -i hello <paroneayea>but nothing new appears in /var/guix/profiles/per-user/cwebber/guix-profile <paroneayea>but nothing new appears in /var/guix/profiles/per-user/cwebber/ <davexunit>is the profile anywhere? perhaps it doesn't get registered as a gcroot automatically <paroneayea>cwebber@oolong:~$ ls /home/cwebber/guix-profiles/ -l <paroneayea>drwxr-xr-x 2 cwebber cwebber 4096 Feb 24 10:01 latex <paroneayea>lrwxrwxrwx 1 cwebber cwebber 39 Feb 24 10:07 test -> /home/cwebber/guix-profiles/test-1-link <paroneayea>lrwxrwxrwx 1 cwebber cwebber 51 Feb 24 10:07 test-1-link -> /gnu/store/fwz5n74w0vjxs04ildzfmh21a5w7l70r-profile <mark_weaver>bah, the latest release of the xf86-video-intel driver, released in 2013, doesn't even compile against the current xorg-server. and the git version of the intel driver is buggy as hell on my X60 :-( <flat13>hey, do I put all the mountOpts(like ssd, defaults, discard, compress etc) I would otherwise put in fstab in the system configuration file unders "options" ? ***marxistvegan_ is now known as marxistvegan
<bavier>paroneayea: I tried packaging it a while ago <bavier>I have most of them in a private branch, but they probably all need updating now <bavier>and even then, I wasn't able to get the latest (at that time) git-annex to build correctly <bavier>but the experience did fix a few problems in our haskell-build-system <flat13>the only partition that gets set up in install guide is the root. Am I supposed to use the "file-systems" field just as a normal fstab(mounting swap, boot, etc.), or does boot get automatically mounted, after I configure GRUB there, f.e. ? <flat13>do options like "defaults,discard,noatime" get set by default> <alezost>flat13: yes, /etc/fstab is generated from "file-systems" field; only "defaults" is set by default <flat13>thanks, I was wondering as the root is mounted without any in the docs <lfam>Has anybody had a chance to read my patches applying fixes for the libssh and libssh2 bugs? <lfam>And it seems that libssh2 provides SSH for hundreds of our packages <mark_weaver>lfam: one question: is libssh-0.6.5 vulnerable to CVE-2016-0739 or CVE-2016-7087 ? <lfam>Yes, it is. But, it's the most recent version of libssh that guile-ssh can use. <mark_weaver>the patches themselves look good to me, but the commit logs could use some tweaks, and you sounded uncertain whether they would cause a massive rebuild, so I felt the need to check it. <mark_weaver>lfam: I wonder if the fix could be backported to 0.6.5, or maybe someone has already done it. <lfam>The libssh2 will require many rebuilds, although I checked that curl would need to be rebuilt <lfam>That redhat bugzilla page contains a link to the upstream libssh commit that fixes the bug <mark_weaver>Debian has a patch to fix CVE-2016-0739 in libssh-0.6.3 <mark_weaver>that's probably close enough that adapting it for 0.6.5 would be easy <lfam>mark_weaver: I can take a crack at applying it <flat13>ok, I have never used or seen Lisp in my life... while trying to guix system init, no matter what I put inside the (services (cons foo)) // or packages, I get an unbound variable error <davexunit>flat13: a likely error is that you haven't imported the module that defines the relevant variable <flat13>does any1 mind sharing their config.scm, so I can see how is it done properly? <lfam>flat13: Do you see (use-service-modules ...) and (use-package-modules ...) at the top of the file? If you want to add a package or service, you must also import the relevant module. <lfam>The example configs should work, except for the file-system stuff, which you must adapt to your hardware <flat13>I did not add anything, I actually took out the X and more stuff <lfam>flat13: I recommend either starting from one of the examples, or sharing your changes so that we can tell what the problem is <lfam>Remember, once you have GuixSD installed, you can always reconfigure to make changes. So it's fine to start with one of the examples and work from there <flat13>now I commeneted out almost everything and I get a "wrong number of arguments to #<procedure cons ()>" error. I can not share, as networkijng does not work on the machine, and I did, I took the desktop one and took the unneeded stuff out <flat13>the networking does not work on the machine I am installing the distro on <lfam>flat13: Please make a copy of your configuration *off* the machine you are installing on. There will not be a copy of the configuration after you have installed <alezost>flat13: cons can take only 2 args; it's likely you want to use cons* <lfam>The other option is to install the bare-bones example, get online, and work from there... <mark_weaver>flat13: (cons <item> <list>) returns a new list with <item> added to the front of <list>. (cons* <item> ... <list>) does the same but adds any number of items to the front of <list> <mark_weaver>but you need a list as the last argument, and it should probably be either %base-services or %desktop-services <lfam>mark_weaver: That Debian patch applies cleanly to libssh-0.6.5. <mark_weaver>so, the summary line of that patch isn't sufficient, I think. <lfam>Okay, I'll try to give more context and information about the source <mark_weaver>it mentions updating libssh but doesn't hint at the other changes, and it doesn't mention the CVE <mark_weaver>I wonder if it would be reasonable to split this into two commits <lfam>Are you referring to the Debian patch, or my patch? <lfam>It does mention the CVE... <lfam>I did struggle with how to organize these changes, as well <lfam>I thought that for each of libssh and libssh2, there should be one atomic change that makes us not vulnerable. <lfam>Do everything at once for each one <lfam>I'll do it another way if asked to <mark_weaver>one more thing: in the libssh2 update patch, the commit log should only describe what you changed, not the rationales. the rationales should go in comments. it's good that you put a comment above the libssh2-1.4 package. maybe also add a brief comment where it is used as an input to 'curl'? <lfam>The Debian patch appears identical to the upstream commit, so how about I give upstream as the source? <lfam>I can add links to downstream bug reports for context <n0m>hi all, why does guix need Nix to compile? <n0m>is there anything I need to pass to configure to disable this dependency? <mark_weaver>n0m: guix doesn't need Nix to compile. what makes you think it does? <n0m>configure: error: Nix programs not found; please install Nix or use `--with-nix-prefix'. <n0m>compiling 0.9.0 from source <n0m>with --disable-daemon <n0m>i don't have root access :( so the daemon does me no good <n0m>also my system doesnt have gcc4.7 <mark_weaver>n0m: if you don't have root access, then you probably can't use Guix, sorry. <lfam>You lose *a lot* without the daemon <lfam>You basically lose the core idea of Guix and Nix without the daemon: The isolated build environment that allows us to approach the problem of building software functionally <n0m>the daemon requires root access, right? I thought guix was supposed to be a root-less package manager? <lfam>Ah right, I was thinking of running an unprivileged daemon <n0m>okay, so I should just build gcc 4.8 and run again without --disable-daemon? <mark_weaver>n0m: root needs to install and run guix-daemon. after that, then ordinary users can build arbitrary packages without being root. <n0m>damn. I guess guix won't fit my use case then <mark_weaver>in the future, "user namespaces" may allow us to run guix-daemon without root, but we're not there yet. <wingo>mark_weaver: it seems i got polkit peoples' attention so no review needed for now <n0m>pizzaiolo: restricted environment at school. they give us build tools and encourage us to build programs we want while they get approval in the bureaucract <mark_weaver>and there's even some question as to whether the needed user namespace functionality will be widely available, because it's proving difficult to implement that feature securely in Linux (the kernel) <n0m>mark_weaver: that probably would be much use anyways, our kernel is 2.6 :) <lfam>mark_weaver: I'm adding the comment to curl and I realized that I don't understand our approach. Most of the rebuilds related to libssh2 are "via" curl. Not a lot of packages depend directly on libssh2. If we keep curl "as-is", when we will actually do all those rebuilds? <n0m>ah well. if anyone has alternative non-root package managers, feel free to mention them! I couldn't get gentoo prefix to build (some bug in sys-apps/net-tools), and pkgsrc didn't have anything I was looking for <mark_weaver>I could be wrong, but my guess is that the libssh2-via-curl thing is not going to affect many programs in practice, dunno. <mark_weaver>obviously we should do the rebuild, but I don't feel an urgency to put the media-updates on hold while we build this out. <lfam>Yeah, many of those dependent packages *shouldn't* need secure 2-way networking <alezost>flat13: you can't use "(cons %base-packages)"; just "%base-packages" instead; the same for (cons %base-services) <alezost>flat13: also you probably want "/dev/sda" instead of "/dev/sda1" for grub-configuration <flat13>but before I had cons bspwm sxhkd %base-packages <flat13>I jsut gradually deleted everything <flat13>I just copied how it was in the example, while changing the names <mark_weaver>flat13: as I wrote to you earlier, 'cons' requires two arguments: an element, and a list. <alezost>also it should be (swap-devices '("/dev/sda2")), not (swap-devices ("/dev/sda2")) <wingo>mark_weaver: tx for trying a different git revision <mark_weaver>flat13: 'cons*' adds any number of elements to the front of a list, which must be the last argument to 'cons*'. <wingo>that was really nice of you to go through that trouble :) <flat13>I also commented that. "same thing" - error, about the cons. OK, I got that, will try again. what about the list? <wingo>of course it would be best if they made a proper release :) <flat13>and other than that, everything should work, right? <alezost>flat13: just use "(packages %base-packages)" instead of "(packages (cons %base-packages))" <alezost>flat13: I've just tried your config with the above fixes and it works <flat13>I'm gonna packages (cons sxhkd bspwm %base-packages) <mark_weaver>wingo: I'll be glad to have these updates in master soon :) <wingo>sounds like media-updates is going ok, so me too :) <alezost>flat13: for sxhkd and bspwm, you also need to add 'wm' and 'xdisorg' to (use-package-modules ...) <mark_weaver>bah, gst-plugins-good consistently fails its tests on my X60 :-( <mark_weaver>or did twice in a row in the same way: "FAIL: elements/splitmux" and "FAIL: elements/rtprtx" <lfam>That's been on my back-burner <lfam>I experienced the failure, saw the bug reports, and moved on to something else. <lfam>Why do computers barely work? <lfam>And why do they do the wrong thing when they do work? <flat13>wow, thank you, something actually started to happen! The build itself failed though, but at lease I can continue :) <detrout>I did guix (outer debian version) package -i guix. Then when I run guix from /gnu/store its having trouble finding libgcrypt <alezost>flat13: btw did you run "guix pull"? If not, it's likely that the (old versions of) packages will be built locally instead of downloading from our build farm <detrout>mark_weaver: do I need to subscribe to bug-guix in order to get a response? <wingo>aw gst-plugins-base fails to download b/c https. garr <wingo>i had merged media-updates into my local branch <wingo>how do i know what branches will be rebased? anything outside master can be rebased? <lfam>mark_weaver: 3rd version of libssh / libssh2 security update patches sent <mark_weaver>wingo: sorry, this probably should have been called the 'wip-media-updates' branch. <wingo>i keep bouncing back and forth, some projects rebase all the time, some never <mark_weaver>I probably won't rebase it again, but I wasn't expecting so many broken updates... <flat13>alezost: I fixed the network, left guix to do its job and went to make myself a dinner. It failed just a sec ago, will do, thanks! :) <wingo>gstreamer built for me fine fwiw. yay reproducibility :/ <civodul>mark_weaver: it should have been called wip-media-updates maybe :-) <wingo><mark_weaver> wingo: sorry, this probably should have been called the 'wip-media-updates' branch. :) <mark_weaver>lfam: I pushed slightly modified versions of your libssh patches. thanks! <mark_weaver>lfam: btw, by our commit log conventions, continuation lines begin with two spaces so that the first word lines up with the text above it. <wingo>hoo, now i am confused, i thought all lines in guix started at col 0 <lfam>mark_weaver: I thought this was discussed a couple months ago and we reached the opposite conclusion <lfam>Not that I feel strongly about it either way <mark_weaver>bah, sorry. I haven't been keeping up with the mailing list lately. <lfam>I'll start on any column. I don't think it's the most important factor of a good changelog <lfam>And your changes did improve my messages <wingo>yeah no strong feelings here either :) <lfam>I think our changelog is generally excellent compared to many other projects' :) <lfam>No commits that just say "Oops!" or "Fix thing we talked about" <wingo>tho the more i program, the less i rely on comments tho, commit logs included <lfam>The curl comment is also an improvement <a_e>sneek: later tell paroneayea: Never install texlive-texmf into your profile! Just use texlive. texlive-texmg is an internal package that is only exposed so that it can be built locally instead of served by the substituter. <wingo>civodul has long said that if something important needs to be said, it should be in a comment, and i am coming around to that, finally :) <lfam>wingo: I know what you mean. In a project like Guix where the same changes are repeated often (for example, adding or updating packages), it's very nice to have a convention that allows readers to skim the changelog <lfam>Is prefixing comments with 'XXX' a convention that indicates some action is required? <wingo>lfam: true, i do find myself searching in the changelog for commit logs of known forms <wingo>lfam: for me XXX is not a convention we should encourage precisely because it's unclear :) <lfam>I actually started using it in my college papers, to provide a marker that indicated something was unfinished. It's funny that other people seem to have independently started using it in the same way <lfam>The idea being that I could not submit a paper that said XXX anywhere ;) <wingo>ACTION 5 minutes away from a media-updates system, whee <lfam>Regarding known forms in commit logs, our release instructions actually include things like 'Run "git log" and search for "^Fixes".' So there is a practical reason to stick to the convention <mark_weaver>heh, I use XXX to draw attention to something that should be fixed. maybe FIXME would be better. <lfam>They both have X in them <a_e>We have 120 "TODO" and 152 "FIXME" in the packages. <lfam>Haha. I guess we should look at those periodically <wingo>isn't XXX what is traditionally written on the outside of bottles of home-made spirits <lfam>That's not the only traditional use of it! But this might be getting too off-topic ;) <bavier>I always understood "XXX" to me "check" <detrout>mark_weaver: I think my bug was due mixing a guix git clone built with debian tools with guix components built with guix. <wingo>detrout: it's really easy to do, isn't it :/ <detrout>I think I solved it. I just need to test it a bit more and write how I worked around it down <detrout>Also other than hydra always being slow guix environment is really really nice <wingo>hopefully hydra speeds up soon. we need to make guix stop checking hydra just for environments i think <detrout>Is there any caching options to help hydra? <wingo>like, i don't want to download a profile for hydra <wingo>detrout: there are a few things in place afaiu <wingo>apparently though querying for substitutes is quite a drag, everyone wants different ones, and hydra will expire old one <detrout>Like it might be nice for this execution of guix to accept that it checked hydra 3 minutes ago and not much is likely to have changed <wingo>better servers are on the way <wingo>yeah could be we're dropping some caching opportunities on the floor <lfam>I think we are making use of caching <lfam>I end up thinking about when to use --no-substitutes, and it's made things go a lot faster <mark_weaver>nginx caches nars, but we don't have enough disk space and so our cache is smaller than we'd like. <detrout>So far when I add --no-substitutes it seems like it goes off and downloads source packages <bavier>detrout: that's the intended behavior :) <lfam>detrout: Yeah, and then you build from source. But if you are iterating over the same package definition or environment, you might not need to download anything after the first time <lfam>So, not checking for substitutes can save you several seconds, or even some minutes when things are really bad <lfam>Soon we will buy a *narly* new server and things will improve ;) <detrout>but if you become more popular.... then you'll need even more servers... <lfam>And hopefully more donations! <lfam>Apparently the current hydra.gnu.org has abysmally low disk I/O. So I am very optimistic about the replacement. <lfam>I think that disk bandwidth is not a regular problem for this type of server, and just getting to a "normal" amount of disk bandwidth should help a lot <detrout>Is there a way to chain hydras? E.g. I run a local hydra that cache my packages I like, but if I ask for something new it can check the public hydra? <lfam>In the long run we want to distribute binaries over gnunet, with P2p <detrout>I tried running it, but there's the problem a network isn't really that useful if you don't have something to talk to <lfam>I think the plan is to make P2P binary substitute distribution over gnunet a default part of Guix. So all Guix users will be on gnunet, serving each other. That's my fantasy, anyways <wingo>ACTION has more faith in good servers than p2p :) <lfam>`guix publish` is useful, but I think we still have the issue where if the first server you check for a substitute doesn't have it, subsequent servers are not checked. I'm not sure if we fixed that yet or not. <wingo>i am finally only a yak or two away from having working brightness keys <lfam>That limits the utility of `guix publish` unless you are continously building all packages, in which case you might as well set up your own instance of hydra <lfam>wingo: *good* servers being the key! <detrout>Debian has 'apt-cacher-ng' so when you tell a bunch of machines to do apt-get you only hit the upstream servers once per package version <wingo>bah, getting this working requires cgroups <wingo>maybe i can hack it into place using the pid tree <rekado>my xfce looks a little ugly. I have the adwaita-icons installed, but I don't think it's using the adwaita GTK theme. <lfam>Do we package Thunderbird under some other name? <lfam>There is a security advisory on it <rekado>does anyone else have a pretty xfce? <lfam>I don't see it in mail.scm or gnuzilla.scm <lfam>Ah, I should have asked wingo about my pending msmtp patches <lfam>I couldn't find it so I figured we didn't <petter>rekado: i think you need to add adwaita-icon-theme to packages in your configuration file <rekado>petter: I have the adwaita-icon-theme installed. <petter>but do you have it in your configuration file? <rekado>when I say "ugly" I mean for example: the look of the buttons in the panel. <rekado>yes, it's in the list of packages in my os configuration file.