bug#22954: Suspicious ownership or permission on harfbuzz-1.0.6-bin

[Andreas Enge]

On Tue, Mar 08, 2016 at 09:14:40PM -0600, Jeffrey Serio wrote:
> The build failed with the error message "Suspicious ownership or
> permission on /gnu/store/...-harfbuzz-1.0.6-bin".

I have been getting these from time to time recently; it may be related
to grafts, I think it appears when one package is supposed to be grafted
to another one. The two or three times it happened to me, just rerunning
the command succeeded.

Andreas

bug#22550: (require 'magit) produces error: "no such file or directory" "dash"

[Alex Kost]

myglc2 (2016-03-08 16:49 +0300) wrote:

> Alex Kost  writes:
>
>> myglc2 (2016-03-07 23:03 +0300) wrote:
>>
[...]
>>> I re-read your earlier posts. AIUI now, in order to use the latest guix
>>> emacs features from 'git checkout master' one must add to emacs init:
>>>
>>> (let ((dir "~/src/guix/emacs"))
>>>   (add-to-list 'load-path dir)
>>>   (setq guix-load-path dir)
>>>   (require 'guix-init nil t))
>>
>> Yes, this is the recommended way of setting it up.  It is described in
>> (info "(guix) Emacs Initial Setup").
>>
>>> Do you think we should we add that to (info "(guix) Building from Git") ? 
>>
>> Since it is already described in the other section, it shouldn't be
>> duplicated, but we can add a cross reference, not into "Building from
>> Git" though, maybe to (info "(guix) The Perfect Setup")
>
> Then you need to also fix the intro paragraph which says (emphasis
> added):

I don't agree, this intro paragraph is (should be in theory) correct.

> "On the Guix System Distribution (*note GNU Distribution::), “guix.el”
> is ready to use [...] So [...] you can happily SKIP THIS SECTION [...]"
>
> Since I am using GuixSD I have always skipped this section.  That is why
> you have had to explain this twice to me.

It's just that no one tried to use system profile for adding emacs
packages before you, but this case will be handled in the next release,
so I think this part of the manual shouldn't be changed.

-- 
Alex

bug#22954: Suspicious ownership or permission on harfbuzz-1.0.6-bin

[Ludovic Courtès]

Andreas Enge  skribis:

> On Tue, Mar 08, 2016 at 09:14:40PM -0600, Jeffrey Serio wrote:
>> The build failed with the error message "Suspicious ownership or
>> permission on /gnu/store/...-harfbuzz-1.0.6-bin".
>
> I have been getting these from time to time recently; it may be related
> to grafts, I think it appears when one package is supposed to be grafted
> to another one. The two or three times it happened to me, just rerunning
> the command succeeded.

Right, I experienced it a few times, hence 82f5186.

However, last time I saw this failure, I re-run the faulty derivation
with

  guix build /gnu/store/….drv --rounds=10

and it always succeeded.

So I suspect something fishy like a race condition in the daemon or
something.

Ludo’.

bug#22952: MacBook2, 1 brightness control requires root privileges

[Ludovic Courtès]

Albin  skribis:

> I've discovered that the non-working brightness controls for the
> MacBook2,1 are due to insufficient permissions.
>
> The first indication of this was that I could change brightness by
> running the program redshift with root permissions (`sudo redshift`).

Interesting.  I use a simple window manager (ratpoison), and ‘redshift’
works fine as non-root.

> Today I was presented with this dialog box in GNOME 3 after having
> pressed one of the brightness-control keys:
>
> "Authentication is needed to run
> '/gnu/store/[...]-gnome-settings-daemon-3.18.2/libexec/gsd-backlight-helper'
> as the super user.
>
> Administrator
> Password [__]"

This is something Andy is working on:

  https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00247.html

Looks like we’re almost there.  :-)

Ludo’.

bug#22948: Porting ocl-icd to guix fails because of ruby

[Ludovic Courtès]

Dennis Mungai  skribis:

> env TEMPDIR=/gnu/tmp GUIX_PACKAGE_PATH=../guix-bioinformatics
> ./pre-inst-env guix build -K ocl-icd

Note that setting TEMPDIR here (or even TMPDIR) has no effect, since
it’s the ‘guix-daemon’ process, not ‘guix build’, that creates temporary
files.

> Error encountered:
>
> guix build: error: build failed: error parsing derivation
> `/gnu/store/7f9hwk8v9vzghc93m93y94iibvcc3mvd-ruby-2.3.0.tar.xz.drv':
> expected string `Derive(['

Could you send the content of the file above?

It looks like your store may be be corrupt.  Did you modify files by
hand under /gnu/store?  This would void your warranty.  :-)

Thanks,
Ludo’.

bug#22550: (require 'magit) produces error: "no such file or directory" "dash"

[myglc2]

Alex Kost  writes:

> myglc2 (2016-03-08 16:49 +0300) wrote:
>
>> Alex Kost  writes:
>>
>>> myglc2 (2016-03-07 23:03 +0300) wrote:
>>>
> [...]
 I re-read your earlier posts. AIUI now, in order to use the latest guix
 emacs features from 'git checkout master' one must add to emacs init:

 (let ((dir "~/src/guix/emacs"))
   (add-to-list 'load-path dir)
   (setq guix-load-path dir)
   (require 'guix-init nil t))
>>>
>>> Yes, this is the recommended way of setting it up.  It is described in
>>> (info "(guix) Emacs Initial Setup").
>>>
 Do you think we should we add that to (info "(guix) Building from Git") ? 
>>>
>>> Since it is already described in the other section, it shouldn't be
>>> duplicated, but we can add a cross reference, not into "Building from
>>> Git" though, maybe to (info "(guix) The Perfect Setup")
>>
>> Then you need to also fix the intro paragraph which says (emphasis
>> added):
>
> I don't agree, this intro paragraph is (should be in theory) correct.
>
>> "On the Guix System Distribution (*note GNU Distribution::), “guix.el”
>> is ready to use [...] So [...] you can happily SKIP THIS SECTION [...]"
>>
>> Since I am using GuixSD I have always skipped this section.  That is why
>> you have had to explain this twice to me.
>
> It's just that no one tried to use system profile for adding emacs
> packages before you, but this case will be handled in the next release,
> so I think this part of the manual shouldn't be changed.

You are are assuming that I am running emacs in the system
profile. Meanwhile "tricky george" stopped trying to swim upstream and
installed emacs in the user profile :O. Based on running both ways I
still believe this needs attention.  But I am badly off the topic of the
original bug so I will put it in a new post.

I do apologize for the run-around. Many thanks! - George

bug#22962: Something keeps overwriting /etc/hosts

[Danny Milosavljevic]

bug#22966: HTTPS with GnuTLS's 'session-record-port' is inefficient

[Ludovic Courtès]

(guix build download) uses ‘session-record-port’ from (gnutls), which
returns a port to conveniently write to/read from the TLS session’s
“record” layer.

The problem is that every write to the port, that is, every call to
‘write_to_session_record_port’ in the GnuTLS bindings, leads to the
creation of one “Application Data” packet.

For instance, when (web requests) writes an HTTP GET request, it roughly
does:

  (display "GET" port)
  (display " " port)
  (display uri port)
  (display "\n\r" port)
  …

it ends up creating a lot of small Application Data packets.  When
debugging is enabled in (guix build download), that translates to things
like:

  gnutls: [14594|5] REC[0x152c9c0]: Preparing Packet Application Data(23) with 
length: 1 and min pad: 0
  gnutls: [14594|9] ENC[0x152c9c0]: cipher: AES-128-GCM, MAC: AEAD, Epoch: 1
  gnutls: [14594|5] REC[0x152c9c0]: Sent Packet[4] Application Data(23) in 
epoch 1 and length: 30

Terribly suboptimal.

The difficulty is that the session record port doesn’t do any caching by
itself, and it shouldn’t, because it’s the application’s responsibility.
So we might have to do our own caching and/or use ‘record-send’ and
‘record-receive!’ instead of ‘session-record-port’.

Ludo’.

bug#22965: git guix build error in ./pre-inst-env guix environment guix

[Danny Milosavljevic]

Note: after make distclean, it works again.

Was weird.

bug#22937: guix package fails when --substitute-urls specifies an HTTPS endpoint

[Ludovic Courtès]

First, the graceless error handling is fixed in
204d34ff961d6dabf18b255decc29712e03afef0.

Second, here’s a preliminary patch that almost works with
.

The problem is that sometimes the server closes the connection
unexpectedly, leading to an obscure backtrace like this:

--8<---cut here---start->8---
substitute:  629: 6 [lookup-narinfos "https://hydra-mirror.marusich.info"; #]
substitute:  585: 5 [fetch-narinfos "https://hydra-mirror.marusich.info"; #]
substitute:  510: 4 [http-multiple-get # ...]
substitute: In web/response.scm:
substitute:  197: 3 [read-response #]
substitute: In web/http.scm:
substitute: 1157: 2 [read-response-line #]
substitute:  151: 1 [read-header-line #]
substitute: In unknown file:
substitute:?: 0 [%read-line #]
substitute: 
substitute: ERROR: In procedure %read-line:
substitute: ERROR: Throw to key `gnutls-error' with args `(# fill_session_record_port_input)'.
--8<---cut here---end--->8---

The “error in the pull function” is because ‘gnutls_record_recv’ got
ECONNRESET while reading.

I wonder whether this could be due to the particular configuration of
nginx at Cloudfront, so I’ll try with another server (I’ve set up Let’s
Encrypt on that server but it’s not accessible yet via port 443.)

To be continued!

Ludo’.

diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index b82fc17..df95de0 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -32,6 +32,7 @@
   #:use-module ((guix build utils) #:select (mkdir-p dump-port))
   #:use-module ((guix build download)
 #:select (progress-proc uri-abbreviation
+  open-connection-for-uri
   store-path-abbreviation byte-count->string))
   #:use-module (ice-9 rdelim)
   #:use-module (ice-9 regex)
@@ -171,7 +172,7 @@ to the caller without emitting an error message."
  (let ((port (open-file (uri-path uri)
 (if buffered? "rb" "r0b"
(values port (stat:size (stat port)
-((http)
+((http https)
  (guard (c ((http-get-error? c)
 (let ((code (http-get-error-code c)))
   (if (and (= code 404) quiet-404?)
@@ -201,10 +202,10 @@ to the caller without emitting an error message."
  (close-port port
(begin
  (when (or (not port) (port-closed? port))
-   (set! port (open-socket-for-uri uri))
+   (set! port (open-connection-for-uri uri))
(unless buffered?
  (setvbuf port _IONBF)))
- (http-fetch uri #:text? #f #:port port
+ (http-fetch uri #:text? #f #:port port))
 (else
  (leave (_ "unsupported substitute URI scheme: ~a~%")
 (uri->string uri)
@@ -478,20 +479,26 @@ may be #f, in which case it indicates that PATH is unavailable at CACHE-URL."
 ".narinfo")))
 (build-request (string->uri url) #:method 'GET)))
 
-(define (http-multiple-get base-url proc seed requests)
-  "Send all of REQUESTS to the server at BASE-URL.  Call PROC for each
+(define (http-multiple-get base-uri proc seed requests)
+  "Send all of REQUESTS to the server at BASE-URI.  Call PROC for each
 response, passing it the request object, the response, a port from which to
 read the response body, and the previous result, starting with SEED, à la
 'fold'.  Return the final result."
   (let connect ((requests requests)
 (result   seed))
-;; (format (current-error-port) "connecting (~a requests left)..."
-;; (length requests))
-(let ((p (open-socket-for-uri base-url)))
+(format (current-error-port) "connecting (~a requests left)..."
+(length requests))
+(let ((p (open-connection-for-uri base-uri)))
+  ;; For HTTPS, P is not a file port and does not support 'setvbuf'.
+  (when (file-port? p)
+(setvbuf p _IOFBF (expt 2 16)))
+
   ;; Send all of REQUESTS in a row.
-  (setvbuf p _IOFBF (expt 2 16))
-  (for-each (cut write-request <> p) requests)
-  (force-output p)
+  ;; XXX: Do our own caching to work around .
+  (let-values (((buffer get) (open-bytevector-output-port)))
+(for-each (cut write-request <> buffer) requests)
+(put-bytevector p (get))
+(force-output p))
 
   ;; Now start processing responses.
   (let loop ((requests requests)
@@ -501,6 +508,8 @@ read the response body, and the previous result, starting with SEED, à la
(reverse result))
   ((head tail ...)
(let* ((resp   (read-response p))
+  ;; (xxx(format (current-error-port)
+  ;; "http response: ~s~%" resp))
   (body   (response-body-port resp))
   (result (proc head resp body 

bug#22962: Something keeps overwriting /etc/hosts

[Danny Milosavljevic]

If I make it immutable, I get the following message on guix system reconfigure 
... :

  guix system: error: copy-file: Permission denied: "/etc/hosts"

Aha!

bug#22970: guix edit mutt -- not working

[Jean Louis]

Hello,

My understanding is that each user, shall be able to:

guix edit mutt

as example, change the options, and get such package, as I wanted to
add: --enable-hcache here:

 `(#:configure-flags '("--enable-smtp"
   "--enable-imap"
   "--enable-pop"
   "--enable-gpgme"
   "--with-ssl"
   "--with-sasl"

but I cannot "save" the file, as it is read only:

/gnu/store/632msbms2yaldfnlrb5lbnlnmn9yjisw-guix-0.9.0/share/guile/site/2.0/gnu/packages/mail.scm:
unmodified,
UNLOCKED, readonly: line 206 of 1007 [20%]

And I could not save the file in my home directory, and do:

guix package -i mutt -f mail.scm

I need help in understanding, rather than using mutt, as I want to
urgently run the GNU.

Jean Louis

bug#22970: guix edit mutt -- not working

[Andreas Enge]

On Thu, Mar 10, 2016 at 12:22:20AM +0100, Jean Louis wrote:
> And I could not save the file in my home directory, and do:
> guix package -i mutt -f mail.scm

As mentioned on IRC, modify the file mail.scm by adding a line
   mutt
at the end. Then
   guix package -f mail.scm
does "install the package that the code within FILE evaluates to" as
explained by "guix package --help". mail.scm itself does not evaluate
to anything, it just contains a number of variable definitions. By adding
the line, it "returns" the value of the variable mutt, which is your
package definition.

Better yet, use GUIX_PACKAGE_PATH, for instance as follows:
   export GUIX_PACKAGE_PATH=$HOME/guix
Then create the same file layout in that directory as in the source code:
   mkdir -p $HOME/guix/gnu/packages
Copy mail.scm there, modify mutt, then
   guix package -i mutt
will first look for your modified package.

As this is not a bug, it would have been better to post to help-g...@gnu.org;
let us continue the discussion there (if you are not yet subscribed, please
do so), and I am closing this bug.

Andreas

bug#22965: git guix build error in ./pre-inst-env guix environment guix

[Christopher Allan Webber]

Closing the bug.

bug#22972: insecure content on: https://gnu.org/software/guix/packages/

[Jean Louis]

The icecat is reporting insecure content on:
https://gnu.org/software/guix/packages/

and it shall be corrected, as package "Expand" is not visible.

Jean Louis

bug#22962: Something keeps overwriting /etc/hosts

[Leo Famulari]

On Thu, Mar 10, 2016 at 12:28:11AM +0100, Danny Milosavljevic wrote:
> If I make it immutable, I get the following message on guix system 
> reconfigure ... :
> 
>   guix system: error: copy-file: Permission denied: "/etc/hosts"
> 
> Aha!

I think that on GuixSD, the hosts file is generated from the system
configuration, specifically the 'hosts-file' field, which is mentioned
in section 7.2.2 Operating System Reference [0].

I assume that the resulting file is recreated each time you reconfigure. 

In that case, you'd want to leave the file /etc/hosts alone, and make
your changes in the operating system configuration.

I say "I think" and "I assume" because I haven't actually used
'hosts-file' yet, nor have I looked at that part of the code.

Does that help?

[0]
https://www.gnu.org/software/guix/manual/guix.html#operating_002dsystem-Reference

bug#22974: make check FAIL: tests/store

[myglc2]

git checkout: * master ce6027b gnu: nautilus: Don't propagate gtk+.

==
   GNU Guix 0.9.1: ./test-suite.log
==

# TOTAL: 61
# PASS:  60
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/store
=



make.check.160309.log
Description: Binary data


make.check.160309.test-suite.log
Description: Binary data

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

[Ricardo Wurmus]

Fixed with 82f145ef7aef8f4d28a144ee8efcadf3fdd4b877