IRC channel logs

<mbuf>what do I need to do to run guix using VirtualBox (VB)? Can I also create a new instance in VB and install Guix on it?

<mbuf>I don't want to install it along my existing GNU/Linux system

<efraim>that should work, but most of us got started by installing it side-by-side with our existing system using guix instead of guixsd

<efraim>they work nicely together

<efraim>s/work/play

<mbuf>efraim, I see

<mbuf>efraim, is there a tutorial or blog post that I can refer+

<mbuf>s/\\+/?/

<efraim>i followed the documentation from the online copy of the manual https://www.gnu.org/software/guix/manual/html_node/index.html for binary installation

<mbuf>efraim, okay, will give it a spin

<mbuf>efraim, thanks!

<efraim>:)

<efraim>I think there's supposed to be a step 8 with `$guix pull` to get the user started after the rest of the system is all set up but I don't remember exactly about this point

<efraim>I remember running `guix build hello` to make sure it was working, so I don't think `guix pull` is necessary to get started, but highly suggested to bring you up to a more recent date

<lfam>Is there a Guix way to `set -x` on a packages ./configure script?

<lfam>package's

<mbuf>in step 5, "drop ~root/.guix-profile/lib/systemd/system/guix-daemon.service in /etc/systemd/system" means cp or mv?

<mbuf>in step 6, "ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix" there should be a dot at the end?

<mbuf>in step 5, do I expect the guix-daemon to run in the foreground and not return to the terminal prompt? step 7. tells me "warning: failed to install locale: Invalid argument"

<mbuf>I have the binary install, just need to know how to use it

<toothbrush0>Hi Guix!

<mbuf>toothbrush0, Hi

<mbuf>toothbrush0, what's with the 0?

<efraim>mbuf: i'd go with cp for step 5

<efraim>step 6 i don't rremember offhand

<efraim>for guix-daemon, without using the systemd commands, if you add " &" to the end of the command it'll run in the background

<mbuf>efraim, it is running in the foreground, and that is fine; when I do "guix build hello", I get "warning: failed to install locale: Invalid argument"

