Re: cross-compiling in core-updates

[Manolis Ragkousis]

The reason for the cascading errors is bash-minimal.

Trying to build `./pre-inst-env guix build bash-minimal'
on core-updates ends up with :

The following derivation will be built:
   /gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv
@ build-started
/gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv -
x86_64-linux
/usr/local/var/log/guix/drvs/1r//0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv.bz2
ice-9/psyntax.scm:1534:32: In procedure expand-macro:
ice-9/psyntax.scm:1534:32: Syntax error:
/gnu/store/k84sww1zzh33a5hw8bcmsa5yp7w628a8-bash-minimal-4.4.12-guile-builder:1:2285:
source expression failed to match any pattern in form (%modify-phases
phases* (delete (quote move-development-files)))
builder for
`/gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv'
failed with exit code 1
@ build-failed
/gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv - 1
builder for
`/gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv'
failed with exit code 1
guix build: error: build failed: build of
`/gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv' failed

It's the same issue Sergei reported and commit 78dea6f1d4a did not fix it.

On 04/26/17 00:26, Sergei Trofimovich wrote:
> On Tue, 25 Apr 2017 17:10:58 +0300
> Manolis Ragkousis  wrote:
> 
>> Hello Rene,
>>
>> I am currently looking into that.
>>
>> Manolis
> 
> I've tracked it down to guile-2.-0>2.2 bump.
> 'define-syntax %modify-phases' somehow changed the meaning:
> https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00315.html
> but I know almost nothing on how all the nested guix's quotations interact.
> 
> Would be nice to hear from those who Know Things (CCed Andy and Ludovic :)
> 

Re: potluck status

[David Pirotte]

Le Fri, 28 Apr 2017 11:46:43 -0500,
Christopher Allan Webber  a écrit :

> Andy Wingo writes:
> 
> > On Fri 28 Apr 2017 14:42, Hartmut Goebel  
> > writes:
> >  
> >> Am 28.04.2017 um 14:05 schrieb Andy Wingo:  
> >>>   5.15 Invoking ‘guix potluck’  
> >>
> >> Please think about an other name for this command. "potlouk"  may be
> >> common to native speakers but I never heard this word. Thanks.  
> >
> > I thought about many things :)  Do you have a suggestion?
> > https://guix-potluck.org/ does provide the definition.
> >
> > Andy  
> 
> I personally like Potluck a lot; I know it might not be a particularly
> common English word, but it may be a good one for people to learn if
> they don't already know it.  It captures the spirit of things to me very
> nicely.
 
1+
and this name is part of 'our' history

David


pgpla2kxXevmk.pgp
Description: OpenPGP digital signature

Re: potluck status

[Christopher Allan Webber]

Andy Wingo writes:

> On Fri 28 Apr 2017 14:42, Hartmut Goebel  
> writes:
>
>> Am 28.04.2017 um 14:05 schrieb Andy Wingo:
>>>   5.15 Invoking ‘guix potluck’
>>
>> Please think about an other name for this command. "potlouk"  may be
>> common to native speakers but I never heard this word. Thanks.
>
> I thought about many things :)  Do you have a suggestion?
> https://guix-potluck.org/ does provide the definition.
>
> Andy

I personally like Potluck a lot; I know it might not be a particularly
common English word, but it may be a good one for people to learn if
they don't already know it.  It captures the spirit of things to me very
nicely.

Re: Defining user services in Guix.

[Mathieu Othacehe]

Hi,

> Agreed.  A ‘guix user’ tool (or similar) could talk to the user’s
> Shepherd instance to upgrade user services like
> ‘upgrade-shepherd-services’ does in (guix scripts system).

With the attached patch, it is possibe to use (gnu services herd) to
interact with a user shepherd instance.

For instance :

--8<---cut here---start->8---
(use-modules (gnu services herd))
(parameterize
 ((%shepherd-socket-file "/home/mathieu/.config/shepherd/run/socket"))
 (current-services))
--8<---cut here---end--->8---

