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

[Eric Bavier]

On Wed, 26 Apr 2017 20:09:33 +0200
Petter  wrote:

> On Tue, 25 Apr 2017 22:36:27 -0500
> Eric Bavier  wrote:
> 
> > Could you ping the developer about porting some of these fixes to their
> > fork?  I think we'd want to create a local patch for at least the first
> > commit.  The others could wait for a new release.  
> 
> Sure, I'll do that!

Thanks!

> 
> > > +(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.

> > > +(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.

> 
> > 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.
> > 
> > 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."
> > 
> > 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.

`~Eric


pgpw94uBopkGX.pgp
Description: OpenPGP digital signature

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]

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
+(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: store reference detection (was Re: JARs and reference scanning)

[Hartmut Goebel]

Am 27.04.2017 um 15:46 schrieb Ludovic Courtès:
> ‘propagated-inputs’ is one way to manually specify run-time references.
> It works at the package level and not at the store level—that is, the
> store item’s references are unaffected by what ‘propagated-inputs’
> contains.  It’s usually enough for our purposes though.

I'm not sure if 'propagated-inputs' are enough. For example
"python-passlib" as propagated-input python-py-bcrypt, but the later
does not show up as reference, requisite nor referrer:

$ ./pre-inst-env guix build --fallback python-passlib
[…]
/gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1
$ ./pre-inst-env guix gc -R
/gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1
/gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1
$ ./pre-inst-env guix gc --references
/gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1
/gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1
$ ./pre-inst-env guix gc --referrers
/gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1
/gnu/store/n9h6wr1ydgz2a2az04jpswmnl756x48r-python-passlib-1.7.1


-- 
Regards
Hartmut Goebel

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

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]

>... -V gnu-disk-image /mnt/disk-image-partition-1.
> xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules

That's because all characters in an ISO 9660 volume identification need to be 
one of "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_".

If you use more complicated labels you additionally need to support an 
extension like Joliet (which provides its own seperate directory tree in 
addition to the one of ISO 9660!).  It's easier to use uppercase letters only 
and not have a second tree.

See .

That page also describes how the disklabel looks:
- The first 32 KiB contain some non-ISO9660 stuff - it might be misdetected as 
something non-ISO9660 if you take it seriously.  So skip that.
- A sector has 2 KiB.
- The volume descriptors start at sector 16.
- There can be multiple volume descriptors.
- Each volume descriptor is one sector long.
- A volume descriptor can be either a boot record, a primary volume descriptor, 
a supplementary volume descriptor (for Joliet), a volume partition descriptor, 
or a volume descriptor set terminator.
- The list of volume descriptors have to be terminated by a volume descriptor 
set terminator.

- The primary volume descriptor contains the volume identifier at offset 40, 
length 32 Byte.

See also 
.

Re: [PATCH] doc: Fix spelling.

[Maxim Cournoyer]

Hi Ricardo!

On April 27, 2017 8:28:25 AM PDT, Ricardo Wurmus  wrote:
>* doc/cuirass.texi (Introduction): Fix typo and use American English
>spelling.
>---
> doc/cuirass.texi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/doc/cuirass.texi b/doc/cuirass.texi
>index e5f29a6..ff5f7b0 100644
>--- a/doc/cuirass.texi
>+++ b/doc/cuirass.texi
>@@ -70,7 +70,7 @@ Reference sections:
> @dfn{Cuirass} is a general-purpose build automation server that checks
> out source files from @acronym{VCS, Version Control System}
> repositories, executes a @dfn{build job}, and notifies the results of
>-that job.  A build job consists of a combinaison of tasks such as
>+that job.  A build job consists of a combination of tasks such as
> compiling source code to binary code and running automated tests.
> Notification is achieved by using a database that stores the build
>results associated with an HTTP server that provides a convenient way
>to
>@@ -102,7 +102,7 @@ basis of the @dfn{Continuous integration} practice.
>@command{cuirass} acts as a daemon polling @acronym{VCS, version
>control
> system} repositories for changes, and evaluating a derivation when
> something has changed (@pxref{Derivations, Derivations,, guix, Guix}).
>-As a final step the derivation is realised and the result of that
>build
>+As a final step the derivation is realized and the result of that

Earlier we used *results* (plural). I think both are OK but we should harmonize.

>build
> allows you to know if the job succeed or not.

succeeded

> 
> What is actually done by @command{cuirass} is specified in a @dfn{job

The rest LGTM.

Re: We need an RFC procedure [Re: Services can now have a default value]

[Petter]

If I may make a suggestion, coming from a place of ignorance.

How about a stable branch that would be opt-in?

On Thu, 27 Apr 2017 15:29:53 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Ricardo Wurmus  skribis:
> 
> > It’s a little unfortunate that packages are developed together with
> > everything else, because this means that there is no way for people to
> > opt out of breaking changes until the next release without also opting
> > out of getting any updates at all.  
> 
> It’s both a strength and a weakness I guess.  The good thing is that we
> can make changes that affect everything at once.  The bad thing is what
> you mention.
> 
> We could use feature branches more, with the downside that they would
> probably get little additional testing, precisely because one would have
> to choose between features and packages.
> 
> Thoughts?
> 
> Ludo’.
> 

[PATCH] doc: Fix spelling.

[Ricardo Wurmus]

* doc/cuirass.texi (Introduction): Fix typo and use American English spelling.
---
 doc/cuirass.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/cuirass.texi b/doc/cuirass.texi
index e5f29a6..ff5f7b0 100644
--- a/doc/cuirass.texi
+++ b/doc/cuirass.texi
@@ -70,7 +70,7 @@ Reference sections:
 @dfn{Cuirass} is a general-purpose build automation server that checks
 out source files from @acronym{VCS, Version Control System}
 repositories, executes a @dfn{build job}, and notifies the results of
-that job.  A build job consists of a combinaison of tasks such as
+that job.  A build job consists of a combination of tasks such as
 compiling source code to binary code and running automated tests.
 Notification is achieved by using a database that stores the build
 results associated with an HTTP server that provides a convenient way to
@@ -102,7 +102,7 @@ basis of the @dfn{Continuous integration} practice.
 @command{cuirass} acts as a daemon polling @acronym{VCS, version control
 system} repositories for changes, and evaluating a derivation when
 something has changed (@pxref{Derivations, Derivations,, guix, Guix}).
-As a final step the derivation is realised and the result of that build
+As a final step the derivation is realized and the result of that build
 allows you to know if the job succeed or not.
 
 What is actually done by @command{cuirass} is specified in a @dfn{job
-- 
2.12.2

OnApp Clouds [Fwd: [Ticket ID: 985993] Question on behalf of GNU Guix regarding special requirements of Orangewebsite VPS]

[ng0]

Hi,

clouds are everywhere and this one wasn't mentioned here before so I have to 
ask.
We need to teach our GuixSD how to fly among these systems.
The skill we need to learn this time is "OnApp".
Has anyone used it before? I'm totally unaware of most cloud solutions as
I'm not professionally involved with cloudy stuff at this moment.

According to the OnApp website it seems to be rather big, but maybe 1 million 
instances
isn't that much in cloudland.

This one (Orangewebsite) is also theoretic unless I can afford to rent
some more servers for testing.

- Forwarded message from "OrangeWebsite.com Technical Support - Level 3" 
-

> Date: Thu, 27 Apr 2017 04:42:35 +
> From: "OrangeWebsite.com Technical Support - Level 3"
> To: "Privacy Department (OrangeWebsite.com)"
> Subject: [Ticket ID: 985993] Question on behalf of GNU Guix regarding special 
> requirements of Orangewebsite VPS
> X-Mailer: OrangeWebsite.com
> 
> Hello,
> 
> our VPS using OnApp ( https://onapp.com
> 
> Also yes we can manually also add custom OS, but mostly these have not been 
> working if there is no support for kvm or onapp.
> 
> Example: http://templates.repo.onapp.com
> 
> Best greetings,
> J. J. Karppinen
> Customer Support Representative
> OrangeWebsite.com - 'Your solid partner in business'
> 
> 
> 
> 
> 
> 
> 
[snip]

- End forwarded message -

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

Re: store reference detection

[Thomas Danckaert]

From: l...@gnu.org (Ludovic Courtès)
Subject: Re: store reference detection (was Re: JARs and reference 
scanning)

Date: Thu, 27 Apr 2017 15:46:59 +0200


Really? Qt/WxWidgets “hide” store references by default?


Not by default.  But there are cases were I've been bitten:

 - Qt has a “QStringLiteral”, which transforms your character literal
   to a UTF-16-encoded string at compile-time.  For example the
   kdbusaddons source used such a literal to encode the kdeinit5
   executable.  (In this case I patched the code, replacing it by a
   regular string.)

 - Similarly, when I packaged DVDStyler (a wxWidgets program), I
   noticed it also uses wchar_t strings to encode the name of
   executables.  (Here I used wrap-program to set the PATH, instead 
of

   embedding the full store location of the executables)


Does it make sense to expand the reference detecting code (perhaps
this would lead to too many different special cases?), or maybe
provide a mechanism to force references when the daemon cannot 
detect
them.  I suppose you can always add a text file with a list of 
store

items to the output, but maybe there's a more elegant way?


‘propagated-inputs’ is one way to manually specify run-time 
references.
It works at the package level and not at the store level—that is, 
the

store item’s references are unaffected by what ‘propagated-inputs’
contains.  It’s usually enough for our purposes though.

In that sense, I think jars are comparable to Python/Perl libraries,
which do not carry reference information by themselves and thus 
need a

manually-provided ‘propagated-inputs’.


I think it's nice to avoid propagated inputs if possible, because 
they pollute the profile with things the user didn't strictly as for. 
So Hartmuts proposed workaround (embed dependencies in the .jar's, 
if it's really possible, and use a .deps text file in the store to 
enable reference detection) sounds better.


Thomas

Re: Guile 2.2 .go files are larger

[Ludovic Courtès]

Hi!

Andy Wingo  skribis:

> On Sat 22 Apr 2017 15:19, l...@gnu.org (Ludovic Courtès) writes:
>
>> The closure of Guix built with 2.0 is 193.8 MiB; when built with 2.2,
>> it’s 311.8 MiB.  Guix itself goes from 66 to 150 MiB:
>>
>> $ du -ms 
>> /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.0-9.25a4/lib/guile/2.2
>> 101  
>> /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.0-9.25a4/lib/guile/2.2
>> $ du -ms 
>> /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/lib/guile/2.0
>> 24   
>> /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/lib/guile/2.0
>
> Before we begin, some general notes.  My understanding is that the heap
> usage corresponding to an individual Guix process will be lower, both
> due to allocation of read-only data in read-only, shareable sections of
> the .go ELF files, allocation of read-write data in packed sections
> known to the GC but not managed by GC, and various optimizations that
> can eliminate or simplify some heap allocations (closure optimization
> among them).  In short my understanding is that Guile 2.2 (and systems
> built on it) should have a smaller run-time footprint than Guile 2.2.

Yes of course.

>> Would you have any suggestions to shrink the ELF files a bit?
>
> Why?  Have you compared gzipped or lzipped sizes?  I don't want to put
> effort in here that's not worth it :)

--8<---cut here---start->8---
$ du -ms $(./pre-inst-env guix pack guile@2.0)
35  /gnu/store/25ppdmridc8i1j771s9c498y1sr9xfzb-tarball-pack.tar.gz
$ du -ms $(./pre-inst-env guix pack guile@2.2)
40  /gnu/store/3fkhdpfpjjn8088fs0dxgb6hi38ac46m-tarball-pack.tar.gz
--8<---cut here---end--->8---

(Of course the difference is also due to the additional source code in
2.2.)

> Part of it is that our page alignment is 64 kB and so average wasteage
> per .go is 32kB, and there are a lot of .go files.  These are just zero
> bytes though.

OK.  It might be that file systems can store sparse files reasonably
efficiently.

> If you look at an individual file, you can use readelf to see things, or
> that old ELF visualizer I wrote:
>
>   https://wingolog.org/elf-mapper/
>
> Here's a map of gnu/packages/curl.go:
>
>   https://wingolog.org/pub/elf/elf-JWXYrI.png
>
> I think stripping the .debug_* stuff won't get you much of anywhere.
>
> Stripping arities info could reduce size by 10%.  We could figure out a
> different way to represent arities that takes less space.
>
> Compiling all the .go files together (requires Guile hacking) could
> remove that per-go 64kB alignment overhead.  Alternately we could do
> what GNU tools / ld.so do which maps the linear sequence of bytes in the
> file to aligned segments in memory.
>
> Honestly though I would punt.  It's not a run-time issue.  I don't think
> it's a transport issue.  It's only a disk space issue.  I personally
> don't plan to spend time on it but am happy to point out possibilities
> to people that will do so.

Sure, I understand.  I was just wondering if there was some low-hanging
fruit here.

Thanks for your feedback!

Ludo’.

Re: store reference detection (was Re: JARs and reference scanning)

[Ludovic Courtès]

Hello,

Thomas Danckaert  skribis:

> From: Chris Marusich 
> Subject: Re: JARs and reference scanning
> Date: Tue, 25 Apr 2017 22:34:02 -0700
>
>>> I have to admit that I do not know at all how the reference
>>> scanning and
>>> dependency-tracking in the store works.
>>
>> As I understand it, the mechanism used by the Guix daemon (and the
>> Nix
>> daemon) for scanning references doesn't work when the output of a
>> derivation is scrambled in some way (e.g. compressed).  Therefore,
>> if we
>> use JAR files, they should not be compressed.
>
> The code scanning for reference is in nix/libstore/references.cc .  It
> looks for base32 hashes encoded as character strings in the binaries.
>
> Could/should this be generalized somehow?  Apart from compression,
> store filenames encoded with 16-bit character encodings also cause
> problems (can happen with Qt or WxWidgets).  And the are probably more
> cases where it fails.

Really? Qt/WxWidgets “hide” store references by default?

> Does it make sense to expand the reference detecting code (perhaps
> this would lead to too many different special cases?), or maybe
> provide a mechanism to force references when the daemon cannot detect
> them.  I suppose you can always add a text file with a list of store
> items to the output, but maybe there's a more elegant way?

‘propagated-inputs’ is one way to manually specify run-time references.
It works at the package level and not at the store level—that is, the
store item’s references are unaffected by what ‘propagated-inputs’
contains.  It’s usually enough for our purposes though.

In that sense, I think jars are comparable to Python/Perl libraries,
which do not carry reference information by themselves and thus need a
manually-provided ‘propagated-inputs’.

WDYT?

Ludo’.

Re: GuixSD bootable ISO-9669 image

[Ludovic Courtès]

Hello!

Chris Marusich  skribis:

> Chris Marusich  writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
 There appear to be (at least) two problem that prevent this naive
 solution from working, which might point us in the right direction:

 First, the GRUB menu is trying to find a file system with label
 "gnu-disk-image" (via "search --label --set gnu-disk-image"), which
 won't work because there is no file system with that label in the
 resulting image.
>>>
>>> So it seems that the crux of the problem is that ISO9660 lacks file
>>> system labels, which breaks the whole thing, right?
>>
>> Yes, probably.  It seems we can set a "volume id", but not a label like
>> in EXT file systems.  For example, see here:
>>
>> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/cd-dvd/iso-image.nix
>
> I discovered that grub-mkrescue also lets you pass through options to
> xorriso.  So, you can set the volume ID as follows:
>
> $ sudo grub-mkrescue -V gnu-disk-image -v -o /tmp/test-img.iso 
> /mnt/disk-image-partition-1
> ...
> grub-mkrescue: info: enabling BIOS support 
> grub-mkrescue: info: grub-mkimage --directory 
> '/gnu/store/2hxz9cpipsbf2hkiz5aq70k73wjj0fw1-grub-2.02rc1/lib/grub/i386-pc' 
> --prefix '/boot/grub' --output 
> '/tmp/grub.zilpbK/boot/grub/i386-pc/eltorito.img' --format 'i386-pc-eltorito' 
> --compression 'auto'  --config '/tmp/grub.N4OuA5' 'biosdisk' 'iso9660' 
> ...
> grub-mkrescue: info: executing xorriso -as mkisofs -graft-points 
> --modification-date=2017042404413800 -b boot/grub/i386-pc/eltorito.img 
> -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info 
> --grub2-mbr 
> /gnu/store/2hxz9cpipsbf2hkiz5aq70k73wjj0fw1-grub-2.02rc1/lib/grub/i386-pc/boot_hybrid.img
>  --protective-msdos-label -o /tmp/test-img.iso -r /tmp/grub.zilpbK 
> --sort-weight 0 / --sort-weight 1 /boot -V gnu-disk-image 
> /mnt/disk-image-partition-1.
> ...
> xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
> ...
> Writing to 'stdio:/tmp/test-img.iso' completed successfully.
>
>
> Looks like setting the volume ID worked (despite the warning above):
>
> $ sudo blkid /tmp/test-img.iso
> /tmp/test-img.iso: UUID="2017-04-24-04-41-38-00" LABEL="gnu-disk-image" 
> TYPE="iso9660" PTTYPE="dos"

Excellent.  So we would first need to add support for reading ISO9660
labels in (gnu build file-systems), which is what we use instead of
libblkid.  With that in place, we should be almost done.

Ludo’.

Re: Defining user services in Guix.

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

> Mekeor Melire  writes:

[...]

>> And secondly, each user could have a user.scm e.g. like
>>
>> (user-configuration
>> ; ...
>> (aliases
>> '(
>> ("sysrec" "system reconfigure")
>> ("pl" "pull")
>> ; ...
>> ))
>> (services
>> (emacs-daemon-service)
>> (dzen-service)
>> ; ...
>> ))
>>
>> or similar :)
>
> While I’m not a fan of Guix-specific aliases, I think it’s not a bad
> idea to use Guix for user configurations.  I’m tired of having to keep
> track of a set of custom configuration files scattered all over the
> place, but I’m not sure how to approach this without going overboard.
>
> To stay on the topic of user services: I think they do have a place in
> Guix and could be defined with the same mechanisms that we have for
> system services.

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).

For non-Shepherd things, the benefits are less obvious to me.  For
instance, having ~/.bashrc be a simply to /gnu/store/…-bashrc is not
significantly better to having ~/.bashrc link to
~/directory-under-version-control/bashrc.

Anyway, food for thought!

Ludo’.

Re: We need an RFC procedure [Re: Services can now have a default value]

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> It’s a little unfortunate that packages are developed together with
> everything else, because this means that there is no way for people to
> opt out of breaking changes until the next release without also opting
> out of getting any updates at all.

It’s both a strength and a weakness I guess.  The good thing is that we
can make changes that affect everything at once.  The bad thing is what
you mention.

We could use feature branches more, with the downside that they would
probably get little additional testing, precisely because one would have
to choose between features and packages.

Thoughts?

Ludo’.

Re: ‘guix pull’ vs. transition to Guile 2.2

[Ludovic Courtès]

Jan Nieuwenhuizen  skribis:

> Ludovic Courtès writes:
>
>> Thoughts? Ideas?
>
> Great!  With this patch applied to master I get
>
> 
> Testsuite summary for GNU Guix 0.12.0
> 
> # TOTAL: 701
> # PASS:  573
> # SKIP:  34
> # XFAIL: 0
> # FAIL:  94
> # XPASS: 0
> # ERROR: 0
>
> Are you [all] running core-updates?  Should I be?

‘core-updates’ is still in its early stages, I bet nobody runs it.  :-)

I haven’t checked whether I get those test failures though.

Ludo’.

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

[Ricardo Wurmus]

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.

>From 3fb7b9cce90649dc880eb23e022a6a22efada657 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Wed, 26 Oct 2016 09:56:33 +0200
Subject: [PATCH 1/9] WIP

---
 guix/upstream.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/guix/upstream.scm b/guix/upstream.scm
index a47a52be3..6ceb7881a 100644
--- a/guix/upstream.scm
+++ b/guix/upstream.scm
@@ -269,6 +269,8 @@ if an update was made, and #f otherwise."
 ;; thereof).
 (let ((old-hash (bytevector->nix-base32-string old-hash))
   (hash (bytevector->nix-base32-string hash)))
+  ;; TODO: be smart and don't replace accidental matches, e.g. in "sha256"
+  ;; or in the description.  Only replace in the "version" field.
   (string-replace-substring
(string-replace-substring expr old-hash hash)
old-version version)))
-- 
2.12.2

>From 4fccff582967c475e92a2150f3fd784f223b524c Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Tue, 25 Oct 2016 21:49:10 +0200
Subject: [PATCH 2/9] refresh: Suggest changes to inputs when updating.

* guix/scripts/refresh.scm (updater->importer-info): New procedure.
(mock): New syntax rule.
(update-package): Run matching importer to suggest changes to inputs.
---
 guix/scripts/refresh.scm | 98 +++-
 1 file changed, 97 insertions(+), 1 deletion(-)

diff --git a/guix/scripts/refresh.scm b/guix/scripts/refresh.scm
index 4d3c695aa..3487685d3 100644
--- a/guix/scripts/refresh.scm
+++ b/guix/scripts/refresh.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2014 Eric Bavier 
 ;;; Copyright © 2015 Alex Kost 
 ;;; Copyright © 2016 Ben Woodcroft 
+;;; Copyright © 2016 Ricardo Wurmus 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -213,6 +214,35 @@ unavailable optional dependencies such as Guile-JSON."
  ((guix import github) => %github-updater)
  ((guix import crate) => %crate-updater)))
 
+(define (updater->importer-info updater-name)
+  "Return a list containing an update procedure, a package name converter,
+and, optionally, an archive symbol for the given UPDATER-NAME.  Return #F for
+an unknown updater."
+  (case updater-name
+((gnu)
+ (list gnu->guix-package
+   package-name))
+((elpa)
+ (list elpa->guix-package
+   package-name))
+((cran)
+ (list cran->guix-package
+   (@@ (guix import cran) package->upstream-name)))
+((bioconductor)
+ (list cran->guix-package
+   (@@ (guix import cran) package->upstream-name)
+   'bioconductor))
+((hackage)
+ (list hackage->guix-package
+   (@@ (guix import gem) guix-package->hackage-name)))
+((pypi)
+ (list pypi->guix-package
+   guix-package->pypi-name))
+((gem)
+ (list gem->guix-package
+   (@@ (guix import gem) guix-package->gem-name)))
+(else #f)))
+
 (define (lookup-updater-by-name name)
   "Return the updater called NAME."
   (or (find (lambda (updater)
@@ -253,6 +283,17 @@ unavailable optional dependencies such as Guile-JSON."
   (location->string (package-location package))
   (package-name package)))
 
+;; FIXME: copied from (guix tests)
+(define-syntax-rule (mock (module proc replacement) body ...)
+  "Within BODY, replace the definition of PROC from MODULE with the definition
+given by REPLACEMENT."
+  (let* ((m (resolve-module 'module))
+ (original (module-ref m 'proc)))
+(dynamic-wind
+  (lambda () (module-set! m 'proc replacement))
+  (lambda () body ...)
+  (lambda () (module-set! m 'proc original)
+
 (define* (update-package store package updaters
  #:key (key-download 'interactive) warn?)
   "Update the source file that defines PACKAGE with the new version.
@@ -276,7 +317,62 @@ warn about packages that have no 

Re: Planning for the next release

[Ricardo Wurmus]

Leo Famulari  writes:

> On Sat, Apr 22, 2017 at 12:27:11AM +0200, Ludovic Courtès wrote:
>> I’m going to be mostly away for a week, but it would be nice if we could
>> release after that, wouldn’t it?
>> 
>> I think we’ll have to postpone work on the installer though since that
>> would leave too little time now.
>> 
>> WDYT?
>
> Sounds good to me!

I also agree.  Looking forward to a new release!

-- 
Ricardo

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

Mes 0.5 released

[Jan Nieuwenhuizen]

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.

* About

Mes aims to create full source bootstrapping for GuixSD: an
entirely source-based bootstrap path.  The target is to [have
GuixSD] boostrap from a minimal, easily inspectable binary --that
should be readable as source-- into something close to R6RS
Scheme.

It currently consists of a mutual self-hosting [close to Guile-]
Scheme interpreter prototype in C and a Nyacc-based C compiler in
[Guile] Scheme.

The Scheme interpreter prototype (mes.c) has a Garbage Collector,
a library of loadable Scheme modules-- notably Dominique Boucher's
LALR[1], Pre-R6RS portable syntax-case[2] with R7RS ellipsis, Matt
Wette's Nyacc[3] Guile's PEG[4] --and test suite just barely
enough to support a simple REPL (repl.mes) and simple C-compiler
(mescc.mes) that can produce the second initial ELF binary from
binary from mes.c, in only about 2h30'.

Mes was inspired by The Maxwell Equations of Software: LISP-1.5[5]
-- John McCarthy page 13, GNU Guix's[6] source/binary packaging
transparency and Jeremiah Orians's stage0[7] bootstrap project.

* Download

git clone https://gitlab.com/janneke/mes

wget https://gitlab.com/janneke/mes/repository/archive.tar.gz?ref=v0.5 -O 
mes-0.5.tar.gz

Mes runs from the source tree and can also be built, packaged and
installed in Guix[SD] by the usual

guix package -f guix.scm

* Changes in 0.5 since 0.4
 ** Core
 *** Support compilation with Mescc.
 *** Support compilation with -nostdinc, -nostdlib using mlibc.
 *** Support call-with-current-continuation.
 *** Support exception handling, catch/throw.
 *** Give sensible error message when a macro is missing.
 ** Language
 *** Map now supports 4 lists.
 *** The reader supports negative hex numbers.
 *** 24 new functions
 access?, assoc-set! cr, compose, list->char-set,
 open-input-string, read-string, string-delete, with-throw-handler.
 ** Mescc
 *** Mescc can be used separately as a Nyacc-based C compiler backend for Guile.
 *** Switch to Nyacc frontend, update Nyacc to 0.76.5.
 *** Mescc now has a test suite, scaffold/t.c.
 *** Mescc now includes a minimal C library: libc/mlib.c libc/mstart.c.
 *** Mescc can now compile mes.c.
 ** Noteworthy bug fixes
 *** The build system (configure, make) has been refactored.
 *** Support map-4.
 *** Evaluate arguments of OR only once.
 *** Fix assq-set!
 *** Fix ,expand in the REPL.

Greetings,
janneke

[1] https://github.com/schemeway/lalr-scm
[2] https://www.cs.indiana.edu/chezscheme/syntax-case/old-psyntax.html
[3] https://www.nongnu.org/nyacc/
[4] https://www.gnu.org/software/guile/docs/master/guile.html/PEG-Parsing.html
[5] 
http://www.softwarepreservation.org/projects/LISP/book/LISP%25201.5%2520Programmers%2520Manual.pdf
[6] https://www.gnu.org/software/guix/
[7] https://github.com/oriansj/stage0

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

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

[Roel Janssen]

Ricardo Wurmus writes:

> Roel Janssen  writes:
>
>> From de9f486828827b1d024cad4918eed3ed96202cc0 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen 
>> Date: Wed, 26 Apr 2017 10:30:52 +0200
>> Subject: [PATCH] import: Update Bioconductor release to 3.5.
>>
>> * guix/import/cran.scm: Change Bioconductor release to 3.5.
>>  guix/import/cran.scm | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Excellent!  I planned to do this next week, but I’m glad you beat me to
> it :)

Awesome.  Good that I can finally help by taking some of the work. :)

>>
>> +(define-public r-bookdown
>> +  (package
>> +  (name "r-bookdown")
>> +  (version "0.3")
>> +  (source (origin
>> +(method url-fetch)
>> +(uri (cran-uri "bookdown" version))
>> +(sha256
>> + (base32
>> +  "0r9bchzg7im6psc3jphvshzbidc5bv5xaih1qg7b5518jy4iyvb9"
>> +  (build-system r-build-system)
>> +  (propagated-inputs
>> +   `(("r-htmltools" ,r-htmltools)
>> + ("r-knitr" ,r-knitr)
>> + ("r-rmarkdown" ,r-rmarkdown)
>> + ("r-yaml" ,r-yaml)))
>> +  (home-page "https://github.com/rstudio/bookdown;)
>> +  (synopsis "Authoring books and technical documents with R markdown")
>> +  (description "This package provides output formats and utilities for
>> +authoring books and technical documents with R Markdown.")
>> +  (license license:gpl3)))
>> +
>
> LGTM.  Sadly, it does indeed seem to be GPLv3 only.
>
>> From f661fce758f3f051f4f951c4c7384c69268169d9 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen 
>> Date: Wed, 26 Apr 2017 11:02:28 +0200
>> Subject: [PATCH] gnu: Add r-delayedarray.
>>
>> * gnu/packages/bioinformatics.scm (r-delayedarray): New variable.
> […]
>> +(define-public r-delayedarray
>> +  (package
>> +(name "r-delayedarray")
>> +(version "0.2.0")
>> +(source (origin
>> +  (method url-fetch)
>> +  (uri (bioconductor-uri "DelayedArray" version))
>> +  (sha256
>> +   (base32
>> +"0pcsk0f2dg2ldzprs1cccqrk53jrysmm6ccgjj5wh6z3x17g7g2r"
>> +(properties
>> + `((upstream-name . "DelayedArray")))
>> +(build-system r-build-system)
>> +(propagated-inputs
>> + `(("r-biocgenerics" ,r-biocgenerics)
>> +   ("r-s4vectors" ,r-s4vectors)
>> +   ("r-iranges" ,r-iranges)
>> +   ("r-matrixstats" ,r-matrixstats)))
>> +(home-page "http://bioconductor.org/packages/DelayedArray;)
>> +(synopsis "Delayed operations on array-like objects")
>> +(description
>> + "Wrapping an array-like object (typically an on-disk object) in a
>> +DelayedArray object allows one to perform common array operations on
>> it
>
> @code{DelayedArray}
>
>> +without loading the object in memory.  In order to reduce memory usage
>> +and optimize performance, operations on the object are either delayed
>> +or executed using a block processing mechanism.  Note that this also
>> +works on in-memory array-like objects like DataFrame objects
>> (typically
>
> @code{DataFrame}
>
>> +with Rle columns), Matrix objects, and ordinary arrays and data frames.")
>> +(license license:artistic2.0)))
>> +
>
> Okay with these changes.

Great!

>> From d4313b287e05efcf54f87160d6e34ea60bfbadf6 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen 
>> Date: Wed, 26 Apr 2017 11:01:23 +0200
>> Subject: [PATCH] gnu: Add r-genomeinfodbdata.
>>
>> * gnu/packages/bioinformatics.scm (r-genomeinfodbdata): New variable.
>> ---
> […]
>
>> +(define-public r-genomeinfodbdata
>> +  (package
>> +(name "r-genomeinfodbdata")
>> +(version "0.99.0")
>> +(source (origin
>> +  (method url-fetch)
>> +  (uri (bioconductor-uri "GenomeInfoDbData" version))
>> +  (sha256
>> +   (base32
>> +"120qvhb0pvkzd65lsgja62vyrgc37si6fh68q4cg4w5x9f04jw25"
>> +(properties
>> + `((upstream-name . "GenomeInfoDbData")))
>> +(build-system r-build-system)
>> +(home-page "http://bioconductor.org/packages/GenomeInfoDbData;)
>> +(synopsis "Species and taxonomy ID look up tables for GenomeInfoDb")
>> +(description
>> + "This package contains data for mapping between NCBI taxonomy ID and
>> +species.  It is used by functions in the GenomeInfoDb package.")
>> +(license license:artistic2.0)))
>> +
>
> LGTM!
>
> 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 

Re: Memory Usage

[Maxim Cournoyer]

Hello Rodger,

Rodger Fox  writes:

> Thanks for the feedback on this. I think it was just my mistake.
> This is what I was looking at: GiB Mem : 16.6/2.929
> After using 'free', which gives more reasonable output, I think top is
> reporting a percentage. I never realized that, and it seems unintuitive,
> given the units it displays, but this is not a Guix issue, just my own
> mistake in what I was reading.

I think it is only unintuitive because this was changed in a recent
version of top. You can press 'm' twice to display the memory values
instead of percentage, or '?' to learn about the different toggles.

Maxim


signature.asc
Description: PGP signature

Re: Helping with Guix on Hurd: my notes

[Jan Nieuwenhuizen]

Maxim Cournoyer writes:

H! Maxim

> Thank you Jan for sharing these precious notes!

At FOSDEM'17, Manolis [cc] inspired me with his talk to have a look at
HURD and help.

Sadly, the above recipe is all the help I found to offer until now, but hey.

> I've saved your message; I had started looking into Hurd last year, but
> then turned my attention to Guix and have been (slowly) making myself at home 
> here. I
> intend to restart investigating Hurd as things stabilize on the Guix
> side :). They are destined to work together anyway ;)

That's how I feel too.  Guix should make working together on a project
like Hurd a lot easier.

I'm sure the recipe has bitrotten a bit, esp. names of branches and
hashes; it would be great if you could try it and help keep it up to
date.

Greetings--janneke

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

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

[Ricardo Wurmus]

Roel Janssen  writes:

> From de9f486828827b1d024cad4918eed3ed96202cc0 Mon Sep 17 00:00:00 2001
> From: Roel Janssen 
> Date: Wed, 26 Apr 2017 10:30:52 +0200
> Subject: [PATCH] import: Update Bioconductor release to 3.5.
>
> * guix/import/cran.scm: Change Bioconductor release to 3.5.
>  guix/import/cran.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Excellent!  I planned to do this next week, but I’m glad you beat me to
it :)

>
> +(define-public r-bookdown
> +  (package
> +  (name "r-bookdown")
> +  (version "0.3")
> +  (source (origin
> +(method url-fetch)
> +(uri (cran-uri "bookdown" version))
> +(sha256
> + (base32
> +  "0r9bchzg7im6psc3jphvshzbidc5bv5xaih1qg7b5518jy4iyvb9"
> +  (build-system r-build-system)
> +  (propagated-inputs
> +   `(("r-htmltools" ,r-htmltools)
> + ("r-knitr" ,r-knitr)
> + ("r-rmarkdown" ,r-rmarkdown)
> + ("r-yaml" ,r-yaml)))
> +  (home-page "https://github.com/rstudio/bookdown;)
> +  (synopsis "Authoring books and technical documents with R markdown")
> +  (description "This package provides output formats and utilities for
> +authoring books and technical documents with R Markdown.")
> +  (license license:gpl3)))
> +

LGTM.  Sadly, it does indeed seem to be GPLv3 only.

> From f661fce758f3f051f4f951c4c7384c69268169d9 Mon Sep 17 00:00:00 2001
> From: Roel Janssen 
> Date: Wed, 26 Apr 2017 11:02:28 +0200
> Subject: [PATCH] gnu: Add r-delayedarray.
>
> * gnu/packages/bioinformatics.scm (r-delayedarray): New variable.
[…]
> +(define-public r-delayedarray
> +  (package
> +(name "r-delayedarray")
> +(version "0.2.0")
> +(source (origin
> +  (method url-fetch)
> +  (uri (bioconductor-uri "DelayedArray" version))
> +  (sha256
> +   (base32
> +"0pcsk0f2dg2ldzprs1cccqrk53jrysmm6ccgjj5wh6z3x17g7g2r"
> +(properties
> + `((upstream-name . "DelayedArray")))
> +(build-system r-build-system)
> +(propagated-inputs
> + `(("r-biocgenerics" ,r-biocgenerics)
> +   ("r-s4vectors" ,r-s4vectors)
> +   ("r-iranges" ,r-iranges)
> +   ("r-matrixstats" ,r-matrixstats)))
> +(home-page "http://bioconductor.org/packages/DelayedArray;)
> +(synopsis "Delayed operations on array-like objects")
> +(description
> + "Wrapping an array-like object (typically an on-disk object) in a
> +DelayedArray object allows one to perform common array operations on
> it

@code{DelayedArray}

> +without loading the object in memory.  In order to reduce memory usage
> +and optimize performance, operations on the object are either delayed
> +or executed using a block processing mechanism.  Note that this also
> +works on in-memory array-like objects like DataFrame objects
> (typically

@code{DataFrame}

> +with Rle columns), Matrix objects, and ordinary arrays and data frames.")
> +(license license:artistic2.0)))
> +

Okay with these changes.

> From d4313b287e05efcf54f87160d6e34ea60bfbadf6 Mon Sep 17 00:00:00 2001
> From: Roel Janssen 
> Date: Wed, 26 Apr 2017 11:01:23 +0200
> Subject: [PATCH] gnu: Add r-genomeinfodbdata.
>
> * gnu/packages/bioinformatics.scm (r-genomeinfodbdata): New variable.
> ---
[…]

> +(define-public r-genomeinfodbdata
> +  (package
> +(name "r-genomeinfodbdata")
> +(version "0.99.0")
> +(source (origin
> +  (method url-fetch)
> +  (uri (bioconductor-uri "GenomeInfoDbData" version))
> +  (sha256
> +   (base32
> +"120qvhb0pvkzd65lsgja62vyrgc37si6fh68q4cg4w5x9f04jw25"
> +(properties
> + `((upstream-name . "GenomeInfoDbData")))
> +(build-system r-build-system)
> +(home-page "http://bioconductor.org/packages/GenomeInfoDbData;)
> +(synopsis "Species and taxonomy ID look up tables for GenomeInfoDb")
> +(description
> + "This package contains data for mapping between NCBI taxonomy ID and
> +species.  It is used by functions in the GenomeInfoDb package.")
> +(license license:artistic2.0)))
> +

LGTM!

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.

--
Ricardo

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

Re: Staging merged!

[Ricardo Wurmus]

Leo Famulari  writes:

> On Tue, Apr 25, 2017 at 02:33:13PM -0400, Leo Famulari wrote:
>> I just merged master into staging and started a new evaluation. Barring
>> any new complications, I plan to merge staging into master later today.
>
> I merged the staging branch into the master branch as
> 2018eea07bb00663d2f0cec9d9085d51afa4513b and started a new evaluation.
> Most of the substitutes should already be available.
>
> Some notable changes are updates to mesa, xorg-server, gtk+, and tzdata.
>
> Thanks to Marius for working on the branch!

Yay, thanks a lot for taking care of this!

-- 
Ricardo

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

Re: Helping with Guix on Hurd: my notes

[Maxim Cournoyer]

Thank you Jan for sharing these precious notes!

I've saved your message; I had started looking into Hurd last year, but
then turned my attention to Guix and have been (slowly) making myself at home 
here. I
intend to restart investigating Hurd as things stabilize on the Guix
side :). They are destined to work together anyway ;)

Maxim


signature.asc
Description: PGP signature