Re: Building from a local source code checkout

[Ludovic Courtès]

Martin Castillo  skribis:

> Why can't guix use the argument package name argument?
>  v-- this one
> guix build python-activepapers --with-source=$HOME/Dev/AP

Because there can be several packages passes as arguments to ‘guix
build’.

Now it would make sense to DTRT when there’s just one package on the
command line.

Ludo’.

Re: website: showcase or list videos and slides, sources of all talks

[Ludovic Courtès]

Hello,

sirgazil  skribis:

> On 20/12/17 17:32, Ludovic Courtès wrote:
>> Hartmut Goebel  skribis:
>>
>>> Am 19.12.2017 um 17:15 schrieb ng0:
> It should be here:
>
>https://www.gnu.org/software/guix/blog/tags/talks/
>https://www.gnu.org/software/guix/blog/tags/papers/
 This doesn't work really well to discover them, like on
 a submenu page in the head menu, leading to these pages
 or dedicated (non-blog, non-markdown) pages.

>>> +1 for linking them from a more prominent page on the main website.
>>>
>>> Blogs are like a diary, but not good for documentation an important content.
>>
>> sirgazil, WDYT?  :-)
>
> Well, I think we could convert the current Blog item in the website
> menu into a Media item with the following subitems:
>
>   Blog
>   Papers
>   Screenshots
>   Talks

I like it; perhaps I’d leave “Blog” as a separate menu item though.

> Just like screenshots and blog posts, some talks could be highlighted
> in the home page. These changes could make it easier for people to
> find them, I think.

Could be nice.

> We can design the new pages and update current pages so that people
> browsing the summaries of posts, talks, etc. know if the full content
> of a given item contains video, slides, etc.
>
> With these changes, which I think I can start designing right now, I
> think it would not be necessary to list talks and papers in the Help
> section again. What do you think, Mark?

I prefer the idea of a “Media” menu, but perhaps you’re suggesting to do
both?  That would be great.

Thanks,
Ludo’.

Re: [WIP][PATCH] profiles: info-dir-file: Don't consider unwanted manifest entries

[宋文武]

Martin Castillo  writes:

> Hi,
>
> in the second patch file:
>> +  ;; We only need to build the 'dir' file for inputs that does
> containing info
>> +  ;; manuals.
> s/containing/contain
>

Okay, thanks!

> On 15.12.2017 16:12, 宋文武 wrote:> Hello!
>>
>> Currently we run profile hooks for all manifest inputs, so if you
>> install a new package to your profile, all profile hooks will be run
>> again, even if the new package doesn't provide info manuals, man pages,
>> etc.  Ideally only interested hooks need to be run, eg: if the new
>> package has info manuals, then the 'info-dir-file' hook will run.
>
> One would need to filter man-pages too, right?

Yes, that need be done in the 'manual-database' hook.

Re: OpenBLAS and performance

[Dave Love]

Ricardo Wurmus  writes:

>> I was confused.  I see the only version of the library shipped is built
>> with pthreads.  I think there should be serial, pthreads, and OpenMP
>> versions, as for Fedora.
>
> Do these library variants have the same binary interface, so that a user
> could simply preload one of them to override the default variant we use
> in the input graph of a given package?

Yes.  You can use LD_LIBRARY_PATH as normal if you have variants with
the right soname, like the trivial shims in the example I referenced.
You probably want versions with the implementation-specific names too.

Re: OpenBLAS and performance

[Dave Love]

Ludovic Courtès  writes:

