Re: 04/04: gnu: guix: Add dependency on Guile-Git.

[Mark H Weaver]

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

> civodul pushed a commit to branch master
> in repository guix.
>
> commit 9ca8aa38ecce0b0651a0ff394ee4ce32bdd0bb41
> Author: Ludovic Courtès 
> Date:   Fri Jul 28 17:52:21 2017 +0200
>
> gnu: guix: Add dependency on Guile-Git.

Hydra has failed to build the updated 'guile-git' twice in a row on
i686, so now it's no longer possible to build 'guix' for i686:

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

Obviously this is very bad for i686 users, so we'll need to revert these
changes if it can't be fixed soon.

  Mark

Re: Using scheme-memcached with Guile

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> I noticed recently that there is a scheme client for Memcached [1], I
> was looking at how this can be used with Guile, with the intention of
> packaging it for Guix.

Ian Price can probably answer.  :-)

There’s also a memcached client in Andy’s Fibers, which might be of
interest:

  https://github.com/wingo/fibers/wiki/Manual#Memcached

HTH,
Ludo’.

Re: revert perl-5.26.0 update?

[Ludovic Courtès]

Hi Leo,

Leo Famulari  skribis:

> On Thu, Jul 27, 2017 at 11:03:50AM +0200, Ludovic Courtès wrote:
>> Reverting is not an option at this point IMO.  There are several Date::*
>> modules required by Biber that FTBFS and need an update, indeed, but I
>> think we should rather find a way to fix them (I spent a bit of time on
>> it but then moved on to something else.)
>
> I've got the Date::* modules building with the attached patch series.

Woow, impressive patch set!  At first sight the 26 patches look
reasonable to me, so I would suggest pushing them, along with the
biber-next@2.7 update you mentioned.

As for biber itself, perhaps the best option is to make biber-next the
new biber?  I don’t use it so I can’t really tell whether there’d be
undesirable consequences.

Another option might be to mass-escape left braces in the Biber code,
but that’s probably not that easy…

Thoughts?

Anyway, this patch series probably closes the main blocker for
core-updates no?

Thanks,
Ludo’.

Re: Thunderbird

[ng0]

What I mean is, I'd rather want to have the input and opinions
of our community than of many others I've already read.

I could include everything from here 
https://git.parabola.nu/abslibre.git/tree/nonprism/icedove
which fits for us, but I don't want to include more patches and substitutions 
than necessary.

