Re: cross-compiling in core-updates

[rennes]

Hello,
Following the tests('./pre-inst-env guix build --target=i586-pc-gnu  
bootstrap-tarballs'), now shows the following:


---
environment variable `PATH' set to  
`/gnu/store/5if2cargrflg5j9jh7ykqpgvm6p2ydid-tar-1.29/bin:/gnu/store/hbcpwp65nngw0abyhk27dgmbac47ymk0-xz-5.2.2/bin'
@ build-succeeded  
/gnu/store/40j2pslf5saqw7zs4z1cpr8lj7w6ibym-glibc-stripped-tarball-2.23.drv  
-
@ build-started  
/gnu/store/w26zkmxffr6b86g14631md9nq16mgi2l-grep-3.0.drv - x86_64-linux  
/var/log/guix/drvs/w2//6zkmxffr6b86g14631md9nq16mgi2l-grep-3.0.drv.bz2

ice-9/psyntax.scm:1534:32: In procedure expand-macro:
ice-9/psyntax.scm:1534:32: Syntax error:
/gnu/store/9hq535wqqxg4rxa6z4mnmykmrw368hkw-grep-3.0-guile-builder:2:1887:  
source expression failed to match any pattern in form (%modify-phases  
phases* (delete (quote fix-egrep-and-fgrep)))
builder for `/gnu/store/w26zkmxffr6b86g14631md9nq16mgi2l-grep-3.0.drv'  
failed with exit code 1
@ build-failed /gnu/store/w26zkmxffr6b86g14631md9nq16mgi2l-grep-3.0.drv  
- 1 builder for  
`/gnu/store/w26zkmxffr6b86g14631md9nq16mgi2l-grep-3.0.drv' failed with  
exit code 1
@ build-started  
/gnu/store/jf8pnajml667p4926hpfr26ma7rbqvsi-guile-static-2.0.14.drv -  
x86_64-linux  
/var/log/guix/drvs/jf//8pnajml667p4926hpfr26ma7rbqvsi-guile-static-2.0.14.drv.bz2
cannot build derivation  
`/gnu/store/jq4llinka0r42763sgnq9wlcbnbvjnmc-static-binaries-0.drv': 1  
dependencies couldn't be built
cannot build derivation  
`/gnu/store/l2fj6didfwkaqc3r2h80yvzwf350q7a4-static-binaries-tarball-0.drv':  
1 dependencies couldn't be built
cannot build derivation  
`/gnu/store/4a0n4ji7vjapyvlwpg9l3lxqb03vcr4q-bootstrap-tarballs-0.drv':  
1 dependencies couldn't be built
guix build: error: build failed: build of  
`/gnu/store/4a0n4ji7vjapyvlwpg9l3lxqb03vcr4q-bootstrap-tarballs-0.drv'  
failed

---

Re: Debugging info unavailability

[Maxim Cournoyer]

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

> Ricardo Wurmus  skribis:
>
>> Maxim Cournoyer  writes:
>>
> Adding the "debug" to the default value of  would every package
> to now have a debug output; isn't this why Danny suggested to only
> change it at the build system level? That way nothing which doesn't have
> debugging symbols by default would break or have a useless debug output.

 Yes, it’s tempting to do it at the build-system level.  However, there
 would now be a discrepancy between the actual outputs of the package
 derivations and those of the package object: the package object would
 declare just one output, but the corresponding derivation would have two
 outputs.

>>>
>>> Thanks for pointing that! It would be a Bad Thing indeed to introduce a
>>> mismatch between the package definition and the corresponding store
>>> item...
>>>
>>> Possibly another Bad Idea, but we could leave things as they are... And
>>> run a script which would rewrite (really, at the package definition
>>> level) the package outputs to include "debug" for every package built
>>> using the gnu/glib-or-gtk build systems? The commit will not be
>>> pretty, that would bring us where we want to be? Being Scheme, that'd be
>>> somewhat easy.
>>
>> This sounds better.  I just don’t know if Hydra would have enough space
>> for all of these additional outputs.
>>
>> Can we increase storage space on Hydra already or do we need to wait for
>> bayfront to replace the server in Boston?
>
> I don’t think we can have more space easily on hydra.gnu.org.
>
> I’m also unsure how much would be needed.  Currently ‘guix publish’
> prepares bakes archives on-demand.  So if you ask for glibc:out, it
> returns 404, prepares it, and the next request for glibc:out will
> succeed.  But if you ask for glibc:debug, it’s similarly missing
> initially.
>
> With this model, ‘guix publish’ gives the impression that not all the
> outputs of a given derivation are available at the same time.
>
> We could change ‘guix publish’ to “bake” all the outputs of a derivation
> as soon as one if requested—e.g., when you ask for glibc:out, it bakes
> not only glibc:out but also glibc:debug.  But then we might have a disk
> space issue.
>
> Thoughts?
>
> Ludo’.

The ideal situation would be to not be space contrived and to build a cache
everything or at least following some heuristic such as "every package that
was requested at least once in the past month". For someone following
master, I find that the current way substitutes are built is not
aggressive enough, and I find often find myself building the world with
--fallback.

What good is a substitute server if it doesn't hold the stuff I need
*now*? :) On the other side, it really makes me want to look at GNUnet,
which seems like the better long term solution.

