Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Leo Famulari]

On Sun, Dec 24, 2017 at 06:16:29PM -0500, Kei Kebreau wrote:
> I've attempted to use the upstream patch, but it involves some GIT
> binaries which aren't supported by GNU patch. Among other hackish
> options, temporarily upgrading to the appropriate upstream commit may
> fix this for now.

Does it work if you pass '--binary' to patch-flags?


signature.asc
Description: PGP signature

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Kei Kebreau]

Mark H Weaver  writes:

> Kei Kebreau  writes:
>
>> Mark H Weaver  writes:
>>
>>> kkebr...@posteo.net (Kei Kebreau) writes:
>>>
 kkebreau pushed a commit to branch master
 in repository guix.

 commit 9e3a8ed0ebc5b4095f1b64d85fd56ce7fb636580
 Author: Kei Kebreau 
 Date:   Mon Dec 4 17:56:37 2017 -0500

 gnu: python-pillow: Update to 4.3.0.
>>>
>>> This new version seems to deterministically fail its test suite on i686:
>>>
>>>   https://hydra.gnu.org/build/2400760
>>>   https://hydra.gnu.org/build/2400819
>>>
>>> I restarted both of these, and they each failed again the second time.
>>> The same builds (python-pillow and python2-pillow) also failed on armhf,
>>> although as I write this they have not yet completed their second build
>>> attempts.
>
> The (new) failure on armhf also appears to be consistent, although
> different from the i686 failure.  Instead of a failed test, the build
> times out after 1 hour of silence during the test suite:
>
>   https://hydra.gnu.org/build/2400971
>
> Running selftest:
> --- 57 tests passed.
> ...S...S..SS.SS...S..SS.S.SS.S.building
>  of `/gnu/store/cjinxvws27bwdwn7n2fab3k10had6y2p-python2-pillow-4.3.0.drv' 
> timed out after 3600 seconds of silence
> @ build-failed 
> /gnu/store/cjinxvws27bwdwn7n2fab3k10had6y2p-python2-pillow-4.3.0.drv - timeout
>
>> I'm investigating now. Thanks for the heads up.
>
>  Thanks!
>Mark

The i686 failure is possibly related to this bug:
https://github.com/python-pillow/Pillow/issues/2758

I've attempted to use the upstream patch, but it involves some GIT
binaries which aren't supported by GNU patch. Among other hackish
options, temporarily upgrading to the appropriate upstream commit may
fix this for now.

As for the armhf build, I'm still not sure what is going on.


signature.asc
Description: PGP signature

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Mark H Weaver]

Kei Kebreau  writes:

> Mark H Weaver  writes:
>
>> kkebr...@posteo.net (Kei Kebreau) writes:
>>
>>> kkebreau pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit 9e3a8ed0ebc5b4095f1b64d85fd56ce7fb636580
>>> Author: Kei Kebreau 
>>> Date:   Mon Dec 4 17:56:37 2017 -0500
>>>
>>> gnu: python-pillow: Update to 4.3.0.
>>
>> This new version seems to deterministically fail its test suite on i686:
>>
>>   https://hydra.gnu.org/build/2400760
>>   https://hydra.gnu.org/build/2400819
>>
>> I restarted both of these, and they each failed again the second time.
>> The same builds (python-pillow and python2-pillow) also failed on armhf,
>> although as I write this they have not yet completed their second build
>> attempts.

The (new) failure on armhf also appears to be consistent, although
different from the i686 failure.  Instead of a failed test, the build
times out after 1 hour of silence during the test suite:

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

--8<---cut here---start->8---
Running selftest:
--- 57 tests passed.
...S...S..SS.SS...S..SS.S.SS.S.building
 of `/gnu/store/cjinxvws27bwdwn7n2fab3k10had6y2p-python2-pillow-4.3.0.drv' 
timed out after 3600 seconds of silence
@ build-failed 
/gnu/store/cjinxvws27bwdwn7n2fab3k10had6y2p-python2-pillow-4.3.0.drv - timeout
--8<---cut here---end--->8---

> I'm investigating now. Thanks for the heads up.

 Thanks!
   Mark

Re: Removing configure option for Gnuastro 0.5

[Leo Famulari]

