IRC channel logs


back to list of 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>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>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.
<davexunit>I intend to make sure that guix has good support for Ruby.
<davexunit>the NixOS hackers just import stuff from
<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>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 ;_;
<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.