Re: gnumaint changes

[Mike Gerwitz]

On Wed, Jul 11, 2018 at 16:11:37 +0200, Ludovic Courtès wrote:
> Hello Mike,
>
> Mike Gerwitz  skribis:

[...]

>> pkgblurbs.txt has also been replaced by rec/pkgblurbs.rec.
>
> Commit daf76c7cd54df428abc28d490747c7f83a844df0 changes
> gnu-maintenance.scm to use the .rec files.  Thanks for the heads-up.

Thanks.  I was planning to submit a patch this weekend, but you beat me
to it.  Sorry for the trouble!  I'm glad to see that the change was
pretty simple.

>> If anyone here also knows of any other external systems pulling from
>> womb, please lmk.  I wasn't aware that anyone outside of maintainers@
>> used that repo, tbh.
>
> It’s used by ‘guix import gnu’ and ‘guix lint -c gnu-descriptions’
> currently.
>
> It’d be nice if synopses and descriptions in the Womb could contain
> Texinfo markup.
>
> In fact, perhaps it’d make sense to reverse the roles, i.e., have the
> Womb take (some of its) descriptions from Guix?

`blub' in pkgblurbs (which is what `official-description' uses) is
provided by package authors after they've been dubbed by rms.  That is
in turn used on gnu.org.  Consequently, I think it's best to have such
blurbs maintained independently of guix.

What sort of Texinfo markup are you looking for, and are we talking
about the same field?  What field does guix use for the synopsis?
Everything in rec/gnupackages.rec is handled by us at maintainers@, so
we can do whatever we want there.

Do you have a couple examples of what you think would be beneficial to
pull form Guix?  I'm certainly open to the idea where it makes sense;
there's no sense in us duplicating effort within GNU unnecessarily.

I'm also working on automating parts of our recordkeeping: in the next
few weeks, Womb will have up-to-date version information automatically
pulled from info-gnu release announcements; the FTP server; and a couple
websites where necessary, though I'll be manually committing it for the
first few months to verify that it is all working properly.  So Guix
might also be able to depend on rec/gnupackages.rec for checking for new
releases as well, since unfortunately GNU doesn't mandate the use of the
FTP server, or even info-gnu (so releases are all over the place).

-- 
Mike Gerwitz


signature.asc
Description: PGP signature

Note on Outreachy internship

[Ricardo Wurmus]

Hi Guix,

after reviewing the current state of the project “Improve the user
experience for the "guix package" command line tool”, for which Gábor
and I mentored an Outreachy intern, we have decided to terminate the
internship at the midterm evaluations.

The remainder of the funds that have been paid in advance to the
Software Freedom Conservancy to support this internship will be reserved
for a future intern for Guix in the next round of Outreachy internships.

Thanks to all of you who supported the intern in the past weeks!

--
Ricardo

Re: SOLVED: Re: gcc-4.7.4: libgcc2.h:157: error: unable to emulate 'TF'

[Jan Nieuwenhuizen]

U.Mutlu writes:

>> Thanks!  I'm very grateful for your help.  I succeeded in building
>> gcc-4.7.4 from almost no binary seeds[0] for GuixSD!
>
> Congrats!  :-)

Thanks!

> Can you give us some info on your project? (mes?)

Mes[0] aims to help create full source bootstrapping for GNU/Linux
distributions such as GuixSD[1] as part of the bootstrappable builds[2]
effort.

It consists of a mutual self-hosting Scheme interpreter written in
~5,000LOC of simple C and a Nyacc-based C compiler written in Scheme.

> As I could figure out, GuixSD is a (new) GNU package manager, right?

Correct.  Guix is the packagage manager, GuixSD (for System Distribution) is
GNU's GNU/Linux distribution built around it.

> I think you mentioned TCC, scheme, own header files etc.

This MesCC compiler comes with three sizes of Mes lib C: libc for
building mes.c, libc+tcc for building TCC.  Then, there is libc+gnu that
is used together with TCC to build binutils-2.20a and gcc-2.95.3.

> Did you still had to use also the old gcc 2.95.3 ?

We are using gcc 2.95.3 as the first GCC compiler mainly because (after
many experiments with versions from 1.40 to 4.1) it proved the most
"bootstrappable" GCC.  GCC 3 introduces a dependency on dirent, e.g.,
that our naive C library does not support.

If we make our libc+gnu richer then we can probably target a newer GCC,
but it's not obvious to me what the bootstrap consequences of that are.

> What's the goal, and why especially that target version gcc 4.7.4 ?

GCC 4.7.4 is currently used as one of the bootstrap binaries of GuixSD.
Also, it's the most recent GCC compiler that can be considered to be
directly bootstrappable.  I don't consider building a c++ bootstrap
compiler ;-)

The goal is to replace the x86 bootstrap of GNU/Linux distributions,
using a bootstrap [mostly] from source instead of what currently
happens: seeding it with a very large blob of bootstrap binaries.

GuixSD seems the best place to develop this in.

> Just a little bit curious about your complicated looking project :-)

Thanks for showing interest!

Greetings,
janneke


[0] http://gitlab.com/janneke/mes
[1] https://www.gnu.org/software/guix
[2] http://bootstrappable.org

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: [PATCH 0/1] Go importer

[Leo Famulari]

On Mon, Jun 04, 2018 at 10:18:53AM +0200, Pierre-Antoine Rouby wrote:
> Attached an update of importer.

Thanks! I'm sorry my response is so late.

> From 3e9b4fa12811432fdd7a4d6330f9093dcc72d25a Mon Sep 17 00:00:00 2001
> From: Rouby Pierre-Antoine 
> Date: Thu, 26 Apr 2018 15:05:23 +0200
> Subject: [PATCH] import: Add gopkg importer.
> 
> * guix/import/gopkg.scm: New file.
> * guix/scripts/import/gopkg.scm: New file.
> * guix/scripts/import.scm: Add 'gopkg'.
> * Makefile.am: Add 'gopkg' importer in modules list.

