Re: [PATCH] gnu: bash-completion: Update to 2.3.

[Leo Famulari]

On Fri, Aug 05, 2016 at 08:53:46PM +0200, Andreas Enge wrote:
> The autoreconf phase is strange. Why is it suddenly needed? If there is no
> way around it, you should at least add a comment.

I notice that when projects move to GitHub, they sometimes forget to cut
a new release. GitHub automatically generates a tarball of the source
tree for each tag, and those are not bootstrapped. That's probably what
happened here, and it's worth an upstream bug report, IMO.

Re: [PATCH 06/10] gnu: mesa: Enable wayland support.

[Leo Famulari]

On Fri, Aug 05, 2016 at 04:31:25PM +0200, David Craven wrote:
> So now that 0.11.0 was merged can the update to mesa 12.0.0 go into
> core-updates?

We need to make the new core-updates branch, but there is a hiccup:

http://lists.gnu.org/archive/html/guix-devel/2016-08/msg00456.html

Please hold :)

Re: [PATCH v2] gnu: node: Update to 6.3.1.

[Leo Famulari]

On Fri, Aug 05, 2016 at 01:02:45PM +0200, Jelle Licht wrote:
>   ;; FIXME: These tests fail in the build container, but they 
> don't
>   ;; seem to be indicative of real problems in practice.
>   (for-each delete-file
> -   '("test/parallel/test-cluster-master-error.js"
> +   '("test/parallel/test-https-connect-address-family.js"
> + "test/parallel/test-tls-connect-address-family.js"

The file names suggest they require a network interface, which is
unavailable in the build environment.

> + "test/parallel/test-dgram-membership.js"
> + "test/parallel/test-cluster-master-error.js"

I assume the above comment about not being real problems in practice
holds for these tests?

> - (replace 'patch-shebangs
> -   (lambda* (#:key outputs #:allow-other-keys #:rest all)
> - ;; Work around .
> - (let* ((patch  (assoc-ref %standard-phases 'patch-shebangs))
> -(npm(string-append (assoc-ref outputs "out")
> -   "/bin/npm"))
> + (add-after 'patch-shebangs 'patch-npm-shebang
> +   (lambda* (#:key outputs #:allow-other-keys)
> + (let* ((bindir (string-append (assoc-ref outputs "out")
> +   "/bin"))
> +(npm(string-append bindir "/npm"))
>  (target (readlink npm)))
> -   (and (apply patch all)
> -(with-directory-excursion (dirname npm)
> -  ;; Turn NPM into a symlink to TARGET again, which 'npm'
> -  ;; relies on for the resolution of relative file names
> -  ;; in JS files.
> -  (delete-file target)
> -  (rename-file npm target)
> -  (symlink target npm)
> -  #t
> +   (with-directory-excursion bindir
> + (patch-shebang target (list bindir))
> + #t)))

Will you mention these changes in the commit message?

Re: [PATCH] Add python-pythondialog

[Leo Famulari]

On Thu, Aug 04, 2016 at 08:16:42AM +, ng0 wrote:
> Leo Famulari  writes:
> 
> > On Thu, Jul 28, 2016 at 12:53:15PM +0200, Vincent Legoll wrote:
> >> And actually the patch is wrong, I think it's missing a closing paren
> >> for python2-pythondialog...
> >
> > I re-wrote it using the 'python2-variant' system, as attached. Does it
> > work for you?
> >
> > I'm not sure if that's the right approach, but the resulting package for
> > python2-pythondialog has the same result as before. What I mean is that
> > I was able to download a substitute from Hydra for it, even with this
> > new package definition.
> >
> > Also, I noticed that the Python 3 and Python 2 versions of this software
> > tend to be released concurrently, so I made the Python 2 package take
> > the version of the Python 3 package. Do you think that will work?
> 
> Maybe.. I have no reference why I needed this in the first
> place. PyBitmessage dependeny? I would say it works for me, but I don't
> know exactly what the problem was outside of this thread.

Okay, well I just pushed it as 1ae44b802 :) So we have it if we need it.

Re: [PATCH] gnu: Add bs1770gain.

[Leo Famulari]

On Wed, Aug 03, 2016 at 05:38:46PM -0500, Alex Griffin wrote:
> This patch adds bs1770gain, a tool for adjusting and normalizing the
> loudness of audio and video files.
> 
> * gnu/packages/video.scm (bs1770gain): New variable.

Thanks!

The license headers say GPL version 2 or later, so I changed it to
gpl2+.

And, since it operates on audio, I moved it to the audio package module.

Pushed as e87c7ec2

Re: [PATCH] gnu: beets: Update to 1.3.19.

[Leo Famulari]

On Wed, Aug 03, 2016 at 05:38:40PM -0500, Alex Griffin wrote:
> The most important plugin that I'm missing is the replaygain plugin, and
> I've got it working on my system now. There are multiple replaygain
> backends, and I wanted the bs1770gain backend, so I created a package
> for that. I started to make some related changes in the beets package
> too, but I'm not sure if it's worth the trouble.
> 
> If a user (1) installs bs1770gain into their profile, and (2) edits
> their config file to use that backend, then the replaygain plugin works
> fine. The nix package does a lot of patching to make both of those step
> unnecessary, but it seems like overkill to me.
> 
> The 'convert' plugin is similar in that it doesn't work OOTB, but it can
> be fixed by the user without modifying beets (just install ffmeg or
> configure it to use other commands for conversion).
> 
> WDYT?

I don't know how we've handled plugins, in general, so far. I think
there is an interesting approach to ALSA plugins on this branch:
https://notabug.org/Jookia/guix/commits/WIP_av

In the meantime, asking users to configure them manually seems fine. But
maybe I'm biased — I literally only use Beets to copy new music into my
library based on the music metadata tags. No plugins for me :)

Do you know how it works for Beets on "traditional" distros?

Re: [PATCH 1/5] gnu: Add libvirt.

[Leo Famulari]

On Wed, Aug 03, 2016 at 05:45:59PM +0200, Ricardo Wurmus wrote:
> + (add-after 'unpack 'fix-tests
> +   (lambda _
> + (substitute* '("tests/commandtest.c"
> +"gnulib/tests/test-posix_spawn1.c"
> +"gnulib/tests/test-posix_spawn2.c")
> +   (("/bin/sh") (which "bash")))
> + #t))

According to the man page, Bash changes its behavior to be more POSIX-y
when called as sh.  So, how about replacing these shebangs with (which
"sh"), since their names suggest they are testing some POSIX behavior
(at least the latter two tests).

Re: [PATCH 2/2] gnu: tcsh: Update to 6.19.00.

[Leo Famulari]

On Wed, Aug 03, 2016 at 05:33:36AM +0200, Tobias Geerinckx-Rice wrote:
> Only four tests fail now when building unpatched on my x86_64-linux
> machine, down from six in the previous version. I've trimmed down
> ‘tcsh-fix-autotest.patch’ to only disabled those 4 tests.
> 
> This may be overly optimistic. Testing (tips) welcome.

It is possible to test 32-bit i686 from x86_64 with `guix build
--system=i686-linux tcsh`. I only do this for critical packages,
however, unless I happen to have the i686 base system already in my
store. For armhf and mips64el, we can let Hydra test for us, unless
somebody wants to try it.

Btw, what do others think about updating this on master? `guix refresh
-l` reports 309 rebuilds.

In general, the patch LGTM.

Re: [PATCH 1/2] gnu: zsh: Use 'modify-phases'.

[Leo Famulari]

On Wed, Aug 03, 2016 at 05:33:35AM +0200, Tobias Geerinckx-Rice wrote:
> * gnu/packages/shells.scm (zsh)[arguments]: Use ‘modify-phases’
> instead of ‘alist-delete’.

LGTM

Re: [PATCH]Add ALSA support for recordmydesktop.

[Leo Famulari]

On Tue, Aug 02, 2016 at 11:13:43PM +0300, Pak Pang wrote:
> Hello. I made a patch to add ALSA support for recordmydesktop.

Great, thanks!

> Dmitry Nikolaev

What name do you want to use for the Git commit's Author field?

As is, it looks like this:

$ git log
commit fa58352d7a630f352ff4e84d1b7b175c3fcfc788
Author: 8p8c 
Date:   Tue Aug 2 23:11:46 2016 +0300

gnu: recordmydesktop: Add ALSA support.

* gnu/packages/video.scm (recordmydesktop)[inputs]: Add ALSA-LIB

It's fine to use 8p8c if you prefer.

Re: [PATCH] gnu: Add stress-make.

[Leo Famulari]

On Tue, Aug 02, 2016 at 11:53:33AM -0500, Eric Bavier wrote:
> Hello Guix,
> 
> I'm mostly looking for a second-opinion on the license of this package.
> Other comments welcome too, of course.
> 
> * gnu/packages/debug.scm (stress-make): New variable.

> +  (version (string-append "1.0-" revision "." (string-take commit 7)))

It appears they never made a release, so I think we should use "0.0.0"
instead of "1.0".

> + (uri (git-reference
> +   (url "git://github.com/losalamos/stress-make.git")

I think it's better to use the HTTPS protocol instead of the Git
protocol, unless there is some reason not to. What do you think?

https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#The-Git-Protocol

> +  (inputs
> +   `(("make-src" ,(package-source gnu-make

How about "make-source", since we seem to shun abbreviations?

> +  (arguments
> +   ;; stress-make's configure script insists on having a tarball and does
> +   ;; not accept a directory name instead.  To let the gnu-build-system's
> +   ;; patch-* phases work properly, we unpack the source first, then
> +   ;; repack before the configure phase.

o_O

> +  ;; stress-make wrapper is under BSD-3-modifications-must-be-indicated,
> +  ;; and patched GNU Make is under its own license.
> +  (license (list bsd-3 (package-license gnu-make))

Perhaps we should call it non-copyleft instead of bsd-3?

Re: [PACKAGE] sinit

[Leo Famulari]

On Sat, Jul 30, 2016 at 06:19:47PM +0200, Vincent Legoll wrote:
> On Sat, Jul 30, 2016 at 3:46 PM, Vincent Legoll
>  wrote:
> > Here is the accompanying patch for sinit to build properly under guix
> >
> > It will be submitted alongside the scm modifs.
> >
> > I may even try to make it upstream, as it's fairly straightforward...
> 
> DONE:
> http://lists.suckless.org/hackers/1607/11719.html
> 
> Dunno the responsiveness, so no ETA for an upstream release fixing this...

I noticed they replied with another suggestion:

http://lists.suckless.org/hackers/1607/11720.html

What happens if you set those variables in #:make-flags? There is an
example in (gnu packages dvtm).

Re: [Nix-dev] GNU Guix & GuixSD 0.11.0 released

[Leo Famulari]

On Fri, Aug 05, 2016 at 07:55:28PM +0200, Profpatsch wrote:
> On 16-08-03 04:03pm, Ludovic Courtès wrote:
> > We are pleased to announce the release of GNU Guix & GuixSD 0.11.0,
> > representing 2,119 commits by 70 people over 4 months.
> 
> Thumbs up for the effort.
> Would love to see some cross-fertilization between the projects.

I agree. All ideas welcome :)


signature.asc
Description: PGP signature

Re: [PATCH 12/12] gnu: python: Add python-ipaddress.

[Leo Famulari]

On Sat, Aug 06, 2016 at 02:52:37PM +0200, David Craven wrote:
> > I believe we already have python2-ipaddress, although an older version.
> 
> Ups, I missed that. Thanks.
> 
> Can you answer some questions on best practices for packaging python packages?
> 
> 1. Are python-setuptools inputs or native-inputs? It seems to be done
> both ways but I guess it doesn't really matter since it's an interpreted
> language.

Almost always native-inputs, but there are a handful of packages that
actually use setuptools at runtime.

> 2. Pypi uri scheme changed in April to including a blake hash of the
> files, but they introduced backwards compatible redirects after it
> broke many existing tools [0]. Should new packages use the new
> or the old scheme? IMO the old one is cleaner since we can use
> (pypi-uri "package-name" version) to construct it instead of having
> long hashes. If this is a best practice we should also have the
> pypi importer suggest it instead of the new url's.

We prefer to use pypi-uri. We used the long blake URLs while we were
adjusting pypi-uri to work with the new PyPi URL scheme.

Re: [GSoC] Continuous integration tool à la Hydra.

[Mathieu Lirzin]

Hello David,

David Craven  writes:

> Are you already working on a package/service for guix?

This would indeed be the goal, however I am not there yet.

> I'd like to deploy it to my server to avoid silly mistakes
> like in my last two pushes to master...
>
> Does it rebuild from commit individually or only HEAD?
> This would be nice to check for rebase mistakes where
> HEAD builds but a commit doesn't.

That would make sense as an option, however the current model is
simplistic and only evaluates the new HEAD commit.

> Does it already support building packages for all guix
> supported systems?

For now, you have to modify the 'gnu-system.scm' file to your needs to
achieve that.  basically you need to define another "subset" case in
'gnu-system.scm' and adjust the '#:arguments' value in the job
specification.

> ```
> (define (local-file file)
> ;; In the common case jobs will be defined relative to the repository.
> ;; However for testing purpose use local gnu-system.scm instead.
> (string-append (dirname (current-filename)) "/" file))
> (define hello-master
> `((#:name . "guix")
> (#:url . "git://git.savannah.gnu.org/guix.git")
> (#:load-path . ".")
> (#:file . ,(local-file "gnu-system.scm"))
> (#:proc . hydra-jobs)
> (#:arguments (subset . "hello"))
> (#:branch . "master")))
> (list hello-master)
> ```
>
> Can I also define custom jobs like running guix --rounds=2 and
> guix lint?

Likewise.  However this would require more work.  :)

I guess the future approach will be to define both the scheme code
running on the client side and on the build (remote) side in the job
specification.  I mean something similar to what Guix is doing for its
package definitions.  The details are not defined yet.

Thanks for your questions.

-- 
Mathieu Lirzin

Re: [PATCH] gnunet-svn, gnunet-gtk-svn

[ng0]

The next 2.5 days will be unpleasant for me and probably difficult to
focus, but I know how to fix the 3 failing tests for us.
I'll have this fixed in thex next days.

Appended is the failing tests output (for me as a backup) and the
combined gnunet-svn + gnunet-gtk-svn patch. As we discussed this will
not be in guix at the moment and is intended as a test package to get
the next release of gnunet to build on guix when it is released.

There are last things I want to transition from my Gentoo package to the
guix packages.

I'd like to have a gnunet package with --with-experimental enabled
(features: conversation etc, at least last time I read the Makefile), so
this will be available out of tree when all the features are too much
for master tree (or --with-experimental is considered too unstable to
ship).

The log attachment was too big, log can be replicated with tests
enabled.

Have a nice weekend.

<<< message/external-body; name="#(\"/home/ng0/src/guix/guix-gnunet/0001-gnu-Add-gnunet-svn.patch\" 10 14 (face flx-highlight-face) 14 19 (face flx-highlight-face) 19 31 (face flx-highlight-face) 31 41 (face flx-highlight-face))"; access-type=local-file: Unrecognized >>>
>From 3b20856c29dc559dc046cd267428b0bd771a7efb Mon Sep 17 00:00:00 2001
From: ng0 
Date: Sat, 30 Jul 2016 15:04:24 +
Subject: [PATCH 2/3] gnu: Add gnunet-gtk-svn.

* gnu/packages/gnunet.scm (gnunet-gtk-svn): New variable.
---
 gnu/packages/gnunet.scm | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 25ac073..a3f34ea 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -412,3 +412,50 @@ an application for secure publication of files, it has grown to include all
 kinds of basic applications for the foundation of a GNU internet.")
   (license license:gpl3+)
   (home-page "https://gnunet.org/;
+
+(define-public gnunet-gtk-svn
+  (let ((svn-revision 37273))
+(package
+  (inherit gnunet-svn)
+  (name "gnunet-gtk-svn")
+  (version (package-version gnunet-svn))
+  (source
+   (origin
+ (method svn-fetch)
+ (uri (svn-reference
+   (url "https://gnunet.org/svn/gnunet-gtk/;)
+   (revision svn-revision)))
+ (file-name (string-append name "-" version "-checkout"))
+ (sha256
+  (base32
+   "1mckc5aq05wpbvb8mbm0llkhavb0j2f496l73zaapdy3ndyhai8j"
+  (arguments
+   `(#:configure-flags
+ (list "--without-libunique"
+   "--with-qrencode"
+   (string-append "--with-gnunet="
+  (assoc-ref %build-inputs "gnunet-svn")))
+ #:phases
+ (modify-phases %standard-phases
+   (add-before 'configure 'bootstrap
+ (lambda _
+   (zero? (system* "autoreconf" "-vfi")))
+  (inputs
+   `(("gnunet-svn" ,gnunet-svn)
+ ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
+ ("gnutls" ,gnutls)
+ ("libgcrypt" ,libgcrypt)
+ ("gtk+" ,gtk+)
+ ("libextractor" ,libextractor)
+ ("glade3" ,glade3)
+ ("qrencode" ,qrencode)))
+  (native-inputs
+   `(("pkg-config" ,pkg-config)
+ ("libglade" ,libglade)
+ ("autoconf" ,autoconf)
+ ("gnu-gettext" ,gnu-gettext)
+ ("automake" ,automake)
+ ("libtool" ,libtool)))
+  (synopsis "Graphical front-end tools for GNUnet")
+  (home-page "https://gnunet.org;
+
-- 
2.9.2

>From 282df1603637d80946c619ebaea8598d766d7527 Mon Sep 17 00:00:00 2001
From: ng0 
Date: Sat, 6 Aug 2016 17:54:02 +
Subject: [PATCH 3/3] further changes on top of gnunet-svn and gnunet-svn-gtk.

---
 gnu/packages/gnunet.scm | 56 ++---
 1 file changed, 44 insertions(+), 12 deletions(-)

diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index a3f34ea..bdfd3b4 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -49,6 +49,13 @@
   #:use-module (gnu packages databases)
   #:use-module (gnu packages tls)
   #:use-module (gnu packages video)
+  #:use-module (gnu packages web)
+  #:use-module (gnu packages ncurses)
+  #:use-module (gnu packages admin)
+  #:use-module (gnu packages gnuzilla)
+  #:use-module (gnu packages multiprecision)
+  #:use-module (gnu packages linux)
+;;  #:use-module (gnu packages tex)
   #:use-module (gnu packages xiph)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
@@ -338,7 +345,7 @@ services.")
 ;; version before refactoring work towards 0.10.2 started.
 
 (define-public gnunet-svn
-  (let ((svn-revision 37273))
+  (let ((svn-revision 37667))
 (package
   (name "gnunet-svn")
   (version (string-append "0.10.1" "-1" ".svn"
@@ -352,7 +359,7 @@ services.")
  (file-name (string-append name "-" version "-checkout"))
   

Re: [GSoC] Continuous integration tool à la Hydra.

[David Craven]

> I understand that, but developers should have a simple way to check
> their own work. Hopefully commits made to master are good commits
> and hydra only has to rebuild from HEAD.

It would also be nice if developers could easily hook up their servers to
the guix build farm, if I do run my own continuous integration system,
my server would be idling most of the time anyway, so it would be
nice to use that time.

Re: [GSoC] Continuous integration tool à la Hydra.

[David Craven]

> We don't have enough build farm capacity to make it practical to check
> every commit.  It might make sense to include an option for this, but
> most of the time we'd need to disable it.

I understand that, but developers should have a simple way to check
their own work. Hopefully commits made to master are good commits
and hydra only has to rebuild from HEAD.

Re: [GSoC] Continuous integration tool à la Hydra.

[Mark H Weaver]

David Craven  writes:

> Hi Mathieu,
>
> Are you already working on a package/service for guix?
>
> I'd like to deploy it to my server to avoid silly mistakes
> like in my last two pushes to master...
>
> Does it rebuild from commit individually or only HEAD?
> This would be nice to check for rebase mistakes where
> HEAD builds but a commit doesn't.

We don't have enough build farm capacity to make it practical to check
every commit.  It might make sense to include an option for this, but
most of the time we'd need to disable it.

  Mark

Re: [PATCH 3/5] gnu: qemu: Enable spice support.

[Mark H Weaver]

Hi David,

David Craven  writes:

>> Unfortunately, 'spice' only builds successfully on x86_64, so with this
>> patch, i686 and armhf lose 'qemu'.
>
> 'usbredir' is needed by 'spice-gtk' which is only needed to run the tests
> for spice. This can be fixed by removing the automated tests configure-flag
> and removing spice-gtk from the dependencies on i686.

I would prefer to fix 'usbredir' on i686.  The same error occurs on all
non-x86_64 systems, so if you can fix it on i686, there's a good chance
it will work on mips64el and armhf as well.  Hydra will check that.

In any case, i686 is the most important for now.  You can see the failed
build log via this link:

  https://hydra.gnu.org/job/gnu/master/usbredir-0.7.1.i686-linux

Here's the relevant excerpt:

--8<---cut here---start->8---
  CC   libusbredirhost_la-usbredirhost.lo
usbredirhost.c: In function ‘usbredirhost_can_write_iso_package’:
usbredirhost.c:1023:13: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 4 has type ‘uint64_t’ [-Werror=format=]
 DEBUG("START dropping isoc packets %lu buffer > %lu hi threshold",
 ^
usbredirhost.c:1023:13: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format=]
usbredirhost.c:1028:13: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 4 has type ‘uint64_t’ [-Werror=format=]
 DEBUG("STOP dropping isoc packets %lu buffer < %lu low threshold",
 ^
usbredirhost.c:1028:13: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format=]
usbredirhost.c: In function ‘usbredirhost_set_iso_threshold’:
usbredirhost.c:1162:5: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 4 has type ‘uint64_t’ [-Werror=format=]
 DEBUG("higher threshold is %lu bytes | lower threshold is %lu bytes",
 ^
usbredirhost.c:1162:5: error: format ‘%lu’ expects argument of type ‘long 
unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format=]
cc1: all warnings being treated as errors
--8<---cut here---end--->8---

> If supported-systems is set correctly, will guix try to build without
> the required package?

No.  A package is considered "unsupported" on a given architecture if
any of its transitive inputs are unsupported there.  See
'package-transitive-supported-systems' and 'supported-package?'
in guix/packages.scm.

> Trying to build with guix build --system=armhf-linux tells me that I'm
> x86-64-linux and the same for --system=mipsel-linux. It would be
> nice if guix build would spin up a qemu instance in this case.

I agree that would be very nice, but no one has implemented it yet.

> Before reinventing the wheel or deploying my own hydra build farm
> (or cuirass), is there a simple way to build a package for all supported
> platforms?

No, it currently requires having access to a system of the desired
architecture running Guix.  If you have this, then you can arrange for
builds to be automatically "offloaded" to that machine as needed.  See
section 2.4.2 (Using the Offload Facility) in the Guix manual for
details.

Note that if GuixSD included support for mips64el or armhf running qemu,
then you could use "guix system vm" to create a virtual system of the
desired system, and then configure Guix to offload builds to it, and
this could be automated.  However, at present, you'd need to install a
different distro within qemu, install Guix within it, and then set up
offloading manually.

Anyway, it is always possible to build for i686 on an x86_64 system
without offloading, and fortunately that should be sufficient to make
progress on this issue.

> It looks like guix ignores the supported-systems property and
> doesn't make use of it anywhere.

It's used to determine which build jobs are attempted on Hydra, affects
the output of "guix package --list-available", and maybe a few other
things.

> Say it doesn't prevent building a package on i686-linux when only
> x86_64-linux is in the list.

Yes, Guix will attempt a build if you ask it to, even if the package is
listed as unsupported on your system.

Thanks for your efforts!

 Regards,
   Mark

Re: [PATCH 12/12] gnu: python: Add python-ipaddress.

[Danny Milosavljevic]

> 1. Are python-setuptools inputs or native-inputs? It seems to be done
> both ways but I guess it doesn't really matter since it's an interpreted
> language.

Usually native-inputs. The idea is you only need the native-inputs to compile 
and install the thing and then you can throw the native-inputs away. On the 
other hand, you need the inputs at runtime of the installed program.

You usually don't need *setup*tools after it has setup whatever it was supposed 
to setup :)

Re: [PATCH] ui: 'package->recutils' serializes the source field.

[Mathieu Lirzin]

Alex Kost  writes:

> David Craven (2016-08-05 17:58 +0300) wrote:
>
>> * guix/ui.scm (package->recutils): Format origin.
>> ---
>>  guix/ui.scm | 18 ++
>>  1 file changed, 18 insertions(+)
>>
>>
>> diff --git a/guix/ui.scm b/guix/ui.scm
>> index 4d1b65c..e232548 100644
>> --- a/guix/ui.scm
>> +++ b/guix/ui.scm
>> @@ -26,6 +26,7 @@
>>  (define-module (guix ui)
>>#:use-module (guix utils)
>>#:use-module (guix store)
>> +  #:use-module (guix base32)
>>#:use-module (guix config)
>>#:use-module (guix packages)
>>#:use-module (guix profiles)
>> @@ -33,6 +34,7 @@
>>#:use-module (guix combinators)
>>#:use-module (guix build-system)
>>#:use-module (guix serialization)
>> +  #:use-module (guix git-download)
>>#:use-module ((guix build utils) #:select (mkdir-p))
>>#:use-module ((guix licenses) #:select (license? license-name))
>>#:use-module ((guix build syscalls) #:select (terminal-columns))
>> @@ -878,6 +880,22 @@ WIDTH columns."
>>;; Note: Don't i18n field names so that people can post-process it.
>>(format port "name: ~a~%" (package-name p))
>>(format port "version: ~a~%" (package-version p))
>> +
>> +  (let ((uri (origin-uri (package-source p
>
> This will fail for some packages (for example, for 'gcc-toolchain')
> because the source value can be #f, and (origin-uri #f) errors.
>
>> +(cond
>> +  ((git-reference? uri)
>> +(begin
>
> 'begin' is not needed here.
>
>> +  (format port "source-git-url: ~a~%"
>> +   (git-reference-url uri))
>> +  (format port "source-git-commit: ~a~%"
>> +   (git-reference-commit uri))
>> +  (format port "source-git-recursive: ~a~%"
>> +   (git-reference-recursive? uri
>> +  (#t
>
> I think using 'else' here would be more Schemey than '#t'.
>
>> +(format port "source-uri: ~a~%" uri
>> +
>> +  (format port "source-hash: ~a~%" (bytevector->base32-string
>> +  (origin-sha256 (package-source p
>>(format port "outputs: ~a~%" (string-join (package-outputs p)))
>>(format port "systems: ~a~%"
>>(string-join (package-transitive-supported-systems p)))
>
> After all I would write it like this:
>
>   (let ((source (package-source p)))
> (when (origin? source)
>   (let ((uri (origin-uri source)))
> (cond
>  ((git-reference? uri)
>   (format port "source-git-url: ~a~%"
>   (git-reference-url uri))
>   (format port "source-git-commit: ~a~%"
>   (git-reference-commit uri))
>   (format port "source-git-recursive: ~a~%"
>   (git-reference-recursive? uri)))
>  (else
>   (format port "source-uri: ~a~%" uri
>   (format port "source-hash: ~a~%"
>   (bytevector->base32-string (origin-sha256 source)
>
> However, I'm not sure whether all these source things are needed to be
> in the output, I would wait for other opinions.
>
> (I agree with you though and I would like to add the same info for Emacs
> interface :-))
>
> Also note that packages may have multiple sources.  For example, for
> 'sudo' package, the output will be:
>
>   source-uri: (https://www.sudo.ws/sudo/dist/sudo-1.8.17p1.tar.gz 
> ftp://ftp.sudo.ws/pub/sudo/OLD/sudo-1.8.17p1.tar.gz)

I don't have an opinion on what should be displayed or not (at least not
yet).  However I think there is an issue with FSDG compliance here, when
upstream includes non-free stuff for the same reason that 'guix build
--source PACKAGE' is required by FSDG to provide a cleaned version of the
tarball.

"source-uris" should point to the same thing that 'guix build -S
PACKAGE' provides however in our current infrastructure this is not
possible.

For the same reason I think Emacs interface should not display the
origin URL of those packages.  I Don't know how to achieve this, maybe
displaying only the URL when there is no snippet part would work even if
it will remove more package source URLs than needed.

WDYT?

-- 
Mathieu Lirzin

Re: core-updates merged!

[Leo Famulari]

On Wed, Aug 03, 2016 at 12:04:46AM -0400, Leo Famulari wrote:
> On Tue, Aug 02, 2016 at 11:28:59PM +0200, Ludovic Courtès wrote:
> > Leo Famulari  skribis:
> > Otherwise LGTM; could you push it to core-updates-next?
> 
> I merged master into core-updates-next and made the change in a
> subsequent commit.
> 
> Unfortunately, I can't push the branch to Savannah because it contains
> the following unsigned commits (one of them is mine, oops!):
> 
> f21403e2b6f5a9491937a0cc9f31fc113998ce5e
> 9bc84dfea9560c497c91863e7b5021860bd3c254
> 745ad37a780b28f72ac9dfcc8092317e577e51c9
> 2d74d94b17b23ab95072da68553d85ac0b3bfede
> aebd383d04b351465cfb14e4fd0949b67d4b282e
> 
> What should we do?

This is still preventing me from starting the new core-updates branch.

I guess that we should do the same thing we did when fixing the squashed
merge: disable the assert-commit-signed hook temporarily for the push.

It was also suggested to cherry-pick the 11 commits from
core-updates-next onto master — essentially rebasing them. I can try
that if everyone is okay with me re-signing those commits.

> In the meantime, you can inspect the updated branch on my personal Git
> repo:
> https://github.com/lfam/guix/commits/core-updates-next

Mark, if you want to do method that requires disabling the hook, feel
free to take my (signed) work from this link. It will save you from
doing a lot of merge conflict resolution.

Re: guix-0.11 help2man errors during compilation

[Mathieu Lirzin]

Alex Vong  writes:

> Mathieu Lirzin  writes:
>
>> Hello,
>>
>> Jan Synáček  writes:
>>
>>> I'm getting strange errors:
>>>
>>> ...
>>> HELP2MAN doc/guix-daemon.1
>>> help2man: can't get `--help' info from guix-daemon
>>> Try `--no-discard-stderr' if option outputs to stderr
>>> WARNING: 'help2man' is missing on your system.
>>>  You should only need it if you modified a dependency of a man page.
>>>  You may want to install the GNU Help2man package:
>>>  
>>> Makefile:4893: recipe for target 'doc/guix-daemon.1' failed
>>> make: [doc/guix-daemon.1] Error 127 (ignored)
>>> ...
>>>
>>> help2man *is* present on my system. Later on, more man pages in doc/
>>> are built just fine.
>
> Hi, I get similar but not identical error from help2man when building
> from the git repo.
>
> [...]
>
> LANGUAGE= ./pre-inst-env /bin/bash 
> /home/alexvong1995/scm/guix/build-aux/missing help2man --source=GNU 
> --info-page=guix --output="doc/guix-daemon.1" `basename "doc/guix-daemon.1" 
> .1`
> help2man: can't get `--version' info from guix-daemon
> Try `--no-discard-stderr' if option outputs to stderr
> Makefile:4892: recipe for target 'doc/guix-daemon.1' failed
> make[2]: [doc/guix-daemon.1] Error 64 (ignored)
> make[2]: Leaving directory '/home/alexvong1995/scm/guix'
> make[1]: Leaving directory '/home/alexvong1995/scm/guix'

[...]

> # config.log
>
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
>
> It was created by GNU Guix configure 0.11.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>
>   $ ./configure --disable-silent-rules CFLAGS=-O2 -flto CXXFLAGS=-O2 -flto 
> LDFLAGS=-O2 -flto
>

When testing with this configuration on my Debian testing system, the
build fails because guix-daemon fails to build due to "-flto" options.
I am using GCC 5.4.  I don't know anything about link time optimizations
so maybe I am overlooking something.

can you print the output of:

 ./pre-inst-env which guix-daemon

and

 ./pre-inst-env guix-daemon --version

Thanks.

-- 
Mathieu Lirzin

Re: help with setenv of perl-curses

[ng0]

Hi,

Efraim Flashner  writes:

> On Sat, Jul 23, 2016 at 01:18:10PM +, ng0 wrote:
>> Possibly fixed with this patch. Things I have not addressed so
>> far and require input on: How to do this
>> "perl Makefile.PL PANELS MENUS FORMS" in the setup.
>> Successfully built does not mean functional in all cases, so I
>> will build the package I needed this for now and see if it
>> changed.
>
> Sometimes using makeflags works for adding arguments to the `make'
> command, other times I've gone and replaced the 'make phase with a
> custom make phase. I haven't looked at the perl build system to see if
> makeflags works.

Coming back to this, should I build this with all the options? I had no
time to work on this again, so if someone else wants to add these
functionalities, go ahead.

-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: help with setenv of perl-curses

[ng0]

Hi,

Vincent Legoll  writes:

> Hello,
>
>> +(build-system perl-build-system)
>> +(inputs `(("ncurses" ,ncurses)))
>> +(arguments
>> + `(#:phases
>> +   (modify-phases %standard-phases
>> + (add-before
>> + 'configure 'set-curses-ldflags
>> +   (lambda* (#:key inputs #:allow-other-keys)
>> + (setenv "CURSES_LIBTYPE" "ncurses")
>> + (setenv "CURSES_CFLAGS"
>> + (string-append "-I" (assoc-ref inputs "ncurses")
>> +"/include"))
>> + (setenv "CURSES_LDFLAGS"
>> + (string-append "-L" (assoc-ref inputs "ncurses")
>
> Is this specific to perl-ncurses or would other ncurses-using packages also 
> need
> these definitions ?

I don't know, read the README and/or INSTALL file of this package on
cpan.

> -- 
> Vincent Legoll


-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: guix-0.11 help2man errors during compilation

[Mathieu Lirzin]

Jan Synáček  writes:

> On Fri, Aug 5, 2016 at 2:19 PM, Mathieu Lirzin  wrote:
>> Hello,
>>
>> Jan Synáček  writes:
>>
>>> I'm getting strange errors:
>>>
>>> ...
>>> HELP2MAN doc/guix-daemon.1
>>> help2man: can't get `--help' info from guix-daemon
>>> Try `--no-discard-stderr' if option outputs to stderr
>>> WARNING: 'help2man' is missing on your system.
>>>  You should only need it if you modified a dependency of a man page.
>>>  You may want to install the GNU Help2man package:
>>>  
>>> Makefile:4893: recipe for target 'doc/guix-daemon.1' failed
>>> make: [doc/guix-daemon.1] Error 127 (ignored)
>>> ...
>>>
>>> help2man *is* present on my system. Later on, more man pages in doc/
>>> are built just fine.

>> Are you building from the Git repository or the release tarball?
>
> I'm building from the 0.11 release tarball.

Humm, this is really weird.  Building from tarball is not supposed to
trigger rebuilding any of the manpages which are already included.

>> When you execute make again does it try to rebuild 'doc/guix-daemon.1'
>> if yes, does it succeed?
>
> It tries again but never succeeds.
>
> However, after rebooting my machine, I cannot reproduce this anymore...

bahhh... I will inspect what happens on Alex side then.

Thank you for the details.

-- 
Mathieu Lirzin

Re: [PATCH] gnunet-svn, gnunet-gtk-svn

[ng0]

Andreas Enge  writes:

> Hello,
>
> On Wed, Aug 03, 2016 at 11:45:56AM +, ng0 wrote:
>> I think the costs of maintaining a -svn of gnunet are too high at the
>> moment. I'm using these two packages as a base for debugging gnunet in
>> addition to gentoo to help work with upstream.
>> 
>> A revision-less svn package does not work (unlike in gentoo), so my
>> focus is at the moment to help to push towards 0.10.2 release.
>
> that sounds like a good option, to make sure that the 0.10.2 release will
> work on Guix, and hopefully pass all its tests.
>
> Thanks for the work!
>
> Andreas
>

Update: I think I have found what causes the problem, I'll post an
updated patch soon.
-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: [PATCH 12/12] gnu: python: Add python-ipaddress.

[David Craven]

> I believe we already have python2-ipaddress, although an older version.

Ups, I missed that. Thanks.

Can you answer some questions on best practices for packaging python packages?

1. Are python-setuptools inputs or native-inputs? It seems to be done
both ways but I guess it doesn't really matter since it's an interpreted
language.

2. Pypi uri scheme changed in April to including a blake hash of the
files, but they introduced backwards compatible redirects after it
broke many existing tools [0]. Should new packages use the new
or the old scheme? IMO the old one is cleaner since we can use
(pypi-uri "package-name" version) to construct it instead of having
long hashes. If this is a best practice we should also have the
pypi importer suggest it instead of the new url's.

[0] 
https://bitbucket.org/pypa/pypi/issues/438/backwards-compatible-un-hashed-package

Re: [PATCH] ui: 'package->recutils' serializes the source field.

[Alex Kost]

David Craven (2016-08-05 17:58 +0300) wrote:

> * guix/ui.scm (package->recutils): Format origin.
> ---
>  guix/ui.scm | 18 ++
>  1 file changed, 18 insertions(+)
>
>
> diff --git a/guix/ui.scm b/guix/ui.scm
> index 4d1b65c..e232548 100644
> --- a/guix/ui.scm
> +++ b/guix/ui.scm
> @@ -26,6 +26,7 @@
>  (define-module (guix ui)
>#:use-module (guix utils)
>#:use-module (guix store)
> +  #:use-module (guix base32)
>#:use-module (guix config)
>#:use-module (guix packages)
>#:use-module (guix profiles)
> @@ -33,6 +34,7 @@
>#:use-module (guix combinators)
>#:use-module (guix build-system)
>#:use-module (guix serialization)
> +  #:use-module (guix git-download)
>#:use-module ((guix build utils) #:select (mkdir-p))
>#:use-module ((guix licenses) #:select (license? license-name))
>#:use-module ((guix build syscalls) #:select (terminal-columns))
> @@ -878,6 +880,22 @@ WIDTH columns."
>;; Note: Don't i18n field names so that people can post-process it.
>(format port "name: ~a~%" (package-name p))
>(format port "version: ~a~%" (package-version p))
> +
> +  (let ((uri (origin-uri (package-source p

This will fail for some packages (for example, for 'gcc-toolchain')
because the source value can be #f, and (origin-uri #f) errors.

> +(cond
> +  ((git-reference? uri)
> +(begin

'begin' is not needed here.

> +  (format port "source-git-url: ~a~%"
> +   (git-reference-url uri))
> +  (format port "source-git-commit: ~a~%"
> +   (git-reference-commit uri))
> +  (format port "source-git-recursive: ~a~%"
> +   (git-reference-recursive? uri
> +  (#t

I think using 'else' here would be more Schemey than '#t'.

> +(format port "source-uri: ~a~%" uri
> +
> +  (format port "source-hash: ~a~%" (bytevector->base32-string
> +  (origin-sha256 (package-source p
>(format port "outputs: ~a~%" (string-join (package-outputs p)))
>(format port "systems: ~a~%"
>(string-join (package-transitive-supported-systems p)))

After all I would write it like this:

  (let ((source (package-source p)))
(when (origin? source)
  (let ((uri (origin-uri source)))
(cond
 ((git-reference? uri)
  (format port "source-git-url: ~a~%"
  (git-reference-url uri))
  (format port "source-git-commit: ~a~%"
  (git-reference-commit uri))
  (format port "source-git-recursive: ~a~%"
  (git-reference-recursive? uri)))
 (else
  (format port "source-uri: ~a~%" uri
  (format port "source-hash: ~a~%"
  (bytevector->base32-string (origin-sha256 source)

However, I'm not sure whether all these source things are needed to be
in the output, I would wait for other opinions.

(I agree with you though and I would like to add the same info for Emacs
interface :-))

Also note that packages may have multiple sources.  For example, for
'sudo' package, the output will be:

  source-uri: (https://www.sudo.ws/sudo/dist/sudo-1.8.17p1.tar.gz 
ftp://ftp.sudo.ws/pub/sudo/OLD/sudo-1.8.17p1.tar.gz)

I'm not sure if this is a desired formatting, WDYT?

-- 
Alex

Re: [PACKAGE] musl libc

[ng0]

Ricardo Wurmus  writes:

> Vincent Legoll  writes:
>
>> On Wed, Aug 3, 2016 at 1:24 PM, Ricardo Wurmus  wrote:
>>> I just built musl and found that it also installs “bin/musl-gcc”, a
>>> wrapper of sorts, but it doesn’t work as it depends on a “gcc”
>>> executable to be available.
>>
>> I did not see that as I probably had gcc installed in the profile with
>> which i built musl...
>>
>>> Is this something that needs to work in order for this package to be
>>> useful?
>>
>> Maybe not, but the default / documented way it is to be used is with
>> the wrapper, so it is nice to have...
>>
>> Is this not the same with glibc, but in a more hidden way ?
>
> We usually don’t use the “gcc” package directly in Guix.  Instead we use
> “gcc-toolchain”, which also comes with a wrapper around the linker that
> ensures that binaries are linked with libraries in the store, ensuring
> that things generally just work™.
>
> I think more work would be needed to ensure that packages can actually
> successfully be linked with musl, but I’m not at all familiar with this.
> I had mixed success with a GCC ARM cross-compiler toolchain linking with
> newlib, so I know that it’s not exactly obvious how to do this right,
> but I find it hard to understand this.
>
> Have you tried building something that links with the libc provided by
> this musl package instead of the GNU libc?  I’m not opposed to adding
> the package, but I’d like it to be usable.
>
> ~~ Ricardo
>
>

Is this package in a state where I can review sinit with it? It would be
good if someone can comment on sinit too, as I commented on musl in
general there too.

-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: [PATCH] gnu: libextractor: Update inputs.

[ng0]

Andreas Enge  writes:

> On Fri, Aug 05, 2016 at 08:42:46PM +, ng0 wrote:
>> This is weird. I ran this 2 days ago with no failing tests.
>> I'll see if I had an update I did not post.
>
> This could also be a sign of non-determinism. As posted two days ago,
> I had packages that failed on hydra, but built correctly locally.
> Sometimes there are also race conditions between different tests;
> adding "#:parallel-tests? #f" can be an option then.
>
> Andreas
>

With #:parallel-tests? #f

ng0@shadowwalker ~/src/guix/guix-libextractor$ ./pre-inst-env guix build 
--rounds=15 libextractor
/gnu/store/92wafrh7wfyzpdd89m38xsgq90qrybkn-libextractor-1.3


All 28 tests succeed.

Without it, the default:

@ build-succeeded
/gnu/store/c96r9pj4i1i95c5j35vl9nsrahj9xclg-libextractor-1.3.drv -
/gnu/store/4slpl020cwyxdygvn2ra07fk0pla2ajn-libextractor-1.3
retrieving 1 files from '192.168.1.198'...
Cannot open display "default display"
importing file or directory
'/gnu/store/4slpl020cwyxdygvn2ra07fk0pla2ajn-libextractor-1.3'...
found valid signature for
'/gnu/store/4slpl020cwyxdygvn2ra07fk0pla2ajn-libextractor-1.3'
Cannot open display "default display"
done with offloaded
'/gnu/store/c96r9pj4i1i95c5j35vl9nsrahj9xclg-libextractor-1.3.drv'
/gnu/store/4slpl020cwyxdygvn2ra07fk0pla2ajn-libextractor-1.3

This just to check eventual limitations of offloading since I am new to
using it:

ng0@shadowwalker ~/src/guix/guix-libextractor$ ./pre-inst-env guix build 
--no-build-hook --rounds=15 libextractor
make  all-recursive
make[1]: Entering directory '/home/ng0/src/guix/guix-libextractor'
Making all in po/guix
make[2]: Entering directory
'/home/ng0/src/guix/guix-libextractor/po/guix'
make[2]: Leaving directory
'/home/ng0/src/guix/guix-libextractor/po/guix'
Making all in po/packages
make[2]: Entering directory
'/home/ng0/src/guix/guix-libextractor/po/packages'
make[2]: Leaving directory
'/home/ng0/src/guix/guix-libextractor/po/packages'
make[2]: Entering directory '/home/ng0/src/guix/guix-libextractor'
Compiling Scheme modules...
make[2]: Leaving directory '/home/ng0/src/guix/guix-libextractor'
make[1]: Leaving directory '/home/ng0/src/guix/guix-libextractor'
/gnu/store/4slpl020cwyxdygvn2ra07fk0pla2ajn-libextractor-1.3


So I'd say use this patch I append and see what hydra does with it in
many runs. I can not reproduce your error here, but with parallel-tests
off, this can be addressed as a start. Later we should look at why it's
behaving like this and either patch here or upstream.

From 49cffb1882131710d58ae90aee1a9274c80a6183 Mon Sep 17 00:00:00 2001
From: ng0 
Date: Wed, 3 Aug 2016 13:42:27 +
Subject: [PATCH] gnu: libextractor: Add inputs.

* gnu/packages/gnunet.scm (libextractor)[inputs]: Add gtk+, libarchive,
libgsf, libmpeg2.
* [arguments](configure-flags): Add flag to configure with libltdl.
---
 gnu/packages/gnunet.scm | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 4d888bd..9afb461 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -50,6 +50,7 @@
   #:use-module (gnu packages tls)
   #:use-module (gnu packages video)
   #:use-module (gnu packages xiph)
+  #:use-module (gnu packages backup)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
@@ -81,17 +82,12 @@
;; FIXME:
;; The following dependencies are all optional, but should be
;; available for maximum coverage:
-   ;; * libarchive
-   ;; * libgif (giflib)
-   ;; * libgtk+ >= 3.0.0 (may probably drop glib then as a propagated input of
-   ;; gtk)
-   ;; * libgsf
;; * libmagic (file)
-   ;; * libmpeg2
-   ;; * libmp4v2
-   ;; * librpm
-   ;; * libsmf
-   ;; * libtidy
+   ;; * libmp4v2; package it
+   ;; * librpm  ; package it
+   ;; * libsmf  ; package it
+   ;; * libtidy ; package it
+   ;; * libgif (giflib) ; investigate failure
(inputs
 `(("exiv2" ,exiv2)
   ("flac" ,flac)
@@ -100,14 +96,23 @@
   ("glib" ,glib)
   ("gstreamer" ,gstreamer)
   ("gst-plugins-base" ,gst-plugins-base)
+  ("gtk+" ,gtk+)
+  ("libarchive" ,libarchive)
+  ("libgsf" ,libgsf)
   ("libjpeg" ,libjpeg)
+  ("libltdl" ,libltdl)
+  ("libmpeg2" ,libmpeg2)
   ("libogg" ,libogg)
   ("libtiff" ,libtiff)
-  ("libltdl" ,libltdl)
   ("libvorbis" ,libvorbis)
   ("zlib" ,zlib)))
(native-inputs
-  `(("pkg-config" ,pkg-config)))
+`(("pkg-config" ,pkg-config)))
+   (arguments
+`(#:configure-flags
+  (list (string-append "--with-ltdl="
+   (assoc-ref %build-inputs "libltdl")))
+  #:parallel-tests? #f))
(synopsis "Library to extract meta-data from media files")
(description
 "GNU libextractor is a library for extracting metadata from files.  It
-- 
2.9.2


-- 
♥Ⓐ  ng0
Current Keys: 

Re: Tor Browser

[ng0]

Hi,

in the following reply I assume that you did not read all of the
original thread[0]. If I am wrong, correct me.

Alex Vong  writes:

> ng0  writes:
>
>> Ludovic Courtès  writes:
>>
>>> n...@we.make.ritual.n0.is skribis:
>>>
 Ludovic Courtès writes:
>>>
>>> [...]
>>>
> I suppose TB contains a script that does all that, right?  Would it work
> to simply run it?  If it invokes wget/curl, then this needs to be
> replaced, but the rest should be fine.

 It's not that easy I'm afraid.
 Currently they use a gitian build, as described in this README[0],
 which the person maintaining the torbrowser ebuild for Gentoo out
 of portage replicates and follows in parts.
 It can't be followed completely, as `builders/tor-browser-bundle'
 requires a checkout of gitian of the torproject.org

 So we have to look at what they do and recreate this build
 procedure, there's no individual Makefile, the releases are
 created in VMs.

 Dependencies are kept up to date here[1].

 This[2] is the script connecting/using gitian for gnu-linux releases.

 The Makefile just runs the corresponding scripts.
>>>
>>> Gitian is about building binaries.  There must be some script somewhere
>>> to apply the relevant patches to the source first, before one builds it,
>>> no?
>>>
> It’s unfortunate that there’s no ready-to-build TB tarball, that would
> simplify things for us.

 Yes.. But I think icecat suffers from the same problem, only that
 icecat tarballs/binaries are built using a bash script applying
 all that's needed to the firefox sources again.
>>>
>>> IceCat publishes source tarballs that, AIUI, are produced essentially by
>>> running a script that patches Firefox’s code base (same approach for
>>> Linux-libre.)
>>>
>>> Thanks,
>>> Ludo’.
>>
>> There are the .mar files, which I suppose are the built source of
>> torbrowser, but I can't tell for sure since i can't find an upstream for
>> mar-tools. I guess it is Mozilla, but where is it available?
>>
>> https://dist.torproject.org/torbrowser/6.0.3/
>
> Hi, I am a tor browser and torsocks user (since a few months ago). Last
> time I tried building tor browser from source (and failed), gitian will
> have to download some non-free xcode stuff to build for the os x
> platform. Is it possible to only build for gnu/linux without building
> for windows and os x? Will the resulting binary still be byte-to-byte
> identical with the tor project official build?

Was this a build with a guix package? Can you share the code if it is?

> Also, it seems tor browser needs virtualenv and virtualbox to
> build. Last time I checked virtualbox, it was on the contrib area of
> debian since it requires a non-free[1] compiler to build the bios[2].
> I hope we can find way around these issues since tor browser is IMHO an
> essential tool nowadays.

You might want to re-read the full thread this message is part of. I
already wrote that with the builds I use for torbrowser in Gentoo, that
at least virtualbox is not needed and Ludovic said that the gitian build
is not what we should be looking into. It is mostly poncho's work on
Gentoo, but the overlay I contribute to mirrors their work. There we
don't use gitian but a combination of torbrowser source + firefox source
and distro specific patches.


We could also address tor with this when we succeed, as they have an
interest in NixOS or they are looking into it, specifically hydra for
builds: https://trac.torproject.org/projects/tor/ticket/12520

> Finally, I agree that icecat could switch to tor browser as its upstream.

Maybe you want to help me out with writing the email / post to
torproject:
https://lists.gnu.org/archive/html/guix-devel/2016-08/msg00326.html

On second note, maybe this is message should be addressed to both
torproject and icecat developer(s). What do you think? I have no fixed
plan in mind for this.

[0]: 
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=torbrowser=Search=guix-devel
>
> [1]: https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License
> [2]: https://wiki.debian.org/VirtualBox

-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: [PATCH 3/5] gnu: qemu: Enable spice support.

[David Craven]

> Trying to build with guix build --system=armhf-linux tells me that I'm
> x86-64-linux and the same for --system=mipsel-linux. It would be
> nice if guix build would spin up a qemu instance in this case. It will
> take me a while to test.

Before reinventing the wheel or deploying my own hydra build farm
(or cuirass), is there a simple way to build a package for all supported
platforms?

> If supported-systems is set correctly, will guix try to build without
> the required package? This is useful in case the dependency is
> only optional.

It looks like guix ignores the supported-systems property and
doesn't make use of it anywhere. Say it doesn't prevent building
a package on i686-linux when only x86_64-linux is in the list.

Re: [GSoC] Continuous integration tool à la Hydra.

[David Craven]

Hi Mathieu,

Are you already working on a package/service for guix?

I'd like to deploy it to my server to avoid silly mistakes
like in my last two pushes to master...

Does it rebuild from commit individually or only HEAD?
This would be nice to check for rebase mistakes where
HEAD builds but a commit doesn't.

Does it already support building packages for all guix
supported systems?

```
(define (local-file file)
;; In the common case jobs will be defined relative to the repository.
;; However for testing purpose use local gnu-system.scm instead.
(string-append (dirname (current-filename)) "/" file))
(define hello-master
`((#:name . "guix")
(#:url . "git://git.savannah.gnu.org/guix.git")
(#:load-path . ".")
(#:file . ,(local-file "gnu-system.scm"))
(#:proc . hydra-jobs)
(#:arguments (subset . "hello"))
(#:branch . "master")))
(list hello-master)
```

Can I also define custom jobs like running guix --rounds=2 and
guix lint?

Thank you,
David

[PATCH 5/5] gnu: gnome-themes-standard: Don't install 'icon-theme.cache'.

[宋文武]

* gnu/packages/gnome.scm (gnome-themes-standard)[arguments]: New field.
---
 gnu/packages/gnome.scm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 78827eb..0258e28 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -1673,6 +1673,12 @@ engineering.")
 (base32
  "1p1vvmzfky1ax3yv9ld10xgqwydhmglxpgq3skrfc4539nrq9phw"
 (build-system gnu-build-system)
+(arguments
+ '(#:configure-flags
+   ;; Don't create 'icon-theme.cache'.
+   (let* ((coreutils (assoc-ref %build-inputs "coreutils"))
+  (true  (string-append coreutils "/bin/true")))
+ (list (string-append "GTK_UPDATE_ICON_CACHE=" true)
 (inputs
  `(("gtk+" ,gtk+)
("gtk+-2" ,gtk+-2)
-- 
2.8.4

[PATCH 4/5] gnu: gnome-icon-theme, adwaita-icon-theme: Don't install 'icon-theme.cache'.

[宋文武]

* gnu/packages/gnome.scm (gnome-icon-theme)[native-inputs]: Remove 'gtk+'.
[arguments]: Set 'GTK_UPDATE_ICON_CACHE' to the path of 'true'.
(adwaita-icon-theme)[native-inputs]: Add 'gtk+:bin'.
---
 gnu/packages/gnome.scm | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 8be68ab..78827eb 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -645,9 +645,14 @@ update-desktop-database: updates the database containing a 
cache of MIME types
(base32
 "0fjh9qmmgj34zlgxb09231ld7khys562qxbpsjlaplq2j85p57im"
 (build-system gnu-build-system)
+(arguments
+ '(#:configure-flags
+   ;; Don't create 'icon-theme.cache'.
+   (let* ((coreutils (assoc-ref %build-inputs "coreutils"))
+  (true  (string-append coreutils "/bin/true")))
+ (list (string-append "GTK_UPDATE_ICON_CACHE=" true)
 (native-inputs
- `(("gtk+" ,gtk+) ; for gtk-update-icon-cache
-   ("icon-naming-utils" ,icon-naming-utils)
+ `(("icon-naming-utils" ,icon-naming-utils)
("intltool" ,intltool)
("pkg-config" ,pkg-config)))
 (home-page "http://art.gnome.org/;)
@@ -669,7 +674,9 @@ update-desktop-database: updates the database containing a 
cache of MIME types
   name "-" version ".tar.xz"))
   (sha256
(base32
-"0ddfwwqx8s63qbqimmbb015lqsab4s0rvy1j81jdsh7k95rqh2ks"))
+"0ddfwwqx8s63qbqimmbb015lqsab4s0rvy1j81jdsh7k95rqh2ks"
+(native-inputs
+ `(("gtk-encode-symbolic-svg" ,gtk+ "bin")
 
 (define-public shared-mime-info
   (package
-- 
2.8.4

[PATCH 3/5] gnu: evince: Don't install 'icon-theme.cache'.

[宋文武]

* gnu/packages/gnome.scm (evince)[arguments]: Add 'skip-gtk-update-icon-cache'
phase.
---
 gnu/packages/gnome.scm | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 2038f8f..8be68ab 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -480,7 +480,15 @@ forgotten when the session ends.")
;; FIXME: Tests fail with:
;;   ImportError: No module named gi.repository
;; Where should that module come from?
-   #:tests? #f))
+   #:tests? #f
+   #:phases
+   (modify-phases %standard-phases
+ (add-before 'install 'skip-gtk-update-icon-cache
+   ;; Don't create 'icon-theme.cache'.
+   (lambda _
+ (substitute* "data/Makefile"
+   (("gtk-update-icon-cache") "true"))
+ #t)
 (inputs
  `(("libspectre" ,libspectre)
("djvulibre" ,djvulibre)
-- 
2.8.4

[PATCH 2/5] profiles: gtk-icon-themes: Use 'gtk-update-icon-cache' from 'gtk+:bin'.

[宋文武]

* guix/profiles.scm (gtk-icon-themes): Use 'gtk-update-icon-cacnhe' from
the "bin" output of gtk+ package.
---
 guix/profiles.scm | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/guix/profiles.scm b/guix/profiles.scm
index db807a8..9c2dbba 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -642,7 +642,18 @@ MANIFEST.  Single-file bundles are required by programs 
such as Git and Lynx."
 (define (gtk-icon-themes manifest)
   "Return a derivation that unions all icon themes from manifest entries and
 creates the GTK+ 'icon-theme.cache' file for each theme."
-  (mlet %store-monad ((gtk+ (manifest-lookup-package manifest "gtk+")))
+  (define gtk+  ; lazy reference
+(module-ref (resolve-interface '(gnu packages gtk)) 'gtk+))
+
+  (mlet %store-monad ((%gtk+ (manifest-lookup-package manifest "gtk+"))
+  ;; XXX: Can't use gtk-update-icon-cache corresponding
+  ;; to the gtk+ referenced by 'manifest'.  Because
+  ;; '%gtk+' can be either a package or store path, and
+  ;; there's no way to get the "bin" output for the later.
+  (gtk-update-icon-cache
+   -> #~(string-append #+gtk+:bin
+   "/bin/gtk-update-icon-cache")))
+
 (define build
   (with-imported-modules '((guix build utils)
(guix build union)
@@ -659,9 +670,7 @@ creates the GTK+ 'icon-theme.cache' file for each theme."
 (let* ((destdir  (string-append #$output "/share/icons"))
(icondirs (filter file-exists?
  (map (cut string-append <> "/share/icons")
-  '#$(manifest-inputs manifest
-   (update-icon-cache (string-append
-   #+gtk+ "/bin/gtk-update-icon-cache")))
+  '#$(manifest-inputs manifest)
 
   ;; Union all the icons.
   (mkdir-p (string-append #$output "/share"))
@@ -676,11 +685,11 @@ creates the GTK+ 'icon-theme.cache' file for each theme."
;; "abiword_48.png".  Ignore these.
(when (file-is-directory? dir)
  (ensure-writable-directory dir)
- (system* update-icon-cache "-t" dir "--quiet"
+ (system* #+gtk-update-icon-cache "-t" dir "--quiet"
(scandir destdir (negate (cut member <> '("." "..")
 
 ;; Don't run the hook when there's nothing to do.
-(if gtk+
+(if %gtk+
 (gexp->derivation "gtk-icon-themes" build
   #:local-build? #t
   #:substitutable? #f)
-- 
2.8.4

[PATCH 1/5] gnu: gtk+: Add "bin" output.

[宋文武]

* gnu/packages/gtk.scm (gtk+)[outputs]: New field.
---
 gnu/packages/gtk.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index 21365b9..5c42053 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -624,6 +624,7 @@ application suites.")
  (base32
   "157nh9gg0p2avw765hrnkvr8lsh2w811397yxgjv6q5j4fzz6d1q"))
 (patches (search-patches "gtk3-respect-GUIX_GTK3_PATH.patch"
+   (outputs '("out" "bin" "doc"))
(propagated-inputs
 `(("at-spi2-atk" ,at-spi2-atk)
   ("atk" ,atk)
-- 
2.8.4

Re: [PATCH 5/5] services: Add spice vdagent service.

[David Craven]

> Usually we ask for about one week to pass before merging without
> comment.  Otherwise there’s just not enough time for reviewers to look
> over the patches.

Thank you for the information!

In case you are referring to the 'enable spice in qemu patch', it was first
submitted 2016/07/29. But I should have tested it on all platforms we
support.

Ludo already reviewed the spice-vdagent-service and I thought
that the changes he wanted me to make were minor corrections.

I guess I am trigger happy, if there is a trigger somewhere I'll pull
it =P

David

Re: [PATCH 3/5] gnu: qemu: Enable spice support.

[David Craven]

> Unfortunately, 'spice' only builds successfully on x86_64, so with this
> patch, i686 and armhf lose 'qemu'.

'usbredir' is needed by 'spice-gtk' which is only needed to run the tests
for spice. This can be fixed by removing the automated tests configure-flag
and removing spice-gtk from the dependencies on i686.

If supported-systems is set correctly, will guix try to build without
the required
package? This is useful in case the dependency is only optional.

Trying to build with guix build --system=armhf-linux tells me that I'm
x86-64-linux and the same for --system=mipsel-linux. It would be
nice if guix build would spin up a qemu instance in this case. It will
take me a while to test.

Re: ‘core-updates’ merge is a squashed commit

[Andreas Enge]

On Fri, Aug 05, 2016 at 08:59:32PM -0400, Mark H Weaver wrote:
> I haven't thought deeply on this, but it seems to me that Andy's
> suggestion has a lot of merit.  We could choose to decide, as a matter
> of policy, that if you sign a commit with unsigned ancestor commit(s),
> you are effectively vouching for those ancestor commits.  We could
> modify the commit hook to accept a push as long as the new HEAD commit
> is signed by an authorized key, disregarding the ancestors.
> 
> There's one thing that each of us would need to be careful of, though.
> If we adopt this policy, then before signing a commit, we'd need to
> first verify that the parent commit has been signed, lest we
> accidentally vouch for an unsigned commit that we know nothing about.

I am not very happy about such a policy; if I sign a commit, I am only
signing my commit, and not all of its history, or even only its history
up to the previous signed commit. Also, while signing each commit is
a simple git configuration option, needing to verify the history before
each commit would be a hassle that as far as I can see is not easily
automated.

> In practice, this could only happen if Savannah is compromised or
> there's a man-in-the-middle attack, because Savannah is supposed to
> ensure that pushes with unsigned HEADs are rejected.

Agreed, this mitigates the problem above. But I feel better with the
current situation.

Andreas

Re: [PATCH 5/5] services: Add spice vdagent service.

[Ricardo Wurmus]

David Craven  writes:

> No comment means these patches are ok to merge?

Usually we ask for about one week to pass before merging without
comment.  Otherwise there’s just not enough time for reviewers to look
over the patches.

~~ Ricardo