Mate fails to build on i686-linux

  • Open
  • quality assurance status badge
Details
One participant
  • Dariqq
Owner
unassigned
Submitted by
Dariqq
Severity
normal
D
D
Dariqq wrote on 30 Sep 23:41 +0200
(address . bug-guix@gnu.org)
f5fac497-fd0b-4e36-97f9-cde4f8c8f524@posteo.net
Hi,

The meta-package for the mate-desktop fails to build on i686-linux due
to test failures in the dependency graph:

- python-werkzeug
- skia
- node


After skipping these tests with --without-tests the mate build passes.

I have not yet looked into the details why some tests are failing.
D
D
Dariqq wrote on 1 Oct 19:08 +0200
(address . 73575@debbugs.gnu.org)
cb11f7b6-eaad-496c-b315-31aca9031674@posteo.net
Had a look at the test failures:


- python-werkzeug:
tests/test_serving.py: ConnectionRefusedError: [Errno 111] Connection
refused

Not sure what is causing this. Some other linux distributions disable
this test (this package has a lot of dependants though)



- skia
../../src/base/SkContainers.cpp:66: fatal error: "assert(capacity >= 0)"


The function that is causing the error looks like this

#+begin_src cpp
size_t SkContainerAllocator::roundUpCapacity(int64_t capacity) const {
SkASSERT(capacity >= 0);

// If round will not go above fMaxCapacity return rounded capacity.
if (capacity < fMaxCapacity - kCapacityMultiple) {
return SkAlignTo(capacity, kCapacityMultiple);
}

return SkToSizeT(fMaxCapacity);
}
#+end_src


In the same file there is another function which calls roundUpCapacity
which looks like it can overflow because things get castet to int64_t
after the multiplication which will fail to catch the overflow

#+begin_src cpp
size_t SkContainerAllocator::growthFactorCapacity(int capacity, double
growthFactor) const {
SkASSERT(capacity >= 0);
SkASSERT(growthFactor >= 1.0);
// Multiply by the growthFactor. Remember this must be done in
64-bit ints and not
// size_t because size_t changes.
const int64_t capacityGrowth = static_cast<int64_t>(capacity *
growthFactor);

// Notice that for small values of capacity, rounding up will
provide most of the growth.
return this->roundUpCapacity(capacityGrowth);
}
#+end_src




- node:
In tests/parallel/test-fs-utimes-y2K38.js
this is failing:

#+begin_src js
const path = `${tmpdir.path}/test-utimes-precision`;
fs.writeFileSync(path, '');

const Y2K38_mtime = 2 ** 31;
fs.utimesSync(path, Y2K38_mtime, Y2K38_mtime);
#+end_src

with
#+begin_example
not ok 1133 parallel/test-fs-utimes-y2K38
---
duration_ms: 157.49700
severity: fail
exitcode: 1
stack: |-
node:internal/fs/utils:351
throw err;
^

Error: EINVAL: invalid argument, utime
'/tmp/guix-build-node-18.19.0.drv-0/node-v18.19.0/test/.tmp.1155/test-utimes-precision'
at Object.utimesSync (node:fs:2134:3)
at Object.<anonymous>
(/tmp/guix-build-node-18.19.0.drv-0/node-v18.19.0/test/parallel/test-fs-utimes-y2K38.js:46:4)
at Module._compile (node:internal/modules/cjs/loader:1356:14)
at Module._extensions..js
(node:internal/modules/cjs/loader:1414:10)
at Module.load (node:internal/modules/cjs/loader:1197:32)
at Module._load (node:internal/modules/cjs/loader:1013:12)
at Function.executeUserEntryPoint [as runMain]
(node:internal/modules/run_main:128:12)
at node:internal/main/run_main_module:28:49 {
errno: -22,
syscall: 'utime',
code: 'EINVAL',
path:
'/tmp/guix-build-node-18.19.0.drv-0/node-v18.19.0/test/.tmp.1155/test-utimes-precision'
}

Node.js v18.19.0
#+end_example


This seems to be another overflow/integer too big error as 2**31 -1 works.
D
D
Dariqq wrote 6 days ago
(address . 73575@debbugs.gnu.org)
9890d432-cb93-403c-aac9-f851fbf0a823@posteo.net
Since the python-team merge and the node update python-werkzeug and node
build without issues.

However there are some new issues in the dependency graph for cantarell
font:

Test failures in

- python-pandas-2 : TypeError: Cannot cast array data from
dtype('int64') to dtype('int32') according to the rule 'safe'
- python-pytest-regressions : tests/test_ndarrays_regression.py:140:
AssertionError

which are both needed by scipy.

Honestly at this point I think it would be easier to just remove
cantarell font from the default mate package.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 73575@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 73575
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch