Re: Help needed: Updating GHC to 8.4.3

[Timothy Sample]

Hi Ricardo,

Ricardo Wurmus  writes:

> Hi Ludo,
>
>> Hello,
>>
>> Ricardo Wurmus  skribis:
>>
>>> GHC 8.0 had been patched with
>>> "ghc-dont-pass-linker-flags-via-response-files.patch" to avoid using
>>> response files with the linker, because our ld-wrapper doesn’t seem to
>>> behave right in some edge case that GHC depends on.  I tried porting the
>>> patch to GHC 8.4.3 by applying this snippet:
>>
>> I think this patch predates the addition of support for response files
>> in ld-wrapper.  That support is not entirely faithful (see the FIXME in
>> ld-wrapper.in), but I think it’s good enough for GHC.
>>
>> Could you maybe try removing the patch and see if it works better?
>
> I did try to build GHC 8.4.3 without any patches first, but this failed
> (with the same errors and warnings when trying to set up the tests).
> Only then did I try to port the patch from 8.0.x to 8.4.3.

I had some success with GHC 8.4.3.  It turns out that the warnings exist
for 8.0.2 as well.  I’m not sure what they are about, but they are not a
new problem.

The new problem is that the stage-2 GHC compiler is not using the
ld-wrapper.  This is due to some changes to their Autoconf scripts which
add “-fuse-ld=bfd” to the later-stage compilers’ “gcc” invocations by
default.  Since “ld.bfd” does not point to the ld-wrapper, the wrapper
gets bypassed.

There are two easy solutions to this:

  1. Use the “--disable-ld-override” configure flag.
  2. Set the “LD” environment variable.

I got the package to build using option 1.  However, it didn’t work
because it expected all the build tools (“gcc”, “ld”, etc.) to be in
“PATH”.  They traded “AC_PATH_” for “AC_CHECK_”, setting the variables
to just the command names.  Nix uses option 2 and sets explicit paths
for all the tools via environment variables.  I think we have to do the
same.

Also, I didn’t need the response files patch, and the
“native-search-paths” field needs to be updated.

Hope that helps!


-- Tim

guix system init question

[Rene]

Hello,

I'm updating my guix repository in Debian/Hurd with the commit 
40f5c53d89da266055a1dd6571c380f5c57fe5f9.
When I run `sudo ./pre-inst-env guix system init doc/os-config-hurd.scm /guix 
--fallback --no-substitutes --no-build-hook` show the error:

`
Backtrace:
  10 (primitive-load "/home/jin/guix/scripts/guix")
In guix/ui.scm:
  1452:12  9 (run-guix-command _ . _)
In ice-9/boot-9.scm:
    829:9  8 (catch _ _ # …)
    829:9  7 (catch _ _ # …)
In guix/scripts/system.scm:
   1109:8  6 (_)
    983:6  5 (process-action _ _ _)
In guix/store.scm:
  1444:24  4 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
In guix/scripts/system.scm:
    714:2  3 (_ _)
In gnu/services.scm:
    317:2  2 (_ _)
In gnu/system.scm:
   434:28  1 (_ _)
   996:34  0 (operating-system-boot-parameters-file #< …)

gnu/system.scm:996:34: In procedure operating-system-boot-parameters-file:
In procedure struct_vtable: Wrong type argument in position 1 (expecting 
struct): #f
`
I have reviewed the code in (scripts system), but I have not had luck; Any idea 
what's happening?

Attachment operating system configuration template.

Thank you
Rene
(use-modules (gnu))
(use-package-modules hurd)

