New release soon?

New release soon?

[swedebugia]

Hi

Considering the change to guile-gcrypt and the bugs we have found and 
fixed since 0.15 I think we should release 0.16.0 soon.

Or perhaps a maintenance 0.15.1 if the features added do not hold up to 
a minor release.

What do you think?

-- 
Cheers
Swedebugia

Re: New release soon?

[Ricardo Wurmus]

swedebugia <swedebugia@riseup.net> writes:

> Considering the change to guile-gcrypt and the bugs we have found and
> fixed since 0.15 I think we should release 0.16.0 soon.
>
> Or perhaps a maintenance 0.15.1 if the features added do not hold up
> to a minor release.
>
> What do you think?

The next release will hopefully be 1.0.0.  We wanted to get this
released sometime before FOSDEM 2019.

--
Ricardo

Re: New release soon?

[Marius Bakke]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> swedebugia <swedebugia@riseup.net> writes:
>
>> Considering the change to guile-gcrypt and the bugs we have found and
>> fixed since 0.15 I think we should release 0.16.0 soon.
>>
>> Or perhaps a maintenance 0.15.1 if the features added do not hold up
>> to a minor release.
>>
>> What do you think?
>
> The next release will hopefully be 1.0.0.  We wanted to get this
> released sometime before FOSDEM 2019.

I think it could be useful to do a 0.16 release in the interim, since
it's difficult to build 0.15 from source currently (because of the
broken Python test in 'master' which OOMs (on) many kernels).

The many "guix pull" and UI improvements would also be nice to have "out
of the box" on new installs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: New release soon?

[Ludovic Courtès]

Hi,

Marius Bakke <mbakke@fastmail.com> skribis:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> swedebugia <swedebugia@riseup.net> writes:
>>
>>> Considering the change to guile-gcrypt and the bugs we have found and
>>> fixed since 0.15 I think we should release 0.16.0 soon.
>>>
>>> Or perhaps a maintenance 0.15.1 if the features added do not hold up
>>> to a minor release.
>>>
>>> What do you think?
>>
>> The next release will hopefully be 1.0.0.  We wanted to get this
>> released sometime before FOSDEM 2019.
>
> I think it could be useful to do a 0.16 release in the interim, since
> it's difficult to build 0.15 from source currently (because of the
> broken Python test in 'master' which OOMs (on) many kernels).
>
> The many "guix pull" and UI improvements would also be nice to have "out
> of the box" on new installs.

I agreed.  I’m all for a 0.16 release within a couple of weeks.

Initially I thought we may want to wait for core-updates to be merged,
but it looks like we have troubles focusing on that ;-), so I don’t
know.  Thoughts?

Ludo’.

Re: New release soon?

[Ricardo Wurmus]

Hi,

>> I think it could be useful to do a 0.16 release in the interim, since
>> it's difficult to build 0.15 from source currently (because of the
>> broken Python test in 'master' which OOMs (on) many kernels).
>>
>> The many "guix pull" and UI improvements would also be nice to have "out
>> of the box" on new installs.
>
> I agreed.  I’m all for a 0.16 release within a couple of weeks.
>
> Initially I thought we may want to wait for core-updates to be merged,
> but it looks like we have troubles focusing on that ;-), so I don’t
> know.  Thoughts?

I would prefer to have core-updates in the next release.  This has been
delayed for much too long.  This would also avoid the bad look for a new
release to have somewhat outdated core packages.

If we can’t get core-updates ready within the next few weeks I won’t
object to a release without it, but I think we should really try.

--
Ricardo

Re: New release soon?

[Ludovic Courtès]

Heya,

Ricardo Wurmus <rekado@elephly.net> skribis:

>> Initially I thought we may want to wait for core-updates to be merged,
>> but it looks like we have troubles focusing on that ;-), so I don’t
>> know.  Thoughts?
>
> I would prefer to have core-updates in the next release.  This has been
> delayed for much too long.  This would also avoid the bad look for a new
> release to have somewhat outdated core packages.
>
> If we can’t get core-updates ready within the next few weeks I won’t
> object to a release without it, but I think we should really try.

Yes, that makes sense to me.

