Bug#1051166: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: breathe-doc
Version: 4.35.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is breathe-doc.

The build error was:

  Exception occurred while building, starting debugger:
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 
281, in build_main

  app.build(args.force_all, args.filenames)
File "/usr/lib/python3/dist-packages/sphinx/application.py", line 
341, in build

  self.builder.build_update()
File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", 
line 310, in build_update

  self.build(to_build,
File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", 
line 325, in build

  with logging.pending_warnings():
File "/usr/lib/python3.11/contextlib.py", line 144, in __exit__
  next(self.gen)
File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 
218, in pending_warnings

  memhandler.flushTo(logger)
File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 
183, in flushTo

  logger.handle(record)
File "/usr/lib/python3.11/logging/__init__.py", line 1644, in handle
  self.callHandlers(record)
File "/usr/lib/python3.11/logging/__init__.py", line 1706, in 
callHandlers

  hdlr.handle(record)
File "/usr/lib/python3.11/logging/__init__.py", line 974, in handle
  rv = self.filter(record)
  ^^^
File "/usr/lib/python3.11/logging/__init__.py", line 830, in filter
  result = f.filter(record)
  
File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 
426, in filter

  raise exc
  sphinx.errors.SphinxWarning: 
/<>/documentation/source/specific.rst:195:Invalid C++ 
declaration: Expected identifier in nested name. [error at 0]


^
  > /usr/lib/python3/dist-packages/sphinx/util/logging.py(426)filter()
  -> raise exc
  (Pdb)
  make[3]: *** [Makefile:56: html] Error 2

I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages breathe-doc depends on:
ii  libjs-mathjax2.7.9+dfsg-1
ii  libjs-sphinxdoc  5.3.0-7

breathe-doc recommends no packages.

breathe-doc suggests no packages.

-- no debconf information

breathe_4.35.0-2.xz
Description: application/xz

Bug#1051165: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: libstxxl-doc
Version: 1.4.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is libstxxl-doc.

The build error was:

  ! LaTeX Error: File `topics.tex' not found.

  Type X to quit or  to proceed,
  or enter new name. (Default extension: tex)

  Enter file name:
  ! Emergency stop.
  

  l.211 \input{topics}
  ^^M
  !  ==> Fatal error occurred, no output PDF file produced!
  Transcript written on refman.log.

I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libstxxl-doc depends on:
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1

libstxxl-doc recommends no packages.

libstxxl-doc suggests no packages.

-- no debconf information

libstxxl_1.4.1-3.xz
Description: application/xz

Bug#1051162: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: netcdf-doc
Version: 1:4.9.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is netcdf-doc.

The build error was:

  /<>/docs/dispatch.md:392: error: Unexpected 
subsubsection command found inside section! (warning treated as error, 
aborting now)
  make[3]: *** [docs/CMakeFiles/doc_all.dir/build.make:74: 
docs/CMakeFiles/doc_all] Error 1


I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

netcdf_1:4.9.2-1.xz
Description: application/xz

Bug#1051156: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: seqan-raptor-doc
Version: 3.0.1+ds-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is seqan-raptor-doc.

The build error was:

  xelatex refman
  This is XeTeX, Version 3.141592653-2.6-0.95 (TeX Live 
2023/Debian) (preloaded format=xelatex)

  restricted \write18 enabled.
  entering extended mode
  (./refman.tex
  LaTeX2e <2023-06-01>
  L3 programming layer <2023-06-05>

  make[2]: *** [Makefile:12: refman.pdf] Error 1

I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

seqan-raptor_3.0.1+ds-3.xz
Description: application/xz

Bug#1051155: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: wxpython-tools
Version: 4.2.1+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 5 failed and one is wxpython-tools.

The build error was:

  Running command: etg
  "/usr/bin/python3.11" etg/_core.py --sip --nodoc
  "/usr/bin/python3.11" etg/_html2.py --sip --nodoc
  "/usr/bin/python3.11" etg/_xml.py --sip --nodoc
  "/usr/bin/python3.11" etg/_xrc.py --sip --nodoc
  "/usr/bin/python3.11" etg/_richtext.py --sip --nodoc
  "/usr/bin/python3.11" etg/_stc.py --sip --nodoc
  "/usr/bin/python3.11" etg/_grid.py --sip --nodoc
  "/usr/bin/python3.11" etg/_msw.py --sip --nodoc 


  "/usr/bin/python3.11" etg/_propgrid.py --sip --nodoc
  "/usr/bin/python3.11" etg/_dataview.py --sip --nodoc
  "/usr/bin/python3.11" etg/_glcanvas.py --sip --nodoc
  Traceback (most recent call last):
File "/<>/etg/_glcanvas.py", line 137, in 
  run()
File "/<>/etg/_glcanvas.py", line 49, in run
  etgtools.parseDoxyXML(module, ITEMS) 


File "/<>/etgtools/__init__.py", line 91, in parseDoxyXML
  item = module.addElement(element)
^^
File "/<>/etgtools/extractors.py", line 1576, in 
addElement

  self.addElement(node)
File "/<>/etgtools/extractors.py", line 1547, in 
addElement

  item = EnumDef(element, inClass)
^
File "/<>/etgtools/extractors.py", line 1185, in __init__
  self.extract(element) 


File "/<>/etgtools/extractors.py", line 1189, in extract
  super(EnumDef, self).extract(element)
File "/<>/etgtools/extractors.py", line 65, in extract
  if '::' in self.name:
^
  TypeError: argument of type 'NoneType' is not iterable

I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wxpython-tools depends on:
ii  python3   3.11.4-5+b1
ii  python3-wxgtk4.0  4.2.1+dfsg-1

wxpython-tools recommends no packages.

wxpython-tools suggests no packages.

-- no debconf information

wxpython4.0_4.2.1+dfsg-1.xz
Description: application/xz

Bug#1051154: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: libcaca-dev
Version: 0.99.beta20-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is libcaca-dev.

The build error was:

  The control sequence at the end of the top line
  of your error message was never \def'ed. If you have
  misspelled it (e.g., `\hobx'), type `I' and the correct
  spelling (e.g., `I\hbox'). Otherwise just continue,
  and I'll forget about whatever was undefined.

  ! TeX capacity exceeded, sorry [text input levels=15].
  \tabu@textbar ...ar \m@ne \scantokens {\def \:{|}}
\expandafter 
\endgroup \ex...

  l.46 \begin{DoxyParams}{Parameters}
^^M
  If you really absolutely need more capacity,
  you can ask a wizard to enlarge me.


  Here is how much of TeX's memory you used:
  18690 strings out of 477695
  304727 string characters out of 5831649
  1925759 words of memory out of 500
  38172 multiletter control sequences out of 15000+60
  560241 words of font info for 97 fonts, out of 800 for 9000
  14 hyphenation exceptions out of 8191
  101i,15n,117p,1820b,797s stack positions out of 
1i,1000n,2p,20b,20s

  !  ==> Fatal error occurred, no output PDF file produced!
  make[3]: *** [Makefile:663: stamp-latex] Error 1

I attach the full build log.

Paolo


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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcaca-dev depends on:
ii  libcaca0   0.99.beta20-3
ii  libslang2-dev  2.3.3-3

libcaca-dev recommends no packages.

libcaca-dev suggests no packages.

-- no debconf information

libcaca_0.99.beta20-3.xz
Description: application/xz

Bug#1015864: doxygen: diff for NMU version 1.9.4-3.1

[Paolo Greppi]

Hi Adrian,

Il 15/10/22 14:30, Adrian Bunk ha scritto:

Control: tags 1015864 + patch
Control: tags 1015864 + pending

Dear maintainer,

I've prepared an NMU for doxygen (versioned as 1.9.4-3.1) and uploaded
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian


thanks for the NMU. I'll let it go through and afterwards import it back 
into the salsa git repo for reference.


Paolo

Bug#1000932: doxygen: diff for NMU version 1.9.1-2.1

[Paolo Greppi]

Il 15/07/22 00:23, Sebastian Ramacher ha scritto:

On 2022-07-14 16:23:16 +0200, Paolo Greppi wrote:
...
ACK, I've canceled the NMU. Please consider that doxygen is a key
package and thus effectively keeping llvm-toolchain-11 in testing. A
timely fix for this issue would be much appreciated.

Cheers


Many thanks. I have prepared the new version with a fix for your issue 
(https://salsa.debian.org/debian/doxygen) and started a "fast" ratt job 
(https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.1-1_amd64%20partial).


This will take a few days to compete, so far we're at 22% of the 
progress and 8% of packages fail on the first pass, but all are probably 
false positives.


If all goes well I should be able to upload by Friday.

Paolo

Bug#1000932: doxygen: diff for NMU version 1.9.1-2.1

[Paolo Greppi]

Hi Sebastian!

Il 14/07/22 11:22, Sebastian Ramacher ha scritto:

Control: tags 1000932 + patch
Control: tags 1000932 + pending

Dear maintainer,

I've prepared an NMU for doxygen (versioned as 1.9.1-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers


thanks for the quick patch; alas your fix will break this logic:
https://salsa.debian.org/debian/doxygen/-/blob/master/debian/rules#L23
which was contributed by Norbert Lange to fix 
https://bugs.debian.org/945427.


At this point I am unsure what effects this may cause, I only vaguely 
remember that the Clang_DIR and LLVM_DIR env vars plug into cmake somehow.


So I'd propose to skip this NMU, as I'd rather address this as part of 
the new upstream release (https://bugs.debian.org/1013636).
With each upstream release, I usually run massive archive rebuilds with 
ratt which helps pinpoint which of the ~700 paackages that 
reverse-build-dep on doxygen might fail when the new version is pushed 
through.


Having said that, if you feel confident this will not break too many 
things, feel free to let it go.


Otherwise I'm more than happy if you are inspired to contribute in any 
way to doxygen maintenance; for me the preferred way is by means of 
Merge Requests on salsa.


MfG,

Paolo

P.S. I also tried reviving the salsa gitlab CI:
https://salsa.debian.org/debian/doxygen/-/commits/bugfix/sramacher/1000932 
but ATM the pipeline is failing for unrelated reasons:

https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/358

Bug#1012021: [Pkg-javascript-devel] 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.

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

Bug#977814: should be fixed with clazy 1.9-3

[Paolo Greppi]

Hi I see "pass" for clazy/1.9-3 with llvm-toolchain-11/1:11.0.1-2:
https://ci.debian.net/packages/c/clazy/testing/amd64/

I also tried this here on unstable and the autopkgtest did pass.

Can you check and if confirmed as fixed close this bug?

Thanks,

Paolo

Bug#975931: should be fixed with pocl 1.6 ?

[Paolo Greppi]

pocl 1.6-3 has migrated to testing on 2021-01-13, and upstream declares that v1.6 
includes "Support for Clang/LLVM 11".

Can you try your reproducer now ?

Thanks

Paolo

Bug#979007: Processed: retitle and set severity to critical

[Paolo Greppi]

Dear Melvin,

Il 14/01/21 13:51, Melvin Vermeeren ha scritto:

Hi Paolo,

On Thursday, 14 January 2021 10:28:32 CET Paolo Greppi wrote:

Doh I had not seen this: https://bugs.debian.org/976227
Let me put both the future Debian maintainer and the current upstream
maintainer in Cc.


Thanks for the CC. I'm currently finalising some unrelated work so if all goes
according to plan I'll have the Debian packaging updated before the end of the
month. Still some uncertainty with handling the uploads though.

The patch you found should indeed fix FTBFS, there have been no other changes
for compatibility since Breathe 4.24.0. It's probably a good idea for this to
be released as a quick update if there is some form of time pressure on this.

Thanks,



as I wrote earlier, this FTBFS is blocking the new version of doxygen (1.9.1)
from entering testing / bullseye.

So the urgency is given by the upcoming freeze:
https://lists.debian.org/debian-devel-announce/2021/01/msg2.html

If you intend to take over maintenance of berathe, please prepare the new
upload and get it sponsored. FWIW I have given you maintainer access to my
fork on salsa.

Paolo

Bug#979007: Processed: retitle and set severity to critical

[Paolo Greppi]

Il 14/01/21 09:40, Sebastian Ramacher ha scritto:

...
The package is orphaned. If you a fix for it, please upload it.

Best



Doh I had not seen this: https://bugs.debian.org/976227
Let me put both the future Debian maintainer and the current upstream 
maintainer in Cc.

I am a DM and currently maintain among other things doxygen.
I have no urge to pick up breathe, and I can't upload the NMU myself or sponsor 
some else's.

But I have created a MR to the current repo with just the upstream patch 
imported:
https://salsa.debian.org/sramacher/breathe/-/merge_requests/1

Salsa CI (https://salsa.debian.org/salsa-ci-team/pipeline) is active in my repo 
and most tests have passed:
https://salsa.debian.org/paolog/breathe/-/pipelines/218933

This is blocking the new minor version of doxygen from entering testing.
Please push the fix through soon !

Paolo

Bug#979007: Processed: retitle and set severity to critical

[Paolo Greppi]

Hi Sebastian,

Il 09/01/21 11:41, Sebastian Ramacher ha scritto:

Control: severity -1 serious
...

No, critical is not the correct severity for FTBFS bugs. That's serious.


Sorry my fault.

I just added a "forwarded upstream" link, it is possible that just by applying 
the patch provided by upstream fixes the issue.

You can import the github patch like this (may require adjustments and adding 
some DEP-3 tags):
wget 
https://github.com/michaeljones/breathe/commit/41d520e86cb96fba276b7bd3ec0d35e6b4734de3.patch
 -O debian/patches/41d520e86cb96fba276b7bd3ec0d35e6b4734de3.patch

This is blocking the new minor version of doxygen from entering testing.

Paolo

Bug#977781: [Pkg-javascript-devel] 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

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

Bug#976495: also happens on amd64, should be worked around by 1.8.20-5 but the real fix will come with 1.8.20-6

[Paolo Greppi]

Hi Lucas (is it you, or a bot?), thanks for the new bug report about doxygen 
1.8.20-4 FTBFS on arm64:
https://bugs.debian.org/976495

I had noticed this issue yesterday and worked around it with 1.8.20-5 but the 
real fix will come with 1.8.20-6, thanks to a tip from Norbert Preining:
https://bugs.debian.org/976405#10

It would be interesting to know when you last run the archive rebuild on arm64 
or amd64, because it's not clear since when this error happens.

Paolo

Bug#976081: [Pkg-javascript-devel] 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

Bug#973741: [Pkg-javascript-devel] 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

Bug#973741: [Pkg-javascript-devel] 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

Bug#972952: [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

Bug#969313: doxygen: fails to parse long configuration files from standard input

[Paolo Greppi]

Package: doxygen
Version: 1.8.19-1
Severity: serious

when doxygen is invoked with the "-" parameter, it does not always do what is 
advertised in the doxygen manpage ("If - is used for configName doxygen will 
read from standard input")

due to a buffer size limit, only 4096 characters of the configuration file from 
standard input are read in and the rest is discarded

also see #969142

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

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

Versions of packages doxygen depends on:
ii  libc6  2.31-3
ii  libclang-cpp9  1:9.0.1-14
ii  libclang1-91:9.0.1-14
ii  libgcc-s1  10.2.0-5
ii  libllvm9   1:9.0.1-14
ii  libstdc++6 10.2.0-5
ii  libxapian301.4.17-1

doxygen recommends no packages.

Versions of packages doxygen suggests:
pn  doxygen-doc
pn  doxygen-gui
ii  doxygen-latex  1.8.19-1
ii  graphviz   2.42.2-4

-- no debconf information

Bug#950675: upstream does support doxygen-latex, but ...

[Paolo Greppi]

Hi Simon, thanks for revving the conversation on this bug. I'll summarize below 
my points.

Il 20/08/20 11:08, Simon McVittie ha scritto:
> On Wed, 05 Feb 2020 at 11:56:16 +0100, Paolo Greppi wrote:
> ...
> smcv
> 

- in general printable documentation is less relevant now than it used to be

- but some people may still need it, so doxygen-latex is useful in general, it 
mostly works fine, and we should try to keep it in Debian

- occasionally packages that build printable documentation (PDF or PS) with 
doxygen-latex have tripped (and will trip in the future) on obscure bugs in 
latex or doxygen or doxygen-latex or some-fancy-latex-plugin

- when this happens, I'll try to address it with the help of upstream, the 
latex maintainer and the latex community, but it may take a long time to fix or 
may be practically impossible to fix (because it's a messy tangle of old 
software, or because some-fancy-latex-plugin is no more supported, or some 
other obscure reason)

- when that takes really too long, on a case-by-case basis, and as a last 
resort, I would suggest the maintainers of those specific packages to 
(temporarily) drop PDF/PS documentation and only produce HTML docs, or to work 
with their upstream to switch to other PDF/PS generation toolchains as was 
suggested by Dimitri

In conclusion, I'll downgrade this bug to non-RC and if Aurelien is OK, I 
propose to close it.

Paolo

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

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

Bug#943423: troubles generating refman.pdf

[Paolo Greppi]

Hi,

CCfits fails to generate refman.pdf on Debian unstable with doxygen 1.8.16 and 
pdflatex from texlive-latex-base 2019.20191208.

To reproduce:

  wget https://heasarc.gsfc.nasa.gov/fitsio/CCfits/CCfits-2.5.tar.gz
  tar xf CCfits-2.5.tar.gz 
  cd CCfits/
  ./configure
  make docs
  make -C latex

output:

  make: *** [Makefile:8: refman.pdf] Error 1

I attach refman.log

For more background: https://bugs.debian.org/943423

Thanks !

Paolo


refman.log.xz
Description: application/xz

Bug#943423: workaround

[Paolo Greppi]

Hi,

sorry for the trouble and not being able to help: I am a latex noob !

As a workaround (while we reach a consensus on the future of doxygen-latex, or 
some latex guru pops up and provides a solution) I suggest that you disable the 
generation of /usr/share/doc/libccfits-doc/refman.pdf.gz and drop the build 
dependency on doxygen-latex.

Paolo

Bug#950675: upstream does support it, but ...

[Paolo Greppi]

According to:
grep-dctrl -n -w -F Build-Depends,Build-Depends-Indep -s Package doxygen-latex 
/var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Sources | sort | 
uniq | wc
there are 60 packages that build-depend on doxygen-latex in sid.

The last time I run a full rebuild of build dependents from doxygen:
https://lists.debian.org/debian-devel/2019/10/msg00260.html
10 packages were failing, all of them on latex issues.

We can assume that of the 60 packages that build-depend on doxygen latex, 
probably 17% FTBFS.
That's a lot, but I would not say that doxygen-latex is totally broken.

Nor would I say that it is not supported by upstream anymore: of 1863 issues 
open upstream, 145 match on "latex", and I know for sure they are being worked 
upon (as was the one with longtabu that caused so many more failures).

The issue with doxgen-latex is that both doxygen and latex are old, and the 
latter carries a few flaky plugins / dependencies.
As always when integrating two software products, the total trouble is the 
product of the troubles caused by each of them.

So the maintainer of doxygen is not going to unilaterally ask for removal of 
doxygen-latex and break 50 more packages out of the blue.

Having said all that, I was tempted myself to open an issue upstream on 
"dropping support for latex output”.
Personally I have never found any use for the bulky PDF files produced by 
doxyen-latex + pdflatex, the html doxygen output is more practical and easier 
to browse on any device. And nobody is supposed to print those nowadays !

So what shall we do with this ?

Paolo

Bug#947364: please address this bug

[Paolo Greppi]

Hi !

this is blocking migration of libglvnd from 1.1.0-1 to 1.3.0-5, which in turn
is blocking migration of qtbase-opensource-src from 5.12.5+dfsg-2 to
5.12.5+dfsg-5, which in turn is blocking doxygen (that's where this hits me !).

I have verified that libgl-dev 1.3.0-5 indeed breaks the 3depict build.

It seems that the d/control file should be fixed similarly to this commit:
https://salsa.debian.org/xorg-team/lib/libglvnd/commit/cdfd0513bcf80c120332211cc89da1ff0be1204d

Actually upstream README says: "GL/ contains code for libGL. This is a wrapper
around libGLdispatch and libGLX" so libgl-dev could be made to depend on
libglvnd-dev and libglx-dev (latter will pull in libx11-dev), exactly as libgl1
depends on libglvnd0 and libglx0.

Thanks,

Paolo

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

Bug#947117: reproducible

[Paolo Greppi]

Thanks for reporting !

Can be patched by adding libegl-dev to the build deps, but I'd wait of the Qt 
gurus find a better way to fix it.

Paolo

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

Bug#943623: I got this too with libclang-9-dev 9.0.0-2 for libclangTooling.a

[Paolo Greppi]

See:
https://salsa.debian.org/debian/doxygen/-/jobs/393296

ar x /usr/lib/llvm-9/lib/libclangTooling.a
file *.o

AllTUsExecution.cpp.o:   LLVM IR bitcode
ArgumentsAdjusters.cpp.o:LLVM IR bitcode
CommonOptionsParser.cpp.o:   LLVM IR bitcode
CompilationDatabase.cpp.o:   LLVM IR bitcode
Execution.cpp.o: LLVM IR bitcode
FileMatchTrie.cpp.o: LLVM IR bitcode
FixIt.cpp.o: LLVM IR bitcode
GuessTargetAndModeCompilationDatabase.cpp.o: LLVM IR bitcode
InterpolatingCompilationDatabase.cpp.o:  LLVM IR bitcode
JSONCompilationDatabase.cpp.o:   LLVM IR bitcode
RefactoringCallbacks.cpp.o:  LLVM IR bitcode
Refactoring.cpp.o:   LLVM IR bitcode
StandaloneExecution.cpp.o:   LLVM IR bitcode
Tooling.cpp.o:   LLVM IR bitcode

Thanks for all your work !

Paolo

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

Bug#934458: missing python-xdg ?

[Paolo Greppi]

Seems the same as:
https://bugs.debian.org/901780

Try again after:

sudo apt install python-xdg

P.S. note that linkchecker-gui is not anymore in stable

Paolo

Bug#929829: [Pkg-javascript-devel] 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

Bug#924858: doxygen: FTBFS: make[4]: *** [doc/CMakeFiles/doxygen_pdf.dir/build.make:62: doc/CMakeFiles/doxygen_pdf] Error 1

[Paolo Greppi]

unreproducible here, relevant part:
...
make[4]: ingresso nella directory "/tmp/doxygen-1.8.13/build"
[100%] Generating Doxygen Manual PDF.
cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/cmake -E remove refman.tex
cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/cmake -E copy 
/tmp/doxygen-1.8.13/build/doc/doxygen_manual.tex .
cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/cmake -E copy 
/tmp/doxygen-1.8.13/build/doc/manual.sty .
cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/epstopdf 
/tmp/doxygen-1.8.13/doc/doxygen_logo.eps --outfile=doxygen_logo.pdf
cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/pdflatex -shell-escape 
doxygen_manual.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) 
(preloaded format=pdflatex)
 \write18 enabled.
entering extended mode
(./doxygen_manual.tex
LaTeX2e <2018-12-01>

cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/makeindex doxygen_manual.idx
...

Paolo

Bug#921779: Bug#919413: cascade of FTBFS

[Paolo Greppi]

Hi Dominique, see below

Il 14/02/2019 15:16, Dominique Dumont ha scritto:

On Tuesday, 12 February 2019 16:54:12 CET Andreas Tille wrote:

I'm
not sure how to deal with the jquery.js one since this is potentially an
issue with lots of dependencies - I remember discussions about this
which I did not followed.

Fortunately, jquery is available as a Debian package.

We had a similar issue with libmojolicious-perl. This package now:
- removes jquery from source tarball [1] using debian/copyright Files-excluded 
parameter
- depends on libjs-jquery
- provides a symlink to Debian's query instead of the regular jquery file using
   debian/libmojolicious-perl.links file [2]

HTH

[1] 
https://salsa.debian.org/perl-team/modules/packages/libmojolicious-perl/blob/master/debian/copyright#L7
[2] 
https://salsa.debian.org/perl-team/modules/packages/libmojolicious-perl/blob/master/debian/libmojolicious-perl.links


I 'm afraid we will not be able to avoid embedding jquery in doxygen, 
because it makes a weird use of it.

The matter has been nicely put down by the former maintaners, see:
https://salsa.debian.org/paolog-guest/doxygen/blob/master/debian/README.jquery

Paolo

Bug#921356: [Pkg-javascript-devel] Bug#921356: Not suitable for buster, package probably unmaintained

[Paolo Greppi]

This is used in node-ws (popcon 92)

Paolo

Bug#921369: [Pkg-javascript-devel] Bug#921369: Not suitable for buster, package probably unmaintained

[Paolo Greppi]

This is used in: flashproxy (popcon 25), node-d3-request (popcon 2), 
node-xmlhttprequest-ssl (popcon 14)

Paolo

Il 04/02/19 17:35, Mike Gabriel ha scritto:
> Package: node-xmlhttprequest
> Version: 1.6.0-1
> Severity: serious
> 
> Dear all,
> 
> In 2016/12 I removed my name from this package's Uploaders: field. It
> hasn't been touch sinced then and seems unmaintained.
> 
> Due to this, the package might not be suitable for the Debian buster
> release. This needs to be checked by someone with more involvement in
> Javascript packaging than me. Thanks!
> 
> light+love,
> Mike
> 
> 
> -- System Information:
> Debian Release: 9.7
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages node-xmlhttprequest depends on:
> ii  nodejs  4.8.2~dfsg-1
> 
> node-xmlhttprequest recommends no packages.
> 
> node-xmlhttprequest suggests no packages.
> 
> -- no debconf information
> 

Bug#921301: starpu: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: starpu
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
mv: cannot stat 'latex/refman.pdf': No such file or directory

Paolo

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

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

Bug#921299: caffe: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: caffe
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo

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

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

Bug#921300: frobby: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Package: frobby
Version: 0.9.0-5
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo

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

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

Versions of packages frobby depends on:
ii  libc6  2.28-5
ii  libgcc11:8.2.0-16
ii  libgmp10   2:6.1.2+dfsg-4
ii  libgmpxx4ldbl  2:6.1.2+dfsg-4
ii  libstdc++6 8.2.0-16

frobby recommends no packages.

frobby suggests no packages.

-- no debconf information

Bug#921298: libstxxl: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: libstxxl
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo


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

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

Bug#921297: qevercloud: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: qevercloud
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo

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

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

Bug#921295: wcslib: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: wcslib
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found. popcon = 569

Paolo

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

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

Bug#921296: ccfits: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: ccfits
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
make[2]: *** [Makefile:8: refman.pdf] Error 1

Paolo

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

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

Bug#921293: hwloc: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Package: hwloc
Version: 1.11.12-1
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo

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

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

Versions of packages hwloc depends on:
ii  libc6  2.28-5
ii  libcairo2  1.16.0-2
ii  libhwloc5  1.11.12-1
ii  libice62:1.0.9-2
ii  libsm6 2:1.2.2-1+b3
ii  libtinfo6  6.1+20181013-1
ii  libx11-6   2:1.6.7-1

hwloc recommends no packages.

hwloc suggests no packages.

-- no debconf information

Bug#921294: fltk1.3: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: fltk1.3
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
cp: cannot stat 'latex/refman.pdf': No such file or directory

Paolo

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

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

Bug#888903: [Pkg-javascript-devel] Bug#888903: Bug#888903: 888903

[Paolo Greppi]

Il 31/01/19 12:52, Jonas Smedegaard ha scritto:
> ...
> I suggest this way forward:
> 
>  1) Release node-js-beautify to unstable with no executable at all
>  2) Release node-js-beautify to experimental adding python package
>  3) Release node-js-beautify to unstable when 1) is in testing
> 
> I am quite busy elsewhere today, so if others can handle 1) it would be 
> great!
> 
>  - Jonas

Hi, I'll tackle 1. soon.
Watch out for the RFS

Paolo

Bug#920982: deal.ii: FTFBFS with doxygen 1.8.15 draft package

[Paolo Greppi]

Source: deal.ii
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413
https://salsa.debian.org/paolog-guest/doxygen/-/jobs/107680/artifacts/browse/debian/output/

and it FTBFS with this error:

# Replace links to external html resources by local links:
sed -i -e 
's#"https://www.dealii.org/images/steps/developer/\(step[_-].*\)"#"images/\1"#g'
 \
-e 's#"https://zenodo.org/badge/DOI/10.5281/#"images/#g' \
debian/tmp/usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/step_*.html
sed: can't read 
debian/tmp/usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/step_*.html: No 
such file or directory

it seems easy to fix by replacing step_ with step- here:
https://salsa.debian.org/science-team/deal.ii/blob/master/debian/rules#L60

Paolo

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
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

Bug#888903: [Pkg-javascript-devel] Bug#888903: jsbeautifier, node-js-beautify: both ship /usr/bin/js-beautify

[Paolo Greppi]

Il 31/01/19 01:15, Jérémy Lal ha scritto:
> ...
> Hi,
> 
> i find it funny that no one even tried to solve this bug:
> both packages (python-jsbeautifier, node-js-beautify)
> have the same upstream !
> The solution here is to provide two dpkg-alternative to
> /usr/bin/js-beautify.
> 
> It's blocking postcss, it would be nice to quickly fix this.
> 
> Jérémy

I had proposed an ever quicker fix:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-January/030590.html
which is still on my todo list. What do you think of that ?

A more complex (but nicer) alternative would be to have single source generate 
both the js and python package.

Currently they have the same homepage, but different upstream tarballs.
python-jsbeautifier watches pypi:
https://salsa.debian.org/debian/python-jsbeautifier/blob/debian/master/debian/watch
whereas we watch github:
https://salsa.debian.org/js-team/node-js-beautify/blob/master/debian/watch

Another difficulty is that python-jsbeautifier is at version 1.6.4, whereas 
node-js-beautifyis at 1.7.5.
In any case both packages could be updated to 1.8.9 which is the current 
non-beta version.

Paolo

Bug#884155: show be fixed in unstable & testing

[Paolo Greppi]

chai 4.2 has landed in testing, and all tests pass.
can this be closed now ?

Paolo

Bug#892656: even more tests fail with version 2.0.2

[Paolo Greppi]

Il 13/01/19 16:52, Paul Gevers ha scritto:
> user debian-rele...@lists.debian.org
> usertags 884543 bsp-2019-01-nl-venlo
> thanks
> 
> On Mon, 23 Apr 2018 14:36:00 +0200 Paolo Greppi 
> wrote:
>> So I'd propose we go straight for option #3 (downgrade node-is-descriptor to 
>> 1.0).
>> Can you do that please ?
> 
> Is this what needs to happen? Should this be packaged:
> https://github.com/jonschlinkert/is-descriptor/archive/1.0.2.tar.gz ?
> 
> Paul
> Sent from the BSP in Venlo

Hi Paul, seems like npm registry now has is-descriptor 3.0.0:
https://www.npmjs.com/package/is-descriptor

but even define-property 2.0.2 still wants is-descriptor 1.0.2:
https://github.com/jonschlinkert/define-property/blob/master/package.json#L27

Now that we consider acceptable to embed tiny node modules (and is-descriptor 
certainly is tiny) we have two options:
1. (old #3) downgrade node-is-descriptor to 1.0.2
2. remove node-is-descriptor 2.0.0 and embed is-descriptor 1.0.2 into 
node-define-property

Paolo

Bug#895316: node-once repo on salsa

[Paolo Greppi]

FYI, I have manually migrated the git repo of node-once from:
https://alioth-archive.debian.org/git/collab-maint/node-once.git.tar.xz
to:
https://salsa.debian.org/js-team/node-once

I skipped all repos on collab-maint during the mass migration in April last 
year:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2018-April/025850.html
because my paolog-guest account had no write access to those

Paolo

Bug#867943: this is fixed by upstream in 8.0.12

[Paolo Greppi]

https://dev.mysql.com/doc/relnotes/workbench/en/wb-news-8-0-12.html

Changes in MySQL Workbench 8.0.12 (2018-07-27, General Availability)

...

Functionality Added or Changed

...

libgnome-keyring was depreciated and replaced with libsecret in this release on 
Linux platforms. Some users with existing stored passwords will be prompted to 
enter a password after upgrading. (Bug #27635281, Bug #89898, Bug #20291538, 
Bug #75345)

Bug#878337: [Pkg-javascript-devel] Bug#878337: Remove the package?

[Paolo Greppi]

Il 31/07/2018 17:07, Julien Puydt ha scritto:
> Hi,
> 
> is there any hope for this package? At one point node-source-map will need to 
> be updated.
> 
> For now I have a RC bug on node-source-map to remind me not to update it too 
> fast, but it's a bit unfair : the problem doesn't stem from node-source-map 
> if node-grunt-contrib-concat is abandoned...
> 
> jpuydt on irc.debian.org

Development is abandoned, but it's actively used.
Stats from yarnpkg.com rate it in the top five downdloaded grunt-contrib-* 
modules:

grunt-contrib-watch: 1 M downloads in the last 30 days
grunt-contrib-clean 995.9 k
grunt-contrib-copy 958.5 k
grunt-contrib-uglify 870.3 k
grunt-contrib-concat 720.5 k
grunt-contrib-jshint 612 k
grunt-contrib-cssmin 560.5 k
grunt-contrib-less 373.1 k
...

Grunt itself is 2.1 M.

source-map is much more popular (79 M downloads in the last 30 days)

Paolo

Bug#898997: fix

[Paolo Greppi]

This fixes the issue:

sudo apt install python-dnspython

That package should be added to the dependencies.

Paolo

Bug#834915: tentative fix

[Paolo Greppi]

Hi and thanks for your thorough testing.

My explanation is that for certain filesystem / CPU speed combinations, the
temp.track() option (turned on on line 7) cleans up the temporary file as
soon as it receives the .end() call, and faster than the assert on file
existence on line 58 can pass.

Hoping to prevent that, I have attempted a fix (not yet uploaded) that reverts
the assert and the .end() function call.

So can you please try the 0.8.3-2 version found on salsa
https://salsa.debian.org/js-team/node-temp
on your autobuilders ?

Thanks,

Paolo

Bug#900032: [Pkg-javascript-devel] Help with a RC bug in one of my package

[Paolo Greppi]

Il 26/05/2018 21:33, Bastien ROUCARIES ha scritto:
> Hi,
> 
> I am clueless about #900032 ...
> 
> I found a bug and pushed it due to build profile but the empty doc is strange
> 
> It will be empty only on upgrade (install will create the symlink). I
> use dpkg-maintscript-helper so normally dir to symlink should work
> 
> Bastien

>From what I can see, you want to install docs only for binary libjs-mocha and 
>add a symlink for mocha, using dh_installdocs --link-doc
As per CAVEAT 1 in man dh_installdocs, since the previous version was built 
without this option, you enabled a "dir to symlink" migration by providing a 
"debian/package.maintscript" file:
https://salsa.debian.org/js-team/node-mocha/blob/master/debian/mocha.maintscript

According to https://codesearch.debian.net/search?q=link-doc, this has never 
been used for a node-* package before, so the pkg-javascript-devel list may not 
be right rigth place where to ask ..
As for me, I have no clue.
Is there a way you can test these dh_* wizardry manually so that you can check 
what's going on step by step ?
Alternatively, can you frop the 4.1.0+ds1-1 version and revert back to not 
using --link-doc ?

BTW I think there's something wrong with the repo:

debcheckout node-mocha
cd node-mocha   
gbp buildpackage -us -uc
...
dpkg-source: error: cannot read 
node-mocha/debian/patches/0004-use-relative-path-in-doc.patch: No such file or 
directory
...

Paolo

Bug#897156: [Pkg-javascript-devel] Bug#897156: node-cache-base: FTBFS and Debci failure with node-is-extendable 1.0.1-1

[Paolo Greppi]

Il 29/04/2018 09:29, Adrian Bunk ha scritto:
> Source: node-cache-base
> Version: 0.8.4-1
> Severity: serious
> 
> https://ci.debian.net/packages/n/node-cache-base/unstable/amd64/
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-cache-base.html
> 
> ...
>   39 passing (460ms)
>   5 failing
> 
>   1) cache-base
>.union()
>  should union a string value:
>  TypeError: union-value expects the first argument to be an object.
>   at Function.unionValue (/usr/lib/nodejs/union-value/index.js:10:11)
>   at Cache.union (index.js:111:11)
>   at Context. (test/test.js:69:11)
>   at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:354:21)
>   at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
>   at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:442:10)
>   at /usr/lib/nodejs/mocha/lib/runner.js:560:12
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:356:14)
>   at /usr/lib/nodejs/mocha/lib/runner.js:366:7
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:290:14)
>   at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:334:5)
> 
>   2) cache-base
>.union()
>  should union multiple string values:
>  TypeError: union-value expects the first argument to be an object.
>   at Function.unionValue (/usr/lib/nodejs/union-value/index.js:10:11)
>   at Cache.union (index.js:111:11)
>   at Context. (test/test.js:74:11)
>   at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:354:21)
>   at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
>   at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:442:10)
>   at /usr/lib/nodejs/mocha/lib/runner.js:560:12
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:356:14)
>   at /usr/lib/nodejs/mocha/lib/runner.js:366:7
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:290:14)
>   at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:334:5)
> 
>   3) cache-base
>.union()
>  should union multiple arrays:
>  TypeError: union-value expects the first argument to be an object.
>   at Function.unionValue (/usr/lib/nodejs/union-value/index.js:10:11)
>   at Cache.union (index.js:111:11)
>   at Context. (test/test.js:81:11)
>   at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:354:21)
>   at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
>   at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:442:10)
>   at /usr/lib/nodejs/mocha/lib/runner.js:560:12
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:356:14)
>   at /usr/lib/nodejs/mocha/lib/runner.js:366:7
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:290:14)
>   at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:334:5)
> 
>   4) cache-base
>.union()
>  should union nested string values:
>  TypeError: union-value expects the first argument to be an object.
>   at Function.unionValue (/usr/lib/nodejs/union-value/index.js:10:11)
>   at Cache.union (index.js:111:11)
>   at Context. (test/test.js:88:11)
>   at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:354:21)
>   at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
>   at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:442:10)
>   at /usr/lib/nodejs/mocha/lib/runner.js:560:12
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:356:14)
>   at /usr/lib/nodejs/mocha/lib/runner.js:366:7
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:290:14)
>   at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:334:5)
> 
>   5) cache-base
>.union()
>  should union and uniquify arrays:
>  TypeError: union-value expects the first argument to be an object.
>   at Function.unionValue (/usr/lib/nodejs/union-value/index.js:10:11)
>   at Cache.union (index.js:111:11)
>   at Context. (test/test.js:95:11)
>   at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:354:21)
>   at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
>   at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:442:10)
>   at /usr/lib/nodejs/mocha/lib/runner.js:560:12
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:356:14)
>   at /usr/lib/nodejs/mocha/lib/runner.js:366:7
>   at next (/usr/lib/nodejs/mocha/lib/runner.js:290:14)
>   at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:334:5)
> 
> 
> 
> make[1]: *** [debian/rules:13: override_dh_auto_test] Error 5

Thanks for finding this one so quick !

I remember testing all rdepends of node-is-extendable prior to the RFS:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2018-April/025848.html

And indeed all 5 passed:
- node-clone-deep
- node-extend-shallow
- node-mixin-deep
- node-object.omit
- node-union-value.

But node-cache-base is a reverse dependency of node-union-value so meta/build 
did not test it !

Version 2.0.2 which is in the VCS (and was on hold till node-base 1.0.1-1 could 
be 

Bug#892656: even more tests fail with version 2.0.2

[Paolo Greppi]

Il 12/04/2018 06:19, Pirate Praveen ha scritto:
> 
> 
> On April 12, 2018 2:48:32 AM GMT+05:30, Paolo Greppi <paolo.gre...@libpf.com> 
> wrote:
>> Normally you'd expect to fix bugs with a new version, in this case
>> while trying to update node-define-property 1.0.0-1 -> 2.0.2 the
>> failing tests actually increased from 1 to 4.
>>
>> What puzzled me was that no tests fail on upstream's CI (travis), which
>> also tests nodejs version 8.
>>
>> Turns out that we have upgraded node-is-descriptor to version 2.0.0,
>> but the npm registry only has 1.0.2.
>>
>> I have forwarded the issue upstream, and I expect upstream to answer
>> that define-property correctly pins the major version of is-descriptor
>> with ^1.0.2 (https://docs.npmjs.com/misc/semver), stating that it won't
>> work with 2.x.
>>
>> ^1.0.2 should be translated with >= 1.0.2 && < 2.0.0 but we can't
>> encode that in debian/control.
>>
>> So how can we check reverse dependencies for this type of issues in the
>> future ?
>>
>> Paolo
> 
> build-and-upload script from ruby-team/meta can help if we have enabled 
> tests. If we used that, then is-descriptor 1.0 -> 2.0 update would notify the 
> failure before upload. But its likely we added is-descriptor 2.0 directly.
> 
> The best choice is upstream updating their dependency. Second choice is we 
> update and send merge request.
> 
> As a worse case, we can downgrade node-is-descriptor to 1.0 if we have no 
> other reverse dependency or embed 1.0 in node-define-property.
> 

Upstream closed the issue I reported:
https://github.com/jonschlinkert/define-property/issues/3
so that rules out option #1.

I have checked and in Debian we have no other dependent than 
node-define-property:

apt-cache rdepends node-is-descriptor
node-is-descriptor
Reverse Depends:
  node-define-property

whereas on npm registry there are 5 dependents listed:
- react-native-handcheque-engine
- dk_2018_1_1
- @ngxvoice/ngx-voicelistner
- define-property
- vue-size-tracker
none of which has ITP/RFP.

So I'd propose we go straight for option #3 (downgrade node-is-descriptor to 
1.0).
Can you do that please ?

Paolo

Bug#892656: even more tests fail with version 2.0.2

[Paolo Greppi]

Normally you'd expect to fix bugs with a new version, in this case while trying 
to update node-define-property 1.0.0-1 -> 2.0.2 the failing tests actually 
increased from 1 to 4.

What puzzled me was that no tests fail on upstream's CI (travis), which also 
tests nodejs version 8.

Turns out that we have upgraded node-is-descriptor to version 2.0.0, but the 
npm registry only has 1.0.2.

I have forwarded the issue upstream, and I expect upstream to answer that 
define-property correctly pins the major version of is-descriptor with ^1.0.2 
(https://docs.npmjs.com/misc/semver), stating that it won't work with 2.x.

^1.0.2 should be translated with >= 1.0.2 && < 2.0.0 but we can't encode that 
in debian/control.

So how can we check reverse dependencies for this type of issues in the future ?

Paolo

Bug#886120: thanks for the info

[Paolo Greppi]

With my previous message I was trying to understand your purpose with your bug 
report, not to demonstrate anything nor to dismiss it.

Adding the new info you provided, the chain of events triggered by your actions 
would be:
1) = as above
2) = as above
3) = as above
4) since doxygen is a “key package”, when the times are ripe the Release Team 
will likely mark this bug as buster-ignore
4) (let’s stick to this peculiar numbering system) but at that point ctpp2-doc 
is still FTBFSing so its maintainer will get back the hot potato, last minute.
Please confirm I got it right this time.

Additionally, I would appreciate your comments on this:
https://salsa.debian.org/paolog-guest/doxygen/wikis/home

P.S. FYI I intend to adopt this package, but I haven't yet.

Bug#886120: doxygen = scapegoat ?

[Paolo Greppi]

@kilobyte, let me see if I can understand your purpose with this bug report.

What happened is:
1) you find a serious bug in ctpp2 (popcon: 14)
2) you decide it's RC
3) it's doxygen fault so you reassign it to doxygen (popcon: 8381), and it 
stays RC

Now let's look at the effect of all this:
1) doxygen is currently orphaned (https://bugs.debian.org/888580)
2) therefore nobody will take care of this unless someone adopts it
3) the average Johanna trying to decide whether she should adopt it will be 
repelled by this RC bug and the perspective that anybody anytime can file RC 
bugs because any obscure package fails to build and it's doxygen fault
4) consequently doxygen will not make it to buster
4) ctpp2-doc is also dropped from stable, and all other packages that depend on 
doxygen for building, which if I am not mistaken are 443:

grep-dctrl -FBuild-Depends doxygen -sPackage /var/lib/apt/lists/*Sources | wc
443 8868612

Is that your wish ?

Paolo

Bug#861515: unreproducibile

[Paolo Greppi]

Hi,

this seems now to have gone away by itself,
possibly thanks to the upgrade from nodejs 4.x to 8.x:
I don't see any error on the buildds, and it works without the patch on my x86 
VM here.

So I have reset the repo to the debian/1.0.0-2 tag, and moved the patch
to a separate branch (wip/paolog/skip_test) in case we need it later.

@Adam, if you have access to an armhf test machine, you could try yourself on 
that too.

I'll wait a bit more before I close this one and the upstream bug.

Paolo

Bug#865892: reproducible

[Paolo Greppi]

This is easily reproducible: just apt remove node-asnyc, and try the build.

I am working on the fix while at the same time updating to 2.0.1

Paolo

Bug#863934: fix

[Paolo Greppi]

According to upstream (https://github.com/felixge/node-dateformat/issues/21) 
"dateformat() doesn't really play well with timezones since the javascript 
Date() object itself doesn't really play well with timezones."

We should be content with fixing the tests for the GMT timezone using the trick 
suggested by kapouer 
(https://github.com/felixge/node-dateformat/issues/41#issuecomment-286419133):

TZ=GMT mocha -R spec

Paolo

Bug#861515: node-grunt-contrib-copy FTBFS on armhf i386

[Paolo Greppi]

Hi all,

re. https://bugs.debian.org/861515, since we haven't got any reply from 
upstream for almost a month 
(https://github.com/gruntjs/grunt-contrib-copy/issues/291), I have updated 
node-grunt-contrib-copy to simply skip the failing test: 
https://anonscm.debian.org/git/pkg-javascript/node-grunt-contrib-copy.git/tree/debian/changelog

I have checked that the patch works when tests are run during the build 
(debian/tests/control) on i386 architecture. I have no way to test on armhf.

With autopkgtest, the patch is missing and it fails.

So if the patch is OK, please sponsor this upload else this package and its 
dependencies (node-inquirer and node-rx) will be autoremoved from testing on 
2017-06-12.
Else I am open to suggestions.

Paolo

Bug#861515: reproducibile here

[Paolo Greppi]

I have set up an i386 debci lxc testbed with:

  debci_arch=i386 debci setup

then confirmed that the lxc container has indeed been created:

  lxc-ls --fancy
  NAME  STATE   AUTOSTART GROUPS IPV4 IPV6 
  adt-sid-amd64 STOPPED 0 -  --
  adt-sid-i386  STOPPED 0 -  --

and run the test suite from the source package in the archive with:

  adt-run --user debci --output-dir /tmp/output-dir node-grunt-contrib-copy --- 
lxc --sudo adt-sid-i386

it fails with:

✖ copy - timestamp_equal

AssertionError: 1457124645257 == 1457124645000
  at Object.equal (/usr/lib/nodejs/nodeunit/lib/types.js:83:39)
  at Object.exports.copy.timestamp_equal 
(/tmp/autopkgtest-virt-lxc.shared.wv8ud5o5/downtmp/build.iwX/node-grunt-contrib-copy-1.0.0/test/copy_test.js:92:10)
  at Object. (/usr/lib/nodejs/nodeunit/lib/core.js:236:16)
  at Object. (/usr/lib/nodejs/nodeunit/lib/core.js:236:16)
  at /usr/lib/nodejs/nodeunit/lib/core.js:236:16
  at Object.exports.runTest (/usr/lib/nodejs/nodeunit/lib/core.js:70:9)
  at /usr/lib/nodejs/nodeunit/lib/core.js:118:25
  at /usr/lib/nodejs/nodeunit/deps/async.js:513:13
  at iterate (/usr/lib/nodejs/nodeunit/deps/async.js:123:13)
  at /usr/lib/nodejs/nodeunit/deps/async.js:134:25
  at /usr/lib/nodejs/nodeunit/deps/async.js:515:17
  at Immediate._onImmediate (/usr/lib/nodejs/nodeunit/lib/types.js:146:17)
  at processImmediate [as _immediateCallback] (timers.js:396:17)


AssertionError: 1457124645257 == 1457124645000
  at Object.equal (/usr/lib/nodejs/nodeunit/lib/types.js:83:39)
  at Object.exports.copy.timestamp_equal 
(/tmp/autopkgtest-virt-lxc.shared.wv8ud5o5/downtmp/build.iwX/node-grunt-contrib-copy-1.0.0/test/copy_test.js:93:10)
  at Object. (/usr/lib/nodejs/nodeunit/lib/core.js:236:16)
  at Object. (/usr/lib/nodejs/nodeunit/lib/core.js:236:16)
  at /usr/lib/nodejs/nodeunit/lib/core.js:236:16
  at Object.exports.runTest (/usr/lib/nodejs/nodeunit/lib/core.js:70:9)
  at /usr/lib/nodejs/nodeunit/lib/core.js:118:25
  at /usr/lib/nodejs/nodeunit/deps/async.js:513:13
  at iterate (/usr/lib/nodejs/nodeunit/deps/async.js:123:13)
  at /usr/lib/nodejs/nodeunit/deps/async.js:134:25
  at /usr/lib/nodejs/nodeunit/deps/async.js:515:17
  at Immediate._onImmediate (/usr/lib/nodejs/nodeunit/lib/types.js:146:17)
  at processImmediate [as _immediateCallback] (timers.js:396:17)


✔ copy - timestamp_changed

FAILURES: 2/17 assertions failed (234ms)

AFAICT this seems related to this upstream PR: 
https://github.com/gruntjs/grunt-contrib-copy/pull/268, that claims to have 
fixed a similar problem

I'll try to bring this to the attention of upstream over there.

Bug#860634: fix for node-grunt-contrib-copy RC bug

[Paolo Greppi]

Hi team there is a RC bug on node-grunt-contrib-copy, I have provided a fix and 
uploaded that to alioth.

I have tested with pkg-ruby-extras/build and tested the reverse deps (node-rx) 
too.

These two packages have an impressive popcon count of ... 7+5 ! But anyway 
please someone sponsor the upload

Cheers,

Paolo 

Bug#860634: reproducible here

[Paolo Greppi]

This is easy to reproduce on stretch from the root of a source package against 
the currently installed package.

Just make sure the tmp directory created during the build process is not 
present:
  make -f debian/rules clean

or just:
  rm -rf tmp

then run the tests in the local environment (that's the easiest path as per 
https://ci.debian.net/doc/file.MAINTAINERS.html):
  adt-run --output-dir /tmp/output-dir ./ --- null

The reason for the failure is that when tests are run during the build process, 
they are run via the debian/rules override_dh_clean which does:
  rm -rf tmp
  mkdir -p tmp
  grunt copy
  nodeunit

whereas when they are run by adt-run and hence by debci the tests run as 
declared in debian/tests/control per DEP-8 spec, i.e. by running nodeunit 
straight.

Interestingly this package has no Testsuite: autopkgtest or XS-Testsuite: 
autopkgtest entries in the source stanza in debian/control, but debci runs the 
tests anyway.

A fix is to make both tests run via the supplied ./debian/tests/run_tests 
script.

Bug#853035: mmmh

[Paolo Greppi]

In the log you attached this line:

  [0m Error: timeout of 5000ms exceeded

looks different from what you report in the bug:

  [0m Error: timeout of 1ms exceeded

The test suite is run by upstream (and by us) with this command:

  mocha -t 5000 -b -R spec test/index

this is where the timeout of 5 s comes from.

Not sure if we should worry about this one.
And above all: I'm clueless at why it should fail.

Where did it fail ?
What is special with your test environment ?

Paolo

Bug#848749: set a different $HOME for build-time tests

[Paolo Greppi]

As per this comment in the Pkg-javascript-devel mailing list:
https://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2016-December/016725.html

I have changed the approach to set a different $HOME for build-time
tests. This should fix the build-time tests.

Paolo

Bug#848749: disable build-time tests

[Paolo Greppi]

Il looks like node-expand-tilde returns a directory which does not exist
(sbuild-nonexistent) at this line in
node-fined/test/utils/get-userhome-file.js:
var userHomeDir = expandTilde('~');

This in turn triggers the exception in the next line:
var userHomeFiles = fs.readdirSync(userHomeDir);

Google tells me that in an sbuild chroot HOME is indeed set to
/sbuild-nonexistent.

Node-expand-tilde has build and autopkgtests turned on, but they pass
because they do not check that the returned dir exist, only that they
are consistent !

I guess we have no choice but to disable build tests. I have done so in
the repo on alioth, autopkgtests are still on (although I had to disable
a few also related to tilde expansion).

Paolo

Bug#847353: [Pkg-javascript-devel] Bug#847353: Bug#846961: recent update of libjs-jquery-ui broke gitlab

[Paolo Greppi]

On 07/12/2016 14:54, Pirate Praveen wrote:
> On Wed, 7 Dec 2016 17:12:12 +0530 Pirate Praveen  wrote:
>> I tested the patch, but that was not enough., I still get the same error :(
> 
> I tested using embedded copy of jquery-ui in ruby-jquery-ui-rails and it
> is working. So it is not an upstream issue, but debian specific issue.
> 
> We now have grunt in the archive and we can try using that instead of
> custom build steps in debian/rules that is prone to errors like this and
> hard to maintain and support.
> 
> Though when I tried using grunt, I got this error,
> 
> jqueryui$ grunt
> Loading "Gruntfile.js" tasks...ERROR
>>> TypeError: grunt.util._.pluck is not a function
> 
> package.json mentions grunt 0.4.5 so we should update Gruntfile to use
> grunt 1.0.1

I wonder if this is relevant ?

https://github.com/gruntjs/grunt-contrib-clean/issues/90

Paolo




signature.asc
Description: OpenPGP digital signature

Bug#846228: It seems upstream is patching it

[Paolo Greppi]

https://github.com/joblib/joblib/issues/413
(scroll to the comment by  karandesai-96 on 2016-12-04)

Paolo



signature.asc
Description: OpenPGP digital signature

Bug#834918: test failures

[Paolo Greppi]

This was already observed with version 0.12.7, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753220 which was
closed because unreproducible.

The problem is also known to upstream
(https://github.com/bottlepy/bottle/issues/618,
https://github.com/bottlepy/bottle/issues/891), the author of the
package states that "the server tests are unstable (and should probably
be disabled in debian builds because they are more integration than unit
tests)"

One way of patching it would be to pass the "fast" option ("Skip server
adapter tests") to the testall.py script in the Makefile, line 33.








signature.asc
Description: OpenPGP digital signature

Bug#839075: confirmed on stretch as of today

[Paolo Greppi]

I installed python3-jsonschema on clean debian stretch amd64 lxc
container and could reproduce the issue

installing python3-pkg-resources fixes it:

# apt-get install python3-jsonschema
...

# jsonschema
Traceback (most recent call last):
  File "/usr/bin/jsonschema", line 5, in 
from pkg_resources import load_entry_point

# apt-get install python3-jsonschema python3-pkg-resources
...

# jsonschema
usage: jsonschema [-h] [-i INSTANCES] [-F ERROR_FORMAT] [-V VALIDATOR]
schema

JSON Schema Validation CLI

positional arguments:
  schemathe JSON Schema to validate with

optional arguments:
  -h, --helpshow this help message and exit
  -i INSTANCES, --instance INSTANCES
a path to a JSON instance to validate (may be
specified multiple times)
  -F ERROR_FORMAT, --error-format ERROR_FORMAT
the format to use for each error output message,
specified in a form suitable for passing to
str.format, which will be called with 'error'
for each
error
  -V VALIDATOR, --validator VALIDATOR
the fully qualified object name of a validator
to use,
or, for validators that are registered with
jsonschema, simply the name of the class.



signature.asc
Description: OpenPGP digital signature

Bug#783553: numdiff: debian/copyright file is not complete

[Paolo Greppi]

Hi the issue of switching the numdiff docs to the GPL was raised with
upstream 2 years ago, and Ivano preferred to stick to GFDL.

The actual issue with the incomplete debian/copyright file is also
reported by lintian as warning file-without-copyright-information.
Currently 272 packages cause this warning, and about 10 files have
an undocumented license.

The easiest way forward is to complete the copyright file which I am
going to do ASAP.

Thanks for reporting !

Paolo

On 28/04/2015 00:14, Francesco Poli (wintermute) wrote:
 Package: numdiff
 Version: 5.8.1-1
 Severity: serious
 Justification: Policy 4.5
 
 Hello and thanks for maintaining this interesting package in Debian!
 
 After taking a look at bug #709492, I noticed that the debian/copyright
 file for numdiff/5.8.1-1 [1] seems to be incomplete, as it does not
 mention the GFDL-licensed files. There are at least some files
 under the GFDL [2].
 
 [1] https://tracker.debian.org/media/packages/n/numdiff/copyright-5.8.1-1
 [2] for instance:
 https://sources.debian.net/src/numdiff/5.8.1-1/docs/numdiff.txi/
 
 Please update the debian/copyright file to correctly document the
 licensing status of the package.
 
 Or, even better, could the upstream developer(s) be persuaded to
 re-license the documentation under the same terms as the rest
 of the package (GPL)?
 This would be an optimal solution, since, for example, it would
 allow any contributor to use material copied from the program
 source code, when improving the documentation.
 Moreover, it would simplify the debian/copyright file!   ;-)
 
 Bye and thanks for your time.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#709492: R: Re: Bug#709492: Numdiff doc is non free

[Paolo Greppi]

All versions of GFDL are not compatible with Debian. Please switch the
numdiff docs to the GPL or if you want to stick to GFDL, then skip the
optional invariant sections clause.

We will then repackage 5.6.2 with the new numdiff doc license.

Thanks, Paolo

On 23/05/2013 22:23, ivpr...@libero.it wrote:
 Hi all,
 
 It is not a problem for me to remove the optional invariant sections clause.
 Next month I am going to release a new version of Numdiff with this change.
 Would it help if I switched from GFDL 1.2 to GFDL 1.3 or later?
 Kind regards,
 
 Ivano Primi


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#709492: Numdiff doc is non free

[Paolo Greppi]

Hi there, it turned out the GFDL is incompatible with debian policies,
see here:
http://www.debian.org/vote/2006/vote_001

Would it be possible to switch the numdiff docs to a different license
such as the GNU General Public License ? Or at least to not include the
optional invariant sections clause ?

Otherwise we may be forced to remove those parts from the debian package ...

TIA

Paolo

On 23/05/2013 17:54, Bastien ROUCARIÈS wrote:
 Package: src:numdiff
 Severity: serious
 user: debian...@lists.debian.org
 usertags: gfdl-invariant
 severity: serious
 
 At least :
 docs/numdiff.html
 docs/numdiff.info
 docs/numdiff.txi
 docs/numdiff.txt
 are under the gfdl with invariant section and thus non free.
 
 Please repackage, or ask upstream to relicence
 


-- 
==
 Paolo Greppi
   +39 320 8960642
paolo.gre...@libpf.com
 http://www.libpf.com
==


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org