Re: question regarding substitute* and #t

[Andy Wingo]

On Thu 25 Jan 2018 06:31, Maxim Cournoyer  writes:

> Where does this `invoke' comes from? Geiser is unhelpful at finding it,
> and it doesn't seem to be documented in the Guile Reference?

https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00163.html

Re: question regarding substitute* and #t

[Maxim Cournoyer]

Andy Wingo  writes:

> On Wed 24 Jan 2018 14:28, Mark H Weaver  writes:
>
>> Andy Wingo  writes:
>>
>>> On Wed 24 Jan 2018 13:06, Mark H Weaver  writes:
>>>
 + ;; Install to the right directory
 + (substitute* '("Makefile"
 +"Qsci/Makefile")
 +   (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
 +(assoc-ref outputs "out")))
 + #t)
>>>
>>> I guess once we switch over all instances of "system" and "system*" to
>>> use invoke, does that mean we will also be able to remove these
>>> vestigial "#t" returns?
>>
>> After we switch to using 'invoke' everywhere, or more precisely, after
>> we arrange to never return #false from any phase or snippet, then there
>> should be one more step before removing the vestigial #true returns: we
>> should change the code that calls phases or snippets to ignore the
>> value(s) returned by those procedures.  When that is done, then the #t's
>> will truly be vestigial.  Does that make sense?
>
> Sure, makes sense.  Thanks for thinking it through with me :)
>
> Andy

Where does this `invoke' comes from? Geiser is unhelpful at finding it,
and it doesn't seem to be documented in the Guile Reference?

Thanks,

Maxim

Re: weird errors; shepherd

[Ludovic Courtès]

Danny Milosavljevic  skribis:

> On Wed, 24 Jan 2018 15:47:16 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> I’m not sure what you mean.  There’s no notion of dependencies among
>> activation snippets, let alone between activation snippets and service
>> starts (when booting, activation snippets run *before* shepherd is
>> started).  Perhaps there’s a misunderstanding here?
>
> Yeah, if it's intended that way, that's fine.  So it's like /etc/rc.local
> and it just runs the snippets in any order?

Yes.

> Now, I just do both the trytond DB-upgrading and the service starting at the
> "start" action because postgres isn't running yet otherwise.

That’s the right thing to do if you need ordering.

>> >   As far as I understand make-forkexec-constructor takes special care not
>> >   to kill stderr.  As long there's no log-file specified it should leave 
>> > stdout
>> >   and stderr alone.  So where does the text go?  
>> 
>> To PID 1’s stdout/stderr, i.e., /dev/console (which sucks).
>
> Really?  I don't see it in the marionette os output (for make check-system) - 

When running “make check-system”, you see the console (which is
redirected to the host’s qemu stdout), like this:

--8<---cut here---start->8---
$ make check-system TESTS=basic

[...]

[0.511024] Freeing unused kernel memory: 308K
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
Welcome, this is GNU's early boot Guile.
Use '--repl' for an initrd REPL.

loading kernel modules...

[...]

adding group 'input'...
adding group 'video'...
adding group 'audio'...
adding group 'netdev'...
adding group 'lp'...
adding group 'disk'...
adding group 'floppy'...

[...]

Service udev has been started.
Service urandom-seed has been started.
Service user-processes has been started.
Service host-name has been started.
Service user-homes could not be started.
nscd: 279 monitoring file `/etc/hosts` (1)
nscd: 279 monitoring directory `/etc` (2)
nscd: 279 monitoring file `/etc/resolv.conf` (3)
nscd: 279 monitoring directory `/etc` (2)
nscd: 279 monitoring file `/etc/services` (4)
nscd: 279 monitoring directory `/etc` (2)
Service nscd has been started.

[...]

Written by Mike Haertel and others, see 
.
+ info --version
info (GNU texinfo) 6.3

Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
shepherd: Service user-homes could not be started.
QEMU runs as PID 6
connected to QEMU's monitor
read QEMU monitor prompt
connected to guest REPL
 Starting test basic  (Writing full log to "basic.log")
marionette is ready

;;; (services (user-processes loopback term-tty2 udev console-font-tty2 
term-tty3 term-tty1 console-font-tty6 urandom-seed file-system-/dev/shm 
console-font-tty5 console-font-tty1 guix-daemon host-name file-system-/dev/pts 
user-file-systems root term-tty4 file-systems user-homes root-file-system nscd 
marionette syslogd term-tty6 term-tty5 console-font-tty4 console-font-tty3))
# of expected passes  19
@ build-succeeded /gnu/store/xab6i89lf15rab8ipy78rkj4218dzjvd-basic.drv -
TOTAL: 1
PASS: /gnu/store/hazdppnr6cd1dhqnbjhyj44yb6xcfpnf-basic
--8<---cut here---end--->8---

Here you see the output of ‘useradd’, shepherd itself, nscd, marionette,
etc.  All this is /dev/console.

> Also tried
> (marionette-eval '(current-output-port
>  (open-file "/dev/console" 
> "w0"))
> 
> marionette)
> (marionette-eval '(current-error-port
>  (open-file "/dev/console" 
> "w0"))
> 
> marionette)

This shouldn’t be necessary, but it would change the error port for the
marionette process itself.

>> That’s inconvenient but “expected” in the sense that the ‘start’ method
>> is called right from shepherd.conf.  Perhaps we should call ‘start’ at a
>> later stage.
>
> Well, as it is it makes the system very brittle.
>
> Once one service does that... oops.

Yeah, but then again we test services in a VM beforehand.  :-)
Also, using (error "xxx") is frowned upon because it raises an exception
that cannot usefully be handled.

Ludo’.

Re: question regarding substitute* and #t

[Ricardo Wurmus]

Andy Wingo  writes:

>> I wonder why substitute* not simply returns #t?!
>
> There was a proposal to make it return #t!  However then someone pointed
> out that actually instead of making phases return boolean results, we
> should instead signal problems via exceptions, and that drove the shift
> from system / system* to invoke.  In the future world where completion
> means success, it doesn't matter what substitute* returns.

There is also the question what it means for substitute* to fail.  Does
it fail when one of the substitutions couldn’t be performed in one of
the files?  Or does it only fail when no substitutions succeeded?  Or
something in between?

I’m sure we have a bunch of places in package definitions where old
substitions actually no longer apply to current versions of the sources.
Cleaning this up will take quite some time.

(I think that it would be helpful if substitute* failed when any
substitution failed, but this would make some shortcuts impossible.)

--
Ricardo

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

Cuirass news

[Ludovic Courtès]

Hello Guix!

Over the last few days, out of frustration ;-), I hacked Cuirass to
improve several things:

  • Logging is improved: useful events are logged, including build
started/succeeded/failed (using a variant of what I proposed in the
Guix ‘wip-ui’ branch).  This makes it much easier to understand
what’s going on!

  • Concurrency: the evaluate/build cycle would previously happen
sequentially.  This was bad for latency (it could take a while
before we would pull from the repo) and for resource usage (while
evaluating all the build machines would be idle).  Now there’s some
concurrency, with a switch to Fibers (yay!), which means that these
activities can be interleaved, as well as HTTP request processing.

  • Build status: the starttime/stoptime of a ‘Build’ entry in the
database is now accurate since we set them once the build has
actually started/stopped.  This means the database is updated as
soon as a build finishes, rather than when the whole
‘build-derivations’ RPC has returned.  We can also distinguish
between started and scheduled builds now.

  • HTTP API: as a corollary, /api/latestbuilds now really returns the
latest builds.  There’s a new /api/queue that returns pending
builds—builds that have a database entry with ‘status’ < 0.

  • Restarting unfinished builds: it’s common, especially when testing,
to interrupt Cuirass, leaving a number of builds unfinished or not
even started.  Now Cuirass restarts those upon startup.

And!  This brings a whole set of new bugs that I’m hunting notably on
berlin (which may thus lag behind…).  Overall I think it’ll make Cuirass
easier to work with and more “introspectable”.

Feedback welcome!

Ludo’.

neomutt package maintenance

[ng0]

Just a heads-up message:

I've (probably) switched clients for good now, and I am no longer
using neomutt. I don't have the time to deliver a timely
appropriate update of our neomutt package. I've seen some of us
developers using it (or originating from other distros the
package?). It would be good if you'd cherry pick the changes from
here: https://c.n0.is/ng0/guix/guix/log/?h=package/neomutt20171215

and unbundle autosetup. neomutt provided some notes for the
switch, but they can also be found in #neomutt on
ircs://freenode.net if you have questions.

Afterwards it will be easy to update neomutt again. It already is
now, but their switch of the buildsystem part came at the wrong
time.
-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/