So everyone: let’s join forces and get ‘core-updates’ finally merged!

Ludo’.

Re: New release soon?

[Björn Höfling]

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

On Fri, 16 Nov 2018 22:20:27 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> Heya,
> 
> Ricardo Wurmus <rekado@elephly.net> skribis:
> 
> >> Initially I thought we may want to wait for core-updates to be
> >> merged, but it looks like we have troubles focusing on that ;-),
> >> so I don’t know.  Thoughts?  
> >
> > I would prefer to have core-updates in the next release.  This has
> > been delayed for much too long.  This would also avoid the bad look
> > for a new release to have somewhat outdated core packages.
> >
> > If we can’t get core-updates ready within the next few weeks I won’t
> > object to a release without it, but I think we should really try.  
> 
> Yes, that makes sense to me.
> 
> So everyone: let’s join forces and get ‘core-updates’ finally merged!

What is to do for core-updates to succeed? Is it "just" that
hydra/berlin need to build it, or is there anything a human being can
do (Or is the former necessary to define the latter?)?

Is there a list of open/unresolved tasks?

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: New release soon?

[Gábor Boskovits]

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> ezt írta (időpont:
2018. nov. 16., P, 23:06):
>
> On Fri, 16 Nov 2018 22:20:27 +0100
> ludo@gnu.org (Ludovic Courtès) wrote:
>
> > Heya,
> >
> > Ricardo Wurmus <rekado@elephly.net> skribis:
> >
> > >> Initially I thought we may want to wait for core-updates to be
> > >> merged, but it looks like we have troubles focusing on that ;-),
> > >> so I don’t know.  Thoughts?
> > >
> > > I would prefer to have core-updates in the next release.  This has
> > > been delayed for much too long.  This would also avoid the bad look
> > > for a new release to have somewhat outdated core packages.
> > >
> > > If we can’t get core-updates ready within the next few weeks I won’t
> > > object to a release without it, but I think we should really try.
> >
> > Yes, that makes sense to me.
> >
> > So everyone: let’s join forces and get ‘core-updates’ finally merged!
>
> What is to do for core-updates to succeed? Is it "just" that
> hydra/berlin need to build it, or is there anything a human being can
> do (Or is the former necessary to define the latter?)?
>
> Is there a list of open/unresolved tasks?
>

Same questions here.

> Björn

g_bor

Getting ‘core-updates’ merged

[Ludovic Courtès]

Hi!

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> skribis:

> On Fri, 16 Nov 2018 22:20:27 +0100
> ludo@gnu.org (Ludovic Courtès) wrote:
>> Ricardo Wurmus <rekado@elephly.net> skribis:

[...]

>> > I would prefer to have core-updates in the next release.  This has
>> > been delayed for much too long.  This would also avoid the bad look
>> > for a new release to have somewhat outdated core packages.
>> >
>> > If we can’t get core-updates ready within the next few weeks I won’t
>> > object to a release without it, but I think we should really try.  
>> 
>> Yes, that makes sense to me.
>> 
>> So everyone: let’s join forces and get ‘core-updates’ finally merged!
>
> What is to do for core-updates to succeed? Is it "just" that
> hydra/berlin need to build it, or is there anything a human being can
> do (Or is the former necessary to define the latter?)?
>
> Is there a list of open/unresolved tasks?

What remains to be done is mostly (1) ensuring that there’s no
significant regression in terms of build failures compared to ‘master’,
and (2) making sure GuixSD boots and works fine.

For #1, a simple test is to try and upgrade your profile and see if
everything builds and works well.  In addition, you can look at these
dashboards to identify build failures that need to be addressed:

  https://hydra.gnu.org/jobset/gnu/core-updates
  https://berlin.guixsd.org/jobset/core-updates-core-updates

For #2, running “make check-system”, or at least the inexpensive subset
of system tests (the expensive tests are the installation tests) should
give a good overview—Mark already reported an issue at
<https://issues.guix.info/issue/33362>.  The next step of course is to
try it on the bare metal for your own system config.

If we all do our share of testing, this can actually be pretty fast.
If today is a rainy day, here’s a good activity for you!  :-)

Thanks,
Ludo’.

Re: Getting ‘core-updates’ merged

