[Pkg-javascript-devel] Bug#1012021: Bug#1012021: unreproducible here

[Paolo Greppi]

Il 29/05/22 21:34, Pirate Praveen ha scritto:


On തി, മേയ് 30 2022 at 12:56:53 രാവിലെ +05:30:00 +05:30:00, Pirate 
Praveen  wrote:


On ഞാ, മേയ് 29 2022 at 09:34:45 രാവിലെ +02:00:00 +02:00:00, Paolo 
Greppi  wrote:
Hi Andreas! thanks for your report. To try to reproduce it, I set 
...
Finally there is more trouble ahead when building this package, 
because I also tried:


    apt install git
    git clone 
https://salsa.debian.org/pkg-security-team/greenbone-security-assistant

    cd greenbone-security-assistant
    yarnpkg
    yarnpkg build

and the last command failed with:

    ...
    Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:130:10)
    at module.exports 
(/greenbone-security-assistant/node_modules/webpack/lib/util/createHash.js:135:53) 

    at NormalModule._initBuildHash 
(/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:417:16) 

    at 
/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:452:10 

    at 
/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:323:13 

    at 
/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:367:11 

    at 
/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:233:18 

    at context.callback 
(/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:111:13) 

    at 
/greenbone-security-assistant/node_modules/babel-loader/lib/index.js:59:103 

    at processTicksAndRejections 