> Hello,
>
> Dave Love  skribis:
>
>> Fedora sensibly builds separately-named libraries for different flavours
>> , but I'd
>> argue also for threaded versions being available with the generic soname
>> in librray sub-directories.  There's some discussion and measurements
>> (apologies if I've referenced it before) at
>> 
>
> I like the idea of an ‘update-alternative’ kind of approach for
> interchangeable implementations.

/etc/ld.so.conf.d normally provides a clean way to flip the default, but
that isn't available in Guix as far as I remember.

> Unfortunately my understanding is that implementations aren’t entirely
> interchangeable, especially for LAPACK (not sure about BLAS), because
> BLIS, OpenBLAS, etc. implement slightly different subsets of netlib
> LAPACK, AIUI.

LAPACK may add new routines, but you can always link with the vanilla
Netlib version, and openblas is currently only one release behind.  The
LAPACK release notes I've seen aren't very helpful for following that.
The important requirement is fast GEMM from the optimized BLAS.  I
thought BLIS just provided the BLAS layer, which is quite stable, isn't
it?

> Packages also often check for specific implementations in
> their configure/CMakeLists.txt rather than just for “BLAS” or “LAPACK”.

It doesn't matter what they're built against when you dynamically load a
compatible version.  (You'd hope a build system would be able to find
arbitrary BLAS but I'm too familiar with cmake pain.)  The openblas
compatibility hack basically just worked on an RHEL6 cluster when I
maintained it.

> FlexiBLAS, which Eric mentioned, looks interesting because it’s designed
> specifically for that purpose.  Perhaps worth giving it a try.

I see it works by wrapping everything, which I wanted to avoid.  Also
it's GPL, which restricts its use.  What's the advantage over just
having implementations which are directly interchangeable at load time?

> Besides, it would be good to have a BLAS/LAPACK policy in Guix.  We
> should at least agree (1) on default BLAS/LAPACK implementations, (2)
> possibly on a naming scheme for variants based on a different
> implementation.

Yes, but the issue is wider than just linear algebra.  It seems to
reflect tension between Guix' approach (as I understand it) and the late
binding I expect to use.  There are potentially other libraries with
similar micro-architecture-specific issues, and the related one of
profiling/debugging versions.  I don't know how much of a real problem
there really is, and it would be good to know if someone has addressed
this.

It's a reason I'm currently not convinced about the trades-off with
Guix, and don't go along with the "reproducibility" mantra.  Obviously
I'm not writing Guix off, though, and I hope the discussion is useful.

> For #1 we should probably favor implementations that support run-time
> implementation selection such as OpenBLAS (or the coming BLIS release).
>
> Thoughts?
>
> Ludo’.

Yes, but even with dynamic dispatch you need to account for situations
like we currently have on x86_64 with OB not supporting the latest
micro-architecture, and it only works on x86 with OB.  You may also want
to avoid overhead -- see FFTW's advice for packaging.  Oh for SIMD
hwcaps...

Porting GuixSD to ARM article.

[Mathieu Othacehe]

Hi Guix!

A new article is available on Guix's website. It summarizes recent
progress on ARM porting topic.

https://www.gnu.org/software/guix/blog/2017/porting-guixsd-to-armv7/

Feel free to ask any question or propose follow-up actions here!
Many thanks to Ludo, Danny and Ricardo for the early review :)

Happy reading,

Mathieu

Re: website: showcase or list videos and slides, sources of all talks

[sirgazil]

On 22/12/17 04:32, Ludovic Courtès wrote:

Hello,

sirgazil  skribis:


On 20/12/17 17:32, Ludovic Courtès wrote:

Hartmut Goebel  skribis:


Am 19.12.2017 um 17:15 schrieb ng0:

It should be here:

https://www.gnu.org/software/guix/blog/tags/talks/
https://www.gnu.org/software/guix/blog/tags/papers/

This doesn't work really well to discover them, like on
a submenu page in the head menu, leading to these pages
or dedicated (non-blog, non-markdown) pages.


+1 for linking them from a more prominent page on the main website.

Blogs are like a diary, but not good for documentation an important content.


sirgazil, WDYT?  :-)


Well, I think we could convert the current Blog item in the website
menu into a Media item with the following subitems:

   Blog
   Papers
   Screenshots
   Talks


I like it; perhaps I’d leave “Blog” as a separate menu item though.



I'm fine with that too.



Just like screenshots and blog posts, some talks could be highlighted
in the home page. These changes could make it easier for people to
find them, I think.


Could be nice.


We can design the new pages and update current pages so that people
browsing the summaries of posts, talks, etc. know if the full content
of a given item contains video, slides, etc.

With these changes, which I think I can start designing right now, I
think it would not be necessary to list talks and papers in the Help
section again. What do you think, Mark?


I prefer the idea of a “Media” menu, but perhaps you’re suggesting to do
both?  That would be great.



Yes, I mean that we can have the "Media" menu, but we can also use, for 
example, the concept of post types in the blog (using post metadata), so 
that posts of types "video" or "slides" can have summaries that tell 
people that the post is a video or a slideshow.