[Ludovic Courtès]

Hi there!

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

> What remains to be done is mostly (1) ensuring that there’s no
> significant regression in terms of build failures compared to ‘master’,
> and (2) making sure GuixSD boots and works fine.
>
> For #1, a simple test is to try and upgrade your profile and see if
> everything builds and works well.  In addition, you can look at these
> dashboards to identify build failures that need to be addressed:
>
>   https://hydra.gnu.org/jobset/gnu/core-updates
>   https://berlin.guixsd.org/jobset/core-updates-core-updates

There are still failures out there!

  https://hydra.gnu.org/eval/110331?full=1#tabs-still-fail

The above list is slightly outdated so I’m restarting an evaluation on
hydra.gnu.org.

A prominent issue is LibreOffice:

  https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00332.html

There are also many more issues on armhf and i686 than on x86_64.

> For #2, running “make check-system”, or at least the inexpensive subset
> of system tests (the expensive tests are the installation tests) should
> give a good overview—Mark already reported an issue at
> <https://issues.guix.info/issue/33362>.  The next step of course is to
> try it on the bare metal for your own system config.

I’m running GuixSD from ‘core-updates’ and everything is working fine.
:-)  (I’m using Xorg, NM, etc., but not GNOME.)

Please check if it works for you!  We need your help!

Ludo’.

Re: Getting ‘core-updates’ merged

[Björn Höfling]

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

On Thu, 22 Nov 2018 10:41:59 +0100
ludo@gnu.org (Ludovic Courtès) wrote:


> I’m running GuixSD from ‘core-updates’ and everything is working fine.
> :-)  (I’m using Xorg, NM, etc., but not GNOME.)
> 
> Please check if it works for you!  We need your help!

I did a guix reconfigure from core-updates and it worked too (X-less
VirtualBox image). Maven compiles on core-updates.

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Getting ‘core-updates’ merged

[Ludovic Courtès]

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

> There are still failures out there!
>
>   https://hydra.gnu.org/eval/110331?full=1#tabs-still-fail
>
> The above list is slightly outdated so I’m restarting an evaluation on
> hydra.gnu.org.
>
> A prominent issue is LibreOffice:
>
>   https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00332.html

Another one is Rust 1.22.1, which is a dependency of IceCat:

  https://berlin.guixsd.org/log/7i2nmyj2nv0942mi01lz89c4kq22j5rv-rust-1.22.1

Excerpt:

--8<---------------cut here---------------start------------->8---
failures:

---- [run-make] run-make/issue-26092 stdout ----
	


error: make failed
status: exit code: 2
command: "make"
stdout:
------------------------------------------
LD_LIBRARY_PATH="/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/lib:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/deps:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib:" '/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc' --out-dir /tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu -L /tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu  -o "" blank.rs 2>&1 | \
		grep -i 'No such file or directory'

------------------------------------------
stderr:
------------------------------------------
make: *** [Makefile:4: all] Error 1

------------------------------------------

thread '[run-make] run-make/issue-26092' panicked at 'explicit panic', src/tools/compiletest/src/runtest.rs:2433:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.
--8<---------------cut here---------------end--------------->8---

Danny, does that ring a bell?

Thanks,
Ludo’.

Re: Getting ‘core-updates’ merged

[Julien Lepiller]

It.s not a reproducible failure, I built it from today's core-updates on the second try.