I'll investigate the script to add "debug" to our gnu/gtk packages.

Maxim


signature.asc
Description: PGP signature

Re: 04/04: offload: Avoid using '_' as a 'match' pattern.

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>> In hindsight, it would have been wiser to just rename ‘_’ in (guix ui)
>> to something else, like ‘G_’.  Well, it’s not too late.  Should we do
>> that?  Thoughts?
>
> I agree that renaming '_' in (guix ui) is the better approach.

Done in 69daee23af49aeafcb1d250c90860f9253da719e.

The downside is that I had to disable -Wformat, which reported too many
“non-literal format string”: -Wformat assumes that the ‘gettext’
procedure can be called ‘_’, and otherwise emits that warning.

We should do something on the Guile side to fix this, perhaps by
allowing users to annotate identifiers as being gettext-like procedures.

Thoughts?

Ludo’.

Re: potluck status

[Ludovic Courtès]

Christopher Allan Webber  skribis:

> Andy Wingo writes:
>
>> On Fri 28 Apr 2017 14:42, Hartmut Goebel  
>> writes:
>>
>>> Am 28.04.2017 um 14:05 schrieb Andy Wingo:
   5.15 Invoking ‘guix potluck’
>>>
>>> Please think about an other name for this command. "potlouk"  may be
>>> common to native speakers but I never heard this word. Thanks.
>>
>> I thought about many things :)  Do you have a suggestion?
>> https://guix-potluck.org/ does provide the definition.
>>
>> Andy
>
> I personally like Potluck a lot; I know it might not be a particularly
> common English word, but it may be a good one for people to learn if
> they don't already know it.  It captures the spirit of things to me very
> nicely.

Perhaps we could add a short footnote in the manual to explain what a
potluck is and how this relate to all this?

Ludo’.

Re: potluck status

[Ludovic Courtès]

Hello!

Andy Wingo  skribis:

> Here is part of the documentation in that branch:
>
>   5.15 Invoking ‘guix potluck’
>   

Excellent, nicely written as usual!

> With the release of Guile 2.2.2, I have re-enabled
> https://guix-potluck.org.  I also refactored that server's configuration
> to move some service definitions into Guix itself (the certbot service,
> for example); see:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26684
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26685
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26686
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26687

Awesome.

> I also updated the code for "guix potluck host-channel" to show recent
> packages added, log entries, and so on.  Finally I found the source of
> the HTTPS post error; it was in Guile:
>
>   https://git.savannah.gnu.org/cgit/guile.git/commit/
>
> With that I think I'd like to move to a "use" phase where I just sit
> back and see how people use the thing :)  WDYT?  If you agree I can push
> patches from the above bugs into master maybe this weekend or so.

The week-end has passed ;-), but I agree.  I’m taking a look at #26645
(the actual potluck patch) to see if I have anything to add, but yeah,
let’s push this real soon!