<toothbrush0>mbuf: the username `toothbrush' was taken, way back when

<toothbrush0>prosaic as that story may be :P

<efraim>that warning is fine

<mbuf>efraim, guix build error: build failed: the group 'guixbuild' specified in 'build-users-group' does not exist

<efraim>did you add the guixbuilder users on https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup

<mbuf>efraim, ahh! I skipped step. 4

<mbuf>efraim, okay, I did step.4 and restarted the guix-daemon. Now doing "guix build hello"

<mbuf>efraim, it worked! how do I run the executable?

<efraim>`guix build foo` builds the package, `guix package -i foo` (builds and) installs the package

<mbuf>efraim, I just used /gnu/store/zl8...-hello-2.10/bin/hello

<efraim>but you can find the path in /gnu/store

<mbuf>efraim, since this is just the package manager, there is no login, I guess; for which I need to use guixSD

<efraim>right

<efraim>but it does work as is also, i'm running it along side debian atm

<efraim>ACTION goes to make lunch for the kids

<mbuf>efraim, "as is"?

<efraim>i mean as a second package manager together with the native one for your distribution

<mbuf>efraim, okay

<davexunit> https://twitter.com/EricJMRitz/status/657192850652844032

<davexunit>bleh

<davexunit>either this person didn't enable substitutes or is using the 0.8.3 binary release which no longer has substitutes available.

<efraim>should we add `$guix pull` as step 8 for the binary installation?

<davexunit>probably

<bev__>If you are working on improving the new user experience: I found/find it very confusing that the guix homepage is actually the GuixSD homepage and the link to "Guix package manager" points to some random subchapter of the manual instead of https://savannah.gnu.org/projects/guix

<davexunit>the home page is for both things.

<davexunit>they are a single project.

<keverets>True, but one is a superset of the other, and there's room for confusion when a new user just wants to use the package management to get their feet wet

<davexunit>bev__: what do you find useful about the savannah page that you don't find useful about the current link?

<keverets>I don't think the savannah page is significantly more enlightening for someone wanting to try the package management side

<keverets>I'd think of it in the way that Debian the project is different than Debian packages, both of which are different than Debian the distribution

<davexunit>yeah, that's my feeling. but it is clear that there is some confusion and it would be nice to find something that fixes it.

<keverets>though that analogy falls down a bit since there is rarely uptake of debian packages without a debian derived distribution

<davexunit>you can run guix on another host distro, but you still get all the tools to build GuixSD VMs and disk images.

<keverets>which is very cool, but not entirely clear from the guix homepage

<davexunit>yes, we should make it more clear.

<davexunit>I don't know the best way to do that.

<keverets>I'd expect two main sections on the page, one for "GuixSD (the full, raw Guix Goodness(tm)" and one for "try on your current host, (with bonus that you can easily make GuixSD VMs & disk images)"

<davexunit>best to start a discussion on the mailing list about it

<bev__>well, the savannah page has the links to the source code and the home page has not, as far as i can tell

<keverets>true... that's a more appropriate forum

<davexunit>the home page links to the source

<davexunit>there's a big "download" link in the nav

<keverets>in a footer, but it's there

<keverets>oh, I assmed "Download" was for GuixSD, and "Source code under the GNU AGPL" was for the packages

<keverets>but looking at it, that's probably for the page itself

<keverets>since it links to guix/guix-artwork.git

<davexunit>the code for the site is AGPL licensed

<davexunit>the site is a static website built with a Guile program.

<keverets>ah, makes sense

<keverets>actually, the entire "Download" section is pretty clear (with links to "Installation instructions." for all 3)... that could be put on the front page

<bev__>ok, with "source code" i mean of course the git repository, not a source tarball

<keverets>bev__: I wouldn't consider that "of course", but that's from a long time of playing with free software pre-git

<keverets>that said, a link to the repo would be lovely

<keverets>that's available under "Contribute", but that's a ways from the link to the tarball

<davexunit>the download page should link to the repo at the bottom, I think.

<davexunit>there are other links to the repo around.

<keverets>since the source to the site _is_ available as a git repo, perhaps a merge request/pull request would be useful

<davexunit>you can send patches to guix-devel

<davexunit>we should advertise that fixes to the website can be sent there.

<bev__>keverets: i always wondered, what was the workflow before git? do you download the source tarball, make your changes, and then get another pristine copy of the tarball to make your diff's against?

<davexunit>there were many other version control systems used.

<davexunit>mostly centralized ones

<davexunit>like cvs and subversion

<bev__>sure, but they would require write/commit rights before you can commit, right? i mean if you just wanted to contribute some drive-by patch to an open source project

<keverets>you could use rcs locally if you cared, but for one-off project submissions generally a diff emailed to the author/mailing list

<keverets>look at lkml.org ... the history goes way, way back

<bev__>ok, and my question was: what was the workflow for generating the diff? :D

<rekado>the "diff" programme?

<keverets>bigger projects would host CVS or SVN servers, but most were a literal "diff" emailing workflow (that I used)

<keverets>sourceforge (and from that, savannah) was a huge improvement, before it became terrible, since anyone could create a CVCS

<keverets>sourceforge became terrible, not savannah

<bev__>so you would have two copies of the source tree, one for editing and one for diffing?

<rekado>bev__: you can diff individual files.

<keverets>src/project-orig/ and src/project typically. Usually keeping the .tar.gz around incase one needed to recreate src/project-orig

<bev__>rekado: i know, but you need something to diff against ;)

<keverets>upstream would usually have an http server or ftp server to grab the source from, even if you deleted it. Could just take a while with slow connections

<keverets>ftp://ftp.gnu.org/gnu has been a treasure chest for many, many years

<bev__>keverets: ok, i see

<keverets>there are downsides, of course. My contributions to GNU xhippo, for instance, are probably lost in the sands of time since I believe there was no archived mailing list so I probably emailed the diffs directly to the author

<keverets>though general credit could still show up in "CONTRIBUTIONS" or "ChangeLog"

<keverets>lacking a "blame" equivalent was sad, too

<keverets>since it was hard to see why many lines were changed the way they were between versions

<keverets>anywho, enough reminiscing... back to work

<bev__>tbh, i would be suprised if there were upsides ;)

<bev__>resumable downloads if the connection is unreliable maybe

<bavier>yay for new haskell packages!

<toothbrush0>bavier: Hey Eric,

<toothbrush0>i'm looking at fixing up the haskell-build-system to check if perhaps build-type == Configure, but i'm not 100% sure of the best approach

<toothbrush0>do you think it'd be acceptable to do something similar to `grep pack.cabal "^ *build-type: +Configure *$"` or is there a more sophisticated approach one should take?

<bavier>toothbrush0: hi!

<bavier>thanks for getting the branch merged

<bavier>I think (file-exists? "configure") would work in this case

<toothbrush0>bavier: that's cool, no stress :)

<toothbrush0>ah

<toothbrush0>but are we sure that file-exists(configure) <=> build-type: Configure ?

<toothbrush0>excuse my awful notation

<bavier>the cabal docs say that such a file is required if "build-type: Configure"

<toothbrush0>yes

<toothbrush0>but the other direction of the implication bothers me

<bavier>yes

<toothbrush0>but i guess that an extra ENV variable cannot hurt

<bavier>right

<toothbrush0>okay

<toothbrush0>i'll try that then

<bavier>thanks

<toothbrush0>i'm tempted to put it into the configure function in haskell-build-system.scm, do you agree?

<toothbrush0>(i'm still exploring how it works, so bear with me :p)

<bavier>yeah, that would be a fine place for such a thing

<toothbrush0>great

<toothbrush0>then i think i'm understanding

<toothbrush0>seems like some serious Haskell-wizardry went into figuring out how to create the haskell-build-system!

<toothbrush0>i have no idea at the level of packagedb's etc how GHC works, even though i've been doing it for so long :o

<bavier>:)

<toothbrush0>bavier: that wasn't too hard, it seems to work!

<toothbrush0>:D

<toothbrush0>i'll send a patch soon, then everyone can tell me why it's a kludgy hack.

<bavier>toothbrush0: great

<toothbrush0>bavier: i think it's best if i send a fixup patch for the affected haskell packages in one commit, WDYT?

<bavier>toothbrush0: I think it would be fine to send them in two patches

<toothbrush0>bavier: great, done.

<toothbrush0>i haven't come across cases that need the "SHELL" variable, so i haven't added it. i figure that can be added later, if it turns out to be necessary.

<bavier>for sure, sounds good

<lfam>"guix build: error: build failed: invalid hash `3c30ec3d96c4e7a4879902845bef78d0b33d6e898298e238b0cfe2be61'" What hash is that?