On Sun, Dec 24, 2017 at 08:53:28PM +0100, Mohammad Akhlaghi wrote:
> Hi Leo,
> 
> Thanks a lot of applying the configuration change.
> 
> 
> On December 24, 2017 8:28:43 PM GMT+01:00, Leo Famulari  
> wrote:
> 
> >I notice our package is using libjpeg-8, while we also have libjpeg-9
> >available. Gnuastro seems to build fine with libjpeg-9, but I don't
> >know
> >how to actually test it. Do you know if we can use libjpeg-9 for our
> >Gnuastro packaging?
> 
> There shouldn't be any problem with libjpeg-9. 
> 
> Several tests of libjpeg are made during "make check". So if nothing fails 
> there, then Gnuastro has used libjpeg-9 properly. Maybe this is the simplest 
> test.

Okay, thanks for the info.

I've updated our package with commit
09c9fe4a77e93949cdb51ff0be330650aa1a0486:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=09c9fe4a77e93949cdb51ff0be330650aa1a0486


signature.asc
Description: PGP signature

Re: Removing configure option for Gnuastro 0.5

[Mohammad Akhlaghi]

Hi Leo,

Thanks a lot of applying the configuration change.


On December 24, 2017 8:28:43 PM GMT+01:00, Leo Famulari  
wrote:

>I notice our package is using libjpeg-8, while we also have libjpeg-9
>available. Gnuastro seems to build fine with libjpeg-9, but I don't
>know
>how to actually test it. Do you know if we can use libjpeg-9 for our
>Gnuastro packaging?

There shouldn't be any problem with libjpeg-9. 

Several tests of libjpeg are made during "make check". So if nothing fails 
there, then Gnuastro has used libjpeg-9 properly. Maybe this is the simplest 
test.

Thanks again,
Mohammad

Re: Removing configure option for Gnuastro 0.5

[Leo Famulari]

On Sat, Dec 23, 2017 at 04:37:51PM +0100, Mohammad Akhlaghi wrote:
> Dear Guix developers,
> 
> This is Mohammad Akhlaghi, the maintainer of GNU Astronomy Utilities.
> 
> Gnuastro 0.5 was just released and since it is also packaged in Guix, I
> wanted to let you know that the `--enable-bin-op-alltypes' configure time
> option is now removed (it was added with the 0.3 release).
> 
> You kindly added this configure time option after my request in June 2017
> (link below). I now found a good way to solve the problem, so this option is
> also removed.
> 
> http://lists.gnu.org/archive/html/guix-devel/2017-06/msg00172.html

Thanks for the reminder!

I notice our package is using libjpeg-8, while we also have libjpeg-9
available. Gnuastro seems to build fine with libjpeg-9, but I don't know
how to actually test it. Do you know if we can use libjpeg-9 for our
Gnuastro packaging?


signature.asc
Description: PGP signature

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Kei Kebreau]

Mark H Weaver  writes:

> Hi Kei,
>
> kkebr...@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 9e3a8ed0ebc5b4095f1b64d85fd56ce7fb636580
>> Author: Kei Kebreau 
>> Date:   Mon Dec 4 17:56:37 2017 -0500
>>
>> gnu: python-pillow: Update to 4.3.0.
>
> This new version seems to deterministically fail its test suite on i686:
>
>   https://hydra.gnu.org/build/2400760
>   https://hydra.gnu.org/build/2400819
>
> I restarted both of these, and they each failed again the second time.
> The same builds (python-pillow and python2-pillow) also failed on armhf,
> although as I write this they have not yet completed their second build
> attempts.
>
> Altogether, this caused around 150 new dependency failures:
>
>   https://hydra.gnu.org/eval/109866#tabs-now-fail
>
> See below for the tail of one of the i686 build logs.
>
> Could you take a look?
>
>Mark
>
> FAIL: TestFontPcf.test_high_characters
> --
> Traceback (most recent call last):
>   File 
> "/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/test_font_pcf.py",
>  line 62, in test_high_characters
> self._test_high_characters(message.encode('latin1'))
>   File 
> "/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/test_font_pcf.py",
>  line 55, in _test_high_characters
> self.assert_image_equal(image, compare)
>   File 
> "/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/helper.py", 
> line 85, in assert_image_equal
> msg or "got size %r, expected %r" % (a.size, b.size))
> AssertionError: Tuples differ: (775, 22) != (765, 22)
>
> First differing element 0:
> 775
> 765
>
> - (775, 22)
> ?   ^
>
> + (765, 22)
> ?   ^
>  : got size (775, 22), expected (765, 22)
>  >> begin captured logging << 
> PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
> PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 2644
> PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
> PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 1400
> PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
> PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 2644
> PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
> PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 1400
> - >> end captured logging << -
>
> --
> Ran 1085 tests in 4.238s
>
> FAILED (SKIP=116, failures=1)
> phase `check-installed' failed after 8.9 seconds
> builder for 
> `/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv' failed 
> with exit code 1
> @ build-failed 
> /gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv - 1 
> builder for 
> `/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv' failed 
> with exit code 1