(operating-system
  (host-name "antelope")
  (timezone "Europe/Paris")
  (locale "en_US.utf8")
  
  ;; Assuming /dev/sdX is the target hard disk, and "my-root" is
  ;; the label of the target root file system.
  (bootloader (bootloader-configuration
   (bootloader grub-bootloader)
   (target "/dev/hd2s1")))
  
  (kernel gnumach)
  
  (file-systems (cons (file-system
(device "my-root")
(title 'label)
(mount-point "/guix")
(type "ext2"))
  %base-file-systems))
  
  (users (cons (user-account
(name "prometheus")
(comment "Welcome to the Hurd")
(group "users")
(home-directory "/home/prometheus"))
   %base-user-accounts))

  (packages (cons* 
	 %base-packages-hurd))
  
  (services %base-services-hurd))

Re: Graft hooks

[Mark H Weaver]

Hi Ludovic,

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

> Mark H Weaver  skribis:
>
>> I think it would be quite unfortunate if _every_ graft had to run
>> _every_ graft hook, or if every graft hook had to be defined in
>> (guix grafts) and/or (guix build graft).
>>
>> It's reasonable to have a few global graft hooks, e.g. for handling
>> debugging information, but I would greatly prefer for Guix to also have
>> a mechanism allowing individual packages or build systems to introduce
>> graft hooks without modifying (guix grafts) or (guix build graft), and
>> for such a mechanism to be used for Racket and its libraries.
>
> Sure, like I wrote, a more extensible solution along the lines of what
> Timothy and you suggest sounds better long-term.  It just happens to be
> harder to implement today (in particular until ‘wip-build-systems-gexp’
> is merged), and not entirely clear how this could work, as discussed
> with Timothy.

That's fine.  This solution is fine for now, as long as the number of
graft hooks is fairly small.  Maybe we can revisit this after
'wip-build-systems-gexp' is merged.

  Thanks,
Mark

New German PO file for 'guix' (version 0.15.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/guix/de.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

http://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Guix on aarch64

[Ricardo Wurmus]

Ludovic Courtès  writes:

> In addition, Ricardo has a plan to throw more storage at berlin (we
> currently have 1TB for the store).  That would allow us to increase the
> TTL and generally worry less, though it’s no substitute for the GC root
> mechanism above.

Right.  Unfortunately, this depends on me writing a multipathd service
for GuixSD so that we can use the external storage redundantly from the
head node of berlin.guixsd.org.

I haven’t been able to reserve enough time to implement this, but it’s
near the top of my list.

--
Ricardo

Re: Ghostscript / ImageMagick / GraphicsMagick vulnerability mitigation?

[Leo Famulari]

On Fri, Aug 24, 2018 at 03:04:53PM +0200, Ludovic Courtès wrote:
> In this week’s discussions, it’s unclear to me why people are focusing
> so much on ImageMagick and Evince when the real issue is in
> Ghostscript’s ability to run arbitrary commands from PostScript code.  I
> rarely run ‘convert’ on PS files, but I do run ‘gs’ from different
> sources: gv, Emacs Docview, Evince, ps2pdf, etc.

I think they take for granted that Ghostscript should not handle
untrusted input, so they are looking for ways that it may be invoked by
other applications without the user's explicit consent. And, they are
still picking the "low-hanging fruit" in this search, for example the
thumbnailing thing.

Apparently GNOME containerizes the thumbnailer in some cases with
'bubblewrap', but it requires the system to be set up properly (by us,
for example).

> So I was wondering if we could arrange to provide a wrapper around ‘gs’
> that would run it in a container that can only access its input and
> output files, plus font files from the store.  Now I wonder if I’m too
> naive and if this would in practice require more work.
> 
> Thoughts?

Yeah, that would be interesting. Are there any packages that have
something similar right now?

> I agree that it would be good to provide a policy.xml somehow. On
> GuixSD, we could provide it by default for new accounts (as a Shadow
> “skeleton”.)

Agreed, or at least alter the default copy that comes in the built
package.


signature.asc
Description: PGP signature

Re: [Next browser] Common Lisp: mgl-pax: Package SWANK-BACKEND does not exist.

[Pierre Neidhardt]

Thank you, Ludo.

Upstream suggests a patch to the ASDF system definition.  I'll try that later.

I've pushed the current state of work to the 'wip-next-browser' branch.

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


signature.asc
Description: PGP signature

Re: Ghostscript / ImageMagick / GraphicsMagick vulnerability mitigation?

[Ludovic Courtès]

Hello Leo,

Leo Famulari  skribis:

> For the last couple years, people have been finding exploitable bugs in
> the image processing system based on Ghostscript and ImageMagick /
> GraphicsMagick:
>
> http://seclists.org/oss-sec/2018/q3/142
> http://seclists.org/oss-sec/2016/q4/29

In this week’s discussions, it’s unclear to me why people are focusing
so much on ImageMagick and Evince when the real issue is in
Ghostscript’s ability to run arbitrary commands from PostScript code.  I
rarely run ‘convert’ on PS files, but I do run ‘gs’ from different
sources: gv, Emacs Docview, Evince, ps2pdf, etc.

So I was wondering if we could arrange to provide a wrapper around ‘gs’
that would run it in a container that can only access its input and
output files, plus font files from the store.  Now I wonder if I’m too
naive and if this would in practice require more work.

Thoughts?

There are a few applications that use libgs directly though, and these
would have to be treated separately.

> Despite these issues, these programs are still the best way to achieve
> some common image processing goals, so we have to think about how to
> make them safer.
>
> The primary recommendation seems to be setting a restrictive security
> policy in ImageMagick's policy.xml file, as described in the discussions
> linked above.
>
> Currently, Guix doesn't "set up" ImageMagick at all upon installation,
> which is different from some other systems like Debian and Fedora and
> their cousins, where the vulnerabilities are more dire [0]. Our
> ImageMagick package includes the default, unrestricted policy.xml.
>
> But, I'm wondering if anyone is using these tools in production from
> Guix and, if so, how they do it, and if they would like us to ship a
> non-default, more restrictive policy.xml in our package. And if so,
> could they write the policy.xml? :)

I agree that it would be good to provide a policy.xml somehow. On
GuixSD, we could provide it by default for new accounts (as a Shadow
“skeleton”.)

Thanks,
Ludo’.

Re: [Next browser] Common Lisp: mgl-pax: Package SWANK-BACKEND does not exist.

[Ludovic Courtès]

Hi Pierre,

Pierre Neidhardt  skribis:

> I have no clue what this SWANK-BACKEND is.  I can find SWANK/BACKEND in
> the source however.  Maybe my misunderstanding of Common Lisp...
>
> Any clue?

I’m clueless ;-) but I’ve Cc’d one of our local CL experts.
Any ideas, Andy?