I wonder which of the new files needs to be added to Makefile.am? My
Autotools knowledge is not very strong...

> +(define (get-new-tmp-dir)
> +  "Return new temp directory."
> +  (let ((tmp "/tmp/guix-import-gopkg"))
> +(define (new num)
> +  (let ((new-dir (string-append tmp "-" (number->string num
> +(if (file-exists? new-dir)
> +(new (+ num 1))
> +new-dir)))
> +(if (file-exists? tmp)
> +(new 0)
> +tmp)))
> +
> +(define tmp-dir (get-new-tmp-dir))

I noticed a couple issues with this code. First, the names of the
temporary directories are predictable (they use an incrementing
integer). Second, the temporary files are not deleted after the importer
runs. I've attached a modified patch that addresses this by using ((guix
utils) call-with-temporary-directory), which should address these
problems. [0]

> +(define* (git-fetch url commit directory
> +#:key (git-command "git") recursive?)
> +  "Fetch COMMIT from URL into DIRECTORY.  COMMIT must be a valid Git commit
> +identifier.  When RECURSIVE? is true, all the sub-modules of URL are fetched,
> +recursively.  Return #t on success, #f otherwise."
> +  ;; Disable TLS certificate verification.  The hash of the checkout is known
> +  ;; in advance anyway.
> +  (setenv "GIT_SSL_NO_VERIFY" "true")

My patch turns certificate verification back on. When importing, the
hash of the checkout is not known in advance.

And finally I added some brief documentation to the manual. Maybe there
could be further clean-up and code deduplication with other parts of the
Guix codebase, but I think it's better to have this importer in Guix
now.

What do you think of my patch? Does it still work for you?

[0] Actually, the temp directories will not be cleaned up due to
, but I think this will eventually be fixed.
From 50c12ff1770286fae00dac469cad3af4a9df1070 Mon Sep 17 00:00:00 2001
From: Rouby Pierre-Antoine 
Date: Thu, 26 Apr 2018 15:05:23 +0200
Subject: [PATCH] import: Add gopkg importer.

* guix/import/gopkg.scm: New file.
* guix/scripts/import/gopkg.scm: New file.
* guix/scripts/import.scm: Add 'gopkg'.
* Makefile.am: Add 'gopkg' importer in modules list.

Co-authored-by: Leo Famulari 
---
 Makefile.am   |   1 +
 doc/guix.texi |   9 +-
 guix/import/gopkg.scm | 352 ++
 guix/scripts/import.scm   |   2 +-
 guix/scripts/import/gopkg.scm |  99 ++
 5 files changed, 461 insertions(+), 2 deletions(-)
 create mode 100644 guix/import/gopkg.scm
 create mode 100644 guix/scripts/import/gopkg.scm

diff --git a/Makefile.am b/Makefile.am
index 618d1653e..a93a280b2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -186,6 +186,7 @@ MODULES =   \
   guix/import/hackage.scm  \
   guix/import/elpa.scm \
   guix/import/texlive.scm  \
+  guix/import/gopkg.scm\
   guix/scripts.scm \
   guix/scripts/download.scm\
   guix/scripts/perform-download.scm\
diff --git a/doc/guix.texi b/doc/guix.texi
index a8e53a530..07100cd25 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -20,7 +20,7 @@ Copyright @copyright{} 2014, 2015, 2016 Alex Kost@*
 Copyright @copyright{} 2015, 2016 Mathieu Lirzin@*
 Copyright @copyright{} 2014 Pierre-Antoine Rault@*
 Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@*
-Copyright @copyright{} 2015, 2016, 2017 Leo Famulari@*
+Copyright @copyright{} 2015, 2016, 2017, 2018 Leo Famulari@*
 Copyright @copyright{} 2015, 2016, 2017, 2018 Ricardo Wurmus@*
 Copyright @copyright{} 2016 Ben Woodcroft@*
 Copyright @copyright{} 2016, 2017, 2018 Chris Marusich@*
@@ -6667,6 +6667,13 @@ Import metadata from the crates.io Rust package 
repository
 @cindex OCaml
 Import metadata from the @uref{https://opam.ocaml.org/, OPAM} package
 repository used by the OCaml community.
+
+@item gopkg
+@cindex gopkg
+@cindex Golang
+@cindex Go
+Import metadata from the @uref{https://gopkg.in/, gopkg} package
+versioning service used by some Go software.
 @end table
 
 The structure of the @command{guix import} code is modular.  It would be
diff --git a/guix/import/gopkg.scm b/guix/import/gopkg.scm
new file mode 100644
index 0..c2b72616a
--- /dev/null
+++ b/guix/import/gopkg.scm
@@ -0,0 +1,352 @@
+;;; GNU Guix --- Functional 

Re: SOLVED: Re: gcc-4.7.4: libgcc2.h:157: error: unable to emulate 'TF'

[U.Mutlu]

Jan Nieuwenhuizen wrote on 07/11/2018 07:01 PM:

U.Mutlu writes:


Just a tip: you can build the compiler much faster if you use 
--disable-bootstrap
(here it reduces the compile time from 111 minutes down to 12 minutes).
After it's ok, then you can build w/o it to also test the
bootstrapping.


Thanks!  I'm very grateful for your help.  I succeeded in building
gcc-4.7.4 from almost no binary seeds[0] for GuixSD!


Congrats!  :-)

Can you give us some info on your project? (mes?)
I think you mentioned TCC, scheme, own header files etc.
Did you still had to use also the old gcc 2.95.3 ?
What's the goal, and why especially that target version gcc 4.7.4 ?
As I could figure out, GuixSD is a (new) GNU package manager, right?
Just a little bit curious about your complicated looking project :-)



The weird error in Subject was caused by configure+make (and my usage of
configure flags, environment settings) trying to use CC_FOR_BUILD (the
i368-unknow-linux-gcc 2.95.3 compiler) to build libgcc2.c

Here's the configure that I used, which works.

../build/configure\
  --build=i686-unknown-linux-gnu\
  --host=i686-unknown-linux-gnu\
  
--with-native-system-header-dir=/gnu/store/lwadx3lm73f8rmy8cvwijrflb9wgcm7j-glibc-mesboot-2.2.5/include\
  
--with-build-sysroot=/gnu/store/lwadx3lm73f8rmy8cvwijrflb9wgcm7j-glibc-mesboot-2.2.5/include\
  --prefix=/gnu/store/bci6j4dfrmkfzqbpbbcz5ypk8xmr0j5z-gcc-mesboot-4.7.4\
  --disable-bootstrap\
  --disable-decimal-float\
  --disable-libatomic\
  --disable-libcilkrts\
  --disable-libgomp\
  --disable-libitm\
  --disable-libmudflap\
  --disable-libquadmath\
  --disable-libsanitizer\
  --disable-libssp\
  --disable-libvtv\
  --disable-lto\
  --disable-lto-plugin\
  --disable-multilib\
  --disable-plugin\
  --disable-shared\
  --disable-threads\
  --enable-languages=c\
  --enable-static\
  --enable-threads=single\
  --disable-libstdc__-v3\
  --disable-libstdcxx-pch\
  --disable-build-with-cxx

Greetings,
janneke

[0] 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/mes.scm?h=wip-bootstrap

Re: Cuirass changes

[Ludovic Courtès]

Clément Lassieur  skribis:

> Ludovic Courtès  writes:
>
>>> 1. Adding support for multiple inputs.  Currently Cuirass only supports
>>> one input per specification, which has to be the Guix git repository.
>>> But one might want inputs for:
>>>   - a repository containing the 'proc' that returns the jobs,
>>>   - a repository containing extra packages (GUIX_PACKAGE_PATH).
>>> Those inputs would be fetched at INTERVAL as well, and any change would
>>> trigger an evaluation.  This is a follow-up of
>>> https://lists.gnu.org/archive/html/guix-patches/2018-06/msg00311.html.
>>
>> Excellent.  I think the polling interval should be per input, while
>> we’re at it.
>
> Indeed, but that would complicate things.  Would it make sense to do it
> in another commit?

Sure, this can definitely be done later, I was just mentioning it in
passing.

Ludo’.

SOLVED: Re: gcc-4.7.4: libgcc2.h:157: error: unable to emulate 'TF'

[Jan Nieuwenhuizen]

U.Mutlu writes:

> Just a tip: you can build the compiler much faster if you use 
> --disable-bootstrap
> (here it reduces the compile time from 111 minutes down to 12 minutes).
> After it's ok, then you can build w/o it to also test the
> bootstrapping.

Thanks!  I'm very grateful for your help.  I succeeded in building
gcc-4.7.4 from almost no binary seeds[0] for GuixSD!

The weird error in Subject was caused by configure+make (and my usage of
configure flags, environment settings) trying to use CC_FOR_BUILD (the
i368-unknow-linux-gcc 2.95.3 compiler) to build libgcc2.c

Here's the configure that I used, which works.

../build/configure\
 --build=i686-unknown-linux-gnu\
 --host=i686-unknown-linux-gnu\
 
--with-native-system-header-dir=/gnu/store/lwadx3lm73f8rmy8cvwijrflb9wgcm7j-glibc-mesboot-2.2.5/include\
 
--with-build-sysroot=/gnu/store/lwadx3lm73f8rmy8cvwijrflb9wgcm7j-glibc-mesboot-2.2.5/include\
 --prefix=/gnu/store/bci6j4dfrmkfzqbpbbcz5ypk8xmr0j5z-gcc-mesboot-4.7.4\
 --disable-bootstrap\
 --disable-decimal-float\
 --disable-libatomic\
 --disable-libcilkrts\
 --disable-libgomp\
 --disable-libitm\
 --disable-libmudflap\
 --disable-libquadmath\
 --disable-libsanitizer\
 --disable-libssp\
 --disable-libvtv\
 --disable-lto\
 --disable-lto-plugin\
 --disable-multilib\
 --disable-plugin\
 --disable-shared\
 --disable-threads\
 --enable-languages=c\
 --enable-static\
 --enable-threads=single\
 --disable-libstdc__-v3\
 --disable-libstdcxx-pch\
 --disable-build-with-cxx

Greetings,
janneke

[0] 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/mes.scm?h=wip-bootstrap

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: /dev/urandom

[Vincent Legoll]

Hello,

On Wed, Jul 11, 2018 at 5:50 PM, Danny Milosavljevic
 wrote:
> http://soc.yonsei.ac.kr/Abstract/International_journal/pdf/106_Data%20Randomization%20Scheme%20for%20Endurance%20Enhancement%20and%20Interference%20Mitigation%20of%20Multilevel%20Flash%20Memory%20Devices.pdf

Thanks a lot

I didn't understand everything in there, but sufficiently to sleep
a bit less stupid tonight...

I think it boils down to that: this random data mitigates errors
that are due to cell content interferences. I don't think it is directly
related to cells wear.

Do you concur ?

-- 
Vincent Legoll

Re: Having a Guix archive on the download page?

[Pjotr Prins]

On Wed, Jul 11, 2018 at 02:55:45PM +0200, Ludovic Courtès wrote:
> Now the question is, will it always be possible to run ‘guix pull’ from
> an arbitrary-old Guix?  Maybe it will still be impossible sometimes if
> the old Guix is really too old.  However, I suspect such issues will be
> much more rare.  There’s essentially a single file that needs to be put
> under scrutiny to avoid such issues: build-aux/build-self.scm.

I think we should have a rescue mode. The nar does not have to
be visible on the main download page, but maybe on a rescue page in
the manual? A rescue nar would always work. 

At this point none of my systems runs guix pull any longer. Even
getting a build system (from guix) to build the tree is problematic. I
realise it may be less of an issue in the future... Mind that, even
now, if you change the database layout (e.g. with a source install)
guix pull may break. We could have specific rescue nars that go with
database versions. That also frees you to change the database :). Call
it a transition/rescue nar on time points where things can break. 

The change to guile2 was such a break, guile-json/tls another and now the
new guix pull come to mind. That was dependencies only. We know we are
going to change the database in the future...

> An archive like you suggest could be useful in those hopefully rare
> cases where things break, so it’s a good idea.

It should be easy to generate when we do a new release, similar to the
binary image, right? We only need a rescue when there is a breaking
change, however. They do happen.

Pj.

Re: /dev/urandom

[Danny Milosavljevic]

Hi Vincent,

On Wed, 11 Jul 2018 17:07:02 +0200
Vincent Legoll  wrote:

> On Wed, Jul 11, 2018 at 4:17 PM, Danny Milosavljevic
>  wrote:
> > the randomness is necessary for NAND wear levelling,  
> 
> Any pointers about that subject ?

http://soc.yonsei.ac.kr/Abstract/International_journal/pdf/106_Data%20Randomization%20Scheme%20for%20Endurance%20Enhancement%20and%20Interference%20Mitigation%20of%20Multilevel%20Flash%20Memory%20Devices.pdf


pgpti4CPHNzK6.pgp
Description: OpenPGP digital signature

Fwd: Re: /dev/urandom

[doncatnip]

Of course, I forgot the CC.



 Forwarded Message 
Subject:Re: /dev/urandom
Date:   Wed, 11 Jul 2018 09:58:14 +0100
From:   Steffen Schulz 
To: Leo Famulari 



I probably got it wrong.

but it seems the programs purpose is to build images (boot loaders). I
then wonder why it needs to do this during installation. If image
building is the programs purpose, it should happen during execution
after installation, no ?

Users would *most likely* prefer it's actual purpose (proper Images,
including optimization) instead of reproducibility.

On 10.07.2018 23:40, Leo Famulari wrote:

On Tue, Jul 10, 2018 at 08:58:43PM +0200, Danny Milosavljevic wrote:

It writes an image file.  Since that image is later written to flash storage
(by the user), the program randomizes the data in order to increase longevity.
Then it stores the random data used as well.

I see. Like Ludo and Mark, I think we should avoid doing tricky things
with urandom.

Could /dev/zero work here? Does it use urandom once, to get a seed, or
does it read urandom repeatedly, expecting different values each time?

Also, I wonder if Guix users would want reproducibility here instead of
longer-lived NAND storage.

Fwd: Re: /dev/urandom

[doncatnip]

Of course, I forgot the CC here too.




 Forwarded Message 
Subject:Re: /dev/urandom
Date:   Wed, 11 Jul 2018 17:38:52 +0200
From:   doncatnip 
To: Vincent Legoll 



I'd guess this is about the distribution of blocks within the image, so
that the load of each sector is different from image to image containing
the same data. Of course, I'm just speculating as I haven't looked into
it - but if that is the case, it would seem even more strange that this
random seed is generated during install and not during use of the program.


On 7/11/2018 5:07 PM, Vincent Legoll wrote:

On Wed, Jul 11, 2018 at 4:17 PM, Danny Milosavljevic
 wrote:

the randomness is necessary for NAND wear levelling,

Any pointers about that subject ?

This looks strange as I'd have thought that less writes => less wear.

Re: /dev/urandom

[Vincent Legoll]

On Wed, Jul 11, 2018 at 4:17 PM, Danny Milosavljevic
 wrote:
> the randomness is necessary for NAND wear levelling,

Any pointers about that subject ?

This looks strange as I'd have thought that less writes => less wear.

-- 
Vincent Legoll

Re: Cuirass changes

[Clément Lassieur]

Hi Ludovic,

Ludovic Courtès  writes:

>> 1. Adding support for multiple inputs.  Currently Cuirass only supports
>> one input per specification, which has to be the Guix git repository.
>> But one might want inputs for:
>>   - a repository containing the 'proc' that returns the jobs,
>>   - a repository containing extra packages (GUIX_PACKAGE_PATH).
>> Those inputs would be fetched at INTERVAL as well, and any change would
>> trigger an evaluation.  This is a follow-up of
>> https://lists.gnu.org/archive/html/guix-patches/2018-06/msg00311.html.
>
> Excellent.  I think the polling interval should be per input, while
> we’re at it.

Indeed, but that would complicate things.  Would it make sense to do it
in another commit?

>> 3. Allowing any input to be in Guile's %load-path when 'proc' is called.
>> Usually, the only input that is in Guile's %load-path is Guix.  But
>> someone might want to use a custom library in 'proc'.  The alternative
>> is to just specify the Guix input that should be appended to Guile's
>> %load-path.
>>
>> (I'm unsure about 3., I can't find any real use case.  That would just
>> make it more flexible I guess.)
>
> We can also wait until there’s a real use case, it’s often a good idea.
> :-)

I finally opted for a flexible %load-path.  I think it also makes the
structure of the specification more transparent and understandable: it's
very clear that the input will be used as the load path, it's less
magical.  But if you object I'd happily change it.

>> I'm sending this email because even though the patches are already done
>> and they work on my Cuirass instance, there are a few other things to do
>> before I can send them:
>>   - add a mechanism to update the database,
>>   - update the documentation.
>> So if you think I'm not on the right track, please let me know as soon
>> as possible :-)
>
> Looks like you’re on the right track.  You submitted changes to
> guix-patches in the meantime so I’ll take a look at these.

Cool!  Thank you :-)

Clément

Re: GSoC update

[Jelle Licht]

2018-07-11 0:40 GMT+02:00 Ludovic Courtès :

> Hi Ioannis,
>
> Ioannis Panagiotis Koutsidis  skribis:
>
> > This patch adds initial support for .socket unit files. It does not
> > currently work but is near completion.
>
> Could you expound a bit?  That’s a very short summary for all the sweat
> you’ve put in it.  :-)
>
> Also, what is the patch against?  It’s not against ‘master’; I suppose
> it’s against the previous state of your own branch, do you have a copy
> of your repo on-line?
>
> > During the past month I also worked on a patch that adds signalfd and
> > fiber support but these are currently way too unstable and for that
> > reason I have not included them in this patch.
>
> It’s OK that the thing doesn’t quite work—we knew it was not an easy
> task.  What’s disappointing though is that you didn’t come to us to
> discuss the issues until now.  GSoC is not about working in all
> loneliness separately from the rest of the group; it’s about becoming
> part of the group.
>
> On IRC Jelle and I (and possibly others) offered help on the ‘signalfd’
> issue; I also outlined reasonable milestones (first, only use
> signalfd(2) instead of SIGCHLD, then discuss together what it would take
> to Fiberize the whole thing.)  It’s sad that you remained stuck instead
> of taking this opportunity to discuss it with us.
>

Ioannis, could you perhaps share some of your w.i.p. code regarding
signalfd-based signal handling in guile? Adding to what Ludo'
mentioned, I imagine you are running into some peculiarities regarding
guile's way of handling signals, so I would recommend to start
lurking on #guile if you did not do this before now, so you can interact
with the folks with the most expertise regarding the problems you
might be facing :-)

>
> > From cd260ae65056b53749e7c03f2498a28af2525934 Mon Sep 17 00:00:00 2001
> > From: Ioannis Panagiotis Koutsidis 
> > Date: Tue, 10 Jul 2018 20:03:21 +0300
> > Subject: [PATCH] .socket units
> >
> > ---
> >  modules/shepherd.scm |  44 +++--
> >  modules/shepherd/service.scm | 170 ++---
> >  modules/shepherd/systemd.scm | 354 ---
> >  3 files changed, 368 insertions(+), 200 deletions(-)
>
> The patch changes lots of things and unfortunately, without
> explanations, I do not understand what to do with it.  Like what’s the
> new feature?  How is it used?  What implementation choices were made?
> What’s left to be done?…
>
> Thank you,
> Ludo’.
>
>

Re: Cuirass changes

[Clément Lassieur]

Hi Ricardo,

Ricardo Wurmus  writes:

> Hi Clément,
>
> Ludovic Courtès  writes:
>
>> Lots of exciting stuff in this message!
>
> Indeed!

Thank you :-)

> I’m supportive of all of the proposed changes.  My only concern is about
> potential conflicts with Tatiana’s work on the web interface.  Do you
> think we could merge Tatiana’s patches first?

I think we should merge whichever patchset is ready first.  I will
surely help with the conflicts resolution, but it shouldn't be too
difficult, because we didn't work on the same parts.  It's a matter of
renaming a few database fields, that's all.  (There is no git conflict.)

Clément

Newbie Install Experience Report [FYI]

[Ken.Dickey]

Greetings.  

Just getting started.  Don't know enough to properly post bugs yet, but hope 
this is useful.

I really want to try out aarch64 with various (raspi3,LePotato) but decided to 
start simple with power hungry ol' x86_64.

Used:

  https://alpha.gnu.org/gnu/guix/guixsd-install-0.15.0.x86_64-linux.iso.xz


[1] Instructions pretty good but had a typo in my timezone ("config.scm"), so 
after the long, slow download process the install failed.

RECOMMEND: Timezone "preflight" check at beginning would have saved much time.

Started again from scratch.  This worked OK, but you know the download delay is 
painful.  8^|

Thanks for zile, btw [prefer mg]. Old emacs fingers...

[2] I typically multiboot but did not see how to do this easily, so allowed the 
grub install [no efi].

[3] After reboot and setting passwords, did
root> guix pull
root> guix system reconfigure

==> guix system: error: wrong number of arguments to 'reconfigure'

Tried
root> guix system reconfigure /etc/config.scm
which reported no errors.

root> guix package -i mg
root> guix package -i emacs dillo
==> guix package: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

user> guix pull && guix package -u

... on to other explorations ...


FYI,
-KenD


config.scm
Description: Lotus Screencam

Re: /dev/urandom

[Danny Milosavljevic]

Hi Mark,

those are all good points.

In this specific case the randomness is necessary for NAND wear levelling,
so getting rid of it isn't good anyhow.

I'll investigate whether there is a way to defer invocation of
the randomizer so that the user can invoke it in the installed package.


pgplD320fNBx7.pgp
Description: OpenPGP digital signature

Re: gnumaint changes

[Ludovic Courtès]

Hello Mike,

Mike Gerwitz  skribis:

> On Wed, Jun 27, 2018 at 21:40:19 -0400, Mike Gerwitz wrote:
>> I'll have to look at what guix/gnu-maintenance.scm does, but:
>
> [...]
>
>> Rather than get rid of gnupackages.txt completely, I wrote a script last
>> week to generate it from rec/gnupackages.rec.  The formats are largely
>> the same---it's possible that you can use the recfile directly.
>> However, if you still need the old format, just run
>> `make gnupackages.txt`.
>
> Ah, I see, it fetches that single file over HTTP.  Certainly running
> `make` (or the underlying gawk script) is undesirable in that situation.
>
> Can someone with more knowledge of what this is used for run a couple of
> tests to see what is broken if you use rec/gnupackages.rec instead?
> Worst case, I can commit gnupackages.txt until the script can be
> updated, but I'd prefer to keep generated files out of the repository.
>
> pkgblurbs.txt has also been replaced by rec/pkgblurbs.rec.

Commit daf76c7cd54df428abc28d490747c7f83a844df0 changes
gnu-maintenance.scm to use the .rec files.  Thanks for the heads-up.

> If anyone here also knows of any other external systems pulling from
> womb, please lmk.  I wasn't aware that anyone outside of maintainers@
> used that repo, tbh.

It’s used by ‘guix import gnu’ and ‘guix lint -c gnu-descriptions’
currently.

It’d be nice if synopses and descriptions in the Womb could contain
Texinfo markup.

In fact, perhaps it’d make sense to reverse the roles, i.e., have the
Womb take (some of its) descriptions from Guix?

Ludo’.

Re: bootstrap integration strategies

[Ludovic Courtès]

Hello Jan!

Jan Nieuwenhuizen  skribis:

> With Mes 0.16 released I felt that after two years of straight hacking
> I was pretty much done.  Hmm...
>
> On the wip-bootstrap branch we have these packages
>
> binutils-2.20.1, gcc-2.95.3, and glibc-2.2.5
>
> built without using any of these 3 main tools from the bootstrap
> binaries.
>
> Using these we have built gcc-4.1.0 and glibc-2.3.6.

I’ve said it before, but really: thumbs up to you and everyone at
#bootstrapable for getting this far!  It’s something that seemed like a
pipe dream not so long ago, so it’s really amazing that you made it a
reality.

> And the above is an over-simplification, here's the list of seeds and
> packages in order:
>
> %mescc-tools-seed
> %mes-seed
> %tinycc-seed
> mescc-tools-boot
> mes-boot
> nyacc-boot
> tcc-boot-0@0.9.26
> tcc-boot@0.9.27
> binutils-mesboot@2.20.1a
> gcc-core-mesboot@2.95.3
> glibc-mesboot@2.2.5
> gcc-mesboot0@2.95.3
> binutils-mesboot@2.20.1a
> gcc-mesboot@4.1.0
> [glibc-mesboot@2.3.6]

Is tcc-boot a seed, or is it built from source using MesCC?

> I hoped to get gcc-4.7.4 packaged easily but haven't succeeded in two
> weeks.  That means I'm stuck[0].  Much has happened: I'm helping to get
> mescc-tools, Nyacc and Mes packaged in Debian, am writing some
> documentation[1], got a preliminary hello-world on Hurd, worked on Gash[2]
> to get it on par with bournish, applied for a GNU evaluation of Mes...

Woow.

> If we get gcc-4.7.4 built for x86 that's nice, but can we bootstrap
> other architectures from that?  Do we want that?  We probably do not
> want different bootstrap paths for different architectures.  What
> about the Hurd?

I think that’s the main difficulty.  I think we’d rather not have
separate bootstrap paths for Intel GNU/Linux on one hand, and everything
else on the other hand.

Yet, we know that porting what you already did on x86-linux-gnu to
GNU/Hurd and ARMv7 and AArch64 etc. is going to be a lot of non-trivial
work (especially since historical versions of the GNU toolchain did not
support AArch64, for instance.)

Waiting for this to be “solved” (and we don’t even know how) would
equate to a status quo.  But obviously, it’d be sad to have all this
work already done on Intel and not be able to benefit from it.

So perhaps we’ll have to get over it and have a different bootstrap path
on x86-linux-gnu.

(BTW, I suspect we can get away with using 32-bit bootstrap binaries on
both i686/x86_64 and armv7/aarch64, no?)

> That is why I've also been working on Gash--Guile As SHell--by
> Rutger[cc] lately.  If we make Gash powerful enough to replace bash to
> build make and some of the other bootstrap binaries, that would be
> nice.  After a promising re-start it now proved that the heart of
> Gash, the SH grammar in PEG and its subsequent transformations needs
> an overhaul.  That's being worked on but there is not much visible
> progress.

Gash seems to be a low-hanging fruit and a relatively easy thing,
because it’s architecture-independent.  How
far is it from being able to run typical ‘configure’ scripts?

I think the day it’s able to run ‘configure’ scripts, we can switch to
it right away without further ado, and then incrementally improve it as
we stumble upon limitations and bugs.

WDYT?

