Re: 02/02: gnu: python-pillow: Update to 4.3.0.
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.
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.
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
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
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
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.
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.
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.
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
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
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
