[Pkg-javascript-devel] Bug#970651: Bug#970651: Bug#970651: rollup: Unable to build with current tsc
On 2020, സെപ്റ്റംബർ 21 3:37:01 AM IST, Jonas Smedegaard wrote: >> I think we should create a release team within js team to handle it >> like how release team works for transitions. > >What do you mean more concretely? > >That only a smaller elite group should (approve) upload to unstable, and >everyone else should upload only to experimental, or...? For major updates that has reverse dependencies, some one should approve. It can even be anyone in the team and not just a fixed smaller group. At least one other person should approve. The request should include if they ran autopkgtests and rebuilds of affected packages and list any failed packages. It can even be auto approval in case no one objects in a week's time. The more important part is asking before upload, than who gets to approve. We can document this in js team policy. Ruby team already documented it (expectations from people uploading breaking changes) https://wiki.debian.org/Teams/Ruby/Packaging#Updating_packages_with_API_breaking_changes > - Jonas > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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] Plan for legacy rollup plugins in bullseye (was Re: node-rollup-plugin-inject 4.0.2+~3.0.2-1 MIGRATED to testing)
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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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
[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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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#964205: node-request: fails to build with node-uuid 8.2 in experimental
Package: node-request Version: 2.88.1-4 Severity: important Build fails with this error when building with node-uuid 8.2.0-1 in experimental. Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './v4' is not defined by "exp orts" in /usr/share/nodejs/uuid/package.json Full build log attached. The severity will be raised to serious when node-uuid 8.2 is uploaded to unstable. sbuild (Debian sbuild) 0.79.1 (22 April 2020) on ilvala2 +==+ | node-request 2.88.1-4 (amd64)Fri, 03 Jul 2020 12:23:27 + | +==+ Package: node-request Version: 2.88.1-4 Source Version: 2.88.1-4 Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-6bafcec5-98b5-4f13-ae31-9481be46f977' with '<>' I: NOTICE: Log filtering will replace 'build/node-request-r1AngI/resolver-HS7SuM' with '<>' +--+ | Update chroot| +--+ Get:1 file:/build/node-request-r1AngI/resolver-RwMvH4/apt_archive ./ InRelease Ign:1 file:/build/node-request-r1AngI/resolver-RwMvH4/apt_archive ./ InRelease Get:2 file:/build/node-request-r1AngI/resolver-RwMvH4/apt_archive ./ Release [951 B] Get:2 file:/build/node-request-r1AngI/resolver-RwMvH4/apt_archive ./ Release [951 B] Get:3 file:/build/node-request-r1AngI/resolver-RwMvH4/apt_archive ./ Release.gpg Ign:3 file:/build/node-request-r1AngI/resolver-RwMvH4/apt_archive ./ Release.gpg Get:4 file:/build/node-request-r1AngI/resolver-RwMvH4/apt_archive ./ Packages [794 B] Ign:4 file:/build/node-request-r1AngI/resolver-RwMvH4/apt_archive ./ Packages Get:4 file:/build/node-request-r1AngI/resolver-RwMvH4/apt_archive ./ Packages [1576 B] Get:5 http://deb.debian.org/debian unstable InRelease [146 kB] Get:6 http://deb.debian.org/debian experimental InRelease [72.2 kB] Get:7 http://deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB] Get:8 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [27.9 kB] Get:9 http://deb.debian.org/debian unstable/main Sources 2020-07-02-1404.31.pdiff [14.7 kB] Get:10 http://deb.debian.org/debian unstable/main Sources 2020-07-02-2005.56.pdiff [6890 B] Get:11 http://deb.debian.org/debian unstable/main Sources 2020-07-03-0205.54.pdiff [5060 B] Get:12 http://deb.debian.org/debian unstable/main Sources 2020-07-03-0807.11.pdiff [9142 B] Get:13 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-02-1404.31.pdiff [8049 B] Get:14 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-02-2005.56.pdiff [9235 B] Get:15 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-03-0205.54.pdiff [26.6 kB] Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-03-0807.11.pdiff [8624 B] Get:12 http://deb.debian.org/debian unstable/main Sources 2020-07-03-0807.11.pdiff [9142 B] Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-03-0807.11.pdiff [8624 B] Get:17 http://deb.debian.org/debian experimental/main amd64 Packages [351 kB] Fetched 714 kB in 2s (319 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Local sources - /tmp/tmp.A0NSEi5tnn/node-request_2.88.1-4.dsc exists in /tmp/tmp.A0NSEi5tnn; copying to chroot I: NOTICE: Log filtering will replace 'build/node-request-r1AngI/node-request-2.88.1' with '<>' I: NOTICE: Log filtering will replace 'build/node-request-r1AngI' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper-compat (= 12), node-aws-sign2, node-aws4, node-bluebird, node-buffer-equal, node-caseless, node-combined-stream (>= 1.0.6~), node-extend (>= 3.0.2~), node-forever-agent (>= 0.6.1~), node-form-data (>= 2.3.2~), node-har-validator, node-http-signature, node-is-typedarray, node-isstream, node-json-stringify-safe (>= 5.0.1~), node-mime-types (>= 2.1.19~), node-oauth-sign (>= 0.9~), node-performance-now, node-qs (>= 6.5.2~), node-rimraf, node-safe-buffer, node-tape, node-tough-cookie,
[Pkg-javascript-devel] Bug#964206: node-http-signature: ftbfs with node-uuid 8.2 in experimental - Cannot read property 'on' of null
.0.3+dfsg-1 node-typedarray-to-buffer_3.0.3-3 node-uuid_8.2.0-1 node-verror_1.10.0-1 node-wrappy_1.0.2-1 node-write-file-atomic_3.0.3-1 nodejs_12.18.1~dfsg-1 openssl_1.1.1g-1 passwd_1:4.8.1-1 patch_2.7.6-6 perl_5.30.3-4 perl-base_5.30.3-4 perl-modules-5.30_5.30.3-4 perl-openssl-defaults_5 pkg-js-tools_0.9.37 po-debconf_1.0.21 sbuild-build-depends-main-dummy_0.invalid.0 sed_4.7-1 sensible-utils_0.0.12+nmu1 sysvinit-utils_2.96-3 tar_1.30+dfsg-7 tzdata_2020a-1 util-linux_2.35.2-6 xz-utils_5.2.4-1+b1 zlib1g_1:1.2.11.dfsg-2 +--+ | Build| +--+ Unpack source - -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 3.0 (quilt) Source: node-http-signature Binary: node-http-signature Architecture: all Version: 1.3.2-1 Maintainer: Debian Javascript Maintainers Uploaders: Pirate Praveen Homepage: https://github.com/joyent/node-http-signature/ Standards-Version: 4.5.0 Vcs-Browser: https://salsa.debian.org/js-team/node-http-signature Vcs-Git: https://salsa.d
[Pkg-javascript-devel] Bug#964207: node-node-rest-client: autopkgtest fails with node-uuid 8.2 in experimental
Package: node-node-rest-client Version: 2.5.0-4 Severity: important This package's autopkgtest failed with node-uuid 8.2 in experimental with error Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './v1' is not defined by "exports" in /usr/share/nodejs/uuid/package.json Full autopkgtest log (run in a clean lxc container) is attached. The severity of this bug will be raised to serious when node-uuid is uploaded to unstable. autopkgtest [17:45:29]: version 5.10 autopkgtest [17:45:29]: host ilvala2; command line: /usr/bin/autopkgtest --user debci --apt-upgrade --log-file=/tmp/node-uuid_8.2.0-1_amd64.xZ6b416lqk/autopkgtest/node-node-rest-client.log /home/pravi/forge/js-team/build-area/node-node-uuid_8.2.0-1_all.deb /home/pravi/forge/js-team/build-area/node-uuid_8.2.0-1_all.deb node-node-rest-client -- lxc --sudo autopkgtest-unstable-amd64 autopkgtest [17:45:44]: test bed setup Get:1 http://deb.debian.org/debian unstable InRelease [146 kB] Get:2 http://deb.debian.org/debian-debug unstable-debug InRelease [42.7 kB] Get:3 http://deb.debian.org/debian unstable/contrib Sources.diff/Index [27.8 kB] Get:4 http://deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB] Get:5 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index [27.8 kB] Get:6 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [27.9 kB] Get:7 http://deb.debian.org/debian unstable/contrib Sources 2020-07-03-0205.54.pdiff [403 B] Get:8 http://deb.debian.org/debian unstable/main Sources 2020-07-02-1404.31.pdiff [14.7 kB] Get:9 http://deb.debian.org/debian unstable/main Sources 2020-07-02-2005.56.pdiff [6,890 B] Get:10 http://deb.debian.org/debian unstable/main Sources 2020-07-03-0205.54.pdiff [5,060 B] Get:11 http://deb.debian.org/debian unstable/main Sources 2020-07-03-0807.11.pdiff [9,142 B] Get:7 http://deb.debian.org/debian unstable/contrib Sources 2020-07-03-0205.54.pdiff [403 B] Get:11 http://deb.debian.org/debian unstable/main Sources 2020-07-03-0807.11.pdiff [9,142 B] Get:12 http://deb.debian.org/debian unstable/contrib amd64 Packages 2020-07-02-1404.31.pdiff [212 B] Get:13 http://deb.debian.org/debian unstable/contrib amd64 Packages 2020-07-03-0205.54.pdiff [563 B] Get:14 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-02-1404.31.pdiff [8,049 B] Get:13 http://deb.debian.org/debian unstable/contrib amd64 Packages 2020-07-03-0205.54.pdiff [563 B] Get:15 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-02-2005.56.pdiff [9,235 B] Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-03-0205.54.pdiff [26.6 kB] Get:17 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-03-0807.11.pdiff [8,624 B] Get:17 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-03-0807.11.pdiff [8,624 B] Get:18 http://deb.debian.org/debian-debug unstable-debug/main Sources.diff/Index [27.9 kB] Get:19 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages.diff/Index [27.9 kB] Get:20 http://incoming.debian.org/debian-buildd buildd-unstable InRelease [39.7 kB] Get:21 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-02-1404.31.pdiff [5,341 B] Get:22 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-02-2005.56.pdiff [8,002 B] Get:23 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-03-0205.54.pdiff [2,158 B] Get:24 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-03-0807.11.pdiff [6,826 B] Get:25 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-02-1404.31.pdiff [8,886 B] Get:24 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-03-0807.11.pdiff [6,826 B] Get:26 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-02-2005.56.pdiff [25.5 kB] Get:27 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-03-0205.54.pdiff [11.1 kB] Get:28 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-03-0807.11.pdiff [6,119 B] Get:28 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-03-0807.11.pdiff [6,119 B] Get:29 http://incoming.debian.org/debian-buildd buildd-unstable/main Sources [88.7 kB] Get:30 http://incoming.debian.org/debian-buildd buildd-unstable/contrib Sources [1,876 B] Get:31 http://incoming.debian.org/debian-buildd buildd-unstable/contrib amd64 Packages [2,552 B] Get:32 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages [118 kB] Fetched 770 kB in 1s (516 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following packages will be upgraded: dbus libdbus-1-3 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 454 kB of archives. After this operation, 2,048 B of additional disk space will be used. Get:1 http://deb.debian.org/debian
[Pkg-javascript-devel] Bug#964218: node-yarnpkg: autopkgtest fails with node-uuid 8.2 from experimental - "Cannot read property 'v4' of undefined"
Package: node-yarnpkg Version: 1.22.4-3 Severity: important Full build log is attached. This was run in a clean and uptodate lxc container using salsa.debian.org/ruby-team/meta/build script. autopkgtest [18:26:50]: version 5.10 autopkgtest [18:26:50]: host ilvala2; command line: /usr/bin/autopkgtest --user debci --apt-upgrade --log-file=/tmp/node-uuid_8.2.0-1_amd64.Ix8K1VsEM6/autopkgtest/node-yarnpkg.log /home/pravi/forge/js-team/build-area/node-node-uuid_8.2.0-1_all.deb /home/pravi/forge/js-team/build-area/node-uuid_8.2.0-1_all.deb node-yarnpkg -- lxc --sudo autopkgtest-unstable-amd64 autopkgtest [18:27:02]: test bed setup Hit:1 http://deb.debian.org/debian unstable InRelease Hit:2 http://incoming.debian.org/debian-buildd buildd-unstable InRelease Hit:3 http://deb.debian.org/debian-debug unstable-debug InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. autopkgtest [18:27:05]: testbed dpkg architecture: amd64 autopkgtest [18:27:05]: testbed running kernel: Linux 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) autopkgtest [18:27:06]: apt-source node-yarnpkg Get:1 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (dsc) [7,508 B] Get:2 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [6,144 B] Get:3 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [2,652 B] Get:4 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [7,888 B] Get:5 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [2,432 B] Get:6 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [14.8 kB] Get:7 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [1,756 B] Get:8 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [1,440 B] Get:9 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [2,100 B] Get:10 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [4,780 B] Get:11 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [4,604 B] Get:12 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [2,936 B] Get:13 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [6,780 B] Get:14 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [28.0 kB] Get:15 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [3,212 B] Get:16 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [6,864 B] Get:17 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [5,516 B] Get:18 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [72.9 MB] Get:19 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (diff) [12.1 kB] gpgv: unknown type of key resource 'trustedkeys.kbx' gpgv: keyblock resource '/home/debci/.gnupg/trustedkeys.kbx': General error gpgv: Signature made Sat 02 May 2020 07:38:13 AM UTC gpgv:using RSA key D30863E26020E543F4719A838F53E0193B294B75 gpgv: Can't check signature: No public key dpkg-source: warning: failed to verify signature on ./node-yarnpkg_1.22.4-3.dsc tar: Ignoring unknown extended header keyword 'NODETAR.depth' tar: Ignoring unknown extended header keyword 'NODETAR.follow' tar: Ignoring unknown extended header keyword 'NODETAR.ignoreFiles.0' tar: Ignoring unknown extended header keyword 'NODETAR.ignoreFiles.1' tar: Ignoring unknown extended header keyword 'NODETAR.ignoreFiles.2' tar: Ignoring unknown extended header keyword 'NODETAR.package.name' tar: Ignoring unknown extended header keyword 'NODETAR.package.version' tar: Ignoring unknown extended header keyword 'NODETAR.package.description' tar: Ignoring unknown extended header keyword 'NODETAR.package.keywords.0' tar: Ignoring unknown extended header keyword 'NODETAR.package.keywords.1' tar: Ignoring unknown extended header keyword 'NODETAR.package.license' tar: Ignoring unknown extended header keyword 'NODETAR.package.author' tar: Ignoring unknown extended header keyword 'NODETAR.package.files.0' tar: Ignoring unknown extended header keyword 'NODETAR.package.main' tar: Ignoring unknown extended header keyword 'NODETAR.package.repository' tar: Ignoring unknown extended header keyword 'NODETAR.package.scripts.test' tar: Ignoring unknown extended header keyword 'NODETAR.package.dependencies.babel-plugin-transform-strict-mode' tar: Ignoring unknown extended header keyword 'NODETAR.package.dependencies.builtin-modules' tar: Ignoring unknown extended header keyword 'NODETAR.package.devDependencies.babel-core' tar: Ignoring unknown extended header keyword 'NODETAR.package.devDependencies.babel-plugin-check-es2015-constants' tar: Ignoring unknown extended header keyword 'NODETAR.package.devDependencies.babel-plugin-external-helpers' tar:
[Pkg-javascript-devel] Bug#964218: Bug#964218: Bug#964218: node-yarnpkg: autopkgtest fails with node-uuid 8.2 from experimental - "Cannot read property 'v4' of undefined"
On 2020, ജൂലൈ 4 2:39:27 AM IST, Paolo Greppi wrote: >Updating that dependency is already in upsream's TODO list >https://github.com/yarnpkg/yarn/issues/6829 >.. but they seem to lag on updating dependencies. > >I guess it would require fixing against this breaking change: >https://github.com/uuidjs/uuid/blob/master/CHANGELOG.md#-breaking-changes >and upstream the patch .. > >Why do you need uuid v8 if I may ask ? gitlab needs it. Currently all unpackaged dependencies are pulled via yarn install, but I'm trying package it one by one. But even when uuid is installed via yarn for gitlab, second time when I run yarnpkg install (when updating gitlab), yarnpkg fails with this error. So I have to manually remove node_modules/uuid and run update again. Though it seems to happen only on node 12 (sid) and not on node 10 (buster). -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On Thu, Jun 25, 2020 at 01:41, Pirate Praveen wrote: On Tue, Jun 23, 2020 at 2:40 pm, Sean Whitton wrote: Thanks. I think at this point we probably need to wait to hear from Bastian, who processed the REJECT. In the meantime, it would be good to reupload with the reason for the binary package split documented, as previously described. I have added a debian/README.Debian, mentioned this in the changelog and uploaded again. It is over two weeks since I added debian/README.Debian, some feedback on it (if it is sufficient or if you need more time to discuss it inside team) would be good. -- 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#964218: Bug#964218: Bug#964218: node-yarnpkg: autopkgtest fails with node-uuid 8.2 from experimental - "Cannot read property 'v4' of undefined"
On Fri, Jul 3, 2020 at 23:09, Paolo Greppi wrote: Updating that dependency is already in upsream's TODO list https://github.com/yarnpkg/yarn/issues/6829 .. but they seem to lag on updating dependencies. I guess it would require fixing against this breaking change: https://github.com/uuidjs/uuid/blob/master/CHANGELOG.md#-breaking-changes and upstream the patch .. I tried fixing this in babel6 branch (as master is broken - I found it broke after merging babel 7 branch), but autopkgtest still fails with the same error. Can you check/review the patch? Could this be a bug in uuid? -- 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#963761: Bug#963761: Bug#963761: Bug#963761: Bug#963761: Bug#963761: node-node-sass: missing versioned dependency relation?: Sass could not find a binding for your current en
On Sun, Jul 12, 2020 at 12:52, Jonas Smedegaard wrote: I think that when we declare only¹ lower bounds, we do avoid the biggest headache of nodejs failing to transition - and reduce the problem to each package requiring a binNMU being flagged as such. Please others chime in if you think I am mistaken about that. Agreed. Upper bounds are generally extra work as you have to manually remove them when new versions are uploaded. -- 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-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On 2020, ജൂൺ 23 2:56:37 AM IST, Sean Whitton wrote:
>Hello Pirate,
>
>On Mon 22 Jun 2020 at 12:58AM +0530, Pirate Praveen wrote:
>
>> We usually use Provides instead of splitting when we can remove the Depends
>> on the interpreter. For example node-clipboard provides libjs-clipboard.js.
>> This works when the node package does not ship a user facing significant
>> executable. User facing executable as separate binary was recognized as a
>> valid reason by CTTE in the ruling I quoted in my first reply.
>>
>> In case of this particular package, katex binary also provide a command line
>> interface via katex command. So we cannot drop the depends on nodejs (rc
>> bug, nodejs is not an optional component but the interpreter needed to run
>> the katex program). Avoiding unnecessary dependency on interpreters was
>> achieved in all previous instances by removing the dependency on pure
>> libraries. We expect whichever user facing program depending on the library
>> to set Depends on the interpreter. For example gitlab depending on nodejs is
>> enough for node-clipboard to satisfy dependency on nodejs. In this case
>> katex itself is a user facing program not tied to nodejs development (it is
>> used for maths typesetting). So we cannot reasonably expect a user wanting
>> to use katex will have nodejs installed already.
>
>Would someone want to use libjs-katex without nodejs installed?
Jonas answered it already.
>> I thought the CTTE guideline on this specific case of user facing executable
>> was enough. They could have just asked for an explanation before rejecting.
>
>You should ensure it's visible in the source package, in
>README.{source,Debian} and/or d/changelog.
>
Okay. I will do it from next time.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On Tue, Jun 23, 2020 at 2:40 pm, Sean Whitton wrote: Hello, On Tue 23 Jun 2020 at 01:47AM +02, Jonas Smedegaard wrote: Quoting Sean Whitton (2020-06-22 23:26:37) Would someone want to use libjs-katex without nodejs installed? Yes: Pandoc can produce output which uses katex rendered with the Javascript interpreter of web browsers, not on OS-bound Javascript rendering like Node.js. Currently Pandoc suggests node-katex, but pulling in Node.js is unneeded baggage. For some users it may even be bad: Node.js may not be covered by security support for as long as Firefox (due to the extraordinary treatment of Firefox in stable Debian). Thanks. I think at this point we probably need to wait to hear from Bastian, who processed the REJECT. In the meantime, it would be good to reupload with the reason for the binary package split documented, as previously described. I have added a debian/README.Debian, mentioned this in the changelog and uploaded again. -- Sean Whitton -- 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#962039: Bug#962037: Plan B for not being able to replicate upstream exports exactly
On 2020, ജൂൺ 16 7:46:01 AM IST, Daniel Ring wrote: >Control: reopen 962037 >Control: reopen 962039 > >Sorry about closing the bugs early, I'm used to close-on-commit instead >of close-on-release and I forgot Debian handles things differently. I >updated Rainloop's changelog on Salsa to indicate that these are fixed. Uploaded. >I didn't realize that this bug was due to Rainloop blocking the >migration of node-less to unstable; my comment about testing >experimental versions was because this started off as a node-less bug, >and it looked like most of the issues weren't related to Rainloop. I'm >happy to help with transitions from the Rainloop side but it may take me >up to a few weeks to respond to non-security issues. OK, no worries. I initially thought it was a rainloop bug, then I had to make more changes to less.js build and then confirmed rainloop needs fixing as well. >Is pkg-js-tools stable, and is there good documentation for it? I took a >quick look but only found a README with a list of debhelper hooks. My >main argument for using flat files for Rainloop's bundled dependencies >is that I only look at this package once or twice a year when upstream >releases a new version, and I don't want to relearn the tooling each >time. (That's also why I replaced my custom Makefile with upstream's >build system.) I agree that Quilt is a better way to handle the patches >to the bundled libraries though. The thing is, other people in the team can help fix things when required and using standard tools and processes helps. See https://wiki.debian.org/Javascript/GroupSourcesTutorial and you can ask in pkg-javascript-devel for help. >By "broken in unstable" I just meant Rainloop's code in Salsa, which now >depends on experimental node-less to build; the compiled package is fine >either way. (Also, it looks like updated node-less is now in unstable, >so it's not broken anymore.) I uploaded fixed rainloop, so we are good now. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
changed. Updating the path resolved the build error. I pushed the fixes for both issues to the Rainloop repository on salsa.d.o. Rainloop now builds successfully on current unstable with node-less from experimental. Thanks, I can upload it to unstable. -- Daniel On 6/5/2020 9:02 AM, Pirate Praveen wrote: On Fri, Jun 5, 2020 at 5:11 pm, Pirate Praveen wrote: On Fri, Jun 5, 2020 at 3:10 pm, Pirate Praveen wrote: This is likely broken by node-merge-stream update from 1.0 to 2.0. node-merge-stream is a build dependeny of node-autolinker. Tried building with autolinker 3.x in embed-autolinker-3 branch, but the same failure. I tried to run the upstream test suite for node-autolinker (yarnpkg install, yarnpkg test), but it seems gulp 3 is segfaulting in debian, tried with node 10 and 12 via npm with the same results. I had seen the same failure when trying to run gulp in node-puka as well. All unit tests passed on autolinker master which has gulp 4 with merge-stream 2.0, so it is not merge-stream change that broke. -- 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#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
On Mon, Jun 15, 2020 at 4:07 pm, Pirate Praveen wrote: You don't have to upload broken packages to unstable. You can wait till less.js lands in unstable to upload your changes to experimental. The idea is to give you a chance to fix your package before it actually breaks. Also please don't close bugs before the package is uploaded. I can sponsor it after you prepare a changelog for the new version. Please close the bugs in the changelog, this helps us keep track of fixed versions. -- 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#962039: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
On Mon, Jun 15, 2020 at 4:07 pm, Pirate Praveen wrote: Please don't invent your own methods and follow the standards used by the rest of the team. If everyone invents their own methods to embed, that makes it unnecessarily hard to collaborate as a team. I don't think the rest of the js team agrees with your judgement here. This method makes is harder to update embedded dependencies and it essentially become a fork. You can use the normal patching workflow with quilt for modules embedded via pkg-js-tools (it is not even specific to pkg-js-tools, it is supported by dpkg and used across the archive). Js Team, Please comment your opinion here as we have a difference in embed strategy here. Just a clarification, there are two ways of embedding modules, 1, using debian/watch component with debian/gbp.conf and 2, adding to debian/build_modules or debian/test_modules Only method 1 allows using quilt patching. I assume he was referring to method 2. I was referring to method 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] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On 2020, ജൂൺ 21 10:17:57 PM IST, Sean Whitton wrote: >[speaking as an FTP team member, not ctte member, though this is *not* >an official statement made on behalf of the whole FTP team] > >Hello Jonas, > >On Sun 21 Jun 2020 at 10:48AM +02, Jonas Smedegaard wrote: > >> Could you please elaborate a bit on your opinion that the introduced >> split into katex and libjs-katex is unnecessary? > >I have not looked at this particular package, but here is what I >understand to be the team's consensus: the FTP team wants to see some >technical purpose which is served by the binary package split, to >justify taking up more space in the Packages file. We will also object >if this technical purpose could be easily served by something other than >a binary package split (e.g. by adding Provides: entries). We usually use Provides instead of splitting when we can remove the Depends on the interpreter. For example node-clipboard provides libjs-clipboard.js. This works when the node package does not ship a user facing significant executable. User facing executable as separate binary was recognized as a valid reason by CTTE in the ruling I quoted in my first reply. In case of this particular package, katex binary also provide a command line interface via katex command. So we cannot drop the depends on nodejs (rc bug, nodejs is not an optional component but the interpreter needed to run the katex program). Avoiding unnecessary dependency on interpreters was achieved in all previous instances by removing the dependency on pure libraries. We expect whichever user facing program depending on the library to set Depends on the interpreter. For example gitlab depending on nodejs is enough for node-clipboard to satisfy dependency on nodejs. In this case katex itself is a user facing program not tied to nodejs development (it is used for maths typesetting). So we cannot reasonably expect a user wanting to use katex will have nodejs installed already. >So I would assume that the FTP team member who processed this upload >couldn't see how a technical purpose was being served by the split. If >Pirate could explain some technical purpose that was missed that would >be helpful. I thought the CTTE guideline on this specific case of user facing executable was enough. They could have just asked for an explanation before rejecting. >I don't think that the bar is particularly high here. Even if an FTP >team member wouldn't themselves solve the problem by introducing a >binary package split, if it's clear that the maintainer has consciously >chosen to use a binary package split to solve a problem and that's a >reasonable way to go about solving the problem, we'll sign off on it. > Thanks. I hope that explanation was enough. Let me know if that is not sufficient. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On 2020, ജൂൺ 21 11:55:54 PM IST, Jonas Smedegaard wrote: >Quoting Sean Whitton (2020-06-21 18:47:57) >> [speaking as an FTP team member, not ctte member, though this is *not* >> an official statement made on behalf of the whole FTP team] >> >> Hello Jonas, >> >> On Sun 21 Jun 2020 at 10:48AM +02, Jonas Smedegaard wrote: >> >> > Could you please elaborate a bit on your opinion that the introduced >> > split into katex and libjs-katex is unnecessary? >> >> I have not looked at this particular package, but here is what I >> understand to be the team's consensus: the FTP team wants to see some >> technical purpose which is served by the binary package split, to >> justify taking up more space in the Packages file. We will also object >> if this technical purpose could be easily served by something other than >> a binary package split (e.g. by adding Provides: entries). >> >> So I would assume that the FTP team member who processed this upload >> couldn't see how a technical purpose was being served by the split. If >> Pirate could explain some technical purpose that was missed that would >> be helpful. >> >> I don't think that the bar is particularly high here. Even if an FTP >> team member wouldn't themselves solve the problem by introducing a >> binary package split, if it's clear that the maintainer has consciously >> chosen to use a binary package split to solve a problem and that's a >> reasonable way to go about solving the problem, we'll sign off on it. > >Thanks for the clarification, Sean. > >I think that was quite helpful. I will let Pirate Praveen continue from >here. Thanks Jonas for asking this question. I hope my explanation was clear. >@Sean: You posted twice to the list, but I accidentally rejected one of >them - if the other mail was relevant then please send again and I will >approve. Sorry for the confusion. > > > - Jonas > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On 2020, ജൂൺ 19 1:40:09 AM IST, Bastian Blank wrote: > >The introduces an unnecessary split into katex and libjs-katex. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54 * User-facing executable programs associated with a library should usually be packaged in a non-library binary package whose name reflects the program (for example tappy, flatpak, parted) or collection of related programs (for example kmod, libsecret-tools, libglib2.0-bin), rather than being bundled in the same binary package as the runtime library. Do you disagree with recommendation of ctte or you don't think it does not apply here? > > >=== > >Please feel free to respond to this email if you don't understand why >your files were rejected, or if you upload new files which address our >concerns. > > >-- >Pkg-javascript-devel mailing list >Pkg-javascript-devel@alioth-lists.debian.net >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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
On 2020, മേയ് 21 1:08:32 PM IST, Pirate Praveen wrote: > > >On 2020, മേയ് 21 2:34:43 AM IST, Xavier wrote: >>Hi all, >> >>here is the current result given by dak. Still to fix: >> * libjs-webrtc-adapter > >This can be fixed by switching from browserify-lite to webpack (or possibly >rollup too which is lighter than webpack). I have a proof of concept commit in >babel7 branch which has all tests passing. With today's upload of libjs-webrtc-adapter by Jonas (rollup was used), this is cleared. >> * 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. >> * rails > >rails is fixed in experimental (rails 6) and will come to unstable when rail 6 >transition starts, if we fix node-yarnpkg before that I will fix in unstable >too (rails 5). >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity. > >-- >Pkg-javascript-devel mailing list >Pkg-javascript-devel@alioth-lists.debian.net >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
Control: reassign -1 rainloop Control: retitle -1 rainloop ftbfs with node-less 3.11.2 in experimental On Wed, Jun 3, 2020 at 1:27 am, Pirate Praveen wrote: We could try building rainloop with npm version of less 3.11.2 to confirm if it is rainloop that needs updating or less that needs fixing. I have reproduced the same error with less npm dist tarball in embed-less-npm-dist-tar branch of rainloop in salsa, so reassigning back to rainloop. [05:52:23] Finished 'lightgalleryFontsCopy' after 497 ms [05:52:23] Finished 'fontasticFontsCopy' after 941 ms [05:52:26] Finished 'ckeditorCopyPlugins' after 4.37 s (node:36015) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_ARG_TYPE]: The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type object at Function.from (buffer.js:231:9) at new Buffer (buffer.js:181:17) at /<>/debian/build/gulp-less.js:40:23 at /<>/debian/build_modules/less/dist/less.cjs.js:10288:17 at /<>/debian/build_modules/less/dist/less.cjs.js:10520:17 at ImportVisitor.finish [as _finish] (/<>/debian/build_modules/less/dist/less.cjs.js:6798:28) at ImportVisitor._onSequencerEmpty (/<>/debian/build_modules/less/dist/less.cjs.js:5097:14) at ImportSequencer.tryRun (/<>/debian/build_modules/less/dist/less.cjs.js:5064:18) at /<>/debian/build_modules/less/dist/less.cjs.js:5034:29 at fileParsedFunc (/<>/debian/build_modules/less/dist/less.cjs.js:10167:21) (node:36015) 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(). (rejection id: 1) [05:52:35] Finished '' after 13 s [05:52:35] Starting 'jsLibs'... [05:52:35] Starting 'jsApp'... [05:52:35] Starting 'jsAdmin'... [05:52:35] 'jsLibs' errored after 13 ms [05:52:35] Error: File not found with singular glob: /usr/lib/nodejs/autolinker/dist/Autolinker.js (if this was purposeful, use `allowEmpty` option) at Glob. (/usr/share/nodejs/glob-stream/readable.js:84:17) at Object.onceWrapper (events.js:286:20) at Glob.emit (events.js:198:13) at Glob.EventEmitter.emit (domain.js:448:20) at Glob._finish (/usr/share/nodejs/glob/glob.js:197:8) at done (/usr/share/nodejs/glob/glob.js:182:14) at Glob._processSimple2 (/usr/share/nodejs/glob/glob.js:688:12) at /usr/share/nodejs/glob/glob.js:676:10 at Glob._stat2 (/usr/share/nodejs/glob/glob.js:772:12) at lstatcb_ (/usr/share/nodejs/glob/glob.js:764:12) [05:52:35] 'rainloop' errored after 14 s [05:52:35] The following tasks did not complete: , , cssMainBuild, jsApp, jsAdmin [05:52:35] Did you forget to signal async completion? -- 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#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
On Fri, Jun 5, 2020 at 11:36 am, Pirate Praveen wrote: I have reproduced the same error with less npm dist tarball in embed-less-npm-dist-tar branch of rainloop in salsa, so reassigning back to rainloop. [05:52:23] Finished 'lightgalleryFontsCopy' after 497 ms [05:52:23] Finished 'fontasticFontsCopy' after 941 ms [05:52:26] Finished 'ckeditorCopyPlugins' after 4.37 s (node:36015) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_ARG_TYPE]: The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type object at Function.from (buffer.js:231:9) at new Buffer (buffer.js:181:17) at /<>/debian/build/gulp-less.js:40:23 at /<>/debian/build_modules/less/dist/less.cjs.js:10288:17 at /<>/debian/build_modules/less/dist/less.cjs.js:10520:17 at ImportVisitor.finish [as _finish] (/<>/debian/build_modules/less/dist/less.cjs.js:6798:28) at ImportVisitor._onSequencerEmpty (/<>/debian/build_modules/less/dist/less.cjs.js:5097:14) at ImportSequencer.tryRun (/<>/debian/build_modules/less/dist/less.cjs.js:5064:18) at /<>/debian/build_modules/less/dist/less.cjs.js:5034:29 at fileParsedFunc (/<>/debian/build_modules/less/dist/less.cjs.js:10167:21) (node:36015) 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(). (rejection id: 1) I have fixed this error in master by embedding a newer version of gulp-less. [05:52:35] Finished '' after 13 s [05:52:35] Starting 'jsLibs'... [05:52:35] Starting 'jsApp'... [05:52:35] Starting 'jsAdmin'... [05:52:35] 'jsLibs' errored after 13 ms [05:52:35] Error: File not found with singular glob: /usr/lib/nodejs/autolinker/dist/Autolinker.js (if this was purposeful, use `allowEmpty` option) at Glob. (/usr/share/nodejs/glob-stream/readable.js:84:17) This error is still there. at Object.onceWrapper (events.js:286:20) at Glob.emit (events.js:198:13) at Glob.EventEmitter.emit (domain.js:448:20) at Glob._finish (/usr/share/nodejs/glob/glob.js:197:8) at done (/usr/share/nodejs/glob/glob.js:182:14) at Glob._processSimple2 (/usr/share/nodejs/glob/glob.js:688:12) at /usr/share/nodejs/glob/glob.js:676:10 at Glob._stat2 (/usr/share/nodejs/glob/glob.js:772:12) at lstatcb_ (/usr/share/nodejs/glob/glob.js:764:12) [05:52:35] 'rainloop' errored after 14 s [05:52:35] The following tasks did not complete: , , cssMainBuild, jsApp, jsAdmin [05:52:35] Did you forget to signal async completion? -- 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 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#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
On Fri, Jun 5, 2020 at 11:54 am, Pirate Praveen wrote: On Fri, Jun 5, 2020 at 11:36 am, Pirate Praveen wrote: I have reproduced the same error with less npm dist tarball in embed-less-npm-dist-tar branch of rainloop in salsa, so reassigning back to rainloop. [05:52:23] Finished 'lightgalleryFontsCopy' after 497 ms [05:52:23] Finished 'fontasticFontsCopy' after 941 ms [05:52:26] Finished 'ckeditorCopyPlugins' after 4.37 s (node:36015) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_ARG_TYPE]: The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type object at Function.from (buffer.js:231:9) at new Buffer (buffer.js:181:17) at /<>/debian/build/gulp-less.js:40:23 at /<>/debian/build_modules/less/dist/less.cjs.js:10288:17 at /<>/debian/build_modules/less/dist/less.cjs.js:10520:17 at ImportVisitor.finish [as _finish] (/<>/debian/build_modules/less/dist/less.cjs.js:6798:28) at ImportVisitor._onSequencerEmpty (/<>/debian/build_modules/less/dist/less.cjs.js:5097:14) at ImportSequencer.tryRun (/<>/debian/build_modules/less/dist/less.cjs.js:5064:18) at /<>/debian/build_modules/less/dist/less.cjs.js:5034:29 at fileParsedFunc (/<>/debian/build_modules/less/dist/less.cjs.js:10167:21) (node:36015) 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(). (rejection id: 1) I have fixed this error in master by embedding a newer version of gulp-less. [05:52:35] Finished '' after 13 s [05:52:35] Starting 'jsLibs'... [05:52:35] Starting 'jsApp'... [05:52:35] Starting 'jsAdmin'... [05:52:35] 'jsLibs' errored after 13 ms [05:52:35] Error: File not found with singular glob: /usr/lib/nodejs/autolinker/dist/Autolinker.js (if this was purposeful, use `allowEmpty` option) at Glob. (/usr/share/nodejs/glob-stream/readable.js:84:17) This error is still there. This is likely broken by node-merge-stream update from 1.0 to 2.0. node-merge-stream is a build dependeny of node-autolinker. -- 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#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
On Fri, Jun 5, 2020 at 3:10 pm, Pirate Praveen wrote: This is likely broken by node-merge-stream update from 1.0 to 2.0. node-merge-stream is a build dependeny of node-autolinker. Tried building with autolinker 3.x in embed-autolinker-3 branch, but the same failure. I tried to run the upstream test suite for node-autolinker (yarnpkg install, yarnpkg test), but it seems gulp 3 is segfaulting in debian, tried with node 10 and 12 via npm with the same results. I had seen the same failure when trying to run gulp in node-puka as well. $ yarnpkg test yarn run v1.22.4 warning ../../../package.json: No license field $ gulp test gulp[147975]: ../src/node_contextify.cc:635:static void node::contextify::ContextifyScript::New(const v8::FunctionCallbackInfo&): Assertion `args[1]->IsString()' failed. 1: 0x8fb090 node::Abort() [gulp] 2: 0x8fb165 [gulp] 3: 0x92f95e node::contextify::ContextifyScript::New(v8::FunctionCallbackInfo const&) [gulp] 4: 0xb9029b [gulp] 5: 0xb92232 v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) [gulp] 6: 0x329c5c1dbe1d Aborted error Command failed with exit code 134. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command. -- 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#962037: Bug#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
On Wed, Jun 3, 2020 at 12:29 am, Pirate Praveen
wrote:
On Tue, Jun 2, 2020 at 10:33 pm, Pirate Praveen
wrote:
I'm trying to close the gap between upstream build and our builds by
using rollup to generate cjs file as well, but build fails with
this error.
/usr/bin/node -e require\(\"./.\"\)
/home/pravi/forge/js-team/less.js/dist/less.cjs.js:17699
const { Barrett } = BigInteger.prototype;
^
TypeError: Cannot read property 'prototype' of undefined
at Object.
(/home/pravi/forge/js-team/less.js/dist/less.cjs.js:17699:32)
This code comes from node-ecc-jsbn and it looks like a bug there,
its package.json wants jsbn 0.1 but we already have 1.0
This was caused when copied the rollup.config.js for umd to build
cjs, it had BUNDLE = true which created this issue. Also there was no
need to use babel except for ES module to CJS conversion which rollup
alone can do. Hopefully this will fix the issue. Running the tests
now.
Now I think we are closer to how upstream ships these files, but
rainloop still fails to build
(node:423913) UnhandledPromiseRejectionWarning: TypeError
[ERR_INVALID_ARG_TYPE]: The first argument must be one of type string,
Buffer, ArrayBuffer, Array, or Array-like Object. Received type object
at Function.from (buffer.js:231:9)
at new Buffer (buffer.js:181:17)
at /<>/debian/build/gulp-less.js:40:23
at parse (/usr/share/nodejs/less/dist/less.cjs.js:11461:17)
at Parser.parse (/usr/share/nodejs/less/dist/less.cjs.js:11711:21)
at ImportVisitor.finish [as _finish]
(/usr/share/nodejs/less/dist/less.cjs.js:7701:28)
at ImportVisitor._onSequencerEmpty
(/usr/share/nodejs/less/dist/less.cjs.js:5832:14)
at ImportSequencer.tryRun
(/usr/share/nodejs/less/dist/less.cjs.js:5797:18)
at /usr/share/nodejs/less/dist/less.cjs.js:5766:29
at fileParsedFunc (/usr/share/nodejs/less/dist/less.cjs.js:11331:21)
(node:423913) 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(). (rejection id: 1)
[19:54:10] Finished '' after 18 s
[19:54:10] Starting 'jsLibs'...
[19:54:10] Starting 'jsApp'...
[19:54:10] Starting 'jsAdmin'...
[19:54:10] 'jsLibs' errored after 17 ms
[19:54:10] Error: File not found with singular glob:
/usr/lib/nodejs/autolinker/dist/Autolinker.js (if this was purposeful,
use `allowEmpty` option)
at Glob.
(/usr/share/nodejs/glob-stream/readable.js:84:17)
at Object.onceWrapper (events.js:286:20)
at Glob.emit (events.js:198:13)
at Glob.EventEmitter.emit (domain.js:448:20)
at Glob._finish (/usr/share/nodejs/glob/glob.js:197:8)
at done (/usr/share/nodejs/glob/glob.js:182:14)
at Glob._processSimple2 (/usr/share/nodejs/glob/glob.js:688:12)
at /usr/share/nodejs/glob/glob.js:676:10
at Glob._stat2 (/usr/share/nodejs/glob/glob.js:772:12)
at lstatcb_ (/usr/share/nodejs/glob/glob.js:764:12)
[19:54:10] 'rainloop' errored after 18 s
[19:54:10] The following tasks did not complete: , ,
cssMainBuild, jsApp, jsAdmin
[19:54:10] Did you forget to signal async completion?
We could try building rainloop with npm version of less 3.11.2 to
confirm if it is rainloop that needs updating or less that needs fixing.
--
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#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
On Fri, Jun 5, 2020 at 5:11 pm, Pirate Praveen wrote: On Fri, Jun 5, 2020 at 3:10 pm, Pirate Praveen wrote: This is likely broken by node-merge-stream update from 1.0 to 2.0. node-merge-stream is a build dependeny of node-autolinker. Tried building with autolinker 3.x in embed-autolinker-3 branch, but the same failure. I tried to run the upstream test suite for node-autolinker (yarnpkg install, yarnpkg test), but it seems gulp 3 is segfaulting in debian, tried with node 10 and 12 via npm with the same results. I had seen the same failure when trying to run gulp in node-puka as well. All unit tests passed on autolinker master which has gulp 4 with merge-stream 2.0, so it is not merge-stream change that broke. -- 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: node-rollup-plugin-buble build depends on the babeljs provides that will not be in bullseye
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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined
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 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. 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#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined
I'm wondering if this will require another bootstraping cycle as node-babel7 autopkgtest is also broken and it depends on itself. -- 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
On Sun, Jul 26, 2020 at 22:24, Pirate Praveen wrote: Babel build situation is indeed a mess. It is even worse than I estimated. We can no longer build it with npm DEB_BUILD_PROFILES=pkg.node-babel7.npm sbuild ... HOME=`pwd` npm i npm ERR! code EUNSUPPORTEDPROTOCOL npm ERR! Unsupported URL Type "link:": link:./eslint/babel-eslint-config-internal we have to change it to yarn. -- 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-less-loader_5.0.1-1_amd64.changes REJECTED
On Thu, Jul 23, 2020 at 21:10, Thorsten Alteholz wrote: Hi, according to LICENSE the copyright holder is "JS Foundation and other contributors". Probably upstream can shed some light on this. Fixed an reuploaded. npm2deb takes Author in package.json as copyright holder by default, but sometimes it does not match with LICENSE file. I update copyright to match LICENSE file. Thanks! Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. -- 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 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: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined
On 2020, ജൂലൈ 27 1:42:32 AM IST, Nicolas Mora wrote: >I'm not sure yet if this would fix the bug but in all the build log >errors, I see that the file /usr/share/nodejs/lodash/_baseOrderBy.js is >always the source of the error. > >The file _baseOrderBy.js in the package seems buggy for an unresolved reson. > >File in node-lodash unstable package: >4.17.19+dfsg-1 _baseOrderBy.js https://paste.debian.net/1157886/ > >File in node-lodash bullseye package >4.17.15+dfsg-2 _baseOrderBy.js https://paste.debian.net/1157887/ > >In the unstable version, the call to isArray line 24 is the root of errors. This is possibly introduced by the security fix, but I can't be sure. Hope someone else can clarify. >Also, I see that the upstream version 4.17.19 isn't tagged as latest >release, 4.17.16 is, maybe it's worth a try to package 4.17.16 instead? > >https://github.com/lodash/lodash/releases 4.17.19 is correct as per https://github.com/lodash/lodash/issues/4837#issuecomment-655648024 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined
Control: reopen -1 On Mon, Jul 27, 2020 at 00:32, Pirate Praveen wrote: This did not fix the issue :( So we have to reopen this bug once the upload reaches the archive (which will close this bug as fixed). Thanks to the brave new world of embedding eveything and reducing the number of js packages. Complicated build systems in favor of reducing the metadata size, ftw! -- 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: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined
On Sun, Jul 26, 2020 at 22:43, Pirate Praveen wrote: On Sun, Jul 26, 2020 at 22:24, Pirate Praveen wrote: Babel build situation is indeed a mess. It is even worse than I estimated. We can no longer build it with npm DEB_BUILD_PROFILES=pkg.node-babel7.npm sbuild ... HOME=`pwd` npm i npm ERR! code EUNSUPPORTEDPROTOCOL npm ERR! Unsupported URL Type "link:": link:./eslint/babel-eslint-config-internal we have to change it to yarn. This did not fix the issue :( So we have to reopen this bug once the upload reaches the archive (which will close this bug as fixed). -- 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-markdown-it_10.0.0+dfsg-1_amd64.changes REJECTED
On 2020, ജൂലൈ 12 11:30:09 AM IST, Sean Whitton wrote: > >+--+ >| REJECT reasoning | >+--+ > >test/fixtures/commonmark/spec.txt is under a different license. Fixed and reuploaded. >+--+ >|Other comments| >+--+ > >Copyright years for linkify-it and mdurl should include 2015. > >+--+ >| N.B. | >+--+ > >This review may not be exhaustive. Please check your source package >against your d/copyright and the ftpmaster REJECT-FAQ, throughly, >before uploading to NEW again. > >Thank you for your time and contribution! > >Sean > > > > >=== > >Please feel free to respond to this email if you don't understand why >your files were rejected, or if you upload new files which address our >concerns. > > >-- >Pkg-javascript-devel mailing list >Pkg-javascript-devel@alioth-lists.debian.net >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined
Control: forwarded -1 https://github.com/lodash-archive/lodash-cli/pull/141 On Sun, Jul 26, 2020 at 16:12, Nicolas Mora wrote: I'm not sure yet if this would fix the bug but in all the build log errors, I see that the file /usr/share/nodejs/lodash/_baseOrderBy.js is always the source of the error. The file _baseOrderBy.js in the package seems buggy for an unresolved reson. File in node-lodash unstable package: 4.17.19+dfsg-1 _baseOrderBy.js https://paste.debian.net/1157886/ File in node-lodash bullseye package 4.17.15+dfsg-2 _baseOrderBy.js https://paste.debian.net/1157887/ In the unstable version, the call to isArray line 24 is the root of errors. Also, I see that the upstream version 4.17.19 isn't tagged as latest release, 4.17.16 is, maybe it's worth a try to package 4.17.16 instead? I think I found the correct way, https://github.com/lodash-archive/lodash-cli/pull/141 and now node-babel7 built fine. I'll upload both 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#978123: node-postcss-filter-plugins: broken with node-postcss 8.x
Package: node-postcss-filter-plugins Version: 2.0.2-3 Severity: serious autopkgtest fails with stderr output postcss.plugin was deprecated. Migration guide: https://evilmartians.com/chronicles/postcss-8-plugin-migration This was reported on the team mailing list [1] and tracked in postcss 8 transition wiki [2] but filing a bug here for completeness. [1] https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-September/044914.html [2] https://wiki.debian.org/Javascript/Nodejs/Transitions/PostCSS8 Full log of the failure, https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-postcss-filter-plugins/9136124/log.gz Since it is no longer has any reverse (build) dependencies, it can be removed. -- 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: make it easy to specify autopkgtest restrictions in pkg-js-tools
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. -- 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#978608: node-rollup-plugin-node-resolve: Update to new upstream version 11.x
Package: node-rollup-plugin-node-resolve Version: 10.0.0+repack+~4.2.4-1 severity: important At least autoprefixer-rails build is broken with version 10. https://github.com/ai/autoprefixer-rails/pull/200#issuecomment-751924645 Probably more builds are silently broken. While at it, I think we should try to remove the embedded copy of the legacy plugin and port all reverse dependencies to the new version. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- 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#960901: Buffer is a built-in node function
On Tue, Dec 29, 2020 at 20:02, Ben Finney wrote: Control: found -1 webpack/4.43.0-6 On 16-Jun-2020, Ben Finney wrote: On 18-May-2020, Pirate Praveen wrote: > https://salsa.debian.org/js-team/node-clone/-/blob/master/clone.js#L109 > I think we may need to embed older version of buffer module in > node-libs-browser Okay. I assume that is information for the ‘node-libs-browser’ maintainer, I think as a user I can't affect that. Pirate, can you open a new bug report if necessary? I don't understand the above information enough to know even whether an additional bug report is required, or what it would report. As user of webpack, you need to configure it properly. You need to specify how webpack should handle node builtins like buffer. > For this particular case you can try embedding buffer module > version 4.x as browsers need an equivalent module to features > present only in node. This looks like advice for me to work around the problem. What do I need to do? How do I (as a user of Webpack) “embed buffer module version 4.x”? What does that suggestion mean, and who should take action to make it happen? That was not an exact assessment. It was a possibility I could think. In case of rollup, there is a plugin rollup-plugin-node-polyfills that resolves these builtins for rollup. I don't know what is the equivalent of webpack here. If you don't have a specific requirement to using webpack, I suggest you try rollup and rollup-plugin-node-polyfills instead of webpack. I don't think this is an issue specific to the debian package, but something that decided by webpack upstream. So you need to check the upstream documentation for webpack and figure out how to tell webpack to resolve these builtins. -- 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
Control: reassign -1 node-css-loader Control: retitle -1 autopkgtest regression due to stderr On Sat, Dec 26, 2020 at 10:50, Xavier wrote: 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 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#977900: node-autoprefixer: FTBFS: ENOENT: no such file or directory, open 'path'
On Fri, 25 Dec 2020 20:58:20 +0530 Pirate Praveen wrote: > Now with updated @rollup/plugin-node-resolve > > (debian-sid)pravi@ilvala2:~/forge/js-team/autoprefixer-rails-10.1.0.0/build$ > yarnpkg upgrade @rollup/plugin-node-resolve@^10.0.0 > yarn upgrade v1.22.10 > [1/4] Resolving packages... > [2/4] Fetching packages... > info fsevents@2.1.3: The platform "linux" is incompatible with this > module. > info "fsevents@2.1.3" is an optional dependency and failed > compatibility check. Excluding it from installation. > [3/4] Linking dependencies... > [4/4] Rebuilding all packages... > success Saved lockfile. > success Saved 1 new dependency. > info Direct dependencies > └─ @rollup/plugin-node-resolve@10.0.0 > info All dependencies > └─ @rollup/plugin-node-resolve@10.0.0 > Done in 3.75s. > In case we are not able to fix this error with version 10, I plan to embed version 9 of this plugin. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- 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] Removing legacy rollup-plugin-node-resolve module
Hi,
I'd like to remove embedded copy of rollup-plugin-node-resolve from
bullseye and port all modules to use @rollup/plugin-node-resolve
I have rebuilt all the reverse dependencies and you can see the list of
packages that failed at
https://wiki.debian.org/Javascript/Nodejs/Transitions/Rollup-plugin-node-resolve-legacy-rm
Most of the time, just a simple one line change should be enough.
--- a/rollup.config.js
+++ b/rollup.config.js
@@ -1,5 +1,5 @@
import ascii from "rollup-plugin-ascii";
-import node from "rollup-plugin-node-resolve";
+import node from "@rollup/plugin-node-resolve";
import {terser} from "rollup-plugin-terser";
import * as meta from "./package.json";
If you'd like to help with this transition, feel free to take any
module from the list, add your name next to it and move it to in
progress section.
--
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] Yarnpkg future
On Wed, Jan 6, 2021 at 7:54 pm, Pirate Praveen
wrote:
I'm trying to build corepack and it is progressing well. We will need
to package some dependencies (clipanion, terser-webpack-plugin,
ts-loader etc). I will report how it goes as I make progress.
Good news. I got a working yarn 2 build from the git main branch
snapshot with .yarn/cache removed.
I had to use npm dist tarballs for
clipanion terser terser-webpack-plugin ts-loader
@yarnpkg/fslib @zkochan/cmd-shim
terser in the archive seems to be missing some features (octal escape
sequences not supported), so it needs to be updated to 4.8.0.
Also schema-utils 2.x for terser-webpack-plugin.
In the process I also added @types/tar and @types/which to node-tar and
node-which
(debian-sid)praveen@mahishasura:/tmp/project2$ node
~/forge/corepack-main/dist/yarn.js init -y
{
name: 'project2'
}
(debian-sid)praveen@mahishasura:/tmp/project2$ node
~/forge/corepack-main/dist/yarn.js add pretty-ms
yarn add v1.22.10
warning package.json: No license field
warning ../package.json: No license field
info No lockfile found.
warning project2: No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
warning project2: No license field
success Saved 2 new dependencies.
info Direct dependencies
└─ pretty-ms@7.0.1
info All dependencies
├─ parse-ms@2.1.0
└─ pretty-ms@7.0.1
Done in 0.45s.
(debian-sid)praveen@mahishasura:/tmp/project2$ ls
node_modules package.json README.md yarn.lock
--
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#979531: lodash/fp does not have all the files shipped by npm dist.tarball
Package: node-lodash Version: 4.17.20+dfsg+~cs8.31.172-1 Severity: important Control: affects -1 gitlab Control: tags -1 help gitlab package from salsa master-13.5 branch fails with this error during installation. ERROR in /environments/components/environments_table.vue?vue=script=js& (/usr/share/nodejs/babel-loader/lib??ref--1!/var/lib/gitlab/node_modules/vue-loader/lib??vue-loader-options!./environments/components/environments_table.vue?vue=script=js&) Module build failed (from /usr/share/nodejs/babel-loader/lib/index.js): SyntaxError: /usr/share/gitlab/app/assets/javascripts/environments/components/environments_table.vue: The 'lodash' method `flow` is not a known module. Please report bugs to https://github.com/lodash/babel-plugin-lodash/issues. 132 | * 5. Put folders first. 133 | */ > 134 | return flow( | 135 | sortBy(env => (env.isFolder ? env.folderName : env.name)), 136 | reverse, 137 | sortBy(env => (env.last_deployment ? env.last_deployment.created_at : '')), at File.buildCodeFrameError (/usr/share/nodejs/@babel/core/lib/transformation/file/file.js:250:12) at NodePath.buildCodeFrameError (/usr/share/nodejs/@babel/traverse/lib/path/index.js:138:21) at resolvePath (/usr/share/nodejs/babel-plugin-lodash/lib/importModule.js:28:18) at importModule (/usr/share/nodejs/babel-plugin-lodash/lib/importModule.js:36:53) at memoized (/usr/share/nodejs/lodash/memoize.js:65:23) at /usr/share/nodejs/babel-plugin-lodash/lib/index.js:187:62 at arrayEach (/usr/share/nodejs/lodash/_arrayEach.js:18:9) at forEach (/usr/share/nodejs/lodash/forEach.js:41:10) at /usr/share/nodejs/babel-plugin-lodash/lib/index.js:177:30 at arrayEach (/usr/share/nodejs/lodash/_arrayEach.js:18:9) at forEach (/usr/share/nodejs/lodash/forEach.js:41:10) at /usr/share/nodejs/babel-plugin-lodash/lib/index.js:165:28 at arrayEach (/usr/share/nodejs/lodash/_arrayEach.js:18:9) at forEach (/usr/share/nodejs/lodash/forEach.js:41:10) at PluginPass.Program (/usr/share/nodejs/babel-plugin-lodash/lib/index.js:154:26) at newFn (/usr/share/nodejs/@babel/traverse/lib/visitors.js:175:21) at NodePath._call (/usr/share/nodejs/@babel/traverse/lib/path/context.js:55:20) at NodePath.call (/usr/share/nodejs/@babel/traverse/lib/path/context.js:42:17) at NodePath.visit (/usr/share/nodejs/@babel/traverse/lib/path/context.js:92:31) at TraversalContext.visitQueue (/usr/share/nodejs/@babel/traverse/lib/context.js:115:16) at TraversalContext.visitSingle (/usr/share/nodejs/@babel/traverse/lib/context.js:84:19) at TraversalContext.visit (/usr/share/nodejs/@babel/traverse/lib/context.js:143:19) at Function.traverse.node (/usr/share/nodejs/@babel/traverse/lib/index.js:82:17) at traverse (/usr/share/nodejs/@babel/traverse/lib/index.js:64:12) at transformFile (/usr/share/nodejs/@babel/core/lib/transformation/index.js:107:29) at transformFile.next () at run (/usr/share/nodejs/@babel/core/lib/transformation/index.js:35:12) at run.next () at Function.transform (/usr/share/nodejs/@babel/core/lib/transform.js:27:41) at transform.next () at step (/usr/share/nodejs/gensync/index.js:254:32) at /usr/share/nodejs/gensync/index.js:266:13 at async.call.result.err.err (/usr/share/nodejs/gensync/index.js:216:11) @ /environments/components/environments_table.vue?vue=script=js& 1:0-225 1:241-244 1:246-468 1:246-468 @ ./environments/components/environments_table.vue @ ./environments/mixins/environments_mixin.js @ ./environments/mount_show.js @ ./pages/projects/environments/show/index.js @ multi ./main ./pages/projects/index.js /pages/projects/environments/show/index.js When 451 files are shipped with npmjs.com dist tarball of lodash in lodash/fp, only 101 files are shipped in debian package. And indeed flow.js is missing from the debian package. -- 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#949243: Unable to reproduce
On Mon, 23 Nov 2020 12:11:25 +0100 Xavier wrote: > Control: tags -1 + moreinfo > > Hi, > > I'm unable to reproduce this bug after many tries > > DEB_BUILD_PROFILES=nocheck sbuild is failing for node-vinyl-fs in sid as well. -- 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 ?
On Sun, Dec 6, 2020 at 11:37, Jonas Smedegaard wrote: Sorry, I was unclear. Let me try rephrase to clarify: ftpmaster strongly dislikes (i.e. they will reject) too tiny source packages, but ftpmaster does not actively encourage (even if they might tolerate) duplicate code. My point was not that ftpmaster rejects duplicate code (they might in severe cases, but that is not really their task to judge on). My point was, instead, that it is wrong to interpret the fact that ftpmaster rejects tiny source packages as an endorsement of duplicate source through _repeated_ embedding of same module. "One line of code (=exaggeration for simple module) should be always embedded independent of the number of packages that depend on it." - Thorsten Alteholz / ftp master https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2018-September/027873.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
Re: [Pkg-javascript-devel] please file ITP bugreport to track new packages
On Thu, Dec 3, 2020 at 11:53, Jonas Smedegaard wrote: Please use Debbugs... Debian has an issue tracker called debbugs. Despite its name it can also track other kinds of issues than bugs, including the interest and eventual preliminary work preparing a new package, before the package is added to Debian. Such issues are tracked by filing a bugreport against the psudo-packae "wnpp" with a type of either "RFP" or "ITP". See more details at https://www.debian.org/devel/wnpp/ Please track new packages in Debbugs! Today I wasted time creating a package apparently already in preparation for several years, because it was not tracked in Debbugs. I have moved aside that old work - please those involved in that mess cherry-pick anything sensible and then delete the git repo: https://salsa.debian.org/js-team/node-serialize-javascript.old This package was rejected because it was considered too small by ftp masters. https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2018-September/028329.html It is documented at https://wiki.debian.org/Javascript/Nodejs/NEW and there was an ITP at that time https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885137 which was closed after it was rejected. apt-file find node_modules/serialize-javascript is a good way to find already embedded modules and probably a nice addition to npm2deb search. -- 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#976081: Bug#976081: Bug#976081: yarnpkg: Provide prebuilt yarnpkg in contrib
On Tue, 01 Dec 2020 00:39:18 +0530 Pirate Praveen wrote: > > > On Tue, Dec 1, 2020 at 00:28, Pirate Praveen > wrote: > > > > > > On Mon, Nov 30, 2020 at 19:46, Paolo Greppi > > wrote: > >> The resulting package was not installable due to node-babel-runtime > >> missing from testing > > > > May be we can add babel-runtime as a component? (it is going to > > contrib anyway) > > Or see if we can replace babel-runtime to @babel/runtime with patch and > node-babel7 as runtime dependency. I have included babel-runtime as a component now. Please check 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#974069: Bug#974069: error Yarn hasn't been able to find a cache folder it can use although folders are writable
Control: fixed -1 1.22.4-4 On Mon, 09 Nov 2020 22:00:53 +0530 Pirate Praveen wrote: > This is caused by node-mkdirp transition, but node-yarnpkg is ftbfs currently (caused by node-babel/node-babel7 transition) which makes it hard to fix. Fixed in last uplod. -- 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#972952: Bug#972952: node-mkdirp 1.0 is incompatible with 0.5, breaks yarnpkg
Control: fixed -1 1.22.4-4 On Tue, 27 Oct 2020 07:41:34 +0100 Xavier wrote: > migration from mkdirp 0.53 to 1.0.x is easy but I'm not able to patch > yarnpkg since build already fails for some babel reasons. This is fixed in the last upload, though we need to build it using snapshot.debian.org and we cannot do a source only upload. -- 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?
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.
--
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?
On Mon, 07 Dec 2020 18:25:26 +0530 Pirate Praveen wrote: > 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 think uuid itself had a bug, with uuid 8.3.1, I don't see this issue now. Opened an upstream MR with gitlab to update uuuid https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49364 So I had to update both node-copy-webpack-plugin and gitlab to fix this issue. I can see npm now required uuid 8.3.0, so npm should work with node-uuid from experimental. -- 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#964218: Bug#964218: Bug#964218: node-yarnpkg: autopkgtest fails with node-uuid 8.2 from experimental - "Cannot read property 'v4' of undefined"
Control: reassign -1 node-copy-webpack-plugin On Sun, 12 Jul 2020 15:43:19 +0530 Pirate Praveen wrote: > I tried fixing this in babel6 branch (as master is broken - I found it > broke after merging babel 7 branch), but autopkgtest still fails with > the same error. Can you check/review the patch? Could this be a bug in > uuid? I found the problem and a work around. yarnpkg why uuid yarn why v1.22.4 [1/4] Why do we have the module "uuid"...? [2/4] Initialising dependency graph... [3/4] Finding dependency... [4/4] Calculating file sizes... => Found "uuid@8.1.0" info Has been hoisted to "uuid" info This module exists because it's specified in "dependencies". info Disk size without dependencies: "244KB" info Disk size with unique dependencies: "244KB" info Disk size with transitive dependencies: "244KB" info Number of shared dependencies: 0 => Found "aws-sdk#uuid@3.3.2" info This module exists because "aws-sdk" depends on it. info Disk size without dependencies: "108KB" info Disk size with unique dependencies: "108KB" info Disk size with transitive dependencies: "108KB" info Number of shared dependencies: 0 Done in 0.70s. Since gitlab wants uuid 8.x, /usr/share/gitlab/node_modules has uuid 8.1.0 and gets priority over /usr/share/nodejs/uuid Once I force uuid 3.x for copy-webpack-plugin by cd /usr/share/nodejs/copy-webpack-plugin/node_modules/ ln -s /usr/share/nodejs/uuid/ . The error about uuid exports is gone. A proper fix would be to update node-uuid to 8.x in debian. This will need a transition and updating all reverse dependencies to use the new api. We can continue that discussion in #974587. -- 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#964218: fixed in node-copy-webpack-plugin 5.1.2+~cs9.0.2-2
Control: reopen -1 Control: reassign -1 gitlab On Mon, 07 Dec 2020 13:49:55 + Debian FTP Masters wrote: > Source: node-copy-webpack-plugin > Source-Version: 5.1.2+~cs9.0.2-2 > Done: Pirate Praveen > > We believe that the bug you reported is fixed in the latest version of > node-copy-webpack-plugin, which is due to be installed in the Debian FTP > archive. > Not fixed fully, so reopening. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- 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: Re: node-uuid: Bad "exports" field?
On Mon, 07 Dec 2020 23:00:56 +0530 Pirate Praveen wrote: > So if we fix node-request to work with newer uuid or probably remove > the dependency on node-request in yarnpkg, I hope we can fix this issue. I have fixed node-request to work with uuid 8.x API and yarnpkg is fixed 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#974587: Bug#974587: Re: node-uuid: Bad "exports" field?
Control: reassign -1 node-request Control: fixed -1 2.88-5 On Mon, Dec 7, 2020 at 23:27, Pirate Praveen wrote: On Mon, 07 Dec 2020 23:00:56 +0530 Pirate Praveen wrote: > So if we fix node-request to work with newer uuid or probably remove > the dependency on node-request in yarnpkg, I hope we can fix this issue. I have fixed node-request to work with uuid 8.x API and yarnpkg is fixed now. Reassigning to node-request and add fixed version -- 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: [JS Policy] what to set in "Provides" field ?
On Thu, Dec 3, 2020 at 19:17, Jonas Smedegaard wrote: 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. I suggest you embed serialize-javascript in node-terser and if you wish you can expose it as virtual package via Provides. Connecting unrelated packages together is making things complicated for transitions and also increases installed packages size. Also 'should' is not 'must' in policy. -- 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: reopen -1 Control: reassign -1 gitlab On Thu, Dec 3, 2020 at 10:14, Xavier wrote: Does gitlab use `npm install` ? If so, we just have to fix node-compression-webpack-plugin/package.json This is indeed caused by mix of schema-utils 2 and 3. Version 2 is pulled by yarn and version 3 by debian. I found a work around for now, cd /usr/share/nodejs/compression-webpack-plugin/node_modules ln -s /usr/share/nodejs/schema-utils/ . cd /usr/share/nodejs/uglifyjs-webpack-plugin/node_modules ln -s /usr/share/nodejs/schema-utils/ . cd /usr/share/nodejs/webpack/node_modules ln -s /usr/share/nodejs/schema-utils/ . cd /usr/share/nodejs/cache-loader-loader/node_modules ln -s /usr/share/nodejs/schema-utils/ . mkdir /usr/share/nodejs/url-loader/node_modules cd /usr/share/nodejs/url-loader/node_modules ln -s /usr/share/nodejs/schema-utils/ . mkdir /usr/share/nodejs/babel-loader/node_modules cd /usr/share/nodejs/babel-loader/node_modules ln -s /usr/share/nodejs/schema-utils/ . I will try to get css-loader from debian working with gitlab as a proper fix. -- 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 ?
On 2020, ഡിസംബർ 3 10:03:18 PM IST, Xavier wrote: >I'm not in favor of your proposal: if I need a node-very-few-module >which is provided by a package with many dependencies, I'm not happy to >depend on it. To apply that, we should then choose with precaution in >which package we will embed each code. Packaging JS is already a hudge >work, I'm not sure we need more complexity. > >@JS-Team, does anyone have any other opinion? Else which option do you >choose? I'll update pkg-js-tools with your choice of course. I agree with yadd here. We should not complicate js packaging more than it already is. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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#976440: pkg-js-tools: add a minimal test to check the dependencies in package.json does not differ by major versions
Package: pkg-js-tools Version: 0.9.53 Severity: wishlist It would be nice to have a test in pkg-js-tools to make sure the dependencies mentioned in package.json of a module is not differing by a major version. Example node-css-loader. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976408#57 for list dependencies with mismatched versions. package.json has postcss-modules-extract-imports": "^2.0.0" but node-postcss-modules-extract-imports in the archive is 3.0.0-1. In ruby team, gem2deb does this already. It will test if dependencies mentioned in gemspec is satisfied and fail in case of mismatch. If we know the mismatch is not a problem, we add a patch to adjust the required version. GEM_PATH= ruby2.7 -e gem\ \"faraday\" is how gem2deb tests it. -- 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#976615: please provide /usr/share/nodejs/pdfjs-dist
package: pdf.js version: 2.6.347+dfsg-2 severity: wishlist There is a node module pdfjs-dist https://www.npmjs.com/package/pdfjs-dist which includes a prebuilt version of pdf.js. gitlab needs this (currently it is pulled from npmjs.com via yarn), so it would be good if pdfjs-dist can be installed in /usr/share/nodejs This would also help me with #976310 / #976408 as pdfjs-dist pulls in schema-utils via worker-loader. -- 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-uuid 8.x transition
hi, I have fixed node-request to work with node-uuid 8 API and it also fixed yarnpkg/gitlab. I'd like to upload node-uuid 8.x to unstable in the coming days. Help is welcome to ensure every package is fixed with this version. Please see the patch in node-request for how to do it. Also uuid 8 readme has the now recommended way of importing/requiring uuid. As per https://release.debian.org/britney/pseudo-excuses-experimental.html Only two more packages fail, autopkgtest for node-copy-webpack-plugin/5.1.2+~cs9.0.2-1 (I will fix this) autopkgtest for node-node-rest-client/2.5.0-4 I think we should also rebuild reverse dependencies too, The list of reverse build dependencies are, $ reverse-depends -b node-uuid Reverse-Testsuite-Triggers * node-node-rest-client * node-redis Reverse-Build-Depends * node-ajv-keywords * node-copy-webpack-plugin * node-fastcgi * node-http-signature * node-request * npm npm package.json already mentions uuid 8.x so that should be fine. So need help with node-node-rest-client, node-redis, node-ajv-keywords, node-fastcgi, node-http-signature. Thanks Praveen -- 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-uuid 8.x transition
On 2020, ഡിസംബർ 8 10:53:26 AM IST, Andrius Merkys wrote: >Hello, > >On 2020-12-07 20:46, Pirate Praveen wrote: >> I have fixed node-request to work with node-uuid 8 API and it also fixed >> yarnpkg/gitlab. > >Does this mean node-request is going to be part of bullseye? There was a >mass bug filling (see #974064 for example) suggesting otherwise. No, it does not have to be in bullseye. yarnpkg was broken due to this bug, which is also not going to be in bullseye. So any package that wants to be in bullseye should replace dependency on node-request with some other package. I think we should file an rc bug against node-request to allow auto removal from testing. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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-uuid 8.x transition
On Tue, Dec 8, 2020 at 00:16, Pirate Praveen wrote: I think we should also rebuild reverse dependencies too, I did a rebuild and here is the results, rebuild node-ajv-keywords... PASS autopkgtest node-redis ... PASS autopkgtest node-request ... PASS rebuild node-request ... PASS autopkgtest npm ... PASS rebuild npm ... PASS autopkgtest node-copy-webpack-plugin ... FAIL rebuild node-copy-webpack-plugin ... FAIL rebuild node-fastcgi ... FAIL rebuild node-http-signature ... FAIL autopkgtest node-node-rest-client... FAIL autopkgtest node-yarnpkg ... FAIL Out of this, I already fixed node-copy-webpack-plugin. I'm fixing node-http-signature. I wonder why yarnpkg is still failing. It is working fine when used with gitlab and also in my sample test case as given here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974587#25 This was failing before node-request fix and started working after the fix. But yarnpkg autopkgtest is still failing, even though I can see the fixed version of node-yarnpkg is used. May be it actually needs node-uuid 8? -- 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-uuid 8.x transition
On Tue, Dec 8, 2020 at 13:45, Jonas Smedegaard wrote: Thanks for raising that concern, Andrius. An RC bug has already been filed for that purpose, however: bug#956423. I did not see an auto removal notice against it at tracker.debian.org so I thought the severity might be lower than rc. Later I found out about it, but I wonder why this did not trigger an autoremoval notice, even though the bug was filed on 10 Apr 2020. Could it be because found versions are not updated? -- 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#976861: node-fastcgi: ftbfs with node-uuid 8.x in experimental
Package: node-fastcgi Version: 1.3.3-3 Severity: important Control: block 956423 by -1 Control: tags -1 patch Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './v4' is not defined by "exports" in /usr/share/nodejs/uuid/package.json Full log attached. This is caused by embedded copy of request not compatible with uuid 8. https://salsa.debian.org/js-team/node-fastcgi/-/tree/master/debian/tests/test_modules/request node-request already has this patch https://salsa.debian.org/js-team/node-request/-/blob/master/debian/patches/uuid-8-compat.patch sbuild (Debian sbuild) 0.79.1 (22 April 2020) on ilvala2 +==+ | node-fastcgi 1.3.3-3 (amd64) Tue, 08 Dec 2020 12:58:00 + | +==+ Package: node-fastcgi Version: 1.3.3-3 Source Version: 1.3.3-3 Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-f6b21bc8-880b-4262-98c5-4fd6144e921f' with '<>' I: NOTICE: Log filtering will replace 'build/node-fastcgi-iuwxXB/resolver-D7yYO5' with '<>' +--+ | Update chroot| +--+ Get:1 file:/build/node-fastcgi-iuwxXB/resolver-iqVUJS/apt_archive ./ InRelease Ign:1 file:/build/node-fastcgi-iuwxXB/resolver-iqVUJS/apt_archive ./ InRelease Get:2 file:/build/node-fastcgi-iuwxXB/resolver-iqVUJS/apt_archive ./ Release [951 B] Get:2 file:/build/node-fastcgi-iuwxXB/resolver-iqVUJS/apt_archive ./ Release [951 B] Get:3 file:/build/node-fastcgi-iuwxXB/resolver-iqVUJS/apt_archive ./ Release.gpg Ign:3 file:/build/node-fastcgi-iuwxXB/resolver-iqVUJS/apt_archive ./ Release.gpg Get:4 file:/build/node-fastcgi-iuwxXB/resolver-iqVUJS/apt_archive ./ Packages [783 B] Ign:4 file:/build/node-fastcgi-iuwxXB/resolver-iqVUJS/apt_archive ./ Packages Get:4 file:/build/node-fastcgi-iuwxXB/resolver-iqVUJS/apt_archive ./ Packages [1579 B] Hit:5 http://deb.debian.org/debian unstable InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following packages were automatically installed and are no longer required: krb5-locales libnss-nis libnss-nisplus Use 'apt autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Local sources - /tmp/tmp.oVdqvmQM3T/node-fastcgi_1.3.3-3.dsc exists in /tmp/tmp.oVdqvmQM3T; copying to chroot I: NOTICE: Log filtering will replace 'build/node-fastcgi-iuwxXB/node-fastcgi-1.3.3' with '<>' I: NOTICE: Log filtering will replace 'build/node-fastcgi-iuwxXB' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper-compat (= 13), dh-sequence-nodejs, chai, mocha, node-aws-sign2, node-aws4, node-caseless, node-extend, node-fastcgi-stream, node-forever-agent, node-form-data, node-har-validator, node-http-signature, node-is-typedarray, node-isstream, node-json-stringify-safe, node-mime-types, node-oauth-sign, node-performance-now, node-qs, node-safe-buffer, node-tough-cookie, node-tunnel-agent, node-uuid, build-essential, fakeroot Filtered Build-Depends: debhelper-compat (= 13), dh-sequence-nodejs, chai, mocha, node-aws-sign2, node-aws4, node-caseless, node-extend, node-fastcgi-stream, node-forever-agent, node-form-data, node-har-validator, node-http-signature, node-is-typedarray, node-isstream, node-json-stringify-safe, node-mime-types, node-oauth-sign, node-performance-now, node-qs, node-safe-buffer, node-tough-cookie, node-tunnel-agent, node-uuid, build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-main-dummy' in '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. Ign:1 copy:/<>/apt_archive ./ InRelease Get:2 copy:/<>/apt_archive ./ Release [963 B] Ign:3 copy:/<>/apt_archive ./ Release.gpg Get:4 copy:/<>/apt_archive ./ Sources [560 B] Get:5 copy:/<>/apt_archive ./ Packages [625 B] Fetched 2148 B in 0s (75.1 kB/s) Reading package lists... Get:1 file:/<>/resolver-iqVUJS/apt_archive ./ InRelease Ign:1 file:/<>/resolver-iqVUJS/apt_archive ./ InRelease Get:2 file:/<>/resolver-iqVUJS/apt_archive ./ Release [951 B] Get:2
Re: [Pkg-javascript-devel] node-uuid 8.x transition
On Tue, Dec 8, 2020 at 19:44, Pirate Praveen wrote: autopkgtest node-copy-webpack-plugin ... FAIL rebuild node-copy-webpack-plugin ... FAIL rebuild node-fastcgi ... FAIL rebuild node-http-signature ... FAIL autopkgtest node-node-rest-client... FAIL autopkgtest node-yarnpkg ... FAIL Out of this, I already fixed node-copy-webpack-plugin. I'm fixing node-http-signature. This is now fixed. I wonder why yarnpkg is still failing. It is working fine when used with gitlab and also in my sample test case as given here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974587#25 This was failing before node-request fix and started working after the fix. But yarnpkg autopkgtest is still failing, even though I can see the fixed version of node-yarnpkg is used. May be it actually needs node-uuid 8? I found out the issue. The autopkgtest is is pulling request from npmjs.com which does not work with uuid 8.x. So I fixed autopkgtest to test things in a clean project. So now only node-fastcgi and node-node-rest-client is left. -- 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#949243: Bug#949243: Unable to reproduce
On Tue, Nov 24, 2020 at 13:32, Mattia Rizzolo wrote: Just a note: On Tue, Nov 24, 2020 at 04:55:02PM +0530, Pirate Praveen wrote: DEB_BUILD_PROFILES=nocheck sbuild If you sepcify nocheck in _PROFILES you also *MUST* specify nocheck in _OPTIONS. See the relevant line in https://wiki.debian.org/BuildProfileSpec#Registered_profile_names Thanks for sharing this. But I think it would be better to assume DEB_BUILD_OPTIONS also set to nocheck instead of expecting setting two variables that does the same thing. May be that is not in the scope for pkg-js-tools. -- 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] acorn_8.0.4+ds+~cs19.19.27-1~bpo10+1_amd64.changes REJECTED
On Wed, Dec 9, 2020 at 18:24, Debian FTP Masters
wrote:
There was an uncaught exception when processing your upload:
Traceback (most recent call last):
File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 109,
in _install_file
session.query(ArchiveFile).filter_by(archive=archive,
component=component, file=poolfile).one()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line
3046, in one
raise orm_exc.NoResultFound("No row was found for one()")
sqlalchemy.orm.exc.NoResultFound: No row was found for one()
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line
214, in wrapper
return function(directory, upload, *args, **kwargs)
File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line
269, in accept
upload.install()
File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 1356,
in install
(db_source, db_binaries) = self._install_to_suite(suite,
redirected_suite, source_component_func, binary_component_func,
source_suites=source_suites, extra_source_archives=[suite.archive],
policy_upload=policy_upload)
File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 1095,
in _install_to_suite
fingerprint=self.fingerprint
File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 377,
in install_source
db_source = self.install_source_to_archive(directory, source,
suite.archive, component, changed_by, allow_tainted, fingerprint)
File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 273,
in install_source_to_archive
db_file_dsc = self._install_file(directory, source._dsc_file,
archive, component, source_name)
File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 117,
in _install_file
self.fs.copy(hashed_file_path, path, link=False,
mode=archive.mode)
File "/srv/ftp-master.debian.org/dak/daklib/fstransactions.py",
line 152, in copy
self.actions.append(_FilesystemCopyAction(source, destination,
link=link, symlink=symlink, mode=mode))
File "/srv/ftp-master.debian.org/dak/daklib/fstransactions.py",
line 52, in __init__
self.check_for_temporary()
File "/srv/ftp-master.debian.org/dak/daklib/fstransactions.py",
line 33, in check_for_temporary
raise IOError("Temporary file '{0}' already
exists.".format(self.temporary_name))
OSError: Temporary file
'/srv/ftp-master.debian.org/ftp/pool/main/a/acorn/acorn_8.0.4+ds+~cs19.19.27-1~bpo10+1.dsc'
already exists.
Any original reject reason follows below.
===
Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.
Hi FTP Masters,
Can some one check and figure out why this was rejected? Similarly long
version was already in buster-backports so I doubt it is about the
version.
Thanks
Praveen
--
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#976155: Bug#976155: yarnpkg: depends on obsolete virtual node-node-uuid
On Mon, Nov 30, 2020 at 19:35, Jonas Smedegaard wrote: Btw, it seems you need to push latest changes to git for yarnpkg The recent changes are in master-1 branch as we could not fix the master branch (attempted to build with babel 7 without success). -- 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#976155: Bug#976155: yarnpkg: depends on obsolete virtual node-node-uuid
On Mon, Nov 30, 2020 at 18:32, Jonas Smedegaard wrote: Package: yarnpkg Version: 1.22.4-4 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 yarnpkg depends on node-node-uuid. node-node-uuid was deprecated 2 yars ago, replaced by node-uuid. Please change to instead depend on node-uuid. Raised severity as this is the last package relying on the old name, and we want to drop it before freeze. Since node-yarnpkg is not in bullseye and ftbfs already (it needs a snapshot.debian.org chroot with babel 6 from the time 1.22.4-3 was built by buildd), I think you can request node-node-uuid to be removed from bullseye or add an rc bug for auto removal. We can fix node-yarnpkg if we need to fix another breakage like node-mkdirp 1.0. Or if someone wants to fix it earlier, feel free. -- 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#976081: Bug#976081: Bug#976081: yarnpkg: Provide prebuilt yarnpkg in contrib
On Tue, Dec 1, 2020 at 00:28, Pirate Praveen wrote: On Mon, Nov 30, 2020 at 19:46, Paolo Greppi wrote: The resulting package was not installable due to node-babel-runtime missing from testing May be we can add babel-runtime as a component? (it is going to contrib anyway) Or see if we can replace babel-runtime to @babel/runtime with patch and node-babel7 as runtime dependency. -- 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#976081: Bug#976081: yarnpkg: Provide prebuilt yarnpkg in contrib
On Mon, Nov 30, 2020 at 19:46, Paolo Greppi wrote: On Sun, 29 Nov 2020 18:02:16 +0530 Pirate Praveen wrote: Control: clone -1 -2 Control: retitle -2 "Provide prebuilt yarnpkg in contrib" On Sat, Nov 28, 2020 at 22:07, Paolo Greppi wrote: >> 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. > > +1 I have a created a new branch master-contrib in salsa and pushed my changes. Please review the changes and if it looks good, we can upload it. Also we can move this discussion to the cloned bug. I have made a couple of commits to master-contrib branch. The resulting package was not installable due to node-babel-runtime missing from testing May be we can add babel-runtime as a component? (it is going to contrib anyway) Also it does not install the man manpage. Pushed a change, so it should get installed 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#976310: node-compression-webpack-plugin: TypeError: (0 , _schemaUtils.validate) is not a function
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 at new CompressionPlugin (/usr/share/nodejs/compression-webpack-plu gin/dist/index.js:40:31) at Object. (/etc/gitlab/webpack.config.js:451:41) at Module._compile (/usr/share/nodejs/webpack/node_modules/v8-compi le-cache/v8-compile-cache.js:194:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:10 35:10) at Module.load (internal/modules/cjs/loader.js:879:32) at Function.Module._load (internal/modules/cjs/loader.js:724:14) at Module.require (internal/modules/cjs/loader.js:903:19) at require (/usr/share/nodejs/webpack/node_modules/v8-compile-cache /v8-compile-cache.js:161:20) at WEBPACK_OPTIONS (/usr/share/nodejs/webpack/node_modules/webpack- cli/bin/utils/convert-argv.js:114:13) at requireConfig (/usr/share/nodejs/webpack/node_modules/webpack-cl i/bin/utils/convert-argv.js:116:6) at /usr/share/nodejs/webpack/node_modules/webpack-cli/bin/utils/con vert-argv.js:123:17 at Array.forEach () at module.exports (/usr/share/nodejs/webpack/node_modules/webpack-c li/bin/utils/convert-argv.js:121:15) at /usr/share/nodejs/webpack/node_modules/webpack-cli/bin -- 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
On Thu, Dec 3, 2020 at 10:14, Xavier wrote: _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 yes, it uses yarnpkg install. Can you fix it then? This is the webpack.config.js https://salsa.debian.org/ruby-team/gitlab/-/blob/master/config/webpack.config.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#976310: Bug#976310: node-compression-webpack-plugin: TypeError: (0 , _schemaUtils.validate) is not a function
On Thu, Dec 3, 2020 at 10:13, Xavier wrote: _schemaUtils.validate *is* a function when using schema-utils ≥ 3. Problem is probably somewhere else I think it is because css-loader is installed from npm which would pull node-schema-loader 2.x. I could not get node-css-loader working last time after it was updated by a major version. -- 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
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. 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
[Pkg-javascript-devel] Bug#973741: Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use
Control: clone -1 -2 Control: retitle -2 "Provide prebuilt yarnpkg in contrib" On Sat, Nov 28, 2020 at 22:07, Paolo Greppi wrote: 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. +1 I have a created a new branch master-contrib in salsa and pushed my changes. Please review the changes and if it looks good, we can upload it. Also we can move this discussion to the cloned bug. -- 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#976081: Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use
Control: reopen -1 Control: notfixed -1 1.22.4-4 On Sun, 29 Nov 2020 18:02:16 +0530 Pirate Praveen wrote: > I have a created a new branch master-contrib in salsa and pushed my > changes. > Please review the changes and if it looks good, we can upload it. Also > we can move this discussion to the cloned bug. Moving discussion to the new bug. -- 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#977311: node-uglifyjs-webpack-plugin: dead upstream since July 2019
On Sun, 13 Dec 2020 21:30:41 +0100 Jonas Smedegaard wrote: > It seems this package has only one reverse dependency (webpack) and two > reverse build-dependencies (node-chai and node-webpack). > > Seems it is time to replace this package with its successor, > https://github.com/webpack-contrib/terser-webpack-plugin We will need to package this first. > Setting severity to serious due to the upcoming breaking change to > node-terser. -- 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#977485: @babel/standalone modules is empty
Package: node-babel7 Version: 7.12.10+~cs150.141.83-1 Severity: wishlist Currently it only has package.json in /usr/share/nodejs/@babel/standalone I'd like to use it for @gitlab/ui module. -- 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-yarnpkg_1.22.4-6_source.changes ACCEPTED into unstable
On Fri, Dec 18, 2020 at 12:41, Xavier wrote: Hi, I still see one problem: yarnpkg seems to depends on node-babel-plugin-transform-strict-mode Thanks for checking, with babel-plugin-transform-inline-imports-commonjs removed, we can remove this build dependency. I will remove it in the next upload. -- 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#958687: node-request-promise: Remove dependency to node-request
On Thu, 10 Dec 2020 21:22:49 +0530 Pirate Praveen wrote: > node-request-promise has no reverse (build) dependencies, so I think we > can request removal. Filed request for removal from archive. -- 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#914509: [request] contains unnecessary embedded copy of node-uuid
Control: fixed -1 2.88.1-3 On Sat, 24 Nov 2018 07:26:26 +0100 Paolo Greppi wrote: > This package contains an embedded copy of node-uuid 3.3.2 which is unnecessary now that we have it in the archive: > https://packages.debian.org/sid/node-uuid > > The embedded copy should be removed and a dependency on node-uuid added. This is already fixed in 2.88.1-3 -- 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] help with node-vue-style-loader autopkgtest and jest
Hi, The tests are running fine for node-vue-style-loader during build but it fails during autopkgtest because the module is shipping esm files directly. It has a .babelrc file which jest uses during build to transform the modules, but during autopkgtest, lib is a symlink to /usr/share/nodejs/vue-style-loader/lib so it refuses to transform and fails because it is ES Module (import statement). I tried adding export BABEL_ENV=commonjs (which worked in some other package) and adding a jest.config.js with different values for "transformIgnorePatterns":, including empty [], "node_modules/(?!(vue-style-loader)/)", "nodejs/(?!(vue-style-loader)/)", /(?!(vue-style-loader)/ etc. Can anyone try it? You just need to add Testsuite: autopkgtes-pkg-nodejs to debian/control and run autopkgtest. Files are in salsa. Note: I tried jest --ci, and jest --ci test as well. Thanks Praveen -- 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#977232: babeljs-node is unable to find system modules
Control: retitle -1 missing dependency node-environment-flags Control: clone -1 -2 Control: retitle -2 node-yargs missing dependency on node-define-property Control: reassign -2 node-yargs On Sun, 13 Dec 2020 02:06:42 +0530 Pirate Praveen > When trying to run mocha using babeljs-node command, it fails to find > the modules installed in global nodejs directories. So this was a problem with my local environment. I had nvm setup with a different node executable. After removing ~/.nvm I can find these modules. But the following is still an issue, > > Some other things I found in this experiment, > > 1. node-environment-flags module which is required in > 2. Also node-yargs is missing a dependency on node-define-property. This should be a bug against node-yargs though. Cloned as separate bug. -- 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#977234: node-vue-style-loader: enable autopkgtest
Package: node-vue-style-loader
Version: 4.1.2-1
severity: wishlist
As continuation of
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-December/048394.html
I tried running the test with babeljs-node after embedding missing
node-environment-flags in debian/test/test_modules and exporting
NODE_PATH=debian/tests/test_modules in debian/tests/pkg-js/test
These steps are workaround for this bug,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977232
+ /usr/bin/babeljs-node /usr/bin/jest
FAIL test/test.js
● Test suite failed to run
Jest encountered an unexpected token
This usually means that you are trying to import a file which Jest
cannot parse, e.g. it's not plain JavaScript.
By default, if Jest sees a Babel config, it will use that to
transform your files, ignoring "node_modules".
Here's what you can do:
• If you are trying to use ECMAScript Modules, see
https://jestjs.io/docs/en/ecmascript-modules for how to enable it.
• To have some of your "node_modules" files transformed, you can
specify a custom "transformIgnorePatterns" in your config.
• If you need a custom transformation specify a "transform"
option in your config.
• If you simply want to mock your non-JS modules (e.g. binary
assets) you can stub them out with the "moduleNameMapper" config option.
You'll find more details and examples of these config options in
the docs:
https://jestjs.io/docs/en/configuration.html
Details:
/usr/share/nodejs/vue-style-loader/lib/addStylesClient.js:6
import listToStyles from './listToStyles';
^^
SyntaxError: Cannot use import statement outside a module
1093 | try {
1094 | const scriptFilename =
this._resolver.isCoreModule(filename) ? `jest-nodejs-core-${filename}`
: filename;
> 1095 | return new
(_vm().Script)(this.wrapCodeInModuleWrapper(scriptSource), {
| ^
1096 | displayErrors: true,
1097 | filename: scriptFilename,
1098 | // @ts-expect-error: Experimental ESM API
at Runtime.createScriptFromCode
(../../../../../usr/share/nodejs/jest-runtime/build/index.js:1095:14)
at Object. (test/test.js:1:1)
Test Suites: 1 failed, 1 total
Tests: 0 total
Snapshots: 0 total
Time: 1.643 s
Ran all test suites.
autopkgtest [02:34:48]: test pkg-js-autopkgtest:
---]
autopkgtest [02:34:48]: test pkg-js-autopkgtest: - - - - - - - - - -
results - - - - - - - - - -
pkg-js-autopkgtest FAIL non-zero exit status 1
autopkgtest [02:34:48]: summary
pkg-js-autopkgtest-require PASS (superficial)
pkg-js-autopkgtest FAIL non-zero exit status 1
I'm out of ideas for 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#977232: babeljs-node is unable to find system modules
Package: node-babel7 Version: 7.12.9+~cs150.130.99-1 Severity: important When trying to run mocha using babeljs-node command, it fails to find the modules installed in global nodejs directories. pravi@mahishi:~/forge/js-team/node-window-size$ babeljs-node /usr/bin/mocha -R spec internal/modules/cjs/loader.js:638 throw err; ^ Error: Cannot find module 'v8flags' 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/node/lib/babel-node.js:3:39) at Module._compile (internal/modules/cjs/loader.js:778:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) at Module.load (internal/modules/cjs/loader.js:653:32) at tryModuleLoad (internal/modules/cjs/loader.js:593:12) at Function.Module._load (internal/modules/cjs/loader.js:585:3) Once I manually set the NODE_PATH variable, it starts working. We should probably set these paths before calling babeljs-node command. pravi@mahishi:~/forge/js-team/node-window-size$ export NODE_PATH=/usr/lib/nodejs:debian/tests/test_modules:/usr/share/nodejs:/usr/lib/x86_64-linux-gnu/nodejs/:/usr/share/nodejs/mocha/node_modules pravi@mahishi:~/forge/js-team/node-window-size$ babeljs-node /usr/bin/mocha -R spec window-size ✓ should return an object with width and height ✓ should expose a `.get` method to get up-to-date size ✓ should get size from process.stdout ✓ should get size from process.stderr ✓ should get size from process.env ✓ should get size from tty ✓ should get size from tput utils ✓ should expose a `.get` method to get up-to-date size ✓ should get size from process.env ✓ should get size from tty ✓ should get size from tput 11 passing (27ms) pravi@mahishi:~/forge/js-team/node-window-size$ Some other things I found in this experiment, 1. node-environment-flags module which is required in /usr/share/nodejs/@babel/node/lib/babel-node.js is only available in /usr/share/nodejs/mocha/node_modules Error: Cannot find module 'node-environment-flags' 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/node/lib/babel-node.js:7:52) at Module._compile (internal/modules/cjs/loader.js:778:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) at Module.load (internal/modules/cjs/loader.js:653:32) at tryModuleLoad (internal/modules/cjs/loader.js:593:12) at Function.Module._load (internal/modules/cjs/loader.js:585:3) 2. Also node-yargs is missing a dependency on node-define-property. /usr/share/nodejs/yargs/yargs.js:1242 else throw err ^ Error: Cannot find module 'define-property' 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. (/home/pravi/forge/js-team/node-window-size/index.js:10:14) -- 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: webpack: mkdirp > 1 patch seems broken
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.
--
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: Bug#977962: Bug#977962: webpack: mkdirp > 1 patch seems broken
On Wed, Dec 23, 2020 at 16:06, Jonas Smedegaard wrote: memfs? Is Nodejs module "memfs" in Debian, or are you talking about something else here? memfs is used by compression-webpack-plugin for tests, but it is not yet packaged. -- 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#977900: node-autoprefixer: FTBFS: ENOENT: no such file or directory, open 'path'
Control: tags -1 pending On Tue, 22 Dec 2020 16:25:36 +0100 Andreas Beckmann wrote: > debian/autoprefixer.js → dist/autoprefixer.js... > [!] Error: Could not load path (imported by ./../usr/share/nodejs/postcss/lib/map-generator.js): ENOENT: no such file or directory, open 'path' > Error: Could not load path (imported by ./../usr/share/nodejs/postcss/lib/map-generator.js): ENOENT: no such file or directory, open 'path' > > make[1]: *** [debian/rules:14: override_dh_auto_build] Error 1 > make[1]: Leaving directory '/build/node-autoprefixer-10.0.0' > make: *** [debian/rules:11: binary] Error 2 > > A previous build on Oct 28 has been successful, so this current failure is probably > caused by some updated (transitive) build-depends. It is fixed by changing the order of plugins used in rollup.config.js, rollup-plugin-polyfills should come before commonjs and node-resolve plugins. -- 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#978014: node-schema-utils: missing dependency
Package: node-schema-utils Version: 3.0.0-3 Severity: important schema-utils mentions "@types/json-schema": "^7.0.6" as a dependency in its package.json but it is not available in debian. It should probably be added to node-json-schema and added as a dependency to node-schema-utils. -- 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#977688: node-css-loader: please embed additional postcss extensions
Control: block -1 by 977900 Control: tag 977900 help On Sat, 19 Dec 2020 23:21:20 +0530 Pirate Praveen wrote: > I'd like to update css-loader to latest upstream release/postcss 8 > transition before I work on this. node-postcss 8 transition is blocked by an ftbfs bug in node-autoprefixer https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977900 (need help) -- 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#940704: Bug#940704: some tests do pass
On Thu, Dec 24, 2020 at 19:50, Paolo Greppi
wrote:
I have run jest in the yarnpkg source tree with:
jest --ci __tests__/
You can add this to debian/tests/pkg-js/test
having this jest.config.js to disable failing tests:
and include this as a patch.
module.exports = {
testURL: "http://localhost/;,
testPathIgnorePatterns: [
"/node_modules/",
"/__tests__/index.js",
"/__tests__/integration.js",
"/__tests__/lifecycle-scripts.js",
"/__tests__/pipe.js",
"/__tests__/commands/pack.js",
"/__tests__/commands/run.js",
"/__tests__/fixtures",
"/__tests__/reporters/_mock.js",
"/__tests__/commands/_helpers.js",
"/__tests__/_temp.js",
"/__tests__/__mocks__",
"/__tests__/commands/install/lockfiles.js"
]
}
result:
Test Suites: 1 skipped, 81 passed, 81 of 82 total
Tests: 15 skipped, 1116 passed, 1131 total
Snapshots: 111 passed, 111 total
Time:74.936s
Ran all test suites matching /__tests__\//i.
I think we can include it in the autopkgtest, later we can try to
understand why some tests are failing ..
yes, running some tests soon while we figure out what is wrong with the
rest is a good idea.
Note:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-November/047062.html
Paolo
--
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#978033: node-autoprefixer: build ruby-autoprefixer-rails binary
Package: node-autoprefixer Version: 10.1.0+~cs11.3.2.0-1 Severity: wishlist Now node-autoprefixer includes autoprefixer-rails as a component in source package (for its build directory). We can build ruby-autoprefixer-rails binary package from the same source and drop libjs-autoprefixer (there is no such independant browser library upstream and it was specifically created for use in autoprefixer-rails). This will reduce the maintenance burden. -- 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-postcss 7.x -> 8.x transition - work started in experimental
On Mon, Sep 28, 2020 at 8:01 pm, Pirate Praveen wrote: Hi, I have uploaded node-postcss 8.0.5-1 to experimental. I have started https://wiki.debian.org/Javascript/Nodejs/Transitions/PostCSS8 to track progress of this transition. Help is welcome. With all reverse dependencies fixed and bug filed against rainloop (on 28th Sepetember). I'm going to upload node-postcss 8.x to unstable now. Thanks to yadd for help with the transition. -- 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#971271: rainloop: ftbfs with node-postcss 8.0 in experimental
Control: retitle rainloop: ftbfs with node-postcss 8.0 Control: severity -1 serious On Mon, 28 Sep 2020 21:21:26 +0530 Pirate Praveen wrote: > > node-postcss 8.x will be uploaded to unstable when node-css-loader is > ready (there is already an upstream pull request and hopefully next > release will support it). Please make sure rainloop is ready for the > transition. > node-postcss 8 is now in unstable and raising severity to serious. -- 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#977670: Bug#977670: jest: should explicitly (build-)depend on needed babel modules
On Fri, Dec 18, 2020 at 17:28, Jonas Smedegaard wrote: Package: jest Version: 26.6.3+repack+~cs61.38.31-2 Followup-For: Bug #977670 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: reoen -1 Control: retitle -1 jest: should explicitly (build-)depend on needed babel modules Thanks for clarifying that this issue is not scenario a). Now, please either... b) if only some embedded modules need babel-related modules at runtime, and jest does not need those at runtime, then move them to a package which itself need babel at runtime, otherwise c) explicitly depend on the (possibly virtual) module packages needed I.e. in any case it is wrong to declare (build-)dependency on "node-babel7" because that package name represents a *bundle* of modules, not explicit modules. In short: please explicitly (build-)depend on needed babel modules Explicitly, not implicitly through bundle-package (which may change content in future!). This does not work for buster-backports. I had to change dependency to node-debbundle-acorn from virtual packages in webpack and rollup for packages that build depends on webpack or rollup to work. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
