Re: Haunt locale bug

[Daniel Pimentel]

Hi Guixs,

after I added this in my .bashrc:
export LC_ALL=C

Haunt works.

But, with locale set to en_US.UTF-8 not work to me.

Thanks,

--
Daniel Pimentel (aka d4n1)

Re: Haunt locale bug

[Daniel Pimentel]

Hi Alex,

I did:

export LC_ALL=C

It works now.

So, I added in my .bashrc.

--
Daniel Pimentel (aka d4n1)

Re: Reverse dependencies

[Eric Bavier]

On 2016-08-12 11:24, Chris Marusich wrote:

Eric Bavier  writes:


On 2016-08-11 09:43, Vincent Legoll wrote:

Hello,


I'm trying to understand which package(s) depends on some other
package,
kind of the reverse of what guix graph does (I think).


I think that `guix refresh --list-dependent foo` is what you are
asking
for, or at least it's close. We use it to learn what will need to be
rebuilt when upgrading foo.


Not really what I want to know:

# guix refresh --list-dependent inkscape
Building the following 5 packages would ensure 10 dependent packages
are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
termite-11 hydra-20150407.4c0e3e4

None of those are installed, but inkscape is pulled in by something
which I want to know

Is there no other way to get that information ?


Something like (mildly tested):

(use-modules (guix packages)
 (gnu packages)
 (gnu packages inkscape)
 (srfi srfi-1)
 (srfi srfi-26))

