Re: Why is GCL built with gcc@4.9?

[Efraim Flashner]

On Thu, Dec 13, 2018 at 10:33:48PM +0200, Efraim Flashner wrote:
> On Thu, Dec 13, 2018 at 12:03:59AM -0500, Mark H Weaver wrote:
> > Hi Efraim,
> > 
> > I'm curious about this commit of yours from April 2017:
> > 
> > --8<---cut here---start->8---
> > commit 5c7815f205e9164d4b82378de91bee7a65bcfbcb
> > Author: Efraim Flashner 
> > Date:   Mon Apr 10 05:20:09 2017 +0300
> > 
> > gnu: gcl: Build with gcc@4.9.
> > 
> > * gnu/packages/lisp.scm (gcl)[native-inputs]: Add gcc@4.9.
> > --8<---cut here---end--->8---
> > 
> > Do you remember why you did this?  There's no explanation in the
> > comments, nor in the commit log, nor in the 'bug-guix' or 'guix-devel'
> > email archives from around that time.
> > 
> > I'd like to remove it, and I've verified that on x86_64-linux, GCL
> > builds successfully with the default compiler.
> > 
> > In general, it would be good to include comments with rationale for
> > workarounds like this, so that we have some idea of when the workaround
> > can be removed, and what tests we must do to ensure that the original
> > problem has been addressed.
> > 
> >  Thanks,
> >Mark
> 
> I looked through the commits and I'm not sure why I added gcc@4.9. When
> did we change our default gcc from 4.9 to 5? I've made one attempt so
> far at building on aarch64-linux without gcc@4.9 and I got a core-dump
> but I haven't built it recently to see if it does that as-is.
> 
> I'll take a closer look at it and try to see what's up.
> 

I tried compiling gcl with gcc@7 also and it still failed on aarch64.
The closest I have to a clue is that Debian's rule file has commented
out to use gcc@4.6, so I'm guessing that following our upgrade to
building with gcc@5 the package broke and it worked for a time with
gcc@4.9. Since it fails to build in any case on aarch64 and building
with gcc@5 doesn't cause any problems I'll go ahead and remove it.


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


signature.asc
Description: PGP signature

Re: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Hi Ludo,

On Fri, 14 Dec 2018 11:48:52 +0100
Ludovic Courtès  wrote:

> I believe you can download it by running:
> 
>   guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv

I don't have it.

> If you don’t have this .drv, you should be able to build it from commit
> cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.

I tried

