Bug#1011973: node-webpack-sources: autopkgtest failure TypeError: addMapping is not a function
with node-source-map 0.7 built from salsa master branch, there is only 1 failure. 26 tests were failing earlier with node-source-map 0.6. This is a red herring. The autopkgtest fails aren't related to node-source-map at all. Specifically, the tests don't fail in gbp buildpackage, but only in autopkgtest, that too only in one particular stage. That's because the __mocks__ that jest relies on are in the lib/helpers/ directory and that's not available somehow to the autopkgtest run. For example, if you do autopkgtest with --shell-fail and after it fails copy __mocks__ to /usr/share/nodejs/webpack-sources/lib/helpers and rerun the test with /usr/share/pkg-js-autopkgtest/runner it passes You can replicate it by downloading upstream code and removing `__mocks__` folder and running yarnpkg test https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices#Recommendations > Use upstream test-suite if they have as-installed test The jest tests are not as-installed
Bug#1009598: reassigned this bug to node-postcss-loader
On Wed, 11 May 2022 11:23:52 +0200 Georges Khaznadar wrote: Hello, the errors raised during the build of node-ktex are due to an error which comes from node-postcss-loader I can confirm the bug is in node-postcss-loader It is because webpack 5 is required for this version of postcss-loader. https://github.com/webpack-contrib/postcss-loader/issues/514
Bug#1009245: ruby-autoprefixer-rails: broken build (TypeError: Cannot read property 'env' of undefined)
On the other hand, the autoprefixer.js from the gem (about 1 MB) and the autoprefixer.js that's generated through build from the upstream repo (about 8 MB) seems to be different. This is unexplained by the dev. I was comparing an older version of the gem actually. Please ignore this comment. On the other hand, I have found that the node-resolve is somehow resolving util.js from the system (/usr/share/nodejs) instead of node_modules (possibly related to the patch we're applying) and that causes process.env to be read directly (without handling it as if it is inside browser)
Bug#1009245: ruby-autoprefixer-rails: broken build (TypeError: Cannot read property 'env' of undefined)
There is a possibility that this is related to the execjs version. https://github.com/ai/autoprefixer-rails/issues/203#issuecomment-838512342 On the other hand, the autoprefixer.js from the gem (about 1 MB) and the autoprefixer.js that's generated through build from the upstream repo (about 8 MB) seems to be different. This is unexplained by the dev.
Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require
Package: ruby-google-protobuf Version: 3.17.3-1 Severity: grave Justification: renders package unusable Dear Maintainer, I was trying to install gitlab to reproduce #966653 Installed ruby-google-protobuf from experimental The pg_query library was erroring at startup, with failure to require 'google/protobuf' I tried to isolate it to debian by `gem install google-protobuf` It worked correctly with that. On comparing stable version http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.12.4-1_amd64.deb with the experimental version http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.17.3-1_amd64.deb I could see that the latter lacks the /2.7.0/gems/lib/google/protobuf directory altogether The upstream gem at https://rubygems.org/downloads/google-protobuf-3.17.3.gem includes this lib directory with lots of ruby files I'm suspecting that this folder is critical to the functioning of this package -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ruby-google-protobuf depends on: ii libc6 2.31-13 ii libruby2.7 2.7.4-1 ii ruby1:2.7+2 ruby-google-protobuf recommends no packages. ruby-google-protobuf suggests no packages. -- no debconf information
Bug#990458: libjs-autosize is not fixed by node-babel-plugin-add-module exports update
https://stackoverflow.com/questions/33505992/babel-6-changes-how-it-exports-default But most importantly https://kentcdodds.com/blog/misunderstanding-es6-modules-upgrading-babel-tears-and-a-solution 03-Jul-2021 16:56:56 Pirate Praveen : > Control: reopen -1 > > On Wed, 30 Jun 2021 22:40:13 +0530 Pirate Praveen > wrote: >> and this is working with diaspora. Thanks again for tracking down the >> issue. > > Looks like I was wrong here and it is still failing with libjs-autosize built > with latest node-babel-plugin-add-module-exports. > > You can see this on browser console of > https://diaspora.publicvm.com/statistics (setup by Rojin for testing).
Bug#990458: Attaching the files from buster vs bullseye
This is most likely due to babel-plugin-add-module-exports being broken. See https://github.com/59naga/babel-plugin-add-module-exports/issues/72 and https://github.com/59naga/babel-plugin-add-module-exports/issues/80 and https://github.com/59naga/babel-plugin-add-module-exports/issues/73 That 73 points to a new version that's put only on npm and not on github. I'm not exactly sure how it works with fakeupstream at https://salsa.debian.org/js-team/node-babel-plugin-add-module-exports/-/tree/master/ Either way, the version in salsa seems to be 0.2.1 which is definitely outdated (as per the github description of babel-plugin-add-module-exports Two ways I see are: Either, update this plugin in Debian to the fork that's pushed only to npm (or switch to https://github.com/lijunle/babel-plugin-add-module-exports/ I guess) OR Try removing this plugin altogether and changing the "export default autosize" statement in the last line of autosize.js to "module.exports = autosize" I'm NOT sure whether either of these will work.
Bug#977900: node-autoprefixer: FTBFS: ENOENT: no such file or directory, open 'path'
A few observations. 1) The commit https://github.com/rollup/plugins/commit/1459cf0ab5e5eb7beee46f52bc4dbbb88d3e4335#diff-c68d63c5e10e04a850c0ea8abd479dbb77c794b3aadecf91483dcf3df96156df which prevents exceptions from being silently ignored maybe the reason why this is starting to err. 2) See this build log: https://salsa.debian.org/js-team/node-autoprefixer/-/jobs/1280125 Line 1757 has the dh_auto_configure output dh_auto_configure --buildsystem=nodejs -O--package=node-autoprefixer mkdir node_modules ln -s ../fractionjs node_modules/fraction.js debian/rules override_dh_auto_build It only symlinks fractionjs. I don't really read perl, but I think https://salsa.debian.org/js-team/pkg-js-tools/-/blob/master/lib/Debian/Debhelper/Buildsystem/nodejs.pm#L128 says this: next if $self->main_package and $component eq $self->main_package; which probably means it will skip a component of the same name as the package. Here, component autoprefixer is probably clashing with the name "node-autoprefixer". On line 1770 this causes (!) Circular dependency autoprefixer.js -> autoprefixer.js where another filename clash makes import from "autoprefixer" to resolve to build/autoprefixer.js (probably because it doesn't have an autoprefixer in node_modules because of dh_auto_configure above) 3) https://salsa.debian.org/js-team/node-autoprefixer/-/blob/master/debian/patches/rearrange-plugins-order.patch seems to revert the changes to nodeResolve.customResolveOptions.moduleDirectory in the first patch. Akshay
Bug#977781: [Pkg-javascript-devel] Bug#977781: Bug#977781: real issue is, it does not pull not-yet-cached modules
gbp:error: upstream/1.22.10+_cs18.39.16 is not a valid treeish indeed your fork only has 33 tags, whereas js-team/node-yarnpkg has 37. Please pull those tags and push them to your fork, then force restart the CI pipeline. This would help us to see if your proposed fix works. Pushing tags indeed helped extract sources. But build fails due to incompatibilities with upstream files As to upgrading tar-fs, it is possible that some other dependency we updated here and there requires it. Upstream are currently using 1.16.3: https://github.com/yarnpkg/yarn/blob/master/yarn.lock#L7137 whereas we were already using version 2 If we want to upgrade tar-fs we need to upgrade its sources and then import them in upstream and master branches: https://wiki.debian.org/Javascript/GroupSourcesTutorial I think Praveen locked the dependency on tar-fs to version 1.x in https://salsa.debian.org/js-team/node-yarnpkg/-/commit/8f44f7d238f4330b89d3b62c2cc369bb909459a6 I'm unsure if that's because upstream yarn mentions 1.x tar-fs as dependency or because there are other dependencies to 1.x tar-fs. The API of tar-fs doesn't change between 1.x and 2.x, but the dependencies do. And the dependencies we have in debian make it such that 1.x doesn't work. I tried following GroupSourcesTutorial and gbp manual. It is becoming very confusing for me with many version numbers and tags floating around. So I'll have to leave this here for possibly Praveen to pick up. Akshay
Bug#977781: [Pkg-javascript-devel] Bug#977781: real issue is, it does not pull not-yet-cached modules
There are some 4 pipes before the finish event. I'm looking through each one of them to see if there's a mismatch. It seems to be tar-fs Please see https://salsa.debian.org/js-team/node-yarnpkg/-/merge_requests/4 I've just downloaded the latest version from the github of tar-fs and replace in the directory. Not sure if this is the way to do it.
Bug#977781: [Pkg-javascript-devel] Bug#977781: real issue is, it does not pull not-yet-cached modules
> >I think the real issue is that it does not pull not-yet-cached
modules.
>
I did some console.log debugging yesterday.
The tarball-fetcher, for whatever be the reason, doesn't ever trigger
the .on('finish' event
https://salsa.debian.org/js-team/node-yarnpkg/-/blob/master/src/fetchers/tarball-fetcher.js#L164
There are some 4 pipes before the finish event. I'm looking through each
one of them to see if there's a mismatch.
Bug#977781: yarnpkg: fails to download modules
> Since yarnpkg add command did not return an error, the autpkgtest was > succeeding even though it did not add any modules to node_modules > directory. > I did a bisect (sort of). Removing cache is not an issue till commit 232ee703 (New upstream version 1.22.4+debian) But, it is an issue at commit d40971ee (Refresh patches (remove parts no longer needed) The one commit in between them - New upstream version 1.22.10+~cs18.39.16 ( 40af4cca ) could be the one which introduced this.
Bug#977781: yarnpkg: fails to download modules
> Since yarnpkg add command did not return an error, the autpkgtest was > succeeding even though it did not add any modules to node_modules > directory. > I did a bisect (sort of). Removing cache is not an issue till commit 232ee703 (New upstream version 1.22.4+debian) But, it is an issue at commit d40971ee (Refresh patches (remove parts no longer needed) The one commit in between them - New upstream version 1.22.10+~cs18.39.16 ( 40af4cca ) could be the one which introduced this. signature.asc Description: This is a digitally signed message part.
