Can we speed it up? Prev: compiling guix is too slow?

[Pjotr Prins]

On Wed, Jul 05, 2017 at 08:49:52PM -0700, Chris Marusich wrote:
> "Feng Shu"  writes:
> 
> > Now I have found that 'guix pull' is too slow,
> > I need 3 hours to compile guix, is it possible to speed it ?
> 
> 3 hours is longer than it usually takes on my Lenovo X200 laptop with 2
> cores, an SSD, and 8 GB of RAM.  Usually, for me, it seems to take about
> 15 minutes.

Guix pull takes a while and building Guix in general is slow too. I
find I have to rebuild quite often (updating trunk, moving between
machines) and with having my own guix publish server building
Guix is the bottle neck(!) From our discussion on Friday I gather
it is going to get a lot worse with the growing number of packages. 
It scales probably worse than linear.

What will it be like with 15K packages? We will get there. We can
actually try it now by doubling the package tree - anyone wants to try
and create a simulation? I.e., not just double the tree, make sure
there are cross references between the two graphs by modifying some of
the inputs at random.

This leads to the following thought: why don't we create a 'lazy'
build. There are multiple ways to go about it (I think). One would be
to parse scheme files for package names and only compile those that
are needed when someone invokes a guix command (and have not been
compiled yet). Or generate a meta list for a source tree. Or
subcategorize packages so only those packages get included that are
asked for (assuming there are no deeper dependencies). For example,
few people need the bioinformatics packages. We could have the sub
section of the graph split out and have people do:

  guix package --topic=bio -i samtools

for example and compile the contents gnu/packages/bio/ directory when
that happens the first time for a specific checkout.

This would be a lot more scalable and the main package section could be
fairly small and build fast. 

Sectioning the graph may be hard (you'd be inclined to section off
languages and window managers), but I think it can be dictated by
whether a sub graph can live on its own. And if we allow packages to
reference packages in a sub graph (triggering the build) then anything
goes - the JVM subsystem could be in one and Perl CPAN in another.

I think scalability is a good goal and instant compilation another ;).
A few years back it just took 30 seconds to build Guix.

Pj.

Re: 01/03: gnu: Add QD.

[Eric Bavier]

On Sat, 03 Feb 2018 22:55:56 -0500
Mark H Weaver  wrote:

