Re: branch core-updates updated (49c2a46 -> 568004c)

[Leo Famulari]

On Tue, Mar 14, 2017 at 02:49:00PM -0400, Efraim Flashner wrote:
> efraim pushed a change to branch core-updates
> in repository guix.
> 
>   from  49c2a46   gnu: python@2.7: Update to 2.7.13
>new  c5e9101   gnu: mesa: Use llvm backend for Intel hardware only.
>new  2a8b89c   gnu: mesa: Customize build flags based on architecture.
>new  044006f   gnu: mesa: Enable gallium tests.
>new  568004c   gnu: nss: Build for aarch64-linux with 64-bit support.

Some in this push broke mesa for me on x86_64.

It fails in the configure phase like this:

checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
checking for PTHREADSTUBS... yes
checking for LIBDRM... yes
checking for SHA1Init... no
checking for CC_SHA1_Init... no
checking for wincrypt.h... no
checking for SHA1Init in -lmd... no
checking for LIBSHA1... no
checking for nettle_sha1_init in -lnettle... no
checking for gcry_md_open in -lgcrypt... no
checking for SHA1_Init in -lcrypto... no
checking for OPENSSL... no
checking for SHA1 implementation...
checking for GLPROTO... yes
checking for DRI2PROTO... yes
checking for DRI3PROTO... yes
checking for PRESENTPROTO... yes 
checking for XCB_DRI3... yes
checking for XF86VIDMODE... yes
checking for DRIGL... yes
checking for EXPAT... yes
configure: error: classic DRI driver '915' does not exist
phase `configure' failed after 12.6 seconds

Please tell me what other information or debugging I can provide.


signature.asc
Description: PGP signature

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Marius Bakke]

Leo Famulari  writes:

> On Tue, Mar 14, 2017 at 10:39:48PM +0100, Marius Bakke wrote:
>> Going forward, I wonder if there could be any unintended side effects by
>> simply increasing the timeouts in nss/gtests/ssl_gtest/tls_connect.cc
>> from 5000 ms to something like 2. If a 0-day is discovered in "nss",
>> we don't want to wait several days to get a successful build.
>
> If these failures seem to be timeout issues, I think we should try this.
> We do have other packages that make similar changes.

I'm currently building NSS (on x86_64) with timeouts increased from 5s
to 25s. The recent armhf test failure took 22725ms, and when we
struggled with 3.29.2 it took ~2ms too.

Patch attached. I *think* the two values are for client and server
respectively, but will study the source and build logs some more to make
sure we're adjusting the right knobs.

I suggest we try this on 'core-updates' if the patch is correct.

From c8e0b85953133328e27f0bfcc9a9a0330e36ce5a Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Tue, 14 Mar 2017 22:54:41 +0100
Subject: [PATCH] gnu: nss: Increase test timeouts.

* gnu/packages/patches/nss-increase-test-timeout.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/gnuzilla.scm (nss)[source]: Use it.
---
 gnu/local.mk |  1 +
 gnu/packages/gnuzilla.scm|  3 ++-
 gnu/packages/patches/nss-increase-test-timeout.patch | 20 
 3 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/nss-increase-test-timeout.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index c1b076a5f..7fb22ebb5 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -780,6 +780,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/ninja-tests.patch			\
   %D%/packages/patches/ninja-zero-mtime.patch			\
   %D%/packages/patches/node-9077.patch\
+  %D%/packages/patches/nss-increase-test-timeout.patch		\
   %D%/packages/patches/nss-pkgconfig.patch			\
   %D%/packages/patches/ntfs-3g-CVE-2017-0358.patch		\
   %D%/packages/patches/nvi-assume-preserve-path.patch		\
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index e6e24f665..1d84e7a9a 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -199,7 +199,8 @@ in the Mozilla clients.")
(base32
 "149807rmzb76hnh48rw4m9jw83iw0168njzchz0hmbsgc8mk0i5w"))
   ;; Create nss.pc and nss-config.
-  (patches (search-patches "nss-pkgconfig.patch"
+  (patches (search-patches "nss-pkgconfig.patch"
+   "nss-increase-test-timeout.patch"
 (build-system gnu-build-system)
 (outputs '("out" "bin"))
 (arguments
diff --git a/gnu/packages/patches/nss-increase-test-timeout.patch b/gnu/packages/patches/nss-increase-test-timeout.patch
new file mode 100644
index 0..76d4853ba
--- /dev/null
+++ b/gnu/packages/patches/nss-increase-test-timeout.patch
@@ -0,0 +1,20 @@
+--- a/nss/gtests/ssl_gtest/tls_connect.cc	2017-03-14 22:47:30.855813629 +0100
 b/nss/gtests/ssl_gtest/tls_connect.cc	2017-03-14 22:48:49.042335273 +0100
+@@ -245,7 +245,7 @@
+ 
+   ASSERT_TRUE_WAIT((client_->state() != TlsAgent::STATE_CONNECTING) &&
+(server_->state() != TlsAgent::STATE_CONNECTING),
+-   5000);
++   25000);
+ }
+ 
+ void TlsConnectTestBase::EnableExtendedMasterSecret() {
+@@ -387,7 +387,7 @@
+   } else {
+ fail_agent = server_;
+   }
+-  ASSERT_TRUE_WAIT(fail_agent->state() == TlsAgent::STATE_ERROR, 5000);
++  ASSERT_TRUE_WAIT(fail_agent->state() == TlsAgent::STATE_ERROR, 25000);
+ }
+ 
+ void TlsConnectTestBase::ConfigureVersion(uint16_t version) {
-- 
2.12.0



signature.asc
Description: PGP signature

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Leo Famulari]

On Tue, Mar 14, 2017 at 10:39:48PM +0100, Marius Bakke wrote:
> Going forward, I wonder if there could be any unintended side effects by
> simply increasing the timeouts in nss/gtests/ssl_gtest/tls_connect.cc
> from 5000 ms to something like 2. If a 0-day is discovered in "nss",
> we don't want to wait several days to get a successful build.

If these failures seem to be timeout issues, I think we should try this.
We do have other packages that make similar changes.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add fpc. (version 2)

[Danny Milosavljevic]

Hi,

>+   (copy-file (assoc-ref inputs "fpc-binary")
>+  "fpc-bin.tar")
>+   (zero? (system* "tar" "xvf" "fpc-bin.tar")

Why the copy-file and then untar ? Can't it be untarred immediately from where 
it is? If it is useful, maybe add a comment about the reason.

Also, it might be easier to have a fpc-bootstrap package with the bootstrap 
binaries that installs the binaries required to build fpc normally and to make 
a fpc package depend on fpc-bootstrap as native-inputs.  What do you think?  I 
myself don't have a strong preference about it - but some other packages do it 
that way.

About the fpc-reproducibility.patch , it might make sense to file bugs upstream 
about it so they add it on their side.

Also, these existing bootstrap compilers on sourceforge do not produce bit 
reproducible executables, right?  Should they also have the same patch applied 
upstream in the future ?

Overall LGTM!

fpc supports armhf and usually so do we - although not here.  We can add armhf 
support in a future patch, though.

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Marius Bakke]

Leo Famulari  writes:

> On Tue, Mar 14, 2017 at 05:02:12PM -0400, Mark H Weaver wrote:
>> This is not really sustainable.  A single build attempt takes 7 hours on
>> armhf, and about 40 hours on mips.  When the failure occurs, it causes
>> hundreds of other dependency failures, which must be restarted manually,
>> one at a time, via the web interface.  (We have a way to restart *all*
>> dependency failures, but that results in a huge amount of wasted work
>> for Hydra).
>> 
>> We need test suites to be robust on heavily loaded build machines.
>
> I agree that this situation is not sustainable. If we are committed to
> offering substitutes, we can't have such a critical package not building
> reliably.
>
> But, it seems unsatisfactory to not update NSS / nss-certs without
> working towards a real solution.
>
> Nss-certs provides the CA certificate store in Guix. It does get updated
> along with NSS [0], although not in every NSS release.
>
> I think we should find a way to decouple the certificate store from NSS,
> since we can't build NSS reliably.
>
>> Is there a compelling reason not to revert this update for now?
>
> Since there were no changes to the certificates between 3.29.2 and
> 3.29.3, I think it's fine to revert.

NSS is a crypto library in addition to a certificate store and 3.29.3
resolves a crash when TLS 1.3 is enabled. I don't know how serious this
issue is, but we should try to keep up on both packages.

Nevertheless, I've reverted the commits for now so the old substitutes
should be valid again.

Going forward, I wonder if there could be any unintended side effects by
simply increasing the timeouts in nss/gtests/ssl_gtest/tls_connect.cc
from 5000 ms to something like 2. If a 0-day is discovered in "nss",
we don't want to wait several days to get a successful build.


signature.asc
Description: PGP signature

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Leo Famulari]

On Tue, Mar 14, 2017 at 05:02:12PM -0400, Mark H Weaver wrote:
> This is not really sustainable.  A single build attempt takes 7 hours on
> armhf, and about 40 hours on mips.  When the failure occurs, it causes
> hundreds of other dependency failures, which must be restarted manually,
> one at a time, via the web interface.  (We have a way to restart *all*
> dependency failures, but that results in a huge amount of wasted work
> for Hydra).
> 
> We need test suites to be robust on heavily loaded build machines.

I agree that this situation is not sustainable. If we are committed to
offering substitutes, we can't have such a critical package not building
reliably.

But, it seems unsatisfactory to not update NSS / nss-certs without
working towards a real solution.

Nss-certs provides the CA certificate store in Guix. It does get updated
along with NSS [0], although not in every NSS release.

I think we should find a way to decouple the certificate store from NSS,
since we can't build NSS reliably.

> Is there a compelling reason not to revert this update for now?

Since there were no changes to the certificates between 3.29.2 and
3.29.3, I think it's fine to revert.

[0]
https://wiki.mozilla.org/NSS:Release_Versions


signature.asc
Description: PGP signature

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Mark H Weaver]

Marius Bakke  writes:

> I have built this without trouble on two different x86_64 systems. The
> release notes[0] lists a single entry[1] which looks innocuous[2], so I
> doubt the failure is related to the upgrade.
>
> I can't find the build log of the first run,

When restarting builds on Hydra, the log for the first build attempt is
lost.  However, I'm in the habit of making private copies of these logs
before restarting jobs, so I have a copy of both.

> but note how in the second failure the test took more than five seconds:
>
> [  FAILED  ] 
> ExtensionPre13Datagram/TlsExtensionTestPre13.AlpnReturnedBadNameLength/0, 
> where GetParam() = ("TLS", 770) (5543 ms)
> (from https://hydra.gnu.org/build/1905330/nixlog/6/raw )
>
> This is reminiscent of the trouble we had getting 3.29.2 to build on
> armhf[3]. Something caused the build to stall for a few seconds, which
> in turn makes the test fail due to exceeding time treshold.

The nss-3.29.3 build on armhf also failed:

  https://hydra.gnu.org/build/1906025

> Can you try restarting the build once more?

This is not really sustainable.  A single build attempt takes 7 hours on
armhf, and about 40 hours on mips.  When the failure occurs, it causes
hundreds of other dependency failures, which must be restarted manually,
one at a time, via the web interface.  (We have a way to restart *all*
dependency failures, but that results in a huge amount of wasted work
for Hydra).

We need test suites to be robust on heavily loaded build machines.

Is there a compelling reason not to revert this update for now?

  Mark

Re: delete profile

[Federico Beffa]

Alex Kost  writes:

> Federico Beffa (2017-03-14 09:42 +0100) wrote:
>
>> Pjotr Prins  writes:
>> 'guix -p $HOME/guix-test-profile' lists only 1 generation (but I did
>> create another one and then I rolled-back).
>>
>> I run 'guix gc' and now I find dangling symlinks in my $HOME.
>
> What dangling symlinks?  Just remove them :-)

Of this type:

$HOME/guix-test-profile-XXX-link -> /gnu/store/...

Yes, sure, I deleted them.  It just seems strange that a GC leaves
dangling links around.

>
>> One
>> symlink is still active (the active generation) which imply that it is
>> registered as a GC root.
>
> Look at /var/guix/gcroots/auto/ to see the registered GC roots, but
> don't remove them manually, just remove the profile links you created,
> then "guix gc" should clean the store from those profiles.
>
>> However, it's not in
>> '/usr/local/var/guix/profiles' (I installed from source with the default
>> prefix=/usr/local).
>
> this var/guix/profiles is only for system and per-user profiles.
> Profiles that you create explicitly (with --profile option) are not
> placed there.
>
>> Not sure where to find it.
>
> I'm not sure what you mean: the profiles you created with "guix package
> -p $HOME/guix-test-profile -i ..." are in the store and the symlinks to
> them are these "$HOME/guix-test-profile[-XXX-link]" links.  Simply remove
> these links and run "guix gc".

As Pjotr suggested, I was expecting to have to delete a GC root
somewhere.  If this is not the case then the better.

Thanks for the explanation.
Fede

Re: Question related to outputs

[Pjotr Prins]

On Tue, Mar 14, 2017 at 03:14:02PM +, Pjotr Prins wrote:
> In a package I have targets for out and debug. Now I want to tell the
> make file to build different targets
> 
>   make -f Makefile.guix build-with-checks
> 
>   make -f Makefile.guix build-without-checks
> 
> The latter would be the debug with built in bounds checking etc.
> 
> After an hour of searching I don't find any example. Packages like git
> have multiple outputs, e.g. git:send-email but I it simply expands
> paths. Is there a way to test for these targets?
> 
>   (if build-without-checks (do this) (do that))

When I look in the bag for git, all outputs are always defined and they are all 
available at build time.

#< name: "git-2.11.0" system: "x86_64-linux" target: #f build-inputs: 
(("source" #) 
("native-perl" #) 
("gettext" #) ("git-manpages" #) ("tar" 
#) ("gzip" #) ("bzip2" #) ("xz" #) ("file" #) ("diffutils" #) ("patch" #) ("sed" #) ("findutils" #) ("gawk" #) ("grep" #) ("coreutils" #) ("make" #) ("bash" #) ("ld-wrapper" #) ("binutils" #) ("gcc" #) ("libc" #) ("locales" #)) 
host-inputs: (("curl" #) 
("expat" #) ("openssl" 
#) ("perl" #) ("python" #) ("zlib" #) ("perl-cgi" #) ("subversion" #) 
("perl-term-readkey" #) ("perl-authen-sasl" #) ("perl-net-smtp-ssl" 
#) 
("perl-io-socket-ssl" #) ("tcl" #) ("tk" #)) target-inputs: () outputs: ("out" 
"send-email" "svn" "gui") arguments: (#:system "x86_64-linux" #:make-flags 
(quasiquote ("V=1" "NO_INSTALL_HARDLINKS=indeed")) #:test-target "test" 
#:tests? #f #:configure-flags (list (string-append "--with-tcltk=" (assoc-ref 
%build-inputs "tk") "/bin/wish8.6")) #:modules ((srfi srfi-1) (guix build 
gnu-build-system) (guix build utils) (guix build gremlin) (guix elf)) #:phases 
(modify-phases %standard-phases (add-after (quote configure) (quote 
patch-makefile-shebangs) (lambda _ (substitute* "Makefile" (("/bin/sh") (which 
"sh")) (("/usr/bin/perl") (which "perl")) (("/usr/bin/python") (which 
"python") (add-after (quote configure) (quote add-PM.stamp) (lambda _ 
(call-with-output-file "perl/PM.stamp" (const #t)) #t)) (add-after (quote 
install) (quote install-shell-completion) (lambda* (#:key outputs 
#:allow-other-keys) (let* ((out (assoc-ref outputs "out")) (completions 
(string-append out "/etc/bash_completion.d"))) (mkdir-p completions) (copy-file 
"contrib/completion/git-completion.bash" (string-append completions "/git")) 
#t))) (add-after (quote install) (quote split) (lambda* (#:key inputs outputs 
#:allow-other-keys) (let* ((out (assoc-ref outputs "out")) (se (assoc-ref 
outputs "send-email")) (svn (assoc-ref outputs "svn")) (gui (assoc-ref outputs 
"gui")) (gitk (string-append out "/bin/gitk")) (gitk* (string-append gui 
"/bin/gitk")) (git-gui (string-append out "/libexec/git-core/git-gui")) 
(git-gui* (string-append gui "/libexec/git-core/git-gui")) (git-cit 
(string-append out "/libexec/git-core/git-citool")) (git-cit* (string-append 
gui "/libexec/git-core/git-citool")) (git-se (string-append out 
"/libexec/git-core/git-send-email")) (git-se* (string-append se 
"/libexec/git-core/git-send-email")) (git-svn (string-append out 
"/libexec/git-core/git-svn")) (git-svn* (string-append svn 
"/libexec/git-core/git-svn")) (git-sm (string-append out 
"/libexec/git-core/git-submodule"))) (mkdir-p (string-append gui "/bin")) 
(mkdir-p (string-append gui "/libexec/git-core")) (mkdir-p (string-append se 
"/libexec/git-core")) (mkdir-p (string-append svn "/libexec/git-core")) 
(for-each (lambda (old new) (copy-file old new) (delete-file old) (chmod new 
365)) (list gitk git-gui git-cit git-se git-svn) (list gitk* git-gui* git-cit* 
git-se* git-svn*)) (wrap-program git-svn* (quasiquote ("PATH" ":" prefix 
((unquote (string-append (assoc-ref inputs "subversion") "/bin") 
(quasiquote ("PERL5LIB" ":" prefix (unquote (map (lambda (i) (string-append 
(assoc-ref inputs i) "/lib/perl5/site_perl")) (quote ("subversion" 
"perl-term-readkey")) (quasiquote ("LD_LIBRARY_PATH" ":" prefix ((unquote 
(string-append (assoc-ref inputs "subversion") "/lib")) (wrap-program 
git-se* (quasiquote ("PERL5LIB" ":" prefix (unquote (map (lambda (o) 
(string-append o "/lib/perl5/site_perl")) (list (assoc-ref inputs 
"perl-authen-sasl") (assoc-ref inputs "perl-net-smtp-ssl") (assoc-ref inputs 
"perl-io-socket-ssl") (assoc-ref inputs "perl-gssapi") (assoc-ref inputs 
"perl-digest-hmac") (assoc-ref inputs "perl-uri") (assoc-ref inputs 
"perl-net-ssleay"))) (wrap-program (string-append out 
"/share/gitweb/gitweb.cgi") (quasiquote ("PERL5LIB" ":" prefix (unquote (map 
(lambda (o) (string-append o "/lib/perl5/site_perl")) (list (assoc-ref inputs 
"perl-cgi") (assoc-ref inputs "perl-html-parser"))) (wrap-program git-sm 
(quasiquote ("PATH" ":" prefix ((unquote (string-append (assoc-ref inputs 
"perl") "/bin")) (wrap-program (string-append out "/bin/git") (quasiquote 
("PATH" ":" prefix ("$HOME/.guix-profile/libexec/git-core"))) (add-after 
(quote split) (quote install-man-pages) (lambda* 

Re: delete profile

[Pjotr Prins]

On Tue, Mar 14, 2017 at 05:28:52PM +0300, Alex Kost wrote:
> No, "$HOME/guix-test-profile" was not a symlink to
> "/var/guix/profiles/...".  Try this:

Hmmm. You are right. ~/.guix-profile, meanwile, does point inside
/var/guix. 

I have wondered before how GC works on profiles not in /var/guix.

Where does it store that state? In the database? I mean, if I simply
remove the symlink

  lrwxrwxrwx  1 wrk   502   51 Feb 19 09:38 guix-build-system-1-link -> 
/gnu/store/0lyv2p35ziymd6xjrfxy8sp502n2ii5d-profile

how does Guix know it can GC 
/gnu/store/0lyv2p35ziymd6xjrfxy8sp502n2ii5d-profile?

Pj.

Question related to outputs

[Pjotr Prins]

In a package I have targets for out and debug. Now I want to tell the
make file to build different targets

  make -f Makefile.guix build-with-checks

  make -f Makefile.guix build-without-checks

The latter would be the debug with built in bounds checking etc.

After an hour of searching I don't find any example. Packages like git
have multiple outputs, e.g. git:send-email but I it simply expands
paths. Is there a way to test for these targets?

  (if build-without-checks (do this) (do that))

In gnu/packages/python.scm:L268

 (let ((out (assoc-ref outputs "out"))
   (tk  (assoc-ref outputs "tk")))
  (when tk 
(match (find-files out "tkinter.*\\.so")
...

looks faulty to me as tk always expands to an outputs path.

Pj.
-- 

Re: delete profile

[Alex Kost]

Federico Beffa (2017-03-14 09:42 +0100) wrote:

> Pjotr Prins  writes:
>
>> On Mon, Mar 13, 2017 at 10:35:56PM +0300, Alex Kost wrote:
>>> Federico Beffa (2017-03-12 18:28 +0100) wrote:
>>> 
>>> > Hi,
>>> >
>>> > I've created a profile for test purposes with
>>> >
>>> > guix package -p $HOME/guix-test-profile -m test-manifest.scm
>>> >
>>> > that now I would like to delete.  I've looked up the documentation but
>>> > not found any suitable command.  What's the recommended procedure to
>>> > delete it?
>>> 
>>> I would simply remove it and all its generations
>>> ("$HOME/guix-test-profile-XX-link") manually.  I don't know if there is
>>> any recommended way to do it though.
>>
>> That removes the symlinks to a directory in /var/guix/profiles. I
>> think you also need to remove the links in the latter if you want the
>> garbage collection to work. 
>
> 'guix -p $HOME/guix-test-profile' lists only 1 generation (but I did
> create another one and then I rolled-back).
>
> I run 'guix gc' and now I find dangling symlinks in my $HOME.

What dangling symlinks?  Just remove them :-)

> One
> symlink is still active (the active generation) which imply that it is
> registered as a GC root.

Look at /var/guix/gcroots/auto/ to see the registered GC roots, but
don't remove them manually, just remove the profile links you created,
then "guix gc" should clean the store from those profiles.

> However, it's not in
> '/usr/local/var/guix/profiles' (I installed from source with the default
> prefix=/usr/local).

this var/guix/profiles is only for system and per-user profiles.
Profiles that you create explicitly (with --profile option) are not
placed there.

> Not sure where to find it.

I'm not sure what you mean: the profiles you created with "guix package
-p $HOME/guix-test-profile -i ..." are in the store and the symlinks to
them are these "$HOME/guix-test-profile[-XXX-link]" links.  Simply remove
these links and run "guix gc".

-- 
Alex

Re: delete profile

[Alex Kost]

Pjotr Prins (2017-03-14 05:55 +) wrote:

> On Mon, Mar 13, 2017 at 10:35:56PM +0300, Alex Kost wrote:
>> Federico Beffa (2017-03-12 18:28 +0100) wrote:
>>
>> > Hi,
>> >
>> > I've created a profile for test purposes with
>> >
>> > guix package -p $HOME/guix-test-profile -m test-manifest.scm
>> >
>> > that now I would like to delete.  I've looked up the documentation but
>> > not found any suitable command.  What's the recommended procedure to
>> > delete it?
>>
>> I would simply remove it and all its generations
>> ("$HOME/guix-test-profile-XX-link") manually.  I don't know if there is
>> any recommended way to do it though.
>
> That removes the symlinks to a directory in /var/guix/profiles.

No, "$HOME/guix-test-profile" was not a symlink to
"/var/guix/profiles/...".  Try this:

  guix package --no-grafts -i hello -p /tmp/test-profile
  ls -l /tmp/test-profile*

As you can see, now there is "/tmp/test-profile" which points to a
single generation which points to "/gnu/store…-profile".

> I think you also need to remove the links in the latter if you want
> the garbage collection to work.
>
> Is that correct?

No, as you can see "/var/guix/profiles/..." was not modified in any way.
So removing "/tmp/test-profile*" links should be enough; next time "guix
gc" will remove the store entries for the created profile.

-- 
Alex

Re: Introducing ‘guix pack’

[Andy Wingo]

Hey :)

On Tue 14 Mar 2017 14:42, l...@gnu.org (Ludovic Courtès) writes:

> If we remove /var/guix/profiles, users will have to actually type
> /gnu/store/asasdfadfgsadfa-profile/bin/guile.  This is not great, but I
> don’t know what else could be done.  We could profile a
> /bin/guile → /gnu/store/asasdfadfgsadfa-profile/bin/guile symlink, but
> perhaps that’s risky too.

As we were discussing in the channel, maybe it's OK for these binary
installs to claim "/opt/gnu".  Then we expose the profile in /opt/gnu,
so you would run Guile as /opt/gnu/bin/guile.  Additionally you could
actually build against that Guile, which would be pretty neat.  If the
user untars multiple guix packs, /gnu/store easily absorbs the union,
and /opt/gnu will adjoin any new profile directories/files and replace
any overwritten links.

We would have to make sure the union directory in /opt/gnu has all real
directories and only symlink files, as per the recent patch on
guix-devel.

Andy

Re: [Whonix-devel] GNU Guix Questions

[Ludovic Courtès]

Hello!

ban...@openmailbox.org skribis:

> Yes we are interested in running our own substitute servers. We
> currently host our project specific .deb repo. Or do you mean a full
> mirror of hydra?

>From a security viewpoint, the more independent builders there are, the
better.

So if Whonix and other organizations would run their own build farm and
publish their own substitutes (presumably with Cuirass and ‘guix
publish’), that would be great.  With more and more of our packages
being bit-reproducible, users could easily use ‘guix challenge’ to
compare what each server is providing and detect anything suspicious.

Ludo’.

Re: Introducing ‘guix pack’

[Ludovic Courtès]

Hi!

Andy Wingo  skribis:

> Yes, though I hadn't thought everything out.  I guess my mail question
> is about user experience -- this is going to be a gateway for people to
> get Guix and Guile and we should make sure there are no rough edges.  I
> guess in particular I have a concern about users overwriting their
> /var/guix.  (No worries about overwriting /gnu/store of course.)
>
> Particularly if a user installs one "guix pack" then installs another
> "guix pack", what happens?  Does the /var/guix tarball include the
> sqlite db?  Could it be overwritten?  What if the user had already
> installed Guix already; does this silently trash their Guix install?
>
> A bug report: I just tried it but it seems guix pack doesn't respect
> --no-build-hook for some reason, and also for some reason on this
> machine my Guix daemon fails with "offload: command not found", which I
> was getting around via --no-build-hook.
>
> I guess what would be ideal would be:
>
>   cd /
>   sudo tar xvf aasdfafasdfjasdaldfhasdfh-guile.tar.xz
>
> and then telling the user to run via
> /gnu/store/asasdfadfgsadfa-profile/bin/guile.  That way there is very
> little risk of trashing the user's system.

Yes, something like that.

> Of course we could also provide them a README of sorts for all the load
> paths, but in the end this is a gateway to the real experience :)
>
> I guess for binary installs you would of course want /var/guix, the
> database, and the profiles.  I think in that case it makes sense to add
> an option to --pack about including them, and have it default to off
> (given the potential to trample a user's store).
>
> WDYT?  Any of this make sense? :)

Yes!  I thought about making at least /var/guix/db optional and
off by default.

If we remove /var/guix/profiles, users will have to actually type
/gnu/store/asasdfadfgsadfa-profile/bin/guile.  This is not great, but I
don’t know what else could be done.  We could profile a
/bin/guile → /gnu/store/asasdfadfgsadfa-profile/bin/guile symlink, but
perhaps that’s risky too.

Thoughts?

Ludo’.

Re: [PATCH 00/10] Next 10 ocaml packages

[Ludovic Courtès]

Leo Famulari  skribis:

> On Sun, Mar 12, 2017 at 09:28:58PM +0100, Julien Lepiller wrote:
>> Julien Lepiller (10):
>>   gnu: Add ocaml-sexplib.
>>   gnu: Add ocaml-typerep.
>>   gnu: Add ocaml-variantslib.
>>   gnu: Add ocaml-ppx-sexp-conv.
>>   gnu: Add ocaml-ppx-variants-conv.
>>   gnu: Add ocaml-ppx-here.
>>   gnu: Add ocaml-ppx-assert.
>>   gnu: Add ocaml-ppx-enumerate.
>>   gnu: Add ocaml-ppx-let.
>>   gnu: Add ocaml-ppx-typerep-conv.
>
> LGTM!

BTW Julien, consider using guix-patc...@gnu.org in the future.  :-)
That goes to the queue at .

Ludo’.

Re: delete profile

[Ludovic Courtès]

Hi,

Federico Beffa  skribis:

> I've created a profile for test purposes with
>
> guix package -p $HOME/guix-test-profile -m test-manifest.scm
>
> that now I would like to delete.  I've looked up the documentation but
> not found any suitable command.  What's the recommended procedure to
> delete it?

I just do:

  rm $HOME/guix-test-profile*

Ludo’.

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Marius Bakke]

Mark H Weaver  writes:

> Hi Marius,
>
> mba...@fastmail.com (Marius Bakke) writes:
>> mbakke pushed a commit to branch master
>> in repository guix.
>>
>> commit 4f3dcdd99ba13ab3bdbf1e014afcd076cd95fac7
>> Author: Marius Bakke 
>> Date:   Mon Mar 13 16:53:27 2017 +0100
>>
>> gnu: nss, nss-certs: Update to 3.29.3.
>> 
>> * gnu/packages/gnuzilla.scm (nss): Update to 3.29.3.
>
> Hydra has tried to build nss-3.29.3 on x86_64 twice, and the test suite
> failed both times.
>
>   https://hydra.gnu.org/build/1905330
>
> The first time, we got this:
>
> [  FAILED  ] 1 test, listed below:
> [  FAILED  ] DamageYDatagram/TlsDamageDHYTest.DamageClientY/8, where 
> GetParam() = ("DTLS", 770, 4, true)
>
> and the second time, this:
>
> [  FAILED  ] 1 test, listed below:
> [  FAILED  ] 
> ExtensionPre13Datagram/TlsExtensionTestPre13.AlpnReturnedBadNameLength/0, 
> where GetParam() = ("TLS", 770)
>
> This is the first time I've ever seen NSS fail to build on x86_64.  It's
> quite serious since it means around 230 dependency failures, including
> IceCat, GNOME and Qt/KDE.
>
>   https://hydra.gnu.org/eval/109538#tabs-now-fail
>
> If this problem cannot be fixed very soon, we'll need to revert this
> update.  Did it build successfully on your machine?  If so, which
> architecture did you test it on?

Hi Mark,

I have built this without trouble on two different x86_64 systems. The
release notes[0] lists a single entry[1] which looks innocuous[2], so I
doubt the failure is related to the upgrade.

I can't find the build log of the first run, but note how in the second
failure the test took more than five seconds:

[  FAILED  ] 
ExtensionPre13Datagram/TlsExtensionTestPre13.AlpnReturnedBadNameLength/0, where 
GetParam() = ("TLS", 770) (5543 ms)
(from https://hydra.gnu.org/build/1905330/nixlog/6/raw )

This is reminiscent of the trouble we had getting 3.29.2 to build on
armhf[3]. Something caused the build to stall for a few seconds, which
in turn makes the test fail due to exceeding time treshold.

Can you try restarting the build once more?

0: 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.29.3_release_notes
1: https://bugzilla.mozilla.org/show_bug.cgi?id=1342358
2: https://hg.mozilla.org/projects/nss/rev/4e9aee9c5343
3: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25974#17


signature.asc
Description: PGP signature

Re: org.gtk.Settings.FileChooser bomb out fix (aka GNOME Settings Schemas)

[Pjotr Prins]

Here is another for icecat:

(icecat:9674): Gtk-WARNING **: Could not find the icon
'gtk-go-back-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.

I guess it ought to go into debbugs.
- 

Re: delete profile

[Federico Beffa]

Pjotr Prins  writes:

> On Mon, Mar 13, 2017 at 10:35:56PM +0300, Alex Kost wrote:
>> Federico Beffa (2017-03-12 18:28 +0100) wrote:
>> 
>> > Hi,
>> >
>> > I've created a profile for test purposes with
>> >
>> > guix package -p $HOME/guix-test-profile -m test-manifest.scm
>> >
>> > that now I would like to delete.  I've looked up the documentation but
>> > not found any suitable command.  What's the recommended procedure to
>> > delete it?
>> 
>> I would simply remove it and all its generations
>> ("$HOME/guix-test-profile-XX-link") manually.  I don't know if there is
>> any recommended way to do it though.
>
> That removes the symlinks to a directory in /var/guix/profiles. I
> think you also need to remove the links in the latter if you want the
> garbage collection to work. 

'guix -p $HOME/guix-test-profile' lists only 1 generation (but I did
create another one and then I rolled-back).

I run 'guix gc' and now I find dangling symlinks in my $HOME.  One
symlink is still active (the active generation) which imply that it is
registered as a GC root.  However, it's not in
'/usr/local/var/guix/profiles' (I installed from source with the default
prefix=/usr/local).  Not sure where to find it.

Thanks for the suggestions.
Fede

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Mark H Weaver]

I wrote:
> If this problem cannot be fixed very soon, we'll need to revert this
> update.

One more thing: If you decide to revert the nss update (commit
4f3dcdd99b), please also revert commit 87f1c7efc1 (gnu: nss: Use
'modify-phases' syntax), to save Hydra from needlessly rebuilding
several hundred packages.  These two commits should be reverted
together, and then re-applied together when the problem is ultimately
resolved.

  Thanks,
Mark

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Mark H Weaver]

Hi Marius,

mba...@fastmail.com (Marius Bakke) writes:
> mbakke pushed a commit to branch master
> in repository guix.
>
> commit 4f3dcdd99ba13ab3bdbf1e014afcd076cd95fac7
> Author: Marius Bakke 
> Date:   Mon Mar 13 16:53:27 2017 +0100
>
> gnu: nss, nss-certs: Update to 3.29.3.
> 
> * gnu/packages/gnuzilla.scm (nss): Update to 3.29.3.

Hydra has tried to build nss-3.29.3 on x86_64 twice, and the test suite
failed both times.

  https://hydra.gnu.org/build/1905330

The first time, we got this:

[  FAILED  ] 1 test, listed below:
[  FAILED  ] DamageYDatagram/TlsDamageDHYTest.DamageClientY/8, where GetParam() 
= ("DTLS", 770, 4, true)

and the second time, this:

[  FAILED  ] 1 test, listed below:
[  FAILED  ] 
ExtensionPre13Datagram/TlsExtensionTestPre13.AlpnReturnedBadNameLength/0, where 
GetParam() = ("TLS", 770)

This is the first time I've ever seen NSS fail to build on x86_64.  It's
quite serious since it means around 230 dependency failures, including
IceCat, GNOME and Qt/KDE.

  https://hydra.gnu.org/eval/109538#tabs-now-fail

If this problem cannot be fixed very soon, we'll need to revert this
update.  Did it build successfully on your machine?  If so, which
architecture did you test it on?

  Mark

Re: delete profile

[Pjotr Prins]

On Mon, Mar 13, 2017 at 10:35:56PM +0300, Alex Kost wrote:
> Federico Beffa (2017-03-12 18:28 +0100) wrote:
> 
> > Hi,
> >
> > I've created a profile for test purposes with
> >
> > guix package -p $HOME/guix-test-profile -m test-manifest.scm
> >
> > that now I would like to delete.  I've looked up the documentation but
> > not found any suitable command.  What's the recommended procedure to
> > delete it?
> 
> I would simply remove it and all its generations
> ("$HOME/guix-test-profile-XX-link") manually.  I don't know if there is
> any recommended way to do it though.

That removes the symlinks to a directory in /var/guix/profiles. I
think you also need to remove the links in the latter if you want the
garbage collection to work. 

Is that correct?

Pj.