Re: OpenBLAS and performance

[Dave Love]

For what it's worth, I get 37000 Mflops from the dgemm.goto benchmark
using the current Guix openblas and OPENBLAS_NUM_THREADS=1 at a size of
7000 on a laptop with "i5-6200U CPU @ 2.30GHz" (avx2).  That looks about
right, and it should more-or-less plateau at that size.  For comparison,
I get 44000 on a cluster node "E5-2690 v3 @ 2.60GHz" with its serial
build of 0.2.19.  (I mis-remembered the sandybridge figures, which
should be low 20s, not high 20s.)

If you see something much different, perhaps the performance counters
give a clue, e.g. with Guix' scorep/cube, oprofile, or perf.

I've sent a patch for the correct cache size on haswell, but I don't
think it makes much difference in this case.

Re: OpenBLAS and performance

[Ludovic Courtès]

Hi,

Dave Love  skribis:

> Ludovic Courtès  writes:
>
>> Hello,
>>
>> Dave Love  skribis:
>>
>>> Fedora sensibly builds separately-named libraries for different flavours
>>> , but I'd
>>> argue also for threaded versions being available with the generic soname
>>> in librray sub-directories.  There's some discussion and measurements
>>> (apologies if I've referenced it before) at
>>> 
>>
>> I like the idea of an ‘update-alternative’ kind of approach for
>> interchangeable implementations.
>
> /etc/ld.so.conf.d normally provides a clean way to flip the default,
> but that isn't available in Guix as far as I remember.

Right.

>> Unfortunately my understanding is that implementations aren’t entirely
>> interchangeable, especially for LAPACK (not sure about BLAS), because
>> BLIS, OpenBLAS, etc. implement slightly different subsets of netlib
>> LAPACK, AIUI.
>
> LAPACK may add new routines, but you can always link with the vanilla
> Netlib version, and openblas is currently only one release behind.  The
> LAPACK release notes I've seen aren't very helpful for following that.
> The important requirement is fast GEMM from the optimized BLAS.  I
> thought BLIS just provided the BLAS layer, which is quite stable, isn't
> it?

I tried a while back to link PaSTiX (a sparse matrix direct solver
developed by colleagues of mine), IIRC, against BLIS, and it would miss
a couple of functions that Netlib LAPACK provides.

>> Packages also often check for specific implementations in
>> their configure/CMakeLists.txt rather than just for “BLAS” or “LAPACK”.
>
> It doesn't matter what they're built against when you dynamically load a
> compatible version.

Right but they do that precisely because all these implementations
provide different subsets of the Netlib APIs, AIUI.

>> FlexiBLAS, which Eric mentioned, looks interesting because it’s designed
>> specifically for that purpose.  Perhaps worth giving it a try.
>
> I see it works by wrapping everything, which I wanted to avoid.  Also
> it's GPL, which restricts its use.  What's the advantage over just
> having implementations which are directly interchangeable at load time?

Dunno, I haven’t dig into it.

>> Besides, it would be good to have a BLAS/LAPACK policy in Guix.  We
>> should at least agree (1) on default BLAS/LAPACK implementations, (2)
>> possibly on a naming scheme for variants based on a different
>> implementation.
>
> Yes, but the issue is wider than just linear algebra.  It seems to
> reflect tension between Guix' approach (as I understand it) and the late
> binding I expect to use.  There are potentially other libraries with
> similar micro-architecture-specific issues, and the related one of
> profiling/debugging versions.  I don't know how much of a real problem
> there really is, and it would be good to know if someone has addressed
> this.

Guix’ approach is to use static binding a lot, and late binding
sometimes.  For all things plugin-like we use late binding.  For shared
libraries (not dlopened) we use static binding.

Static binding has a cost, as you write, but it gives us control over
the environment, and the ability to capture and replicate the software
environment.  As a user, that’s something I value a lot.

I’d also argue that this is something computational scientists should
value: first because results they publish should not depend on the phase
of the moon, second because they should be able to provide peers with a
self-contained recipe to reproduce them.

> Yes, but even with dynamic dispatch you need to account for situations
> like we currently have on x86_64 with OB not supporting the latest
> micro-architecture, and it only works on x86 with OB.  You may also want
> to avoid overhead -- see FFTW's advice for packaging.  Oh for SIMD
> hwcaps...

I’m not sure what you mean.  That OB does not support the latest
micro-architecture is not something the package manager can solve.

As for overhead, it should be limited to load time, as illustrated by
IFUNC and similar designs.

Thanks,
Ludo’.

Re: Porting GuixSD to ARM article.

[Vincent Legoll]

Hello,

On Fri, Dec 22, 2017 at 2:12 PM, Mathieu Othacehe  wrote:
> https://www.gnu.org/software/guix/blog/2017/porting-guixsd-to-armv7/
>
> Feel free to ask any question or propose follow-up actions here!
> Many thanks to Ludo, Danny and Ricardo for the early review :)

