Re: Guix search, colors and INSIDE_EMACS

[zimoun]

Hi Pierre,

On Mon, 17 Feb 2020 at 08:51, Pierre Neidhardt  wrote:
>
> Can we still do the following:
>
> - Leave colors when INSIDE_EMACS is set.

It is what I propose. But this a "bug" in the patches that I sent. The
'link' is turned off and the 'highlight' is still set on but the
display is without the bold face.

> - Disable pager hint and display all search results when INSIDE_EMACS is set.

I have never look at. But why not.


Cheers,
simon

Re: Port Guix to my Apple Aluminum PowerBook G4

[Efraim Flashner]

I've done a bit of work on the port and my two branches live here¹ and
here². On master I get as far as gcc-cross-boot0. Core-updates does much
better, getting to glibc-intermediate, where it fails to build since it
says it can't find nptl. Searching the Guix tree I see that there's some
references to nptl in (gnu packages commencement) and in a
glibc-2.29-git-updates.patch, so I'll take a look at that.


¹ https://gitlab.com/Efraim/guix/-/tree/ppc-master
² https://gitlab.com/Efraim/guix/-/tree/ppc-core-updates


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: New build system: copy-build-system

[Jesse Gibbons]

Hi Pierre,
On Fri, 2020-02-14 at 13:54 +0100, Pierre Neidhardt wrote:
>   Error verifying signature: Failed to execute gpg.
> I've just sent a patch: 39...@debbugs.gnu.org.
> 
> Ideally, it would need a bit more testing with a package that has
> subdirectories.
> Any good suggestion?
> 
Thank you for making this amazing time-saver!

Attached is an early version of a good candidate. It's a wrapper script
for clojure taken from from clojure's brew installer.

src/main/resources/clojure should be moved to bin/
src/main/resources/cl
j should be moved to bin/

doc/clojure.1 should be moved to share/man/

And unless there's a sufficient reason not to,
epl.html could be moved to share/doc/clojure-1.10.1/


Everything else could probably be ignored.

Since I'm patching one of the scripts to play better with guix, the
source will become a tarball. I would rather not worry about extracting
everything, moving some things, and deleting what is not used.

If your patches are pushed before you get this, I will make the package
myself. But it's a complex yet useful example of a package that would
be simpler with the copy-build-system, so you can check how easy it is
to change from trivial-build-system and test how well copy-build-system 
works with subdirectories.

-Jesse
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Alex Vong 
;;; Copyright © 2018 Pierre Neidhardt 
;;; Copyright © 2019 Tobias Geerinckx-Rice 
;;; Copyright © 2020 Ludovic Courtès 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .

(define-module (clojure)
  #:use-module (gnu packages)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix build-system ant)
  #:use-module (guix build-system clojure)
  #:use-module (guix build-system trivial)
  #:use-module (ice-9 match))

(define-public clojure-wrapper
   (package
(name "clojure-wrapper")
(version "1.10.1.507")
(source
 (origin
  (method git-fetch)
  (uri (git-reference
(url "https://github.com/clojure/brew-install.git;)
(commit version)))
  (file-name (git-file-name name version))
  (sha256
   (base32 "1zipz22pszv4vls4qhxkia8gm86s1wkahr0jdbqhc46mpd8n54fz"
(build-system trivial-build-system)
(arguments
 `(#:modules ((guix build utils))
   #:builder (begin
 (use-modules (guix build utils))
 (let* ((out (assoc-ref %outputs "out"))
(bin-dir (string-append out "/bin/"))
(source (assoc-ref %build-inputs "source"))
(script-dir
 (string-append source "/src/main/resources/"))
 (scripts '("clojure" "clj")))
   (mkdir out)
   (mkdir bin-dir)
   (map (lambda (script)
  (copy-file (string-append script-dir script)
 (string-append bin-dir script)))
scripts)
 
(synopsis "Clojure launch scripts")
(description "Scripts to launch clojure from the command line.
Without these scripts a user would need to run jar with the clojure jar's
location. Who would want to do that?")
(home-page "https://clojure.org/;)
(license license:epl1.0)))

Outreachy funding

[Gábor Boskovits]

Hello Guix,

This is my second letter on this subject. My question is still the
same, are we willing to provide funding for more than one Outreachy
intern?

Additional information:
1. We have 3 proposals listed.
2. We confirmed funding for 1 intern.
3. Funding per intern is 6500 USD.
4. I am aware that at least two people are interested in applying.

Should you need any more information please let me know.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

GNU Shepherd 0.7.0 released

[Ludovic Courtès]

We are pleased to announce the GNU Shepherd version 0.7.0, a bug-fix
release.

• About

  The GNU Daemon Shepherd or GNU Shepherd is a service manager written
  in Guile that looks after the herd of system services.  It provides a
  replacement for the service-managing capabilities of SysV-init (or any
  other init) with a dependency-based system with a convenient
  interface.  The GNU Shepherd may also be used by unprivileged users to
  manage per-user daemons (e.g., tor, privoxy, mcron, etc.)  It is
  written in Guile Scheme, and is configured and extended using Guile.

  The GNU Shepherd is developed jointly with the GNU Guix project; it is
  used as the init system of Guix, GNU’s advanced GNU/Linux distribution.

  https://www.gnu.org/software/shepherd/


• Download

  Here are the compressed sources and a GPG detached signature[*]:
https://ftp.gnu.org/gnu/shepherd/shepherd-0.7.0.tar.gz
https://ftp.gnu.org/gnu/shepherd/shepherd-0.7.0.tar.gz.sig

  Use a mirror for higher download bandwidth:
https://ftpmirror.gnu.org/shepherd/shepherd-0.7.0.tar.gz
https://ftpmirror.gnu.org/shepherd/shepherd-0.7.0.tar.gz.sig

  Here are the SHA1 and SHA256 checksums:

  43806f67e15e23d44b992367a0952da581ebfb74  shepherd-0.7.0.tar.gz
  fdbbacdd014313de463d566ba94b6d34b8e8325440f2bcb8154b7de441db431e  
shepherd-0.7.0.tar.gz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify shepherd-0.7.0.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver pool.sks-keyservers.net \
--recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

  and rerun the 'gpg --verify' command.

  This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.16.1
Makeinfo 6.7
Help2man 1.47.12


• Changes since version 0.6.1 (excerpt from the NEWS file)

  ** New crash handler allows shepherd as PID 1 to dump core on GNU/Linux
  ** (shepherd service) now exports ‘default-environment-variables’
  ** ‘make-forkexec-constructor’ no longer removes log file
  ** Disable reboot on ctrl-alt-del before loading the config file
 ()
  ** Exception handling adjusted for Guile 3.0.0

Please report bugs to bug-g...@gnu.org.
Join guix-devel@gnu.org and gnu-system-disc...@gnu.org for discussions.

Ludovic, on behalf of the Shepherd herd.


signature.asc
Description: PGP signature

Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.

[Bengt Richter]

Hi Marius,

On +2020-02-16 17:34:13 +0100, Marius Bakke wrote:
> Bengt Richter  writes:
> 
> > Hi Efraim,
> >
> > On +2020-02-16 16:55:17 +0200, Efraim Flashner wrote:
> >> On Sun, Feb 16, 2020 at 03:27:36PM +0100, Marius Bakke wrote:
> >> > guix-comm...@gnu.org writes:
> >> > 
> >> > > commit 481a0f1a7ceac666a011b28324220584ead07698
> >> > > Author: Efraim Flashner 
> >> > > AuthorDate: Thu Feb 13 10:54:29 2020 +0200
> >> > >
> >> > > build: gnu-build-system: Don't run configure during bootstrap.
> >> > > 
> >> > > * guix/build/gnu-build-system.scm (bootstrap): Add NOCONFIGURE
> >> > > environment variable before running bootstrap scripts.
> >> > 
> >> > [...]
> >> > 
> >> > > @@ -190,6 +190,7 @@ working directory."
> >> > >(if (executable-file? script)
> >> > >(begin
> >> > >  (patch-shebang script)
> >> > > +(setenv "NOCONFIGURE" "true")
> >> > >  (invoke script))
> >> > >(invoke "sh" script)))
> >> > >  (if (or (file-exists? "configure.ac")
> >> > 
> >> > Should we unset NOCONFIGURE afterwards?  Probably at least one package
> >> > uses this variable for something completely different...
> >> 
> >> It probably wouldn't hurt to unset it. I've never come across a package
> >> where that's been a problem but best not invite trouble.
> >>
> > With all due respect, I am not comfortable with this kind of rationale :) 
> >
> > If it's never been a problem, unsetting might hide a case where it _would_
> > cause a problem -- which IMO it would be better to find out about than not.
> 
> I'm not sure I follow.  The variable in question has only been used in a
> handful of packages[0].  Now we are adding it in nearly 10k packages.
>
Yow, I sure didn't mean to suggest that!
 
> Why would we want to know whether a package build process has a problem
> with that particular variable?
Debugging unexpected results?

I was reacting to
┌───┐
│ > >> > Should we unset NOCONFIGURE afterwards?  Probably at least one package 
│
│ > >> > uses this variable for something completely different...   
│
│ > >>  
│
│ > >> It probably wouldn't hurt to unset it. I've never come across a package  
│
│ > >> where that's been a problem but best not invite trouble. 
│
└───┘
and wondering what kind of problem was anticipated if NOCONFIGURE were left set.

So I thought, if you unset it, you will never discover that problem.
Then I doubled down with the rest, to suggest forcing the ghost problem
to show itself ;-)

My motivation was to make any problem more easily debuggable rather than less,
but it was about debugging, not standard operating procedure.

> 
> [0] 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates=778d6b522ae361767d3cf984a3b182bac7361b7a

-- 
Regards,
Bengt Richter

Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.

[Efraim Flashner]

On Sun, Feb 16, 2020 at 05:24:22PM +0100, Bengt Richter wrote:
> Hi Efraim,
> 
> On +2020-02-16 16:55:17 +0200, Efraim Flashner wrote:
> > On Sun, Feb 16, 2020 at 03:27:36PM +0100, Marius Bakke wrote:
> > > guix-comm...@gnu.org writes:
> > > 
> > > > commit 481a0f1a7ceac666a011b28324220584ead07698
> > > > Author: Efraim Flashner 
> > > > AuthorDate: Thu Feb 13 10:54:29 2020 +0200
> > > >
> > > > build: gnu-build-system: Don't run configure during bootstrap.
> > > > 
> > > > * guix/build/gnu-build-system.scm (bootstrap): Add NOCONFIGURE
> > > > environment variable before running bootstrap scripts.
> > > 
> > > [...]
> > > 
> > > > @@ -190,6 +190,7 @@ working directory."
> > > >(if (executable-file? script)
> > > >(begin
> > > >  (patch-shebang script)
> > > > +(setenv "NOCONFIGURE" "true")
> > > >  (invoke script))
> > > >(invoke "sh" script)))
> > > >  (if (or (file-exists? "configure.ac")
> > > 
> > > Should we unset NOCONFIGURE afterwards?  Probably at least one package
> > > uses this variable for something completely different...
> > 
> > It probably wouldn't hurt to unset it. I've never come across a package
> > where that's been a problem but best not invite trouble.
> >
> With all due respect, I am not comfortable with this kind of rationale :) 
> 
> If it's never been a problem, unsetting might hide a case where it _would_
> cause a problem -- which IMO it would be better to find out about than not.
> 
> Is there an official policy regarding garbage/dangling environment variables?
> 
> (Or is that just to be expected in the sargasso sea of "undefined behaviour"? 
> ;-)
> 
> So, if in doubt, instead of unsetting, perhaps set it something like
> 
> 
> "IF_YOU_SEE_THIS_PLEASE_REPORT_HOW_IT_HAPPENED_TO_efraim_AT_flashner.co.il"
> 
> ;-P
> 
> or make it throw an exception somehow, if following processing uses 
> NOCONFIGURE
> any way at all before being replaced with a proper meaningful new value.
> 
> > Also, looking at the snippet, I should move it higher up. If it's not
> > executable then NOCONFIGURE doesn't get set.
> > 
> 
> Hope I didn't offend anyone :)

(ins)efraim@E5400 ~$ env | grep -i pants
PANTS=ON

There's some inside joke somewhere in Enlightenment that I don't know.
I've found the code that sets PANTS=ON but I've never tried changing it.

The beginning of the gnu-build-system goes:
(phases set-SOURCE-DATE-EPOCH set-paths install-locale unpack
bootstrap

So if NOCONFIGURE is set previously it's from us anyway. So in this case
I think it's fair to clean up after ourselves.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.

[Marius Bakke]

Bengt Richter  writes:

> Hi Efraim,
>
> On +2020-02-16 16:55:17 +0200, Efraim Flashner wrote:
>> On Sun, Feb 16, 2020 at 03:27:36PM +0100, Marius Bakke wrote:
>> > guix-comm...@gnu.org writes:
>> > 
>> > > commit 481a0f1a7ceac666a011b28324220584ead07698
>> > > Author: Efraim Flashner 
>> > > AuthorDate: Thu Feb 13 10:54:29 2020 +0200
>> > >
>> > > build: gnu-build-system: Don't run configure during bootstrap.
>> > > 
>> > > * guix/build/gnu-build-system.scm (bootstrap): Add NOCONFIGURE
>> > > environment variable before running bootstrap scripts.
>> > 
>> > [...]
>> > 
>> > > @@ -190,6 +190,7 @@ working directory."
>> > >(if (executable-file? script)
>> > >(begin
>> > >  (patch-shebang script)
>> > > +(setenv "NOCONFIGURE" "true")
>> > >  (invoke script))
>> > >(invoke "sh" script)))
>> > >  (if (or (file-exists? "configure.ac")
>> > 
>> > Should we unset NOCONFIGURE afterwards?  Probably at least one package
>> > uses this variable for something completely different...
>> 
>> It probably wouldn't hurt to unset it. I've never come across a package
>> where that's been a problem but best not invite trouble.
>>
> With all due respect, I am not comfortable with this kind of rationale :) 
>
> If it's never been a problem, unsetting might hide a case where it _would_
> cause a problem -- which IMO it would be better to find out about than not.

I'm not sure I follow.  The variable in question has only been used in a
handful of packages[0].  Now we are adding it in nearly 10k packages.

Why would we want to know whether a package build process has a problem
with that particular variable?

[0] 
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates=778d6b522ae361767d3cf984a3b182bac7361b7a


signature.asc
Description: PGP signature

Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.

[Bengt Richter]

Hi Efraim,

On +2020-02-16 16:55:17 +0200, Efraim Flashner wrote:
> On Sun, Feb 16, 2020 at 03:27:36PM +0100, Marius Bakke wrote:
> > guix-comm...@gnu.org writes:
> > 
> > > commit 481a0f1a7ceac666a011b28324220584ead07698
> > > Author: Efraim Flashner 
> > > AuthorDate: Thu Feb 13 10:54:29 2020 +0200
> > >
> > > build: gnu-build-system: Don't run configure during bootstrap.
> > > 
> > > * guix/build/gnu-build-system.scm (bootstrap): Add NOCONFIGURE
> > > environment variable before running bootstrap scripts.
> > 
> > [...]
> > 
> > > @@ -190,6 +190,7 @@ working directory."
> > >(if (executable-file? script)
> > >(begin
> > >  (patch-shebang script)
> > > +(setenv "NOCONFIGURE" "true")
> > >  (invoke script))
> > >(invoke "sh" script)))
> > >  (if (or (file-exists? "configure.ac")
> > 
> > Should we unset NOCONFIGURE afterwards?  Probably at least one package
> > uses this variable for something completely different...
> 
> It probably wouldn't hurt to unset it. I've never come across a package
> where that's been a problem but best not invite trouble.
>
With all due respect, I am not comfortable with this kind of rationale :) 

If it's never been a problem, unsetting might hide a case where it _would_
cause a problem -- which IMO it would be better to find out about than not.

Is there an official policy regarding garbage/dangling environment variables?

(Or is that just to be expected in the sargasso sea of "undefined behaviour"? 
;-)

So, if in doubt, instead of unsetting, perhaps set it something like

"IF_YOU_SEE_THIS_PLEASE_REPORT_HOW_IT_HAPPENED_TO_efraim_AT_flashner.co.il"

;-P

or make it throw an exception somehow, if following processing uses NOCONFIGURE
any way at all before being replaced with a proper meaningful new value.

> Also, looking at the snippet, I should move it higher up. If it's not
> executable then NOCONFIGURE doesn't get set.
> 
> 
> -- 
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

Hope I didn't offend anyone :)
-- 
Regards,
Bengt Richter

staging branch open

[Marius Bakke]

Hello Guixers,

The 'staging' branch is awaiting your patches.  The next freeze date
will be Monday, February 24th.


signature.asc
Description: PGP signature

Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.

[Efraim Flashner]

On Sun, Feb 16, 2020 at 03:27:36PM +0100, Marius Bakke wrote:
> guix-comm...@gnu.org writes:
> 
> > commit 481a0f1a7ceac666a011b28324220584ead07698
> > Author: Efraim Flashner 
> > AuthorDate: Thu Feb 13 10:54:29 2020 +0200
> >
> > build: gnu-build-system: Don't run configure during bootstrap.
> > 
> > * guix/build/gnu-build-system.scm (bootstrap): Add NOCONFIGURE
> > environment variable before running bootstrap scripts.
> 
> [...]
> 
> > @@ -190,6 +190,7 @@ working directory."
> >(if (executable-file? script)
> >(begin
> >  (patch-shebang script)
> > +(setenv "NOCONFIGURE" "true")
> >  (invoke script))
> >(invoke "sh" script)))
> >  (if (or (file-exists? "configure.ac")
> 
> Should we unset NOCONFIGURE afterwards?  Probably at least one package
> uses this variable for something completely different...

It probably wouldn't hurt to unset it. I've never come across a package
where that's been a problem but best not invite trouble.

Also, looking at the snippet, I should move it higher up. If it's not
executable then NOCONFIGURE doesn't get set.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Oddities with the dev86 package

[Christopher Baines]

Hey,

I noticed that the dev86 package was a bit odd from looking at the
package reproducibility page in the Guix Data Service, it was appearing
in the "Matching" section for all architectures, which seemed a bit odd
[1].

1: 
http://data.guix.gnu.org/revision/3c6aca4232d1a3638ec962bc7afe9121626c43ec/package-reproducibility

Playing with this package on the command line, it seems that whatever
system you ask Guix to generate a derivation for, it generates the same
derivation.

→ guix build -d --system=i686-linux dev86
/gnu/store/wmzryaqgxxank355d9c1i7ikz813j7qd-dev86-0.16.21.drv

→ guix build -d --system=x86_64-linux dev86
/gnu/store/wmzryaqgxxank355d9c1i7ikz813j7qd-dev86-0.16.21.drv

→ guix build -d --system=aarch64-linux dev86
/gnu/store/wmzryaqgxxank355d9c1i7ikz813j7qd-dev86-0.16.21.drv


This is particularly odd, as the package declares it only supports
i686-linux and x86_64-linux, so I wouldn't expect to be able to compute
a derivation for aarch64-linux.

I'm guessing this behaviour has something to do with the #:system
argument to the build system?

From looking at the package definition myself, I'd expect at least that
generating a aarch64-linux derivation would fail. I'm not sure what
should happen in the x86_64-linux case, I guess you can infer some
information from asking for an x86_64-linux derivation, and then getting
back a i686-linux one.

Thanks,

Chris


signature.asc
Description: PGP signature

Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.

[Marius Bakke]

guix-comm...@gnu.org writes:

> commit 481a0f1a7ceac666a011b28324220584ead07698
> Author: Efraim Flashner 
> AuthorDate: Thu Feb 13 10:54:29 2020 +0200
>
> build: gnu-build-system: Don't run configure during bootstrap.
> 
> * guix/build/gnu-build-system.scm (bootstrap): Add NOCONFIGURE
> environment variable before running bootstrap scripts.

[...]

> @@ -190,6 +190,7 @@ working directory."
>(if (executable-file? script)
>(begin
>  (patch-shebang script)
> +(setenv "NOCONFIGURE" "true")
>  (invoke script))
>(invoke "sh" script)))
>  (if (or (file-exists? "configure.ac")

Should we unset NOCONFIGURE afterwards?  Probably at least one package
uses this variable for something completely different...


signature.asc
Description: PGP signature

GNU Guix Workflow Language 0.2.0 released

[Ricardo Wurmus]

We are pleased to announce the release of the GNU Guix Workflow
Language version 0.2.0, representing 383 commits by 3 people.

This release contains a number of big, incompatible changes compared
to the previous release 0.1.1.  The "guix process" command has been
removed in favor of a single "guix workflow" command and workflows are
now loaded from files instead of finding them in Guile modules on
GUIX_WORKFLOW_PATH.  Workflows can now be specified in Wisp syntax in
addition to the S-expression Scheme syntax.  For details see the
section on changes below, or take a look at the manual:

https://workflows.guix.info/manual/

• About

  The Guix Workflow Language (GWL) provides an extension to GNU Guix's
  declarative language for package management to automate the
  execution of programs in scientific workflows.  The GWL can use
  process engines to integrate with various computing environments.

• Download

  Here are the compressed sources and a GPG detached signature[*]:
https://ftpmirror.gnu.org/gwl/gwl-0.2.0.tar.gz
https://ftpmirror.gnu.org/gwl/gwl-0.2.0.tar.gz.sig

  Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify gwl-0.2.0.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 
BCA689B636553801C3C62150197A5888235FACAC

  and rerun the 'gpg --verify' command.

  This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.16.1
Gnulib v0.1-3269-g03d7a6b1f

• Changes in 0.2.0 (since 0.1.1)

** Command line interface
  * Remove the “guix process” command.
  * Remove GUIX_WORKFLOW_PATH; load workflows from files instead.
  * Add --container flag to enable process isolation
** Workflow syntax
  * Support Wisp syntax in workflow files.
  * Add syntactic sugar for defining workflows and processes.
  * Support syntax for procedures written in languages other than Guile.
  * Add graph syntax to specify process dependencies.
  * Add “auto-connect” helper to automatically link up process inputs and 
outputs.
  * Deprecate the “restrictions” field in workflow records in favor of 
“auto-connect” and “graph” syntax in the “processes” field.
  * Fields of the “process” form that expect lists now also accept multiple 
values.
  * Add “on” procedure for application of higher-order functions to collections
  * Add “expand” procedure to expand variables in file name templates
** Execution engines
  * Add simple execution engine and use it by default instead of the 
bash-engine.
** Programming interface
  * Remove modules “(guix processes)” and “(guix workflows)”.  Use “(gwl 
processes)” and “(gwl workflows)” instead.
  * Remove “define-dynamically” macro
  * Use GOOPS instead of “(guix records)”
** Documentation
  * Add manual in Texinfo format

-- 
Ricardo


signature.asc
Description: PGP signature

Re: Guix Data Services: whishlist about SWH

[Christopher Baines]

zimoun  writes:

> Recently, the source of package was missing and so "guix time-machine"
> was broken [1]. It is not the first time that it appears [2]; patches
> are coming... :-)
>
> Using the Software Heritage (SWH) API [3], does it seems a good idea
> to add SWH coverage somewhere in the Guix Data Services?
>
> I do not remember where the Reproducibility chart is located, but a
> chart there could be added, telling how many packages are already
> archived in SWH and how many not yet.
>
> And for example, on the webpage about the history of the package [4],
> some information about SWH could be added.
>
> What do you think?

I think that would be good data to have in the Guix Data Service.

I'm not sure quite how this data would fit in, I guess it would be
similar to the data for nar files, but more limited to fixed output
derivations.

I think the first step towards this would be to experiment with fetching
data from the Software Heritage API. Do you know how you'd fetch data
about the output from a fixed output derivation (like harfbuzz)?

http://data.guix.gnu.org/gnu/store/53mfydv96wfwg2fxjyyml44v7v2y84z3-harfbuzz-2.5.3.tar.xz

> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39575
> [2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28659
> [3] https://archive.softwareheritage.org/api/
> [4] http://data.guix.gnu.org/repository/1/branch/master/package/harfbuzz
>
>
> (Note that on [4] the version 2.4.0 which is the culprit is not shown,
> is it expected?)
>
> All the best,
> simon


signature.asc
Description: PGP signature