> Hi Eric,
> 
> ericbav...@centurylink.net (Eric Bavier) writes:
> > bavier pushed a commit to branch master
> > in repository guix.
> >
> > commit cbc084e1a7c25d1c8944bcb20a989f795acdb096
> > Author: Eric Bavier 
> > Date:   Wed Jan 31 13:55:37 2018 -0600
> >
> > gnu: Add QD.  
> [...]
> > +(define-public qd
> > +  (package
> > +(name "qd")
> > +(version "2.3.18")
> > +(source (origin
> > +  (method url-fetch)
> > +  (uri (string-append "http://crd.lbl.gov/~dhbailey/mpdist/qd-;
> > +  version ".tar.gz"))
> > +  (sha256
> > +   (base32
> > +"0vkihcj9fyv2cycq8515713gbs3yskhmivy8bznvx72i6ddnn2c1"
> > +(build-system gnu-build-system)
> > +(native-inputs
> > + `(("gfortran" ,gfortran)))
> > +(arguments
> > + `(#:configure-flags `("--disable-enable_fma" ;weird :/  
> 
> "weird :/" is not a very useful comment.

Sorry.  I thought it was obvious it was in reference to the
"disable-enable" bit.

>  Can you change it to explain
> why you added this flag?  It seems unfortunate to disable fused
> multiply-add for this kind of library.

The library does not support runtime ISA detection.  I thought FMAs are
something we don't support in our baseline x86-64 builds?

`~Eric

Re: 01/01: gnu: solfege: Make configuration more robust to GC

[Mark H Weaver]

Hi Nicolas,

m...@nicolasgoaziou.fr (Nicolas Goaziou) writes:

> ngz pushed a commit to branch master
> in repository guix.
>
> commit 95e545a4dafe82499c68625e0c145df45ac38484
> Author: Nicolas Goaziou 
> Date:   Thu Feb 1 22:38:42 2018 +0100
>
> gnu: solfege: Make configuration more robust to GC

Did you test this?  It failed with the following error:

--8<---cut here---start->8---
@ build-started /gnu/store/6x7md71bdd2lwyrvcfsxs7s4z91ilraf-solfege-3.22.2.drv 
- x86_64-linux 
/var/log/guix/drvs/6x//7md71bdd2lwyrvcfsxs7s4z91ilraf-solfege-3.22.2.drv.bz2
ice-9/boot-9.scm:222:17: In procedure map1:
Syntax error:
/gnu/store/9bmqpvnrmkqygdgnncrjllqj35f0wdg5-solfege-3.22.2-guile-builder:2:3952:
 let: bad let in form (let (("aplay" (match:substring m 0))) (let-matches (+ 1 
0) m () (loop rest (match:end m) (cons* (begin) (substring l o (match:start m)) 
r
builder for `/gnu/store/6x7md71bdd2lwyrvcfsxs7s4z91ilraf-solfege-3.22.2.drv' 
failed with exit code 1
@ build-failed /gnu/store/6x7md71bdd2lwyrvcfsxs7s4z91ilraf-solfege-3.22.2.drv - 
1 builder for `/gnu/store/6x7md71bdd2lwyrvcfsxs7s4z91ilraf-solfege-3.22.2.drv' 
failed with exit code 1
--8<---cut here---end--->8---

and the problem is a syntax error, here:

> diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
> index 2fb62d0..2e8bc17 100644
> --- a/gnu/packages/music.scm
> +++ b/gnu/packages/music.scm
> @@ -10,7 +10,7 @@
>  ;;; Copyright © 2016 Alex Griffin 
>  ;;; Copyright © 2017 ng0 
>  ;;; Copyright © 2017 Rodger Fox 
> -;;; Copyright © 2017 Nicolas Goaziou 
> +;;; Copyright © 2017, 2018 Nicolas Goaziou 
>  ;;; Copyright © 2017 Pierre Langlois 
>  ;;; Copyright © 2017 Arun Isaac 
>  ;;; Copyright © 2017, 2018 Tobias Geerinckx-Rice 
> @@ -1050,22 +1050,10 @@ complete studio.")
>   (add-after 'unpack 'fix-configuration
> (lambda* (#:key inputs #:allow-other-keys)
>   (substitute* "default.config"
> -   (("csound=csound")
> -(string-append "csound="
> -   (assoc-ref inputs "csound")
> -   "/bin/csound"))
> -   (("/usr/bin/aplay")
> -(string-append (assoc-ref inputs "aplay")
> -   "/bin/aplay"))
> -   (("/usr/bin/timidity")
> -(string-append (assoc-ref inputs "timidity")
> -   "/bin/timidity"))
> -   (("/usr/bin/mpg123")
> -(string-append (assoc-ref inputs "mpg123")
> -   "/bin/mpg123"))
> -   (("/usr/bin/ogg123")
> -(string-append (assoc-ref inputs "ogg123")
> -   "/bin/ogg123")))
> +   (("/usr/bin/aplay" "aplay"))

In the line above, one of the right parentheses is misplaced.  It should
be like this:

> +   (("/usr/bin/aplay") "aplay")

I guess that maybe you made some changes after your last test?
Can you fix it please?

   Mark

FOSDEM 2018 and announcing a GNU Guix/Guile day! After getting home...

[Pjotr Prins]

Hi everyone.

This was huge. We had an amazing day with ~25 GNU Guix contributors
and the father and project leaders of Nix, and it blew me away how
much Guix has progressed in the last year and what interesting
discussions that led to. 

I think the next phase we are moving beyond a 'standard' package
manager with optimized builds, channels, workflows, provision and
orchestration.  All logical next steps because Guix is such a solid
foundation :).

FOSDEM was great too. It was busier than ever, but the crowd appears
to be increasingly experienced too. In other words the FOSS community
appears to be growing and feels very very solid!

I thank everyone for joining, especially when you realise how much
most of us had to travel. I, for one, feel very inspired!

Pj.

getxattr / setxattr syscalls not allowed in build-container

[Hartmut Goebel]

Hi,

when hunting down a failing test-case with strace, I found this error:

   getxattr("…/writertest.txt") -> EOPNOTSUPP (Operation not supported)

and

   setxattr("…/writertest.txt") -> EOPNOTSUPP (Operation not supported)


I wonder if getxattr and setxattr are not supported in the build-container?!

-- 
Regards
Hartmut Goebel

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

Re: Guix key signing party at FOSDEM?

[Tobias Geerinckx-Rice]

Chris, Guix,

On 2018-02-03 15:14, Chris Marusich wrote:

Hi everyone,

It was a pleasure meeting many of you yesterday at the GNU Guix 
meet-up!


I heartily concur.


Some people expressed an interest in PGP key signing, but unfortunately
we didn't have time to do that on Friday.  In addition, I'm one of 
those

who did not register in time for the FOSDEM key signing event, so I
can't participate in that this year.  In spite of this, I'm interested
in doing a mini key signing party with other like-minded Guix members,
if you're still in the area.

Would any of you be interested in getting together for an hour or so to
do this, either today or tomorrow?  If not, that's totally fine - I 
just

hate to miss the opportunity while I'm here!


How did this go?

I couldn't make it in time for the Guix subparty today and won't be in 
Brussels this evening (I guess I'm officially too old to go ~3 nights 
without sleep; good to know) but would like to repeat it next year if 
there's interest.


Zz,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Re: Licensing question about Pale Moon Browser binary distribution

[Moonchild]

Hi!

You've read the exception point correctly:

Using New Moon (=unofficial) branding, you are allowed to do whatever
you wish with your distribution, including reconfiguration, different
home page, etc. Go right ahead!
If you make source code changes, you should also supply your modified
source code to stay within the requirements of the MPL source code license.

Moonchild.

On 04/02/2018 12:58, n...@n0.is wrote:

>>From re-reading item 12:
> 
>> Unofficial branding ("New Moon") as supplied in the source code
>> may be used for unendorsed binaries at all times. Thusly
>> branded binaries with the New Moon logo and product name are
>> not subject to the endorsement and exception rules as set out
>> in previous points of this license and may be freely
>> distributed in altered or unaltered form, subject to the
>> Mozilla Public License as regards source code changes and
>> availability. This permission does, however, not include any
>> rights or license to the Pale Moon name and logo that may still
>> be present in the resulting unofficially branded binaries.
> 
> in the above mentioned policy I understand that we will be
> allowed to distribute the resulting binaries. Is my understanding
> of your policy exception correct or did I miss anything?
> 
> Regards,
> ng0
> 



0x6DA5F2AC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Licensing question about Pale Moon Browser binary distribution

[ng0]

Hi,

On Sun, 04 Feb 2018, Moonchild  wrote:
> Hi!
>
> You've read the exception point correctly:
>
> Using New Moon (=unofficial) branding, you are allowed to do whatever
> you wish with your distribution, including reconfiguration, different
> home page, etc. Go right ahead!
> If you make source code changes, you should also supply your modified
> source code to stay within the requirements of the MPL source code license.
>
> Moonchild.

Alright then. I should've asked this question earlier. Better
late than never.

Thanks for your reply!

> On 04/02/2018 12:58, n...@n0.is wrote:
>
>>>From re-reading item 12:
>> 
>>> Unofficial branding ("New Moon") as supplied in the source code
>>> may be used for unendorsed binaries at all times. Thusly
>>> branded binaries with the New Moon logo and product name are
>>> not subject to the endorsement and exception rules as set out
>>> in previous points of this license and may be freely
>>> distributed in altered or unaltered form, subject to the
>>> Mozilla Public License as regards source code changes and
>>> availability. This permission does, however, not include any
>>> rights or license to the Pale Moon name and logo that may still
>>> be present in the resulting unofficially branded binaries.
>> 
>> in the above mentioned policy I understand that we will be
>> allowed to distribute the resulting binaries. Is my understanding
>> of your policy exception correct or did I miss anything?
>> 
>> Regards,
>> ng0
>> 
>
>

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

How to refresh to a specific version?

[Hartmut Goebel]

Hi,

guix refresh fetches the newest version of packages. How can I refresh
to a specific version or to the newest sub-version of a specific minor
version?

Rational: Qt has released 5.10, while 5.9 is still maintained. I want to
refresh to the latest 5.9.x version, but not (yet) to 5.10, as the later
might require bigger changes.

-- 
Regards
Hartmut Goebel

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

Re: Guix key signing party at FOSDEM?

[Efraim Flashner]

This sounds great. I've been feeling not great the past day or two but I'm 
starting to feel better and might even make it for a dinner tonight. And of 
course I'll be at the keysigning.

On February 4, 2018 1:17:07 AM UTC, Chris Marusich  wrote:
>Efraim Flashner  writes:
>
>> I have some printed slips with my key to hand out, when do we want to
>do
>> it? Another options is that last year at the key signing party some
>people
>> did show up with some slips and joined the line and handed out slips
>of
>> paper instead of identifying their number.
>
>About 15 of us discussed this over dinner, and we agreed to meet at the
>same place and time where FOSDEM will be holding its key signing party
>(which is: "Sunday, at 14:00, in the corridor on the second level of
>the
>U building" [1]).  We will meet and conduct our own little key signing
>party nearby, without intruding on the main event.
>
>To participate, you just need to (1) know your key fingerprint and
>associated user ID, and (2) bring a form of official identification
>(e.g., your passport).  To make it easy to share your key fingerprint
>and user ID with others, it would be good to create print-outs (or
>hand-written copies) so that you can bring them to the party.  When you
>do this, please be sure to double check the print-outs for correctness
>before coming.
>
>At the party, all we have to do is (1) share fingerprints/user IDs and
>(2) verify user IDs using everyone's official form of identification.
>There is no need to actually sign keys on the same day.  You can
>actually sign the keys later (e.g., after FOSDEM is done - although
>sooner is always better!), at which point you should send the signed
>keys back to their respective owners.
>
>If there are any errors in what I have said above, please correct me. 
>I
>look forward to doing this together with many of you tomorrow!  As for
>you specifically, Efraim: I hope that you will join in after the main
>key signing event is done (and that others will stick around long
>enough
>to meet with you, too!).
>
>See you tomorrow,
>
>Footnotes: 
>[1]  https://fosdem.org/2018/keysigning/

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Licensing question about Pale Moon Browser binary distribution

[ng0]

Hello licensing team of Pale Moon,

a long time ago I packaged Pale Moon in the Newmoon flavor (or
"brand") for GNU Guix.
I have maintained it in my local set of repositories for some
time now, simply because of your redistribution policies
(http://www.palemoon.org/redist.shtml). It is building from
source locally on the machines of the people who might use it,
effectively like Gentoo. With Guix we have the possibility to
either build from source or to use so called "binary
substitutes" from binary substitutes servers (which can be
compared to what users of binary-only distributions use).

I'm not a lawyer. I'm a volunteer and activist, interested in
providing secure, safe and reproducible builds across the
whole variety of hardware and Operating Systems GNU Guix can run
on.
What's bothering me is the default landing page. No matter the
good intentions, it exposes users to a landing page with
trackers, at least last time I checked it.

I want to bring Pale Moon into Guix, so that more people can make
use of it. Here are my questions:
If we would substitute ("patch out") the landing page, defaulting
to a branded one (for example "gnu.org") or anything else
including "about:blank", could we still distribute it with the
New Moon theme/branding?
>From re-reading item 12:

> Unofficial branding ("New Moon") as supplied in the source code
> may be used for unendorsed binaries at all times. Thusly
> branded binaries with the New Moon logo and product name are
> not subject to the endorsement and exception rules as set out
> in previous points of this license and may be freely
> distributed in altered or unaltered form, subject to the
> Mozilla Public License as regards source code changes and
> availability. This permission does, however, not include any
> rights or license to the Pale Moon name and logo that may still
> be present in the resulting unofficially branded binaries.

in the above mentioned policy I understand that we will be
allowed to distribute the resulting binaries. Is my understanding
of your policy exception correct or did I miss anything?

Regards,
ng0
-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

Re: Guix - installation script

[Hellseher]

Hi, all


I've changed a structure of my repo (did not push it to official Guix 
one yet)


https://github.com/Hellseher/wds/blob/master/wds-hacks/wds-guix-install.sh

Regards,

Oleg


On 28/01/18 18:00, Ricardo Wurmus wrote:

Catonano  writes:


what did happen with this ?

Was there any progress ?

The script has since disappeared from the repository, but I took a
previous version and am now in the process of extending it and making it
ready for inclusion in Guix.

--
Ricardo

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

Packing Telegram Messenger

[Ethan R. Jones]

Hello! 
I'm currently working on getting the Telegram instant messenger packaged and
would be very pleased with any assistance fellow hackers can offer. Currently I
have a patch filed [1] for one dependency, however there are three other in
various states of development in my guix repo [2] and at least one more
completely unpackaged (libappindicator[-gtk3]). Currently, I've been basing my
work off the already, helpfully, packaged version in nixos [3]. Any help that
people can provide is much appreciated. Submitting a PR or emailing me a patch
would preferred - feel free to hit me up in IRC aswell.
Thanks!
[1] http://lists.gnu.org/archive/html/guix-patches/2018-02/msg00021.html
[2] https://notabug.org/doubleplusgood23/guix
[3] https://github.com/NixOS/nixpkgs/blob/c1d9aff56e0ae52ee4705440fe09291a51e919
77/pkgs/applications/networking/instant-
messengers/telegram/tdesktop/default.nix#L104
-- 
Ethan R. Jones
PGP Key: DA3ABDDC176CEF90

Packaging Telegram Messenger

[dpg]

Hello! 
I'm currently working on getting the Telegram instant messenger packaged and
would be very pleased with any assistance fellow hackers can offer. Currently I
have a patch filed [1] for one dependency, however there are three other in
various states of development in my guix repo [2] and at least one more
completely unpackaged (libappindicator[-gtk3]). Currently, I've been basing my
work off the already, helpfully, packaged version in nixos [3]. Any help that
people can provide is much appreciated. Submitting a PR or emailing me a patch
would preferred - feel free to hit me up in IRC aswell.
Thanks!
[1] http://lists.gnu.org/archive/html/guix-patches/2018-02/msg00021.html
[2] https://notabug.org/doubleplusgood23/guix
[3] https://github.com/NixOS/nixpkgs/blob/c1d9aff56e0ae52ee4705440fe09291a51e919
77/pkgs/applications/networking/instant-
messengers/telegram/tdesktop/default.nix#L104