IRC channel logs

<mark_weaver>yenda: you're running guix out of the git repo, right? if so, can you find an older revision that works, and then use 'git bisect' to determine which commit introduced the problem?

<mark_weaver>I've been running 'guix system reconfigure' recently without problems, but it might be specific to your config.

<mark_weaver>(this is another advantage to running guix from a git checkout)

<yenda>mark_weaver: if I have to use sudo to reconfigure how do I make sudo use my guix from the git repo ?

<mark_weaver>yenda: make /root/.config/guix/latest a symlink to your git repo

<mark_weaver>or alternatively, do: sudo /path/to/guix/pre-inst-env guix system reconfigure /etc/config.scm

<yenda>I think that might be my solution

<yenda>might take a few day to get the answer at hydra's current rate

<mark_weaver>hydra currently has a lot to do. it's rebuilding everything for an expat security update.

<yenda>mark_weaver: that's the kind of tricks that should be in a wiki, I was suspecting it but I wouln't have been able to guess the exact simlink

<mark_weaver>but also, there's no guarantee that the same problem happens on hydra

<mark_weaver>I think these things should actually be described in the manual

<yenda>I don't know I would put it in a wiki until everybody is tired of doing it and someone writes a devel command to set everything up in one line

<yenda>at least I'll do it for myself once I get more confortable with the system to make set ups easier

<mark_weaver>wikis can be great, but they vary a *lot* in quality, and require a lot of effort by knowledgeable individuals to keep them in good shape.

<mark_weaver>also, people would no doubt put stuff in there about how to install non-free software, and that would be a big problem for us.

<mark_weaver>we are committed to not steer users toward non-free software in our documentation

<mark_weaver>also, wikis are by their nature centralized

<mark_weaver>don't get me wrong, some of them are *great*. wikipedia, for example, is a wonderful thing.

<mark_weaver>but then there are others like the openwrt wiki that has given me consistently bad advice, presumably outdated from previous versions.

<yenda>I have learned a lot from arch wiki

<mark_weaver>yes, the arch wiki is excellent

<yenda>even if some stuff were outdated overall it had been of great help

<mark_weaver>IMO, we have not yet reached a scale where a wiki is needed, and it would add to our workload quite a bit IMO.

<yenda>at least the chan is logged but it lacks some formatting

<mark_weaver>but maybe Ludovic will feel differently. he's the maintainer of Guix, on vacation now for the next few weeks.

<yenda>ty mark_weaver it worked

<yenda>* going to bed

<zacts>hi

<zacts>davexunit: I think I chatted with someone here who made a guile version of the CPAN importer

<zacts>but we discussed having a Perl version to help for completeness

<zacts>let me link what I mean

<zacts>davexunit: http://perl-begin.org/topics/cpan/wrappers-for-distributions/

<zacts> https://metacpan.org/pod/CPANPLUS::Dist::Slackware

<zacts>^ this kind of thing for guix

<zacts>I would need to look into more on what is already implemented on the guix + guile side of things, but yeah... If it would prove to be benificial in any way then cool

<davexunit>ah so there'd be an importer both in guile and in perl

<davexunit>?

<zacts>davexunit: yeah

<zacts>well, I think so..

<zacts>you may not even need a guile importer

<zacts>well actually it would need one I think

<zacts>as CPANPLUS I think makes packages

<zacts>but guile operates also on a ports-like system (with install recipes)

<zacts>anyway, I don't know enough yet.

<zacts>I can't remember the nick here who did the current guix importer for CPAN modules

<zacts>I need to look into if this will be useful for guix, and if so I will probably volunteer to do this

<davexunit>awesome :)

<davexunit>ACTION wants an emacs command that runs 'guix download' on a URI and inserts the resulting hash at the point

<mark_weaver>I never use 'guix download' when adding a new source uri. instead, I use 'wget' and then 'guix hash' (after checking the GPG signature, if any).

<mark_weaver>the reason I do this is because if I use 'guix download' and then later botch the URI in the source origin, I won't notice the error

<mark_weaver>if a file with the right hash is already in the store, it doesn't download it.

<mark_weaver>bavier: I've noticed that scalapack takes a ridiculously long time to build on hydra, and that most of the time is spent in the test suite. almost every test times out after 1500 seconds (25 minutes). e.g. see http://hydra.gnu.org/build/610508/nixlog/1/tail-reload which is currently in progress.

<mark_weaver>can you take a look?

<adhoc>last night hydra must have been pretty busy, downloads were timing out