I think there are typoes:

The definition on an installation image for the BeagleBone Black.
s/on an/of an/

In "Preparing a dedicated system configuration",  I'm not sure,
but you have a "tty-O-0" in the system configuration:

(tty "ttyO0")

Isn't that a typo also ?

-- 
Vincent Legoll

Re: Porting GuixSD to ARM article.

[Pjotr Prins]

On Fri, Dec 22, 2017 at 02:12:02PM +0100, Mathieu Othacehe wrote:
> 
> Hi Guix!
> 
> A new article is available on Guix's website. It summarizes recent
> progress on ARM porting topic.
> 
> https://www.gnu.org/software/guix/blog/2017/porting-guixsd-to-armv7/
> 
> Feel free to ask any question or propose follow-up actions here!
> Many thanks to Ludo, Danny and Ricardo for the early review :)
> 
> Happy reading,

Very cool!

-- 

Re: OpenBLAS and performance

[Pjotr Prins]

On Fri, Dec 22, 2017 at 04:10:39PM +0100, Ludovic Courtès wrote:
> Static binding has a cost, as you write, but it gives us control over
> the environment, and the ability to capture and replicate the software
> environment.  As a user, that’s something I value a lot.

> I’d also argue that this is something computational scientists should
> value: first because results they publish should not depend on the phase
> of the moon, second because they should be able to provide peers with a
> self-contained recipe to reproduce them.

As a scientist I value that *more* than a lot. There is a tension
between 'just getting things done' and making things reproducible. If
we can do the latter, we should.  Also as a programmer I value
reproducibility a lot. I want people who report bugs to use the exact
same setup. Especially when they are running on machines I can not
access (quite common in sequencing centers). If someone sends me a
core dump, stack trace or even an asserting in a shared lib it is
incredibly useful the full stack is the same.

I am wary of flexible resolution of optimized libraries and kernels.
Look at what atlas tried to do and what a mess it became. I strongly
believe we need explicit statements about what we are running. It does
imply Guix will have to provide all options, directly or through
channels.

I also work on HPC and if I know where I am running I know *what* to
target. It is a deterministic recipe. 

Pj.

Packaging LyX

[Gammel Holte]

Hi all,

I'm planning to switch a dozen or so machines to GuixSD.