signature.asc
Description: PGP signature

Re: question regarding substitute* and #t

[Kei Kebreau]

Andy Wingo  writes:

> On Wed 24 Jan 2018 14:28, Mark H Weaver  writes:
>
>> Andy Wingo  writes:
>>
>>> On Wed 24 Jan 2018 13:06, Mark H Weaver  writes:
>>>
 + ;; Install to the right directory
 + (substitute* '("Makefile"
 +"Qsci/Makefile")
 +   (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
 +(assoc-ref outputs "out")))
 + #t)
>>>
>>> I guess once we switch over all instances of "system" and "system*" to
>>> use invoke, does that mean we will also be able to remove these
>>> vestigial "#t" returns?
>>
>> After we switch to using 'invoke' everywhere, or more precisely, after
>> we arrange to never return #false from any phase or snippet, then there
>> should be one more step before removing the vestigial #true returns: we
>> should change the code that calls phases or snippets to ignore the
>> value(s) returned by those procedures.  When that is done, then the #t's
>> will truly be vestigial.  Does that make sense?
>
> Sure, makes sense.  Thanks for thinking it through with me :)
>
> Andy

Thanks to you both for this thread!


signature.asc
Description: PGP signature

Re: GuixSD on Olimex A20 OLinuXino?

[Ludovic Courtès]

Hello,

Danny Milosavljevic  skribis:

>> I have one of these (maybe not the “LIME”, but does it make a
>> difference?).  
>
> Yes, it makes a difference (in U-Boot only).
>
> Which one do you have? There's MICRO, LIME, LIME2 and additional
> variants with eMMC and without eMMC.

It’s the MICRO.

> Most of these should already have entries in
> gnu/system/install.scm .  If not, one can easily add one
> (add entry to gnu/bootloader/u-boot.scm, inheriting from allwinner-bootloader,
> and then add entry to gnu/system/install.scm using it)

OK.

>> How should I proceed?  Is it enough to dump this on
>> microSD and boot?
>
> Yes.

Awesome.  :-)

I guess I’ll give it a try probably after FOSDEM.  Really crazy that
GuixSD on ARM “just works”!

Ludo’.

Re: Guix Workflow Language ?

[Roel Janssen]

Dear Zimoun,

zimoun writes:

> Dear,
>
> Thank you to provide a workflow manager!
> It is fun. :-)

Thanks for looking at the GWL.

>
> I am currently investigating to describe basic and simple workflows.
> And there is a couple of solutions, from python-oriented Snakemake
> with Conda capabilities to Common Workflow Language or Workflow
> Description Language.
>
> https://snakemake.readthedocs.io/en/latest/
> http://www.commonwl.org
> https://software.broadinstitute.org/wdl/
>
> And there is already some pipelines elsewhere, e.g.,
> https://view.commonwl.org/workflows?search=rnaseq
> https://github.com/UMCUGenetics/GGR-cwl

Here's an example of a GWL workflow:
https://github.com/UMCUGenetics/gwl-atacseq

> Moreover, some hyper-specialised and classical genomics pipelines are
> also available elsewhere, e.g.,
> http://bioinformatics.mdc-berlin.de/pigx/
>
>
> Well, my question is: does it appear to you reasonable to write a
> front-end for CWL ?
>
>
> Because it seems hard to have some room in this landscape, even if I
> think that the Guix-way is the most scientific (reproducible, open,
> etc.).
> I mean, there is room for a guix-backend engine (another CWL
> implementation), I guess.

The way I see it, there are two ways to go about this:

1. Make workflows written in GWL (in Scheme) run on a CWL execution
engine.  So basically, produce a YAML file adhering to the CWL spec.

This way we can, at the very least, convert GWL workflows to CWL
workflows -- producing wide compatibility for workflow execution.

This is doable, as long as we put some limitations on the GWL workflow.
It has to have clearly defined 'inputs' and 'outputs', and we probably
have to generate a Docker container with the software dependencies.

2. Let CWL workflows run on top of GWL.  I think this is a lot harder,
because the software deployment is unclear.

>
> So, during a raining week-end, I gave a look to the specs of CWL and
> why not start by define a subset, but then I have failed to write a
> parser of it in Guile.
>
>
> Hum? another question: does it exist an easy-to-use Guile library for
> parsing YAML-like files ?
>
>
> I have found Racket ones, but it was not clear to me how to do with
> Guile (without reinventing the wheel).
>
>
> What do you think about feeding GWL engine by CWL pipeline ?

I am not sure what you mean by this.  Do you mean, run a CWL workflow
using the GWL?  Then my question would be:  Where does the software come
from?  Guix, or some other package manager?  What would the added
benefit of GWL be?

> Thank you for any advice.
>
> All the best,
> simon

Thanks for your interest!

Kind regards,
Roel Janssen

Re: weird errors; shepherd

[Danny Milosavljevic]

Hi Ludo,

On Wed, 24 Jan 2018 15:47:16 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> I’m not sure what you mean.  There’s no notion of dependencies among
> activation snippets, let alone between activation snippets and service
> starts (when booting, activation snippets run *before* shepherd is
> started).  Perhaps there’s a misunderstanding here?

Yeah, if it's intended that way, that's fine.  So it's like /etc/rc.local
and it just runs the snippets in any order?

Now, I just do both the trytond DB-upgrading and the service starting at the
"start" action because postgres isn't running yet otherwise.

> >   As far as I understand make-forkexec-constructor takes special care not
> >   to kill stderr.  As long there's no log-file specified it should leave 
> > stdout
> >   and stderr alone.  So where does the text go?  
> 
> To PID 1’s stdout/stderr, i.e., /dev/console (which sucks).

Really?  I don't see it in the marionette os output (for make check-system) - 
I just tried it again, stdout is nowhere to be seen with check-system.
(I just put a program-file as shepherd start action and called "display" there)

Also tried
(marionette-eval '(current-output-port
 (open-file "/dev/console" 
"w0"))

marionette)
(marionette-eval '(current-error-port
 (open-file "/dev/console" 
"w0"))

marionette)

but that didn't change anything either...

> > I've had other problems like:
> >
> > * root's shepherd hangs sometimes and herd can't connect to it anymore.  
> 
> That’s a serious bug.  Can you reproduce it?

I'll try.

> That’s inconvenient but “expected” in the sense that the ‘start’ method
> is called right from shepherd.conf.  Perhaps we should call ‘start’ at a
> later stage.

Well, as it is it makes the system very brittle.

Once one service does that... oops.

Re: [RFC] A simple draft for channels

[Ricardo Wurmus]

myg...@gmail.com writes:

> Ricardo, AIUI, your channels don't work like this. But I am at a loss to
> say how they will work in practice from the user's POV. If you could
> write such a description it would sure help us understand the proposal
> better.

This draft is similar to how Conda channels[1] work:

Conda packages are downloaded from remote channels, which are URLs
to directories containing conda packages. The conda command searches
a default set of channels, and packages are automatically downloaded
and updated from http://repo.continuum.io/pkgs/. You can modify what
remote channels are automatically searched. You might want to do
this to maintain a private or internal channel.

[1]: https://conda.io/docs/user-guide/concepts.html#conda-packages

In our case a channel consists of a git repository with Guile module
definitions and a channel description file.  Optionally, it points to a
URL from where substitutes can be fetched.

Other than that it behaves like a Conda user would expect:

   “Guix does not yet include ‘foolicious 2000’, but I know it has been
packaged by someone else and made available on the
‘garlic-onion-sweat’ channel.  So I enable this channel, authorize
its public key, and then install ‘foolicious 2000’.”

Users can add any number of channels; their modules will be downloaded
and built (TODO: this might be dangerous, so try sandboxing), and then
added to GUIX_PACKAGE_PATH.

The second iteration of this would involve some potluck ideas for extra
safety and convenience.

--
Ricardo

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

Re: GuixSD on Olimex A20 OLinuXino?

[Danny Milosavljevic]

> Most of these should already have entries in
> gnu/system/install.scm .  If not, one can easily add one
> (add entry to gnu/bootloader/u-boot.scm, inheriting from allwinner-bootloader,
> and then add entry to gnu/system/install.scm using it)

Oh yeah, and a bootloader package into gnu/packages/bootloader.scm .

if you don't know the make-u-boot-package parameter, just guess it
wrong - you'll get a list.

Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags.

[Adam Van Ymeren]

n...@n0.is writes:

>
> Out of curiosity: Where do you use gnURL in the system? For
> normal user experience it was never intended (though it would
> work). It would be nice to know if another project depends on it,
> as we've started looking into wget2 as a successor to cURL for
> GNUnet.

