***kelsoo5 is now known as kelsoo
<rekado>argh, this again: Error starting virt-manager: structure type 'GVariant' is not supported yet <rekado>I encountered this GVariant thing in ibus before but I don’t remember if I ever figured out how to fix it. <rekado>I like the idea of a guided installation, but I cannot remember having encountered an installer that I actually liked. <efraim>other than trying to install gentoo or arch into a spare partition, debian's is the only installer I've ever used <efraim>and the time i installed guixsd on my P4 <rekado>I used the installers of Fedora, CentOS, and Ubuntu. <dysfun>hey folks, i was discussing with someone the other day about the encrypted root support. i've got some time to look into it this afternoon, so are there are any design documents or a bug to hang things off? ***lumidify_ is now known as lumidify
<dysfun>ACTION waits for firefox to wake up <dysfun>oh yes, i just found this bug a minute ago <dysfun>i'm not actually on guix, so i need to write a configuration to test it <efraim>(symlink a b) means have a, want b? <rekado>efraim: the docs say (symlink oldpath newpath) <rekado>"Create a symbolic link named NEWPATH with the value (i.e., pointing to) OLDPATH." <efraim>i can never remember with `ln -s' either <dysfun>i like to pretend that -s takes an argument, the target file <myglc2>When I do 'M-x guix-edit RET screen RET' I get "Autodoc not available (No Geiser REPL for this buffer (try M-x run-geiser))" but guix already has two REPLs running and it opened this buffer. Should I really have to start up another REPL? <paroneayea>civodul: the people at Think Penguin also wrote out an email of support <paroneayea>plus $65 is not too much to risk given the strong possibilities if this really succeeds <wingo>lkcl tho... good luck to him but istr him starting more projects than finishing <wingo>maybe this is the one though :) <paroneayea>wingo: well, I'm willing to risk $65 on this, given how dire things are currently :) <mckinley_>rekado: I believe you previously started a discussion related to a maven build system on the mailing list; I was wondering if you'd already done the work to package Maven itself (I've been fiddling with the idea, but found some issues) <efraim>civodul: I have a fix for the missing gs binary in ghostscript in core-updates, but it involves rebuilding ghostscript and its ~1200 dependants <efraim>i tested it on lout, which doesn't depend on texlive <vlegoll>Hello, I'm just starting to fiddle with guixsd, and while I read the manual (almost) I didn't find an answer to a simple question: how do I install software so that it is available for all users, in their PATH. I installed, as root (guix package -i vim) but it is only in root's PATH, should Ire do the install for each other user ? Did I miss it in TFM ? Thanks <efraim>thats for guixsd, not for guix-on-foreign-distro <mckinley_>oh, thought they said they were fiddling with guixsd... <efraim>i'm so used to seeing the question phrased as guix on a foreign distro <vlegoll>D'oh, how did I miss that ? thanks... :-)) <civodul>efraim: i purposefully removed the 'gs' binary; what's the problem exactly? <efraim>I haven't tried it yet, but I think using `sudo guix -i foo' and stow to symlink it to /usr/local <efraim>also fastcap and asymptote want the gs binary specifically <efraim>I just added a symlink from gsc to gs <civodul>efraim: Lout is fine, it's just a leaf; can we patch the other packages for now? <civodul>it seems easier than rebuilding it all <civodul>i did that in 61dc82d9b90d0545739c30bfc33003bd062071f0 <vlegoll>I've installed guixsd in a qemu VM, booted from the usb image (as someone pointed it as doable to me here yesterday) <efraim>asymptote and fastcap are also leafs <efraim>sneek: later tell civodul the other two packages I mentioned are also leafs, i'll save the patch for core-updates-next <lfam>Does anyone know a way to ignore a source tarball that is already in the store and double-check that a package's origin works correctly? <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, alezost says: what's the problem of taking hash from a failed build? <lfam>Something like `guix build --source --check --no-substitutes foo`, but that actually tries to download the file again? <vlegoll>mckinley_: so to be sure I don't mess it, I should add the pkg name to (package ...) in /etc/config.scm then run guix system reconfigure (with eventually a guix pull before) ? <efraim>lfam: I've messed that up enough times that I actually run `guix gc ${guix build foo -S)' and then `guix build foo -S' again to make sure it works <lfam>sneek: later tell alezost: This is a bit paranoid, but the remote server could detect the signature of the Guix downloader and serve something different. And, I think it's worth being a little paranoid since we are making packages for others to use. <lfam>efraim: I was hoping there was something faster than starting the garbage collector, who takes a little while to wake up :) <mckinley_>vlegoll: I'm not sure what your configuration looks like at the moment. The base configuration when I started was different and didn't use the nice specification->package procedure described in the documentation. If your configuration isn't using that, you'll also have to pull in the package module the package resides in via use-package-modles <lfam>I can't make my browser *not* load git.savannah.gnu.org with HTTPS, which fails because the server does not support HTTPS <efraim>when I click on it it loads correctly, when I add https at the beginning it fails with "ERR_SSL_PROTOCOL_ERROR" <vlegoll>mckinley_: it's the sample minimal one from /etc/configuration/ on guix-usb-install-0.10.0, edited for hostname, partition, nothing fancy, I even removed the tcpdump package that was there as an example <lfam>efraim: What browser are you using? <lfam>efraim: Do you have a Firefox derived browser available to try it in? <lfam>I'd appreciate another data point :) <lfam>If not, don't worry about building or installing it <efraim>i have firefox on debian I can try <lfam>I'm trying to figure out if something obscure broke in my Firefox or if there is actually something wrong on the Savannah servers <efraim>when I click on it it defaults to http, https fails to load <lfam>Okay, can I quote that line in my bug report? <lfam>Or, can I quote this whole conversation? <lfam>efraim: Maybe I misunderstood your message. Did it redirect you to https on Firefox? <efraim>i do have the https-everywhere extension installed <lfam>I don't have anything like that <lfam>This is so strange, it's started happening to me on lists.gnu.org. ***kelsoo1 is now known as kelsoo
<rekado>mckinley_: yes, I have started packaging the dependencies of maven. <rekado>I still didn’t get around to revisiting the patches <rekado>I have a number of unpushed patches for Java bootstrap packages. <rekado>maven itself has dependencies that would need maven to build easily, so I’m trying to build them and their dependencies from source with ant. <rekado>the alternative is to use the binaries of these dependencies, but I don’t want to do that <rekado>I hope that by the end of this week I’ll find some time to push the java packages I have lined up <mckinley_>rekado: that's great to hear! I was a little nonplussed to find the source releases include a binary, and wondered how to proceed; it seemed just to build maven we needed to nail down the creation of the maven-build-system, and you'd brought up some challenging points to it in the mailing list <rekado>mckinley_: a lot of bootstrapping work is ahead of us to get a maven-build-system. <rekado>unfortunately, it seems that nobody is building java applications completely from source. <mckinley_>Seems like there are a lot of things that need to be figured out, since it's been so long since some of these things have been built from source <rekado>my pleasure! Sometimes it’s fun to try to work this out. <rekado>(it quickly turns into frustration and desperation, and that’s when I switch git branches and focus on something else for a few weeks :)) <rekado>this week I’ll try to switch back, though, and post some news to the mailing list <mckinley_>rekado: understandable! I came on here out of frustration, after finding the source release included a jar; didn't want duplicate work, or anguish ;) <efraim>sneek: later tell civodul is it possible that my clone error is hiding that my aarch64 patch forgot to add aarch64 to package-management.scm? <jmd>I read that guix cannot run on the Raspberry Pi. Is that just because of lack of disk space or is there a more fundamental reason? <efraim>jmd: the RPi is armv6 which guix doesn't support, the pi-2 and pi-3 i think can run guix <efraim>i'm not sure exactly, i think its the low ram mostly <efraim>beyond not having the code in guix for bootstrapping <lfam>Probably, nobody has done the work. And I bet that many Guix people are turned off by the ARMv6 Pi's dependence on a closed-source GPU blob to run the OS <lfam>What does it typically mean if the builder fails to produce the output path? <efraim>i sometimes get that with Qt modules when nothing actually built and there's nothing install <efraim>normally have to look up a couple lines to see what the real error is <lfam>I probably made a mistake in my custom install phase. It must not be writing anything to the output directory <lfam>Using the go-1.5 package from guix-devel: @ build-succeeded /gnu/store/pvkwzn6691qp1y21160nffba114x8x4b-syncthing-v0.13.10.drv - <efraim>is that a full package definition with dependancies? <lfam>It uses the "vendored" dependencies, to use Go's word for bundling, so it's not ready. But it does build them all from source, so it's not a bad work in progress, in my opinion :) <efraim>when you first wrote it i assumed you did `guix environment --ad-hoc go -- go build syncthing <lfam>I did that yesterday, today I have a package definition <efraim>some, but right now i'm still working on fdroid and onionshare <efraim>fdroid is actually pretty close, but i need to actually set it up my own repo to test it <lfam>It does build a working Syncthing. I am using it now :) <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, efraim says: the other two packages I mentioned are also leafs, i'll save the patch for core-updates-next <sneek>civodul, efraim says: is it possible that my clone error is hiding that my aarch64 patch forgot to add aarch64 to package-management.scm? <lfam>I might have spoken too soon. Syncthing runs, but it might not be working correctly. It doesn't seem to be connecting to the rest of my cluster <civodul>it's written in C tho, less fun than with Syncthing ;-) <rekado>it’s python + gobject-introspection and lots of weird stuff <rekado>this gobject-introspection bug was related to not using the correct version of python-pygobject <rekado>if the version is too recent we get this strange and unhelpful GVariant error. <rekado>virt-manager has a lot of undeclared dependencies. <rekado>it’s at least the third time that I think I’m finally done with it :) <rekado>things usually just fall apart at runtime. <rekado>we’ll see. I’ll continue tomorrow. Some of the patches aren’t very nice, unfortunately. <rekado>libosinfo needs an unversioned file, for example (which probably means that the hash will change at some point) <lfam>I restarted Syncthing several times, and now it's working! <civodul>rekado: maybe we should try and ask upstream if they can do something about it <lfam>Time to think about what go-build-system needs. I'll start the discussion on guix-deve <rekado>civodul: yeah, I think I should do this. <civodul>lfam: finally we can envision a Docker package!