[Pkg-javascript-devel] node-sanitize-html 2.13.0+~2.11.0-1 MIGRATED to testing

2024-04-30 Thread Debian testing watch 
FYI: The status of the node-sanitize-html source package
in Debian's testing distribution has changed.

  Previous version: 2.8.0+~2.6.2-1
  Current version:  2.13.0+~2.11.0-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] node-pre-gyp 1.0.11+~2.0.3-1 MIGRATED to testing

2024-04-30 Thread Debian testing watch 
FYI: The status of the node-pre-gyp source package
in Debian's testing distribution has changed.

  Previous version: 1.0.10+~2.0.1-2
  Current version:  1.0.11+~2.0.3-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] node-supertest 7.0.0+~6.0.2-1 MIGRATED to testing

2024-04-30 Thread Debian testing watch 
FYI: The status of the node-supertest source package
in Debian's testing distribution has changed.

  Previous version: 6.3.2-1
  Current version:  7.0.0+~6.0.2-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] node-ip 2.0.1+~1.1.3-1 MIGRATED to testing

2024-04-30 Thread Debian testing watch 
FYI: The status of the node-ip source package
in Debian's testing distribution has changed.

  Previous version: 2.0.0+~1.1.0-1
  Current version:  2.0.1+~1.1.3-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#1068750: moment-timezone.js: FTBFS everywhere

2024-04-30 Thread Martina Ferrari 

Hi Santiago,

On 30/04/2024 14:01, Santiago Vila wrote:

It fails to build if tzdata is updated, but it never stops working. It 
just needs to be updated as often as tzdata is. But if you have a 
suggestion to make this more automatic, I would love to hear it..


Sorry, I still don't get it.

Why does the package build needs to fail if tzdata is updated?



What happens if we allow the package to be built anyway?
(as in the attached patch).
Would the resulting package be broken in any way?


It works, but then there is no way to embed the (effective) tzdata 
version into the moment-timezone.js version, so you could have identical 
source packages producing binaries with the same version and different 
contents, and no way to depend on it. Plus, it almost always fails to 
build anyway, because many of the tests need to be adjusted when tzdata 
changes.


The (better) alternative would be to make it always use a fixed tzdata 
version, but then tzdata migrations will be blocked each time until I 
upload a new version.



I have been doing this very repetitive maintenance for years!


Well, I get that you have to make a new upload so that the package is 
current.
What I don't get is that the package fails to build. At most, it would 
result

in an improved package, not worse. Or maybe I'm missing anything.


What I described above, but I am really open to suggestions on how to 
better handle this.


--
Martina Ferrari

--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#1068750: moment-timezone.js: FTBFS everywhere

2024-04-30 Thread Santiago Vila 

# Fail the build if the tzdata package does not match TZVER.
grep -q '^# version 2023d$' /usr/share/zoneinfo/tzdata.zi


Yes, this is expected after each update to tzdata.


I'm curious: Does this package embed the information from tzdata into 
javascript code,
in such a way that a change in tzdata requires a rebuild?


Yes. It is the only way I found to keep the package aligned with tzdata while 
ensuring it is fully built from source: upstream ships the pre-compiled tzdata 
information, so I regenerate those files using the tzdata package.


I think it would be highly desirable to find a way for this package to do what
it's supposed to do without having to fix it in oldstable and stable every year.


Without a new upload, I cannot imagine how.. :-/


(In fact, I asked Paul Gevers about this, he says that a package which we know
for sure that it will fail to build during the support time of the release is 
RC).


It fails to build if tzdata is updated, but it never stops working. It just 
needs to be updated as often as tzdata is. But if you have a suggestion to make 
this more automatic, I would love to hear it..


Sorry, I still don't get it.

Why does the package build needs to fail if tzdata is updated?

What happens if we allow the package to be built anyway?
(as in the attached patch).

Would the resulting package be broken in any way?


I have been doing this very repetitive maintenance for years!


Well, I get that you have to make a new upload so that the package is current.
What I don't get is that the package fails to build. At most, it would result
in an improved package, not worse. Or maybe I'm missing anything.

Thanks.--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends: debhelper-compat (= 13)
  , dh-sequence-nodejs
  , uglifyjs
  , ts-node 
+ , tzdata (>= 2024a)
  , tzdata-legacy (>= 2024a)
 Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/js-team/moment-timezone.js
--- a/debian/rules
+++ b/debian/rules
@@ -23,10 +23,6 @@ all: binary
 %:
dh $@
 
-execute_before_dh_auto_configure:
-   # Fail the build if the tzdata package does not match TZVER.
-   grep -q '^# version $(TZVER)$$' /usr/share/zoneinfo/tzdata.zi
-
 override_dh_auto_build: $(TARGETS)
 
 execute_before_dh_auto_test: tests/zones/zulu.js
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#1070103: libnode-dev: Version bump of NODE_MODULE_VERSION makes node-gyp build broken modules

2024-04-30 Thread Matijs van Zuijlen 

On 30/04/2024 08:53, Jérémy Lal wrote:



Le mar. 30 avr. 2024 à 08:21, Matijs van Zuijlen > a écrit :


Package: libnode-dev
Version: 18.20.1+dfsg-4+b2
Severity: normal

Dear maintainer,

I tried building and installing the renovate tool from npm, using
npm -g install renovate.