Which returns :

--8<---cut here---start->8---
$1 = (#< provision: (redshift) requirement: () running: 3632> 
#< provision: (root shepherd) requirement: () running: #t>)
--8<---cut here---end--->8---

Based on that, I'll try to define a guix user command to upgrade user
services if it is ok for everyone :).

Thanks,

Mathieu
>From caf7d9f5a7875663623b24662c1c23b99e60c5ad Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Fri, 28 Apr 2017 17:09:53 +0200
Subject: [PATCH] services: herd: Make %shepherd-socket-file a parameter and
 export it.

* gnu/services/herd.scm (%shepherd-socket-file): Make it an exported
  parameter.
(open-connection): Adapt.
---
 gnu/services/herd.scm | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/gnu/services/herd.scm b/gnu/services/herd.scm
index 03bfbf1d7..f8d60a480 100644
--- a/gnu/services/herd.scm
+++ b/gnu/services/herd.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016 Ludovic Courtès 
+;;; Copyright © 2017 Mathieu Othacehe 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -23,7 +24,9 @@
   #:use-module (srfi srfi-34)
   #:use-module (srfi srfi-35)
   #:use-module (ice-9 match)
-  #:export (shepherd-error?
+  #:export (%shepherd-socket-file
+
+shepherd-error?
 service-not-found-error?
 service-not-found-error-service
 action-not-found-error?
@@ -58,9 +61,9 @@
 ;;; Code:
 
 (define %shepherd-socket-file
-  "/var/run/shepherd/socket")
+  (make-parameter "/var/run/shepherd/socket"))
 
-(define* (open-connection #:optional (file %shepherd-socket-file))
+(define* (open-connection #:optional (file (%shepherd-socket-file)))
   "Open a connection to the daemon, using the Unix-domain socket at FILE, and
 return the socket."
   ;; The protocol is sexp-based and UTF-8-encoded.
-- 
2.12.2

Re: bug#25356: livestreamer no longer supported

[ng0]

Leo Famulari transcribed 0.7K bytes:
> On Wed, Jan 04, 2017 at 06:50:14PM +, ng0 wrote:
> > Do I read this correctly that they include some kind of
> > anti-military license in there? I mean I am very much welcoming
> > such an exclusion but with all the past discussions I had it lead
> > to the point where it is not compatible with free software.
> > 
> > Do we have to strip OCB from the source?
> > https://github.com/Legrandin/pycryptodome/blob/master/LICENSE.rst
> > 
> > Pycryptodome is a dependency of streamlink.
> 
> The question is about the OCB block cipher mode. I think we are able to
> distribute implementations of it:
> 
> http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil
> http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#license
> http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm
> 

With regards to this bug, can someone help to get the facts clear here
so that we know what needs to be done to package streamlink?

Thanks.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Should I enable lua-scripting in the neomutt package?

[Ricardo Wurmus]

ng0  writes:

> Recently, with the last release, neomutt introduced lua-scripting
> for neomutt. It's not enabled by default because it's in a phase
> where neomutt wants people to enable it, test it, and receive feedback
> to improve it.
[…]
> Should we just wait until neomutt enables lua-scripting by default in
> the build?

I’d say: yes.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: potluck status

[Andy Wingo]

Hi :)

On Fri 28 Apr 2017 15:41, Katherine Cox-Buday  
writes:

> Andy Wingo  writes:
>
>> With that I think I'd like to move to a "use" phase where I just sit
>> back and see how people use the thing :)  WDYT?
>
> I am very excited about this functionality for all of the reasons you
> enumerated. I don't have any time at the moment, but I was (and still
> am) interested in getting Scala and sbt packaged, and I think this is
> how I would begin. I could also see packaging a few private work-related
> things as potluck packages for use by myself and others.
>
> A couple of questions:
>
> 1. When Guix grows channel support, will it have a concept of
>dev->test->prod?
> 2. Would it make sense for the dev channel to be expressed in terms of
>potluck packages?
>
> I'm not very active in the community at the moment, but I wanted to
> chime in and say +1, and thanks for the effort.

Great to hear the interest.  There are many many many unknowns at this
point.  The basic "channel" facility could be just like "git remote" --
you do "guix channel add testing https:///testing.git;.  "git
channel pull" or so could update that checkout.  "git channel enable"
makes a channel active for you by default.  I guess you would probably
also want to to specify also a set of active channels for a given guix
command; e.g. "guix package --channels=testing --install my-package".

Concretely you could "git channel add potluck
https://guix-potluck.org/git/target.git; to get the potluck channels.
Currently what you have to do is manually check out that repo and do
"guix package -L /path/to/checkout --install my-package".  So an initial
"guix channel" would just pave that guix-packages-in-a-git-repository
cowpath.

As for Scala and sbt and everything -- I think potluck packages are most
appropriate for "leaf" packages.  For packages that form
"infrastructure" like sbt and all, I think you will probably want to
integrate more closely in Guix.  But I don't know.

& as for dev/testing/prod/etc -- I have no idea :)  I'm not really an
ops person, so I can only speculate, and anyone can do that as well as I
can :)  I think with guix-potluck.org my main focus is to let people
share work-in-progress Guix packages immediately.  I can imagine many
ways this could relate to a sort of devopsy workflow but I can't pretend
to be an expert here :)