I'm investigating now. Thanks for the heads up.


signature.asc
Description: PGP signature

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Mark H Weaver]

Hi Kei,

kkebr...@posteo.net (Kei Kebreau) writes:

> kkebreau pushed a commit to branch master
> in repository guix.
>
> commit 9e3a8ed0ebc5b4095f1b64d85fd56ce7fb636580
> Author: Kei Kebreau 
> Date:   Mon Dec 4 17:56:37 2017 -0500
>
> gnu: python-pillow: Update to 4.3.0.

This new version seems to deterministically fail its test suite on i686:

  https://hydra.gnu.org/build/2400760
  https://hydra.gnu.org/build/2400819

I restarted both of these, and they each failed again the second time.
The same builds (python-pillow and python2-pillow) also failed on armhf,
although as I write this they have not yet completed their second build
attempts.

Altogether, this caused around 150 new dependency failures:

  https://hydra.gnu.org/eval/109866#tabs-now-fail

See below for the tail of one of the i686 build logs.

Could you take a look?

   Mark


--8<---cut here---start->8---
FAIL: TestFontPcf.test_high_characters
--
Traceback (most recent call last):
  File 
"/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/test_font_pcf.py",
 line 62, in test_high_characters
self._test_high_characters(message.encode('latin1'))
  File 
"/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/test_font_pcf.py",
 line 55, in _test_high_characters
self.assert_image_equal(image, compare)
  File 
"/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/helper.py", line 
85, in assert_image_equal
msg or "got size %r, expected %r" % (a.size, b.size))
AssertionError: Tuples differ: (775, 22) != (765, 22)

First differing element 0:
775
765

- (775, 22)
?   ^

+ (765, 22)
?   ^
 : got size (775, 22), expected (765, 22)
 >> begin captured logging << 
PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 2644
PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 1400
PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 2644
PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 1400
- >> end captured logging << -

--
Ran 1085 tests in 4.238s

FAILED (SKIP=116, failures=1)
phase `check-installed' failed after 8.9 seconds
builder for 
`/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv' failed 
with exit code 1
@ build-failed 
/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv - 1 builder 
for `/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv' 
failed with exit code 1
--8<---cut here---end--->8---

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Mark H Weaver]

kkebr...@posteo.net (Kei Kebreau) writes:

> kkebreau pushed a commit to branch master
> in repository guix.
>
> commit 9e3a8ed0ebc5b4095f1b64d85fd56ce7fb636580
> Author: Kei Kebreau 
> Date:   Mon Dec 4 17:56:37 2017 -0500
>
> gnu: python-pillow: Update to 4.3.0.

This new version seems to deterministically fail its test suite on i686:

  https://hydra.gnu.org/build/2400760
  https://hydra.gnu.org/build/2400819

I restarted both of these, and they each failed twice.  The same builds
(python-pillow and python2-pillow) also failed on armhf, although as I
write this they have not yet completed their second build attempts.

Altogether, this caused around 150 new dependency failures:

  https://hydra.gnu.org/eval/109866#tabs-now-fail

See below for the tail of one of the i686 build logs.

Could you take a look?

   Mark


--8<---cut here---start->8---
FAIL: TestFontPcf.test_high_characters
--
Traceback (most recent call last):
  File 
"/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/test_font_pcf.py",
 line 62, in test_high_characters
self._test_high_characters(message.encode('latin1'))
  File 
"/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/test_font_pcf.py",
 line 55, in _test_high_characters
self.assert_image_equal(image, compare)
  File 
"/tmp/guix-build-python-pillow-4.3.0.drv-0/Pillow-4.3.0/Tests/helper.py", line 
85, in assert_image_equal
msg or "got size %r, expected %r" % (a.size, b.size))
AssertionError: Tuples differ: (775, 22) != (765, 22)

First differing element 0:
775
765

- (775, 22)
?   ^

+ (765, 22)
?   ^
 : got size (775, 22), expected (765, 22)
 >> begin captured logging << 
PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 2644
PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 1400
PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 2644
PIL.PngImagePlugin: DEBUG: STREAM b'IHDR' 16 13
PIL.PngImagePlugin: DEBUG: STREAM b'IDAT' 41 1400
- >> end captured logging << -

--
Ran 1085 tests in 4.238s

FAILED (SKIP=116, failures=1)
phase `check-installed' failed after 8.9 seconds
builder for 
`/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv' failed 
with exit code 1
@ build-failed 
/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv - 1 builder 
for `/gnu/store/74g32xnyc7zzang94ji4jh1xbiqmcjks-python-pillow-4.3.0.drv' 
failed with exit code 1
--8<---cut here---end--->8---