The only major package my users are missing is LyX (a LaTeX editor, see
https://www.lyx.org/) so I packaged it, and it works fine. See code below.

I would appreciate some help wrapping python. I'm familiar how to do this
in Nix, but not in Guix. Despite requiring a python interpreter for during
build, LyX dynamically looks for a python interpreter at runtime.
Obviously, it'd be desirable to link LyX to the python instance used as
input. For the record this is the LyX package in Nixpkgs:

https://github.com/NixOS/nixpkgs/blob/86da6d441f7a248b02d545ac1b2c90ef27f42d0b/pkgs/applications/misc/lyx/default.nix

I also had some doubts when packaging:

- Is a xz source preferred to a gz one?
- Nix uses qtcore and qtsvg as inputs, but if I use these in Guix (in place
of the whole qt) then LyX can't render its icons (svgz)

There are another minor TODOs:

- Transition to proper package and define-public syntax, as I was
installing with guix package -f
- Decide whether the package should live in tex.scm or elsewhere

Once this is done, I'm happy to submit a proper patch.

Thanks.

(use-modules
 (guix packages)
 (guix download)
 (guix build-system gnu)
 (guix licenses)
 (gnu packages algebra)
 (gnu packages compression)
 (gnu packages pkg-config)
 (gnu packages python)
 (gnu packages qt))

(package
 (name "lyx")
 (version "2.2.3")
 (source (origin
  (method url-fetch)
  (uri (string-append "ftp://ftp.lyx.org/pub/lyx/stable/2.2.x/lyx-";
  version ".tar.gz"))
  (sha256
   (base32 "0xvaz0i371nn2ndinc0d3ywj76ivb62649a4sdgwbivisiahd2fj"
 (build-system gnu-build-system)
 (inputs `(("pkg-config" ,pkg-config)
   ("python" ,python-2)
   ("qt" ,qt)
   ("bc" ,bc)
   ("zlib" ,zlib)))
 (arguments `(#:configure-flags (list "--enable-qt5")))
 (home-page "http://www.lyx.org";)
 (synopsis "An advanced WYSIWYM document processor and LaTeX front-end")
 (description "LyX is a document processor that encourages an approach
to writing based on the structure of your documents (WYSIWYM) and not
simply their appearance (WYSIWYG). LyX combines the power and
flexibility of TeX/LaTeX with the ease of use of a graphical
interface.")
 (license gpl2+))

license naming

[ng0]

I've just read this link: 
https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2

Full Quote:

> In this article, For Clarity's Sake, Please Don't Say "Licensed under GNU GPL 
> 2"!, Free Software Foundation president Richard Stallman (RMS) explains how 
> to properly identify what GNU license your work is under. Whenever a 
> developer releases their work under a GNU license, they have the option to 
> either release it under that version of the license only, or to make it 
> available under any later version of that license. This option ensures that 
> software can remain compatible with future versions of the license. But what 
> happens if someone just says their program is under GNU GPL version 2, for 
> example?
>
>>[T]hey are leaving the licensing of the program unclear. Is it released 
>> under GPL-2.0-only, or GPL-2.0-or-later? Can you merge the code with 
>> packages released under GPL-3.0-or-later?
>
> Thus, it is vitally important that developers indicate in their license 
> notices whether they are licensing their work under that version "only" or 
> under "any later version." Of course, these days it is also helpful for 
> license notices to be machine-readable. The Software Package Data Exchange 
> (SPDX) specification sets a standardized way of identifying licenses on 
> software packages. They are updating their license identifiers to include 
> this distinction in their upcoming version. For example, for GNU GPL version 
> 2, the identifiers are now "GPL-2.0-only or GPL-2.0-or-later." The old 
> identifiers (e.g. "GPL-2.0") are now deprecated and should no longer be used. 
> Based on the changes SPDX says are coming in the SPDX specification and its 
> Web site, the FSF expects to endorse the new version of the SPDX. We thank 
> SPDX and their community for making these helpful changes.


Maybe we could make use of what https://spdx.org/licenses/
provides. I didn't compare the names with our names, I'll do
this on the train next week.
Good idea, bad idea?
-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
  WWW: https://n0.is


signature.asc
Description: PGP signature

Re: Packaging LyX

[ng0]

Hi,

Gammel Holte transcribed 5.8K bytes:
> Hi all,
> 
> I'm planning to switch a dozen or so machines to GuixSD.
> 
> The only major package my users are missing is LyX (a LaTeX editor, see
> https://www.lyx.org/) so I packaged it, and it works fine. See code below.
> 
> I would appreciate some help wrapping python. I'm familiar how to do this
> in Nix, but not in Guix. Despite requiring a python interpreter for during
> build, LyX dynamically looks for a python interpreter at runtime.
> Obviously, it'd be desirable to link LyX to the python instance used as
> input. For the record this is the LyX package in Nixpkgs:
> 
> https://github.com/NixOS/nixpkgs/blob/86da6d441f7a248b02d545ac1b2c90ef27f42d0b/pkgs/applications/misc/lyx/default.nix
> 
> I also had some doubts when packaging:
> 
> - Is a xz source preferred to a gz one?

I would say it doesn't matter. For the files produced,
xz is smaller in most cases. Pick what you see fit.

> - Nix uses qtcore and qtsvg as inputs, but if I use these in Guix (in place
> of the whole qt) then LyX can't render its icons (svgz)

This shouldn't be a blocker. If it works with qt, that's okay. We
can strip it down to individual Qt modules later on.
Nix can be used as an inspiration but they do some things differently.

> There are another minor TODOs:
> 
> - Transition to proper package and define-public syntax, as I was
> installing with guix package -f
> - Decide whether the package should live in tex.scm or elsewhere

I think (gnu packages editors) or what the editor module is called again
would be better.

> Once this is done, I'm happy to submit a proper patch.
> 
> Thanks.
> 
> (use-modules
>  (guix packages)
>  (guix download)
>  (guix build-system gnu)
>  (guix licenses)
>  (gnu packages algebra)
>  (gnu packages compression)
>  (gnu packages pkg-config)
>  (gnu packages python)
>  (gnu packages qt))
> 
> (package
>  (name "lyx")
>  (version "2.2.3")
>  (source (origin
>   (method url-fetch)
>   (uri (string-append "ftp://ftp.lyx.org/pub/lyx/stable/2.2.x/lyx-";
>   version ".tar.gz"))
>   (sha256
>(base32 "0xvaz0i371nn2ndinc0d3ywj76ivb62649a4sdgwbivisiahd2fj"
>  (build-system gnu-build-system)
>  (inputs `(("pkg-config" ,pkg-config)
>("python" ,python-2)

Is this python-2 only? If not, could you explain why you picked 2 and not 3
(2 is on its way out in 20 months).

>("qt" ,qt)
>("bc" ,bc)
>("zlib" ,zlib)))
>  (arguments `(#:configure-flags (list "--enable-qt5")))
>  (home-page "http://www.lyx.org";)
>  (synopsis "An advanced WYSIWYM document processor and LaTeX front-end")

I'd drop the "An" and simply write

  (synopsis "Advanced WYSIWYM document processor and LaTeX front-end")

>  (description "LyX is a document processor that encourages an approach
> to writing based on the structure of your documents (WYSIWYM) and not
> simply their appearance (WYSIWYG). LyX combines the power and
> flexibility of TeX/LaTeX with the ease of use of a graphical
> interface.")

You need to use two spaces between sentences here.

>  (license gpl2+))



Otherwise looks good to me with some indendation adjustments.
If you send a patch for master to a new bug ticket I can test it
and give additional feedback.

Thanks
-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
  WWW: https://n0.is


signature.asc
Description: PGP signature

Re: license naming

[Jelle Licht]

ng0  writes:

> I've just read this link: 
> https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2
>
> Full Quote:
>
>> In this article, For Clarity's Sake, Please Don't Say "Licensed under GNU 
>> GPL 2"!, Free Software Foundation president Richard Stallman (RMS) explains 
>> how to properly identify what GNU license your work is under. Whenever a 
>> developer releases their work under a GNU license, they have the option to 
>> either release it under that version of the license only, or to make it 
>> available under any later version of that license. This option ensures that 
>> software can remain compatible with future versions of the license. But what 
>> happens if someone just says their program is under GNU GPL version 2, for 
>> example?
>>
>>>[T]hey are leaving the licensing of the program unclear. Is it released 
>>> under GPL-2.0-only, or GPL-2.0-or-later? Can you merge the code with 
>>> packages released under GPL-3.0-or-later?
>>
>> Thus, it is vitally important that developers indicate in their license 
>> notices whether they are licensing their work under that version "only" or 
>> under "any later version." Of course, these days it is also helpful for 
>> license notices to be machine-readable. The Software Package Data Exchange 
>> (SPDX) specification sets a standardized way of identifying licenses on 
>> software packages. They are updating their license identifiers to include 
>> this distinction in their upcoming version. For example, for GNU GPL version 
>> 2, the identifiers are now "GPL-2.0-only or GPL-2.0-or-later." The old 
>> identifiers (e.g. "GPL-2.0") are now deprecated and should no longer be 
>> used. Based on the changes SPDX says are coming in the SPDX specification 
>> and its Web site, the FSF expects to endorse the new version of the SPDX. We 
>> thank SPDX and their community for making these helpful changes.
>
>
> Maybe we could make use of what https://spdx.org/licenses/
> provides. I didn't compare the names with our names, I'll do
> this on the train next week.
> Good idea, bad idea?

We already have a `spdx-string->license' function in
`(guix import utils)', in case you need a starting point. It
makes sense to me to use a de facto way of referring to licenses,
but I am not sure whether this has some disadvantages compared to the
currently used way of referring to licenses.

- Jelle

Re: license naming

[ng0]

Jelle Licht transcribed 2.3K bytes:
> 
> ng0  writes:
> 
> > I've just read this link: 
> > https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2
> >
> > Full Quote:
> >
> >> In this article, For Clarity's Sake, Please Don't Say "Licensed under GNU 
> >> GPL 2"!, Free Software Foundation president Richard Stallman (RMS) 
> >> explains how to properly identify what GNU license your work is under. 
> >> Whenever a developer releases their work under a GNU license, they have 
> >> the option to either release it under that version of the license only, or 
> >> to make it available under any later version of that license. This option 
> >> ensures that software can remain compatible with future versions of the 
> >> license. But what happens if someone just says their program is under GNU 
> >> GPL version 2, for example?
> >>
> >>>[T]hey are leaving the licensing of the program unclear. Is it 
> >>> released under GPL-2.0-only, or GPL-2.0-or-later? Can you merge the code 
> >>> with packages released under GPL-3.0-or-later?
> >>
> >> Thus, it is vitally important that developers indicate in their license 
> >> notices whether they are licensing their work under that version "only" or 
> >> under "any later version." Of course, these days it is also helpful for 
> >> license notices to be machine-readable. The Software Package Data Exchange 
> >> (SPDX) specification sets a standardized way of identifying licenses on 
> >> software packages. They are updating their license identifiers to include 
> >> this distinction in their upcoming version. For example, for GNU GPL 
> >> version 2, the identifiers are now "GPL-2.0-only or GPL-2.0-or-later." The 
> >> old identifiers (e.g. "GPL-2.0") are now deprecated and should no longer 
> >> be used. Based on the changes SPDX says are coming in the SPDX 
> >> specification and its Web site, the FSF expects to endorse the new version 
> >> of the SPDX. We thank SPDX and their community for making these helpful 
> >> changes.
> >
> >
> > Maybe we could make use of what https://spdx.org/licenses/
> > provides. I didn't compare the names with our names, I'll do
> > this on the train next week.
> > Good idea, bad idea?
> 
> We already have a `spdx-string->license' function in
> `(guix import utils)', in case you need a starting point. It
> makes sense to me to use a de facto way of referring to licenses,
> but I am not sure whether this has some disadvantages compared to the
> currently used way of referring to licenses.
> 
> - Jelle

My "problem", or rather the question I pose is: Does it make sense to
adjust how the license is displayed? Like instead of "GPL 2" We'd display
"GPL 2.0 only" and instead of "GPL 2+" (no example at hand to test if this
is the current display) we'd display "GPL 2 or later".
-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
  WWW: https://n0.is


signature.asc
Description: PGP signature

Re: Packaging LyX

[Danny Milosavljevic]

Hmm, do the tests work for you? Back when I tried this was the blocker for me...

Re: OpenBLAS and performance

[Ricardo Wurmus]

Pjotr Prins  writes:

>> > If I compile for a target it
>> > makes a large difference.
>> 
>> The FAQ document[1] says this:
>> 
>>   The environment variable which control the kernel selection is
>>   OPENBLAS_CORETYPE (see driver/others/dynamic.c) e.g. export
>>   OPENBLAS_CORETYPE=Haswell. And the function char*
>>   openblas_get_corename() returns the used target.
>> 
>> [1]: https://github.com/xianyi/OpenBLAS/wiki/Faq
>> 
>> Have you tried this and compared the performance?
>
> About 10x difference on 24+ cores for matrix multiplication (my
> version vs what comes with Guix).
>
> I do think we need to default to a conservative openblas for general
> use. Question is how we make it fly on dedicated hardware.

Have you tried preloading the special library with LD_PRELOAD?

-- 
Ricardo

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

Re: license naming

[Ludovic Courtès]

ng0  skribis:

> My "problem", or rather the question I pose is: Does it make sense to
> adjust how the license is displayed? Like instead of "GPL 2" We'd display
> "GPL 2.0 only" and instead of "GPL 2+" (no example at hand to test if this
> is the current display) we'd display "GPL 2 or later".

Sure, that sounds reasonable to me.

Ludo’.

Re: Packaging LyX

[Gammel Holte]

Danny Milosavljevic  wrote:

> Hmm, do the tests work for you? Back when I tried this was the blocker for
> me...
>

Yes, they work fine. Aside, I've tested LyX for a few days and everything
has worked as expected so far.

After looking into all documentation, packages from other distros, and
testing different things I'm pretty sure the minimal set of dependencies is
what I listed in my previous email.

Give the script attached a try if you want (still not a proper package, so
you need to do guix package -f lyx.scm). It also needs python@2.7 in the
environment as LyX doesn't bind to python properly, but rather tries to
find it dynamically during runtime. I need to fix that.
(use-modules
 (guix packages)
 (guix download)
 (guix build-system gnu)
 (guix licenses)
 (gnu packages algebra)
 (gnu packages compression)
 (gnu packages pkg-config)
 (gnu packages python)
 (gnu packages qt))

(package
 (name "lyx")
 (version "2.2.3")
 (source (origin
	  (method url-fetch)
	  (uri (string-append "ftp://ftp.lyx.org/pub/lyx/stable/2.2.x/lyx-";
			  version ".tar.gz"))
	  (sha256
	   (base32 "0xvaz0i371nn2ndinc0d3ywj76ivb62649a4sdgwbivisiahd2fj"
 (build-system gnu-build-system)
 (inputs `(("pkg-config" ,pkg-config)
	   ("python" ,python-2)
	   ("qt" ,qt)
	   ("bc" ,bc)
	   ("zlib" ,zlib)))
 (arguments `(#:configure-flags (list "--enable-qt5")))
 (home-page "http://www.lyx.org";)
 (synopsis "An advanced WYSIWYM document processor and LaTeX front-end")
 (description "LyX is a document processor that encourages an approach
to writing based on the structure of your documents (WYSIWYM) and not
simply their appearance (WYSIWYG). LyX combines the power and
flexibility of TeX/LaTeX with the ease of use of a graphical
interface.")
 (license gpl2+))

;; wrap python
;; zlib lint

Re: Porting GuixSD to ARM article.

[Mathieu Othacehe]

> Very cool!

Thanks Pjotr!

Mathieu

Re: Porting GuixSD to ARM article.

[Mathieu Othacehe]

Hi Vicent,

> The definition on an installation image for the BeagleBone Black.
> s/on an/of an/

Thanks for pointing it out.

> In "Preparing a dedicated system configuration",  I'm not sure,
> but you have a "tty-O-0" in the system configuration:
>
> (tty "ttyO0")
>
> Isn't that a typo also ?

Nope it is not. It's the name of serial port on some Omap targets.

Mathieu

Re: Packaging LyX

[Gammel Holte]

On Fri, Dec 22, 2017 at 7:42 PM, ng0  wrote:

Thanks for your comments. I will address those before I circulate a patch.

> Is this python-2 only? If not, could you explain why you picked 2 and not
3
> (2 is on its way out in 20 months).

LyX is sadly not ready for Python 3 yet. It will be soon, but there are
still
tickets open to support it: https://www.lyx.org/trac/ticket/9006

Furthermore, I've tested LyX with Python 3 and it breaks.

Any hints on how to wrap the LyX package output so that it binds to the
Python input, instead of looking for it at runtime, like the Nix package
does?

https://github.com/NixOS/nixpkgs/blob/86da6d441f7a248b02d545ac1b2c90ef27f42d0b/pkgs/applications/misc/lyx/default.nix

Re: Building from a local source code checkout

[Ludovic Courtès]

Konrad Hinsen  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> I agree the matching-name constraint can be annoying.  The alternative
>> would be allow the user to (optionally?) specify the name of the package
>> whose source is being changed, as in:
>>
>>   guix build python-activepapers \
>> --with-source=python-activepapers=$HOME/Dev/AP
>>
>> WDYT?
>
> Looks much clearer to me. But, as you say, this could well be optional
> if we can live with an ambiguity in the rare case of filenames containg
> an equal sign.

I’ve implemented it here:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3e30cdf1c35ebeb52630ec19b3b43b9e6d5ffb81

You no longer need to rename your source directory.  :-)

Ludo’.