Bug#1033482: also here
Hi, I have tripped onto this while following blindly the automatic sbuild setup using sbuild-debian-developer-setup described here: https://wiki.debian.org/sbuild#Automatic_setup_using_sbuild-debian-developer-setup Alberto's workaround (sudo apt install -t bookworm-backports debootstrap) worked for me. Paolo
Bug#1051166: FTBFS with doxygen 1.9.8
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
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
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
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
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
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#1040864:
Hi Andreas! Il 11/07/23 22:27, Andreas Hasenack ha scritto: So I took a stab at backporting the upstream patches, and there are many: $ grep ^commit debian/patches/doc-build-with-newer-cairo-*.patch debian/patches/doc-build-with-newer-cairo-1.patch:commit c22ae5ed4ca8d7e5568be7d5a930ee388117703e debian/patches/doc-build-with-newer-cairo-2.patch:commit 9df76e22464a0b6302b7c1cda980a35b39185bc4 debian/patches/doc-build-with-newer-cairo-3.patch:commit 293d3beaf03c8798899332b7a948b32c4a3da3e9 debian/patches/doc-build-with-newer-cairo-4.patch:commit 966d69c603b5a6ae22e3132b6ecc6a39b86e52ab debian/patches/doc-build-with-newer-cairo-5.patch:commit 7b2a6027775b0158304635a98de0f9b5672f163a debian/patches/doc-build-with-newer-cairo-6.patch:commit 8129939c312e4b5060042fdb93bd071b7b133381 debian/patches/doc-build-with-newer-cairo-7.patch:commit e002e293d9dc956a0634b3a4bcc8d93e655582d5 This looks risky. It's probably best to update to 1.9.7. What do you think? My WIP branch is at https://code.launchpad.net/~ahasenack/ubuntu/+source/doxygen/+git/doxygen/+ref/mantic-doxygen-cairo-compat many thanks for the timely heads-up and for the research. I think the best would be to just upgrade to 1.9.7. I'll take care. Paolo
Bug#1017504: Enabling large file support in doxygen
Hi! sorry for the long delay, at last I'm looking at incorporating your patch. It's now WIP here: https://salsa.debian.org/debian/doxygen Before I upload it to unstable, I was wandering: 1. what would be the easiest way to turn this on only for 32-bit builds? 2. what side effects can we expect? ~600 packages build-depend on doxygen, I would not want to break havoc 3. reading some threads about enabling large file support for all packages, I was scared by the issue of ABI breaking, are we 100% sure that we will not trigger that? Thanks for you comments, Paolo
Bug#1015864: doxygen: diff for NMU version 1.9.4-3.1
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#1016208: jenkins.debian.org: downloading artifacts from tests.reproducible-builds.org
Package: jenkins.debian.org X-Debbugs-Cc: paolo.gre...@libpf.com Severity: normal Hi, I am looking at the reproducible build results for doxygen: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/doxygen.html If I remember well, previously it was possible to download the build artifacts (i.e. doxygen-doc_1.9.4-2_all.deb ... maybe the build dirs ...) for the reference build and the perturbed build, so that I could run diffoscope here, compare PDF files etc. I ca'nt find these artifacts links anymore. Have they been moved or removed ? As a workaround, it would be nice to have a oneliner I can try at home to reproduce here the reproducible builds! Thanks, Paolo
Bug#1016050: sddm: intermittedly shows black page instead of login screen
Package: sddm
X-Debbugs-Cc: paolo.gre...@libpf.com
Version: 0.19.0-3
Severity: important
About 90% of the times after a fresh reboot, sddm shows a black page
with mouse pointer instead of the login screen.
The systemd sddm service is up and running. If I restart it on tty 1,
the login screen reappears.
I attach two extracts from journalctl -u sddm, one for a successful
boot, where the login screen was showed so that I could login
(success.log) and one for a non-successful boot (failure.log).
They are similar up to "Greeter session started successfully". But in
failure.log after that it says:
lug 25 17:25:50 localhost sddm[1442]: Greeter session started
successfully
lug 25 17:25:50 localhost.localdomain sddm-helper[1573]: [PAM]
Closing session
lug 25 17:25:50 localhost.localdomain sddm-helper[1573]: [PAM] Ended.
lug 25 17:25:50 localhost.localdomain sddm-helper[1573]:
pam_unix(sddm-greeter:session): session closed for user sddm
lug 25 17:25:50 localhost.localdomain sddm[1442]: Auth: sddm-helper
exited with 6
lug 25 17:25:50 localhost.localdomain sddm[1442]: Greeter stopped.
In that case at 17:27:21 I restarted the service ("Signal received:
SIGTERM") and then I could login.
In success.log after "Greeter session started successfully" it goes on with:
lug 26 06:54:27 localhost sddm[1503]: Greeter session started
successfully
lug 26 06:54:27 localhost sddm[1503]: Message received from greeter:
Connect
lug 26 06:54:38 localhost.localdomain sddm[1503]: Message received
from greeter: Login
lug 26 06:54:38 localhost.localdomain sddm[1503]: Reading from
"/usr/share/xsessions/plasma.desktop"
lug 26 06:54:38 localhost.localdomain sddm[1503]: Reading from
"/usr/share/xsessions/plasma.desktop"
lug 26 06:54:38 localhost.localdomain sddm[1503]: Session
"/usr/share/xsessions/plasma.desktop" selected, command:
"/usr/bin/startplasma-x11"
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM]
Starting...
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM]
Authenticating...
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM]
Preparing to converse...
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM]
Conversation with 1 messages
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]:
pam_kwallet5(sddm:auth): (null): pam_sm_authenticate
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM] returning.
lug 26 06:54:38 localhost.localdomain sddm[1503]: Authenticated
successfully
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]:
pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]:
pam_unix(sddm:session): session opened for user paolog(uid=1000) by (uid=0)
lug 26 06:54:38 localhost.localdomain sddm[1503]: Auth: sddm-helper
exited successfully
lug 26 06:54:38 localhost.localdomain sddm[1503]: Greeter stopped.
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]:
pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: Starting:
"/etc/sddm/Xsession \"/usr/bin/startplasma-x11\""
lug 26 06:54:38 localhost.localdomain sddm[1503]: Session started
So the difference is that in the second case sddm gets to "Message
received from greeter: Connect" and all goes well, whereas in the first
case that status is never reached because sddm-helper closes the PAM
session and bails out, causing the greeter to stop.
It looks to me as a race condition.
Probably the PAM system is not yet ready when sddm-helper tries to connect.
Paolo
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable'), (400, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-16-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sddm depends on:
ii adduser 3.118
ii debconf [debconf-2.0] 1.5.77
ii libc6 2.31-13+deb11u3
ii libgcc-s1 10.2.1-6
ii libpam0g1.4.0-9+deb11u1
ii libqt5core5a5.15.2+dfsg-9
ii libqt5dbus5 5.15.2+dfsg-9
ii libqt5gui5 5.15.2+dfsg-9
ii libqt5network5 5.15.2+dfsg-9
ii libqt5qml5 5.15.2+dfsg-6
ii libqt5quick55.15.2+dfsg-6
ii libstdc++6 10.2.1-6
ii libsystemd0 247.3-7
ii libxcb-xkb1 1.14-3
ii libxcb1 1.14-3
ii qml-module-qtquick2 5.15.2+dfsg-6
ii x11-common 1:7.7+22
ii xauth 1:1.1-1
ii xserver-xorg [xserver] 1:7.7+22
Versions of packages sddm
Bug#1015862: geos-bin: FTBFS with upcoming doxygen 1.9.4
Hi! thanks for the quick reaction. Il 22/07/22 18:01, Sebastiaan Couwenberg ha scritto: Control: tags -1 upstream Control: forwarded -1 https://github.com/libgeos/geos/issues/654 On 7/22/22 17:37, Paolo Greppi wrote: I am about to upload the current version of doxygen, before doing that I ran a quick scan of ~500 build-deps (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.4-1_amd64-partial) and found that this package was one of 4 that FTBFS. I don't see 1.9.4 in experimental, will you upload it there first? I've added a patch that should fix the issue by ignoring the (new) warning: https://salsa.debian.org/debian-gis-team/geos/-/commit/693b718e4b701ede6f28e94e9e9d2dcac67a8a6a But I cannot easily test it without 1.9.4 in experimental. Kind Regards, Bas I'd like to skip experimental and go to unstable by today or tomorrow. Also there are are deb files you can use as artifacts from the latest salsa CI run: https://salsa.debian.org/debian/doxygen/-/jobs/3014516/artifacts/browse/debian/output/ Paolo
Bug#1015865: liblog4c3: FTBFS with upcoming doxygen 1.9.4
Package: liblog4c3
Version: 1.2.4-2
Severity: important
File: /usr/share/doc/liblog4c3/copyright
Tags: ftbfs
X-Debbugs-Cc: paolo.gre...@libpf.com
Hello,
I am about to upload the current version of doxygen, before doing that I
ran a quick scan of ~500 build-deps
(https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.4-1_amd64-partial)
and found that this package was one of 4 that FTBFS.
The errors were:
Output written on refman.dvi (90 pages, 336368 bytes).
Transcript written on refman.log.
latex_count=%(LATEX_COUNT) ; \
while egrep -s 'Rerun (LaTeX|to get cross-references right|to get
bibliographical references right)' refman.log && [ $latex_count -gt 0 ] ;\
do \
echo "Rerunning latex" ;\
latex refman.tex ; \
latex_count=`expr $latex_count - 1` ;\
done
/bin/sh: 1: Syntax error: "(" unexpected
make[4]: *** [Makefile:30: refman.dvi] Error 2
The errors do not occur with the current version of doxygen (1.9.1). I
attach the build logs.
Paolo
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-16-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages liblog4c3 depends on:
ii libc6 2.33-7
ii libexpat1 2.4.8-1
liblog4c3 recommends no packages.
liblog4c3 suggests no packages.
-- no debconf information
1_9_1.log.xz
Description: application/xz
1_9_4.log.xz
Description: application/xz
Bug#1015861: bamtools: FTBFS with upcoming doxygen 1.9.4
Package: bamtools Version: 2.5.1+dfsg-10+b1 Severity: important Tags: ftbfs X-Debbugs-Cc: paolo.gre...@libpf.com Hello, I am about to upload the current version of doxygen, before doing that I run a quick scan of build-deps of doxygen (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.4-1_amd64-partial) and found that this package FTBFS with this error: mv: cannot stat 'docs/Doxyfile.bak': No such file or directory The error does not occur with the current version of doxygen (1.9.1). I attach the build logs. Paolo -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-16-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages bamtools depends on: ii libbamtools2.5.1 2.5.1+dfsg-10+b1 ii libc6 2.33-7 ii libgcc-s1 12.1.0-5 ii libjsoncpp25 1.9.5-4 ii libstdc++612.1.0-5 bamtools recommends no packages. bamtools suggests no packages. -- no debconf information 1_9_1.log.xz Description: application/xz 1_9_4.log.xz Description: application/xz
Bug#924040: next steps
I installed the package above and when I tried the archivebox command I got the same error about the missing atomicwrites module. This is easy to fix by adding lib/python3.9/site-packages/atomicwrites/__init__.py from https://pypi.org/project/atomicwrites/ 1.4.1 as debian/vendor/atomicwrites.py. A better way of vendoring dependencies would be to use gbp components, so that they are versioned, uscan looks for new versions etc. Another issue is that if I try to "archivebox add" an url I get these warnings: ! SINGLEFILE_BINARY: single-file (unable to detect version) ! READABILITY_BINARY: readability-extractor (unable to detect version) ! MERCURY_BINARY: mercury-parser (unable to detect version) Indeed the page is archived as (I have the recommended dep chromium): - Chrome > PDF - Chrome Screenshot - wget > HTML - Archive.org - Headers - Chrome > HTML - MEdia - Git But these fail: - Chrome > SingleFile - Readability - Mercury - Git (not sure why) Getting the first three to work would require installing the JS dependencies listed in package.json which is a mess. But after the atomicwrites fix the package seems to be usable as-is and worth uploading! Paolo
Bug#924040: 0.6.2
Hi! and thanks for your efforts to package archivebox. I have picked it up from there and tried to build the current version (0.6.2). For that I have refreshed the patches, here is a MR: https://salsa.debian.org/debian/archivebox/-/merge_requests/1 Feel free to pick up whatever you need from there. There is a test error: = test session starts == platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0 rootdir: /tmp/build-area/archivebox-0.6.2 plugins: django-3.5.1, sugar-0.9.4 collected 44 items / 1 error / 43 selected ERRORS ERROR collecting .pybuild/cpython3_3.9/build/tests/test_extractors.py _ ImportError while importing test module '/tmp/build-area/archivebox-0.6.2/.pybuild/cpython3_3.9/build/tests/test_extractors.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: ... archivebox/system.py:14: in from .vendor.atomicwrites import atomic_write as lib_atomic_write E ModuleNotFoundError: No module named 'archivebox.vendor.atomicwrites' === short test summary info ERROR tests/test_extractors.py Interrupted: 1 error during collection === 1 error in 0.60s === but this does not prevent the package to build (?). Anyway I m not familiar with this style of tracking only the debian dir in salsa (I normally use gbp and push the upstream sources as well). How can you enable salsa CI BTW ? Paolo
Bug#808641: duplicate of #818379
Thanks for your bug report. This is caused by doxygen not reporting dot failures, which is tracked at bug #818379. Paolo
Bug#1000932: doxygen: diff for NMU version 1.9.1-2.1
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#1001682: should be fixed by the upcoming 1.9.4 version
Hi! and thanks for reporting. I am in the process of packaging doxygen 1.9.4 and this issue seems to be fixed in that version. To test, I did this twice: cd `mktemp -d` git clone https://github.com/BYVoid/OpenCC cd OpenCC/ cd doc # no need to run cmake etc. just quickly generate the Doxyfile ... cp opencc.doxy.in Doxyfile sed -i 's/@CMAKE_SOURCE_DIR@/../g' Doxyfile sed -i 's/@OPENCC_VERSION/1.1.4/g' Doxyfile doxygen -u doxygen the compared the dirs: kdiff3 html/ ../../../tmp.bcQZ8jaXXy/OpenCC/doc/html While with 1.9.1 I get: with 1.9.4 I get: so the build path is not embedded anymore. If you have time to test yourself, you can try with this package here on unstable: https://salsa.debian.org/debian/doxygen/-/jobs/3001759/artifacts/browse/debian/output/ Paolo
Bug#235576: fixed in the current version, will close soon
I reproduced with the attached minimal example and no warning is printed. Upstream issue is also closed. Will now close. P. test.tar.xz Description: application/xz
Bug#216195: fixed in the current version, will close soon
I reproduced with the attached minimal example and no warning is printed. Upstream issue is also closed. Will now close. P. test.tar.xz Description: application/xz
Bug#818379: WARN_AS_ERROR=YES could be the solution
Since some time doxygen has a WARN_AS_ERROR config option: https://doxygen.nl/manual/config.html#cfg_warn_as_error Since version 1.9.1 or 1.9.2 if that is set to YES, graphviz's dot is absent but HAVE_DOT=YES is set, doxygen will stop and exit with status of 1 (upstream choose this opt-in way for enabling stricter error trapping so that users are not hit by unexpected failures). If we think we should be strict, we could set the default value of WARN_AS_ERROR to YES (we already deviate from upstream defaults overriding HAVE_DOT's default from 0 to 1). Do you think this would a valid solution for Debian? Paolo
Bug#1000932: doxygen: diff for NMU version 1.9.1-2.1
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
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
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#980316: about corepack and yarnpkg
I stumbled upon this thread related to packaging corepack for gentoo: https://github.com/nodejs/corepack/issues/76 We now have node 16 in experimental, but our package does not bundle corepack (as upstream does): https://packages.debian.org/experimental/amd64/nodejs/filelist I propose that we create a RFP/ITP for corepack separate from nodejs, with Conflicts: yarnpkg The corepack binary would install /usr/bin/yarnpkg pointing to the corepack shims; this would allow Debian users who "use different package manager versions across multiple projects" to happily install random binaries downloaded from the internet if they wish. If we agree that we (as a distribution) need specific versions of yarnpkg (for building other stuff, we need to keep one or more yarnpkg packages in Debian, all with Conflicts: corepack + each other. If we really want yarnpkg 1, according to my tests, the corepack route is useless: docker pull node:16 docker run -it --rm node:16 bash yarn -v # 1.22.15 # this downloads https://registry.npmjs.org/yarn/-/yarn-1.22.17.tgz # based on the versions / 1.22.17 / dist / tarball value in: # https://registry.yarnpkg.com/yarn/ corepack prepare yarn@1.22.17 --activate yarn -v # 1.22.15 corepack yarn -v # 1.22.17 ls -l /root/.node/corepack total 2 -rw-r--r-- 1 root root 63 Jan 9 18:33 lastKnownGood.json drwxr-xr-x 1 root root 14 Jan 9 18:13 yarn To "build" it quick and dirty we can download once and for all the same pre-built binary that corepack would download, extract it and symlink it to /usr/bin/yarnpkg (without shims); this package should go to contrib since it downloads stuff from the internet during the build, but would fix the issue of yarnpkg blocking the migration to webpack5 and removal of node-request. Or else keep alive the current version in main by just bundling into it webpack4 and node-request. If we really want a new yarnpkg3 package, corepack is also useless as it merely installs yarnpkg 1. The upstream recommended way of installing yarnpkg 3 (get yarn 1 with corepack then yarn init -2 (sic!)) just downloads the current pre-built binary (ATM https://repo.yarnpkg.com/3.1.1/packages/yarnpkg-cli/bin/yarn.js, 2199165 bytes) to .yarn/releases/yarn-3.1.1.cjs. AFAICT this does not integrate with the shared package manager versions stored in ~/.node/corepack. One way to "build" yarnpkg3 quick and dirty is to download once and for all the same pre-built binary that yarn init -2 would download, and symlink it to /usr/bin/yarnpkg (without shims). Or if we want it in main we should replicate the way upstream builds this yarn.js binary. Sorry for the long message, this is a mess! Paolo
Bug#1001532: [Pkg-javascript-devel] Bug#1001532: yarnpkg: yarnpkg --version cannot find @babel/runtime/helpers module
Il 11/12/21 18:29, Brian Thompson ha scritto: Package: yarnpkg Severity: important Dear Maintainer, After install yarnpkg for the first time and running `yarnpkg --version`, I got the following error: Error: Cannot find module '@babel/runtime/helpers/interopRequireWildcard' I expected the package to return its version. Thanks for reporting the issue. Unfortunately I can not reproduce it on any of my systems here. I also tried on a "clean" Debian stable install with: docker run -it --rm debian:bullseye bash apt update && apt install yarnpkg yarnpkg --version and I get: 1.22.10 I run the command under strace and it looks like indeed it does not find /usr/share/nodejs/yarn/node_modules/@babel/runtime/helpers/interopRequireWildcard.js, but it then proceeds to also try /usr/lib/x86_64-linux-gnu/nodejs/@babel/runtime/helpers/interopRequireWildcard.js (not here) and finally /usr/share/nodejs/@babel/runtime/helpers/interopRequireWildcard.js (this one is there). With: dpkg -S /usr/share/nodejs/@babel/runtime/helpers/interopRequireWildcard.js I find that interopRequireWildcard.js is installed by package node-babel7-runtime which is listed as a "dep" of yarnpkg here: https://packages.debian.org/bullseye/yarnpkg Is it possible that on your system you have installed some non-Debian node module that takes precedence over the ones installed by the Debian packages? Paolo
Bug#991544: closing rathen than merging
See https://bugs.debian.org/985857 Paolo
Bug#991544: [Pkg-javascript-devel] Bug#991544: please package bootstrap 5
Hi, Il 27/07/21 08:51, Daniel Baumann ha scritto: Package: twitter-bootstrap4 Hi, thanks a lot for maintaining bootstrap in Debian. Do you already have an ETA for bootstrap 5 (probably a new package in Debian I guess)? Regards, Daniel thanks for your request but twitter-bootstrap4 is no Debian package (it's libjs-bootstrap4) Anyway libjs-bootstrap5 has been requested before as a RFP proper, so I'll merge this one with the bug #985857. RFPs (Requests for Package) are the correct way of entering new package requests in Debian: https://wiki.debian.org/RFP As you can see there is no activity in #985857 yet, so it's basically up for anyone to pick it (we welcome new contributors ;-). Paolo
Bug#940704: I give up
Control: noowner -1 Control: tags -1 - pending Trying to make the upstream test suite, designed for jest 22, work with our jest 26 is tricky. Also some things defy intuition, i.e. I patch here: https://salsa.debian.org/js-team/node-yarnpkg/-/blob/wip/paolog/jest/debian/patches/20-jest-require-actual.diff#L26 and the autopkgtest baffles me: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1387234#L273 I have parked my work in the wip/paolog/jest branch. I'll release 1.22.10+~cs22.25.14-2 without the test suite FTMB, we can pick it up from there later. Paolo
Bug#981241: tracker.debian.org: please update uscan
Package: tracker.debian.org X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org Severity: important For yarnpkg: https://tracker.debian.org/pkg/node-yarnpkg tracker.debian.org reports: uscan had problems while searching for a new upstream version: unrecognized option ctype=nodejs The option was added with devscripts 2.20.5: https://lists.debian.org/debian-perl/2020/11/msg00047.html Please upgrade devscripts so that uscan works reliably for packages that use the option. BTW thanks for the excellent service! Paolo -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#940704: [Pkg-javascript-devel] Bug#940704: next error
Dear Xavier,
Il 27/01/21 06:30, Xavier ha scritto:
Le 27/01/2021 à 00:14, Paolo Greppi a écrit :
I fixed the error:
Cannot find module 'babel-preset-env'
but I am not sure if the fix is 100% right.
Now I get:
TypeError: Cannot read property 'mkdir' of undefined
5 | export default function(filename?: string):
Promise {
6 | return new Promise((resolve, reject) => {
> 7 | temp.mkdir(filename, function(err, path) {
I added node-temp in debian/tests/control Depends afetr jest, but that
did not help (it would have errored on require('temp') anyway).
I have then turned my attention at brushing up node-temp, see this
message to the js-team list:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052152.html
Hi,
fixed (patch for node-mkdirp ≥ 1), take a look at my changes
Fantastic job thanks!
I suggest that you also upload it - I am still a DM so I'd nee to bother
someone for sponsorship anyway.
The only comment I have is that the Salsa CI was already enabled, as I had set the Custom CI
config path to recipes/debian.yml@salsa-ci-team/pipeline in Settings -> CI/CD -> General
Pipelines as advised "If the base pipeline configuration fits your needs without further
modifications" here:
https://salsa.debian.org/salsa-ci-team/pipeline#basic-use
But now you have set it to debian/salsa-ci.yml and added that file, with the
same content as:
https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/recipes/debian.yml
so nothing changes.
Is there any reason why you prefer the debian/salsa-ci.yml way ?
Paolo
Bug#940704: next error
I fixed the error:
Cannot find module 'babel-preset-env'
but I am not sure if the fix is 100% right.
Now I get:
TypeError: Cannot read property 'mkdir' of undefined
5 | export default function(filename?: string): Promise {
6 | return new Promise((resolve, reject) => {
> 7 | temp.mkdir(filename, function(err, path) {
I added node-temp in debian/tests/control Depends afetr jest, but that did not
help (it would have errored on require('temp') anyway).
I have then turned my attention at brushing up node-temp, see this message to
the js-team list:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052152.html
Paolo
Bug#981105: RM: node-i18next-xhr-backend -- ROM; not used and deprecated upstream
Package: ftp.debian.org Severity: normal This package has low popcon (1), and according to upstream: https://github.com/i18next/i18next-xhr-backend it is "[deprecated] can be replaced with i18next-http-backend". The latter we already have in Debian: https://tracker.debian.org/pkg/node-i18next-http-backend The maintainer is the Debian Javascript Maintainers team of which I am part of. The original owner of the ITP (https://bugs.debian.org/969295) wrote to the js-team list that he does not "need it anymore since [he] replaced it with node-i18next-http-backend": https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052128.html Thanks, Paolo
Bug#940704: new error: Cannot find module 'babel-preset-env'
Hi, I think I fixed the error:
Cannot find module 'babel-plugin-transform-inline-imports-commonjs'
with this commit:
https://salsa.debian.org/js-team/node-yarnpkg/-/commit/d055e01b6d1a7f6fad6df2ccdf6d0f7d01ddcbc2
but the tests still fail, all with this new error:
FAIL __tests__/commands/licenses.js
● Test suite failed to run
Cannot find module 'babel-preset-env'
Require stack:
- /usr/share/nodejs/@babel/core/lib/config/files/plugins.js
- /usr/share/nodejs/@babel/core/lib/config/files/index.js
- /usr/share/nodejs/@babel/core/lib/index.js
- /usr/share/nodejs/babel-jest/build/loadBabelConfig.js
- /usr/share/nodejs/babel-jest/build/index.js
- /usr/share/nodejs/@jest/transform/build/ScriptTransformer.js
- /usr/share/nodejs/@jest/transform/build/index.js
- /usr/share/nodejs/jest-runtime/build/index.js
- /usr/share/nodejs/jest-runner/build/testWorker.js
- /usr/share/nodejs/jest-worker/build/workers/processChild.js
- Did you mean "@babel/env"?
89 |
90 | try {
> 91 | return require.resolve(standardizedName, {
|^
92 | paths: [dirname]
93 | });
94 | } catch (e) {
at resolveStandardizedName (../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:91:20)
at resolvePreset
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:48:10)
at loadPreset
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:67:20)
at createDescriptor
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:154:9)
at
../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:109:50
at Array.map ()
at createDescriptors
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:109:29)
at createPresetDescriptors
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:101:10)
see: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1373973
I tried the obvious fix in debian/tests/control:
-Depends: @, jest
+Depends: @, jest, node-babel-preset-env
but no change.
Paolo
Bug#980775: your initial example also fails with upstream
I tried using the docker "official image" for node: docker pull node docker run -it --rm node bash mkdir -p test/foo cd test yes '' | yarn init yarn add file:foo yields: yarn add file:foo yarn add v1.22.5 info No lockfile found. [1/4] Resolving packages... [2/4] Fetching packages... error /test@0.0.0: Name contains illegal characters info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command. you need to add the following as in my previous message: cd foo yes '' | yarn init cd .. P.
Bug#980775: patch
With this WIP patch: https://salsa.debian.org/js-team/node-yarnpkg/-/blob/master/debian/patches/18-uuid.diff I can do: rm -rf /tmp/test mkdir -p /tmp/test/foo cd /tmp/test yes '' | yarn init cd foo yes '' | yarn init cd .. yarn add file:foo and get: yarn add v1.22.10 info No lockfile found. [1/4] Resolving packages... [2/4] Fetching packages... [3/4] Linking dependencies... [4/4] Building fresh packages... success Saved lockfile. success Saved 1 new dependency. info Direct dependencies └─ foo@1.0.0 info All dependencies └─ foo@1.0.0 Done in 0.25s. Paolo
Bug#977814: should be fixed with clazy 1.9-3
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 ?
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
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
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
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#979551: [Pkg-javascript-devel] Bug#979551: node-babel7: update-alternatives set up fails
Il 08/01/21 11:35, Jonas Smedegaard ha scritto: Quoting Paolo Greppi (2021-01-08 08:46:36) I guess that's because the bullseye-slim image lacks the manpages. A Debian install with man pages excluded seems to be an unsupported system: Whatever hooks applied to do that trick should be extended to handle update-alternatives - not the packages providing alternatives nor the update-alternatives mechanism itself! If you disagree, then please try locate passages in Debian Policy to support your view. - Jonas Sorry I am not qualified to respond. Using Debian official images with docker/podman is a use case we should support as it is one significant way for Debian to stay relevant in this post-devops world. Also see: - https://hub.docker.com/_/debian/#Image_Variants - https://github.com/debuerreotype/debuerreotype/issues/10 Paolo
Bug#979551: node-babel7: update-alternatives set up fails
Package: node-babel7 Version: 7.12.11+~cs150.141.84-3 Severity: important Dear Maintainer, installing node-babel7 on official debian "bullseye-slim" docker image fails like this: docker pull debian:bullseye-slim docker run --rm -it debian:bullseye-slim apt update && apt install -y --no-install-recommends yarnpkg ... Setting up node-babel7 (7.12.11+~cs150.141.84-3) ... update-alternatives: using /usr/bin/babeljs-7 to provide /usr/bin/babeljs (babeljs) in auto mode update-alternatives: using /usr/bin/babeljs-7-external-helpers to provide /usr/bin/babeljs-external-helpers (babeljs-external-helpers) in auto mode update-alternatives: using /usr/bin/babeljs-7-node to provide /usr/bin/babeljs-node (babeljs-node) in auto mode update-alternatives: using /usr/bin/babeljs-7-parser to provide /usr/bin/babeljs-parser (babeljs-parser) in auto mode update-alternatives: error: alternative path /usr/share/man/man1/babeljs-7.1.gz doesn't exist dpkg: error processing package node-babel7 (--configure): installed node-babel7 package post-installation script subprocess returned error exit status 2 dpkg: dependency problems prevent configuration of yarnpkg: yarnpkg depends on node-babel7; however: Package node-babel7 is not configured yet. dpkg: error processing package yarnpkg (--configure): dependency problems - leaving unconfigured I guess that's because the bullseye-slim image lacks the manpages. BTW, why is node-babel7 a run-time dependency of yarnpkg ? Should it not just be a build-dep ? Paolo -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages node-babel7 depends on: ii node-browserslist 4.16.0+~cs5.4.69-1 ii node-chalk 4.1.0-1 ii node-commander 6.2.1-2 ii node-convert-source-map 1.7.0+~1.5.1-1 ii node-core-js3.8.1-1 ii node-debug 4.3.1+~cs4.1.5-1 ii node-esutils2.0.3-1 ii node-find-cache-dir 3.3.1-1 ii node-fs-readdir-recursive 1.1.0-1 ii node-glob 7.1.6+~7.1.3-1 ii node-globals13.5.0-1 ii node-js-tokens 6.0.0-1 ii node-jsesc 3.0.2-1 ii node-json5 2.1.3-2 ii node-lodash 4.17.20+dfsg+~cs8.31.170-1 ii node-make-dir 3.0.2-1 ii node-quick-lru 1.1.0-2 ii node-regenerator-runtime0.13.7-1 ii node-regenerator-transform 0.14.5-4 ii node-regexpu-core 4.7.1-1 ii node-resolve1.19.0+~cs5.20.8-2 ii node-semver 7.3.4-1 ii node-slash 3.0.0-1 ii node-source-map 0.7.0++dfsg2+really.0.6.1-4 ii node-source-map-support 0.5.19+ds+~0.5.3-1 ii node-to-fast-properties 3.0.1-1 ii node-v8flags3.2.0-1 ii nodejs 12.19.0~dfsg-1 node-babel7 recommends no packages. node-babel7 suggests no packages. -- no debconf information
Bug#979403: skopeo: Error loading trust policy: open /etc/containers/policy.json: no such file or directory
Package: skopeo Version: 1.2.0+dfsg1-2 Severity: important Dear Maintainer, I noticed that if skopeo is installed without buildah, a simple command such as: skopeo copy docker://busybox oci:busybox fails with: FATA[] Error loading trust policy: open /etc/containers/policy.json: no such file or directory as mentioned here: https://github.com/containers/skopeo/issues/181 this can be worked around by executing skopeo with a command-line option: skopeo --insecure-policy copy docker://busybox oci:busybox But /etc/containers/policy.json is installed by buildah, should skopeo recommend buildah ? Or should /etc/containers/policy.json be installed by a new package from which both skopeo and buildah depend ? Thanks, Paolo -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages skopeo depends on: ii libc6 2.31-6 ii libdevmapper1.02.1 2:1.02.173-1 ii libgpgme11 1.14.0-1+b2 skopeo recommends no packages. skopeo suggests no packages. -- no debconf information
Bug#979014: wxpython4.0: FTBFS with doxygen 1.9.0 from experimental
Il 02/01/21 02:51, Scott Talbert ha scritto: On Sat, 2 Jan 2021, Paolo Greppi wrote: The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.8.20 is 50 MB and contains 1812 files. The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.9.0 is 42 MB and contains 1583 files. I attach the list of contained files. This could well be a doxygen issue. Please let me know what you think about it. Thanks for the heads up. I think in this case it might be a bug in wxWidgets' Doyxfile, or at least I think I've found a simple way to fix it. I just need to do a full test. BTW, do you happen to know how to install just a single package from experimental when using sbuild? Scott According to the sbuild manpage the charm should be: --extra-repository="deb http://deb.debian.org/debian experimental main" but TBH I dont' use sbuild directly, I use ratt which in turn calls sbuild, and ratt takes as input a .changes file. So I build doxygen locally for sid and pass this .changes file to ratt. Here are the debs I used in case they may help you: https://www.libpf.com/doxygen_1.9.0.tar.xz Paolo
Bug#979014: wxpython4.0: FTBFS with doxygen 1.9.0 from experimental
Source: wxpython4.0 Severity: important Dear Maintainer, in a partial rebuild of the doxygen build dependencies against 1.9.0 from experimental: https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.0-1_amd64-partial this package failed to build with this error: Finished command: dox (0m14.759s) Running command: touch Finished command: touch (0.5s) Running command: etg "/usr/bin/python3.9" etg/_core.py --sip --nodoc "/usr/bin/python3.9" etg/_glcanvas.py --sip --nodoc "/usr/bin/python3.9" etg/_stc.py --sip --nodoc Unable to find xml file for ITEM: wxTextCtrl Tried: /root/d/wxpython4.0-4.0.7+dfsg/ext/wxWidgets/docs/doxygen/out/xml/classwx_text_ctrl.xml /root/d/wxpython4.0-4.0.7+dfsg/ext/wxWidgets/docs/doxygen/out/xml/structwx_text_ctrl.xml /root/d/wxpython4.0-4.0.7+dfsg/ext/wxWidgets/docs/doxygen/out/xml/wxTextCtrl Traceback (most recent call last): File "/root/d/wxpython4.0-4.0.7+dfsg/etg/_stc.py", line 243, in run() File "/root/d/wxpython4.0-4.0.7+dfsg/etg/_stc.py", line 151, in run mod = textctrl.parseAndTweakModule() File "/root/d/wxpython4.0-4.0.7+dfsg/etg/textctrl.py", line 32, in parseAndTweakModule etgtools.parseDoxyXML(module, ITEMS) File "/root/d/wxpython4.0-4.0.7+dfsg/etgtools/__init__.py", line 82, in parseDoxyXML raise DoxyXMLError(msg) etgtools.DoxyXMLError: Unable to find xml file for ITEM: wxTextCtrl Command '"/usr/bin/python3.9" etg/_stc.py --sip --nodoc' failed with exit code 1. Finished command: etg (0.688s) The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.8.20 is 50 MB and contains 1812 files. The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.9.0 is 42 MB and contains 1583 files. I attach the list of contained files. This could well be a doxygen issue. Please let me know what you think about it. I am not yet 100% sure that it makes sense to rush doxygen 1.9.0 to bullseye, but I might try, and if so, I'll increase the severity of this bug to serious. Paolo -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled 1.8.20.txt.xz Description: application/xz 1.9.0.txt.xz Description: application/xz
Bug#979011: forgot to attach the log file
libvigraimpex_1.11.1+dfsg-7.xz Description: application/xz
Bug#979011: libvigraimpex: FTBFS with doxygen 1.9.0 from experimental
Source: libvigraimpex Severity: important Dear Maintainer, in a partial rebuild of the doxygen build dependencies against 1.9.0 from experimental: https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.0-1_amd64-partial this package failed to build with this error: Postprocessing html files cd /<>/obj.x86_64-linux-gnu/docsrc && /usr/bin/python3 /<>/docsrc/makeFunctionIndex.py /<>/doc/vigra Traceback (most recent call last): File "/<>/docsrc/makeFunctionIndex.py", line 141, in generateFunctionIndex(functionList) File "/<>/docsrc/makeFunctionIndex.py", line 124, in generateFunctionIndex text = open(path + "/namespaces.html").read() File "/usr/lib/python3.9/codecs.py", line 322, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb3 in position 138922: invalid start byte I attach the full log. The namespaces.html file found in doc/vigra is 142804 bytes long (for reference, the one installed in /usr/share/doc/libvigraimpex-dev/html/namespaces.html by libvigraimpex-doc is 7535 bytes). I cheched with hexdump around position 138922 (hex 21EAA): ... 00021e60 3d 22 64 65 73 63 22 3e 43 6f 6d 70 75 74 61 74 |="desc">Computat| 00021e70 69 6f 6e 20 6f 66 20 57 69 67 6e 65 72 20 44 20 |ion of Wigner D | 00021e80 6d 61 74 72 69 78 20 2b 20 72 6f 74 61 74 69 6f |matrix + rotatio| 00021e90 6e 20 66 75 6e 63 74 69 6f 6e 73 20 69 6e 20 53 |n functions in S| 00021ea0 48 2c 56 48 20 61 6e 64 20 52 b3 20 3c 2f 74 64 |H,VH and R. .CWignerMatrixComputation of Wigner D matrix + rotation functions in SH,VH and R³ This text is extracted from include/vigra/wigner-matrix.hxx: ... 0b90 78 20 2b 20 72 6f 74 61 74 69 6f 6e 20 66 75 6e |x + rotation fun| 0ba0 63 74 69 6f 6e 73 20 0a 20 20 20 20 20 2a 20 20 |ctions . * | 0bb0 20 20 20 20 20 20 20 69 6e 20 53 48 2c 56 48 20 | in SH,VH | 0bc0 61 6e 64 20 52 b3 0a 20 20 20 20 20 2a 0a 20 20 |and R.. *. | 0bd0 20 20 20 2a 20 41 6c 6c 20 72 6f 74 61 74 69 6f | * All rotatio| ... The 0xb3 byte is present in your source, and doxygen merely moves it from one place to the other. You can either fix the byte in the source or file or fix the Python script to be more lax with Unicode errors. I am not yet 100% sure that it makes sense to rush doxygen 1.9.0 to bullseye, but I might try, and if so, I'll increase the severity of this bug to serious. Paolo -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#979007: breathe: FTBFS with doxygen 1.9.0 from experimental
Source: breathe
Severity: important
Dear Maintainer,
in a partial rebuild of the doxygen build dependencies against 1.9.0 from
experimental:
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.0-1_amd64-partial
this package failed to build with this error:
AssertionError
>
/<>/.pybuild/cpython3_3.9/build/breathe/renderer/sphinxrenderer.py(1781)visit_friendclass()
-> assert typ in ("friend class", "friend struct")
A similar error occurred while building liborcus.
I attach the full logs for both.
I am not yet 100% sure that it makes sense to rush doxygen 1.9.0 to bullseye,
but I might try, and if so, I'll increase the severity of this bug to serious.
Paolo
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
breathe_4.24.0-1.xz
Description: application/xz
liborcus_0.16.1-3.xz
Description: application/xz
Bug#940704: autopkgtests now failing
I have enabled he upstream test suite on salsa, it fails with many of these: FAIL __tests__/commands/install/integration.js ● Test suite failed to run Cannot find module 'babel-plugin-transform-inline-imports-commonjs' Require stack: ... See: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1287491 Not sure how to proceed .. Paolo
Bug#940704: some tests do pass
I have run jest in the yarnpkg source tree with:
jest --ci __tests__/
having this jest.config.js to disable failing tests:
module.exports = {
testURL: "http://localhost/;,
testPathIgnorePatterns: [
"/node_modules/",
"/__tests__/index.js",
"/__tests__/integration.js",
"/__tests__/lifecycle-scripts.js",
"/__tests__/pipe.js",
"/__tests__/commands/pack.js",
"/__tests__/commands/run.js",
"/__tests__/fixtures",
"/__tests__/reporters/_mock.js",
"/__tests__/commands/_helpers.js",
"/__tests__/_temp.js",
"/__tests__/__mocks__",
"/__tests__/commands/install/lockfiles.js"
]
}
result:
Test Suites: 1 skipped, 81 passed, 81 of 82 total
Tests: 15 skipped, 1116 passed, 1131 total
Snapshots: 111 passed, 111 total
Time:74.936s
Ran all test suites matching /__tests__\//i.
I think we can include it in the autopkgtest, later we can try to understand
why some tests are failing ..
Note:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-November/047062.html
Paolo
Bug#977781: [Pkg-javascript-devel] Bug#977781: Bug#977781: real issue is, it does not pull not-yet-cached modules
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
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#976405: texlive-latex-base: pdflatex command fails while building doxygen
Hi Hilmar, Il 09/12/20 23:44, Hilmar Preuße ha scritto: Control: reassign -1 src:doxygen ... As explained this issue is probably not related to changed in TL base, hence I'm reassigning to src:doxygen . For the other build failures, w/ docbook based documents I've opened Bug#976887 w/ criticality serious to make sure the new TL packages do not migrate to testing until the issue is sorted out. Hilmar well done ! Paolo
Bug#976405: also happens on amd64, should be worked around by 1.8.20-5 but the real fix will come with 1.8.20-6
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#976405: texlive-latex-base: pdflatex command fails while building doxygen
Hi Norbert, Il 04/12/20 23:29, Norbert Preining ha scritto: Hi Paolo, /usr/bin/pdflatex: Not writing to ../html/examples/group/latex//group__group2.aux (openout_any = p). make[4]: *** [doc/CMakeFiles/doxygen_pdf.dir/build.make:81: doc/CMakeFiles/doxygen_pdf] Error 1 Is this new? This should have happened already since long time ago. LaTeX etc now ensures to not write out of the current directory and its sub-directories, so writing to ../html is a no go, this is the setting openout_any = p From /usr/share/texlive/texmf-dist/web2c/texmf.cnf ** % Do we allow TeX \input or \openin (openin_any), or \openout % (openout_any) on filenames starting with `.' (e.g., .rhosts) or % outside the current tree (e.g., /etc/passwd)? % a (any): any file can be opened. % r (restricted) : disallow opening dot files % p (paranoid) : as `r' and disallow going to parent directories, and % restrict absolute paths to be under $TEXMFOUTPUT. openin_any = a openout_any = p ** This is not a new change, at least ... at least ... I can't remember, years? So I am very surprised that it would show up only now. Options are: - don't write to .. - use pdflatex -cnf-line="openout_any = r" (never tried it though) - temporarily set in /usr/local/share/texmf/web2c/texmf.cnf by adding the same openout definition Hope that helps Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 thanks for the tip ! Not sure why this surfaced only now ... anyway your 2nd option seems to fix it. I have also submitted the patch to doxygen upstream for review: https://github.com/doxygen/doxygen/issues/8226 If all goes well I'll upload doxygen 1.8.20-6 in a few days and this will be closed. Paolo
Bug#976405: texlive-latex-base: pdflatex command fails while building doxygen
Package: texlive-latex-base Version: 2020.20201203-1 Severity: important Dear Maintainer, doxygen FTBFS due to a failure to run pdflatex. See this recent salsa build: https://salsa.debian.org/debian/doxygen/-/jobs/1213110 The error is: /usr/bin/pdflatex: Not writing to ../html/examples/group/latex//group__group2.aux (openout_any = p). make[4]: *** [doc/CMakeFiles/doxygen_pdf.dir/build.make:81: doc/CMakeFiles/doxygen_pdf] Error 1 I attach the complete pdflatex log file. I am no latex expert, so this could well be a doxygen issue. Can you advise ? thanks in advance, Paolo P.S. I will patch the build to temporarily work around this, so it is not a blocker. -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. *** The Debian TeX Team is *not* a LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) or http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files -rw-r--r-- 1 root root 2351 Dec 4 17:36 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Jun 8 10:31 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Dec 3 23:04 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Dec 3 23:04 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 475 Jul 9 06:19 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Dec 3 23:04 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN lrwxrwxrwx 1 root root 32 Dec 3 23:04 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 4986 Dec 4 17:35 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Jan 17 2017 mktex.cnf -rw-r--r-- 1 root root 475 Jul 9 06:19 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-2-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 texlive-latex-base depends on: ii fonts-lmodern 2.004.5-6 ii tex-common6.15 ii texlive-base 2020.20201203-1 ii texlive-binaries 2020.20200327.54578-5 texlive-latex-base recommends no packages. Versions of packages texlive-latex-base suggests: pn texlive-latex-base-doc Versions of packages tex-common depends on: ii dpkg 1.20.5 ii ucf 3.0043 Versions of packages tex-common suggests: ii debhelper 13.2.1 Versions of packages texlive-latex-base is related to: ii tex-common6.15 ii texlive-binaries 2020.20200327.54578-5 -- no debconf information doxygen_manual.log.xz Description: application/xz
Bug#976081: [Pkg-javascript-devel] Bug#976081: yarnpkg: Provide prebuilt yarnpkg in contrib
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
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
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
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
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 ...
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#969142: BTW do not add graphviz as build-dep
Also note that if doyxgen parses the correct and full configuration file, it does not invoke dot So please discard my initial suggestion to add graphviz as a build-dependency, that was wrong ! Paolo
Bug#969142: frobby: FTBFS with doxygen 1.8.19
Hi Douglas, see below. Il 30/08/20 13:57, Torrance, Douglas ha scritto: > Control: tags -1 confirmed > > On 8/28/20 3:43 AM, Paolo Greppi wrote: >> while rebuilding the build dependencies of doxygen with the upcoming doxygen >> 1.8.19 >> (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.8.19-1_amd64-partial) >> this package FTBFS. >> >> This is the error: >> >> sh: 1: dot: not found >> error: Problems running dot: exit code=127, command='dot', >> arguments='"/<>/bin/develDoc/html/graph_legend.dot" -Tpng -o >> "/<>/bin/develDoc/html/graph_legend.png"' >> Doxygen version used: 1.8.19 (552186a667287506d0359bb1ae14d11ad531bb25*) >> >> This should be pretty easy to fix: just add graphviz to the build deps. > > Thanks for the report! > > After adding graphviz to Build-Depends, I get a build error a bit > further down: > >> cd bin/develDoc/latexPdf; for f in `ls *.eps`; do epstopdf $f; done # Cygwin >> fix >> /bin/sh: 1: cd: can't cd to bin/develDoc/latexPdf >> ls: cannot access '*.eps': No such file or directory >> cd bin/develDoc/latexPdf/; make refman.pdf; mv refman.pdf ../develDoc.pdf >> /bin/sh: 1: cd: can't cd to bin/develDoc/latexPdf/ >> make[3]: Entering directory '/root/frobby' >> make[3]: *** No rule to make target 'refman.pdf'. Stop. >> make[3]: Leaving directory '/root/frobby' >> mv: cannot stat 'refman.pdf': No such file or directory >> make[2]: *** [Makefile:279: develDocPdf] Error 1 >> make[2]: Leaving directory '/root/frobby' >> dh_auto_build: error: make -j1 "INSTALL=install --strip-program=true" all >> library doc develDoc MODE=shared library=libfrobby.so.0.0.0 returned exit >> code 2 >> make[1]: *** [debian/rules:13: override_dh_auto_build] Error 25 >> make[1]: Leaving directory '/root/frobby' >> make: *** [debian/rules:10: binary] Error 2 >> dpkg-buildpackage: error: debian/rules binary subprocess returned exit >> status 2 >> debuild: fatal error at line 1182: >> dpkg-buildpackage -us -uc -ui failed > > I'll investigate further and try and figure out what's going on. > > Doug Thanks for the info, this is very interesting. It looks like doxygen fails to create the bin/develDoc/latexPdf/ dir in the preceding line of the Makefile: https://salsa.debian.org/science-team/frobby/-/blob/master/Makefile#L280 I have manually tried this command from the develDocHtml target: cat doc/doxygen.conf doc/doxHtml|doxygen - and it apparently succeeds, but produces empty documentation in bin/develDoc/html These commands work: rm -rf Doxyfile cat doc/doxygen.conf doc/doxHtml > Doxyfile doxygen while "doxygen -" is broken due to a known doxygen 1.8.19 bug, see: https://github.com/doxygen/doxygen/issues/7951#issuecomment-671370005 This is serious so I'll now release 1.8.19 to unstable and simultaneously file a RC bug in the BTS to block it. According to upstream, this has been fixed in the doxygen version 1.8.20 which they already released. I plan to package it ASAP so I suggest you wait for that and not patch your Makefile. Paolo
Bug#969149: possible fix
Please note that a similar problem has been fixed by the fcml maintainer: https://bugs.debian.org/969148 Paolo
Bug#969148: fcml: FTBFS with doxygen 1.8.19
Hi Stephen, Il 28/08/20 12:22, Stephen Kitt ha scritto: > Hi Paolo, > >> ... > > After building the package with doxygen from experimental, I get > > $ find . -name doxygen.\* > ./docs/doxygen/doxygen.stamp > ./docs/doxygen/html/doxygen.css > ./docs/doxygen/html/doxygen.svg > ./docs/doxygen/latex/doxygen.sty > ./debian/libfcml-doc/usr/share/doc/libfcml-doc/html/doxygen.css > ./debian/tmp/usr/share/doc/fcml/html/doxygen.css > ./debian/tmp/usr/share/doc/fcml/html/doxygen.svg > > dh_doxygen is invoked with -plibfcml-doc so this happens because the SVG file > isn’t installed there. Fixing that allows the build to complete. > > Regards, > > Stephen Thanks for the research and quick fix. This will be helpful to bug 969149 which I'll notify. Paolo
Bug#969150: boost1.71: FTBFS with doxygen 1.8.19
Source: boost1.71 Severity: normal Dear Maintainer, while rebuilding the build dependencies of doxygen with the upcoming doxygen 1.8.19 (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.8.19-1_amd64-partial) this package FTBFS. This is the error: doxygen-action build-doc/boost/bin.v2/libs/xpressive/doc/autodoc-xml.xml-dir rm -f "build-doc/boost/bin.v2/libs/xpressive/doc/autodoc-xml/*.xml" & "doxygen" "build-doc/boost/bin.v2/libs/xpressive/doc/autodoc-xml.doxyfile" && echo "Stamped" > "build-doc/boost/bin.v2/libs/xpressive/doc/autodoc-xml.xml-dir" /<>/boost/preprocessor/slot/detail/shared.hpp:27: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:28: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:29: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:30: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:31: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:32: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:33: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:34: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:35: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:36: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:39: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:40: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:41: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:42: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:43: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:44: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:45: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:46: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:47: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:48: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:51: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:52: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:53: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:54: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:55: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:56: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:57: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:58: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:59: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:60: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:63: warning: preprocessing issue while doing constant expression evaluation: syntax error /<>/boost/preprocessor/slot/detail/shared.hpp:64: warning: preprocessing issue while doing constant expression evaluation: syntax error
Bug#969147: aubio-tools: FTBFS with doxygen 1.8.19
Package: aubio-tools Version: 0.4.9-4+b1 Severity: normal Dear Maintainer, while rebuilding the build dependencies of doxygen with the upcoming doxygen 1.8.19 (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.8.19-1_amd64-partial) this package FTBFS. This is the error: sh: 1: dot: not found error: Problems running dot: exit code=127, command='dot', arguments='"/<>/doc/web/html/graph_legend.dot" -Tpng -o "/<>/doc/web/html/graph_legend.png"' This should be pretty easy to fix: just add graphviz to the build deps. Paolo -- 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 aubio-tools depends on: ii libaubio5 0.4.9-4+b1 ii libc6 2.31-3 ii libjack-jackd2-0 [libjack-0.125] 1.9.14~dfsg-0.1 ii python3 3.8.2-3 ii python3-aubio 0.4.9-4+b1 aubio-tools recommends no packages. aubio-tools suggests no packages. -- no debconf information
Bug#969148: fcml: FTBFS with doxygen 1.8.19
Package: fcml Version: 1.2.2-1 Severity: normal Dear Maintainer, while rebuilding the build dependencies of doxygen with the upcoming doxygen 1.8.19 (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.8.19-1_amd64-partial) this package FTBFS. This is the error: dh_doxygen: error: Doxygen documentation not found make[1]: *** [debian/rules:31: override_dh_installdocs-indep] Error 25 This requires further investigation; I thought I had fixed dh_doxygen with this commit: https://salsa.debian.org/debian/doxygen/-/commit/6e3577327a78d060268c7e32adac1d9b1051bf0f But this seems to fail on your package. Can you find the doxygen.css, doxygen.svg and index.html files in the doxygen-built doc dir after the doxygen command is run by the build script ? Thanks, Paolo -- 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 fcml depends on: ii libc6 2.31-3 ii libfcml0 1.2.2-1 fcml recommends no packages. fcml suggests no packages. -- no debconf information
Bug#969149: imagemagick: FTBFS with doxygen 1.8.19
Package: imagemagick Version: 8:6.9.11.24+dfsg-1+b1 Severity: normal Dear Maintainer, while rebuilding the build dependencies of doxygen with the upcoming doxygen 1.8.19 (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.8.19-1_amd64-partial) this package FTBFS. This is the error: dh_doxygen: error: Doxygen documentation not found make[1]: *** [debian/rules:722: override_dh_install-indep] Error 25 This requires further investigation; I thought I had fixed dh_doxygen with this commit: https://salsa.debian.org/debian/doxygen/-/commit/6e3577327a78d060268c7e32adac1d9b1051bf0f But this seems to fail on your package. Can you find the doxygen.css, doxygen.svg and index.html files in the doxygen-built doc dir after the doxygen command is run by the build script ? Thanks, Paolo -- Package-specific info: ImageMagick program version --- animate: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org compare: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org convert: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org composite: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org conjure: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org display: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org identify: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org import: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org mogrify: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org montage: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org stream: ImageMagick 6.9.11-24 Q16 x86_64 20200718 https://imagemagick.org -- 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 imagemagick depends on: ii imagemagick-6.q16 8:6.9.11.24+dfsg-1+b1 imagemagick recommends no packages. imagemagick suggests no packages. -- no debconf information
Bug#969145: sratom: FTBFS with doxygen 1.8.19
Source: sratom Severity: normal Dear Maintainer, while rebuilding the build dependencies of doxygen with the upcoming doxygen 1.8.19 (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.8.19-1_amd64-partial) this package FTBFS. This error comes up: dh_install: warning: Cannot find (any matches for) "usr/share/man/man3" (tried in ., debian/tmp) dh_install: warning: libsratom-doc missing files: usr/share/man/man3 dh_install: error: missing files, aborting make: *** [debian/rules:16: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 I can guess that doxygen silently fails without generating the man file. I suggest you update the doxygen configuration file to the latest format with doxygen -u Paolo -- 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
Bug#969141: of course I forgot to attach the logs
logs.tar.xz Description: application/xz
Bug#969143: libsord-dev: FTBFS with doxygen 1.8.19
Package: libsord-dev Version: 0.16.4-1 Severity: normal Dear Maintainer, while rebuilding the build dependencies of doxygen with the upcoming doxygen 1.8.19 (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.8.19-1_amd64-partial) this package FTBFS. doxygen reports: warning: Tag 'TCL_SUBST' at line 26 of file '-' has become obsolete. To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u" warning: ignoring unknown tag 'EXTRA' at line 174, file - Later this error comes up: dh_install: warning: Cannot find (any matches for) "usr/share/man/man3" (tried in ., debian/tmp) dh_install: warning: libsord-doc missing files: usr/share/man/man3 dh_install: error: missing files, aborting make: *** [debian/rules:12: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 I can guess that doxygen silently fails without generating the man file. I suggest you update the doxygen configuration file to the latest format with doxygen -u Paolo -- 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 libsord-dev depends on: ii libserd-dev 0.30.4-1 ii libsord-0-0 0.16.4-1 Versions of packages libsord-dev recommends: ii pkg-config 0.29.2-1 Versions of packages libsord-dev suggests: pn libsord-doc -- no debconf information
Bug#969142: frobby: FTBFS with doxygen 1.8.19
Package: libfrobby0 Version: 0.9.1-1 Severity: normal Dear Maintainer, while rebuilding the build dependencies of doxygen with the upcoming doxygen 1.8.19 (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.8.19-1_amd64-partial) this package FTBFS. This is the error: sh: 1: dot: not found error: Problems running dot: exit code=127, command='dot', arguments='"/<>/bin/develDoc/html/graph_legend.dot" -Tpng -o "/<>/bin/develDoc/html/graph_legend.png"' Doxygen version used: 1.8.19 (552186a667287506d0359bb1ae14d11ad531bb25*) This should be pretty easy to fix: just add graphviz to the build deps. Paolo -- 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 libfrobby0:amd64 depends on: ii libc6 2.31-3 ii libgcc-s1 10.2.0-5 ii libgmp10 2:6.2.0+dfsg-6 ii libgmpxx4ldbl 2:6.2.0+dfsg-6 ii libstdc++6 10.2.0-5 libfrobby0:amd64 recommends no packages. libfrobby0:amd64 suggests no packages. -- no debconf information
Bug#969141: websocketpp: errors while generating documentation & FTBFS with doxygen 1.8.19
Source: websocketpp Severity: normal Dear Maintainer, while rebuilding the build dependencies of doxygen with the upcoming doxygen 1.8.19 (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.8.19-1_amd64-partial) this package FTBFS. I attach the buildlogs: - buildlogs/websocketpp_0.8.2-1 (with doxygen 1.8.19) - buildlogs_recheck/websocketpp_0.8.2-1 (with doxygen 1.8.18) In both buildlogs doxygen reports: error: fixed-compilation-database: Error while opening fixed database: No such file or directory json-compilation-database: Error while opening JSON database: No such file or directory using clang compilation database path of: "(null)" error: /usr/include/wchar.h:35:10: fatal error: 'stddef.h' file not found [clang] error: /usr/include/sched.h:29:10: fatal error: 'stddef.h' file not found [clang] This then causes a segmentation fault with 1.8.19. Also doxygen is parsing the files readme.md, changelog.md and roadmap.md which is incorrect. You should fix the Doxyfile INPUT key and remove them (doxygen should only parse source code). The segmentation fault may well be a doxygen issue, but fixing the Doxyfile of websocketpp is the first step required to pinpoint the root issue. Paolo -- 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
Bug#968921: ITP: dotnet-core-3.1 -- Microsoft .NET Core SDK 3.0.100
Also see https://bugs.debian.org/779970 Paolo
Bug#960120: node-yarnpkg: I found an older commit that still builds
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#968340: thanks for the heads up
H, this was already in my todo list. But it's good to know this release is of value for someone, I'll give it a higher priority. So I plan to upload to experimental in a week or so. Before uploading to unstable I'd like to launch the usual ratt built (see wiki on salsa) so it will take a bit longer. Paolo
Bug#960120: different error during build
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#964218: [Pkg-javascript-devel] Bug#964218: node-yarnpkg: autopkgtest fails with node-uuid 8.2 from experimental - "Cannot read property 'v4' of undefined"
Updating that dependency is already in upsream's TODO list https://github.com/yarnpkg/yarn/issues/6829 .. but they seem to lag on updating dependencies. I guess it would require fixing against this breaking change: https://github.com/uuidjs/uuid/blob/master/CHANGELOG.md#-breaking-changes and upstream the patch .. Why do you need uuid v8 if I may ask ? Paolo Il 03/07/20 21:03, Pirate Praveen ha scritto: > Package: node-yarnpkg > Version: 1.22.4-3 > Severity: important > > Full build log is attached. This was run in a clean and uptodate lxc > container using salsa.debian.org/ruby-team/meta/build script.
Bug#961337: ITP: A secure runtime for JavaScript and TypeScript.
Il 29/06/20 21:27, Akshat Agarwal ha scritto: > Package: wnpp > Followup-For: Bug #961337 > Owner: Akshat Agarwal > > > * Package name: deno > Version : 1.1.2 > Upstream Author : Deno authors > * URL : https://github.com/denoland/deno > * License : MIT > Programming Lang: Rust, TypeScript, JavaScript > Description : A secure runtime for JavaScript and TypeScript. > > I intend to package Deno and maintain it. If anybody is willing to can > co-maintain with me. > > Thanks, > Akshat Agarwal (humancalico) Hi Akshat, many thanks for your interest in contributing to Debian. would you like to maintain deno within the js-team ? We already maintain nodejs ... Paolo
Bug#961726: OK ! here are the tarballs
This certainly makes sense and will be easier to digest by ftp-master (although you'll have two packages in NEW). For the tarballs, they are here: https://gitlab.eumetsat.int/open-source/PublicDecompWT/-/tags (click on the Download icon at the right). gitlab works well with uscan, see for example: https://codesearch.debian.net/search?q=gitlab+path%3Adebian%2Fwatch=0 Paolo
Bug#913997: what is the current maintainer view on this ?
The issue has been raised again on the yarnpkg side: https://bugs.debian.org/940511 Antonio, what is your point of view ? Do you think we can fix this for the Bookworm release ? Thanks, Paolo
Bug#940511: [Pkg-javascript-devel] Bug#940511: yarnpkg: Package symlink yarn -> yarnpkg
See below ...
On Wed, 20 May 2020 18:08:29 +0200 =?UTF-8?Q?Ma=C3=ABl_Nison?=
wrote:
> Hi, I'm Maël, Yarn's lead maintainer.
>
> While cmdtest has a popcon score higher than the yarn package, it's mostly
> because Yarn isn't traditionally installed using the Debian package. For
> historical reasons the 1.x branch always updated it, but in general our
> users install Yarn using it's "competitor", npm. The npm numbers give a
> very different picture: Yarn is downloaded 6.1m times per month.
>
> There are currently talks to, potentially, ship symlinks for the three main
> package managers along with Node (npm, which is already there, along with
> Yarn and maybe pnpm). These plans aren't concrete yet, but a few people
> think it's worth studying. In any case, the decision is expected to be
> taken for Node 15, which will happen this year. To the extent possible, I
> think it could be wise (and very appreciated!) to consider renaming the
> `yarn` binary from `cmdtest` before it risks becoming an actual problem.
>
> As a last note, I pinged Lars Wirzenius (who I think was the original
> cmdtest maintainer?), back in March '19. He mentioned having recently
> retired, but seemed fairly supportive of the idea ("I've now discussed the
> name of our testing tool with its other developer and we will likely change
> the name of our program during the Debian buster+1 development cycle").
>
> Maël
Hi Maël,
thanks for the feedback and for your Debian contribution.
I've added here the info on the bug that has to be addressed by the cmdtest
maintainer (if he agrees) for us to be able to fix this one.
I'll also ping him.
Paolo
Bug#940704: first try with node-jest 24.9.0
With node-jest now in the NEW queue, I have started working on this here:
https://salsa.debian.org/js-team/node-yarnpkg/-/tree/jest
I have built jest from https://salsa.debian.org/js-team/node-jest assuming
commit b9255f45c22c030b863e7d42aaf78c207db43478 will be tagged as 24.9.0+ds-2
(although that is not in NEW queue):
git checkout b9255f45c22c030b863e7d42aaf78c207db43478
git switch -c debian/24.9.0+ds-2
gbp buildpackage -uc -us --git-ignore-branch
I need to side-load these packages to /usr/share/nodejs to make jest start:
import-local realpath-native jest-snapshot-serializer-raw sane react-is
natural-compare p-each-series throat
Now the test suite starts, and all 91 tests fail. I need to also side-load:
string-length fast-json-stable-stringify source-map-support
not sure if these are jest run-time dependencies or yarnpkg test-time
dependencies.
Now all the tests fail because:
Cannot find module 'source-map-support' from 'source-map-support.js'
To fix this, I upgrade source-map-support to 0.5.19; now I get:
Cannot find module 'chalk' from 'Env.js'
this comes from /usr/share/nodejs/jest-jasmine2/build/jasmine/Env.js which is
compiled from node-jest/packages/jest-jasmine2/src/jasmine/Env.ts.
But node-chalk is installed:
nodejs
> chalk = require('chalk');
{ [Chalk]
constructor: [Function: Chalk],
supportsColor: { level: 2, hasBasic: true, has256: true, has16m: false },
default: [Circular] }
> ^d
Clearly the jest command is broken.
I suggest to enable the jest self-test suite in node-jest.
I tried running "jest" in node-jest source tree (after side-loading the 8
packages above), I get:
● Validation Error:
Test environment ./packages/jest-environment-node cannot be found. Make sure
the testEnvironment configuration option points to an existing node module.
Configuration Documentation:
https://jestjs.io/docs/configuration.html
Although ./packages/jest-environment-node exists (?)
I tried to specify the testEnvironment from the command line:
jest --env=node
and with that I get:
● Validation Error:
Module /packages/pretty-format/build/plugins/ConvertAnsi.js in the
snapshotSerializers option was not found.
is: /root/node-jest
Configuration Documentation:
https://jestjs.io/docs/configuration.html
Also note that the command:
jest --init
requires side-loading prompts module.
For my own record, I reset all the changes to my test machine with:
apt remove jest
apt autoremove
cd /usr/share/nodejs
rm import-local realpath-native jest-snapshot-serializer-raw sane react-is
natural-compare p-each-series throat string-length fast-json-stable-stringify
source-map-support prompts
mv source-map-support.old/ source-map-support
Paolo
Bug#958780: do we really want to do this ?
My understanding is that node-gulp-babel v8 should be used with babel7. Same goes for node-babel-loader, you need v8 for babel7, but we only have node-babel-loader 7 in Debian. If we want babel6 to co-exist with babel7, then we don't want to just update node-gulp-babel and node-babel-loader to v8. We want to keep node-gulp-babel and node-babel-loader at v7 for compatibility with babel6, and upload new node-gulp-babel8 and node-babel-loader8 for babel7. Back to the topic of this bug, do we really want to upgrade the yarn build system from babel6 to babel7 ? Here is some indication that upstream is not interested: https://github.com/yarnpkg/yarn/pull/6322 But I have raised the issue anyway: https://github.com/yarnpkg/yarn/issues/8083 Paolo
Bug#958780: take ownership
owner 958780 Paolo Greppi
Bug#941906: unreproducibile
Hi, I just tried on sid with the attached changes file: ratt ../texinfo_6.7.0.dfsg.2-5_amd64.changes 2020/04/25 16:41:15 Loading changes file "../texinfo_6.7.0.dfsg.2-5_amd64.changes" 2020/04/25 16:41:15 - 6 binary packages: info info-dbgsym install-info install-info-dbgsym texinfo texinfo-dbgsym 2020/04/25 16:41:15 Corresponding .debs (will be injected when building): 2020/04/25 16:41:15 ../info-dbgsym_6.7.0.dfsg.2-5_amd64.deb 2020/04/25 16:41:15 ../info_6.7.0.dfsg.2-5_amd64.deb 2020/04/25 16:41:15 ../install-info-dbgsym_6.7.0.dfsg.2-5_amd64.deb 2020/04/25 16:41:15 ../install-info_6.7.0.dfsg.2-5_amd64.deb 2020/04/25 16:41:15 ../texinfo-dbgsym_6.7.0.dfsg.2-5_amd64.deb 2020/04/25 16:41:15 ../texinfo_6.7.0.dfsg.2-5_amd64.deb 2020/04/25 16:41:15 Setting -dist=sid (from .changes file) 2020/04/25 16:41:15 Figuring out reverse build dependencies using dose-ceve(1). This might take a while 2020/04/25 16:47:55 Found 30676 reverse build dependencies 2020/04/25 16:47:55 Setting -sbuild_dist=unstable (from .changes file) 2020/04/25 16:47:55 Building package 1 of 30676: golang-github-biogo-hts 2020/04/25 16:49:07 Building package 2 of 30676: optimir 2020/04/25 16:50:03 Building package 3 of 30676: haskell-validity-containers ... I have this in /etc/apt/sources.list: deb http://mi.mirror.garr.it/mirrors/debian/ unstable main contrib non-free deb-src http://mi.mirror.garr.it/mirrors/debian/ unstable main contrib non-free deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main contrib non-free deb http://deb.debian.org/debian experimental main and of course I just run apt update. Paolo Format: 1.8 Date: Fri, 11 Oct 2019 07:32:01 +0900 Source: texinfo Binary: info info-dbgsym install-info install-info-dbgsym texinfo texinfo-dbgsym Architecture: source amd64 Version: 6.7.0.dfsg.2-5 Distribution: unstable Urgency: medium Maintainer: Debian TeX maintainers Changed-By: Norbert Preining Description: info - Standalone GNU Info documentation browser install-info - Manage installed documentation in info format texinfo- Documentation system for on-line information and printed output Changes: texinfo (6.7.0.dfsg.2-5) unstable; urgency=medium . * remove provides, doesn't work with breaks of info Checksums-Sha1: f554a272792cb8e86eca670bdee59470eb3fc3d9 1337 texinfo_6.7.0.dfsg.2-5.dsc 179f63287cb7f40028b9a4231ec9725f289e34ce 27188 texinfo_6.7.0.dfsg.2-5.debian.tar.xz 8343f0d079ba4d4dd5738cdda48091cb6884b3e3 436080 info-dbgsym_6.7.0.dfsg.2-5_amd64.deb f51dbbac20710f82e098c4fc068da92669c6a69d 298548 info_6.7.0.dfsg.2-5_amd64.deb cdc7c0947069d0d1810a8c334ffdf5df87c33f7a 157664 install-info-dbgsym_6.7.0.dfsg.2-5_amd64.deb fcec3a5826953f61c226b393cc13caf0508b6482 151212 install-info_6.7.0.dfsg.2-5_amd64.deb 9c53f5be1f341339c850dbe127aaebaf3e309a2b 358512 texinfo-dbgsym_6.7.0.dfsg.2-5_amd64.deb 8003ac2c7cefc1f35bf06512c19ad85c471df7ec 6681 texinfo_6.7.0.dfsg.2-5_amd64.buildinfo 579d71edb0bf27742f8c39104d18cf016f71df75 1760612 texinfo_6.7.0.dfsg.2-5_amd64.deb Checksums-Sha256: 82858886cc21a664de56f03045b72d8e0753bddf6c639dd0bc89ed22859a9609 1337 texinfo_6.7.0.dfsg.2-5.dsc 4723d2fc3dc720e89f6bfa863797216791d19369f3abea288698c908ead681a5 27188 texinfo_6.7.0.dfsg.2-5.debian.tar.xz f26320c784a8064daab474a9eb7ee9ef4e2b07596621ba0c1c071943929b09d4 436080 info-dbgsym_6.7.0.dfsg.2-5_amd64.deb db9f0d3cb627fa768e3b6b73f4ecd1d556c074b838e3ba11fb446dd9033a5c0e 298548 info_6.7.0.dfsg.2-5_amd64.deb b129d53ed97f579cd297976860fb3295fb95918ce09c4cd0d1003ac53f7bddd9 157664 install-info-dbgsym_6.7.0.dfsg.2-5_amd64.deb c9adcd0c96a71dfbacc93652292ff796d0a6d107f01b45ab4a4e5134a654696e 151212 install-info_6.7.0.dfsg.2-5_amd64.deb 132a5837d18fa547d468f0be4d4879613ec1311658c93665090853b8622b45ef 358512 texinfo-dbgsym_6.7.0.dfsg.2-5_amd64.deb 486769ac391ad9c1a48905b56b9f322ab435c42e35e14e30bf385d583e790381 6681 texinfo_6.7.0.dfsg.2-5_amd64.buildinfo ae8a4019231059d7e581570ab68e730462e9cbad865276365b1ed749bd6c7dff 1760612 texinfo_6.7.0.dfsg.2-5_amd64.deb Files: 680c5d029155c1656515687dfcd153a6 1337 doc standard texinfo_6.7.0.dfsg.2-5.dsc 78ddb5658fe44e3ffad4c4d8d87c2f03 27188 doc standard texinfo_6.7.0.dfsg.2-5.debian.tar.xz 36c23d3caa95a07ca1898537f92f3339 436080 debug optional info-dbgsym_6.7.0.dfsg.2-5_amd64.deb 110c8eb10d480d440052c6ddbdd62015 298548 doc important info_6.7.0.dfsg.2-5_amd64.deb ee405d3f0fcc7bac88b53d045012b456 157664 debug optional install-info-dbgsym_6.7.0.dfsg.2-5_amd64.deb 20b70ad2b508ff83b530186321898143 151212 doc important install-info_6.7.0.dfsg.2-5_amd64.deb d571c63f240d20992c2594cc4649dcb6 358512 debug optional texinfo-dbgsym_6.7.0.dfsg.2-5_amd64.deb 8991ecab03745ba475cc540bc805ea29 6681 doc standard texinfo_6.7.0.dfsg.2-5_amd64.buildinfo d9d1d22c7c5f4c9d9191dfc11f2eb00b 1760612 text optional texinfo_6.7.0.dfsg.2-5_amd64.deb
Bug#368577: unreproducible
Hi, I set up a small example to try to reproduce this problem: https://salsa.debian.org/paolog-guest/hello-doxygen/-/commits/368577 Note: I set CALL_GRAPH = YES in Doxyfile. Call graphs are generated fine for me on buster with doxygen 1.8.13-10 (see attachment). I'll close this bug unless someone has any objections. Paolo
Bug#375434: unreproducible
Hi, I just tried using the current master from https://salsa.debian.org/debian/schroot and doxygen 1.8.13-10 from buster. This is the log: doxygen schroot.dox warning: Tag `XML_SCHEMA' at line 1484 of file `schroot.dox' has become obsolete. To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u" warning: Tag `XML_DTD' at line 1490 of file `schroot.dox' has become obsolete. To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u" warning: doxygen no longer ships with the FreeSans font. You may want to clear or change DOT_FONTNAME. Otherwise you run the risk that the wrong font is being used for dot generated graphs. Notice: Output directory `schroot' does not exist. I have created it for you. Searching for include files... Searching for example files... Searching for images... Searching for dot files... Searching for msc files... Searching for dia files... Searching for files to exclude Searching INPUT for files to process... Searching for files in directory /tmp/schroot/bin/schroot-base Searching for files in directory /tmp/schroot/bin/schroot Searching for files in directory /tmp/schroot/bin/schroot-listmounts Searching for files in directory /tmp/schroot/bin/schroot-mount Searching for files in directory /tmp/schroot/bin/dchroot Searching for files in directory /tmp/schroot/bin/dchroot-dsa Reading and parsing tag files Parsing files Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-main.cc... Parsing file /tmp/schroot/bin/schroot-base/schroot-base-main.cc... Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-main.h... Parsing file /tmp/schroot/bin/schroot-base/schroot-base-main.h... Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-option-action.cc... Parsing file /tmp/schroot/bin/schroot-base/schroot-base-option-action.cc... Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-option-action.h... Parsing file /tmp/schroot/bin/schroot-base/schroot-base-option-action.h... Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-options.cc... Parsing file /tmp/schroot/bin/schroot-base/schroot-base-options.cc... Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-options.h... Parsing file /tmp/schroot/bin/schroot-base/schroot-base-options.h... Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-run.h... Parsing file /tmp/schroot/bin/schroot-base/schroot-base-run.h... Preprocessing /tmp/schroot/bin/schroot/schroot-main-base.cc... Parsing file /tmp/schroot/bin/schroot/schroot-main-base.cc... Preprocessing /tmp/schroot/bin/schroot/schroot-main-base.h... Parsing file /tmp/schroot/bin/schroot/schroot-main-base.h... Preprocessing /tmp/schroot/bin/schroot/schroot-main.cc... Parsing file /tmp/schroot/bin/schroot/schroot-main.cc... Preprocessing /tmp/schroot/bin/schroot/schroot-main.h... Parsing file /tmp/schroot/bin/schroot/schroot-main.h... Preprocessing /tmp/schroot/bin/schroot/schroot-options-base.cc... Parsing file /tmp/schroot/bin/schroot/schroot-options-base.cc... Preprocessing /tmp/schroot/bin/schroot/schroot-options-base.h... Parsing file /tmp/schroot/bin/schroot/schroot-options-base.h... Preprocessing /tmp/schroot/bin/schroot/schroot-options.cc... Parsing file /tmp/schroot/bin/schroot/schroot-options.cc... Preprocessing /tmp/schroot/bin/schroot/schroot-options.h... Parsing file /tmp/schroot/bin/schroot/schroot-options.h... Preprocessing /tmp/schroot/bin/schroot/schroot.cc... Parsing file /tmp/schroot/bin/schroot/schroot.cc... Preprocessing /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-main.cc... Parsing file /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-main.cc... Preprocessing /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-main.h... Parsing file /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-main.h... Preprocessing /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-options.cc... Parsing file /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-options.cc... Preprocessing /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-options.h... Parsing file /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-options.h... Preprocessing /tmp/schroot/bin/schroot-listmounts/schroot-listmounts.cc... Parsing file /tmp/schroot/bin/schroot-listmounts/schroot-listmounts.cc... Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount-main.cc... Parsing file /tmp/schroot/bin/schroot-mount/schroot-mount-main.cc... Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount-main.h... Parsing file /tmp/schroot/bin/schroot-mount/schroot-mount-main.h... Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount-options.cc... Parsing file /tmp/schroot/bin/schroot-mount/schroot-mount-options.cc... Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount-options.h... Parsing file /tmp/schroot/bin/schroot-mount/schroot-mount-options.h... Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount.cc... Parsing file
Bug#496459: forward upstream ?
Hi. this bug has been sitting idle for a long time. Do you still have this problem ? No one else in Debian project considered this issue worth bumping. Can you please forward it upstream to: https://github.com/doxygen/doxygen/issues and tag this one as forwarded upstream ? Thanks, Paolo
Bug#514229: more info required
Hi this bug has been sitting idle for a long time. Do you still have this problem ? No one else in Debian project considered this issue worth bumping. Can you please forward it upstream to: https://github.com/doxygen/doxygen/issues?q=is%3Aissue+buffer+log+is%3Aclosed and tag this one as forwarded upstream ? Thanks, Paolo
Bug#781636: more info required
Hi, do you still have this problem ? Can you provide a minimal example to reproduce the problem ? Maybe something based on this small project: https://salsa.debian.org/paolog-guest/hello-doxygen Thanks, Paolo
Bug#820853: not relevant anymore ?
Hi, currently we depend on qtbase5-dev (>= 5.12.5+dfsg-3): https://salsa.debian.org/debian/doxygen/-/blob/master/debian/control#L7 This bug report is probably not relevant anymore. If you agree please close this bug. Thanks, Paolo
Bug#869998: unreproducible
Hi ! I tried to reproduce your report with doxygen 1.8.13-10 on buster, see this repo/branch: https://salsa.debian.org/paolog-guest/hello-doxygen/-/commits/%23869998 But doxygen runs fine. The generated documentation page for hello.cc is like in the screenshot, the two example links point to: https://www.debian.org/security/#contact https://www.debian.org/security//#contact Can we consider this fixed ? Paolo
Bug#403451: Debian bug #403451 - please package the doxygen vim modes
Hi, this bug has been sitting idle for a long time. Clicking on the links you posted 14 years ago now redirects to vim homepage. I have found here a repository of vim scripts but there seems to be several doxygen plugins: https://github.com/vim-scripts?tab=repositories=doxygen In any case all these have a different source than doxygen itself, so they would need an ITP bug and a separate package. If you agree please close this bug. Thanks, Paolo
Bug#651884: still an issue for you ?
Hi, this bug has been sitting idle for a long time. doxygen-latex is a pure dependency package. It installs pretty much nothing, it just pulls in the right dependencies, among them is doxygen itself, which it makes sure is on par or more recent than its own version. So it is similar to python3.7 or python3.8. Its build dependencies can choose to request a specific version like this: doxygen-latex (=1.8.15). Of the 66 packages that mention doxygen-latex in debian/control that I could find: https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+doxygen-latex only avr-libc versions it: doxygen-latex (>=1.8.7). Currently doxygen builds fine on most archs: https://buildd.debian.org/status/package.php?p=doxygen Can you name a case where doxygen-latex has caused trouble recently ? If not, please close this bug. Thanks, Paolo