Cheers,

Andy

Re: potluck status

[Incoherent-lime]

I am personally happy with potluck, however collab has a similar group feeling 
to it.

-H

Sent from ProtonMail mobile  Original Message  On 28 Apr 2017, 
14:46, Katherine Cox-Buday wrote: I don't hold any strong opinions on the name, 
but in the interest of ideas: - guix quorum - guix collab - guix confer - guix 
conjoin That's all I have for now :) -- Katherine

Re: potluck status

[Katherine Cox-Buday]

I don't hold any strong opinions on the name, but in the interest of
ideas:

- guix quorum
- guix collab
- guix confer
- guix conjoin

That's all I have for now :)

-- 
Katherine

Re: potluck status

[Katherine Cox-Buday]

Andy Wingo  writes:

> With that I think I'd like to move to a "use" phase where I just sit
> back and see how people use the thing :)  WDYT?

I am very excited about this functionality for all of the reasons you
enumerated. I don't have any time at the moment, but I was (and still
am) interested in getting Scala and sbt packaged, and I think this is
how I would begin. I could also see packaging a few private work-related
things as potluck packages for use by myself and others.

A couple of questions:

1. When Guix grows channel support, will it have a concept of
   dev->test->prod?
2. Would it make sense for the dev channel to be expressed in terms of
   potluck packages?

I'm not very active in the community at the moment, but I wanted to
chime in and say +1, and thanks for the effort.

-- 
Katherine

Re: potluck status

[Incoherent-lime]

In the UK,
We do potluck dinners, I also had one in Canada.

Though I agree it's quite colloquial term, does one have to understand the 
reference to understand how to use the command on the CLI?

-H

Sent from ProtonMail mobile

 Original Message 
On 28 Apr 2017, 13:58, Jan Nieuwenhuizen wrote:
Hartmut Goebel writes:

> Please think about an other name for this command. "potlouk" may be
> common to native speakers but I never heard this word. Thanks.

Potluck dish --even though it's English--- is a common word even in the
Netherlands...possibly this is a European thing.

I like the name, you are the one who wants another name; what would you
suggest?

Greetings,
janneke

--
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl

Re: potluck status

[Jan Nieuwenhuizen]

Hartmut Goebel writes:

> Please think about an other name for this command. "potlouk"  may be
> common to native speakers but I never heard this word. Thanks.

Potluck dish --even though it's English--- is a common word even in the
Netherlands...possibly this is a European thing.

I like the name, you are the one who wants another name; what would you
suggest?

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: potluck status

[Andy Wingo]

On Fri 28 Apr 2017 14:42, Hartmut Goebel  writes:

> Am 28.04.2017 um 14:05 schrieb Andy Wingo:
>>   5.15 Invoking ‘guix potluck’
>
> Please think about an other name for this command. "potlouk"  may be
> common to native speakers but I never heard this word. Thanks.

I thought about many things :)  Do you have a suggestion?
https://guix-potluck.org/ does provide the definition.

Andy

Re: potluck status

[Hartmut Goebel]

Hi,

Am 28.04.2017 um 14:05 schrieb Andy Wingo:
>   5.15 Invoking ‘guix potluck’

Please think about an other name for this command. "potlouk"  may be
common to native speakers but I never heard this word. Thanks.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH] gnu: Add cool-retro-term.

[Petter]

On Thu, 27 Apr 2017 20:47:54 -0500
Eric Bavier  wrote:

> > > > +(inputs
> > > > + `(("qt" ,qt)))  
> > > 
> > > Does this package need all of qt, or could we use the component
> > > packages instead?
> > 
> > I don't know. I'll do some experiments and see.  
> 
> OK, great.

Fixed!

Now it is:
  (inputs
   `(("qtbase" ,qtbase)
 ("qtdeclarative" ,qtdeclarative)
 ("qtgraphicaleffects" ,qtgraphicaleffects)
 ("qtquickcontrols" ,qtquickcontrols)))

> > > > +(description
> > > > + "Cool-retro-term (crt) is a terminal emulator which mimics the
> > > > look and +feel of the old cathode ray tube (CRT) screens.  It has been
> > > > designed to be +eye-candy, customizable, and reasonably lightweight.")
> > > > +(home-page "https://github.com/Swordfish90/cool-retro-term;)
> > > > +(license (list license:gpl2 license:gpl3)  
> > > 
> > > The license seems unclear: 1) there is both a gpl-2.txt and gpl-3.txt
> > > in $topsrcdir, but no mention of which actually applies in any of the
> > > source files, 2) $topsrcdir/packaging/debian/copyright claims GPL-3,
> > > while 4) $topsrcdir/packaging/rpm/cool-retro-term.spec and
> > > $topsrcdir/packaging/appdata/cool-retro-term.appdata.xml both claim
> > > GPL-3.0+, and 5) the qmltermwidget component appears to be under
> > > gpl2+.  IANAL but this suggests license:gpl2+ to me.  Does that seem
> > > right?
> > 
> > I can't answer this, hopefully someone else will chime in.  
> 
> I did a little more looking: The sources in app/qml seem to have
> license headers marked as GPLv3+, so we can mark it as such.

I changed the GPL3 license GPL3+.

The owner has replied in an issue about this.

---[Swordfish90 commented on Dec 1, 2015]---
Hi @nadams810 and sorry for the late response. Since the project is split
into two different components, the idea behind the licensing was the
following:

1. All the files belonging to QMLTermWidget which is a separate library
forked by qtermwidget are licensed under GPL2 (as the original library).
2. All the files belonging to CRT are licensed under GPL3.
 
To be fair I'm not really an expert when it comes to licensing and if there
is something wrong with the following approach just let me know.
---end-quote---

https://github.com/Swordfish90/cool-retro-term/issues/269

> >   
> > > It would not hurt to also list the SIL license, for
> > > $topsrcdir/app/qml/fonts/modern-hermit, and the X11 license for
> > > fonts/modern-pro-font-win-tweaked and fonts/modern-proggy-tiny.

Added.

> > > The fonts/modern-envy-code-r font probably needs to be stripped; it's
> > > license is non-free; from 'Read Me.txt':
> > > 
> > >   "Free to use but redistribution prohibited."
> > > 

This font was removed Mar 13, 2016.
https://github.com/Swordfish90/cool-retro-term/commit/c505dfaa11166054686df7390cf04dba324ad869