> So, where to go?  Integrate the Mes x86 bootstrap and build other
> architectures on top of that (is that even possible)?  Add the Mes
> bootstrap as an additional, weird `x86-linux' architecture to mature
> first?  Add other architectures to Mes and keep one bootstrap path in
> Guix?  Finish the x86 bootstrap/gcc-4.7.4 (I need help!)?

If you’d like to take a break from the hardcode GCC bootstrap path ;-),
I think Gash for bootstrap is a good quickly-rewarding task.

There’s also another option you didn’t mention: ditching the 2.0
bootstrap Guile in favor of Mes.  That can be done in several steps:

  1. Replace the guile-2.0.*.xz binary tarballs with Mes, and add a step
 that builds Guile 2.x using our big bootstrap GCC binary.

  2. Same, but build Guile 2.x, libgc, etc. using MesCC.

This could allow us to remove quite a lot of KiBs from our binary seeds.

Thoughts?

Thank you!

Ludo’.

Re: Having a Guix archive on the download page?

[Ludovic Courtès]

Hi Pjotr,

Pjotr Prins  skribis:

> Is it an idea to also have a current Guix archive on the download
> page? Or at least a link to one?
>
>https://www.gnu.org/software/guix/download/
>
> Ever so often I need to rescue a running Guix system which won't run
> guix pull and even a build-from-source quickly. Being able to do
>
>guix archive --import < guix-latest.nar
>
> or something similar would be rather convenient. 

FWIW, this is in essence what the new ‘guix pull’ attempts to do with
the help of substitutes.

Problems about missing dependencies leading to unusable ‘guix pull’
(lack of Guile-Git, Guile-SQLite3, etc.) should now be gone because
‘guix pull’ now pulls Guix *and* its dependencies, which was not the
case before.

Now the question is, will it always be possible to run ‘guix pull’ from
an arbitrary-old Guix?  Maybe it will still be impossible sometimes if
the old Guix is really too old.  However, I suspect such issues will be
much more rare.  There’s essentially a single file that needs to be put
under scrutiny to avoid such issues: build-aux/build-self.scm.

An archive like you suggest could be useful in those hopefully rare
cases where things break, so it’s a good idea.

Ludo’.

Re: shortening the git test suite

[Ludovic Courtès]

Hello,

Mark H Weaver  skribis:

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

[...]

>> Currently if test fails, the whole derivation fails, and you can’t
>> install your package.  If tests were run separately, this would no
>> longer hold: you could get your package regardless of whether tests
>> fail.
>
> Indeed, and I agree that we would need to address this.
>
>> How would you address this?  I guess that calls for a new build
>> model, no?
>
> I'm not sure what you mean by "build model", whether you are talking
> about the daemon interface or something else, but I think the changes
> could be confined to the Guix user interface.  A field could be added to
> , somewhat similar to 'replacement', but pointing to a package
> object which runs tests, or perhaps a list of package objects.  The guix
> client could simply add the test packages to the list of derivations to
> build.  This could be inhibited via a "--no-tests" guix build option.
>
> In typical cases where "make check" expects to be run from a fully built
> source directory, the main package would typically produce a tarball of
> the built source directory as an additional output.  The test package
> would simply unpack this tarball and run "make check" in it.
>
> Regarding the build order: ideally, we would run the tests for package
> FOO immediately after building FOO, or at least before building anything
> that depends on FOO, to avoid wasted work in case the tests fail.  I'm
> not sure how best to accomplish this.
>
> What do you think?

I’m afraid doing everything at the level of package objects rather than
derivations would lead to something clunky (grafts already suffer from
that.)

Namely, Guix clients would have to explicitly do a second
‘build-derivations’ RPC once they’re done building packages.  If they
don’t do that, then tests are not run and you get to install a possibly
broken package.

Besides, there are lots of details to get right in a proposal like
yours.  In particular, saving the build tree and for later reuse may
prove to be more challenging than it seems.

IOW, this looks like a radical change with lots of potential pitfalls,
one I’d rather not make before 1.0.  I agree that long test suites can
be a problem, but for now I think we should focus on package-specific
solutions, to the extent possible, such as what we discussed for Git, as
well as improvements to our build farm infrastructure.

Thoughts?

Ludo’.

Re: Cuirass changes

[Ricardo Wurmus]

Hi Clément,

Ludovic Courtès  writes:

> Lots of exciting stuff in this message!

Indeed!

I’m supportive of all of the proposed changes.  My only concern is about
potential conflicts with Tatiana’s work on the web interface.  Do you
think we could merge Tatiana’s patches first?

-- 
Ricardo

Re: [PATCH] gnu: gzochi: Update to 0.12

[Efraim Flashner]

On Thu, Jul 05, 2018 at 11:13:49AM -0400, Julian Graham wrote:
> Hi Guix folk,
> 
> Find attached a patch that bumps the version of gzochi, a game
> development framework I maintain. I've done a `guix build' test run
> for amd64. Let me know if anything looks untoward.
> 
Patch pushed. Next time send it to guix-patc...@gnu.org :)

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: [PATCH] gnu: gzochi: Update to 0.12

[Ludovic Courtès]

Hi Julian,

Julian Graham  skribis:

> From d09752ea47bea9ef0a769e4356ffef5cf08242f8 Mon Sep 17 00:00:00 2001
> From: Julian Graham 
> Date: Thu, 5 Jul 2018 11:06:02 -0400
> Subject: [PATCH] gnu: gzochi: Update to 0.12.
>
> * gnu/packages/game-development.scm (gzochi): Update to 0.12.

Applied, thank you!  And congrats on the new Gzochi release.  :-)

Ludo’.

Re: Guix support in cachix

[Ludovic Courtès]

Hello,

Marius Bakke  skribis:

> It looks useful for those who don't want to or can't publish their own
> substitutes.  And `guix challenge` makes it easy to verify the builds
> coming from a particular "channel".

I agree that it can be useful.

I would very much like it if we had a solution that did not rely on a
central service, though.  If ‘guix publish’ could publish over
BitTorrent, say (or GNUnet, like we tried during GSoC a few years ago),
that would be awesome.

Thanks,
Ludo’.

Re: [PATCH] profiles: Let canonicalize-profile return an absolute path.

[Ludovic Courtès]

Hi Roel,

Roel Janssen  skribis:

> I'd like to change the way the symlinks to custom profiles are created.
> Here's what currently happens:
>
> $ guixr package -i hello -p guix-profiles/test
> $ ls -l guix-profiles
> lrwxrwxrwx. 1 user group 25 Jul  3 19:53 test -> guix-profiles/test-1-link
> lrwxrwxrwx. 1 user group 51 Jul  3 19:53 test-1-link -> 
> /gnu/store/...6qbaps-profile
>
> Now, that symlink is broken.
> Instead, I'd like to have it always use absolute paths:

How about instead making the link to the generation file (“test-1-link”)
always a relative symlink?  Like this:

--8<---cut here---start->8---
$ ./pre-inst-env guix package -p foo/x -i sed

[...]

