bug#21888: guix-publish gets ERROR when serve gtk+.

[Ludovic Courtès]

宋文武  skribis:

> ---request begin---
> GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 HTTP/1.1
> User-Agent: Wget/1.16.3 (linux-gnu)
> Accept: */*
> Accept-Encoding: identity
> Host: localhost:8080
> Connection: Keep-Alive
>
> ---request end---
>
> ---response begin---
> HTTP/1.1 404 Not Found
> Content-Length: 69
> Content-Type: text/plain;charset=utf-8
>
> ---response end---
> Registered socket 3 for persistent reuse.
> URI content encoding = 'utf-8'
> Skipping 69 bytes of body: [Resource not found: 
> /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2] done.

Here ‘guix publish’ returns 404, presumably because
/gnu/store/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 is not on disk
or not valid.

Is this correct?

Now, does http://localhost/1dlz1am0qmj1579f5p6j5cvfx9l2aw50.narinfo
return?  It should also return 404, otherwise there’s an inconsistency.

Thanks,
Ludo’.

bug#20889: [PATCH] tk: Hardcode path to TK_LIBRARY.

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> 宋文武  skribis:
>
>> From 6c9ea521e88d36bd1ce990a561477ec0e2950017 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
>> Date: Thu, 12 Nov 2015 13:31:19 +0800
>> Subject: [PATCH] tk: Hardcode path to TK_LIBRARY.
>>
>> Fixes .
>>
>> * gnu/packages/patches/tk-find-library.patch: New patch.
>> * gnu-system.am (dist_patch_DATA): Add it.
>> * gnu/packages/tcl.scm (tk)[source]: Add patch.
>
> [...]
>
>> +++ b/gnu/packages/patches/tk-find-library.patch
>> @@ -0,0 +1,30 @@
>> +This patch hardcode where Tk found its script library during package
>  ^^  
> “This patch hard-codes the Tk library directory during package
> initialization.”
>
> OK with this change.  Thanks for providing a quick fix!  :-)
>
> Could you commit it in a new ‘tk-update’ branch?
Done.
>
> At the same time, I think we should move tkinter*.so to a separate
> output of the Python packages; I think it’s a matter of moving the .so
> to a separate output, literally.  Would you like to give it a try?
I don't know much about python, so I'd like to leave it for others :-)

bug#21888: guix-publish gets ERROR when serve gtk+.

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> 宋文武  skribis:
>
>> ---request begin---
>> GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 HTTP/1.1
>> User-Agent: Wget/1.16.3 (linux-gnu)
>> Accept: */*
>> Accept-Encoding: identity
>> Host: localhost:8080
>> Connection: Keep-Alive
>>
>> ---request end---
>>
>> ---response begin---
>> HTTP/1.1 404 Not Found
>> Content-Length: 69
>> Content-Type: text/plain;charset=utf-8
>>
>> ---response end---
>> Registered socket 3 for persistent reuse.
>> URI content encoding = 'utf-8'
>> Skipping 69 bytes of body: [Resource not found: 
>> /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2] done.
>
> Here ‘guix publish’ returns 404, presumably because
> /gnu/store/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 is not on disk
> or not valid.
>
> Is this correct?
No, the gtk+ item is valid, and replace 'gtk+' with 'gtk%2B' in the url
will make wget download it happily.
>
> Now, does http://localhost/1dlz1am0qmj1579f5p6j5cvfx9l2aw50.narinfo
> return?  It should also return 404, otherwise there’s an
> inconsistency.
for the narinfo, It does return 200.

bug#21888: guix-publish gets ERROR when serve gtk+.

[Ludovic Courtès]

iyzs...@member.fsf.org (宋文武) skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> 宋文武  skribis:
>>
>>> ---request begin---
>>> GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 HTTP/1.1
>>> User-Agent: Wget/1.16.3 (linux-gnu)
>>> Accept: */*
>>> Accept-Encoding: identity
>>> Host: localhost:8080
>>> Connection: Keep-Alive
>>>
>>> ---request end---
>>>
>>> ---response begin---
>>> HTTP/1.1 404 Not Found
>>> Content-Length: 69
>>> Content-Type: text/plain;charset=utf-8
>>>
>>> ---response end---
>>> Registered socket 3 for persistent reuse.
>>> URI content encoding = 'utf-8'
>>> Skipping 69 bytes of body: [Resource not found: 
>>> /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2] done.
>>
>> Here ‘guix publish’ returns 404, presumably because
>> /gnu/store/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 is not on disk
>> or not valid.
>>
>> Is this correct?
> No, the gtk+ item is valid, and replace 'gtk+' with 'gtk%2B' in the url
> will make wget download it happily.

Oooh, I see.  We’re missing a decoding phase here.  David?  :-)

Ludo’.

bug#21888: guix-publish gets ERROR when serve gtk+.

[Thompson, David]

On Fri, Nov 13, 2015 at 8:29 AM, Ludovic Courtès  wrote:
> iyzs...@member.fsf.org (宋文武) skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> 宋文武  skribis:
>>>
 ---request begin---
 GET /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 HTTP/1.1
 User-Agent: Wget/1.16.3 (linux-gnu)
 Accept: */*
 Accept-Encoding: identity
 Host: localhost:8080
 Connection: Keep-Alive

 ---request end---

 ---response begin---
 HTTP/1.1 404 Not Found
 Content-Length: 69
 Content-Type: text/plain;charset=utf-8

 ---response end---
 Registered socket 3 for persistent reuse.
 URI content encoding = 'utf-8'
 Skipping 69 bytes of body: [Resource not found: 
 /nar/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2] done.
