Gnome-updates

Gnome-updates

[Andreas Enge]

Hi all,

the gnome-updates branch has built on x86, and compared to master, there are
not that many regressions:
   http://hydra.gnu.org/eval/108921?compare=master#tabs-now-fail
I saw a few that seem to be related to fonts and freetype, but I am not
a specialist. Do you think we could nevertheless merge back to master?
In any case, it would be nice if people who are competent in these matters
could have a look at the few remaining build failures.

Andreas

Re: Gnome-updates

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> the gnome-updates branch has built on x86, and compared to master, there are
> not that many regressions:
>    http://hydra.gnu.org/eval/108921?compare=master#tabs-now-fail

In fact this slightly overestimates the failures compared to master; in
particular, all the Octave/Fltk-related failures are already in master.

> I saw a few that seem to be related to fonts and freetype, but I am not
> a specialist. Do you think we could nevertheless merge back to master?
> In any case, it would be nice if people who are competent in these matters
> could have a look at the few remaining build failures.

Since ‘make assert-binaries-available’ passed, I went ahead and merge
the branch.

If anything goes wrong, please let us know!

Thanks,
Ludo’.

Re: Gnome-updates

[宋文武]

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

> Andreas Enge <andreas@enge.fr> skribis:
>
>> the gnome-updates branch has built on x86, and compared to master, there are
>> not that many regressions:
>>    http://hydra.gnu.org/eval/108921?compare=master#tabs-now-fail
>
> In fact this slightly overestimates the failures compared to master; in
> particular, all the Octave/Fltk-related failures are already in master.
>
>> I saw a few that seem to be related to fonts and freetype, but I am not
>> a specialist. Do you think we could nevertheless merge back to master?
>> In any case, it would be nice if people who are competent in these matters
>> could have a look at the few remaining build failures.
>
> Since ‘make assert-binaries-available’ passed, I went ahead and merge
> the branch.
Oh, luckily the merge doesn't have effect.
>
> If anything goes wrong, please let us know!
Sorry, this is still not ready yet!  I have skip a gjs test temporary,
and disable the spell plugin of gedit.  I'd continue to work on the
gnome-updates branch, and will reply to this thread when it's ok.

Re: Gnome-updates

[Ludovic Courtès]

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

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andreas Enge <andreas@enge.fr> skribis:
>>
>>> the gnome-updates branch has built on x86, and compared to master, there are
>>> not that many regressions:
>>>    http://hydra.gnu.org/eval/108921?compare=master#tabs-now-fail
>>
>> In fact this slightly overestimates the failures compared to master; in
>> particular, all the Octave/Fltk-related failures are already in master.
>>
>>> I saw a few that seem to be related to fonts and freetype, but I am not
>>> a specialist. Do you think we could nevertheless merge back to master?
>>> In any case, it would be nice if people who are competent in these matters
>>> could have a look at the few remaining build failures.
>>
>> Since ‘make assert-binaries-available’ passed, I went ahead and merge
>> the branch.
> Oh, luckily the merge doesn't have effect.
>>
>> If anything goes wrong, please let us know!
> Sorry, this is still not ready yet! 

Indeed!  I screwed things up in two ways: I didn’t revert the reverts,
meaning the merge had not effect, and because of this, I failed to
realize that things that were broken before were still broken.  My bad!

Specifically, Mark told me that at least these important packages fail
to build: evolution-data-server, gedit, gnome-control-center,
gnome-session, gtkmm, totem, mupdf.

> I have skip a gjs test temporary, and disable the spell plugin of
> gedit.  I'd continue to work on the gnome-updates branch, and will
> reply to this thread when it's ok.

OK!

Thanks, and sorry all for the mess!

Ludo’.

Re: Gnome-updates

[Ludovic Courtès]

Hello!

Regarding the gjs failure worked around by commit
63e7796f626ee40b8259ce56b93f5596e8a1f8c5, I briefly investigated.  Upon
failure, the ‘stderr.log’ file reads:

--8<---------------cut here---------------start------------->8---
Gjs-Message: JS LOG: Expected nonconst ♥ utf8 (string) but was  (string)

Stack trace follows:
JsUnitException@resource:///org/gnome/gjs/modules/jsUnit.js:272
_assert@resource:///org/gnome/gjs/modules/jsUnit.js:110
assertEquals@resource:///org/gnome/gjs/modules/jsUnit.js:147
testUtf8@/tmp/guix-build-gjs-1.44.0.drv-0/gjs-1.44.0/installed-tests/js/testEverythingBasic.js:162
gjstestRun@resource:///org/gnome/gjs/modules/jsUnit.js:438
@/tmp/guix-build-gjs-1.44.0.drv-0/gjs-1.44.0/installed-tests/js/testEverythingBasic.js:699
--8<---------------cut here---------------end--------------->8---

This corresponds to this test in ‘testEverythingBasic.js’:

--8<---------------cut here---------------start------------->8---
   function testUtf8() {
       const CONST_STR = "const \u2665 utf8";
       const NONCONST_STR = "nonconst \u2665 utf8";

       JSUnit.assertEquals(CONST_STR, Everything.test_utf8_const_return());
       JSUnit.assertEquals(NONCONST_STR, Everything.test_utf8_nonconst_return());
       Everything.test_utf8_const_in(CONST_STR);
       JSUnit.assertEquals(NONCONST_STR, Everything.test_utf8_out());
*      JSUnit.assertEquals(NONCONST_STR, Everything.test_utf8_inout(CONST_STR));
       JSUnit.assertEquals(NONCONST_STR, Everything.test_utf8_inout(CONST_STR));
       JSUnit.assertEquals(NONCONST_STR, Everything.test_utf8_inout(CONST_STR));
       JSUnit.assertEquals(NONCONST_STR, Everything.test_utf8_inout(CONST_STR));
   }
--8<---------------cut here---------------end--------------->8---

The ‘test_utf8_inout’ function is bound via ‘Regress-1.0.git’, and its
definition is in $(guix build
gobject-introspection)/share/gobject-introspection-1.0/tests/regress.c:

--8<---------------cut here---------------start------------->8---
void
regress_test_utf8_inout (char **inout)
{
  /* inout parameter, transfer mode full */
  g_assert (strcmp (*inout, utf8_const) == 0);
  g_free (*inout);
  *inout = g_strdup (utf8_nonconst);
}
--8<---------------cut here---------------end--------------->8---

… where:

--8<---------------cut here---------------start------------->8---
static const char utf8_nonconst[] = "nonconst \xe2\x99\xa5 utf8";
--8<---------------cut here---------------end--------------->8---

So it seems that it’s a failure of ‘g_strdup’, or in
‘gjs_string_from_utf8’ in jsapi-util-string.cpp.

I’ll pass it on to you or anyone else.  :-)

Ludo’.

Re: Gnome-updates

[宋文武]

Hi, I have rebase it upon mastet, update more packages to their latest,
and test on my x86_64 laptop with 'gnome-desktop-service'.
It seems work fine so far.

And here are some 'questionable' changes:

- Disable a failing rtprtx test of gst-plugins-good.
  I can pass it using `guix environment', but fail with `guix build'.

- Add xdg-desktop-database and xdg-mime-database hooks.
  I pick it from my old branch, and notice that my old code really
  requires shared-mime-info and desktop-file-utils to be installed
  explicitly..  So I factor out the 'manifest-lookup-package' proceduce
  used by gtk-icon-themes to allow find them in the propagated-inputs
  in manifest.  (or maybe I should lookup for glib?  but I think it's
  ok now since I add them to the gnome meta package)

- Drop the 'loaders.cache' file from librsvg.
  Since we have use gdk-pixbuf+svg for gtk+, gtk+ applications can use
  SVG without wrap with it.  I have tested key-mon (works), but not
  solfege (too slow to download texlive..).

- Disable the Spell plugin of gedit.
  It now needs gspell, which doesn't work due to enchant can't list
  dicts of aspell.  Report it as:
  <https://lists.gnu.org/archive/html/aspell-devel/2016-04/msg00004.html>
  (Does it works before?)

- Skip 'test_utf8_inout' of gjs.
  it fails with gobject-introspection-1.48.0, but use python3 to
  call the test in Regress.typelib will pass.  Report as:
  <https://bugzilla.gnome.org/show_bug.cgi?id=765465>
  (No one notice yet.)


Also, 1 test of libsoup on x86_64 fails (other systems fine):
 <http://hydra.gnu.org/build/1180730>.
Should we skip it, or retry the build on hydra?


I think it's time to merge if the above changes are reviewed to be ok :-)

Re: Gnome-updates

[Ludovic Courtès]

Hello!

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

> - Disable a failing rtprtx test of gst-plugins-good.
>   I can pass it using `guix environment', but fail with `guix build'.

The log for this commit contains a typo: it doesn’t mention the variable
name, only the ‘arguments’ field.  Also, could you add a comment that
says why we disable this test?

With this comment, I think it’s OK.

> - Add xdg-desktop-database and xdg-mime-database hooks.
>   I pick it from my old branch, and notice that my old code really
>   requires shared-mime-info and desktop-file-utils to be installed
>   explicitly..  So I factor out the 'manifest-lookup-package' proceduce
>   used by gtk-icon-themes to allow find them in the propagated-inputs
>   in manifest.  (or maybe I should lookup for glib?  but I think it's
>   ok now since I add them to the gnome meta package)

Sounds good, but it’s not directly related to this branch, is it?  Would
have been best to submit for inclusion in ‘master’, if possible.

At first sight these 3 patches look good.

> - Drop the 'loaders.cache' file from librsvg.
>   Since we have use gdk-pixbuf+svg for gtk+, gtk+ applications can use
>   SVG without wrap with it.  I have tested key-mon (works), but not
>   solfege (too slow to download texlive..).

OK.

> - Disable the Spell plugin of gedit.
>   It now needs gspell, which doesn't work due to enchant can't list
>   dicts of aspell.  Report it as:
>   <https://lists.gnu.org/archive/html/aspell-devel/2016-04/msg00004.html>
>   (Does it works before?)

No idea, but OK.  (Thanks for emailing the Aspell folks!)

> - Skip 'test_utf8_inout' of gjs.
>   it fails with gobject-introspection-1.48.0, but use python3 to
>   call the test in Regress.typelib will pass.  Report as:
>   <https://bugzilla.gnome.org/show_bug.cgi?id=765465>
>   (No one notice yet.)

I would prefer this one to be fixed, because it’s worrisome that such a
basic feature is broken.

The bug report above mentions a dangling pointer.  Do you have a
backtrace or something to illustrate that?  Did you set a breakpoint on
‘regress_test_utf8_inout’ or something?

> Also, 1 test of libsoup on x86_64 fails (other systems fine):
>  <http://hydra.gnu.org/build/1180730>.
> Should we skip it, or retry the build on hydra?

The failing test is:

--8<---------------cut here---------------start------------->8---
ERROR: multipart-test - exited with status 139 (terminated by signal 11?)
--8<---------------cut here---------------end--------------->8---

Signal 11 doesn’t sound good.  :-)

However, I can’t reproduce it on my machine:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build libsoup --check --no-grafts -q
/gnu/store/km0g7xmsngs1yd8ix08pkifk152qifss-libsoup-2.54.1
/gnu/store/fbq6hal96vfy556sybzwhyj879w8pgr5-libsoup-2.54.1-doc
$ git describe
v0.10.0-612-g0a24549
--8<---------------cut here---------------end--------------->8---

So unless someone can reproduce it and get more info, I’d be in favor of
retrying.

Thoughts?

Thank you,
Ludo’.

Re: Gnome-updates

[宋文武]

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

> Hello!
>
> iyzsong@member.fsf.org (宋文武) skribis:
>
>> - Disable a failing rtprtx test of gst-plugins-good.
>>   I can pass it using `guix environment', but fail with `guix build'.
>
> The log for this commit contains a typo: it doesn’t mention the variable
> name, only the ‘arguments’ field.  Also, could you add a comment that
> says why we disable this test?
>
> With this comment, I think it’s OK.
Oh, thanks!

>
>> - Add xdg-desktop-database and xdg-mime-database hooks.
>>   I pick it from my old branch, and notice that my old code really
>>   requires shared-mime-info and desktop-file-utils to be installed
>>   explicitly..  So I factor out the 'manifest-lookup-package' proceduce
>>   used by gtk-icon-themes to allow find them in the propagated-inputs
>>   in manifest.  (or maybe I should lookup for glib?  but I think it's
>>   ok now since I add them to the gnome meta package)
>
> Sounds good, but it’s not directly related to this branch, is it?  Would
> have been best to submit for inclusion in ‘master’, if possible.
Yes..
>
> At first sight these 3 patches look good.
>
>> - Drop the 'loaders.cache' file from librsvg.
>>   Since we have use gdk-pixbuf+svg for gtk+, gtk+ applications can use
>>   SVG without wrap with it.  I have tested key-mon (works), but not
>>   solfege (too slow to download texlive..).
>
> OK.
>
>> - Disable the Spell plugin of gedit.
>>   It now needs gspell, which doesn't work due to enchant can't list
>>   dicts of aspell.  Report it as:
>>   <https://lists.gnu.org/archive/html/aspell-devel/2016-04/msg00004.html>
>>   (Does it works before?)
>
> No idea, but OK.  (Thanks for emailing the Aspell folks!)
>
>> - Skip 'test_utf8_inout' of gjs.
>>   it fails with gobject-introspection-1.48.0, but use python3 to
>>   call the test in Regress.typelib will pass.  Report as:
>>   <https://bugzilla.gnome.org/show_bug.cgi?id=765465>
>>   (No one notice yet.)
>
> I would prefer this one to be fixed, because it’s worrisome that such a
> basic feature is broken.
Agree, but the only user of gjs is gnome-shell, and it seems works,
so I guess we could leave it for later?