GNOME on Wayland current status

[Rutger Helling]

Hello Guix,

As discussed in patch #29758 I've tried GNOME on Wayland on the 
different display managers.


SDDM: Should work, just pick the "GNOME (on Wayland)" session.
SLiM: Doesn't seem to work. I'm not sure if SLiM has support for Wayland 
sessions at all.

I couldn't get GDM to start, so I don't know if that works or not.

Note that you can use the following command to manually start GNOME on 
Wayland:

XDG_SESSION_TYPE=wayland dbus-run-session gnome-session

This seems to require that you've started GNOME via a display manager 
first though.

Re: code review

[Catonano]

2017-09-12 21:35 GMT+02:00 Christopher Baines :

> On Mon, 11 Sep 2017 22:10:22 +0200
> Catonano  wrote:
>
> > I could use some code review on my Trytond service hypothesis
> >
> > As far as I understand, there are 2 steps that need to be done in
> > order for a Trytond service to be usable.
> >
> > 1) as the "postgres" role (that is as the operating system "postgres"
> > user), create a "tryton" role
> >
> > 2) as the tryton user (hence under the tryton role) run the Tryton
> > initialization script (trytond-admin -c  -d  > name> --all)
> >
> > I feel like I should extend the postgresql service in order to create
> > te trytond role but I don't know how
>
> I don't think there is any current approach for doing this.
>
> Service extension could be one way of doing it. It's similar to how
> other services in Guix interact with each other.
>
> However, I believe creating a role can only be done when the PostgreSQL
> server is running, which means that you'd need to defer creating the
> role until that point. Keeping this in a single shepherd service might
> not be easy to implement, and even if you did, there are some usability
> issues, e.g. if you add a new service to the system, and that service
> also extends PostgreSQL, then you might run in to trouble creating the
> role for the new service, without needlessly restarting the PostgreSQL
> service in the process.
>
> One approach I've implemented and used [1] is to do create roles for
> PostgreSQL when you start the service that uses that role.
>

Yes, I'll work on this approach from now on


>
> I also remember Ludo suggesting using additional services to handle
> this kind of setup, which I understood to be something like a
> tryton-postgresql-role shepherd service, which the tryton shepherd
> service would require.
>

I attempted this but my trytond-postgres-role-service-type doesn't extend
shepherd-root-service-type

I chose not to extend shepherd-root-service-type because the trytond role
doesn't require a daemon running
It has to be created one off (una tantum) so, I tought, a simple activation
will do

But now, the trytond-service-type (in charge of running the trytond daemon)
should require trytond-postgres-role among its dependencies but there is NO
sheperd service provisioning a postgres role

So this is what I end up with (when testing the system with the marionette
machinery)

srfi/srfi-1.scm:640:9: In procedure for-each:
srfi/srfi-1.scm:640:9: Throw to key `srfi-34' with args `(#)'.
make: *** [Makefile:5295: check-system] Error 1


Should I make the trytond-postgres-role a sheperd service ?
Admittedly I don't like the idea

So, I'm thinking, I'll get back to creating the postgres role upon
activation of the trytond-service-type

I failed to foresee this issue so I wasted some work :-/

The branch is here, should anyone want to take a look (pay attention, I
rebase carelessly)
https://gitlab.com/humanitiesNerd/guix-hacks