>>>
>>> Here ‘guix publish’ returns 404, presumably because
>>> /gnu/store/1dlz1am0qmj1579f5p6j5cvfx9l2aw50-gtk+-3.18.2 is not on disk
>>> or not valid.
>>>
>>> Is this correct?
>> No, the gtk+ item is valid, and replace 'gtk+' with 'gtk%2B' in the url
>> will make wget download it happily.
>
> Oooh, I see.  We’re missing a decoding phase here.  David?  :-)

I don't know when I'll be able to fix it, but it sounds easy.  I'll
post a patch when I have time.

Thanks,

- Dave

bug#21829: guix import hackage failures

[Federico Beffa]

On Thu, Nov 12, 2015 at 9:21 PM, Ludovic Courtès  wrote:
> If we go for the CRLF conversion port, we should avoid the pipe and
> extra thread.  Instead, I would suggest something like:
>
>   (define (canonical-newline-port port)
> "Return an input port that wraps PORT such that all newlines consist
>   of a single carriage return."
> (make-custom-binary-input-port …))

I like this suggestion :-)

I never used custom ports. Is something like this OK? (Seems to work
in the REPL.)

---
(define (canonical-newline-port port)
  "Return an input port that wraps PORT such that all newlines consist
  of a single carriage return."
  (define (get-position)
(if (port-has-port-position? port) (port-position port) #f))
  (define (set-position! position)
(if (port-has-set-port-position!? port)
(set-port-position! position port)
#f))
  (define (close) (close-port port))
  (define (read! bv start n)
(let loop ((count 0)
   (byte (get-u8 port)))
  (cond ((or (eof-object? byte) (= count n)) count)
((eqv? byte (char->integer #\return)) (loop count (get-u8 port)))
(else
 (bytevector-u8-set! bv (+ start count) byte)
 (loop (+ count 1) (get-u8 port))
  (make-custom-binary-input-port "canonical-newline-port"
 read!
 get-position
 set-position!
 close))
---

IMO this is general enough that it could go into "guix/utils.scm". Are
you OK with this?

Regards,
Fede

bug#21909: Segfault with eigen in R

[Kyle Meyer]

Hello,

With R 3.2.2 built from r in statistics.scm (guix 0.9.0), I'm seeing a
segfault when eigen is called with a matrix over some size.  I can
trigger the error with the following code [1]:

> M <- 50
> N <- 500
> eigen(crossprod(matrix(rnorm(M * N), M, N)))

 *** caught segfault ***
address 0xfb0, cause 'memory not mapped'

Traceback:
 1: eigen(crossprod(matrix(rnorm(M * N), M, N)))

Can others reproduce this?

Thanks.


[1] This is a down-sized version of the snippet from an ATLAS bug report
in 2011 for a similar error with R 2.14.

http://sourceforge.net/p/math-atlas/support-requests/792/

--
Kyle

bug#21909: Segfault with eigen in R

[Ricardo Wurmus]

Kyle Meyer  writes:

> With R 3.2.2 built from r in statistics.scm (guix 0.9.0), I'm seeing a
> segfault when eigen is called with a matrix over some size.  I can
> trigger the error with the following code [1]:
>
> > M <- 50
> > N <- 500
> > eigen(crossprod(matrix(rnorm(M * N), M, N)))
>
>  *** caught segfault ***
> address 0xfb0, cause 'memory not mapped'
>
> Traceback:
>  1: eigen(crossprod(matrix(rnorm(M * N), M, N)))
>
> Can others reproduce this?

I can reproduce this running R 3.2.2 on GuixSD on a x86_64 machine.

~~ Ricardo

bug#21829: guix import hackage failures

[Ludovic Courtès]

Federico Beffa  skribis:

> ---
> (define (canonical-newline-port port)
>   "Return an input port that wraps PORT such that all newlines consist
>   of a single carriage return."
>   (define (get-position)
> (if (port-has-port-position? port) (port-position port) #f))
>   (define (set-position! position)
> (if (port-has-set-port-position!? port)
> (set-port-position! position port)
> #f))
>   (define (close) (close-port port))
>   (define (read! bv start n)
> (let loop ((count 0)
>(byte (get-u8 port)))
>   (cond ((or (eof-object? byte) (= count n)) count)

BYTE is lost here in the case it is not EOF.

It may be best to move the (= count n) case right before the recursive
call below.

> ((eqv? byte (char->integer #\return)) (loop count (get-u8 port)))

In practice this discards LF even if it’s not following CR; that’s
probably a good enough approximation, but an XXX comment would be
welcome.

> (else
>  (bytevector-u8-set! bv (+ start count) byte)
>  (loop (+ count 1) (get-u8 port))
>   (make-custom-binary-input-port "canonical-newline-port"
>  read!
>  get-position
>  set-position!
>  close))
> ---
>
> IMO this is general enough that it could go into "guix/utils.scm". Are
> you OK with this?

Looks good!  Could you make a patch that does that, along with adding a
test or two in tests/utils.scm?

Thank you!

Ludo’.