bug#43893: [PATCH v2] maint: update-guix-package: Prevent accidentally breaking guix pull.

[Maxim Cournoyer]

Hello Marius,

And thanks for the review!

[...]

>> +(define (git-add-worktree directory commit-ish)
>> +  "Create a new git worktree at DIRECTORY, detached on commit COMMIT-ISH."
>> +  (invoke "git" "worktree" "add" "--detach" directory commit-ish))
>
> Is it feasible to use Guile-Git here (given appropriate bindings)?

I had a cursory look at the guile-git sources, and it seems to miss at
least bindings for manipulating worktrees, and I'm not sure how we could
get a list of all the remotes and check their URLs to find the remote
used to push to Savannah.  Supposing we'd be able to get that remote, I
also don't know how we could query if its master branch contains a given
commit (I imagine it's doable, but it's not documented so it takes time
to figure it out :-).

[...]

>> -  (string-append (getcwd) "/" root))
>> +(define (commit-already-pushed? remote commit)
>> +  "True if COMMIT is found in the REMOTE repository."
>> +  (not (string-null? (with-input-pipe-to-string
>> +  "git" "branch" "-r" "--contains" commit
>> +  (string-append remote "/master")
>
> ...because parsing git CLI output is error-prone and "ugly" (IMO).  But
> not a strong opinion.

I agree; but for the time being we don't have an another option.  I'd be
happy to be proven wrong.

[...]

>> + (lambda ()
>> +   (invoke "git" "worktree" "prune")
>
> This is not great, because users (well, developers who run this script)
> may have worktrees that are temporarily inaccessible (e.g. on a USB
> drive or whatever).  Better to just leave the stale reference instead of
> potentially destroying users worktrees.

That's a good point.  I've improved the cleanup in v3 to only remove the
worktree it creates and no other.

> Perhaps the script could 'git clone --maxdepth=1' instead of creating
> a worktree?

I think you meant something like:

--8<---cut here---start->8---
$ git clone --branch the-branch --depth -1 %top-srcdir
--8<---cut here---end--->8---

That could work, but it's about 2x slower and more expensive than
creating a worktree (15975 syscalls vs 647, according to 'strace -c').

Thank you,

Maxim

bug#43893: [PATCH v3] maint: update-guix-package: Prevent accidentally breaking guix pull.

[Maxim Cournoyer]

Fixes .

This changes the 'update-guix-package' tool so that it:

1. Always uses a clean checkout to compute the hash of the updated 'guix'
package.
2. Ensures the commit used in the updated 'guix' package definition has already
been pushed upstream.

* build-aux/update-guix-package.scm (%savannah-guix-git-repo-push-url): New
variable.
(with-input-pipe-to-string, with-temporary-git-worktree): New syntaxes.
(find-origin-remote, git-add-worktree): New procedures.
(commit-already-pushed?): New predicate.
(main): Check the commit used has already been pushed upstream and compute the
hash from a clean checkout.
* doc/contributing.texi (Updating the Guix Package): Document it.
* .dir-locals.el (scheme-mode): Fix indentation of with-temporary-git-worktree.
---
 .dir-locals.el|  1 +
 build-aux/update-guix-package.scm | 98 +--
 doc/contributing.texi | 43 ++
 3 files changed, 112 insertions(+), 30 deletions(-)

diff --git a/.dir-locals.el b/.dir-locals.el
index 7f310d2612..19f15b3e1a 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -103,6 +103,7 @@
(eval . (put 'call-with-progress-reporter 'scheme-indent-function 1))
(eval . (put 'with-repository 'scheme-indent-function 2))
(eval . (put 'with-temporary-git-repository 'scheme-indent-function 2))
+   (eval . (put 'with-temporary-git-worktree 'scheme-indent-function 2))
(eval . (put 'with-environment-variables 'scheme-indent-function 1))
(eval . (put 'with-fresh-gnupg-setup 'scheme-indent-function 1))
 
diff --git a/build-aux/update-guix-package.scm 
b/build-aux/update-guix-package.scm
index f695e91cfd..9b03b06c7c 100644
--- a/build-aux/update-guix-package.scm
+++ b/build-aux/update-guix-package.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright ?? 2017, 2018 Ludovic Court??s 
+;;; Copyright ?? 2020 Maxim Cournoyer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -24,13 +25,20 @@
 ;;; Code:
 
 (use-modules (guix)
+ (guix ui)
  (guix git-download)
  (guix upstream)
  (guix utils)
  (guix base32)
  (guix build utils)
+ (guix scripts hash)
  (gnu packages package-management)
- (ice-9 match))
+ (ice-9 match)
+ (ice-9 popen)
+ (ice-9 textual-ports)
+ (srfi srfi-1)
+ (srfi srfi-2)
+ (srfi srfi-26))
 
 (define %top-srcdir
   (string-append (current-source-directory) "/.."))
@@ -101,44 +109,74 @@ COMMIT."
   (exp
(error "'guix' package definition is not as expected" exp)
 
+(define (git-add-worktree directory commit)
+  "Create a new git worktree at DIRECTORY, detached on commit COMMIT."
+  (invoke "git" "worktree" "add" "--detach" directory commit))
+
+(define-syntax-rule (with-temporary-git-worktree commit body ...)
+  "Execute BODY in the context of a temporary git worktree created from 
COMMIT."
+  (call-with-temporary-directory
+   (lambda (tmp-directory)
+ (dynamic-wind
+   (lambda ()
+ #t)
+   (lambda ()
+ (git-add-worktree tmp-directory commit)
+ (with-directory-excursion tmp-directory body ...))
+   (lambda ()
+ (invoke "git" "worktree" "remove" "--force" tmp-directory))
+
+(define %savannah-guix-git-repo-push-url
+  "git.savannah.gnu.org/srv/git/guix.git")
+
+(define-syntax-rule (with-input-pipe-to-string prog arg ...)
+  (let* ((input-pipe (open-pipe* OPEN_READ prog arg ...))
+(output (get-string-all input-pipe))
+(exit-val (status:exit-val (close-pipe input-pipe
+(unless (zero? exit-val)
+  (error (format #f "Command ~s exited with non-zero exit status: ~s"
+ (string-join (list prog arg ...)) exit-val)))
+(string-trim-both output)))
+
+(define (find-origin-remote)
+  "Find the name of the git remote with the Savannah Guix git repo URL."
+  (and-let* ((remotes (string-split (with-input-pipe-to-string
+ "git" "remote" "-v")
+#\newline))
+ (origin-entry (find (cut string-contains <>
+  (string-append
+   %savannah-guix-git-repo-push-url
+   " (push)"))
+ remotes)))
+(first (string-split origin-entry #\tab
+
+(define (commit-already-pushed? remote commit)
+  "True if COMMIT is found in the REMOTE repository."
+  (not (string-null? (with-input-pipe-to-string
+  "git" "branch" "-r" "--contains" commit
+  (string-append remote "/master")
+
 
 (define (main . args)
   (match args
 ((commit version)
- (with-store store
-   (let* ((source   (add-to-store store
-  "guix-checkout" ;dummy name
-  

bug#43984: `--with-graft=...` doesn't work with packages of different length name/version

[pkill9]

As expected, if you attempt to graft a package's dependency, and it's
name + version is different length to the original dependency, then it
will fail to graft.

Maybe if the length/version is different, then a symlink could be
created in the store pointing to the new dependency, with a
name/version that matches the length of the original dependency's store
name? Perhaps this new name/version could be something like
/gnu/store/...-original-dependency-name-gg, where 'g..' matches the
length of the version of the original dependency. The many 'g's would
make it clear that it is a graft. Then if someone looks in the store,
they would see it's a symlink too.

bug#40832: alsa-lib cannot find its plugins

[Leo Famulari]

Upstream has implemented (but not yet released) a potential solution:

https://github.com/alsa-project/alsa-lib/commit/8580c081c25678d11278efcb61bd15cf44d0a225

I haven't tested it yet but my understanding is that it supports
specifying a single plugin directory via the ALSA_PLUGIN_DIR environment
variable.


signature.asc
Description: PGP signature

bug#43893: [PATCH v2] maint: update-guix-package: Prevent accidentally breaking guix pull.

[Marius Bakke]

Maxim Cournoyer  writes:

> Fixes .
>
> This changes the 'update-guix-package' tool so that it:
>
> 1. Always uses a clean checkout to compute the hash of the updated 'guix'
> package.
> 2. Ensures the commit used in the updated 'guix' package definition has 
> already
> been pushed upstream.
>
> * build-aux/update-guix-package.scm (%savannah-guix-git-repo-push-url): New
> variable.
> (with-input-pipe-to-string): New syntax.
> (find-origin-remote, git-add-worktree): New procedures.
> (commit-already-pushed?): New predicate.
> (main): Check the commit used has already been pushed upstream and compute the
> hash from a clean checkout.
> * doc/contributing.texi (Updating the Guix Package): Document it.

[...]
  
>  (define %top-srcdir
>(string-append (current-source-directory) "/.."))
> @@ -101,44 +109,69 @@ COMMIT."
>(exp
> (error "'guix' package definition is not as expected" exp)
>  
> -
> -(define (main . args)
> -  (match args
> -((commit version)
> - (with-store store
> -   (let* ((source   (add-to-store store
> -  "guix-checkout" ;dummy name
> -  #t "sha256" %top-srcdir
> -  #:select? version-controlled?))
> -  (hash (query-path-hash store source))
> -  (location (package-definition-location))
> -  (old-hash (content-hash-value
> -  (origin-hash (package-source guix)
> - (edit-expression location
> -  (update-definition commit hash
> - #:old-hash old-hash
> - #:version version))
> +(define (git-add-worktree directory commit-ish)
> +  "Create a new git worktree at DIRECTORY, detached on commit COMMIT-ISH."
> +  (invoke "git" "worktree" "add" "--detach" directory commit-ish))

Is it feasible to use Guile-Git here (given appropriate bindings)?

> +(define %savannah-guix-git-repo-push-url
> +  "git.savannah.gnu.org/srv/git/guix.git")
>  
> - ;; Re-add SOURCE to the store, but this time under the real name 
> used
> - ;; in the 'origin'.  This allows us to build the package without
> - ;; having to make a real checkout; thus, it also works when working
> - ;; on a private branch.
> - (reload-module
> -  (resolve-module '(gnu packages package-management)))
> +(define-syntax-rule (with-input-pipe-to-string prog arg ...)
> +  (let* ((input-pipe (open-pipe* OPEN_READ prog arg ...))
> +  (output (get-string-all input-pipe))
> +  (exit-val (status:exit-val (close-pipe input-pipe
> +(unless (zero? exit-val)
> +  (error (format #f "Command ~s exited with non-zero exit status: ~s"
> + (string-join (list prog arg ...)) exit-val)))
> +(string-trim-both output)))
>  
> - (let* ((source (add-to-store store
> -  (origin-file-name (package-source 
> guix))
> -  #t "sha256" source))
> -(root   (store-path-package-name source)))
> +(define (find-origin-remote)
> +  "Find the name of the git remote with the Savannah Guix git repo URL."
> +  (and-let* ((remotes (string-split (with-input-pipe-to-string
> + "git" "remote" "-v")
> +#\newline))
> + (origin-entry (find (cut string-contains <>
> +  (string-append
> +   %savannah-guix-git-repo-push-url
> +   " (push)"))
> + remotes)))
> +(first (string-split origin-entry #\tab
>  
> -   ;; Add an indirect GC root for SOURCE in the current directory.
> -   (false-if-exception (delete-file root))
> -   (symlink source root)
> -   (add-indirect-root store
> -  (string-append (getcwd) "/" root))
> +(define (commit-already-pushed? remote commit)
> +  "True if COMMIT is found in the REMOTE repository."
> +  (not (string-null? (with-input-pipe-to-string
> +  "git" "branch" "-r" "--contains" commit
> +  (string-append remote "/master")

...because parsing git CLI output is error-prone and "ugly" (IMO).  But
not a strong opinion.

> -   (format #t "source code for commit ~a: ~a (GC root: ~a)~%"
> -   commit source root)
> +
> +(define (main . args)
> +  (match args
> +((commit version)
> + (with-directory-excursion %top-srcdir
> +   (or (getenv "GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT")
> +   (commit-already-pushed? (find-origin-remote) commit)
> +   (leave (G_ "Commit ~a is not pushed upstream.  Aborting.~%") 
> commit))
> +   (dynamic-wind
> + (lambda 

bug#43721: Package 'dune' (ocaml) is not Reproducible

[Julien Lepiller]

Le 13 octobre 2020 11:41:32 GMT-04:00, zimoun  a 
écrit :
>On Tue, 13 Oct 2020 at 17:29, Julien Lepiller 
>wrote:
>
>> Yes, the differences look very similar between these two issues. I've
>posted a bug report at https://github.com/ocaml/dune/issues/3863.
>Hopefully this will result in a good fix. As a workaround, building
>with one thread seems to be effective, but we need to change the
>dune-build-system for that.
>
>Which means core-updates, right?

We don't have more than 300 dependents, so I think it should be master.

bug#43721: Package 'dune' (ocaml) is not Reproducible

[zimoun]

On Tue, 13 Oct 2020 at 17:29, Julien Lepiller  wrote:

> Yes, the differences look very similar between these two issues. I've posted 
> a bug report at https://github.com/ocaml/dune/issues/3863. Hopefully this 
> will result in a good fix. As a workaround, building with one thread seems to 
> be effective, but we need to change the dune-build-system for that.

Which means core-updates, right?

bug#43721: Package 'dune' (ocaml) is not Reproducible

[Julien Lepiller]

Le 13 octobre 2020 08:17:10 GMT-04:00, zimoun  a 
écrit :
>Dear,
>
>On Wed, 30 Sep 2020 at 14:42, Julien Lepiller 
>wrote:
>
>>> --8<---cut here---start->8---
>>> Binary files
>>>
>/gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3/lib/ocaml/site-lib/dune/configurator/configurator.cma
>>> and
>>>
>/gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3-check/lib/ocaml/site-lib/dune/configurator/configurator.cma
>>> differ Binary files
>>>
>/gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3/lib/ocaml/site-lib/dune/configurator/configurator__Extract_obj.cmt
>>> and
>>>
>/gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3-check/lib/ocaml/site-lib/dune/configurator/configurator__Extract_obj.cmt
>>> differ Binary files
>>>
>/gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3/lib/ocaml/site-lib/dune/configurator/configurator__V1.cmti
>>> and
>>>
>/gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3-check/lib/ocaml/site-lib/dune/configurator/configurator__V1.cmti
>>> differ
>
>[...]
>
>> The difference seems to be bigger than a simple timestamp, but it's
>all
>> on binary files, and diffoscope is not very useful for that. Maybe
>file
>> system ordering? I'm investigating.
>
>Is it not related to your detailed analysis:
>
>   

Yes, the differences look very similar between these two issues. I've posted a 
bug report at https://github.com/ocaml/dune/issues/3863. Hopefully this will 
result in a good fix. As a workaround, building with one thread seems to be 
effective, but we need to change the dune-build-system for that.

>
>BTW, the update of “dune“ #43745 seems fixing the issue.

Yes indeed :) nice side-effect.

>
>
>All the best,
>simon

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

bug#18698: Our WindowMaker wrapper pollutes PATH in the entire X session

[Maxim Cournoyer]

Hello,

Mark H Weaver  writes:

> We install a wrapper script around WindowMaker that prepends
> /gnu/store/XXX-windowmaker-XXX/bin to $PATH.  This setting is propagated
> to all subprocesses in the entire X session, which is suboptimal.  It
> would be nice to find another solution, preferably by using absolute
> pathnames when launching subprocesses run by WindowMaker.
>
>   Mark

I tested with the following modifications to our lightweight-desktop
template:

--8<---cut here---start->8---
modified   gnu/system/examples/lightweight-desktop.tmpl
@@ -2,6 +2,7 @@
 ;; for a "desktop" setup without full-blown desktop
 ;; environments.

+(use-modules (gnu packages gnustep))
 (use-modules (gnu) (gnu system nss))
 (use-service-modules desktop)
 (use-package-modules bootloaders certs ratpoison suckless wm xorg)
@@ -42,7 +43,7 @@
   ;; the log-in screen with F1.
   (packages (append (list
  ;; window managers
- ratpoison i3-wm i3status dmenu
+ windowmaker
  ;; terminal emulator
  xterm
  ;; for HTTPS access
--8<---cut here---end--->8---

And I cannot reproduce this.  I believe the fix Ludo did 6 years ago in
be05e643ae4d62dc25aa88b7fbdb0eae9cf10eb0 combined with the use of a
xsession file added in commit 537fe4568f4 by Kei resolved this issue for
good.

Closing.

Thanks,

Maxim

bug#24288: gnome-maps fails

[Maxim Cournoyer]

Hello Ricardo,

Ricardo Wurmus  writes:

> I just installed “gnome-maps” and tried to start it with disappointing
> results:
>
> 
> $ gnome-maps 
>
> (org.gnome.Maps:5547): GLib-GIO-ERROR **: Settings schema 
> 'org.gnome.desktop.interface' is not installed
>
> Trace/breakpoint trap
> 
>
> I’m not using GNOME but Xfce.

Seems you fixed this yourself 2 years ago with
8d26f48e8ab3802d73e74b18c877c549c4248eed :-).

Closing.

Thanks,

Maxim

bug#43843: git-annex is not Reproducible

[zimoun]

On Tue, 13 Oct 2020 at 15:06, Ludovic Courtès  wrote:

> You can always build with ‘--cores=1’, which will ensure both the build
> and test will run sequentially.

Yes but in this case, "guix challenge" would still complain, isn't it?

bug#24066: icecat "mailto" handler does not work - and cannot be reconfigured by user

[Maxim Cournoyer]

Hello Danny,

Danny Milosavljevic  writes:

[...]

> Checking the application preferences of icecat, it only gives "always
> ask" (note: it doesn't ask) and not an application for "mailto". (in
> GuixSD)

Testing in latest IceCat, there's a 'Use other...' entry in the mailto
applications configuration.  I also saw 'Emacs' in the list of potential
applications to open mailto URIs, tried it and it opened Emacs.

Does that work for you?

To get the applications recognized as supporting this URI scheme, they
must provide a .desktop file which mentions support for it, for example
via a MimeType=x-scheme-handler entry:

--8<---cut here---start->8---
$ grep -rin 'x-scheme-handler' $(guix build weechat)
/gnu/store/...-weechat-2.9/share/applications/weechat.desktop:17:MimeType=x-scheme-handler/irc;x-scheme-handler/ircs;--8<---cut
 here---end--->8---

This information gets compiled into a MIME database by a profile hook
under:

--8<---cut here---start->8---
$ grep 'x-scheme-handler/ircs' 
~/.guix-profile/share/applications/mimeinfo.cache 
x-scheme-handler/ircs=weechat.desktop;
--8<---cut here---end--->8---

And Icecat picks its up to show ircs:// URIs and shows the application
as registered for this type in its Applications settings view.

Maxim

bug#43843: git-annex is not Reproducible

[Ludovic Courtès]

zimoun  skribis:

> On Mon, 12 Oct 2020 at 12:34, Ricardo Wurmus  wrote:
>
>> > Does the parallel build save a lot of time and CPU?  If yes, maybe we
>> > could to provide a transformation for the expert, something like
>> > "haskell-build-system-with-parellel-build" which tweaks
>> > "PARALLEL-BUILD?", similarly to the recent "no tests".  WDYT?
>>
>> We shouldn’t compromise reproducibility for parallel builds.  Ideally we
>> would figure out what exactly causes the differences and fix that
>> instead of disabling parallel builds, but if that turns out to be too
>> difficult I think we should just revert this until we have a good fix.
>>
>> Perhaps something can be done by fixing the order of files somewhere.
>
> My proposal is for the expert and not at the CLI level.  Something
> like "(funky-name ghc-foo)" which returns a new package with
> PARALLEL-BUILD? turned to #t.  And the default should be #f.  WDYT?

You can always build with ‘--cores=1’, which will ensure both the build
and test will run sequentially.

Ludo’.

bug#43721: Package 'dune' (ocaml) is not Reproducible

[zimoun]

Dear,

On Wed, 30 Sep 2020 at 14:42, Julien Lepiller  wrote:

>> --8<---cut here---start->8---
>> Binary files
>> /gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3/lib/ocaml/site-lib/dune/configurator/configurator.cma
>> and
>> /gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3-check/lib/ocaml/site-lib/dune/configurator/configurator.cma
>> differ Binary files
>> /gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3/lib/ocaml/site-lib/dune/configurator/configurator__Extract_obj.cmt
>> and
>> /gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3-check/lib/ocaml/site-lib/dune/configurator/configurator__Extract_obj.cmt
>> differ Binary files
>> /gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3/lib/ocaml/site-lib/dune/configurator/configurator__V1.cmti
>> and
>> /gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3-check/lib/ocaml/site-lib/dune/configurator/configurator__V1.cmti
>> differ

[...]

> The difference seems to be bigger than a simple timestamp, but it's all
> on binary files, and diffoscope is not very useful for that. Maybe file
> system ordering? I'm investigating.

Is it not related to your detailed analysis:

   

BTW, the update of “dune“ #43745 seems fixing the issue.


All the best,
simon