bug#19219: New command-line syntax for package + version?

2016-01-01 Thread Leo Famulari 
On Fri, Jan 01, 2016 at 04:55:40PM +0100, Ludovic Courtès wrote:
> Efraim Flashner  skribis:
> 
> > On Wed, 30 Dec 2015 20:16:31 -0500
> > Leo Famulari  wrote:
> >
> >> On Wed, Dec 30, 2015 at 11:45:14PM +0100, Mathieu Lirzin wrote:
> >>  [...]  
> >>  [...]  
> >>  [...]  
> >>  [...]  
> >>  [...]  
> >>  [...]  
> >> > 
> >> > I'm OK with that.  Since choosing the reserved characters is not a
> >> > technical decision, maybe we could poll users?  
> >> 
> >> I think we should poll a big list of packages and see which characters
> >> are most safe to use.
> >> 
> >> The question is: which big list? Debian's?
> >> 
> >> 
> >  
> > When debian adopted multiarch 
> 
> [...]
> 
> I forgot to reply to Leo’s message, but it seems clear to me that it
> only makes sense to discuss on Guix mailing lists.  I don’t think anyone
> else cares about the syntax of Guix’s command-line interface.  ;-)

I don't mean that we should discuss it on Debian's mailing list. I mean
that we should consult the largest list of packages that we can find in
order to learn which characters are safest to choose as reserved. Debian
has a very long list of packages.

> 
> Ludo’.

bug#19219: New command-line syntax for package + version?

2016-01-01 Thread Leo Famulari 
On Fri, Jan 01, 2016 at 04:25:40PM -0500, Leo Famulari wrote:
> On Fri, Jan 01, 2016 at 04:55:40PM +0100, Ludovic Courtès wrote:
> > Efraim Flashner  skribis:
> > 
> > > On Wed, 30 Dec 2015 20:16:31 -0500
> > > Leo Famulari  wrote:
> > >
> > >> On Wed, Dec 30, 2015 at 11:45:14PM +0100, Mathieu Lirzin wrote:
> > >>  [...]  
> > >>  [...]  
> > >>  [...]  
> > >>  [...]  
> > >>  [...]  
> > >>  [...]  
> > >> > 
> > >> > I'm OK with that.  Since choosing the reserved characters is not a
> > >> > technical decision, maybe we could poll users?  
> > >> 
> > >> I think we should poll a big list of packages and see which characters
> > >> are most safe to use.
> > >> 
> > >> The question is: which big list? Debian's?
> > >> 
> > >> 
> > >  
> > > When debian adopted multiarch 
> > 
> > [...]
> > 
> > I forgot to reply to Leo’s message, but it seems clear to me that it
> > only makes sense to discuss on Guix mailing lists.  I don’t think anyone
> > else cares about the syntax of Guix’s command-line interface.  ;-)
> 
> I don't mean that we should discuss it on Debian's mailing list. I mean
> that we should consult the largest list of packages that we can find in
> order to learn which characters are safest to choose as reserved. Debian
> has a very long list of packages.

Of course, Debian has to choose how to name their packages, so the list
provided by `apt-cache pkgnames` is not the same as the list of upstream
names. But it does give some idea of what is possible once everything is
packaged.

I did this:
$ apt-cache pkgnames | tr -d 'a-zA-Z0-9' | tr -d - | tr -d '\n'

The only remaining characters were '.' and '+'. So it could be possible
to reserve : and @ without causing too many problems.

> 
> > 
> > Ludo’.

bug#19219: New command-line syntax for package + version?

2016-01-01 Thread Andreas Enge 
On Thu, Dec 31, 2015 at 10:26:56AM -0600, Christopher Allan Webber wrote:
> If the @ is for the optional choice of including a version, I'm good
> with it.  It does mean we can never have @ in our package names, but
> that might be a good restriction anyway :)

According to the packaging guidelines, package names should only contain
lower-case letters, digits and "-" (the formulation is a bit ambiguous,
but this is the intent). So any choice of separators apart from "-" should
be fine, and we can happily bikeshed!

Andreas

bug#22280: failure of `guix graph --type=bag-emerged hello`

2016-01-01 Thread Leo Famulari 
When attempting `guix graph --type=bag-emerged hello`, the program
crashes and produces a backtrace.

I am using an up-to-date Guix on Debian Stretch.

$ uname -a
Linux jasmine 4.3.0-1-amd64 #1 SMP Debian 4.3.3-2 (2015-12-17) x86_64 GNU/Linux

Here is the full output of the command invocation:

;;; note: source file /home/leo/pkgs/leo/packages/borg.scm
;;;   newer than compiled 
/home/leo/.cache/guile/ccache/2.0-LE-8-2.0/home/leo/work/pkgs/leo/packages/borg.scm.go
;;; note: source file /home/leo/pkgs/leo/packages/ddar.scm
;;;   newer than compiled 
/home/leo/.cache/guile/ccache/2.0-LE-8-2.0/home/leo/work/pkgs/leo/packages/ddar.scm.go
digraph "Guix bag-emerged" {
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" [label = 
"hello-2.10", shape = box, fontname = Helvetica];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/fighqx3qn58f4kzs957zy40axbyq1rp9-hello-2.10.tar.gz.drv" [color = 
red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/al3z0qyj1jg7s0j53cbmdnzis2q1qkzv-tar-1.28.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/8xqlzrg2gv9saqq77zlxzgq34yj3il1v-gzip-1.6.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/0dlz07rdvvl5ii16gbks1j5jd334g20b-bzip2-1.0.6.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/gq2118sa24fglpi023wfx04570bx36hv-xz-5.0.4.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/c8kp50w8j5z6dya08kxgmj56b9m37l51-file-5.22.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/ja8pgg14zprdzjlrkga8mv3dmiv3bx9m-diffutils-3.3.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/0c38rgzbhvzwb2z4zq4200b3n8pdghsi-patch-2.7.5.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/hcccb1xi5xhqkzjy4im9vigii16pl4d0-sed-4.2.2.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/xq3k5hc1ginpn7wy0n5ifh79nmh5fmvc-findutils-4.4.2.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/nnmad3s5p1smizqd92vwbzj0f6rxk70w-gawk-4.1.3.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/ph732mz4gmy3j1fir2aygwl8w6vpj4ak-grep-2.21.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/nc28660wl2wjqch09lfnq63xlrcy9pk6-coreutils-8.24.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/ky80kk7lqm6s1w2i3bammal2mxsl7j7r-make-4.1.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/ldnsawbw8va4j7nhda7lb1hkvxm0w69q-bash-4.3.39.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/id5cfnyfk99qwd2i9mccq0mg6awk8m91-ld-wrapper-0.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/vh5nil1s5pss0nhvzg4dypr3k6cvsj72-binutils-2.25.1.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/972yibayx2vzs9lfynwj9baz0b27nbjs-gcc-4.9.3.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/qy66yjqpnxb6p6nawfzvqyx7fs1qn25v-glibc-2.22.drv" [color = red];
  "/gnu/store/17n7nhssy98idxcs4zgs7aprfd3f7w7z-hello-2.10.drv" -> 