Le 23 novembre 2018 14:52:42 GMT+01:00, ludo@gnu.org a écrit :
>ludo@gnu.org (Ludovic Courtès) skribis:
>
>> There are still failures out there!
>>
>>   https://hydra.gnu.org/eval/110331?full=1#tabs-still-fail
>>
>> The above list is slightly outdated so I’m restarting an evaluation
>on
>> hydra.gnu.org.
>>
>> A prominent issue is LibreOffice:
>>
>>   https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00332.html
>
>Another one is Rust 1.22.1, which is a dependency of IceCat:
>
>https://berlin.guixsd.org/log/7i2nmyj2nv0942mi01lz89c4kq22j5rv-rust-1.22.1
>
>Excerpt:
>
>--8<---------------cut here---------------start------------->8---
>failures:
>
>---- [run-make] run-make/issue-26092 stdout ----
>	
>
>
>error: make failed
>status: exit code: 2
>command: "make"
>stdout:
>------------------------------------------
>LD_LIBRARY_PATH="/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/lib:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/deps:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib:"
>'/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc'
>--out-dir
>/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu
>-L
>/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu
> -o "" blank.rs 2>&1 | \
>		grep -i 'No such file or directory'
>
>------------------------------------------
>stderr:
>------------------------------------------
>make: *** [Makefile:4: all] Error 1
>
>------------------------------------------
>
>thread '[run-make] run-make/issue-26092' panicked at 'explicit panic',
>src/tools/compiletest/src/runtest.rs:2433:8
>note: Run with `RUST_BACKTRACE=1` for a backtrace.
>--8<---------------cut here---------------end--------------->8---
>
>Danny, does that ring a bell?
>
>Thanks,
>Ludo’.

Re: Getting ‘core-updates’ merged

[Danny Milosavljevic]

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

Hi Ludo,

On Fri, 23 Nov 2018 14:52:42 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> ------------------------------------------
> LD_LIBRARY_PATH="/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/lib:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/deps:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib:" '/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc' --out-dir /tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu -L /tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu  -o "" blank.rs 2>&1 | \
> 		grep -i 'No such file or directory'

> Danny, does that ring a bell?

Yes, it's a known Rust bug.  We've hit it before, see thread
"Re: 01/03: llvm: Build with RTTI by default".

Also see https://github.com/rust-lang/rust/issues/43402 (the fix is
supposed to be in 1.22.1, though).

It should work when you try again.

If someone has it fail reproducibly (or at least often enough that you can
reproduce it once), please try to invoke the command above, but without the
"grep".  It would be interesting to know what it said.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Getting ‘core-updates’ merged

[Ludovic Courtès]

Hello Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Fri, 23 Nov 2018 14:52:42 +0100
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> ------------------------------------------
>> LD_LIBRARY_PATH="/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/lib:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/deps:/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib:" '/tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc' --out-dir /tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu -L /tmp/guix-build-rust-1.22.1.drv-0/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/test/run-make/issue-26092.stage2-x86_64-unknown-linux-gnu  -o "" blank.rs 2>&1 | \
>> 		grep -i 'No such file or directory'
>
>> Danny, does that ring a bell?
>
> Yes, it's a known Rust bug.  We've hit it before, see thread
> "Re: 01/03: llvm: Build with RTTI by default".
>
> Also see https://github.com/rust-lang/rust/issues/43402 (the fix is
> supposed to be in 1.22.1, though).

It seems that this bug is not fully resolved.  Do you know how we could
skip it in the meantime?

Thanks,
Ludo’.

Re: Getting ‘core-updates’ merged

[Danny Milosavljevic]

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

Hi Ludo,

On Sun, 25 Nov 2018 16:54:53 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> It seems that this bug is not fully resolved.  Do you know how we could
> skip it in the meantime?

Yes, just try the build again.  It's a thread synchronization problem.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Getting ‘core-updates’ merged

[Danny Milosavljevic]

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

Or this:

(delete-file-recursively "src/test/run-make/issue-26092")

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Getting ‘core-updates’ merged

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Or this:
>
> (delete-file-recursively "src/test/run-make/issue-26092")

Yes, let’s do that until the underlying issue is fixed upstream, with a
link to the upstream report.

Can you take care of it?

Thanks,
Ludo’.

Re: Getting ‘core-updates’ merged

[Björn Höfling]

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

On Thu, 22 Nov 2018 10:41:59 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> There are still failures out there!
> 
>   https://hydra.gnu.org/eval/110331?full=1#tabs-still-fail
> 
> The above list is slightly outdated so I’m restarting an evaluation on
> hydra.gnu.org.

You can also compare it to master, I think this gives a better picture
than comparing two consecutive core-updates evaluations:

https://hydra.gnu.org/eval/110331?compare=master#tabs-now-fail

(Update evaluation-number when a newer evaluation is finished)

It's also worth looking at the "New jobs" tab, as new jobs can
initially fail and version-updates are handled as
old-version-out-new-version-in.

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]