Planning for 0.8.2

Planning for 0.8.2

[Ludovic Courtès]

It’s about time to prepare for 0.8.2.  Here’s what I think should be
completed by then:

  • ‘wip-build-systems-gexp’ merged in ‘core-updates’, although if that
    turns out to involve more work than expected, I’m happy to delay it
    until the next release.

  • New phase to validate NEEDED against RUNPATH (see
    <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20039#11>; we're
    almost there.)

  • ‘guix publish’ merged in (I think it's ready now, right?)

  • ‘guix import hackage’ and ‘haskell-build-system’.

  • LibreOffice (anyone?), Hydra(?).

  • Addressing the bug reports that have accumulated since the last
    release.  Many are packaging and usability issues that are easily
    addressed, I think.  I invite everyone to look at them.  A bug fix a
    day, keeps the doctor away!

Anything else?  What do people think?

Thanks,
Ludo’.

Re: Planning for 0.8.2

[Andreas Enge]

On Tue, Mar 31, 2015 at 05:57:20PM +0200, Ludovic Courtès wrote:
>   • LibreOffice (anyone?)

I started work on this, adding two of the prerequisites in commits c12efc7
and 97039f6. As there is a long list of dependencies, with package recipes
to be completed and updated, tests to be fixed and so on, I do not think it
will be ready for 0.8.2. (Moreover, I will not have much time over the next
two weeks. Of course, everybody is welcome to contribute to the task.)

Andreas

Re: Planning for 0.8.2

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Tue, Mar 31, 2015 at 05:57:20PM +0200, Ludovic Courtès wrote:
>>   • LibreOffice (anyone?)
>
> I started work on this, adding two of the prerequisites in commits c12efc7
> and 97039f6. As there is a long list of dependencies, with package recipes
> to be completed and updated, tests to be fixed and so on, I do not think it
> will be ready for 0.8.2.

Oh really?  The last report on wip-libreoffice, was more encouraging:

  http://lists.gnu.org/archive/html/guix-devel/2015-03/msg00340.html

Anyway, it’d be nice to have but it’s not a blocker.

Thanks,
Ludo’.

Re: Planning for 0.8.2

[Ricardo Wurmus]

Andreas Enge writes:

> On Tue, Mar 31, 2015 at 05:57:20PM +0200, Ludovic Courtès wrote:
>>   • LibreOffice (anyone?)
>
> I started work on this, adding two of the prerequisites in commits c12efc7
> and 97039f6. As there is a long list of dependencies, with package recipes
> to be completed and updated, tests to be fixed and so on, I do not think it
> will be ready for 0.8.2. (Moreover, I will not have much time over the next
> two weeks. Of course, everybody is welcome to contribute to the task.)

I would like to help with packaging dependencies.  Does someone have an
overview on what still needs to be done?  I can't take this over all by
myself and I don't want to step on other people's feet.

~~ Ricardo

Re: Planning for 0.8.2

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Andreas Enge writes:
>
>> On Tue, Mar 31, 2015 at 05:57:20PM +0200, Ludovic Courtès wrote:
>>>   • LibreOffice (anyone?)
>>
>> I started work on this, adding two of the prerequisites in commits c12efc7
>> and 97039f6. As there is a long list of dependencies, with package recipes
>> to be completed and updated, tests to be fixed and so on, I do not think it
>> will be ready for 0.8.2. (Moreover, I will not have much time over the next
>> two weeks. Of course, everybody is welcome to contribute to the task.)
>
> I would like to help with packaging dependencies.

Since it was reported that the version in wip-libreoffice builds (only
with tests disabled), I suppose all the dependencies are there.

Or am I missing something?

Ludo’.

Re: Planning for 0.8.2

[Andreas Enge]

On Thu, Apr 02, 2015 at 02:51:05PM +0200, Ludovic Courtès wrote:
> Since it was reported that the version in wip-libreoffice builds (only
> with tests disabled), I suppose all the dependencies are there.

I suppose so. But the work in wip-libreoffice is more a quick proof of
concept, getting as quickly as possible to a compiling libreoffice. For the
two dependencies I added, I needed to fill in fields (synopses and/or descrip-
tions), enable the tests and make them work, and add optional inputs (which
apparently were not needed for libreoffice, but should be there for a complete
package, that is presented to the user and not only an input to libreoffice).

As I see it, we should not simply merge the wip-libreoffice branch, but pick
up the added dependencies one by one and turn them into proper patches for
new packages.

Andreas

Re: Planning for 0.8.2

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> As I see it, we should not simply merge the wip-libreoffice branch, but pick
> up the added dependencies one by one and turn them into proper patches for
> new packages.

I see, that makes sense.

Thanks,
Ludo’.

Re: Planning for 0.8.2

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

On Mon, Apr 06, 2015 at 06:11:46PM +0200, Andreas Enge wrote:
     On Thu, Apr 02, 2015 at 02:51:05PM +0200, Ludovic Court?s wrote:
     > Since it was reported that the version in wip-libreoffice builds (only
     > with tests disabled), I suppose all the dependencies are there.
     
     I suppose so. But the work in wip-libreoffice is more a quick proof of
     concept, getting as quickly as possible to a compiling libreoffice. For the
     two dependencies I added, I needed to fill in fields (synopses and/or descrip-
     tions), enable the tests and make them work, and add optional inputs (which
     apparently were not needed for libreoffice, but should be there for a complete
     package, that is presented to the user and not only an input to libreoffice).
     
     As I see it, we should not simply merge the wip-libreoffice branch, but pick
     up the added dependencies one by one and turn them into proper patches for
     new packages.
     
I agree.  

The most problematic dependency was nss which has since been added to master.  I don't
know, but I suspect it might need tweaking to play nicely with libreoffice.

Libreoffice has some tests which run during the build phase, and others which run 
in the test phase.  It was one in the build phase that was crashing.

I didn't have a machine that was up to the job of building everything locally.  So
I had to rely on hydra.

The Libreoffice devs refused assistance after I described how Guix worked.

J'
     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Planning for 0.8.2

[Mark H Weaver]

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

> It’s about time to prepare for 0.8.2.  Here’s what I think should be
> completed by then:
>
>   • ‘wip-build-systems-gexp’ merged in ‘core-updates’, although if that
>     turns out to involve more work than expected, I’m happy to delay it
>     until the next release.
>
>   • New phase to validate NEEDED against RUNPATH (see
>     <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20039#11>; we're
>     almost there.)
>
>   • ‘guix publish’ merged in (I think it's ready now, right?)
>
>   • ‘guix import hackage’ and ‘haskell-build-system’.
>
>   • LibreOffice (anyone?), Hydra(?).
>
>   • Addressing the bug reports that have accumulated since the last
>     release.  Many are packaging and usability issues that are easily
>     addressed, I think.  I invite everyone to look at them.  A bug fix a
>     day, keeps the doctor away!
>
> Anything else?  What do people think?

I'd like to add one more item to the list:

  * Clean /var/run and /tmp at boot time.

Also, it would be nice to fix <http://bugs.gnu.org/20102> before the
0.8.2 release, since it renders Guix essentially unusable on armhf.

Is anyone willing to help with this?  As it is, I seem to be the only
person working on either MIPS or ARM.

      Mark

Re: Planning for 0.8.2

[Eric Bavier]

On 2015-03-31 10:57, ludo@gnu.org wrote:
> It’s about time to prepare for 0.8.2.  Here’s what I think should be
> completed by then:
[...]
>   • LibreOffice (anyone?), Hydra(?).

Hydra would indeed be nice to have completed.  Unfortunately there's a 
blocking license issue with one of the needed perl modules (Set::Object 
is under the Artistic1.0 license).  I've asked the 
maintainers/developers already if they'd consider upgrading to the 
Artistic2.0.  I'll ping them again to see if I can get a response.

-- 
`~Eric

Re: Planning for 0.8.2

[Mark H Weaver]

It would also be good to fix Qt-5 on i686.

     Mark

Re: Planning for 0.8.2

[Taylan Ulrich Bayırlı/Kammer]

Mark H Weaver <mhw@netris.org> writes:

> It would also be good to fix Qt-5 on i686.

I've been looking into this but didn't come very far on fixing it.

I opened a Qt bug report on it:
https://bugreports.qt.io/browse/QTBUG-45205

In short, the qtwebengine sources end up including both GL headers, and
a GLES2-specific header in the Chromium source tree.  (GL and GLES can
generally not be included at the same time.)

Taylan

Re: Planning for 0.8.2

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> It’s about time to prepare for 0.8.2.  Here’s what I think should be
> completed by then:
>
>   • ‘wip-build-systems-gexp’ merged in ‘core-updates’, although if that
>     turns out to involve more work than expected, I’m happy to delay it
>     until the next release.

This is postponed until after the release.

>   • New phase to validate NEEDED against RUNPATH (see
>     <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20039#11>; we're
>     almost there.)
>
>   • ‘guix publish’ merged in (I think it's ready now, right?)
>
>   • ‘guix import hackage’ and ‘haskell-build-system’.
>
>   • LibreOffice (anyone?), Hydra(?).

All of this is OK, except LibreOffice.

>   • Addressing the bug reports that have accumulated since the last
>     release.  Many are packaging and usability issues that are easily
>     addressed, I think.  I invite everyone to look at them.  A bug fix a
>     day, keeps the doctor away!

There are still some left, notably newly introduced ones.  :-)

For those I’ve just reopened core-updates with the intent of freezing it
in a couple of days or so.  The changes should be limited to:

  1. ld-wrapper bugs fixed (just pushed);

  2. libstdc++ not having libgcc_s in its RUNPATH (bug #20358);

  3. #:validate-runpath? turned on by default for all the build systems
     (currently it’s only gnu-build-system); more broken packages will
     become apparent as a result;

  4. libc’s own message catalogs are installed (just pushed).

I think Eric has a small Perl patch that would be welcome, but that’s
about it.

Thoughts?

Ludo’.

Re: Planning for 0.8.2

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> For those I’ve just reopened core-updates with the intent of freezing it
> in a couple of days or so.  The changes should be limited to:
>
>   1. ld-wrapper bugs fixed (just pushed);
>
>   2. libstdc++ not having libgcc_s in its RUNPATH (bug #20358);
>
>   3. #:validate-runpath? turned on by default for all the build systems
>      (currently it’s only gnu-build-system); more broken packages will
>      become apparent as a result;
>
>   4. libc’s own message catalogs are installed (just pushed).
>
> I think Eric has a small Perl patch that would be welcome, but that’s
> about it.

I’m done with these.  If everything is OK, we may want to enable the
whole set of packages for build on Hydra in the next few days (Mark?).

Ludo’.

Re: Planning for 0.8.2

[Taylan Ulrich Bayırlı/Kammer]

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

> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> For those I’ve just reopened core-updates with the intent of freezing it
>> in a couple of days or so.  The changes should be limited to:
>>
>>   1. ld-wrapper bugs fixed (just pushed);
>>
>>   2. libstdc++ not having libgcc_s in its RUNPATH (bug #20358);
>>
>>   3. #:validate-runpath? turned on by default for all the build systems
>>      (currently it’s only gnu-build-system); more broken packages will
>>      become apparent as a result;
>>
>>   4. libc’s own message catalogs are installed (just pushed).
>>
>> I think Eric has a small Perl patch that would be welcome, but that’s
>> about it.
>
> I’m done with these.  If everything is OK, we may want to enable the
> whole set of packages for build on Hydra in the next few days (Mark?).
>
> Ludo’.

There's news on the Qt 5.4/i686 front.  I applied the patch linked to in
<https://bugreports.qt.io/browse/QTBUG-45205> locally and will try
building it now, which should take ~7 hours on my machine IIRC.

Excited for the release. :-)

Taylan

Re: Planning for 0.8.2

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> For those I’ve just reopened core-updates with the intent of freezing it
> in a couple of days or so.  The changes should be limited to:
>
>   1. ld-wrapper bugs fixed (just pushed);
>
>   2. libstdc++ not having libgcc_s in its RUNPATH (bug #20358);
>
>   3. #:validate-runpath? turned on by default for all the build systems
>      (currently it’s only gnu-build-system); more broken packages will
>      become apparent as a result;
>
>   4. libc’s own message catalogs are installed (just pushed).
>
> I think Eric has a small Perl patch that would be welcome, but that’s
> about it.

I’ve just merged ‘core-updates’.

Note that there are still build failures, notably Numpy.  Please take a
look at <http://hydra.gnu.org/jobset/gnu/master> and consider squashing
the bugs.

Ludo’.

Re: Planning for 0.8.2

[Ludovic Courtès]

We’re making progress!  :-)

I am hoping to be able to release next week, sometime between the 13th
and the 16th, provided we can address the last remaining quirks
(primarily bumping the Guile requirement, and fixing a guix-daemon bug
that shows up when compiling with GCC 5, see
<https://github.com/NixOS/nix/commit/f52b6c944e90b3e35925122779175705fdc02e12>.)

I will need help from someone with an armv7 machine to produce the
tarball for that platform.  Mark, would that be OK for you?

I’d like to have the new web site installed before the release; that
seems doable.

I don’t think “we” (i.e., Mark :-)) can switch to the new hydra.gnu.org
by then, but that’ll still be perfect even if it happens later.

Thoughts?

Ludo’.

Re: Planning for 0.8.2

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:
> I will need help from someone with an armv7 machine to produce the
> tarball for that platform.  Mark, would that be OK for you?

Yes, in fact I've already created one, but I'll create another one based
on 0.8.2 when the time comes.

> I don’t think “we” (i.e., Mark :-)) can switch to the new hydra.gnu.org
> by then, but that’ll still be perfect even if it happens later.

Indeed, I ran into some difficulties with the donated hardware, and then
had to take some time off to focus on other things.

       Mark

Re: Planning for 0.8.2

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>> I will need help from someone with an armv7 machine to produce the
>> tarball for that platform.  Mark, would that be OK for you?
>
> Yes, in fact I've already created one, but I'll create another one based
> on 0.8.2 when the time comes.

Yes, the release process (which has yet to be written down) will be like
for the USB images: we create the tarball with v0.8.2 + 1 commit that
updates the ‘guix’ package.  So we will have to synchronize.

>> I don’t think “we” (i.e., Mark :-)) can switch to the new hydra.gnu.org
>> by then, but that’ll still be perfect even if it happens later.
>
> Indeed, I ran into some difficulties with the donated hardware, and then
> had to take some time off to focus on other things.

Sure, no problem!

Thanks,
Ludo’.