"/gnu/store/25li3mnn7dr4cds9g95yj0ny5sxjhpkk-glibc-utf8-locales-2.22.drv" 
[color = red];
Backtrace:
In unknown file:
   ?: 19 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 18 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 17 [eval # #]
In ice-9/boot-9.scm:
2401: 16 [save-module-excursion #]
4050: 15 [#]
1724: 14 [%start-stack load-stack ...]
1729: 13 [#]
In unknown file:
   ?: 12 [primitive-load 
"/gnu/store/n3jn19gckk3pim8jr53yxvdll3m77gw9-guix-0.9.0.43c082b/bin/.guix-real"]
In guix/ui.scm:
1175: 11 [run-guix-command graph "--type=bag-emerged" "hello"]
In guix/scripts/graph.scm:
 340: 10 [guix-graph "--type=bag-emerged" "hello"]
In ice-9/boot-9.scm:
 157: 9 [catch srfi-34 # ...]
 157: 8 [catch system-error ...]
In guix/scripts/graph.scm:
 352: 7 [#]
In guix/store.scm:
1061: 6 [run-with-store # ...]
In guix/graph.scm:
 174: 5 [# #]
In guix/monads.scm:
 286: 4 [mapm # # #]
 276: 3 [loop (#f) ()]
 288: 2 [# #f ()]
In guix/scripts/graph.scm:
 103: 1 [bag-node-identifier #f]
In unknown file:
   ?: 0 [#f #f "x86_64-linux" #f]

ERROR: In procedure #f:
ERROR: Wrong type to apply: #f

bug#22281: grub.cfg incorrectly determines root device

2016-01-01 Thread Ludovic Courtès 
As Chris notes at
,
the generated grub.cfg on GuixSD should search the root by UUID or label
rather than by file.

Ludo’.

bug#22276: .sig

2016-01-01 Thread Ludovic Courtès 
Hi,

I’ve amended that section of the manual based on text from the
announcement (see
).
Step 1 becomes:

--8<---cut here---start->8---
  1. Download the binary tarball from
 ‘ftp://alpha.gnu.org/gnu/guix/guix-binary-0.9.0.SYSTEM.tar.xz’,
 where SYSTEM is ‘x86_64-linux’ for an ‘x86_64’ machine already
 running the kernel Linux, and so on.

 Make sure to download the associated ‘.sig’ file and to verify the
 authenticity of the tarball against it, along these lines:

  $ wget 
ftp://alpha.gnu.org/gnu/guix/guix-binary-0.9.0.SYSTEM.tar.xz.sig
  $ gpg --verify guix-binary-0.9.0.SYSTEM.tar.xz.sig

 If that command fails because you don’t have the required public
 key, then run this command to import it:

  $ gpg --keyserver keys.gnupg.net --recv-keys 3D9AEBB5

 and rerun the ‘gpg --verify’ command.
--8<---cut here---end--->8---

Thanks for your feedback!

Ludo’.

bug#22137: python-urwid on x86_64: AsyncEventLoopTest

2016-01-01 Thread Leo Famulari 
On Thu, Dec 10, 2015 at 02:05:56AM -0500, Leo Famulari wrote:
> python-urwid-1.3.0 fails to build on x86_64 during the
> "AsyncioEventLoopTest" test with the error "KeyError: '5 is not
> registered'". It has failed repeatedly for some time now. It fails in
> the same way when updated to python-urwid-1.3.1.
> 
> I looked for interesting changes made between the last successful build
> and the first failing build. Notably, this range includes the upgrade
> from python-3.3.5 to python-3.4.3 (08c04509). Asyncio was integrated
> into the Python standard library in 3.4 — previously it had been an
> external library. [0] Our python-3.4.3 package passes its 'test_asyncio'
> test, FWIW.
> 
> I entered the failed build tree and successfully ran the tests using the
> python-3.4.3-7 [1] installed by Debian Stretch. That only tells us so
> much, but I think it does indicate either a bug in our python-3.4.3, or
> some problem with python-urwid caused by the unfamiliar Guix build
> environment.
> 
> Here's the hydra.gnu.org page:
> http://hydra.gnu.org/build/861615

BTW, I filed a bug upstream:
https://github.com/urwid/urwid/issues/164

No response yet, although I should add some more information to the bug
report.

In the meantime, what about downgrading python-urwid to 1.2.2 and
leaving python2-urwid at 1.3.0?

1.2.2 works for the software I am trying to package, and currently there
are no users of python-urwid.

> 
> Here's the failing part of the build log:
> 
> --8<---cut here---start->8---
> 
> ==
> ERROR: test_remove_watch_file 
> (urwid.tests.test_event_loops.AsyncioEventLoopTest)
> --
> Traceback (most recent call last):
>   File 
> "/gnu/store/13n8xbi9wv9pigfyhir007qadr81jq46-python-3.4.3/lib/python3.4/asyncio/selector_events.py",
>  line 234, in add_reader
> key = self._selector.get_key(fd)
>   File 
> "/gnu/store/13n8xbi9wv9pigfyhir007qadr81jq46-python-3.4.3/lib/python3.4/selectors.py",
>  line 182, in get_key
> raise KeyError("{!r} is not registered".format(fileobj)) from None
> KeyError: '5 is not registered'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File 
> "/tmp/nix-build-python-urwid-1.3.0.drv-0/urwid-1.3.0/build/lib.linux-x86_64-3.4/urwid/tests/test_event_loops.py",
>  line 33, in test_remove_watch_file
> handle = evl.watch_file(5, lambda: None)
>   File 
> "/tmp/nix-build-python-urwid-1.3.0.drv-0/urwid-1.3.0/build/lib.linux-x86_64-3.4/urwid/main_loop.py",
>  line 1263, in watch_file
> self._loop.add_reader(fd, callback)
>   File 
> "/gnu/store/13n8xbi9wv9pigfyhir007qadr81jq46-python-3.4.3/lib/python3.4/asyncio/selector_events.py",
>  line 237, in add_reader
> (handle, None))
>   File 
> "/gnu/store/13n8xbi9wv9pigfyhir007qadr81jq46-python-3.4.3/lib/python3.4/selectors.py",
>  line 402, in register
> self._epoll.register(key.fd, epoll_events)
> PermissionError: [Errno 1] Operation not permitted
> 
> --
> Ran 284 tests in 0.384s
> 
> FAILED (errors=1)
> phase `check' failed after 4.6 seconds
> --8<---cut here---end--->8---
> 
> [0]
> https://docs.python.org/3/library/asyncio.html
> 
> [1] Reported by `apt-cache show python3`, this python-3.4.3-7's .deb has
> a SHA256 hash of:
> 53fa197ee35501152b1897bf84ab6123f7f65201efdddc2e4aa882de494f3870

bug#19219: New command-line syntax for package + version?

2016-01-01 Thread Ludovic Courtès 
Efraim Flashner  skribis:

> On Wed, 30 Dec 2015 20:16:31 -0500
> Leo Famulari  wrote:
>
>> On Wed, Dec 30, 2015 at 11:45:14PM +0100, Mathieu Lirzin wrote:
>>  [...]  
>>  [...]  
>>  [...]  
>>  [...]  
>>  [...]  
>>  [...]  
>> > 
>> > I'm OK with that.  Since choosing the reserved characters is not a
>> > technical decision, maybe we could poll users?  
>> 
>> I think we should poll a big list of packages and see which characters
>> are most safe to use.
>> 
>> The question is: which big list? Debian's?
>> 
>> 
>  
> When debian adopted multiarch 

[...]

I forgot to reply to Leo’s message, but it seems clear to me that it
only makes sense to discuss on Guix mailing lists.  I don’t think anyone
else cares about the syntax of Guix’s command-line interface.  ;-)

Ludo’.

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

2016-01-01 Thread Ludovic Courtès 
Christopher Allan Webber  skribis:

> If I reboot into GuixSD, at some point in the boot process it resets my
> hardware clock to 1970!  If I reboot into Debian again after that, it's
> 1970 there also.

Ouch!  Your config includes the ntp daemon.  Could it be that it’s
misbehaving?

You can remove it along the lines of:

  (define %my-desktop-services
(remove (lambda (service)
  (eq? (service-kind service) ntp-service-type))
%desktop-services))

Well, you need to export ‘ntp-service-type’ from (gnu services
networking) first…

Other than that, I have no idea what could be resetting the hardware
clock to 0.

HTH,
Ludo’.

bug#19219: New command-line syntax for package + version?

2016-01-01 Thread carl hansen 
On Fri, Jan 1, 2016 at 1:45 PM, Leo Famulari  wrote:

>
>
> I did this:
> $ apt-cache pkgnames | tr -d 'a-zA-Z0-9' | tr -d - | tr -d '\n'
>
> The only remaining characters were '.' and '+'.
>
>
> I did:
ls -1 /var/cache/apt/archive/ | tr -d 'a-zA-Z0-9' | tr -d - | tr -d '\n'
Got:  . + % ~ _

typical pkgnames, as seen in the file system:
zlib1g-dev_1%3a1.2.8.dfsg-2ubuntu4_amd64.deb
zoo_2.10-27_amd64.deb
zynjacku_6-4build1_amd64.deb

Note pkgname:

package-name  _  upstreamversion - localversion _ otherstuff

version delimited by _
may have optional subversions split by -
(like when an upstream version is remade on hydra, but is only locally
different somehow.)

For your comtemplation.

I believe on debian the : is used when the package starts a new numbering
scheme, like when
they decide the old scheme was crazy.

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

2016-01-01 Thread Mark H Weaver 
Christopher Allan Webber  writes:

> I recently installed GuixSD on the laptop I got fresh from Minifree.  I
> was happy to see how much worked, but I've noticed a bug that occurs in
> GuixSD but not in Debian.
>
> In Debian I can set the hardware clock (with `hwclock -w`) and if I
> reboot back into Debian again, I still have the same hardware clock.
>
> If I reboot into GuixSD, at some point in the boot process it resets my
> hardware clock to 1970!  If I reboot into Debian again after that, it's
> 1970 there also.

Very strange.  FWIW, I've used Libreboot X60 and X200 laptops running
GuixSD quite extensively -- they are my primary development machines --
and I've never seen anything like this.

One possibility that comes to mind is that perhaps your hardware clock
battery is dead, and that sometimes Debian is able to hide that fact by
setting the date via NTP or something.  Can you try running "hwclock -r"
after a cold boot into Debian and see what it says?

> Any idea what could be causing this?  I noticed that if I rebooted it
> at the time that it asked me for a passphrase to decrypt /home/ that it
> didn't reset the clock, though maybe I should test that again.

If you're sharing /home between Debian and GuixSD, I wonder if going
back and forth between two different versions of GNOME while sharing the
data in dot-files/directories is causing a problem?

This in turn makes me wonder if the clock is truly being reset during
the GuixSD boot process, or if it might be happening during login to
your desktop environment.  Please try the following:

* Cold boot into Debian.
* Set the hardware clock (hwclock -w).
* Read the hardware clock to verify that it works (hwclock -r).
* Reboot into GuixSD.
* Log in to a text console as root and check both the system clock
  (date) and the hardware clock (hwclock -r).

 Thanks,
   Mark