ng0 transcribed 2.5K bytes:
> Hi,
> 
> Adonay Felipe Nogueira transcribed 1.2K bytes:
> > The existence of Icedove and absense of Thunderbird in the following
> > places tell me that the major issues aren't solved yet:
> > 
> > - [[https://www.parabola.nu/packages/?q=thunderbird]].
> > 
> > -
> >   [[https://devel.trisquel.info/trisquel/package-helpers/tree/flidas]]. 
> > Flidas
> >   is the codename of the upcoming Trisquel 8.
> > 
> > - [[https://directory.fsf.org/wiki/Icedove]]. Also,
> >   [[https://directory.fsf.org/wiki/Thunderbird]] redirects to the first
> >   one.
> > 
> > As a plus, go to
> > [[https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines]],
> > and *search* for Thunderbird (the links to it in the table of contents
> > don't work well, you have to search for it).
> 
> Which major issues? I asked for issues which might exists,
> the libreplanet.org wiki is notoriously lacking content most
> of the time or lagging behind and directory.fsf.org isn't
> up to date aswell for most of the software present there.
> 
> I'd like to get input on this mailinglist what you consider
> to be major (and minor) issues.
> 
> Just for the libreplanet list:
> "Problem: Recommends non-free software (extensions) and non-free 
> searchplugins. "
> This is the one problem I am going to address which I know of and it is easy
> to fix in the package receipe.
> -- 
> ng0
> GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
> GnuPG: https://n0is.noblogs.org/my-keys
> https://www.infotropique.org https://krosos.org



-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org


signature.asc
Description: PGP signature

Re: Thunderbird

[ng0]

Hi,

Adonay Felipe Nogueira transcribed 1.2K bytes:
> The existence of Icedove and absense of Thunderbird in the following
> places tell me that the major issues aren't solved yet:
> 
> - [[https://www.parabola.nu/packages/?q=thunderbird]].
> 
> -
>   [[https://devel.trisquel.info/trisquel/package-helpers/tree/flidas]]. Flidas
>   is the codename of the upcoming Trisquel 8.
> 
> - [[https://directory.fsf.org/wiki/Icedove]]. Also,
>   [[https://directory.fsf.org/wiki/Thunderbird]] redirects to the first
>   one.
> 
> As a plus, go to
> [[https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines]],
> and *search* for Thunderbird (the links to it in the table of contents
> don't work well, you have to search for it).

Which major issues? I asked for issues which might exists,
the libreplanet.org wiki is notoriously lacking content most
of the time or lagging behind and directory.fsf.org isn't
up to date aswell for most of the software present there.

I'd like to get input on this mailinglist what you consider
to be major (and minor) issues.

Just for the libreplanet list:
"Problem: Recommends non-free software (extensions) and non-free searchplugins. 
"
This is the one problem I am going to address which I know of and it is easy
to fix in the package receipe.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org


signature.asc
Description: PGP signature

Re: Thunderbird

[Adonay Felipe Nogueira]

The existence of Icedove and absense of Thunderbird in the following
places tell me that the major issues aren't solved yet:

- [[https://www.parabola.nu/packages/?q=thunderbird]].

-
  [[https://devel.trisquel.info/trisquel/package-helpers/tree/flidas]]. Flidas
  is the codename of the upcoming Trisquel 8.

- [[https://directory.fsf.org/wiki/Icedove]]. Also,
  [[https://directory.fsf.org/wiki/Thunderbird]] redirects to the first
  one.

As a plus, go to
[[https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines]],
and *search* for Thunderbird (the links to it in the table of contents
don't work well, you have to search for it).

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: [PATCH] gnu: Add openfoam

[Paul Garlick]

Hello Ludo,
> I think it might make sense to create a new “simulation” module, and
> eventually move OpenCascade there as well, WDYT?
> 
Sure.  I will create a new module and put the OpenFOAM package
definition in there as the first one.
> Some comments:
> 
> 
> > 
> > +(build-system trivial-build-system)
> > 

> 
> 
> Did you consider using ‘gnu-build-system’?  I think this would save
> quite a few lines corresponding to the initial setup (set-paths, unpack,
> patch-shebang, etc.), and also ensure that the final phases (strip,
> compress-documentation, etc.) are run.  In addition you wouldn’t need to
> list all the usual build inputs (GCC, Coreutils, Make, etc.).  WDYT?
> 

I did consider both options, removing and modifying stages in the gnu-
build-system or starting from scratch with the trivial-build-system.  I
can give the gnu-build-system option a go, reverting to the trivial-
build-system if the new attempt proves too troublesome.  
One aspect I will need to investigate in the gnu-build-system is using
the "./Allwmake" command to trigger the build process.  In OpenFOAM,
wmake is short for "wrapped-make" and the package has its own
configuration step.  In brief, it has its own sequence and does not
follow the standard "./configure && make && make install" steps.
Using the trivial-build-system the patch-shebang section is indeed a
little extended.  I found this was necessary to avoid a failure of the
patch-shebang command using a simple 'find-files "."' from top-level
directory.  There is a scenario where sub-directories named '0', in the
'tutorials' directory, identified by the find-files command, being
passed to 'patch-shebang', which should only receive files, not
directories.  This causes 'patch-shebang' to stop and the build fails.
> > 
> > +  )
> > +)
> > +   )
> > + )
> > 

> 
> 
> Please listen to what ‘guix lint’ has to say about these.  :-)
> 

Interestingly, 'guix lint' let me get away with this without making
comment.  However, I shall condense things accordingly in the new
patch.
> What about wrapping the resulting binaries so that they have
> ‘FOAM_INST_DIR’ set to %output?
> 
> 

In fact, FOAM_INST_DIR is used in multiple places to navigate around
the installed files (not just the binaries), so I think this variable
may need to remain available as is.
> 
> You could make it “if true”, thereby avoiding the need to define
> $READLINE_ROOT.
> 
> 

Could you elaborate on this idea a little?  At the moment the test is
"if file exists".
> Could you send an updated patch to guix-patc...@gnu.org, where it will
> , where it will
> be visible in the patch tracker?
> 
> 
> 

Aha, a new system!
Best,
Paul.

Re: Latest guile-daemon changes and bewilderment

[Caleb Ristvedt]

> Is there a line above or below the backtrace mentioning the uncaught
> exception?  Could you ‘strace -f’ the daemon process?

No, no line above or below. Very strange.

> BTW, I see the code uses ‘clone’ directly.  It would be safer to use
> ‘call-with-container’, which already handles bind mounts, non-local
> exits, and so on.  Would it be an option?

There are a couple of issues with using call-with-container. In
decreasing order of perceived difficulty to solve:

1. Copying the output from the build to the real store. How would that
work? It wouldn't work with call-with-container - the container can't
access the outside world, and the chroot directory is automatically
deleted once the scope of the container is left. On top of that, there's
no guarantee that anything inside the chroot directory is visible
outside of the container namespace, since it's on a separate filesystem
mounted in that separate namespace.

The primary solution I have in mind for this is to add a separate
procedure argument to call-with-container (maybe "use-output"?) to be
run after the main thunk has finished running but before the temporary
directory has been deleted and which takes the chroot directory as its
only argument. Also to change the mounting of a tmpfs on the chroot dir
to happen before the clone, and explicitly unmount it after running the
aforementioned use-output thunk.

2. Some MS_PRIVATE stuff. Cleaning up will fail when whatever filesystem
the chroot directory is on is mounted as MS_SHARED, which according to a
comment in build.cc is what systemd mounts stuff as. (I'm curious why we
don't seem to have run into this issue yet, perhaps I have misunderstood
something)

My solution here is to change the propagation type of the chroot
directory inside the namespace to MS_PRIVATE. Anything mounted under it
will inherit that propagation type and not appear mounted in the
original namespace, and unmounting the chroot directory should work
fine.

3. Miscellaneous order changes. I don't know enough about the inner
workings of linux to be completely sure to what extent the order of some
operations is significant.

4. Minor differences. For example, the C++ daemon doesn't currently
bind-mount /dev/ptmx or /dev/fuse or /dev/console. I don't think those
would be a problem, but I dunno.

... and then I paused writing this for 2 days while I checked whether my
in-theory solutions would work in practice. And it seems like they
actually do (see recent branch update). Mostly. I need to figure out why
it fails when a new user namespace is created - for some reason
pivot-root fails when new-root was mounted from a different user
namespace.

But on the bright side, it somehow solved the bug I described earlier. I
still haven't managed to make it all the way to building hello (a
libunistring test hangs), but it's getting much farther.


> Regarding scanning, (guix build grafts) contains a special-purpose
> reference scanner that Mark carefully optimized; it might be worth
> looking at.

Huh. I did not know that. In hindsight, it seems obvious that there must
have been something like that for grafts to function. I'll look into
that.

>> You'll notice that among the environment variables is
>> GUILE_AUTO_COMPILE=0. This is actually something I added myself because
>> for some reason the bootstrap guile wasn't honoring the
>> --no-auto-compile flag, but does honor the environment
>> variable. Strange.
>
> Yeah, we shouldn’t add this environment variable to derivations because
> that would influence everything that goes in there.

Aye, it was mostly just for debugging. That problem has also disappeared
with the switch to using call-with-container. It's nice and all, but I
do wish I knew what caused it.

> Could it be that ‘argv’ lacked the executable name as argv[0], and thus
> the argument list was shifted to the left?

That's what I thought too, but the same behavior happened when adding
the executable name explicitly as the first argument both to system* and
execl.

> Let’s maybe try to further debug this interactively on IRC.

... and then I promptly fell asleep and spent the next few days
(nights?) tinkering. Oops.

Oh well, there will be no shortage of debugging to be done. It seems
like that's going to be the pattern for the near future - add an
isolation mechanism or something that conforms better to what is
currently done, try to build stuff, get a bit farther, look for more
stuff to fix.

- reepca

Re: Open MPI keeps references to GCC, GFortran, etc.

[Ludovic Courtès]

Hi,

Dave Love  skribis:

> Ludovic Courtès  writes:
>
>> Hello,
>>
>> Open MPI retains references to GCC, GFortran, etc., which significantly
>> increases its closure size.
>
> My query about cycles from separating the lib output was from looking at
> basically this.  There should be a runtime package for compute nodes and
> a development one (as "openmpi" and "openmpi-devel" in Fedora).

Interesting.  It’s not a “should” though IMO, in the sense that we add
additional inputs only when we have a good reason to do so.  For
example, in most cases, a “doc” output would only save you a few KiB of
man pages, representing .1% of the package size, so we don’t add a “doc”
output in those cases.  This is different from the Fedora/Debian
approach where packages are systematically split in several outputs.
The “Submitting Patches” section of the manual mentions this.

In the case of Open MPI, adding a “lib” output wouldn’t help: “out”
would still refer to gfortran via ‘ompi_info’, and “lib” would refer to
gfortran via opal_config.h.  Hence my suggestion to simply remove the
reference to gfortran & co.

> [It's not the only example of monstrous dependencies I've noticed
> trying to build things.]

Yeah I think it’s easy to overlook this when working on packages, but we
should constantly pay attention to this with ‘guix size’.

>> The references come from cpp macros such as OMPI_FC_ABSOLUTE (absolute
>> file name of the Fortran compiler), defined in opal_config.h and
>> returned by command-line tools ‘ompi_info’ and ‘oshmem_info’.
>
> I'm confused what the wrappers are doing,

The two commands return the actual compiler names, not the names of
wrappers:

--8<---cut here---start->8---
$ $(guix build openmpi)/bin/ompi_info

[...]

  C compiler: gcc
 C compiler absolute: 
/gnu/store/zlyn8z138s2vv86bdx9d72kchjczv0xn-gcc-5.4.0/bin/gcc
  C compiler family name: GNU
  C compiler version: 5.4.0
C++ compiler: g++
   C++ compiler absolute: 
/gnu/store/zlyn8z138s2vv86bdx9d72kchjczv0xn-gcc-5.4.0/bin/g++
   Fort compiler: gfortran
   Fort compiler abs: 
/gnu/store/vcx02xlp6s92bxrcafnpw7hnqa4kc32b-gfortran-5.4.0/bin/gfortran
 Fort ignore TKR: yes (!GCC$ ATTRIBUTES NO_ARG_CHECK ::)
--8<---cut here---end--->8---

AIUI, this is “purely informational”.  Replacing the absolute file names
with just the base name won’t break anything.  Except that there’s
always the possibility of scripts or tools out there parsing the output
of ‘ompi_info’.  Thus my question was: do people really parse the output
of these commands, or can we safely assume that third-party programs
don’t rely on these absolute file names?

> I was intending to look at parameterizing the build on gfortran version,

I suppose you could to:

  (define openmpi-with-gfortran7
(package
  (inherit openmpi)
  (name "openmpi-gfortran7")
  (inputs `(("gfortran" ,gfortran-7)
,@(alist-delete "gfortran" (package-inputs openmpi))

(That said, if the .mod files are compatible among gfortran versions, it
probably doesn’t make sense to do this.)

WDYT?

Ludo’.