<mark_weaver>bavier: also, the builds consistently fail on i686.

<davexunit>apologies for the github link, but I've been just been giving some very discouraging news after reporting an issue to a ruby project: https://github.com/rails/arel/issues/384

<davexunit>apparently including test files in released gem archives is deprecated, and we should just trust someone else's CI system instead of our that the build is good.

<jsgrant>So, yeah, no luck adding Openssl as an input to/for Racket in getting 'raco pkg' working.

<davexunit>after I had just spent a lot of time converting our existing ruby packages to use .gem archives, most of which had test suites included.

<mark_weaver>bavier: actually, the problem only occurs on i686. the tests timeout after 25 minutes and then the build fails anyway.

<mark_weaver>davexunit: bah, that's no good :-(

<mark_weaver>it's not just a matter of trusting someone else's CI system. just because it works there doesn't mean it will work properly in our system.

<davexunit>yes, that too.

<mark_weaver>bavier: whereas on x86_64 the entire test suite finishes in about 2 minutes.

<mark_weaver>bavier: the current i686 build of scalapack has been going for 9h 40m, and that is typical

<jsgrant>BBL.

<sir123>Good evening gentlemen :) I've accidentally screwed my grub config and am now staring at GRUBs bash like console. Where is Guix's Linux kernel image to boot?

<sir123>The grub manual suggests /linuz, but that doesn't exist in guix

<sir123>*/vmlinuz

<sir123>Does anyone here know how to boot Guix from Grub's command line?

<sir123>Hi phant0mas

<phant0mas>Good morning sir123 :-)

<sir123>Hey phant0mas, do you know how to boot Guix from Grub's command line? It needs a Linux kernel image file, dunno how Guix has modified things :-)

<rekado->bleh, there doesn't seem to be a standard way to run tests for a given R package.

<rekado->there is "R CMD check" but its primary purpose is to check a package tarball, much like "guix lint".

<rekado->"R CMD check" may also run tests, but it checks a lot of other things (like resolvable dependencies, etc)

<phant0mas>sir123: I think mark_weaver is better suited to answer that :-)

<amz3>sir123: do you know how to chroot ?

<amz3>you may be able to chroot into your guix from guix install and redo the configure

<amz3>let's wait mark

<sir123>No, but I can't even boot to anything, grub cant find a kernel to boot

<sir123>And yes :-)

<amz3>just to explain the chroot thing, it's super useful to debug, I mean I used to do that all the time with gentoo, to debug it

<amz3>you start with the usb disk, you mount the disk where guix is installed and /dev, /sys and probably something else then you use chroot

<amz3>you source the correct bash profile

<amz3>it as if you did boot on the disk

<amz3>now that i think about it , you might not need to chroot

<rekado->ah, there's tools::testInstalledPackage which I might call separately.

<alezost>sir123: hi, basically you need to 1) set the root partition 2) load the kernel 3) load initrd

<alezost>so, if your guix partition is labeled "guix", then the commands will be:

<alezost>search --label --set guix

<alezost>linux /var/guix/profiles/system/kernel/bzImage --root=guix --system=/var/guix/profiles/system --load=/var/guix/profiles/system/boot

<alezost>initrd /var/guix/profiles/system/initrd

<sir123>awesome! Thank you so much alezost!

<sir123>It's working!

<alezost>sir123: wow, you are quick at trying!

<alezost>so you have booted into GuixSD, right?

<alezost>don't forget to reconfigure the system to "repair" grub

<sir123>Yup, yup and doing it now :-)

<davexunit>despite the test suite issue, I converted all of our existing rubygems to a new .gem-based ruby build system, and I only had to disable tests for a couple of gems.

<davexunit>ACTION prepares big patch

<cjbarnes18>hi all, where can I find an example of a config that can be used with "guix system vm"?

<davexunit>cjbarnes18: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples

<cjbarnes18>awesome, thanks davexunit

<davexunit>cjbarnes18: here are my relatively simple configs, as well: https://git.dthompson.us/guixsd.git/tree

<davexunit>pardon the self-signed SSL cert

<cjbarnes18>thanks, am I correct in thinking that it would ignore bootloader and file-systems?

<davexunit>file-systems are not ignored

<davexunit>and yes, bootloader is ignored.

<davexunit>the file-systems field contains not only the partitions of physical disks, but also various virtual file systems provided by the kernel

<davexunit>ACTION sends patch for new ruby build system

<bavier>mark_weaver: thanks for mentioning the scalapack issue.

<bavier>mark_weaver: I'll look into it further

<yenda>anyone tried to package docker already ?

<Steap>yenda: I don't think so

<Steap>there are not a lot of Docker fans around here

<yenda>I am not a fan either but I need it for work

<davexunit>several of the problems with Docker enumerated here <http://sirupsen.com/production-docker/> can be resolved by using Guix. :)

<yenda>davexunit: how is your container feature for guix doing btw ?

<Steap>You mean, "using Guix instead of Docker" ? :p

<Steap>davexunit: I need it badly :)

<ifur>yenda: what about rocket? :)

<davexunit>yenda: I'm optimistic that it will be in the next release.

<davexunit>gotta hack some more and write a blog post about it.

<davexunit>I need to collect my thoughts and try to clearly explain *why* Guix containers don't work like everyone else's containers and why that is a good thing.

<davexunit>I know that Docker's image layering technique is bad, but I have a hard time explaining.

<yenda>i'd like to hear about it

<davexunit>as far as I'm concerned, Docker's image layering system is a hack.

<davexunit>they need this hack because they have no way of doing the kinds of build caching that Guix can do.

<davexunit>Dockerfiles are imperative. they are a sequence of steps to execute in a particular order.

<davexunit>and each step of the way, Docker takes an image.

<davexunit>this image, from what I've read, is a copy-on-write diff

<davexunit>so when all the images are stacked on top of each other, you get the correct result.

<davexunit>without this, Docker builds would be very slow because repeated builds that differ at all with a previously built image have to be made from scratch.

<davexunit>with the layers, Docker only has to rebuild starting from the first Dockerfile directive that is different.

<davexunit>Guix doesn't work this way, of course. it's declarative and functional. We know the precise dependency graph to build anything, and we cache the build results of each node in the graph.

<jynxy>ello?

<davexunit>hello jynxy

<jynxy>well that was the easy part

<jynxy>I am a little new to the nix based system. I am having trouble installing the enlightenment desktop

<jynxy>or getting it to load

<jynxy>I think its my env variables but I have set everything I can think of. LC LOCAL PATH LD

<jynxy>put exec in xsession and it still wont load

<jynxy>any ideah?

<jynxy>ello

<jynxy>everyone on thorzeen or are you all just bots

<jynxy>(only a bot would answer that)

<jynxy>fucking trolls

<yenda>what just happened ?

<csed>No idea.

<yenda>probably someone who drinks too much coffee

<csed>That'd be me.

<csed>I get a cup of black coffee for 80 cents.

<csed>I can't be blamed for taking advantage of this.

<davexunit>I step out to get my lunch and this happens...

<davexunit>sorry, forgot we were 24/7 instantaneous technical support

<csed>Now you know.

<yenda>I was just reading some code for 5 min :D

<csed>I'm writing documentation for one of my scripts. I now know that I am shit at writing documentation.

<yenda>and then I was wondering what thorzeen means

<csed>I'm still wondering what thorzeen means.

<davexunit>looks like a misspelling of the drug "thorazine"

<yenda>yes that's what I got from it too

<csed>Huh.

<yenda>I wonder if it's the same guy who made a rant on #docker a few months ago because they were using go and he wanted ruby because he already spent too much time following the ruby hype

<davexunit>lol

<davexunit>well you've got new hype to follow

<davexunit>go really is terrible, though.

<csed>Never tried Go. What's it supposed to be used for?

<davexunit>systems programming

<csed>Huh.

<davexunit>someone described it as "a bold step backwards", and I'm inclined to agree.

<davexunit>it's not the liberating language that Scheme is.

<csed>Then again, most people still throw a parenthesis tantrum when Scheme/Lisp is mentioned.

<davexunit>replace Scheme with Ruby or something

<davexunit>same argument

<davexunit>Go is more like Java

<davexunit>cold, dead.

<csed>Ouch.

<davexunit>no real metaprogramming abilities

<csed>Grabbing my old X61s in a few weeks. Anyone try dropping Guix on one of those?

<csed>Not Libreboot.

<davexunit>several people have installed guixsd on x60s

<csed>davexunit: Glad to hear it, cheers.

<davexunit>most were librebooted, I think.

<davexunit>the only issue I can foresee with the proprietary BIOS is the wireless chip

<davexunit>that requires a blob

<csed>I think it might be Broadcom, not sure. But I usually had issues with that, so I'll figure it out, hopefully.

<davexunit>okay.

<davexunit>just keep in mind that guix doesn't provide the non-free drivers for it.

<csed>Yeah, I know.

<davexunit>phant0mas: have you seen this? http://blog.darknedgy.net/technology/2015/07/25/0/

<davexunit>been seeing it pop up on reddit and elsewhere

<yenda>csed: you might have to use the vanilla kernel

<yenda>I still have to do the switch on my desktop. it's a real pain for the eyes at the moment because the native resolution is not supported (no free firmware for the gpu)

<csed>yenda: Ah. Well, we'll see how it goes. Not that big of a deal if I do.

<yenda>davexunit: I'm always surprised how often Hurd pop up on HN front page, and yet very few people use it/know how it works/what it is

<davexunit>people love to hate it, unfortunately.

<yenda>davexunit: not really on HN they seem to wish for it to gain more popularity

<phant0mas>davexunit: no, haven't checked reddit today :P, thanks for the link

<phant0mas>from what I see he encountered the same problem as I did

<phant0mas>I should get in touch with him, get him involved :-)

<davexunit>yenda: HN is more open to the HURD than, say, r/linux, yes.

<davexunit>phant0mas: yes!

<phant0mas>currently I am investigating an issue with natively building perl on Hurd with guix

<davexunit>I saw that blog post title on HN and was wondering if you wrote it :)

<phant0mas>hehe one of these days I should write one about my experience with the Hurd

<davexunit>yes, definitely.

<davexunit>I'm sure it will be useful to future travelers.

<phant0mas>exactly

<phant0mas>but for now I will have to solve this perl problem,

<phant0mas>there is a problem in glibc's memmove, an assertion fails in PAGE_COPY_FWD_MAYBE

<phant0mas>and the thing is that the solution already exists as debian's glibc works

<yenda>where do you get the sha256 for a git repository ?

<davexunit>yenda: we don't have an automated tool for this yet, but here's what to do:

<davexunit>git clone the-repo.git

<davexunit>cd the-repo

<davexunit>rm -rf .git

<davexunit>guix hash -r .

<yenda>ty

<yenda>is there a template for a new package .scm file ?

<davexunit>no

<davexunit>create the new file, add the file name to GNU_SYSTEM_MODULES in gnu-system.am

<yenda>ok I was missing this last part

***hopses is now known as hospes

<yenda>it's wierd yesterday I did "ln -s ~/guix /root/.config/guix/latest" for "sudo guix system reconfigure" to work with my local repo of guix and it broke my normal user install. I had to rm the symlink for root, the one for my user and redo "ln -s ~/guix ~/.config/guix/latest"

<davexunit>more docker criticism: http://blog.wercker.com/2015/07/28/Dockerfiles-considered-harmful.html

<amz3>davexunit: don't provide links for people to learn more on docker ;)

<davexunit>learn all about docker, and you will see why guix offers something better.

<davexunit>ACTION is extremely frustrated with the Arel devs

<davexunit> https://github.com/rails/arel/issues/384#issuecomment-125690850

<davexunit>rekado-: I know that you thought that .gem archives were like release tarballs, but I think they should be thought of more like the "eggs" that the python build system generates. that is, not source code.

<davexunit>the source code is something else, from which the gem is built.

<davexunit>wdyt?

<davexunit>if so, the big patch I sent to guix-devel this morning is useless, and I'm back to square one with how to leverage rubygems.org to more quickly develop guix packages for ruby gems.

<davexunit>I need to just step away from this again before I throw my monitor in blind rage.

<amz3>davexunit: `>:-/

<yenda>python now has wheel to replace the eggs iirc

<amz3>someday it will replace eggs, it seems to me that there is always a new way to do packaging in python

<rekado->:(

<rekado->well, this sucks.

<davexunit>rekado-: yeah...

<rekado->I can't really say that I'm disappointed in the ruby community, though, because they've always been doing things differently for no good reason... :-/

<davexunit>for a community that often touts how much friendlier their language and tools are, I've run into a lot of roadblocks that simply don't exist for other programming languages

***hopses is now known as hospes

<yenda>is there a particular method to package an app in guix ? or is it just a build/fail/correct loop ?

<davexunit>yenda: pretty much that.

<davexunit>I use 'guix environment' to diagnose certain difficult problems

<davexunit>to avoid having to start builds from scratch after each change

<yenda>do you have unconventionnal packages in mind that don't use ./configure ?

<davexunit>I've encountered those

<yenda>can you name them I'm looking for exemples

<yenda>please :)

<davexunit>yenda: search for "delete 'configure"

<davexunit>you should find some packages that delete the configure phase

<yenda>ty