Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
On Sunday, 31 July 2022 16:35:12 CEST Jérémy Lal wrote: > Indeed, sorry for my somewhat irritated tone - it just happens that it was > the second time libuv1 was updated during a nodejs transition, and the > upstream bug it creates on nodejs hasn't been fixed yet, so it shoots the > transition in the guts. > Nodejs depends heavily on libuv1... I understand your furstration. Sorry about the mess. > Maybe a simple approach would be to upload libuv1 updates to experimental > first, and wait a week to see how it scares the others :) That I can do. All the best.
Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
Le dim. 31 juil. 2022 à 16:27, Dominique Dumont a écrit : > On Saturday, 30 July 2022 19:36:26 CEST you wrote: > > libuv1 is a library, you're supposed to manage the transition: > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > This page applies when the new version breaks the ABI or API. This was not > the > case. There was no symbol change. The SO version of libuv1 has not changed > since the transition between libuv and libuv1. > Indeed, sorry for my somewhat irritated tone - it just happens that it was the second time libuv1 was updated during a nodejs transition, and the upstream bug it creates on nodejs hasn't been fixed yet, so it shoots the transition in the guts. Nodejs depends heavily on libuv1... > In particular, rebuild all reverse build dependencies and check they > won't > break is highly desirable. > > There are tools and services in debian to do that (though honestly it's > not > so easy to setup). > > I'm already stretched quite thin. I'll see what I can do. > > In any case, I'd be happy to handover libuv1 to people willing to better > maintain this package. Maybe a simple approach would be to upload libuv1 updates to experimental first, and wait a week to see how it scares the others :) Jérémy Jérémy
Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
On Saturday, 30 July 2022 19:36:26 CEST you wrote: > libuv1 is a library, you're supposed to manage the transition: > https://wiki.debian.org/Teams/ReleaseTeam/Transitions This page applies when the new version breaks the ABI or API. This was not the case. There was no symbol change. The SO version of libuv1 has not changed since the transition between libuv and libuv1. > In particular, rebuild all reverse build dependencies and check they won't break is highly desirable. > There are tools and services in debian to do that (though honestly it's not so easy to setup). I'm already stretched quite thin. I'll see what I can do. In any case, I'd be happy to handover libuv1 to people willing to better maintain this package. All the best.
Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
Le sam. 30 juil. 2022 à 19:24, Dominique Dumont a écrit : > On Saturday, 30 July 2022 17:25:29 CEST you wrote: > > libuv1 maintainer: please avoid uploading new versions when nodejs is > > in transition... > > I package libuv1 because it's a dependency of moarvm. > > I don't follow nodejs releases, so I was not aware of on-going transition > and > I did not expect problems because only the minor version number was > increased. > > On the other hand, I have no problem with delaying uploads of libuv1 > provided > someone warns me of issues in other packages. libuv1 is a library, you're supposed to manage the transition: https://wiki.debian.org/Teams/ReleaseTeam/Transitions In particular, rebuild all reverse build dependencies and check they won't break is highly desirable. There are tools and services in debian to do that (though honestly it's not so easy to setup). Reverse Build-depends in main: -- ardour bind9 cmake csound-plugins dnsjit dnswire dqlite driftnet forked-daapd getdns golang-github-evanw-esbuild h2o haxe hddemux janus kamailio knot-resolver libstorj libwebsockets lua-luv lua-nvim macaulay2 moarvm mosquitto neovim netdata node-expat node-fbjs node-grunt-sass node-iconv node-jasmine node-leveldown node-modern-syslog node-nan node-node-sass node-nouislider node-opencv node-pause node-pre-gyp node-re2 node-react node-rollup-plugin-sass node-shiny-server node-sqlite3 node-websocket node-ws node-zx nodejs npm nqp ocaml-luv passenger pcp polybar python-gevent r-cran-fs r-cran-httpuv r-cran-v8 radare2 radare2-cutter raft rakudo rtpengine select2.js siridb-server swupdate tensorpipe ttyd uvloop Found a total of 69 reverse build-depend(s) for libuv1-dev. Jérémy
Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
On Saturday, 30 July 2022 17:25:29 CEST you wrote: > libuv1 maintainer: please avoid uploading new versions when nodejs is > in transition... I package libuv1 because it's a dependency of moarvm. I don't follow nodejs releases, so I was not aware of on-going transition and I did not expect problems because only the minor version number was increased. On the other hand, I have no problem with delaying uploads of libuv1 provided someone warns me of issues in other packages. All the best
Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
Source: nodejs Version: 18.6.0+dfsg-3 Followup-For: Bug #1016305 X-Debbugs-Cc: lib...@packages.debian.org The two actually failing tests are: parallel/test-socket-write-after-fin-error parallel/test-tls-streamwrap-buffersize Those failures are regressions caused by recent upload of libuv1 1.44.2. Upstream nodejs already knows this but they are still figuring out how to fix one of the failures. libuv1 maintainer: please avoid uploading new versions when nodejs is in transition... -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1016305: [Pkg-javascript-devel] Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
Le ven. 29 juil. 2022 à 20:27, Lucas Nussbaum a écrit :
> Source: nodejs
> Version: 18.6.0+dfsg-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220728 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > not ok 1778 parallel/test-net-socket-connect-without-cb
> > ---
> > duration_ms: 0.261
> > severity: fail
> > exitcode: 1
> > stack: |-
> > node:events:491
> > throw er; // Unhandled 'error' event
> > ^
> >
> > Error: getaddrinfo EAI_AGAIN localhost
> > at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:111:26)
> > Emitted 'error' event on Socket instance at:
> > at emitErrorNT (node:internal/streams/destroy:151:8)
> > at emitErrorCloseNT (node:internal/streams/destroy:116:3)
> > at process.processTicksAndRejections
> (node:internal/process/task_queues:82:21) {
> > errno: -3001,
> > code: 'EAI_AGAIN',
> > syscall: 'getaddrinfo',
> > hostname: 'localhost'
> > }
> >
> > Node.js v18.6.0
> > ...
>
>
Those
Error: getaddrinfo EAI_AGAIN localhost
are really painful.
Some build environments have localhost -> 127.0.0.1 and some have localhost
-> ::1.
Some can't even resolve "localhost" !
> > not ok 2130 parallel/test-socket-write-after-fin-error
> > ---
> > duration_ms: 0.327
> > severity: fail
> > exitcode: 1
> > stack: |-
> > node:assert:400
> > throw err;
> > ^
> >
> > AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy
> value:
> >
> > assert(gotServerError)
> >
> > at process.
> (/<>/test/parallel/test-socket-write-after-fin-error.js:52:5)
> > at process.emit (node:events:525:35) {
> > generatedMessage: true,
> > code: 'ERR_ASSERTION',
> > actual: false,
> > expected: true,
> > operator: '=='
> > }
> >
> > Node.js v18.6.0
> > ...
> [...]
> > not ok 2576 parallel/test-tls-streamwrap-buffersize
> > ---
> > duration_ms: 0.326
> > severity: fail
> > exitcode: 1
> > stack: |-
> > Mismatched function calls. Expected exactly 1, actual 0.
> > at Proxy.mustCall (/<>/test/common/index.js:392:10)
> > at TLSSocket.
> (/<>/test/parallel/test-tls-streamwrap-buffersize.js:63:35)
> > at TLSSocket.
> (/<>/test/common/index.js:434:15)
> > at Object.onceWrapper (node:events:627:28)
> > at TLSSocket.emit (node:events:513:28)
> > at TLSSocket.onConnectSecure (node:_tls_wrap:1567:10)
> > at TLSSocket.emit (node:events:513:28)
> > at TLSSocket._finishInit (node:_tls_wrap:948:8)
> > at ssl.onhandshakedone (node:_tls_wrap:729:12)
> > ...
>
>
I suspect those issues come from untimely upload of libuv1 1.44.2 :(
Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
Source: nodejs
Version: 18.6.0+dfsg-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220728 ftbfs-bookworm
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> not ok 1778 parallel/test-net-socket-connect-without-cb
> ---
> duration_ms: 0.261
> severity: fail
> exitcode: 1
> stack: |-
> node:events:491
> throw er; // Unhandled 'error' event
> ^
>
> Error: getaddrinfo EAI_AGAIN localhost
> at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:111:26)
> Emitted 'error' event on Socket instance at:
> at emitErrorNT (node:internal/streams/destroy:151:8)
> at emitErrorCloseNT (node:internal/streams/destroy:116:3)
> at process.processTicksAndRejections
> (node:internal/process/task_queues:82:21) {
> errno: -3001,
> code: 'EAI_AGAIN',
> syscall: 'getaddrinfo',
> hostname: 'localhost'
> }
>
> Node.js v18.6.0
> ...
[...]
> not ok 2130 parallel/test-socket-write-after-fin-error
> ---
> duration_ms: 0.327
> severity: fail
> exitcode: 1
> stack: |-
> node:assert:400
> throw err;
> ^
>
> AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:
>
> assert(gotServerError)
>
> at process.
> (/<>/test/parallel/test-socket-write-after-fin-error.js:52:5)
> at process.emit (node:events:525:35) {
> generatedMessage: true,
> code: 'ERR_ASSERTION',
> actual: false,
> expected: true,
> operator: '=='
> }
>
> Node.js v18.6.0
> ...
[...]
> not ok 2576 parallel/test-tls-streamwrap-buffersize
> ---
> duration_ms: 0.326
> severity: fail
> exitcode: 1
> stack: |-
> Mismatched function calls. Expected exactly 1, actual 0.
> at Proxy.mustCall (/<>/test/common/index.js:392:10)
> at TLSSocket.
> (/<>/test/parallel/test-tls-streamwrap-buffersize.js:63:35)
> at TLSSocket.
> (/<>/test/common/index.js:434:15)
> at Object.onceWrapper (node:events:627:28)
> at TLSSocket.emit (node:events:513:28)
> at TLSSocket.onConnectSecure (node:_tls_wrap:1567:10)
> at TLSSocket.emit (node:events:513:28)
> at TLSSocket._finishInit (node:_tls_wrap:948:8)
> at ssl.onhandshakedone (node:_tls_wrap:729:12)
> ...
[..]
> not ok 3072 sequential/test-debugger-preserve-breaks # TODO : Fix flaky test
> ---
> duration_ms: 31.166
> severity: flaky
> exitcode: 1
> stack: |-
> /<>/test/common/debugger.js:84
> reject(new Error([
> ^
>
> Error: Timeout (3) while waiting for /(?:assert|break|break on
> start|debugCommand|exception|other|promiseRejection) in/i; found: debug>
> debug>
>
> < Waiting for the debugger to disconnect...
> <
>
> debug>
> at Timeout.
> (/<>/test/common/debugger.js:84:18)
> at listOnTimeout (node:internal/timers:564:17)
> at process.processTimers (node:internal/timers:507:7)
>
> Node.js v18.6.0
> ...
The full build log is available from:
http://qa-logs.debian.net/2022/07/28/nodejs_18.6.0+dfsg-3_unstable.log
All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220728;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220728=lu...@debian.org=1=1=1=1#results
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects
If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.