I don't actually use it directly, but it's an input for gnunet which I
like to play with from time to time, so I need gnurl to build for gnunet
to build.

>
>> I think an env. variable solution makes sense.  We already have
>> machinery for this in place with how packages can provide "search paths"
>> for other environment variables.  Perhaps the same should be applied to
>> SSL certificates.
>
> https://curl.haxx.se/docs/sslcerts.html what applies is this +
> some grepping through the cURL source and reading it.
>
> probably useful TIL of this whole issue: cURL could suffer the
> same issue if we try this, and I need to test all the options.

I think the patch you did of setting
--with-ca-bundle=/etc/ssl/certs/ca-certificates.crt is reasonable as it
lets gnURL use the operating system level cert store..

I think the root problem is that the gnURL tests the gnURL/cURL tests
are not self contained and depend upon this setting rather for tests
rather than using an embedded cert store during testing.

>
>> Referencing some file on the root filesystem does not feel very
>> functional to me.  That becomes system specific mutable state, which
>> certainly shouldn't be an input to the build/test process.  For the
>> purposes of the test, gnurl should be providing an embedded certificate
>> store inside its own package that it runs tests against, otherwise the
>> tests are going to be prone to flaky failure like this.
>
> That really is a cURL specific bug though. I wouldn't mind
> extending gnURL where it makes sense, but due to the high speed
> chase with cURL it is difficult.

Yes this is definitely a bug with upstream cURL tests, and a fix for
that should be submitted upstream if anyone makes one.

>
>> If we want to refernce /etc/ssl/certs for use on non GuixSD distros,
>> then I think we should make sure that that directory is populated on
>> startup from the operating system profile on activation.
>
> ... with the only problem that operating-system profile
> activation does not exist (yet ;)?) for other systems, iirc.

I may not have been clear.  I meant if we want to have gnURL reference
this directory so that it works nicely on non GuixSD systems, then we
should also make sure that it _is_ provided on GuixSD systems.  And I
think it should be provided on GuixSD at operating system activation
time, so it remains a part of the purely functional system rather than
some mutable state that could get out of date or corrupted.

>> It's pretty concerning that we're getting different results for building
>> gnurl, such a thing should be impossible or at least incredibly rare
>> with a purely function package manager.
>>
>> Checking hydra.gnu.org, gnurl is failing there as well for i686 and
>> x86_64 but for different reasons.  It's failing because unbound is
>> failing which is an input to gnutls-dane which is an input to gnurl.
>>
>> https://hydra.gnu.org/build/2453496
>
> Damn. I'll look into it as soon (or slow) as I can. Time is
> limited atm.

No rush, I can work around it for now :).  Thanks for your hard work
maintaining this.

>
> Thanks for your reply so far. I'll also look into spinning up
> some addition gitlab CI jobs to see if I can replicate what we
> encountered.
> We don't have GuixSD runners yet, but some people on our side are
> working on it.
>
> If you have more, like build logs etc would you like to send them
> in here, open a bug on our (GNUnet) Mantis instance or send them
> to the gnunet bugs list?

I've attached a build log to this message in case it helps :).



yp9k0ykw5phh6w9i3cwms2mhjlgswl-gnurl-7.57.0.drv.bz2
Description: log of guix build gnurl

Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags.

[ng0]

On Wed, 24 Jan 2018, Adam Van Ymeren  wrote:
> n...@n0.is writes:
>
>>> The problem I'm trying to address is the same horror story we
>>> have with cURL: We need to be able to reference a certificate
>>> store.
>>> So far no one in 2+ years fixed this in our cURL to my best
>>> knowledge, so my idea as a maintainer of gnURL was to simply
>>> apply this to gnURL because someone in GNUnet reported errors
>>> with regards to gnURL not finding the certificates with a recent
>>> build of gnURL. I though I had this fixed a while ago, but
>>> apparently I didn't.
>>> I'm more than open to better fixes (we could also set the
>>> expected environment variable).
>>
>> Another path forward I see is that I recommend every distro
>> to set this path for themselves. We haven't fixed the Guix
>> and GuixSD issue with this, but that's something I need to
>> adjust for the upcoming release.
>>
>>
 I guess we want to be able to to change what certificates that gnurl
 accepts without rebulding the package, but I think we need something to
 provide that file when building the package in the first place, or
>>>
>>> What you seem to want is the env. variable solution.
>
> All I really want is to be able to update my system ;).

Out of curiosity: Where do you use gnURL in the system? For
normal user experience it was never intended (though it would
work). It would be nice to know if another project depends on it,
as we've started looking into wget2 as a successor to cURL for
GNUnet.

Not that we make it obsolete and people really use it. I have no
problem with long-term maintenance.

> I think an env. variable solution makes sense.  We already have
> machinery for this in place with how packages can provide "search paths"
> for other environment variables.  Perhaps the same should be applied to
> SSL certificates.

https://curl.haxx.se/docs/sslcerts.html what applies is this +
some grepping through the cURL source and reading it.

probably useful TIL of this whole issue: cURL could suffer the
same issue if we try this, and I need to test all the options.

> Referencing some file on the root filesystem does not feel very
> functional to me.  That becomes system specific mutable state, which
> certainly shouldn't be an input to the build/test process.  For the
> purposes of the test, gnurl should be providing an embedded certificate
> store inside its own package that it runs tests against, otherwise the
> tests are going to be prone to flaky failure like this.

That really is a cURL specific bug though. I wouldn't mind
extending gnURL where it makes sense, but due to the high speed
chase with cURL it is difficult.

> If we want to refernce /etc/ssl/certs for use on non GuixSD distros,
> then I think we should make sure that that directory is populated on
> startup from the operating system profile on activation.

... with the only problem that operating-system profile
activation does not exist (yet ;)?) for other systems, iirc.

>>> May I ask what system you are building on? I have a GuixSD-only
>>> setup here. Next time I'll wait for the CI to finish building
>>> (Debian based). I'm in the middle of releasing gnURL 7.58.0 and
>>> preparing for a test that I have tomorrow, followed by some
>>> social appointments afterwards, so I'll be able to start working
>>> on a real fix on the weekend.
>
> I'm building on GuixSD only as well.  I'm building from a git checkouts
> with a few local changes to add/update packages I'm working on
> (strongswan/python-axolotl) neither of which I believe are inputs to
> gnurl.

Nope, they aren't. Hm. Curious.

> It's pretty concerning that we're getting different results for building
> gnurl, such a thing should be impossible or at least incredibly rare
> with a purely function package manager.
>
> Checking hydra.gnu.org, gnurl is failing there as well for i686 and
> x86_64 but for different reasons.  It's failing because unbound is
> failing which is an input to gnutls-dane which is an input to gnurl.
>
> https://hydra.gnu.org/build/2453496

Damn. I'll look into it as soon (or slow) as I can. Time is
limited atm.

Thanks for your reply so far. I'll also look into spinning up
some addition gitlab CI jobs to see if I can replicate what we
encountered.
We don't have GuixSD runners yet, but some people on our side are
working on it.

If you have more, like build logs etc would you like to send them
in here, open a bug on our (GNUnet) Mantis instance or send them
to the gnunet bugs list?

Thanks!
>>>
>>> In the meantime you could send a patch to revert my commit.

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

Re: [RFC] A simple draft for channels

[myglc2]

On 01/24/2018 at 15:08 Ludovic Courtès writes:

> Hello,
>
> iyzs...@member.fsf.org (宋文武) skribis:
>
>> Ricardo Wurmus  writes:
>>
>>> Hi Guix,
>>>
>>> I’d like to retire GUIX_PACKAGE_PATH as the main way to get third-party
>>> packages, because we can’t really keep track of packages that were added
>>> or redefined in this way.  I want to replace it with slightly more
>>> formal “channels”.
>>
>> Hello, as a way to get and manage third-party guix repositories, it
>> sounds more like “overlays” (in Gentoo world) rather than “channels” (in
>> Nix world, to ensure binaries availability and updates stability) to me.
>>
>> https://wiki.gentoo.org/wiki/Overlay
>> https://nixos.org/nix/manual/index.html#sec-channels
>>
>> How about call it as “overlay”?

> I think “overlay” has the notion that it’s a layer on top of another
> layer, which is not exactly the case here.  It’s not exactly like what
> Nix channels either, but closer to that, I think.

Because Nix is not well known and their definition[1] is obscure I
looked for mainstream uses of "channels". I found Chrome "Release
Channels"[2] and Red Hat Network Satellite "Channels"[3,4]. A Chrome
user can use only one channel at a time, e.g., Stable, Beta,
Developer. The Red Hat model is more complex:

CHANNEL
A channel is a list of packages. Channels are used to choose packages to
be installed from client systems. Every client system must be subscribed
to one Base Channel and can be subscribed to one or more Child Channel .

BASE CHANNEL
A base channel is a type of Channel that consists of a list of packages
based on a specific architecture and Red Hat release. For example, all
the packages in Red Hat Enterprise Linux AS 3 for the x86 architecture
make a base channel.

CHILD CHANNEL
A child channel is a Channel associated with a Base Channel but contains
extra packages.

Ricardo, AIUI, your channels don't work like this. But I am at a loss to
say how they will work in practice from the user's POV. If you could
write such a description it would sure help us understand the proposal
better.

[1] https://nixos.org/nix/manual/#sec-channels:

"A Nix channel is just a URL that points to a place that contains a
set of Nix expressions and a manifest."

[2] https://www.chromium.org/getting-involved/dev-channel

[3]
https://access.redhat.com/documentation/en-us/red_hat_network_satellite/5.3/html/reference_guide/glossary

[4] 
https://access.redhat.com/documentation/en-us/red_hat_network_satellite/5.3/html/reference_guide/s1-sm-channels-packages

Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags.

[Adam Van Ymeren]

n...@n0.is writes:

>> The problem I'm trying to address is the same horror story we
>> have with cURL: We need to be able to reference a certificate
>> store.
>> So far no one in 2+ years fixed this in our cURL to my best
>> knowledge, so my idea as a maintainer of gnURL was to simply
>> apply this to gnURL because someone in GNUnet reported errors
>> with regards to gnURL not finding the certificates with a recent
>> build of gnURL. I though I had this fixed a while ago, but
>> apparently I didn't.
>> I'm more than open to better fixes (we could also set the
>> expected environment variable).
>
> Another path forward I see is that I recommend every distro
> to set this path for themselves. We haven't fixed the Guix
> and GuixSD issue with this, but that's something I need to
> adjust for the upcoming release.
>
>
>>> I guess we want to be able to to change what certificates that gnurl
>>> accepts without rebulding the package, but I think we need something to
>>> provide that file when building the package in the first place, or
>>
>> What you seem to want is the env. variable solution.

All I really want is to be able to update my system ;).

I think an env. variable solution makes sense.  We already have
machinery for this in place with how packages can provide "search paths"
for other environment variables.  Perhaps the same should be applied to
SSL certificates.

Referencing some file on the root filesystem does not feel very
functional to me.  That becomes system specific mutable state, which
certainly shouldn't be an input to the build/test process.  For the
purposes of the test, gnurl should be providing an embedded certificate
store inside its own package that it runs tests against, otherwise the
tests are going to be prone to flaky failure like this.

If we want to refernce /etc/ssl/certs for use on non GuixSD distros,
then I think we should make sure that that directory is populated on
startup from the operating system profile on activation.

>> May I ask what system you are building on? I have a GuixSD-only
>> setup here. Next time I'll wait for the CI to finish building
>> (Debian based). I'm in the middle of releasing gnURL 7.58.0 and
>> preparing for a test that I have tomorrow, followed by some
>> social appointments afterwards, so I'll be able to start working
>> on a real fix on the weekend.

I'm building on GuixSD only as well.  I'm building from a git checkouts
with a few local changes to add/update packages I'm working on
(strongswan/python-axolotl) neither of which I believe are inputs to
gnurl.

It's pretty concerning that we're getting different results for building
gnurl, such a thing should be impossible or at least incredibly rare
with a purely function package manager.

Checking hydra.gnu.org, gnurl is failing there as well for i686 and
x86_64 but for different reasons.  It's failing because unbound is
failing which is an input to gnutls-dane which is an input to gnurl.

https://hydra.gnu.org/build/2453496



>>
>> In the meantime you could send a patch to revert my commit.
>
> -- 
> ng0 :: https://ea.n0.is
> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags.

[Adam Van Ymeren]

n...@n0.is writes:

>> The problem I'm trying to address is the same horror story we
>> have with cURL: We need to be able to reference a certificate
>> store.
>> So far no one in 2+ years fixed this in our cURL to my best
>> knowledge, so my idea as a maintainer of gnURL was to simply
>> apply this to gnURL because someone in GNUnet reported errors
>> with regards to gnURL not finding the certificates with a recent
>> build of gnURL. I though I had this fixed a while ago, but
>> apparently I didn't.
>> I'm more than open to better fixes (we could also set the
>> expected environment variable).
>
> Another path forward I see is that I recommend every distro
> to set this path for themselves. We haven't fixed the Guix
> and GuixSD issue with this, but that's something I need to
> adjust for the upcoming release.
>
>
>>> I guess we want to be able to to change what certificates that gnurl
>>> accepts without rebulding the package, but I think we need something to
>>> provide that file when building the package in the first place, or
>>
>> What you seem to want is the env. variable solution.

All I really want is to be able to update my system ;).

I think an env. variable solution makes sense.  We already have
machinery for this in place with how packages can provide "search paths"
for other environment variables.  Perhaps the same should be applied to
SSL certificates.

Referencing some file on the root filesystem does not feel very
functional to me.  That becomes system specific mutable state, which
certainly shouldn't be an input to the build/test process.  For the
purposes of the test, gnurl should be providing an embedded certificate
store inside its own package that it runs tests against, otherwise the
tests are going to be prone to flaky failure like this.

If we want to refernce /etc/ssl/certs for use on non GuixSD distros,
then I think we should make sure that that directory is populated on
startup from the operating system profile on activation.

>> May I ask what system you are building on? I have a GuixSD-only
>> setup here. Next time I'll wait for the CI to finish building
>> (Debian based). I'm in the middle of releasing gnURL 7.58.0 and
>> preparing for a test that I have tomorrow, followed by some
>> social appointments afterwards, so I'll be able to start working
>> on a real fix on the weekend.

I'm building on GuixSD only as well.  I'm building from a git checkouts
with a few local changes to add/update packages I'm working on
(strongswan/python-axolotl) neither of which I believe are inputs to
gnurl.

It's pretty concerning that we're getting different results for building
gnurl, such a thing should be impossible or at least incredibly rare
with a purely function package manager.

Checking hydra.gnu.org, gnurl is failing there as well for i686 and
x86_64 but for different reasons.  It's failing because unbound is
failing which is an input to gnutls-dane which is an input to gnurl.

https://hydra.gnu.org/build/2453496



>>
>> In the meantime you could send a patch to revert my commit.
>
> -- 
> ng0 :: https://ea.n0.is
> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

Re: Meltdown / Spectre

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> FYI, in another thread, I recently posted preliminary patches to add the
>> GCC 7.3 release candidate as a Guix package, and to use it to build
>> linux-libre on x86_64 and i686 systems:
>>
>>   https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00292.html
>
> Today’s Jan. 24th, so hopefully we can roll in these patches today!

It won't be today, but maybe tomorrow:

  https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html

  Mark

Re: question regarding substitute* and #t

[Andy Wingo]

On Wed 24 Jan 2018 15:45, Hartmut Goebel  writes:

> Am 24.01.2018 um 13:14 schrieb Andy Wingo:
>> On Wed 24 Jan 2018 13:06, Mark H Weaver  writes:
>>
>>> + ;; Install to the right directory
>>> + (substitute* '("Makefile"
>>> +"Qsci/Makefile")
>>> +   (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
>>> +(assoc-ref outputs "out")))
>>> + #t)
>> I guess once we switch over all instances of "system" and "system*" to
>> use invoke, does that mean we will also be able to remove these
>> vestigial "#t" returns?
> I wonder why substitute* not simply returns #t?!

There was a proposal to make it return #t!  However then someone pointed
out that actually instead of making phases return boolean results, we
should instead signal problems via exceptions, and that drove the shift
from system / system* to invoke.  In the future world where completion
means success, it doesn't matter what substitute* returns.

However!  Because it doesn't matter, perhaps in the interest of
transition we should make substitute* return #t, so that once we switch
to the new exception-based error signalling, that we have less code to
clean up later.

Andy

Re: question regarding substitute* and #t

[Andy Wingo]

On Wed 24 Jan 2018 14:28, Mark H Weaver  writes:

> Andy Wingo  writes:
>
>> On Wed 24 Jan 2018 13:06, Mark H Weaver  writes:
>>
>>> + ;; Install to the right directory
>>> + (substitute* '("Makefile"
>>> +"Qsci/Makefile")
>>> +   (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
>>> +(assoc-ref outputs "out")))
>>> + #t)
>>
>> I guess once we switch over all instances of "system" and "system*" to
>> use invoke, does that mean we will also be able to remove these
>> vestigial "#t" returns?
>
> After we switch to using 'invoke' everywhere, or more precisely, after
> we arrange to never return #false from any phase or snippet, then there
> should be one more step before removing the vestigial #true returns: we
> should change the code that calls phases or snippets to ignore the
> value(s) returned by those procedures.  When that is done, then the #t's
> will truly be vestigial.  Does that make sense?

Sure, makes sense.  Thanks for thinking it through with me :)

Andy

Re: [RFC] A simple draft for channels

[Konrad Hinsen]

On 24/01/2018 13:33, n...@n0.is wrote:


In my honest opinion: No. We can not prevent this. All we can do
is to provide a list of *official* channels. Beyond that I don't
think we should try to regulate what's in an unofficial channel
and what's allowed.


+1

The best option in my opinion is to make it as easy as possible for 
users to find out the policy of any channel, and to do automatic 
filtering (for the day when there will be hundreds of channels to manage).


One simple measure would be a field in the channel description that says 
"complies with Guix' rules for free software yes/no". An added benefit: 
it forces channel designers to think about the question right from the 
start.


Konrad.

Re: weird errors; shepherd

[Ludovic Courtès]

Hello,

Danny Milosavljevic  skribis:

> Everyone:
>
> After I've tried writing some shepherd service I have to say that writing a
> shepherd "start" action is way too difficult.
>
> Even now, I've not gotten to work:
>
> * Having the activation depend on any other service.

I’m not sure what you mean.  There’s no notion of dependencies among
activation snippets, let alone between activation snippets and service
starts (when booting, activation snippets run *before* shepherd is
started).  Perhaps there’s a misunderstanding here?

> * Logging errors from start-trytond to stderr or stdout.

You can write:

  (make-forkexec-constructor
…
#:log-file "/var/log/something.log")

which will redirect stdout/stderr to that file (info "(shepherd) Service
De- and Constructors").

Now, I think stdout/stderr should be captured by default, and perhaps
made available with a journalctl-like interface (Leo proposed a GSoC
project along these lines.)

>   As far as I understand make-forkexec-constructor takes special care not
>   to kill stderr.  As long there's no log-file specified it should leave 
> stdout
>   and stderr alone.  So where does the text go?

To PID 1’s stdout/stderr, i.e., /dev/console (which sucks).

> I've had other problems like:
>
> * root's shepherd hangs sometimes and herd can't connect to it anymore.

That’s a serious bug.  Can you reproduce it?

> * When I use (error "XXX") in a shepherd start block, booting the system
> drops me into a REPL and doesn't let me out again (instead of just failing
> this one service and continuing to boot).

That’s inconvenient but “expected” in the sense that the ‘start’ method
is called right from shepherd.conf.  Perhaps we should call ‘start’ at a
later stage.

As you write, the Shepherd leaves quite a bit to be desired.  The good
news is that it’s a very small code base, so I’d encourage people to
look at it when they find something they’re dissatisfied with, and see
how it can be improved.

Thanks,
Ludo’.

Re: question regarding substitute* and #t

[Hartmut Goebel]

Am 24.01.2018 um 13:14 schrieb Andy Wingo:
> On Wed 24 Jan 2018 13:06, Mark H Weaver  writes:
>
>> + ;; Install to the right directory
>> + (substitute* '("Makefile"
>> +"Qsci/Makefile")
>> +   (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
>> +(assoc-ref outputs "out")))
>> + #t)
> I guess once we switch over all instances of "system" and "system*" to
> use invoke, does that mean we will also be able to remove these
> vestigial "#t" returns?
I wonder why substitute* not simply returns #t?!

-- 
Regards
Hartmut Goebel

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

Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags.

[Ricardo Wurmus]

n...@n0.is writes:

> Why? Why are we waiting for months and months and months to
> patch every single application instead of simply fixing cURL
> or our build of cURL and close this case?

This is only about libcurl.  Libcurl expects that a user (i.e. a
programme linking with libcurl) sets the certificate bundle.  This
happens in different ways in different applications.  Libcurl
purposefully ignores the usual environment variables, because those are
meant for the “curl” command line tool only.

There also is no bug report in the bug tracker.  Instead of demanding an
answer to why this hasn’t “simply” been fixed, I encourage you to
(re-)read the previous discussions about this:

https://lists.gnu.org/archive/html/guix-devel/2017-01/msg00516.html
https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00245.html


--
Ricardo

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

Re: Guixsd.org domain

[Ludovic Courtès]

Hi Andreas,

Andreas Enge  skribis:

> just for your information, I am in the process of moving the guixsd.org
> domain from my personal account to Guix Europe and also to a different
> registrar. I suppose that the DNS records will just move with it, but I
> am not totally sure; so if servers appear to be unreachable, this might
> be due to a transient failure in name resolution.

Thanks for the heads-up and for transitioning ownership!

Ludo’.

Re: Errors encountered in building guix from source.

[Ludovic Courtès]

Fis Trivial  skribis:

> * Do as the menu said
> So I ran the following command in sequence:
> $ guix environment guix --ad-hoc help2man git strace
> $ ./bootstrap
> $ ./configure --localstatedir=/var
>
> The last configure command resulted in error, here is the last part from 
> output:
>
> configure: checking for guile 2.2
> configure: found guile 2.2
> checking for guile-2.2... no
> checking for guile2.2... no
> checking for guile-2... no
> checking for guile2... /usr/bin/guile2
> configure: error: found development files for Guile 2.2, but /usr/bin/guile2 
> has effective version 2.0

Most likely your .bashrc, .bash_profile, or similar is overriding PATH
and other environment variables defined by ‘guix environment’, which is
why /usr/bin/guile2 takes precedence.

See the footnote at
.

HTH,
Ludo’.

Guix Workflow Language ?

[zimoun]

Dear,

Thank you to provide a workflow manager!
It is fun. :-)

I am currently investigating to describe basic and simple workflows.
And there is a couple of solutions, from python-oriented Snakemake
with Conda capabilities to Common Workflow Language or Workflow
Description Language.

https://snakemake.readthedocs.io/en/latest/
http://www.commonwl.org
https://software.broadinstitute.org/wdl/

And there is already some pipelines elsewhere, e.g.,
https://view.commonwl.org/workflows?search=rnaseq
https://github.com/UMCUGenetics/GGR-cwl

Moreover, some hyper-specialised and classical genomics pipelines are
also available elsewhere, e.g.,
http://bioinformatics.mdc-berlin.de/pigx/


Well, my question is: does it appear to you reasonable to write a
front-end for CWL ?


Because it seems hard to have some room in this landscape, even if I
think that the Guix-way is the most scientific (reproducible, open,
etc.).
I mean, there is room for a guix-backend engine (another CWL
implementation), I guess.

So, during a raining week-end, I gave a look to the specs of CWL and
why not start by define a subset, but then I have failed to write a
parser of it in Guile.


Hum? another question: does it exist an easy-to-use Guile library for
parsing YAML-like files ?


I have found Racket ones, but it was not clear to me how to do with
Guile (without reinventing the wheel).


What do you think about feeding GWL engine by CWL pipeline ?


Thank you for any advice.

All the best,
simon

Re: Overriding PostGIS install directories

[Ludovic Courtès]

Hi,

Ben Sturmfels  skribis:

> On Fri, 19 Jan 2018, Ludovic Courtès wrote:
>
>> However, I’d recommend simply patching ‘configure’ itself in a snippet,
>> using ‘substitute*’.  That way, you won’t have to add these dependencies
>> and extra phase.
>
> Thanks, substitute* is much neater and changing configure directly is
> working.
>
> I've just discovered though that the build includes makefile templates
> from the input postgres package, eg
> ...-postgresql-10.1/lib/pgxs/src/makefiles/pgxs.mk and parents. These
> makefiles are created from a separate run of `pg_config --sharedir` when
> building postgresql.
>
> I wonder whether it would be simpler to mock the "pg_config" program to
> return the paths I want, rather than patch out all the calls to it. Is
> that possible to do for a package and its inputs? What do you think?

I guess it all depends on the number of ‘pg_config’ invocations that
need to be patch, and whether each one needs different treatment.  We
should minimize complexity.

Ludo’.

Re: Prevent native-inputs references ending up in the final binary

[Ludovic Courtès]

Hi,

Tobias Geerinckx-Rice  skribis:

> Leo Famulari wrote on 21/01/18 at 23:37:
>> On Sat, Jan 20, 2018 at 04:47:14PM +0100, Tobias Geerinckx-Rice wrote:
>>> Danny,
>>>
>>> Danny Milosavljevic wrote on 20/01/18 at 11:40:
 We should change that in core-updates-next, if possible.
  
 I think that native-inputs shouldn't end up in the final binary as a
 reference [...]
>>> This has been discussed before, and I agree. (I started a branch to do
>>> so but it breaks quite a few things and it got tedious. I think I'm
>>> ready for more now.)
>
> [...]
>
>> I'd rather we do it somewhere else than core-updates.
>> 
>> It's already very difficult to complete the core-updates cycles. We
>> should limit core-updates to updates of core packages, and handle big
>> changes to Guix itself on their own branches.
>
> Er, yeah. Definitely.

+1

Anyway, I think it’s worth experimenting this on a branch.  We’ll have
to expect lots of breakage as Leo writes, so we’ll need to refine things
progressively.

Once such a branch exist, we can get it built on berlin or hydra.

Ludo’.

Re: GuixSD on Olimex A20 OLinuXino?

[Danny Milosavljevic]

Hi Ludo,

> I have one of these (maybe not the “LIME”, but does it make a
> difference?).  

Yes, it makes a difference (in U-Boot only).

Which one do you have? There's MICRO, LIME, LIME2 and additional
variants with eMMC and without eMMC.

Most of these should already have entries in
gnu/system/install.scm .  If not, one can easily add one
(add entry to gnu/bootloader/u-boot.scm, inheriting from allwinner-bootloader,
and then add entry to gnu/system/install.scm using it)

> How should I proceed?  Is it enough to dump this on
> microSD and boot?

Yes.

> I would actually write the final system rather than the installation
> system given that ‘guix pull’ currently runs out of memory on that
> device.

You can also boot the image using qemu-system-arm -kernel ... -dtb ... 
in order to directly load the Linux kernel (skipping u-boot).

Then set everything up in there.

Then copy the resulting image to the SD card.

You'd just have to specify the correct bootloader form in the final
system. (u-boot-a20-olinuxino-whatever-bootloader).

