Bug#1068016: bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2

[Jérémy Lal]

Package: release.debian.org
Followup-For: Bug #1068016

node-babel7 needs node-undici 5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4
(see release.d.o. #1068912).

Also, even with that, the current debdiff *will FTBFS*, see #1068933.

Please find attached another debdiff that addresses that issue.

Jérémy
(sorry for the very late reaction)
diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog 
node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog
--- node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog 2023-10-13 
16:02:05.0 +0200
+++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog 2024-03-29 
17:29:05.0 +0100
@@ -1,3 +1,18 @@
+node-babel7 (7.20.15+ds1+~cs214.269.168-3+deb12u2) bookworm; urgency=medium
+
+  * Team upload
+  * Improve tsc-workaround patch, fixing compilation against
+nodejs 18.19.0+dfsg-6~deb12u1. Closes: #1068933.
+
+  [ Andreas Beckmann ]
+  * Backport Breaks+Replaces fixes from 7.20.15+ds1+~cs214.269.168-4.
+
+  [ Yadd ]
+  * Add missing Breaks+Replaces against all node-babel-* that were in Debian 10
+(Closes: #1037234)
+
+ -- Andreas Beckmann   Fri, 29 Mar 2024 17:29:05 +0100
+
 node-babel7 (7.20.15+ds1+~cs214.269.168-3+deb12u1) bookworm-security; 
urgency=medium
 
   * Team upload
diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/control 
node-babel7-7.20.15+ds1+~cs214.269.168/debian/control
--- node-babel7-7.20.15+ds1+~cs214.269.168/debian/control   2023-10-13 
16:02:05.0 +0200
+++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/control   2024-03-29 
17:29:05.0 +0100
@@ -120,8 +120,92 @@
 Suggests: node-babel-plugin-polyfill-es-shims
  , node-babel7-debug
 Breaks: node-babel-core (<< 6.26.0+repack-3~)
+ , node-babel-cli (<< 7)
  , node-babel-code-frame (<< 7)
-Replaces: node-babel-code-frame (<< 7)
+ , node-babel-generator (<< 7)
+ , node-babel-helper-bindify-decorators (<< 7)
+ , node-babel-helper-builder-binary-assignment-operator-visitor (<< 7)
+ , node-babel-helper-builder-react-jsx (<< 7)
+ , node-babel-helper-call-delegate (<< 7)
+ , node-babel-helper-explode-assignable-expression (<< 7)
+ , node-babel-helper-explode-class (<< 7)
+ , node-babel-helper-function-name (<< 7)
+ , node-babel-helper-hoist-variables (<< 7)
+ , node-babel-helper-optimise-call-expression (<< 7)
+ , node-babel-helper-remap-async-to-generator (<< 7)
+ , node-babel-helper-replace-supers (<< 7)
+ , node-babel-helpers (<< 7)
+ , node-babel-plugin-external-helpers (<< 7)
+ , node-babel-plugin-syntax-async-generators (<< 7)
+ , node-babel-plugin-syntax-class-properties (<< 7)
+ , node-babel-plugin-syntax-decorators (<< 7)
+ , node-babel-plugin-syntax-do-expressions (<< 7)
+ , node-babel-plugin-syntax-dynamic-import (<< 7)
+ , node-babel-plugin-syntax-flow (<< 7)
+ , node-babel-plugin-syntax-function-bind (<< 7)
+ , node-babel-plugin-syntax-jsx (<< 7)
+ , node-babel-plugin-syntax-object-rest-spread (<< 7)
+ , node-babel-plugin-transform-async-to-generator (<< 7)
+ , node-babel-plugin-transform-exponentiation-operator (<< 7)
+ , node-babel-plugin-transform-flow-strip-types (<< 7)
+ , node-babel-plugin-transform-jscript (<< 7)
+ , node-babel-plugin-transform-proto-to-assign (<< 7)
+ , node-babel-plugin-transform-react-display-name (<< 7)
+ , node-babel-plugin-transform-react-jsx (<< 7)
+ , node-babel-plugin-transform-react-jsx-self (<< 7)
+ , node-babel-plugin-transform-react-jsx-source (<< 7)
+ , node-babel-plugin-transform-regenerator (<< 7)
+ , node-babel-plugin-transform-runtime (<< 7)
+ , node-babel-plugin-transform-strict-mode (<< 7)
+ , node-babel-preset-env (<< 7)
+ , node-babel-preset-flow (<< 7)
+ , node-babel-preset-react (<< 7)
+ , node-babel-register (<< 7)
+ , node-babel-template (<< 7)
+ , node-babel-traverse (<< 7)
+Replaces: node-babel-cli (<< 7)
+ , node-babel-code-frame (<< 7)
+ , node-babel-generator (<< 7)
+ , node-babel-helper-bindify-decorators (<< 7)
+ , node-babel-helper-builder-binary-assignment-operator-visitor (<< 7)
+ , node-babel-helper-builder-react-jsx (<< 7)
+ , node-babel-helper-call-delegate (<< 7)
+ , node-babel-helper-explode-assignable-expression (<< 7)
+ , node-babel-helper-explode-class (<< 7)
+ , node-babel-helper-function-name (<< 7)
+ , node-babel-helper-hoist-variables (<< 7)
+ , node-babel-helper-optimise-call-expression (<< 7)
+ , node-babel-helper-remap-async-to-generator (<< 7)
+ , node-babel-helper-replace-supers (<< 7)
+ , node-babel-helpers (<< 7)
+ , node-babel-plugin-external-helpers (<< 7)
+ , node-babel-plugin-syntax-async-generators (<< 7)
+ , node-babel-plugin-syntax-class-properties (<< 7)
+ , node-babel-plugin-syntax-decorators (<< 7)
+ , node-babel-plugin-syntax-do-expressions (<< 7)
+ , node-babel-plugin-syntax-dynamic-import (<< 7)
+ , node-babel-plugin-syntax-flow (<< 7)
+ , node-babel-plugin-syntax-function-bind (<< 7)
+ , node-babel-plugin-syntax-jsx (<< 7)
+ , node-babel-plugin-syntax-object-rest-spread (<< 7)
+ , node-babel-plugin-transform-async-to-generator (<< 7)
+ , 

Bug#1068932: bookworm-pu: package node-v8-compile-cache/2.3.0-3+deb12u1

[Jérémy Lal]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: node-v8-compile-ca...@packages.debian.org, Debian Javascript 
Maintainers 
Control: affects -1 + src:node-v8-compile-cache
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
FTBFS because of test failures, see #1068921
These are regressions caused by nodejs 18.19.0+dfsg-6~deb12u1

[ Impact ]
Only FTBFS

[ Tests ]
The tests are fixed, not skipped, so they will pass with
nodejs 18.19.0+dfsg-6~deb12u1 and node-undici 
5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4

[ Risks ]
Close to none

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
One patch that fixes the tests, consists of two commits cherr-picked,
and a small rewrite to allow the test to pass with nodejs 18.13 and 18.19.
diff -Nru node-v8-compile-cache-2.3.0/debian/changelog 
node-v8-compile-cache-2.3.0/debian/changelog
--- node-v8-compile-cache-2.3.0/debian/changelog2022-11-22 
13:06:02.0 +0100
+++ node-v8-compile-cache-2.3.0/debian/changelog2024-04-13 
17:52:45.0 +0200
@@ -1,3 +1,11 @@
+node-v8-compile-cache (2.3.0-3+deb12u1) UNRELEASED; urgency=medium
+
+  * Upload to bookworm-p-u
+  * patch: NativeCompileCache-test for Node 18.13 and 18.19
+and fix test mock. Closes: #1068921
+
+ -- Jérémy Lal   Sat, 13 Apr 2024 17:52:45 +0200
+
 node-v8-compile-cache (2.3.0-3) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru node-v8-compile-cache-2.3.0/debian/gbp.conf 
node-v8-compile-cache-2.3.0/debian/gbp.conf
--- node-v8-compile-cache-2.3.0/debian/gbp.conf 2022-11-22 13:06:02.0 
+0100
+++ node-v8-compile-cache-2.3.0/debian/gbp.conf 2024-04-13 15:00:41.0 
+0200
@@ -1,4 +1,5 @@
 [DEFAULT]
+debian-branch = debian/bookworm
 pristine-tar = True
 
 [import-orig]
diff -Nru 
node-v8-compile-cache-2.3.0/debian/patches/native-compile-cache-test.patch 
node-v8-compile-cache-2.3.0/debian/patches/native-compile-cache-test.patch
--- node-v8-compile-cache-2.3.0/debian/patches/native-compile-cache-test.patch  
1970-01-01 01:00:00.0 +0100
+++ node-v8-compile-cache-2.3.0/debian/patches/native-compile-cache-test.patch  
2024-04-13 17:51:42.0 +0200
@@ -0,0 +1,42 @@
+Description: fix this test to pass on nodejs 18.13 and 18.19
+Author: Jérémy Lal 
+Last-Update: 2024-04-13
+Forwarded: https://github.com/zertosh/v8-compile-cache/pull/49
+Origin: 
https://github.com/zertosh/v8-compile-cache/commit/de822a607c9dbe7cfc826a44c67fc5f82b03c9ca
+--- a/test/NativeCompileCache-test.js
 b/test/NativeCompileCache-test.js
+@@ -85,12 +85,14 @@
+ tap.test('deletes previously cached code when the cache is an invalid file', 
t => {
+   fakeCacheStore.has = () => true;
+   fakeCacheStore.get = () => Buffer.from('an invalid cache');
+-  let deleteWasCalledWith = null;
+-  fakeCacheStore.delete = arg => { deleteWasCalledWith = arg; };
++  let wasCalledWith = null;
++  fakeCacheStore.set = arg => { wasCalledWith = arg; };
++  // older v8 still calls delete, though
++  fakeCacheStore.delete = arg => { wasCalledWith = arg; };
+ 
+   const fn3 = require('./fixtures/file-3');
+ 
+-  t.equal(deleteWasCalledWith, require.resolve('./fixtures/file-3'));
++  t.equal(wasCalledWith, require.resolve('./fixtures/file-3'));
+   t.equal(fn3(), 3);
+ 
+   t.end();
+--- a/test/FileSystemBlobStore-mock.js
 b/test/FileSystemBlobStore-mock.js
+@@ -20,7 +20,14 @@
+   }
+ 
+   set(key, invalidationKey, buffer) {
++const entry = this._cachedFiles.find(
++  file => file.key === key && file.invalidationKey === invalidationKey
++);
++if (entry == null) {
+ this._cachedFiles.push({key, invalidationKey, buffer});
++} else {
++  entry.buffer = buffer;
++}
+ return buffer;
+   }
+ 
diff -Nru node-v8-compile-cache-2.3.0/debian/patches/series 
node-v8-compile-cache-2.3.0/debian/patches/series
--- node-v8-compile-cache-2.3.0/debian/patches/series   2022-11-22 
13:06:02.0 +0100
+++ node-v8-compile-cache-2.3.0/debian/patches/series   2024-04-13 
15:00:41.0 +0200
@@ -1 +1,2 @@
 latest-tap.patch
+native-compile-cache-test.patch

Bug#1068920: bookworm-pu: package node-zx/7.1.1+~cs6.7.23-2+deb12u1

[Jérémy Lal]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: node...@packages.debian.org, Debian Javascript Maintainers 

Control: affects -1 + src:node-zx
User: release.debian@packages.debian.org
Usertags: pu


[ Reason ]
Fix regression or just plain mistake.
node-zx currently FTBFS #1068918

[ Impact ]
None, it just fixes a test.

[ Tests ]
The test is run during build and autopkgtest:
"argv works with zx and node"

[ Risks ]
Very low risk, since it only affects a test.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
* patch: fix flaky test (upstream commit)

[ Other info ]
This requires node-undici 5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4,
so should be part of the same bookworm-p-u

Bug#1068912: bookworm-pu: package node-undici/5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4

[Jérémy Lal]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: node-und...@packages.debian.org, Debian Javascript Maintainers 

Control: affects -1 + src:node-undici
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
node-undici: FTBFS with nodejs 18.19.0+dfsg-6~deb12u1
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063530

[ Impact ]
node-undici FTBFS, also several other packages need node-undici
to properly export its typescript types, which it currently doesn't.

[ Tests ]
(What automated or manual tests cover the affected code?)
Rebuild+Autopkgtest should be enough to cover the affected code.
All this is caused by a regression introduced by nodejs 18.19.0+dfsg-6~deb12u1

[ Risks ]
No further risks.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
  * Import upstream patch that moves index.d.ts to types/ (closes #1063530)
  * Force @types/node to use local copy of undici-types
  * Fix build failures on lld 15+

[ Other info ]
node-zx, node-v8-compile-cache, node-babel7 will also be proposed,
to fix their tests suites w.r.t. the aforementioned regression.
diff -Nru node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/changelog 
node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/changelog
--- node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/changelog  2023-12-21 
11:14:59.0 +0100
+++ node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/changelog  2024-04-13 
11:22:02.0 +0200
@@ -1,3 +1,12 @@
+node-undici (5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4) UNRELEASED; urgency=medium
+
+  [ Ryan Gonzalez ]
+  * Import upstream patch that moves index.d.ts to types/ (closes #1063530)
+  * Force @types/node to use local copy of undici-types
+  * Fix build failures on lld 15+
+
+ -- Jérémy Lal   Sat, 13 Apr 2024 11:22:02 +0200
+
 node-undici (5.15.0+dfsg1+~cs20.10.9.3-1+deb12u3) bookworm-security; 
urgency=medium
 
   * Team upload.
diff -Nru node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/gbp.conf 
node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/gbp.conf
--- node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/gbp.conf   2023-12-21 
11:08:13.0 +0100
+++ node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/gbp.conf   2024-04-13 
11:19:52.0 +0200
@@ -1,4 +1,5 @@
 [DEFAULT]
+debian-branch = bookworm
 pristine-tar=True
 filter=[ '.gitignore', '.travis.yml', '.git*' ]
 component=['llhttp', 'llparse', 'llparse-frontend', 'llparse-builder', 
'binary-search']
diff -Nru node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/build 
node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/build
--- node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/build   2023-12-21 
11:08:13.0 +0100
+++ node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/build   2024-04-13 
11:18:29.0 +0200
@@ -10,7 +10,7 @@
 #  - direct clang call
 clang -nodefaultlibs --sysroot=/usr -target wasm32-unknown-wasi \
-Ofast -fno-exceptions -fvisibility=hidden \
-   -mexec-model=reactor -Wl,-lc -Wl,-error-limit=0 -Wl,-O3 \
+   -mexec-model=reactor -Wl,-lc -Wl,--error-limit=0 -Wl,-O3 \
-Wl,--lto-O3 -Wl,--strip-all -Wl,--allow-undefined \
-Wl,--export-dynamic -Wl,--export-table -Wl,--export=malloc \
-Wl,--export=free \
diff -Nru node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/extcopies 
node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/extcopies
--- node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/extcopies   
1970-01-01 01:00:00.0 +0100
+++ node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/extcopies   
2024-04-13 11:18:29.0 +0200
@@ -0,0 +1 @@
+@types/node
diff -Nru node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/extlinks 
node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/extlinks
--- node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/extlinks
2022-10-22 13:28:40.0 +0200
+++ node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/nodejs/extlinks
2024-04-13 11:18:29.0 +0200
@@ -1,4 +1,3 @@
 busboy
 @types/debug
-@types/node
 @types/semver
diff -Nru 
node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/patches/Add-publish-types-script-2273.patch
 
node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/patches/Add-publish-types-script-2273.patch
--- 
node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/patches/Add-publish-types-script-2273.patch
1970-01-01 01:00:00.0 +0100
+++ 
node-undici-5.15.0+dfsg1+~cs20.10.9.3/debian/patches/Add-publish-types-script-2273.patch
2024-04-13 11:18:29.0 +0200
@@ -0,0 +1,341 @@
+From: Ethan Arrowood 
+Date: Wed, 20 Sep 2023 15:02:42 -0600
+Subject: Add publish types script (#2273)
+
+* add publish types script
+
+* use postpublish script
+
+* 5.24.0-test.0
+
+* 5.24.0-test.1
+
+* uncomment
+
+* 5.24.0-test.2
+
+* simplify automation
+
+* 5.24.0-test.3
+
+* fix script
+
+* 5.24.0-test.4
+
+* fix script
+
+* 5.24.0

Re: OpenSSL transition to testing

[Jérémy Lal]

Le jeu. 23 nov. 2023 à 14:17, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> a écrit :

> On 2023-11-22 22:15:43 [+0100], Jérémy Lal wrote:
> > Plase wait a moment before doing more uploads.
> > I am gonna deal with it before the end the week. Sorry for that.
>
> Sorry for any trouble I may have caused. I haven't had any response and
> I wasn't granted any free rider card so I started backporting on SAT
> evening. And to not make it look selfish I looked at the CVEs, too. This
> and testing took a while.
> I just (wrongly) assumed the other testsuite failures is just my local
> setup problem…
>

Don't worry, I'm the one lagging behind. I've started work on latest 18.x
update, and will check those.

Jérémy

Re: OpenSSL transition to testing

[Jérémy Lal]

Le ven. 17 nov. 2023 à 22:24, Adrian Bunk  a écrit :

> On Fri, Nov 17, 2023 at 05:22:35PM +0100, Sebastian Andrzej Siewior wrote:
> >...
> > I'm now curious to learn what could be the best way to move forward. I
> > have a few ideas:
> > - NMU #1055416, allow the transition to happen.
> >
> > - NMU also #1052470 in order to allow an OpenSSL 3.1.4 upload. This
> >   could be tricky because proposed change is based on nodejs' master-18.x
> >   branch meaning new nodejs version which could lead to other issues.
> >   I could try to isolate the needed bits but…
> >
> > - Ignore debci for Nodejs which would allow 3.0.12-2 to migrate and
> >   3.1.4 could follow to unstable shortly after.
> >
> > Anyone?
>
> Your last option is in practice equivalent to Nodejs not having any
> autopkgtest at all, disabling one or few tests would be preferable
> to that since regressions in the other > 3000 tests would still be
> detected. E.g. different tests in Nodejs fail with c-ares/unstable,[1]
> and this will no longer be visible if the autopkgtest always fails.
>

Plase wait a moment before doing more uploads.
I am gonna deal with it before the end the week. Sorry for that.

Jérémy

Bug#1015270: transition: nodejs

[Jérémy Lal]

Le sam. 30 juil. 2022 à 15:42, Paul Gevers  a écrit :

> Hi Jérémy,
>
> On 29-07-2022 22:47, Jérémy Lal wrote:
> > All seems to be well on its way, with the exception of the
> autopkgtest
> > failure of node-babel7 on ppc64el. Did you already have a look at
> that?
> >
> > I can file the bug against node-babel7 if you want.
> >
> >
> > v8 clearly crashes on ppc64el here while executing tsc, so it's not a
> > node-babel7 bug.
>
> If I understand you correctly, v8 is some internal thing of nodejs and
> the issue needs to be fixed there.


That's right.


> Did you already report the issue
> upstream? Do you need help from the ppc64el porters? Will you handle this?
>

Not yet but yes, I'm currently working on it - good news is that it
reproduces on plummer.d.o.

Jérémy

Bug#1015270: transition: nodejs

[Jérémy Lal]

Le ven. 29 juil. 2022 à 22:30, Paul Gevers  a écrit :

> Hi Jérémy.
>
> On 22-07-2022 14:51, Graham Inggs wrote:
> > On Mon, 18 Jul 2022 at 19:09, Jérémy Lal  wrote:
> >> nodejs 18.6.0 will soon be the active version of nodejs:
> >> https://nodejs.org/en/about/releases/
> >>
> >> I rebuilt and checked all reverse-build-deps of libnode-dev/nodejs,
> >> and dealt with most of the regressions, or opened bugs proposing a
> solution.
> >
> > Please go ahead with the upload to unstable.
>
> All seems to be well on its way, with the exception of the autopkgtest
> failure of node-babel7 on ppc64el. Did you already have a look at that?
>
> I can file the bug against node-babel7 if you want.
>

v8 clearly crashes on ppc64el here while executing tsc, so it's not a
node-babel7 bug.

Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)

[Jérémy Lal]

Le ven. 29 juil. 2022 à 22:00, Debian Bug Tracking System <
ow...@bugs.debian.org> a écrit :

> Hi Jérémy,
>
> On 29-07-2022 19:36, Jérémy Lal wrote:
> > when a package pass all autopkgtests it can migrate in 2 days,
> > however if it depends on an architecture that reports "Not a regression",
> > it seems that the bonus is lost and the package must wait 5 days.
>
> That's by design.
>
> > The problem is that it happens when a package depends on a package
> > that is not available in a given architecture.
>
> Unfortunately, that's indeed the price of that design. As we're supposed
> to try and support all architectures equally well, I decided that's
> acceptable.
>
>
I don't see how artificially adding migration days will improve debian
quality in any way.
It will do exactly the opposite during freeze.

Jérémy

Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney


Hi,

when a package pass all autopkgtests it can migrate in 2 days,
however if it depends on an architecture that reports "Not a regression",
it seems that the bonus is lost and the package must wait 5 days.

The problem is that it happens when a package depends on a package
that is not available in a given architecture.

Specific example:

excuses:
Migration status for node-node-rest-client (3.1.1-1 to 3.1.1-2): Waiting for 
test results or another package, or too young (no action required now - check 
later)
Issues preventing migration:
∙ ∙ Too young, only 2 of 5 days old
Additional info:
∙ ∙ Piuparts tested OK - 
https://piuparts.debian.org/sid/source/n/node-node-rest-client.html
∙ ∙ autopkgtest for node-node-rest-client/3.1.1-2: amd64: Pass, arm64: Pass, 
armel: Not a regression, armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Pass
Not considered


Jérémy

Bug#1015270: transition: nodejs

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

nodejs 18.6.0 will soon be the active version of nodejs:
https://nodejs.org/en/about/releases/

I rebuilt and checked all reverse-build-deps of libnode-dev/nodejs,
and dealt with most of the regressions, or opened bugs proposing a solution.

Thanks,
Jérémy


Ben file:

title = "nodejs";
is_affected = .depends ~ /\b(libnode93)\b/ | .depends ~ /\b(libnode108)\b/;
is_good = .depends ~ /\b(libnode108)\b/;
is_bad = .depends ~ /\b(libnode93)\b/;

Bug#1010438: transition: nodejs

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

nodejs 16.14.2 is the current active version of nodejs:
https://nodejs.org/en/about/releases/
It also supports riscv64 architecture and has much better support of ppc64.

A rebuild of all (1600+) reverse-build-deps of libnode-dev/nodejs shows
very few regressions, alerady being dealt with.

Ben file:

title = "nodejs";
is_affected = .depends ~ "libnode83" | .depends ~ "libnode93";
is_good = .depends ~ "libnode93";
is_bad = .depends ~ "libnode83";

Bug#1008063: transition: nodejs

[Jérémy Lal]

Le lun. 28 mars 2022 à 21:30, Adrian Bunk  a écrit :

> On Mon, Mar 28, 2022 at 04:59:58PM +0200, Jérémy Lal wrote:
> >
> > Yes, actually all packages depending on libnode-dev/sid now need to
> depend
> > on nodejs/sid, or else autopkgtest runs the tests against nodejs/testing,
> > and that fails.
> > I'll reupload them if that's all right.
> >
> > The other solution is to have /usr/bin/node12, /usr/bin/node14 and
> > /usr/bin/node
> > as an alternative link. Which is not going to happen for that transition.
>
> Isn't the actual bug that the Breaks of libnode83 against libnode72 does
> not cover the version in testing permitting obviously non-working
> combinations of packages, and the correct solution is to make the
> Breaks of libnode83 against libnode72 unversioned?
>
> libnode is not a standalone library but a way to embed into a specific
> nodejs version, is there a reason why libnode is a separate package and
> not part of the nodejs package with Provides: libnode83?
>
> Other ecosystems are doing it in a similar way, e.g. with perlapi-5.34.0


Transition happened anyway...

>

Bug#1008063: transition: nodejs

[Jérémy Lal]

On Mon, Mar 28, 2022 at 4:19 PM Sebastian Ramacher 
wrote:

> On 2022-03-22 20:06:50, Jérémy Lal wrote:
> > On Mon, Mar 21, 2022 at 10:42 PM Sebastian Ramacher <
> sramac...@debian.org>
> > wrote:
> >
> > > Control: tags -1 confirmed
> > >
> > > On 2022-03-21 18:54:38 +0100, Jérémy Lal wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: transition
> > > > X-Debbugs-Cc: Debian Javascript Maintainers <
> > > pkg-javascript-de...@lists.alioth.debian.org>
> > > >
> > > > Hi,
> > > >
> > > > this transition correspond to a nodejs 12 -> 14 major major bump.
> > > >
> > > > I carefully checked (twice, actually) that all build-dependencies of
> > > > - libnode-dev (arch-dependent)
> > > > - nodejs (arch-independent)
> > > > can be rebuilt using latest libnode-dev / nodejs, though of course
> > > > only the arch-dependent ones are concerned by this transition.
> > >
> > > Please go ahead
> >
> >
> > We just just finished fixing some issues
> > with nodejs_16.13.2+really14.19.1~dfsg-5:
> > - test issues
> > - missing important files for typescript-dependent modules
> >
> > Also i just uploaded a fix for
> > node-modern-syslog
> >
> > node-opencv is known to fail and might be fixed, but it will be removed
> if
> > not.
>
> The remaining blockers are some autopkgtest regressions:
>
> ∙ ∙ autopkgtest for node-expat/2.4.0+ds-1: amd64: Regression ♻
> (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻
> (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻
> (reference ♻)
> ∙ ∙ autopkgtest for node-iconv/3.0.1+~3.0.0-1: amd64: Regression ♻
> (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻
> (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻
> (reference ♻)
> ∙ ∙ autopkgtest for node-jest/27.5.1~ds+~cs69.51.22-4: amd64: Regression
> ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻
> (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Not a
> regression
> ∙ ∙ autopkgtest for node-modern-syslog/1.2.0-2: amd64: Regression ♻
> (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻
> (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻
> (reference ♻)
> ∙ ∙ autopkgtest for node-node-forge/1.2.1~dfsg-2: ppc64el: No test
> results
> ∙ ∙ autopkgtest for node-node-sass/7.0.1+git20211229.3bb51da+dfsg-1:
> amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻),
> armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻),
> ppc64el: Regression ♻ (reference ♻)
> ∙ ∙ autopkgtest for node-npmrc/1.1.1-2: amd64: Regression ♻ (reference
> ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference
> ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference
> ♻)
> ∙ ∙ autopkgtest for node-re2/1.17.4+~cs2.13.8-1: amd64: Regression ♻
> (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻
> (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻
> (reference ♻)
> ∙ ∙ autopkgtest for node-sqlite3/5.0.2+ds1-3: amd64: Regression ♻
> (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻
> (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻
> (reference ♻)
> ∙ ∙ autopkgtest for node-ts-jest/27.1.3+~cs0.2.6-2: ppc64el: Pass
> ∙ ∙ autopkgtest for node-websocket/1.0.34+~cs10.0.25-1: amd64:
> Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf:
> Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el:
> Regression ♻ (reference ♻)
>
> Could you please have a look at them?
>

Yes, actually all packages depending on libnode-dev/sid now need to depend
on nodejs/sid, or else autopkgtest runs the tests against nodejs/testing,
and that fails.
I'll reupload them if that's all right.

The other solution is to have /usr/bin/node12, /usr/bin/node14 and
/usr/bin/node
as an alternative link. Which is not going to happen for that transition.

Jérémy

Bug#1008063: transition: nodejs

[Jérémy Lal]

On Mon, Mar 21, 2022 at 10:42 PM Sebastian Ramacher 
wrote:

> Control: tags -1 confirmed
>
> On 2022-03-21 18:54:38 +0100, Jérémy Lal wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: Debian Javascript Maintainers <
> pkg-javascript-de...@lists.alioth.debian.org>
> >
> > Hi,
> >
> > this transition correspond to a nodejs 12 -> 14 major major bump.
> >
> > I carefully checked (twice, actually) that all build-dependencies of
> > - libnode-dev (arch-dependent)
> > - nodejs (arch-independent)
> > can be rebuilt using latest libnode-dev / nodejs, though of course
> > only the arch-dependent ones are concerned by this transition.
>
> Please go ahead


We just just finished fixing some issues
with nodejs_16.13.2+really14.19.1~dfsg-5:
- test issues
- missing important files for typescript-dependent modules

Also i just uploaded a fix for
node-modern-syslog

node-opencv is known to fail and might be fixed, but it will be removed if
not.

Jérémy

Bug#1008063: transition: nodejs

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: Debian Javascript Maintainers 


Hi,

this transition correspond to a nodejs 12 -> 14 major major bump.

I carefully checked (twice, actually) that all build-dependencies of
- libnode-dev (arch-dependent)
- nodejs (arch-independent)
can be rebuilt using latest libnode-dev / nodejs, though of course
only the arch-dependent ones are concerned by this transition.

Ben file:

title = "nodejs";
is_affected = .depends ~ "libnode72" | .depends ~ "libnode83";
is_good = .depends ~ "libnode83";
is_bad = .depends ~ "libnode72";

Thank you for considering.

Jérémy

Bug#1007905: transition: icu

[Jérémy Lal]

Le ven. 18 mars 2022 à 18:26, László Böszörményi (GCS)  a
écrit :

> On Fri, Mar 18, 2022 at 5:38 PM László Böszörményi (GCS) 
> wrote:
> >  I didn't file those bugs, but started patching those and filed only
> > when succeeded. At this point I remember only two packages that FTBFS
> > with ICU 70.1 and I couldn't fix those. One is mozjs78 and the other
> > is 0ad. I had trouble with PostgreSQL, but that has a new major
> > upstream release uploaded since then, meaning it needs to be
> > re-tested.
>  Speak of the devil. ICU 71.1 RC [1] just released. Final is expected
> in April (two-three weeks). Would you two mind if I package it and ask
> for testing of your packages (mozjs91 and nodejs) against it?
>
> Regards,
> Laszlo/GCS
> [1] https://icu.unicode.org/download/71


Ok for rebuilding node 14 ans 16

>
>

Bug#1007905: transition: icu

[Jérémy Lal]

On Fri, Mar 18, 2022 at 12:51 PM Simon McVittie  wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org, i...@packages.debian.org
> Forwarded: https://release.debian.org/transitions/html/auto-icu.html
> Tags: moreinfo
>
> icu has a new upstream version in experimental (#1006960). Is there a
> plan to get it into unstable and then testing?
>
> The reason I'm asking is that GNOME 42 will need an updated gjs, which
> needs mozjs91, which needs either icu 70 or rebuilding to use its vendored
> copy of icu.
>


FYI same here, i had to fallback to nodejs 14 instead of 16 because of that.
Last time I asked, icu maintainer had issues fixing icu reverse
build-dependencies.
He probably needs help ?

Jérémy

Bug#991707: marked as done (unblock: nodejs/12.22.4~dfsg-1)

[Jérémy Lal]

Le ven. 30 juil. 2021 à 16:36, Debian Bug Tracking System <
ow...@bugs.debian.org> a écrit :

> Your message dated Fri, 30 Jul 2021 16:32:35 +0200
> with message-id  7wab3i9k_ch07wkp6moypdpit...@mail.gmail.com>
> and subject line Re: Bug#991707: Acknowledgement (unblock:
> nodejs/12.22.4~dfsg-1)
> has caused the Debian Bug report #991707,
> regarding unblock: nodejs/12.22.4~dfsg-1
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 991707: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991707
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "Jérémy Lal" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 30 Jul 2021 15:27:24 +0200
> Subject: unblock: nodejs/12.22.4~dfsg-1
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: secur...@debian.org
>
> Please unblock package nodejs
>
> [ Reason ]
> Debian security team plans to upload nodejs security updates "as-is",
> at least while upstream still maintain nodejs 12.x. This is what was
> done in Buster.
>
> Latest security update is 12.22.4 (severity high).
> I did not try to get nodejs > 12.21.0 into bullseye up until now
> because upstream changes were essentially not concerning the debian
> package.
>
> However the 12.22.4 release has many v8 fixes, and a security fix (high).
>
>
> [ Impact ]
> If not in Bullseye, it will require users to download nodejs a second time
> just after installation, through security updates.
> So it will postpone any issue post-release.
>
>
> [ Tests ]
> Usual thorough upstream test suite + all dependents packages tests.
>
> [ Risks ]
> Low, but when considering the regressions i saw false positives:
> - node-chokidar seems to have a flaky test
> - node-esquery, node-caniuse-api, node-browserslist suites fail on their
> own,
>   for an unrelated problem
> - node-websocket-driver was already broken, probably for a long time.
>   I opened #991700 and will ask its removal from testing.
>
> Also an undocumented internal api has been deprecated, and old modules
> trying
> accessing it will now print a warning (process.binding('http_parser')).
> Only node-websocket-driver is actually using it...
> A code search shows node-http-signature, node-fastcgi are using it in their
> test suites, but it doesn't pose any problem.
>
> https://codesearch.debian.net/search?q=process%5C.binding%5C%28%5B%27%22%5Dhttp_parser%5B%27%22%5D%5C%29=0
>
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
>
> [ Other info ]
> debdiff is without deps/cares (not used), deps/openssl (not used), test/*,
> benchmark/*, tools/msvs/*.
> Still waiting for armhf test results when writing this request.
>
> unblock nodejs/12.22.4~dfsg-1
>

>
> -- Forwarded message --
> From: "Jérémy Lal" 
> To: 991707-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 30 Jul 2021 16:32:35 +0200
> Subject: Re: Bug#991707: Acknowledgement (unblock: nodejs/12.22.4~dfsg-1)
> I just double-checked nodejs 12.22.4 was actually fixing
> CVE-2021-22930, supposed to be reproducible with
> https://github.com/mdouglass/repro-node-crash
>
> It does not, so i'm closing this bug until i find out what's happening.
>

What was happening was an incomplete upstream fix, released in nodejs
12.22.5.

I suppose it's too late for an unblock request so i'll just propose it to
security updates.

Jérémy

>

Bug#991708: RM: node-websocket-driver/0.3.5-1.1 -- RC-buggy, ROM

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: 991...@bugs.debian.org

This package is too buggy. See #991700 for details.

Reverse deps and build-deps: node-faye-websocket

Reverse deps and build-deps of node-faye-websocket: none

Do i need to RM node-faye-websocket too ?

Jérémy

Bug#991707: unblock: nodejs/12.22.4~dfsg-1

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: secur...@debian.org

Please unblock package nodejs

[ Reason ]
Debian security team plans to upload nodejs security updates "as-is",
at least while upstream still maintain nodejs 12.x. This is what was
done in Buster.

Latest security update is 12.22.4 (severity high).
I did not try to get nodejs > 12.21.0 into bullseye up until now
because upstream changes were essentially not concerning the debian package.

However the 12.22.4 release has many v8 fixes, and a security fix (high).


[ Impact ]
If not in Bullseye, it will require users to download nodejs a second time
just after installation, through security updates.
So it will postpone any issue post-release.


[ Tests ]
Usual thorough upstream test suite + all dependents packages tests.

[ Risks ]
Low, but when considering the regressions i saw false positives:
- node-chokidar seems to have a flaky test
- node-esquery, node-caniuse-api, node-browserslist suites fail on their own,
  for an unrelated problem
- node-websocket-driver was already broken, probably for a long time.
  I opened #991700 and will ask its removal from testing.

Also an undocumented internal api has been deprecated, and old modules trying
accessing it will now print a warning (process.binding('http_parser')).
Only node-websocket-driver is actually using it...
A code search shows node-http-signature, node-fastcgi are using it in their
test suites, but it doesn't pose any problem.
https://codesearch.debian.net/search?q=process%5C.binding%5C%28%5B%27%22%5Dhttp_parser%5B%27%22%5D%5C%29=0

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
debdiff is without deps/cares (not used), deps/openssl (not used), test/*, 
benchmark/*, tools/msvs/*.
Still waiting for armhf test results when writing this request.

unblock nodejs/12.22.4~dfsg-1
diff -Nru --exclude '*.md' --exclude '*.html' --exclude '*.json' --exclude 
'*.ts' nodejs-12.21.0~dfsg/common.gypi nodejs-12.22.4~dfsg/common.gypi
--- nodejs-12.21.0~dfsg/common.gypi 2021-02-23 03:58:04.0 +0100
+++ nodejs-12.22.4~dfsg/common.gypi 2021-07-29 12:35:21.0 +0200
@@ -34,7 +34,7 @@
 
 # Reset this number to 0 on major V8 upgrades.
 # Increment by one for each non-official patch applied to deps/v8.
-'v8_embedder_string': '-node.45',
+'v8_embedder_string': '-node.56',
 
 # V8 defaults for Node.js #
 
diff -Nru --exclude '*.md' --exclude '*.html' --exclude '*.json' --exclude 
'*.ts' nodejs-12.21.0~dfsg/debian/changelog nodejs-12.22.4~dfsg/debian/changelog
--- nodejs-12.21.0~dfsg/debian/changelog2021-07-03 20:50:29.0 
+0200
+++ nodejs-12.22.4~dfsg/debian/changelog2021-07-30 01:02:46.0 
+0200
@@ -1,3 +1,12 @@
+nodejs (12.22.4~dfsg-1) unstable; urgency=medium
+
+  * New upstream version 12.22.4~dfsg
+Fixed vulnerabilities:
++ CVE-2021-22930: Use after free on close http2
+  on stream canceling (High)
+
+ -- Jérémy Lal   Fri, 30 Jul 2021 01:02:46 +0200
+
 nodejs (12.21.0~dfsg-5) unstable; urgency=medium
 
   * Patch uvwasi.gyp to honour --shared-libuv. Closes: #990569.
diff -Nru --exclude '*.md' --exclude '*.html' --exclude '*.json' --exclude 
'*.ts' nodejs-12.21.0~dfsg/deps/cjs-module-lexer/lexer.js 
nodejs-12.22.4~dfsg/deps/cjs-module-lexer/lexer.js
--- nodejs-12.21.0~dfsg/deps/cjs-module-lexer/lexer.js  2021-02-23 
03:58:04.0 +0100
+++ nodejs-12.22.4~dfsg/deps/cjs-module-lexer/lexer.js  2021-07-29 
12:35:21.0 +0200
@@ -37,8 +37,6 @@
 const ExportAssign = 1;
 const ExportStar = 2;
 
-const strictReserved = new Set(['implements', 'interface', 'let', 'package', 
'private', 'protected', 'public', 'static', 'yield', 'enum']);
-
 function parseCJS (source, name = '@') {
   resetState();
   try {
@@ -49,14 +47,39 @@
 e.loc = pos;
 throw e;
   }
-  const result = { exports: [..._exports].filter(expt => 
!unsafeGetters.has(expt)), reexports: [...reexports] };
+  const result = { exports: [..._exports].filter(expt => expt !== undefined && 
!unsafeGetters.has(expt)), reexports: [...reexports].filter(reexpt => reexpt 
!== undefined) };
   resetState();
   return result;
 }
 
-function addExport (name) {
-  if (!strictReserved.has(name))
-_exports.add(name);
+function decode (str) {
+  if (str[0] === '"' || str[0] === '\'') {
+try {
+  const decoded = (0, eval)(str);
+  // Filter to exclude non-matching UTF-16 surrogate strings
+  for (let i = 0; i < decoded.length; i++) {
+const surrogatePrefix = decoded.charCodeAt(i) & 0xFC00;
+if (surrogatePrefix < 0xD800) {
+  // Not a surrogate
+  continue;
+}
+else if (surrogatePrefix === 0xD800) {
+  // Validate surrogate pair
+  

Bug#990646: unblock: nodejs/12.21.0~dfsg-5

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nodejs

[ Reason ]
nodejs have been using its own copy of libuv for a while,
without me noticing.

[ Impact ]
nodejs using own copy of libuv, bad for security fixes.

[ Tests ]
nodejs own test suite is thorough.

[ Risks ]
None. But I might have overlooked a risk. Please tell me.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
The problem should have been discovered one year ago. Sorry for this.

unblock nodejs/12.21.0~dfsg-5
diff -Nru nodejs-12.21.0~dfsg/debian/changelog 
nodejs-12.21.0~dfsg/debian/changelog
--- nodejs-12.21.0~dfsg/debian/changelog2021-04-21 12:42:46.0 
+0200
+++ nodejs-12.21.0~dfsg/debian/changelog2021-07-03 20:50:29.0 
+0200
@@ -1,3 +1,9 @@
+nodejs (12.21.0~dfsg-5) unstable; urgency=medium
+
+  * Patch uvwasi.gyp to honour --shared-libuv. Closes: #990569.
+
+ -- Jérémy Lal   Sat, 03 Jul 2021 20:50:29 +0200
+
 nodejs (12.21.0~dfsg-4) unstable; urgency=medium
 
   [ Andreas Beckmann ]
diff -Nru nodejs-12.21.0~dfsg/debian/patches/series 
nodejs-12.21.0~dfsg/debian/patches/series
--- nodejs-12.21.0~dfsg/debian/patches/series   2021-03-19 18:28:07.0 
+0100
+++ nodejs-12.21.0~dfsg/debian/patches/series   2021-07-03 16:18:02.0 
+0200
@@ -1,3 +1,4 @@
+shared_uv_from_uvwasi.patch
 large_pages_assembly_gnu_stack.patch
 dfhs_module_path_arch_triplet.patch
 # 2012_kfreebsd.patch
diff -Nru nodejs-12.21.0~dfsg/debian/patches/shared_uv_from_uvwasi.patch 
nodejs-12.21.0~dfsg/debian/patches/shared_uv_from_uvwasi.patch
--- nodejs-12.21.0~dfsg/debian/patches/shared_uv_from_uvwasi.patch  
1970-01-01 01:00:00.0 +0100
+++ nodejs-12.21.0~dfsg/debian/patches/shared_uv_from_uvwasi.patch  
2021-07-03 17:43:00.0 +0200
@@ -0,0 +1,26 @@
+Description: uvwasi depends on uv.gyp and ignores shared_libuv
+Author: Jérémy Lal 
+Last-Update: 2021-07-03
+Forwarded: https://github.com/nodejs/node/issues/39248
+--- a/deps/uvwasi/uvwasi.gyp
 b/deps/uvwasi/uvwasi.gyp
+@@ -18,9 +18,6 @@
+ 'src/wasi_rights.c',
+ 'src/wasi_serdes.c',
+   ],
+-  'dependencies': [
+-'../uv/uv.gyp:libuv',
+-  ],
+   'direct_dependent_settings': {
+ 'include_dirs': ['include']
+   },
+@@ -31,6 +28,9 @@
+ '_POSIX_C_SOURCE=200112',
+   ],
+ }],
++[ 'node_shared_libuv=="false"', {
++  'dependencies': [ '../uv/uv.gyp:libuv' ],
++}],
+   ],
+ }
+   ]
diff -Nru nodejs-12.21.0~dfsg/debian/rules nodejs-12.21.0~dfsg/debian/rules
--- nodejs-12.21.0~dfsg/debian/rules2021-02-23 19:22:31.0 +0100
+++ nodejs-12.21.0~dfsg/debian/rules2021-07-03 15:48:04.0 +0200
@@ -16,19 +16,20 @@
 export LANG
 DEB_CONFIGURE_NORMAL_ARGS =
 DEB_CONFIGURE_EXTRA_FLAGS = \
+--verbose \
 --without-npm \
 --shared \
 --shared-zlib \
 --shared-cares \
---shared-nghttp2 \
 --shared-brotli \
 --with-intl=system-icu \
 --prefix=/usr \
 --openssl-use-def-ca-store \
 --arch-triplet=$(DEB_HOST_MULTIARCH) \
---node-relative-path="lib/$(DEB_HOST_MULTIARCH)/nodejs:share/nodejs:lib/nodejs"
 \
---shared-libuv
+--node-relative-path="lib/$(DEB_HOST_MULTIARCH)/nodejs:share/nodejs:lib/nodejs"
 
+DEB_CONFIGURE_EXTRA_FLAGS += --shared-nghttp2
+DEB_CONFIGURE_EXTRA_FLAGS += --shared-libuv
 DEB_CONFIGURE_EXTRA_FLAGS += --shared-openssl
 
 # map HOST ARCH AND OS, and if unknown let upstream guess

Bug#987827: unblock: node-opencv/7.0.0+git20200310.6c13234-1+b1

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 987...@bugs.debian.org

Please unblock package node-opencv

[ Reason ]
node-opencv ReadImageAsync segfaults #987364

[ Impact ]
- Users will occasionally have segfaults using node-opencv.
- Build tests and autopkgtest sometimes fails on some architectures

[ Tests ]
Yes, autopkgtest fails (but not always).
Specifically examples/readimage.js fails when repeated several times on ppc64el.
Also I manually checked that:
- it fails ~ every five times before the patch
- it doesn't fail at all after the patch

[ Risks ]
Very low risk.
The patch copies a buffer and frees it afterwise.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock node-opencv/7.0.0+git20200310.6c13234-1+b1
diff -Nru node-opencv-7.0.0+git20200310.6c13234/debian/changelog 
node-opencv-7.0.0+git20200310.6c13234/debian/changelog
--- node-opencv-7.0.0+git20200310.6c13234/debian/changelog  2020-06-15 
14:58:13.0 +0200
+++ node-opencv-7.0.0+git20200310.6c13234/debian/changelog  2021-04-30 
14:18:17.0 +0200
@@ -1,3 +1,10 @@
+node-opencv (7.0.0+git20200310.6c13234-2) unstable; urgency=medium
+
+  * Fix OpenCV::ReadImageAsync segfault (Closes: #987364).
+Thanks to Jochen Sprickerhof.
+
+ -- Jérémy Lal   Fri, 30 Apr 2021 14:18:17 +0200
+
 node-opencv (7.0.0+git20200310.6c13234-1) unstable; urgency=medium
 
   * Team upload
diff -Nru 
node-opencv-7.0.0+git20200310.6c13234/debian/patches/async_malloc.patch 
node-opencv-7.0.0+git20200310.6c13234/debian/patches/async_malloc.patch
--- node-opencv-7.0.0+git20200310.6c13234/debian/patches/async_malloc.patch 
1970-01-01 01:00:00.0 +0100
+++ node-opencv-7.0.0+git20200310.6c13234/debian/patches/async_malloc.patch 
2021-04-30 14:06:38.0 +0200
@@ -0,0 +1,27 @@
+Description: avoid occasional crash in async call to opencv
+Author: Jochen Sprickerhof 
+Reviewed-By: Jérémy Lal 
+Last-Update: 2021-04-30
+Forwarded: https://github.com/peterbraden/node-opencv/pull/679
+--- a/src/OpenCV.cc
 b/src/OpenCV.cc
+@@ -37,6 +37,7 @@
+ cv::Mat mbuf(len, 1, CV_64FC1, buf);
+ outputmat = cv::imdecode(mbuf, flags);
+ success = 1;
++free(buf);
+   } catch(...){
+ success = 0;
+   }
+@@ -224,8 +225,10 @@
+ // async
+ uint8_t *buf = (uint8_t *) 
Buffer::Data(Nan::To(info[0]).ToLocalChecked());
+ unsigned len = 
Buffer::Length(Nan::To(info[0]).ToLocalChecked());
++uint8_t *buf_new = (uint8_t *)malloc(len);
++memcpy(buf_new, buf, len);
+ Nan::Callback *callback = new Nan::Callback(cb.As());
+-Nan::AsyncQueueWorker(new AsyncImDecodeWorker(callback, buf, len, 
flags));
++Nan::AsyncQueueWorker(new AsyncImDecodeWorker(callback, buf_new, len, 
flags));
+ return;
+   }
+   // WILL have returned by here unless exception
diff -Nru node-opencv-7.0.0+git20200310.6c13234/debian/patches/series 
node-opencv-7.0.0+git20200310.6c13234/debian/patches/series
--- node-opencv-7.0.0+git20200310.6c13234/debian/patches/series 2020-06-15 
14:58:13.0 +0200
+++ node-opencv-7.0.0+git20200310.6c13234/debian/patches/series 2021-04-30 
14:06:30.0 +0200
@@ -1 +1,2 @@
+async_malloc.patch
 0002_patch_unittest.patch

Bug#987307: unblock: nodejs/12.21.0~dfsg-4

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nodejs

[ Reason ]
Fixing bug #987301: please add Breaks: node-babel-runtime (<< 7)

[ Impact ]
Problem for users having node-babel-runtime when upgrading
from buster to bullseye.

[ Tests ]
Piuparts... see also bug report.

[ Risks ]
Probably none.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock nodejs/12.21.0~dfsg-4
diff -Nru nodejs-12.21.0~dfsg/debian/changelog 
nodejs-12.21.0~dfsg/debian/changelog
--- nodejs-12.21.0~dfsg/debian/changelog2021-03-19 18:43:52.0 
+0100
+++ nodejs-12.21.0~dfsg/debian/changelog2021-04-21 12:42:46.0 
+0200
@@ -1,3 +1,11 @@
+nodejs (12.21.0~dfsg-4) unstable; urgency=medium
+
+  [ Andreas Beckmann ]
+  * nodejs: Add Breaks: node-babel-runtime (<< 7)
+for smoother upgrades from buster. (Closes: #987301)
+
+ -- Jérémy Lal   Wed, 21 Apr 2021 12:42:46 +0200
+
 nodejs (12.21.0~dfsg-3) unstable; urgency=medium
 
   * Upstream patch fix test-worker-prof (Closes: #985550)
diff -Nru nodejs-12.21.0~dfsg/debian/control nodejs-12.21.0~dfsg/debian/control
--- nodejs-12.21.0~dfsg/debian/control  2021-02-23 19:22:31.0 +0100
+++ nodejs-12.21.0~dfsg/debian/control  2021-04-21 12:40:54.0 +0200
@@ -69,7 +69,7 @@
 Suggests: npm
 Replaces: nodejs-legacy
 Conflicts: nodejs-legacy
-Breaks: node-typescript-types (<< 20210110~)
+Breaks: node-typescript-types (<< 20210110~), node-babel-runtime (<< 7)
 Provides: node-types-node (= ${types:Node})
 Description: evented I/O for V8 javascript - runtime executable
  Node.js is a platform built on Chrome's JavaScript runtime for easily

Bug#986729: unblock: nodejs/12.21.0~dfsg-3

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nodejs

[ Reason ]
Two patches are added:

* Upstream patch fix test-worker-prof
  Closes: #985550, "test-worker-prof is flaky on s390x"
  which has lead to ftbfs sometimes.
* THP ELF assembly: Add .note.GNU-stack section
  Closes: #980272, "'/usr/bin/node' started with executable stack"
  which IMO is an important security issue but i cannot proof it.

[ Impact ]
Potential FTBFS, potential security issue.

[ Tests ]
The first patch is a fixed upstream version of a flaky test.
The second patch was just verified manually like this:
readelf --program-headers --wide /usr/bin/node | grep -w GNU_STACK
  GNU_STACK  0x00 0x 0x 0x00 
0x00 RW  0x10

[ Risks ]
Zero risks.
nodejs and many other modules have test suites and there was no regression.
One change only affects the test suite, the other only affects the executable 
bit.


[ Checklist ]
  [ x ] all changes are documented in the d/changelog
  [ x ] I reviewed all changes and I approve them
  [ x ] attach debdiff against the package in testing


unblock nodejs/12.21.0~dfsg-3
diff -Nru nodejs-12.21.0~dfsg/debian/changelog 
nodejs-12.21.0~dfsg/debian/changelog
--- nodejs-12.21.0~dfsg/debian/changelog2021-02-23 19:14:23.0 
+0100
+++ nodejs-12.21.0~dfsg/debian/changelog2021-03-19 18:43:52.0 
+0100
@@ -1,3 +1,16 @@
+nodejs (12.21.0~dfsg-3) unstable; urgency=medium
+
+  * Upstream patch fix test-worker-prof (Closes: #985550)
+
+ -- Jérémy Lal   Fri, 19 Mar 2021 18:43:52 +0100
+
+nodejs (12.21.0~dfsg-2) unstable; urgency=medium
+
+  [ James Addison ]
+  * THP ELF assembly: Add .note.GNU-stack section (Closes: #980272)
+
+ -- Jérémy Lal   Fri, 19 Mar 2021 11:15:57 +0100
+
 nodejs (12.21.0~dfsg-1) unstable; urgency=high
 
   * New upstream version 12.21.0~dfsg
diff -Nru 
nodejs-12.21.0~dfsg/debian/patches/large_pages_assembly_gnu_stack.patch 
nodejs-12.21.0~dfsg/debian/patches/large_pages_assembly_gnu_stack.patch
--- nodejs-12.21.0~dfsg/debian/patches/large_pages_assembly_gnu_stack.patch 
1970-01-01 01:00:00.0 +0100
+++ nodejs-12.21.0~dfsg/debian/patches/large_pages_assembly_gnu_stack.patch 
2021-03-19 11:13:53.0 +0100
@@ -0,0 +1,12 @@
+Description: Adds .GNU-stack section header to disable executable stack flag
+Author: James Addison 
+Origin: https://github.com/nodejs/node/pull/37688
+--- a/src/large_pages/node_text_start.S
 b/src/large_pages/node_text_start.S
+@@ -1,3 +1,6 @@
++#if defined(__ELF__)
++.section .note.GNU-stack,"",@progbits
++#endif
+ .text
+ .align 0x2000
+ .global __node_text_start
diff -Nru nodejs-12.21.0~dfsg/debian/patches/series 
nodejs-12.21.0~dfsg/debian/patches/series
--- nodejs-12.21.0~dfsg/debian/patches/series   2021-02-23 19:14:23.0 
+0100
+++ nodejs-12.21.0~dfsg/debian/patches/series   2021-03-19 18:28:07.0 
+0100
@@ -1,3 +1,4 @@
+large_pages_assembly_gnu_stack.patch
 dfhs_module_path_arch_triplet.patch
 # 2012_kfreebsd.patch
 use_system_node_gyp.patch
@@ -15,3 +16,4 @@
 ppc64.patch
 python3.patch
 cjs-module-lexer.patch
+upstream-fix-test-worker-prof.patch
diff -Nru 
nodejs-12.21.0~dfsg/debian/patches/upstream-fix-test-worker-prof.patch 
nodejs-12.21.0~dfsg/debian/patches/upstream-fix-test-worker-prof.patch
--- nodejs-12.21.0~dfsg/debian/patches/upstream-fix-test-worker-prof.patch  
1970-01-01 01:00:00.0 +0100
+++ nodejs-12.21.0~dfsg/debian/patches/upstream-fix-test-worker-prof.patch  
2021-03-19 18:27:32.0 +0100
@@ -0,0 +1,93 @@
+From 04fb597996455d0abbe7b12bbc2d2a5ce16fbb3d Mon Sep 17 00:00:00 2001
+From: Rich Trott 
+Date: Sun, 14 Feb 2021 15:52:54 -0800
+Subject: [PATCH] test: fix flaky test-worker-prof
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fixes: https://github.com/nodejs/node/issues/26401
+Co-authored-by: Gireesh Punathil 
+
+PR-URL: https://github.com/nodejs/node/pull/37372
+Reviewed-By: Antoine du Hamel 
+Reviewed-By: Michaël Zasso 
+Reviewed-By: James M Snell 
+Reviewed-By: Luigi Pinca 
+Reviewed-By: Gireesh Punathil 
+---
+ test/sequential/sequential.status   |  4 
+ test/sequential/test-worker-prof.js | 15 ---
+ 2 files changed, 8 insertions(+), 11 deletions(-)
+
+--- a/test/sequential/sequential.status
 b/test/sequential/sequential.status
+@@ -24,8 +24,6 @@
+ [$system==win32]
+ # https://github.com/nodejs/node/issues/22327
+ test-http2-large-file: PASS, FLAKY
+-# https://github.com/nodejs/node/issues/26401
+-test-worker-prof: PASS, FLAKY
+ 
+ [$system==linux]
+ 
+@@ -45,10 +43,6 @@
+ # https://github.com/nodejs/node/pull/30819
+ test-perf-hooks: SKIP
+ 
+-[$arch==arm]
+-# https://github.com/nodejs/node/issues/26401#issuecomment-613095719
+-test-worker-prof: PASS, FLAKY
+-
+ [$arch==mipsel]
+ test-inspector-async-hook-setup-at-inspect-brk: SK

Re: Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Jérémy Lal]

Hi Thomas,

i've successfully built paperwork 2.0.2 in a clean sid chroot,
using gbp buildpackage (and sbuild).
The package is lintian clean.

However, i don't quite understand the usefulness of these packages:
- openpaperwork-core
- openpaperwork-core-doc
- openpaperwork-gtk
- openpaperwork-gtk-doc

I've installed openpaperwork-gtk and it seems it doesn't depend on
paperwork-gtk,
but maybe i'm missing some documentation, and the long package description
of
openpaperwork-gtk
doesn't help either.

Manually i had to do
dpkg -i paperwork-gtk_2.0.2-1_all.deb paperwork-backend_2.0.2-1_all.deb
 openpaperwork-core_2.0.2-1_all.deb
to get it, and that somehow looks wrong.

On the other hand, once installed, it seems to be working all right. I'll
try to do actual scanning with it later.

Jérémy

PS:

i really think it would be a bonus to Bullseye to have paperwork 2.
Maybe debian-release will allow it if we ensure the debian packaging is all
right very quickly.

Bug#926651: Acknowledgement (unblock: nodejs/10.15.2~dfsg-2)

[Jérémy Lal]

Ping ?
Also i forgot to mention (though it's written in the diff of the changelog):
Closes #919588 nodejs: FTBFS randomly

Jérémy

Bug#926651: unblock: nodejs/10.15.2~dfsg-2

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nodejs

Two trivial changes:

- two tests are marked as flaky
(one fails with eatmydata, one fails for no known reason
though i suspect it is related to running tests in parallel).

- debian/gbp.conf set to debian/buster branch

unblock nodejs/10.15.2~dfsg-2

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru nodejs-10.15.2~dfsg/debian/changelog 
nodejs-10.15.2~dfsg/debian/changelog
--- nodejs-10.15.2~dfsg/debian/changelog2019-02-28 15:52:30.0 
+0100
+++ nodejs-10.15.2~dfsg/debian/changelog2019-04-08 15:06:40.0 
+0200
@@ -1,3 +1,12 @@
+nodejs (10.15.2~dfsg-2) unstable; urgency=medium
+
+  * Avoid two tests to cause a FTBFS (Closes #919588)
++ test-fs-error-messages fails with eatmydata
++ test-net-listen-after-destroying-stdin is flaky
+  * gbp for debian/buster branch
+
+ -- Jérémy Lal   Mon, 08 Apr 2019 15:06:40 +0200
+
 nodejs (10.15.2~dfsg-1) unstable; urgency=high
 
   * New upstream version 10.15.2~dfsg
diff -Nru nodejs-10.15.2~dfsg/debian/gbp.conf 
nodejs-10.15.2~dfsg/debian/gbp.conf
--- nodejs-10.15.2~dfsg/debian/gbp.conf 2018-06-11 09:15:16.0 +0200
+++ nodejs-10.15.2~dfsg/debian/gbp.conf 2019-04-08 15:04:57.0 +0200
@@ -2,7 +2,7 @@
 
 [DEFAULT]
 upstream-branch = upstream-10.x
-debian-branch = master-10.x
+debian-branch = debian/buster
 
 pristine-tar = True
 sign-tags = True
diff -Nru nodejs-10.15.2~dfsg/debian/patches/test_ci_buildd.patch 
nodejs-10.15.2~dfsg/debian/patches/test_ci_buildd.patch
--- nodejs-10.15.2~dfsg/debian/patches/test_ci_buildd.patch 2019-01-30 
00:12:11.0 +0100
+++ nodejs-10.15.2~dfsg/debian/patches/test_ci_buildd.patch 2019-04-08 
15:02:58.0 +0200
@@ -31,7 +31,7 @@
@echo "Clean up any leftover processes, error if found."
 --- a/test/parallel/parallel.status
 +++ b/test/parallel/parallel.status
-@@ -8,6 +8,29 @@
+@@ -8,6 +8,35 @@
  # https://github.com/nodejs/node/issues/23207
  test-net-connect-options-port: PASS,FLAKY
  
@@ -58,10 +58,16 @@
 +# might fail, see https://github.com/nodejs/node/issues/17909
 +test-fs-utimes: PASS,FLAKY
 +
++# https://bugs.debian.org/919588
++## flaky on some user environments
++test-net-listen-after-destroying-stdin: PASS,FLAKY
++## fails when running with eatmydata
++test-fs-error-messages: PASS,FLAKY
++
  [$system==win32]
  test-http2-pipe: PASS,FLAKY
  test-worker-syntax-error: PASS,FLAKY
-@@ -21,6 +44,10 @@
+@@ -21,6 +50,10 @@
  # https://github.com/nodejs/node/issues/25028
  test-cli-node-options: PASS,FLAKY
  

Re: should i try nodejs 10.15.3 ?

[Jérémy Lal]

I meant "upload to unstable" and also this is from my usual email.

Le ven. 15 mars 2019 à 23:21, Jérémy Lal  a écrit :

> Hi,
>
> i believe it's reasonable to get nodejs 10.15.3 into buster.
> The diff is not trivial, though, with many fixes to the program, the docs,
> and the build system (debdiff attached).
> Tests behave very well in experimental.
> No ABI/API changes.
> If i upload nodejs 10.15.3 to experimental, is there a chance it can be
> accepted to testing ?
>
> Thank you for even considering,
> Jérémy
>
>
>

Bug#924436: unblock: node-gyp/3.8.0-6

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-gyp

- fixes #921625: node-gyp cannot extract tarballs,
something that happens when installing big projects
from npm.
- removes temporarily-needed Breaks:node-modern-syslog,
which was only there to speed up migration of nodejs
- adds upstream tests as autopkgtest, but not
during build to avoid surprises this late winter.

Please find the debdiff attached.

unblock node-gyp/3.8.0-6

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru node-gyp-3.8.0/debian/changelog node-gyp-3.8.0/debian/changelog
--- node-gyp-3.8.0/debian/changelog 2019-01-28 16:40:25.0 +0100
+++ node-gyp-3.8.0/debian/changelog 2019-03-04 00:51:30.0 +0100
@@ -1,3 +1,22 @@
+node-gyp (3.8.0-6) unstable; urgency=medium
+
+  * Upstream test suite depends on build-essential
+
+ -- Jérémy Lal   Mon, 04 Mar 2019 00:51:30 +0100
+
+node-gyp (3.8.0-5) unstable; urgency=medium
+
+  [ Mattia Rizzolo ]
+  * Remove the Breaks:node-modern-syslog added in the previous
+upload: it was a workaround to avoid ci testing regression.
+
+  [ Jérémy Lal ]
+  * Upstream support for node-tar 3 (Closes: #921625)
+  * Drop node-fstream dependency, unneeded with tar3-compat.patch
+  * Add upstream test suite to autopkgtests
+
+ -- Jérémy Lal   Sat, 02 Mar 2019 23:11:39 +0100
+
 node-gyp (3.8.0-4) unstable; urgency=medium
 
   * Team upload
diff -Nru node-gyp-3.8.0/debian/control node-gyp-3.8.0/debian/control
--- node-gyp-3.8.0/debian/control   2019-01-28 16:37:51.0 +0100
+++ node-gyp-3.8.0/debian/control   2019-03-02 19:32:09.0 +0100
@@ -18,7 +18,6 @@
  , nodejs
  , libnode-dev
  , gyp (>= 0.1+20150913git1f374df9)
- , node-fstream
  , node-glob
  , node-graceful-fs
  , node-mkdirp
@@ -31,7 +30,6 @@
  , node-tar
  , node-which
 Recommends: build-essential
-Breaks: node-modern-syslog (<< 1.1.4-2)
 Description: Native addon build tool for Node.js
  node-gyp is a cross-platform command-line tool written in Node.js
  for compiling native addon modules for Node.js.
diff -Nru node-gyp-3.8.0/debian/patches/series 
node-gyp-3.8.0/debian/patches/series
--- node-gyp-3.8.0/debian/patches/series2019-01-28 16:31:48.0 
+0100
+++ node-gyp-3.8.0/debian/patches/series2019-03-02 18:55:56.0 
+0100
@@ -2,3 +2,4 @@
 2003_fPIC_ia32.patch
 kfreebsd.patch
 link_libnode.patch
+tar3-compat.patch
diff -Nru node-gyp-3.8.0/debian/patches/tar3-compat.patch 
node-gyp-3.8.0/debian/patches/tar3-compat.patch
--- node-gyp-3.8.0/debian/patches/tar3-compat.patch 1970-01-01 
01:00:00.0 +0100
+++ node-gyp-3.8.0/debian/patches/tar3-compat.patch 2019-03-02 
18:55:42.0 +0100
@@ -0,0 +1,125 @@
+From 5f924ce62c9bca9ab9c2e547bfb87b9a391271ed Mon Sep 17 00:00:00 2001
+From: isaacs 
+Date: Tue, 30 May 2017 20:52:45 -0400
+Subject: [PATCH] Upgrade to tar v3
+
+Tar version 3 performs better and is more well tested than its
+predecessor.  npm will be using this in the near future, so there is no
+benefit in shipping a node-gyp that uses the slower and less reliable
+fstream-based tar.
+
+This drops support for node 0.x, and thus should be considered a
+breaking semver-major change.
+
+PR-URL: https://github.com/nodejs/node-gyp/pull/1212
+Reviewed-By: Refael Ackermann 
+Reviewed-By: Ben Noordhuis 
+Reviewed-By: Gibson Fahnestock 
+---
+ lib/install.js | 38 --
+ package.json   |  5 ++---
+ 2 files changed, 18 insertions(+), 25 deletions(-)
+
+--- a/lib/install.js
 b/lib/install.js
+@@ -20,10 +20,8 @@
+   , rm = require('rimraf')
+   , path = require('path')
+   , crypto = require('crypto')
+-  , zlib = require('zlib')
+   , log = require('npmlog')
+   , semver = require('semver')
+-  , fstream = require('fstream')
+   , request = require('request')
+   , mkdir = require('mkdirp')
+   , processRelease = require('./process-release')
+@@ -148,41 +146,33 @@
+   var tarPath = gyp.opts.tarball
+   var badDownload = false
+ , extractCount = 0
+-, gunzip = zlib.createGunzip()
+-, extracter = tar.Extract({ path: devDir, strip: 1, filter: isValid })
+ 
+   var contentShasums = {}
+   var expectShasums = {}
+ 
+   // checks if a file to be extracted from the tarball is valid.
+   // only .h header files and the gyp files get extracted
+-  function isValid () {
+-var name = this.path.substring(devDir.length + 1)
+-var isValid = v

Bug#864743: unblock: nodejs/4.8.3~dfsg-1

[Jérémy Lal]

Le sam. 9 mars 2019 à 16:58, Adam D. Barratt  a
écrit :

> On Sun, 2018-12-02 at 16:47 +0100, Julien Cristau wrote:
> > Control: tag -1 - moreinfo
> >
> > On Sat, Jun 17, 2017 at 05:53:31PM +0100, Adam D. Barratt wrote:
> > > retitle 864743 stretch-pu: package nodejs
> > > user release.debian@packages.debian.org
> > > usertags 864743 = pu
> > > tags 864743 + stretch moreinfo
> > > thanks
> > >
> > > On Wed, 2017-06-14 at 00:40 +0200, Jérémy Lal wrote:
> > > > Please unblock package nodejs
> > > >
> > > > - it's a LTS upstream update from 4.8.2 to 4.8.3
> > > > - it fixes #855018, #855018 to avoid test failures
> > > > - it fixes #864735  with a Priority: optional on source package
> > > > - it restores how upstream finds global nodejs modules:
> > > >   /usr/lib/nodejs (as before) when executable is in
> > > > /usr/bin/nodejs
> > > >   /usr/local/lib/nodejs (not as before) when executable is in
> > > >   /usr/local/bin/nodejs.
> > > >   It was a bad idea to disable this in the first place.
> > > >
> > > > I've excluded upstream changes concerning:
> > > > - tests and their fixtures
> > > > - html documentation
> > > > - markdown documentation, changelog, readme, ...
> > >
> > > Sorry this didn't get a reply before the release, although it was
> > > filed
> > > very late in the process.
> > >
> > > Converting to a proto-pu request so we can consider what might be
> > > appropriate for an update in stable.
> > >
> >
> > Sorry for the delay.  Looks fine for upload if there's still
> > interest.
>
> Ping? I plan on closing this bug in a couple of weeks if nothing
> changes.
>
> Regards,
>
> Adam
>

It's probably meaningless to upload any change to nodejs in stretch right
now.
I'd rather close this bug.

Jérémy

Bug#919585: RM: node-groove/2.5.0-4 -- RoM; FTBFS; orphaned; abandoned upstream

[Jérémy Lal]

Le dim. 10 févr. 2019 à 00:14, Adam D. Barratt  a
écrit :

> Control: tags -1 + moreinfo
>
> On Thu, 2019-01-17 at 16:26 +0100, Jérémy Lal wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: rm
> >
> > Note that groovebasin is already removed from testing.
>
> So where are/were you requesting removal from?
>

The idea was to remove node-groove from testing and the only software
using it was groovebasin, which was already removed.
Maybe even from unstable since the situation for that software is not going
to improve.
And the message i wrote wasn't explicit enough, sorry about that.

Jérémy

Bug#919585: RM: node-groove/2.5.0-4 -- RoM; FTBFS; orphaned; abandoned upstream

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Note that groovebasin is already removed from testing.

Thanks
Jérémy

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#886294: transition: nodejs

[Jérémy Lal]

2018-01-30 20:31 GMT+01:00 Emilio Pozuelo Monfort :

> On 29/01/18 20:15, Philipp Kern wrote:
> > On 2018-01-25 11:36, Aurelien Jarno wrote:
> >> Bumping the baseline to z196 looks like the easiest way and as you said,
> >> it would also fix go, rustc and maybe more software. However we
> discussed
> >> raising the ISA to z10 about one year and a half ago, and the conclusion
> >> was that we still have users with older machines. I'll try to restart
> >> the discussion again.
> >
> > What's the venue to have this discussion in? :)
>
> debian-s390@l.d.o ?
>
> FWIW you two (Philipp and Aurelien) are the two current s390x porters, so I
> think it's mostly your call.


Hi,

now that this issue has been solved, it seems nodejs is ready for migration
to testing.

Jérémy.

Bug#886294: transition: nodejs

[Jérémy Lal]

cc-ing s390x team to ask (re)building nodejs-8.9.3~dfsg-11 on zemlinsky.

2018-01-21 18:46 GMT+01:00 Jérémy Lal <kapo...@melix.org>:

> 2018-01-21 17:45 GMT+01:00 Jérémy Lal <kapo...@melix.org>:
>
>> 2018-01-21 16:25 GMT+01:00 Emilio Pozuelo Monfort <po...@debian.org>:
>>
>>> On 09/01/18 19:02, Jérémy Lal wrote:
>>> > It should be all right on armxx.
>>> > However what i believed to be a memory exhaustion bug might be
>>> > some problem with v8 and some mips/s390x processors (which is bad news,
>>> > but i'm not sure it's the case yet).
>>>
>>> I'm not sure what the problem is on mips(el),
>>
>>
>> For mips(el) it was an issue with the number of jobs used during tests,
>> leading to memory exhaustion. Fixed in nodejs-8.9.3~dfsg-9 by setting
>> that number of jobs to "one" when SCHROOT_USER is set.
>>
>
> I was too optimistic here, judging from the build logs and failures it
> seems there
> too there are failures on specific processors.
>

 So that problem is #888021 and has been fixed thanks to James Cowgill in
version
nodejs-8.9.3~dfsg-10.


> but on s390x you're getting
>>> illegal instructions on zemlinsky, which is a Z10 mainframe. Looks like
>>> newer
>>> node possibly bumped the baseline, or just accidentally introduced
>>> instructions
>>> not supported by our baseline.
>>>
>>
>> Starting investigations about that. Hopefully it's a change that could
>> have been
>> backward-compatible.
>>
>
nodejs/v8 somewhat officially support s390x down to z196.
I removed the added march=z196 flag and uploaded it into
nodejs-8.9.3~dfsg-11.
It would be wonderful to build it on zemlinsky to see what happens.

Jérémy

Bug#886294: transition: nodejs

[Jérémy Lal]

2018-01-21 17:45 GMT+01:00 Jérémy Lal <kapo...@melix.org>:

>
>
> 2018-01-21 16:25 GMT+01:00 Emilio Pozuelo Monfort <po...@debian.org>:
>
>> On 09/01/18 19:02, Jérémy Lal wrote:
>> > It should be all right on armxx.
>> > However what i believed to be a memory exhaustion bug might be
>> > some problem with v8 and some mips/s390x processors (which is bad news,
>> > but i'm not sure it's the case yet).
>>
>> I'm not sure what the problem is on mips(el),
>
>
> For mips(el) it was an issue with the number of jobs used during tests,
> leading to memory exhaustion. Fixed in nodejs-8.9.3~dfsg-9 by setting
> that number of jobs to "one" when SCHROOT_USER is set.
>

I was too optimistic here, judging from the build logs and failures it
seems there
too there are failures on specific processors.




> but on s390x you're getting
>> illegal instructions on zemlinsky, which is a Z10 mainframe. Looks like
>> newer
>> node possibly bumped the baseline, or just accidentally introduced
>> instructions
>> not supported by our baseline.
>>
>
> Starting investigations about that. Hopefully it's a change that could
> have been
> backward-compatible.
>
> Jérémy
>
>

Bug#886294: transition: nodejs

[Jérémy Lal]

2018-01-21 16:25 GMT+01:00 Emilio Pozuelo Monfort <po...@debian.org>:

> On 09/01/18 19:02, Jérémy Lal wrote:
> > It should be all right on armxx.
> > However what i believed to be a memory exhaustion bug might be
> > some problem with v8 and some mips/s390x processors (which is bad news,
> > but i'm not sure it's the case yet).
>
> I'm not sure what the problem is on mips(el),


For mips(el) it was an issue with the number of jobs used during tests,
leading to memory exhaustion. Fixed in nodejs-8.9.3~dfsg-9 by setting
that number of jobs to "one" when SCHROOT_USER is set.


> but on s390x you're getting
> illegal instructions on zemlinsky, which is a Z10 mainframe. Looks like
> newer
> node possibly bumped the baseline, or just accidentally introduced
> instructions
> not supported by our baseline.
>

Starting investigations about that. Hopefully it's a change that could have
been
backward-compatible.

Jérémy

Bug#886294: transition: nodejs

[Jérémy Lal]

It should be all right on armxx.
However what i believed to be a memory exhaustion bug might be
some problem with v8 and some mips/s390x processors (which is bad news,
but i'm not sure it's the case yet).

Jérémy

2018-01-09 18:55 GMT+01:00 Felipe Sateler <fsate...@debian.org>:

> On Thu, 4 Jan 2018 18:43:13 +0100 Emilio Pozuelo Monfort
> <po...@debian.org> wrote:
> > On 04/01/18 16:28, Jérémy Lal wrote:
> > >
> > >
> > > 2018-01-04 12:09 GMT+01:00 Emilio Pozuelo Monfort <po...@debian.org
> > > <mailto:po...@debian.org>>:
> > >
> > > Control: tags -1 confirmed
> > >
> > > On 04/01/18 02:40, Jérémy Lal wrote:
> > > > Package: release.debian.org <http://release.debian.org>
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > <mailto:release.debian@packages.debian.org>
> > > > Usertags: transition
> > > >
> > > > nodejs 8.9.3 brings the following improvements for debian:
> > > > - a backported openssl 1.1.0 compatibility from nodejs 9.x branch
> > > > - hard-to-debug segmentation faults fix (#878674)
> > > > - it is an upstream LTS branch
> > > >
> > > > Julien Puydt and me checked all direct reverse build-deps and i
> > > > took care of several issues that appeared with the update:
> > > > - test failures caused by the move to openssl 1.1.0
> > > > - failures caused by exception names changes in assert module
> > > > - failures caused by api that was deprecated long ago then
> dropped
> > > >
> > > > There was no major issue with pure javascript modules and
> > > > addons depending on nodejs-abi were rebuilt smoothly after the
> fixes.
> > >
> > > The ongoing nodejs transition to 6.12.0 hasn't been completed yet
> due to a build
> > > failure on mips(el) and those segfaults. Given 8.9/experimental
> seems to fix all
> > > those issues, let's go with that version.
> > >
> > >
> > > Cool. Do you mean i should upload it to unstable now ?
>
> For the record, Jérémy Lal uploaded nodejs a few days ago (although it
> is not built on all archs yet, arm64 and armhf are missing).
>
> Saludos
>

Bug#886294: transition: nodejs

[Jérémy Lal]

2018-01-04 12:09 GMT+01:00 Emilio Pozuelo Monfort <po...@debian.org>:

> Control: tags -1 confirmed
>
> On 04/01/18 02:40, Jérémy Lal wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > nodejs 8.9.3 brings the following improvements for debian:
> > - a backported openssl 1.1.0 compatibility from nodejs 9.x branch
> > - hard-to-debug segmentation faults fix (#878674)
> > - it is an upstream LTS branch
> >
> > Julien Puydt and me checked all direct reverse build-deps and i
> > took care of several issues that appeared with the update:
> > - test failures caused by the move to openssl 1.1.0
> > - failures caused by exception names changes in assert module
> > - failures caused by api that was deprecated long ago then dropped
> >
> > There was no major issue with pure javascript modules and
> > addons depending on nodejs-abi were rebuilt smoothly after the fixes.
>
> The ongoing nodejs transition to 6.12.0 hasn't been completed yet due to a
> build
> failure on mips(el) and those segfaults. Given 8.9/experimental seems to
> fix all
> those issues, let's go with that version.
>

Cool. Do you mean i should upload it to unstable now ?

Jérémy

Bug#886294: transition: nodejs

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

nodejs 8.9.3 brings the following improvements for debian:
- a backported openssl 1.1.0 compatibility from nodejs 9.x branch
- hard-to-debug segmentation faults fix (#878674)
- it is an upstream LTS branch

Julien Puydt and me checked all direct reverse build-deps and i
took care of several issues that appeared with the update:
- test failures caused by the move to openssl 1.1.0
- failures caused by exception names changes in assert module
- failures caused by api that was deprecated long ago then dropped

There was no major issue with pure javascript modules and
addons depending on nodejs-abi were rebuilt smoothly after the fixes.

Thank you for your attention,
Jérémy


Ben file:

title = "nodejs";
is_affected = .depends ~ "nodejs-abi-48" | .depends ~ "nodejs-abi-57";
is_good = .depends ~ "nodejs-abi-57";
is_bad = .depends ~ "nodejs-abi-48";

Bug#849505: transition: nodejs

[Jérémy Lal]

2017-08-30 23:26 GMT+02:00 Emilio Pozuelo Monfort <po...@debian.org>:

> On 29/08/17 23:15, Sebastiaan Couwenberg wrote:
> > On 06/25/2017 01:15 PM, Jonathan Wiltshire wrote:
> >> Now stretch is released we can deal with this.
> >>
> >> On Wed, Dec 28, 2016 at 12:49:33AM +0100, Jérémy Lal wrote:
> >>> Transition should have minimal impact on these addons.
> >>> Most other pure Node.js modules should be okay - they either
> >>> are already compatible with Node.js 6 or have upstream updates
> >>> providing that compatibility.
> >>
> >> This sounds rather, well, hopeful. Please stage the transition in
> >> experimental first, and test/fix reverse dependencies. Then come back
> and
> >> we'll schedule a time to do it in unstable.
> >>
> >> (Transitions should really be ready to go by the time they come to us;
> >> they should also be able to happen quickly, because a blocked transition
> >> holds up all sorts of other work.)
> >
> > Jérémy, the transition was started by the upload of nodejs to unstable,
> > but you've not replied to the above yet.
> >
> > Can you confirm that all reverse dependencies build successfully with
> > the new nodejs in unstable?
> >
> > If so, the binNMUs can be scheduled to move this transition along.
>
> The problem is the nodejs mips64el failure, caused by the mips64el gcc-7
> bug
> (#871514). I'm waiting for that to be fixed first.
>

I've tried building with g++-6 but there is one test failure. I'm looking
why this is.

Jérémy

Bug#849505: transition: nodejs

[Jérémy Lal]

2017-08-29 23:15 GMT+02:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>:

> On 06/25/2017 01:15 PM, Jonathan Wiltshire wrote:
> > Now stretch is released we can deal with this.
> >
> > On Wed, Dec 28, 2016 at 12:49:33AM +0100, Jérémy Lal wrote:
> >> Transition should have minimal impact on these addons.
> >> Most other pure Node.js modules should be okay - they either
> >> are already compatible with Node.js 6 or have upstream updates
> >> providing that compatibility.
> >
> > This sounds rather, well, hopeful. Please stage the transition in
> > experimental first, and test/fix reverse dependencies. Then come back and
> > we'll schedule a time to do it in unstable.
> >
> > (Transitions should really be ready to go by the time they come to us;
> > they should also be able to happen quickly, because a blocked transition
> > holds up all sorts of other work.)
>
> Jérémy, the transition was started by the upload of nodejs to unstable,
> but you've not replied to the above yet.
>
> Can you confirm that all reverse dependencies build successfully with
> the new nodejs in unstable?
>
> If so, the binNMUs can be scheduled to move this transition along.
>
> I just uploaded a new upstream release of node-mapnik, that won't need
> an NMU now, but the other rdeps still do.
>
> Kind Regards,
>

All the reverse deps of nodejs-abi-xx should rebuild fine.

Jérémy

Bug#872023: transition: nodejs

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Transition from nodejs 4 to nodejs 6, with module abi change from
version 46 to version 48.
All nodejs c++ addons (build-depending on nodejs-dev) must be rebuilt.

Also Julien Puydt rebuilt all node modules packages against nodejs 6
to check for failures and report them:
- node-chai #868319 fixed upstream
- node-argparse #868294 might be fixed upstream
- node-evp-bytestokey fails and is deprecated. #868298

Also i'm using nodejs 6 from experimental for some time now, and i don't
see breakage.

Ben file:

title = "nodejs";
is_affected = .build-depends ~ /nodejs-dev/;
is_good = .depends ~ /nodejs-abi-48/;
is_bad = .depends ~ /nodejs-abi-46/;


Regards,

Jérémy

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

Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#864743: unblock: nodejs/4.8.3~dfsg-1

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nodejs

- it's a LTS upstream update from 4.8.2 to 4.8.3
- it fixes #855018, #855018 to avoid test failures
- it fixes #864735  with a Priority: optional on source package
- it restores how upstream finds global nodejs modules:
  /usr/lib/nodejs (as before) when executable is in /usr/bin/nodejs
  /usr/local/lib/nodejs (not as before) when executable is in
  /usr/local/bin/nodejs.
  It was a bad idea to disable this in the first place.

I've excluded upstream changes concerning:
- tests and their fixtures
- html documentation
- markdown documentation, changelog, readme, ...

unblock nodejs/4.8.3~dfsg-1

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (1001, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru --exclude 'test*' --exclude '*.md' --exclude '*.html' 
nodejs-4.8.2~dfsg/debian/changelog nodejs-4.8.3~dfsg/debian/changelog
--- nodejs-4.8.2~dfsg/debian/changelog  2017-04-04 15:46:55.0 +0200
+++ nodejs-4.8.3~dfsg/debian/changelog  2017-06-14 00:23:33.0 +0200
@@ -1,3 +1,15 @@
+nodejs (4.8.3~dfsg-1) unstable; urgency=medium
+
+  * New upstream version 4.8.3~dfsg
+  * Let nodejs global modules be searched in ${prefixDir}/lib/nodejs
+as it was intended by upstream. This does not change behavior
+of system-installed nodejs.
+  * Add ca-certificates to autopkgtest depends. (Closes: #855018)
+  * Update test_ci_buildd.patch to skip test-process-config (Closes: #855018)
+  * Priority: optional on source package (Closes: #864735)
+
+ -- Jérémy Lal <kapo...@melix.org>  Wed, 14 Jun 2017 00:23:33 +0200
+
 nodejs (4.8.2~dfsg-1) unstable; urgency=medium
 
   * New upstream version 4.8.2~dfsg
diff -Nru --exclude 'test*' --exclude '*.md' --exclude '*.html' 
nodejs-4.8.2~dfsg/debian/control.in nodejs-4.8.3~dfsg/debian/control.in
--- nodejs-4.8.2~dfsg/debian/control.in 2017-04-03 00:07:03.0 +0200
+++ nodejs-4.8.3~dfsg/debian/control.in 2017-06-13 23:01:01.0 +0200
@@ -1,5 +1,6 @@
 Source: nodejs
 Section: web
+Priority: optional
 Maintainer: Debian Javascript Maintainers 
<pkg-javascript-de...@lists.alioth.debian.org>
 Uploaders: Jérémy Lal <kapo...@melix.org>,
  Jonas Smedegaard <d...@jones.dk>
diff -Nru --exclude 'test*' --exclude '*.md' --exclude '*.html' 
nodejs-4.8.2~dfsg/debian/patches/2001_FHS_and_rename_to_nodejs.patch 
nodejs-4.8.3~dfsg/debian/patches/2001_FHS_and_rename_to_nodejs.patch
--- nodejs-4.8.2~dfsg/debian/patches/2001_FHS_and_rename_to_nodejs.patch
2017-04-04 15:41:17.0 +0200
+++ nodejs-4.8.3~dfsg/debian/patches/2001_FHS_and_rename_to_nodejs.patch
2017-06-13 23:00:41.0 +0200
@@ -1,17 +1,18 @@
 Description: FHS path for nodejs, rename man page to nodejs.
  Use /usr/lib/nodejs for packaged modules.
+ Fix test.
  
 Forwarded: not-needed
 Author: Jérémy Lal <kapo...@melix.org>
-Last-Update: 2013-03-16
+Last-Update: 2017-05-03
 --- a/lib/module.js
 +++ b/lib/module.js
-@@ -453,7 +453,7 @@
- homeDir = process.env.HOME;
+@@ -462,7 +462,7 @@
+   } else {
+ prefixDir = path.resolve(process.execPath, '..', '..');
}
- 
--  var paths = [path.resolve(process.execPath, '..', '..', 'lib', 'node')];
-+  var paths = ['/usr/lib/nodejs'];
+-  var paths = [path.resolve(prefixDir, 'lib', 'node')];
++  var paths = [path.resolve(prefixDir, 'lib', 'nodejs')];
  
if (homeDir) {
  paths.unshift(path.resolve(homeDir, '.node_libraries'));
@@ -49,3 +50,22 @@
  .RB [ \-\-v8-options ]
  
  Execute without arguments to start the REPL.
+--- a/test/parallel/test-module-loading-globalpaths.js
 b/test/parallel/test-module-loading-globalpaths.js
+@@ -68,12 +68,12 @@
+   env['HOME'] = env['USERPROFILE'] = bothHomeDir;
+   runTest('$HOME/.node_modules', env);
+ 
+-  // Test module in $PREFIX/lib/node.
+-  // Write module into $PREFIX/lib/node.
+-  const expectedString = '$PREFIX/lib/node';
++  // Test module in $PREFIX/lib/nodejs.
++  // Write module into $PREFIX/lib/nodejs.
++  const expectedString = '$PREFIX/lib/nodejs';
+   const prefixLibPath = path.join(prefixPath, 'lib');
+   fs.mkdirSync(prefixLibPath);
+-  const prefixLibNodePath = path.join(prefixLibPath, 'node');
++  const prefixLibNodePath = path.join(prefixLibPath, 'nodejs');
+   fs.mkdirSync(prefixLibNodePath);
+   const pkgPath = path.join(prefixLibNodePath, pkgName + '.js');
+   fs.writeFileSync(pkgPath, 'exports.string = \'' + expectedString + '\';');
diff -Nru --exclude 'test*' --exclude '*.md' --exclude '*.html' 
nodejs-4.8.2~dfsg/debian/patches/2012_kfreebsd.patch 
nodejs-4.8.3~dfsg/debian/patches/2012_kfreebsd.patch
--- no

Re: Bug#857986: [Pkg-javascript-devel] Bug#857986: npm: This pakcage is 3 years old? (consider removal)

[Jérémy Lal]

2017-05-22 16:10 GMT+02:00 Pirate Praveen :

> On തിങ്കള്‍ 22 മെയ് 2017 06:41 വൈകു, Jonas Smedegaard wrote:
> > ...for the _initial_ packaging work.
> >
> > We are package *maintainers*.
>
> If you have not realized, we are discussing about maintaining an
> existing package. I think you have also not realized the meaning of team
> maintained packages. The person who did the initial package need not be
> the maintainer of the packager for ever. When there is enough interest
> in the package, it will remain maintained else it gets removed.
>

I did the initial npm packaging. At that moment i was optimistic upstream
wouldn't add or change dependencies too much. I was wrong, npm is
constantly adding/removing modules through the months and years, requiring
a lot of maintainer work to keep up.
I think Jonas was pointing out that updating npm today won't actually solve
any issue regarding npm maintenance. Some company should fund that work.

Jérémy

Re: Bug#857986: npm: This pakcage is 3 years old? (consider removal)

[Jérémy Lal]

2017-05-19 12:07 GMT+02:00 Riku Voipio <riku.voi...@iki.fi>:

> Jérémy Lal:
> > To others, preoccupied that npm won't be available in debian:
> > - please help with npm maintenance
> > - hopefully we'll make an updated version installable through debian
> backports
>
> Are there any complications to building npm as part of nodejs package?
>

There are complications to distributing npm: it depends on a LOT of
modules, which
means it requires a lot of debian-maintainer time to package, and update.
Using the upstream nodejs tarball as source for npm or the upstream npm
tarball
does not change anything about that.

Jérémy

Bug#860528: Acknowledgement (nmu: libev_1:4.22-1)

[Jérémy Lal]

2017-04-18 11:32 GMT+02:00 Adam D. Barratt <a...@adam-barratt.org.uk>:
> On 2017-04-18 10:15, Jérémy Lal wrote:
>>
>> My mistake, i meant to ask a binNMU in testing/unstable
>>
>> nmu libev_1:4.22-1 . ANY . stretch . -m "Rebuild to Close #860301"
>
>
> For a rebuild in unstable, that's still wrong, I'm afraid - just drop the "
> . stretch", as unstable is the default.

Should the request be for unstable, and then an unblock request so it
goes to stretch ?

I'm confused.
Jérémy

Bug#860528: Acknowledgement (nmu: libev_1:4.22-1)

[Jérémy Lal]

My mistake, i meant to ask a binNMU in testing/unstable

nmu libev_1:4.22-1 . ANY . stretch . -m "Rebuild to Close #860301"

Bug#860528: nmu: libev_1:4.22-1

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu libev_1:4.22-1 . ANY . jessie . -m "Rebuild to Close #860301"

I don't really understand what's going on...
bug reporter says it's fixed when rebuilt. So let's rebuild !

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (1001, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: Remove all leaf node-* packages (and libjs-* too) from testing ?

[Jérémy Lal]

2017-04-18 10:09 GMT+02:00 Niels Thykier <ni...@thykier.net>:
> Jérémy Lal:
>> To be more precise the question should be:
>>
>> Remove all leaf node-* packages AND not installing an executable in 
>> /usr/(s)bin/
>> AND not depending on node-gyp.
>>
>> Because a nodejs module in debian falls in these categories:
>> - needed by another module
>> - needed by an executable
>> - building js libs for a web app
>> - providing an executable
>> - compiling a nodejs c++ addon
>>
>> So a leaf module not falling in these categories is useless in debian/stable.
>>
>> Attention: i am not asking removal from debian/unstable. Maintainers
>> currently packaging a tree of nodejs modules won't be affected.
>>
>> Can anyone help me providing the release team with a list of those ?
>>
>> Jérémy
>>
>
> Hi Jérémy,
>
> Did such a list materialise?

No, i hoped some clever programmer would show up and explain how it
could be obtained from udd or something. I guess i need to do it asap by hand.

Jérémy

Remove all leaf node-* packages (and libjs-* too) from testing ?

[Jérémy Lal]

To be more precise the question should be:

Remove all leaf node-* packages AND not installing an executable in /usr/(s)bin/
AND not depending on node-gyp.

Because a nodejs module in debian falls in these categories:
- needed by another module
- needed by an executable
- building js libs for a web app
- providing an executable
- compiling a nodejs c++ addon

So a leaf module not falling in these categories is useless in debian/stable.

Attention: i am not asking removal from debian/unstable. Maintainers
currently packaging a tree of nodejs modules won't be affected.

Can anyone help me providing the release team with a list of those ?

Jérémy

Re: Please don't remove npm from Stretch

[Jérémy Lal]

2017-04-03 16:45 GMT+02:00 Niels Thykier <ni...@thykier.net>:
> Thomas Goirand:
>> Hi,
>>
>> [...]
>>
>
>> Also, removing such a non-leaf package at this point of the release is a
>> way too late. IMO, a bug should have been opened a long time ago asking
>> for an upgrade of the package.
>>
>
>
> Hi,
>
> I would (also) strongly prefer, if we got better at finding and dealing
> with things like outside the freeze.  That said...
>
> In the concrete case, the removal does not look too bad at a metadata
> level.  Assuming qtwebchannel5-examples can drop its dependency, the
> rest can be removed from testing without affecting any other package
> than those listed below.
>
> """
> $ dak rm -nR -s testing npm
> [...]
> Checking reverse dependencies...
> # Broken Depends:
> npm2deb: npm2deb
> qtwebchannel-opensource-src: qtwebchannel5-examples [...]
>
> # Broken Build-Depends:
> ruby-license-finder: npm
> """
>
>> Last, at this point in time, I believe we should discuss the issue with
>> the release team. They may agree, for example, that we upgrade the
>> package to a newer version (this is unlikely, but it is up to them to
>> tell). They may don't agree that we "fix" so many source package to
>> remove the build-dependency. Anyway, the solution should be discuss with
>> them. Therefore, I'm CC-ing the release team.
>>
>
> From my PoV; upgrade is unlikely to be accepted.  Removal appears to be
> doable, so the real question is:
>
>  * Is npm so out of date that it is release critical?
>
> If yes, fix qtwebchannel-opensource-src (etc.) and remove the rest from
> stretch.  If no, tag it -ignore and move on.  To be honest, I know next
> to nothing about npm and its state, so I will apply "Do-cracy" to this
> decision.
>   AFAICT, Jérémy Lal have done all of the uploads since 2013 and is the
> sole committer to the packaging between 2013-08 to 2014-08[1], which
> pretty much makes Jérémy the closest person to an "active do'er" in this
> case.
>
> @Jérémy Lal: Your call:
>
>  * Are you willing to support npm for 3-5 years in stretch given its
>current state?
>- If yes, then tag the npm bug stretch-ignore or downgrade it
>- If no, then we will effectuate the removal before the release.

I agree completely with the above analysis, and I'm not willing to support
the current npm version that is in testing.

To others, preoccupied that npm won't be available in debian:
- please help with npm maintenance
- hopefully we'll make an updated version installable through debian backports,

Jérémy.

Bug#858124: RM: npm/1.4.21+ds-3

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

This package is obsolete, too difficult to maintain and to
update to a new upstream version, making it something that
shouldn't be shipped in next debian stable.

I've postponed that removal for years, believing one day
i'd find the time and motivation to update it, and that
never happened - i feel so sorry for that.

Please see also https://bugs.debian.org/857986 for the list
of reverse (build-) dependencies blocking the bug.

Cheers,
Jérémy.


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#849505: nodejs 6.9 in unstable, manual transition, schedule

[Jérémy Lal]

2017-01-04 14:32 GMT+01:00 Emilio Pozuelo Monfort <po...@debian.org>:
> On 04/01/17 12:02, Jérémy Lal wrote:
>> 2017-01-04 11:56 GMT+01:00 Jonas Smedegaard <jo...@jones.dk>:
>>> Quoting Jérémy Lal (2017-01-04 10:12:44)
>>>> 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin <w...@debian.org>:
>>>>> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote:
>>>>>> i really think it would be best to have nodejs 6.9 in next debian 
>>>>>> release.
>>>>>> That version is currently in experimental and i was about to upload it
>>>>>> to unstable, but i tried to do things right and prepared the addons
>>>>>> that need to be rebuilt and binNMUed, then opened a transition bug
>>>>>> #849505.
>>>>>> No answer yet, people are busy, and the number of concerned packages
>>>>>> is low (a dozen or so), should i just rebuild and upload them myself ?
>>>>> The transition freeze was on Nov 5.
>>>>
>>>> This is not very smart - i'm talking about something that will make
>>>> future maintenance and security patches easier, something that is easy
>>>> to do and that i can even do alone.
>>>> Contrast this with an openssl 1.1 upload few days before the
>>>> transition freeze. I don't get it.
>>>
>>> libssl transition was coordinated with the release team well before the
>>> freeze.
>>> Apart from giving up and let things rest as they are (or fall apart and
>>> get kicked out), I believe there is also the option of asking the
>>> release team for permission to do the transition even if late.
>>
>> Oh, i thought transition bugs were read by release team.
>> Please, release team ?
>
> Sorry but this is way too late. Shipping the latest upstream release always
> makes it easier to backport fixes, but at some point we need to stop accepting
> transitions in order to stabilise and prepare for the release. That point was
> two months ago.

That's too bad for debian stable, especially considering the high
level of compatibility
between the two versions, the transition could have been quick and painless.

Jérémy

Re: nodejs 6.9 in unstable, manual transition, schedule

[Jérémy Lal]

2017-01-04 11:56 GMT+01:00 Jonas Smedegaard <jo...@jones.dk>:
> Quoting Jérémy Lal (2017-01-04 10:12:44)
>> 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin <w...@debian.org>:
>>> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote:
>>>> i really think it would be best to have nodejs 6.9 in next debian release.
>>>> That version is currently in experimental and i was about to upload it
>>>> to unstable, but i tried to do things right and prepared the addons
>>>> that need to be rebuilt and binNMUed, then opened a transition bug
>>>> #849505.
>>>> No answer yet, people are busy, and the number of concerned packages
>>>> is low (a dozen or so), should i just rebuild and upload them myself ?
>>> The transition freeze was on Nov 5.
>>
>> This is not very smart - i'm talking about something that will make
>> future maintenance and security patches easier, something that is easy
>> to do and that i can even do alone.
>> Contrast this with an openssl 1.1 upload few days before the
>> transition freeze. I don't get it.
>
> libssl transition was coordinated with the release team well before the
> freeze.
> Apart from giving up and let things rest as they are (or fall apart and
> get kicked out), I believe there is also the option of asking the
> release team for permission to do the transition even if late.

Oh, i thought transition bugs were read by release team.
Please, release team ?

Jérémy

Bug#849505: transition: nodejs

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

nodejs 4.6.1~dfsg-1 provides nodejs-abi-46
nodejs 6.9.2~dfsg-1 provides nodejs-abi-48

I recently uploaded fixes to all Node.js c++ addons
so they use dh_nodejs to depend on the correct nodejs-abi-xx
provided by nodejs-dev used during build.

Transition should have minimal impact on these addons.
Most other pure Node.js modules should be okay - they either
are already compatible with Node.js 6 or have upstream updates
providing that compatibility.

Thanks,
Jérémy

Ben file:

title = "nodejs";
is_affected = .depends ~ "nodejs-abi-46" | .depends ~ "nodejs-abi-48";
is_good = .depends ~ "nodejs-abi-48";
is_bad = .depends ~ "nodejs-abi-46";

Re: libuv minor bumps

[Jérémy Lal]

cc debian-release - maybe they can find it interesting.

2016-04-12 23:36 GMT+02:00 Luca BRUNO :

> On Tuesday, April 12, 2016 10:58:41 PM you wrote:
> > Hi Luca,
> >
> > since libuv is at the core of nodejs, could you inform me just a little
> > before
> > you upload new minor version bumps of that lib ?
> >
> > Right now nodejs 4.2 LTS is supported with libuv 1.8, not libuv 1.9.
> > Any bug coming from that version mismatch won't be supported by
> > upstream long term support team - this is bad.
>
> I'm definitely super sorry about that, I was not taking into account the
> nodejs release channels.
>
> I have to say I'm a bit lost at the moment with nodejs versions, so just to
> recap I have a single question: is 4.2 LTS the nodejs intended to be
> shipped
> with stretch?
>

Yes ! Actually the correct answer is "Node.js 4 LTS" (because minor version
bumps
can happen in the LTS but not addons ABI bumps, so usually nothing to worry
about).
Upstream is really committed to that long term support: we will have
security
fixes for bundled dependencies. So it's a good idea to keep in touch in case
nodejs LTS provides such fixes.

If so, 1.9 has not yet reached testing and we can put an artificial RC to
> block it right now, then revert it (via an epoch or +really version).


> OTOH, if we are not aiming for it as the target version in stretch it
> shouldn't be a problem, right? (This release actually highlighted a
> regression
> in upstream, which is easier to bisect at this point)
>

Well, it's going to be a problem in the worst case of having to upload a
new libuv
version < 1.9.0.
Blocking the transition to testing is enough for me right now - i'm in
favor of waiting
a little before deciding something, because
https://github.com/nodejs/node/pull/4276#issuecomment-167992719
shows Node.js 4 might get libuv 1.9 soon.

Jérémy.

Re: libstdc++ follow-up transitions

[Jérémy Lal]

2015-08-17 12:47 GMT+02:00 Bastien ROUCARIES roucaries.bast...@gmail.com:

 On Mon, Aug 17, 2015 at 12:07 PM, Matthias Klose d...@debian.org wrote:
  Unstable now has GCC 5 as the default for more than two weeks. The
 follow-up
  transitions are in progress, however the list of transitions at [1] is
 not
  exhaustive, because this only covered libraries without dependencies on
  libraries which need a transition.  There is now another test rebuild
 [2] done
  with an augmented dh_makeshlibs printing cxx11 symbols in libraries
 [3].  No new
  bug reports were filed yet.
 
  There seems to be a tendency to avoid transitions, where Debian doesn't
 have any
  reverse dependencies, or where developers analyze the library API's and
 come to
  the conclusion that no transition is necessary.  I'm not yet sure if
 this is the
  safest way forward, given the alternative of semi-automatic renaming of
 the
  packages.
 
  As an example (no pun intended): for libsigc++-2.0 the maintainer
 assessed that
  the one change wouldn't have any impact.  However after a non-change
 rebuild,
  some binaries started crashing (e.g. aptitude).  The problem here is
 that you
  don't see every ABI change from just looking at the symbols files, which
 doesn't
  show subtype changes. One way to find out about these is to look at the
 debug
  information (which is not always available), and compare the old and the
 new
  package. Tools to do this are abi-compliance-checker and libabigail (you
 need
  the one in unstable).

 Please notice that sadly abi-compliance-checker is not anymore
 devellopped and upstream site will be going to rot. I dream that
 jenkins jobs could be run for checking ABI at unstrable step.


Not the software by itself
http://lvc.github.io/abi-compliance-checker/

Jérémy

Bug#782018: unblock: nodejs/0.10.29~dfsg-2

[Jérémy Lal]

2015-04-12 10:47 GMT+02:00 Julien Cristau jcris...@debian.org:
 Control: tags -1 = confirmed

 On Sun, Apr 12, 2015 at 02:18:59 +0200, Jérémy Lal wrote:

 Package: release.debian.org
 Followup-For: Bug #782018
 User: release.debian@packages.debian.org
 Usertags: unblock

 Here the debdiff of the version i intend to upload.

 Alright.  Please let us know when this is in sid.

It is now in sid.

Jérémy.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cajxtcxyoocypvykcpt1t+071yqxre3z1j-+hrwkfnj+onfz...@mail.gmail.com

Bug#782018: unblock: nodejs/0.10.29~dfsg-2

[Jérémy Lal]

Package: release.debian.org
Followup-For: Bug #782018
User: release.debian@packages.debian.org
Usertags: unblock

Here the debdiff of the version i intend to upload.

Jérémy.
diff -Nru nodejs-0.10.29~dfsg/debian/changelog nodejs-0.10.29~dfsg/debian/changelog
--- nodejs-0.10.29~dfsg/debian/changelog	2014-12-28 13:53:34.0 +0100
+++ nodejs-0.10.29~dfsg/debian/changelog	2015-04-12 02:11:22.0 +0200
@@ -1,3 +1,11 @@
+nodejs (0.10.29~dfsg-2) unstable; urgency=medium
+
+  * Update 2015_fix_test_crypto_stream.patch with a less strict
+check for that test - coming from upstream. Also use DEP-3 format.
+Closes: #781710.
+
+ -- Jérémy Lal kapo...@melix.org  Sun, 12 Apr 2015 01:59:43 +0200
+
 nodejs (0.10.29~dfsg-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nodejs-0.10.29~dfsg/debian/patches/2015_fix_test_crypto_stream.patch nodejs-0.10.29~dfsg/debian/patches/2015_fix_test_crypto_stream.patch
--- nodejs-0.10.29~dfsg/debian/patches/2015_fix_test_crypto_stream.patch	2014-12-28 13:53:34.0 +0100
+++ nodejs-0.10.29~dfsg/debian/patches/2015_fix_test_crypto_stream.patch	2015-04-12 02:10:44.0 +0200
@@ -1,27 +1,16 @@
-From 707cc25011d142fe4ade14ce2aa083a96ef15bcb Mon Sep 17 00:00:00 2001
-From: Fedor Indutny fe...@indutny.com
-Date: Wed, 15 Oct 2014 20:50:15 +0400
-Subject: [PATCH] test: fix test-crypto-stream
+Description: loosen error check in test-crypto-stream
+Origin: https://github.com/joyent/node/commit/9e387fb6
+Last-Update: 2015-04-12
 
-Because of constant-timeness change made in openssl-1.0.1j the error is
-no longer returned from EVP_DecryptFinal_ex. Now it just return 0, and
-thus the error message does not contain proper error code. Adapt to this
-change, there is not much that we could do about it.

- test/simple/test-crypto-stream.js | 3 +--
- 1 file changed, 1 insertion(+), 2 deletions(-)
-
-diff --git a/test/simple/test-crypto-stream.js b/test/simple/test-crypto-stream.js
-index 72c9776..402761e 100644
 --- a/test/simple/test-crypto-stream.js
 +++ b/test/simple/test-crypto-stream.js
-@@ -70,8 +70,7 @@ var key = new Buffer('48fb56eb10ffeb13fc0ef551bbca3b1b', 'hex'),
+@@ -70,8 +70,7 @@
  
  cipher.pipe(decipher)
.on('error', common.mustCall(function end(err) {
 -// TypeError: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
 -assert(/:06065064:/.test(err));
-+assert(/::/.test(err));
++assert(/bad decrypt/.test(err));
}));
  
  cipher.end('Papaya!');  // Should not cause an unhandled exception.

Bug#782018: unblock: nodejs/0.10.29~dfsg-2

[Jérémy Lal]

Please wait for another debdiff proposal - upstream wrote a better fix
for the test,
avoiding the check for hex error code.

Jérémy.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cajxtcxzq9yc0pdih7blwuepmlhfocuaci0mnzafbohi9y2c...@mail.gmail.com

Bug#782018: unblock: nodejs/0.10.29~dfsg-2

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nodejs

it simply reverts a fix for a test that was broken by a previous
openssl version. Now with openssl 1.0.1k-3 the upstream test does
not fail and the patch is no longer needed.

i'll upload the package as soon as i have your consentment.

unblock nodejs/0.10.29~dfsg-2

Jérémy
diff -Nru nodejs-0.10.29~dfsg/debian/changelog nodejs-0.10.29~dfsg/debian/changelog
--- nodejs-0.10.29~dfsg/debian/changelog	2014-12-28 13:53:34.0 +0100
+++ nodejs-0.10.29~dfsg/debian/changelog	2015-04-06 16:47:44.0 +0200
@@ -1,3 +1,11 @@
+nodejs (0.10.29~dfsg-2) unstable; urgency=medium
+
+  * Unapply 2015_fix_test_crypto_stream.patch, no longer needed
+with openssl found in current testing.
+Closes: #781710.
+
+ -- Jérémy Lal kapo...@melix.org  Mon, 06 Apr 2015 16:47:42 +0200
+
 nodejs (0.10.29~dfsg-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nodejs-0.10.29~dfsg/debian/patches/series nodejs-0.10.29~dfsg/debian/patches/series
--- nodejs-0.10.29~dfsg/debian/patches/series	2014-12-28 13:53:34.0 +0100
+++ nodejs-0.10.29~dfsg/debian/patches/series	2015-04-06 16:40:53.0 +0200
@@ -13,4 +13,3 @@
 2014_donotinclude_root_certs.patch
 1006_relax_timeouts_in_tests.patch
 1007_revert_invalid_utf8_fix.patch
-2015_fix_test_crypto_stream.patch

Bug#779980: unblock: gpaste/3.14-2

[Jérémy Lal]

Control: tags -1 - moreinfo

thanks !

Le mardi 10 mars 2015 à 19:39 +0100, Emilio Pozuelo Monfort a écrit :
 Control: tags -1 confirmed moreinfo
 
 On 07/03/15 15:19, Jérémy Lal wrote:
  Package: release.debian.org
  Followup-For: Bug #779980
  User: release.debian@packages.debian.org
  Usertags: unblock
 
  Here's the debdiff before i upload.
 
 Please go ahead and remove the moreinfo tag when your upload is accepted.
 
 Emilio


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1426026190.9550.1.ca...@melix.org

Bug#779980: unblock: gpaste/3.14-2

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gpaste

Current version of gpaste gnome-shell extension often crashes
and disappears from gnome-shell's menu.
The patch added in version 3.14-2 is made by upstream author
to fix this issue, please see dep-3 fields of the quilt patch
below for links to upstream issue/commit.

unblock gpaste/3.14-2

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (650, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150307141013.7734.53615.reportbug@imac.localdomain

Bug#779980: unblock: gpaste/3.14-2

[Jérémy Lal]

Package: release.debian.org
Followup-For: Bug #779980
User: release.debian@packages.debian.org
Usertags: unblock

Here's the debdiff before i upload.
diff -Nru gpaste-3.14/debian/changelog gpaste-3.14/debian/changelog
--- gpaste-3.14/debian/changelog	2014-10-11 12:18:59.0 +0200
+++ gpaste-3.14/debian/changelog	2015-03-07 15:05:15.0 +0100
@@ -1,3 +1,9 @@
+gpaste (3.14-2) unstable; urgency=medium
+
+  * Upstream patch fixing gnome-shell extension crashes.
+
+ -- Jérémy Lal kapo...@melix.org  Sat, 07 Mar 2015 14:44:36 +0100
+
 gpaste (3.14-1) unstable; urgency=medium
 
   * Imported Upstream version 3.14 (Closes: #764803).
diff -Nru gpaste-3.14/debian/patches/series gpaste-3.14/debian/patches/series
--- gpaste-3.14/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ gpaste-3.14/debian/patches/series	2015-03-07 15:03:28.0 +0100
@@ -0,0 +1 @@
+upstream-fix-crashes-0e899af5.patch
diff -Nru gpaste-3.14/debian/patches/upstream-fix-crashes-0e899af5.patch gpaste-3.14/debian/patches/upstream-fix-crashes-0e899af5.patch
--- gpaste-3.14/debian/patches/upstream-fix-crashes-0e899af5.patch	1970-01-01 01:00:00.0 +0100
+++ gpaste-3.14/debian/patches/upstream-fix-crashes-0e899af5.patch	2015-03-07 15:03:28.0 +0100
@@ -0,0 +1,83 @@
+From: Marc-Antoine Perennou marc-anto...@perennou.com
+Last-Update: 2015-03-07
+Description: gnome-shell: fix weird gjs gsignal bug
+Origin: https://github.com/Keruspe/GPaste/commit/0e899af538631026c6cd739986ea854f79b91c95
+Bug: https://github.com/Keruspe/GPaste/issues/106
+Reviewed-By: Jérémy Lal kapo...@melix.org
+
+--- a/src/gnome-shell/indicator.js
 b/src/gnome-shell/indicator.js
+@@ -86,8 +86,9 @@
+ this._dummyHistoryItem.update();
+ this._prefsItem = new PrefsItem.GPastePrefsItem(this.menu);
+ this._emptyHistoryItem = new EmptyHistoryItem.GPasteEmptyHistoryItem(this._client);
++this._switch = new StateSwitch.GPasteStateSwitch(this._client);
+ 
+-this._addToHeader(new StateSwitch.GPasteStateSwitch(this._client));
++this._addToHeader(this._switch);
+ this._addToHeader(this._searchItem);
+ this._actions.actor.add(this._prefsItem, { expand: true, x_fill: false });
+ this._actions.actor.add(this._emptyHistoryItem, { expand: true, x_fill: false });
+@@ -97,6 +98,7 @@
+ this._refresh(0);
+ 
+ this._clientShowId = this._client.connect('show-history', Lang.bind(this, this._popup));
++this._clientTrackingId = this._client.connect('tracking', Lang.bind(this, this._toggle));
+ 
+ this._onStateChanged (true);
+ 
+@@ -239,6 +241,10 @@
+ this._selectSearch(true);
+ },
+ 
++_toggle: function(c, state) {
++this._switch.toggle(state);
++},
++
+ _selectSearch: function(active) {
+ if (this._history.length  0) {
+ this._searchItem.setActive(active);
+@@ -281,6 +287,7 @@
+ _onDestroy: function() {
+ this._client.disconnect(this._clientUpdateId);
+ this._client.disconnect(this._clientShowId);
++this._client.disconnect(this._clientTrackingId);
+ this._settings.disconnect(this._settingsMaxSizeChangedId);
+ this._settings.disconnect(this._settingsSizeChangedId);
+ }
+--- a/src/gnome-shell/stateSwitch.js
 b/src/gnome-shell/stateSwitch.js
+@@ -35,27 +35,18 @@
+ this._client = client;
+ this._fromDaemon = false;
+ 
+-this._clientTrackingId = client.connect('tracking', Lang.bind(this, function(c, state) {
+-this._toggle(state);
+-}));
+-this._toggle(client.is_active());
+-
+-this.connect('toggled', Lang.bind(this, function() {
+-if (!this._fromDaemon) {
+-client.track(this.state, null);
+-}
+-}));
+-
+-this.actor.connect('destroy', Lang.bind(this, this._onDestroy));
++this.connect('toggled', Lang.bind(this, this._onToggle));
+ },
+ 
+-_toggle: function(state) {
++toggle: function(state) {
+ this._fromDaemon = true;
+ this.setToggleState(state);
+ this._fromDaemon = false;
+ },
+ 
+-_onDestroy: function() {
+-this._client.disconnect(this._clientTrackingId);
++_onToggle: function() {
++if (!this._fromDaemon) {
++this._client.track(this.state, null);
++}
+ }
+ });

Bug#760972: RM: node-node-markdown/0.1.0-1 -- RoM, deprecated upstream

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Please remove node-node-markdown, as it is deprecated in favor of
marked source package.

Thank you.
Jérémy.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140909153138.22930.11849.reportbug@imac.localdomain

Bug#760973: RM: showdown/0.0.1-1 -- RoM, abandoned upstream

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Please remove showdown package, as it is abandoned upstream,
and deprecated in favor of marked package anywhere a
markdown parser is needed in browser/nodejs.

Regards,
Jérémy.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140909153358.23302.88470.reportbug@imac.localdomain

Bug#760973: RM: showdown/0.0.1-1 -- RoM, abandoned upstream

[Jérémy Lal]

Le mardi 09 septembre 2014 à 17:02 +0100, Adam D. Barratt a écrit :
 Control: tags -1 + moreinfo
 
 On 2014-09-09 16:33, Jérémy Lal wrote:
  Please remove showdown package, as it is abandoned upstream,
  and deprecated in favor of marked package anywhere a
  markdown parser is needed in browser/nodejs.
 
 As with your other request, should this be removed from unstable rather 
 than just testing?

Indeed, the request was meant to be removed from testing/unstable.

Should i close this and do requests to the right pseudo-package ?
Sometimes the mail interface just kills me.

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1410279441.13901.9.ca...@melix.org

Please give back nodejs on mipsel

[Jérémy Lal]

Hello,

nodejs builds successfully except on mipsel, because some tests
can fail when the buildd server is busy. Since it's the first time
i see those specific tests fail, i suppose eberlin was really busy.

  gb nodejs_0.10.26~dfsg1-1 . mipsel

Thanks.

Jérémy.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1393832982.3004.4.camel@imac.chaumes

Re: Please give back mapnik on mipsel s390

[Jérémy Lal]

On 11/12/2013 22:26, Julien Cristau wrote:
 On Fri, Sep 27, 2013 at 11:49:34 +0200, Jérémy Lal wrote:
 
 Hello,

 mapnik built successfully except on those two arches, for
 no clear reason (out of memory on s390, hanged on mipsel).
 I'd like to see if it's going to fail again before trying
 to debug.

   gb mapnik_2.2.0+ds1-2 . mipsel s390

 It's now failed consistently on mipsel for the last few versions:
 https://buildd.debian.org/status/logs.php?pkg=mapnikarch=mipsel
 Probably from memory exhaustion each time.

Thanks,

i'm trying to get help from upstream.

Jérémy.




signature.asc
Description: OpenPGP digital signature

Please binNMU osmjs against libv8-3.14

[Jérémy Lal]

Hello,

The source package libv8 is going to be removed, in favor of libv8-3.14.
Before that, please:

nmu osmjs_0.0~20111213-g7f3500a-3+b2 . ALL . -m 'Rebuild against libv8-3.14'

Thanks.



signature.asc
Description: OpenPGP digital signature

Bug#711551: pu: package redmine/1.4.4+dfsg1-2

[Jérémy Lal]

On 30/09/2013 00:42, Cyril Brulebois wrote:
 Control: tag -1 -moreinfo +confirmed
 
 Jérémy Lal kapo...@melix.org (2013-06-10):
 --- redmine-1.4.4+dfsg1/debian/changelog 2013-01-19 15:54:09.0 
 +0100
 +++ redmine-1.4.4+dfsg1/debian/changelog 2013-06-10 01:01:48.0 
 +0200
 @@ -1,3 +1,14 @@
 +redmine (1.4.4+dfsg1-2+deb7u1) proposed-updates; urgency=low
 
 Even though that would work, I'd be happy to see wheezy in there,
 which can be useful after a while to figure out which suite was targeted
 at that point (without having to look at the version number, and its
 meaning).

Do you mean it'd be better to use wheezy-proposed-updates as distribution ?

 
 +  [ Ondřej Surý ]
 +  * Pull upstream fixes for Ruby 1.9 as default interpreter:
 ++ Use DateTime.parse as alternative to ParseDate.parsedate,
 +  fixing time series and schedule SVG graphs. (Closes: #700754)
 ++ Use ::Time from global namespace, fixing REST Issue API.
 +  (Closes: #79)
 
 Assuming the latter change doesn't break the Ruby 1.8 use case (and
 doesn't need a dance similar to the respond_to one in the former),
 please upload (with or without an edit for the above mentioned point).

I'm going to recheck that because i only remember doing it on irb,
not on redmine code.

Thanks for looking into this.

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52493e3f.4090...@melix.org

Bug#711551: pu: package redmine/1.4.4+dfsg1-2

[Jérémy Lal]

On 30/09/2013 11:09, Cyril Brulebois wrote:
 Jérémy Lal kapo...@melix.org (2013-09-30):
 Jérémy Lal kapo...@melix.org (2013-06-10):
 --- redmine-1.4.4+dfsg1/debian/changelog   2013-01-19 15:54:09.0 
 +0100
 +++ redmine-1.4.4+dfsg1/debian/changelog   2013-06-10 01:01:48.0 
 +0200
 @@ -1,3 +1,14 @@
 +redmine (1.4.4+dfsg1-2+deb7u1) proposed-updates; urgency=low

 Even though that would work, I'd be happy to see wheezy in there,
 which can be useful after a while to figure out which suite was targeted
 at that point (without having to look at the version number, and its
 meaning).

 Do you mean it'd be better to use wheezy-proposed-updates as distribution ?
 
 That or just wheezy :-)
 
 Assuming the latter change doesn't break the Ruby 1.8 use case (and
 doesn't need a dance similar to the respond_to one in the former),
 please upload (with or without an edit for the above mentioned point).

 I'm going to recheck that because i only remember doing it on irb,
 not on redmine code.
 
 Thanks for that.

There was a small error.
Now both bugs i reproduced today are fixed.

Uploading in a moment.

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5249fabc.7090...@melix.org

Please give back mapnik on mipsel s390

[Jérémy Lal]

Hello,

mapnik built successfully except on those two arches, for
no clear reason (out of memory on s390, hanged on mipsel).
I'd like to see if it's going to fail again before trying
to debug.

  gb mapnik_2.2.0+ds1-2 . mipsel s390

Thanks.

Jérémy.



signature.asc
Description: OpenPGP digital signature

Please binNMU reverse build dependencies of node-gyp on kfreebsd-*

[Jérémy Lal]

Hello,

there was a bug in node-gyp 0.10.10-1 that prevented packages
build-depending on it to build on kfreebsd.
node-gyp 0.10.10-2 fixes the issue and the following packages
need a binNMU :

nmu node-zipfile_0.4.0+ds1 . kfreebsd-i386 kfreebsd-amd64 -m 'Rebuild against 
node-gyp on kfreebsd'
node-sqlite3_2.1.15+ds2 . kfreebsd-i386 kfreebsd-amd64 -m 'Rebuild against 
node-gyp on kfreebsd'
node-srs_0.3.2+ds1 . kfreebsd-i386 kfreebsd-amd64 -m 'Rebuild against node-gyp 
on kfreebsd'
node-mapnik_1.2.0 . kfreebsd-i386 kfreebsd-amd64 -m 'Rebuild against node-gyp 
on kfreebsd'

(I am idling on #debian-js just in case)

Thank you for your help,
Jérémy.



signature.asc
Description: OpenPGP digital signature

Bug#674587: transition: mapnik 2.0.x

[Jérémy Lal]

Hi,

i am working on mapnik 2.2, and transitioning
libmapnik2-dev to libmapnik-dev

(side note, python-mapnik2 becomes a transitional
package in favor of python-mapnik).

Reverse build-dependencies seems to be limited to
monav-preprocessor 0.3-6+b1
node-mapnik 0.6.7-3

I am working on updating node-mapnik to 1.1 branch, and
will try to provide patches for monav-preprocessor.

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/521cb419.7050...@melix.org

Bug#711551: pu: package redmine/1.4.4+dfsg1-2

[Jérémy Lal]

On 07/06/2013 22:48, Adam D. Barratt wrote:
 Control: tags -1 + moreinfo wheezy
 
 On Fri, 2013-06-07 at 22:20 +0200, Jérémy Lal wrote:
 1.4.4+dfsg1-2+deb7u1 backports upstream fixes.
 See attached debdiff (containing only two quilt patches).
 
 Am I reading the log for #700754 correctly, in that it fixes things for
 Ruby 1.9 but also breaks the use of 1.8? (Which is technically a valid
 use-case according to the ruby | ruby-interpreter dependency.)

Here is a fixed patch.

Jérémy.


diff -Nru redmine-1.4.4+dfsg1/debian/changelog 
redmine-1.4.4+dfsg1/debian/changelog
--- redmine-1.4.4+dfsg1/debian/changelog2013-01-19 15:54:09.0 
+0100
+++ redmine-1.4.4+dfsg1/debian/changelog2013-06-10 01:01:48.0 
+0200
@@ -1,3 +1,14 @@
+redmine (1.4.4+dfsg1-2+deb7u1) proposed-updates; urgency=low
+
+  [ Ondřej Surý ]
+  * Pull upstream fixes for Ruby 1.9 as default interpreter:
++ Use DateTime.parse as alternative to ParseDate.parsedate,
+  fixing time series and schedule SVG graphs. (Closes: #700754)
++ Use ::Time from global namespace, fixing REST Issue API.
+  (Closes: #79)
+
+ -- Jérémy Lal kapo...@melix.org  Fri, 07 Jun 2013 21:09:13 +0200
+
 redmine (1.4.4+dfsg1-2) unstable; urgency=low
 
   * Manage and set dbuser default value like dbname. (Closes: #695774)
diff -Nru redmine-1.4.4+dfsg1/debian/patches/1001_Parsedate.parsedate.patch 
redmine-1.4.4+dfsg1/debian/patches/1001_Parsedate.parsedate.patch
--- redmine-1.4.4+dfsg1/debian/patches/1001_Parsedate.parsedate.patch   
1970-01-01 01:00:00.0 +0100
+++ redmine-1.4.4+dfsg1/debian/patches/1001_Parsedate.parsedate.patch   
2013-06-10 00:54:25.0 +0200
@@ -0,0 +1,40 @@
+Description: Use DateTime.parse for ruby1.9, ParseDate.parsedate for ruby1.8 
(Closes: #700754)
+Origin: upstream, 
http://www.redmine.org/projects/redmine/repository/revisions/10439
+Origin: upstream, 
http://www.redmine.org/projects/redmine/repository/revisions/11091
+Last-Update: 2013-06-10
+--- a/lib/SVG/Graph/Schedule.rb
 b/lib/SVG/Graph/Schedule.rb
+@@ -159,8 +159,13 @@
+   if im3 == 0
+ y  data[:data][i]
+   else
+-arr = ParseDate.parsedate( data[:data][i] )
+-t = Time.local( *arr[0,6].compact )
++t = data[:data][i]
++if DateTime.respond_to?(:parse)
++  t = DateTime.parse( t ).to_time
++else
++  arr = ParseDate.parsedate( t )
++  t = Time.local( *arr[0,6].compact )
++end
+ (im3 == 1 ? x_start : x_end)  t.to_i
+   end
+ }
+--- a/lib/SVG/Graph/TimeSeries.rb
 b/lib/SVG/Graph/TimeSeries.rb
+@@ -157,8 +157,13 @@
+ y = []
+ data[:data].each_index {|i|
+   if i%2 == 0
+-arr = ParseDate.parsedate( data[:data][i] )
+-t = Time.local( *arr[0,6].compact )
++t = data[:data][i]
++if DateTime.respond_to?(:parse)
++  t = DateTime.parse( t ).to_time
++else
++  arr = ParseDate.parsedate( t )
++  t = Time.local( *arr[0,6].compact )
++end
+ x  t.to_i
+   else
+ y  data[:data][i]
diff -Nru redmine-1.4.4+dfsg1/debian/patches/1002_REST_API_ruby1.9.3.patch 
redmine-1.4.4+dfsg1/debian/patches/1002_REST_API_ruby1.9.3.patch
--- redmine-1.4.4+dfsg1/debian/patches/1002_REST_API_ruby1.9.3.patch
1970-01-01 01:00:00.0 +0100
+++ redmine-1.4.4+dfsg1/debian/patches/1002_REST_API_ruby1.9.3.patch
2013-05-11 16:27:48.0 +0200
@@ -0,0 +1,14 @@
+Description: Fix broken REST API (Closes: #79)
+Origin: upstream, 
http://www.redmine.org/projects/redmine/repository/revisions/10299
+Last-Update: 2013-02-26
+--- a/lib/redmine/views/builders/xml.rb
 b/lib/redmine/views/builders/xml.rb
+@@ -29,7 +29,7 @@ module Redmine
+ end
+ 
+ def method_missing(sym, *args, block)
+-  if args.size == 1  args.first.is_a?(Time)
++  if args.size == 1  args.first.is_a?(::Time)
+ __send__ sym, args.first.xmlschema, block
+   else
+ super
diff -Nru redmine-1.4.4+dfsg1/debian/patches/series 
redmine-1.4.4+dfsg1/debian/patches/series
--- redmine-1.4.4+dfsg1/debian/patches/series   2013-01-19 11:33:48.0 
+0100
+++ redmine-1.4.4+dfsg1/debian/patches/series   2013-05-11 16:27:48.0 
+0200
@@ -5,3 +5,5 @@
 2008_force_table_encoding_mysql.patch
 2009_FHS_thin_config.patch
 2017_Gemfile_debian.patch
+1001_Parsedate.parsedate.patch
+1002_REST_API_ruby1.9.3.patch

Bug#711551: pu: package redmine/1.4.4+dfsg1-2

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu

Hi,
1.4.4+dfsg1-2+deb7u1 backports upstream fixes.
See attached debdiff (containing only two quilt patches).

Thank you.
Jérémy.
diff -Nru redmine-1.4.4+dfsg1/debian/changelog redmine-1.4.4+dfsg1/debian/changelog
--- redmine-1.4.4+dfsg1/debian/changelog	2013-01-19 15:54:09.0 +0100
+++ redmine-1.4.4+dfsg1/debian/changelog	2013-06-07 21:09:16.0 +0200
@@ -1,3 +1,12 @@
+redmine (1.4.4+dfsg1-2+deb7u1) proposed-updates; urgency=low
+
+  [ Ondřej Surý ]
+  * Pull upstream fixes for Ruby 1.9 as default interpreter:
++ Replace missing ParseDate with DateTime (Closes: #700754)
++ Fix broken REST API (Closes: #79)
+
+ -- Jérémy Lal kapo...@melix.org  Fri, 07 Jun 2013 21:09:13 +0200
+
 redmine (1.4.4+dfsg1-2) unstable; urgency=low
 
   * Manage and set dbuser default value like dbname. (Closes: #695774)
diff -Nru redmine-1.4.4+dfsg1/debian/patches/1001_Parsedate.parsedate.patch redmine-1.4.4+dfsg1/debian/patches/1001_Parsedate.parsedate.patch
--- redmine-1.4.4+dfsg1/debian/patches/1001_Parsedate.parsedate.patch	1970-01-01 01:00:00.0 +0100
+++ redmine-1.4.4+dfsg1/debian/patches/1001_Parsedate.parsedate.patch	2013-05-11 16:27:48.0 +0200
@@ -0,0 +1,28 @@
+Description: Replace missing ParseDate with DateTime (Closes: #700754)
+Origin: upstream, http://www.redmine.org/projects/redmine/repository/revisions/10439
+Origin: upstream, http://www.redmine.org/projects/redmine/repository/revisions/11091
+Last-Update: 2013-02-26
+--- a/lib/SVG/Graph/Schedule.rb
 b/lib/SVG/Graph/Schedule.rb
+@@ -159,8 +159,7 @@ module SVG
+   if im3 == 0
+ y  data[:data][i]
+   else
+-arr = ParseDate.parsedate( data[:data][i] )
+-t = Time.local( *arr[0,6].compact )
++t = DateTime.parse( data[:data][i] ).to_time
+ (im3 == 1 ? x_start : x_end)  t.to_i
+   end
+ }
+--- a/lib/SVG/Graph/TimeSeries.rb
 b/lib/SVG/Graph/TimeSeries.rb
+@@ -157,8 +157,7 @@ module SVG
+ y = []
+ data[:data].each_index {|i|
+   if i%2 == 0
+-arr = ParseDate.parsedate( data[:data][i] )
+-t = Time.local( *arr[0,6].compact )
++t = DateTime.parse( data[:data][i] ).to_time
+ x  t.to_i
+   else
+ y  data[:data][i]
diff -Nru redmine-1.4.4+dfsg1/debian/patches/1002_REST_API_ruby1.9.3.patch redmine-1.4.4+dfsg1/debian/patches/1002_REST_API_ruby1.9.3.patch
--- redmine-1.4.4+dfsg1/debian/patches/1002_REST_API_ruby1.9.3.patch	1970-01-01 01:00:00.0 +0100
+++ redmine-1.4.4+dfsg1/debian/patches/1002_REST_API_ruby1.9.3.patch	2013-05-11 16:27:48.0 +0200
@@ -0,0 +1,14 @@
+Description: Fix broken REST API (Closes: #79)
+Origin: upstream, http://www.redmine.org/projects/redmine/repository/revisions/10299
+Last-Update: 2013-02-26
+--- a/lib/redmine/views/builders/xml.rb
 b/lib/redmine/views/builders/xml.rb
+@@ -29,7 +29,7 @@ module Redmine
+ end
+ 
+ def method_missing(sym, *args, block)
+-  if args.size == 1  args.first.is_a?(Time)
++  if args.size == 1  args.first.is_a?(::Time)
+ __send__ sym, args.first.xmlschema, block
+   else
+ super
diff -Nru redmine-1.4.4+dfsg1/debian/patches/series redmine-1.4.4+dfsg1/debian/patches/series
--- redmine-1.4.4+dfsg1/debian/patches/series	2013-01-19 11:33:48.0 +0100
+++ redmine-1.4.4+dfsg1/debian/patches/series	2013-05-11 16:27:48.0 +0200
@@ -5,3 +5,5 @@
 2008_force_table_encoding_mysql.patch
 2009_FHS_thin_config.patch
 2017_Gemfile_debian.patch
+1001_Parsedate.parsedate.patch
+1002_REST_API_ruby1.9.3.patch

Bug#711551: pu: package redmine/1.4.4+dfsg1-2

[Jérémy Lal]

On 07/06/2013 22:48, Adam D. Barratt wrote:
 Control: tags -1 + moreinfo wheezy
 
 On Fri, 2013-06-07 at 22:20 +0200, Jérémy Lal wrote:
 1.4.4+dfsg1-2+deb7u1 backports upstream fixes.
 See attached debdiff (containing only two quilt patches).
 
 Am I reading the log for #700754 correctly, in that it fixes things for
 Ruby 1.9 but also breaks the use of 1.8? (Which is technically a valid
 use-case according to the ruby | ruby-interpreter dependency.)

Thank you for noticing that flaw - i'll resubmit
a tested against ruby1.8 diff later.

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b2486c.7080...@melix.org

Bug#677574: transition: libv8

[Jérémy Lal]

May i ask what's best to do now ?
Shall i close this transition bug and reopen a new one
to latest libv8 version ?

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518f61ac.6030...@melix.org

Bug#677574: transition: libv8

[Jérémy Lal]

I reopened the bug because i closed it too quickly.
It was on the assumption from a private message that
it wouldn't be accepted after all.

This transition is painless. Please initiate it.

Jérémy.




--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4feea8cb.8090...@melix.org

Bug#677574: [Pkg-javascript-devel] Bug#677574: transition: libv8

[Jérémy Lal]

On 17/06/2012 12:52, Jonas Smedegaard wrote:
 On 12-06-17 at 12:06pm, Jérémy Lal wrote:
 according to [1] we have
 After Sunday the 20th of May, any new transitions are likely not to be
 processed until after the release.

 So that transition is way too late, and the result is that libv8 3.10.8
 should be uploaded to experimental instead.

 Closing this bug.
 
 Whoa - would you mind reconsidering that?
 
 unlikely != impossible
 
 ...and this transition seems a pretty lightweight one to me: three 
 packages (with no other packages depending on them) needing a simple 
 rebuild, and one package not even in testing at all at the moment and 
 also cauising no other ripples as I can see, which needs minor work.
 
 Why give up without even trying?

Cons:
* one month too late
* chromium isn't even using libv8 nor libv8-i18n
* nodejs won't be in wheezy
* current libv8 seems good enough for drizzle and osmium

Pros:
* libv8 3.10.8 won't require transition for each patch-level fix,
  and that is something really good from a security-team P.O.V.
* i spent a hell of a lot of time to make sure it runs on mipsel
* and as a bonus it runs on kfreebsd-*

More cons that pros, still if someone (a DD, of course) want
to make that transition *today* i'll be happy to do my part of the
job (i.e. upload nodejs compatible with libv8-3.10.8).

Jérémy.




signature.asc
Description: OpenPGP digital signature

Bug#677574: transition: libv8

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,
i'd like to update libv8 3.8.9.20 to 3.10.8.

* packages needing a simple rebuild (i checked them) :
  + libv8-i18n
  + osmium
  + drizzle

* packages needing more work :
  nodejs (i'm maintaining it and it's ready to be uploaded)

Please note that SONAME is libv8.so.3.10.8 instead of libv8.so.3.10.8.15,
allowing libv8 maintainers to do patch-level updates without the need to
setup a transition. This will hopefully improve the current situation.
I started some discussion about that here :
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2012-June/003683.html

Ben file:

title = libv8;
is_affected = .depends ~ libv8-3.8.9.20 | .depends ~ libv8-3.10.8;
is_good = .depends ~ libv8-3.10.8;
is_bad = .depends ~ libv8-3.8.9.20;


Regards,
Jérémy.




--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120614231010.9525.49513.reportbug@imac.chaumes

Re: [Pkg-javascript-devel] Please schedule binNMU for rdepends of libv8

[Jérémy Lal]

On 11/05/2012 19:10, Julien Cristau wrote:
 On Sat, May  5, 2012 at 20:25:14 +0200, Tobias Frost wrote:
 
 Dear release team,

 to allow removal of old version of libv8 and allow transition of it to
 testing, please schedule a binnmu for its rdepends:

 drizzle
 osmium

 Done.

Thank you.

 What about chromium-browser's FTBFS on arm, and libv8-i18n?

I'll update libv8-i18n.
What's the relation with chromium FTBFS on arm (i guess you mean armel) ?

 Somebody should talk to the v8 folks about ABI stability sometime.

I do... no success yet [1]

I would very much like to use libv8-x.y instead of libv8-x.y.z.
Some tool like [2] seems to indicate that for example, there is no
ABI breakage risk between libv8-3.9.24.1 and libv8-3.9.24.21, as
upstream explains it in [1] too.
But, as was discussed on debian-devel [3], it's hard to certify
without upstream supporting this.
Also it takes an experimented c++ programmer to support that.
I'm not.

Jérémy.



[1]
https://groups.google.com/d/topic/v8-users/VJRmaQV-M3E/discussion
[2]
http://www.upstream-tracker.org/versions/v8.html
[3]
http://lists.debian.org/debian-devel/2012/01/msg00671.html


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fad5567.5030...@melix.org

Bug#611663: RM: nodejs/testing -- ROM; NPOASR; RC-buggy; outdated

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Please remove nodejs-0.2.0-1 from testing :
* outdated software
* binary renamed due to policy reasons
These will only confuse users, who will search to install
a backport or testing version.

Please read this rc-bug, where i've been more verbose :
http://bugs.debian.org/611657

Reversed dependencies :
coffeescript 0.7.0-1
Maintainer : Geza Kovacs gkov...@mit.edu
quoting him :
On 31/01/2011 17:13, Geza Kovacs wrote:
 An update of nodejs in squeeze would be most welcome. Alternatively,
 removal of nodejs and dependent packages from squeeze wouldn't be as
 nice, but is also fine (current version of coffescript in squeeze is
 rather outdated and unlikely to be used much).

Best regards,
Jérémy Lal



signature.asc
Description: OpenPGP digital signature

Re: Bug#608397: redmine security issues fixed in 1.0.5

[Jérémy Lal]

Hi,

On 04/01/2011 21:23, Julien Cristau wrote:
 user release.debian@packages.debian.org
 usertag 608397 squeeze-can-defer
 tag 608397 squeeze-ignore
 kthxbye
 
 On Sat, Jan  1, 2011 at 19:38:35 +0100, Julien Cristau wrote:
 
 On Fri, Dec 31, 2010 at 23:53:11 +0100, Jérémy Lal wrote:

 Hi,
 i'd need some tip about how to manage the situation with redmine package :
 version 1.0.1-1 is in testing, version 1.0.5-1 in unstable (my bad, i should
 have uploaded it to experimental).
 I would like to see either redmine 1.0.5-1 go to testing, or backport the
 security issues i'm aware of to a 1.0.1-2 version -- i know this is the
 solution when deep freeze is in effect.
 The question being : where should i upload 1.0.1-2 ? t-p-u ?

 Or testing-security.  In any case, please prepare the package and come
 back to us and the security team when that's ready and tested, and we'll
 figure out where the upload should go.
 
 Tagging as -can-defer as this can be fixed post-release if not ready
 soon enough.
 
 Cheers,
 Julien

I sent a debdiff for review to t...@s.d.o

Cheers,
Jérémy.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d244754.6090...@edagames.com

redmine security issues fixed in 1.0.5

[Jérémy Lal]

Hi,
i'd need some tip about how to manage the situation with redmine package :
version 1.0.1-1 is in testing, version 1.0.5-1 in unstable (my bad, i should
have uploaded it to experimental).
I would like to see either redmine 1.0.5-1 go to testing, or backport the
security issues i'm aware of to a 1.0.1-2 version -- i know this is the
solution when deep freeze is in effect.
The question being : where should i upload 1.0.1-2 ? t-p-u ?

Kind regards,
Jérémy Lal


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d1e5ed7.9070...@edagames.com

nodejs 0.2.0 supported upstream as a stable version

[Jérémy Lal]

Hi,
the nodejs package has seen a lot of evolutions through the
0.1.x releases. As promised by upstream author Ryan Dahl,
version 0.2 will be supported on its own branch, without
API changes.
Unfortunately it's been released after squeeze freeze,
however i (with advice from my mentor Dave Beckett) think
it would be much better if nodejs 0.2.0-1 was allowed to go
into squeeze.
I don't attach debdiff between 0.1.102-1 and 0.2.0-1, since
the changes are only upstream changes.

Kind regards,
Jérémy Lal


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c70445d.9020...@edagames.com

libv8 2.2.24-5 fixes important bugs

[Jérémy Lal]

Hi,
i uploaded libv8 2.2.24-5 to unstable.
That version fixes two bugs (one of which is important,
if not critical), updates Standards-Version to 3.9.1,
and nothing else changed.
Please see attached debdiff for further information.

About bug #591148 (fix priority to optional) :
i submitted bug #592844 to ftp.debian.org, which is not yet
fixed.

It would be great version 2.2.24-5 made it to squeeze.

With kind regards,
Jérémy Lal


diff -Nru libv8-2.2.24/debian/changelog libv8-2.2.24/debian/changelog
--- libv8-2.2.24/debian/changelog	2010-07-25 09:49:55.0 +0200
+++ libv8-2.2.24/debian/changelog	2010-08-12 23:42:17.0 +0200
@@ -1,3 +1,14 @@
+libv8 (2.2.24-5) unstable; urgency=low
+
+  * Standards-Version 3.9.1. Nothing had to be changed to comply.
+  * Fix chromium-browser: priority optional, depends on libv8 which
+has priority extra. (Closes: #591148)
+  * Compile with GCC_VERSION=44.
+With that option, v8 pass all tests, and setting a breakpoint
+in chromium inspector does not crash. (Closes: #584562)
+
+ -- Jérémy Lal kapo...@melix.org  Thu, 12 Aug 2010 23:39:43 +0200
+
 libv8 (2.2.24-4) unstable; urgency=low
 
   * Replace arch: mips with mipsel (on the three packages) 
diff -Nru libv8-2.2.24/debian/control libv8-2.2.24/debian/control
--- libv8-2.2.24/debian/control	2010-07-25 09:47:55.0 +0200
+++ libv8-2.2.24/debian/control	2010-08-04 22:26:31.0 +0200
@@ -1,9 +1,9 @@
 Source: libv8
-Priority: extra
+Priority: optional
 Maintainer: Antonio Radici anto...@dyne.org
 Uploaders: Jérémy Lal kapo...@melix.org
 Build-Depends: debhelper (= 7), pkg-config, scons, cdbs (= 0.4.73)
-Standards-Version: 3.9.0
+Standards-Version: 3.9.1
 Section: libs
 Homepage: http://code.google.com/p/v8/
 DM-Upload-Allowed: yes
@@ -32,6 +32,7 @@
  program.
 
 Package: libv8-dbg
+Priority: extra
 Section: debug
 Architecture: i386 amd64 armel mipsel
 Depends: libv8-2.2.24 (= ${binary:Version}), ${misc:Depends}
diff -Nru libv8-2.2.24/debian/rules libv8-2.2.24/debian/rules
--- libv8-2.2.24/debian/rules	2010-07-24 20:38:53.0 +0200
+++ libv8-2.2.24/debian/rules	2010-08-12 23:44:15.0 +0200
@@ -26,6 +26,8 @@
 CFLAGS += -fno-strict-aliasing
 export CFLAGS
 export CXXFLAGS
+# this is needed to avoid buggy behavior when compiled with gcc 44
+export GCC_VERSION=44
 
 DEB_SCONS_OPTIONS  := library=shared soname=on shlibtype=hidden
 DEB_SCONS_INSTALL_OPTIONS  := $(DEB_SCONS_OPTIONS) DESTDIR=$(DEB_DESTDIR)