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

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.

Re: Debugging info unavailability

[Ricardo Wurmus]

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?

--
Ricardo

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

Re: GuixSD bootable ISO-9669 image

[Mark H Weaver]

ng0  writes:

> Ludovic Courtès transcribed 5.2K bytes:
>> Anyway, I think we should polish and commit real soon.  :-)  Perhaps we
>> can add a note about endianness and assume little endian for now.
>
> Excuse me if I didn't pay much attention to the thread, I just flipped
> through all of it. Isn't that (little endian) the most common assumption
> most operation system have? I know that Gentoo defaults to little endian.
>
> https://packages.gentoo.org/useflags/search?q=big-endian
>
> And we don't support SuperH or similar Big Endian hardware. Or am I
> thinking about different reasons why the endianness here matters?

We should keep the door open to adding support for big-endian systems in
the future.  That job will be made more difficult if we incorporate code
that assumes little-endian.  Let's please strive for portability.

  Mark

Re: Templates for monadic procedures

[Ricardo Wurmus]

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.

> Currently it doesn’t have a noticeable performance impact because monads
> are used sparsely, but I expect it will help with the
> ‘wip-build-systems-gexp’ branch, which aims to use gexps (and thus
> ‘%store-monad’) for packages.

Yay, super cool!  I’m looking forward to seeing that branch merged!

--
Ricardo

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