Ludo’.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> I’d love to get us closer to being able to run the GNU system with the
> Hurd and Guix underpinnings.  Unfortunately, Hurd is not considered a
> priority by GNU, which shows in the lack of support for modern hardware.

I know you know ;-) but there’s no such thing as GNU when it comes to
setting a direction and providing resources to pursue software
development goals.

So I think what’s important here is to change the Hurd’s image to
attract freedom-conscious and security-savvy people and organizations.
Like Guix, it needs a critical mass to take off.

Ludo’.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Ludovic Courtès]

Hi there!

Christopher Lemmer Webber  skribis:

>  - It's getting hard to trust our computers as in terms of our physical
>hardware.  Companies like Purism are helping to build blobless
>systems, but even then the hardware is built on un-auditable and
>with growing apparent insecurity (Spectre, Meltdown) with little
>chance of fixing things.  RISC-V has a libre instruction set, and in
>the long term I think we want to support that.

Probably, though it’s hard to tell what RISC-V-based hardware will look
like—companies in a position to fabricate CPUs and to build computers
have goals not necessarily aligned with user freedom and autonomy.
RISC-V remains may be our best hope at this point, though.

>In the long run, we'll want to support object capability based OS
>designs which follow the principle of least authority, so a program's
>vulnerabilities will be limited in scope.

Definitely!

>  - What paths do we have forward on that last one?
>
>- Well, GNU Hurd is a microkernel + ocap system (while also trying
>  to be POSIX compatible).  Manolis has done much good work in
>  helping to make that a more feasible option for Guix users.
>
>- There's also seL4 which has a verified security kernel, possibly
>  even seL4 with Genode.  I'm not sure how hard it will be to run
>  POSIX type things on Genode.
>
>- There's also Google's recent work with Magenta/Fuschia.  From what
>  I've read, architecturally this looks right.  I think the reason
>  for worry here is the same difficulty the community has had to
>  build actual community and libre distributions on top of the
>  Android ecosystem could apply here.

Indeed.