(fold-packages
  (lambda (package _)
(when (any (cut eq? <> inkscape)
   (map second (package-direct-inputs package)))
  (format #t "~a depends on inkscape~%"
  (package-full-name package
  #t)

which, when run, results in:
"dblatex-0.3.5 depends on inkscape"


The 'guix graph' command has the ability to print out references, but 
my
understanding is that because these are the references which result 
from

Nix's scan of the output store path, these references will only be
runtime dependencies (see '(guix) Invoking guix graph' in the manual).


This is not completely accurate.  'guix graph's '--type' argument can be 
used to display different node types.  The 'references' type corresponds 
to run-time dependencies.


--
`~Eric

Re: Reverse dependencies

[Chris Marusich]

Eric Bavier  writes:

> On 2016-08-11 09:43, Vincent Legoll wrote:
>> Hello,
>>
 I'm trying to understand which package(s) depends on some other
 package,
 kind of the reverse of what guix graph does (I think).
>>>
>>> I think that `guix refresh --list-dependent foo` is what you are
>>> asking
>>> for, or at least it's close. We use it to learn what will need to be
>>> rebuilt when upgrading foo.
>>
>> Not really what I want to know:
>>
>> # guix refresh --list-dependent inkscape
>> Building the following 5 packages would ensure 10 dependent packages
>> are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
>> termite-11 hydra-20150407.4c0e3e4
>>
>> None of those are installed, but inkscape is pulled in by something
>> which I want to know
>>
>> Is there no other way to get that information ?
>
> Something like (mildly tested):
>
> (use-modules (guix packages)
>  (gnu packages)
>  (gnu packages inkscape)
>  (srfi srfi-1)
>  (srfi srfi-26))
>
> (fold-packages
>   (lambda (package _)
> (when (any (cut eq? <> inkscape)
>(map second (package-direct-inputs package)))
>   (format #t "~a depends on inkscape~%"
>   (package-full-name package
>   #t)
>
> which, when run, results in:
> "dblatex-0.3.5 depends on inkscape"

The 'guix graph' command has the ability to print out references, but my
understanding is that because these are the references which result from
Nix's scan of the output store path, these references will only be
runtime dependencies (see '(guix) Invoking guix graph' in the manual).

The 'guix gc' command has the ability to print out 'referrers', which
might also be useful.  See '(guix) Invoking guix gc' for details.  This
will show you components that refer to the specified store path.

I also hear that the Nix daemon can be configured to maintain a database
of derivers, which would let you find out which derivation generated a
given store path.  I don't know if Guix enables this by default.  If
it's enabled, then you could potentially investigate the derivation
which generated a store path (e.g., to see if the derivation references
inkscape), but I don't know of any automated tools for investigating
that stuff today.

-- 
Chris


signature.asc
Description: PGP signature

Re: Reverse dependencies

[Thompson, David]

On Fri, Aug 12, 2016 at 11:55 AM, Thompson, David
 wrote:

> I'd also like to point out that you can already use 'guix gc
> --referrers /gnu/store/-foo-1.0' to find out which store items
> depend on the one passed in.

I realize this is redundant with what I wrote above.  Hasty writing...
Sorry for the noise.

- Dave

Re: GNU sites down

[Chris Marusich]

Vincent Legoll  writes:

> Hello,
>
> I cannot connect to gnu.org sites since this morning

It's all loading for me right now.

-- 
Chris


signature.asc
Description: PGP signature

Re: Reverse dependencies

[Thompson, David]

On Fri, Aug 12, 2016 at 5:27 AM, Vincent Legoll
 wrote:
> Hello,
>
>> I think you mean inkscape is pulled when you build the system.  Then you
>> will not find it like this.  It is needed to build the fancy grub image,
>> and it is "pulled" by the system building code (specifically by
>> 'svg->png' procedure in (gnu system grub) module).  If you want to avoid
>> it, you can specify an "empty" theme for example:
>>
>>   (bootloader (grub-configuration (device "/dev/sda")
>>   (theme (grub-theme
>
> Thanks for that information, that was what I wanted to know (both the where
> does it come from, and the how to avoid it being pulled in)
>
> I think a "guix revdep $PKG" should be a valuable tool

While we can certainly make learning about this stuff easier, but
making a new subcommand with a cryptic name just for this purpose
wouldn't be a very good UI.

> it should work:
> 1 - globally in the list of defined packages
> 2 - locally in the list of packages from the current user's profile
> 3 - systemly, from the list of installed packages in the system profile

What do you define "dependencies" to be?  Using your situation as an
example, inkscape is *not* a dependency of the built system, but it is
a dependency of the *derivation* that builds the system.  Using
profiles wouldn't work because profiles may contain references to
store items that the current Guix has no knowledge of.  package
expression -> built package is a one way transformation.  What you can
do, however, is use 'guix gc --referrers' to get a list of store items
that refer to the store item passed in.  This still doesn't help you
in the inkscape case because the built system has no reference to
inkscape, it was just used in the build script.

I think the "right thing" here is to add features to 'guix graph' so
that it can make a referrer graph using the Scheme package graph.
'guix system' has graph subcommands already, so we could add one that
produces a full package dependency graph which would show you who
depends on inkscape.

Any volunteers? :)

I'd also like to point out that you can already use 'guix gc
--referrers /gnu/store/-foo-1.0' to find out which store items
depend on the one passed in.

- Dave

Re: GNU sites down

[Leo Famulari]

On Fri, Aug 12, 2016 at 04:20:59PM +0200, Vincent Legoll wrote:
> Hello,
> 
> I cannot connect to gnu.org sites since this morning
> see http://www.downornot.net/full-history?id=3073
> 
> I could get on hydra, though, so the entire domain is
> not AWOL, but a significant portion is (www, savannah,
> etc.)
> 
> Do anyone know if there's an ETA for availability?
> 
> BTW, in the mean time are there any mirrors for the
> www ?

The FSF sysadmins publish notices of downtime on their pump.io channel:

https://pumprock.net/fsfstatus

Re: How to install an old package version?

[Alex Kost]

Hartmut Goebel (2016-08-11 22:16 +0300) wrote:

> Hi,
>
> I'm curious about how to install an old package version with guix.
>
> Example for what I mean:
>
> In e.g Debian, the list of available packages is separate from
> apt-get (et al.). So I can query all available versions of a package
> and install the version I need:
>
>  $ apt-cache madison nginx
>  nginx | 1.9.10-1~bpo8+3 | http://debian.mirror.lrz.de/debian/
> jessie-backports/ma
>  nginx | 1.6.2-5+deb8u2 | http://security.debian.org/ jessie/
> updates/main amd64 Pa
>
>
> Now in guix, the list of available packages is build into guix, there
> is no external cache. So how can I e.g. install python-2.7.10 after I
> installed guix 0.11.0, which only defines python-2.7.11?

You have to make your own package for this version, that would look like
this:

(define-public python-2.7.10
  (package
(inherit python)
(version "2.7.10")
(source (origin
  (inherit (package-source python-2.7))
  (uri (string-append "https://www.python.org/ftp/python/;
  version "/Python-" version ".tar.xz"))
  (sha256 (base32 "some-letters-and-numbers"))

and to put it to a file from GUIX_PACKAGE_PATH.
See (info "(guix) Package Modules") for details.

Alternatively, you can use a guix git checkout on a specific commit that
still has python-2.7.10, but it's probably not what you want.

-- 
Alex

Re: Reverse dependencies

[Vincent Legoll]

Hello,

> I think you mean inkscape is pulled when you build the system.  Then you
> will not find it like this.  It is needed to build the fancy grub image,
> and it is "pulled" by the system building code (specifically by
> 'svg->png' procedure in (gnu system grub) module).  If you want to avoid
> it, you can specify an "empty" theme for example:
>
>   (bootloader (grub-configuration (device "/dev/sda")
>   (theme (grub-theme

Thanks for that information, that was what I wanted to know (both the where
does it come from, and the how to avoid it being pulled in)

I think a "guix revdep $PKG" should be a valuable tool

it should work:
1 - globally in the list of defined packages
2 - locally in the list of packages from the current user's profile
3 - systemly, from the list of installed packages in the system profile

I'm trying Eric's suggestion (thanks Eric), and that seems to do 1, I need
a way to modify it to do the other 2... (see the attached script)

WDYT ?

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

(use-modules (guix packages)
 (gnu packages)
 (srfi srfi-1)
 (srfi srfi-26)
 (ice-9 getopt-long))
 	
(define (revdep pkg)
  (fold-packages
(lambda (package _)
  (when (any (cut eq? <> (specification->package pkg))
 (map second (package-direct-inputs package)))
(format #t "~a depends on ~a~%"
(package-full-name package) pkg)))
#t))

(define (main args)
  (let* ((option-spec '((version (single-char #\v) (value #f))
(help(single-char #\h) (value #f
 (options (getopt-long args option-spec))
 (help-wanted (option-ref options 'help #f))
 (version-wanted (option-ref options 'version #f))
 (pkgs (option-ref options '() #f)))
(if (or version-wanted help-wanted)
(begin
  (if version-wanted
  (display "revdep.scm version 0.1\n"))
  (if help-wanted
  (display "\
revdev.scm [options|package names]
  -v, --versionDisplay version
  -h, --help   Display this help\n")))
(map revdep pkgs

(main (command-line))

guix pull parallelism

[Vincent Legoll]

Hello,

it does look like some parts of "guix pull" are parallelized
as I was seeing guix-daemon's child guile take 200% CPU during :

loading... 23.5% of 511 filesrandom seed for tests: 1471011793
loading... 99.8% of 511 files
compiling... 99.6% of 511 files

So far so good, nice to use those cores that would stay idle.

But...

$ grep -c ^processor /proc/cpuinfo
3

So why is that not a ~300% is there only parallelism for 2 threads,
or is it an unintended side effect and there is no parallelism ?

If it had been ~100% or ~300% I would not have asked, but that
200% looks wrong one (missed a core) way or the other (no
parallelism)...

Thanks for feeding my curiosity...

-- 
Vincent Legoll

Re: Reverse dependencies

[Alex Kost]

Vincent Legoll (2016-08-11 17:43 +0300) wrote:

> Hello,
>
>>> I'm trying to understand which package(s) depends on some other package,
>>> kind of the reverse of what guix graph does (I think).
>>
>> I think that `guix refresh --list-dependent foo` is what you are asking
>> for, or at least it's close. We use it to learn what will need to be
>> rebuilt when upgrading foo.
>
> Not really what I want to know:
>
> # guix refresh --list-dependent inkscape
> Building the following 5 packages would ensure 10 dependent packages
> are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
> termite-11 hydra-20150407.4c0e3e4
>
> None of those are installed, but inkscape is pulled in by something
> which I want to know

I think you mean inkscape is pulled when you build the system.  Then you
will not find it like this.  It is needed to build the fancy grub image,
and it is "pulled" by the system building code (specifically by
'svg->png' procedure in (gnu system grub) module).  If you want to avoid
it, you can specify an "empty" theme for example:

  (bootloader (grub-configuration (device "/dev/sda")
  (theme (grub-theme

-- 
Alex

GNU sites down

[Vincent Legoll]

Hello,

I cannot connect to gnu.org sites since this morning
see http://www.downornot.net/full-history?id=3073

I could get on hydra, though, so the entire domain is
not AWOL, but a significant portion is (www, savannah,
etc.)

Do anyone know if there's an ETA for availability?

BTW, in the mean time are there any mirrors for the
www ?

-- 
Vincent Legoll