<Petter>In a new package I'm working on I get into trouble when I switch from http://downloads.sourceforge.net/xcalib to mirror://sourceforge/xcalib. Building/installing seems to be fine, but "guix lint xcalib" throws out a lot of 404 Not Found. <Petter>It injects a /project in the path which seem to mess things up. Not sure what's going on here. <ng0>what's the total path? <ng0>some sourceforge files have /projects instead of /project <ng0>the mirror so far only covers project <lfam>Sourceforge doesn't have consistent URLs between projects, so we can't just do <mirror://sourceforge/xcalib> <Petter>I was using: (uri (string-append "mirror://sourceforge/xcalib/""xcalib-source-" version ".tar.gz)) <lfam>You have to download the file from the sourceforge web page and then see what URL it actually got the file from. It will probably not be same as the URL you click to download because it redirects you <lfam>Most browsers should be able to show you the URL the file actually came from <lfam>That's how I got the URL I used in my example <Petter>Right, I actually just discovered this with curl. <Petter>This flies: (uri (string-append "mirror://sourceforge/xcalib/xcalib/" version "/xcalib-source-" version ".tar.gz")) <Petter>I'll be sending a new patch soon. <ng0>reconfigured and rebooted, all still working <buenouanq>what do I have to install, run, or configure to get some kind of spellcheck working? <dadinn>I am always getting an error message when I am trying to install a package, that build users group has no members, but it shouldn't be the case <dadinn>any ideas why this happens? Last time I tried it under a docker container, but have the same issue on the host <lfam>dadinn: When you do `ps aux | grep guix-daemon`, do you see '--build-users-group=guixbuild' in the output? <lfam>If so, do you see any output from `grep guixbuild /etc/passwd`? <lfam>The manual explains how to create the builders' group and the builders in 2.4.1 Build Environment Setup <dadinn>lfam: yes for both questions. In /etc/passwd it only matches for the name of the users <lfam>Okay, how about `grep guixbuild /etc/group`? <dadinn>the name of the users is guixbuildXX <lfam>I'm not sure why that would make a difference, but that's how mine is <lfam>Otherwise, I'm not sure. I'd send an email to help-guix@gnu.org <rekado>8GB on the root file system are not enough to install texlive :( <rekado>the tarball takes up ~2GB, the unpacked sources are ~4GB, the final store item is ~4GB <rekado>building texlive from source I regularly run out of space when the finished build is to be moved into the store. <rekado>I really want to split up texlive <Apteryx>rekado: Also, I find that when Guix run out of space, it's nasty as there might not be able to run garbage collection, so you end up stuck in that situation unless you can extend your disk partition! <Apteryx>Might be smarter to never use *all* the disk space and warn about it when there is, say, 500 MB left. <Apteryx>But even 500 MB is probably too tight to run gc <Apteryx>*might not be enough space left to run <rekado>I have no problem running gc with even 500k left <Apteryx>rekado: OK. In my case I think when I was running gc, it somehow tried building some missing drv and would the run out of space. <rekado>that’s a problem sometimes when you have an older profile and updated Guix. <rekado>I wonder how to go about splitting TeXlive <rekado>maybe we shouldn’t be using Texlive at all and create packages for everything on CTAN…? <Apteryx>rekado: I wouldn't like that much. It's a pain to hunt down every needed package. <Apteryx>I think Debian/Ubuntu breaks it into <Apteryx>1) minimal 2) extra 3) case by case, and already this wasn't too fun to use in my case (I'd just end up doing "apt-get install texlive*" <rekado>but texlive includes almost *everything* that’s on CTAN <rekado>we have a package manager, we don’t *need* to bundle everything in one package. <rekado>we could still offer a meta-package that installs all CTAN packages. <rekado>I think the difficulty here is configuration. <rekado>maybe we’ll need yet another profile hook to generate configuration files. <rekado>installing texlive right now is quite painful. <rekado>for one we don’t offer substitutes, which trips up quite a few users <Apteryx>Ok, I didn't know there were no substitutes for it. What's the reason? Disk space? <rekado>the other issue is that building it all from source takes a long time: downloading the 1.7G tarball, unpacking it, waiting for the very long installation time… <rekado>this has to be zipped up by hydra (on the fly?) <rekado>in the past we had problems with network connectivity resulting in many aborted texlive downloads and lost of lost resources on hydra as it was zipping up the same substitite for multiple times <Apteryx>OK. Yeah TexLive is not a small thing, even when I do the usual manual installation it happens that the connection drops and I must resume the process manually. <Apteryx>Trying to get gpg working with guix. Installed gnupg version 2.1.13, along with pinentry, but when I attempt to decrypt a file from the command line, I get: "gpg: public key decryption failed: No pinentry". Any idea? <buenouanq>you sure your keys were made using gnupg2 and not gnupg1? <Apteryx>buenouanq: That's a good question. Are they not compatible? <buenouanq>I don't understand why or how, and compatible isn't the right word, but they are not. <buenouanq>If you generated your keys with gnupg1, you can't just copy the dir and use gnupg2- <buenouanq>I had this same problem a few days ago and that's what it was. <buenouanq>the permissions might also have to be fixed on your ~/.gnupg and ~/.gnupg/private-keys <Apteryx>OK :(. Strange that the error message would say anything about pinentry rather than gnupg versions. <Apteryx>That's possible, I copied the folder from my backup to my home dir. <buenouanq>did you just install pinentry or pinentry-gnome/gtk/etc? <Apteryx>I was trying to get it to work into emacs. Not sure I actually need "pinentry". <Apteryx>buenouanq: Can you remember what was the error message like when you had failures because of gnupg v1 keys being used with gnupg v2? <buenouanq>run guix package -r gnupg@2 -i gnupg@1 and see if that's it <Apteryx>It worked with gnupg v1. I'll have to figure out how to migrate tomorrow :) <Apteryx>OK! I'll let the solution out if I'm successful. <alezost>sneek: later tell Apteryx re "No pinentry" error: the problem is gpg doesn't know where pinentry is placed, so gpg-agent has be started with --pinentry-program option. One way to do it is to put "pinentry-program /home/<you>/.guix-profile/bin/pinentry" to your ~/.gnupg/gpg-agent.conf <rekado>a problem in cryptsetup that allows you to get a shell by pressing the return key for 70 seconds at the password prompt <buenouanq>this came up the other day and there's some problem with luks <kmicu>rekado: TexLive in Nixpkgs is granular so a user can compile tex to pdf with a ~20MiB of TeX packages e.g. ‘nix-shell --pure -p "(texlive.combine { inherit (texlive) scheme-basic xetex lm; })" --run 'xelatex test.tex'’. The old monolithic TexLive infrastructure is deprecated. Meta sets like ‘collection-science’, ‘scheme-full’ are also provided. Guix could copycat that approach. <rekado>kmicu: yeah, that's nice. I'll look into this to see how we would implement it in Guix. <wingo>is there any mitigation for crashy icecat? :) <jmd>rekado: How does the upstream for TexLive recommend it's done? <rekado>wingo: setting the rendering backends from "cairo" to "skia" <rekado>wingo: i.e. on about:config find gfx.content.azure.backends and gfx.canvas.azure.backends, then change "cairo" to "skia". <rekado>jmd: TexLive is a distribution of its own. They don't seem to have preferences when it comes to distro repackaging. They link to slackware documentation as well as Debian documentation. <wingo>there is a downside to having old browsers <wingo>you can of course resurrect it yourself :) <buenouanq>there is a downside to having new browsers too though <wingo>it was thought that the new icecat being based on stable ff would have no problems in that regard <wingo>anyway maintaining an old browser isn't within guix's budget, so *shrug* <buenouanq>but the latest ff isn't usable either, I'm not talking about stability <wingo>ah in that regard, you appear to be in an unhappy minority :) <rekado>I'm using eww, epiphany, and icecat for my big legacy session <wingo>we must stick to upstream browser development. otherwise is too costly. <buenouanq>I vote we abandon the web entirely and start over. <rekado>(also trying to use xwidget-webkit in the latest development version of Emacs; still needs work to become fully usable) <buenouanq>should I report the oddities I encounter with Gnome on Guix to you guys, or is it a Gnome thing? <rekado>buenouanq: please send email to bug-guix@gnu.org <rekado>I'm not using GNOME on GuixSD (yet), but I plan to switch eventually. If something isn't working it's probably our fault. <buenouanq>It's actually my first time trying Gnome - Richard help me, I'm actually liking it. <buenouanq>Xfce terminal was eating my Alts which I couldn't figure out, so I just switched to the Gnome services. <buenouanq>some things if you click and drag long enough crash X <ng0>is 4.8.8 a security release of linux? <buenouanq>things get stuck maximized or won't change size for me <ng0>well every release is <ng0>but is it advised to update? <buenouanq>the biggest problem with the latest icecat is the search bar <buenouanq>the oneoffbuttons thing doesn't work any more <buenouanq>ng0: before a recent update you could revert to the old usable searchbar with something in about:config but they've removed it now <ng0>that's firefox, not icecat.. <ng0>and if it's icecat, you can remove that by fixing the guix package for yourself <buenouanq>I feel decades away from even attempting something like that. <ng0>civodul: does the cargo-build-system require more reviewers? <civodul>ng0: i think it was pretty much ready but dvc considered it has problems <ng0>is it mentioned in the thread or was it in irc / off list ? <ng0>it's not obvious, at least from the first rust thread in september <ng0>Message-Id: <20160928151538.11679-1-david@craven.ch> this one <ng0>sneek: later tell dvc: what are the problems with rust-build-system which prevents it from being ready? <civodul>ng0: use the mailing list, prolly more effective :-) ***jmd` is now known as jmd
<rekado>I don't understand something about grafts. <jmd>I don't understand a lot of things about them. <rekado>I just built a package for the very first time and after installation it is grafted to a different output. <rekado>grafting '/gnu/store/4946vf93r0rhwzv9wljssjrd2ryfhwyl-rstudio-server-bimsb-1.0.44' -> '/gnu/store/jwd0mi8m7a4ac03im3hz7jcyrk5w24pg-rstudio-server-bimsb-1.0.44'... <rekado>the former is the target directory of the build. <rekado>I don't know where the latter comes from. <bavier>rekado: the package must refer to another package with a replacement <jmd>Presumably, because something upon which it depends, has had a security update. <rekado>can I see which of the inputs caused the graft? <rekado>unfortunately the output is in the wrong order so it's hard to tell why certain things happen <bavier>I'd assume there's some scheme API :) <ng0>it seems like slowly the icecat wakes up from its discussion induced hibernation <ng0>votes and stuff is happening <civodul>rekado: re grafts, you could look at the .drv of the grafted thing to see what's going on <civodul>from the .drv, open the build script, which contains the list of things being grafted <wingo>ACTION has an updated guix. computer sweated for days ;) <civodul>ENOSPC happened right after the core-updates merge <efraim>looks like i'm having problems with SSL certs on my machine actually <lfam>Yeah, I noticed an issue with the linter, but I bet you'd have similar issues with the importers. <thomassgn>Hey can I configure guixsd to not change mbr and grub? <lfam>That's on a foreign distro where $SSL_CERT_DIR points to /etc/ssl/certs, which is provided by Debian and seems to work for my other applications <lfam>efraim: Does that look like your issue? <thomassgn>davexunit: for the guix system commands I assume? Thanks a lot. <davexunit>civodul: --no-grub is honored in 'guix system reconfigure' as well as 'guix system init', right? <lfam>I'm pretty sure that's the case <jmd>We need some kind of dictionary to explain what all our branches are for. <lfam>jmd: Yeah, it should go in HACKING in my opinion <lfam>ng0: It's an error returned by the system call write(2) <ng0>ah, i thought it was some obscure abbreviation <lfam>It basically means the write failed due to a lack of "space", but like so many syscall errors, it's not very specific <lfam>It *is* an obscure abbreviation ;) <lfam>It might be returned by other system calls, I'm not sure <lfam>jmd: There was a recent message on guix-devel that explained the common branches. If you search the archives for 'core-updates' and 'staging' you should find it <lfam>Beyond that, it would be helpful for feature branches to include a note about themselves <catern>hey, gsrc is pretty neat! this is making getting guix working on this ancient Wheezy box which I don't have root on, pretty painless <lfam>ng0: See `man 3 errno` for all the Linux errors <jmd>Actually I think cgit has such a feature. <catern>ng0: there's also a command "errno" in moreutils which will tell you <bavier>catern: still need to install libunistring, bdw-gc, and some other things, right? <lfam>jmd: Wouldn't it be better for the information to be recorded in the Git history itself? It would be nice if cgit could treat a Git-tracked file specially and use it as annotation <catern>bavier: no, bdw-gc is present in gsrc now! I seem to remember that maybe it wasn't, last time I tried <jmd>lfam: You are probably right, yes. <catern>so all I had to do was make -C pkg/other/bdw-gc install <catern>(I did have to do that manully rather than it being auto-installed as a dependency of guile if that is what you mean) <bavier>catern: oh, cool, its not in the last release version that I have to work with, due to no bzr <jmd>Acch! With a recent checkout the wrong decompression program gets used for xz files :( <jmd>bzip2: Compressed file ends unexpectedly <lfam>How recent? In the last hour several changes were made to the download code <jmd>I pulled about 5 mins ago. <catern>jmd: oh yeah, I just noticed that also, heh <catern>(er, wait, I was talking about gsrc, not guix) <catern>bavier: there was a small issue where gsrc was using lzip without it being installed already, but I just installed that too <catern>me too, it's quite a good idea. are you just using it to bootstrap to guix, or something else? <catern>it would be nice if guix was in gsrc <bavier>guixsd gets a nice shout-out on the gsrc package list package, and shepherd is included, but yeah a guix package would be interesting <jmd>I thought gsrc was no longer being maintained. <catern>it's getting updates, so, seems like it is being maintained after all? <bavier>it seems to have had steady updates, but not release since 2014 <efraim>I was putting the kids down, yeah thats the error I get with `guix lint', also guix on debian with SSL_CERT_DIR=.guix-profile/etc/ssl/certs <efraim>also, I now read ENOSPC as "eh, no space" <lfam>efraim: Can you send a bug report about the cert issue? <jmd>efraim: Is euthanasing your children legal in your part of the world? <jmd>Soon will be in the USA. <lfam>It's not that funny for this USA person :/ <lfam>I guess my hope is that I take it too seriously <catern>hmm, I'm trying to build guix-0.10.0 from tarball and at the start I get "missing interface for module (gnutls)" after guix download... I thought I didn't need gnutls-guile? and then at the end I get various errors and eventually ("no such language" tree-il) <catern>what am I missing? the configure went fine, I passed --disable-daemon because I don't have sqlite yet, just want to get the guix command line tools available <davexunit>catern: I don't follow. did you run ./configure and make? <lfam>catern: Why use that old version? <lfam>Unless you are doing security vulnerability research, I recommend using 0.11.0 <lfam>Does anyone ever see `./pre-inst-env` ignore changes made in a source file? <lfam>I made a "stop" build phase for gpgme, but my change isn't being respected <catern>lfam: the same issue happened with 0.11.0, so I tried 0.10.0 :) <catern>"./configure --disable-daemon", then "make" <catern>the failure happens during "make". the actual failure is in GUILEC, I assume, since that sounds like a guile error <catern>guile 2.0.13, btw, which I got from gsrc <catern>hmm, maybe my guile is broken... <catern>strange... ,language tree-il works at the repl, but the compile says ("no such language" tree-il)... <lfam>With that change in my Git tree, using `./pre-inst-env guix build gpgme`, the stop phase is not used <lfam>Is there a typo or something? <lfam>I deleted the old gnupg.go file from the Git tree and my user's ccache <lfam>Alright, I try `make clean` <jmd>does guixsd play nicely with btrfs ? <lfam>I think it should work for non-root partitions. nckx is the most active maintainer of the btrfs-progs package; he should know <lfam>It would be nice to support it for root partitions <lfam>Oh, I see my gpgme problem. I duplicated the (arguments) field <lfam>mark_weaver: Do you remember why we set GPG=gpg2 in the gpgme package definition? Also, why we build it with gnupg-2.0 instead of gnupg@2.1? <lfam>I don't see the variable GPG used in gpgme's 'configure' or 'Makefile' <lfam>Now that we make gnupg@2.1 create the executable as 'gpg' instead of 'gpg2', it seems like we could remove these customizations <catern>so I ran make check on my guile installation and it passed all the tests (assuming "unresolved test cases" aren't failures) <lfam>catern: Does it work when gnutls-guile is available? <catern>well, let me install it and see... <catern>wait, what is this, the error randomly changes??? <catern>it was just "Module named (system vm frame) does not exist" <catern>and now it changed again, it's "no such language assembly" <catern>this is without installing gnutls-guile or even trying to <lfam>If nobody can help you on IRC after waiting a while, I recommend sending mail to help-guix@gnu.org <lfam>I wonder, since you are installing from source, what are you using to provide the dependencies? <catern>gsrc for guile and libgcrypt and make <catern>I suppose one strange thing is that when running ./configure without --disable-daemon, it complains about sqlite not being there - but I can run sqlite from the command line, and it is of a high enough version... <lfam>Okay, you'll need to tell ./configure how to find sqlite <catern>right, and I can probably figure out how to do that, but isn't it weird that configure can't find sqlite when it is already there? <lfam>Also, I presume it's looking for the sqlite library and not the executable you invoke on the command line, although I don't know <catern>it's in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 <catern>but I guess there's no pkg-config file for it <catern>are my _LIBS and _FLAGS just -l/usr/lib/x86_64-linux-gnu/libsqlite3.so.0 ? <catern>oh. the headers seem to be missing on my machine... i see <catern>okay, but even running "./configure" without --disable-daemon, when I run make I get strange errors such as "no such language tree-il" <catern>(oh, context: I just installed sqlite3 the proper way and now ./configure automatically picks it up) <catern>okay, so now I'm trying with a guile I installed from nix <catern>I think this might be a guile problem? <davexunit>I think it's a problem with your environment <davexunit>those problems sound like you have a mix of guile 2.0 and guile 2.1 <bavier>catern: also, the 0.10.0 might not properly auto-detect sqlite, whereas 0.11.0 should just fine <bavier>catern: oh, missed your "works now" message :) <jmd>What does guix use to do dns lookups? <catern>davexunit: hmm! maybe, how would I check? <jmi2k>Hello, I'm looking for help with GRUB. I have root encrypted, and boot fails because GRUB can't load the kernel (/gnu/store/...). Any advice? <efraim>I updated jasper, not sure which CVEs the update covers :/ <efraim>i'm going to have to push the commit without the CVEs mentioned, I don't see them mentioned in the git repo or the website and I don't want to go through the oss-sec mails to pull out the CVEs <catern>also, something mid-build seems to be trying to run git ls-files?! why? <fredmanglis>So, as part of my packaging endevour, I have to add a package that from the look of things, might not be having active development <fredmanglis>But said package is required as a dependency, for one of the dependencies to the final package that I want to get on guix <bavier>fredmanglis: I'd just package it <fredmanglis>The check stage fails with "ERROR: 'rake/rdoctask' is obsolete and no longer supported. Use 'rdoc/task'" <fredmanglis>bavier, cool. So, is there a process to justify deactivating tests? <bavier>fredmanglis: if the failures are serious, they should be fixed <bavier>fredmanglis: otherwise if there are no tests, or a good-faith effort can't fix non-critical failures, then they can be deactivated <fredmanglis>Hmm, '... good-faith effort ...' does that mean, I need to learn some ruby to fix the issues with the tests? <bavier>fredmanglis: check with upstream and see if its been fixed there <catern>the one unfortunate thing about gsrc is that they didn't respond to my email with minor bugfixes... <civodul>jmd: it's not that the wrong decompression program is used, it's that an incomplete item was cached by nginx <taylan>does anyone else use Conkeror with IceCat from Guix? when I try to open a file dialog for uploads, it crashes. <taylan>it outputs "(conkeror:4147): GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.FileChooser' does not contain a key named 'date-format'" so maybe I have a broken config file somewhere <taylan>hmm, there's /usr/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml on my system and it contains no date-format anywhere <taylan>didn't help to add the date-format key to that (copy-pasted from a newer version of the file found on the web). probably it doesn't use that file, but one from a guix package, like glib. let's see... <taylan>oh wait a minute, I'm still using the ...-gnu1-beta icecat package. weird, I have ...-gnu2 in my /gnu/store <taylan>argh, never mind that, the -gnu2 one is an older package with FF 38. so we're still on beta for FF 45, ok :) <taylan>guix gc -R leads me to /gnu/store/mlw128yp44x7fqbxpp5sa1kn2hjrwgsd-glib-2.48.2, in which share/glib-2.0/schemas/ only contains the file gschema.dtd (which contains nothing with FileChooser). but don't really know if this is the issue. <civodul>taylan: do you have the XDG_ something variables set? <civodul>for instance i have: XDG_DATA_DIRS=/home/ludo/.guix-profile/share:/run/current-system/profile/share:/home/ludo/.guix-profile/share:/run/current-system/profile/share <civodul>though it might be that Conkeror should be built with glib-or-gtk-build-system instead of gnu-build-system <taylan>oh I'm just using: icecat -app ~/src/conkeror/application.ini <taylan>I don't have XDG_DATA_DIRS set, but ...DATA_HOME, CONFIG_HOME and CACHE_HOME <civodul>ok, but DATA_DIRS specifies where schemas and other things are looked for <taylan>civodul: aha, setting it to /gnu/store/...-gtk+-3.20.9/share/:/usr/share worked :) thanks! that gtk package isn't in my profile though; maybe it needs to be propagated or something? (after which I'd use .guix-profile/share in that path) <taylan>(that gtk package is the one output by guix gc -R ...icecat) <civodul>ecraven: yeah i noticed that, terrible! ;-) <ecraven>civodul: I wish I had a bit more time, to actually work on guixsd, nixos still has a few advantages and things that I just could not do, last time I checked :-/ <civodul>ecraven: which advantages would you list? <ecraven>well, the first thing I ran into, I want to put ssh keys into my system configuration file, and have those deployed automatically into the image <ecraven>I think I checked about 9 months ago or so, no way to do this nicely in guixsd <ecraven>general lack of packages isn't so bad, I can always add some, but things like a good way to configure nginx/apache for multiple vhosts was another <ecraven>that was amazingly easy to do in nixos, I seem to remember. I would have thought it would be much harder, after running into problems with that with puppet <ecraven>I'll try to find some time and investigate these things in the next few days <ecraven>my use case is deploying an entire server fully automatically based on a system description. so no interactive use at all would be ideal. updates when necessary <davexunit>and thus not appropriate for a guixsd config file <davexunit>setting up nginx/apache configs is just lacking the right service definitions <davexunit>our nginx service can be extended with additional configuration, for example. <civodul>yeah, there's no real solution for private keys, NixOS or GuixSD <civodul>you don't want to have them in the store because they'd be world-readable <civodul>so you need a separate mechanism to put them on the machine <civodul>GuixSD's nginx service is getting better but yeah, probably not as versatile as NixOS' yet <civodul>thanks ecraven for your feedback :-) <jmd>Maybe it'd be possible to have the keys purged from the store as the last thing in the system init process. <davexunit>this isn't a GuixSD/NixOS, this is a more general problem that all the "devops" people face