Like this does:

  (define (adjust-bootloader os)
  (operating-system (inherit os)
(bootloader (bootloader-configuration
 (bootloader u-boot-a20-olinuxino-whatever-bootloader)
 (target "/dev/mmcblk0")

Re: Meltdown / Spectre

[Ludovic Courtès]

Mark H Weaver  skribis:

> Leo Famulari  writes:
>
>> On Fri, Jan 19, 2018 at 05:06:25PM -0500, Mark H Weaver wrote:
>>> There's now a GCC 7.3 release candidate that apparently contains the
>>> necessary compiler support to allow linux-libre-4.14.14 to use the
>>> retpoline technique internally.
>>> 
>>>   https://gcc.gnu.org/ml/gcc/2018-01/msg00115.html
>>> 
>>> They hope to release GCC 7.3 on January 24th.  It would be good to
>>> promptly add GCC 7.3 to Guix when its released, and to start using it to
>>> build linux-libre-4.14 on selected systems: x86_64 and possibly aarch64.
>>> 
>>> I'd prefer to continue using our default compiler to build linux-libre
>>> on systems where GCC 7.3 is not known to help with this issue.
>>
>> Thanks for looking into this, Mark. Your plan sounds good to me.
>
> FYI, in another thread, I recently posted preliminary patches to add the
> GCC 7.3 release candidate as a Guix package, and to use it to build
> linux-libre on x86_64 and i686 systems:
>
>   https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00292.html

Today’s Jan. 24th, so hopefully we can roll in these patches today!

Thank you,
Ludo’.

Re: website: say what Guix is at the very top

[Oleg Pykhalov]

Hello,

myg...@gmail.com writes:

[...]

>> (I’m not as sure about these proposed individual changes as I am about
>> the proposal to separate the pages for Guix and GuixSD.)
>
> ISTM this difficulty in splitting the content across two pages is a
> reason to consider again how to unify the presentation of Guix/GuixSD.

Nix folks have a talk about splitted web pages for Nix package manager,
NixOS, Nix Expression Language.  They don't like it much, because when a
new person come to Nix, he cannot find a documentation for Nix
Expression language, because it's not clear that you need to go to the
separate page  and not for example
.

Again while I'm writing current message, I cannot find their NixOS
installation page manual.  :-) It's under support if you want to get
there with a mouse.  


Oleg.


signature.asc
Description: PGP signature

Re: website: say what Guix is at the very top

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:

[...]

>> In principle I think it’s a good idea.  In practice I’m not sure what
>> this would look like, though.
>>
>> For instance, does that mean /distro would be a “second home page”, with
>> screenshots, contacts, blog entries, baseline, and all?  Or would it be
>> different?  What would be remove from or add to the actual home page?
>
> I think of /distro as just a leaf page, not a whole website on its own.
>
> - The logo in the menu bar should be the Guix logo.  The GuixSD logo
>   could be shown in the contents of the /distro page.
>
> - The menu should probably have an item for GuixSD
>
> - The screenshots are applicable to GuixSD only, in my opinion, so they
>   don’t make much sense on the Guix home page.  I guess we could have
>   Guix-only text “screenshots” to show the command-line user interface.
>
> - I’d remove the “All packages” button from “Discover GuixSD”
>
> - “GNU Guix in other GNU/Linux distros” is a great section that should
>   link to the Guix package manager’s home page.
>
> - I would remove the blog, contact, and “GuixSD and GNU Guix in your
>   field” sections from the distro sub-page to avoid duplication.

Sounds reasonable and actionable.

> - The two sites should have separate Download sections.
>
> … and as I imagine these changes I become confused about how to link to
> these two download pages.  Having a single “Download” link at the top
> bar would not work when we want to offer separate pages for GuixSD and
> Guix.  We could have /distro/download, which would be linked from the
> /distro page, just like we currently have /download linked from right
> after the introduction.  It would have to be a very prominent button,
> shown “above the page fold” so that we can drop the “Download” item
> from the menu bar.
>
> The download page for GuixSD should offer the GuixSD options first and
> link to the Guix download page ater the options — and vice versa.

Agreed.

So I guess we should start working in that direction.
Anyone willing to start?

WDYT, sirgazil?

Thanks,
Ludo’.

Re: website: say what Guix is at the very top

[Ludovic Courtès]

Hello,

Chris Marusich  skribis:

> Ricardo Wurmus  writes:
>
>> Hi Guix,
>>
>> on the website it starts right away with a list of features:
>> “Liberating”, “Dependable”, and “Hackable”.  But what is this thing
>> called Guix?
>>
>> We should add a very short paragraph above that list to say what Guix
>> and GuixSD are.
>>
>> What do you think?
>
> How is Guix different from other package managers?  Why is it better?

That’s what Liberating (free software), Dependable (transactional,
etc.), Hackable (it’s a Scheme API) tries to convey.

The hope was that by reading these 3 items people could tell how it
differs from APT/dpkg, Conda, or Nix.

> Perhaps the best way to do that would be to write a problem statement.
> Instead of explaining what Guix is, explain what problems Guix solves.
> The first chapter of Eelco Dolstra's Ph. D. thesis [1] did a fantastic
> job of explaining what problems Nix solves, and by the end of that
> chapter, I was really excited to learn more about Nix (and Guix) and try
> it out.  In particular, the list of problems with the state of the art
> in section 1.3 "Motivation" and the list of solutions that Nix offers in
> section 1.5 "Contributions" were particularly concise and convincing.
> Maybe we can aim for something similar on our Guix website?

The “Introduction” and “Features” sections of the manual aim to achieve
that goal, but in a “constructive” way (stating what properties it has,
rather than what properties other solutions lack.)  However, I think
it’s not that concise and it’s quite technical, so I’d keep that in the
manual rather than on the front page.

Thoughts?

Ludo’.

Re: Drive identifiers

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> ;; Get the UUID of the encrypted disk
> (define %uuid
>   (let* ((port (open-input-pipe "blkid -s UUID -o value /dev/sda1"))
>  (str  (read-line port)))
> (close-pipe port)
> str))
> …
> (operating-system …
>   (mapped-devices (list (mapped-device
>  (source (uuid %uuid))
>  (target "root")
>  (type luks-device-mapping

It’s a weird example because the idea of UUIDs is precisely to *not*
record the partition’s /dev name.  :-)

Ludo’.

Re: [RFC] A simple draft for channels

[Ludovic Courtès]

Hello,

iyzs...@member.fsf.org (宋文武) skribis:

> Ricardo Wurmus  writes:
>
>> Hi Guix,
>>
>> I’d like to retire GUIX_PACKAGE_PATH as the main way to get third-party
>> packages, because we can’t really keep track of packages that were added
>> or redefined in this way.  I want to replace it with slightly more
>> formal “channels”.
>
> Hello, as a way to get and manage third-party guix repositories, it
> sounds more like “overlays” (in Gentoo world) rather than “channels” (in
> Nix world, to ensure binaries availability and updates stability) to me.
>
> https://wiki.gentoo.org/wiki/Overlay
> https://nixos.org/nix/manual/index.html#sec-channels
>
> How about call it as “overlay”?

I think “overlay” has the notion that it’s a layer on top of another
layer, which is not exactly the case here.  It’s not exactly like what
Nix channels either, but closer to that, I think.

Ludo’.

GuixSD on Olimex A20 OLinuXino?

[Ludovic Courtès]

Hello Danny!

dan...@scratchpost.org (Danny Milosavljevic) skribis:

> commit c55c6985948b12a39cd5805bde95db9a80def3ba
> Author: Danny Milosavljevic 
> Date:   Mon Jan 22 22:35:06 2018 +0100
>
> system: Add A20 OLinuXino LIME installer.
> 
> * gnu/bootloader/u-boot.scm (u-boot-a20-olinuxino-lime-bootloader):
> New exported variable.
> * gnu/packages/bootloaders.scm (u-boot-a20-olinuxino-lime):
> New exported variable.
> * gnu/system/install.scm (a20-olinuxino-lime-installation-os):
> New exported variable.

So, does it actually work?  :-)

I have one of these (maybe not the “LIME”, but does it make a
difference?).  How should I proceed?  Is it enough to dump this on
microSD and boot?

I would actually write the final system rather than the installation
system given that ‘guix pull’ currently runs out of memory on that
device.

Ludo’.

Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags.

[ng0+guixpatches]

Sorry, my email went out-of-order for the past 7 days.
I would've sent an explanation to the patch otherwise.
Let me comment inline.

a...@vany.ca transcribed Tue 23 Jan 2018 08:55:35 PM UTC bytes:
> Regarding https://debbugs.gnu.org/30165
>
> gnurl is failing to build on my system and I think this patch is to
> blame.  Why is gnurl referencing something under the root filesystem
> rather something provided by an input?  Shouldn't we provided
> ca-certificates.crt from an input and reference that?

The problem I'm trying to address is the same horror story we
have with cURL: We need to be able to reference a certificate
store.
So far no one in 2+ years fixed this in our cURL to my best
knowledge, so my idea as a maintainer of gnURL was to simply
apply this to gnURL because someone in GNUnet reported errors
with regards to gnURL not finding the certificates with a recent
build of gnURL. I though I had this fixed a while ago, but
apparently I didn't.
I'm more than open to better fixes (we could also set the
expected environment variable).

> I guess we want to be able to to change what certificates that gnurl
> accepts without rebulding the package, but I think we need something to
> provide that file when building the package in the first place, or

What you seem to want is the env. variable solution.

> disable the relelvant tests.
>
> For reference the build error I'm seeing is
> ==
> test 0324...[TLS-SRP with server cert checking]
>
> curl returned 77, when expecting 51
>  exit FAILED
>
>  - abort tests
>
> =

Wild. For what it's worth, I built this before I've sent a patch
and it passed all of its relevant testsuites. I didn't get this
error.

> From the curl man page, exit code 77 means "Problem with reading the SSL
> CA cert (path? access rights?)."

May I ask what system you are building on? I have a GuixSD-only
setup here. Next time I'll wait for the CI to finish building
(Debian based). I'm in the middle of releasing gnURL 7.58.0 and
preparing for a test that I have tomorrow, followed by some
social appointments afterwards, so I'll be able to start working
on a real fix on the weekend.

In the meantime you could send a patch to revert my commit.
-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

Re: question regarding substitute* and #t

[Mark H Weaver]

Hi Andy,

Andy Wingo  writes:

> On Wed 24 Jan 2018 13:06, Mark H Weaver  writes:
>
>> + ;; Install to the right directory
>> + (substitute* '("Makefile"
>> +"Qsci/Makefile")
>> +   (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
>> +(assoc-ref outputs "out")))
>> + #t)
>
> I guess once we switch over all instances of "system" and "system*" to
> use invoke, does that mean we will also be able to remove these
> vestigial "#t" returns?

After we switch to using 'invoke' everywhere, or more precisely, after
we arrange to never return #false from any phase or snippet, then there
should be one more step before removing the vestigial #true returns: we
should change the code that calls phases or snippets to ignore the
value(s) returned by those procedures.  When that is done, then the #t's
will truly be vestigial.  Does that make sense?

  Mark

Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags.

[ng0]

> Sorry, my email went out-of-order for the past 7 days.
> I would've sent an explanation to the patch otherwise.
> Let me comment inline.
>
> a...@vany.ca transcribed Tue 23 Jan 2018 08:55:35 PM UTC bytes:
>> Regarding https://debbugs.gnu.org/30165
>>
>> gnurl is failing to build on my system and I think this patch is to
>> blame.  Why is gnurl referencing something under the root filesystem
>> rather something provided by an input?  Shouldn't we provided
>> ca-certificates.crt from an input and reference that?
>
> The problem I'm trying to address is the same horror story we
> have with cURL: We need to be able to reference a certificate
> store.
> So far no one in 2+ years fixed this in our cURL to my best
> knowledge, so my idea as a maintainer of gnURL was to simply
> apply this to gnURL because someone in GNUnet reported errors
> with regards to gnURL not finding the certificates with a recent
> build of gnURL. I though I had this fixed a while ago, but
> apparently I didn't.
> I'm more than open to better fixes (we could also set the
> expected environment variable).

Another path forward I see is that I recommend every distro
to set this path for themselves. We haven't fixed the Guix
and GuixSD issue with this, but that's something I need to
adjust for the upcoming release.


>> I guess we want to be able to to change what certificates that gnurl
>> accepts without rebulding the package, but I think we need something to
>> provide that file when building the package in the first place, or
>
> What you seem to want is the env. variable solution.

I'll try that on the weekend at the CI and at home.
Alternative solutions with reference to the original cURL issue
bug in Guix are still welcome.

If we haven't fixed that for cURL in core-updates, as I thought
we had when I read the thread that inspired me for this fix:
Why? Why are we waiting for months and months and months to
patch every single application instead of simply fixing cURL
or our build of cURL and close this case?

On the plus side, once we know which configuration this bug
occurred with, we know that cURL could fail in a similar way ;)

>> disable the relelvant tests.
>>
>> For reference the build error I'm seeing is
>> ==
>> test 0324...[TLS-SRP with server cert checking]
>>
>> curl returned 77, when expecting 51
>>  exit FAILED
>>
>>  - abort tests
>>
>> =
>
> Wild. For what it's worth, I built this before I've sent a patch
> and it passed all of its relevant testsuites. I didn't get this
> error.
>
>> From the curl man page, exit code 77 means "Problem with reading the SSL
>> CA cert (path? access rights?)."
>
> May I ask what system you are building on? I have a GuixSD-only
> setup here. Next time I'll wait for the CI to finish building
> (Debian based). I'm in the middle of releasing gnURL 7.58.0 and
> preparing for a test that I have tomorrow, followed by some
> social appointments afterwards, so I'll be able to start working
> on a real fix on the weekend.
>
> In the meantime you could send a patch to revert my commit.

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

Re: weird errors; shepherd

[Catonano]

2018-01-24 13:46 GMT+01:00 Danny Milosavljevic :

> Hi Catonano,
>
> > With "successfully"" you mean that it connects to postgres and it shhows
> te
> > proper screens in the client ?
>
> Yes.
>
> I invoked "tryton" which pops up a GUI.  Then I edited the profiles there,
> adding "localhost" and then I logged into the client GUI via login "admin"
> and password "tryton".  It asked me to configure "modules".
>
> Then, it showed a window with two modules, "ir" and "res", in it.
>


Wonderful ! It's working !!

Re: weird errors; shepherd

[Danny Milosavljevic]

Hi Catonano,

> With "successfully"" you mean that it connects to postgres and it shhows te
> proper screens in the client ?

Yes.

I invoked "tryton" which pops up a GUI.  Then I edited the profiles there,
adding "localhost" and then I logged into the client GUI via login "admin"
and password "tryton".  It asked me to configure "modules".

Then, it showed a window with two modules, "ir" and "res", in it.

Re: weird errors; shepherd

[Catonano]

2018-01-23 23:43 GMT+01:00 Danny Milosavljevic :

> The attached file is gnu/services/trytond.scm which successfully runs
> trytond.
>

With "successfully"" you mean that it connects to postgres and it shhows te
proper screens in the client ?

Sometimes the trytond daemon does run but it fails to connect to postgres

I'll check this out. Only, not today, neither tomorrow probably. But I
will, sooner or later

Thanks !



> Everyone:
>
> After I've tried writing some shepherd service I have to say that writing a
> shepherd "start" action is way too difficult.
>
> Even now, I've not gotten to work:
>
> * Having the activation depend on any other service.
> * Logging errors from start-trytond to stderr or stdout.
>   As far as I understand make-forkexec-constructor takes special care not
>   to kill stderr.  As long there's no log-file specified it should leave
> stdout
>   and stderr alone.  So where does the text go?
>
> I've had other problems like:
>
> * root's shepherd hangs sometimes and herd can't connect to it anymore.
> * When I use (error "XXX") in a shepherd start block, booting the system
> drops me into a REPL and doesn't let me out again (instead of just failing
> this one service and continuing to boot).
>
> Sigh...
>

I'm relieved that someone else finds this difficult

Thans again !

Re: [RFC] A simple draft for channels

[ng0]

myg...@gmail.com:
> On 01/23/2018 at 16:50 n...@n0.is writes:
>
>> myglc2 writes:
>>> On 01/19/2018 at 14:41 Ludovic Courtès writes:
>>>
 Hi!

 Ricardo Wurmus  skribis:

> As a first implementation of channels I’d just like to have a channel
> description file that records at least the following things:
>> […]
 One thing that’s still an open question is how we should treat Guix
 itself in that channelized world.

 Should Guix be a “normal” channel?  It’s tempting to think of it as a
 regular channel; however, it’s definitely “special” in that it can
 update the ‘guix’ command, maybe guix-daemon & co., locale data, etc.
 How does that affect ‘guix channel’?
>>>
>>> ISTM this design allows channels to inject non-free &/or non-safe
>>> components into other user's Guix systems. Is that true?
>>>
>>> If so, how will it impact the Guix promise of software freedom/safety?
>>>
>>> WDYT? - George
>>
>> Just commenting on this one for now until I got my mail fixed:
>>
>> Why is this a problem? Already today you can run Guix with as many
>> modifications as you like to, and you are free to install whatever you
>> want.  That's one of the very good aspects of Guix - you can use it to
>> create whatever you like.  Or maybe you need to expand a bit on the
>> sentences you wrote George.
>
> Yes, and this is important to the current user base. But in the future
> the majority of our users will be end-users that do not directly use FSF
> freedoms & Guix hackability. Still, they will choose Guix because this
> freedom and hackability provides indirect benefits such as enhanced
> security and safety.
>
> Yes, FSF freedom means we must permit any user to shoot themselves in
> the foot. But with GUIX_PACKAGE_PATH, this is not a worry.
>
> Channels dramatically increases the ease with which an end-user can harm
> themselves by e.g. using a channel that delivers non-free &/or non-safe
> software. This raises the question: are we obliged to, and if so, how do
> we help end-users protect themselves from this risk?

In my honest opinion: No. We can not prevent this. All we can do
is to provide a list of *official* channels. Beyond that I don't
think we should try to regulate what's in an unofficial channel
and what's allowed.
It would be waste of time better spent in other parts of the
project.

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

question regarding substitute* and #t (was: Simplifications enabled by switching to 'invoke')

[Andy Wingo]

Hi!

On Wed 24 Jan 2018 13:06, Mark H Weaver  writes:

> + ;; Install to the right directory
> + (substitute* '("Makefile"
> +"Qsci/Makefile")
> +   (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
> +(assoc-ref outputs "out")))
> + #t)

