<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
<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?
<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
<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>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?
<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>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>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
<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
<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 email@example.com 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>sneek: later tell marusich: ...hash). I'm about to ask a question to firstname.lastname@example.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.
<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>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.
<rain1>output path `/gnu/store/4yrspg3v9r26j6n4cfrxnjdkiz1c44m5-guile-gnome-platform-2.16.4.tar.gz' should have sha256 hash `020wz5w8z6g79nbqifg2n496wxwkcjzh8xizpv6mz0hczpl155ma', instead has `1hqnqbb2lmr3hgbcv9kds1himn3av6h0lkk0zll8agcrsn7d9axd'
<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
<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
<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>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 :-(
<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?
<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
<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'?
<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)
<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
<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.
<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>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