When we’re done, what about writing a blog post for the web site about
it?  I guess it could largely be a copy/paste of the documentation you
posted above.

> We can fix the "specification->package" interface in parallel as
> discussed here:
>
>   https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00401.html
>
> when we add the "guix channel" facility, which I guess will depend on
> guile-git.

Yes, post 0.13.0, we’ll depend on Guile-Git and start doing fun stuff
with it I hope.

Ludo’.

Re: guix package / output for guix documentation

[ng0]

ng0 transcribed 0.4K bytes:
> Do you think it could be good to provide the output of
> guix' "make doc/guix.html" and other make doc/ outputs
> in a separate package (or outputs of guix itself)?
> 
> My idea is to have an independent online/offline version
> of the html documentation, matching some snapshot or
> commit id.
> In my case, I will provide this online, currently solved
> with a script instead of a guix package.

Looking at the implications of dependencies:

Definitely NOT as an output of Guix itself.
I'm working on a small package now which uses "current-guix"
as a base.

-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/

Re: [PATCH] gnu: Add cool-retro-term.

[Petter]

On Tue, 2 May 2017 08:51:06 -0500
Eric Bavier  wrote:

> Hi Petter,
> 
> Thanks again for your patience with this review.

Hi Eric,

I'm in no rush :)

> "gpl2" in the license field should be "gpl2+" according to
> qmltermwidget license headers.  Could you also include a comment noting
> the component split?  Nothing fancy, just "for qmltermwidget" or so next
> to gpl2+ and "for cool-retro-term" next to gpl3+.

Done. I did it like this:
  (license (list 
license:gpl2+ ; qmltermwidget
license:gpl3+ ; cool-retro-term
;; Fonts
license:silofl1.1
license:x11)

> > > > > and the fonts/1977-apple2, fonts/1977-commodore-pet, probably also
> > > > > needs to be stripped as non-free; from 'FreeLicense.txt':
> > > > > 
> > > > >   "1. The User may not sell copies of the Software for a fee."
> > > > > 
> > > > > The fonts/1979-atari-400-800 font seems to be non-free license, which
> > > > > is not mentioned in the 'ReadMe.rtf' but only on the WayBack Machine
> > > > > at
> > > > > https://web-beta.archive.org/web/20080907111008/http://www2.bitstream.net/~marksim/atarimac/fonts.html
> > > > >  :
> > > > > 
> > > > >   "These fonts are freeware and may not be offered for sale seperately
> > > > >   or as part of a collection."
> > > > > 
> > > > > The fonts/1982-commodore64 font is licensed under non-free terms; see
> > > > > fonts/1982-commodore64/license.txt
> > > > > 
> > > > > The only mention of a license for fonts/1985-ibm-pc-vga is at
> > > > > http://www.dafont.com/font-comment.php?file=perfect_dos_vga_437 where
> > > > > the author says "The license is this: this font is free to use in
> > > > > whatever you want.", but that probably "doesn't count".
> > > > > 
> > > > > I could not find license info for a few of the other fonts.
> > > > > 
> > > > > OTOH I recall a discussion on IRC recently about fonts embedded in
> > > > > packages being treated as non-functional data, and thus OK from a FSDG
> > > > > perspective.  But I would want verification on that.
> > > > 
> > > > Let's see if someone can shine some light on this.
> > > >   
> > > 
> > > Leo pointed me at https://bugs.gnu.org/26588 which references
> > > https://www.gnu.org/distros/free-system-distribution-guidelines.html#non-functional-data
> > >  .
> > > I think many of these fonts would need to be stripped out or
> > > substituted because their license prohibits commercial/non-commercial
> > > redistribution.
> > 
> > Recipe is now removing the following from disk and GUI:
> >   '("1977-apple2"
> > "1977-commodore-pet"
> > "1979-atari-400-800"
> > "1982-commodore64"
> > "1985-ibm-pc-vga")  
> 
> The code you've added to delete these fonts and adjust the source
> accordingly would be better in an origin 'snippet' so that `guix build
> -S cool-retro-term` does not include the fonts.

Done.

