<vagrantc>if you had to verify anything else using openpgp signatures ... you'd have the same problem right now
<basdfewaf>hello! I'm using btrfs with my root partition on a subvolume "@". guix doesn't seem to be able to deal with this, and generates broken grub.cfg. to get the system to boot I need to prefix the kernel and initrd paths with "/@", and pass a root=... parameter to the kernel. how do I fix this?
<vagrantc>the short of it is the keyservers used to share public openpgp keys always had a vulnerability where anyone could upload anyone else's keys with signatures ... and someone proved how bad an idea that is by uploading prominent developers keys with tens of thousands of signatures ... and ... problems happened.
<tune>hm `sudo herd restart networking` didn't fix it either
<dftxbs3e>nexgen: I think you need to bootstrap a new architecture entirely. gnu/packages/make-bootstrap.scm allows you to create the bootstrap binaries, gnu/packages/bootstrap.scm is also used by gnu/packages/make-bootstrap.scm and then, gnu/packages/commencement.scm takes those bootstrap binaries to "grow" GNU Guix as a whole
<dftxbs3e>once you are inside GNU Guix, run `guix environment guix --ad-hoc git nss-certs` then `git clone https://git.savannah.gnu.org/git/guix.git` and then inside the "guix" folder, run `./bootstrap` (runs autoconf), then `./configure --localstatedir=/var` then `make -j$(nproc)`, then you can test your changes by prefixing `./pre-inst-env` to any command, e.g. `./pre-inst-env guix build hello`
<dftxbs3e>you don't need to recompile GNU Guix to test changes, scheme files newer than compiled objects will be interpreted instead
<numerobis>dftxbs3e: Thanks, I am aware of that. The only thing is that the user 'nginx' is not declared explicitly in /etc/config.scm; it gets created for the 'cgit' service I think. So I'm afraid that, if I declare it manually with (user account ...), the other automatically created properties of the user will be somehow lost.
<dftxbs3e>numerobis: depending on what you're trying to solve, you could find your solution inside the cgit service configuration then
<dftxbs3e>if not, then I think this is part of the rough edges of GNU Guix
<numerobis>dftxbs3e: Thanks. My issue is that, at the moment, nginx does not seem to have read access to the 'project.list' file generated by gitolite. I guess I could still manually chmod it, but not ideal.
<grumbel>How does one use clang++ in Guix (ontop of Ubuntu)? I am currently getting "ld: cannot find crt1.o: No such file or directory", which I assume means I have to add a few linker flags to point it to the right directory
<ngz>numerobis: It seems that you can set a user and a group for Gitolite to use. Have you tried that?
<reepca>gcc-5 fails to build in a test-env for some reason. I wonder if some more hard-coded "/gnu/store" patches were added?
<numerobis>naz; I was just reading about it. The thing is that the permissions of the project.list file are 600, so adding a group doesn't help. I also have umask set to 022, which should be fine for reading, but somehow this doesn't seem to have made a difference. I'll investigate.
<numerobis>naz: Update: I deleted the whole /var/lib/gitolite and reinstalled (guix system reconfigure ...) and now the permissions on project.list are expected. (Ie, there is read access for the group). I'll try adding 'nginx' to the group to see if that works .
<dftxbs3e>grumbel: from a quick look it seems that's a bug, compare `gcc -v test.c` / `clang -v test.c` outputs and see, I'd go see what gnu/packages/gcc.scm looks like to mirror changes over to clang in some way
<bgardner>rekado_: Regarding LDAP auth, that's weird that my config works while yours does not. Seems not guixy; let me know when you have a moment and I can provide more of my config.
<numerobis>naz,dftxbs3e: In the end I got it to work, but I had to set the umask to 022 (not idea) and manually chmod 755 the home directory of the user git (created by gitolite), i.e. /var/lib/gitolite.
<numerobis>dftxbs3e: sounds like it, unless there is a mechanism for post-reconfigure hooks to do the 'chmod' part?
<dftxbs3e>numerobis: no that's not how GNU Guix works
<numerobis>dftxbs3e: Yes, I agree, that would be quite ugly.
***scs is now known as Guest47358
<numerobis>dftxbs3e: I see in the gitolite service definition that the user-account 'command' (or object, I don't know the correct terminology yet) is used internally. Considering that the permissions of the home directory cannot be passed to it, how would you go about modifying the service?
<numerobis>dftxbs3e: I wrapped the 'guix system reconfigure' command in a Makefile, with at the end of the recipe a chmod command. Very ugly, but a functional temporary solution for now. In any case, I've added some hacking of the gitolite service to my todo list, because repo-hooks can't be enabled with the current gitolite-rc interface. Thanks for your help
<Zaab1t>this is quite frustrating because I cant reconfigure xmonad without compilling it :(
<nixo_>Where do I send a patch for the website? (git repo guix-artwork)
<bavier>Zaab1t: iirc this has been an issue for a while. The problem is that xmonad tries to rebuild itself in the current user's profile, which may not contain everything actually required to build xmonad.
<bavier>Zaab1t: until a better fix is prepared, you could instead create a custom xmonad guix package that contains your configuration
<vagrantc>any rough ideas about the next release version? getting pretty close to be able to upload to Debian, especially with some changes in master
<vagrantc>suppose i can start with a git snapshot...
<reepca>hm, yeah, whether it uses chroot or not, any attempt at building gcc-5 within test-env fails with "x86_64-guix-linux-gnu-ld: cannot find -lstdc++", but it succeeds outside of test-env. Any idea why that would be?
<Zaab1t>bavier: I guess I start by copying the definition of `guix edit xmonad` to a new file?
<bavier>Zaab1t: that would be one way; using 'inherit' might be better long term.
<bavier>put that in a new scheme file "my-xmonad.scm" or similar
<bavier>and put a guile module definition at the top
<bavier>Zaab1t: then, I believe xmonad allows you to create a configuration file in the build tree -- I'm unclear on the specifics -- but you'll want to add a new phase that creates that configuration file to the package's arguments
<Zaab1t>bavier: I think it would actually be enough, if the build step ran `xmonad --recompile` after the ghc stuff. How would that look?
<bavier>Zaab1t: maybe add a phase before the 'install' phase that runs `xmonad --recompile`.
<bavier>Zaab1t: though I think xmonad does some "tricky" stuff with $HOMEDIR, i.e. I think the recompile'd xmonad is placed somewhere else that the "original" xmonad. (kinda like guix with 'guix pull')
<PotentialUser-47>OK then: I want to install some more globally visible packages. Do I edit /etc/config.scm and then guix system reconfigure or should I guix package -i <pkg> -p <current system profile>?
<ryanprior>vagrantc: I would love to submit it, but I want to check to make sure that it actually works. (I suspect that it doesn't, this is my first time trying to package anything for guix, I would be shocked if I nailed it on my first attempt)
<ryanprior>But I litereally don't know what to do with my .scm file to get guix to attempt to build it X.X
<vagrantc>i've mostly worked with the ./pre-inst-env method ... which is nicer in some ways
<lfam>It's simplified for use with --install-from-file. They way you had written the package definition is the right way for integrating your package into the GNU Guix repo but not necessary or quite correct for the simple --install-from-file method
<pkill9>ryanprior: you need to put "harvey" at the bottom of your scm file, at the moment it just defines a variable but doesnt return something to evaluate
<lfam>If you ever run a `guix package` command are wondering if it installed anything, it's more correct to use `guix package --list-installed` than to look in /gnu/store, since that directory is more like a cache than a list of installed things
<lfam>I also recommend using '--verbosity=9' so you can see what it's doing (it will fail to compile)
<ryanprior>Okay, that's giving me something to work with at least :)
<lfam>I don't know the full answer but there are still a few missing dependencies :)
<lfam>I think it's no longer necessary to add the plain "harvey" line at the end, pkill9 and ryanprior. I guess it was a "user experience" bug that we fixed
<lfam>'--install-from-file' is mostly used by people trying Guix packaging for the first time so I figure it was unecessarily pedantic to require it for that audience
<xavierm02>having it be code allows stuff like definining a package by "the union of those two other packages" or "this package, but with this thing replaced by that other thing"
<bavier>ryanprior: package definitions interact with other package definitions and guix modules, which are not set in stone enough to be able to separate them
<rekado_>package definitions aren’t just data. A big part of them is (like descriptions, home pages, etc), but for the parts that aren’t it’s really convenient to have a general purpose programming language to work with.
<rekado_>package definitions are written in an embedded domain specific language
<rekado_>so you have the choice of either freezing the API of that language or go with the flow.
<rekado_>the second option works fine for Linux, and it works fine for us as we don’t have to make releases of the DSL and worry about API versioning and all that.
<rekado_>don’t see it as “forking” Guix. It’s contribution to a part that grows together with other parts of Guix.
<rekado_>If you don’t want to contribute to Guix that’s fine as well; you can operate an independent channel.
<rekado_>it’s just that the existence of third party channels won’t keep us from making breaking changes when they benefit Guix.
<rekado_>so the best path to packages that will work with Guix is to contribute them to the package collection that is developed together with the rest of Guix.
<ryanprior>Now that I have harvey.scm in my guix tree, running `make` throws: "ice-9/eval.scm:293:34: no code for module (gnu packages harvey)"
<lfam>ryanprior: The file I gave you removed the part that defined the module. Did you put it back?
<lfam>ryanprior: Remove the lines from 12 to 19. Put the '(define-public harvey (package ...))' part back. Add the file to 'gnu/local.mk' in the list of package module files. Run `make` and then do `./pre-inst-env guix build harvey` and it should work
<lfam>If you didn't do the whole `make` dance yet, this is how it goes: Do `guix environment guix` to set up an environment for developing Guix. Then do `./bootstrap && ./configure --localstatedir=/var && make`
<lfam>'/var' is the default value for the local state directory and it allows your development Guix to share the store with your installed Guix
<ryanprior>Yep that much I've done (except I didn't do `--localstatedir=/var`, so I guess I'll redo that part)
<lfam>It's a good idea to save time and disk space