> > > and the fonts/1977-apple2, fonts/1977-commodore-pet, probably also needs
> > > to be stripped as non-free; from 'FreeLicense.txt':
> > > 
> > >   "1. The User may not sell copies of the Software for a fee."
> > > 
> > > The fonts/1979-atari-400-800 font seems to be non-free license, which is
> > > not mentioned in the 'ReadMe.rtf' but only on the WayBack Machine at
> > > https://web-beta.archive.org/web/20080907111008/http://www2.bitstream.net/~marksim/atarimac/fonts.html
> > >  :
> > > 
> > >   "These fonts are freeware and may not be offered for sale seperately
> > >   or as part of a collection."
> > > 
> > > The fonts/1982-commodore64 font is licensed under non-free terms; see
> > > fonts/1982-commodore64/license.txt
> > > 
> > > The only mention of a license for fonts/1985-ibm-pc-vga is at
> > > http://www.dafont.com/font-comment.php?file=perfect_dos_vga_437 where
> > > the author says "The license is this: this font is free to use in
> > > whatever you want.", but that probably "doesn't count".
> > > 
> > > I could not find license info for a few of the other fonts.
> > > 
> > > OTOH I recall a discussion on IRC recently about fonts embedded in
> > > packages being treated as non-functional data, and thus OK from a FSDG
> > > perspective.  But I would want verification on that.
> > 
> > Let's see if someone can shine some light on this.
> >   
> 
> Leo pointed me at https://bugs.gnu.org/26588 which references
> https://www.gnu.org/distros/free-system-distribution-guidelines.html#non-functional-data
>  .
> I think many of these fonts would need to be stripped out or
> substituted because their license prohibits commercial/non-commercial
> redistribution.

Recipe is now removing the following from disk and GUI:
  '("1977-apple2"
"1977-commodore-pet"
"1979-atari-400-800"
"1982-commodore64"
"1985-ibm-pc-vga")

Should more be removed?

What do we do about the 

potluck status

[Andy Wingo]

Hi!

To recall, "guix potluck" is a packaging facility that is a decoupled
from mainline Guix development.  The latest patches are in wip-potluck,
and a recent copy of the patches is here:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26645