> > 
> > Should more be removed?  
> 
> modern-monaco.  It's a font from Apple which is specifically *not*
> freely distributable, but the ttf file is still floating around the
> internet, giving many projects the impression that it is.
> 
> > 
> > What do we do about the fonts without licensing info?  
> 
> I agree with Chris that we need to remove them.

Right, I've made the mental switch now to whitelist rather than blacklist.
The ones that are included now are modern-hermit, modern-pro-font-win-tweaked
and modern-proggy-tiny. The rest are out until proven Free.

Let me know if there are other fonts /we can include/ ;)


Also added a `crt` as a symlink to cool-retro-term.


Thanks Eric and Chris for being so thorough and helpful! Let me know if there
are more issues.


Best,
Petter
From c4b0d4bc32053660476c54a7471c6d312651788a Mon Sep 17 00:00:00 2001
From: Petter 
Date: Sun, 23 Apr 2017 13:46:41 +0200
Subject: [PATCH] gnu: Add cool-retro-term.

* gnu/packages/terminals.scm (cool-retro-term): New variable.
---
 .../cool-retro-term-dont-check-uninit-member.patch |  33 ++
 .../patches/cool-retro-term-fix-array-size.patch   |  25 ++
 .../patches/cool-retro-term-memory-leak-1.patch|  32 ++
 .../cool-retro-term-remove-non-free-fonts.patch| 403 +
 gnu/packages/terminals.scm | 109 ++
 5 files changed, 602 insertions(+)
 create mode 100644 gnu/packages/patches/cool-retro-term-dont-check-uninit-member.patch
 create mode 100644 gnu/packages/patches/cool-retro-term-fix-array-size.patch
 create mode 100644 gnu/packages/patches/cool-retro-term-memory-leak-1.patch
 create mode 100644 gnu/packages/patches/cool-retro-term-remove-non-free-fonts.patch

diff --git a/gnu/packages/patches/cool-retro-term-dont-check-uninit-member.patch b/gnu/packages/patches/cool-retro-term-dont-check-uninit-member.patch
new file mode 100644
index 0..c6e1d2731
-

guix package / output for guix documentation

[ng0]

Do you think it could be good to provide the output of
guix' "make doc/guix.html" and other make doc/ outputs
in a separate package (or outputs of guix itself)?

My idea is to have an independent online/offline version
of the html documentation, matching some snapshot or
commit id.
In my case, I will provide this online, currently solved
with a script instead of a guix package.
-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/

Re: [PATCH] gnu: Add cool-retro-term.

[Petter]

On Sun, 30 Apr 2017 13:59:29 -0700
Chris Marusich  wrote:

> Petter  writes:
> 
> > What do we do about the fonts without licensing info?  
> 
> Unfortunately, "no license" is not a free license:

Yeah, I kinda figured that one just after I sent the e-mail :)

> 
> https://www.gnu.org/licenses/license-list.en.html#NoLicense
> 
> "If source code does not carry a license to give users the four
> essential freedoms, then unless it has been explicitly and validly
> placed in the public domain, it is not free software."
> 
> The FSDG states:
> 
> https://www.gnu.org/distros/free-system-distribution-guidelines.html
> 
> "License Rules
> 
> 'Information for practical use' includes software, documentation,
> fonts, and other data that has direct functional applications. It does
> not include artistic works that have an aesthetic (rather than
> functional) purpose, or statements of opinion or judgment.
> 
> All information for practical use in a free distribution must be
> available in source form. ('Source' means the form of the information
> that is preferred for making changes to it.)
> 
> The information, and the source, must be provided under an appropriate
> free license. We evaluate specific licenses and list our determinations
> in our license list, with separate sections for licenses that are
> suitable for software, documentation, fonts, and other useful works. If
> such a work is released under a disjunction of licenses, the work is
> free as long as at least one of its licenses is free; the system
> developers should follow the terms of the applicable free license(s)
> when they distribute and/or modify it."
> 
> The same page also has a section on fonts:
> 
> https://www.gnu.org/licenses/license-list.en.html#Fonts
> 
> "The licenses below apply to an instantiation of a design in a computer
> file, not the artistic design. As far as we know, an implementation of a
> design is always copyrightable. The legal status of the artistic design
> is complex, and varies by jurisdiction."
> 
> To ensure that this contribution meets these guidelines and respects the
> freedom of the system's users, I think we cannot include a font for
> which we cannot find an associated license.  If we can find a license
> for the font and it is a free license, then we could include it.
> 