We could also mention MINIX, which many of us are already using daily.
:-)

Putting aside Fuschia, I think the Hurd and MINIX are by far the
solutions that require the less work to be in a state where people with
“regular needs” like the rest of us to switch (MINIX is probably in that
state already.)

The Hurd already has a very advanced POSIX C library, which is not
negligible, especially compared to the other OSes.  Much progress has
been made in recent years wrt. drivers (using the Rump kernel in
particular.)  There are of course serious shortcomings, in particular
lack of 64-bit and SMP support.  But fixing these is relatively “little
work” in the grand scheme of things.

To put this in perspective, consider Linux namespaces: they have already
seen years of evolution, and the story of user namespaces shows that
it’s far from complete.

> As a side note, if we don't have both together (libre hardware + ocap)
> and we just have microkernel + ocap systems on top of proprietary
> hardware, especially heavily "vendor controlled" systems, we could end
> up much more screwed than we are even in our current systems, which is
> why I think it's critical that we engage these things.  In the book
> Rainbow's End (minor spoilers here) it's hinted that all the users are
> running computers which have object capaiblity security and are thus
> much more resilient to attacks, except that the bottom most layer of the
> system is intentionally government compromised so that all systems are
> effectively backdoored.  So, your sustem is secure... except for the
> backdoor.

Yeah.

> Anyway... the goal of this email was mostly just to try to get people
> thinking about the direction we want to go long term.  Hope that's
> useful/interesting even if it isn't an actual contribution of code
> towards it ;)

Another option that we can already start working on is to implement
least-authority in GNU/Linux through namespaces, as was discussed at:

  https://lists.gnu.org/archive/html/help-guix/2018-01/msg00056.html

Specifically there are two things we can implement:

  1. A ‘guix run’ command along the lines of
 .

  2. A mechanism that would allow, say, ‘guix package -i PKG --pola’ to
 automatically add “least-authority wrappers” around the binaries of
 PKG, pretty much like ‘guix pack --relocatable’ does (see
 ‘wrapped-package’ in (guix scripts pack)).

Not as bullet-proof as what an ocap OS or something like Qubes can
achieve, but already be an improvement.

For some packages (hi, ghostscript!), we might even want to add a
least-authority wrapper by default.

Thoughts?

Ludo’.

Re: FOSDEM 2019

[Christopher Lemmer Webber]

Manolis Ragkousis writes:

> Hello everyone,
>
> It's that time of the year again we need to start organizing about
> FOSDEM. We have a deadline for the 20th of September[1] to apply for a
> devroom. We also need to start looking for a place for this year's
> fringe event!
>
> I created a libreplanet page[2] to start writing possible talk ideas in
> case we get a devroom.

Thanks for everyone is doing organizing, especially Manolis for kicking
this off!

I added a talk topic: "A Guiler's Year of Racket".  I think there's a
lot we could learn from our fellow friends in Racket-land, and I'd like
to share some of that!