>
> The bug report above mentions a dangling pointer.  Do you have a
> backtrace or something to illustrate that?  Did you set a breakpoint on
> ‘regress_test_utf8_inout’ or something?
No, I find it with some print functions..

>
>> Also, 1 test of libsoup on x86_64 fails (other systems fine):
>>  <http://hydra.gnu.org/build/1180730>.
>> Should we skip it, or retry the build on hydra?
>
> The failing test is:
>
> ERROR: multipart-test - exited with status 139 (terminated by signal 11?)
>
> Signal 11 doesn’t sound good.  :-)
>
> However, I can’t reproduce it on my machine:
>
> $ ./pre-inst-env guix build libsoup --check --no-grafts -q
> /gnu/store/km0g7xmsngs1yd8ix08pkifk152qifss-libsoup-2.54.1
> /gnu/store/fbq6hal96vfy556sybzwhyj879w8pgr5-libsoup-2.54.1-doc
> $ git describe
> v0.10.0-612-g0a24549
>
> So unless someone can reproduce it and get more info, I’d be in favor of
> retrying.
OK.


Thanks for the review.
I have rebase it upon master again with the one log change but
leave out the poppler CVE-2015-8868 fix (it's in 0.42.0) in master.
(I can't use force push so I delete and push it again..)

Re: Gnome-updates

[Leo Famulari]

On Mon, May 02, 2016 at 10:47:16PM +0800, 宋文武 wrote:
> Thanks for the review.
> I have rebase it upon master again with the one log change but
> leave out the poppler CVE-2015-8868 fix (it's in 0.42.0) in master.
> (I can't use force push so I delete and push it again..)

I'm just joining this conversation. Do you want me to commit a different
poppler bug-fix to gnome-updates? That could be the branch where we
"undo" this graft.

Re: Gnome-updates

[宋文武]

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

Current poppler is 0.42.0 in gnome- updates, I think when merge back into master, with conflict resolved it will undo the graft.  Do you mean we resolve it explicitly in gnome-updates? That's better, thanks!  And perhaps we could update it to the lastest 0.43.0?

[-- Attachment #2: Type: text/html, Size: 266 bytes --]

Re: Gnome-updates

[Efraim Flashner]

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

On Tue, May 03, 2016 at 12:38:58AM +0000, 宋文武 wrote:
> Current poppler is 0.42.0 in gnome- updates, I think when merge back into master, with conflict resolved it will undo the graft.  Do you mean we resolve it explicitly in gnome-updates? That's better, thanks!  And perhaps we could update it to the lastest 0.43.0?

IIRC odd numbers in gnome are development snapshots

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

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

Re: Gnome-updates

[Leo Famulari]

On Tue, May 03, 2016 at 08:32:29PM +0300, Efraim Flashner wrote:
> On Tue, May 03, 2016 at 12:38:58AM +0000, 宋文武 wrote:
> > Current poppler is 0.42.0 in gnome- updates, I think when merge back into master, with conflict resolved it will undo the graft.  Do you mean we resolve it explicitly in gnome-updates? That's better, thanks!  And perhaps we could update it to the lastest 0.43.0?
> 
> IIRC odd numbers in gnome are development snapshots

This page describes 0.43.0 as stable:

https://poppler.freedesktop.org/

"The latest stable release is poppler-0.43.0.tar.xz, released on April
28, 2016"

Re: Gnome-updates

[Ludovic Courtès]

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

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

[...]

>>> - Skip 'test_utf8_inout' of gjs.
>>>   it fails with gobject-introspection-1.48.0, but use python3 to
>>>   call the test in Regress.typelib will pass.  Report as:
>>>   <https://bugzilla.gnome.org/show_bug.cgi?id=765465>
>>>   (No one notice yet.)
>>
>> I would prefer this one to be fixed, because it’s worrisome that such a
>> basic feature is broken.
> Agree, but the only user of gjs is gnome-shell, and it seems works,
> so I guess we could leave it for later?

Hmm OK, let’s do it this way.

It might be worth providing more details in the bug report above, such
as the method you used to find out about the dangling pointer, and a
specific script to illustrate “I also use python3 with pygobject…”.
Just to give upstream an incentive to investigate.  :-)

> I have rebase it upon master again with the one log change but
> leave out the poppler CVE-2015-8868 fix (it's in 0.42.0) in master.
> (I can't use force push so I delete and push it again..)

It’s building now.  Once most of it is built on x86_64, we should look
at the diff against master in Hydra and check for any regressions.

Thanks!

Ludo’.

Re: Gnome-updates

[Andreas Enge]

On Tue, May 03, 2016 at 01:35:49PM +0200, Ludovic Courtès wrote:
> It’s building now.  Once most of it is built on x86_64, we should look
> at the diff against master in Hydra and check for any regressions.

There is a problem with a simple solution, I think:
   http://hydra.gnu.org/build/1187760/nixlog/1/tail-reload
failed to download "/gnu/store/bwm6p3sv4msi3nswrsvrkl6ji1ykd08i-mate-themes-gtk3.20-1.12.2.tar.xz"
The themes have apparently moved to a different directory:
   http://pub.mate-desktop.org/releases/themes/3.20/
But the file name has also changed, so I do not know which would be the
appropriate version.
In case someone is interested, there is a new release 1.14 of mate.

Apart from that, things look mostly good:
   http://hydra.gnu.org/eval/108936?compare=master
aseprite has a problem with freetype.
ghc-memory fails a test, which causes more ghc-* failures.
Some perl modules fail.

Andreas

gnome-updates

[Ludovic Courtès]

Hello Kei,

kei@openmailbox.org (Kei Kebreau) skribis:

> kkebreau pushed a change to branch gnome-updates
> in repository guix.

I don’t see a ‘gnome-updates’ jobset on hydra.gnu.org.  Is anyone taking
care of it?  It would be nice to merge this branch eventually.  :-)

Thanks,
Ludo’.

Re: gnome-updates

[Marius Bakke]

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

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Kei,
>
> kei@openmailbox.org (Kei Kebreau) skribis:
>
>> kkebreau pushed a change to branch gnome-updates
>> in repository guix.
>
> I don’t see a ‘gnome-updates’ jobset on hydra.gnu.org.  Is anyone taking
> care of it?  It would be nice to merge this branch eventually.  :-)

It looks like this branch cherry-picked a bunch of commits from
'master' instead of merging them. I don't think we should merge them
back to prevent all the duplicate commits, and in particular commit
signatures.

Instead I merged an older revision of this branch to 'staging' and
cherry-picked the latest patches. @Leo, are you able to start it later
today? Please wait for a mesa update, coming soonish :-)

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

Re: gnome-updates

[Leo Famulari]

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

On Sun, May 14, 2017 at 05:35:15PM +0200, Marius Bakke wrote:
> Instead I merged an older revision of this branch to 'staging' and
> cherry-picked the latest patches. @Leo, are you able to start it later
> today? Please wait for a mesa update, coming soonish :-)

Started!

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

Re: gnome-updates

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Sun, May 14, 2017 at 05:35:15PM +0200, Marius Bakke wrote:
>> Instead I merged an older revision of this branch to 'staging' and
>> cherry-picked the latest patches. @Leo, are you able to start it later
>> today? Please wait for a mesa update, coming soonish :-)
>
> Started!

Leo: Can you restart the 'staging' evaluation? Let's try to get it in
'master' before core-updates starts rolling.

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

Re: gnome-updates

[Leo Famulari]

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

On Wed, May 24, 2017 at 10:17:22PM +0200, Marius Bakke wrote:
> Leo Famulari <leo@famulari.name> writes:
> 
> > On Sun, May 14, 2017 at 05:35:15PM +0200, Marius Bakke wrote:
> >> Instead I merged an older revision of this branch to 'staging' and
> >> cherry-picked the latest patches. @Leo, are you able to start it later
> >> today? Please wait for a mesa update, coming soonish :-)
> >
> > Started!
> 
> Leo: Can you restart the 'staging' evaluation? Let's try to get it in
> 'master' before core-updates starts rolling.

Done!

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