Re: [Pkg-javascript-devel] nodejs-12 transition
Le 31/05/2020 à 18:04, Nilesh Patra a écrit : > It doesn't go well ! > Both mips archs won't compile, > > > Is it only mips that this fails on? > If yes, maybe this can be ignored for the moment. No we can't: testing migration requires success on amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el and s390x. Only other arch are optional. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#960808: node-babel7 7.9.6
Le 19/05/2020 à 15:10, Xavier a écrit : > Le 19/05/2020 à 14:37, Xavier a écrit : >> Le 19/05/2020 à 10:21, Xavier a écrit : >>> Le 18/05/2020 à 18:50, Pirate Praveen a écrit : >>>> >>>> >>>> On Sun, May 17, 2020 at 9:29 pm, Xavier wrote: >>>>> Control: blocked -1 by 952335 >>>>> >>>>> Hi all, >>>>> >>>>> node-babel7 7.9.6 seems ready but it needs node-commander 4. >>>>> node-commander upgrade is blocked by #952335 (uglify-js needs >>>>> node-commander 2) >>>>> >>>> >>>> Can we upload this to experimental till uglify-js is fixed in unstable? >>> >>> Yes of course, I'm going to do it >> >> Done >> >>>> Also which branch you have used for this update? >>> >>> Not yet pushed. I'm cleaning my work and will push after >> >> Done also. I think babel-7.9.6 is a good candidate for bullseye > > Hi, > > node-babel7 7.9.6 is ready in experimental. It is able to build itself > and was also tested with twitter-bootstrap4 4.5.0. > > More tests welcome! I launched a full rebuild of all reverse deps. All good except: * filesaver.js babeljs -o dist/FileSaver.js --presets @babel/env --modules umd \ src/FileSaver.js error: unknown option '--modules' * node-caniuse-lite Error: Cannot find module 'babel-types' * node-string-decoder Error: Cannot find module 'core-js/es6' at Function.Module._resolveFilename (internal/modules /cjs/loader.js:636:15) at Function.Module._load (internal/modules/cjs/loader.js:562:25) at Module.require (internal/modules/cjs/loader.js:692:17) at require (internal/modules/cjs/helpers.js:25:18) at Object. (/usr/share/nodejs/@babel/polyfill/lib/noConflict.js:3:1) -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#961111: Bug#961111: add an option to specify build-only components in watch
Le 20/05/2020 à 10:53, Pirate Praveen a écrit : > Package: pkg-js-tools > Version: 0.9.36 > Severity: wishlist > > Currently we use debian/build_modules to add build only modules, but > that is manual and we cannot use uscan like other components. Can we add > an option to watch file to specify a component is build-only and need > not be installed in the binary package? > > For example katex-fonts in node-katex, I'd like to use uscan to download > the compnent, but I don't want it installed in node_modules in the final > package. May be an option to specify which directory it should be > symlinked to, for example, in this case, I want it symlinked to > submodules and not node_modules (node_modules can be the default if > nothing is specified). Hi, you can do it: if you list components in debian/nodejs/submodules, only listed components will be installed -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#960808: Bug#960808: node-babel7 7.9.6
Le 20/05/2020 à 09:02, Xavier a écrit : > Le 19/05/2020 à 15:10, Xavier a écrit : >> Le 19/05/2020 à 14:37, Xavier a écrit : >>> Le 19/05/2020 à 10:21, Xavier a écrit : >>>> Le 18/05/2020 à 18:50, Pirate Praveen a écrit : >>>>> >>>>> >>>>> On Sun, May 17, 2020 at 9:29 pm, Xavier wrote: >>>>>> Control: blocked -1 by 952335 >>>>>> >>>>>> Hi all, >>>>>> >>>>>> node-babel7 7.9.6 seems ready but it needs node-commander 4. >>>>>> node-commander upgrade is blocked by #952335 (uglify-js needs >>>>>> node-commander 2) >>>>>> >>>>> >>>>> Can we upload this to experimental till uglify-js is fixed in unstable? >>>> >>>> Yes of course, I'm going to do it >>> >>> Done >>> >>>>> Also which branch you have used for this update? >>>> >>>> Not yet pushed. I'm cleaning my work and will push after >>> >>> Done also. I think babel-7.9.6 is a good candidate for bullseye >> >> Hi, >> >> node-babel7 7.9.6 is ready in experimental. It is able to build itself >> and was also tested with twitter-bootstrap4 4.5.0. >> >> More tests welcome! > > I launched a full rebuild of all reverse deps. All good except: > > * filesaver.js > > babeljs -o dist/FileSaver.js --presets @babel/env --modules umd \ > src/FileSaver.js > error: unknown option '--modules' Unable to reproduce > * node-caniuse-lite > > Error: Cannot find module 'babel-types' Fixed in node-caniuse-lite > * node-string-decoder > > Error: Cannot find module 'core-js/es6' > at Function.Module._resolveFilename (internal/modules > /cjs/loader.js:636:15) > at Function.Module._load (internal/modules/cjs/loader.js:562:25) > at Module.require (internal/modules/cjs/loader.js:692:17) > at require (internal/modules/cjs/helpers.js:25:18) > at Object. > (/usr/share/nodejs/@babel/polyfill/lib/noConflict.js:3:1) Fixed in node-babel7 7.9.6+~cs66.71.39-4 (core-js patch) -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#961111: Bug#961111: Bug#961111: add an option to specify build-only components in watch
Le 20 mai 2020 12:24:05 GMT+02:00, Pirate Praveen a écrit : > > >On Wed, May 20, 2020 at 11:03 am, Xavier wrote: >> Le 20/05/2020 à 10:53, Pirate Praveen a écrit : >>> Package: pkg-js-tools >>> Version: 0.9.36 >>> Severity: wishlist >>> >>> Currently we use debian/build_modules to add build only modules, but >>> that is manual and we cannot use uscan like other components. Can >>> we add >>> an option to watch file to specify a component is build-only and >>> need >>> not be installed in the binary package? >>> >>> For example katex-fonts in node-katex, I'd like to use uscan to >>> download >>> the compnent, but I don't want it installed in node_modules in the >>> final >>> package. May be an option to specify which directory it should be >>> symlinked to, for example, in this case, I want it symlinked to >>> submodules and not node_modules (node_modules can be the default if >>> nothing is specified). >> >> Hi, >> >> you can do it: if you list components in debian/nodejs/submodules, >> only >> listed components will be installed > >Thanks, that works. Would it be a lot of work to do it in watch as a >new option? Just checking if it can be done at single place easily. Modifying debian/watch requires a pkg-js-tools-specific change in uscan, not easy -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] @rollup/* plugins
Le 16/09/2020 à 19:24, Xavier a écrit :
> Le 15/09/2020 à 18:35, Xavier a écrit :
>> Le 15/09/2020 à 17:04, Pirate Praveen a écrit :
>>>
>>>
>>> On Tue, Sep 15, 2020 at 11:06, Xavier wrote:
>>>> Hi all,
>>>>
>>>> next node-babel7 needs some @rollup/* plugins that can not be replaced
>>>> by rollup-*.
>>>> Proposition: for each node-rollup-* package:
>>>> * change default debian/watch entry to download @rollup/*
>>>> * embed old rollup-* as a component to keep compatibility
>>>> *OR*
>>>> * create a dummy rollup-* module with
>>>> `module.export = require("@rollup/NAME")`
>>>>
>>>> Do you agree with that?
>>>>
>>>> NB: @rollup/* look to work fine with current rollup
>>>
>>> I think all @rollup/plugins are in a single repo. Does it make sense to
>>> create a single rollup-plugins package?
>>
>> Yes single repo but:
>> * no version management
>> * no tags
>>
>> So uscan won't be able to know what version it downloads and if it's a
>> release or not
>
> I prepared an upgrade of node-rollup-pluginutils which contains both
> @rollup/pluginutils and rollup-pluginutils (pushed to salsa only). This
> package can be built using current (legacy) modules and future ones (see
> debian/rules).
>
> debian/watch downloads github.com/rollup/plugins content based on tags
> named "pluginsutils-v".
>
> I think that this can be reproduced for each node-rollup-* package and I
> don't find a better way for now.
>
> Could you take a look ?
I pushed some rollup-plugin* to experimental. They provides legacy +
up-to-date module. Hope someone could have a look
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc
Le 20/09/2020 à 22:08, Pirate Praveen a écrit : > > > On 2020, സെപ്റ്റംബർ 21 12:38:37 AM IST, Xavier Guimard > wrote: >> Package: rollup >> Version: 1.12.0-2 >> Severity: serious >> Tags: ftbfs >> Justification: Policy 7.7.7 >> >> node-rollup 1.12.0 can't be build with current typescript (4.0.2). It >> requires tsc 3.4.5 (tested with success). Output: > > I think the root cause is uploading major versions without coordination. It > should have been easily found out if all packages using typescript was > rebuilt before it was uploaded to unstable. > > I think we should create a release team within js team to handle it like how > release team works for transitions. +1 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] @rollup/* plugins
Le 15/09/2020 à 18:35, Xavier a écrit :
> Le 15/09/2020 à 17:04, Pirate Praveen a écrit :
>>
>>
>> On Tue, Sep 15, 2020 at 11:06, Xavier wrote:
>>> Hi all,
>>>
>>> next node-babel7 needs some @rollup/* plugins that can not be replaced
>>> by rollup-*.
>>> Proposition: for each node-rollup-* package:
>>> * change default debian/watch entry to download @rollup/*
>>> * embed old rollup-* as a component to keep compatibility
>>> *OR*
>>> * create a dummy rollup-* module with
>>> `module.export = require("@rollup/NAME")`
>>>
>>> Do you agree with that?
>>>
>>> NB: @rollup/* look to work fine with current rollup
>>
>> I think all @rollup/plugins are in a single repo. Does it make sense to
>> create a single rollup-plugins package?
>
> Yes single repo but:
> * no version management
> * no tags
>
> So uscan won't be able to know what version it downloads and if it's a
> release or not
I prepared an upgrade of node-rollup-pluginutils which contains both
@rollup/pluginutils and rollup-pluginutils (pushed to salsa only). This
package can be built using current (legacy) modules and future ones (see
debian/rules).
debian/watch downloads github.com/rollup/plugins content based on tags
named "pluginsutils-v".
I think that this can be reproduced for each node-rollup-* package and I
don't find a better way for now.
Could you take a look ?
debc:
usr/share/doc/
usr/share/doc/node-rollup-pluginutils/
usr/share/doc/node-rollup-pluginutils/README.md.gz
usr/share/doc/node-rollup-pluginutils/changelog.Debian.gz
usr/share/doc/node-rollup-pluginutils/copyright
usr/share/nodejs/
usr/share/nodejs/@rollup/
usr/share/nodejs/@rollup/pluginutils/
usr/share/nodejs/@rollup/pluginutils/dist/
usr/share/nodejs/@rollup/pluginutils/dist/cjs/
usr/share/nodejs/@rollup/pluginutils/dist/cjs/index.js
usr/share/nodejs/@rollup/pluginutils/dist/es/
usr/share/nodejs/@rollup/pluginutils/dist/es/index.js
usr/share/nodejs/@rollup/pluginutils/package.json
usr/share/nodejs/@rollup/pluginutils/types/
usr/share/nodejs/@rollup/pluginutils/types/index.d.ts
usr/share/nodejs/rollup-pluginutils/
usr/share/nodejs/rollup-pluginutils/dist/
usr/share/nodejs/rollup-pluginutils/dist/pluginutils.cjs.js
usr/share/nodejs/rollup-pluginutils/dist/pluginutils.d.ts
usr/share/nodejs/rollup-pluginutils/dist/pluginutils.es.js
usr/share/nodejs/rollup-pluginutils/package.json
usr/share/nodejs/rollup-pluginutils/src/
usr/share/nodejs/rollup-pluginutils/src/addExtension.ts
usr/share/nodejs/rollup-pluginutils/src/attachScopes.ts
usr/share/nodejs/rollup-pluginutils/src/createFilter.ts
usr/share/nodejs/rollup-pluginutils/src/dataToEsm.ts
usr/share/nodejs/rollup-pluginutils/src/extractAssignedNames.ts
usr/share/nodejs/rollup-pluginutils/src/index.ts
usr/share/nodejs/rollup-pluginutils/src/makeLegalIdentifier.ts
usr/share/nodejs/rollup-pluginutils/src/pluginutils.d.ts
usr/share/nodejs/rollup-pluginutils/src/utils/
usr/share/nodejs/rollup-pluginutils/src/utils/ensureArray.ts
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] rollup 1.32.1 in unstable
Hi all, I successfully tested the last rollup 1.x (1.32.1 uploaded to experimental) with all the following packages (autopkgtest and rebuild). Exceptions: * node-rollup-plugin-commonjs (2 little test output changes) * node-rollup-plugin-replace (1 little test output change) * notepadqq build failed for another reason (#964603) * should.js: *incompatible uglifyjs update* I no one disagree, I plan to push it to unstable after fixing node-rollup-plugin-commonjs/replace. Cheers, Xavier autopkgtest --- node-buble node-rollup-plugin-alias node-magic-string node-rollup-plugin-babel node-rollup-plugin-bublenode-rollup-plugin-json node-rollup-plugin-commonjs node-rollup-plugin-node-resolve node-rollup-plugin-replace node-rollup-plugin-typescript node-rollup-plugin-string node-rollup-pluginutils rebuild --- acorn node-d3-fetch codemirror-js node-d3-force d3-format node-d3-geo leaflet-markercluster node-d3-hierarchy leaflet node-d3-interpolate less.js node-d3-path libjs-fetch node-d3-polygon libjs-webrtc-adapternode-d3-quadtree node-autoprefixer node-d3-queue node-babel7 node-d3-random node-buble node-d3 node-chart.js node-d3-request node-d3-array node-d3-scale-chromatic node-d3-axisnode-d3-scale node-d3-brush node-d3-selection node-d3-chord node-d3-shape node-d3-collection node-d3-time-format node-d3-color node-d3-time node-d3-contour node-d3-timer node-d3-dispatchnode-d3-transition node-d3-dragnode-d3-voronoi node-d3-dsv node-d3-zoom node-d3-easenode-dagre-d3-renderer node-dagre-layout node-rollup-plugin-commonjs node-debug node-rollup-plugin-json node-eslint-utils node-rollup-plugin-node-resolve node-estree-walker node-rollup-plugin-replace node-graphlibrary node-rollup-plugin-string node-i18next-browser-languagedetector node-rollup-plugin-typescript node-i18nextnode-rollup-pluginutils node-i18next-xhr-backendnode-sourcemap-codec node-immutable node-stable node-immutable-tuplenode-terser node-jest node-timeago.js node-locate-character node-tippex node-magic-string node-uri-js node-markdown-itnotepadqq node-mocha popper.js node-prosemirror-markdown psl.js node-prosemirror-model rails node-puka rainbow.js node-react should.js node-redux three.js node-rollup-plugin-aliastwitter-bootstrap4 node-rollup-plugin-babelvue.js node-rollup-plugin-bublevue-router.js -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Notes for node-mkdirp upgrade
Hi, mkdirp is outdated in Debian. Upgrade to ≥ 1.0.3 introduces a major breaking change, however easy to patch (callback replaced by promise). => If no one disagrees, I'll push these packages from experimental to unstable when the 9 remaining packages will be patched. _Packages ready in experimental_: * node-copy-concurrently * node-cpr * node-fstream * node-tar *Packages not yet patched*: * node-bluebird * node-cacache (last version needs a recent mkdirp) * node-chownr * node-fs-vacuum * node-glob * node-klaw * node-mocha * node-multiparty * node-node-sass Packages that already look OK with experimental packages listed above: * grunt * node-babel7 * node-cache-loader * node-findit2 * node-gypnode-istanbul * node-isexe * node-istanbul * node-js-beautify * node-move-concurrently * node-mqtt * node-npmrc * node-pre-gyp * node-output-file-sync * node-rimraf * node-stylus * node-tacks * node-tap * node-unicode-data * node-webpack * node-yargs * npm (temporary patch: embeds its updated cacache+mkdirp for now to avoid a major break, *back to normal life after mkdirp upgrade*) Known broken packages: * node-yarnpkg -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Notes for node-mkdirp upgrade
Le 23/10/2020 à 10:03, Xavier a écrit : > Hi, > > mkdirp is outdated in Debian. Upgrade to ≥ 1.0.3 introduces a major > breaking change, however easy to patch (callback replaced by promise). > > => If no one disagrees, I'll push these packages from experimental to >unstable when the 9 remaining packages will be patched. Update: I'm ready to push these package to unstable: * node-copy-concurrently * node-cpr * node-fstream * node-tar * node-bluebird * node-cacache (last version needs a recent mkdirp) * node-chownr * node-fs-vacuum * node-glob * node-klaw * node-multiparty * node-node-sass Packages that already look OK with experimental packages listed above: * grunt * node-babel7 * node-cache-loader * node-findit2 * node-gypnode-istanbul * node-isexe * node-istanbul * node-js-beautify * node-move-concurrently * node-mqtt * node-npmrc * node-pre-gyp * node-output-file-sync * node-rimraf * node-stylus * node-tacks * node-tap * node-unicode-data * node-webpack * node-yargs * npm (temporary patch: embeds its updated cacache+mkdirp for now to avoid a major break, *back to normal life after mkdirp upgrade*) Known broken packages: * node-yarnpkg -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Plan for legacy rollup plugins in bullseye (was Re: node-rollup-plugin-inject 4.0.2+~3.0.2-1 MIGRATED to testing)
Le 25/10/2020 à 09:06, Pirate Praveen a écrit :
>
> On 2020, ഒക്ടോബർ 25 10:09:13 AM IST, Debian testing watch
> wrote:
>> FYI: The status of the node-rollup-plugin-inject source package
>> in Debian's testing distribution has changed.
>>
>> Previous version: (not in testing)
>> Current version: 4.0.2+~3.0.2-1
>
> Are we going to maintain legacy versions of these plugins in bullseye? I
> agree adding them makes the transition easier, but removing the legacy copies
> should also be part of the plan to avoid maintaining multiple versions of
> these plugins.
Hi,
you're right, however there are a lot of outdated modules in JS Team
packages, and these rollup plugins have no known vulnerabilities.
We can also facilitate transition using this way (using experimental of
course):
* remove legacy module from any node-rollup-plugin-*
* insert our own legacy modules in them including just:
* /usr/share/nodejs/rollup-plugin-foo/package.json
{ "name":"rollup-plugin-foo",
"main":"index.js",
"dependencies":{
"@rollup/plugin-foo": "*"
}
}
* /usr/share/nodejs/rollup-plugin-foo/index.js
module.export = require("@rollup/plugin-foo");
Note that transition of node-rollup-plugin-commonjs won't be easy
(remember 10.0.1+really.9.2.0). Same for node-rollup-plugin-node-resolve
Cheers,
Xavier
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Bug#972952: node-mkdirp 1.0 is incompatible with 0.5, breaks yarnpkg
Le 26/10/2020 à 15:28, ano...@users.sourceforge.net a écrit : > Package: node-mkdirp > Version: 1.0.4-2 > Severity: critical > > I don't know whether to report this against node-mkdirp for breaking > compatibility, or yarnpkg for depending on "node-mkdirp (>= 0.5.1)" > rather than "node-mkdirp (>= 0.5.1), node-mkdirp (<<1.0.0)". Either way, > things are currently broken in unstable and shouldn't migrate to > testing. > > I upgraded various packages this morning, and found that yarn would no > longer work. > > $ yarn > yarn install v1.22.4 > warning Skipping preferred cache folder "/home/redacted/.cache/yarn" > because it is not writable. > warning Skipping preferred cache folder "/tmp/.yarn-cache-1000" because it > is not writable. > warning Skipping preferred cache folder "/tmp/.yarn-cache" because it is > not writable. > error Yarn hasn't been able to find a cache folder it can use. Please use > the explicit --cache-folder option to tell it what location to use, or make > one of the preferred locations writable. > info Visit https://yarnpkg.com/en/docs/cli/install for documentation about > this command. > > This turns out to be due to this error being thrown: > > TypeError: invalid options argument > at optsArg (/usr/share/nodejs/mkdirp/lib/opts-arg.js:13:11) > at mkdirp (/usr/share/nodejs/mkdirp/index.js:11:10) > at /usr/share/nodejs/yarn/lib/util/promise.js:37:10 > at new Promise () > at /usr/share/nodejs/yarn/lib/util/promise.js:17:12 > at Object. (/usr/share/nodejs/yarn/lib/util/fs.js:1024:15) > at Generator.throw () > at step > (/usr/share/nodejs/babel-runtime/helpers/asyncToGenerator.js:17:30) > at /usr/share/nodejs/babel-runtime/helpers/asyncToGenerator.js:30:13 > > It turns out yarn is expecting node-mkdirp to accept a callback, which > was apparently dropped in node-mkdirp 1.0 in favor of it returning a > promise. > > Downgrading node-mkdirp to 0.5.1-2 fixed it: > > $ yarn > yarn install v1.22.4 > info No lockfile found. > [1/4] Resolving packages... > [2/4] Fetching packages... > [3/4] Linking dependencies... > [4/4] Building fresh packages... > success Saved lockfile. > Done in 0.07s. Hi JS Team, yarnpkg is not in testing due to babel problems. Do you agree to dicrease severity of this bug to allow mkdirp transition (or reassign this bug to node-yarnpkg) ? Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#973170: node-formidable: FTBFS: dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
Control: reassign -1 node-fetch Control: affects -1 node-formidable Le 27/10/2020 à 18:07, Lucas Nussbaum a écrit : > Source: node-formidable > Version: 1.2.1+20200129git8231ea6-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201027 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Test works fine using node-fetch installed using npm (same version but code differs). -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#973081: Bug#973081: pdf.js: FTBFS: [12:18:32] TypeError: Cannot read property 'then' of undefined
Control: reassign -1 webpack Control: affects -1 src:pdf.js Le 27/10/2020 à 18:09, Lucas Nussbaum a écrit : > Source: pdf.js > Version: 2.6.347+dfsg-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201027 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): >> make[1]: Entering directory '/<>' >> gulp dist-pre >> [12:18:24] Local gulp not found in /<> >> [12:18:24] Try running: npm install gulp >> [12:18:24] Using globally installed gulp >> [12:18:24] Using gulpfile /<>/gulpfile.js >> [12:18:24] Starting 'dist-pre'... >> [12:18:24] Starting 'generic'... >> [12:18:24] Starting 'buildnumber'... >> >> ### Getting extension build number >> This is not a Git repository; using default build number. >> Extension build number: 0 >> [12:18:24] Finished 'buildnumber' after 26 ms >> [12:18:24] Starting 'default_preferences'... >> [12:18:24] Starting 'default_preferences-pre'... >> >> ### Building `default_preferences.json` >> Since Acorn 8.0.0, options.ecmaVersion is required. >> Defaulting to 2020, but this will stop working in the future. >> [12:18:25] Finished 'default_preferences-pre' after 425 ms >> [12:18:25] Starting ''... >> [12:18:25] Finished '' after 3.36 ms >> [12:18:25] Finished 'default_preferences' after 429 ms >> [12:18:25] Starting 'locale'... >> >> ### Building localization files >> [12:18:25] Finished 'locale' after 145 ms >> [12:18:25] Starting ''... >> >> ### Creating generic viewer >> (node:27451) [DEP0005] DeprecationWarning: Buffer() is deprecated due to >> security and usability issues. Please use the Buffer.alloc(), >> Buffer.allocUnsafe(), or Buffer.from() methods instead. >> [12:18:32] '' errored after 7.53 s >> [12:18:32] TypeError: Cannot read property 'then' of undefined >> at /usr/share/nodejs/webpack/lib/Compiler.js:493:44 > failed build was retried once to eliminate random failures. Problem comes from mkdirp-1 patch -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#973081: Bug#973081: Bug#973081: pdf.js: FTBFS: [12:18:32] TypeError: Cannot read property 'then' of undefined
Control: reassign -1 src:pdf.js Control: found -1 2.6.347+dfsg-1 Le 27/10/2020 à 23:29, Xavier a écrit : > Control: reassign -1 webpack > Control: affects -1 src:pdf.js > > Le 27/10/2020 à 18:09, Lucas Nussbaum a écrit : >> Source: pdf.js >> Version: 2.6.347+dfsg-1 >> Severity: serious >> Justification: FTBFS on amd64 >> Tags: bullseye sid ftbfs >> Usertags: ftbfs-20201027 ftbfs-bullseye >> >> Hi, >> >> During a rebuild of all packages in sid, your package failed to build >> on amd64. >> >> Relevant part (hopefully): >>> make[1]: Entering directory '/<>' >>> gulp dist-pre >>> [12:18:24] Local gulp not found in /<> >>> [12:18:24] Try running: npm install gulp >>> [12:18:24] Using globally installed gulp >>> [12:18:24] Using gulpfile /<>/gulpfile.js >>> [12:18:24] Starting 'dist-pre'... >>> [12:18:24] Starting 'generic'... >>> [12:18:24] Starting 'buildnumber'... >>> >>> ### Getting extension build number >>> This is not a Git repository; using default build number. >>> Extension build number: 0 >>> [12:18:24] Finished 'buildnumber' after 26 ms >>> [12:18:24] Starting 'default_preferences'... >>> [12:18:24] Starting 'default_preferences-pre'... >>> >>> ### Building `default_preferences.json` >>> Since Acorn 8.0.0, options.ecmaVersion is required. >>> Defaulting to 2020, but this will stop working in the future. >>> [12:18:25] Finished 'default_preferences-pre' after 425 ms >>> [12:18:25] Starting ''... >>> [12:18:25] Finished '' after 3.36 ms >>> [12:18:25] Finished 'default_preferences' after 429 ms >>> [12:18:25] Starting 'locale'... >>> >>> ### Building localization files >>> [12:18:25] Finished 'locale' after 145 ms >>> [12:18:25] Starting ''... >>> >>> ### Creating generic viewer >>> (node:27451) [DEP0005] DeprecationWarning: Buffer() is deprecated due to >>> security and usability issues. Please use the Buffer.alloc(), >>> Buffer.allocUnsafe(), or Buffer.from() methods instead. >>> [12:18:32] '' errored after 7.53 s >>> [12:18:32] TypeError: Cannot read property 'then' of undefined >>> at /usr/share/nodejs/webpack/lib/Compiler.js:493:44 >> failed build was retried once to eliminate random failures. > > Problem comes from mkdirp-1 patch Finally, problem is in pdf.js/debian/build_modules/webpack-stream, a wrapper around webpack -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#973170: node-fetch has no default export
Control: retitle -1 node-fetch has no default export
Le 27/10/2020 à 21:47, Xavier a écrit :
> Control: reassign -1 node-fetch
> Control: affects -1 node-formidable
>
> Le 27/10/2020 à 18:07, Lucas Nussbaum a écrit :
>> Source: node-formidable
>> Version: 1.2.1+20200129git8231ea6-1
>> Severity: serious
>> Justification: FTBFS on amd64
>> Tags: bullseye sid ftbfs
>> Usertags: ftbfs-20201027 ftbfs-bullseye
>>
>> Hi,
>>
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>
> Test works fine using node-fetch installed using npm (same version but
> code differs).
Here is the bug:
*with node-fetch from npm registry*, this works:
$ node -e 'var f = require("node-fetch");
console.log("result",f("http://google.com;))'
result Promise { }
*with node-fetch from Debian* /(same version)/:
$ node -e 'var f = require("node-fetch");
console.log("result",f("http://google.com;))'
[eval]:1
var f = require("node-fetch");console.log("e",f("http://google.com;))
^
TypeError: f is not a function
*but this works*:
$ node -e 'var f = require("node-fetch");
console.log("result",f.default("http://google.com;))'
result Promise { }
So "default" is not default. There is problably a missing rollup plugin,
NB: node-fetch/package.json requires "rollup ^0.63.4"
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] RFH: FTBFS problem with jekyll build because some node* packages were updated
Le 25/10/2020 à 21:04, Xavier a écrit : > Le 25/10/2020 à 20:42, Pirate Praveen a écrit : >> [Adding pkg-javascript-devel list] >> >> On 2020, ഒക്ടോബർ 26 12:14:08 AM IST, Daniel Leidert >> wrote: >>> Hi, >>> >>> the jekyll build fails at the moment because livereload.js created in the >>> override_dh_auto_build target is not created. The creation prints some >>> warnings: >>> >>>> make[1]: Entering directory '/tmp/build-area/jekyll-3.9.0+dfsg' >>>> cd debian/node_modules/livereload-js; webpack --entry ./lib/startup.js \ >>>> --output >>>> ../../../lib/jekyll/commands/serve/livereload_assets/livereload.js; cd - >>>> (node:391702) UnhandledPromiseRejectionWarning: TypeError: invalid options >>>> argument >>>> at optsArg (/usr/share/nodejs/mkdirp/lib/opts-arg.js:13:11) >>>> at NodeOutputFileSystem.mkdirp >>>> (/usr/share/nodejs/mkdirp/index.js:11:10) >>>> at /usr/share/nodejs/webpack/lib/Compiler.js:494:26 >>>> at AsyncSeriesHook.eval [as callAsync] (eval at create >>>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :4:1) >>>> at AsyncSeriesHook.lazyCompileHook [as _callAsync] >>>> (/usr/share/nodejs/tapable/lib/Hook.js:35:21) >>>> at Compiler.emitAssets >>>> (/usr/share/nodejs/webpack/lib/Compiler.js:491:19) >>>> at onCompiled (/usr/share/nodejs/webpack/lib/Compiler.js:278:9) >>>> at /usr/share/nodejs/webpack/lib/Compiler.js:681:15 >>>> at AsyncSeriesHook.eval [as callAsync] (eval at create >>>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :4:1) >>>> at AsyncSeriesHook.lazyCompileHook [as _callAsync] >>>> (/usr/share/nodejs/tapable/lib/Hook.js:35:21) >>>> at /usr/share/nodejs/webpack/lib/Compiler.js:678:31 >>>> at AsyncSeriesHook.eval [as callAsync] (eval at create >>>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :4:1) >>>> at AsyncSeriesHook.lazyCompileHook [as _callAsync] >>>> (/usr/share/nodejs/tapable/lib/Hook.js:35:21) >>>> at /usr/share/nodejs/webpack/lib/Compilation.js:1423:35 >>>> at AsyncSeriesHook.eval [as callAsync] (eval at create >>>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :4:1) >>>> at AsyncSeriesHook.lazyCompileHook [as _callAsync] >>>> (/usr/share/nodejs/tapable/lib/Hook.js:35:21) >>>> at /usr/share/nodejs/webpack/lib/Compilation.js:1414:32 >>>> at eval (eval at create >>>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :9:1) >>>> at /usr/share/nodejs/uglifyjs-webpack-plugin/dist/index.js:263:11 >>>> at step >>>> (/usr/share/nodejs/uglifyjs-webpack-plugin/dist/uglify/Runner.js:98:11) >>>> at done >>>> (/usr/share/nodejs/uglifyjs-webpack-plugin/dist/uglify/Runner.js:110:22) >>>> (node:391702) UnhandledPromiseRejectionWarning: Unhandled promise >>>> rejection. This error originated either by throwing inside of an async >>>> function without a catch block, or by rejecting a promise which was not >>>> handled with .catch(). To terminate the node process on unhandled promise >>>> rejection, use the CLI flag `--unhandled-rejections=strict` (see >>>> https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection >>>> id: 1) >>>> (node:391702) [DEP0018] DeprecationWarning: Unhandled promise rejections >>>> are deprecated. In the future, promise rejections that are not handled >>>> will terminate the Node.js process with a non-zero exit code. >>>> /tmp/build-area/jekyll-3.9.0+dfsg >>> >>> I was able to restore the old behavior in Sid via: >>> >>> sudo apt-get install node-cacache=11.3.3-2 node-mkdirp=0.5.1-2 \ >>> node-copy-concurrently=1.0.5-5 webpack+ >>> >>> But I really need help fixing whatever the problem is with the updated node* >>> packages. Any help is appreciated. >> >> This is the result of node-mkdirp transition. >> >> See >> https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-October/045643.html >> >>> Regards, Daniel > > Sadly debci didn't show this problem before transition, I' going to fix > webpack Fixed in 4.43.0-2, sorry for this. Now your build fails but for other reasons... Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] RFH: FTBFS problem with jekyll build because some node* packages were updated
Le 25/10/2020 à 20:42, Pirate Praveen a écrit : > [Adding pkg-javascript-devel list] > > On 2020, ഒക്ടോബർ 26 12:14:08 AM IST, Daniel Leidert > wrote: >> Hi, >> >> the jekyll build fails at the moment because livereload.js created in the >> override_dh_auto_build target is not created. The creation prints some >> warnings: >> >>> make[1]: Entering directory '/tmp/build-area/jekyll-3.9.0+dfsg' >>> cd debian/node_modules/livereload-js; webpack --entry ./lib/startup.js \ >>> --output >>> ../../../lib/jekyll/commands/serve/livereload_assets/livereload.js; cd - >>> (node:391702) UnhandledPromiseRejectionWarning: TypeError: invalid options >>> argument >>> at optsArg (/usr/share/nodejs/mkdirp/lib/opts-arg.js:13:11) >>> at NodeOutputFileSystem.mkdirp (/usr/share/nodejs/mkdirp/index.js:11:10) >>> at /usr/share/nodejs/webpack/lib/Compiler.js:494:26 >>> at AsyncSeriesHook.eval [as callAsync] (eval at create >>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :4:1) >>> at AsyncSeriesHook.lazyCompileHook [as _callAsync] >>> (/usr/share/nodejs/tapable/lib/Hook.js:35:21) >>> at Compiler.emitAssets >>> (/usr/share/nodejs/webpack/lib/Compiler.js:491:19) >>> at onCompiled (/usr/share/nodejs/webpack/lib/Compiler.js:278:9) >>> at /usr/share/nodejs/webpack/lib/Compiler.js:681:15 >>> at AsyncSeriesHook.eval [as callAsync] (eval at create >>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :4:1) >>> at AsyncSeriesHook.lazyCompileHook [as _callAsync] >>> (/usr/share/nodejs/tapable/lib/Hook.js:35:21) >>> at /usr/share/nodejs/webpack/lib/Compiler.js:678:31 >>> at AsyncSeriesHook.eval [as callAsync] (eval at create >>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :4:1) >>> at AsyncSeriesHook.lazyCompileHook [as _callAsync] >>> (/usr/share/nodejs/tapable/lib/Hook.js:35:21) >>> at /usr/share/nodejs/webpack/lib/Compilation.js:1423:35 >>> at AsyncSeriesHook.eval [as callAsync] (eval at create >>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :4:1) >>> at AsyncSeriesHook.lazyCompileHook [as _callAsync] >>> (/usr/share/nodejs/tapable/lib/Hook.js:35:21) >>> at /usr/share/nodejs/webpack/lib/Compilation.js:1414:32 >>> at eval (eval at create >>> (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :9:1) >>> at /usr/share/nodejs/uglifyjs-webpack-plugin/dist/index.js:263:11 >>> at step >>> (/usr/share/nodejs/uglifyjs-webpack-plugin/dist/uglify/Runner.js:98:11) >>> at done >>> (/usr/share/nodejs/uglifyjs-webpack-plugin/dist/uglify/Runner.js:110:22) >>> (node:391702) UnhandledPromiseRejectionWarning: Unhandled promise >>> rejection. This error originated either by throwing inside of an async >>> function without a catch block, or by rejecting a promise which was not >>> handled with .catch(). To terminate the node process on unhandled promise >>> rejection, use the CLI flag `--unhandled-rejections=strict` (see >>> https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection >>> id: 1) >>> (node:391702) [DEP0018] DeprecationWarning: Unhandled promise rejections >>> are deprecated. In the future, promise rejections that are not handled will >>> terminate the Node.js process with a non-zero exit code. >>> /tmp/build-area/jekyll-3.9.0+dfsg >> >> I was able to restore the old behavior in Sid via: >> >> sudo apt-get install node-cacache=11.3.3-2 node-mkdirp=0.5.1-2 \ >> node-copy-concurrently=1.0.5-5 webpack+ >> >> But I really need help fixing whatever the problem is with the updated node* >> packages. Any help is appreciated. > > This is the result of node-mkdirp transition. > > See > https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-October/045643.html > >> Regards, Daniel Sadly debci didn't show this problem before transition, I' going to fix webpack -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Working on jest
Hi all, I updated node-istanbul and node-babel7 for jest (and node-es-abstract has been accepted). Now missing dependencies are: assign-symbols atob bser buffer-from callsites capture-exitchar-regex cjs-module-lexer collect-v8-coverage decode-uri-component emittery emoji-regex exec-sh fast-json-stable-stringify fb-watchman fsevents growly human-signals import-local is-ci is-core-module is-docker is-fullwidth-code-point is-wsl jest-pnp-resolver json-parse-even-better-errors kleur lines-and-columns makeerror nanomatch natural-compare nice-try node-int64 node-notifier object.pick onetime path-key path-parse p-each-series prompts p-try resolve-url ret rsvp safer-buffer sane shellwords sisteransi source-map-resolve source-map-url string-length strip-final-newline supports-hyperlinks terminal-link throat tmpl type-fest urix v8-to-istanbul walker word-wrap Le 27/10/2020 à 08:33, Debian FTP Masters a écrit : > > > Accepted: > > Format: 1.8 > Date: Tue, 27 Oct 2020 07:58:32 +0100 > Source: node-istanbul > Architecture: source > Version: 0.4.5+ds+~cs33.3.7-1 > Distribution: unstable > Urgency: medium > Maintainer: Debian Javascript Maintainers > > Changed-By: Xavier Guimard > Changes: > node-istanbul (0.4.5+ds+~cs33.3.7-1) unstable; urgency=medium > . >* Team upload >* Bump debhelper compatibility level to 13 >* Declare compliance with policy 4.5.0 >* Add "Rules-Requires-Root: no" >* Use dh-sequence-nodejs >* Embed components: babel-plugin-istanbul get-package-type html-escaper >istanbul-lib-coverage istanbul-lib-instrument >istanbul-lib-report istanbul-lib-source-maps >istanbul-reports >@istanbuljs/load-nyc-config @istanbuljs/schema > babel-plugin-istanbul test-exclude >* New upstream version 0.4.5+ds+~cs33.3.7 > Really: 0.4.5+~0.1.0+~3.0.0+~3.0.0+~4.0.3 > +~3.0.0+~4.0.0+~3.0.2+~1.1.0+~0.1.2+~6.0.0+~6.0.0 >* Add node-babel7 and node-resolve-from to recommended dependencies >* Add minimal components test >* Update copyright >* Drop unneeded version constraints from (build) dependencies >* Use dh-sequence-nodejs auto links >* New upstream version 0.4.5+ds+~cs33.3.7 >* Build components >* Add lintian overrides >* Replace custom test by upstream tests > Checksums-Sha1: > 42f6e36bc3b55c702ff960c961b3fbf9c7305568 6570 > node-istanbul_0.4.5+ds+~cs33.3.7-1.dsc > fac0615939a5011591e600777f04ce46f6cdaadf 58300 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-babel-plugin-istanbul.tar.xz > 1b205d84267e79f0de7fb080e51e28010c6c23a3 3876 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-get-package-type.tar.xz > fbdea039512a148775aa22e63a3e6486c64ff527 4684 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-html-escaper.tar.xz > 6001b4547077944aca9a7fb322fbc12e6ca4e75b 6640 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-istanbul-lib-coverage.tar.xz > 3ce4c4292d8757510f8a9a5f94db0112a5b2a277 13324 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-istanbul-lib-instrument.tar.xz > 4ec8386773459636ee93ecf64d6e9cdda03c1870 9784 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-istanbul-lib-report.tar.xz > 93d40076201cc8f511eb164f54640d7d872030ab 8084 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-istanbul-lib-source-maps.tar.xz > a34cec8d43ce5e4eabd1d62fd7caaa463b87959e 71100 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-istanbul-reports.tar.xz > ce99546bcc000c235dabac74ddeae6d76927b529 7564 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-istanbuljs-load-nyc-config.tar.xz > 4289c6e4e4be3af53718b7c901c684329c387d8f 6472 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-istanbuljs-schema.tar.xz > f8788522a6abed781546317effe2fe853a0d86b7 9168 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-test-exclude.tar.xz > 9d13fcd87618c87533cc31588ac71e4f4991f376 96744 > node-istanbul_0.4.5+ds+~cs33.3.7.orig.tar.xz > 0edb86b48fed7eb9ea800daa5b01bedf348e7131 8064 > node-istanbul_0.4.5+ds+~cs33.3.7-1.debian.tar.xz > Checksums-Sha256: > 3924553cda0737366d4d415732d1fb6535469027a5098db4605d1876e9f55009 6570 > node-istanbul_0.4.5+ds+~cs33.3.7-1.dsc > 07c455fc15d04760120f2bcc94dbc39d53ea3cae68afedd7b8cd4b46c87ac587 58300 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-babel-plugin-istanbul.tar.xz > ad752c4516dda5afe316750ddb522bc023b87f7c59de6c876be1f2e945d5fbc0 3876 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-get-package-type.tar.xz > c2339acc4ecdf26655cdced9354a95c808fa445405bc7202247afe20a541c21c 4684 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-html-escaper.tar.xz > 5201d8679c013e42da7af7772b30df6e6e4c23bd39438ff5127e6841c9b7435f 6640 > node-istanbul_0.4.5+ds+~cs33.3.7.orig-istanbul-lib-coverage.tar.xz > 39567f044fbb575ebb683b8a7e31d9
Re: [Pkg-javascript-devel] Plan for legacy rollup plugins in bullseye (was Re: node-rollup-plugin-inject 4.0.2+~3.0.2-1 MIGRATED to testing)
Le 25/10/2020 à 11:57, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-10-25 11:27:55)
>> Le 25/10/2020 à 09:06, Pirate Praveen a écrit :
>>>
>>> On 2020, ഒക്ടോബർ 25 10:09:13 AM IST, Debian testing watch
>>> wrote:
>>>> FYI: The status of the node-rollup-plugin-inject source package
>>>> in Debian's testing distribution has changed.
>>>>
>>>> Previous version: (not in testing)
>>>> Current version: 4.0.2+~3.0.2-1
>>>
>>> Are we going to maintain legacy versions of these plugins in bullseye? I
>>> agree adding them makes the transition easier, but removing the legacy
>>> copies should also be part of the plan to avoid maintaining multiple
>>> versions of these plugins.
>>
>> Hi,
>>
>> you're right, however there are a lot of outdated modules in JS Team
>> packages, and these rollup plugins have no known vulnerabilities.
>>
>> We can also facilitate transition using this way (using experimental of
>> course):
>> * remove legacy module from any node-rollup-plugin-*
>> * insert our own legacy modules in them including just:
>>* /usr/share/nodejs/rollup-plugin-foo/package.json
>>
>> { "name":"rollup-plugin-foo",
>>"main":"index.js",
>>"dependencies":{
>> "@rollup/plugin-foo": "*"
>>}
>> }
>>
>>* /usr/share/nodejs/rollup-plugin-foo/index.js
>>
>> module.export = require("@rollup/plugin-foo");
>>
>> Note that transition of node-rollup-plugin-commonjs won't be easy
>> (remember 10.0.1+really.9.2.0). Same for node-rollup-plugin-node-resolve
>
> Do I understand you correctly that you propose to ship legacy library
> embedded with consuming packages?
>
> That seems backwards to me - what would be the benefit?
Upstream chose to rename its rollup-plugin-foo to @rollup/plugin-foo.
For now, I modified all of them: I embedded in node-rollup-plugin-foo
both libraries:
* main source is @rollup/plugin-foo
* a component named "legacy" that embeds old node-rollup-plugin-foo
Most of them have non breaking changes. Then instead of keeping an
outdated library, I propose to install only @rollup/plugin-foo and add a
very simple /usr/share/nodejs/rollup-plugin-foo that returns
@rollup/plugin-foo (see above). This permits legacy removal and avoids
to maintain a lot of patches in nodejs packages that uses them. No
urgency for now since there are no security issues.
Some of @rollup/plugin-foo *have* breaking changes, at least
@rollup/plugin-commonjs and @rollup/plugin-node-resolve //(our legacy
node-rollup-plugin-{commonjs,node-resolve} are already outdated)//.
Propositions:
1. keep packages with both libraries
2. try to patch all packages that uses them, then remove "legacy"
component (no urgency for now since there are no security issues)
> I think it is better to ship legacy library with non-legacy library, to
> ease tracking of its continued need and maintain it where there is most
> knowledge about the library, but I may be missing something...
Sorry, I didn't understand, would you like to keep current situation
(I'm OK with this) or remove legacy component (I'm OK too)?
I'm so sorry, my poor English (neither the help of Google Translator)
makes me unable to understand the meaning of "to ship" here (send in
package or send outside package?).
Cheers,
Xavier
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] [RFS] node-prosemirror-state
Le 02/08/2020 à 00:22, Abraham Raji a écrit : > Hi, > > I have pacakged node-prosemirror-state. The updated package built > successfully. > <http://goog_1556917720> > https://salsa.debian.org/avron/node-prosemirror-state. > > Request for review and sponsorship. Hi, * copyright years are wrong * build dependencies are missing * in patch, "forwarded" field must be set to "not-needed" Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#964637: node-rollup: FTBFS: dh_auto_build: error: cd ./. && sh -ex debian/nodejs/./build returned exit code 1
Control: reassign -1 node-typescript-types FTBFS is due to @types/node which was upgraded to version 14.0.14 while we run nodejs 12 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#964637: Bug#964637: node-rollup: FTBFS: dh_auto_build: error: cd ./. && sh -ex debian/nodejs/./build returned exit code 1
Le 06/08/2020 à 20:51, Xavier a écrit : > Control: reassign -1 node-typescript-types > > FTBFS is due to @types/node which was upgraded to version 14.0.14 while > we run nodejs 12 It's time to move @types/node from src:typescript-types to src:nodejs -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#963437: Bug#963437: node-tap: FTBFS: failed tests
Le 21/06/2020 à 22:32, Lucas Nussbaum a écrit :
> Source: node-tap
> Version: 12.0.1+ds-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200620 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
>> make[1]: Entering directory '/<>'
>> cd module-bind-obj-methods && /<>/bin/run.js -R spec -t 3
>> test.js
>>
>> test.js
>>
>> [...]
>>
>> 5370 passing (22s)
>> 2 failing
>>
>> 1) test/test.js assertions and weird stuff equal equal:
>>
>> Error: equal
>> + expected - actual
>>
>> at:
>>line: #
>>column: #
>>file: test/test.js
>> - compare: '==='
>> + compare: ===
>> found: 1
>> source: |
>>tt.equal(1, 2)
>> stack: |
>> at:
>>line: #
>>column: #
>>file: test/test.js
>> - compare: '==='
>> + compare: ===
>> found:
>>foo: 1
>> note: Objects never === one another
>> source: |
>>
>> at Timeout._onTimeout (test/test.js:792:13)
>>
>> 2) test/test.js assertions and weird stuff type type:
>>
>> Error: type
>> + expected - actual
>>
>> at:
>>line: #
>>column: #
>>file: test/test.js
>> - compare: '==='
>> + compare: ===
>> found: 'null'
>> source: |
>>tt.type(null, 'object', 'this fails')
>> stack: |
>> at:
>>line: #
>>column: #
>>file: test/test.js
>> - compare: '==='
>> + compare: ===
>> found: function
>> source: |
>>tt.type(() => {}, Object, 'fail: arrows are not objects')
>> stack: |
>>
>> at Timeout._onTimeout (test/test.js:792:13)
>>
>> make[1]: *** [debian/rules:40: override_dh_auto_test] Error 1
>
> The full build log is available from:
>http://qa-logs.debian.net/2020/06/20/node-tap_12.0.1+ds-2_unstable.log
Problem comes from js-yaml: test succeeds with js-yaml@3.11.0 and fails
with js-yaml@3.14.0 (currently in unstable)
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#964880: Bug#964880: npm: test failures in ppc64el and s390x
compare: === > at: > line: 55 > column: 7 > file: test/tap/legacy-platform-all.js > type: global > function: installCheckAndTest > stack: | > installCheckAndTest (test/tap/legacy-platform-all.js:55:7) > f (/usr/lib/nodejs/once/once.js:25:25) > ChildProcess. (test/common-tap.js:175:5) > source: | > t.is(stderr, '', 'no error messages') > ... > > not ok 2 - install went ok > --- > found: 1 > wanted: 0 > compare: === > at: > line: 56 > column: 7 > file: test/tap/legacy-platform-all.js > type: global > function: installCheckAndTest > stack: | > installCheckAndTest (test/tap/legacy-platform-all.js:56:7) > f (/usr/lib/nodejs/once/once.js:25:25) > ChildProcess. (test/common-tap.js:175:5) > source: | > t.is(code, 0, 'install went ok') > ... > > 1..2 > # failed 2 of 2 tests > not ok 2 - platform-all # time=1259.494ms > > # Subtest: cleanup > 1..0 > ok 3 - cleanup # time=3.623ms > > 1..3 > # failed 1 of 3 tests > # time=1284.26ms > not ok 103 - test/tap/legacy-platform-all.js # time=2193.623ms > > > Looks like you already did a patch for this, not sure why it is commented > out... > > This is the last test that is failing on ppc64el and s390x Hi, this bugs seems fixed now (node.js update ?), just to add "s390x" and "ppc64el" in test/tap/legacy-platform-all.js. @Gianfranco, could you verify ? Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#963628: Bug#963628: Bug#963628: Node-jest fails with: Error: Cannot find module 'import-local'
Le 28/06/2020 à 09:32, Xavier a écrit : > Control: severity -1 grave > > Le 27/06/2020 à 23:31, Nilesh Patra a écrit : >> >> >> On Sun, 28 Jun 2020, 02:45 Xavier, > <mailto:y...@debian.org>> wrote: >> >> Control: severity -i grave >> >> >> Thanks. >> >> >> Le 24/06/2020 à 21:18, Nilesh Patra a écrit : >> > Package: node-jest >> > Severity: serious >> > >> > Dear Maintainer, >> > >> > Node-jest fails with the following on all the node-modules I've >> tried yet. >> > Sample examples on >> >> Work needed for node-jest: >> * add babel-plugin-istanbul; proposition: add it in node-babel7 >> >> >> It's good. >> Would you mind discussing this bit on the list? > > pkg-js list receives messages related to this bug > >> * update and fix node-jsdom >> * add missing components >> >> >> Noted. >> >> >> Here is the list of missing modules (mix of node-jest and node-jsdom): > > jsdom: > * data-urls > * domexception > * html-encoding-sniffer > * w3c-hr-time > * whatwg-encoding > * whatwg-mimetype > * whatwg-url > * xml-name-validator Hi all, after fixing node-jsdom, these modules are required for jest: * astral-regex * babel-plugin-istanbul * babel-preset-current-node-syntax * fast-json-stable-stringify * is-generator-fn * makeerror * natural-compare * p-each-series * p-reduce * sane * string-length * supports-hyperlinks * terminal-link * throat * tmpl * walker I suggests to embed babel* in node-babel7 and others in node-jest. What are your advises ? -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#963628: Bug#963628: Bug#963628: Node-jest fails with: Error: Cannot find module 'import-local'
Le 14/07/2020 à 22:06, Xavier a écrit : > Le 28/06/2020 à 09:32, Xavier a écrit : >> Control: severity -1 grave >> >> Le 27/06/2020 à 23:31, Nilesh Patra a écrit : >>> >>> >>> On Sun, 28 Jun 2020, 02:45 Xavier, >> <mailto:y...@debian.org>> wrote: >>> >>> Control: severity -i grave >>> >>> >>> Thanks. >>> >>> >>> Le 24/06/2020 à 21:18, Nilesh Patra a écrit : >>> > Package: node-jest >>> > Severity: serious >>> > >>> > Dear Maintainer, >>> > >>> > Node-jest fails with the following on all the node-modules I've >>> tried yet. >>> > Sample examples on >>> >>> Work needed for node-jest: >>> * add babel-plugin-istanbul; proposition: add it in node-babel7 >>> >>> >>> It's good. >>> Would you mind discussing this bit on the list? >> >> pkg-js list receives messages related to this bug >> >>> * update and fix node-jsdom >>> * add missing components >>> >>> >>> Noted. >>> >>> >>> Here is the list of missing modules (mix of node-jest and node-jsdom): >> >> jsdom: >> * data-urls >> * domexception >> * html-encoding-sniffer >> * w3c-hr-time >> * whatwg-encoding >> * whatwg-mimetype >> * whatwg-url >> * xml-name-validator > > Hi all, > > after fixing node-jsdom, these modules are required for jest: > * astral-regex > * babel-plugin-istanbul > * babel-preset-current-node-syntax > * fast-json-stable-stringify > * is-generator-fn > * makeerror > * natural-compare > * p-each-series > * p-reduce > * sane > * string-length > * supports-hyperlinks > * terminal-link > * throat > * tmpl > * walker + import-local and realpath-native > I suggests to embed babel* in node-babel7 and others in node-jest. What > are your advises ? > -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] mathjax 3
Le 05/07/2020 à 02:01, Norbert Preining a écrit : > Dear Xavier, dear JS Team, > > we are currently preparing a new version of calibre which switched to > Mathjax3. > > I saw that there is some ongoing work in the git repo of mathjax to go > to version 3. Do you have any timeline about the update? > > At the moment we are pondering using the embedded copy of mathjax3 of > calibre, but would like to see the (not so) new version being packaged. > > If there is anything I can do to help, please let me know! > > All the best > > Norbert Hi Norbert, mathjax 3 is not yet ready but I'm going to take a look. Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#964880: Bug#964880: npm: test failures in ppc64el and s390x
Control: forcemerge -1 964854
Control: forwarded 964854 https://github.com/npm/cli/issues/1455
Le 11/07/2020 à 19:54, Gianfranco Costamagna a écrit :
> Source: npm
> Version: 6.14.6+ds-1
> Severity: serious
>
> Hello, looks like one test is failing on ppc64el and s390x.
> Could you please have a look?
>
> this on s390x
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/n/npm/20200711_092356_eb5fd@/log.gz
> # Subtest: test/tap/legacy-platform-all.js
> # Subtest: setup
> 1..0
> ok 1 - setup # time=2.926ms
>
> # Subtest: platform-all
> not ok 1 - no error messages
> ---
> found: >
> npm ERR! code EBADPLATFORM
>
> npm ERR! notsup Unsupported platform for
> npm-test-platform-all@9.9.9-9: wanted
>
> {"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
> (current: {"os":"linux","arch":"s390x"})
>
> npm ERR! notsup Valid OS:
> darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
>
> npm ERR! notsup Valid Arch: arm,arm64,mips,ia32,x64,sparc
>
> npm ERR! notsup Actual OS: linux
>
> npm ERR! notsup Actual Arch: s390x
>
>
> npm ERR! A complete log of this run can be found in:
>
> npm ERR!
>
> /tmp/autopkgtest.TwzxSV/autopkgtest_tmp/smokeh0DzIy/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_18_58_795Z-debug.log
> wanted: ''
> compare: ===
> at:
> line: 55
> column: 7
> file: test/tap/legacy-platform-all.js
> type: global
> function: installCheckAndTest
> stack: |
> installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
> f (/usr/lib/nodejs/once/once.js:25:25)
> ChildProcess. (test/common-tap.js:175:5)
> source: |
> t.is(stderr, '', 'no error messages')
> ...
>
> not ok 2 - install went ok
> ---
> found: 1
> wanted: 0
> compare: ===
> at:
> line: 56
> column: 7
> file: test/tap/legacy-platform-all.js
> type: global
> function: installCheckAndTest
> stack: |
> installCheckAndTest (test/tap/legacy-platform-all.js:56:7)
> f (/usr/lib/nodejs/once/once.js:25:25)
> ChildProcess. (test/common-tap.js:175:5)
> source: |
> t.is(code, 0, 'install went ok')
> ...
>
> 1..2
> # failed 2 of 2 tests
> not ok 2 - platform-all # time=767.548ms
>
> # Subtest: cleanup
> 1..0
> ok 3 - cleanup # time=1.651ms
>
> 1..3
> # failed 1 of 3 tests
> # time=782.166ms
> not ok 103 - test/tap/legacy-platform-all.js # time=1350.563ms
Adding s390x to supported arch list is not enough, see
https://github.com/npm/cli/issues/1455 issue for more on s390x
> and this on ppc64el
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/n/npm/20200711_093200_7007f@/log.gz
> # Subtest: test/tap/legacy-platform-all.js
> # Subtest: setup
> 1..0
> ok 1 - setup # time=4.916ms
>
> # Subtest: platform-all
> not ok 1 - no error messages
> ---
> found: >
> npm ERR! code EBADPLATFORM
>
> npm ERR! notsup Unsupported platform for
> npm-test-platform-all@9.9.9-9: wanted
>
> {"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
> (current: {"os":"linux","arch":"ppc64"})
>
> npm ERR! notsup Valid OS:
> darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
>
> npm ERR! notsup Valid Arch: arm,arm64,mips,ia32,x64,sparc
>
> npm ERR! notsup Actual OS: linux
>
> npm ERR! notsup Actual Arch: ppc64
>
>
> npm ERR! A complete log of this run can be found in:
>
> npm ERR!
>
> /tmp/autopkgtest.RvsIrP/autopkgtest_tmp/smokevhVLkX/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_24_22_560Z-debug.log
> wanted: ''
> compare: ===
> at:
> line: 55
> column: 7
> file: test/tap/legacy-platform-all.js
> type: global
> function: installCheckAndTest
> stack: |
> installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
> f (/usr/lib/nodejs/once/once.js:25:25)
>
[Pkg-javascript-devel] Bug#963539: Bug#963539: npm: autopkgtests failures on various architectures
Le 23/06/2020 à 12:01, Gianfranco Costamagna a écrit :
> Source: npm
> Version: 6.14.5+ds-1
> Severity: serious
>
> Hello, looks like npm is failing again its autopkgtests...
>
> On armhf there is a timeout that I "fixed" with:
> https://github.com/npm/cli/pull/1454
>
> on ppc64el there is another failure:
> https://ci.debian.net/data/autopkgtest/unstable/ppc64el/n/npm/6017343/log.gz
>
> and I also spot a s390x failure on Ubuntu:
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/n/npm/20200505_235736_15e60@/log.gz
>
> can you please have another look?
> (in the meanwhile I'm marking that test as flaky in Ubuntu)
>
> thanks!
Hi,
when trying to launch tests on a s390x machine, I got this kind of error:
Error: Failed to replace env in config: ${prefix}
at /home/yadd/cli-6.14.5/lib/config/core.js:415:13
at String.replace ()
at envReplace (/home/yadd/cli-6.14.5/lib/config/core.js:411:12)
at parseField (/home/yadd/cli-6.14.5/lib/config/core.js:389:7)
at /home/yadd/cli-6.14.5/lib/config/core.js:330:24
at Array.forEach ()
at Conf.add (/home/yadd/cli-6.14.5/lib/config/core.js:328:23)
at ConfigChain.addString
(/home/yadd/cli-6.14.5/node_modules/config-chain/index.js:244:8)
at Conf. (/home/yadd/cli-6.14.5/lib/config/core.js:316:10)
at /home/yadd/cli-6.14.5/node_modules/graceful-fs/graceful-fs.js:123:16
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#963628: Bug#963628: Node-jest fails with: Error: Cannot find module 'import-local'
Control: severity -i grave Le 24/06/2020 à 21:18, Nilesh Patra a écrit : > Package: node-jest > Severity: serious > > Dear Maintainer, > > Node-jest fails with the following on all the node-modules I've tried yet. > Sample examples on Work needed for node-jest: * add babel-plugin-istanbul; proposition: add it in node-babel7 * update and fix node-jsdom * add missing components Here is the list of missing modules (mix of node-jest and node-jsdom): * astral-regex * babel-plugin-istanbul * browser-process-hrtime * data-urls * domexception * es-abstract * fast-json-stable-stringify * html-encoding-sniffer * import-local * is-generator-fn * is-regex * left-pad * makeerror * natural-compare * nwsapi * object.getownpropertydescriptors * object-keys * parse5 * p-each-series * pn * p-reduce * realpath-native * request-promise-native * sane * string-length * symbol-tree * throat * tmpl * tr46 * util.promisify * w3c-hr-time * walker * whatwg-encoding * whatwg-mimetype * whatwg-url * xml-name-validator Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#963628: Bug#963628: Bug#963628: Node-jest fails with: Error: Cannot find module 'import-local'
Control: severity -1 grave Le 27/06/2020 à 23:31, Nilesh Patra a écrit : > > > On Sun, 28 Jun 2020, 02:45 Xavier, <mailto:y...@debian.org>> wrote: > > Control: severity -i grave > > > Thanks. > > > Le 24/06/2020 à 21:18, Nilesh Patra a écrit : > > Package: node-jest > > Severity: serious > > > > Dear Maintainer, > > > > Node-jest fails with the following on all the node-modules I've > tried yet. > > Sample examples on > > Work needed for node-jest: > * add babel-plugin-istanbul; proposition: add it in node-babel7 > > > It's good. > Would you mind discussing this bit on the list? pkg-js list receives messages related to this bug > * update and fix node-jsdom > * add missing components > > > Noted. > > > Here is the list of missing modules (mix of node-jest and node-jsdom): jsdom: * data-urls * domexception * html-encoding-sniffer * w3c-hr-time * whatwg-encoding * whatwg-mimetype * whatwg-url * xml-name-validator > * astral-regex > * babel-plugin-istanbul > * browser-process-hrtime > * data-urls > * domexception > * es-abstract > * fast-json-stable-stringify > * html-encoding-sniffer > * import-local > * is-generator-fn > * is-regex > * left-pad > * makeerror > * natural-compare > * nwsapi > * object.getownpropertydescriptors > * object-keys > * parse5 > * p-each-series > * pn > * p-reduce > * realpath-native > * request-promise-native > * sane > * string-length > * symbol-tree > * throat > * tmpl > * tr46 > * util.promisify > * w3c-hr-time > * walker > * whatwg-encoding > * whatwg-mimetype > * whatwg-url > * xml-name-validator > > > Would you have a rough idea as to how many of these can be simply > embedded - or do all of these need to be packaged NEW? > > For all new packages needed, > I would really like helping here :-) > > Kind Regards, > Nilesh > -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] babel 7.9.6 update
Le 06/06/2020 à 09:41, Xavier a écrit : > Le 05/06/2020 à 21:37, Xavier a écrit : >> Hi, >> >> node-rollup-plugin-babel tests are broken by babel 7.9.6 (autopkgtest >> only: no test during build to avoid circular deps). Here is the >> difference with `npm i` (given by my debug tools). It's the only one bug >> I found when trying to update babel. Could someone take a look? >> >> The error is: >> >> /usr/share/nodejs/yargs/yargs.js:1242 >> else throw err >> ^ >> TypeError: Cannot read property 'type' of null > > Update: > * test passed with a copy of some /usr/share/nodejs/@babel modules in >node_modules [2] (with a little patch [1]) > * when removing some of them (example with >@babel/helper-create-class-features-plugin), I got a similar but >different error: > > 1) rollup-plugin-babel >works with proposal-decorators (#18): > TypeError: Cannot read property 'type' of null > > Problem exists only with node-babel7 7.9.6, not with 7.4.5 > > There is nothing strange in test/**/.babelrc > > [1]: > https://salsa.debian.org/js-team/node-rollup-plugin-babel/-/blob/master/debian/patches/fix-test-for-babel-7.9.6.diff > > [2]: core helper-create-class-features-plugin > helper-create-regexp-features-plugin plugin-external-helpers > plugin-proposal-async-generator-functions plugin-proposal-decorators > plugin-proposal-nullish-coalescing-operator > plugin-proposal-object-rest-spread plugin-proposal-optional-chaining > plugin-proposal-unicode-property-regex > plugin-transform-async-to-generator > plugin-transform-block-scoped-functions plugin-transform-block-scoping > plugin-transform-classes plugin-transform-computed-properties > plugin-transform-destructuring plugin-transform-dotall-regex > plugin-transform-duplicate-keys plugin-transform-exponentiation-operator > plugin-transform-for-of plugin-transform-member-expression-literals > plugin-transform-modules-amd plugin-transform-modules-commonjs > plugin-transform-modules-systemjs plugin-transform-modules-umd > plugin-transform-named-capturing-groups-regex > plugin-transform-new-target plugin-transform-object-super > plugin-transform-parameters plugin-transform-property-literals > plugin-transform-reserved-words plugin-transform-runtime > plugin-transform-shorthand-properties plugin-transform-spread > plugin-transform-sticky-regex plugin-transform-template-literals > plugin-transform-typeof-symbol plugin-transform-unicode-regex preset-env Hi, After some tries, our babel 7.9.6 has the same behavior than `npm i` downloaded one. So I prepared a workaround: * use debian/nodejs/extcopies (with a little change in pkg-js-tools to avoid an error with babel 7.4.5 ; => pkg-js-tools_0.9.37) * add a little patch to be compatible with babel 7.9.6 error messages I'm ready to upload both node-rollup-plugin-babel and pkg-js-tools, waiting for eventual comments (all is pushed to salsa) -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] babel 7.9.6 update
Le 10/06/2020 à 13:22, Xavier a écrit : > Le 06/06/2020 à 09:41, Xavier a écrit : >> Le 05/06/2020 à 21:37, Xavier a écrit : >>> Hi, >>> >>> node-rollup-plugin-babel tests are broken by babel 7.9.6 (autopkgtest >>> only: no test during build to avoid circular deps). Here is the >>> difference with `npm i` (given by my debug tools). It's the only one bug >>> I found when trying to update babel. Could someone take a look? >>> >>> The error is: >>> >>> /usr/share/nodejs/yargs/yargs.js:1242 >>> else throw err >>> ^ >>> TypeError: Cannot read property 'type' of null >> >> Update: >> * test passed with a copy of some /usr/share/nodejs/@babel modules in >>node_modules [2] (with a little patch [1]) >> * when removing some of them (example with >>@babel/helper-create-class-features-plugin), I got a similar but >>different error: >> >> 1) rollup-plugin-babel >>works with proposal-decorators (#18): >> TypeError: Cannot read property 'type' of null >> >> Problem exists only with node-babel7 7.9.6, not with 7.4.5 >> >> There is nothing strange in test/**/.babelrc >> >> [1]: >> https://salsa.debian.org/js-team/node-rollup-plugin-babel/-/blob/master/debian/patches/fix-test-for-babel-7.9.6.diff >> >> [2]: core helper-create-class-features-plugin >> helper-create-regexp-features-plugin plugin-external-helpers >> plugin-proposal-async-generator-functions plugin-proposal-decorators >> plugin-proposal-nullish-coalescing-operator >> plugin-proposal-object-rest-spread plugin-proposal-optional-chaining >> plugin-proposal-unicode-property-regex >> plugin-transform-async-to-generator >> plugin-transform-block-scoped-functions plugin-transform-block-scoping >> plugin-transform-classes plugin-transform-computed-properties >> plugin-transform-destructuring plugin-transform-dotall-regex >> plugin-transform-duplicate-keys plugin-transform-exponentiation-operator >> plugin-transform-for-of plugin-transform-member-expression-literals >> plugin-transform-modules-amd plugin-transform-modules-commonjs >> plugin-transform-modules-systemjs plugin-transform-modules-umd >> plugin-transform-named-capturing-groups-regex >> plugin-transform-new-target plugin-transform-object-super >> plugin-transform-parameters plugin-transform-property-literals >> plugin-transform-reserved-words plugin-transform-runtime >> plugin-transform-shorthand-properties plugin-transform-spread >> plugin-transform-sticky-regex plugin-transform-template-literals >> plugin-transform-typeof-symbol plugin-transform-unicode-regex preset-env > > Hi, > > After some tries, our babel 7.9.6 has the same behavior than `npm i` > downloaded one. So I prepared a workaround: > * use debian/nodejs/extcopies (with a little change in pkg-js-tools to >avoid an error with babel 7.4.5 ; => pkg-js-tools_0.9.37) > * add a little patch to be compatible with babel 7.9.6 error messages > > I'm ready to upload both node-rollup-plugin-babel and pkg-js-tools, > waiting for eventual comments (all is pushed to salsa) And push node-babel7 7.9.6 of course -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] New autodep8/pkg-js-tools features
Fix (variable are extra_*, not pkg_nodejs_extra_*) Le 28/05/2020 à 17:48, Xavier a écrit : > Hi all, > > autodep8 0.23 permits to add some additional restrictions or additional > package in pkg-js-tools autopkgtest without having to set a manual > debian/tests/control > > Additional dependencies: for a package which has circular dependency, > you can > * remove test during build (and its dependencies) > * write test in debian/tests/pkg-js/test as usual > * write a debian/tests/autopkgtest-pkg-nodejs.conf with test >dependencies: > > extra_depends=node-tap,node-tape > >NB1: this will be concatenated with default dependencies: > "@, @builddeps@, pkg-js-autopkgtest >NB2: this additional dependencies will also be added to "require" > test (concatenated with "@, nodejs, pkg-js-autopkgtest" > > Additional restrictions: autopkgtest will disable network access except > if "needs-internet" is set. To add it (for npm, yarnpkg,...): > * write test in debian/tests/pkg-js/test as usual > * write a debian/tests/autopkgtest-pkg-nodejs.conf with >additional restrictions: > > extra_restrictions=needs-internet > >Default: > * require: superficial, skippable > * test : allow-stderr, skippable > > Other feature (not in autodep8 but in pkg-js-tools): if build and > autopkgtest tests differ, you can use debian/nodejs/test to overwrite > debian/tests/pkg-js/test during build -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] babel 7.9.6 update
Hi, node-rollup-plugin-babel tests are broken by babel 7.9.6 (autopkgtest only: no test during build to avoid circular deps). Here is the difference with `npm i` (given by my debug tools). It's the only one bug I found when trying to update babel. Could someone take a look? PACKAGE :DEB-VERSION => GOOD-VERSION @babel/core : 7.9.6 => 7.3.4 @babel/plugin-external-helpers : 7.8.3 => 7.0.0 @babel/plugin-proposal-async-generator-functions : 7.8.3 => 7.2.0 @babel/plugin-proposal-decorators: 7.8.3 => 7.0.0 @babel/plugin-proposal-object-rest-spread: 7.9.6 => 7.3.4 @babel/plugin-proposal-unicode-property-regex: 7.8.8 => 7.2.0 @babel/plugin-transform-async-to-generator : 7.8.3 => 7.3.4 @babel/plugin-transform-block-scoped-functions : 7.8.3 => 7.2.0 @babel/plugin-transform-block-scoping: 7.8.3 => 7.3.4 @babel/plugin-transform-classes : 7.9.5 => 7.3.4 @babel/plugin-transform-computed-properties : 7.8.3 => 7.2.0 @babel/plugin-transform-destructuring: 7.9.5 => 7.3.2 @babel/plugin-transform-dotall-regex : 7.8.3 => 7.2.0 @babel/plugin-transform-duplicate-keys : 7.8.3 => 7.2.0 @babel/plugin-transform-exponentiation-operator : 7.8.3 => 7.2.0 @babel/plugin-transform-for-of : 7.9.0 => 7.2.0 @babel/plugin-transform-modules-amd : 7.9.6 => 7.2.0 @babel/plugin-transform-modules-commonjs : 7.9.6 => 7.2.0 @babel/plugin-transform-modules-systemjs : 7.9.6 => 7.3.4 @babel/plugin-transform-modules-umd : 7.9.0 => 7.2.0 @babel/plugin-transform-named-capturing-groups-regex : 7.8.3 => 7.3.0 @babel/plugin-transform-new-target : 7.8.3 => 7.0.0 @babel/plugin-transform-object-super : 7.8.3 => 7.2.0 @babel/plugin-transform-parameters : 7.9.5 => 7.3.3 @babel/plugin-transform-runtime : 7.9.6 => 7.0.0 @babel/plugin-transform-shorthand-properties : 7.8.3 => 7.2.0 @babel/plugin-transform-spread : 7.8.3 => 7.2.2 @babel/plugin-transform-sticky-regex : 7.8.3 => 7.2.0 @babel/plugin-transform-template-literals: 7.8.3 => 7.2.0 @babel/plugin-transform-typeof-symbol: 7.8.4 => 7.2.0 @babel/plugin-transform-unicode-regex: 7.8.3 => 7.2.0 @babel/preset-env: 7.9.6 => 7.3.4 The error is: /usr/share/nodejs/yargs/yargs.js:1242 else throw err ^ TypeError: Cannot read property 'type' of null -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] babel 7.9.6 update
Le 05/06/2020 à 21:37, Xavier a écrit : > Hi, > > node-rollup-plugin-babel tests are broken by babel 7.9.6 (autopkgtest > only: no test during build to avoid circular deps). Here is the > difference with `npm i` (given by my debug tools). It's the only one bug > I found when trying to update babel. Could someone take a look? > > The error is: > > /usr/share/nodejs/yargs/yargs.js:1242 > else throw err > ^ > TypeError: Cannot read property 'type' of null Update: * test passed with a copy of some /usr/share/nodejs/@babel modules in node_modules [2] (with a little patch [1]) * when removing some of them (example with @babel/helper-create-class-features-plugin), I got a similar but different error: 1) rollup-plugin-babel works with proposal-decorators (#18): TypeError: Cannot read property 'type' of null Problem exists only with node-babel7 7.9.6, not with 7.4.5 There is nothing strange in test/**/.babelrc [1]: https://salsa.debian.org/js-team/node-rollup-plugin-babel/-/blob/master/debian/patches/fix-test-for-babel-7.9.6.diff [2]: core helper-create-class-features-plugin helper-create-regexp-features-plugin plugin-external-helpers plugin-proposal-async-generator-functions plugin-proposal-decorators plugin-proposal-nullish-coalescing-operator plugin-proposal-object-rest-spread plugin-proposal-optional-chaining plugin-proposal-unicode-property-regex plugin-transform-async-to-generator plugin-transform-block-scoped-functions plugin-transform-block-scoping plugin-transform-classes plugin-transform-computed-properties plugin-transform-destructuring plugin-transform-dotall-regex plugin-transform-duplicate-keys plugin-transform-exponentiation-operator plugin-transform-for-of plugin-transform-member-expression-literals plugin-transform-modules-amd plugin-transform-modules-commonjs plugin-transform-modules-systemjs plugin-transform-modules-umd plugin-transform-named-capturing-groups-regex plugin-transform-new-target plugin-transform-object-super plugin-transform-parameters plugin-transform-property-literals plugin-transform-reserved-words plugin-transform-runtime plugin-transform-shorthand-properties plugin-transform-spread plugin-transform-sticky-regex plugin-transform-template-literals plugin-transform-typeof-symbol plugin-transform-unicode-regex preset-env -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-babel 6 removal
Pirate Praveen wrote: > [...] >>> * node-yarnpkg >> >>I tried a lot of different options and plugins but it is still failing >> autopkgtest. I have asked Jishnu to have a look. If we can't fix it >> in some time, we should package 2.x (currently rc and supports babel >> 7). > This is now the only package blocking removal of node-babel 6. And the last blocking of babel 7.9.6 update is uglify-js. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#965173: Bug#965173: Bug#965173: Bug#965173: node-rollup-plugin-buble build depends on the babeljs provides that will not be in bullseye
Le 17/07/2020 à 12:15, Jonas Smedegaard a écrit :
> Quoting Pirate Praveen (2020-07-17 11:50:17)
>>
>>
>> On 2020, ജൂലൈ 17 12:12:09 PM IST, Adrian Bunk wrote:
>>> Source: node-rollup-plugin-buble
>>> Version: 0.19.8-2
>>> Severity: serious
>>> Tags: ftbfs
>>> Control: block 960748 by -1
>>>
>>> node-rollup-plugin-buble build depends on the babeljs provides
>>> that will not be in bullseye due to #960748.
>>
>> I think we should add Provides: babeljs to node-babel7.
>
> Only if it provides unversioned executable babeljs.
>
> That should probably be done using dh_installalternatives.
Alternative is already declared (node-babel provides /usr/bin/babeljs-6
and node-babel7 provides /usr/bin/babeljs-7 and both provides
alternatives to /usr/bin/babeljs), we just have to add "babeljs" in
"Provides" field. I suggests also to add "${nodejs:Provides}" to declare
all installed modules.
Cheers,
Xavier
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Comments regarding node-mermaid_8.4.8-1_amd64.changes
Le 16/07/2020 à 03:28, Sean Whitton a écrit : > Hello Nilesh, > > On Thu 16 Jul 2020 at 05:27AM +0530, Nilesh Patra wrote: > >> I'd admit this was a mistake on my part when this was first uploaded. >> I plan to remove this file, and use the archive's moment.js to minify once >> accepted - in the source-only-upload. > > Thank you for your reply. Couldn't you just upload a -2 with moment.js > removed to NEW? Hi, I just uploaded it. Many thanks ! -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Most team Lintian checks and tags now part of mainline
Le 14/07/2020 à 14:05, Felix Lechner a écrit : > Dear Javascript Team, > > Starting with Lintian's next release, most of your team's checks and > tags are part of our mainline program. The sole exception is the tag > inconsistency-debian-watch, which requires the network. > > Network functionality may appear in Lintian as an optional feature. At > that point, the remaining tag will be integrated. > > Details are available here: > > > https://salsa.debian.org/lintian/lintian/-/commit/8a665222f34f46d7d9c665b44610e3853cc761ef > > No more merge requests from our side. Plus, you will eventually see > your tags on lintian.d.o! > > Kind regards > Felix Lechner Thanks Felix, I'm going to remove lintian checks from pkg-js-tools (except "inconsistency-debian-watch" of course). Is there something to modify for this last tag? New install place? Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#965353: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined
Le 26/07/2020 à 18:54, Pirate Praveen a écrit : > > > On Sun, Jul 26, 2020 at 19:35, Adrian Bunk wrote: >> On Sun, Jul 26, 2020 at 09:55:47PM +0530, Pirate Praveen wrote: >>> I'm wondering if this will require another bootstraping cycle as >>> node-babel7 >>> autopkgtest is also broken and it depends on itself. >> >> If the problem is in node-lodash and gets fixed there, >> shouldn't this fix everything? > > I don't think the problem is in lodash as I can see babel upstream is > already using lodash 4.17.19 in their yarn.lock > https://github.com/babel/babel/blob/f7964a9ac51356f7df6404a25b27ba1cffba1ba7/yarn.lock#L7114 Hi, our lodash build does not provide the same result than npm package. > I think babel needs to use the same version of lodash it was built with > and a breaking change in lodash was released as a minor/patch > release/security release. > > I think it is becoming more and more common to break API during security > releases (we had to face this in rack/rails in ruby team). > > Babel build situation is indeed a mess. the problem is in lodash. > They are dicussing removing lodash from babel though see > https://github.com/babel/babel/pull/11789 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#963425: Bug#963425: node-terser: FTBFS: ERROR: `m` is not a supported option
Control: tags -1 + patch
Le 05/07/2020 à 16:47, Jonas Smedegaard a écrit :
> Control: reassign -1 node-commander 4.1.1-1
> Control: affects -1 uglifyjs.terser
>
> Quoting Lucas Nussbaum (2020-06-21 22:24:18)
>> Source: node-terser
>> Version: 4.1.2-6
>> Severity: serious
>> Justification: FTBFS on amd64
>> Tags: bullseye sid ftbfs
>> Usertags: ftbfs-20200620 ftbfs-bullseye
>>
>> Hi,
>>
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>
> Thanks, Lucas.
>
> These errors are caused by node-commander upgrade to new major release
> without proper testing reverse dependencies.
Hi,
it was tested but test reports just a warning and build succeeded
locally. Here is the fix (I can't push an MR since MR are disabled in
this salsa repo!). However I pushed a branch named commander-4 with this
patch:
--- a/bin/uglifyjs
+++ b/bin/uglifyjs
@@ -28,6 +28,15 @@
program.version(info.name + " " + info.version);
program.parseArgv = program.parse;
program.parse = undefined;
+var argv = [];
+process.argv.forEach(function(arg){
+ if(arg.match(/^-([pcmbode]+)$/)) {
+argv = argv.concat(RegExp.$1.split('').map(s => { return '-'+s }));
+ }
+ else argv.push(arg);
+});
+process.argv = argv;
+
if (process.argv.includes("ast")) program.helpInformation = describe_ast;
else if (process.argv.includes("options")) program.helpInformation =
function() {
var text = [];
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] dropping node-typescript-types
Le 11/01/2021 à 12:59, Xavier a écrit : > Le 11/01/2021 à 12:42, Jonas Smedegaard a écrit : >> Hi, >> >> Thanks, Xavier, for your work on deprecating node-typescript-types. >> >> I filed bugs #979761, #979762, #979763 against the 3 reverse dependencies. >> >> I have *not* filed a bug against this reverse suggestion: >> >> node-typescript >> >> I have *not* filed bugs against these reverse build-dependencies: > > Hi, > > thanks Jonas, I filed a "mass-bug" against other packages. I'm currently compiling nodejs to provide "node-types-node" -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#956423: Bullseye freeze is coming soon
Hi all, Bullseye freeze is coming and we still have problems with node-request removal. In particular, node-jsdom is not easy to patch. I tried a patch (not approved by upstream) but it needs a lot of unavailable Node.js modules. Looking at the following list, it seems that only node-jsdom is important to update, others have no important reverse dependencies AFAIK, haven't they? List of problems (from dak): # Broken Depends: node-jsdom: node-jsdom node-jsonld: node-jsonld node-matrix-js-sdk: node-matrix-js-sdk node-millstone: node-millstone node-yarnpkg: yarnpkg # Broken Build-Depends: node-client-sessions: node-request node-jsdom: node-request node-matrix-js-sdk: node-request node-opencv: node-request node-request-promise-core: node-request node-yarnpkg: node-request (>= 2.88.1-5~) -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] dropping node-typescript-types
Le 11/01/2021 à 12:42, Jonas Smedegaard a écrit : > Hi, > > Thanks, Xavier, for your work on deprecating node-typescript-types. > > I filed bugs #979761, #979762, #979763 against the 3 reverse dependencies. > > I have *not* filed a bug against this reverse suggestion: > > node-typescript > > I have *not* filed bugs against these reverse build-dependencies: Hi, thanks Jonas, I filed a "mass-bug" against other packages. Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#978127: Bug#978127: make it easy to specify autopkgtest restrictions in pkg-js-tools
Le 26/12/2020 à 10:45, Pirate Praveen a écrit : > Package: pkg-js-tools,node-css-loader > Severity: wishlist > > node-css-loader autopkgtest fails because of a deprecation warning in > stderr. In manual autopkgtest, we can easily add Restrictions: > allow-stderr, provide a way to pass this to autopkgtest-pkg-nodejs tests > too. Already done: see https://salsa.debian.org/js-team/pkg-js-tools/-/tree/master/doc/autopkgtest#additional-test-packages-or-test-restrictions -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#978127: Bug#978127: Bug#978127: make it easy to specify autopkgtest restrictions in pkg-js-tools
Le 26/12/2020 à 10:50, Xavier a écrit : > Le 26/12/2020 à 10:45, Pirate Praveen a écrit : >> Package: pkg-js-tools,node-css-loader >> Severity: wishlist >> >> node-css-loader autopkgtest fails because of a deprecation warning in >> stderr. In manual autopkgtest, we can easily add Restrictions: >> allow-stderr, provide a way to pass this to autopkgtest-pkg-nodejs tests >> too. > > Already done: see > https://salsa.debian.org/js-team/pkg-js-tools/-/tree/master/doc/autopkgtest#additional-test-packages-or-test-restrictions Note that allow-stderr is already set (try autodep8 is sourcedir). -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] [RFS] --- node-gulp-tsb
Le 07/01/2021 à 12:48, VIVEK K J a écrit : > Hi there, > > > I am created a debian package for gulp-tsb which is used as a gulp > plugin for very fast TypeScript compilation. I'm looking someone for > sponsoring the package... I'm filed a RFS bug also in debian BTS[1]. > This is a part of HedgeDoc packaging[2]. > > > Salsa Link - https://salsa.debian.org/vivekkj/node-gulp-tsb > > Regards, > Vivek K J Hi, please fix these things: * fix copyright years: 2014 instead of 2021 * add missing copyright entry for gulp-mocha/* (not same author) * debhelper-compat dependency version is too old (11). It should be 13 * unnecessary greater-than versioned dependency: node-ansi-colors (>= 1.0.1) * Missing "Rules-Requires-Root: no" * Remove dependency to nodejs * Add binary dependencies to "Build-Depends" (with "" if not used during build step)) * Fix missing dependencies to node-dargs, node-execa, node-plugin-error, node-through, node-typescript (build-dep or binary-dep ?) * Fix missing test dependencies: mocha * install gulp-mocha in the right place (set '*' in debian/nodejs/root_modules) You should build in a clean chroot (using sbuild/schroot) to avoid such problems. See https://wiki.debian.org/Javascript/Tutorial -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] New "ctype" option in uscan
Hi, I added a new feature in uscan to help uscan comparison when components are embedded, especially when "checksum" target is used: if "ctype" exists, uscan will use "version" value from package.json (JavaScript) or META.json (Perl) to get current component value. For now, only "nodejs" and "perl" values are accepted. This feature comes with devscripts 2.20.5. Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] typescript regression
Hi,
while trying to build node-rxjs, I noticed that after typescript update,
build fails with some:
src/internal/Subscription.ts(98,9): error TS2349: This expression is
not callable.
Each member of the union type '((arg: {} | T) => arg is T extends
readonly any[] ? unknown extends T ? never : readonly any[] : any[])
| ((x: any) => x is T[])' has signatures, but
Is there a known breaking thing between 4.0.5 and 4.1.2 ?
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#975362: Bug#975362: src:node-rollup-plugin-json: contains source-less wasm code
Le 20/11/2020 à 19:33, Jonas Smedegaard a écrit : > Package: src:node-rollup-plugin-json > Version: 4.1.0+~4.0.0-2 > Severity: serious > Justification: Policy 2.1 > > source contains compiled webassembly code from project wabt. > > A corresponding lintian override has the comment "Unused files", > but that's not ok: Used or not, all code must include source. Fixed, thanks. However you should also open a bug against lintian: if you consider that having unused wasm files in source is a RC bug, then lintian should not consider this as "pedantic". Ref: P source-contains-prebuilt-wasm-binary The source tarball contains a prebuilt binary wasm object. They are usually provided for the convenience of users. These files usually just take up space in the tarball and need to be rebuilt from source. Check if upstream also provides source-only tarballs that you can use as the upstream distribution instead. If not, you may want to ask upstream to provide source-only tarballs. List of packages that have wasm files in their sources: https://lintian.debian.org/tags/source-contains-prebuilt-wasm-binary.html -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#975794: FTBFS: Type 'undefined' is not assignable to type 'Duplex | Pick | Agent | PromiseLike'.
>> + tsc >> src/promisify.ts(27,15): error TS2345: Argument of type 'Duplex | >> Pick | Agent | undefined' is not assignable to >> parameter of type 'Duplex | Pick | Agent | >> PromiseLike'. >> Type 'undefined' is not assignable to type 'Duplex | Pick> "addRequest"> | Agent | PromiseLike'. >> dh_auto_build: error: cd ./agent-base && sh -ex >> ../debian/nodejs/agent-base/build returned exit code 2 >> make[1]: *** [debian/rules:15: override_dh_auto_build] Error 25 Same error than with node-rxjs: typescript update breaks many builds. Ref: https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#breaking-changes -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976331: [JS Policy] what to set in "Provides" field ?
Le 06/12/2020 à 02:14, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 21:19:48)
>> Le 03/12/2020 à 19:17, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-12-03 18:42:17)
>>>> Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit :
>>>>> Quoting Xavier (2020-12-03 17:33:18)
>>>>>> Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
>>>>>>> Quoting Xavier (2020-12-03 15:44:48)
>>>>>>>> Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
>>>>>>>>> Quoting Xavier (2020-12-03 14:35:25)
>>>>>>>>>> Le 03/12/2020 à 14:24, Xavier a écrit :
>>>>>>>>>>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
>>>>>>>>>>>> These source packages embed nodejs module
>>>>>>>>>>>> serialize-javascript without offering it as virtual binary
>>>>>>>>>>>> package:
>>>>>>>>>>>>
>>>>>>>>>>>> node-compression-webpack-plugin
>>>>>>>>>>>> node-copy-webpack-plugin
>>>>>>>>>>>> node-uglifyjs-webpack-plugin
>>>>>>>>>>>>
>>>>>>>>>>>> Please embed in only one source package provided as
>>>>>>>>>>>> versioned virtual package, and drop in other source
>>>>>>>>>>>> packages instead depending on the virtual package.
>>>>>>>>>>>>
>>>>>>>>>>>> Severity raised since the lack of virtual package blocks
>>>>>>>>>>>> upgrading node-terser.
>
> [,,,]
>
>>>>>>> I am pretty sure that hiding generally usable embedded code
>>>>>>> violates a "should" somewhere in Debian Policy.
>
> Here (as also mentioned elsewhere in the email thread):
> https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
>
>
>>>> If ftpmasters ask us to minimize package number by embedding
>>>> to-little-modules and if then we decide to publish them as
>>>> separated binary packages, I don't succeed to understand the
>>>> benefit. Then we should return back to previous policy: one source
>>>> = one package?
>>>
>>> My understanding is that ftpmasters dislike small *source* packages.
>>>
>>> Small source packages is a burden in *every* package tracking in
>>> Debian.
>>>
>>> Small binary packages is also a burden in *some* package tracking.
>>>
>>> Zero-size binary packages is also a burden in *some* package
>>> tracking, but I don't hear ftpmasters complain about task packages.
>>>
>>>
>>> This bug 976331 is *not* about repackaging embedded modules as
>>> separate *source* packages, but only about exposing embedded modules
>>> as *binary* packages - either virtual or real ones.
>>
>> That's part of what I misunderstood. So OK to do this here (after
>> ftpmaster rejection since you pushed node-serialize-javascript).
>>
>> But: I was able to upload a lot of packages this year because I
>> automatized many things. So splitting all mixed packages means
>> manually regenerating debian/control, debian/rules,
>> debian/*.install,... This means less uploads, more obsolescence and
>> then less security (and also less interest in doing such manual
>> stuff).
>
> Great that you develop tools to maintain packages more efficiently and
> more automated. If done in compliance with Debian Policy, that is.
>
> Do you say that it is not possible to automate packaging with embedded
> modules provided as virtual or real packages? Why do you think you can
> only develop efficient automating routines with hidden modules?
Pkg-js-tools already automates virtual package. There are 2 configuration:
* components not declared in debian/nodejs/root_modules: installed in a
subdirectory and not "provides"
* components listed in debian/nodejs/root_modules: installed in main
nodejs directory and added in ${nodejs:Provides}
So when a pkg-js-tools package does not export components, just to
insert '*' in debian/nodejs/root_modules and add a "Provides:
${nodejs:Provides}"
> Here is a concrete example of a minimal (manual) that I propose to do
> for one of the three packages involved in this bugreport (and then have
> the other 2 packages drop the embedded module ans instead depend on th
[Pkg-javascript-devel] New pkg-js-tools tool
Hi all, I prepared a little tool to parse npm registry. It displays: * Debian dependencies (using `apt-file search` for now) * missing modules (recursively) Do you think it is useful ? A little example to see output: $ pkgjs-depends ava DEPENDENCIES: node-ansi-styles node-anymatch node-arrify node-boxen node-chalk node-chokidar node-ci-info [...] MISSING: ava └── @concordance/react (2.0.0) └── arrgv (1.0.2) └── chunkd (2.0.1) └── ci-parallel-vars (1.0.1) └── code-excerpt (3.0.0) └── convert-to-spaces (1.0.2) └── common-path-prefix (3.0.0) └── concordance (5.0.1) └── fast-diff (1.2.0) └── js-string-escape (1.0.1) └── well-known-symbols (2.0.0) └── equal-length (1.0.1) └── figures (3.2.0) └── is-error (2.2.2) └── ora (5.1.0) └── is-interactive (1.0.0) └── log-symbols (4.0.0) └── wcwidth (1.0.1) └── p-event (4.2.0) └── pkg-conf (3.1.0) └── supertap (1.0.0) └── serialize-error (2.1.0) └── temp-dir (2.0.0) └── trim-off-newlines (1.0.1) └── update-notifier (4.1.3) └── has-yarn (2.1.0) └── is-installed-globally (0.3.2) └── global-dirs (2.0.1) └── is-yarn-global (0.3.0) └── pupa (2.1.1) └── escape-goat (2.1.1) -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976331: Bug#976331: Bug#976331: Bug#976331: node-compression-webpack-plugin, node-copy-webpack-plugin, node-uglifyjs-webpack-plugin: contains hidden embedded nodejs module s
Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 14:35:25)
>> Le 03/12/2020 à 14:24, Xavier a écrit :
>>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
>>>> These source packages embed nodejs module serialize-javascript
>>>> without offering it as virtual binary package:
>>>>
>>>> node-compression-webpack-plugin
>>>> node-copy-webpack-plugin
>>>> node-uglifyjs-webpack-plugin
>>>>
>>>> Please embed in only one source package provided as versioned
>>>> virtual package, and drop in other source packages instead
>>>> depending on the virtual package.
>>>>
>>>> Severity raised since the lack of virtual package blocks upgrading
>>>> node-terser.
>
> [...]
>
>>> for now, dh-sequence-nodejs adds a "Provides" item for modules
>>> installed in root nodejs directories. Do we want to declare a
>>> "node-foo" for submodules (installed in a /node_modules
>>> directory) ?
>
> Whatever that tool does, the resulting package should declare Provides:
> for each embedded Nodejs module, properly versioned with the module's
> own version as first segment then "~" then source package version.
>
> I cannot see a reason for *any* embedded Nodejs module to stay hidden,
> but if someone comes up with some exceptional cases for that, then the
> reasoning should be explicitly documented in either README.source or
> README.Debian (and possibly in long description too).
I chose that because such modules are not directly usable using a
`require("foo")`, but I can change
>> Note that the future lintian database (classification tags) will
>> permit to see node modules everywhere.
>
> Everywhere?
Sorry, I miss some explanations: lintian parses all files and emit a tag
each time it finds a node_module/foo/package.json or
/foo/package.json or https://lintian.debian.org/tags/nodejs-module-not-declared.html : it
shows node module installed in nodejs main dirs (not in node_modules/
for now).
If we decide to change this ~policy, nodejs-module-not-declared should
also be updated.
But in this case, we will have some not-directly-usable node-* virtual
packages.
> I should be able to declare this in some other package:
>
>Build-Depend: node-serialize-javascript (>= 5)
>
> That is not possible today, because no packages provide that name
> (despite 3 packages containing some version of it).
>
> That will be possible if tommorrow one of those packages adds this:
>
> Provides: node-serialize-javascript (= 5.0.1)
>
> That will *not* be possible, however, if tommorrow dh-sequence-nodejs
> automatically adds this for all three packages:
>
> Provides: $embeddedmodule (= ${embeddedmodule:Version})
It does (see our discussion about acorn) but only for main installed
modules (and if DD didn't omit ${nodejs:Provides} of course)
> ...because then it is not deterministic which of them has priority.
>
> - Jonas
Cheers,
Xavier
NB: maybe I misunderstood part of your explanations and then my
explanations are perhaps out of subject
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976331: Bug#976331: Bug#976331: node-compression-webpack-plugin, node-copy-webpack-plugin, node-uglifyjs-webpack-plugin: contains hidden embedded nodejs module serialize-jav
Le 03/12/2020 à 14:24, Xavier a écrit : > Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit : >> Package: > node-compression-webpack-plugin,node-copy-webpack-plugin,node-uglifyjs-webpack-plugin >> Severity: important >> >> These source packages embed nodejs module serialize-javascript >> without offering it as virtual binary package: >> >> node-compression-webpack-plugin >> node-copy-webpack-plugin >> node-uglifyjs-webpack-plugin >> >> Please embed in only one source package provided as versioned virtual >> package, >> and drop in other source packages instead depending on the virtual package. >> >> Severity raised since the lack of virtual package blocks upgrading >> node-terser. >> >> - Jonas > > Hi, > > for now, dh-sequence-nodejs adds a "Provides" item for modules installed > in root nodejs directories. Do we want to declare a "node-foo" for > submodules (installed in a /node_modules directory) ? > > Cheers, > Xavier Note that the future lintian database (classification tags) will permit to see node modules everywhere. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976331: Bug#976331: node-compression-webpack-plugin, node-copy-webpack-plugin, node-uglifyjs-webpack-plugin: contains hidden embedded nodejs module serialize-javascript
Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit : > Package: node-compression-webpack-plugin,node-copy-webpack-plugin,node-uglifyjs-webpack-plugin > Severity: important > > These source packages embed nodejs module serialize-javascript > without offering it as virtual binary package: > > node-compression-webpack-plugin > node-copy-webpack-plugin > node-uglifyjs-webpack-plugin > > Please embed in only one source package provided as versioned virtual package, > and drop in other source packages instead depending on the virtual package. > > Severity raised since the lack of virtual package blocks upgrading > node-terser. > > - Jonas Hi, for now, dh-sequence-nodejs adds a "Provides" item for modules installed in root nodejs directories. Do we want to declare a "node-foo" for submodules (installed in a /node_modules directory) ? Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#974587: node-uuid: Bad "exports" field?
Le Lundi, Décembre 07, 2020 13:55 CET, Pirate Praveen
a écrit:
> On Thu, 12 Nov 2020 16:25:14 +0100 Xavier Guimard
> wrote:
> > node-uuid breaks dependent package with error like:
> >
> > Package subpath './v1' is not defined by "exports" in
> /usr/share/nodejs/uuid/package.json
> >
> > (same error with any of v{1,2,3,4}.js)
>
> I have seen similar error in gitlab as well. Can you share which
> package showed this error for you?
>
> I suspect this is caused when a package is expecting an older version
> of uuid, for example node-copy-webpack-plugin, which expects uuid 3.x.
>
>
>
>
I suspect uuid itself, even following doc, i've some errors.
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976331: Bug#976331: Bug#976331: [JS Policy] what to set in "Provides" field ?
Le 03/12/2020 à 19:17, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 18:42:17)
>> Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-12-03 17:33:18)
>>>> Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
>>>>> Quoting Xavier (2020-12-03 15:44:48)
>>>>>> Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
>>>>>>> Quoting Xavier (2020-12-03 14:35:25)
>>>>>>>> Le 03/12/2020 à 14:24, Xavier a écrit :
>>>>>>>>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
>>>>>>>>>> These source packages embed nodejs module serialize-javascript
>>>>>>>>>> without offering it as virtual binary package:
>>>>>>>>>>
>>>>>>>>>> node-compression-webpack-plugin
>>>>>>>>>> node-copy-webpack-plugin
>>>>>>>>>> node-uglifyjs-webpack-plugin
>>>>>>>>>>
>>>>>>>>>> Please embed in only one source package provided as versioned
>>>>>>>>>> virtual package, and drop in other source packages instead
>>>>>>>>>> depending on the virtual package.
>>>>>>>>>>
>>>>>>>>>> Severity raised since the lack of virtual package blocks upgrading
>>>>>>>>>> node-terser.
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>>> for now, dh-sequence-nodejs adds a "Provides" item for modules
>>>>>>>>> installed in root nodejs directories. Do we want to declare a
>>>>>>>>> "node-foo" for submodules (installed in a /node_modules
>>>>>>>>> directory) ?
>>>>>>>
>>>>>>> Whatever that tool does, the resulting package should declare
>>>>>>> Provides: for each embedded Nodejs module, properly versioned with
>>>>>>> the module's own version as first segment then "~" then source
>>>>>>> package version.
>>>>>>>
>>>>>>> I cannot see a reason for *any* embedded Nodejs module to stay
>>>>>>> hidden, but if someone comes up with some exceptional cases for
>>>>>>> that, then the reasoning should be explicitly documented in either
>>>>>>> README.source or README.Debian (and possibly in long description
>>>>>>> too).
>>>>>>
>>>>>> I chose that because such modules are not directly usable using a
>>>>>> `require("foo")`, but I can change
>>>>>
>>>>> I am less interested in why historically some pattern was chosen.
>>>>>
>>>>> My interest is in what pattern to use going forward.
>>>>>
>>>>> Code in package have dependencies on code in other packages.
>>>>>
>>>>> We need to be able to declare dependencies between pieces of code.
>>>>>
>>>>> For JavaScript, code is grouped as "Nodejs modules".
>>>>>
>>>>> A a concrete example, Nodejs module rollup-plugin-terser depends on
>>>>> Nodejs module serialize-javascript.
>>>>>
>>>>> Going forward (regardless of why historically some other pattern was
>>>>> chosen), Debian package node-rollup-plugin-terser needs to be able to
>>>>> express a build-dependency on Debian package providing the Nodejs module
>>>>> serialize-javascript.
>>>>>
>>>>>
>>>>>>>> Note that the future lintian database (classification tags) will
>>>>>>>> permit to see node modules everywhere.
>>>>>>>
>>>>>>> Everywhere?
>>>>>>
>>>>>> Sorry, I miss some explanations: lintian parses all files and emit a tag
>>>>>> each time it finds a node_module/foo/package.json or
>>>>>> /foo/package.json or >>>>> able to see nodejs embedded module in all Debian packages.
>>>>>
>>>>> Lintian can help check if a package is valid.
>>>>>
>>>>> Lintian cannot make a package declare as virtual Debian packages the
>>>>> Nodejs modules it has embedded.
>>>>>
>>>>>
&
[Pkg-javascript-devel] Bug#976331: [JS Policy] what to set in "Provides" field ?
Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 15:44:48)
>> Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-12-03 14:35:25)
>>>> Le 03/12/2020 à 14:24, Xavier a écrit :
>>>>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
>>>>>> These source packages embed nodejs module serialize-javascript
>>>>>> without offering it as virtual binary package:
>>>>>>
>>>>>> node-compression-webpack-plugin
>>>>>> node-copy-webpack-plugin
>>>>>> node-uglifyjs-webpack-plugin
>>>>>>
>>>>>> Please embed in only one source package provided as versioned
>>>>>> virtual package, and drop in other source packages instead
>>>>>> depending on the virtual package.
>>>>>>
>>>>>> Severity raised since the lack of virtual package blocks upgrading
>>>>>> node-terser.
>>>
>>> [...]
>>>
>>>>> for now, dh-sequence-nodejs adds a "Provides" item for modules
>>>>> installed in root nodejs directories. Do we want to declare a
>>>>> "node-foo" for submodules (installed in a /node_modules
>>>>> directory) ?
>>>
>>> Whatever that tool does, the resulting package should declare
>>> Provides: for each embedded Nodejs module, properly versioned with
>>> the module's own version as first segment then "~" then source
>>> package version.
>>>
>>> I cannot see a reason for *any* embedded Nodejs module to stay
>>> hidden, but if someone comes up with some exceptional cases for
>>> that, then the reasoning should be explicitly documented in either
>>> README.source or README.Debian (and possibly in long description
>>> too).
>>
>> I chose that because such modules are not directly usable using a
>> `require("foo")`, but I can change
>
> I am less interested in why historically some pattern was chosen.
>
> My interest is in what pattern to use going forward.
>
> Code in package have dependencies on code in other packages.
>
> We need to be able to declare dependencies between pieces of code.
>
> For JavaScript, code is grouped as "Nodejs modules".
>
> A a concrete example, Nodejs module rollup-plugin-terser depends on
> Nodejs module serialize-javascript.
>
> Going forward (regardless of why historically some other pattern was
> chosen), Debian package node-rollup-plugin-terser needs to be able to
> express a build-dependency on Debian package providing the Nodejs module
> serialize-javascript.
>
>
>>>> Note that the future lintian database (classification tags) will
>>>> permit to see node modules everywhere.
>>>
>>> Everywhere?
>>
>> Sorry, I miss some explanations: lintian parses all files and emit a tag
>> each time it finds a node_module/foo/package.json or
>> /foo/package.json or > able to see nodejs embedded module in all Debian packages.
>
> Lintian can help check if a package is valid.
>
> Lintian cannot make a package declare as virtual Debian packages the
> Nodejs modules it has embedded.
>
>
>> NB2, you can also take a look at
>> https://lintian.debian.org/tags/nodejs-module-not-declared.html : it
>> shows node module installed in nodejs main dirs (not in node_modules/
>> for now).
>
> A web page (generated by lintian or written any other way) cannot make a
> package declare as virtual Debian packages the Nodejs modules it has
> embedded.
>
>
>> If we decide to change this ~policy, nodejs-module-not-declared should
>> also be updated.
>
> I am pretty sure that hiding generally usable embedded code violates a
> "should" somewhere in Debian Policy.
If so, lintian should reports "error", not info/warning when a JS lib is
embedded. Ftpmasters didn't reject such packages (see jquery copies for
example).
> Therefore, if Debian JavaScript Policy says that generally useful
> modules should be *hidden* instead of provided as virtual packages, then
> I consider Debian JavaScript Policy broken.
>
>> But in this case, we will have some not-directly-usable node-* virtual
>> packages.
>
> Why not-directly-usable?
>
> Obviously we should not _only_ declare "Provides:" but also make sure
> that the code is actually placed in the correct location below
> /usr/share/nodejs and check testsuite and establish autopkgtest and all
> the other thi
[Pkg-javascript-devel] Bug#976341: node-jest: please provide real (not virtual) package node-jest-worker
Control: tags -1 + confirmed Le 03/12/2020 à 18:07, Jonas Smedegaard a écrit : > Source: node-jest > Version: 26.6.3+ds+~cs64.28.30-1 > Severity: normal > > node-rollup-plugin-terser has a runtime dependency on node-jest-worker. > > Currently node-jest-worker is provided as a virtual package by jest. > Problem with that is the size of the dependency tree... > > rollup+node-rollup-plugin-terser+jest: 334 pkgs / 182 MB > > rollup+node-rollup-plugin-terser+node-jest-worker: 136 pkgs / 107 MB > > I.e. the size is approximately half with node-jest-worker separate from jest. > > > Please provide real (not virtual) package node-jest-worker, > and have jest depend on or recommend that, as appropriate. > > > - Jonas > > Hint: Introducing a new package causes a visit the the NEW queue, > which potentially can require some time for processing. To avoid > such waiting time stalling other development of the jest package > it can be beneficial to first mae a release to experimental > (where it can linger while other releases are made to unstable). According to https://people.debian.org/~yadd/jest-spaghetti-dish.png this makes sense. Do you see some other jest parts that should be separated? Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976331: Bug#976331: [JS Policy] what to set in "Provides" field ?
Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 17:33:18)
>> Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-12-03 15:44:48)
>>>> Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
>>>>> Quoting Xavier (2020-12-03 14:35:25)
>>>>>> Le 03/12/2020 à 14:24, Xavier a écrit :
>>>>>>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
>>>>>>>> These source packages embed nodejs module serialize-javascript
>>>>>>>> without offering it as virtual binary package:
>>>>>>>>
>>>>>>>> node-compression-webpack-plugin
>>>>>>>> node-copy-webpack-plugin
>>>>>>>> node-uglifyjs-webpack-plugin
>>>>>>>>
>>>>>>>> Please embed in only one source package provided as versioned
>>>>>>>> virtual package, and drop in other source packages instead
>>>>>>>> depending on the virtual package.
>>>>>>>>
>>>>>>>> Severity raised since the lack of virtual package blocks upgrading
>>>>>>>> node-terser.
>>>>>
>>>>> [...]
>>>>>
>>>>>>> for now, dh-sequence-nodejs adds a "Provides" item for modules
>>>>>>> installed in root nodejs directories. Do we want to declare a
>>>>>>> "node-foo" for submodules (installed in a /node_modules
>>>>>>> directory) ?
>>>>>
>>>>> Whatever that tool does, the resulting package should declare
>>>>> Provides: for each embedded Nodejs module, properly versioned with
>>>>> the module's own version as first segment then "~" then source
>>>>> package version.
>>>>>
>>>>> I cannot see a reason for *any* embedded Nodejs module to stay
>>>>> hidden, but if someone comes up with some exceptional cases for
>>>>> that, then the reasoning should be explicitly documented in either
>>>>> README.source or README.Debian (and possibly in long description
>>>>> too).
>>>>
>>>> I chose that because such modules are not directly usable using a
>>>> `require("foo")`, but I can change
>>>
>>> I am less interested in why historically some pattern was chosen.
>>>
>>> My interest is in what pattern to use going forward.
>>>
>>> Code in package have dependencies on code in other packages.
>>>
>>> We need to be able to declare dependencies between pieces of code.
>>>
>>> For JavaScript, code is grouped as "Nodejs modules".
>>>
>>> A a concrete example, Nodejs module rollup-plugin-terser depends on
>>> Nodejs module serialize-javascript.
>>>
>>> Going forward (regardless of why historically some other pattern was
>>> chosen), Debian package node-rollup-plugin-terser needs to be able to
>>> express a build-dependency on Debian package providing the Nodejs module
>>> serialize-javascript.
>>>
>>>
>>>>>> Note that the future lintian database (classification tags) will
>>>>>> permit to see node modules everywhere.
>>>>>
>>>>> Everywhere?
>>>>
>>>> Sorry, I miss some explanations: lintian parses all files and emit a tag
>>>> each time it finds a node_module/foo/package.json or
>>>> /foo/package.json or >>> able to see nodejs embedded module in all Debian packages.
>>>
>>> Lintian can help check if a package is valid.
>>>
>>> Lintian cannot make a package declare as virtual Debian packages the
>>> Nodejs modules it has embedded.
>>>
>>>
>>>> NB2, you can also take a look at
>>>> https://lintian.debian.org/tags/nodejs-module-not-declared.html : it
>>>> shows node module installed in nodejs main dirs (not in node_modules/
>>>> for now).
>>>
>>> A web page (generated by lintian or written any other way) cannot make a
>>> package declare as virtual Debian packages the Nodejs modules it has
>>> embedded.
>>>
>>>
>>>> If we decide to change this ~policy, nodejs-module-not-declared should
>>>> also be updated.
>>>
>>> I am pretty sure that hiding generally usable embedded code violates a
>>>
Re: [Pkg-javascript-devel] Nodejs little module policy
Le 04/12/2020 à 22:10, Joerg Jaspert a écrit : > On 15972 March 1977, Xavier wrote: > >> Following a JS discussion (#976341), I proposed a new node-jest in NEW >> queue that splits it into multiple binary packages. > > I've seen that and skipped on the package initially. > >> We decided to embed little Node.js modules to reduce source packages >> number and then avoid having very little packages. My split generates >> some medium/little binary packages (and one big) with one source. Is it >> an acceptable way for you? > >> I did that because some components embedded in Jest are needed by other >> packages, but jest is a big package. This way reduces dependency size >> for "normal" packages (jest is generally a test dependency, not a binary >> one except for some other test tools, but some of its components are >> real dependencies). > > Does it need to be split in so many? It seems excessive. > I can somewhat follow the reasoning in the bug to strip down on > installed size of dependencies, but then a bunch of your packages doesnt > seem to have any dependency, and tiny packages. > How about a split into something like jest / the modules? Or maybe jest > / modules-light / modules-heavy (light/heavy in lots/no dependencies). Hi, Thanks, I reduced the list (and repushed jest): * jest * node-jest-worker * node-jest-debbundle (all little components with common dependencies) Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976409: glibc breaks node-iconv autopkgtest: AssertionError [ERR_ASSERTION]: Missing expected exception
Control: tags -1 + ftbfs Le 04/12/2020 à 20:46, Paul Gevers a écrit : > Source: glibc, node-iconv > Control: found -1 glibc/2.31-5 > Control: found -1 node-iconv/2.3.5-4 > Severity: serious > Tags: sid bullseye > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of glibc the autopkgtest of node-iconv fails in > testing on all architectures when that autopkgtest is run with the > binary packages of glibc from unstable. It passes when run with only > packages from testing. In tabular form: > >passfail > glibc from testing2.31-5 > node-iconv from testing2.3.5-4 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of glibc to testing > [1]. Due to the nature of this issue, I filed this bug report against > both packages. Can you please investigate the situation and reassign the > bug to the right package? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul Hi, I rebuild node-iconv (nocheck) and rebuild/autopkgtest reverse dependencies of node-iconv, all passed: * rebuild: node-body-parser, node-encoding, node-expat, node-iconv-lite, node-raw-body * autopkgtest: node-body-parser, node-d3-dsv, node-raw-body So maybe we can just ignore 2 failing tests for now (a "should throw" which doesn't throw). NB: I tried also with node-iconv 3.0.0, same problem in test. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976607: Bug#976607: node-cheerio: please package (much!) newer release 1.0rc3
Control: tags -1 + pending Le 05/12/2020 à 19:19, Jonas Smedegaard a écrit : > Package: node-cheerio > Version: 0.22.0-2 > Severity: normal > > Hi, > > Thanks for packaging Cheerio. > > Currently packaged release is the latest upstream stable release, > but was released 4 years ago . 1.0rc1 was released 3.5 years ago > and 1.0rc3 was released 1.5 years ago. > > Please consider updating to 1.0rc3 (in preparation for 1.0rc4 > which might soon be released, judging from issue tracker chatter). > > Concretely, 1.0rc3 is needed for matrix-hydrogen that I am preparing, > but I notice that it is also preferred for node-dom-serializer > (even for the outdated 0.2.2 that we carry in Debian), > and some issue tracker chatter seems to indicate that there are also > security bugs fixed along the way of those 4 years of progress. > > Raising severity from wishlist to normal due to possible security risk. > > - Jonas You're absolutely right, built and pushed ;-) -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976618: Bug#976618: Bug#976618: node-cosmiconfig, jest: embedded module tied to large (build-)dependency tree
Le 05/12/2020 à 22:48, Jonas Smedegaard a écrit : > Quoting Xavier (2020-12-05 22:34:06) >> Le 05/12/2020 à 22:22, Jonas Smedegaard a écrit : >>> Package: node-cosmiconfig,jest >>> Severity: normal >>> >>> Both node-cosmiconfig and jest embed Nodejs module callsites. >>> >>> jest provides it as virtual package node-callsites, >>> but jest has a much larger (build-dependency tree. >>> >>> Please consider shifting to provide node-callsites from node-cosmiconfig. >>> >>> - Jonas >> >> Following #976341, callsites is now (will be after ftpmaster review) in >> node-jest-debbundle which is small > > Yes, small _dependency_ tree - which is certainly an improvement. > > It still has a large _build-dependency_ tree, however - which means > there is a higher risk of accidentally crating circular > build-dependencies which is a pain foor bootstrapping new architectures, > and there is a higher risk that anything either depending or > build-depending on node-callsites gets entangled in transitions or even > risk getting kicked out of testing. > > Even if node-cosmiconfig would need jest for checking build-time tests > it would still be helpful to shift: Those bootstrapping would disable > test-only build-dependencies (assuming they were correctly annotated > with ). > > Therefore I still suggest to consider shifting which _source_ package > contain the embedded modules. > > > Or do you thing I have missed something? Wait for jest acceptance, node-jest-debbundle has not a lot of dependencies -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#974648: Bug#974648: Bug#974648: Please really ship TypeScript definitions
Le 04/12/2020 à 14:47, Xavier a écrit : > Le 13/11/2020 à 12:04, Xavier a écrit : >> Le 13/11/2020 à 11:26, Julien Puydt a écrit : >>> Package: jest >>> Version: 26.6.3+ds+~cs64.27.30-1 >>> >>> The file /usr/share/nodejs/package.json says the TypeScript definitions >>> are available in build/jest.d.ts, but the package doesn't contain that >>> file : the build/ directory only has jest.js. >> >> Hi, >> >> this needs a lot of @types/ in other packages (chalk, yargs-parser,...). >> For now I disabled `node script/buildTs.js` in debian/rules. >> >> I'm going to try to fix this. > > Hi, > > good news: I'll be able to build ts definitions > bad news : not with typescript 4.1.x for now... > > Cheers, > Xavier Missing types needed: @types/co @types/color-name @types/convert-source-map @types/dedent @types/exit @types/fb-watchman @types/is-ci @types/istanbul-lib-instrument @types/istanbul-lib-source-maps @types/merge-stream @types/natural-compare @types/node-notifier @types/prettier @types/prompts @types/prop-types @types/resolve @types/sane @types/source-map-support @types/supports-color @types/weak-napi @types/write-file-atomic @types/yargs-parser -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976618: Bug#976618: node-cosmiconfig, jest: embedded module tied to large (build-)dependency tree
Le 05/12/2020 à 22:22, Jonas Smedegaard a écrit : > Package: node-cosmiconfig,jest > Severity: normal > > Both node-cosmiconfig and jest embed Nodejs module callsites. > > jest provides it as virtual package node-callsites, > but jest has a much larger (build-dependency tree. > > Please consider shifting to provide node-callsites from node-cosmiconfig. > > - Jonas Following #976341, callsites is now (will be after ftpmaster review) in node-jest-debbundle which is small -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976618: Bug#976618: Bug#976618: node-cosmiconfig, jest: embedded module tied to large (build-)dependency tree
Le 05/12/2020 à 22:48, Jonas Smedegaard a écrit : > Quoting Xavier (2020-12-05 22:34:06) >> Le 05/12/2020 à 22:22, Jonas Smedegaard a écrit : >>> Package: node-cosmiconfig,jest >>> Severity: normal >>> >>> Both node-cosmiconfig and jest embed Nodejs module callsites. >>> >>> jest provides it as virtual package node-callsites, >>> but jest has a much larger (build-dependency tree. >>> >>> Please consider shifting to provide node-callsites from node-cosmiconfig. >>> >>> - Jonas >> >> Following #976341, callsites is now (will be after ftpmaster review) in >> node-jest-debbundle which is small > > Yes, small _dependency_ tree - which is certainly an improvement. > > It still has a large _build-dependency_ tree, however - which means > there is a higher risk of accidentally crating circular > build-dependencies which is a pain foor bootstrapping new architectures, > and there is a higher risk that anything either depending or > build-depending on node-callsites gets entangled in transitions or even > risk getting kicked out of testing. > > Even if node-cosmiconfig would need jest for checking build-time tests > it would still be helpful to shift: Those bootstrapping would disable > test-only build-dependencies (assuming they were correctly annotated > with ). > > Therefore I still suggest to consider shifting which _source_ package > contain the embedded modules. > > > Or do you thing I have missed something? Ok, let's do this. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Ask to do some quick maintenance on jquery-timepicker
Le 09/12/2020 à 01:39, William Desportes a écrit : > Hi, > > I would like to ask to do some quick maintenance on jquery-timepicker > package. Hi, what is your salsa account ? > We use the library jquery-timepicker at phpMyAdmin, and to use this > package I need the latest version to be up to date into Debian. > The last upstream commit was to abandon the lib [1] and previous > upstream commits are from 2016. > v1.6.3 is the latest version and 1.2 is the Debian version. This package > seems abandoned. > > Most commits are from https://trentrichardson.com/ (cc'ed here) but I > could not find any trace of a potential account in Debian. > > Please give me an access and I will manage to clean things up. > That said having someone to review my changes would be awesome (I mostly > do PHP packaging for now). > > Salsa link: https://salsa.debian.org/js-team/jquery-timepicker > Will close: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841093 > > P.S.: I am not on the mailing list, a cc to reply would be necessary. > > [1] > https://github.com/trentrichardson/jQuery-Timepicker-Addon/commit/7160ce59c660462f4d3379951f1e141131bcb02c > > > Thank you for reading, > William Desportes > > -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976813: Bug#976813: Bug#976813: node-cosmiconfig: missing Breaks+Replaces: jest (<< 26.6.3+repack)
Le 08/12/2020 à 10:04, Jonas Smedegaard a écrit : > Quoting Xavier (2020-12-08 09:44:00) >> Le 08/12/2020 à 09:37, Andreas Beckmann a écrit : >>> Package: node-cosmiconfig >>> Version: 7.0.0+~cs8.3.2-1 >>> Severity: serious >>> User: debian...@lists.debian.org >>> Usertags: piuparts >>> >>> Hi, >>> >>> during a test with piuparts I noticed your package fails to upgrade from >>> 'testing'. >>> It installed fine in 'testing', then the upgrade to 'sid' fails >>> because it tries to overwrite other packages files without declaring a >>> Breaks+Replaces relation. >>> >>> See policy 7.6 at >>> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >>> >>> From the attached log (scroll to the bottom...): >>> >>> Preparing to unpack .../node-cosmiconfig_7.0.0+~cs8.3.2-1_all.deb ... >>> Unpacking node-cosmiconfig (7.0.0+~cs8.3.2-1) ... >>> dpkg: error processing archive >>> /var/cache/apt/archives/node-cosmiconfig_7.0.0+~cs8.3.2-1_all.deb >>> (--unpack): >>>trying to overwrite '/usr/share/nodejs/callsites/index.d.ts', which is >>> also in package jest 26.6.3+ds+~cs64.28.30-1 >>> Errors were encountered while processing: >>>/var/cache/apt/archives/node-cosmiconfig_7.0.0+~cs8.3.2-1_all.deb >>> >>> There is currently >>> >>> Breaks: jest (<< 2.26.3+repack~), node-jest-debbundle (<< 2.26.3+repack~) >>> >>> which looks like a typoed version (2 times?), while the corresponding >>> changelog entry has the correct version. >>> But you also need matching Replaces to properly move files between packages >>> (the Breaks alone could also be satisfied by simply deconfiguring jest). >> >> Hi, >> >> what is wrong in "Breaks: jest (<< 2.26.3+repack~), node-jest-debbundle >> (<< 2.26.3+repack~)" ? Jest version in unstable is >> "26.6.3+repack+~cs61.38.31-1" > > 7.0.0+~cs8.3.2-1 is higher than 2.26.3+repack~ > > ...because 3.2 is higher than 3+ > > ...because + means "just above" so beats only nothing or 0. But 26.6.3+ds+~cs64.28.30-1 (testing) is lower than 2.26.3+repack~, so this "Breaks" looks good, isn't it ? Anyway I don't understand how to fix this -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976813: Bug#976813: Bug#976813: Bug#976813: node-cosmiconfig: missing Breaks+Replaces: jest (<< 26.6.3+repack)
Le Mardi, Décembre 08, 2020 11:07 CET, Jonas Smedegaard a écrit: > Quoting Xavier (2020-12-08 10:47:20) > > Thanks, I had to replace "ds" by "repack" since checksum decreased: I > > removed a useless component. > > For future sake, "ds" really means Debian repackaged source", and if you > need _another_ round of repackaging then more elegant to simply bump it > - i.e. change suffix ~ds to ~ds1 > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private I know that. The problem is that +ds1 is lower than +ds+~, that's why I used repack ! -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976813: Bug#976813: Bug#976813: Bug#976813: node-cosmiconfig: missing Breaks+Replaces: jest (<< 26.6.3+repack)
Le Mardi, Décembre 08, 2020 11:38 CET, Jonas Smedegaard a écrit: > Quoting Xavier (2020-12-08 11:33:40) > > Le Mardi, Décembre 08, 2020 11:07 CET, Jonas Smedegaard a > > écrit: > > > > > Quoting Xavier (2020-12-08 10:47:20) > > > > Thanks, I had to replace "ds" by "repack" since checksum decreased: I > > > > removed a useless component. > > > > > > For future sake, "ds" really means Debian repackaged source", and if you > > > need _another_ round of repackaging then more elegant to simply bump it > > > - i.e. change suffix ~ds to ~ds1 > > > > > > > > > - Jonas > > > > > > -- > > > * Jonas Smedegaard - idealist & Internet-arkitekt > > > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > > > > > [x] quote me freely [ ] ask before reusing [ ] keep private > > > > I know that. The problem is that +ds1 is lower than +ds+~, that's why I > > used repack ! > > No, +ds1 is higher than +ds+~. > > 1 is higher than +, because + beats only nothing or 0. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private I tried, but dch refused it and reported that +ds1 < +ds+ -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976813: Bug#976813: node-cosmiconfig: missing Breaks+Replaces: jest (<< 26.6.3+repack)
Le 08/12/2020 à 09:37, Andreas Beckmann a écrit : > Package: node-cosmiconfig > Version: 7.0.0+~cs8.3.2-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'testing', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > > See policy 7.6 at > https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces > > From the attached log (scroll to the bottom...): > > Preparing to unpack .../node-cosmiconfig_7.0.0+~cs8.3.2-1_all.deb ... > Unpacking node-cosmiconfig (7.0.0+~cs8.3.2-1) ... > dpkg: error processing archive > /var/cache/apt/archives/node-cosmiconfig_7.0.0+~cs8.3.2-1_all.deb (--unpack): >trying to overwrite '/usr/share/nodejs/callsites/index.d.ts', which is > also in package jest 26.6.3+ds+~cs64.28.30-1 > Errors were encountered while processing: >/var/cache/apt/archives/node-cosmiconfig_7.0.0+~cs8.3.2-1_all.deb > > There is currently > > Breaks: jest (<< 2.26.3+repack~), node-jest-debbundle (<< 2.26.3+repack~) > > which looks like a typoed version (2 times?), while the corresponding > changelog entry has the correct version. > But you also need matching Replaces to properly move files between packages > (the Breaks alone could also be satisfied by simply deconfiguring jest). Hi, what is wrong in "Breaks: jest (<< 2.26.3+repack~), node-jest-debbundle (<< 2.26.3+repack~)" ? Jest version in unstable is "26.6.3+repack+~cs61.38.31-1" It seems that jest will migrate tomorrow to testing, then this bug should be fixed automatically Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976813: Bug#976813: node-cosmiconfig: missing Breaks+Replaces: jest (<< 26.6.3+repack)
Le 08/12/2020 à 10:12, Andreas Beckmann a écrit : > On 12/8/20 9:44 AM, Xavier wrote: >> what is wrong in "Breaks: jest (<< 2.26.3+repack~), node-jest-debbundle >> (<< 2.26.3+repack~)" ? Jest version in unstable is >> "26.6.3+repack+~cs61.38.31-1" > > 2.26.3+repack~ (Breaks) << 26.6.3+ds+~cs64.28.30-1 (testing) > > > The package is lacking a clean upgrade path from the version currently > in testing to the version in sid. > > Andreas Oups sorry, I was looking the wrong part of version :-( Thanks! -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976813: Bug#976813: Bug#976813: node-cosmiconfig: missing Breaks+Replaces: jest (<< 26.6.3+repack)
Le 08/12/2020 à 10:32, Jonas Smedegaard a écrit : > Quoting Jonas Smedegaard (2020-12-08 10:04:13) >> Quoting Xavier (2020-12-08 09:44:00) >>> what is wrong in "Breaks: jest (<< 2.26.3+repack~), node-jest-debbundle >>> (<< 2.26.3+repack~)" ? Jest version in unstable is >>> "26.6.3+repack+~cs61.38.31-1" >> >> 7.0.0+~cs8.3.2-1 is higher than 2.26.3+repack~ >> >> ...because 3.2 is higher than 3+ >> >> ...because + means "just above" so beats only nothing or 0. > > Please ignore above - totally crazy of me to compare _node-cosmiconfig_ > version with Breaks value of jest. > > As Andreas posted a moment ago, problem is that the jest version of > 26.6.3+ds+~cs64.28.30-1 is lower than 2.26.3+repack~. > > Seem you forgot to include the +ds suffix, i.e. this should work: > > Breaks: jest (<< 2.26.3+ds+repack~), node-jest-debbundle (<< > 2.26.3+ds+repack~) > > On a related note, I can recommend to generally use suffix ~ds or ~dfsg > for repackaging, to leave room eventually dropping it later it turns out > to be unneeded. If ~ds were used for jest then forgetting to include > the suffix in Breaks would work, but that is just accidental: Correct is > to always include whatever suffix is on the original package version and > then at the end of _full_ version add ~ to cover custom extensions like > ~bpo. Thanks, I had to replace "ds" by "repack" since checksum decreased: I removed a useless component. I think this is now fixed, I looked the bad part of version, there was a typo on node-cosmiconfig "Breaks" field -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#974648: Bug#974648: Bug#974648: Bug#974648: Please really ship TypeScript definitions
Le 05/12/2020 à 22:16, Xavier a écrit : > > > Le 04/12/2020 à 14:47, Xavier a écrit : >> Le 13/11/2020 à 12:04, Xavier a écrit : >>> Le 13/11/2020 à 11:26, Julien Puydt a écrit : >>>> Package: jest >>>> Version: 26.6.3+ds+~cs64.27.30-1 >>>> >>>> The file /usr/share/nodejs/package.json says the TypeScript definitions >>>> are available in build/jest.d.ts, but the package doesn't contain that >>>> file : the build/ directory only has jest.js. >>> >>> Hi, >>> >>> this needs a lot of @types/ in other packages (chalk, yargs-parser,...). >>> For now I disabled `node script/buildTs.js` in debian/rules. >>> >>> I'm going to try to fix this. >> >> Hi, >> >> good news: I'll be able to build ts definitions >> bad news : not with typescript 4.1.x for now... >> >> Cheers, >> Xavier > > Missing types needed: > > @types/co > @types/color-name > @types/convert-source-map > @types/dedent > @types/exit > @types/fb-watchman > @types/is-ci > @types/istanbul-lib-instrument > @types/istanbul-lib-source-maps > @types/merge-stream > @types/natural-compare > @types/node-notifier > @types/prettier > @types/prompts > @types/prop-types > @types/resolve > @types/sane > @types/source-map-support > @types/supports-color > @types/weak-napi > @types/write-file-atomic > @types/yargs-parser Done except of course unpackaged modules: * @types/node-notifier * @types/prettier * @types/weak-napi -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Workarounds for node-ava
Hi,
packaging node-ava needs a (too big) lot of components/packages (I
stopped counting at 48).
Workarounds:
* for simple test files, replace it by node-tape:
## ORIGINAL TEST ###TAPE TEST##
#
import test from 'ava' # const test = require('tape')
import foo from '.' # const foo = require('.')
#
test('bar', t => { # test('bar', t=> {
t.is( foo(0), 0) #t.is( foo(0), 0)
} #t.end()
# }
Just to transform in commonjs and add "t.end()" at each test; and
adapt some functions name. For example, t.notThrows becomes
t.doesNotThrow.
See /usr/share/doc/node-tape/readme.markdown.gz to find
them.
* more complex test files, use jest (via jest-codemods)
$ npx jest-codemods
? Which parser do you want to use? Babel
? Which test library would you like to migrate from? AVA
? Are you using the global object for assertions? No
? Will you be using Jest on Node.js as your test runner? Yes
? On which files or directory should the codemods be applied?
test.js
Executing command: jscodeshift -t [...] test.js \
--ignore-pattern node_modules --parser babel
Processing 1 files...
Spawning 1 workers...
Sending 1 files to free worker...
All done.
Results:
0 errors
0 unmodified
0 skipped
1 ok
# Test it
$ jest --ci --testRegex test.js
It may need a babel file. If so, add a babel.config.json:
{
"presets": [ "@babel/preset-env" ],
"plugins": [ "@babel/plugin-transform-runtime" ]
}
Anyway, jest has not exactly the same features than ava. Especially some
throwsAsync / notThrowsAsync test should be removed or modified.
I'll add this to https://wiki.debian.org/Javascript/Tutorial when
wiki.debian.org will be available (403 for now...)
Cheers,
Xavier
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976341: Bug#976341: node-jest: please provide real (not virtual) package node-jest-worker
Le 03/12/2020 à 19:05, Jonas Smedegaard a écrit : > Quoting Xavier (2020-12-03 18:30:54) >> Control: tags -1 + confirmed >> >> Le 03/12/2020 à 18:07, Jonas Smedegaard a écrit : >>> node-rollup-plugin-terser has a runtime dependency on >>> node-jest-worker. >>> >>> Currently node-jest-worker is provided as a virtual package by jest. >>> Problem with that is the size of the dependency tree... >>> >>> rollup+node-rollup-plugin-terser+jest: 334 pkgs / 182 MB >>> >>> rollup+node-rollup-plugin-terser+node-jest-worker: 136 pkgs / 107 MB >>> >>> I.e. the size is approximately half with node-jest-worker separate >>> from jest. >>> >>> >>> Please provide real (not virtual) package node-jest-worker, >>> and have jest depend on or recommend that, as appropriate. >>> >>> >>> - Jonas >>> >>> Hint: Introducing a new package causes a visit the the NEW queue, >>> which potentially can require some time for processing. To avoid >>> such waiting time stalling other development of the jest package >>> it can be beneficial to first mae a release to experimental >>> (where it can linger while other releases are made to unstable). >> >> According to https://people.debian.org/~yadd/jest-spaghetti-dish.png >> this makes sense. Do you see some other jest parts that should be separated? > > Sorry, I have only closely examined the virtual package that I concrete > have a need for. > > It makes fine sense to me that node-jest-worker was provided only as a > virtual package until now. If you want to do more now than switching > that one binary package from virtual to real, then the most sensible to > me is to make sure _all_ embedded modules are provided as virtual > packages to encourage _others_ to collaborate on that larger ongoing > process of refining pakcage relations. > > Viewed generally, decoupling binary packages can be separated into > multiple steps...: > > 1) provide embedded modules as packages - virtual or not - to allow > declaring explicit package relations. > > 2) declare explicit package relations. > > 3) examine explicit package relations against virtual packages, to > assess if some of them might benefit from being maintained as real > binary packages. > > Here concretely, I just happened to do 2) and 3) together. > > For comparison, some size benefit might be in decoupling > node-types-babel-code-frame from node-babel7 - but in that case I am > _required_ to do examination first, because the virtual package lack > versioning and therefore cannot be declared explicitly in packages > depending on it. By not providing versioned virtual packages, it is > harder to identify places beneficial for decoupling, because exact > relationship cannot be declared ahead of the examination. node-babel7 does provide versioned virtual packages (like acorn). I'll study if node-babel7 can be split into multiple packages. It took me around 4 hours to split jest correctly... Done for jest, waiting for ftpmaster review. Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#974648: Bug#974648: Please really ship TypeScript definitions
Le 13/11/2020 à 12:04, Xavier a écrit : > Le 13/11/2020 à 11:26, Julien Puydt a écrit : >> Package: jest >> Version: 26.6.3+ds+~cs64.27.30-1 >> >> The file /usr/share/nodejs/package.json says the TypeScript definitions >> are available in build/jest.d.ts, but the package doesn't contain that >> file : the build/ directory only has jest.js. > > Hi, > > this needs a lot of @types/ in other packages (chalk, yargs-parser,...). > For now I disabled `node script/buildTs.js` in debian/rules. > > I'm going to try to fix this. Hi, good news: I'll be able to build ts definitions bad news : not with typescript 4.1.x for now... Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976310: Bug#976310: node-compression-webpack-plugin: TypeError: (0 , _schemaUtils.validate) is not a function
Le 03/12/2020 à 10:13, Xavier a écrit : > Control: tags -1 + moreinfo > > Le 03/12/2020 à 09:54, Pirate Praveen a écrit : >> Package: node-compression-webpack-plugin >> Version: 3.0.1-3 >> Severity: serious >> Control: affects -1 gitlab >> >> Installation of gitlab started failing with the following error. I think >> this is related to the recent update of node-schema-utils. >> >> Webpacking... >> /usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js:93 >> throw err; >> ^ >> >> TypeError: (0 , _schemaUtils.validate) is not a function > > Hi, > > _schemaUtils.validate *is* a function when using schema-utils ≥ 3. > Problem is probably somewhere else Does gitlab use `npm install` ? If so, we just have to fix node-compression-webpack-plugin/package.json -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976310: Bug#976310: node-compression-webpack-plugin: TypeError: (0 , _schemaUtils.validate) is not a function
Control: tags -1 + moreinfo Le 03/12/2020 à 09:54, Pirate Praveen a écrit : > Package: node-compression-webpack-plugin > Version: 3.0.1-3 > Severity: serious > Control: affects -1 gitlab > > Installation of gitlab started failing with the following error. I think > this is related to the recent update of node-schema-utils. > > Webpacking... > /usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js:93 > throw err; > ^ > > TypeError: (0 , _schemaUtils.validate) is not a function Hi, _schemaUtils.validate *is* a function when using schema-utils ≥ 3. Problem is probably somewhere else -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976341: Bug#976341: Bug#976341: node-jest: please provide real (not virtual) package node-jest-worker
Le 04/12/2020 à 15:32, Jonas Smedegaard a écrit : > Quoting Xavier (2020-12-04 11:48:58) >> Le 03/12/2020 à 19:05, Jonas Smedegaard a écrit : >>> Quoting Xavier (2020-12-03 18:30:54) >>>> Le 03/12/2020 à 18:07, Jonas Smedegaard a écrit : >>>>> Please provide real (not virtual) package node-jest-worker, and >>>>> have jest depend on or recommend that, as appropriate. > > [...] > >> node-babel7 does provide versioned virtual packages (like acorn). > > You are right: I failed to check correctly versioning. apt and aptitude > apparently does *not* show version for virtual packages (I thought so, > and I thought I had checked that with node-types-uuid). > > This works: > > apt-cache showpkg node-types-babel-code-frame | grep '^[a-z]' > > This also works, and is more flexible to e.g. reveal that 3 node-types-* > packages do not provide version: > > sudo sync-available > grep-available -FProvides -sProvides node-types- | grep -Po > '\bnode-types-[^,]+' I didn't know those tips, thanks! > This should also work flexibly and more elegant, but doesn't for me (not > sure why): > > grep-status --field=Provides -sProvides node-types-babel-code-frame > > >> I'll study if node-babel7 can be split into multiple packages. It took >> me around 4 hours to split jest correctly... >> >> Done for jest, waiting for ftpmaster review. > > Thanks! Note that I didn't succeed to split node-expect, it is really mixed into other jest modules (!= node-expect.js). See (incomplete) https://people.debian.org/~yadd/jest-spaghetti-dish.png. So I think using mocha+expect is a bad thing, prefer to use jest directly (just to set test file paths: `jest --ci --testRegex test/*.test-files.js`). -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#976341: Bug#976341: Bug#976341: node-jest: please provide real (not virtual) package node-jest-worker
Le 04/12/2020 à 15:32, Jonas Smedegaard a écrit : > Quoting Xavier (2020-12-04 11:48:58) >> Le 03/12/2020 à 19:05, Jonas Smedegaard a écrit : >>> Quoting Xavier (2020-12-03 18:30:54) >>>> Le 03/12/2020 à 18:07, Jonas Smedegaard a écrit : >>>>> Please provide real (not virtual) package node-jest-worker, and >>>>> have jest depend on or recommend that, as appropriate. > > [...] > >> node-babel7 does provide versioned virtual packages (like acorn). > > You are right: I failed to check correctly versioning. apt and aptitude > apparently does *not* show version for virtual packages (I thought so, > and I thought I had checked that with node-types-uuid). > > This works: > > apt-cache showpkg node-types-babel-code-frame | grep '^[a-z]' > > This also works, and is more flexible to e.g. reveal that 3 node-types-* > packages do not provide version: > > sudo sync-available > grep-available -FProvides -sProvides node-types- | grep -Po > '\bnode-types-[^,]+' > > This should also work flexibly and more elegant, but doesn't for me (not > sure why): > > grep-status --field=Provides -sProvides node-types-babel-code-frame > > >> I'll study if node-babel7 can be split into multiple packages. It took >> me around 4 hours to split jest correctly... Take a look at https://people.debian.org/~yadd/babel-spaghetti-dish.png (generated with add-node-component --cmptree). I don't know how to split node-babel7 for now... -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#973741: Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use
Le 28/11/2020 à 20:28, Pirate Praveen a écrit : > On Thu, 19 Nov 2020 23:50:24 +0530 Pirate Praveen > wrote: >> >> >> On Thu, Nov 19, 2020 at 18:58, Xavier wrote: >> > we opened bugs to upstream repo and are waiting for... >> >> I don't think upstream will make any significant changes to 1.x branch >> any more. Someone who want to see yarn in debian bullseye will have to >> fix it. > > As per https://dev.to/arcanis/introducing-yarn-2-4eh1 yarn 1.x is > officially in maintenance mode. > > Quoting from above: > > "What will happen to the legacy codebase? > > Yarn 1.22 will be released next week. Once done, the 1.x branch will > officially enter maintenance mode - meaning that it won't receive > further releases from me except when absolutely required to patch > vulnerabilities. New features will be developed exclusively against Yarn > 2." > > And there is no way to separately install yarn 2, you have to install > yarn 1.x to get newer versions of yarn. > > Quoting again, > "The yarn package on npm will not change; we will distribute further > version using the new yarn set version command." > > So some options I can think, > > 1. Port yarn 1.x to build with babel 7 (but this has not been successfull) > 2. Try to run ES6 code directly somehow, may be with newer nodejs and > patches. I think Paolo tried this option, not sure what happened. > 3. Build it using 'deb > https://snapshot.debian.org/archive/debian/20200502T085134Z sid main' > (the last version that builds in sid) and embed the built files in the > package (as two steps, like we bootstrap babel, rollup etc). This will > mean, we will have to move it to contrib. I prefer shipping yarn in > contrib to missing it in bullseye. > > Also can someone help me with a patch for node-mkdirp 1.0? I tried but > could not figure it out, I looked at some of the packages ported by > yadd, but this one is using a different syntax. Hi, just to replace mkdirp by mkdirp-classic in src/util/fs.js > We can't build it in current sid, but create a chroot from the above > snapshot and run dpkg-buildpackage. > > sudo debootstrap sid /srv/chroot/debian-sid-20200502T085134Z > https://snapshot.debian.org/archive/debian/20200502T085134Z/ > > I manually installed node-mkdirp and reverse dependencies to test the > built package. > > We will have to do a binary included upload (it can't migrate to testing > because of babel 6 requirement anyway). > > -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] New "ctype" option in uscan
Le 30 novembre 2020 20:39:21 GMT+01:00, gregor herrmann a écrit : >On Mon, 30 Nov 2020 10:10:54 +0100, Xavier wrote: > >> I added a new feature in uscan to help uscan comparison when components >> are embedded, especially when "checksum" target is used: if "ctype" >> exists, uscan will use "version" value from package.json (JavaScript) or >> META.json (Perl) to get current component value. >> >> For now, only "nodejs" and "perl" values are accepted. > >This looks interesting, thank you. > >Do I understand this correctly? For e.g. >libcgi-application-plugin-authentication-perl >I would make the following change to d/watch: > >#v+ >--- a/debian/watch >+++ b/debian/watch >@@ -2,8 +2,8 @@ version=4 > > https://metacpan.org/release/CGI-Application-Plugin-Authentication > .*/CGI-Application-Plugin-Authentication-v?@ANY_VERSION@@ARCHIVE_EXT@$ group > >-opts="component=driver-cdbi" \ >+opts="component=driver-cdbi,ctype=perl" \ > https://metacpan.org/release/CGI-Application-Plugin-Authentication-Driver-CDBI > > .*/CGI-Application-Plugin-Authentication-Driver-CDBI-v?@ANY_VERSION@@ARCHIVE_EXT@$ > checksum > >-opts="component=driver-dbic" \ >+opts="component=driver-dbic,ctype=perl" \ > https://metacpan.org/release/CGI-Application-Plugin-Authentication-Driver-DBIC > > .*/CGI-Application-Plugin-Authentication-Driver-DBIC-v?@ANY_VERSION@@ARCHIVE_EXT@$ > checksum Yes, you're right >#v- > >and (for the last part) uscan says: > >driver-cdbi has META.json, driver-dbic doesn't, and uscan says: > >uscan info: opts: component=driver-cdbi,ctype=perl >uscan info: line: >https://metacpan.org/release/CGI-Application-Plugin-Authentication-Driver-CDBI > .*/CGI-Application-Plugin-Authentication-Driver-CDB > > >I-v?(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|zip|tgz|tbz|txz))$ > checksum >uscan info: Parsing component=driver-cdbi >uscan info: Parsing ctype=perl >uscan info: line: >https://metacpan.org/release/CGI-Application-Plugin-Authentication-Driver-CDBI > .*/CGI-Application-Plugin-Authentication-Driver-CDB > > >I-v?(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|zip|tgz|tbz|txz))$ > checksum >uscan info: Found version 0.03 for component driver-cdbi >uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.03 >uscan info: Last orig.tar.* tarball version (dversionmangled): 0.03 >uscan info: Requesting URL: > > https://metacpan.org/release/CGI-Application-Plugin-Authentication-Driver-CDBI >uscan info: Matching pattern: > > (?:(?:https://metacpan.org)?\/release\/)?.*/CGI-Application-Plugin-Authentication-Driver-CDBI-v?(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz > > > |tar\.bz2|tar\.gz|zip|tgz|tbz|txz))$ >uscan info: Found the following matching hrefs on the web page (newest first): > > https://cpan.metacpan.org/authors/id/A/AD/ADOPTME/CGI-Application-Plugin-Authentication-Driver-CDBI-0.03.tar.gz > (0.03) index=0.03-1 > > https://cpan.metacpan.org/authors/id/A/AD/ADOPTME/CGI-Application-Plugin-Authentication-Driver-CDBI-0.03.tar.gz > (0.03) index=0.03-1 >uscan info: Looking at $base = >https://metacpan.org/release/CGI-Application-Plugin-Authentication-Driver-CDBI >with >$filepattern = > .*/CGI-Application-Plugin-Authentication-Driver-CDBI-v?(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|zip|tgz > > |tbz|txz))$ found >$newfile = > https://cpan.metacpan.org/authors/id/A/AD/ADOPTME/CGI-Application-Plugin-Authentication-Driver-CDBI-0.03.tar.gz >$newversion = 0.03 >$lastversion = 0.03 >uscan info: Matching target for downloadurlmangle: >https://cpan.metacpan.org/authors/id/A/AD/ADOPTME/CGI-Application-Plugin-Authentication-Driver-CDBI > >-0.03.tar.gz >uscan info: Upstream URL(+tag) to download is identified as >https://cpan.metacpan.org/authors/id/A/AD/ADOPTME/CGI-Application-Plugin-Authentication > >
[Pkg-javascript-devel] Bug#976186: Bug#976186: node-backbone: Please provides typescript definition
Le 01/12/2020 à 12:21, Jonas Smedegaard a écrit : > Quoting Xavier Guimard (2020-12-01 06:22:15) >> node-typescript-types is deprecated, please embed @types/backbone in >> node-backbone. > > Thanks for filing as a formal bugreport! > > Working on it... Hi, note that @types/backbone requires @types/underscore. Do you want a separated BTS for this one? Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Please reject node-gyp-build
Hi all, I pushed node-gyp-build (#977472), but after checking more I think it's a bad idea to push such package to Debian: its goal is to check if a prebuild object exists in package downloaded from npm registry before launching `node-gyp rebuild`. Debian packages provide compiled objects and don't use on-the-fly compilation, then this package is useless. I removed this dependency from node-websocket using a simple patch [1] So please reject node-gyp-build. Cheers, Xavier [1]: https://salsa.debian.org/js-team/node-websocket/-/blob/master/debian/patches/remove-dependency-to-node-gyp-build.patch -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#977960: Bug#977960: dangling /usr/share/javascript/jquery/jquery.js symlink
Le 23/12/2020 à 12:34, Matthias Klose a écrit : > On 12/23/20 12:19 PM, Xavier wrote: >> Control: tags -1 + moreinfo >> >> Le 23/12/2020 à 12:06, Matthias Klose a écrit : >>> Package: libjs-jquery >>> Version: 3.5.1+dfsg+~3.5.5-1 >>> Severity: serious >>> Tags: sid bullseye >>> >>> There's at least one dangling /usr/share/javascript/jquery/jquery.js symlink >>> >>> $ dpkg -S /usr/share/javascript/jquery/jquery.js >>> libjs-jquery: /usr/share/javascript/jquery/jquery.js >>> >>> $ ls -l /usr/share/javascript/jquery/jquery.js >>> lrwxrwxrwx 1 root root 34 Dec 22 08:27 >>> /usr/share/javascript/jquery/jquery.js -> >>> ../../nodejs/jquery/dist/jquery.js >>> >>> $ ls -lL /usr/share/javascript/jquery/jquery.js >>> ls: cannot access '/usr/share/javascript/jquery/jquery.js': No such file or >>> directory >> >> Hi, >> >> I'm unable to reproduce. libjs-jquery depends on node-jquery which >> provides the missing files: >> >> $ dpkg -S /usr/share/javascript/jquery/jquery.js >> libjs-jquery: /usr/share/javascript/jquery/jquery.js >> $ ls -l /usr/share/javascript/jquery/jquery.js >> lrwxrwxrwx 1 root root 34 22 déc. 08:27 >> /usr/share/javascript/jquery/jquery.js -> ../../nodejs/jquery/dist/jquery.js >> $ ls -lL /usr/share/javascript/jquery/jquery.js >> -rw-r--r-- 1 root root 287600 22 déc. 08:27 >> /usr/share/javascript/jquery/jquery.js >> > > > $ ls -l /usr/share/nodejs/jquery/dist > total 0 > lrwxrwxrwx 1 root root 34 Dec 22 08:27 jquery.js -> > ../../nodejs/jquery/dist/jquery.js > lrwxrwxrwx 1 root root 38 Dec 22 08:27 jquery.min.js -> > ../../nodejs/jquery/dist/jquery.min.js > lrwxrwxrwx 1 root root 45 Dec 22 08:27 jquery.min.js.brotli -> > ../../nodejs/jquery/dist/jquery.min.js.brotli > lrwxrwxrwx 1 root root 41 Dec 22 08:27 jquery.min.js.gz -> > ../../nodejs/jquery/dist/jquery.min.js.gz > lrwxrwxrwx 1 root root 39 Dec 22 08:27 jquery.min.map -> > ../../nodejs/jquery/dist/jquery.min.map > lrwxrwxrwx 1 root root 46 Dec 22 08:27 jquery.min.map.brotli -> > ../../nodejs/jquery/dist/jquery.min.map.brotli > lrwxrwxrwx 1 root root 42 Dec 22 08:27 jquery.min.map.gz -> > ../../nodejs/jquery/dist/jquery.min.map.gz > > > the link targets are not files, but again symlinks pointing to itself. Perhaps this is due to double change: $ cat debian/libjs-jquery.maintscript dir_to_symlink /usr/share/javascript/jquery /usr/share/nodejs/jquery/dist 3.5.0+dfsg-1~ symlink_to_dir /usr/share/javascript/jquery /usr/share/nodejs/jquery/dist 3.5.1+dfsg+~3.5.4-4~ Should I have to keep only the last ? -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-commander ≥ 6
Le 23/12/2020 à 12:19, Jonas Smedegaard a écrit : > Hi Xavier, > > Quoting Xavier (2020-12-23 11:34:41) >> node-commander 6 is ready in experimental. It seems that all is OK, >> except a little change in uglifyjs.terser help output detected by your >> Perl test. >> I posted a simple MR, could you see if this is acceptable (compatible >> with node-commander 5)? > > Please attach proposed patch to an email. Preferably as a bugreport. > > Thanks! > > - Jonas Hi, With commander 6, uglifyjs.terser displays: Usage: uglifyjs [options]... instead of: Usage: uglifyjs.terser [options]... I don't know if my patch is useful here: it replaced your test regex with a more tolerant one without fixing the real issue (if this is an issue?). diff --git a/debian/tests/uglifyjs.terser.t b/debian/tests/uglifyjs.terser.t index 7333e22..2412e1c 100644 --- a/debian/tests/uglifyjs.terser.t +++ b/debian/tests/uglifyjs.terser.t @@ -16,7 +16,7 @@ like stdout, qr/^terser [\d.]+$/, 'version, stdout'; cmp_ok stderr, 'eq', '', 'version, stderr'; run_ok $CMD, qw(--help); -like stdout, qr/^\s*Usage: $CMD \[options\] \[files\.\.\.\]\n/, 'help, stdout'; +like stdout, qr/^\s*Usage: uglifyjs\S* \[options\] \[files\.\.\.\]\n/, 'help, stdout'; cmp_ok stderr, 'eq', '', 'help, stderr'; done_testing; -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#977962: Bug#977962: webpack: mkdirp > 1 patch seems broken
Control: severity -1 important
Control: retitle -1 node-compression-webpack-plugin: enable test
Le 23/12/2020 à 13:27, Pirate Praveen a écrit :
> Package: webpack,node-compression-webpack-plugin
> Version: 4.43.0-6
> Severity: serious
>
> To reproduce this issue,
>
> run
> jest --ci test/CompressionPlugin.test.js
>
> in node-compression-webpack-plugin
>
> ● CompressionPlugin › should work and show compress assets in stats
>
> TypeError: callback must be a function
>
> 491 | if (err) return callback(err);
> 492 | outputPath = compilation.getPath(this.outputPath);
> > 493 | this.outputFileSystem.mkdirp(outputPath).then(() =>
> {emitFiles()}).catch(er => {throw er});
> | ^
> 494 | });
> 495 | }
> 496 |
>
> at validateCallback (node_modules/memfs/lib/volume.js:199:15)
> at Volume.mkdirp (node_modules/memfs/lib/volume.js:1579:24)
> at ../../../../../usr/share/nodejs/webpack/lib/Compiler.js:493:26
> at eval (eval at create
> (../../../../../usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12),
> :8:1)
>
> It is also possible a bug in node-compression-webpack-plugin/memfs
> module (this should be added as a test only component, I have not
> committed this to repo as the tests are failing still). memfs does not
> have any dependency on mkdirp hence I think the bug is in webpack.
The bug is that memfs adds hooks to simulate a filesystem and overrides
webpack/mkdirp calls, simulating mkdirp 0.53.
You can fix this in memfs to return a promise instead of waiting for a
callback
Cheers,
Xavier
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#977960: Bug#977960: dangling /usr/share/javascript/jquery/jquery.js symlink
Control: tags -1 + moreinfo Le 23/12/2020 à 12:06, Matthias Klose a écrit : > Package: libjs-jquery > Version: 3.5.1+dfsg+~3.5.5-1 > Severity: serious > Tags: sid bullseye > > There's at least one dangling /usr/share/javascript/jquery/jquery.js symlink > > $ dpkg -S /usr/share/javascript/jquery/jquery.js > libjs-jquery: /usr/share/javascript/jquery/jquery.js > > $ ls -l /usr/share/javascript/jquery/jquery.js > lrwxrwxrwx 1 root root 34 Dec 22 08:27 /usr/share/javascript/jquery/jquery.js > -> > ../../nodejs/jquery/dist/jquery.js > > $ ls -lL /usr/share/javascript/jquery/jquery.js > ls: cannot access '/usr/share/javascript/jquery/jquery.js': No such file or > directory Hi, I'm unable to reproduce. libjs-jquery depends on node-jquery which provides the missing files: $ dpkg -S /usr/share/javascript/jquery/jquery.js libjs-jquery: /usr/share/javascript/jquery/jquery.js $ ls -l /usr/share/javascript/jquery/jquery.js lrwxrwxrwx 1 root root 34 22 déc. 08:27 /usr/share/javascript/jquery/jquery.js -> ../../nodejs/jquery/dist/jquery.js $ ls -lL /usr/share/javascript/jquery/jquery.js -rw-r--r-- 1 root root 287600 22 déc. 08:27 /usr/share/javascript/jquery/jquery.js Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] node-commander ≥ 6
Hi Jonas, node-commander 6 is ready in experimental. It seems that all is OK, except a little change in uglifyjs.terser help output detected by your Perl test. I posted a simple MR, could you see if this is acceptable (compatible with node-commander 5)? Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#977963: node-commander ≥ 6
Le 23/12/2020 à 13:28, Jonas Smedegaard a écrit : > Quoting Jonas Smedegaard (2020-12-23 13:06:40) >> Quoting Xavier (2020-12-23 12:28:53) >>> Le 23/12/2020 à 12:19, Jonas Smedegaard a écrit : >>>> Quoting Xavier (2020-12-23 11:34:41) >>>>> node-commander 6 is ready in experimental. It seems that all is >>>>> OK, except a little change in uglifyjs.terser help output >>>>> detected by your Perl test. >>>>> I posted a simple MR, could you see if this is acceptable >>>>> (compatible with node-commander 5)? >>>> >>>> Please attach proposed patch to an email. Preferably as a >>>> bugreport. >> >>> With commander 6, uglifyjs.terser displays: >>> >>> Usage: uglifyjs [options]... >>> >>> instead of: >>> >>> Usage: uglifyjs.terser [options]... >>> >>> I don't know if my patch is useful here: it replaced your test regex >>> with a more tolerant one without fixing the real issue (if this is an >>> issue?). >> >> Ah, thanks - that is a helpful detail. >> >> No, I don't think that is an issue needed any further work than >> wriggling the terser test a bit. >> >> Please go ahead (assuming no issues elsewhere) with the node-commander >> upgrade - i.e. don't wait for terser, I will handle that from there. > > Oh! This still is just a mailinglist conversation, not a bugreport :-( > > @Xavier, would you mind filing this as a proper bugreport, please? > > Or tell me if that is too uch hassle for you, then I will do it, but > prefor to give you credit for your work. > > In case you wonder: No, this is not just bureaucratic busywork: I am in > the middle of other work with the terser package (and a pile of other > work with other packages, including the mess I made with symlink-to-dir > removals), and tracking issues with the bugtracker truly helps. Hi, can I upload node-commander to unstable or do you prefer to push node-terser first ? Regards, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#977677: Bug#977677: Bug#977677: FTBFS: dependency to node-babel-runtime >=7 isn't understood by deb tools
Le 18/12/2020 à 20:09, Jonas Smedegaard a écrit : > Quoting Xavier (2020-12-18 18:45:30) >> Please launch autopkgtest before uploading such changes to avoid >> problems. > > Yes, I fully agree. > > I generally run autopkgtest at every build + compare with debdiff > against previous package release. > > I certainly intended to do here as well, but see now that my setup miss > some hooks for pkg-js-tools. :-( > > I will stop releasing any packages using pkg-js-tools until I have that > local issued solved. Enabling salsa CI may help here (this is how I discovered the problem). Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#977690: Bug#977690: node-rollup-plugin-json: please embed additional rollup plugins
Le 18/12/2020 à 23:41, Jonas Smedegaard a écrit : > Package: node-rollup-plugin-json > Version: 4.1.0+repack+~4.0.0-1 > Severity: wishlist > > I need these rollup plugins + dependencies not yet in Debian: > > rollup-plugin-cleanup > rollup-plugin-multi-entry > matched > js-cleanup > skip-regex > perf-regexes > > They are all tiny, with seemingly similar dependencies and build- > dependencies as node-rollup-plugin-json - and one of them is even > included already with the source package ;-) > > Please consider embedding them with node-rollup-plugin-json. Hi, it's easy to embed @rollup/plugin-multi-entry (already present in source tree. But not easy to follow changes: @rollup/plugin* use the same git repo but with specific tags. That's why all @rollup/plugin* Debian packages have the same debian/watch except the git-tag regex. Maybe a better way to provide all @rollup/* with one source package (I didn't found a good way, that's why I kept separated packages) Actual example with @rollup/plugin-json: version=4 opts=\ mode=git,\ dversionmangle=auto,\ filenamemangle=s/.*\/v?([\d\.-]+)\.tar\.gz/node-rollup-pluginutils-$1.tar.gz/ \ https://github.com/rollup/plugins.git refs/tags/json-v?([\d\.]+) group -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#977685: Bug#977685: node-jest: build routines are too brittle: build failures go undetected
Le 18/12/2020 à 22:28, Jonas Smedegaard a écrit : > Source: node-jest > Version: 26.6.3+repack+~cs61.38.31-3 > Severity: serious > > By accident I noticed that a release of node-jest with only changes to > package relations changed size from 8.5 megabytes to 500 kilobytes. > > A closer examination of build logs seems to indicate failures to compile > TypeScript code into JavaScript. > > Build logs are here: > https://buildd.debian.org/status/logs.php?pkg=node-jest=all > > wget > 'https://buildd.debian.org/status/fetch.php?pkg=node-jest=all=26.6.3%2Brepack%2B%7Ecs61.38.31-2=1607423417=0' > wget > 'https://buildd.debian.org/status/fetch.php?pkg=node-jest=all=26.6.3%2Brepack%2B%7Ecs61.38.31-3=1608313404=0' > git diff --no-index fetch.php* > > Detail from log comparison which seems important: > > -dh_auto_install: warning: ### Missing char-regex/src, skipping > - > -dh_auto_install: warning: ### Missing char-regex/tsconfig.json, skipping > - > -dh_auto_install: warning: ### Missing char-regex/tsconfig.tsbuildinfo, > skipping These message are false-positive bad warning when using default .npmignore. I'll remove them in pkg-js-tools. The difference comes from new pkg-js-tools feature: it reads now .npmignore, then /usr/share/nodejs/jest-each/assets/ is now removed. I didn't see that this directory contains 4 very big .gif! So closing this bug, this is not a bug but an improvement of pkg-js-tools! Thanks to have looked at this. Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-jest_26.6.3+repack+~cs61.38.31-3_sourceonly.changes ACCEPTED into unstable
Le 18/12/2020 à 19:24, Jonas Smedegaard a écrit : > Quoting Debian FTP Masters (2020-12-18 18:34:31) >> Changes: >> node-jest (26.6.3+repack+~cs61.38.31-3) unstable; urgency=medium >> . >>* Explicitly (build-)depend on needed babel modules (Closes: #977670) > > Something undocumented happened with above release: Package jest was > reduced from 8.4 MB to less than 500 kB! > > Here's a debdiff: > > Files in second .deb but not in first > - > -rw-r--r-- root/root /usr/share/nodejs/@bcoe/v8-coverage/src/lib/ascii.ts > -rw-r--r-- root/root /usr/share/nodejs/@bcoe/v8-coverage/src/lib/clone.ts > -rw-r--r-- root/root /usr/share/nodejs/@bcoe/v8-coverage/src/lib/compare.ts > -rw-r--r-- root/root /usr/share/nodejs/@bcoe/v8-coverage/src/lib/index.ts > -rw-r--r-- root/root /usr/share/nodejs/@bcoe/v8-coverage/src/lib/merge.ts > -rw-r--r-- root/root > /usr/share/nodejs/@bcoe/v8-coverage/src/lib/normalize.ts > -rw-r--r-- root/root > /usr/share/nodejs/@bcoe/v8-coverage/src/lib/range-tree.ts > -rw-r--r-- root/root /usr/share/nodejs/@bcoe/v8-coverage/src/lib/types.ts > -rw-r--r-- root/root > /usr/share/nodejs/@bcoe/v8-coverage/src/test/merge.spec.ts > -rw-r--r-- root/root > /usr/share/nodejs/@jest/test-utils/src/ConditionalTest.ts > -rw-r--r-- root/root > /usr/share/nodejs/@jest/test-utils/src/alignedAnsiStyleSerializer.ts > -rw-r--r-- root/root /usr/share/nodejs/@jest/test-utils/src/config.ts > -rw-r--r-- root/root /usr/share/nodejs/@jest/test-utils/src/index.ts > > Files in first .deb but not in second > - > -rw-r--r-- root/root /usr/share/nodejs/jest-each/assets/default-demo.gif > -rw-r--r-- root/root /usr/share/nodejs/jest-each/assets/describe-demo.gif > -rw-r--r-- root/root > /usr/share/nodejs/jest-each/assets/tagged-template-literal.gif > -rw-r--r-- root/root /usr/share/nodejs/jest-each/assets/test-demo.gif > -rw-r--r-- root/root /usr/share/nodejs/pretty-format/perf/test.js > -rw-r--r-- root/root /usr/share/nodejs/pretty-format/perf/world.geo.json No, here: ll ../jest_26.6.3+repack+~cs61.38.31-3_all.deb -rw-rw-r-- 1 x x 8859668 18 déc. 18:08 \ ../jest_26.6.3+repack+~cs61.38.31-3_all.deb Maybe a problem elsewhere ? jest_26.6.3+repack+~cs61.38.31-3_all.deb new Debian package, version 2.0. size 8859668 bytes: control archive=15032 bytes. 3858 octets,21 lignes control 46173 octets, 540 lignes md5sums Package: jest Source: node-jest Version: 26.6.3+repack+~cs61.38.31-3 Architecture: all Maintainer: Debian Javascript Maintainers Installed-Size: 12538 Depends: node-ansi-regex, node-ansi-styles, node-anymatch, node-babel-code-frame, node-babel-core, node-babel-plugin-add-module-exports, node-babel-template, node-babel-traverse, node-babel-types, node-camelcase, node-chalk, node-co, node-convert-source-map, node-cosmiconfig, node-deepmerge, node-detect-newline, node-emittery, node-execa, node-exit, node-glob, node-graceful-fs, node-is-generator-fn, node-istanbul, node-jest-debbundle, node-jest-worker, node-jsdom, node-json-stable-stringify, node-leven, node-micromatch, node-minimist, node-prompts, node-react, node-read-pkg-up, node-resolve, node-rimraf, node-sane, node-semver, node-sinon, node-slash, node-source-map, node-source-map-support, node-stack-utils, node-strip-bom, node-types-babel-core, node-types-babel-traverse, node-which, node-write-file-atomic, node-yargs, nodejs Provides: node-astral-regex (= 2.0.0), node-babel-jest (= 26.6.3), node-babel-plugin-jest-hoist (= 26.6.2), node-babel-preset-jest (= 26.6.2), node-babel-preset-moxy (= 3.2.0), node-bcoe-v8-coverage (= 0.2.3), node-char-regex (= 1.0.2), node-collect-v8-coverage (= 1.0.1), node-dedent (= 0.7.0), node-diff-sequences (= 26.6.2), node-expect (= 26.6.2), node-import-local (= 3.0.2), node-is-ci (= 2.0.0), node-jest, node-jest-changed-files (= 26.6.2), node-jest-circus (= 26.6.3), node-jest-cli (= 26.6.3), node-jest-config (= 26.6.3), node-jest-console (= 26.6.2), node-jest-core (= 26.6.3), node-jest-create-cache-key-function (= 26.6.2), node-jest-diff (= 26.6.2), node-jest-docblock (= 26.0.0), node-jest-each (= 26.6.2), node-jest-environment (= 26.6.2), node-jest-environment-jsdom (= 26.6.2), node-jest-environment-node (= 26.6.2), node-jest-fake-timers (= 26.6.2), node-jest-get-type (= 26.3.0), node-jest-globals (= 26.6.2), node-jest-haste-map (= 26.6.2), node-jest-jasmine2 (= 26.6.3), node-jest-leak-detector (= 26.6.2), node-jest-matcher-utils (= 26.6.2), node-jest-message-util (= 26.6.2), node-jest-mock (= 26.6.2), node-jest-phabricator (= 26.6.2), node-jest-pnp-resolver (= 1.2.2), node-jest-regex-util (= 26.0.0), node-jest-repl (= 26.6.3), node-jest-reporters (= 26.6.2), node-jest-resolve (= 26.6.2), node-jest-resolve-dependencies (= 26.6.3), node-jest-runner (=