<bavier>the source hash?

<lfam>bavier: The source hash in the format that Guix expects? It's the wrong length. And usually when I get that hash wrong, Guix tells me what the hash actually is. In this case, that is the only output.

<bavier>lfam: the "invalid hash" error probably gets thrown before an "incorrect hash" error

<lfam>bavier: vim is eating my copy+paste by interpreting part of the hash as "return to normal mode"

<lfam>That's the problem

<bavier>ahh

<lfam>Once in a while my convenience remaps bite me :)

<lfam>Is there anything on the net about how to read Guile backtraces? For example, I've found tutorials on reading Valgrind output. It would be helpful to me :)

<lfam>Sometimes I can muddle through

<alezost>I don't think there is a tutorial on reading backtraces

<lfam>I will have to tutor myself

<Necrosporus>Does GuixSD work without systemd?

<toothbrush0>it only works without systemd :)

<toothbrush0>it's based on DMD

<Necrosporus>is it possible to install regular linux kernel or certain firmware, if my hw doesn't work without it?

<toothbrush0>by default it works with linux libre, which is mainstream linux minus proprietary (non-free) blobs

<toothbrush0>but i'm not sure about your question; i haven't tried.

<paroneayea>you could install a blobby kernel, but it won't be supported by the guix project directly

<paroneayea>but there's nothing stopping you from starting a guix-heresies repository if you like

<toothbrush0>paroneayea: nice name :P

<paroneayea>but it won't be advocated here :)

<paroneayea>toothbrush0: feel free to use it ;)

<toothbrush0>heh :)

<toothbrush0>to be perfectly honest, i'm still a faker: only using Guix, not GuixSD

<paroneayea>nothing wrong with that

<paroneayea>I'm doing that

<toothbrush0>i'd like to "upgrade" sometime

<paroneayea>many of us are, and would like to "upgrade" as well :)

<toothbrush0>but i only have one machine, making it a little, um... all or nothing?

<paroneayea>toothbrush0: well you can always iterate on your system using "guix system vm" until it does what you want

<toothbrush0>true. that assumes non-laziness though

<paroneayea>there's nothing that can solve laziness

<toothbrush0>but indeed, in all seriousness, i'll try finishing school first, then go at it :)

<paroneayea>well maybe except (force) #vaguejokes

<toothbrush0>seq toothbrush

<toothbrush0>:P

<toothbrush0>ACTION seq GuixSD

<toothbrush0>ACTION `seq` GuixSD

<toothbrush0>argh, thanks fingers

IRC channel logs

2015-10-23.log