bug#43565: cuirass: Fibers scheduling blocked.

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> In cuirass/utils.scm:
>>320:22  1 (_)
>> In unknown file:
>>0 (make-stack #t)
>> ERROR: In procedure make-stack:
>> In procedure struct-vtable: Wrong type argument in position 1 (expecting 
>> struct): #f
>
> I think this error is caused by setting:
>
>   ;; STORE's socket is O_NONBLOCK but since we're
>   ;; not in a fiber, disable Fiber's handlers.
>   (current-read-waiter #f)
>   (current-write-waiter #f)
>
>
> where it should be:
>
>   ;; STORE's socket is O_NONBLOCK but since we're
>   ;; not in a fiber, disable Fiber's handlers.
>   (current-read-waiter
>(lambda (port)
>  (port-poll port "r")))
>   (current-write-waiter
>(lambda (port)
>  (port-poll port "w")))

Ooh, good catch.

> then this should also be done in "fetch-inputs" that is using non
> blocking ports outside of Fibers.
>
> However, I still have the following error:
>
> In ice-9/boot-9.scm:
>   1731:15 17 (with-exception-handler # …)
>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> In ice-9/eval.scm:
> 619:8 15 (_ #(#(#(#(#)) …) …))
> In unknown file:
>   14 (_ # …)
>   13 (partition # …)
> In guix/store.scm:
>1008:0 12 (valid-path? # "/…")
> 2020-11-19T11:47:23 Failed to compute metric average-eval-build-start-time 
> (1).
>717:11 11 (process-stderr # _)
> In guix/serialization.scm:
> 76:12 10 (read-int #)
> In ice-9/suspendable-ports.scm:
>307:17  9 (get-bytevector-n # 8)
> 2020-11-19T11:47:23 Failed to compute metric average-eval-build-complete-time 
> (1).
> 2020-11-19T11:47:23 Failed to compute metric evaluation-completion-speed (1).
>284:18  8 (get-bytevector-n! # #vu8(0 …) …)
> 67:33  7 (read-bytes # #vu8(0 0 0 0 0 …) …)
> In fibers/internal.scm:
> 402:6  6 (suspend-current-fiber _)
> In ice-9/boot-9.scm:
>   1669:16  5 (raise-exception _ #:continuable? _)
>   1764:13  4 (_ #<&compound-exception components: (#<&error> #<&orig…>)
> In cuirass/utils.scm:
> 319:8  3 (_ _ . _)
> In ice-9/boot-9.scm:
>   1731:15  2 (with-exception-handler # …)
> In cuirass/utils.scm:
>320:22  1 (_)
> In unknown file:
>0 (make-stack #t)
> ERROR: In procedure make-stack:
> Attempt to suspend fiber within continuation barrier
>
> that originates from "valid-path?" in "restart-builds", not sure how to
> fix it yet.

I think that’s because of the ‘partition’ call: ‘partition’ is currently
implemented in C and the stack cannot be captured if it contains C calls
in the middle.

The simplest fix is probably to have a Scheme implementation:

diff --git a/src/cuirass/base.scm b/src/cuirass/base.scm
index 5a0c826..99a17fa 100644
--- a/src/cuirass/base.scm
+++ b/src/cuirass/base.scm
@@ -632,6 +632,21 @@ This procedure is meant to be called at startup."
  db "UPDATE Builds SET status = 4 WHERE status = -2 AND timestamp < "
  (- (time-second (current-time time-utc)) age) ";")))
 
+(define (partition pred lst)
+  ;; Scheme implementation of SRFI-1 'partition' so stack activations can be
+  ;; captured via 'abort-to-prompt'.
+  (let loop ((lst   lst)
+ (pass '())
+ (fail '()))
+(match lst
+  (()
+   (values (reverse pass) (reverse fail)))
+  ((head . tail)
+   (let ((pass? (pred head)))
+ (loop tail
+   (if pass? (cons head pass) pass)
+   (if pass? fail (cons head fail
+
 (define (restart-builds)
   "Restart builds whose status in the database is \"pending\" (scheduled or
 started)."

It’s a bummer that one has to be aware of all these implementation
details when using Fibers.  The vision I think is that asymptotically
these issues would vanish as more things move from C to Scheme.

Thanks,
Ludo’.

bug#44758: doc: build system arguments #:modules and #:imported-modules are not documented

[Stefan]

Hi!

The build system arguments #:modules and #:imported-modules are not documented.

They are at least evaluated by the gnu-build-system, probably by even more 
build systems. I think the trivial-build-system only accepts a #:modules 
argument.

Further it seems important to also document %gnu-build-system-modules (and 
maybe others?) and its use inside #:important-modules.

The cookbook neither mentions one of these arguments.


Bye

Stefan

bug#44745: tests/lint.scm fails building guix with guile-2.2

[zimoun]

Hi Vagrant,

On Thu, 19 Nov 2020 at 16:35, Vagrant Cascadian  wrote:

> test-name: archival: missing content
> location: /build/guix-EdK9LP/guix-1.2.0~rc2/tests/lint.scm:921
> source:
> + (test-assert
> +   "archival: missing content"
> +   (let* ((origin
> +(origin
> +  (method url-fetch)
> +  (uri "http://example.org/foo.tgz";)
> +  (sha256 (make-bytevector 32
> +  (warnings
> +(with-http-server
> +  '((404 "Not archived."))
> +  (parameterize
> +((%swh-base-url (%local-url)))
> +(check-archival
> +  (dummy-package "x" (source origin)))
> + (warning-contains? "not archived" warnings)))
> actual-value: #f
> actual-error:
> + (keyword-argument-error
> +   # headers decode-body? streaming? request)>
> +   "Unrecognized keyword"
> +   ()
> +   (#:verify-certificate?))
> result: FAIL
>

I remember issues fixed by 722ad41c44a499d2250c79527ef7d069ca728de0
which maybe introduce a regression for Guile 2.2.

--8<---cut here---start->8---
+;; XXX: Work around a bug in Guile 3.0.2 where #:verify-certificate? would
+;; be ignored ().
+(define* (http-get* uri #:rest rest)
+  (apply http-request uri #:method 'GET rest))
+(define* (http-post* uri #:rest rest)
--8<---cut here---end--->8---

Maybe it is related.


All the best,
simon

bug#44751: tests/swh.scm hangs building guix with guile-2.2

[zimoun]

Hi Vagrant,

On Thu, 19 Nov 2020 at 17:52, Vagrant Cascadian  wrote:

> I'm exploring building with guile 2.2 because guile-gnutls built with
> guile 3.0 is only available in experimental, and even there, missing for
> arm64.
>
> FAIL: tests/swh.scm - lookup-origin

I remember issues fixed by 722ad41c44a499d2250c79527ef7d069ca728de0
which maybe introduce a regression for Guile 2.2.

--8<---cut here---start->8---
+;; XXX: Work around a bug in Guile 3.0.2 where #:verify-certificate? would
+;; be ignored ().
+(define* (http-get* uri #:rest rest)
+  (apply http-request uri #:method 'GET rest))
+(define* (http-post* uri #:rest rest)
+  (apply http-request uri #:method 'POST rest))
--8<---cut here---end--->8---

Maybe it is related.

All the best,
simon

bug#44760: Closure copy in ‘guix system init’ is inefficient

[Ludovic Courtès]

‘guix system init’ ends by copying the system’s closure from the “host”
store to the target store; it also initializes the database of that
target store.

That copy is inefficient for several reasons.  Let’s pick one file,
shred.1.gz, that ends up being copied, and let’s look at its occurrences
in the strace log of ‘guix system init config.scm /tmp/os’:

--8<---cut here---start->8---
$ grep -A2 '/shred.1.gz' ,,s
lstat("/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 {st_mode=S_IFREG|0444, st_size=1490, ...}) = 0
openat(AT_FDCWD, 
"/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 O_RDONLY) = 15
fstat(15, {st_mode=S_IFREG|0444, st_size=1490, ...}) = 0
openat(AT_FDCWD, 
"/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 O_WRONLY|O_CREAT|O_TRUNC, 0444) = 16
read(15, 
"\37\213\10\0\0\0\0\0\2\3\215VMs\3336\20\275\363Wluh\354\251L%vg\322:M"..., 
8192) = 1490
write(16, 
"\37\213\10\0\0\0\0\0\2\3\215VMs\3336\20\275\363Wluh\354\251L%vg\322:M"..., 
1490) = 1490
--
utimensat(AT_FDCWD, 
"/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 [{tv_sec=1605721025, tv_nsec=616985411} /* 2020-11-18T18:37:05.616985411+0100 
*/, {tv_sec=1, tv_nsec=0} /* 1970-01-01T01:00:01+0100 */], 0) = 0
lstat("/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/sleep.1.gz",
 {st_mode=S_IFREG|0444, st_size=813, ...}) = 0
openat(AT_FDCWD, 
"/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/sleep.1.gz",
 O_RDONLY) = 15
--
lstat("/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 {st_mode=S_IFREG|0444, st_size=1490, ...}) = 0
lstat("/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shuf.1.gz",
 {st_mode=S_IFREG|0444, st_size=972, ...}) = 0
lstat("/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/sleep.1.gz",
 {st_mode=S_IFREG|0444, st_size=813, ...}) = 0
--
lstat("/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 {st_mode=S_IFREG|0444, st_size=1490, ...}) = 0
openat(AT_FDCWD, 
"/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 O_RDONLY) = 17
lseek(17, 0, SEEK_CUR)  = 0
read(17, 
"\37\213\10\0\0\0\0\0\2\3\215VMs\3336\20\275\363Wluh\354\251L%vg\322:M"..., 
1490) = 1490
--
lstat("/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 {st_mode=S_IFREG|0444, st_size=1490, ...}) = 0
openat(AT_FDCWD, 
"/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 O_RDONLY) = 17
lseek(17, 0, SEEK_CUR)  = 0
read(17, 
"\37\213\10\0\0\0\0\0\2\3\215VMs\3336\20\275\363Wluh\354\251L%vg\322:M"..., 
1490) = 1490
--
link("/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shred.1.gz",
 
"/tmp/os/gnu/store/.links/0w0qcs5lp36i89yry91r2ixlghihzf0vc56bpd9yylj342gv82xl")
 = 0
lstat("/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shuf.1.gz",
 {st_mode=S_IFREG|0444, st_size=972, ...}) = 0
openat(AT_FDCWD, 
"/tmp/os/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share/man/man1/shuf.1.gz",
 O_RDONLY) = 17
--8<---cut here---end--->8---

First, /tmp/os/…/shred.1.gz is read entirely twice: once in
‘register-items’ (in the ‘nar-sha256’ call) to compute its hash, and a
second time for deduplication (the ‘deduplicate’ call in there.)

The ‘nar-sha256’ call could be avoided because the database of
/gnu/store contains that value.  As for deduplication, we could perhaps
create those ‘.links’ entries as we copy files instead of re-traversing
the whole thing afterwards.

Second, all of /tmp/os is traversed to reset timestamps, although we
could have cleared those timestamps when we created those files in the
first place ( prevents that though,
unless we keep a bug-fixed copy of ‘copy-recursively’ in there.)

Third, in the case of the installer, we’re really copying from
/mnt/guix-inst/store to /mnt/gnu/store, which is likely the same
device.  In this case we could create hard links instead of actually
copying files.

Fourth, we’re adding items one by one in the target store database, but
it may be more efficient to more or less dump the subset of the source
database in bulk.

Surely we can do better.

Ludo’.

bug#44735: gilbc of the running system got wiped while building a package, system broken

[Ludovic Courtès]

Hi Stefan,

Stefan  skribis:

> I found the root cause of this issue: I made a typo and inadvertently did a 
> “./configure --localstatedir=/vaar”.

Ouch.  :-/

Your store database may no longer be in sync with your actual store so
you may have to reinstall.  You can try ‘guix gc --verify’ to get an
idea of how bad the situation is.

> The manual should warn that using a wrong (or omitted) --localstatedir may 
> destroy the guix installation and possibly the whole guix system.
>
> What can be done to prevent that a simple mistake like this destroys a system?

./configure warns or errors out and the manual warns in a couple of
places too, but evidently it remains too easy to shoot oneself in the
foot.

Could you check ‘config.log’ to see what ‘configure’ said?  You can see
the source of this check at the bottom of ‘m4/guix.m4’.

Also, why did you run guix-daemon from your checkout?  This is only
necessary if you’re actually hacking on the daemon, but perhaps the
manual is misleading.  (Hadn’t you run guix-daemon from the checkout,
the problem would not have occurred, even with a wrong
‘--localstatedir’.)

Thanks,
Ludo’.

bug#44745: tests/lint.scm fails building guix with guile-2.2

[Ludovic Courtès]

Hi,

zimoun  skribis:

> I remember issues fixed by 722ad41c44a499d2250c79527ef7d069ca728de0
> which maybe introduce a regression for Guile 2.2.
>
> +;; XXX: Work around a bug in Guile 3.0.2 where #:verify-certificate? would
> +;; be ignored ().
> +(define* (http-get* uri #:rest rest)
> +  (apply http-request uri #:method 'GET rest))
> +(define* (http-post* uri #:rest rest)
>
> Maybe it is related.

Yeah, #:verify-certificate? is new in 3.0.x:

  https://git.savannah.gnu.org/cgit/guile.git/tree/NEWS#n599

Vagrant, perhaps the simplest option for you would be to skip these
tests.  There’s no rush but I think we’ll remove 2.2 support in the
not-too-distant future.

Ludo’.

bug#44756: racket-7.9-src.tgz hash mismatch

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Mark,

Mark H Weaver 写道：
Racket fails to build, due to a hash mismatch on the source 
tarball.


‘Fixed’ in c57157b89a56d33c76492a1fce1e521f00859f2a.

Thanks!

T G-R


signature.asc
Description: PGP signature

bug#42342: PATCH [0/2] Update wine to 5.21

[Leo Prikler]

Hi Guix,

the following patch updates wine to version 5.21.  An attempt is also
made to fix #42342 by copying wine32 libraries into wine64.

Regards, Leo

bug#44735: gilbc of the running system got wiped while building a package, system broken

[Stefan]

Hi Ludo’!

> Your store database may no longer be in sync with your actual store so
> you may have to reinstall.  You can try ‘guix gc --verify’ to get an
> idea of how bad the situation is.

stefan@guix ~/development/guix$ guix gc --verify
reading the store...
checking path existence...
path `/gnu/store/1kh1p8ypgn1yn826cc0mizw7gjjn5yfb-usbutils-012-guile-builder' 
disappeared, removing from database...
path `/gnu/store/da76qwnqrfravn2qd92b6vk5inp7273v-vala-0.44.5.drv' disappeared, 
removing from database...
path `/gnu/store/iq987sfc1bwyaijckagv59b0z2z3c4nb-vala-0.44.5.drv' disappeared, 
removing from database...
path 
`/gnu/store/m7l8381hqz4dgp12v9fbnf0k9n1ij5ja-module-import-compiled-guile-builder'
 disappeared, removing from database...
path 
`/gnu/store/mnhh9m6v88zk9k7lc6hj15db40qv5cnh-guix-packages-base-modules-builder'
 disappeared, removing from database...
path `/gnu/store/nal2ssav0z0qk523w5v6xp2vfqqfpc13-guix-module-union-builder' 
disappeared, removing from database...
path `/gnu/store/x5gczh79g5aarws1xgkcp2gc1av4fzas-vala-0.44.5.tar.xz.drv' 
disappeared, removing from database…

stefan@guix ~/development/guix$ guix gc --verify
reading the store...
checking path existence…

stefan@guix ~/development/guix$

That doesn’t seem to be so bad. :-)

> ./configure warns or errors out and the manual warns in a couple of
> places too, but evidently it remains too easy to shoot oneself in the
> foot.

It warns in the chapter “2 Requirements”. It doesn’t warn in chapter ”14.1 
Building from Git”.

Anyway, it was just a typo. Even if I would have known about that warning, this 
would have happened. 

> Could you check ‘config.log’ to see what ‘configure’ said?  You can see
> the source of this check at the bottom of ‘m4/guix.m4’.

I retried:

stefan@guix ~/development/guix [env]$ ./configure --localstatedir=/vaar
checking for a BSD-compatible install... 
/gnu/store/5hj9mdr79nqfcqg9hb45dpfrrs5qqrnr-profile/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... 
/gnu/store/5hj9mdr79nqfcqg9hb45dpfrrs5qqrnr-profile/bin/mkdir -p
checking for gawk… gawk

[pages of checking]

checking the current installation's localstatedir... /var
configure: WARNING: chosen localstatedir '/vaar' does not match that of the 
existing installation '/var'
configure: WARNING: installing may corrupt /gnu/store!
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating po/guix/Makefile.in
config.status: creating po/packages/Makefile.in
config.status: creating etc/guix-daemon.cil
config.status: creating guix/config.scm
config.status: creating etc/committer.scm
config.status: creating test-env
config.status: creating pre-inst-env
config.status: creating nix/config.h
config.status: nix/config.h is unchanged
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po/guix/POTFILES
config.status: creating po/guix/Makefile
config.status: creating po/packages/POTFILES
config.status: creating po/packages/Makefile
stefan@guix ~/development/guix [env]$ 

Indeed, there in all that pages of output, luckily on the last page, there is a 
warning. I could have noticed it. But I did’t. Red colour could have helped. :-)

The same warning is hidden inside the very middle of the config.log. At least 
the mistake with localstatedir is visible right at its beginning. 

Would it be possible to do that check right at the beginning of configure and 
ask the user for confirmation?

> Also, why did you run guix-daemon from your checkout?  This is only
> necessary if you’re actually hacking on the daemon, but perhaps the
> manual is misleading.  (Hadn’t you run guix-daemon from the checkout,
> the problem would not have occurred, even with a wrong
> ‘--localstatedir’.)

I was trying to add a build side module into guix/build. This failed all the 
time with an error “no code for module”. As neither #:modules nor 
#:imported-modules are documented (see also 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44758), I was a bit clueless. Then 
I found out, that I have to add the module into Makefile.am and have to run 
configure. And there the typo happened. But still this was’t working and I 
thought that I may need to start the daemon with pre-inst-env to have the 
GUILE_LOAD_PATH properly point to guix/build. Well, and so the disaster 
happened.


Bye

Stefan

bug#22129: python-matplotlib: Non-deterministic build failures on armhf

[Maxim Cournoyer]

Hello Mark,

Mark H Weaver  writes:

> Over the last month, the 'python-matplotlib' build on armhf has failed
> non-deterministically 4 times due to timeout (1 hour of silence) in the
> same place:
>
> phase `install' succeeded after 71.4 seconds
> starting phase `install-doc'
> Running Sphinx v1.2.3
> Initializing GitHub plugin
> loading pickled environment... failed: [Errno 2] No such file or directory: 
> '/tmp/nix-build-python-matplotlib-1.4.3.drv-0/matplotlib-1.4.3/doc/build/doctrees/environment.pickle'
> [autosummary] generating autosummary for: api/afm_api.rst, 
> api/animation_api.rst, api/api_changes.rst, api/artist_api.rst, 
> api/axes_api.rst, api/axis_api.rst, api/backend_bases_api.rst, 
> api/backend_gtkagg_api.rst, api/backend_pdf_api.rst, 
> api/backend_qt4agg_api.rst, ..., users/recipes.rst, users/screenshots.rst, 
> users/shell.rst, users/style_sheets.rst, users/text_intro.rst, 
> users/text_props.rst, users/tight_layout_guide.rst, 
> users/transforms_tutorial.rst, users/usetex.rst, users/whats_new.rst
> Failed to import 'matplotlib.backends.backend_wxagg': no module named 
> matplotlib.backends.backend_wxagg
> Failed to import 'matplotlib.backends.backend_qt4agg': no module named 
> matplotlib.backends.backend_qt4agg
> animation, api, axes_grid, color, event_handling, images_contours_and_fields, 
> lines_bars_and_markers, misc, mplot3d, pie_and_polar_charts, pylab_examples, 
> shapes_and_collections, showcase, specialty_plots, statistics, style_sheets, 
> subplots_axes_and_figures, tests, text_labels_and_annotations, 
> ticks_and_spines, units, user_interfaces, widgets, 
> building [html]: targets for 127 source files that are out of date
> updating environment: 607 added, 0 changed, 0 removed
> reading sources... [  0%] api/afm_api
> reading sources... [  0%] api/animation_api
> reading sources... [  0%] api/api_changes
> reading sources... [  0%] api/artist_api
> reading sources... [  0%] api/axes_api
> reading sources... [  0%] api/axis_api
> reading sources... [  1%] api/backend_bases_api
> reading sources... [  1%] api/backend_gtkagg_api
> reading sources... [  1%] api/backend_pdf_api
> reading sources... [  1%] api/backend_qt4agg_api
> reading sources... [  1%] api/backend_wxagg_api
> reading sources... [  1%] api/cbook_api
> reading sources... [  2%] api/cm_api
> reading sources... [  2%] api/collections_api
> building of 
> `/gnu/store/0hm09h6a4469z3j2r3p7cm6jiwidm3ff-python-matplotlib-1.4.3.drv' 
> timed out after 3600 seconds of silence
> @ build-failed 
> /gnu/store/0hm09h6a4469z3j2r3p7cm6jiwidm3ff-python-matplotlib-1.4.3.drv - 
> timeout
> guix build: error: build failed: build of 
> `/gnu/store/0hm09h6a4469z3j2r3p7cm6jiwidm3ff-python-matplotlib-1.4.3.drv' 
> failed
>
> In all four cases, the timeout occurred in the same place, after
> printing "reading sources... [ 2%] api/collections_api".
>
> The same builds succeeded on later attempts, e.g.:
>
>   http://hydra.gnu.org:3000/build/864760#tabs-buildsteps
>
>   Mark

I've made a couple Python reproducibility enhancements on the
core-updates branch (commits c94a2864d4 and cf495c934e), which allowed
python-matplotlib to be built reproducibly.

The CI doesn't know of any recent failure for the package on armhf-linux
(see:
http://ci.guix.gnu.org/search?query=python-matplotlib%20system:armhf-linux&border-low-id=2144656).

Closing.

Thank you for the report!

Maxim

bug#44769: [staging] gst-plugins-bad fails tests on aarch64, armhf, i686

[Marius Bakke]

Hello Guix,

gst-plugins-bad fails its test suite on anything other than x86_64-linux.

Upstream issues:

  i686: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1463
  aarch64: 
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1464

(I believe the i686 issue affects armhf too)

This issue is currently holding up merging of 'staging' because
gst-plugins-bad is a dependency of 'cheese', which is a dependency of
'gnome'.

To move on with the merge, I wonder whether to:

1. Disable the affected tests, as upstream does not seem terribly
   concerned.
2. Drop 'cheese' from 'gnome'.

I'm leaning towards 2, as the AArch64 failure looks kind of serious.
Unfortunately 'cheese' does seem to require gst-plugins-bad.

Thoughts?


signature.asc
Description: PGP signature

bug#44773: guix pull does not support transformation options but claims to

[pelzflorian (Florian Pelz)]

Running `guix pull --help-transform' displays all the usual
transformation options, but when I try to use any, it reports an
unrecognized option.

It would be nice if I could use `guix pull --without-tests=glib' since
tests time out on my (somewhat slow) Beaglebone Black.

Regards,
Florian

bug#44773: guix pull does not support transformation options but claims to

[pelzflorian (Florian Pelz)]

On Sat, Nov 21, 2020 at 01:09:49AM +0100, pelzflorian (Florian Pelz) wrote:
> It would be nice if I could use `guix pull --without-tests=glib' since
> tests time out on my (somewhat slow) Beaglebone Black.

P.S. --without-tests=glib does not work for 1.2.0 anyway though
because glib was only fixed for core-updates
.
I don’t know if fixing `guix pull` transformation options would aid
pulls to core-updates though.