Here is part of the documentation in that branch:

  5.15 Invoking ‘guix potluck’
  

   Note: As of version 0.12.0, this tool is experimental.  The
   interface is subject to radical change in the future.

 Guix is developed as a unified project composed of both the package
  manager and the set of packages.  This allows Guix to evolve while
  remaining healthy and coherent.  If there is a change that needs to be
  done across Guix’s entire tree, Guix developers can make it happen.  One
  way in which this principle manifests itself is in the ‘package’ data
  type, where input packages are directly specified by value in the
  ‘inputs’, ‘native-inputs’, and ‘propagated-inputs’ fields, instead of
  being specified as some abstract package name and version constraint
  that Guix would have to solve for.  *Note package Reference::, for more
  on the ‘package’ data type.

 However it is sometimes desirable to develop a package or set of
  packages in a more decoupled way, for example when a package set is
  still incubating or when a package is inappropriate for sending upstream
  for some reason.  Such packages use Guix and extend Guix but are not a
  part of the Guix project, properly speaking.  As such, they need to be
  resilient to changes in upstream Guix.  It would be brittle if such a
  package definition had to reference a Guix package by value; the Scheme
  variable denoting the upstream Guix package might move to a different
  module, or be renamed, or changed in some unexpected way.

 Guix’s “potluck” facility fills this gap.  A “potluck package” is
  like a normal Guix package, except it expresses its inputs in the form
  of package specifications instead of direct references.  *Note
  potluck-package Reference::.  Potluck packages also have a simpler
  package structure with fewer fields; compared to normal Guix packages,
  they are less expressive but more isolated from details of upstream
  Guix.

 The user interface to potluck packages is concentrated in the ‘guix
  potluck’ command.  To begin, let’s say you are a developer of the ‘foo’
  project, and you’d like to package ‘foo’ for use in your Guix system and
  maybe also that of a friend.  You’re not sure if you want to support it
  yet so you don’t want to make a proper release, but there should be
  something in the middle between that and not packaging it at all.  You
  decide to give ‘guix potluck’ a go.

 So in that git checkout, you run ‘guix potluck init URL’, where URL
  is a publicly accessible git URL at which ‘foo’ is hosted.  ‘guix
  potluck init’ takes the following options:

  ‘--build-system=SYS’
  ‘--build-system=help’
  ‘--autotools’
   Indicate that the package uses the build system named SYS.  Pass
   ‘help’ as the build system to see available options.  ‘--autotools’
   is like the common ‘--build-system=gnu’, but additionally
   indicating that an ‘autoreconf’ step is needed before building.
  ‘--license=LICENSE’
  ‘--license=help’
   Specify the license of the project.

 Calling ‘guix potluck init’ will result in the creation of a
  ‘guix-potluck’ directory in your git checkout, containing a brief
  overview ‘README.md’ file as well as a ‘foo.scm’ potluck package
  definition.  *Note potluck-package Reference::.  Just fill in the
  synopsis and description and add the inputs and you have the beginnings
  of a potluck package.

 You can try building your new package by running ‘guix build -f
  guix-potluck/foo.scm’.  Once that works, you can share the file with
  your friends and they can build your package too.

 Of course, it would be nice if you could share that package with the
  world.  And it would be nice if your potluck package definitions could
  augment the set of available packages and versions.  And it would be
  nice if your potluck package could serve as a first draft of a proper
  Guix package definition.  We agree completely!

 Guix’s potluck facility also implements a kind of registry of potluck
  recipes, as if it were hosting an actual potluck.  This ‘host-channel’
  facility takes requests to add potluck packages and translates that into
  a git repository of all potluck packages, as well as a git repository of
  Guix packages compiled from those potluck packages.

 To inform a channel host of the presence of fresh tasty potluck
  dishes, run ‘guix potluck update URL BRANCH’.  URL should be the URL of
  a git repository containing a ‘guix-potluck’ directory, and BRANCH is a
  ref in that repository.  By default, the request is made to add the
  package to the default ‘guix-potluck.org’ host; pass ‘--host=HOST’ to
  specify an alternate registry.

 Running ‘guix 

Re: Should I enable lua-scripting in the neomutt package?

[ng0]

ng0 transcribed 0.7K bytes:
> Recently, with the last release, neomutt introduced lua-scripting
> for neomutt. It's not enabled by default because it's in a phase
> where neomutt wants people to enable it, test it, and receive feedback
> to improve it.

And because not everyone is subscribed everywhere, here is the thread:
http://mailman.neomutt.org/pipermail/neomutt-users-neomutt.org/2017-April/000126.html