Re: 01/06: gnu: guile-redis: Update to 1.0.0.

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> civodul pushed a commit to branch master
>> in repository guix.
>>
>> commit a50eed201bf470b3bd124a2983bcea3453ec698f
>> Author: Ludovic Courtès 
>> Date:   Mon Aug 20 14:35:33 2018 +0200
>>
>> gnu: guile-redis: Update to 1.0.0.
>> 
>> * gnu/packages/guile.scm (guile-redis): Update to 1.0.0.
>> [source]: Fetch from github.com.  Remove snippet.
>> [native-inputs]: Add AUTOCONF, AUTOMAKE, and PKG-CONFIG.
>> ---
>>  gnu/packages/guile.scm | 27 ---
>>  1 file changed, 8 insertions(+), 19 deletions(-)
>>
>> diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
>> index f179f29..358613b 100644
>> --- a/gnu/packages/guile.scm
>> +++ b/gnu/packages/guile.scm
>> @@ -1241,31 +1241,20 @@ above command-line parameters.")
>>  (define-public guile-redis
>>(package
>>  (name "guile-redis")
>> -(version "0.1.0")
>> +(version "1.0.0")
>> +(home-page "https://github.com/aconchillo/guile-redis;)
>>  (source (origin
>>(method url-fetch)
>> -  (uri (string-append 
>> "mirror://savannah/guile-redis/guile-redis-"
>> -  version ".tar.gz"))
>> +  (uri (string-append home-page "/archive/" version ".tar.gz"))
>
> [...]
>
>>  (home-page "https://savannah.nongnu.org/projects/guile-redis/;)
>>  (synopsis "Redis client library for Guile")
>>  (description "Guile-redis provides a Scheme interface to the Redis
>
> This commit introduced a duplicate 'home-page' field.  You made the same
> mistake in your recent commit adding 'guile-gcrypt'.  I detected these
> problems quickly because I include the "records: detect duplicate field
> initializers" commit on my private branch.

Oops!

> Anyway, in the case of 'guile-gcrypt', both of the home-page
> initializers were the same.  In the case of 'guile-redis', they are
> different.  They are:
>
>> +(home-page "https://github.com/aconchillo/guile-redis;)
> [...]
>>  (home-page "https://savannah.nongnu.org/projects/guile-redis/;)
>
> Which one is correct?  I deleted the second one, because the first one
> is referenced in the source URI field, and initially I didn't notice
> that they were different.  Did guile-redis move from Savannah to GitHub?

Yes, it moved to GitHub.

Thanks for fixing these!

Ludo’.

Re: [Next browser] Common Lisp: mgl-pax: Package SWANK-BACKEND does not exist.

[Pierre Neidhardt]

I've also reported the issue at https://github.com/slime/slime/issues/457.

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


signature.asc
Description: PGP signature

Re: Guix on aarch64

[Ludovic Courtès]

Hello Mark,

Mark H Weaver  skribis:

> If I'm not mistaken, I believe I have confirmed with the test below that
> a substitute for binutils from early commencement on aarch64 is not
> available on berlin.

[...]

> It occurs to me that on Hydra, I have implemented a system to ensure
> that *all* derivations from a certain set of _evaluations_ (the most
> recent release and the last two weeks of 'master' evaluations) are
> permanently kept as GC roots, regardless of how long ago they were
> built.  Among other things, this ensures that even the early
> commencement derivations are kept even if they were built a long time
> ago.
>
> Berlin.guixsd.org may not have any similar mechanism in place.  It may
> still be using the old policy, where old GC roots are deleted based
> solely on their timestamps in the filesystem, which indicate when the GC
> root symlinks were first installed, long ago during the last core
> updates build-out.  This could result in the early commencement
> derivations and corresponding outputs being deleted prematurely.

Correct.  Berlin uses ‘guix publish’ with a TTL of 45 days: if a nar is
not requested within 45 days, and if its corresponding store item was
GC’d in the meantime, it disappears.

I think there are two problems that made that happen: our two aarch64
build machines have been offline for several weeks so nothing new gets
built, and aarch64 substitutes are probably unpopular and thus more
likely to disappear given the above policy.

We’ll probably need a mechanism similar to what Hydra and you are doing
on hydra.gnu.org, to explicitly retain derivations from certain
evaluations; we can implement that in Cuirass.

In addition, Ricardo has a plan to throw more storage at berlin (we
currently have 1TB for the store).  That would allow us to increase the
TTL and generally worry less, though it’s no substitute for the GC root
mechanism above.

(That said, the error Benjamin reported appears to be a build failure,
which is surely worth investigating in its own right.)

Thanks,
Ludo’.

Re: Graft hooks

[Ludovic Courtès]

Hello Timothy,

Timothy Sample  skribis:

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

[...]

 I agree that this would be the right thing to do!  (I’d really like to
 do it for GDB as discussed in .)

 Package properties would be the right way to make it extensible, but
 there are complications (notably we’d need to use gexps, but build
 systems don’t use gexps yet.)
>>>
>>> But soon, right?  ;)
>>
>> Well, it’s complicated.  :-)
>>
>> Also, I realized that some things, like the .gnu_debuglink and build-id
>> hooks, don’t really fit in any package; they’re transverse.
>
> You’re right.  Packages are the wrong place.  What about build systems?
> Maybe it makes sense (theoretically) to define graft hooks in build
> systems, and then modify them (if necessary) using the “arguments” field
> of a package.  Isn’t it the GNU or Go build systems that are ultimately
> responsible for these checksums?  Shouldn’t it be their job to tell the
> grafting code how to fix them?

It’s not completely clearcut.  For instance, the GCC toolchain can
produce .gnu_debuglink and build-IDs, but the GCC toolchain and
‘gnu-build-system’ are not the only one doing so: ‘guile-build-system’,
‘go-build-system’, etc. could do that as well.  So .gnu_debuglink and
build-IDs are an example of something that doesn’t “belong” to any
single package or build system, I think.

[...]

>> Regarding timestamps: I guess there’s no problem since timestamps are
>> reset in the store.
>
> Whoops!  I didn’t mean the file metadata, I meant in the bytecode files
> themselves.  Also, I only saw the changes in diffoscope and assumed they
> were timestamps.  I looked more closely and realized they were more
> checksums that I didn’t notice before (it should have been obvious
> because they are 20 bytes...).  They are supposed to be updated.
> Nothing to see here.  :)

OK.  :-)

> Following my note above, I think I will try and finish my update code in
> Guile, and then use the existence of “share/racket” as the heuristic to
> determine if it should run.
>
> Maybe I will package a Racket library, too, so I can test it.

Great, thank you!

Ludo’.

GNU Guix Days before FOSDEM

[Ludovic Courtès]

Hello!

Pjotr Prins  skribis:

> If you intend to come and/or want to speak please add your name and
> proposed title to the new page at
>
>   https://libreplanet.org/wiki/Group:Guix/FOSDEM2018
>
> Alternatively, reply here or mail me privately so we can keep a tally.

The real URL is:

  https://libreplanet.org/wiki/Group:Guix/FOSDEM2019#GNU_Guix_Days

I copied and adjusted the text from last year’s page.

Anyway, feel free to add your name if you would come, and ideas of talks
or hacking sessions we may have, so we can start planning!

Thanks,
Ludo’.

Re: FOSDEM 2019 (ACTION: please register or mail)

[Jonathan Brielmaier]

On 8/24/18 11:23 AM, Pjotr Prins wrote:
> Who wants to come to a separate 2 day GNU Guix event?
> 
> That is the Thursday Jan 31st and/or Friday Feb 1st right before
> FOSDEM. I.e., 4 days of hacker nirvana.
> 
> FOSDEM is really great. Look at last year's schedule for Saturday
> 
>   https://archive.fosdem.org/2018/schedule/day/saturday/
> 
> Last year we had a 1 day event with about 25 people before FOSDEM.
> See
> 
>   https://libreplanet.org/wiki/Group:Guix/FOSDEM2018
> 
> If you intend to come and/or want to speak please add your name and
> proposed title to the new page at
> 
>   https://libreplanet.org/wiki/Group:Guix/FOSDEM2018

The new link is apparently:
https://libreplanet.org/wiki/Group:Guix/FOSDEM2019

Re: Graft hooks

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Since this is used when grafting Racket, I would suggest moving this
>> graft to the “build side” entirely, similar to what I did in
>> .  Probably
>> you’d just add a single procedure to (guix build graft) and add it to
>> %graft-hooks.
>>
>> That procedure could be the same as what you have above, except that
>> it’d run OUT/bin/raco, if it exists, and do nothing if OUT/bin/raco does
>> not exist.
>>
>> WDYT?
>
> I think it would be quite unfortunate if _every_ graft had to run
> _every_ graft hook, or if every graft hook had to be defined in
> (guix grafts) and/or (guix build graft).
>
> It's reasonable to have a few global graft hooks, e.g. for handling
> debugging information, but I would greatly prefer for Guix to also have
> a mechanism allowing individual packages or build systems to introduce
> graft hooks without modifying (guix grafts) or (guix build graft), and
> for such a mechanism to be used for Racket and its libraries.

Sure, like I wrote, a more extensible solution along the lines of what
Timothy and you suggest sounds better long-term.  It just happens to be
harder to implement today (in particular until ‘wip-build-systems-gexp’
is merged), and not entirely clear how this could work, as discussed
with Timothy.

That’s why I’m proposing the simple approach for now.  I think we can
revisit the issue if/when we have graft hooks tied to a particular
package or build system.

Note that the .gnu_debuglink hook in  runs
only when there’s a “debug” output, and the Racket hook that Timothy
proposes would only run when Racket is available.  So you get extra
run-time overhead only if there’s something to do.

HTH,
Ludo’.

Re: FOSDEM 2019 (ACTION: please register or mail)

[Ricardo Wurmus]

Pjotr Prins  writes:

> Who wants to come to a separate 2 day GNU Guix event?
>
> That is the Thursday Jan 31st and/or Friday Feb 1st right before
> FOSDEM. I.e., 4 days of hacker nirvana.

I plan to be there for the 2 days of Guix and the 2 FOSDEM days.

Please also let us know (privately, if you prefer) if your attendance
would be dependent on having on-site childcare.

--
Ricardo

Re: Bootstrap Tarballs for alpha-linux Targets

[Ludovic Courtès]

Hi,

Vincent Weisner  skribis:

> No additional patches were needed and no, I don't have any DEC Alpha hardware.

OK.

> If you rather not include an Alpha port, then why does the code state 
> "alpha-linux" in /gnu/packages/bootstrapping.scm?

That’s because somebody else tried cross-compiling to Alpha some time
ago; it was Sergei Trofimovich, and IIRC Sergei did have Alpha hardware
at the time.  :-)

Ludo’.

Re: FOSDEM 2019 (ACTION: please register or mail)

[alex sassmannshausen]

I'm in.

On Fri, 24 Aug 2018, 11:23 Pjotr Prins,  wrote:

> Who wants to come to a separate 2 day GNU Guix event?
>
> That is the Thursday Jan 31st and/or Friday Feb 1st right before
> FOSDEM. I.e., 4 days of hacker nirvana.
>
> FOSDEM is really great. Look at last year's schedule for Saturday
>
>   https://archive.fosdem.org/2018/schedule/day/saturday/
>
> Last year we had a 1 day event with about 25 people before FOSDEM.
> See
>
>   https://libreplanet.org/wiki/Group:Guix/FOSDEM2018
>
> If you intend to come and/or want to speak please add your name and
> proposed title to the new page at
>
>   https://libreplanet.org/wiki/Group:Guix/FOSDEM2018
>
> Alternatively, reply here or mail me privately so we can keep a tally.
>
> Please do so because we need to find a venue again on a first come
> first go basis if we run out of seats.
>
> Pj.
>
> On Tue, Aug 21, 2018 at 04:33:53PM +0300, Manolis Ragkousis wrote:
> > Hello everyone,
> >
> > It's that time of the year again we need to start organizing about
> > FOSDEM. We have a deadline for the 20th of September[1] to apply for a
> > devroom. We also need to start looking for a place for this year's
> > fringe event!
>

Re: FOSDEM 2019 (ACTION: please register or mail)

[Pjotr Prins]

Who wants to come to a separate 2 day GNU Guix event?

That is the Thursday Jan 31st and/or Friday Feb 1st right before
FOSDEM. I.e., 4 days of hacker nirvana.

FOSDEM is really great. Look at last year's schedule for Saturday

  https://archive.fosdem.org/2018/schedule/day/saturday/

Last year we had a 1 day event with about 25 people before FOSDEM.
See

  https://libreplanet.org/wiki/Group:Guix/FOSDEM2018

If you intend to come and/or want to speak please add your name and
proposed title to the new page at

  https://libreplanet.org/wiki/Group:Guix/FOSDEM2018

Alternatively, reply here or mail me privately so we can keep a tally.

Please do so because we need to find a venue again on a first come
first go basis if we run out of seats.

Pj.

On Tue, Aug 21, 2018 at 04:33:53PM +0300, Manolis Ragkousis wrote:
> Hello everyone,
> 
> It's that time of the year again we need to start organizing about
> FOSDEM. We have a deadline for the 20th of September[1] to apply for a
> devroom. We also need to start looking for a place for this year's
> fringe event!