Re: [PATCH] guix package: Export generation procedures.

[Ludovic Courtès]

Hi!

Alex Kost  skribis:

> What about the attached patch?  Some comments and questions:
>
> - I added 'store' argument to the exported procedures, however it is
>   used only in one particular case: when we need to create an empty
>   profile (i.e. to call ‘link-to-empty-profile’).  Is there a way to
>   avoid using 'store' argument there or is it fine to leave it like
>   this?

For now it’s fine to leave it like this, with the ‘store’ argument.
Eventually it should be changed to use the monadic style, though.

> - I actually need only ‘delete-generations’ procedure for Emacs UI, but
>   I think other procedures are also worth to be exported or not?

Yes, sure.

> - Perhaps there is a better place for those functions than
>   (guix scripts package)?

Yes, (guix profiles) would be a better place IMO.

> - (Not related to this patch, but still …)  Currently with “roll-back”,
>   we can only switch to the previous generation.  What about adding a
>   possibility to switch to any generation?  So that we could use
>   something like this:
>
> guix package --switch-generation=7
>
>   Also such functionality can be added to Emacs UI: for example pressing
>   "C" on a generation in *Guix Generation List* will make this
>   generation the current one.
>
>   So ‘roll-back’ procedure may become a special case of the
>   ‘switch-generation’ one.  WDYT?

I think it’s a good idea!  (I think it was suggested in earlier
discussions, but never implemented.)

> From c50d1674d3be699198afb649a2a9932ca44c89bc Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sat, 4 Oct 2014 20:45:35 +0400
> Subject: [PATCH] guix package: Export generation procedures.
>
> * guix/scripts/package.scm: Export 'roll-back', 'delete-generation',
>   'delete-generations'.
>   (link-to-empty-profile, roll-back): Add 'store' argument.
>   (delete-generations): New procedure.
>   (guix-package): Adjust accordingly.
>   [delete-generation]: Move to the top level.  Add 'store' and 'profile'
>   arguments.
>   [display-and-delete]: Move to 'delete-generation'.

OK to commit.

To sum up, I would imagine two followups to this:

  1. Move these procedures to (guix profiles).
  2. Convert them to monadic style.

WDYT?

Thanks,
Ludo’.

Re: GUIX 0.7 under QEMU/KVM with virtio

[Ludovic Courtès]

Hi, Assaf,

Assaf Gordon  skribis:

> First,
> I can provide another recipe:

Thanks for the recipe.  We should probably add a subsection on how to
install to a VM image in the manual.  Would you like to amend guix.texi
for that?

> Second,
> I can confirm Nate's observation that using QEMU's "-usbdrive" option for the 
> USB image causes everything to be VERY slow.
> not sure why.
> Using "-hda" for the USB image is much better.

Weird, no idea either.