./pre-inst-env guix system disk-image --system=armhf-linux -e '(begin 
(use-modules (gnu system) (gnu bootloader) (gnu bootloader u-boot) (gnu system 
install)) (operating-system (inherit installation-os) (bootloader 
(bootloader-configuration (bootloader u-boot-bootloader) (target #f)'

and I get:

[...]
The following package will be installed:
   guile-bootstrap  2.0 
/tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0

The following derivation will be built:
   /tmp/guix-tests/store/dmmv0dnc8wvx9m12mln90w4b26sdxq5v-profile.drv
building /tmp/guix-tests/store/dmmv0dnc8wvx9m12mln90w4b26sdxq5v-profile.drv...
1 package in profile
The following environment variable definitions may be needed:
   export PATH="t-profile-15269/bin${PATH:+:}$PATH"
++ guix package -A guile-bootstrap
++ cut -f 1-2
Backtrace:
In guix/ui.scm:
  1603:12 19 (run-guix-command _ . _)
In ice-9/boot-9.scm:
829:9 18 (catch _ _ # …)
829:9 17 (catch _ _ # …)
In guix/scripts/package.scm:
914:8 16 (_)
   729:25 15 (process-query _)
In guix/discovery.scm:
155:3 14 (fold-module-public-variables _ _ _)
In guix/combinators.scm:
45:26 13 (fold2 # …)
45:26 12 (fold2 # …)
In guix/discovery.scm:
   158:33 11 (_ # …)
In guix/scripts/package.scm:
   732:39 10 (_ # …)
In guix/packages.scm:
   777:17  9 (supported-package? # …)
In guix/memoization.scm:
101:0  8 (_ # # …)
In srfi/srfi-1.scm:
   466:18  7 (fold # …)
In guix/packages.scm:
   768:33  6 (_ _ ("x86_64-linux" "i686-linux" "armhf-linux" "aar…" …))
In guix/memoization.scm:
101:0  5 (_ # # …)
In guix/packages.scm:
   980:46  1 (thunk)
In gnu/packages/scheme.scm:
   170:30  0 (inputs)

gnu/packages/scheme.scm:170:30: In procedure inputs:
Throw to key `match-error' with args `("match" "no matching pattern" 
"armhf-linux")'.
++ guix package -p t-profile-15269 -I
++ cut -f 1-2
+ test '' = 'guile-bootstrap2.0'
+ rm -f t-profile-15269 t-profile-15269-1-link t-guix-package-file-15269
+ rm -rf t-guix-package-15269 t-home-15269
./test-env: line 1: 15250 Terminated  
"/tmp/guix-build-guix-0.16.0-4.60b0402.drv-0/source/pre-inst-env" 
"/tmp/guix-build-guix-0.16.0-4.60b0402.drv-0/source/guix-daemon" 
--disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL"
FAIL tests/guix-package.sh (exit status: 1)
[...]
/gnu/store/diwcb1v9lr156sg3q4ww1wvsniw4n6rf-module-import/guix/build/gnu-build-system.scm:369:6:
 In procedure check:
Throw to key `srfi-34' with args `(#)'.
builder for 
`/gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv' failed 
with exit code 1
build of /gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv 
failed
View build log at 
'/var/log/guix/drvs/db/f84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv.bz2'.
guix system: error: build failed: build of 
`/gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv' failed

And no image...


pgppR3qNVXNCA.pgp
Description: OpenPGP digital signature

Re: guix.gnu.org sub-domain

[Chris Marusich]

Hi Ludo,

Ludovic Courtès  writes:

> I’m sure Julien wouldn’t mind getting some help or insight, so please do
> get in touch!

OK, I'll speak privately with Julien about the DNS setup to avoid adding
noise to this email thread.

-- 
Chris


signature.asc
Description: PGP signature

Re: Golang programs keeping references [gnu: go: Update default to 1.11.]

[Leo Famulari]

On Sat, Dec 15, 2018 at 07:19:49PM +0100, Pierre Neidhardt wrote:
> 
> > So hmm, you’re right!  I’m sure I saw go packages somewhere, dunno…
> 
> Just looked at the source: after my Go 1.11 update, Syncthing was updated to 
> use
> vendored dependencies, just like go-ipfs.  This is why it does not contains 
> any
> go ref.  From the package declaration:
> 
>   ;; Since the update to Go 1.11, Go programs have been keeping
>   ;; spurious references to all their dependencies:
>   ;; .
>   ;; For Syncthing, this increases the size of the 'out' closure
>   ;; from 87.6 MiB to 253.5 MiB.  So, we use the bundled
>   ;; dependencies until the bug is resolved.
>   
> So yup, "guix size" is not happy with Go...

That's right. I've previously audited Syncthing's dependencies and I'm
sure they are all free software. Additionally, the Syncthing project is
committed to shipping free software.

Because the closure size had grown way too big, and we don't have a plan
for fixing the issue with Go 1.11, I decided to just use the bundled
dependencies.

Hopefully we can switch it back at some point. I haven't investigated
this particular issue very much, so I don't know how feasible it will
be. I do know that it is basically not supported by the Go community.


signature.asc
Description: PGP signature

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

Hi Andreas,

On Sat, 15 Dec 2018 11:29:06 +0100
Andreas Enge  wrote:

> On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
> > can you check whether dirindex (hashtables for directory) is enabled?
> > # tune2fs -l /dev/... | grep -o dir_index
> > See also 
> > https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html  
> 
> It was, and I disabled it. Hopefully this does not break anything...
> But does this not mean a big performance hit on /gnu/store/.links?

It does mean that because it uses a linear search to find the file names now.

What ext filesystem is it?

https://en.wikipedia.org/wiki/Ext4 says that ext4 supports B trees - which
should have no problems with hash collisions (it uses operator< to construct
a tree -- and not hashes to construct a list).


pgppoffvtH3X2.pgp
Description: OpenPGP digital signature

Re: Golang programs keeping references [gnu: go: Update default to 1.11.]

[Leo Famulari]

On Sat, Dec 15, 2018 at 07:19:49PM +0100, Pierre Neidhardt wrote:
> 
> > So hmm, you’re right!  I’m sure I saw go packages somewhere, dunno…
> 
> Just looked at the source: after my Go 1.11 update, Syncthing was updated to 
> use
> vendored dependencies, just like go-ipfs.  This is why it does not contains 
> any
> go ref.  From the package declaration:
> 
>   ;; Since the update to Go 1.11, Go programs have been keeping
>   ;; spurious references to all their dependencies:
>   ;; .
>   ;; For Syncthing, this increases the size of the 'out' closure
>   ;; from 87.6 MiB to 253.5 MiB.  So, we use the bundled
>   ;; dependencies until the bug is resolved.
>   
> So yup, "guix size" is not happy with Go...

Also, can we please keep this discussion in the bug report thread?

https://bugs.gnu.org/33620


signature.asc
Description: PGP signature

Re: [GWL] (random) next steps?

[Ricardo Wurmus]

Hi simon,

> Here, I would like to collect some discussions or ideas about the Guix
> Workflow Language (GWL) and the next steps of this awesome tool!

thanks for kicking off this discussion!

> With wisp, the workflow description seems close to CWL, which is an argument 
> ;-)
> Last time, I check, CWL files seems flat yaml-like files and they lack
> programmable extension; as Snakemake provides with Python for example.
> And GWL-wisp will have both: easy syntax and programmable stuff,
> because it is still lisp under the hood.

I’m working on updating the GWL manual to show a simple wispy example.

> 4.
> Some GWL scripts are already there.
> Could we centralize them to one repo?
> Even if they are not clean. I mean something in this flavor:
> https://github.com/common-workflow-language/workflows

I only know of Roel’s ATACseq workflow[1], but we could add a few more
independent process definitions for simple tasks such as sequence
alignment, trimming, etc.  This could be a git subtree that includes an
independent repository.

[1]: https://github.com/UMCUGenetics/gwl-atacseq/

> 5.
> I recently have discovered the ELisp package `s.el` via the blog post:
> http://kitchingroup.cheme.cmu.edu/blog/2018/05/14/f-strings-in-emacs-lisp/
> or other said:
> https://github.com/alphapapa/elexandria/blob/master/elexandria.el#L224
>
> Does it appear to you a right path to write a "formater" in this
> flavour instead of the `string-append` ?
> I mean, e.g.,
>   `(system ,(string-command "gzip  ${data-inputs}  -c >  ${outputs}"))
> instead of e.g.,
>   `(system ,(string-append "gzip " data-inputs " -c > " outputs))
>
> It seems more on the flavour of  Snakemake.

Scheme itself has (format #f "…" foo bar) for string interpolation.
With a little macro we could generate the right “format” invocation, so
that the user could do something similar to what you suggested:

(shell "gzip ${data-inputs} -c > ${outputs}")

–> (system (format #f "gzip ~a -c > ~a" data-inputs outputs))

String concatenation is one possibility, but I hope we can do better
than that.  scsh offers special process forms that would allow us to do
things like this:

(shell (gzip ,data-inputs -c > ,outputs))

or

(run (gzip ,data-inputs -c)
 (> 1 ,outputs))

Maybe we can take some inspiration from scsh.

> 6.
> The graph of dependencies between the processes/units/rules is written
> by hand. What should be the best strategy to capture it ? By files "à
> la" Snakemake ? Other ?

The GWL currently does not use the input information provided by the
user in the data-inputs field.  For the content addressible store we
will need to change this.  The GWL will then be able of determining that
data-inputs are in fact the outputs of other processes.

> 7.
> Does it appear to you a good idea to provide a command `guix workflow pack` ?
> to produce an archive with the binaries or the commit hashes of the
> channels, etc.

This shouldn’t be difficult to implement as all the needed pieces
already exist.

> Last, the webpage [1] points to gwl-devel mailing list which seems broken.
> Does the gwl-devel need to be activated and the GWL discussion will
> append there or everything stay here to not scattered too much.
>
> [1] https://www.guixwl.org/community

Hmm, looks like the mailing list exists, but has never been used.
That’s why there is no archive.  Let’s see if this email creates this
archive.

--
Ricardo

Re: 01/01: hydra: Increase image sizes for USB image and Flash image.

[Maxim Cournoyer]

Hello!

On December 14, 2018 9:08:50 AM UTC, "Ludovic Courtès"  wrote:

[...]

>The good news is that there are other optimization opportunities.  :-)
>
>--8<---cut here---start->8---
>$ guix size $(guix system build gnu/system/install.scm) | head -10
>store item   total 
>  self
>/gnu/store/0zajbn9q39yva4l0zzrcshlll8qikzba-linux-libre-4.19.6
>236.5   236.5  21.2%
>/gnu/store/mdw00a2sq0qqyzqygmp9035g8r2rlslj-guix-0.15.0-8.71a78ba  
>345.7   182.3  16.3%
>/gnu/store/1lcniyxkxkh8g73zvh2gpbccvl6ggna7-locale-2.28
>91.891.8   8.2%
>/gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0   
>146.358.2   5.2%
>/gnu/store/ybglr7nfs8v9kpnm8vf4drg3gafnvd15-guile-static-stripped-2.2.4
>   45.945.9   4.1%
>/gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4   
>121.944.4   4.0%
>/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4   
>121.944.4   4.0%
>/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28 
>37.836.3   3.2%
>/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib  
>68.030.2   2.7%
>--8<---cut here---end--->8

Why does Guile 2.2.4 appear twice but with a different hash?

Maxim 

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
> can you check whether dirindex (hashtables for directory) is enabled?
> # tune2fs -l /dev/... | grep -o dir_index
> See also 
> https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

It was, and I disabled it. Hopefully this does not break anything...
But does this not mean a big performance hit on /gnu/store/.links?

Andreas

Re: 01/01: python: Honor '--cores=...' in tests.

[Christopher Baines]

Eric Bavier  writes:

> On Fri, 14 Dec 2018 15:50:37 +
> Christopher Baines  wrote:
>
>> Christopher Baines  writes:
>>
>> > Eric Bavier  writes:
>> >
>> > Since all the python packages look to inherit from python-2.7 that's
>> > being changed here, perhaps this worked for some of them (I know you
>> > mentioned python-minimal in one message), but not all of them, or at
>> > least python2?
>>
>> Just got around to testing this, moving this change to python-3.7, from
>> python-2.7 fixes the python-2.7 build for me, but I haven't checked
>> how that affects how many cores are actually used when running the tests.
>
> Strange.  I recall testing this patch on both python2 and python.  Not
> sure what has changed since then.

Ok, I've checked out the relevant commit and I can reproduce the issue
there. I've also tried to compare the behaviour between the python2 and
python3 packages.

I think the reason why it might work for python3, and not python2, is
that the python2 package seems to include the -l option by default,
whereas the python3 package doesn't. Looking at the -l option, it's
something about detecting tests that leak memory, which doesn't sound
that important, so maybe the thing to do is to patch out the use of -l
in the python2 package.

What do you think?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: 16/16: doc: Discourage the use of texlive as input

[Ludovic Courtès]

Hello!

Pierre Neidhardt  skribis:

> Yup, I went a bit out of my way here, sorry, long and painful day fighting
> TeXlive...

I can sympathize with that.  :-)

> Conclusion: I'll just add a mention of TeXlive in the existing paragraph then.

Perfect, thanks!  Final nitpick: for package name I’d rather use @code;
@command is for commands.

Ludo’.

Re: Preparing the reduced bootstrap tarballs, take 3

[Ludovic Courtès]

Mark H Weaver  skribis:

> Ludovic Courtès  writes:
>
>> Mark H Weaver  skribis:
>>
>>> Ludovic Courtès  writes:
>>>
 Jan Nieuwenhuizen  skribis:

> Ludovic Courtès writes:
>
> Hi!
>
>> I’ve just uploaded these to
>> :
>>
>>   linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>   linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz.sig
>>   mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz
>>   mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz.sig
>>   mes-minimal-stripped-0.18-0.08f04f5-i686-linux.tar.xz
>>   mes-minimal-stripped-0.18-0.08f04f5-i686-linux.tar.xz.sig
>
> Great!
>
>> Could you adjust bootstrap.scm to refer to this URL?  Currently I see
>> bootstrap.scm refers to a different version of
>> linux-libre-headers-stripped so it should be the only one whose hash
>> needs to be changed.
>
> I don't see that...and the hash matches.

 We’ve discussed it in person, and now I think we’re all set!  :-)
>>>
>>> Does our documentation include instructions on how to reproducibly build
>>> these new bootstrap binaries, to independently verify them?
>>
>> The build procedure remains unchanged (info "(guix) Bootstrapping"):
>>
>>   guix build bootstrap-tarballs
>>
>> To verify them, you can do what I described in this thread, which is to
>> use the same commit as Janneke and myself used, run “guix build
>> bootstrap-tarballs”, and compare the three tarballs listed above.
>
> What commit did you use?  It would be good to document this, so that
> others can independently verify our bootstrap binaries, now or in the
> future.

The commit appears in the commit log and in this very thread, no?

Ludo’.

Re: 01/01: hydra: Increase image sizes for USB image and Flash image.

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> On December 14, 2018 9:08:50 AM UTC, "Ludovic Courtès"  wrote:
>
> [...]
>
>>The good news is that there are other optimization opportunities.  :-)
>>
>>--8<---cut here---start->8---
>>$ guix size $(guix system build gnu/system/install.scm) | head -10
>>store item   total 
>>  self
>>/gnu/store/0zajbn9q39yva4l0zzrcshlll8qikzba-linux-libre-4.19.6
>>236.5   236.5  21.2%
>>/gnu/store/mdw00a2sq0qqyzqygmp9035g8r2rlslj-guix-0.15.0-8.71a78ba  
>>345.7   182.3  16.3%
>>/gnu/store/1lcniyxkxkh8g73zvh2gpbccvl6ggna7-locale-2.28
>>91.891.8   8.2%
>>/gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0   
>>146.358.2   5.2%
>>/gnu/store/ybglr7nfs8v9kpnm8vf4drg3gafnvd15-guile-static-stripped-2.2.4
>>   45.945.9   4.1%
>>/gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4   
>>121.944.4   4.0%
>>/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4   
>>121.944.4   4.0%
>>/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28 
>>37.836.3   3.2%
>>/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib  
>>68.030.2   2.7%
>>--8<---cut here---end--->8
>
> Why does Guile 2.2.4 appear twice but with a different hash?

That’s a good question!  It’s the kind of thing that we need to
investigate…

Ludo’.

Re: Compressing nars with lzip or similar

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Absolutely, but once the bindings are up and running, it should be
> straightforward to update (guix scripts substitute), no?

Sure!  But it will take time before we can assume all our users are
running it.

Ludo’.

Re: GNU Guix & GuixSD 0.16.0 released

[Ludovic Courtès]

Hello,

Giovanni Biscuolo  skribis:

> Ludovic Courtès  writes:
>
>> Pjotr Prins  skribis:
>>
>>> Yesterday I gave a passionate 'I love Guix' lightning talk about Guix
>>> packages at the biohackathon in Japan. Many people after approached me
>>> and said that the website is confusing them because it looks like it
>>> is promoting a Linux distribution... I know this is an old topic, but
>>> it would be nice if we found a way to promote Guix packaging as it
>>> works so well outside GuixSD.
>>
>> Yes, that should be a nice side-effect of calling everything “Guix”.
>
> does this mean that "guix system" is capable of
> instantiating/reconfiguring an operating-system declaration (services
> included) even outside GuixSD?
>
> AFAIK for this we need Sheperd as PID 1 and I do not know how I can get
> it on a systemd based (or any other different PID 1) distro

The only thing that doesn’t work on a foreign distro is ‘guix system
reconfigure’, understandably.  The rest works exactly the same way.

Ludo’.

Re: Golang programs keeping references [gnu: go: Update default to 1.11.]

[Ludovic Courtès]

Hello,

Pierre Neidhardt  skribis:

>> Oh, we should really work towards unbundling things from ‘go-ipfs’.  Any
>> idea how difficult that would be?
>
> go-ipfs has more than 100 deps.  So unless we work on a recursive importer, 
> it's
> going to be a lot of work.
>
> Harder: those dependencies can only be retrieved with gx (or IPFS itself, but
> then we have a  bootstrapping issue).  Hence my former work on the gx
> downloader.  I got stuck at an SSL issue.

Oh OK.  In general, we always unbundle software (for better
transparency, handling of security updates, etc.).  So it can’t be a
long-term plan to keep everything bundled in ‘go-ipfs’ (well, unless we
don’t add any new Go packages, in which case bundling in this specific
package becomes “invisible” :-)).

>> “guix size syncthing”, for instance, returns mostly tiny Go packages,
>> which looks good to me, no?
>
> Funny, for me "guix size syncthing" returns no Go package at all... Err... Am 
> I
> doing something wrong?

Here’s what I see:

--8<---cut here---start->8---
$ guix describe
Generation 46   Dec 14 2018 15:56:53(current)
  guix adb158b
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: adb158b7396cbdcda347fa298978408e531a03fd
$ guix size syncthing
substitute: updating substitutes from 'https://berlin.guixsd.org'... 100.0%
substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
store item   totalself
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28  37.8
36.3  41.4%
/gnu/store/ypiv8dj4lkvsnm82s639h18l87frrh5g-gcc-6.5.0-lib   69.0
31.2  35.6%
/gnu/store/nfikc8vj2whjl7012dgaj30m7y2lpv9d-syncthing-0.14.54   87.7
16.6  19.0%
/gnu/store/8g2wi0i5fgp0ylz99mckhprh25p1zgiv-tzdata-2018e 2.0 
2.0   2.3%
/gnu/store/zzakf905mzla4csi1dn9qpcwmgbxj29b-bash-static-4.4.23   1.5 
1.5   1.7%
/gnu/store/sj8m05bfj2902h67c4qkmvnzg2pjdgsv-net-base-5.3 0.0 
0.0   0.0%
total: 87.7 MiB
--8<---cut here---end--->8---

So hmm, you’re right!  I’m sure I saw go packages somewhere, dunno…

Cheers,
Ludo’.

Re: 16/16: doc: Discourage the use of texlive as input

[Pierre Neidhardt]

Done.
(Oops, missing period in the commit message...  I guess I'm having a day off :p)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Golang programs keeping references [gnu: go: Update default to 1.11.]

[Pierre Neidhardt]

> So hmm, you’re right!  I’m sure I saw go packages somewhere, dunno…

Just looked at the source: after my Go 1.11 update, Syncthing was updated to use
vendored dependencies, just like go-ipfs.  This is why it does not contains any
go ref.  From the package declaration:

  ;; Since the update to Go 1.11, Go programs have been keeping
  ;; spurious references to all their dependencies:
  ;; .
  ;; For Syncthing, this increases the size of the 'out' closure
  ;; from 87.6 MiB to 253.5 MiB.  So, we use the bundled
  ;; dependencies until the bug is resolved.
  
So yup, "guix size" is not happy with Go...

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Compressing nars with lzip or similar

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> I've done some quick research over the various options.
>
> - lzip: better than gz and bzip2 for sure, possibly better than xz (at
> least according to the author).
>
> - plzip: for "parallel lzip".  With 4 threads I was able to compress
> icecat 2.5x faster.  It used 5x more memory though.  The compression
> ratio is 1-2% worse.
>
> - lrzip: it would crash whenever I would change the compression level.
>   Seems less stable.  It's as fast as plzip, while being 1-2% less
>   compressed.  I don't think it's worth using.
>
> All in all, lzip is a definite win over most options.  The main question
> is: lzip or plzip?

‘guix publish’ has its own worker pool and handles parallelism
internally, so in that context plain sequential lzip would be more
appropriate IMO.

Ludo’.

Re: 01/01: gnu: mit-scheme: Update to 10.1.3.

[Kei Kebreau]

Mark H Weaver  writes:

> Hi Kei,
>
> guix-comm...@gnu.org writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit d870cc5e8acfed6fee318a66c3ffc7244aa376a1
>> Author: Kei Kebreau 
>> Date:   Thu Dec 13 08:32:50 2018 -0500
>>
>> gnu: mit-scheme: Update to 10.1.3.
>> 
>> * gnu/packages/scheme.scm (mit-scheme): Update to 10.1.3.
>> [arguments]: Update 'unpack', 'configure-doc', and 'install-doc' phases
>> accordingly.
>> [supported-systems]: Limit to i686-linux and x86_64-linux.
>
> [...]
>
>> @@ -177,24 +171,21 @@
>>  ("x86_64-linux"
>>   (string-append version "-x86-64"))
>>  ("i686-linux"
>> - (string-append version "-i386"))
>> -(_
>> - (string-append "c-" version)))
>> + (string-append version "-i386")))
>>".tar.gz"))
>>(sha256
>> (match (%current-system)
>>   ("x86_64-linux"
>>(base32
>> -   "1skzxxhr0iq96bf0j5m7mvf3i4sppfyfa6gpqn34mwgkw1fx8274"))
>> +   "03m7cc035w3avs91j2pcz9f15ssgvgp3rm045d1vbydqrkzfyw8k"))
>>   ("i686-linux"
>>(base32
>> -   "1fmlpnhf5a75db93phajh4ysbdgrgl72v45lk3kznriprl0a7jc6"))
>> - (_
>> -  (base32
>> -   
>> "0w5ib5vsidihb4hb6fma3sp596ykr8izagm57axvgd6lqzwicsjg"
>> +   
>> "05sjyz90xxfnmi87qv8x0yx0fcallnzl1dciygdafp317pn489is"
>
> Without the fallback cases in these 'match' forms, this package
> definition raises an exception when asked to generate the derivation on
> non-Intel systems.  Ludovic partly reverted your changes here:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=966629a114fd90153784dfdbe5e332e0ac94f1bc
>
> This commit also broke the 'guix' package on armhf-linux, and probably
> on other non-Intel systems as well,
>
>   https://hydra.gnu.org/build/3281991
>
> although admittedly I found this surprising.
>

For some reason, the removing the fallback case from the 'match' forms
didn't set off any alarm bells in my mind. My apologies.

>>  ;; Fails to build on MIPS, see .
>> -(supported-systems '("x86_64-linux" "i686-linux" "armhf-linux"))
>> + ;; Also, the portable C version of MIT/GNU Scheme did not work in
>> time for
>> +;; release in version 10.1.
>> +(supported-systems '("x86_64-linux" "i686-linux"))
>
> In general, please do not remove a system from 'supported-systems'
> unless there is good reason to believe that it would be prohibitively
> difficult to support the package on that system.  If there is merely a
> bug or some minor unfinished work that prevents a package from building
> on a given system, that is not sufficient grounds to remove it from
> 'supported-systems'.
>
>Thanks,
>  Mark

Understood. Thanks to you and Ludovic for cleaning up my small mess.

Re: bug#33676: GuixSD on eoma68-a20?

[Mark H Weaver]

Hi Andreas,

Andreas Enge  writes:

> On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
>> can you check whether dirindex (hashtables for directory) is enabled?
>> # tune2fs -l /dev/... | grep -o dir_index
>> See also 
>> https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
>
> It was, and I disabled it. Hopefully this does not break anything...

Why did you disable it?

> But does this not mean a big performance hit on /gnu/store/.links?

I would expect disabling dir_index to be a big performance hit on Guix
systems, and especially those with a large store, such a build farm
master nodes.

  Mark