Thanks for this information! Licensing is a weak field for me.

I've made a mental change from blacklisting fonts to whitelisting.



pgpxQHPr2Ls67.pgp
Description: OpenPGP digital signature

Re: Templates for monadic procedures

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> So, 
>> 
>> adds a C++-inspired template mechanism to (guix monads).  Now we can
>> write:
>>
>>   (define-template (mapm monad proc lst)
>> …)
>>
>> That automatically leads to the definition of both a generic version
>> (same one as before, inefficient) as well as one specialized version for
>> each monad that is defined.  Each specialized version is more efficient
>> because the monad it is specialized for is known at expansion-time, and
>> thus we can inline the monad’s bind/return:
> […]
>> All this relies on a “stateful macro” that keeps state across the
>> expansion-time and run-time stages.  I think it’s a pretty fun hack!
>
> Wow!  That’s very cool!  I previously played with my own monads in Guile
> for a toy project and it bothered me that too many lookup happened at
> runtime.  Having a lookup directory at expansion time is really neat,
> though I must say that this higher level macrology would be very hard
> for me to come up with from scratch!
>
> I wonder if we could also do monad type checking at expansion or compile
> time.  That’s the last thing that’s missing here.

At this point we can distinguish between “definitely a monad” and “don’t
know” for the first argument of ‘mlet’ and the templated procedures.
That’s a start.  ;-)

I really want to look at Turnstile, which uses macrology to introduce
some typing:

  https://docs.racket-lang.org/turnstile/The_Turnstile_Guide.html

Ludo’.

Re: Debugging info unavailability

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Maxim Cournoyer  writes:
>
 Adding the "debug" to the default value of  would every package
 to now have a debug output; isn't this why Danny suggested to only
 change it at the build system level? That way nothing which doesn't have
 debugging symbols by default would break or have a useless debug output.
>>>
>>> Yes, it’s tempting to do it at the build-system level.  However, there
>>> would now be a discrepancy between the actual outputs of the package
>>> derivations and those of the package object: the package object would
>>> declare just one output, but the corresponding derivation would have two
>>> outputs.
>>>
>>
>> Thanks for pointing that! It would be a Bad Thing indeed to introduce a
>> mismatch between the package definition and the corresponding store
>> item...
>>
>> Possibly another Bad Idea, but we could leave things as they are... And
>> run a script which would rewrite (really, at the package definition
>> level) the package outputs to include "debug" for every package built
>> using the gnu/glib-or-gtk build systems? The commit will not be
>> pretty, that would bring us where we want to be? Being Scheme, that'd be
>> somewhat easy.
>
> This sounds better.  I just don’t know if Hydra would have enough space
> for all of these additional outputs.
>
> Can we increase storage space on Hydra already or do we need to wait for
> bayfront to replace the server in Boston?

I don’t think we can have more space easily on hydra.gnu.org.

I’m also unsure how much would be needed.  Currently ‘guix publish’
prepares bakes archives on-demand.  So if you ask for glibc:out, it
returns 404, prepares it, and the next request for glibc:out will
succeed.  But if you ask for glibc:debug, it’s similarly missing
initially.

With this model, ‘guix publish’ gives the impression that not all the
outputs of a given derivation are available at the same time.

We could change ‘guix publish’ to “bake” all the outputs of a derivation
as soon as one if requested—e.g., when you ask for glibc:out, it bakes
not only glibc:out but also glibc:debug.  But then we might have a disk
space issue.

Thoughts?

Ludo’.

Re: Defining user services in Guix.

[Mathieu Othacehe]

>> Happy hacking!  :-)

>> Ludo’.
>
> Yay!  Welcome Mathieu!

Thanks Ricardo and Ludo !

Pushed as 5e03b122cf295d24e01861ca942505d47f9aa59e.