This went well but when I run it I get the message

   The module

'/usr/local/lib/node_modules/renovate/node_modules/re2/build/Release/re2.node'
   was compiled against a different Node.js version using
   NODE_MODULE_VERSION 108. This version of Node.js requires
   NODE_MODULE_VERSION 109. Please try re-compiling or re-installing
   the module (for instance, using `npm rebuild` or `npm install

After some investigation I found out that re2.node is compiled using a
tool called node-gyp, and that tool fetches the node_version.h from
https://nodejs.org/download/release/v18.20.1/node-v18.20.1-headers.tar.gz 

instead of using the locally installed one. This
upstream version has 108 as the NODE_MODULE_VERSION, of course.


You're supposed to use system-installed modules, especially for node-gyp.
If you're using /usr/bin/node-gyp and it is doing that, then it's a bug 
in node-gyp.

Also note that node-re2 is available in debian.


I have debian versions of both node-re2 and node-gyp installed, but npm 
-g install renovate doesn't pick those up. The npm I'm using is the npm 
from the debian npm package.


To solve both, you should do `pkgjs-install` next to package.json, so 
that your system-installed

modules are symlinked to the local node_modules directory.
Then "npm install" shouldn't remove the symlinks and install just the 
missing ones.


There is no package.json, because I am using npm -g install renovate, 
not installing from a checked-out repository. Is npm -g install not 
supposed to work?


I will now try installing from the repository and let you know if that 
works.


In any case, node 20 or 22 is going to debian unstable soon enough, and 
we'll have "standard" modules versions again.


Looking forward to it!


Jérémy


--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#1070103: libnode-dev: Version bump of NODE_MODULE_VERSION makes node-gyp build broken modules

2024-04-30 Thread Jérémy Lal 
Le mar. 30 avr. 2024 à 08:21, Matijs van Zuijlen  a
écrit :

> Package: libnode-dev
> Version: 18.20.1+dfsg-4+b2
> Severity: normal
>
> Dear maintainer,
>
> I tried building and installing the renovate tool from npm, using
> npm -g install renovate.
>
> This went well but when I run it I get the message
>
>   The module
> '/usr/local/lib/node_modules/renovate/node_modules/re2/build/Release/re2.node'
>   was compiled against a different Node.js version using
>   NODE_MODULE_VERSION 108. This version of Node.js requires
>   NODE_MODULE_VERSION 109. Please try re-compiling or re-installing
>   the module (for instance, using `npm rebuild` or `npm install
>
> After some investigation I found out that re2.node is compiled using a
> tool called node-gyp, and that tool fetches the node_version.h from
> https://nodejs.org/download/release/v18.20.1/node-v18.20.1-headers.tar.gz
> instead of using the locally installed one. This
> upstream version has 108 as the NODE_MODULE_VERSION, of course.
>

You're supposed to use system-installed modules, especially for node-gyp.
If you're using /usr/bin/node-gyp and it is doing that, then it's a bug in
node-gyp.
Also note that node-re2 is available in debian.

To solve both, you should do `pkgjs-install` next to package.json, so that
your system-installed
modules are symlinked to the local node_modules directory.
Then "npm install" shouldn't remove the symlinks and install just the
missing ones.

In any case, node 20 or 22 is going to debian unstable soon enough, and
we'll have "standard" modules versions again.

Jérémy
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Processed: fixed 1070103 in 20.12.2+dfsg-1

2024-04-30 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> fixed 1070103 20.12.2+dfsg-1
Bug #1070103 [libnode-dev] libnode-dev: Version bump of NODE_MODULE_VERSION 
makes node-gyp build broken modules
Marked as fixed in versions nodejs/20.12.2+dfsg-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1070103: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070103
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#1070103: libnode-dev: Version bump of NODE_MODULE_VERSION makes node-gyp build broken modules

2024-04-30 Thread Matijs van Zuijlen 
Package: libnode-dev
Version: 18.20.1+dfsg-4+b2
Severity: normal

Dear maintainer,

I tried building and installing the renovate tool from npm, using
npm -g install renovate.

This went well but when I run it I get the message

  The module 
'/usr/local/lib/node_modules/renovate/node_modules/re2/build/Release/re2.node'
  was compiled against a different Node.js version using
  NODE_MODULE_VERSION 108. This version of Node.js requires
  NODE_MODULE_VERSION 109. Please try re-compiling or re-installing
  the module (for instance, using `npm rebuild` or `npm install

After some investigation I found out that re2.node is compiled using a
tool called node-gyp, and that tool fetches the node_version.h from
https://nodejs.org/download/release/v18.20.1/node-v18.20.1-headers.tar.gz
instead of using the locally installed one. This
upstream version has 108 as the NODE_MODULE_VERSION, of course.

I have tried to resolve this by first running

  node-gyp install

and then editing the downloaded node_version.h in 
~/.cache/node-gyp/18.20.1/include/node
manually, and finally re-installing renovate, but that didn't work and
it seems node-gyp simply re-downloaded the 'correct' node_version.h.

Kind regards,
Matijs


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libnode-dev depends on:
ii  libnode109  18.20.1+dfsg-4+b2
ii  libssl-dev  3.2.1-3
ii  libuv1-dev  1.48.0-1.1

libnode-dev recommends no packages.

libnode-dev suggests no packages.

-- no debconf information

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel