IRC channel logs

<davexunit>what a terrible, terrible build system. nearly every ruby gem does this, too.

<paroneayea>*sad trombone*

<bavier>davexunit: could we provide a parameter to git-fetch to tell it to keep the .git directory?

<davexunit>bavier: that would introduce an impurity

<bavier>I was afraid of that

<davexunit>the best fix would be: convince the Ruby community at large of their sin and get them to repent

<davexunit>;)

<bavier>:P

<davexunit>I haven't been able to come up with a practical, automated solution

<bavier>could we remove the impurities while keeping .git intact?

<bavier>I'm not familiar with git internals

<davexunit>the big issue with the .git directory is that it will be different depending on when you clone it

<davexunit>if you clone guix now, and then clone guix tomorrow after some commits have been made, you'd get a different result if you 'guix hash'd the contents.

<davexunit>even if you checked out the same commit.

<bavier>I see

<davexunit>so preserving .git is not a viable option.

<mark_weaver>davexunit: how about initializing a fresh git repo from the result of git-fetch?

<mark_weaver>what exactly does it need from the git repo? if it only does something like 'git describe', it would be easy to make a fake git script for that.

<davexunit>mark_weaver: it varies from gem to gem, but 'git ls-files' is common

<davexunit>it's hard to automatically fix stuff like this, because the git subcommands used vary

<davexunit>but I could right a phase that gets common patterns

<davexunit>replacing 'git ls-files' with a Ruby array of file-names in the source tree

<davexunit>found with a ftw or whatever

<paroneayea>davexunit: erk

<paroneayea>davexunit: btw, would you possibly be interested in looking at mediagoblin's current ~solution to configure/make stuff

<paroneayea>well, you're pretty busy I guess

<paroneayea>but I'm trying to clean it up

<paroneayea>for the 0.8.0 release

<paroneayea>I'm trying to both support virtualenv/bower type stuff for those who want to use it and also not force that, since "cleaner" environments clearly don't want that

<davexunit>paroneayea: I guess I would just make sure that configure and make don't download dependencies

<davexunit>that would make packagers lives easier

<davexunit>maybe an additional make target could get the deps?

<davexunit>./configure && make deps && make

<davexunit>one extra step, but still easy?

<paroneayea>yeah

<paroneayea>so that's the change I was debating

<paroneayea>currently I have it so

<paroneayea>./configure && make by default *does* build the virtualenv

<paroneayea>but instead,

<paroneayea>even though we have ./configure --without-virtualenv

<paroneayea>probably ./configure && make env

<paroneayea>makes more sense

<davexunit>whichever makes the most sense

<davexunit>I'm not good enough at autotools

<davexunit>maybe configure time is better...

<davexunit>bleh, I dunno. don't listen to me.

<paroneayea>if I had an infinite amount of time, I'd write a guile replacement for ./configure :)

<paroneayea>even though "but shell scripts" (I know, and don't buy it)

<paroneayea>people use scons, so :)

<davexunit>looks I have an adequate solution.

<davexunit>I added a new 'gitify' phase to the ruby-build-system that initializes a git repo in the source tree and stages all of the files.

<davexunit>it's hilarious when you find a rather simple ruby library that requires rails in order to run tests

<davexunit>simply hilarious.

<davexunit>anyway, if I can find a gem that doesn't require any external dependencies to run the test suite, I'll mail a patch set for this stuff. until then, good night.

<davexunit>just when I think I may have found my way to the bottom of the Ruby dependency graph, I find a gem that requires rspec for tests.

<Tsutsukakushi>>ruby

<davexunit>I intend to make sure that guix has good support for Ruby.

<davexunit>the NixOS hackers just import stuff from rubygems.org

<davexunit>which means that they don't run the test suite, among other things.

<bavier`>it occurs to me now, seeing rekado-'s perl module patches, that I could probably trickle-commit some of these perl modules that I'm packaging for hydra.

<rekado_>bavier`: please do!

<rekado_>I was worrying that maybe I'd step on your feet and repackage perl modules you already packaged for hydra.

<bavier`>rekado_: I think I had one or two of the modules you packaged, so no biggie

<bavier`>but yes, I'd feel silly squating on packages when other people might need them, and this hydra package is proving to be more work that I had imagined.

<davexunit>getting any web app packaged is a lot of work.

<bavier`>davexunit: ;)

<davexunit>I have long term goals of getting mediagoblin and gitlab packaged, which require packaging a ton of python and ruby libraries.

<bavier`>it'd be great to have mediagoblin

<davexunit>a lot of dependencies to go

<rekado_>when using snippets are the sources unpacked twice?

<rekado_>I have this application that comes with huge data files and it certainly looks as if the whole thing is unpacked twice.

<davexunit>rekado_: the source tarball is unpacked, then the snippet is applied, then it is repacked.

<davexunit>which will then be unpacked when used as the source of a package recipe.

<rekado_>I see.

<bavier`>rekado_: and hydra serves up substitutes for the patched tarball too

<Xiaoman>What needs to be done for slim to run an Xfce session?

<Xiaoman>It seems that there are no predfined xfce-session-type

<Xiaoman>and I cannot find any slim.conf that does anything to the slim instance

<rekado->Xiaoman: you can create an ~/.xsession file for your user account.

<Xiaoman>Oh, I will try that now

<Xiaoman>Do you mean ~/.xinitrc ?

<Xiaoman>From https://wiki.archlinux.org/index.php/SLiM

<Xiaoman>is slim even looking in /root/.guix-profile/etc/slim.conf?

<Xiaoman>What would I need to define in .xsession?

<Xiaoman>I cannot even see xfce when cycling sessions in SLiM with F1

<Xiaoman>No matter what I do SLiM will only let me choose wmaker or ratpoison :/

<rekado->even with .xsession you won't see any session option in SLiM, but it will start whatever you specified there, ignoring the selected session in SLiM.

<Xiaoman>So, just "exec xfce4-session" ?

<Xiaoman>it doesn't seem to work

<Xiaoman>Do you actually use xfce in GuixSD? Because I really cannot seem to get it to work with SLiM :/

<davexunit>Xiaoman: iyzsong is the original packager for the XFCE programs, so maybe he could help? :)

<Xiaoman>Hopefully :3

<davexunit>I haved used XFCE on GuixSD yet.

<davexunit>I've been happy enough with rat poison.

<rekado->Xiaoman: .xsession must be executable.

<rekado->I use xfce on GuixSD.

*taylanub was just about to type "I miss civodul", sees e-mails from him on the ML

<davexunit>yay civodul is back

<Xiaoman>Awww yeah

<Xiaoman>that did it, thanks rekado-

<Xiaoman>so obvious really ;_;

<davexunit>woo!

<Xiaoman>We xfce4 for on GuixSD now

<taylanub>ouch, I was about to add an import for (gnu packages audio) to (gnu packages video), then noticed one of my previous patches does it the other way around already. :\\ will need to split up some modules I guess. maybe Audacity into its own file?

<davexunit>hello #guix

<bavier`>hello davexunit

<davexunit>back to the ruby mines...

<davexunit>"will davexunit ever make it to the bottom of the dependency graph? tune in next week!"

<davexunit>I think I need to make an rspec package that doesn't run the test suite so that I have an rspec package to feed to all of the packages that rspec depends on to its tests.

<davexunit>these circular dependencies are killing me.

<davexunit>now I've found a gem that doesn't require an external dependencies, but it doesn't tag releases or provide tarballs! hahahaha

<davexunit>this just gets better and better.

IRC channel logs

2015-02-23.log