> Third,
> After boot (before setup), I'm trying to get a login prompt on the serial 
> port (which QEMU's redirect to the terminal).
> I can do the following:
>echo "hello" > /dev/ttyS0   => appears on the terminal
>
> I can also boot with "console=ttyS0,9600n8" (in the GRUB command line), and 
> the kernel messages appear on the console.
> However, I can't get a login prompt on the serial console.
>
> I tried variations of:
>agetty -L 9600 ttyS0 linux
>
> But they all exit after a timeout of few seconds, and no prompt appears on 
> the serial console.
> Any ideas ?

I haven’t tried agetty, but it seems to have a hard-coded default login
program of “/bin/login”, which doesn’t exist here.  Could you try
invoking it with -l $(guix build shadow)/bin/login ?

Alternately you could try adding a mingetty service to the
configuration:

  (operating-system
...
(services (cons (mingetty-service "ttyS0")
%base-services)))

> Fourth,
> Sadly, after installation is complete, and after rebooting, the system fails 
> to load from "/dev/vda1" (drops to "early boot guile").
> Based on the kernel messages, it seems the "virtio_blk" driver is not loaded, 
> and so "/dev/vda" is not available.
> If I then switch QEMU parameters from "-drive if=virtio" to "-drive if=ide" 
> the system loads fine (also requires changing grub's "--root" parameter).
>
> Is there a way to fix this? force the kernel to load virto driver?

Currently all the drivers needed to mount the root partition must be
explicitly loaded in the initrd.  So yes, you would need to have the
virtio modules loaded from the initrd (info "(guix) Initial RAM Disk"):

  (operating-system
...
(initrd (lambda (file-systems . rest)
  (apply base-initrd file-systems
 #:extra-modules '("virtio.ko" "virtio_ring.ko"
   "virtio_blk.ko")
 rest

I think this should work.

Thanks for your feedback!

Ludo’.

Re: Enable debugging by default for CMake?

[Ludovic Courtès]

Andreas Enge  skribis:

> On Mon, Sep 29, 2014 at 10:43:27AM +0200, Ludovic Courtès wrote:
>> Apparently the default for CMake is to compile without -g, unlike what
>> Autoconf-generated configure does.  This is changed by passing
>> ‘-DCMAKE_BUILD_TYPE=RelWithDebInfo’ as a cmake flags.
>> Should we make it the default?
>
> I think this sounds like a good idea. Do you want to add it?

Yes, done in commit 9849cfc.  (This triggers a rebuild of all the
packages that use ‘cmake-build-system’.)

Ludo’.

Re: GUIX 0.7 under QEMU/KVM with virtio

[Ludovic Courtès]

Assaf Gordon  skribis:

> On 10/04/2014 04:42 PM, Ludovic Courtès wrote:
>
>>> Is there a way to fix this? force the kernel to load virto driver?
>>
>> Currently all the drivers needed to mount the root partition must be
>> explicitly loaded in the initrd.  So yes, you would need to have the
>> virtio modules loaded from the initrd (info "(guix) Initial RAM Disk"):
>>
>>(operating-system
>>  ...
>>  (initrd (lambda (file-systems . rest)
>>(apply base-initrd file-systems
>>   #:extra-modules '("virtio.ko" "virtio_ring.ko"
>> "virtio_blk.ko")
>>   rest
>  Two more things were needed:
> 1. adding"virtio_pci.ko" and "virtio_net.ko"  to the list of drivers.

OK.

> 2. Labeling "/dev/vda1" as "gnu-disk-image" (when doing "mkfs.ext4 -L").
>This wasn't needed to boot from "/dev/sda1", but was needed to use 
> "/dev/vda1".
>Perhaps some hard-coded thing ?

“gnu-disk-image” is the label of the root partition of the USB
installation image (see gnu/system/install.scm.)

However, the user’s root can carry any label, as long as the
corresponding ‘file-system’ declaration uses it.

> With these, the VM boots with virtio disk and network.

Good.

>> I haven’t tried agetty, but it seems to have a hard-coded default login
>> program of “/bin/login”, which doesn’t exist here.  Could you try
>> invoking it with -l $(guix build shadow)/bin/login ?
>>
>> Alternately you could try adding a mingetty service to the
>> configuration:
>>
>>(operating-system
>>  ...
>>  (services (cons (mingetty-service "ttyS0")
>>  %base-services)))
>>
>
> I still can't get serial console to work, perhaps needs more fidgeting.

Did you try agetty with -l as suggested above?

> Trying "mingetty ttyS0" from the command line fails with:
> ttyS0: no controlling tty: Operation not permitted

Is mingetty running as root here?  If it is, could you strace it to see
exactly what returns EPERM?

HTH,
Ludo’.

Re: [PATCH 1/1] gnu: add feh

[Ludovic Courtès]

I agree with Alex’s comments.  Ian, could you post an updated patch?

Alex Kost  skribis:

> Ian Denhardt (2014-10-05 07:32 +0400) wrote:

>> +(description (string-append
>> +   "feh is an X11 image viewer aimed mostly at console 
>> users. "
>> +   "Unlike most other viewers, it does not have a fancy 
>> GUI, "
>> +   "but simply displays images. It is controlled via "
>> +   "commandline arguments and configurable key/mouse 
>> actions."))
>
> This will make a long one-line description, which is not preferable.

Indeed.  In addition, it’s important for the description and synopsis to
be a string literal so that it can be picked up by xgettext and subject
to translation.

Ludo’.

Re: [PATCH] emacs: Add support for deleting generations.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-05 00:23 +0400) wrote:

[...]

>> To sum up, I would imagine two followups to this:
>>
>>   1. Move these procedures to (guix profiles).
>>   2. Convert them to monadic style.
>>
>> WDYT?
>
> I like the idea of using monads there, but as I said I'm too week (I
> mean "month" (I mean "weak")) for writing that.

Heh.  :-)  No problem, that can come later.

> Also those followups would make my commit totally redundant, no?
> Wouldn't it be better to make a commit for adding the monadic functions
> to (guix profiles) directly?

I think it’s fine to make changes incrementally.

> However if you still allow me to push this commit,

Sure!

> I think I can also push the attached one with the changes for Emacs UI
> now (if it looks OK for you).
>
>
> From c335cdf17a97d07cc3d4149fa7dc13882d16cc87 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sun, 5 Oct 2014 12:31:23 +0400
> Subject: [PATCH] emacs: Add support for deleting generations.
>
> * doc/emacs.texi (emacs List buffer): Mention new key bindings.
> * emacs/guix-base.el (guix-delete-generations): New procedure.
> * emacs/guix-info.el (guix-generation-info-insert-number): Use it.
> * emacs/guix-list.el (guix-generation-list-mark-delete,
>   guix-generation-list-execute): New procedures.
> * emacs/guix-main.scm (delete-generations*): New procedure.

Looks good!  Nitpicks:

> +@item x
> +Execute actions on the marked generations (i.e.@: delete generations).

I would make it:

  Execute actions on the marked generations---i.e., delete generations.

Or possibly a comma before “i.e.”.  Certainly a comma after it.

> --- a/emacs/guix-main.scm
> +++ b/emacs/guix-main.scm
> @@ -815,3 +815,9 @@ OUTPUTS is a list of package outputs (may be an empty 
> list)."
>"~a packages in profile~%"
>count)
> count)
> +
> +(define (delete-generations* profile generations)
> +  "Delete GENERATIONS from PROFILE.
> +GENERATIONS is a list of generation numbers."
> +  (let ((store (open-connection)))
> +(delete-generations store profile generations)))

Rather:

  (with-store store
(delete-generations store profile generations))

That will take care of closing ‘store’ when the dynamic extent of the
body is left.

Thanks,
Ludo’.

Re: [PATCH] emacs: Add support for deleting generations.

[Ludovic Courtès]

Alex Kost  skribis:

> Thanks for the comments, the updated patch is attached.  I also fixed
> another “i.e.” thing there and used ‘with-store’ in
> ‘process-package-actions’ procedure as well.  Is it OK to make these
> changes in this commit (the ‘with-store’ change is small but many lines
> were changed because of the new indentation)?

The ‘with-store’ change in ‘process-package-actions’ would be better in
a separate patch, because it fixes an unrelated file descriptor leak.

Other than that the patch looks good to me, thank you!

Ludo’.

Re: [PATCH] guix package: Export generation procedures.

[Ludovic Courtès]

Andreas Enge  skribis:

> So how about the following:
> --switch-generation=1
> goes to generation 1;
> --switch-generation=-1
> goes 1 generation back;
> --switch-generation=+1
> goes one generation forward.

Sounds like a good idea.

Ludo’.

Re: Bags

[Ludovic Courtès]

I’ve merged the ‘wip-bags’ branch (which means you’ll find yourself
downloading or rebuilding a number of things.)

Please report any test suite failure or other problem.

I would particularly welcome feedback from David wrt. the suitability
for ‘guix environment’.  :-)

Ludo’.

Re: [PATCH] emacs: Add support for deleting generations.

[Ludovic Courtès]

Alex Kost  skribis:

> Pushed, thanks.  Here is another patch for fixing ‘process-package-actions’.
>
>
> From 6ef2a8b88007840ffa6648563356021770bbb6e6 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sun, 5 Oct 2014 23:52:52 +0400
> Subject: [PATCH] emacs: Use 'with-store' in 'process-package-actions'.
>
> * emacs/guix-main.scm (process-package-actions): Use 'with-store'.

LGTM!

Ludo’.

Re: [PATCH 1/1] gnu: add feh

[Ludovic Courtès]

Ian Denhardt  skribis:

> * gnu/packages/feh.scm: New File

I pushed the patch with a slightly tweaked commit message (gnu-system.am
was not mentioned) and with:

> +(license x11-style)))

... this changed to:

+;; The license is really the Expat license, with additional wording in the
+;; 2nd paragraph: "acknowledgment shall be given in the documentation and
+;; software packages that this Software was used."
+(license (x11-style "file://COPYING"
+"See 'COPYING' in the distribution."

Because ‘x11-style’ is actually a procedure that returns a license.

Thanks!

Ludo’.

Re: [PATCH] gnu: libxdamage: Move inputs to propagated-inputs

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/xorg.scm (libxdamage): Move all existing inputs
>   to propagated-inputs.

OK!

> +(propagated-inputs  ; These are all in the Requires or Requires.private 
> field of xdamage.pc

Please make it a double-semicolon comment on the next line.

Thanks,
Ludo’.

Re: [PATCHv2 1/5] guix lint: make sure check-patches retrieves patch names.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> * guix/lint (check-patches): Test the output of origin-patches.

OK, please push.

Ludo’.

Re: [PATCH 3/5] guix lint: check whether descriptions and synopses start with an upper-case letter.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> On 09/28/2014 06:09 PM, Ludovic Courtès wrote:
>> Cyril Roelandt  skribis:
>> 
>>> * guix/scripts/lint.scm (check-description-style, 
>>> check-synopsis-start-upper-case): New methods
>>> * tests/lint.scm: Test them.
>> 
>> Please specify the test names, and wrap lines.
>> 
>>> +(define (start-with-upper-case s)
>>> +  (char-set-contains? char-set:upper-case (string-ref s 0)))
>> 
>> Rather ‘starts-with-capital-letter?’ (with the question mark, as is
>> conventional, and more grammatically correct I think.)
>> 
>> Also it may be worth checking that S has one or more character, so
>> gracefully handle empty synopses.
>> 
> Not sure whether the "starts-with-capital-letter" function would make a
> lot of sense with an empty string, that why I test this in the caller.
> WDYT ?

Oh right, I hadn’t noticed the test in the caller, sorry about that.

Ludo’.

Re: [PATCHv2 3/5] guix lint: check whether descriptions and synopses start with an upper-case letter.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> * guix/scripts/lint.scm (check-description-style,
>   check-synopsis-start-upper-case): New methods.
> * tests/lint.scm ("description: does not start with an upper-case letter",
>   "synopsis: does not start with an upper-case letter"): New tests.

LGTM, please push.

Thanks,
Ludo’.

Re: [PATCH] gnu: clucene: Enable the contrib-libs.

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/rdf.scm (clucene): Enable the contribs-lib directory.

LGTM.  (Andreas is our Clucene expert now ;-), so you could leave him a
one-day delay before committing just in case.)

Ludo’.

Re: [PATCH] guix package: Add '--switch-generation' option.

[Ludovic Courtès]

Alex Kost  skribis:

> A patch is attached.  Some comments:
>
> - ‘shitted-generation’ is not a very good name, I think.  Ideas?

‘shifted-generation’ is better :-), but otherwise maybe
‘relative-generation’?  No strong opinion.

> - ‘previous-generation-number’ may use ‘shifted-generation’ now:
>
> (define* (previous-generation-number profile #:optional
>  (number (generation-number profile)))
>   "Return the number of the generation before generation NUMBER of
> PROFILE, or 0 if none exists.  It could be NUMBER - 1, but it's not the
> case when generations have been deleted (there are \"holes\")."
>   (or (shifted-generation profile -1 number)
>   0))
>
>   Worth changing?

Yes, why not.

> - Perhaps it would be better to make 2 commits (?): one for adding
>   ‘shifted-generation’ and ‘switch-to-generation’ procedures to (guix
>   profiles) and another is for adding the “--switch-generation” option
>   itself.

Yes.

> - Also I made a couple of cosmetic changes in “guix/scripts/package.scm”:
>   * ‘filter-map’ was replaced by 'for-each' because it was called only for
> side effects there;
>   * ‘begin’ was removed from ‘cond’.
>   I think these changes do not deserve a separate commit and may stay in
>   this patch.  Is it OK?

Several patches make it easier to reason about the changes, but it’s OK
here.  Your call.

> From 3cc52d1aade5e9723c38c0af5fa4437cbdf1a9b6 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Mon, 6 Oct 2014 17:35:51 +0400
> Subject: [PATCH] guix package: Add '--switch-generation' option.
>
> * doc/guix.texi (Invoking guix package): Update documentation.
> * guix/profiles.scm (shifted-generation, switch-to-generation): New
>   procedures.
> * guix/scripts/package.scm: Add '--switch-generation' option.
>   (switch-to-previous-generation): Use 'switch-to-generation'.

Could you add a test in tests/guix-package.sh?

The rest looks good to me, thanks for working on it!

Ludo’.

Re: GUIX 0.7 under QEMU/KVM with virtio

[Ludovic Courtès]

Assaf Gordon  skribis:

> On 10/05/2014 08:29 AM, Ludovic Courtès wrote:
>>>> I haven’t tried agetty, but it seems to have a hard-coded default login
>>>> program of “/bin/login”, which doesn’t exist here.  Could you try
>>>> invoking it with -l $(guix build shadow)/bin/login ?
>>>>
>>>> Alternately you could try adding a mingetty service to the
>>>> configuration:
>>>>
>>>> (operating-system
>>>>   ...
>>>>   (services (cons (mingetty-service "ttyS0")
>>>>   %base-services)))
>>>>
>>>
>>> I still can't get serial console to work, perhaps needs more fidgeting.
>>
>> Did you try agetty with -l as suggested above?
>>
>
> Yes. Same as before - it exists after a timeout of few seconds.
>
>>> Trying "mingetty ttyS0" from the command line fails with:
>>>  ttyS0: no controlling tty: Operation not permitted
>>
>> Is mingetty running as root here?  If it is, could you strace it to see
>> exactly what returns EPERM?
>>
>
> Yes. Running as root.
>
> I don't have "strace" installed - how do I install it ? (I'm very new to 
> guix).

Run ‘guix package -i strace’.  Preferably register hydra.gnu.org.pub to
enable “substitutes” before doing that, so the system doesn’t end up
building the world (info "(guix) Substitutes").

HTH,
Ludo’.

Re: [PATCH] gnu: eudev: Update to 1.10.

[Ludovic Courtès]

"Jason Self"  skribis:

> From 9b0a71a35143ffbea75896960a5dc501b46ae87d Mon Sep 17 00:00:00 2001
> From: Jason Self 
> Date: Mon, 6 Oct 2014 11:58:40 -0700
> Subject: [PATCH 1/1] gnu: eudev: Update to 1.10.
>
> * gnu/packages/linux.scm (eudev): Update to version 1.10.

OK to push if there’s no visible regression.

Thanks,
Ludo’.

Re: [PATCH] glib-or-gtk-build-system: new build-system

[Ludovic Courtès]

Federico Beffa  skribis:

> Please find attached a new build system for applications making use of
> glib or gtk+.
> It uses wrappers as previously discussed on this list.
>
> I've successfully tested it with three packages: emacs, libcanberra and gtk+.

Excellent!  Would be nice to check Evince and EOG, which were known to
have this kind of problem.

> Currently it is implemented as a separate build-system inheriting from
> the gnu-build-system. Essentially it adds 2 phases to the latter.
> IMO, it would make sense to make those 2 phases part of the
> gnu-build-system and enable them with the help of flags.

Great.  The strategy looks good to me.  Mark had concerns about the
wrapper approach in general, but IMO it’s OK here.  Thoughts?

Some mostly cosmetic comments:

> From dcb7dc451eac21e24e6972fa4c1a4524a7658af0 Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Mon, 6 Oct 2014 15:49:29 +0200
> Subject: [PATCH] glib-or-gtk-build-system: new build-system
>
> * guix/build-system/glib-or-gtk.scm, guix/build/glib-or-gtk-build-system.scm:
>   Add initial version of a new build-system called 'glib-or-gtk-build-system'.

Just “New files.”  Also, make sure to add them to gnu-system.am and to
mention it in the log.

> +(define* (glib-or-gtk-build store name source inputs
> + #:key (guile #f)
> + (outputs '("out"))
> + (search-paths '())
> + (configure-flags ''())
> + (make-flags ''())
> + (glib (default-glib))

Please align parameters with ‘store’.

This will have to be adjusted to the new “bags” interface.  Namely, the
part that adds inputs must be moved to a new procedure (called ‘lower’
in the other build systems), and ‘glib-or-gtk-build’ will be simplified
accordingly.

It should be simple to see what needs to be changed by looking at the
other build systems, but let me know if you have any questions.

> +(define (rel-path-exists? path rel-path)
> +  (directory-exists? (string-append path rel-path)))

Rather (subdirectory-exists? parent sub-directory).
(By convention GNU software uses “file names” or “directory names” here,
whereas “path” is used for search paths.)

> +(define (gtk-module-dirs inputs)
> +  "Check for the existence of \"libdir/gtk-v.0\" in INPUTS.  Return a list
> +with all found pathes.  If none is found return an empty list."

s/dirs/directories/ and s/pathes/directories/

No need for “If none is found...”, because it’s just a special case.

> +(define (glib-schemas input prev)
> +  (let* ((in (match input
> +   ((_ . dir) dir)
> +   (_ "")))
> + (datadir (string-append in "/share")))
> +(if (rel-path-exists? datadir "/glib-2.0/schemas")
> +(cons datadir prev)
> +prev)))

I think this should be moved into ‘schemas-directories’.

> +(define (schemas-dirs inputs)
> +  "Check for the existence of \"datadir/glib-2.0/schemas\" in INPUTS.  Return
> +a list with all found pathes.  If none is found return an empty list."

Rather ‘schemas-directories’, and also “directories” instead of “pathes”.

> +(define* (glib-or-gtk-build #:key inputs (phases %standard-phases)
> +  #:allow-other-keys #:rest args)

Please align #:allow-other-keys with #:key.

Lastly, could add an entry in guix.texi under “Build Systems”, ideally
with references (@uref) to the GSettings and GTK+ module documentation?

Could you post an updated patch?

Thanks for all this!

Ludo’.

Re: guix build failure

[Ludovic Courtès]

Federico Beffa  skribis:

> today I pulled from the git repository and now make stops with the
> following error:

[...]

> In unknown file:
>?: 2 [primitive-load-path "gnu/packages/which" ...]
> In gnu/packages/which.scm:
>   27: 1 [#]
> In ice-9/boot-9.scm:
>  106: 0 [# args)> unbound-variable ...]
>
> ice-9/boot-9.scm:106:20: In procedure # ice-9/boot-9.scm:97:6 (thrown-k . args)>:
> ice-9/boot-9.scm:106:20: In procedure module-lookup: Unbound variable: name
> make[2]: *** [guix/scripts/archive.go] Error 1

Not sure what happened.  I just did ‘make clean-go && make’ with commit
177088a and it builds flawlessly.  Perhaps try ‘make clean-go’?

HTH,
Ludo’.

Re: [PATCH] gnu: eudev: Update to 1.10.

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> "Jason Self"  skribis:
>
>> From 9b0a71a35143ffbea75896960a5dc501b46ae87d Mon Sep 17 00:00:00 2001
>> From: Jason Self 
>> Date: Mon, 6 Oct 2014 11:58:40 -0700
>> Subject: [PATCH 1/1] gnu: eudev: Update to 1.10.
>>
>> * gnu/packages/linux.scm (eudev): Update to version 1.10.
>
> OK to push if there’s no visible regression.

There was a typo in 2de5258; with the typo fixed, it failed to build.
Commit eb564fc fixes that.  And not only does it build, there’s even no
regression at run time.  :-)

Please make sure to commit only after checking that in the future.

Ludo’.

Re: guix build failure

[Ludovic Courtès]

Federico Beffa  skribis:

>> Not sure what happened.  I just did ‘make clean-go && make’ with commit
>> 177088a and it builds flawlessly.  Perhaps try ‘make clean-go’?
>
> On top of make clean-go I had to delete the cached files in ~/.cache/...

Oh, OK.  Normally the local .go have higher precedence than those in
~/.cache.  Let us know if that happens again, so we can investigate
better.

Ludo’.

Re: [PATCH] guix package: Add '--switch-generation' option.

[Ludovic Courtès]

Alex Kost  skribis:

> Thanks, I've added a couple of tests.  The new patches are attached.

Thanks for the quick reply.

> Further improvements (documentation may be unsatisfactory)?

> From 9493421a4e094be6686ff6f28749946d491f81cd Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Tue, 7 Oct 2014 11:50:44 +0400
> Subject: [PATCH 1/2] profiles: Add procedures for switching generations.
>
> * guix/scripts/package.scm (switch-to-previous-generation): Move to...
> * guix/profiles.scm: ... here. Use 'switch-to-generation'.
>   (relative-generation): New procedure.
>   (previous-generation-number): Use it.
>   (switch-to-generation): New procedure.

[...]

> +(define* (relative-generation profile shift #:optional
> +  (current (generation-number profile)))
> +  "Return PROFILE's generation shifted from the CURRENT generation by SHIFT.
> +SHIFT is a positive or negative number.
> +Return #f if there is no such generation."

[...]

> +(define (switch-to-generation profile number)
> +  "Atomically switch PROFILE to the generation NUMBER."
> +  (let ((current (generation-number profile))
> +(file(generation-file-name profile number)))
> +(cond ((not (file-exists? profile))
> +   (format (current-error-port)
> +   (_ "profile '~a' does not exist~%")
> +   profile))
> +  ((not (file-exists? file))
> +   (format (current-error-port)
> +   (_ "generation ~a does not exist~%")
> +   number))
> +  (else
> +   (format #t (_ "switching from generation ~a to ~a~%")
> +   current number)
> +   (switch-symlinks profile file)

Could this procedure raise an exception instead of writing messages?
The reason is that I’d like UI code to remain in (guix scripts package),
in the Emacs code, and in guix-web, with (guix profiles) remaining
generic.

It’d be enough for me to just call ‘switch-symlinks’ and let it throw
‘system-error’ if something’s wrong.  The exception will be caught, the
user will see a “No such file” error, and ‘guix package’ with exit with
non-zero (this is done by ‘call-with-error-handling’.)

It’s less informative than what you did, though.  The other option would
be to define specific error condition types and throw them from here.

WDYT?

My apologies for being sloppy and not catching it earlier!

> From 0d89e5466741d8f80a1ac27502cb6cd600afb796 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Tue, 7 Oct 2014 12:05:06 +0400
> Subject: [PATCH 2/2] guix package: Add '--switch-generation' option.
>
> * guix/scripts/package.scm: Add '--switch-generation' option.
>   (guix-package): Adjust accordingly.
> * tests/guix-package.sh: Test it.
> * doc/guix.texi (Invoking guix package): Document it.

[...]

> +  (('switch-generation . pattern)
> +   (let* ((number (string->number pattern))
> +  (number (and number
> +   (case (string-ref pattern 0)
> + ((#\+ #\-)
> +  (relative-generation profile number))
> + (else number)
> + (if number
> + (switch-to-generation profile number)
> + (format (current-error-port)
> + "Cannot switch to generation '~a'~%" pattern)))

Use ‘leave’ instead of ‘format’ here, with lower-case “cannot”.

The rest is perfect.

Thanks for your patience,
Ludo’.

Re: [PATCH 1/4] gnu: Add potrace.

[Ludovic Courtès]

Eric Bavier  skribis:

> From f178a122f3805cbc23119b20c2144cf2a59bed3f Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Tue, 7 Oct 2014 11:13:35 -0500
> Subject: [PATCH 1/4] gnu: Add potrace.
>
> * gnu/packages/fontutils.scm (potrace): New variable.

This part looks good to me, but...

>  gnu/packages/fontutils.scm |   28 ++
>  gnu/packages/giflib.scm|   90 
> 

What about the giflib.scm changes?  Were they intended?  Perhaps giflib
5.x can be added in image.scm?

Thanks,
Ludo’.

Re: [PATCH 2/4] gnu: Add libspiro.

[Ludovic Courtès]

Eric Bavier  skribis:

> From f843feeef69ae5ebf56d3c4f342b589b5a726b39 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Tue, 7 Oct 2014 11:14:39 -0500
> Subject: [PATCH 2/4] gnu: Add libspiro.
>
> * gnu/packages/fontutils.scm (libspiro): New variable.

OK to push!

Ludo’.

Re: [PATCH 3/4] gnu: Add libuninameslist.

[Ludovic Courtès]

Eric Bavier  skribis:

> From 6888ebc0265608ce5727d28666f92fa2101d03a8 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Tue, 7 Oct 2014 11:18:36 -0500
> Subject: [PATCH 3/4] gnu: Add libuninameslist.
>
> * gnu/packages/fontutils.scm (libuninameslist): New variable.

OK!

Ludo'.

Re: [PATCH 4/4] gnu: Add fontforge.

[Ludovic Courtès]

Eric Bavier  skribis:

> From 32cbf42d1e8615cab130d0f58f3c16cd18d6ba01 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Tue, 7 Oct 2014 11:20:20 -0500
> Subject: [PATCH 4/4] gnu: Add fontforge.
>
> * gnu/packages/fontutils.scm (fontforge): New variable.

OK!

> +(define-public fontforge
> +  (package
> +   (name "fontforge")
> +   (version "20120731-b")   ;aka 1.0

“0.99.20120731-b” would be a better choice since that would preserve
lexicographic order when 1.0 is released.

Thanks,
Ludo’.

Re: [PATCH 1/4] gnu: Add potrace.

[Ludovic Courtès]

Eric Bavier  skribis:

> Ludovic Courtès writes:
>
>> Eric Bavier  skribis:
>>
>>> From f178a122f3805cbc23119b20c2144cf2a59bed3f Mon Sep 17 00:00:00 2001
>>> From: Eric Bavier 
>>> Date: Tue, 7 Oct 2014 11:13:35 -0500
>>> Subject: [PATCH 1/4] gnu: Add potrace.
>>>
>>> * gnu/packages/fontutils.scm (potrace): New variable.
>>
>> This part looks good to me, but...
>
> Ok.
>
>>
>>>  gnu/packages/fontutils.scm |   28 ++
>>>  gnu/packages/giflib.scm|   90 
>>> 
>>
>> What about the giflib.scm changes?  Were they intended?
>
> No, those changes were not intended.

OK.

>> Perhaps giflib 5.x can be added in image.scm?
>
> I was experimenting with the latest version of fontforge, which can use
> giflib 5.x.  For the time being it can be left out.
>
> An updated patch is attached.
>
>
> From 6721d6e9e31af8aff5e781d813e55347dea378c9 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Tue, 7 Oct 2014 12:27:37 -0500
> Subject: [PATCH] gnu: Add potrace.
>
> * gnu/packages/fontutils.scm (potrace): New variable.

LGTM!

Ludo'.

Re: [PATCH] guix package: Add '--switch-generation' option.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-07 20:00 +0400) wrote:
>
>> Alex Kost  skribis:

[...]

>> It’d be enough for me to just call ‘switch-symlinks’ and let it throw
>> ‘system-error’ if something’s wrong.  The exception will be caught, the
>> user will see a “No such file” error, and ‘guix package’ with exit with
>> non-zero (this is done by ‘call-with-error-handling’.)
>
> ‘switch-symlinks’ does not throw an error even if files don't exist, so…

Oh right, ‘symlink’ doesn’t care about its first argument.

>> It’s less informative than what you did, though.  The other option would
>> be to define specific error condition types and throw them from here.
>>
>> WDYT?
>
> … I tried to make it this way, thank you for pointing.  I made another
> commit for adding and using condition types (3 patches are attached
> now).

Great.

> Also I moved ‘process-query’ inside ‘with-error-handling’ (because I
> used ‘raise’ there).  Could there be unwanted consequences after that?

No, I think it’s fine.

> From d5e9abb0395a21e79d4f77181597103d4daf138c Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Wed, 8 Oct 2014 00:32:28 +0400
> Subject: [PATCH 1/3] profiles: Add condition types for profile and generation.
>
> * guix/profiles.scm (&profile-error, &generation-error): New condition types.
> * guix/ui.scm (call-with-error-handling): Handle these types.
> * guix/scripts/package.scm (roll-back, guix-package): Raise '&profile-error'
>   where needed.

This is bikeshedding, but I would make a hierarchy like this:

 &profile-error, with ‘profile’ field
^
   .———–+———–.
   | |
  &profile-not-found-error&missing-generation-error, with ‘generation’ 
field

WDYT?

Other than that the patch looks good.

> From e47644b43aaa73885ca648118b6fc59fdb499303 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Wed, 8 Oct 2014 00:39:42 +0400
> Subject: [PATCH 2/3] profiles: Add procedures for switching generations.
>
> * guix/scripts/package.scm (switch-to-previous-generation): Move to...
> * guix/profiles.scm: ... here. Use 'switch-to-generation'.
>   (relative-generation): New procedure.
>   (previous-generation-number): Use it.
>   (switch-to-generation): New procedure.

OK.

> From 003e5c192796e8ea07491a94a85824a533155825 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Wed, 8 Oct 2014 00:45:38 +0400
> Subject: [PATCH 3/3] guix package: Add '--switch-generation' option.
>
> * guix/scripts/package.scm: Add '--switch-generation' option.
>   (guix-package): Adjust accordingly.
> * tests/guix-package.sh: Test it.
> * doc/guix.texi (Invoking guix package): Document it.

OK.

Thanks again!

Ludo’.

Re: [PATCH] gnu: conkeror: install conkeror-spawn-helper.

[Ludovic Courtès]

Eric Bavier  skribis:

> From 16e2259eb3860686a30d40e94c4c5bd39d60dfe0 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Tue, 7 Oct 2014 17:33:00 -0500
> Subject: [PATCH] gnu: conkeror: install conkeror-spawn-helper.
>
> * gnu/packages/conkeror.scm (conkeror)[build-system]: Change to
>   gnu-build-system.  Adjust arguments accordingly.
>   [inputs]: Remove now-implicit bash.
>   [native-inputs]: Remove now-implicit tar and gzip.
>   [description]: Fix two-space-after-end-of-sentence.  Remove comment
>   about separate conkeror-spawn-process-helper package.

OK to push.

(I had got used to spawning the PDF viewer by hand, but this is
definitely an improvement!)

Thanks,
Ludo’.

Re: [PATCH] glib-or-gtk-build-system: new build-system

[Ludovic Courtès]

Federico Beffa  skribis:

> On Wed, Oct 8, 2014 at 9:28 AM, Federico Beffa  wrote:
>> Attached an updated patch. If it is fine, I will update the
>> documentation in a separate patch to follow.
>
> I forgot to mention that I'm not sure how to update gnu-system.am. I
> looked for cmake-build-system as an example, but it is not mentioned
> in the file.

It’s actually in Makefile.am.  gnu-system.am is for things under gnu/.

Ludo’.

Re: [PATCH] glib-or-gtk-build-system: new build-system

[Ludovic Courtès]

Federico Beffa  skribis:

> On Mon, Oct 6, 2014 at 11:32 PM, Ludovic Courtès  wrote:
>> Excellent!  Would be nice to check Evince and EOG, which were known to
>> have this kind of problem.
>
> I've checked Evince and it works fine.

Great.

> I couldn't find EOG. What's the name of the package?

I remember Cyril mentioned it in a discussion, but it’s not in the tree,
so forget about it.

> Attached an updated patch. If it is fine, I will update the
> documentation in a separate patch to follow.

OK.

> From 3bcb914162de1950ff927bc44cb91ea20bd5c1d4 Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Mon, 6 Oct 2014 15:49:29 +0200
> Subject: [PATCH] glib-or-gtk-build-system: New files
>
> * guix/build-system/glib-or-gtk.scm, guix/build/glib-or-gtk-build-system.scm:
>   Add initial version of a new build-system called 'glib-or-gtk-build-system'.

I’ve pushed the patch after adding the files to Makefile.am and tweaking
the commit log (I realize I wasn’t clear: “New files” is for the body of
the commit log, whereas the subject line is typically a sentence.)

Thanks!

Ludo’.

Re: [PATCH] glib-or-gtk-build-system: new build-system

[Ludovic Courtès]

Federico Beffa  skribis:

> On Wed, Oct 8, 2014 at 12:04 PM, Ludovic Courtès  wrote:
>> Federico Beffa  skribis:
>>> I've checked Evince and it works fine.
>>
>
> By the way, note that when started, it complains about missing
> libcanberra as does emacs.
> The problem is solved by adding libcanberra as an input to both programs.
> Maybe libcanberra should be made a propagating-input of some lower
> level library?

Not sure.  Is libcanberra dlopened?  Do you know what dlopens it, and
whether it systematically does?

> Also, as emacs, it give the warning
>
> GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings
> will not be saved or shared with other applications.
>
> I believe this is because they can't find dconf. Any particular reason
> for not being in gnome.scm?

I think it’s just that nobody did it.  :-)

So this is the daemon the GSettings API normally connects to, right?

Thanks,
Ludo’.

Re: [PATCH] gnu: cmake: Use our curl, zlib, expat, bzip2, and libarchive.

[Ludovic Courtès]

Eric Bavier  skribis:

> Sending this patch to the list, as it would likely cause a lot of
> rebuilds.
>
>
> From c824d34faecc173bafc513d0b2052597a46dddfd Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Wed, 8 Oct 2014 11:55:40 -0500
> Subject: [PATCH] gnu: cmake: Use our curl, zlib, expat, bzip2, and
>  libarchive.
>
> * gnu/packages/cmake.scm (cmake)[arguments]: Move sh-patching to new
>   'patch-bin-sh phase.  New 'set-paths phase.
>   [inputs]: Add curl, zlib, expat, bzip2, and libarchive.
>   [description]: Fix space after end-of-sentence.

LGTM.  I think it’s fine to apply it on ‘master’ now (MIPS builds are
lagging behind, but that’s OK.)

Ludo’.

Re: ui: Move 'show-manifest-transaction' from (guix profiles).

[Ludovic Courtès]

Alex Kost  skribis:

>?: 16 [primitive-load-path "guix/profiles" ...]
> In guix/profiles.scm:
>   21: 15 [#]
> In ice-9/boot-9.scm:
> 2951: 14 [define-module* (guix profiles) #:filename ...]
> 2926: 13 [resolve-imports (((guix utils)) ((guix records)) ((guix 
> derivations)) ...)]
> 2864: 12 [resolve-interface (guix gexp) #:select ...]
> 2789: 11 [# autoload version #:key ensure)> # ...]
> 3065: 10 [try-module-autoload (guix gexp) #f]
> 2401: 9 [save-module-excursion # ice-9/boot-9.scm:3066:17 ()>]
> 3085: 8 [#]
> In unknown file:
>?: 7 [primitive-load-path "guix/gexp" ...]
> In guix/gexp.scm:
>   19: 6 [#]
> In ice-9/boot-9.scm:
> 2951: 5 [define-module* (guix gexp) #:filename ...]
> 2926: 4 [resolve-imports ((# # #) (#) (# # #) (#) ...)]
> 2877: 3 [resolve-interface (guix store) #:select ...]
>  768: 2 [for-each # #]
> 2883: 1 [# 
> direct-store-path?]
> In unknown file:
>?: 0 [scm-error misc-error #f ...]
>
> ERROR: In procedure scm-error:
> ERROR: no binding `direct-store-path?' in module (guix store)

This is another circularity issue.  :-/

There’s:

  (guix store) -> (guix nar) -> (guix ui) -> (guix store) ...

This shouldn’t be a problem, except that occasional uses of #:select
trigger a bug (see .)

I’ve fiddled a bit on top of your patch, but couldn’t find any simple
fix.

However, back to the initial problem, is this a problem if the error
conditions are defined in (guix profiles), which is then imported by
(guix ui)?  This is suboptimal, but this kind of circular reference
shouldn’t cause any troubles.

HTH,
Ludo’.

Re: [PATCH] glib-or-gtk-build-system: added documentation

[Ludovic Courtès]

I took the freedom to slightly amend the text (see diff below), tweaked
the commit log, and pushed it.

Thanks!

Ludo’.

diff --git a/doc/guix.texi b/doc/guix.texi
index 36337f1..ed2b81b 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1644,27 +1644,27 @@ debugging information''), which roughly means that code is compiled with
 
 @defvr {Scheme Variable} glib-or-gtk-build-system
 This variable is exported by @code{(guix build-system glib-or-gtk)}.  It
-is intended for use with packages making use of
-@url{https://developer.gnome.org/glib/stable, glib} or
-@url{https://developer.gnome.org/gtk3/stable, gtk+}.
+is intended for use with packages making use of GLib or GTK+.
 
-This build-system adds the following two phases to the ones defined by
-the @code{gnu-build-system}:
+This build system adds the following two phases to the ones defined by
+@var{gnu-build-system}:
 
 @table @code
 @item glib-or-gtk-wrap
 The phase @code{glib-or-gtk-wrap} ensures that programs found under
-@file{bin/} are able to find @code{glib} schemas and @code{gtk+}
-libraries.  This is achieved by appropriately setting the environment
-variables @code{XDG_DATA_DIRS} and @code{GTK_PATH}; and by wrapping the
-programs in suitable launch scripts.
+@file{bin/} are able to find GLib's ``schemas'' and
+@uref{https://developer.gnome.org/gtk3/stable/gtk-running.html, GTK+
+modules}.  This is achieved by wrapping the programs in launch scripts
+that appropriately set the @code{XDG_DATA_DIRS} and @code{GTK_PATH}
+environment variables.
 
 @item glib-or-gtk-compile-schemas
-The phase @code{glib-or-gtk-compile-schemas} makes sure that all
-@code{glib} schemas are compiled.  Compilation is performed by the
-program @code{glib-compile-schemas}.  It is provided by the package
+The phase @code{glib-or-gtk-compile-schemas} makes sure that all GLib's
+@uref{https://developer.gnome.org/gio/stable/glib-compile-schemas.html,
+GSettings schemas} are compiled.  Compilation is performed by the
+@command{glib-compile-schemas} program.  It is provided by the package
 @code{glib:bin} which is automatically imported by the build system.
-The @code{glib} package providing @code{glib-compile-schemas} can be
+The @code{glib} package providing @command{glib-compile-schemas} can be
 specified with the @code{#:glib} parameter.
 @end table
 

Re: [PATCH] gnu: icecat: Update to 31.1.1

[Ludovic Courtès]

Mark H Weaver  skribis:

> Mark H Weaver  writes:
>> This is technically a pre-release, but given that our current Icecat has
>> at least one security hole (and probably others), and fails to build on
>> i686, I'm inclined to push it to master immediately.
>
> After some more testing, I went ahead and pushed this.

Very well, thanks!

Ludo’.

Re: [PATCH] scripts: Add 'environment' command.

[Ludovic Courtès]

Hey!

David Thompson  skribis:

> The purpose of 'guix environment' is to assist hackers in creating
> reproducible development environments without polluting their package
> profile.  'guix environment' takes a package (or packages), builds all
> of the necessary inputs, and creates a shell environment to use them.

Awesome!

[...]

> By default, running 'guix environment' spawns a new $SHELL process,
> because it is usually what one would want to do.  However, the '--exec'
> flag can be used to specify the command to run.
>
> Additionally, the default behavior is to prepend search paths to the
> existing environment variable values so that one has access to other
> installed software e.g. git.  To clear the existing environment firstf,
> the '--pure' flag can be used.
>
> Finally, the '--load' flag can be used to read a package from a file
> instead of searching $GUIX_PACKAGE_PATH.

This looks good to me.

> From 298dcc1dd3aac49e033debeea154c91b25229c14 Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Sun, 21 Sep 2014 13:40:05 -0400
> Subject: [PATCH] scripts: Add 'environment' command.
>
> * guix/scripts/environment.scm: New file.
> * Makefile.am (MODULES): Add it.

[...]

> +(define (purify-environment)
> +  "Unset almost all environment variables.  A small number of variables such
> +as 'HOME' and 'USER' are left untouched."
> +  (for-each unsetenv
> +(filter (lambda (variable)
> +  ;; Protect some env vars from purification.  Borrowed
> +  ;; from nix-shell.
> +  (not (member variable
> +   '("HOME" "USER" "LOGNAME" "DISPLAY"
> + "TERM" "TZ" "PAGER"
> +(map car (get-environment-variables)

Maybe put the list of env. vars in a global variable, say
‘%precious-variables’, and then:

  (remove (cut member <> %precious-variables)
  (match (get-environment-variables)
(((names . values) ...)
 names)))

(My allergy to ‘car’ goes this far.  ;-))

> +  (display (_ "
> +  -e, --exec shell command to execute"))

Perhaps make it -E, and use -e consistently with ‘guix build’?  It may
be possible to reuse ‘options/resolve-packages’ for that.

> +(define %default-options
> +  ;; Default to opening a new shell.
> +  `((exec . ,(getenv "SHELL"))

(or (getenv "SHELL") "/bin/sh")

> +(define (build-inputs inputs opts)
> +  "Build the packages in INPUTS using the build options in OPTS."
> +  (with-store store
> +(run-with-store store
> +  (mlet* %store-monad ((drvs (sequence %store-monad
> +   (map package->derivation 
> inputs
> +(mbegin %store-monad
> +  (show-what-to-build* drvs
> +   #:use-substitutes? (assoc-ref opts 
> 'substitutes?)
> +   #:dry-run? #f)
> +  (set-build-options-from-command-line* opts)
> +  (built-derivations drvs)
> +  (return drvs))

The store should rather be kept open around (system command).  Otherwise
the above derivations and their outputs could be GC’d (it should be
possible to check that by trying to run ‘guix gc -d XXX’ on one of them
from within the sub-shell.)

> +;; Entry point.
> +(define (guix-environment . args)
> +  (define (parse-options)
> +(args-fold* args %options
> +(lambda (opt name arg result)
> +  (leave (_ "~A: unrecognized option~%") name))
> +(lambda (arg result)
> +  (alist-cons 'package arg result))
> +%default-options))
> +
> +  (let* ((opts (parse-options))
> + (pure? (assoc-ref opts 'pure))
> + (command (assoc-ref opts 'exec))
> + ;; Load from file if given, otherwise search for packages.
> + (inputs (packages->transitive-inputs
> +  (or (and=> (assoc-ref opts 'load) load)
> +  (map specification->package
> +   (pick-all opts 'package)
> + (drvs (build-inputs inputs opts)))

Would be good to honor --dry-run as well.  It would just print what
needs to be built and exit.

Thank you!

Ludo’.

Re: Having trouble packaging 'tidy'

[Ludovic Courtès]

I had packaged it in Nixpkgs and I ended up using a CVS checkout.

However, you would need to first write (guix cvs-download), based on
(guix svn-download).  :-)

Ludo’.

Re: ui: Move 'show-manifest-transaction' from (guix profiles).

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-08 23:55 +0400) wrote:

[...]

>> However, back to the initial problem, is this a problem if the error
>> conditions are defined in (guix profiles), which is then imported by
>> (guix ui)?  This is suboptimal, but this kind of circular reference
>> shouldn’t cause any troubles.
>
> Do you mean to "#:select" condition types in (guix ui)?

No, because #:select basically prevents circular references.

> What about making an auxiliary (guix conditions) module with all
> existing condition types, and use it where needed?  I could try to work
> on it if it sounds reasonable.  WDYT?

Hmm yes, but only as a last resort.

I’ve spent some time trying to better understand the problem, but failed
(we desperately need tools in Guile do to this sort of things.)  Another
part of the problem is that (guix monads) uses other modules’ bindings
at the top-level.

Mark, any ideas?

Alex, is there a way we can backtrack a bit and move forward in the
meantime?

Ludo’.

Re: [PATCH] glib-or-gtk-build-system: new build-system

[Ludovic Courtès]

Federico Beffa  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Not sure.  Is libcanberra dlopened?  Do you know what dlopens it, and
>> whether it systematically does?
>
> I've not found out.  I'm attaching the strace log of evince (actually
> the wrapper of my local package built with glib-or-gtk).  Maybe you see
> more than me.

Is the GTK_MODULES environment variable defined on your system?  AIUI,
that tells GTK+ what modules to dlopen.

Ludo’.

Re: [PATCH] gnu: icu4c: Correct error in the binaries' runpath

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/icu4c.scm (icu4c): Apply the RUNPATH to the binaries,
>   instead of the libs

OK to commit, thanks.

Ludo’.

Re: ui: Move 'show-manifest-transaction' from (guix profiles).

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> There’s:
>
>   (guix store) -> (guix nar) -> (guix ui) -> (guix store) ...

Commit 0363991 fixes that.

(Now we must make sure we don’t reintroduce cycles in these modules;
probably we should integrate Mark’s cycle detection script somehow.)

With that I was able to apply the patch you posted.

Thanks, and sorry for the mess!

Ludo’.

Re: [PATCH] gnu: Add perl-zip.

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/zip.scm (perl-zip): New variable.

OK!  Thanks.

Ludo’.

Re: ui: Move 'show-manifest-transaction' from (guix profiles).

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-10 02:08 +0400) wrote:

[...]

>> This is bikeshedding, but I would make a hierarchy like this:
>>
>>  &profile-error, with ‘profile’ field
>> ^
>>.———–+———–.
>>| |
>>   &profile-not-found-error&missing-generation-error, with 
>> ‘generation’ field
>
> Thank you for the idea btw, I like it.  So the question is: should the
> parent &profile-error be handled as well?  If yes, what message to use?

Let’s ignore it for now, it Shouldn’t Happen™.

> 2. And another question: the current error for generation would look
> like this:
>
>   generation 18 does not exist
>
> Is it OK or should I use ‘generation-file-name’ there and make it:
>
>   generation '/some/path/to/profile/generation-18-link' does not exist

I prefer “generation 18 does not exist”, or maybe “generation 18 of
‘/some/profile’ does not exist”.  WDYT?

> The problem now is I can't add ‘switch-to-generation’ procedure to (guix
> profiles) as it uses ‘_’ and ‘switch-symlinks’ from (guix ui) which is
> not “#:use-module”-ed anymore.  This patch is also attached.  What to do
> about it?  I think moving ‘switch-to-generation’ to (guix ui) is not
> good or is it?

Yeah, a you suggested on IRC, let’s just leave it in (guix scripts
package) until we have a better idea.  :-)

> From af9d9869f2430dd3e20885e685867c6843ba4279 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Wed, 8 Oct 2014 17:29:01 +0400
> Subject: [PATCH 1/3] profiles: Add condition types for profiles and
>  generations.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Suggested by Ludovic Courtès.
>
> * guix/profiles.scm (&profile-error, &profile-not-found-error,
>   &missing-generation-error): New condition types.
> * guix/ui.scm (call-with-error-handling): Handle new types.
> * guix/scripts/package.scm (roll-back, guix-package): Raise
>   '&profile-not-found-error' where needed.

Perfect!

> From da49a2b7af5295c3c72b7e4590219cbac827877b Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Wed, 8 Oct 2014 00:39:42 +0400
> Subject: [PATCH 2/3] profiles: Add procedures for switching generations.
>
> * guix/scripts/package.scm (switch-to-previous-generation): Move to...
> * guix/profiles.scm: ... here. Use 'switch-to-generation'.
>   (relative-generation): New procedure.
>   (previous-generation-number): Use it.
>   (switch-to-generation): New procedure.

Perfect as well, OK to commit.

Thanks,
Ludo’.

Re: [PATCH] scripts: Add 'environment' command.

[Ludovic Courtès]

David Thompson  skribis:

> From 26cac530c7a1f69864fc819bdc14553eacd9dc23 Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Sun, 21 Sep 2014 13:40:05 -0400
> Subject: [PATCH] scripts: Add 'environment' command.
>
> * guix/scripts/environment.scm: New file.
> * Makefile.am (MODULES): Add it.
> * doc/guix.texi ("Invoking guix environment"): New node.

Nice!

I didn’t mention it before but it would be wonderful if you could come
up with a little test case.  It’s a bit difficult, esp. since the tests
cannot assume that will download & build the world.  So basically the
test could do, in a tests/guix-environment.sh script:

  guix environment -e '(@@ (gnu packages bootstrap) %bootstrap-guile)' ...

and make sure it at least sees ‘guile’ in $PATH.

WDYT?  That can come in a later commit if you prefer.

> diff --git a/doc/guix.texi b/doc/guix.texi
> index c9760f5..5b9c933 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -2417,6 +2417,7 @@ programming interface of Guix in a convenient way.
>  * Invoking guix hash::  Computing the cryptographic hash of a file.
>  * Invoking guix refresh::   Updating package definitions.
>  * Invoking guix lint::  Finding errors in package definitions.
> +* Invoking guix environment::   Creating new environments from package 
> inputs.

“Setting up development environments.” maybe?

We should also add a

  @dircategory Software development
  @direntry
  ...

at the top of the file for this node.

> +@node Invoking guix environment
> +@section Invoking @command{guix environment}
> +
> +The purpose of @command{guix environment} is to assist hackers in
> +creating reproducible development environments without polluting their
> +package profile.  The @command{guix environment} tool takes a package,

s/a package/one or more packages/

> +The new shell's environment is an augmented version of the environment
> +that @command{guix environment} was run in.  It contains the necessary
> +search paths for building the given package added to the existing
> +environment variables.  To create a ``pure'' environment in which the
> +original environment variables have been unset, use the @code{--pure}
> +option.
> +
> +Additionally, more than one package may be specified.

+ something like “, in which case all the inputs ...  For example, the
command below spawns a shell where all the dependencies of both Guile
and Emacs are available:”

> +@item --exec=@var{command}
> +@item -e @var{command}

Should be -E.

> +@item --search-paths
> +Display needed environment variable definitions.

“Display the environment variable definitions that make up the
environment”, or something like that?  (I find “needed” ambiguous.)

> +@end table

Here add something like:

  It also supports all the common build options that @command{guix
  build} supports (@pxref{Invoking guix build, common build options}).

The rest is good!

Thanks,
Ludo’.

Re: [PATCH] glib-or-gtk-build-system: new build-system

[Ludovic Courtès]

Federico Beffa  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Not sure.  Is libcanberra dlopened?  Do you know what dlopens it, and
>> whether it systematically does?
>
> I've not found out.  I'm attaching the strace log of evince (actually
> the wrapper of my local package built with glib-or-gtk).  Maybe you see
> more than me.
>
> In any case, I've checked a couple more applications making use of the gtk
> toolkit: inkscape, icecat. They all complain about
> libcanberra-gtk-module. It looks like
> libcanberra is used by many gtk+ applications.

I’ve looked again at the strace log and can’t find anything obvious such
as a config file in /home or /etc that would tell it to load
libcanberra-module.

However, I built Evince locally with glib-or-gtk-build-system, and it
doesn’t mention anything about libcanberra:

--8<---cut here---start->8---
$ /gnu/store/14ja1vpbc55yfgpp4irxwriw390zbl1g-evince-3.6.1/bin/evince 
doc/foo.pdf 

** (..evince-real-real:5821): WARNING **: Error retrieving accessibility bus 
address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was 
not provided by any .service files
Error registering document: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gnome.evince.Daemon was not provided by any .service files
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not 
be saved or shared with other applications.
--8<---cut here---end--->8---

So I’m pretty clueless.  Could it be that it receives some message over
D-Bus (on your machine) telling it to load the thing?  What does
‘dbus-monitor’ show?

>> So this is the daemon the GSettings API normally connects to, right?
>
> I believe so. At least that's what I understood reading some of the
> documentation and some threads, e.g.:
>
> http://permalink.gmane.org/gmane.comp.gnome.shell/5897
>
> dconf is the replacement for gconf which is now considered deprecated.
>
> For emacs specifically it appears that the warning may be suppressed
> with configure flags --without-gsettings and --disable-gconf:

Sure, but that would be cheating.  :-)

Thanks,
Ludo’.

Re: [PATCH] gnu: Add perl-zip.

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/zip.scm (perl-zip): New variable.

Looks better, OK to commit (and thanks, Eric.)

Ludo’.

Re: [PATCH] guix: refresh: Use bags.

[Ludovic Courtès]

Eric Bavier  skribis:

> This patch allows the `guix refresh --list-dependent` option to be more
> accurate in its dependency reporting, mostly by taking into account
> implicit dependencies generated at the build-system level (thanks to our
> new wonderful bags).

Cool!

> From ebc348a37addd53bab27ede856e0e4af3aa10b41 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Fri, 10 Oct 2014 14:27:20 -0500
> Subject: [PATCH] guix: refresh: Use bags.
>
> * guix/packages.scm (bag-direct-inputs): New procedure.
> * gnu/packages.scm (package-dependencies): Use it.

OK!

Would be good eventually to add tests for ‘package-direct-dependents’ & co.

> Out of curiosity, I also produced this table of packages and their total
> number of dependent packages.  Something similar might be useful for us,
> e.g., when deciding whether a package update should go in master or
> core-updates.

Definitely!

I’m surprised gzip, diffutils, patch, and tar are very low, even though
they’re part of %final-inputs.  Conversely, bzip2 (also part of
%final-inputs) is higher.

Any idea?

Thanks,
Ludo’.

Re: [PATCH] scripts: Add 'environment' command.

[Ludovic Courtès]

David Thompson  skribis:

>> I didn’t mention it before but it would be wonderful if you could come
>> up with a little test case.  It’s a bit difficult, esp. since the tests
>> cannot assume that will download & build the world.  So basically the
>> test could do, in a tests/guix-environment.sh script:
>>
>>   guix environment -e '(@@ (gnu packages bootstrap) %bootstrap-guile)' ...
>>
>> and make sure it at least sees ‘guile’ in $PATH.
>>
>> WDYT?  That can come in a later commit if you prefer.
>>
>
> Hmm, it's actually a bit trickier than that because the bootstrap guile
> has no inputs, so the resulting purified environment is completely
> empty.

Ah OK.

> +@table @code
> +@item --expression=@var{expr}
> +@itemx -E @var{expr}
> +Create an environment for the package that @var{expr} evaluates to.

[...]

> +@item --exec=@var{command}
> +@item -e @var{command}
> +Execute @var{command} in the new environment.

Typo: swap -e/-E.

The rest is alright, OK to commit!

Thank you!

Ludo’.

GNU Hackers Meeting talk on-line

[Ludovic Courtès]

The video of my talk at the 2014 GHM is now online:

  http://www.gnu.org/software/guix/#talks

(Sound is not very good.)

The other GHM videos are at:

  http://audio-video.gnu.org/video/ghm2014/

Big thanks to those who made it possible, and in particular to
Luca Saiu, Sree Harsha Totakura, and Bernd Paysan.

Ludo’.


signature.asc
Description: PGP signature

Re: [PATCH] glib-or-gtk-build-system: new build-system

[Ludovic Courtès]

(Adding guix-devel, which I think was dropped by mistake.)

Federico Beffa  skribis:

> On Fri, Oct 10, 2014 at 10:29 PM, Ludovic Courtès  wrote:

[...]

>> So I’m pretty clueless.  Could it be that it receives some message over
>> D-Bus (on your machine) telling it to load the thing?  What does
>> ‘dbus-monitor’ show?
>>
>
> This is what I'm getting:
>
> $ dbus-monitor

Hmm I don’t see anything useful either.

> when I start, e.g., Inkscape, it complains about missing
> canberra-gtk-module, but I don't see anything new appearing at the
> output of dbus-monitor. Differently from this, when I start the debian
> version, I do see new messages related to audio devices.

OK.  I don’t have any problems with Inkscape (as in current master) either.

Did these libcanberra issues appear after you switched Evince and
Inkscape to ‘glib-or-gtk-build-system’?

Did you browse /etc for things related to GTK+ modules?  Or maybe did
you check your user account’s GSettings database (I believe there’s a
graphical editor to do that)?

Thanks,
Ludo’.

Re: [PATCH] scripts: Add 'environment' command.

[Ludovic Courtès]

David Thompson  skribis:

> Fixed typo and pushed!

Yay!

I just noticed that ‘guix environment foo’, without -E, doesn’t work for
me because my .bashrc & co. reset PATH, CPATH, etc.

Conversely, ‘guix environment foo -E /bin/sh’ works, because when
invoked as ‘sh’, Bash does not read .bashrc.

I’m not sure if it’s something wrong with my Bash initialization files
or something that might affect others.  WDYT?

Thanks,
Ludo’.

Re: [PATCH] scripts: Add 'environment' command.

[Ludovic Courtès]

David Thompson  skribis:

> I don't think it's something "wrong" with your files, really, but it is
> incompatible with the way 'guix environment' currently operates.
>
> I took another look at nix-build to see how they do things.  They create
> a bashrc file in a temporary directory and run bash (or whatever
> $NIX_BUILD_SHELL is) with the '--rcfile' flag so that the user's bashrc
> isn't used.  We could do something similar, but right now I don't have
> any reason to believe that all shells accept an '--rcfile' option, so it
> could easily break other setups.

POSIX specifies the ‘ENV’ environment variable for that:

  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html

So that’s one thing that could be used.  Apparently Bash checks
‘BASH_ENV’ instead, unless invoked as ‘sh’ (info "(bash) Bash Startup
Files").

In the longer run, another option would be to have a Bash built-in
command, in the form of a plug-in loaded with ‘enable FOO.so’, that
would modify the environment variables of the running Bash process
(recutils has an example of that.)

My 2¢,
Ludo’.

Re: ui: Move 'show-manifest-transaction' from (guix profiles).

[Ludovic Courtès]

Alex Kost  skribis:

> OK, I have not pushed anything yet, as the commits were changed a bit.
> I'm attaching all 3 patches for adding “Switch to generation” support.
> Everything seems OK now (at least “make check” does not fail anymore),
> so if you don't have final comments, I would like to commit them.
> Thanks for the patience.

Looks good from a quick skim, go ahead!

Thanks,
Ludo’.

Re: [PATCH 1/4] gnu: Add imake.

[Ludovic Courtès]

Eric Bavier  skribis:

> From f311e2b1a081e4fd6c8bd3c3b9b2c2654d75f53c Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Fri, 10 Oct 2014 13:06:33 -0500
> Subject: [PATCH 1/4] gnu: Add imake.
>
> * gnu/packages/xorg.scm (imake): New variable.

[...]

> +(define xorg-cf-files
> +  (origin
> +(method url-fetch)
> +(uri "mirror://xorg/individual/util/xorg-cf-files-1.0.5.tar.bz2")
> +(sha256
> + (base32
> +  "1m3ypq0xcy46ghxc0svl1rbhpy3zvgmy0aa2mn7w7v7d8d8bh8zd"

Could you add a comment about what this is and its license?

Other than that LGTM.

Thanks,
Ludo’.

Re: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a.

[Ludovic Courtès]

Eric Bavier  skribis:

> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Fri, 10 Oct 2014 13:07:55 -0500
> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a.
>
> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a.

OK.

Ludo'.

Re: [PATCH 3/4] gnu: Add xfig.

[Ludovic Courtès]

Eric Bavier  skribis:

> From fca4924a98e06ec0d2877b14f074515a2a970605 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Fri, 10 Oct 2014 13:10:42 -0500
> Subject: [PATCH 3/4] gnu: Add xfig.
>
> * gnu/packages/xfig.scm: New file.
> * gnu-system.am (GNU_SYSTEM_MODULES): Add it.

Nice, looks good.

Ludo’.

Re: [PATCH 4/4] gnu: Add transfig.

[Ludovic Courtès]

Eric Bavier  skribis:

> From ece0a8dec5d95ccf84156e9e6c0c582639163b1e Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Fri, 10 Oct 2014 13:11:22 -0500
> Subject: [PATCH 4/4] gnu: Add transfig.
>
> * gnu/packages/xfig.scm (transfig): New variable.

OK!

> +(lambda* (#:key inputs outputs #:allow-other-keys)
> +  (let ((imake (assoc-ref inputs "imake"))
> +(out   (assoc-ref outputs "out")))
> +(substitute* '("fig2dev/Imakefile"
> +   "transfig/Imakefile")
> +  (("XCOMM (BINDIR = )[[:graph:]]*" _ front)
> +   (string-append front out "/bin"))
> +  (("XCOMM USEINLINE") "USEINLINE")
> +  ;; The variable name is deceptive.  The directory is used as an
> +  ;; installation path for bitmaps.
> +  (("(XFIGLIBDIR =[[:blank:]]*)[[:graph:]]*" _ front)
> +   (string-append front out "/lib"))
> +  (("(XPMLIBDIR = )[[:graph:]]*" _ front)
> +   (string-append front (assoc-ref inputs "libxpm") "/lib"))
> +  (("(XPMINC = -I)[[:graph:]]*" _ front)
> +   (string-append front (assoc-ref inputs "libxpm") 
> "/include/X11"))
> +  (("/usr/local/lib/fig2dev") (string-append out "/lib")))

I feel you’ll end up writing an ‘imake-build-system’.  :-)

Thanks,
Ludo’.

Re: [PATCH] guix: refresh: Use bags.

[Ludovic Courtès]

Eric Bavier  skribis:

> Ludovic Courtès writes:
>
>> I’m surprised gzip, diffutils, patch, and tar are very low, even though
>> they’re part of %final-inputs.  Conversely, bzip2 (also part of
>> %final-inputs) is higher.
>>
>> Any idea?
>
> I think this is because fold-packages only looks at packages that are
> exported by a module.  Many of the packages in %final-inputs are not
> exported.
>
> While the vhash returned by (@ (gnu packages) package-dependencies)
> includes dependency lists for packages in %final-inputs, guix refresh
> uses find-package-by-name to get the packages that are used as lookup
> keys, and find-package-by-name only returns packages that can be found
> with fold-packages.  Uff da.

Ah OK.  It’s not that bad, it just means that some packages are omitted
from the list.

Of course it would be good to use the full DAG.  For that we’d need
something that uses ‘fold-packages’ to get the “entry points” of the
DAG, and then traverses it all to also get the private packages.

>From there we could perhaps build a ‘fold-package*’ that would iterate
on the whole DAG.

WDYT?

> One, possibly ugly to implement, solution would be to merge hash entries
> of packages that have the same package-full-name, since the output is
> produced in that format already.

Instead, what about keeping things as is, but also showing the
‘package-location’ of each item?

Thanks,
Ludo’.

Re: [Ghm-discuss] GNU Hackers Meeting talk on-line

[Ludovic Courtès]

John Darrington  skribis:

> On Sat, Oct 11, 2014 at 11:47:41AM +0200, Ludovic Court??s wrote:
>  The video of my talk at the 2014 GHM is now online:
>  
>http://www.gnu.org/software/guix/#talks
>  
>  (Sound is not very good.)
>  
> This seems to be a recurring problem with GHM videos.  Making good quality
> audio/video recordings requires equipment and skill.

I’m not skilled ;-), but I thought that given that speakers were wearing
RF microphones, sound would be better.  I’m not sure why it turned out
not to be the case.

> Since we traditionally, don't have any "proceedings", the videos are the only
> recoding of the meetings.  Does anyone have any suggestions how we could 
> ensure 
> that we get consistently good recordings?

IRILL and Debian have professional equipment that they kindly lent us
for the GHM editions in Paris, and they occasionally lend it for other
conferences as well.  Perhaps we could ask them again, or find similar
institutions that can help?

But then again, beyond equipment, all this takes a lot of time both
during and after the conference, and I’m really grateful for the effort
that Luca, Sree, Matthias, Bernd, and others have put in that.

Ludo’.

Rebuilds and branches

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Eric Bavier  skribis:
>>
>>> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001
>>> From: Eric Bavier 
>>> Date: Fri, 10 Oct 2014 13:07:55 -0500
>>> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a.
>>>
>>> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a.
>>
>> OK.
>
> This triggered over 450 rebuilds.  I wonder if it should have been done
> in core-updates instead.

Arf, probably yes, in a ‘libjpeg-update’ branch, rather.

What about having a policy for that?  Like, above some threshold of the
number of rebuilds reported by ‘guix refresh -l’ (200 packages?), set up
a separate branch and Hydra job set.

In an ideal world a patch queue manager would automatically take care of
that.

Ludo’.

Re: Rebuilds and branches

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver  skribis:
>>
>>> l...@gnu.org (Ludovic Courtès) writes:
>>>
>>>> Eric Bavier  skribis:
>>>>
>>>>> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001
>>>>> From: Eric Bavier 
>>>>> Date: Fri, 10 Oct 2014 13:07:55 -0500
>>>>> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a.
>>>>>
>>>>> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a.
>>>>
>>>> OK.
>>>
>>> This triggered over 450 rebuilds.  I wonder if it should have been done
>>> in core-updates instead.
>>
>> Arf, probably yes, in a ‘libjpeg-update’ branch, rather.
>
> Well, suppose we update two different core packages in close succession,
> e.g. make 4.1 and bash 4.3.30.  I don't want two independent rebuilds,
> one with make 4.1 and bash 4.3.27 and another with make 4.0 and bash
> 4.3.30.  Each of those would turn out to be useless.

Right.

However, this is not a good example, since both Make and Bash are core
packages, so they would go in the same ‘core-updates’ branch.

I was rather thinking of packages like libjpeg, libpng, GLib, GTK+, Qt,
which have many dependencies, but are fairly independent from one
another.  Maybe in some cases it’ll make sense to update several of them
in the same branch, as you note.

>> What about having a policy for that?  Like, above some threshold of the
>> number of rebuilds reported by ‘guix refresh -l’ (200 packages?), set up
>> a separate branch and Hydra job set.
>
> The severity of the bug being fixed may also be a relevant factor in the
> decision.

Yes, I was thinking of non-security-critical updates.

For bug-fix updates that trigger 200+ rebuilds, it may still make sense
to have a separate branch and job set, for the sake of keeping ‘master’
stable.

WDYT?

Ludo’.

Re: [PATCH] guix lint: add the --checkers option.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> * guix/scripts/lint.scm: add the "--checkers" option.
> * doc/guix.texi: Update "Invoking guix lint".

Rather:

  * doc/guix.texi (Invoking guix lint): Document it.

> * tests/guix-lint.sh: New file
> * Makefile.am (SCM_TESTS): Add it.

[...]

> +@item --checkers
> +@itemx -c
> +Only enable the checkers specified in a comma-separated list using the
> +names returned by --list-checkers.

Should be @code{--list-checkers}.

> +  (begin
> +(format (current-error-port)
> +"Invalid checker: ~a~%" c)
> +(exit 1

Use (leave (_ "~a: invalid checker") c) instead.

> +   (let ((checkers (or (assoc-ref opts 'checkers) %checkers)))
> + (if (null? args)
> +  (fold-packages (lambda (p r) (run-checkers p checkers)) '())

Indent -1.

> +  (for-each
> +(lambda (spec)
> +  (run-checkers spec checkers))
> +(map specification->package args))

Both should be combined, as in:

  (for-each (lambda (spec)
  (run-checkers (specification->package spec) checkers))
args)

> +grep_warning ()
> +{
> +res=$(echo "$1" | grep -E -c "(synopsis|description) should")
> +echo $res

$(...) is a Bash extension; please use backquotes instead.

> +# Three issues with the dummy package:
> +# 1) the synopsis starts with the package name;
> +# 2) the synopsis starts with a lower-case letter;
> +# 3) the description starts with a lower-case letter.
> +
> +if [ $(grep_warning "$(guix lint dummy 2>&1)") -ne 3 ]
> +then false; else true; fi
> +
> +if [ $(grep_warning "$(guix lint -c synopsis dummy 2>&1)") -ne 2 ]
> +then false; else true; fi
> +
> +if [ $(grep_warning "$(guix lint -c description dummy 2>&1)") -ne 1 ]
> +then false; else true; fi
> +
> +if [ $(grep_warning "$(guix lint -c description,synopsis dummy 2>&1)") -ne 3 
> ]
> +then false; else true; fi

Backquotes as well (with intermediate variables.)

> +if guix lint -c synopsis,invalid-checker dummy 2>&1 | \
> +   grep -q 'Invalid checker: invalid-checker'
> +then true; else false; fi

OK.

Could you send an updated patch?

Thanks,
Ludo’.

Re: [PATCH 2/2] emacs: Add support for switching generations.

[Ludovic Courtès]

Alex Kost  skribis:

> Thanks, pushed.  Now I would like to add support for switching
> generations from Emacs UI.  The patches for that are attached.
>
> Currently there is no way to see what generation is the current one –
> the first patch will fix it (additional column is added to *Guix
> Generation List*).

OK, this looks good to me.

Thanks!

Ludo’.

Re: Setting environment variables in .bashrc vs .bash_profile

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> I just noticed that ‘guix environment foo’, without -E, doesn’t work for
>> me because my .bashrc & co. reset PATH, CPATH, etc.
>>
>> Conversely, ‘guix environment foo -E /bin/sh’ works, because when
>> invoked as ‘sh’, Bash does not read .bashrc.
>>
>> I’m not sure if it’s something wrong with my Bash initialization files
>> or something that might affect others.  WDYT?
>
> FWIW, I've always put my environment variable settings in .bash_profile
> instead of .bashrc for this reason.  I want to be able to set up an
> alternate environment and launch interactive subshells without resetting
> everything.

OK.  (I never took the time to understand what’s supposed to go in
.bashrc and what’s supposed to go in .bash_profile; now’s the time to
fix it.  ;-))

> I vaguely remember noticing that the standalone Guix system set things
> up in such a way that my environment was reset in every interactive
> shell.  If so, I would be in favor of changing that.

/etc/profile defines a bunch of environment variables (see
gnu/system.scm.)

In turn, new user accounts get a default .bashrc (see shadow.scm) that
sources /etc/profile.

If I got it right, it should be called .bash_profile instead of .bashrc,
and should source .bashrc when present?

> On the other hand, I end up with
> /gnu/store/10fr8jbnrb3gzyc0967m7ar64ch9ggk8-windowmaker-0.95.6/bin in
> front of my PATH within my entire X session, because of our windowmaker
> wrapper.

Yeah, another bug that needs to be fixed.  Could you file it?

Thanks,
Ludo’.

Re: [ANN] Guile-SSH 0.7.0 released

[Ludovic Courtès]

Hi,

Commit 817efe8 updates to Guile-SSH 0.7.1 (with commit e370381 adding
the libssh patch), and no test failures, thanks!

BTW, Guile-SSH has an explicit #include  somewhere, so it
needs libgcrypt as a direct dependency now, but ./configure doesn’t
explicitly check for it.

Ludo’.

Grafts

[Ludovic Courtès]

Hello,

I pushed ‘wip-grafts’, a branch that implements “grafts.”

Normally security updates deep in the DAG, such as an update of Bash or
libc, cause a rebuild of everything, which can some time, as we’ve seen
lately.

The idea of grafts is to graft the fixed package on any packages users
may want to install.  So, suppose there’s a libc fix; when installing
IceCat, you’ll just be starting from the (pre-built) IceCat, and an
additional derivation will patch the files in it to replace references
to the old libc with references to the fixed libc (in practice this only
works if the file name of the old and fixed libc have the same length.)

‘wip-grafts’ adds a ‘graft’ field to package records.  In the example
above, we’d just add a ‘graft’ field to glibc, pointing to the fixed
glibc, and the graft would just be automagically applied.  The branch
has an example of that with Bash:

--- a/gnu/packages/bash.scm
+++ b/gnu/packages/bash.scm
@@ -185,7 +185,13 @@ allows command-line editing, unlimited command history, shell functions and
 aliases, and job control while still allowing most sh scripts to be run
 without modification.")
  (license gpl3+)
- (home-page "http://www.gnu.org/software/bash/";
+ (home-page "http://www.gnu.org/software/bash/";)
+ (graft bash-fixed
+
+(define bash-fixed;FIXME: Use something real.
+  (package (inherit bash)
+(version "4.3.42")
+(graft #f)))
 
 (define-public bash-light
   ;; A stripped-down Bash for non-interactive use.
@@ -210,4 +216,5 @@ without modification.")
 
  ,@(if (%current-target-system)
'("bash_cv_job_control_missing=no")
-   '()
+   '()))
+(graft #f)))

The implementation looks for ‘graft’ fields in all the transitive inputs
of the package being built.

Currently it works but needs more testing and documentation.  There are
also performance issues that need to be worked out.

Comments welcome!

The general idea was implemented by Shea Levy in Nixpkgs¹, and also
suggested by Mark Weaver on IRC, who helped refine how things should
work in Guix–thanks!

Ludo’.

¹ 
https://github.com/NixOS/nixpkgs/commit/d1662d715514e6ef9d3dc29f132f1b3d8e608a18


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add xboing

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/games.scm (xboing): New variable.

[...]

> +(inputs `(("libx11" ,libx11)
> +   ("libxext" ,libxext)
> +   ("libxpm" ,libxpm)))
> +(native-inputs `(("imake" ,imake)
> +  ("inetutils" ,inetutils)
> +  ("makedepend" ,makedepend)))

Please align opening parenthesis and use only spaces, no tabs (for Emacs
23 and later, .dir-locals.el normally sets it up.)

> +(license x11-style)))

‘x11-style’ is a procedure, so it should be:

  (x11-style URI [COMMENT])

Make sure it’s not really ‘x11’ or ‘expat’.

TIA,
Ludo’.

Re: [PATCH] gnu: Add xboing

[Ludovic Courtès]

John Darrington  skribis:

> On Mon, Oct 13, 2014 at 02:27:48PM +0200, Ludovic Court??s wrote:
>  John Darrington  skribis:
>  
>  > * gnu/packages/games.scm (xboing): New variable.
>
>  [...]
>  
>  > +(inputs `(("libx11" ,libx11)
>  > +("libxext" ,libxext)
>  > +("libxpm" ,libxpm)))
>  > +(native-inputs `(("imake" ,imake)
>  > +   ("inetutils" ,inetutils)
>  > +   ("makedepend" ,makedepend)))
>  
>  Please align opening parenthesis and use only spaces, no tabs (for Emacs
>  23 and later, .dir-locals.el normally sets it up.)
>
> This was formatted by emacs using indent-region.  Shouldn't that do the job?
> loading .dir-locals.el results in an error for me.

Emacs 23+ loads it automatically.  Otherwise, drop:

  (setq indent-tabs-mode nil)

somewhere in ~/.emacs.

>  > +(license x11-style)))
>  
>  ???x11-style??? is a procedure, so it should be:
>  
>(x11-style URI [COMMENT])
>  
>  Make sure it???s not really ???x11??? or ???expat???.
>
> It is neither of those, although similar.  The trouble is, I don't think that 
> there is a URI for the license.  It is contained in the tarball.

See other uses: it’s fine to use file://COPYING, say, as the URI to the
license, if the only copy is within the tarball.

Also, it’s even better if you can add a comment above saying what’s
different from the X11 license text.

Thanks,
Ludo’.

Re: [PATCH] gnu: Add xboing

[Ludovic Courtès]

John Darrington  skribis:

> On Mon, Oct 13, 2014 at 03:54:50PM +0200, Ludovic Court??s wrote:
>  
>  Emacs 23+ loads it automatically.  Otherwise, drop:
>  
>(setq indent-tabs-mode nil)
>  
>  somewhere in ~/.emacs.
>
> Thanks!
>
> But it still tends to format
>   (arguments
>  `(#:tests? #f
>#:phases
>
> as
>
>   (arguments
>  `(#:tests? #f
> #:phases
>

Yes, this one is a case that Emacs gets wrong (the only one, I think.)

>  Also, it???s even better if you can add a comment above saying what???s
>  different from the X11 license text.
>
> I will try.  But it is difficult to say what is different without just giving 
> the output
> from diff.

Do what you think is best.

Ludo’.

Re: [PATCH] guix: refresh: Use bags.

[Ludovic Courtès]

Eric Bavier  skribis:

> Ludovic Courtès writes:
>
>> Eric Bavier  skribis:
>>
>>> Ludovic Courtès writes:

[...]

>> Of course it would be good to use the full DAG.  For that we’d need
>> something that uses ‘fold-packages’ to get the “entry points” of the
>> DAG, and then traverses it all to also get the private packages.
>>
>> From there we could perhaps build a ‘fold-package*’ that would iterate
>> on the whole DAG.
>
> Updated patch attached.  It defines a `fold-package*', and uses it in
> `guix refresh' to get all packages of a given name.

Nice!

> This patch may need to go in core-updates.

Why?

> From 1d22367e0806cea004631e22a782b7db3ffe65b0 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Mon, 13 Oct 2014 13:46:09 -0500
> Subject: [PATCH] guix: refresh: Use bags.
>
> * guix/packages.scm (bag-direct-inputs): New procedure.
> * gnu/packages.scm (package-dependencies): Use it.
>   (fold-packages*): New procedure.
> * guix/scripts/refresh.scm (guix-refresh)[list-dependent]: Use it.

[...]

> --- a/guix/scripts/refresh.scm
> +++ b/guix/scripts/refresh.scm
> @@ -232,16 +232,27 @@ update would trigger a complete rebuild."
>  (with-error-handling
>(cond
> (list-dependent?
> -(let* ((rebuilds (map package-full-name
> -  (package-covering-dependents packages)))
> +(let* ((packages*
> +;; Need to consider private packages, which are not found by
> +;; find-packages-by-name
> +(fold-packages*
> + (let ((package-names (map package-name packages)))
> +   (lambda (p r)
> + (if (find (cut string=? (package-name p) <>)
> +   package-names)
> + (cons p r)
> + r)))
> + '()))
> +   (rebuilds (map package-full-name
> +  (package-covering-dependents packages*)))

Could you move the computation of the package list to a different
procedure?  Possibly merging it with the existing expression that
computes ‘packages’ and which is already quite big.

> I'm also attaching the script I used to produce the package dependency
> count table I included previously.  With this updated patch, the numbers
> look much more reasonable and complete for the "core" packages.
>
>
>
> And the revised output, if anyone doesn't want to take the time to run
> the script themselves.
>
> binutils-bootstrap-0. 974 (99.39%)
> bootstrap-binaries-0. 974 (99.39%)
> file-5.19 974 (99.39%)
> findutils-4.4.2.. 974 (99.39%)
> diffutils-3.3 974 (99.39%)

Looks good.

It would be nice to show this info on the output of
build-aux/list-packages.scm (used to build
<https://www.gnu.org/software/guix/package-list.html>.)

Thanks,
Ludo’.

Re: [PATCH] gnu: Add xboing

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/games.scm (xboing): New variable.

OK, thanks.

Ludo’.

Re: [PATCH] guix: refresh: Use bags.

[Ludovic Courtès]

Eric Bavier  skribis:

> Ludovic Courtès writes:
>
>> Eric Bavier  skribis:
>>
>>> This patch may need to go in core-updates.
>>
>> Why?
>
> Would changes in gnu/packages.scm not trigger rebuilds for most
> packages?

No, because this file is just a “host-side” module, it is not used as an
input to build processes.

>> It would be nice to show this info on the output of
>> build-aux/list-packages.scm (used to build
>> <https://www.gnu.org/software/guix/package-list.html>.)
>
> That would be nice, yes.  Did you have something specific in mind?
> Perhaps a line under "status" that says "X packages depend on this
> package"?

Yes, or just “used by X packages”.

Ludo’.

Re: [PATCH] emacs: Support auto-updating after performing REPL operation.

[Ludovic Courtès]

Alex Kost  skribis:

> Currently when a user performs some REPL operation using Emacs UI –
> e.g. installs a package from *Guix Package Info* buffer, information in
> that buffer stays the same, and he needs to press "g" there to revert
> the buffer.

By “information in the buffer”, what do you have in mind?  There’s
highlighting of installed packages, and marks.  Am I missing something?

Pressing ‘g’ removes marks and updates highlighting.

> The attached patches will add that missing feature: after finishing a
> REPL operation, a buffer from which this operation was performed will be
> automatically updated.

What if the operation fails?  For instance, you carefully select a bunch
of packages to install, and then the operation fails because of some
transient networking error, say.  In such a case, the *Guix Package
Info* buffer should *not* be updated IMO, because that would mean losing
all the marks for no reason.

WDYT?

Not commenting on the elisp code, you’re the master.  :-)

Thanks,
Ludo’.

Re: [PATCH] emacs: Support auto-updating after performing REPL operation.

[Ludovic Courtès]

Alex Kost  skribis:

> The attached patches will add that missing feature: after finishing a
> REPL operation, a buffer from which this operation was performed will be
> automatically updated.

It seems the second patch also applies to the *Guix Generation List*
buffer, right?

Ludo’.

Re: Things to do for 0.8

[Ludovic Courtès]

Some things didn’t work out as expected, but I think the time has come
to get ready for another release, within 2–4 weeks ideally.

Comments on what was planned and what’s left to be done:

>   - ‘ungexp-native’ added, like ‘ungexp’, but to allow a gexp to
> explicitly refer to a native package (in case of cross-compilation.)
>
>   - Build system implementations converted to use gexps.
>
>   - New package API, like ‘package-derivation’ but using gexps.  Some
> packages converted to the new style.

This won’t be for this time, partly because it needs more thought.  (One
problem if we allow use of gexps in package declarations is that it will
make it harder to create variants that use different inputs.)

>   - guix.el integrated, with necessary refactorings done in (guix
> profiles) and (guix scripts package).
>
>   - In ‘operating-system’, support for dm-crypt and swap devices added
> (among other things.)

Done.

>   - Improved ‘slim-service’: users can choose among different kinds of
> sessions, which requires .desktop files for slim to know about the
> session types.

Would-be-nice, but non blocking.

>   - New service definitions, new packages, etc.

I’d like to add at least an mcron service.

>   - httpd or similar installed on hydra.gnu.org, with caching for the
> .narinfo pages, after which wip-http-pipelining can be merged.

It would be great to have it done for 0.8, but that shouldn’t be
blocking.

Additional items:

  - Grafts merged.

  - Configuration of libc’s name service switch (NSS), optionally.

  - Testing, bug fix, improvements of the installation image.

  - Possibly updated daemon code from Nix (this requires moving away
from the git submodule approach to filter-branch + read-tree so we
can maintain our own branch of it.)

  - GRUB + SLiM artwork anyone?  :-)

What do people think?

Thanks,
Ludo’.

Re: bug#18524: Guix unable to download from github due to TLS fatal alert

[Ludovic Courtès]

I had managed to bork ‘set-session-server-name!’ in GnuTLS (which
addresses this bug), so this is fixed in commit 5186158 and upstream:
.

Sorry about that!

Ludo’.

Re: Grafts

[Ludovic Courtès]

Mark H Weaver  skribis:

> If you want a real example, upstream bash is at 4.3.30, whereas we only
> have 4.3.27.

Yes, I have it in my working tree, and will push shortly.  :-)

Ludo’.

Re: [PATCH v2] guix lint: add the --checkers option.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> * guix/scripts/lint.scm: add the "--checkers" option.
> * doc/guix.texi (Invoking guix lint): Document it.
> * tests/guix-lint.sh: New file
> * Makefile.am (SCM_TESTS): Add it.

[...]

> +export GUIX_PACKAGE_PATH=$module_dir

I had overlooked this, but it’s also a Bash extension.  Use:

  GUIX_PACKAGE_PATH="$module_dir"
  export GUIX_PACKAGE_PATH

OK to push with this change, thank you!

Ludo’.

Re: [PATCH] emacs: Support auto-updating after performing REPL operation.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-14 23:17 +0400) wrote:
>
>> Alex Kost  skribis:
>>
>>> Currently when a user performs some REPL operation using Emacs UI –
>>> e.g. installs a package from *Guix Package Info* buffer, information in
>>> that buffer stays the same, and he needs to press "g" there to revert
>>> the buffer.
>>
>> By “information in the buffer”, what do you have in mind?  There’s
>> highlighting of installed packages, and marks.  Am I missing something?
>>
>> Pressing ‘g’ removes marks and updates highlighting.
>
> "Installed" column is also being changed.  And in the list of installed
> packages, deleted packages disappear (I mean if you delete some packages
> and press "g" there).  As for *Guix Package Info* buffer, there are many
> differences between installed and not-installed packages.
>
> I have in mind that all data will be updated.  Here is what revert
> (pressing "g") does in a Guix buffer:
>
> - the existing data is erased (using ‘erase-buffer’);
> - information about packages/generations is received again;
> - it is inserted in the buffer.

OK.

> I used to update information manually (before this change) and I think
> that such auto-updating is natural and is exactly what a user expects.
> Don't you agree?

I do!  (I even wondered if the Boolean to turn it off was necessary.)

>> What if the operation fails?  For instance, you carefully select a bunch
>> of packages to install, and then the operation fails because of some
>> transient networking error, say.  In such a case, the *Guix Package
>> Info* buffer should *not* be updated IMO, because that would mean losing
>> all the marks for no reason.
>
> Auto-updating happens only if a REPL operation was successful.  When a
> debugger prompt is entered (for example when a user interrupts the
> process with "C-c C-c"), buffers are not updated, so the marks will not
> be lost.

Perfect.

> Thanks for asking, it led me to the idea that if a package operation was
> "dry-run", then auto-updating shouldn't be performed as no changes were
> made.  I'll adjust the commit for this case (assuming that you agree
> with that :-))

Yes, agreed.

Ludo’.

Re: [PATCH] emacs: Support auto-updating after performing REPL operation.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-14 23:22 +0400) wrote:
>
>> Alex Kost  skribis:
>>
>>> The attached patches will add that missing feature: after finishing a
>>> REPL operation, a buffer from which this operation was performed will be
>>> automatically updated.
>>
>> It seems the second patch also applies to the *Guix Generation List*
>> buffer, right?
>
> Yes, auto-updating takes effect on any “guix list” or “guix info”
> buffer.  So if you execute deleting generations in *Guix Generations
> List*, this buffer will be reverted after the operation will be
> completed successfully in the REPL.  So deleted generations will
> "disappear" from the list.

Perfect then.  :-)

Ludo’.

Re: [PATCH] emacs: Support auto-updating after performing REPL operation.

[Ludovic Courtès]

Given that the concerns I raised were already addressed, of course feel
free to push these two patches!

Ludo’.

Re: [PATCH 2/3] guix import pypi: do not add "python-" to a package name if it's already there.

[Ludovic Courtès]

David Thompson  skribis:

> Cyril Roelandt  writes:
>
>> * guix/import/pypi.scm (make-pypi-sexp): test whether the package name starts
>>   with "python-" before modifying it.
>> ---
>>  guix/import/pypi.scm | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/guix/import/pypi.scm b/guix/import/pypi.scm
>> index 8f5e031..722ad9d 100644
>> --- a/guix/import/pypi.scm
>> +++ b/guix/import/pypi.scm
>> @@ -134,7 +134,9 @@ underscores."
>>"Return the `package' s-expression for a python package with the given 
>> NAME,
>>  VERSION, SOURCE-URL, HOME-PAGE, SYNOPSIS, DESCRIPTION, and LICENSE."
>>`(package
>> - (name ,(string-append "python-" (snake-case name)))
>> + (name ,(if (eq? (string-contains name "python-") 0)
>
> Could we do a regexp match instead?

Or (string-prefix? "python-" name) maybe?

Ludo’.

Re: [PATCH] emacs: Add 'guix-generations-by-time' command.

[Ludovic Courtès]

Alex Kost  skribis:

> I think sometimes it may be useful to select generations for a
> particular period of time.
>
>
> From 91cbf61d8cfb978a877f8c9f1b2174ffd3616556 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Thu, 16 Oct 2014 21:35:47 +0400
> Subject: [PATCH] emacs: Add 'guix-generations-by-time' command.
>
> * emacs/guix-main.scm (find-generations): Add finding generations by time.
> * emacs/guix-utils.el (guix-read-date): New procedure.
> * emacs/guix-base.el (guix-messages): Add new messages.
> * emacs/guix.el (guix-generations-by-time): New command.
> * doc/emacs.texi (emacs Commands): Document it.

I’m all for it, please commit.

Thank you!

Ludo’.

Re: Updating gnu-usb-install-0.7 to latest

[Ludovic Courtès]

Adam Pribyl  skribis:

> I am trying to find a way to update the existing installation of guix
> I did from gnu-usb-install-0.7 image to latest state of art, but guix
> pull fails... could someone point me how to do this, or is it not
> possible ATM?

You’ll have to run ‘guix pull’ from a recent checkout:

  http://lists.gnu.org/archive/html/guix-devel/2014-09/msg00488.html

HTH,
Ludo’.

Re: [PATCH] emacs: Improve interface for working with multiple profiles.

[Ludovic Courtès]

Alex Kost  skribis:

> The main changes are:
>
> - Now default buffer names look like this:
>
> *Guix Package List: guix-profile*
> *Guix Package Info: test4*
>
>   i.e., a buffer name contains a name of a profile used by this buffer.

Neat!

> - All commands for displaying generations and packages now can be called
>   with "C-u".  This allows to select a profile just for this command.
>   (The current profile can be changed with
>   "M-x guix-set-current-profile").

Wonderful!  :-)

What about renaming ‘guix-set-current-profile’ to
‘guix-set-default-profile’?  Because now, what it does is just to define
the profile that is used when C-u isn’t used, right?

> Also as prefix argument was previously used in "M-x guix-generations" to
> select last N generations, I added a new command "M-x
> guix-last-generations".

OK.

>  @item M-x guix-generations
> -List generations for the current profile.  With numeric prefix, show so
> -many last generations.
> +List all generations for the current profile.
   ^^^^
“all the generations”

For all these commands, it may be better to omit “current”, because it’s
not necessary the current/default profile that is used.

> +@item M-x guix-last-generations
> +List last generations for the current profile. You will be prompted for
> +the number of generations.

Maybe: “List the @var{N} last generations of the profile.”
Also, double space after period.

> -By default commands for displaying packages display each output on a
> +All these commands use current profile, which can be changed with
> +@kbd{M-x@tie{}guix-set-current-profile}.  Also if you call any of these
> +commands with prefix argument (@kbd{C-u}), you will be prompted for a
> +profile just for that command.

s/current/default/ ?

I wonder if it might be better to move this paragraph above the first
command, so it’s clear which profile we’re talking about.

> -For example if you want to display all types of results in a single
> +By default, the name of a profile is also displayed in a ``list'' or
> +''info'' buffer name.  To change this behavior, use
   ^^
backquotes

Nothing else to add.  Thanks for being so productive!

Ludo’.

Re: [PATCH] emacs: Improve interface for working with multiple profiles.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-17 23:29 +0400) wrote:
>
>> Alex Kost  skribis:
>
> [...]
>
>> What about renaming ‘guix-set-current-profile’ to
>> ‘guix-set-default-profile’?  Because now, what it does is just to define
>> the profile that is used when C-u isn’t used, right?
>
> Right, but I think it shouldn't be renamed as "default profile" and
> "current profile" have different meanings there:
>
> - default profile is "/var/guix/profiles/per-user/user/guix-profile" (or
>   whatever) and it is “fixed”;
>
> - current profile is used by commands (as you pointed) and it may be
>   changed.
>
> For example, a user decides to look at generations and installed
> packages of some profile.  So he may "M-x guix-set-current-profile ...",
> then "M-x guix-generations" and "M-x guix-installed-packages".  After
> that he could switch to another profile or to a default profile using
> "C-u M-x guix-set-current-profile".
>
> (there are even 2 variables: guix-default-profile and
> guix-current-profile)

OK, let’s keep it as ‘guix-set-current-profile’ then.

> Hawk eye :-)

Heheh.  :-)

OK to commit with those little changes!

Ludo’.

Re: Grafts

[Ludovic Courtès]

The current status of ‘wip-grafts’ is that it works, there’s no
performance issue, etc.

However, the ‘graft-derivation’ procedure is not recursive: it grafts
the derivation you give it, but doesn’t graft its dependencies.  Thus,
only direct references are grafted, which isn’t so great:

  $ guix gc -R $(guix build glib) | grep bash
  /gnu/store/8fmgslrivicy54azysmaab3z1srid773-bash-4.3.27  <--+--- the 
ungrafted bash
  /gnu/store/3yiqz9wmwx6b7hpbapg5q39sjx33kh0j-bash-4.3.27  <--’
  /gnu/store/yl1rp2b8i2qwgxja3d09xc24ffk9sjmr-bash-4.3.27  <-- the grafted 
bash

Changing ‘graft-derivation’ to work recursively and perform well is a
bit challenging.

I’m posting the naive patch I have here, in case someone can look at it
before me.

Ludo’.

	Modified   guix/derivations.scm
diff --git a/guix/derivations.scm b/guix/derivations.scm
index 17c83e9..632bf8e 100644
--- a/guix/derivations.scm
+++ b/guix/derivations.scm
@@ -1007,40 +1009,51 @@ applied."
  target
  grafts))
 
-  (define outputs
-(match (derivation-outputs drv)
-  (((names . outputs) ...)
-   (map derivation-output-path outputs
-
-  (define output-names
-(match (derivation-outputs drv)
-  (((names . outputs) ...)
-   names)))
-
-  (define build
-`(begin
-   (use-modules (guix build graft)
-(guix build utils)
-(ice-9 match))
-
-   (let ((mapping ',mapping))
- (for-each (lambda (input output)
- (format #t "rewriting '~a' to '~a'...~%" input output)
- (rewrite-directory input output
-`((,input . ,output)
-  ,@mapping)))
-   ',outputs
-   (match %outputs
- (((names . files) ...)
-  files))
+  (define input-mapping
+(match-lambda
+ (($  path sub-drv)
+  (let ((orig (call-with-input-file path read-derivation)))
+(cons orig
+  (graft-derivation store (derivation-name orig) orig grafts
+#:guile guile
+#:system system))
 
   (define add-label
 (cut cons "x" <>))
 
   (match grafts
 ((($  sources source-outputs targets target-outputs) ...)
- (let ((sources (zip sources source-outputs))
-   (targets (zip targets target-outputs)))
+ (let* ((sources (zip sources source-outputs))
+(targets (zip targets target-outputs))
+(inputs  (map input-mapping (derivation-inputs drv)))
+(drv (pk 'm (map-derivation store drv inputs
+   (define outputs
+ (match (derivation-outputs drv)
+   (((names . outputs) ...)
+(map derivation-output-path outputs
+
+   (define output-names
+ (match (derivation-outputs drv)
+   (((names . outputs) ...)
+names)))
+
+   (define build
+ `(begin
+(use-modules (guix build graft)
+ (guix build utils)
+ (ice-9 match))
+
+(let ((mapping ',mapping))
+  (for-each (lambda (input output)
+  (format #t "rewriting '~a' to '~a'...~%" input output)
+  (rewrite-directory input output
+ `((,input . ,output)
+   ,@mapping)))
+',outputs
+(match %outputs
+  (((names . files) ...)
+   files))
+
(build-expression->derivation store name build
  #:system system
  #:guile-for-build guile
	Modified   tests/derivations.scm
diff --git a/tests/derivations.scm b/tests/derivations.scm
index a69114a..608a7f6 100644
--- a/tests/derivations.scm
+++ b/tests/derivations.scm
@@ -851,6 +851,42 @@ Deriver: ~a~%"
 (string=? (readlink (string-append graft "/sh")) one)
 (string=? (readlink (string-append graft "/self")) graft))
 
+(test-assert "graft-derivation, recursive"
+  (let* ((build `(begin
+   (mkdir %output)
+   (chdir %output)
+   (call-with-output-file "text"
+ (lambda (output)
+   (format output "foo/~a/bar" ,%mkdir)))
+   (symlink ,%bash "sh")))
+ (dep   (build-expression->derivation %store "dep" build
+  #:inputs `(("a" ,%bash)
+ ("b" ,%mkdir
+ (orig  (build-expression->derivation %store "graft"
+  `(symlink
+(assoc-ref %build-inputs "dep")
+  

Re: [PATCH 1/1] Factor out a common pattern into a procedure.

[Ludovic Courtès]

John Darrington  skribis:

> On Sat, Oct 18, 2014 at 10:03:42PM -0400, Ian Denhardt wrote:

Thanks, Ian, for working on it!

[...]

>  +(define (version-take-api version-string)
>  +  "Return \".\", where major and minor are the major and
>  +minor version numbers from version-string."
>  +  (string-join (take (string-split version-string #\.) 2) "."))
>  +
>   (define (version>? a b)
> "Return #t when A denotes a newer version than B."
> (eq? '> (version-compare a b)))
>
>
> It seems likely to me, that sometime we'll need the number of fields to be 
> parameterised,
> instead of hard coded at 2  (for example lynx has a directory component with 
> 3 fields in its URL)
>
> Also I don't understand the significnace of the name version-take-api What 
> does API have to
> do with anything?
>
> How about something like (string-take-fields "1.22.3.04.5" 3) which would 
> return "1.22.3"

Agreed.  What ‘version-prefix’, with the optional argument defaulting
to 2?

> Possibly an optional argument specifying the separator might be useful too.

I think that’d be overkill.

Ludo’.

Re: [PATCH] gnu: Add sane-backends

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/scanner.scm: New file.
> * gnu-system.am (gnu/packages/scanner.scm): Add it.

Should be:

* gnu-system.am (GNU_SYSTEM_MODULES): Add it.

> +  #:use-module ((guix licenses)
> +#:renamer (symbol-prefix-proc 'license:)))

Use: #:prefix license: .

> +(define-public sane-backends
> +  (package
> +(name "sane-backends")
> +(version "1.0.24")
> +(source (origin
> + (method url-fetch)
> + (uri (string-append 
> +   "http://fossies.org/linux/misc/"; name "-" version 
> ".tar.gz"))
> + ;; This is a private mirror.  The canonical download site is
> + ;; "https://alioth.debian.org/frs/download.php/file/3958/";
> + ;; but it seems not to work with gnutls atm

Indeed, I get 406 "Not Acceptable".  I’m not sure if this relates to
; could you open a bug?

In the meantime, can you put the two URLs, as in:

  (uri (list (string-append ...)
 (string-append ...)))

> +(build-system gnu-build-system)
> +(arguments
> + `(#:tests? #f)) ; It would seem that tests are not maintained

What exactly is failing?  In the comment, please put facts on what’s
failing rather than guesses.  ;-)

> +(home-page "http://www.sane-project.org";)
> +(synopsis "Raster image scanner hardware API")

Maybe “SANE hardware drivers”?

> +(description "SANE stands for \"Scanner Access Now Easy\" and is an API
> +proving access to any raster image scanner hardware (flatbed scanner,
> +hand-held scanner, video- and still-cameras, frame-grabbers, etc.)..")  

Likewise, maybe state that this package provides the drivers.

Thanks,
Ludo’.

Re: [PATCH] gnu: Add sane-backends

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> John Darrington  skribis:

[...]

>> + (uri (string-append 
>> +   "http://fossies.org/linux/misc/"; name "-" version 
>> ".tar.gz"))
>> + ;; This is a private mirror.  The canonical download site is
>> + ;; "https://alioth.debian.org/frs/download.php/file/3958/";
>> + ;; but it seems not to work with gnutls atm
>
> Indeed, I get 406 "Not Acceptable".

A bit of investigation, and now commit 38bf090 fixes it.

Thanks,
Ludo’.

Re: [PATCH] gnu: Add sane-backends

[Ludovic Courtès]

John Darrington  skribis:

> +;; It would seem that tests are not maintained - fails with
> +;; the following:
> +;;
> +;; < This page was last updated on Wed Jul 31 07:52:48 2013
> +;; <  by sane-desc 3.5 from sane-backends 1.0.24git
> +;; ---
> +;; > This page was last updated on Sun Oct 19 15:41:39 2014
> +;; >  by sane-desc 3.5 from sane-backends 1.0.24
> +;;  File generated for html-backends-split mode is different from 
> reference
> +;; Makefile:501: recipe for target 'check.local' failed

Perhaps it would be worth trying to s/24git/24/ and see if it works.
WDYT?

Thanks,
Ludo’.

Re: [PATCH 1/1] Factor out a common pattern into a procedure.

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> John Darrington  skribis:
>>
>>> How about something like (string-take-fields "1.22.3.04.5" 3) which would 
>>> return "1.22.3"
>>
>> Agreed.  What ‘version-prefix’, with the optional argument defaulting
>> to 2?
>
> I also like 'version-prefix', although I'd favor making it a required
> argument.  The improved code clarity is well worth two extra characters.

OK, let’s do that.

Ian: could you post an updated patch?

Thanks,
Ludo’.

Re: [PATCH] gnu: Add sane-backends

[Ludovic Courtès]

John Darrington  skribis:

> On Sun, Oct 19, 2014 at 07:44:28PM +0200, Ludovic Court??s wrote:
>  John Darrington  skribis:
>  
>  > +;; It would seem that tests are not maintained - fails with
>  > +;; the following:
>  > +;;
>  > +;; < This page was last updated on Wed Jul 31 07:52:48 2013
>  > +;; <  by sane-desc 3.5 from sane-backends 1.0.24git
>  > +;; ---
>  > +;; > This page was last updated on Sun Oct 19 15:41:39 2014
>  > +;; >  by sane-desc 3.5 from sane-backends 1.0.24
>  > +;;  File generated for html-backends-split mode is different 
> from reference
>  > +;; Makefile:501: recipe for target 'check.local' failed
>  
>  Perhaps it would be worth trying to s/24git/24/ and see if it works.
>  WDYT?
>  
> Well presumably the date would have to be substituted too.

Oh, right; I had overlooked that.

> I wonder how much it is wise to second guess what the developers wanted.  
> Presumably 
> upstream haven't run "make check" since Jul 31 2013, so it seems that they 
> don't
> consider it important.

Yes, that makes sense.

OK to commit, then.

Thanks,
Ludo’.

Re: [PATCH 1/1] Factor out a common pattern into a procedure.

[Ludovic Courtès]

Ian Denhardt  skribis:

> How about this: separate it out into to functions: version-prefix, which
> is the same as what I have now, but takes a (mandatory) argument
> specifying the number of fields, and feature-version, which is defined
> like:
>
> (define (feature-version version) (version-prefix version 2))
>
> ..with an appropriate docstring explaining the use case. Thoughts?

Sounds good to me, although I’d rather call ‘feature-version’, say,
‘version-major+minor’, on the grounds that the semantics of version
numbers are specific to each project.  Mark?

(Please forgive the extra bikeshedding.  ;-))

Thanks,
Ludo’.

Re: [PATCH v2 1/1] Factor out a common pattern into a procedure.

[Ludovic Courtès]

Ian Denhardt  skribis:

> The procedure version-prefix truncates a version string to a certain
> number of components. version-major+minor is a special case of this,
> which extracts the "major.minor" part of the string. Previously this
> was handled by an expression common to several packages.
>
> * guix/utils.scm (version-prefix, version-major+minor): New procedures
> * gnu/packages/backup.scm (duplicity): Use version-major+minor.
> * gnu/packages/cmake.scm (cmake): Likewise.
> * gnu/packages/gnome.scm (libbonobo, libbonoboui): Likewise.
> * gnu/packages/gnutls.scm (gnutls): Likewise.
> * gnu/packages/mail.scm (gmime): Likewise.
> * gnu/packages/mpd.scm (mpd): Likewise.
> * gnu/packages/mpi.scm (openmpi): Likewise.

Thanks, pushed!  I’ve made the subject line more explicit.

Also, note that the paragraph above isn’t strictly necessary because
these procedures have docstrings anyway.

Ludo’.

Re: Update sqlite

[Ludovic Courtès]

Hi!

Andreas Enge  skribis:

> needing sqlite, I wondered if I could not quickly update it to the latest
> version. It appears that sqlite-large-page-size-fix.patch does not apply
> any more. Mark, as you added it, could you maybe check if it is still needed?

I can’t tell for the MIPS patch, but ‘guix refresh -l sqlite’ says only
19 packages depend on it, so it’s safe to update anytime on ‘master’.

Ludo’.

Re: [PATCH] guix: refresh: Use bags.

[Ludovic Courtès]

Eric Bavier  skribis:

> Ludovic Courtès writes:
>
>> Eric Bavier  skribis:
>>
>>> Ludovic Courtès writes:
>>>
>>> From 1d22367e0806cea004631e22a782b7db3ffe65b0 Mon Sep 17 00:00:00 2001
>>> From: Eric Bavier 
>>> Date: Mon, 13 Oct 2014 13:46:09 -0500
>>> Subject: [PATCH] guix: refresh: Use bags.
>>>
>>> * guix/packages.scm (bag-direct-inputs): New procedure.
>>> * gnu/packages.scm (package-dependencies): Use it.
>>>   (fold-packages*): New procedure.
>>> * guix/scripts/refresh.scm (guix-refresh)[list-dependent]: Use it.
>>
>> [...]
>>
>> Could you move the computation of the package list to a different
>> procedure?  Possibly merging it with the existing expression that
>> computes ‘packages’ and which is already quite big.
>
> New patch attached that cleans up the package list computation a bit.
>
>
> From 0125e2d9a1564eb5e0817d50ea304bb4cb8d7030 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Mon, 20 Oct 2014 11:44:03 -0500
> Subject: [PATCH] guix: refresh: Use bags.
>
> * guix/packages.scm (bag-direct-inputs): New procedure.
> * gnu/packages.scm (package-dependencies): Use it.
>   (fold-packages*): New procedure.
> * guix/scripts/refresh.scm (guix-refresh)[list-dependent]: Use it.

Looks good to me.

Ideally, we’d make one patch for the refactor, one for the new feature,
and one for the ‘guix refresh -l’ change, for easier review and
bisection should a regression be found, but that’s OK here.

> This patch also changes the behavior of `guix refresh` a little.
> Previously, if there were a package with two versions, e.g. bison-2.7
> and bison-3.0.2, `guix refresh bison` would report::
>
>   gnu/packages/bison.scm:33:4: bison would be upgraded from 2.7 to 3.0.2
>
> Which is silly because we already have a bison-3.0.2.  This patch uses
> specification->package for the command-line named packages, so that only
> the newest version of a package is considered by default for upgrading.
> I would imagine this is the expected behavior.

Yes, that’s definitely an improvement.

In some cases, such as old stable branches of GCC, the situation is more
complex, but the general case is as you describe.

Thanks!

Ludo’.