> As the announcement of it points out, this can be used to write the
> neomutt config in lua.
> With awesome-wm, we (still) have lots of issues with lua I haven't
> looked into.
> 
> Are there reasons why we might not want lua as a dependency installed?
> Neomutt is delivered as feature-complete (except the databases, where
> we don't enable every possible type (yet)).
> Should we just wait until neomutt enables lua-scripting by default in
> the build?
> 
> Tell me what you think.
> -- 
> PGP and more: https://people.pragmatique.xyz/ng0/
> 

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Should I enable lua-scripting in the neomutt package?

[ng0]

Recently, with the last release, neomutt introduced lua-scripting
for neomutt. It's not enabled by default because it's in a phase
where neomutt wants people to enable it, test it, and receive feedback
to improve it.
As the announcement of it points out, this can be used to write the
neomutt config in lua.
With awesome-wm, we (still) have lots of issues with lua I haven't
looked into.

Are there reasons why we might not want lua as a dependency installed?
Neomutt is delivered as feature-complete (except the databases, where
we don't enable every possible type (yet)).
Should we just wait until neomutt enables lua-scripting by default in
the build?

Tell me what you think.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

GNU Hackers Meeting 2017 call for presentations!

[Alex Sassmannshausen]

Hello!

The GNU Hackers Meeting is looking for presentations for this years
programme!

Find out all you need to know, and/or submit your proposal at
https://www.gnu.org/ghm/programme.html .

The deadline for submissions is 4 June 2017.

The meeting will take place 24 - 27 August in Germany.  The meeting is
on the smaller end of conferences, which creates a lovely, open and
welcoming atmosphere.

You're interested in Free Software development or activism?  Join us, we
want you there!

Please boost this message far and wide, to mailing lists you are on,
to your IRC communities or via other channels of social media.

Outside of this email, I have put out messages at
https://octodon.social/web/statuses/1284133 and
https://twitter.com/_atheia_/status/857895331673059328 .  Feel free to
repeat, adapt, augment :-)

Happy hacking,

Alex

Re: [PATCH] import: Update Bioconductor release to 3.5.

[Roel Janssen]

Ricardo Wurmus writes:

> Roel Janssen  writes:
>
>>> I’d be happy if you could take care of the mass update.  I should note
>>> that sometimes new inputs are required.  To find them I usually run the
>>> update in a separate branch where I’ve applied changes to import anew
>>> and compare with the existing package expression when updating.  It’s on
>>> my list to clean this all up and submit my changes for review.  It’s
>>> ugly but it works pretty well.  If you’re interested I could send you a
>>> patch.
>>
>> How do you test which inputs are required?  I built all the bioconductor
>> packages and fixed their builds by adding inputs wherever that was
>> needed.  This does not take care of inputs that are no longer needed (if
>> any..).  Any way I can test that in a convenient way?
>
> Attached is my rough patch set.  Apply this and run the update with
> “guix refresh -t bioconductor,cran -u”.  It will tell you to “consider”
> removing or adding inputs.  Some of the suggestions are wrong, but it
> really means well :)
>
> It’s terrible code in some places.  Don’t look too closely.

Thanks!  I think I've processed the mass-update now.  It looks like we
have only gained dependencies. (Not a lot though).

I kept the SVN repository URL for Bioconductor for now, instead of the
Github mirror.  AFAIU, Bioconductor is going to transition to Git (and
Github) before the next release, which deprecates the
'Bioconductor-mirror' repository.  Since package maintainers get the
heads-up and probably have to take some action when this transition
occurs, I will make sure we transition without service disruption. :)

Kind regards,
Roel Janssen

