<fps>lfam: do you know at least a little lisp/scheme?
<lfam>fps: I can, with effort, understand the Scheme used in Guix packages and internals. I often need to read the Guile manual. But I haven't written anything in Scheme besides what goes into package definitions, and that's really just the Guix DSL
<orbea>its like lfs in a way, but lot less manual, instread prompts you upfront on how you want to compile everything
<fps>oh, the memories, sneaking into our uni's computer room aged 16 or so, with a staple of floppy disks, leeching slackware 1.x or so, running home, installing everything, and then one disk had a bad sector
<lfam>Hmm, I have a bunch of commits that are just making python-2 versions of packages introduced in earlier commits. So just two lines of code plus an empty line, all together. When I try to squash these onto the "full package" commit, it starts a big chain reaction of having to manually edit ALL the patches. What is going on there?
<efraim>off the cuff idea, would it work to have hydra say that the url for the substitutes is at a gnunet url instead of an http one, and have people interested in making substitutes available run a version of hydra
<davexunit>the version of the guix-devel package that is in (gnu packages package-management) is what got installed to the system profile
<davexunit>and that is surely different than the version that the root user now has after 'guix pull'
<rekado>As I decend further and further into the madness of the tangled web of Ruby dependencies I begin to doubt my decision to package buildr just to be able to build the two dependencies of Maven. Maybe it would be better to spend time to work around the circular dependencies in Maven.
<davexunit>rekado: on the bright side, you've really helped improve our ruby support. :)
<fps>davexunit: oh ok. that was a missing piece of information that actually makes sense
<piyo>"The following environmental variables maybe needed" How do I get this to display again so I can check it? The last time I got this message I was doing a guix package -i guix in my user account on my foreign distro.
<efraim>pypi is down, so I'm going to have to take a break :)
<efraim>civodul: I fixed python2-setuptools-scm and updated it to 1.9.0. I've been working on some of the packages that depend on the python2 version to update and make them build, but with the new packages it'll end up being emails to the mailinglist later
<efraim>so i'm thinking of just uploading the setuptools-scm fix and working out the rest later. As far as I can tell there are no new broken packages from the update
<efraim>I could split it up to the fix and the update if you think that'd be better, but it'll have to be in a little bit, i g2g
<civodul>i think i'm a bit lost but do send the details on list! :-)
<lfam>I have a patch that applies to a program called "python-configobj". It also applies to "python2-configobj". How can I satisfy the linter? It wants the patch's filename to include the package name, but I can't make it match both. Currently, the patch name is "python-configobj-setuptools.patch"
<lfam>To clarify, the linter complains when I lint python2-configobj.
<davexunit>Kodi was a real beast, but I think I've finally wrangled it.
<lfam>davexunit: Awesome. The zope packages are still mostly present (especially your wrangling of the circular depedency) and I'm sure the lets-encrypt package has enough of your work. You really got it off the ground so I'd say you have a piece of it.
<lfam>davexunit: What is your preferred email address for the copyright attribution? I see two in gnu/packages. gnu.org and worcester.edu
<efraim>also just learned, `grep -c foo bar` and not `grep foo bar | wc -l`
<lfam>Hmm, I'm trying to clean up lets-encrypt before submitting for review. I want to drop an old commit but the rebase just results in this awful chain of merge conflicts from the deleted commit to HEAD
<lfam>I split your big commit into a bunch of python-zope... commits, per package. Then, I added a bunch of other dependencies. Then, I created all the python2-zope... packages. So, when I try to squash a python2-zope... onto its python-zope... partner, I get the chain of merge conflicts.
<orbea>I like to look at xmonad, spectrwm and dwm as their own little group of wms, xmonad has haskell, dwm is suckless (minimal) and spectrwm is a nice middle ground, not as extensible as xmonad and not as diy as dwm