I guess once we switch over all instances of "system" and "system*" to
use invoke, does that mean we will also be able to remove these
vestigial "#t" returns?

Andy

Simplifications enabled by switching to 'invoke'

[Mark H Weaver]

Hello Kei, and other fellow Guix,

kkebr...@posteo.net (Kei Kebreau) writes:
> commit 0af6ffdd8d81f86a232902a54f99d4cfcd369490
> Author: Kei Kebreau 
> Date:   Tue Jan 23 17:44:53 2018 -0500
>
> gnu: qscintilla: Update to 2.10.2.
> 
> * gnu/packages/qt.scm (qscintilla, python-qscintilla, 
> python-pyqt+qscintilla):
> Update to 2.10.2.
[...]
> @@ -1715,8 +1715,8 @@ indicators, code completion and call tips.")
>   (replace 'configure
> (lambda* (#:key outputs configure-flags #:allow-other-keys)
>   (chdir "Python")
> - (and (zero? (apply system* "python3" "configure.py"
> -configure-flags))
> + (and (apply invoke "python3" "configure.py"
> + configure-flags)
>;; Install to the right directory
>(begin
>  (substitute* '("Makefile"

Kei, I appreciate that you took this opportunity to switch from
'system*' to 'invoke' here while doing this update.  I think it makes
sense to do this whenever we update a package.

However, it's worth noting that you missed an important further
simplification that the switch to 'invoke' enables.  Since 'invoke'
never returns #false, the surrounding code that arranges for plumbing of
its result code can be removed entirely.

Step by step:

* Since 'invoke' never returns #false, it can be moved above the 'and'.

* This leaves the 'and' with only one remaining argument.  An 'and' with
  only one argument is equivalent to that argument, so the 'and' can be
  removed, replaced by its argument.

* Since the 'begin' is now within a body (whereas previously it was an
  operand), the 'begin' can now be removed, replaced by its contents.

This is what I did in commit 76c7fc436a151236f5e1ff966fd99172d85ee422 on
master, which I've attached below.

Thanks,
  Mark


>From 76c7fc436a151236f5e1ff966fd99172d85ee422 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 24 Jan 2018 06:35:29 -0500
Subject: [PATCH] gnu: python-qscintilla: Remove result code plumbing.

* gnu/packages/qt.scm (python-qscintilla)[arguments]: In the 'configure'
phase, remove result code plumbing that is no longer needed, since 'invoke'
never returns #false.
---
 gnu/packages/qt.scm | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index 596006080..34938b9c0 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -1715,15 +1715,14 @@ indicators, code completion and call tips.")
  (replace 'configure
(lambda* (#:key outputs configure-flags #:allow-other-keys)
  (chdir "Python")
- (and (apply invoke "python3" "configure.py"
- configure-flags)
-  ;; Install to the right directory
-  (begin
-(substitute* '("Makefile"
-   "Qsci/Makefile")
-  (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
-   (assoc-ref outputs "out")))
-#t)))
+ (apply invoke "python3" "configure.py"
+configure-flags)
+ ;; Install to the right directory
+ (substitute* '("Makefile"
+"Qsci/Makefile")
+   (("\\$\\(INSTALL_ROOT\\)/gnu/store/[^/]+")
+(assoc-ref outputs "out")))
+ #t)
 (inputs
  `(("qscintilla" ,qscintilla)
("python" ,python)
-- 
2.16.1

Re: [RFC] A simple draft for channels

[Pjotr Prins]

On Tue, Jan 23, 2018 at 09:37:04PM +0100, Ricardo Wurmus wrote:
> My initial goal is much simpler.

Let's stick to simple for now. Sorry about raising the noise level. I
would be extremely pleased with a simple replacement of
GUIX_PACKAGE_PATH and I am happy to contribute.

Keys etc. we can probably allow through root rights.

Pj.

Re: Porting GuixSD to ARM article.

[Andreas Enge]

On Wed, Jan 24, 2018 at 09:17:48AM +0100, Mathieu Othacehe wrote:
> Well "vm-image" is pretty close to "disk-image". The difference is that
> "vm-image" output is meant to be run with qemu.

Ah, indeed, the output format is different. The other day I converted
a vm-image to "raw" format, which I suppose is then essentially the same
as a disk-image. I just did not know how to create a disk-image without
the cow-store.

Andreas

Re: Porting GuixSD to ARM article.

[Mathieu Othacehe]

Hello,

> I see, that is a very interesting observation! Is it documented anywhere?
> A further naive question: How does it differ from a vm-image then?

Well "vm-image" is pretty close to "disk-image". The difference is that
"vm-image" output is meant to be run with qemu. However, there's no qemu
machine emulating the BBB. So, producing a "vm-image" for BBB is not
viable.

If one day BBB is (unlikely) supported by qemu, then "vm-image" will
allow you to test system configurations in a VM without the need of a
BBB hardware.

Mathieu