$ ls -l foo/*
lrwxrwxrwx 1 ludo users  8 Jul 11 13:03 foo/x -> x-1-link
lrwxrwxrwx 1 ludo users 51 Jul 11 13:03 foo/x-1-link -> 
/gnu/store/qp6dqlbsf0pw9p9fwc3gzdcaxx40rn9v-profile
--8<---cut here---end--->8---

Patch below.

FWIW I prefer avoiding ‘canonicalize-path’ in general because it’s
inefficient and because it can surprise the user: you can end up with a
long file name that you didn’t type in, or you can have ENOENT errors
because ‘canonicalize-path’ requires the given file to exist.

WDYT?

Thanks,
Ludo’.

diff --git a/guix/profiles.scm b/guix/profiles.scm
index d2a794b18..f34f4fcff 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1521,7 +1521,7 @@ the generation that was current before switching."
   (profile profile)
   (generation number)
   (else
-   (switch-symlinks profile generation)
+   (switch-symlinks profile (basename generation))
current
 
 (define (switch-to-previous-generation profile)
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index 29829f52c..b38a55d01 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -190,7 +190,7 @@ do not treat collisions in MANIFEST as an error."
  (let* ((entries (manifest-entries manifest))
 (count   (length entries)))
(switch-symlinks name prof)
-   (switch-symlinks profile name)
+   (switch-symlinks profile (basename name))
(unless (string=? profile %current-profile)
  (register-gc-root store name))
(format #t (N_ "~a package in profile~%"
diff --git a/tests/guix-package.sh b/tests/guix-package.sh
index 3b3fa35cd..3833b568a 100644
--- a/tests/guix-package.sh
+++ b/tests/guix-package.sh
@@ -215,7 +215,7 @@ do
 guix package --bootstrap --roll-back
 ! test -f "$HOME/.guix-profile/bin"
 ! test -f "$HOME/.guix-profile/lib"
-test "`readlink "$default_profile"`" = "$default_profile-0-link"
+test "`readlink "$default_profile"`" = "`basename $default_profile-0-link`"
 done
 
 # Check whether '-p ~/.guix-profile' makes any difference.

Re: Cuirass changes

[Ludovic Courtès]

Hi Clément,

Sorry for the delay.  Lots of exciting stuff in this message!

Clément Lassieur  skribis:

> 1. Adding support for multiple inputs.  Currently Cuirass only supports
> one input per specification, which has to be the Guix git repository.
> But one might want inputs for:
>   - a repository containing the 'proc' that returns the jobs,
>   - a repository containing extra packages (GUIX_PACKAGE_PATH).
> Those inputs would be fetched at INTERVAL as well, and any change would
> trigger an evaluation.  This is a follow-up of
> https://lists.gnu.org/archive/html/guix-patches/2018-06/msg00311.html.

Excellent.  I think the polling interval should be per input, while
we’re at it.

> 2. Removing the notion of 'project'.  Cuirass really has no project, and
> what is called a 'project' is in fact a 'specification' (which Hydra
> calls 'jobset').  And what is called a 'jobset' by Cuirass is in fact
> the branch of the Guix input.  So the patch associates to the name
> 'jobset' what it really is: a specification.  A consequence is that the
> 'jobset' filtering of the API now filters by specification name, and it
> is not possible anymore to filter by branch.  (But it was useless IMHO.)

That makes sense to me.

> 3. Allowing any input to be in Guile's %load-path when 'proc' is called.
> Usually, the only input that is in Guile's %load-path is Guix.  But
> someone might want to use a custom library in 'proc'.  The alternative
> is to just specify the Guix input that should be appended to Guile's
> %load-path.
>
> (I'm unsure about 3., I can't find any real use case.  That would just
> make it more flexible I guess.)

We can also wait until there’s a real use case, it’s often a good idea.
:-)

> Also, some specification fields (#:load-path-inputs,
> #:package-path-inputs, #:proc-input) refer to the inputs by their name,
> as Hydra does (with nixExprInput).

Nice!

> This makes it easy to do configuration mistakes, and would ultimately
> require a configuration syntax checker.  The only alternative I can
> think of involves duplicating the inputs, which isn't good.

Good.

> I'm sending this email because even though the patches are already done
> and they work on my Cuirass instance, there are a few other things to do
> before I can send them:
>   - add a mechanism to update the database,
>   - update the documentation.
> So if you think I'm not on the right track, please let me know as soon
> as possible :-)

Looks like you’re on the right track.  You submitted changes to
guix-patches in the meantime so I’ll take a look at these.

> I attached my configuration before those patches and the one after them,
> so that you can see how the new configuration would look like.  The work
> in progress is available at
> https://git.lassieur.org/cgit/cuirass.git/log/.

Neat.

>  '((#:name . "guix-manifest-savannah")
>(#:load-path-inputs . ("guix"))
>(#:package-path-inputs . ("packages"))
>(#:proc-input . "conf")
>(#:proc-path . "guix/cuirass-derivations.scm")
>(#:proc . drv-list)
>(#:proc-args . ())
>(#:inputs . (((#:name . "guix")
>  (#:url . "git://git.savannah.gnu.org/guix.git")
>  (#:load-path . ".")
>  (#:branch . "master")
>  (#:no-compile? . #t))
> ((#:name . "conf")
>  (#:url . "git://git.lassieur.org/emacs.git")
>  (#:load-path . ".")
>  (#:branch . "master")
>  (#:no-compile? . #t))
> ((#:name . "packages")
>  (#:url . "git://git.lassieur.org/packages.git")
>  (#:load-path . ".")
>  (#:branch . "master")
>  (#:no-compile? . #t)

Really cool example, and exactly what we were missing from Hydra.

Thanks a lot for working on this!

Ludo’.

Re: [doc RFC] Tame the Guix profile blizzard?

[Nils Gillmann]

George Clemmer transcribed 733 bytes:
> Hi Nils,
> 
> Nils Gillmann  writes:
> 
> >   4) before each profile kind is used for the first time,
> >  make use of something like this for the brief introduction
> >  of it again (our manual is not very long, but it is still
> >  long):
> 
> I Agee.
> 
> > @cartouche
> > @quotation Note
> > In the following ``spacejump'' refers to …
> > @end quotation
> > @end cartouche
> >
> > this renders at least in HTML and PDF output of texinfo. I haven't
> > used this very much so far.
> >
> > A visual example can be found in 'Exchange', Chapter 'Configuration'
> > in https://docs.taler.net/
> 
> I assume you refer to the box that reads, "Note: The rationale behind
> having multiple bank accounts ..." and I agreed this would work well.

yes.

> - George
>