(node:internal/process/task_queues:96:5) {
  opensslErrorStack: [ 'error:0386:digital envelope 
routines::initialization error' ],

  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
    }
    error Command failed with exit code 1.

(this also happens on amd64 BTW).

According to the interwebs this should only occur with node v17 
(whereas in unstable we have v16.15.0) and indeed the commonly 
proposed workaround fails:


    NODE_OPTIONS=--openssl-legacy-provider yarnpkg build
    /usr/bin/node: --openssl-legacy-provider is not allowed in 
NODE_OPTIONS



I was also seeing this error while looking at node-babel-loader

We might need to fix node-babel-loader

https://github.com/babel/babel-loader/issues/923




Even though the pull request is merged 
https://github.com/babel/babel-loader/pull/924 I get same error on 
master branch of upstream babel-loader repo with yarnpkg test.





It seems ad-hoc fixes may be required for each package, such as this 
other one:

https://salsa.debian.org/js-team/node-cacache/-/commit/214b963bd02fd74d445789b184d344777dda8ee2

What is mysterious is that all that should only happen with nodejs v17 ...

P.

--
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#1012021: unreproducible here

[Paolo Greppi]

Hi Andreas! thanks for your report. To try to reproduce it, I set up 
multiarch for docker (https://github.com/multiarch/qemu-user-static) then:


docker run --rm -it arm64v8/debian:unstable bash
apt update
apt upgrade
apt install curl yarnpkg
curl -o package.json 
https://salsa.debian.org/pkg-security-team/greenbone-security-assistant/-/raw/debian/master/package.json?inline=false
curl -o yarn.lock 
https://salsa.debian.org/pkg-security-team/greenbone-security-assistant/-/raw/debian/master/yarn.lock?inline=false

yarnpkg

(this command reads the list of dependencies from package.json + the 
exact versions from yarn.lock and downloads them all in node_modules/ dir).


While the command runs, top reports that the node process is using quite 
some memory:


   PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM 
TIME+ COMMAND
595069 root  20   0 2202764 688100  44356 R 128,2   2,9 
9:06.30 node


but ultimately it succeeds:

root@f679258d6a63:/# yarnpkg
yarn install v1.22.19
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
[4/5] Linking dependencies...
warning "@greenbone/ui-components > bootstrap@4.6.0" has unmet peer 
dependency "jquery@1.9.1 - 3".
warning "@greenbone/ui-components > bootstrap@4.6.0" has unmet peer 
dependency "popper.js@^1.16.1".
warning "@greenbone/ui-components > styled-components@5.2.1" has 
unmet peer dependency "react-is@>= 16.8.0".
warning " > babel-loader@8.1.0" has unmet peer dependency 
"webpack@>=2".
warning "react-scripts > @typescript-eslint/eslint-plugin > 
tsutils@3.17.1" has unmet peer dependency "typescript@>=2.8.0 || >= 
3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev || >= 3.5.0-dev || >= 
3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || >= 3.7.0-beta".
warning "@storybook/react > react-docgen-typescript-plugin@0.6.2" 
has unmet peer dependency "typescript@>= 3.x".
warning "@storybook/react > react-docgen-typescript-plugin > 
react-docgen-typescript@1.20.5" has unmet peer dependency "typescript@>= 
3.x".
warning "@storybook/react > react-docgen-typescript-plugin > 
react-docgen-typescript-loader@3.7.2" has unmet peer dependency 
"typescript@*".
warning " > @testing-library/user-event@13.1.9" has unmet peer 
dependency "@testing-library/dom@>=7.21.4".
warning " > eslint-config-prettier@8.3.0" has unmet peer dependency 
"eslint@>=7.0.0".

[5/5] Building fresh packages...
Done in 448.36s.
root@f679258d6a63:/# uname -a
Linux f679258d6a63 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 
(2022-04-29) aarch64 GNU/Linux


Could it be an issue of low-memory on the !amd64 builder machines ?

Also I was looking for logs here but no luck:
https://buildd.debian.org/status/package.php?p=greenbone-security-assistant

Finally there is more trouble ahead when building this package, because 
I also tried:


apt install git
git clone 
https://salsa.debian.org/pkg-security-team/greenbone-security-assistant

cd greenbone-security-assistant
yarnpkg
yarnpkg build

and the last command failed with:

...
Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:67:19)
at Object.createHash (node:crypto:130:10)
at module.exports 
(/greenbone-security-assistant/node_modules/webpack/lib/util/createHash.js:135:53)
at NormalModule._initBuildHash 
(/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:417:16)
at 
/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:452:10
at 
/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:323:13
at 
/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:367:11
at 
/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:233:18
at context.callback 
(/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
at 
/greenbone-security-assistant/node_modules/babel-loader/lib/index.js:59:103
at processTicksAndRejections 
(node:internal/process/task_queues:96:5) {
  opensslErrorStack: [ 'error:0386:digital envelope 
routines::initialization error' ],

  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}
error Command failed with exit code 1.

(this also happens on amd64 BTW).

According to the interwebs this should only occur with node v17 (whereas 
in unstable we have v16.15.0) and indeed the commonly proposed 
workaround fails:


NODE_OPTIONS=--openssl-legacy-provider yarnpkg build
/usr/bin/node: --openssl-legacy-provider is not allowed in NODE_OPTIONS

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

Re: [Pkg-javascript-devel] Rebuilding of nodejs reverse dependencies

[Paolo Greppi]

Hi Jérémy,

Il 17/03/22 13:26, Jérémy Lal ha scritto:

...

So I ended up installing a gitlab-runner with nspawn-runner and a
semi-active server I maintain.
I documented the process here:
https://wiki.debian.org/Salsa/Doc/CustomRunners/SystemdNspawnRunner


salsa's driving that runner to rebuild the thousands of packages now.
Minimal build time is 1 minute, so it should take about two days to
rebuild the whole.

After that, anyone knowing gitlab API and bugs.debian.org
 API could help to open FTBFS bugs ?

I started this:
https://salsa.debian.org/kapouer/dance 



to fetch logs of failed jobs, and also to be able to retry jobs that 
failed because of external reasons

(runner configuration issue, for example).
When all jobs are finished, i'll start to use "dance" to send bug reports.

Jérémy


this is all super interesting. In the past I have done quite a few mass 
rebuilds of reverse dependencies using ratt 
(https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.1-1_amd64%20partial%202)


Your approach is cool because it can be easier to automate.

To look at pipeline results programmatically I would have used this 
Python library:

- https://packages.debian.org/bullseye/python3-gitlab
- 
https://python-gitlab.readthedocs.io/en/stable/gl_objects/pipelines_and_jobs.html


But I see you plan to use JS for "dance".

Do you intend to trigger the dance from within the pipeline ? You'd then 
have a recursive pipeline ... who knows if it will finish in finite time ;-)


Anyway from my experience:

1. some rdeps reproducibly fail all the time, these should be excluded

2. ratt rebuilds failed rdeps against the previous version of the parent 
package (this filters out false positives), does your job definition do 
that as well ? (too lazy to check)


3. some rdeps take much longer to build than others, I ended up creating 
lists of "fast" and "slow" rdeps; if you only include "fast" ones your 
mass rebuild can run in hours instead of days, but may still be able to 
catch regressions


4. I used to create spreadsheets to compare build times and which rdep 
failed; for max fun it would be nice to have a database (!) where to 
store (stamp, parent_package, old_version, new_version, rdep, status, 
duration)


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

Re: [Pkg-javascript-devel] Bug#980316: about corepack and yarnpkg

[Paolo Greppi]

Hi all

Il 09/01/22 21:59, Paolo Greppi ha scritto:
I stumbled upon this thread related to packaging corepack for gentoo: 
https://github.com/nodejs/corepack/issues/76


We now have node 16 in experimental, but our package does not bundle 
corepack (as upstream does):

https://packages.debian.org/experimental/amd64/nodejs/filelist

I propose that we create a RFP/ITP for corepack separate from nodejs, 
with Conflicts: yarnpkg


The corepack binary would install /usr/bin/yarnpkg pointing to the 
corepack shims; this would allow Debian users who "use different package 
manager versions across multiple projects" to happily install random 
binaries downloaded from the internet if they wish.


If we agree that we (as a distribution) need specific versions of 
yarnpkg (for building other stuff, we need to keep one or more yarnpkg 
packages in Debian, all with Conflicts: corepack + each other.


If we really want yarnpkg 1, according to my tests, the corepack route 
is useless:


     docker pull node:16
     docker run -it --rm node:16 bash
     yarn -v # 1.22.15
     # this downloads https://registry.npmjs.org/yarn/-/yarn-1.22.17.tgz
     # based on the versions / 1.22.17 / dist / tarball value in:
     # https://registry.yarnpkg.com/yarn/
     corepack prepare yarn@1.22.17 --activate
     yarn -v # 1.22.15
     corepack yarn -v # 1.22.17
     ls -l /root/.node/corepack

     total 2
     -rw-r--r-- 1 root root 63 Jan  9 18:33 lastKnownGood.json
     drwxr-xr-x 1 root root 14 Jan  9 18:13 yarn

To "build" it quick and dirty we can download once and for all the same 
pre-built binary that corepack would download, extract it and symlink it 
to /usr/bin/yarnpkg (without shims); this package should go to contrib 
since it downloads stuff from the internet during the build, but would 
fix the issue of yarnpkg blocking the migration to webpack5 and removal 
of node-request.
Or else keep alive the current version in main by just bundling into it 
webpack4 and node-request.


If we really want a new yarnpkg3 package, corepack is also useless as it 
merely installs yarnpkg 1.
The upstream recommended way of installing yarnpkg 3 (get yarn 1 with 
corepack then yarn init -2 (sic!)) just downloads the current pre-built 
binary (ATM 
https://repo.yarnpkg.com/3.1.1/packages/yarnpkg-cli/bin/yarn.js, 2199165 
bytes) to .yarn/releases/yarn-3.1.1.cjs.
AFAICT this does not integrate with the shared package manager versions 
stored in ~/.node/corepack.


One way to "build" yarnpkg3 quick and dirty is to download once and for 
all the same pre-built binary that yarn init -2 would download, and 
symlink it to /usr/bin/yarnpkg (without shims).
Or if we want it in main we should replicate the way upstream builds 
this yarn.js binary.


Sorry for the long message, this is a mess!

Paolo



the bugs related to yarn 1 are piling up, what do we want to do as a 
team on this ?


I vote for keeping yarn 1 in the archive by bundling into it 
node-babel-eslint, webpack4 and node-request-capture-har/node-request. 
This would address #1002902, #1001630, #1000582 and #958686.


BTW in the meantime nobody created a RFP/ITP for corepack: it looks like 
there's not so much interest for that.


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

Re: [Pkg-javascript-devel] RFH: puppeteer tests

[Paolo Greppi]

On 14/01/22 09:48, Jérémy Lal wrote:


Le ven. 14 janv. 2022 à 09:41, Yadd > a écrit :

...
Hi,

I started to modify your package. The problem for tests is that it
launches chromium, then this requires X server.


Unless the tests run chromium with the --headless flag...
but i guess some tests don't.

Jérémy



With puppeteer chrome UI appears if it is started with:

  const browser = await puppeteer.launch({
headless: false
  })

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#980316: about corepack and yarnpkg

[Paolo Greppi]

I stumbled upon this thread related to packaging corepack for gentoo: 
https://github.com/nodejs/corepack/issues/76


We now have node 16 in experimental, but our package does not bundle 
corepack (as upstream does):

https://packages.debian.org/experimental/amd64/nodejs/filelist

I propose that we create a RFP/ITP for corepack separate from nodejs, 
with Conflicts: yarnpkg


The corepack binary would install /usr/bin/yarnpkg pointing to the 
corepack shims; this would allow Debian users who "use different package 
manager versions across multiple projects" to happily install random 
binaries downloaded from the internet if they wish.


If we agree that we (as a distribution) need specific versions of 
yarnpkg (for building other stuff, we need to keep one or more yarnpkg 
packages in Debian, all with Conflicts: corepack + each other.


If we really want yarnpkg 1, according to my tests, the corepack route 
is useless:


docker pull node:16
docker run -it --rm node:16 bash
yarn -v # 1.22.15
# this downloads https://registry.npmjs.org/yarn/-/yarn-1.22.17.tgz
# based on the versions / 1.22.17 / dist / tarball value in:
# https://registry.yarnpkg.com/yarn/
corepack prepare yarn@1.22.17 --activate
yarn -v # 1.22.15
corepack yarn -v # 1.22.17
ls -l /root/.node/corepack

total 2
-rw-r--r-- 1 root root 63 Jan  9 18:33 lastKnownGood.json
drwxr-xr-x 1 root root 14 Jan  9 18:13 yarn

To "build" it quick and dirty we can download once and for all the same 
pre-built binary that corepack would download, extract it and symlink it 
to /usr/bin/yarnpkg (without shims); this package should go to contrib 
since it downloads stuff from the internet during the build, but would 
fix the issue of yarnpkg blocking the migration to webpack5 and removal 
of node-request.
Or else keep alive the current version in main by just bundling into it 
webpack4 and node-request.


If we really want a new yarnpkg3 package, corepack is also useless as it 
merely installs yarnpkg 1.
The upstream recommended way of installing yarnpkg 3 (get yarn 1 with 
corepack then yarn init -2 (sic!)) just downloads the current pre-built 
binary (ATM 
https://repo.yarnpkg.com/3.1.1/packages/yarnpkg-cli/bin/yarn.js, 2199165 
bytes) to .yarn/releases/yarn-3.1.1.cjs.
AFAICT this does not integrate with the shared package manager versions 
stored in ~/.node/corepack.


One way to "build" yarnpkg3 quick and dirty is to download once and for 
all the same pre-built binary that yarn init -2 would download, and 
symlink it to /usr/bin/yarnpkg (without shims).
Or if we want it in main we should replicate the way upstream builds 
this yarn.js binary.


Sorry for the long message, this is a mess!

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#1001532: Bug#1001532: yarnpkg: yarnpkg --version cannot find @babel/runtime/helpers module

[Paolo Greppi]

Il 11/12/21 18:29, Brian Thompson ha scritto:

Package: yarnpkg
Severity: important

Dear Maintainer,

After install yarnpkg for the first time and running `yarnpkg --version`, I
got the following error:

Error: Cannot find module '@babel/runtime/helpers/interopRequireWildcard'

I expected the package to return its version.


Thanks for reporting the issue. Unfortunately I can not reproduce it on 
any of my systems here.




I also tried on a "clean" Debian stable install with:



  docker run -it --rm debian:bullseye bash

  apt update && apt install yarnpkg

  yarnpkg --version



and I get:



  1.22.10



I run the command under strace and it looks like indeed it does not find 
/usr/share/nodejs/yarn/node_modules/@babel/runtime/helpers/interopRequireWildcard.js, 
but it then proceeds to also try 
/usr/lib/x86_64-linux-gnu/nodejs/@babel/runtime/helpers/interopRequireWildcard.js 
(not here) and finally 
/usr/share/nodejs/@babel/runtime/helpers/interopRequireWildcard.js (this 
one is there).




With:



  dpkg -S 
/usr/share/nodejs/@babel/runtime/helpers/interopRequireWildcard.js




I find that interopRequireWildcard.js is installed by package 
node-babel7-runtime which is listed as a "dep" of yarnpkg here:


https://packages.debian.org/bullseye/yarnpkg



Is it possible that on your system you have installed some non-Debian 
node module that takes precedence over the ones installed by the Debian 
packages?




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#991544: closing rathen than merging

[Paolo Greppi]

See https://bugs.debian.org/985857

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#991544: Bug#991544: please package bootstrap 5

[Paolo Greppi]

Hi,

Il 27/07/21 08:51, Daniel Baumann ha scritto:

Package: twitter-bootstrap4

Hi,

thanks a lot for maintaining bootstrap in Debian.

Do you already have an ETA for bootstrap 5 (probably a new package in
Debian I guess)?

Regards,
Daniel



thanks for your request but twitter-bootstrap4 is no Debian package (it's
libjs-bootstrap4)

Anyway libjs-bootstrap5 has been requested before as a RFP proper, so I'll
merge this one with the bug #985857.

RFPs (Requests for Package) are the correct way of entering new package
requests in Debian:
https://wiki.debian.org/RFP

As you can see there is no activity in #985857 yet, so it's basically up for
anyone to pick it (we welcome new contributors ;-).

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

Re: [Pkg-javascript-devel] Processed: BTS housekeeping and severity adjustments

[Paolo Greppi]

Il 31/05/21 23:33, Debian Bug Tracking System ha scritto:

Processing commands for cont...@bugs.debian.org:


severity 986117 serious

Bug #986117 [yarnpkg] yarnpkg is not compatible with node-proper-lockfile 3.0.0+
Severity set to 'serious' from 'normal'
...


Hu everybody, I have drafted a patch for this issue:
https://salsa.debian.org/js-team/node-yarnpkg/-/blob/master/debian/patches/19-proper-lockfile.diff

Any comments?

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#940704: I give up

[Paolo Greppi]

Control: noowner -1
Control: tags -1 - pending

Trying to make the upstream test suite, designed for jest 22, work with our 
jest 26 is tricky.

Also some things defy intuition, i.e. I patch here:
https://salsa.debian.org/js-team/node-yarnpkg/-/blob/wip/paolog/jest/debian/patches/20-jest-require-actual.diff#L26
and the autopkgtest baffles me:
https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1387234#L273

I have parked my work in the wip/paolog/jest branch.
I'll release 1.22.10+~cs22.25.14-2 without the test suite FTMB, we can pick it 
up from there later.

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#981241: tracker.debian.org: please update uscan

[Paolo Greppi]

Package: tracker.debian.org
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org
Severity: important

For yarnpkg: https://tracker.debian.org/pkg/node-yarnpkg
tracker.debian.org reports:

  uscan had problems while searching for a new upstream version:
  unrecognized option ctype=nodejs

The option was added with devscripts 2.20.5:
https://lists.debian.org/debian-perl/2020/11/msg00047.html

Please upgrade devscripts so that uscan works reliably for packages that use 
the option.

BTW thanks for the excellent service! Paolo

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--
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: next error

[Paolo Greppi]

Dear Xavier,

Il 27/01/21 06:30, Xavier ha scritto:

Le 27/01/2021 à 00:14, Paolo Greppi a écrit :

I fixed the error:

     Cannot find module 'babel-preset-env'

but I am not sure if the fix is 100% right.

Now I get:

     TypeError: Cannot read property 'mkdir' of undefined
    5 | export default function(filename?: string):
Promise {
    6 |   return new Promise((resolve, reject) => {
     >  7 | temp.mkdir(filename, function(err, path) {

I added node-temp in debian/tests/control Depends afetr jest, but that
did not help (it would have errored on require('temp') anyway).

I have then turned my attention at brushing up node-temp, see this
message to the js-team list:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052152.html


Hi,

fixed (patch for node-mkdirp ≥ 1), take a look at my changes



Fantastic job thanks!
I suggest that you also upload it - I am still a DM so I'd nee to bother 
someone for sponsorship anyway.

The only comment I have is that the Salsa CI was already enabled, as I had set the Custom CI 
config path to recipes/debian.yml@salsa-ci-team/pipeline in Settings -> CI/CD -> General 
Pipelines as advised "If the base pipeline configuration fits your needs without further 
modifications" here:
https://salsa.debian.org/salsa-ci-team/pipeline#basic-use

But now you have set it to debian/salsa-ci.yml and added that file, with the 
same content as:
https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/recipes/debian.yml
so nothing changes.

Is there any reason why you prefer the debian/salsa-ci.yml way ?

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#940704: next error

[Paolo Greppi]

I fixed the error:

Cannot find module 'babel-preset-env'

but I am not sure if the fix is 100% right.

Now I get:

TypeError: Cannot read property 'mkdir' of undefined
   5 | export default function(filename?: string): Promise {
   6 |   return new Promise((resolve, reject) => {
>  7 | temp.mkdir(filename, function(err, path) {

I added node-temp in debian/tests/control Depends afetr jest, but that did not 
help (it would have errored on require('temp') anyway).

I have then turned my attention at brushing up node-temp, see this message to 
the js-team list:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052152.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] node-temp 0.9.4

[Paolo Greppi]

Hi,

I am preparing an update for node-temp to version 0.9.4, among other things it 
contain a fix to this issue:
https://github.com/bruce/node-temp/issues/91

That will at some point surface in yarnpkg autopkgtest, which I am still 
struggling to set up (see https://bugs.debian.org/940704).
The error you get there is:

SyntaxError: /usr/lib/nodejs/temp/lib/temp.js: Legacy octal literals are 
not allowed in strict mode (227:20)

Anyway node-temp autopkgtest run fine locally but fails with a timeout on salsa 
CI (https://salsa.debian.org/js-team/node-temp/-/jobs/1383063), so I'm stuck.

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] node-i18next-xhr-backend is holding node-babel7 migration

[Paolo Greppi]

According to: https://tracker.debian.org/pkg/node-babel7:
Issues preventing migration: autopkgtest for node-i18next/19.8.2+dfsg-4

Actually I tried building node-i18text 19.8.4 on sid, and it works fine 
including autopkgtest.

And from: https://tracker.debian.org/pkg/node-i18next
Issues preventing migration: autopkgtest for node-i18next-xhr-backend

But node-i18next-xhr-backend has popcon = 1 and according to upstream:
https://github.com/i18next/i18next-xhr-backend
it is "[deprecated] can be replaced with i18next-http-backend"

The latter we already have in Debian:
https://tracker.debian.org/pkg/node-i18next-http-backend

So can we RM node-i18next-xhr-backend ? Any special things I missed ?

Paolo

P.S.: Cc-ing Nicolas as frequent uploader of node-i18text* stuff and original 
owner of node-i18next-xhr-backend ITP https://bugs.debian.org/969295

P.S.2: I am keen in having node-babel7 7.12.12... in testing because that 
version brings a separate node-babel7-runtime which I need to work around 
https://bugs.debian.org/979551

--
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: new error: Cannot find module 'babel-preset-env'

[Paolo Greppi]

Hi, I think I fixed the error:

  Cannot find module 'babel-plugin-transform-inline-imports-commonjs'

with this commit: 
https://salsa.debian.org/js-team/node-yarnpkg/-/commit/d055e01b6d1a7f6fad6df2ccdf6d0f7d01ddcbc2
but the tests still fail, all with this new error:

  FAIL __tests__/commands/licenses.js
● Test suite failed to run
  
  Cannot find module 'babel-preset-env'

  Require stack:
  - /usr/share/nodejs/@babel/core/lib/config/files/plugins.js
  - /usr/share/nodejs/@babel/core/lib/config/files/index.js
  - /usr/share/nodejs/@babel/core/lib/index.js
  - /usr/share/nodejs/babel-jest/build/loadBabelConfig.js
  - /usr/share/nodejs/babel-jest/build/index.js
  - /usr/share/nodejs/@jest/transform/build/ScriptTransformer.js
  - /usr/share/nodejs/@jest/transform/build/index.js
  - /usr/share/nodejs/jest-runtime/build/index.js
  - /usr/share/nodejs/jest-runner/build/testWorker.js
  - /usr/share/nodejs/jest-worker/build/workers/processChild.js
  - Did you mean "@babel/env"?
  
89 |

90 |   try {
  > 91 | return require.resolve(standardizedName, {
   |^
92 |   paths: [dirname]
93 | });
94 |   } catch (e) {
  
at resolveStandardizedName (../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:91:20)

at resolvePreset 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:48:10)
at loadPreset 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:67:20)
at createDescriptor 
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:154:9)
at 
../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:109:50
at Array.map ()
at createDescriptors 
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:109:29)
at createPresetDescriptors 
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:101:10)

see: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1373973

I tried the obvious fix in debian/tests/control:

  -Depends: @, jest
  +Depends: @, jest, node-babel-preset-env

but no change.

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#980775: your initial example also fails with upstream

[Paolo Greppi]

I tried using the docker "official image" for node:

  docker pull node
  docker run -it --rm node bash
  mkdir -p test/foo
  cd test
  yes '' | yarn init
  yarn add file:foo

yields:

  yarn add file:foo
  yarn add v1.22.5
  info No lockfile found.
  [1/4] Resolving packages...
  [2/4] Fetching packages...
  error /test@0.0.0: Name contains illegal characters
  info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this 
command.

you need to add the following as in my previous message:

  cd foo
  yes '' | yarn init
  cd ..

P.

--
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#980775: patch

[Paolo Greppi]

With this WIP patch:
https://salsa.debian.org/js-team/node-yarnpkg/-/blob/master/debian/patches/18-uuid.diff

I can do:

rm -rf /tmp/test
mkdir -p /tmp/test/foo
cd /tmp/test
yes '' | yarn init
cd foo
yes '' | yarn init
cd ..
yarn add file:foo

and get:

yarn add v1.22.10
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
└─ foo@1.0.0
info All dependencies
└─ foo@1.0.0
Done in 0.25s.

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#979551: Bug#979551: node-babel7: update-alternatives set up fails

[Paolo Greppi]

Il 08/01/21 11:35, Jonas Smedegaard ha scritto:

Quoting Paolo Greppi (2021-01-08 08:46:36)

I guess that's because the bullseye-slim image lacks the manpages.


A Debian install with man pages excluded seems to be an unsupported
system: Whatever hooks applied to do that trick should be extended to
handle update-alternatives - not the packages providing alternatives nor
the update-alternatives mechanism itself!

If you disagree, then please try locate passages in Debian Policy to
support your view.


  - Jonas



Sorry I am not qualified to respond.

Using Debian official images with docker/podman is a use case we should support 
as it is one significant way for Debian to stay relevant in this post-devops 
world.

Also see:
- https://hub.docker.com/_/debian/#Image_Variants
- https://github.com/debuerreotype/debuerreotype/issues/10

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#979551: node-babel7: update-alternatives set up fails

[Paolo Greppi]

Package: node-babel7
Version: 7.12.11+~cs150.141.84-3
Severity: important

Dear Maintainer,

installing node-babel7 on official debian "bullseye-slim" docker image fails 
like this:

docker pull debian:bullseye-slim
docker run --rm -it debian:bullseye-slim
apt update && apt install -y --no-install-recommends yarnpkg
...
Setting up node-babel7 (7.12.11+~cs150.141.84-3) ...
update-alternatives: using /usr/bin/babeljs-7 to provide /usr/bin/babeljs 
(babeljs) in auto mode
update-alternatives: using /usr/bin/babeljs-7-external-helpers to provide 
/usr/bin/babeljs-external-helpers (babeljs-external-helpers) in auto mode
update-alternatives: using /usr/bin/babeljs-7-node to provide 
/usr/bin/babeljs-node (babeljs-node) in auto mode
update-alternatives: using /usr/bin/babeljs-7-parser to provide 
/usr/bin/babeljs-parser (babeljs-parser) in auto mode
update-alternatives: error: alternative path /usr/share/man/man1/babeljs-7.1.gz 
doesn't exist
dpkg: error processing package node-babel7 (--configure):
 installed node-babel7 package post-installation script subprocess returned 
error exit status 2
dpkg: dependency problems prevent configuration of yarnpkg:
 yarnpkg depends on node-babel7; however:
  Package node-babel7 is not configured yet.

dpkg: error processing package yarnpkg (--configure):
 dependency problems - leaving unconfigured

I guess that's because the bullseye-slim image lacks the manpages.

BTW, why is node-babel7 a run-time dependency of yarnpkg ?
Should it not just be a build-dep ?

Paolo

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages node-babel7 depends on:
ii  node-browserslist   4.16.0+~cs5.4.69-1
ii  node-chalk  4.1.0-1
ii  node-commander  6.2.1-2
ii  node-convert-source-map 1.7.0+~1.5.1-1
ii  node-core-js3.8.1-1
ii  node-debug  4.3.1+~cs4.1.5-1
ii  node-esutils2.0.3-1
ii  node-find-cache-dir 3.3.1-1
ii  node-fs-readdir-recursive   1.1.0-1
ii  node-glob   7.1.6+~7.1.3-1
ii  node-globals13.5.0-1
ii  node-js-tokens  6.0.0-1
ii  node-jsesc  3.0.2-1
ii  node-json5  2.1.3-2
ii  node-lodash 4.17.20+dfsg+~cs8.31.170-1
ii  node-make-dir   3.0.2-1
ii  node-quick-lru  1.1.0-2
ii  node-regenerator-runtime0.13.7-1
ii  node-regenerator-transform  0.14.5-4
ii  node-regexpu-core   4.7.1-1
ii  node-resolve1.19.0+~cs5.20.8-2
ii  node-semver 7.3.4-1
ii  node-slash  3.0.0-1
ii  node-source-map 0.7.0++dfsg2+really.0.6.1-4
ii  node-source-map-support 0.5.19+ds+~0.5.3-1
ii  node-to-fast-properties 3.0.1-1
ii  node-v8flags3.2.0-1
ii  nodejs  12.19.0~dfsg-1

node-babel7 recommends no packages.

node-babel7 suggests no packages.

-- no debconf information

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

[Pkg-javascript-devel] Yarnpkg future

[Paolo Greppi]

The good news of 2020 was the successful team effort (thanks again Akshay S 
Dinesh and Pirate Praveen !) to keep yarnpkg in bullseye.

Tha bad news of 2021 has been these issues being closed by upstream:
https://github.com/yarnpkg/yarn/issues/8081
https://github.com/yarnpkg/yarn/issues/8083
https://github.com/yarnpkg/yarn/issues/8417

So yarn2 is the future, but yarn1 is still required to “install” it.
More precisely to "vendor" it, i.e. to install in each repo a copy of the 
package manager binary compatible with the package.json / yarn.lock dialect or mode or 
flavor that particular repo is using.

If this sounds crazy, read these issues on the yarn2 (“berry”) upstream:
https://github.com/yarnpkg/berry/issues/181
https://github.com/yarnpkg/berry/issues/2216

As it has been in the last 25 years, the JavaScript ecosystem is a moving 
target (besides yarn2’s pnp mode there is pnpm and deno 
(https://bugs.debian.org/961337) ...) and it does not help to be ideological.
From Debian (or any distribution) POV it’s OK if users choose to use the tools 
we provide in suicidal ways (piping curl into sudo bash, depending on 
registries and binary downloads for each and every build, vendoring binaries 
etc.).
We all do, by the way !

Our only concern should be to also make it possible to use these same tools in 
a sane way, for example making it possible (at some point in the future) to 
reproducibly build a signal-desktop (https://bugs.debian.org/842943) binary 
from clearly identified sources and without network access. Ah, and of course 
maintaining all that in the mid term.

I propose that as js-team we open a single issue on the yarn2 (“berry”) repo, 
with the request to drop yarn1 and to support yarn2 as the only globally 
installed yarnpkg version on the system.
In that case if I init a new “yarn2” repo with my global yarn2 binary, it does 
not need to vendor itself.
But it would vendor yarn1 if you have a legacy repo. Of vendor yarn3 if you 
want to use yarn-next.
When yarn3 becomes stable, upgrade the globally installed yarnpkg version to 
that and so on.

Debian’s baseline task would be to only support the current stable yarnpkg 
version (yes, that will be fun for “berry” see: 
https://bugs.debian.org/976081#63).
And supporting the oldstable version (as we’re doing with yarn1 in bullseye) 
only if required.

What do you think ?

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#940704: autopkgtests now failing

[Paolo Greppi]

I have enabled he upstream test suite on salsa, it fails with many of these:

FAIL __tests__/commands/install/integration.js
  ● Test suite failed to run

Cannot find module 'babel-plugin-transform-inline-imports-commonjs'
Require stack:
...

See: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1287491

Not sure how to proceed ..

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#940704: some tests do pass

[Paolo Greppi]

I have run jest in the yarnpkg source tree with:
jest --ci __tests__/

having this jest.config.js to disable failing tests:

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 ..

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#977781: Bug#977781: Bug#977781: real issue is, it does not pull not-yet-cached modules

[Paolo Greppi]

Hi Akshay, many thanks for the debugging ! see below

Il 22/12/20 06:06, Akshay S Dinesh ha scritto:



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.


It's a pity the salsa Continuous Integration has failed on your fork.

I noticed this message in the extract-source job log:

  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.

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

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#977781: real issue is, it does not pull not-yet-cached modules

[Paolo Greppi]

Hi Pirate,

what you want to put in ~/.yarnrc.yml could be installed globally to 
/etc/yarn/config or /etc/yarnrc, but that does not actually fix it.

I think the real issue is that it does not pull not-yet-cached modules.

To reproduce:

  # clear cache
  rm -rf ~/.cache/yarn
  # actual test
  cd `mktemp -d`
  yarnpkg init -y
  yarnpkg add d3-color

Adding the nodeLinker: "node-modules" option to ~/.yarnrc.yml or the global 
locations does not help.

It would be interesting to debug the JavaScript execution after it prints "Fetching 
packages..."

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#976081: Bug#976081: yarnpkg: Provide prebuilt yarnpkg in contrib

[Paolo Greppi]

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.

I naïvely removed that from the run time deps, but now yarnpkg fails with:

  internal/modules/cjs/loader.js:905
throw err;
^

  Error: Cannot find module 'babel-runtime/helpers/asyncToGenerator'
  Require stack:
  - /usr/share/nodejs/yarn/lib/cli/index.js
  - /usr/share/nodejs/yarn/bin/yarn.js
  at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:902:15)
  at Function.Module._load (internal/modules/cjs/loader.js:747:27)
  at Module.require (internal/modules/cjs/loader.js:974:19)
  at require (internal/modules/cjs/helpers.js:88:18)
  at _load_asyncToGenerator (/usr/share/nodejs/yarn/lib/cli/index.js:17:54)
  at /usr/share/nodejs/yarn/lib/cli/index.js:21:41
  at Object. (/usr/share/nodejs/yarn/lib/cli/index.js:605:3)
  at Module._compile (internal/modules/cjs/loader.js:1085:30)
  at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
  at Module.load (internal/modules/cjs/loader.js:950:32) {
code: 'MODULE_NOT_FOUND',
requireStack: [
  '/usr/share/nodejs/yarn/lib/cli/index.js',
  '/usr/share/nodejs/yarn/bin/yarn.js'
]
  }

Also it does not install the man manpage.

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#973741: Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

[Paolo Greppi]

there is a 4th option, see below

Il 28/11/20 20:28, Pirate Praveen ha scritto:

...
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.


4. Build yarn 2 (berry)

I have done some preliminary exploration.

First, if I follow the upstream suggested path to install yarn 2 I get this (on 
Debian testing with node 14 from experimental):

1. running `npm install yarn` in an empty dir adds node_modules/yarn (about 5 
MB), and no other dependencies; running `./node_modules/yarn/bin/yarn -v` 
returns 1.22.10

2. if you then run `./node_modules/yarn/bin/yarn set version berry` it drops a 
`.yarnrc.yml` file with the content `yarnPath: ".yarn/releases/yarn-berry.cjs"` 
and pulls the single file `.yarn/releases/yarn-berry.cjs` (1.8 MB)

3. now running `./node_modules/yarn/bin/yarn -v` or directly 
`.yarn/releases/yarn-berry.cjs` returns 2.3.3; I can run this file from 
anywhere, referencing its full path

4. for example running `/tmp/yarn/.yarn/releases/yarn-berry.cjs add yarn` in an 
empty dir adds .yarn/unplugged/yarn-npm-1.22.10-b1a926d20f (about 5 MB), and 
running `.yarn/unplugged/yarn-npm-1.22.10-b1a926d20f/node_modules/yarn/bin/yarn 
-v' returns 1.22.10 (back to square one).

What we want is to build the yarn-berry.cjs file from sources. This is what I 
have found on that:

1. Cloning the berry repo from github pulls almost 1GB of data (up from about 
100 MB for yarn 1)

2. the tarball is 180 MB (up from ~70 MB for yarn 1) and has all dependencies 
needed to run yarn (!) including monaco-editor (?) from Microsoft (the code 
editor which powers VS Code), react-icons, 6 versions of the typescript tree 
(version 3.75, 3.95 and 4.1 and three patched versions) etc.

3. running npm install in the source tree fails ('Unsupported URL Type 
"workspace:"')

4. if I delete yarn.lock and remove from package.json the 4 dependencies that 
use the workspace url (@yarnpkg/cli, @yarnpkg/core, @yarnpkg/eslint-config and 
@yarnpkg/pnpify), npm install runs fine

5. we want to run `yarn build:cli`, which according to 
packages/yarnpkg-cli/package.json runs `builder build bundle`; this file gives 
some clue as to what is supposed to happen:
https://github.com/yarnpkg/berry/blob/master/packages/yarnpkg-builder/sources/commands/build/bundle.ts#L96

Finally, I have also found: https://yarnpkg.com/advanced/telemetry

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#973741: Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

[Paolo Greppi]

See below

Il 28/11/20 20:28, Pirate Praveen ha scritto:

On Thu, 19 Nov 2020 23:50:24 +0530 Pirate Praveen  
wrote:
...
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.


I did some tests, but no success.

The plan was to target node 14 (that supports ECMAScript modules) as follows:
- move entire src tree to lib
- strip flow type annotations with @babel/plugin-transform-flow-strip-types
- rename all files from .js to .mjs
- have /usr/bin/yarnpkg just launch node 
/usr/share/nodejs/yarn/lib/cli/index.mjs

I got lost at some point trying to make node find modules here and there, with 
a quote from W. Allen Sleeper's film echoing in my ears:
https://youtu.be/XA_Zrvxjyek#t=1m00s

The resulting binary fails with this error:
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'commander' imported from 
/usr/share/nodejs/yarn/lib/cli/index.mjs

I pushed my failed experiment to this separate repo:
https://salsa.debian.org/paolog/node-yarnpkg/-/tree/wip/paolog/nobabel


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


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.


Not sure if it's relevant, but did you check this comment ?
https://github.com/yarnpkg/yarn/issues/8417#issuecomment-723519990


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).




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

Re: [Pkg-javascript-devel] Bug#972952: Bug#972952: node-mkdirp 1.0 is incompatible with 0.5, breaks yarnpkg

[Paolo Greppi]

Hi Xavier,

Il 26/10/20 20:24, Xavier ha scritto:

Le 26/10/2020 à 15:28, ano...@users.sourceforge.net a écrit :

   ...


Hi JS Team,

yarnpkg is not in testing due to babel problems. Do you agree to
dicrease severity of this bug to allow mkdirp transition (or reassign
this bug to node-yarnpkg) ?

Cheers,
Xavier



I think this should be reassigned to node-yarnpkg and then escalated to upstream
I volunteer to do the second part.

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

Re: [Pkg-javascript-devel] please bring yarnpkg back to testing

[Paolo Greppi]

Hi Pravi, see below

Il 14/09/20 19:01, Pirate Praveen ha scritto:
> 
> 
> On Mon, Sep 14, 2020 at 17:12, Paolo Greppi  wrote:
>> #960120 is keeping yarnpkg out of testing; there are two ways to resolve 
>> this:
>>
>> 1. work with upstream to fix this mess (not likely to happen as upstream 
>> seems unresponsive)
>>
>> 2. revert the changes that caused the issue; the last successful salsa CI 
>> pipeline I can find is this one:
>> https://salsa.debian.org/js-team/node-yarnpkg/-/commit/877478d5ef3f8a7564cdea211e5cd794fdfb97b5
>> so just revert all changes to this repo and the build deps to this status
>>
>> I urge those who caused the mess fix it.
> 
> Hi Paolo,
> 
> We discussed about plan to remove babel 6 from bullseye from the very 
> beginning as upstream won't be supporting it for the life time of bullseye. 
> You can look at the list archive for those mails. I think it is only normal 
> to move to new upstream versions of libraries. We also sent list of affected 
> packages frequently to the list. No one suggested to keep babel 6 in testing 
> at that time. You had a chance to request keeping babel 6 before it was 
> removed as well. Marking for autoremoval was also a warning (node-yarnpkg was 
> also marked for auto removal when I filed rc bug against node-babel), you 
> could have requested keeping babel 6 for longer, though eventually it has to 
> be removed from bullseye if no one steps up to maintain it.
> 
> If someone wants to keep babel 6, they have to step in and take up 
> maintenance. Or you could even embed babel 6 in yarnpkg as it is the only 
> package currently in the archive that does not work without babel 7. 
> Introducing babel 6 back in testing means supporting babel 6 and 7 for the 
> life time of bullseye. Are you prepared to do that? If someone volunteers to 
> maintain babel 6 in bullseye, we can still introduce it back, though my 
> preference would be to fix yarnpkg or wait for yarnpkg 2 (which supports 
> babel 7 already), even if it means missing bullseye and getting it in 
> bullseye-backports.
> 
> This is nothing specific to yarnpkg here, that is how every library 
> transition works. For example in ruby team, we moved to rails 6 and the 
> packages that did not support rails 6 were removed from testing (applications 
> like redmine, open-build-system and diaspora were not compatible with rails 
> 6). We cannot expect old versions of libraries will be supported forever in 
> debian.
> 
> Thanks
> Praveen

Probably we don't need babel.

I made a test in the clean upstream source tree, with a bin/yarn.mjs binary 
tweaked to load the source from ../src rather than the transpiled & bundled 
stuff from ../lib:

#!/usr/bin/env node
import * as cli from '../src/cli/index.mjs';
cli.default().catch(function(error) {
  console.error(error.stack || error.message || error);
  process.exitCode = 1;
});

For my test, I manually removed all type annotations from src/cli/index.js and 
saved it to src/cli/index.mjs

I can run this both in nodejs 12 (there is the "ExperimentalWarning: The ESM 
module loader is experimental.") and node 14 from experimental (no warning).
It parses that first file OK, but does not find the modules in 
/usr/share/nodejs/:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'commander' imported from 
/root/yarn/src/cli/index.mjs

This and the similar errors can be addressed like this:

7c7
< import commander from 'commander';
---
> import commander from '/usr/share/nodejs/commander/index.js';

Of course we need an automated tool to strip the type annotations and fix the 
module lookups.

The typescript transform from this babel replacement should do the first job:
https://github.com/alangpierce/sucrase
And probably webpack can do the second.

In any case I attach the patched src/cli/index.mjs file.

What do you think, is this a viable route, or do we have an alternative ?

Paolo


index.mjs.txt.gz
Description: application/gzip
-- 
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 bring yarnpkg back to testing

[Paolo Greppi]

Il 14/09/20 17:55, Xavier ha scritto:
> Le 14/09/2020 à 17:12, Paolo Greppi a écrit :
>> #960120 is keeping yarnpkg out of testing; there are two ways to resolve 
>> this:
>>
>> 1. work with upstream to fix this mess (not likely to happen as upstream 
>> seems unresponsive)
>>
>> 2. revert the changes that caused the issue; the last successful salsa CI 
>> pipeline I can find is this one:
>> https://salsa.debian.org/js-team/node-yarnpkg/-/commit/877478d5ef3f8a7564cdea211e5cd794fdfb97b5
>> so just revert all changes to this repo and the build deps to this status
> 
> This commit is the last published version, so rolling back will not fix
> anything.
> 

"and the build deps"

P.

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

[Pkg-javascript-devel] please bring yarnpkg back to testing

[Paolo Greppi]

#960120 is keeping yarnpkg out of testing; there are two ways to resolve this:

1. work with upstream to fix this mess (not likely to happen as upstream seems 
unresponsive)

2. revert the changes that caused the issue; the last successful salsa CI 
pipeline I can find is this one:
https://salsa.debian.org/js-team/node-yarnpkg/-/commit/877478d5ef3f8a7564cdea211e5cd794fdfb97b5
so just revert all changes to this repo and the build deps to this status

I urge those who caused the mess fix it.

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

Re: [Pkg-javascript-devel] How to switch to DEP14 automatically for > 1000 existing repositories

[Paolo Greppi]

Hi Andreas,

Il 11/09/20 12:16, Andreas Tille ha scritto:
> Hi,
> 
> in teams where I have lots of packages (summing up to more than 1000)
> I've touched) we followed the gbp default and have branches
> 
> master
> upstream
> pristine-tar
> 
> and this is also the layout fixed in those team policies.  I admit I
> don't have strong feelings about branch names but I'm willing to
> normalize to some common standard which seems to be the now accepted
> DEP14.  However, its not acceptable to change this manually.  As far as
> to my experience it is hard to rename a default branch - at least I did
> this in those rare cases when I had to rename a default branch by using
> the Salsa web interface.
> 
> My guess is that the Salsa API provides means to script everything.  Is
> there any existing script that supports this or is there any volunteer
> to write it.  I would start migrating Debian Med, Debian Science and
> R packaging team repositories once gbp also switched to DEP14.
> 
> Kind regards
> 
>Andreas.

I would use a Python library as client to the Gitlab API on salsa.
We have this one already packaged in Debian:
https://tracker.debian.org/pkg/python-gitlab

Disclaimer: I have already used this library for a different purpose:
https://salsa.debian.org/paolog/bts2salsa

I am interested in working on this for the JavaScript team,
but of course only if the team agrees to this bulk change.

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#960120: node-yarnpkg: I found an older commit that still builds

[Paolo Greppi]

Il 15/08/20 14:00, Pirate Praveen ha scritto:
>> With this build:
>> https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/915568#L2420
> 
>> I get a different error while building:
>> [17:58:12] Starting 'build'...
>> 2420[17:58:13] Error: [BABEL] 
>> /builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.22.4/src/api.js: 
>> Cannot find module
>> 'babel-plugin-transform-strict-mode'
> 
>> ?
> 
> With sbuild, I can reproduce the error. But on a sid schroot, 
> dpkg-buildpackage works. May be I have some things locally installed.
> 
> If you go back to commit 3f1ab4d62789670ee39648eb35078ce244ba2d09 it is 
> building fine. We need to analyze the commits that came after this I think.

The autopkgtest failure you mention in your message to the BTS of May 17th is a 
side effect.
The root cause is that the webpack build itself is broken, but the error 
message ("Unhandled rejection TypeError: fileDependencies.map is not a 
function") is not really helpful.
(I had pointed that out here already: https://bugs.debian.org/958780#39)

I have rebased my last commit (that patches scripts/build-webpack.js so that it 
prints the actual errors) on top of 3f1ab4d6, in the wip/paolog/babel7 branch.
In the log a bunch of new ERRORS appear:

ERROR in ./src/errors.js
Module not found: Error: Can't resolve 
'@babel/runtime/helpers/assertThisInitialized' in 
'/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.22.4/src'
@ ./src/errors.js 12:53-108
@ ./src/cli/index.js
...
ERROR in ./src/config.js
Module not found: Error: Can't resolve 
'@babel/runtime/helpers/asyncToGenerator' in 
'/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.22.4/src'
@ ./src/config.js 17:48-98
@ ./src/cli/index.js
...
ERROR in ./src/errors.js
Module not found: Error: Can't resolve 
'@babel/runtime/helpers/classCallCheck' in 
'/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.22.4/src'
@ ./src/errors.js 10:46-94
@ ./src/cli/index.js
...

for the full list see the salsa CI run: 
https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/937269#L2529

I think we've been too eager to upgrade to babel 7, while upstream does not 
really care (see https://github.com/yarnpkg/yarn/issues/8083)
Also our patches should be easy to forward.

Unfortunately I am not able to help with troubleshooting this babel.

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#960120: different error during build

[Paolo Greppi]

With this build:
https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/915568#L2420

I get a different error while building:
[17:58:12] Starting 'build'...
2420[17:58:13] Error: [BABEL] 
/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.22.4/src/api.js: 
Cannot find module 'babel-plugin-transform-strict-mode'

?

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#964218: Bug#964218: node-yarnpkg: autopkgtest fails with node-uuid 8.2 from experimental - "Cannot read property 'v4' of undefined"

[Paolo Greppi]

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 ?

Paolo

Il 03/07/20 21:03, Pirate Praveen ha scritto:
> 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.

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

Re: [Pkg-javascript-devel] Bug#961337: ITP: A secure runtime for JavaScript and TypeScript.

[Paolo Greppi]

Il 29/06/20 21:27, Akshat Agarwal ha scritto:
> Package: wnpp
> Followup-For: Bug #961337
> Owner: Akshat Agarwal 
> 
> 
> * Package name: deno
>   Version : 1.1.2
>   Upstream Author : Deno authors
> * URL : https://github.com/denoland/deno
> * License : MIT
>   Programming Lang: Rust, TypeScript, JavaScript
>   Description : A secure runtime for JavaScript and TypeScript.
> 
> I intend to package Deno and maintain it. If anybody is willing to can 
> co-maintain with me.
> 
> Thanks,
> Akshat Agarwal (humancalico)

Hi Akshat,

many thanks for your interest in contributing to Debian. 
would you like to maintain deno within the js-team ?
We already maintain nodejs ...

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#940511: Bug#940511: yarnpkg: Package symlink yarn -> yarnpkg

[Paolo Greppi]

See below ...

On Wed, 20 May 2020 18:08:29 +0200 =?UTF-8?Q?Ma=C3=ABl_Nison?= 
 wrote:
> Hi, I'm Maël, Yarn's lead maintainer.
> 
> While cmdtest has a popcon score higher than the yarn package, it's mostly
> because Yarn isn't traditionally installed using the Debian package. For
> historical reasons the 1.x branch always updated it, but in general our
> users install Yarn using it's "competitor", npm. The npm numbers give a
> very different picture: Yarn is downloaded 6.1m times per month.
> 
> There are currently talks to, potentially, ship symlinks for the three main
> package managers along with Node (npm, which is already there, along with
> Yarn and maybe pnpm). These plans aren't concrete yet, but a few people
> think it's worth studying. In any case, the decision is expected to be
> taken for Node 15, which will happen this year. To the extent possible, I
> think it could be wise (and very appreciated!) to consider renaming the
> `yarn` binary from `cmdtest` before it risks becoming an actual problem.
> 
> As a last note, I pinged Lars Wirzenius (who I think was the original
> cmdtest maintainer?), back in March '19. He mentioned having recently
> retired, but seemed fairly supportive of the idea ("I've now discussed the
> name of our testing tool with its other developer and we will likely change
> the name of our program during the Debian buster+1 development cycle").
> 
> Maël

Hi Maël,

thanks for the feedback and for your Debian contribution.

I've added here the info on the bug that has to be addressed by the cmdtest
maintainer (if he agrees) for us to be able to fix this one.

I'll also ping him.

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#940704: first try with node-jest 24.9.0

[Paolo Greppi]

With node-jest now in the NEW queue, I have started working on this here:

  https://salsa.debian.org/js-team/node-yarnpkg/-/tree/jest

I have built jest from https://salsa.debian.org/js-team/node-jest assuming 
commit b9255f45c22c030b863e7d42aaf78c207db43478 will be tagged as 24.9.0+ds-2 
(although that is not in NEW queue):

  git checkout b9255f45c22c030b863e7d42aaf78c207db43478
  git switch -c debian/24.9.0+ds-2
  gbp buildpackage -uc -us --git-ignore-branch

I need to side-load these packages to /usr/share/nodejs to make jest start:

  import-local realpath-native jest-snapshot-serializer-raw sane react-is 
natural-compare p-each-series throat

Now the test suite starts, and all 91 tests fail. I need to also side-load:

  string-length fast-json-stable-stringify source-map-support

not sure if these are jest run-time dependencies or yarnpkg test-time 
dependencies.

Now all the tests fail because:

  Cannot find module 'source-map-support' from 'source-map-support.js'

To fix this, I upgrade source-map-support to 0.5.19; now I get:

  Cannot find module 'chalk' from 'Env.js'

this comes from /usr/share/nodejs/jest-jasmine2/build/jasmine/Env.js which is 
compiled from node-jest/packages/jest-jasmine2/src/jasmine/Env.ts.
But node-chalk is installed:

  nodejs
  > chalk = require('chalk');
  { [Chalk]
constructor: [Function: Chalk],
supportsColor: { level: 2, hasBasic: true, has256: true, has16m: false },
default: [Circular] }
  > ^d

Clearly the jest command is broken.
I suggest to enable the jest self-test suite in node-jest.

I tried running "jest" in node-jest source tree (after side-loading the 8 
packages above), I get:

● Validation Error:

  Test environment ./packages/jest-environment-node cannot be found. Make sure 
the testEnvironment configuration option points to an existing node module.

  Configuration Documentation:
  https://jestjs.io/docs/configuration.html

Although ./packages/jest-environment-node exists (?)

I tried to specify the testEnvironment from the command line:

  jest --env=node

and with that I get:

● Validation Error:

  Module /packages/pretty-format/build/plugins/ConvertAnsi.js in the 
snapshotSerializers option was not found.
  is: /root/node-jest

  Configuration Documentation:
  https://jestjs.io/docs/configuration.html

Also note that the command:

  jest --init

requires side-loading prompts module.

For my own record, I reset all the changes to my test machine with:

  apt remove jest
  apt autoremove
  cd /usr/share/nodejs
  rm import-local realpath-native jest-snapshot-serializer-raw sane react-is 
natural-compare p-each-series throat string-length fast-json-stable-stringify 
source-map-support prompts
  mv source-map-support.old/ source-map-support

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#958780: Bug#958780: do we really want to do this ?

[Paolo Greppi]

see below ...

Il 30/04/20 18:10, Pirate Praveen ha scritto:
> ...
> I have pushed my changes to babel7 branch and the error I get is,
> 
> gulp build
> [15:53:07] Local gulp not found in /<>
> [15:53:07] Try running: npm install gulp
> [15:53:07] Using globally installed gulp
> [15:53:07] Using gulpfile /<>/gulpfile.js
> [15:53:07] Starting 'build'...
> [15:53:13] Finished 'build' after 6.18 s
> node ./scripts/build-webpack.js
> Unhandled rejection TypeError: fileDependencies.map is not a function
>    at compiler.run (/<>/scripts/build-webpack.js:118:38)
> ...

If you get that, it means webpack failed.
The confusing error is because the stats data structure of our webpack (4.30.0) 
is not compatible with the webpack they expect (2.7.0).

To actually see the errors, tweak the compiler.run callback like this:

compiler.run((err, stats) => {
  var stringify = require('json-stringify-safe');
  console.log(stringify(stats, null, 2));
});

I attach the JSON it prints. Sample extract:

"error": {
  "origin": null,
  "dependencies": null,
  "module": "[Circular ~.compilation.entries.0]",
  "name": "ModuleBuildError",
  "error": {
"code": "BABEL_VERSION_UNSUPPORTED",
"version": "6.26.0",
"range": "^7.0.0-0"
  }
}

Paolo


stats.json.xz
Description: application/xz
-- 
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#958780: do we really want to do this ?

[Paolo Greppi]

My understanding is that node-gulp-babel v8 should be used with babel7.
Same goes for node-babel-loader, you need v8 for babel7, but we only have 
node-babel-loader 7 in Debian.

If we want babel6 to co-exist with babel7, then we don't want to just update 
node-gulp-babel and node-babel-loader to v8.
We want to keep node-gulp-babel and node-babel-loader at v7 for compatibility 
with babel6, and upload new node-gulp-babel8 and node-babel-loader8 for babel7.

Back to the topic of this bug, do we really want to upgrade the yarn build 
system from babel6 to babel7 ?
Here is some indication that upstream is not interested: 
https://github.com/yarnpkg/yarn/pull/6322
But I have raised the issue anyway: https://github.com/yarnpkg/yarn/issues/8083

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#958780: take ownership

[Paolo Greppi]

owner 958780 Paolo Greppi 

-- 
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] theia

[Paolo Greppi]

Hi all,

I was intrigued by the recent announcement of an alternative to vscode:
https://theia-ide.org/
(the ITP for the latter is stuck: https://bugs.debian.org/898259)

But also to package theia you'd need electron.

To get out of this stalemate, I prototyped a wrapper based on a Qt WebEngine 
webview:
https://gitlab.com/simevo/theia-app

It kind of works, with some nuisances.
The compiled executable is 30k + 800MB of JavaScript dependencies (but 350MB 
are from puppeteer that should be easy to exclude).

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#927254: closed by Xavier Guimard (Bug#927254: fixed in vue-router.js 3.0.7+ds-1)

[Paolo Greppi]

The previous solution was not working anymore, and in the meantime upstream 
updated to v3.1.6:
https://github.com/vuejs/vue-router/releases

I have updated it, and changed again the approach.
There is no build error anymore, but I can't guarantee that the UMD build will 
work in the browser because I have no time to test it (for example in laminar 
UI).

meskio, can you test laminar with the new build ? Thanks

Paolo

Il 24/03/20 17:38, meskio ha scritto:
> Hello Paolo,
> 
> Quoting Paolo Greppi (2019-10-31 18:39:16)
>> Hi Dmitry, I have fixed the dangling symlink in libjs-vue-route.
>>
>> It now builds locally and on Salsa CI (I enabled it for master branch as 
>> well):
>> https://salsa.debian.org/js-team/vue-router.js/-/jobs/393462
>>
>> I then rebuilt laminar from the current version at 
>> https://salsa.debian.org/debian/laminar against this unreleased 
>> libjs-vue-route 3.0.7+ds-3 version.
>> After issuing:
>>   systemctl start laminar.service
>> and checking that:
>>   systemctl status laminar.service
>> returns success,
>> the laminar service dashboard can be reached from localhost:8080 and causes 
>> no JavaScript error.
> 
> Is there anything still blocking this fix from being uploaded to unstable? 
> Can I 
> do something to help here?
> 
> Thank you for fixing the problem.

-- 
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#952656: related upstream bug + behavior of upstream-provided package

[Paolo Greppi]

see: https://github.com/yarnpkg/yarn/issues/1390

upstream-provided package correctly reports the error:

docker run --rm -it debian:buster-slim /bin/bash

apt update && apt install -y curl gnupg2
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee 
/etc/apt/sources.list.d/yarn.list
apt update && apt install -y yarn
apt remove ca-certificates
cat > package.json
{
  "dependencies": {
"highlight.js": "^9.18.1"
  }
}
^d
cat > yarn.lock
highlight.js@^9.18.1:
  version "9.18.1"
  resolved 
"https://registry.yarnpkg.com/highlight.js/-/highlight.js-9.18.1.tgz#ed21aa001fe6252bb10a3d76d47573c6539fe13c;
  integrity 
sha512-OrVKYz70LHsnCgmbXctv/bfuvntIKDz177h0Co37DQ5jamGZLVmoCVMtjMtNZY3X9DrCcKfklHPNeA0uPZhSJg==
^d
yarn install --verbose
yarn install v1.22.0
warning package.json: No license field
verbose 0.77 Checking for configuration file "/.npmrc".
verbose 0.77 Checking for configuration file "/usr/local/share/.npmrc".
verbose 0.771 Checking for configuration file "/usr/etc/npmrc".
verbose 0.771 Checking for configuration file "/root/.npmrc".
verbose 0.771 Checking for configuration file "/.npmrc".
verbose 0.772 Checking for configuration file "/.yarnrc".
verbose 0.772 Checking for configuration file "/usr/local/share/.yarnrc".
verbose 0.773 Checking for configuration file "/usr/etc/yarnrc".
verbose 0.773 Checking for configuration file "/root/.yarnrc".
verbose 0.773 Checking for configuration file "/.yarnrc".
verbose 0.777 current time: 2020-02-27T08:00:59.988Z
verbose 0.813 Performing "GET" request to "https://yarnpkg.com/latest-version;.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 0.877 Performing "GET" request to 
"https://registry.yarnpkg.com/highlight.js/-/highlight.js-9.18.1.tgz;.
verbose 0.968 Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (_tls_wrap.js:1055:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8)
error An unexpected error occurred: 
"https://registry.yarnpkg.com/highlight.js/-/highlight.js-9.18.1.tgz: unable to 
get local issuer certificate".
info If you think this is a bug, please open a bug report with the information 
provided in "/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this 
command.

so there is something wrong with our package

P.

-- 
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#952656: how to reproduce in docker

[Paolo Greppi]

1. hanging:

docker run --rm -it debian:buster-slim /bin/bash
apt update 
apt install -y --no-install-recommends yarnpkg
yarnpkg add --verbose highlight.js

output:

yarn add v1.13.0
verbose 0.668 Checking for configuration file "/.npmrc".
verbose 0.668 Checking for configuration file "/usr/local/share/.npmrc".
verbose 0.669 Checking for configuration file "/usr/etc/npmrc".
verbose 0.669 Checking for configuration file "/root/.npmrc".
verbose 0.669 Checking for configuration file "/.npmrc".
verbose 0.67 Checking for configuration file "/.yarnrc".
verbose 0.67 Checking for configuration file "/usr/local/share/.yarnrc".
verbose 0.671 Checking for configuration file "/usr/etc/yarnrc".
verbose 0.671 Checking for configuration file "/root/.yarnrc".
verbose 0.671 Checking for configuration file "/.yarnrc".
verbose 0.675 current time: 2020-02-27T07:30:32.620Z
info No lockfile found.
verbose 0.805 Performing "GET" request to "https://yarnpkg.com/latest-version;.
[1/4] Resolving packages...
verbose 1.088 Performing "GET" request to 
"https://registry.yarnpkg.com/highlight.js;.
⠂ highlight.js

[hangs]

2. crashing:

docker run --rm -it debian:buster-slim /bin/bash
apt update 
apt install -y --no-install-recommends yarnpkg
cat > package.json
{
  "dependencies": {
"highlight.js": "^9.18.1"
  }
}
^d
cat > yarn.lock
highlight.js@^9.18.1:
  version "9.18.1"
  resolved 
"https://registry.yarnpkg.com/highlight.js/-/highlight.js-9.18.1.tgz#ed21aa001fe6252bb10a3d76d47573c6539fe13c;
  integrity 
sha512-OrVKYz70LHsnCgmbXctv/bfuvntIKDz177h0Co37DQ5jamGZLVmoCVMtjMtNZY3X9DrCcKfklHPNeA0uPZhSJg==
^d
yarnpkg install --verbose

output:

yarn install v1.13.0
warning package.json: No license field
verbose 0.616 Checking for configuration file "/.npmrc".
verbose 0.617 Checking for configuration file "/usr/local/share/.npmrc".
verbose 0.617 Checking for configuration file "/usr/etc/npmrc".
verbose 0.617 Checking for configuration file "/root/.npmrc".
verbose 0.618 Checking for configuration file "/.npmrc".
verbose 0.618 Checking for configuration file "/.yarnrc".
verbose 0.619 Checking for configuration file "/usr/local/share/.yarnrc".
verbose 0.619 Checking for configuration file "/usr/etc/yarnrc".
verbose 0.619 Checking for configuration file "/root/.yarnrc".
verbose 0.619 Checking for configuration file "/.yarnrc".
verbose 0.624 current time: 2020-02-27T07:40:15.667Z
verbose 0.723 Performing "GET" request to "https://yarnpkg.com/latest-version;.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 0.997 Performing "GET" request to 
"https://registry.yarnpkg.com/highlight.js/-/highlight.js-9.18.1.tgz;.

also, the error is not reported: echo $? returns: 0

P.

-- 
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#952656: yarnpkg: should depend on ca-certificates

[Paolo Greppi]

Package: yarnpkg
Version: 1.21.1-1
Severity: normal

if ca-certificates is not installed, yarnpkg will hang or quit abruptly without
any error message / error status.

To reproduce:
sudo apt install yarnpkg
sudo apt remove ca-certificates
cd $(mktemp -d)
cat > package.json
{
  "dependencies": {
"highlight.js": "^9.17.1",
"reveal.js": "^3.8.0"
  }
}
^d
yarnpkg install --verbose
[crash]

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages yarnpkg depends on:
ii  node-asap  2.0.6-1
ii  node-babel-runtime 6.26.0+dfsg-3
ii  node-bytes 3.0.0-1
ii  node-camelcase 5.0.0-1
ii  node-chalk 2.3.0-2
ii  node-chownr1.1.1-1
ii  node-ci-info   1.1.2-1
ii  node-cli-table 0.3.1-1
ii  node-commander 2.12.2-3
ii  node-death 1.0.0-1
ii  node-debug 3.1.0-2
ii  node-deep-equal1.0.1-1
ii  node-detect-indent 5.0.0-1
ii  node-duplexify 3.6.1-1
ii  node-emoji 1.8.1-1
ii  node-fast-levenshtein  2.0.5-1
ii  node-glob  7.1.3-2
ii  node-imports-loader0.7.1-1
ii  node-ini   1.3.5-1
ii  node-inquirer  3.3.0-2
ii  node-invariant 2.2.2-1
ii  node-is-builtin-module 2.0.0-1
ii  node-js-yaml   3.13.1+dfsg-2~bpo10+1
ii  node-loud-rejection1.6.0-1
ii  node-micromatch2.3.11-1
ii  node-minimatch 3.0.4-3
ii  node-mkdirp0.5.1-1
ii  node-node-uuid 3.3.2-2
ii  node-object-path   0.11.4-2
ii  node-path-root 0.1.1-1
ii  node-proper-lockfile   2.0.1-1
ii  node-puka  1.0.0+dfsg-1
ii  node-pump  3.0.0-1
ii  node-pumpify   1.5.1-1
ii  node-read  1.0.7-1
ii  node-request   2.88.1-2
ii  node-request-capture-har   1.2.2-1
ii  node-resolve   1.5.0-1
ii  node-rimraf2.6.2-1
ii  node-semver5.5.1-1
ii  node-ssri  5.2.4-2
ii  node-strict-uri-encode 2.0.0-1
ii  node-strip-ansi4.0.0-1
ii  node-strip-bom 3.0.0-1
ii  node-tar-stream1.5.2-1
ii  node-validate-npm-package-license  3.0.1-1
ii  node-yn3.0.0-1
ii  nodejs 10.15.2~dfsg-2

yarnpkg recommends no packages.

yarnpkg suggests no packages.

-- no debconf information

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

Re: [Pkg-javascript-devel] nodejs-12 transition

[Paolo Greppi]

Il 16/01/20 20:35, Pirate Praveen ha scritto:
> 
> 
> On വ്യാ, Jan 16, 2020 at 13:27, Nilesh Patra  wrote:
>> Hi,
>> I had been lately seeing discussions in the list regarding requiring 
>> transition for nodejs-12 to unstable. I tested all the reverse depends and 
>> this is the list of all failing reverse-depends[1] and the repository[2] 
>> contains all the individual logs(for all reverse-depends) for convenience.
>> Also rebuilt the reverse-build-depends and this[3] is the list of depends 
>> that fail and the individual logs are in the same repository[4]
>>
>> [1]; 
>> https://git.fosscommunity.in/gi-boi/nodejs_autopkgtest_results/blob/master/rdeps
>> [2]: https://git.fosscommunity.in/gi-boi/nodejs_autopkgtest_results/
>> [3]: 
>> https://git.fosscommunity.in/gi-boi/nodejs_rebuild_results/blob/master/rebuild_deps
>> [4]: https://git.fosscommunity.in/gi-boi/nodejs_rebuild_results/
>>
> 
> Thanks a lot Nilesh for doing it. This is really helpful.
> Some the failures may be unrelated to nodejs 12 change, for example  
> https://tracker.debian.org/pkg/node-dagre-layout this is already failing (I 
> think thanks to /usr/lib to /usr/share migration). Similarly for autopkgtest. 
> So among the packages that failed, we need to find out which of them are 
> already failing (we can get this information from tracker.debian.org).
> 
>> Thanks and Regards
>> Nilesh

Hi Nilesh and thanks for the good work.

For nodejs_autopkgtest_results, of the 1288 logs only 74 contain the string 
'FAIL non-zero exit status' (see attached nodejs_autopkgtest_results-failed).
I propose to mass-file bugs against each of them for easier tracking.

For nodejs_rebuild_results, of the 1168 logs only the 62 in the rebdeps file 
actually failed.
Some may be false positives as suggested by Praveen; had you used ratt [1] you 
could have told it to retry the failing builds without the new package (in this 
case nodejs 12), this would exclude most of those that are already failing.
Who feels like doing it manually now for the 62 failing builds ?

Paolo

[1] https://github.com/Debian/ratt
acorn.log
babel-minify.log
html2canvas.log
node-babel-plugin-transform-define.log
node-body-parser.log
node-cacache.log
node-chokidar.log
node-copy-webpack-plugin.log
node-diffie-hellman.log
node-diff.log
node-ebnf-parser.log
node-eslint-plugin-flowtype.log
node-eslint-plugin-html.log
node-expat.log
node-express.log
node-extend-shallow.log
node-grunt-babel.log
node-grunt-contrib-nodeunit.log
node-grunt-legacy-util.log
node-grunt-webpack.log
node-iconv-lite.log
node-iconv.log
node-immutable-tuple.log
node-jquery-textcomplete.log
node-jquery.waitforimages.log
node-klaw.log
node-leaflet-formbuilder.log
node-leaflet-hash.log
node-leveldown.log
node-levn.log
node-libnpx.log
node-lockfile.log
node-mapnik.log
node-millstone.log
node-multiparty.log
node-nodedbi.log
node-node-localstorage.log
node-node-sass.log
node-npm-bundled.log
node-npmrc.log
node-optionator.log
node-pako.log
node-rai.log
node-raw-body.log
node-re2.log
node-request-promise.log
node-serve-index.log
node-shell-quote.log
node-shiny-server-client.log
node-simplesmtp.log
node-sinon-chai.log
node-source-map-support.log
node-sqlite3.log
node-srs.log
node-sshpk.log
node-stack-utils.log
node-stream-splicer.log
node-string-decoder.log
node-stringprep.log
node-superagent.log
node-supertest.log
node-tap.log
node-telegram-bot-api.log
node-tmp.log
node-to-fast-properties.log
node-type-check.log
node-uniq.log
node-unique-filename.log
node-vinyl-fs.log
node-vue-template-compiler.log
node-websocket.log
node-xmpp.log
node-xoauth2.log
node-zipfile.log
-- 
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] gulp 4 migration

[Paolo Greppi]

Il 14/01/20 20:43, Pirate Praveen ha scritto:
  I was able to build from experimental branch and got this error. This 
 is probably a bug in gulp itself.
> ...
> node-get-value should be in Depends for gulp I think.
> 

I got meta/build to build it too (see below) with the same error.
For that I filed a bug against gulp: https://bugs.debian.org/948994

>> See if 
>> https://salsa.debian.org/ruby-team/meta/blob/master/build-and-upload#L315 is 
>> finding the correct file.
> 
> Strangely, it works if I set $PATH to the repo and call `build` but does not 
> if I give direct path to the script like `../../ruby-team/meta/build`.

Yes, meta/build works if I launch the build executable with full path:

/root/meta/build

or as you did setting the PATH:

export PATH=/root/meta:$PATH
build

in both cases, the SBUILD_CONFIG contains the full path:
SBUILD_CONFIG = /root/meta/sbuild_experimental.conf

if I launch it with a relative path:

../../meta/build

the SBUILD_CONFIG also has the relative path:
SBUILD_CONFIG = ../../meta/sbuild_experimental.conf

and it somehow fails to add the experimental repo.

I propose to amend the meta/build-and-setup script to use realpath before 
dirname as in this MR:
https://salsa.debian.org/ruby-team/meta/merge_requests/8

Finally there is no way to create issues in the 
https://salsa.debian.org/ruby-team/meta repo, what is the preferred way to 
provide feedback ?
For example shellcheck returns a great number of warnings on that script, I 
suggest fixing them.

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#948994: gulp should Depend on node-get-value

[Paolo Greppi]

Package: gulp
Version: 4.0.2-4
Severity: normal

Dear Maintainer,

while building yarnpkg on experimental, it fails while executing the gulp 
command:

...
gulp build
[18:34:23] Local gulp not found in 
/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.21.1
[18:34:23] Try running: npm install gulp
[18:34:23] Using globally installed gulp
internal/modules/cjs/loader.js:638
throw err;
^
Error: Cannot find module 'get-value'
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/gulp/node_modules/array-sort/index.js:12:11)
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)

as can be seen in this salsa CI run:
https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/511658

get-value is required by array-sort which is a dependency of gulp-cli 2:
https://github.com/gulpjs/gulp-cli/blob/master/package.json#L36

BTW a few weeks ago it had worked gulp 4.0.2-4 from experimental:
https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/470197

It could be that the culprit is one of the gulp dependencies ...

Paolo

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

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

Versions of packages gulp depends on:
ii  node-archy   1.0.0-3
ii  node-chalk   2.4.2-1
ii  node-chokidar2.1.6-3
ii  node-concat-stream   1.6.2-1
ii  node-defaults1.0.3-1
ii  node-deprecated  0.0.1-1
ii  node-es6-weak-map2.0.2-1
ii  node-find-up 4.1.0-2
ii  node-for-own 1.0.0-1
ii  node-globule 1.3.0-1
ii  node-gulp-util   3.0.7-1
ii  node-interpret   1.0.1-1
ii  node-is-unc-path 1.0.0-1
ii  node-liftoff 3.1.0-4
ii  node-minimist1.2.0-1
ii  node-normalize-package-data  2.4.0-1
ii  node-orchestrator0.3.8-1
ii  node-parse-json  5.0.0-2
ii  node-pinkie-promise  2.0.1-1
ii  node-pretty-hrtime   1.0.3-1
ii  node-semver  7.1.1-2
ii  node-set-blocking2.0.0-1
ii  node-string-width2.1.1-1
ii  node-tildify 2.0.0-1
ii  node-v8flags 3.1.2-3
ii  node-vinyl-fs3.0.3-3
ii  node-y18n4.0.0-2
ii  node-yargs-parser16.1.0-1
ii  nodejs   10.17.0~dfsg-2

gulp recommends no packages.

gulp suggests no packages.

-- no debconf information

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

Re: [Pkg-javascript-devel] gulp 4 migration

[Paolo Greppi]

Il 14/01/20 18:59, Pirate Praveen ha scritto:
> ...
> Forgot to attach the log I guess, also pristine-tar branch is missing the 
> latest version.

OK attached

Nope pristine-tar has node-yarnpkg_1.2.1.orig*:
https://salsa.debian.org/js-team/node-yarnpkg/tree/pristine-tar

> I was able to build from experimental branch and got this error. This is 
> probably a bug in gulp itself.

experimental branch differs from master only for debian/gbp.conf and 
debian/gitlab-ci.yml (besides the recent commits from Xavier)

> gulp build
> [17:56:05] Local gulp not found in /<>
> [17:56:05] Try running: npm install gulp
> [17:56:05] Using globally installed gulp
> internal/modules/cjs/loader.js:638
>    throw err;
>    ^
> 
> Error: Cannot find module 'get-value'
>    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/gulp/node_modules/array-sort/index.js:12:11)
>    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)
> make[1]: *** [debian/rules:26: override_dh_auto_build] Error 1
> make[1]: Leaving directory '/<>'

weird ! it built 3 weeks ago on salsa CI using gulp 4.0.2-4 (experimental):
https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/470197

get-value is required by array-sort which is a dependency of gulp-cli 2:
https://github.com/gulpjs/gulp-cli/blob/master/package.json#L36

Not sure of what is going on 

Paolo


node-yarnpkg_1.21.1-2~exp1_amd64.build.xz
Description: application/xz
-- 
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] gulp 4 migration

[Paolo Greppi]

Il 13/01/20 10:04, Pirate Praveen ha scritto:
>> ...
>> What is the best oneliner to test a package targeting unstable with a mix of 
>> selected packages from experimental ?
>>
>> Preferably using https://salsa.debian.org/ruby-team/meta ...
>> And what about telling salsa CI to do so for us ?
>>
> meta script mentioned above now takes packages from experimental if build 
> depends is satisfied only with versions from experimental. So with a properly 
> specified build depends, just calling build script is enough for rebuilding 
> reverse build dependencies (though that does not yet work for autopkgtest, I 
> want to do that some time soon, if someone wants to try that before me that 
> would be good too).

I have see the recent commits to meta, and pulled them.

But when I try to rebuild node-yarnpkg 1.21.1-2~exp1 which has in d/control:

Build-Depends:
...
 , gulp (>= 4)
...
 , node-vinyl-fs (>= 3)
...

it fails as per attached log. I tried installing those locally and I know it 
can build fine !

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

Re: [Pkg-javascript-devel] gulp 4 migration

[Paolo Greppi]

Il 13/01/20 07:10, Pirate Praveen ha scritto:
> ...
> Nopes. FTBFS is rc and people do periodic archive wide rebuilds and this can 
> get packages removed from testing. I prefer we fix at least important 
> packages before pushing gulp 4 to unstable.
> 
> gulp package is not an end in itself, but the whole reason gulp was packaged 
> was to build these packages as its unlikely any end user will want to use 
> packaged gulp.
> 
> For packages that is likely to be used directly by users, your approach is OK.

Thanks Pravi, I agree.

What is the best oneliner to test a package targeting unstable with a mix of 
selected packages from experimental ?

Preferably using https://salsa.debian.org/ruby-team/meta ...
And what about telling salsa CI to do so for us ?

?

-- 
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#947760: Bug#947760: Bug#947760: why ?

[Paolo Greppi]

Il 30/12/19 11:36, Xavier ha scritto:
> ...
> I think that npm is needed when a package has to be build locally.
> That's why a "recommends" should be enough
> 

Xavier, I have enabled salsa CI on node-es6-iterator repo and fixed it to run 
tests with yarnpkg so that the dependency on npm can be dropped from 
debian/tests/control

See this run:
https://salsa.debian.org/js-team/node-es6-iterator/-/jobs/483337

If you think this fixes the issue, please go ahead and close this bug.

Paolo

P.S. Regarding node-es6-iterator autopkgtest, after "node 
./node_modules/tad/bin/tad" it prints "No tests run".
This is the same as before when tests were run with "npm run test":
https://salsa.debian.org/js-team/node-es6-iterator/-/jobs/483318
But it does not seem right !
If I run the tests in the source tree with "yarnpkg install && yarnpkg test" 
this is what i see:

yarn run v1.21.1
$ node ./node_modules/tad/bin/tad
15:56:30.392  ✓  #/chain.js ...
15:56:30.397  ✓  array.js ...
15:56:30.404  ✓  for-of.js ...
15:56:30.409  ✓  get.js ...
15:56:30.411  ✓  index.js ..
15:56:30.415  ✓  is-iterable.js .
15:56:30.417  ✓  string.js 
15:56:30.419  ✓  valid-iterable.js ..

.037 141 Ok [100.00%]

Done in 0.83s.

-- 
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#947760: why ?

[Paolo Greppi]

Hi Xavier, I did this on sid:

sudo apt install yarnpkg
sudo apt remove npm
sudo apt autoremove
git clone https://github.com/yarnpkg/yarn
cd yarn
rm -rf node_modules
yarnpkg 

This works fine and installs all of yarnpkg dependencies in node_modules dir. 

Can you provide a use case where it fails ?

Thanks,

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#947184: yarnpkg and gulp 4, node-glob-stream 6 and node-micromatch 4

[Paolo Greppi]

This is fixed by node-vinyl-fs 3.0.3-3 from experimental as that version is 
compatible with glob-stream 6.x:
https://github.com/gulpjs/vinyl-fs/blob/7e223749ee2ada1abd3b2fb326178d8ad8f39f2c/package.json#L30

I tried building yarnpkg with node-micromatch, gulp and node-glob-stream from 
experimental.
The build succeeds provided I disable the patch 07-gulp.diff (that was required 
to make it work with gulp 3.9)

yarn by itself is using gulp 4 since Aug 2018:
https://github.com/yarnpkg/yarn/pull/6143

So from my POV you can go ahead with uploading to unstable all of them.

P.

-- 
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#947184: node-vinyl-fs: makes yarnpkg FTBFS with node-glob-stream 6.1.0-2

[Paolo Greppi]

Package: node-vinyl-fs
Version: 2.4.4-1
Severity: important

This package causes yarnpkg to FTBFS since node-glob-stream was updated.

A sample build log is:
https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/468304

The relevant part is:
...
gulp build
[12:14:44] Local gulp not found in 
/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.21.1
[12:14:44] Try running: npm install gulp
[12:14:44] Using globally installed gulp
[12:14:44] Using gulpfile 
/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.21.1/gulpfile.js
[12:14:44] Starting 'build'...
[12:14:44] 'build' errored after 524 μs
[12:14:44] TypeError: gs.create is not a function
at Object.src (/usr/lib/nodejs/vinyl-fs/lib/src/index.js:35:23)
at Gulp.src (/usr/lib/nodejs/gulp/index.js:27:14)
at build 
(/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.21.1/gulpfile.js:19:8)
at Gulp.gulp.task 
(/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.21.1/gulpfile.js:32:3)
at module.exports (/usr/lib/nodejs/orchestrator/lib/runTask.js:34:7)
at Gulp.Orchestrator._runTask (/usr/lib/nodejs/orchestrator/index.js:273:3)
at Gulp.Orchestrator._runStep (/usr/lib/nodejs/orchestrator/index.js:214:10)
at Gulp.Orchestrator.start (/usr/lib/nodejs/orchestrator/index.js:134:8)
at /usr/lib/nodejs/gulp/bin/gulp.js:132:20
at process._tickCallback (internal/process/next_tick.js:61:11)

This is super easy to reproduce on sid, just do this:
git clone https://salsa.debian.org/js-team/node-yarnpkg
cd node-yarnpkg
quilt push -a
gulp

The glob-stream node module since version v6.0.0 only exports a function 
instead of exposing a create method:
https://github.com/gulpjs/glob-stream/issues/74

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages yarnpkg depends on:
ii  node-asap  2.0.6-1
ii  node-babel-runtime 6.26.0+dfsg-3
ii  node-bytes 3.0.0-1
ii  node-camelcase 5.3.1-1
ii  node-chalk 2.4.2-1
ii  node-chownr1.1.1-1
ii  node-ci-info   1.1.2-1
ii  node-cli-table 0.3.1-1
ii  node-commander 4.0.1-2
ii  node-death 1.0.0-1
ii  node-debug 3.1.0-2
ii  node-deep-equal1.0.1-1
ii  node-detect-indent 5.0.0-1
ii  node-duplexify 4.1.1-1
ii  node-emoji 1.8.1-1
ii  node-fast-levenshtein  2.0.5-1
ii  node-glob  7.1.6-1
ii  node-imports-loader0.8.0-2
ii  node-ini   1.3.5-1
ii  node-inquirer  3.3.0-3
ii  node-invariant 2.2.2-1
ii  node-is-builtin-module 2.0.0-1
ii  node-js-yaml   3.13.1+dfsg-2
ii  node-loud-rejection2.2.0-1
ii  node-micromatch4.0.2-1
ii  node-minimatch 3.0.4-3
ii  node-mkdirp0.5.1-1
ii  node-node-uuid 3.3.2-2
ii  node-object-path   0.11.4-2
ii  node-path-root 0.1.1-1
ii  node-proper-lockfile   2.0.1-1
ii  node-puka  1.0.0+dfsg-1
ii  node-pump  3.0.0-1
ii  node-pumpify   2.0.1-1
ii  node-read  1.0.7-1
ii  node-request   2.88.1-2
ii  node-request-capture-har   1.2.2-1
ii  node-resolve   1.5.0-1
ii  node-rimraf2.6.2-1
ii  node-semver6.3.0-2
ii  node-ssri  6.0.1-2
ii  node-strict-uri-encode 2.0.0-1
ii  node-strip-ansi5.2.0-2
ii  node-strip-bom 3.0.0-1
ii  node-tar-stream1.5.2-1
ii  node-validate-npm-package-license  3.0.1-1
ii  node-yn3.0.0-1
ii  nodejs 10.17.0~dfsg-2

yarnpkg recommends no packages.

yarnpkg suggests no packages.

-- no debconf information

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

[Pkg-javascript-devel] Bug#947074: proposed fix

[Paolo Greppi]

The proposed fix is now here:
https://salsa.debian.org/js-team/node-yarnpkg/commit/ec80b4e923f8513824b978f2fe0e4b25990f7987

To make sure the build is reproducible, I have based it on this code:
https://sources.debian.org/src/mime-support/3.64/debian/rules/?hl=74#L74

Probably node-glob-stream  6.1.0-2 will break the build though ... let's see 
what the salsa CI reports

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#947074: upstream tarballs for certain components contain unreasonably timestamped files

[Paolo Greppi]

Yes, those files get the timestamp from the upstream tarballs.

To reproduce:

dget 
https://deb.debian.org/debian/pool/main/n/node-yarnpkg/node-yarnpkg_1.21.1-1.dsc
ls -R --full-time node-yarnpkg-1.21.1/ | egrep -v '( 2019-| 2018-| 2017-| 2016)'

It could be fixed by re-uploading the tarballs with fixed timestamps, but I 
prefer to stick with upstream tarballs as-they-are ("source reproducibility").

So I propose to patch it by adding commands in d/rules auch as:

find dnscache/ | xargs touch
find hash-for-dep/ | xargs touch
find normalize-url/ | xargs touch
find npm-logical-tree/ | xargs touch
find query-string/ | xargs touch
find resolve-package-path/ | xargs touch
find string-replace-loader/ | xargs touch
find tar-fs/ | xargs touch
find v8-compile-cache/ | xargs touch

Any comments from the submitter or from the js-team ?

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] npm and yarnpkg vuln

[Paolo Greppi]

https://blog.daniel-ruf.de/critical-design-flaw-npm-pnpm-yarn/
https://github.com/yarnpkg/yarn/issues/7761

I will look at updating yarnpkg to 1.21.1 ...

P.

--
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#945305: RM: node-graceful-readlink -- ROM; not used and unmaintained upstream

[Paolo Greppi]

Package: ftp.debian.org
Severity: normal

This package has low popcon (4) and was a build-dep of node-commander, but that 
dependency was removed with version 2.11.0:
https://github.com/tj/commander.js/blob/master/CHANGELOG.md#2110--2017-07-03
Also the upstream repo has last been updated 5 years ago.

The maintainer is the Debian Javascript Maintainers team of which I am part of.
My intention to remove it was announced in the team mailing list about 3 weeks 
ago:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-October/036848.html

Original ITP: https://bugs.debian.org/849178

Thanks, 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#945306: RM: node-object-assign-sorted -- ROM; currently not used

[Paolo Greppi]

Package: ftp.debian.org
Severity: normal

This package has low popcon (7) and is currently not used.
According to the ITP (https://bugs.debian.org/849255) it was required for lerna 
which was a dependency of babel-cli.
But in the meantime lerna is stuck at RFP (https://bugs.debian.org/849258) and 
babel-cli does not depend on either.

The maintainer is the Debian Javascript Maintainers team of which I am part of.
My intention to remove it was announced in the team mailing list about 3 weeks 
ago:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-October/036848.html

Thanks, 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] Fwd: Bug#945302: Acknowledgement (RM: node-command-join -- ROM; currently not used)

[Paolo Greppi]

FYI; I forgot to X-Debbugs-Cc here.

P.

 Messaggio Inoltrato 
Oggetto: Bug#945302: Acknowledgement (RM: node-command-join -- ROM; currently 
not used)
Data: Fri, 22 Nov 2019 19:06:07 +
Mittente: Debian Bug Tracking System 
Rispondi-a: 945...@bugs.debian.org
A: paolo.gre...@libpf.com

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 945302: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945302.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  debian-rele...@lists.debian.org
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 Debian FTP Master 

If you wish to submit further information on this problem, please
send it to 945...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
945302: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945302
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Pkg-javascript-devel] d/changelog and experimental

[Paolo Greppi]

Hi fellow team members,

I was wandering what is the best approach for d/changelog when releasing a 
package to unstable after it has been though a few iterations to experimental.

It would seem that the right thing to do is to keep all experimental changelog 
entries, and add a new one for unstable.

But sometimes experimental uploads are, well ... experimental, there may be 
changes that cancel out (I tried this but it did not work, then I tried that 
etc.).
So another way is to consolidate  all experimental changelog entries into the 
unstable one, tidying it up.
Also as most people never see the experimental releases, they only care for 
what's new since the last release to unstable / stable.

So I took the latter approach with node-yarnpkg 1.19.1-1.

On this topic I found nothing definitive in policy:
https://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
except footnote 3 which does not really discuss experimental.

On debian-devel I found this old thread:
https://lists.debian.org/debian-devel/2005/01/msg00791.html
where different opinions are voiced.

What the best approach for us ?

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

Re: [Pkg-javascript-devel] [Fwd: Re: Packaging node-timezone]

[Paolo Greppi]

See below

On 15/11/19 05:28, Trout, Diane E. wrote:
> ...
> I think my habit was to push the tags after the package was actually
> accepted since I thought moving a tag can cause conflicts.
> 
> Also in the python team the usually leave the distribution as
> UNRELEASED until the final upload and so it's not quite appropriate for
> to tag that.

That's a good policy !

Actually you do not need to mark it as released in d/changelog and/or push the 
debian/... tag.
For others to be able to work with your WIP packaging and git-buildpackage, you 
only need to push the upstream/... tag(s).

In my workflow I add the debian/.. tag only at the very last moment for example 
with:
gbp buildpackage --git-tag
and all other builds before than one I do with:
gbp buildpackage -usc -us

If you now delete the debian/... tag and unroll the last commit (you can safely 
rewrite history of master branch for a personal repo), CI will still work.

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

Re: [Pkg-javascript-devel] Packaging node-timezone

[Paolo Greppi]

Hi Diane, see low and lower

Paolo

On 10/11/19 06:50, Diane Trout wrote:
> Hi,
> 
> In a renewed effort to try and package bokeh for Debian several
> JavaScript dependencies should probably be packaged, and I'm fairly new
> at dealing with JavaScript packaging.
> 
> I started with timezone. https://bigeasy.github.io/timezone/
> 
> I posted my git history here:
> https://salsa.debian.org/diane/node-timezone
> And I posted a mentors release here:
> https://mentors.debian.net/debian/pool/main/n/node-timezone/node-timezone_1.0.22+~2018i-1.dsc
> 
> I turned upstream's examples into a test harness and it seems like
> there's an upstream bug.
> https://github.com/bigeasy/timezone/issues/320

I see that's now solved !

> ITP bug.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944398
> 
> It embeds a copy of the olsen timezone database, as I couldn't figure
> out a good way of reusing the one shipped by Debian.
> I included the tzdata as a multi-source archive (Which is why I also
> posted it to mentors, as I hadn't done that before)
> 
> Would anyone have time to double check the package to see if it's
> reasonable?
> 
> Thanks,
> Diane

When I look at where debian's tzdata package pulls upstream tarball:
https://salsa.debian.org/glibc-team/tzdata/blob/sid/debian/watch
it's: ftp://ftp.iana.org/tz/releases/tzdb-2019c.tar.lz
this contains flat files for each continent.
It seems the d/rules unpacks in into all the Uppercased Dirs and Files in 
/usr/share/zoneinfo

What https://data.iana.org/time-zones/tz-link.html calls their "development 
repository" is eggert/tz which also has the flat files.

This means that the files you need are in the source of tzdata package.
If node-timezone only needs that at build time, I wonder if you could 
build-depend on the source of tzdata ?

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#927254: closed by Xavier Guimard (Bug#927254: fixed in vue-router.js 3.0.7+ds-1)

[Paolo Greppi]

On Sat, 14 Sep 2019 09:53:18 + Dmitry Bogatov  wrote:
> ...
> It does not build for me. Neither it builds on Salsa CI (I added
> debian/.gitlab-ci.yml on branch `wip').
> 
> https://salsa.debian.org/js-team/vue-router.js/-/jobs/321533
> -- 
> Note, that I send and fetch email in batch, once in a few days.
> Please, mention in body of your reply when you add or remove recepients.

Hi Dmitry, I have fixed the dangling symlink in libjs-vue-route.

It now builds locally and on Salsa CI (I enabled it for master branch as well):
https://salsa.debian.org/js-team/vue-router.js/-/jobs/393462

I then rebuilt laminar from the current version at 
https://salsa.debian.org/debian/laminar against this unreleased libjs-vue-route 
3.0.7+ds-3 version.
After issuing:
  systemctl start laminar.service
and checking that:
  systemctl status laminar.service
returns success,
the laminar service dashboard can be reached from localhost:8080 and causes no 
JavaScript error.

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] Obsoleted node modules

[Paolo Greppi]

Hi !

I was looking at node modules I maintain with a low popocont count (< 10)

1. node-array-from is only used by node-command-join

2. node-babel-plugin-array-includes is a build-dep of yarnpkg

3. node-blob
according to ITP https://bugs.debian.org/781478 node-blob it is required for 
node-engine.io-parser (#781458), which in turn is required for node-socket.io 
(#707166)

4. node-command-join
according to the ITP https://bugs.debian.org/849254 it is required for lerna 
which is a dependency of babel-cli
in the meantime lerna is stuck at RFP: https://bugs.debian.org/849258
and babel-cli does not depend on either

5. node-css-select is a dependency of node-css-loader
latter ITP https://bugs.debian.org/888279 states it is a dependency of gitlab 
9.5 also build dependency of node-react-dev-utils
latter is stuck at ITP https://bugs.debian.org/886215 and is a dependency of 
node-react-error-overlay and of gitlab 9.5

6. node-graceful-readlink
was a build-dep of node-commander, but that dependency was removed with version 
2.11.0:
https://github.com/tj/commander.js/blob/master/CHANGELOG.md#2110--2017-07-03
upstream repo has last been updated 5 years ago

7. node-has-binary
according to ITP https://bugs.debian.org/781486 is required for 
node-engine.io-parser (#781458), which in turn is required for node-socket.io 
(#707166

8. node-has-cors
according to ITP https://bugs.debian.org/848241 it's required by 
node-engine.io-client which in turn is one of the bits required by engine.io, 
socket.io and etherpad-lite

9. node-object-assign-sorted
according to ITP https://bugs.debian.org/849255 it is required for lerna which 
is a dependency of babel-cli
see above node-command-join

10. node-pad
this is the ITP https://bugs.debian.org/849182
there seems to be no use for this

11. node-roadrunner
In the ITP (https://bugs.debian.org/846218) I mention that it was required for 
yarn, but they dropped the dependency:
https://github.com/yarnpkg/yarn/pull/3079
Also duck reports that the upstream repo is gone:
https://github.com/kittens/roadrunner
also the repo currently pointed at by npm regstry is gone:
https://github.com/sebmck/roadrunner

12. node-socket.io-parser
according to ITP https://bugs.debian.org/781417 it is required for 
node-socket.io (#707166), which in turn is required for closure-util (#774562)

13. tinycon.js
according to ITP https://bugs.debian.org/721611 it is a requirement of 
etherpad-lite (https://bugs.debian.org/576998)

14. vue.js
not many users for this one yet ... they'll come !

So I propose RMing 6 packages:
- node-array-from
- node-command-join
- node-graceful-readlink
- node-object-assign-sorted
- node-pad
- node-roadrunner

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] yarnpkg 1.9.1 is ready for unstable

[Paolo Greppi]

yarnpkg is listed here:
https://wiki.debian.org/Javascript/Main/packages
so I am pinging the team before uploading 1.9.1 to unstable.

I manually tested the only run-time dep (gitlab) and it does not break it 
(yarnpkg install works).

I double checked the embedded modules- they're 15

The versions we embed are the same as upstream declares in the yarn.lock file 
except for: 

./dnscache/package.json:"version": "1.0.2",
dnscache@^1.0.1:
  version "1.0.1"

./hash-for-dep/package.json:  "version": "1.5.1",
hash-for-dep@^1.2.3:
  version "1.2.3"

./normalize-url/package.json:   "version": "4.5.0",
normalize-url@^2.0.0:
  version "2.0.1"

./query-string/package.json:"version": "6.8.3",
query-string@^5.0.1:
  version "5.1.1"

./resolve-package-path/package.json:  "version": "1.2.7",
this is a run-time dependency not declared in yarn.lock

./string-replace-loader/package.json:  "version": "2.2.0",
string-replace-loader@^2.1.1:
  version "2.1.1"

./tar-fs/package.json:  "version": "2.0.0",
tar-fs@^1.16.0:
  version "1.16.3"

./v8-compile-cache/package.json:  "version": "2.1.0",
v8-compile-cache@^2.0.0:
  version "2.0.0"

... we're always using same or later versions.

BTW we're cheating on dependencies version here:
https://salsa.debian.org/js-team/node-yarnpkg/commit/eaaf53a07a23a110affc20146e8622a70b8641b0
and here:
https://salsa.debian.org/js-team/node-yarnpkg/commit/13f6217bcc8bc6281c16e628044886a925897bc0

If there are no objections I'll upload next week.

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] npm tarballs can be trusted, was: Re: Bug#943389: Bug#943389: node-lodash: source package does not contain upstream source

[Paolo Greppi]

Hi Jeremy, 

I am replying here to the side note.

On 24/10/19 19:47, Jérémy Lal wrote:
> Le jeu. 24 oct. 2019 à 19:33, Jonas Smedegaard  > a écrit :
> ..
> Side note: downloading from npmjs.org  should be avoided 
> and maybe a
> good candidate for a lintian error; for it is an unreliable source
> (no checksum, no guarantee, unlike git, afaik).
> 
> Jérémy, trying to help.

I do not agree that npm registry tarballs should be distrusted.

Actually they are (supposed to be) immutable and they always had a shasum field 
(based on sha1), it is documented here:
https://github.com/npm/registry/blob/master/docs/REGISTRY-API.md#version

For example I looked at async module, version 0.8.0.

There is an archived copy of the npm registry JSON from 4 years ago (17 Jul 
2015): http://archive.is/acGAB
from there, the dist object is for version 0.8.0 is:
{"shasum":"ee65ec77298c2ff1456bc4418a052d0f06435112","tarball":"http://registry.npmjs.org/async/-/async-0.8.0.tgz"},

The same shasum is available today:
curl -s https://registry.npmjs.org/async | jq '.versions["0.8.0"].dist'
{
  "shasum": "ee65ec77298c2ff1456bc4418a052d0f06435112",
  "tarball": "https://registry.npmjs.org/async/-/async-0.8.0.tgz;
}
and this can be verified:

wget https://registry.npmjs.org/async/-/async-0.8.0.tgz
sha1sum async-0.8.0.tgz 
ee65ec77298c2ff1456bc4418a052d0f06435112  async-0.8.0.tgz

Additionally recent tarballs have new fields:
- integrity (based on 
https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata, for 
modules published with npm@5 or later)
- and npm-signature (see 
https://blog.npmjs.org/post/172999548390/new-pgp-machinery)

For example from here:
curl -s https://registry.npmjs.org/yarn | jq '.versions["1.19.1"].dist'
{
  "shasum": "14b92410dd1ba5bab87a12b4a3d807f4569bea97",
  "tarball": "https://registry.npmjs.org/yarn/-/yarn-1.19.1.tgz;,
  "integrity": 
"sha512-gBnfbL9rYY05Gt0cjJhs/siqQXHYlZalTjK3nXn2QO20xbkIFPob+LlH44ML47GcR4VU9/2dYck1BWFM0Javxw==",
  "fileCount": 12,
  "unpackedSize": 5311732,
  "npm-signature": "-BEGIN PGP SIGNATURE-\r\nVersion: OpenPGP.js 
v3.0.4\r\nComment: 
https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdnH9RCRA9TVsSAnZWagAAi4kP/0b67Q6Ra3wfw8bZmY0z\nouSHtZ7Ua3Ke6T4VPUJgcGz4nuRUVu9eRQBX0pHbyek7YBgE5+AIYQ5Gkua5\ndIv182/OS6DtOVFALfyXJogs+51IiD7K+Zd9RExppBiZuFg1yNVRqxK7Ox6X\nLyPw8G20qQFpC/DgRDkj5dur8mZBAGFIxHrbFPTckXKWyEZdtABfE8vT2rp/\nzsnjMLSeS+OORjMBop6GujXxie2ctTKzHiGyrmcrJIxFaYl+rPTep39lxNMM\nKg/Ad/YiE4p9RDFyWsVqHIWSdphwNUyDiB3c9l/JjP31Pvvqiqh5Yq49B8U7\nafcNA3Uh456zYTXvbf+IM1bL3ZYwxh9DD4yuAWcM+D1fbbpQAaow1QFiAxV+\nBP/EBe9FHJlQR6Y3thqMaTwV5SNu9UdS2iYkC2fbilBcYMagUEOuL9ooQ1VU\nxVb2OPIPebpqodt+O5xfioIqAkS3fv9b1BfD8p0akoRRYHwKf4McftO+MM0Q\nr55SRwdqBPm2y/oZVjgXUFmA9nMj8Y8SJ5+yUUwRysGU6qEKgZs0oy16aypk\nZp2Cz2Df+8WuJoDzADWo8mkWSQHaw2/kAVz3P0JtBz4yfVPaip4LMYh6pa4H\nL2XclAkNDOoN+0IQV64miyq6+bbpYjaQFzxYA/SytDoBPvym1p+P91nj0aaR\nmFWt\r\n=QESU\r\n-END
 PGP SIGNATURE-\r\n"
}

shasum and integrity can be verified like this:

openssl dgst -sha512 -binary yarn-1.19.1.tgz | openssl base64 -A
gBnfbL9rYY05Gt0cjJhs/siqQXHYlZalTjK3nXn2QO20xbkIFPob+LlH44ML47GcR4VU9/2dYck1BWFM0Javxw==
sha1sum yarn-1.19.1.tgz
14b92410dd1ba5bab87a12b4a3d807f4569bea97  yarn-1.19.1.tgz

Verifying npm-signature is left as an exercise (they use Keybase for sharing 
the public keys)

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

Re: [Pkg-javascript-devel] Bug#935845: not an RC bug; fix is easy: upgrade embedded lodash.cli

[Paolo Greppi]

Bringing this over to the mailing list ...

On 23/10/19 22:07, Jonas Smedegaard wrote:
> Quoting Paolo Greppi (2019-10-23 21:18:37)
>> ...
>> The reason is that the bundled version of lodash-cli is out of date:
>> grep version lodash-cli/package.json 
>>   "version": "4.17.5",
>>
>> if you replace the lodash-cli dir with the current version (which is in sync 
>> with lodash itself, 4.17.15) you get the correct file generated.
>>
>> So in the future we should keep the bundled lodash-cli in sync with lodash 
>> itself.
> 
> More importantly: We should track versions!!!
> 
> lodash embeds lodash-cli with "ignore" in its watch file.
> 
> How many JavaScript packages are packaged that way?
> 
> 
>  - Jonas

To find packages with ignore in d/watch:
https://codesearch.debian.net/search?q=ignore+path%3Adebian%2Fwatch

But this check is not enough to tell that something is wrong.
It can still be fine provided that upstream has a yarn.lock or a 
package-lock.json AND all components pulled in are at the same version as 
required by the lock files.
It seems that we need tooling to automatically verify that. Any volunteer ?

For lodash the build-dep on lodash.cli is not in the devDependencies key of the 
package.json nor in the lockfiles (the only hint that you need that is in 
.travis.yml file).
Anyway common sense requires that lodash.cli should be at the same version as 
lodash itself.
It does not make sense to hack the version to 
node-lodash_4.17.15+4.17.15+dfsg-1, people have already making fun of that: 
http://joeyh.name/blog/entry/turing_complete_version_numbers/
For this one I propose that we add a test in d/rules override_dh_test target 
that `grep version lodash-cli/package.json` == `grep version package.json` 
(sorry pseudocode but you get the idea)

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#935845: not an RC bug; fix is easy: upgrade embedded lodash.cli

[Paolo Greppi]

First, I tripped on this one while testing yarnpkg 1.19.1 from experimental.
For the record, this is how I found that node-lodash was the culprit:

node --trace-deprecation /usr/bin/yarnpkg install
yarn install v1.19.1
[1/4] Resolving packages...
(node:29081) [DEP0016] DeprecationWarning: 'root' is deprecated, use 'global'
at Object. (/usr/share/nodejs/lodash/_createRound.js:6:22)
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)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/usr/share/nodejs/lodash/ceil.js:1:19)
at Module._compile (internal/modules/cjs/loader.js:778:30)
...

Second, this should not be an RC bug.
It's a deprecation **warning**.
And it could be easily patched out by allowing stderr in the autopkgtest.

But (and that's the third point) there's no need of that hack, because the 
actual fix is easier.

The upstream commit that Jonas pointed to is on a branch (4.17.15-npm) where 
upstream stores built artifacts ("binaries").
You can rebuild those binaries locally in this package sources dir with:
NODE_PATH=. node lodash-cli/bin/lodash modularize exports=node -o modules
only to find that the generated modules/_createRound.js lacks the root = 
require statement

The reason is that the bundled version of lodash-cli is out of date:
grep version lodash-cli/package.json 
  "version": "4.17.5",

if you replace the lodash-cli dir with the current version (which is in sync 
with lodash itself, 4.17.15) you get the correct file generated.

So in the future we should keep the bundled lodash-cli in sync with lodash 
itself.

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#941119: BTW, that was on buster

[Paolo Greppi]

... everything applies to buster:

apt-cache policy pkg-js-tools 
pkg-js-tools:
  Installato: 0.9.16~bpo10+1
...

add-node-component --version
0.2

P.

-- 
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#941119: fails when libjson-xs-perl is installed

[Paolo Greppi]

with:
cd `mktemp -d`
salsa checkout node-is-directory --group js-team
cd node-is-directory/
sudo apt install libjson-xs-perl
add-node-component rollup-plugin-node-builtins

Thread 1 terminated abnormally: Malformed upstream registry: JSON text must be 
an object or array (but found number, string, true, false or null, use 
allow_nonref to allow this) at /usr/share/perl5/JSON.pm line 190.
Component rollup-plugin-node-builtins not found in npm registry at 
/usr/bin/add-node-component line 173.

without:
sudo apt remove libjson-xs-perl
add-node-component rollup-plugin-node-builtins
Components added: rollup-plugin-node-builtins

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

Re: [Pkg-javascript-devel] strange behavior of gbp import-orig --uscan --pristine-tar

[Paolo Greppi]

On 03/10/19 10:19, Xavier wrote:
> Never use gbp --uscan, totally buggy. Préfet uscan, then gbp import-orig 
> ../xx.orig.tard.gz

Thanks for the quick reply. It is indeed a git-buildpackage bug:
https://bugs.debian.org/934200

For future reference, this worked:

cd `mktemp -d`
git clone https://salsa.debian.org/js-team/node-yarnpkg
cd node-yarnpkg
git fetch origin pristine-tar
git checkout pristine-tar
git fetch origin upstream
git checkout upstream
git checkout master
uscan 
gbp import-orig --pristine-tar ../node-yarnpkg_1.19.0.orig.tar.gz

the master branch is now OK:
grep name package.json 
  "name": "yarn",

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] strange behavior of gbp import-orig --uscan --pristine-tar

[Paolo Greppi]

I do this:

cd `mktemp -d`
git clone https://salsa.debian.org/js-team/node-yarnpkg
cd node-yarnpkg
git checkout -b upstream origin/upstream
git checkout upstream 
git pull
git checkout master
gbp import-orig --uscan --pristine-tar

at the end of the process, the master branch is screwed:
grep name package.json 
  "name": "v8-compile-cache",

the key part of the gbp import-orig is:
gbp:info: Launching uscan...
gbp:info: Using uscan downloaded tarball 
../node-yarnpkg_1.19.0.orig-v8-compile-cache.tar.gz
What is the upstream version? [1.19.0] tar: 
gbp:info: ../node-yarnpkg_1.19.0.orig.tar.gz already exists, moving to 
../node-yarnpkg_1.19.0.orig.tar.gz.1570089312
gbp:info: Importing '../node-yarnpkg_1.19.0.orig-v8-compile-cache.tar.gz' to 
branch 'upstream'...
gbp:info: Source package is node-yarnpkg
gbp:info: Upstream version is 1.19.0
gbp:info: Replacing upstream source on 'master'
gbp:info: Successfully imported version 1.19.0 of 
../node-yarnpkg_1.19.0.orig-v8-compile-cache.tar.gz

Before I file a bug, has anyone an idea of what is going on ?

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#941354: proposed fix

[Paolo Greppi]

I have imported the upstream patch in a new version 1.13.0-3:
https://salsa.debian.org/js-team/node-yarnpkg/commit/6808cd918e8c12182e14666c715bb1d372d82449/pipelines

I have checked that it now uses https even if http links are present in 
yarn.lock as follows:

mkdir /tmp/qw
cd /tmp/qw
yarnpkg add string-width
rm -rf node_modules/
sed -i 's/https:/http:/g' yarn.lock
yarnpkg cache clean strip-ansi
yarnpkg cache clean string-width
yarnpkg cache clean ansi-regex
yarnpkg cache clean emoji-regex
yarnpkg cache clean is-fullwidth-code-point
yarnpkg cache clean strip-ansi

strace -s 256 yarnpkg install &> q
ping registry.yarnpkg.com # it's 104.16.22.35
grep 104.16.22.35 q

I get this:
connect(21, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)
connect(22, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)
connect(26, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)
connect(27, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)
connect(28, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)

Should I upload this to unstable ?
Will it automatically roll to stable ?

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#941354: upstream patch link

[Paolo Greppi]

one way to address this is importing this as a debian/patch:

https://github.com/yarnpkg/yarn/commit/2f08a7405cc3f6fe47c30293050bb0ac94850932

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] some progress towards packaging jest

[Paolo Greppi]

Hi,

it now builds on sid:
https://salsa.debian.org/js-team/node-jest/pipelines/73174

but there's still a lot to do:

1) turn on tests of course (it tests itself)

2) this lintian message is worth investigating:
P: node-jest-cli: image-file-in-usr-lib 
usr/lib/nodejs/jest-cli/build/assets/jest_logo.png

3) it needs a manpage for /usr/bin/jest

4) d/copyright is TODO

5) it should generate 6 additional binaries:
- node-jest-changed-files
- node-jest-environment-jsdom
- node-jest-get-type
- node-jest-resolve-dependencies
- node-jest-runner
- node-jest-snapshot

6) there are 12 modules in debian/node_modules/ - some of them are quite large:
SLOCDirectory   SLOC-by-Language (Sorted)
9422rollup-plugin-node-builtins javascript=9422
5556levelup javascript=5547,sh=9
2317level-jsjavascript=2317
1610level-filesystem javascript=1610
1552buffer-es6  javascript=1552
646 rollup-plugin-node-globals javascript=646
425 babel-plugin-transform-inline-imports-commonjs javascript=425
187 process-es6 javascript=187
18  rollup-plugin-flow javascript=18
13  browserify-fs   javascript=13
4   string-length   javascript=4
3   astral-regexjavascript=3
string-length is also a run-time dep (see below)
BTW rollup-plugin-node-builtins is currently used for building node-mocha 4.1.0:
https://sources.debian.org/src/node-mocha/4.1.0+ds3-5/debian/node_modules/rollup-plugin-node-builtins/
(but that dependency is dropped in 6.2.0 which is in experimental)

7) probably it should be repackaged to exclude examples/react-native:
P: node-jest source: source-contains-prebuilt-java-object 
examples/react-native/android/gradle/wrapper/gradle-wrapper.jar
N: 
N:The source tarball contains a prebuilt Java class file. These are often
N:included by mistake when developers generate a tarball without cleaning
N:the source directory first. If there is no sign this was intended,
N:consider reporting it as an upstream bug as it may be a DFSG violation.
N:
N:Severity: pedantic, Certainty: possible
N:
N:Check: java, Type: binary, source

8) and finally assuming the 6 additional binaries are generated from this 
source, it would still be uninstallable because there are 8 missing run-time 
dependencies:
- node-import-local (>= 1.0.0)
- node-istanbul-api (>= 1.1.14)
- node-istanbul-lib-coverage (>= 1.1.1)
- node-istanbul-lib-instrument (>= 1.8.0)
- node-istanbul-lib-source-maps (>= 1.2.1)
- node-node-notifier (>= 5.2.1)
- node-realpath-native (>= 1.0.0)
- node-string-length (>= 2.0.0)
for none of these there's an ITP
if we update to v22.4.4 (the version required by yarnpkg) then these 
dependencies are still there
if we update to v24.9.0 (current) istanbul-api disappears (it is deprecated 
from upstream)
in both cases I haven't checked if there are new deps

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#940704: yarnpkg: enable upstream test suite during build

[Paolo Greppi]

Package: yarnpkg
Version: 1.13.0-1
Severity: normal

the package has autopkgtest enabled but there no test is run during the build

it would be safer to enable the upstream test suite, but this requires jest;
I have given it a try using jest 22.4.4 installed from a separate node_modules 
dir and got:

Summary of all failing tests

FAIL __tests__/commands/run.js
...

  ● properly handle env command

Error: expect(object).toHaveProperty(path)
...

FAIL __tests__/util/request-manager.js
...

  ● RequestManager.request with cafile

error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
...

  ● RequestManager.request with ca (string)

error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
...

  ● RequestManager.request with ca (array)

error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
...

  ● RequestManager.request with mutual TLS

error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
...

FAIL gunzip-maybe/test.js
  ● Test suite failed to run

Cannot find module 'tape' from 'test.js'
...

FAIL __tests__/index.js
  ● Test suite failed to run

These tests require `yarn build` to have been run first.
...

FAIL __tests__/lifecycle-scripts.js
  ● Test suite failed to run

These tests require `yarn build` to have been run first.
...

FAIL peek-stream/test.js
  ● Test suite failed to run

Cannot find module 'tape' from 'test.js'
...

FAIL __tests__/integration.js
  ● Test suite failed to run

These tests require `yarn build` to have been run first.
...

Test Suites: 7 failed, 83 passed, 90 total
Tests:   5 failed, 3 skipped, 1116 passed, 1124 total
Snapshots:   111 passed, 111 total
Time:77.732s

even if we have to exclude some tests, it makes sense to enable the test suite 
as a whole

-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages yarnpkg depends on:
ii  node-asap  2.0.6-1
ii  node-babel-runtime 6.26.0+dfsg-3
ii  node-bytes 3.0.0-1
ii  node-camelcase 5.0.0-1
ii  node-chalk 2.3.0-2
ii  node-chownr1.1.1-1
ii  node-ci-info   1.1.2-1
ii  node-cli-table 0.3.1-1
ii  node-commander 2.12.2-3
ii  node-death 1.0.0-1
ii  node-debug 3.1.0-2
ii  node-deep-equal1.0.1-1
ii  node-detect-indent 5.0.0-1
ii  node-duplexify 3.6.1-1
ii  node-emoji 1.8.1-1
ii  node-fast-levenshtein  2.0.5-1
ii  node-glob  7.1.3-2
ii  node-imports-loader0.7.1-1
ii  node-ini   1.3.5-1
ii  node-inquirer  3.3.0-2
ii  node-invariant 2.2.2-1
ii  node-is-builtin-module 2.0.0-1
ii  node-loud-rejection1.6.0-1
ii  node-micromatch2.3.11-1
ii  node-minimatch 3.0.4-3
ii  node-mkdirp0.5.1-1
ii  node-node-uuid 3.3.2-2
ii  node-object-path   0.11.4-2
ii  node-proper-lockfile   2.0.1-1
ii  node-puka  1.0.0+dfsg-1
ii  node-pump  3.0.0-1
ii  node-pumpify   1.5.1-1
ii  node-read  1.0.7-1
ii  node-request   2.88.1-2
ii  node-request-capture-har   1.2.2-1
ii  node-resolve   1.5.0-1
ii  node-rimraf2.6.2-1
ii  node-semver5.5.1-1
ii  node-ssri  5.2.4-2
ii  node-strip-ansi4.0.0-1
ii  node-strip-bom 3.0.0-1
ii  node-tar-stream1.5.2-1
ii  node-validate-npm-package-license  3.0.1-1
ii  node-yn3.0.0-1
ii  nodejs 10.15.2~dfsg-2

yarnpkg recommends no packages.

yarnpkg suggests no packages.

-- no debconf information

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

[Pkg-javascript-devel] Fwd: node-yarnpkg_1.13.0-2_source.changes REJECTED

[Paolo Greppi]

Hi, BTW it failed also the second time ;-)

I have prepared an update to node-yarnpkg from 1.13.0-1 to  1.13.0-2

Please someone allow me DM upload access for this package or sponsor the upload:
https://salsa.debian.org/js-team/node-yarnpkg

Paolo

 Forwarded Message 
Subject: node-yarnpkg_1.13.0-2_source.changes REJECTED
Date: Tue, 17 Sep 2019 06:50:46 +
From: Debian FTP Masters 
To: Debian Javascript Maintainers 
, Paolo Greppi 




ACL dm: not allowed to upload source package 'node-yarnpkg'



===

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] Fwd: node-yarnpkg_1.13.0-2_source.changes REJECTED

[Paolo Greppi]

Hi all,

do you also get the error below sometime ?

I think it happened to me because uscan had redownloaded all *.orig-*.tar.gz 
files on behalf of gbp buildpackage ..
Each time gbp buildpackage is launched, and those files are not present on the 
parent dir, they are redownloaded and can be different.
I did two new tests and I got node-yarnpkg_1.13.0.orig-npm-logical-tree.tar.gz 
with 4835 and 4838 bytes (not 4834 of my failed upload but also not 4837 as the 
previous uploader.

Before gbp buildpackage I should have used these commands in the source tree:

rm ../*.orig-*.tar.gz
gbp export-orig

to clean up the parent dir and restore the *.orig-*.tar.gz files as were sent 
by the original uploader.

That, or:
dget 
http://deb.debian.org/debian/pool/main/n/node-yarnpkg/node-yarnpkg_1.13.0-1.dsc
but I find gbp export-orig easier.

Paolo

 Forwarded Message 
Subject: node-yarnpkg_1.13.0-2_source.changes REJECTED
Date: Mon, 16 Sep 2019 18:49:47 +
From: Debian FTP Masters 
To: Debian Javascript Maintainers 
, Paolo Greppi 




node-yarnpkg_1.13.0-2.dsc: Invalid size hash for 
node-yarnpkg_1.13.0.orig-npm-logical-tree.tar.gz:
According to the control file the size hash should be 4834,
but node-yarnpkg_1.13.0.orig-npm-logical-tree.tar.gz has 4837.

If you did not include node-yarnpkg_1.13.0.orig-npm-logical-tree.tar.gz in your 
upload, a different version
might already be known to the archive software.



===

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] Bug#940514: yarnpkg: implement bash autocompletion

[Paolo Greppi]

Package: yarnpkg
Version: 1.13.0-1
Severity: normal

please implement bash autocompletion for yarnpkg as we have for example in npm.

-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages yarnpkg depends on:
ii  node-asap  2.0.6-1
ii  node-babel-runtime 6.26.0+dfsg-3
ii  node-bytes 3.0.0-1
ii  node-camelcase 5.0.0-1
ii  node-chalk 2.3.0-2
ii  node-chownr1.1.1-1
ii  node-ci-info   1.1.2-1
ii  node-cli-table 0.3.1-1
ii  node-commander 2.12.2-3
ii  node-death 1.0.0-1
ii  node-debug 3.1.0-2
ii  node-deep-equal1.0.1-1
ii  node-detect-indent 5.0.0-1
ii  node-duplexify 3.6.1-1
ii  node-emoji 1.8.1-1
ii  node-fast-levenshtein  2.0.5-1
ii  node-glob  7.1.3-2
ii  node-imports-loader0.7.1-1
ii  node-ini   1.3.5-1
ii  node-inquirer  3.3.0-2
ii  node-invariant 2.2.2-1
ii  node-is-builtin-module 2.0.0-1
ii  node-loud-rejection1.6.0-1
ii  node-micromatch2.3.11-1
ii  node-minimatch 3.0.4-3
ii  node-mkdirp0.5.1-1
ii  node-node-uuid 3.3.2-2
ii  node-object-path   0.11.4-2
ii  node-proper-lockfile   2.0.1-1
ii  node-puka  1.0.0+dfsg-1
ii  node-pump  3.0.0-1
ii  node-pumpify   1.5.1-1
ii  node-read  1.0.7-1
ii  node-request   2.88.1-2
ii  node-request-capture-har   1.2.2-1
ii  node-resolve   1.5.0-1
ii  node-rimraf2.6.2-1
ii  node-semver5.5.1-1
ii  node-ssri  5.2.4-2
ii  node-strip-ansi4.0.0-1
ii  node-strip-bom 3.0.0-1
ii  node-tar-stream1.5.2-1
ii  node-validate-npm-package-license  3.0.1-1
ii  node-yn3.0.0-1
ii  nodejs 10.15.2~dfsg-2

yarnpkg recommends no packages.

yarnpkg suggests no packages.

-- no debconf information

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

[Pkg-javascript-devel] Bug#940511: there's a already a yarn binary in Debian

[Paolo Greppi]

Hi Melvin,

thanks for raising this issue again.
We can't just symlink yarn to yarnpkg or rename yarnpkg -> yarn because there's 
a already a yarn binary in Debian, see:
https://packages.debian.org/search?suite=sid=all=any=contents=yarn

This was extensively debated in the IPT bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843021#65
and the consensus at the time was that "our" yarn -was to ship only the yarnpkg 
binary

I still think it's confusing and I agree with you that it would be best to use 
the same name as upstream.

I propose to keep this bug open and wait to see what happens; ATM cmdtest is 
far more popular (as per popcon data) than yarnpkg ...

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] potentially interesting for the team: deno runtime for JavaScript and TypeScript

[Paolo Greppi]

https://deno.land/
https://youtu.be/z6JRlx5NC9E

echo node | sed -r 's/\<(..)(..)\>/\2\1/g'
 
P.

-- 
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] potentially interesting for the team: QuickJS Javascript Engine

[Paolo Greppi]

https://bellard.org/quickjs/
https://odino.org/playing-with-quickjs/

P.

-- 
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] De-embedding a component

[Paolo Greppi]

On 14/08/19 14:57, Xavier wrote:
> Le 14/08/2019 à 14:55, Paolo Greppi a écrit :
>> The https://wiki.debian.org/Javascript/GroupSourcesTutorial page is great
>> but does not cover the reverse step, when you want to de-embed a component.
>>
>> This is useful if upstream drops that dependency or if it gets separately
>> packaged in Debian.
>>
>> I have done that manually for node-yarnpkg/strict-uri-encode here:
>> https://salsa.debian.org/js-team/node-yarnpkg/commit/9a7ff6867e
>>
>> Please someone review my approach before I upload, and maybe document it in
>> the wiki page above.
>> One thing I am not sure about is that strict-uri-encode tarball is still
>> present in pristine-tar branch ...
>>
>> Paolo
> 
> Hi,
> 
> I can easily build a "del-node-component"

This operation happens seldom, maybe a documented manual procedure is also OK

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] De-embedding a component

[Paolo Greppi]

The https://wiki.debian.org/Javascript/GroupSourcesTutorial page is great
but does not cover the reverse step, when you want to de-embed a component.

This is useful if upstream drops that dependency or if it gets separately
packaged in Debian.

I have done that manually for node-yarnpkg/strict-uri-encode here:
https://salsa.debian.org/js-team/node-yarnpkg/commit/9a7ff6867e

Please someone review my approach before I upload, and maybe document it in
the wiki page above.
One thing I am not sure about is that strict-uri-encode tarball is still
present in pristine-tar branch ...

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#933498: seems to work with no changes

[Paolo Greppi]

I rebuilt yarnpkg 1.13 using webpack 4.7 from experimental and it worked fine.
I manually tested the resulting package and its yarnpkg executable seems to 
work.

From visual inspection the webpack config that we are using seems compliant 
with the requirements of webpack 4:
https://salsa.debian.org/js-team/node-yarnpkg/blob/master/debian/rules#L15
https://salsa.debian.org/js-team/node-yarnpkg/blob/master/scripts/build-webpack.js#L71

I would keep this bug open until the CI and users confirm that all work fine.

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] automatically pulling vulnerabilities from snyk.io

[Paolo Greppi]

After filing https://bugs.debian.org/932500 I realized it would be great to have
some automation in place to automatically pull vulnerabilities from
https://snyk.io and turn them into CVE bugs in BTS.

Thoughts ?

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#932500: vulnerability: prototype pollution

[Paolo Greppi]

Package: node-mixin-deep
Version: 1.1.3-3
Severity: important

Dear Maintainer,

node-mixin-deep 1.1.3-3  is affected by a prototype pollution vulnerability:
https://snyk.io/vuln/SNYK-JS-MIXINDEEP-450212
https://github.com/jonschlinkert/mixin-deep/issues/6

Please upgrade to either 1.3.2 or 2.0.1.

Thanks, Paolo



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages node-mixin-deep depends on:
ii  node-for-in 1.0.2-1
ii  node-is-extendable  1.0.1-1
ii  nodejs  10.15.2~dfsg-2

node-mixin-deep recommends no packages.

node-mixin-deep suggests no packages.

-- no debconf information

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

[Pkg-javascript-devel] Bug#930647: this is a timezone issue

[Paolo Greppi]

nodejs -e 'dsv = require("."); console.log(dsv.csvFormat([{date: new Date(2018, 
0, 1)}]));'
TZ='UTC' nodejs -e 'dsv = require("."); console.log(dsv.csvFormat([{date: new 
Date(2018, 0, 1)}]));'
TZ='EST' nodejs -e 'dsv = require("."); console.log(dsv.csvFormat([{date: new 
Date(2018, 0, 1)}]));'
TZ='America/Los_Angeles' nodejs -e 'dsv = require("."); 
console.log(dsv.csvFormat([{date: new Date(2018, 0, 1)}]));'

outputs respectively:
2017-12-31T23:00Z
2018-01-01
2018-01-01T05:00Z
2018-01-01T08:00Z

looking at the 1st failing test:
  test.deepEqual(dsv.csvFormat([{date: new Date(2018, 0, 1)}]), 
"date\n2018-01-01T08:00Z");
it looks like the upstream developers live in California

so it can be fixed with:
https://salsa.debian.org/js-team/node-d3-dsv/commit/9a445e4a6c01237c5e73a71daa8ad142450007e9

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] uscan thinks yarnpkg 1.17.0 has been already released

[Paolo Greppi]

as of today, upstream has tagged yarn 1.17.0 but marked it as "Pre-release":
https://github.com/yarnpkg/yarn/releases
(also see screenshot)

but uscan says:
uscan: Newest version of node-yarnpkg on remote site is 1.17.0, local version 
is 1.13.0

is this something we can fix by tweaking the watch file or a uscan bug ?

see:
https://salsa.debian.org/js-team/node-yarnpkg/blob/master/debian/watch

BTW the pre-release / release info is not available in tags:
https://github.com/yarnpkg/yarn/tags
only in relases:
https://github.com/yarnpkg/yarn/releases

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] electron packaging

[Paolo Greppi]

I just filed a couple of RFPs for electron apps and immediately added this one 
as a blocker:
https://bugs.debian.org/842420

So yes there are some trending messaging apps and code editors built with 
electron !

Packaging it would be a huge task also because it is a mixed-language project.
sloccount reports:
cpp:  59225 (61.39%)
javascript:   29379 (30.46%)
ansic: 3833 (3.97%)
python:3205 (3.32%)
sh: 824 (0.85%)
But electron is definitely part of the js ecosystem (exactly as nodejs) so we 
should be brave and pick it up.

The first step would be to evaluate which of the electron apps we (as js-team) 
want to focus on.
Next find out if a single electron version can be used.
From a first look, it seems problematic:

- atom: "electronVersion": "3.1.10"
- beaker: "electron": "5.0.0"
- franz: "electron": "5.0.2",
- mattermost-desktop: "electron": "^4.0.0"
- riot-web: "electronVersion": "4.2.4",
- signal-desktop: "electron": "4.2.2"
- ssb-patchwork: "electron": "^4.2.4",
- vscode: target "4.2.4"
(for vscode it is not in package.json, I found it here (?): 
https://github.com/microsoft/vscode/blob/master/.yarnrc)

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#927254: Bug#927254: possible solution

[Paolo Greppi]

On 10/06/19 20:03, Paolo Greppi wrote:

...
Tomorrow I'll test the generated file inside laminar. If that works this is an 
acceptable solution.
The last bit is to move this config change to debian/rollup-umd.js so that it 
does not impact all builds..

Paolo



I tested with the non-minified file generated using the patched build/config.js 
and this command:
NODE_PATH=debian/node_modules/ rollup -m -c debian/rollup-umd.js
but when opening the laminar dashboard I get a new error:

vue-router.min.js:1195 Uncaught TypeError: Cannot read property 'forEach' of 
undefined
at compileRouteRegex (vue-router.min.js:1195)
at addRouteRecord (vue-router.min.js:1112)
at vue-router.min.js:1061
at Array.forEach ()
at createRouteMap (vue-router.min.js:1060)
at createMatcher (vue-router.min.js:1274)
at new VueRouter (vue-router.min.js:2374)
at app.js:796

Not sure if this is due to some path-to-regexp API change.

Anyway that code is skipped for the minified version:
https://salsa.debian.org/js-team/vue-router.js/blob/master/src/create-route-map.js#L156

so I tested the file generated with:
NODE_PATH=debian/node_modules/ rollup -m -c debian/rollup-umd-min.js

and the JavaScript now works apart from some missing CSS and vue is in dev mode 
(see attached screenshot)

So I confirm that the way to go to fix the issue with libjs-vue-router minified 
UMD build is to enable rollup-plugin-node-resolve.
The proposed config change should be moved from build/config.js to 
debian/rollup-umd*.js so that it does not impact the other builds.

But the dev mode, minified UMD build would be affected by the exception above, 
generated in compileRouteRegex function.

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#927254: Bug#927254: possible solution

[Paolo Greppi]

On 11/06/19 08:03, Pirate Praveen wrote:

I think rollup-plugin-commonjs will also work without extra options, see 
node-d3-fetch.



rollup-plugin-commonjs is already there in the upstream rollup config:
https://salsa.debian.org/js-team/vue-router.js/blob/master/build/configs.js#L4

P.

--
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#927254: possible solution

[Paolo Greppi]

If I build manually the UMD version using the same command as in debian/rules:

NODE_PATH=debian/node_modules/ rollup -m -c debian/rollup-umd.js

I get this:

/home/paolog/Sviluppo/debian/vue-router.js/src/index.js → dist/vue-router.js...
(!) Unresolved dependencies
https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
path-to-regexp (imported by src/util/params.js, src/create-route-map.js)
(!) Missing global variable name
Use options.globals to specify browser global variable names corresponding to 
external modules
path-to-regexp (guessing 'Regexp')
created dist/vue-router.js in 761ms

so it is not bundling path-to-regexp, assuming it is available to the browser 
as Regexp which clearly is not the case.

Following the advice from the rollup and rollup-plugin-node-resolve docs, I 
modified the rollup config like this:

diff --git a/build/configs.js b/build/configs.js
index f81ec3a..378437b 100644
--- a/build/configs.js
+++ b/build/configs.js
@@ -36,11 +36,19 @@ module.exports = [
   }
 ].map(genConfig)
 
+const resolve1 = require('rollup-plugin-node-resolve')

+
 function genConfig (opts) {
   const config = {
 input: {
   input: resolve('src/index.js'),
   plugins: [
+  require('rollup-plugin-node-resolve')({
+customResolveOptions: {
+moduleDirectory: ['/usr/lib/nodejs'],
+preferBuiltins: false
+  }
+}),
 flow(),
 node(),
 cjs(),

Now the same command bundles path-to-regexp, so that the differences between 
the file generated in dist/vue-router.js
and the one from  wget https://unpkg.com/vue-router@3.0.2/dist/vue-router.js 
are much less (mainly the differences between path-to-regexp 1.7.0 bundled by 
upstream and 3.0.0 bundled by us).

Tomorrow I'll test the generated file inside laminar. If that works this is an 
acceptable solution.
The last bit is to move this config change to debian/rollup-umd.js so that it 
does not impact all builds..

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#927254: reproducible, but ...

[Paolo Greppi]

Hi, nice one !

It is reproducible when I use the laminar debs built from the WIP package here:
https://salsa.debian.org/debian/laminar
after these fixes:
https://bugs.debian.org/919181#27

Once started, the laminar service dashboard should be reachable from 
localhost:8080 but it fails to load.
If you open chromium inspector it reports:

vue-router.min.js:10 Uncaught ReferenceError: require is not defined
at vue-router.min.js:10
(anonymous) @ vue-router.min.js:10
app.js:746 Uncaught ReferenceError: Chart is not defined
at app.js:746
(anonymous) @ app.js:746
Navigated to http://10.0.3.188:8080/
vue.min.js:1 You are running Vue in development mode.
Make sure to turn on production mode when deploying for production.
See more tips at https://vuejs.org/guide/deployment.html

Interestingly, laminar package does not depend on libjs-vue-router because the 
file served from:
http://10.0.3.188:8080/js/vue-router.min.js
gets hard-coded in the /usr/sbin/laminard executable in at build time.
Indeed libjs-vue-router is a mere build-dep for laminar package:
https://salsa.debian.org/debian/laminar/blob/master/debian/control#L15

Currently it is hardcoding vue-router.common.js as vue-router.min.js:
https://salsa.debian.org/debian/laminar/blob/master/debian/patches/0001-Patch-build-system-to-use-JS-libraries-from-Debian-p.patch#L29
which is wrong.

I fixed the JS lib locations like this:
diff --git 
a/debian/patches/0001-Patch-build-system-to-use-JS-libraries-from-Debian-p.patch
 
b/debian/patches/0001-Patch-build-system-to-use-JS-libraries-from-Debian-p.patch
index 0d6ca8f..e6ffdfe 100644
--- 
a/debian/patches/0001-Patch-build-system-to-use-JS-libraries-from-Debian-p.patch
+++ 
b/debian/patches/0001-Patch-build-system-to-use-JS-libraries-from-Debian-p.patch
@@ -26,11 +26,11 @@ index cf73a1b..d18dc65 100644
 -css/bootstrap.min.css EXPECTED_MD5 5d5357cb3704e1f43a1f5bfed2aebf42)
 +file(DOWNLOAD file:///usr/share/javascript/vue/vue.min.js
 +  js/vue.min.js)
-+file(DOWNLOAD file:///usr/share/javascript/vue-router/vue-router.common.js
++file(DOWNLOAD file:///usr/lib/nodejs/vue-router/dist/vue-router.min.js
 +  js/vue-router.min.js)
-+file(DOWNLOAD file://usr/share/javascript/ansi_up/ansi_up.min.js
++file(DOWNLOAD file:///usr/share/javascript/ansi_up/ansi_up.min.js
 +  js/ansi_up.js)
-+file(DOWNLOAD file://usr/share/javascript/chart.js/Chart.min.js
++file(DOWNLOAD file:///usr/share/javascript/chart.js/Chart.min.js
 +  js/Chart.min.js)
 +file(DOWNLOAD file://usr/share/javascript/bootstrap/css/bootstrap.min.css
 +  css/bootstrap.min.css)

(notice the three forward slashes after file:)

This gets rid of the Chart error, unfortunately for vue-router.min.js, for that 
I just get a different error in chrome inspector:

vue-router.min.js:791 Uncaught TypeError: Regexp is not a function
at compileRouteRegex (vue-router.min.js:791)
at addRouteRecord (vue-router.min.js:723)
at vue-router.min.js:681
at Array.forEach ()
at createRouteMap (vue-router.min.js:680)
at createMatcher (vue-router.min.js:864)
at new VueRouter (vue-router.min.js:1942)
at app.js:796
compileRouteRegex @ vue-router.min.js:791
addRouteRecord @ vue-router.min.js:723
(anonymous) @ vue-router.min.js:681
createRouteMap @ vue-router.min.js:680
createMatcher @ vue-router.min.js:864
VueRouter @ vue-router.min.js:1942
(anonymous) @ app.js:796

Indeed comparing this file:
https://unpkg.com/vue-router@3.0.2/dist/vue-router.js
with the one packaged by us, they're different.

I attach the diff:
diff vue-router.js_unpkg vue-router.min.js_debian > diff

Paolo
3c3
<   * (c) 2018 Evan You
---
>   * (c) 2019 Evan You
7,10c7,12
<   typeof exports === 'object' && typeof module !== 'undefined' ? 
module.exports = factory() :
<   typeof define === 'function' && define.amd ? define(factory) :
<   (global.VueRouter = factory());
< }(this, (function () { 'use strict';
---
>   typeof exports === 'object' && typeof module !== 'undefined' ? 
> module.exports = factory(require('path-to-regexp')) :
>   typeof define === 'function' && define.amd ? define(['path-to-regexp'], 
> factory) :
>   (global.VueRouter = factory(global.Regexp));
> }(this, (function (Regexp) { 'use strict';
> 
> Regexp = Regexp && Regexp.hasOwnProperty('default') ? Regexp['default'] : 
> Regexp;
21c23
<   if ("development" !== 'production' && !condition) {
---
>   if ("production" !== 'production' && !condition) {
127c129
< }
---
> };
140,146c142
<   {
< warn(
<   false,
<   "props in \"" + (route.path) + "\" is a " + (typeof config) + ", " +
<   "expecting an object, function or boolean."
< );
<   }
---
>   
177c173
< "development" !== 'production' && warn(false, e.message);
---
> "production" !== 'production' && warn(false, e.message);
247a244
> 
487c484
< }
---
> };
648,1080d644
< var isarray = Array.isArray || function (arr) {
<   

[Pkg-javascript-devel] Bug#929829: Bug#929829: Bug#929829: Bug#929829: Bug#929829: gulp 4 cannot build node-babel 7 - Cannot convert undefined or null to object

[Paolo Greppi]

On 06/06/19 07:30, Xavier wrote:

...
My reducejs tool gives a new analysis:
  * updates needed:
- gulp-babel : 7.0.1 => 8.0.0
- rollup-plugin-babel : 3.0.3 => 4.3.2
  * downgraded modules to embed
- process-nextick-args : 2.0.0 => 1.0.7
  * problems:
- build fails with our readable-stream (2.3.6) but succeeds with
  upstream readable-stream (2.3.6 also)


AFAICT readable-stream is only needed to support old versions of node; try to 
patch it away and use the core stream module from node as in:

https://salsa.debian.org/js-team/node-tar-stream/blob/master/debian/patches/00-readable_stream.patch

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