bug#28946: licence problem with cufflinks

Ricardo Wurmus writes: > Ricardo Wurmus writes: > >> Hi Dave, >> >>> I noticed that there's a package for cufflinks, but it has a non-free >>> component. It isn't packaged for Debian or Fedora because of that. See >>> . >> >> Thank you

bug#28946: licence problem with cufflinks

I noticed that there's a package for cufflinks, but it has a non-free component. It isn't packaged for Debian or Fedora because of that. See .

bug#27500: [website] wrong link to talk

[I couldn't find instructions on generating patches for the web pages.] Under https://www.gnu.org/software/guix/help/ the second occurrence of /software/guix/guix-fosdem-hpc-part1-20170204.pdf should have "part1" changed to "part2".

bug#25136: locale confusion

Leo Famulari writes: > My guess is that you updated dlove's Guix package definitions, using > `guix pull`, but not root's. This operation is per-user. So, dlove's > locales package is at 2.24, while root's is at 2.23. That may be right. I've lost track of this now, but I'll try to reconstruct i

bug#25138: failing hackage import

Ludovic Courtès writes: > I’m seeing a different error: > > --8<---cut here---start->8--- > $ git describe > v0.11.0-3322-gf80b4d2 > $ ./pre-inst-env guix import hackage -t darcs > Syntax error: unexpected token : (buildable (False)) (at line 494, column 4) > S

bug#25139: making the update procedure more obvious

It's not very obvious to a newcomer how to update to a new release as it's rather buried in the doc. I think it would help to reference "pull" in the installation section of the manual, and maybe in release announcements, and to index "upgrading" and/or "upgrades" in the manual. I'm not sure it's

bug#25136: locale confusion

I followed the instructions for getting locales working in "(guix)Application Setup" to no effect initially. I'm running over RHEL6, if that's relevant, and I have: $ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8"

bug#25138: failing hackage import

With guix 20161208.12 I see the following, which would probably take me a while to debug as I don't know my way around. (With the 0.11.0 version I got a different error without a backtrace. I upgraded after seeing a bug fix for hackage in the tracker.) $ guix import hackage -t darcs Backtrac

bug#25137: repeated updating list of substitutes during install

During a package install (of guix itself) I see "updating list of substitutes" messages repeated through the install, not just at the start. Is that as it should be? I expected guix to use a recent cached version.

bug#21111: possibly bogus in binary tarball

Ludovic Courtès writes: > Interestingly, I do not get this message, both with ‘tar xf’ and > ‘tar xvf’ with GNU tar 1.28. > > I tried with different timezones, and I can’t trigger it. > > Dave: What version of GNU tar do you use, and in what timezone? > > TIA, > Ludo’. It was on RHEL6 in the UK

bug#21111: possibly bogus in binary tarball

The timestamps in the guix-binary-0.8.3.x86_64-linux.tar.xz tarball are all at the epoch, so unpacking it spews messages like tar: ./var/guix: implausibly old time stamp 1970-01-01 01:00:00 I guess that's not intentional, but if it is, it's probably worth a note in the installation instructions

bug#21101: Binary installation clobbers root ownership

If you unpack guix-binary-0.8.2.x86_64-linux.tar.xz according to the manual instructions in "Binary installation", you clobber the ownership of /, /root, and /var. The tarball needs to unpack with root ownership. While you can use --no-same-owner, the current behaviour is pretty unfriendly. (I n