IRC channel logs


back to list of logs

***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.
<civodul>Hello Guix!
<civodul>oh oh! 237 unread messages
<civodul>(Guix messages)
<rekado>I like the idea of a guided installation, but I cannot remember having encountered an installer that I actually liked.
<civodul>i like Debian's
<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
<civodul>hello dysfun
<civodul>dysfun: there's a patch needing more testing:
<dysfun>hi :)
<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>heya #guix
<paroneayea>I think I'm tossing $65 at this morning.
<efraim>well i'm jealous
<civodul>hey paroneayea
<civodul>that looks pretty nice
<paroneayea>civodul: the people at Think Penguin also wrote out an email of support
<paroneayea>if they think it's serious
<paroneayea>then I think that's a strong sign
<paroneayea>plus $65 is not too much to risk given the strong possibilities if this really succeeds
<paroneayea> the ideas here are pretty cool
<wingo>lkcl tho... good luck to him but istr him starting more projects than finishing
<wingo>maybe this is the one though :)
<paroneayea>wingo: :)
<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
<mckinley_>vlegoll: see Globally-Visible Packages
<efraim>thats for guixsd, not for guix-on-foreign-distro
<efraim>oh, vlegoll did say guixsd
<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
<mckinley_>how do you do it on 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
<civodul>i have to run now, ttyl!
<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
<vlegoll>1st guix boot...
<efraim>sneek: later tell civodul the other two packages I mentioned are also leafs, i'll save the patch for core-updates-next
<sneek>Will do.
<efraim>sneek: botsnack
<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.
<sneek>Got it.
<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>So, is anybody else unable to view our Cgit repo? For example, by clicking from this page?
<lfam>I can't make my browser *not* load with HTTPS, which fails because the server does not support HTTPS
<lfam>If so, you should chime in:
<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>it didn't redirect me
<lfam>Oh, oops :p
<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
***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_>agreed, it's unfortunate
<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
<mckinley_>thank you for working on it!
<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?
<sneek>Will do.
<efraim>sneek: botsnack
<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
<Sleep_Walker>and what is the blocker for ARMv6 to work?
<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>efraim: Here is the Syncthing package definition, if you want to try it out:
<lfam>It does build a working Syncthing. I am using it now :)
<civodul>hi lfam!
<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?
<civodul>a real Go package, cool :-)
<civodul>efraim: what's your "clone error"?
<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
<rekado>yes! virt-manager starts!
<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.
<civodul>oh, but libvirt is C, right?
<civodul>GVariant, hmm
<rekado>libvirt is in C.
<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 :)
<civodul>maybe you really are? :-)
<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
<civodul>lfam: fun :-)
<lfam>Time to think about what go-build-system needs. I'll start the discussion on guix-deve
<rekado>lfam: yay!
<rekado>civodul: yeah, I think I should do this.
<civodul>lfam: finally we can envision a Docker package!