Re: GuixSD bootable ISO-9669 image (was: Re: GuixSD on servers [Fwd: [rtracker.1984.is #131647] A question about VServer system specific requirements])

[Danny Milosavljevic]

Small fix below

On Thu, 27 Apr 2017 22:00:09 +0200
Danny Milosavljevic  wrote:

> Something like this (totally untested):
> 
> diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm
> index 0cb84b8aa..be512d59c 100644
> --- a/gnu/build/file-systems.scm
> +++ b/gnu/build/file-systems.scm
> @@ -230,6 +230,55 @@ Trailing spaces are trimmed."
>  
>  ^L
>  ;;;
> +;;; ISO9660 file systems.
> +;;;
> +
> +;; 
> .
> +
> +;(define-syntax %iso9660-endianness
> +;  ;; Endianness of iso9660 file systems that we use.
> +;  ;; Actually, iso9660 has redundant data (i.e. data for both endiannesses).
> +;  (identifier-syntax (endianness little)))
> +
> +(define (iso9660-superblock? sblock)
> +  "Return #t when SBLOCK is a iso9660 superblock."
> +  (bytevector=? (sub-bytevector sblock 1 6)
> +;; Note: "\x01" is the volume descriptor format version
> +(string->utf8 "CD001\x01")))
> +
> +(define (read-iso9660-primary-volume-descriptor device offset)
> +  "Find and read the first primary volume descriptor, starting at OFFSET.
> +   Return #f if not found."
> +  (let* ((sblock (read-superblock device offset 2048 iso9660-superblock?))
> + (type-code (array-ref sblock 0))) ; FIXME if sblock

+ (type-code (if sblock (array-ref sblock 0) 255)))

> +(match type-code
> +  (255 #f) ; Volume Descriptor Set Terminator.
> +  (1 sblock) ; Primary Volume Descriptor
> +  (_ (read-iso9660-primary-volume-descriptor device (+ offset 2048))
> +
> +(define (read-iso9660-superblock device)
> +  "Return the raw contents of DEVICE's iso9660 superblock as a bytevector, or
> +#f if DEVICE does not contain a iso9660 file system."
> +  ;; Start reading at sector 16.
> +  (read-iso9660-primary-volume-descriptor device (* 2048 16)))
> +
> +(define (iso9660-superblock-uuid sblock)
> +  "Return the Volume ID of a iso9660 superblock SBLOCK as a 4-byte 
> bytevector."
> +  ;; Note: The field is the volume creation time.
> +  ;; FIXME Use only certain parts (See grub).
> +  ;; FIXME treat "all 0" as invalid.
> +  (sub-bytevector sblock 813 17))
> +
> +;; FIXME make result human-readable (See grub).
> +;(define (iso9660-uuid->string uuid)
> +
> +(define (iso9660-superblock-volume-name sblock)
> +  "Return the volume name of SBLOCK as a string.  The volume name is an ASCII
> +string.  Trailing spaces are trimmed."
> +  (string-trim-right (latin1->string (sub-bytevector sblock 40 32) (lambda 
> (c) #f)) #\space))
> +
> +^L
> +;;;
>  ;;; LUKS encrypted devices.
>  ;;;
>  
> @@ -340,7 +389,9 @@ partition field reader that returned a value."
>  (_ #f)))
>  
>  (define %partition-label-readers
> -  (list (partition-field-reader read-ext2-superblock
> +  (list (partition-field-reader read-iso9660-superblock
> +iso9660-superblock-volume-name)
> +(partition-field-reader read-ext2-superblock
>  ext2-superblock-volume-name)
>  (partition-field-reader read-btrfs-superblock
>  btrfs-superblock-volume-name)
> @@ -348,7 +399,9 @@ partition field reader that returned a value."
>  fat32-superblock-volume-name)))
>  
>  (define %partition-uuid-readers
> -  (list (partition-field-reader read-ext2-superblock
> +  (list (partition-field-reader read-iso9660-superblock
> +iso9660-superblock-uuid)
> +(partition-field-reader read-ext2-superblock
>  ext2-superblock-uuid)
>  (partition-field-reader read-btrfs-superblock
>  btrfs-superblock-uuid)

Re: Mes 0.5 released

[Jan Nieuwenhuizen]

Arne Babenhauserheide writes:

> Wow! Congratulation on full bootstrapping of mes!

Thanks, Arne!

> So we can now build mes.c with mescc driven by Guile and then use mes to
> run mescc again to build mes.c?

Yes, that's correcct.  mes.c can be compiled with either gcc

make out/mes

or with [32 bit] gcc -nostdinc -nostdlib

make out/i686-unknown-linux-gnu-mes

or with guile

guile/mescc.scm src/mes.c > out/mes.guile

or with mes

scripts/mescc.mes src/mes.c > out/mes.mes

Now the route can go up (my first aim)

  - compile tcc, guile or gcc

or it can go down

  - add separate assembly step, assembly output
  - use stage0+ project, esp rewrite mes.c in stage2-LISP
  - use/work with epsilon?

or it can stay level

  - cleanup mescc
  - fix bugs
  - look into Nyacc
  - decide on psyntax

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: Mes 0.5 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen writes:

> I am pleased to announce the release of Mes 0.5, representing 249
> commits over 4 months.  Mes is now self-hosting, or rather it features
> a mutual self-hosting Scheme interpreter and C compiler: mes.c and
> mescc; a Nyacc-based C compiler backend that also works separately
> with Guile.

Wow! Congratulation on full bootstrapping of mes!

So we can now build mes.c with mescc driven by Guile and then use mes to
run mescc again to build mes.c?

Best wishes,
Arne