Bug#1071323: libevent: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file
Hello, Le 2024-05-17 à 16 h 38, Santiago Vila a écrit : Package: src:libevent Version: 2.1.12-stable-8.1 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libevent-2.1-7t64/DEBIAN/symbols doesn't match completely debian/libevent-2.1-7t64.symbols --- debian/libevent-2.1-7t64.symbols (libevent-2.1-7t64_2.1.12-stable-8.1_amd64) +++ dpkg-gensymbols7bd7o9 2024-05-17 17:36:32.466620408 + @@ -365,7 +365,7 @@ event_set_mem_functions@Base 2.1.8-stable event_sock_err@Base 2.1.8-stable event_sock_warn@Base 2.1.8-stable - (arch=!musl-linux-any)event_strlcpy_@Base 2.1.8-stable +#MISSING: 2.1.12-stable-8.1# (arch=!musl-linux-any)event_strlcpy_@Base Ah, looks like glibc 3.38 is in testing. I'll apply the patch in experimental and reupload to unstable then, thanks! /Nicolas
Bug#1056348: FTBFS: tests fail in clean environment
Hello, I've forwarded the bug upstream [1] and they made a patch [2]. Can you test their patch on your package, to check if the problem is fixed on your CI? Also, if this works, I suggest to apply their patch rather than yours to make the code more consistent with upstream, do you agree? [1] https://github.com/libssh2/libssh2/issues/1240 [2] https://github.com/libssh2/libssh2/pull/1241
Bug#1056348: FTBFS: tests fail in clean environment
Le 2023-11-23 à 11 h 20, Steve McIntyre a écrit : AFAICS in a non-interactive environment, USER isn't required to be set but LOGNAME is; see https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html Alternatively, the tets should probably be calling get(e)uid and getpwent() rather than relying on the environment here. Indeed, I also had the same conclusion using other documentation. But then, if LOGNAME is mandatory, I suppose it would be better to use $LOGNAME alone instead of the condition. (I'm not refusing your patch, I just try to see if there's a better and cleaner way to fix it) I'll open a bug upstream to get their feedback on this /Nicolas
Bug#1056348: FTBFS: tests fail in clean environment
Le 2023-11-23 à 09 h 46, Steve McIntyre a écrit : Ah, apologies - that version is bogus, it's just the version on the bullseye machine I ran reportbug from. The tests are failing on current unstable source. OK, makes more sense then. Nevertheless I'm wondering about the seriousness of the bug, I can't reproduce on my environment and all the buildd environments where libssh2 is built don't have the problem. Could your issue be fixed by running something like this? USER=$LOGNAME dpkg-buiildpackage I'm just wondering if the patch is worth applying it to fix a less probable case. /Nicolas
Bug#1056348: FTBFS: tests fail in clean environment
Hello, On Tue, 21 Nov 2023 13:30:31 + Steve McIntyre wrote: Source: libssh2 Version: 1.9.0-2 Severity: serious Tags: ftbfs patch Hi! Building libssh2 using debuild in a clean local chroot, I get test failures and even a core dump! Thanks for reporting the bug, although I have concerns on its scope. The package you have found the issue is the bullseye one, and the package updates for oldstable are allowed mostly for security patches. Your bug is related to the test suite, and the patch won't change the binary files in the package, so I assume the patch isn't going to be allowed for proposed-updates. I've added the release team to ask for their opinion. Friends from the release team, do you have a feedback on this? /Nicolas
Bug#1051003: libgdbm6: trap divide error in libgdbm.so.6.0.0
Hello, On Mon, 4 Sep 2023 13:55:51 -0400 Nicolas Mora wrote: > Is this problem still relevant for libgdbm as we have a trap divide > error that should not happen no matter what? Or should I open a ticket > at libpam-shield so the problem (and the solution) is documented - even > if the package is orphaned? > I don't know if we can go further with this, but did you keep the old database file? So one could try to reproduce the problem, and if so, forward it upstream. Any update on this development? /Nicolas
Bug#1051003: libgdbm6: trap divide error in libgdbm.so.6.0.0
Hello Christopher, Le 2023-09-04 à 04 h 09, Christopher Voglstätter a écrit : PAM-shield uses a database file that I migrated from debian 10 to debian 12 in one big double upgrade. For testing purposes I deleted that database file, created an empty file instead and the trap divide error disappeared. PAM-shield works fine again as well and has been for three days now. So... problem solved for my case. It's a good and a bad news at the same time. A good news because you found a working workaround, and a bad news because since a database reset works, it should mean a problem in gdbm itself during some kind of upgrades. Is this problem still relevant for libgdbm as we have a trap divide error that should not happen no matter what? Or should I open a ticket at libpam-shield so the problem (and the solution) is documented - even if the package is orphaned? I don't know if we can go further with this, but did you keep the old database file? So one could try to reproduce the problem, and if so, forward it upstream. /Nicolas
Bug#1051003: libgdbm6: trap divide error in libgdbm.so.6.0.0
Hello, On Fri, 01 Sep 2023 11:13:22 +0200 Schnitzi wrote: Journal-Output: Aug 31 18:02:34 xyz dovecot[2451]: auth: Error: auth-worker: Aborted PASSV request for x...@xyz.xyz: Worker process died unexpectedly Aug 31 18:02:34 xyz dovecot[2451]: auth-worker: Fatal: master: service(auth-worker): child 118182 killed with signal 8 Aug 31 18:02:34 xyz kernel: traps: auth[118182] trap divide error ip:7f7366d16f06 sp:7ffc44386580 error:0 in libgdbm.so.6.0.0[7f7366d12000+a000] I don't know if the problem comes from gdbm or pam_shield yet. The pam_shield package, although orphaned, could be updated. The original pam-shield repository is archived [1], but there seems to be a more recent fork [2]. Could you test with h0tw1r3's 0.9.7 release [3] if the problem persist? If this fixes the problem, then updating pam-shield package would fix this issue. /Nicolas [1] https://github.com/jtniehof/pam_shield [2] https://github.com/h0tw1r3/pam_shield [3] https://github.com/h0tw1r3/pam_shield/releases/tag/0.9.7
Bug#1035503: [Debian-iot-maintainers] Bug#1035503: glewlwyd-common: prompting due to modified conffiles which were not modified by the user: /etc/glewlwyd/config.json
I've updated the package on salsa to rename the config.json file on install, I've attached the debdiff file if someone is willing to review the changes. /Nicolasdiff -Nru glewlwyd-2.7.5/debian/changelog glewlwyd-2.7.5/debian/changelog --- glewlwyd-2.7.5/debian/changelog 2023-01-17 07:24:23.0 -0500 +++ glewlwyd-2.7.5/debian/changelog 2023-05-04 07:21:27.0 -0400 @@ -1,3 +1,10 @@ +glewlwyd (2.7.5-3) unstable; urgency=medium + + * Install config.json as config-2.7.json (Closes: #1035503) + * d/glewlwyd-debian.conf.properties: disable user_middleware_module_path + + -- Nicolas Mora Thu, 04 May 2023 07:21:27 -0400 + glewlwyd (2.7.5-2) unstable; urgency=medium * d/control: add adduser as glewlwyd package dependency, fix piuparts issue diff -Nru glewlwyd-2.7.5/debian/glewlwyd-common.install glewlwyd-2.7.5/debian/glewlwyd-common.install --- glewlwyd-2.7.5/debian/glewlwyd-common.install 2023-01-17 07:24:23.0 -0500 +++ glewlwyd-2.7.5/debian/glewlwyd-common.install 2023-05-04 07:21:27.0 -0400 @@ -7,5 +7,5 @@ webapp-src/favicon.ico usr/share/glewlwyd/webapp/ debian/config.json usr/share/glewlwyd/templates/ -debian/config.json etc/glewlwyd/ +debian/config.json etc/glewlwyd/config-2.7.json debian/glewlwyd-apache.conf etc/glewlwyd/ diff -Nru glewlwyd-2.7.5/debian/glewlwyd-common.links glewlwyd-2.7.5/debian/glewlwyd-common.links --- glewlwyd-2.7.5/debian/glewlwyd-common.links 2023-01-17 07:24:23.0 -0500 +++ glewlwyd-2.7.5/debian/glewlwyd-common.links 2023-05-04 07:21:27.0 -0400 @@ -15,4 +15,4 @@ usr/share/fonts/woff/fork-awesome/forkawesome-webfont.woff usr/share/glewlwyd/webapp/fonts/forkawesome-webfont.woff usr/share/fonts/woff/fork-awesome/forkawesome-webfont.woff2 usr/share/glewlwyd/webapp/fonts/forkawesome-webfont.woff2 -etc/glewlwyd/config.json usr/share/glewlwyd/webapp/config.json +etc/glewlwyd/config-2.7.json usr/share/glewlwyd/webapp/config.json diff -Nru glewlwyd-2.7.5/debian/glewlwyd-debian.conf.properties glewlwyd-2.7.5/debian/glewlwyd-debian.conf.properties --- glewlwyd-2.7.5/debian/glewlwyd-debian.conf.properties 2023-01-17 07:24:23.0 -0500 +++ glewlwyd-2.7.5/debian/glewlwyd-debian.conf.properties 2023-05-04 07:21:27.0 -0400 @@ -94,7 +94,7 @@ user_module_path="/usr/lib/glewlwyd/user" # user_middleware_module path -user_middleware_module_path="/usr/lib/glewlwyd/user_middleware" +#user_middleware_module_path="/usr/lib/glewlwyd/user_middleware" # client_module path client_module_path="/usr/lib/glewlwyd/client" diff -Nru glewlwyd-2.7.5/debian/NEWS glewlwyd-2.7.5/debian/NEWS --- glewlwyd-2.7.5/debian/NEWS 2023-01-17 07:24:23.0 -0500 +++ glewlwyd-2.7.5/debian/NEWS 2023-05-04 07:21:27.00000 -0400 @@ -9,13 +9,19 @@ -- Nicolas Mora Mon, 15 Mar 2021 18:18:01 -0400 -glewlwyd (2.7.5-2) unstable; urgency=medium +glewlwyd (2.7.5-3) unstable; urgency=medium Upgrading Glewlwyd package from Debian Bullseye requires to update the database. It's also recommended to disable the config property 'static_files_path', and serve the static files application located in /usr/share/glewlwyd/webapp/ using a static file web server (Apache, NGINX). + The webapp config.json has been updated, the new config.json file is now + located in /etc/glewlwyd/config-2.7.json and linked to + /usr/share/glewlwyd/webapp/config.json. + If you have made changes to your original config.json, you can backport them + to the new config-2.7.json file or keep your current config.json file if you + don't need the new properties. See /usr/share/doc/glewlwyd/INSTALL.md for more details.
Bug#1035503: [Debian-iot-maintainers] Bug#1035503: glewlwyd-common: prompting due to modified conffiles which were not modified by the user: /etc/glewlwyd/config.json
Hello, Le 2023-05-06 à 06 h 31, Thorsten Alteholz a écrit : Maybe introducing a new filename and adding an entry to the news file could be an option. Indeed, config.json is installed by glewlwyd-common [1], and since bullseye, the file has changed to add new properties. I guess a better solution would be to install config.json as /etc/glewlwyd/config-2.7.5.json and provide documentation in the NEWS file. would that be correct? [1] https://salsa.debian.org/debian-iot-team/oauth2/glewlwyd/-/blob/master/debian/glewlwyd-common.install
Bug#1035503: [Debian-iot-maintainers] Bug#1035503: glewlwyd-common: prompting due to modified conffiles which were not modified by the user: /etc/glewlwyd/config.json
Hello,
I'm having a hard-time fixing this issue.
I've read [1] and related documentation, and I still make anything work.
For some reason, the commands I add in the glewlwyd-common package seems
not to be executed when I upgrade from bullseye to bookworm and I can't
figure out why...
- I've added the rm_conffile and al in a new set of
glewlwyd-common.{postinst,preinst,prerm} scripts
- I've used dpkg-maintscript-helper command instead:
dpkg-maintscript-helper rm_conffile /etc/glewlwyd/config.json 2.5.2
glewlwyd-common -- "$@"
- I've added a glewlwyd-common.maintscript, same no result
- I've tried with a conffiles too, no luck
Does anyone has an idea on how to fix this issue?
/Nicolas
[1] https://wiki.debian.org/DpkgConffileHandling
Bug#1023284: libevent: FTBFS with glibc 2.36
Hello, The patch was submitted upstream for their feedback [1], and was finally agreed. So I will upload a new package very soon then. /Nicolas [1] https://github.com/libevent/libevent/issues/1393#issuecomment-1453924054
Bug#1023284: libevent: FTBFS with glibc 2.36
Hello, I opened an issue upstream [1] to ask for feedbacks. Azat suggest to change the function signature from void evutil_secure_rng_add_bytes(const char *buf, size_t n); to: int evutil_secure_rng_add_bytes(const char *buf, size_t n) and make evutil_secure_rng_add_bytes to return -1, to make it more explicit that the function is no-oped. I understand and I tend to agree with this suggestion, but I'm wondering if this solution is correct for this bug? The symbol would still be the same, but would the signature change introduce problems in the libevent package dependencies and build-deps? Any thoughts? /Nicolas [1] https://github.com/libevent/libevent/issues/1393
Bug#1023284: libevent: FTBFS with glibc 2.36
Hello all, I'm forwarding my questions and thoughts about this patch. Le 2023-01-04 à 11 h 39, Shengjing Zhu a écrit : So Just make evutil_secure_rng_add_bytes noop with glibc's implemtation of arc4random. Please see following patch. In the libevent repo, azat mentions that nooping evutil_secure_rng_add_bytes is not a good thing to do [1] but on the other hand, other implementation have applied this kind of patch, like oracle mentioned above. I'm not pretending I know more, but I'd like to make sure this patch won't silently remove a core functionality in some packages, leading to random number generator being less random. Also, the libevent transition with glibc made by ubuntu in october went fine apparently, just a couple of build had an error [2] Again, I'm not trying to force one solution or another, but I question what solution is the best considering the little time we have until freeze. /Nicolas [1] https://github.com/libevent/libevent/issues/615#issuecomment-421182890 [2] https://bugs.launchpad.net/ubuntu/+source/libevent/+bug/1990941
Bug#1023284: libevent: FTBFS with glibc 2.36
Hello, Le 2022-11-17 à 04 h 15, Benjamin Drung a écrit : We did a library transition in Ubuntu to remove this symbol: https://launchpad.net/bugs/1990941 Attached the patch we applied. Thanks, I've made a new package based on your patch lately, libevent_2.1.12-stable-7 is in NEW for now [1]. Waiting for FTP masters to review the new package so the transition can start. /Nicolas [1] https://ftp-master.debian.org/new/libevent_2.1.12-stable-7.html
Bug#1021779: orage: eats events
Le 2022-11-11 à 14 h 41, Slavko a écrit : Yes, with current libical3 (in testing) the problem is solved, can be closed. Thanks, closing it then
Bug#1023284: libevent: FTBFS with glibc 2.36
Hello, If I understand correctly, removing the symbols evutil_secure_rng_add_bytes from the symbols files is enough to fix this bug? If no objection, I'll upload the fixed package tomorrow.
Bug#1021779: orage: eats events
Hello, On Sun, 23 Oct 2022 11:54:52 +0200 Yves-Alexis Perez wrote: for some reason your reports never reached us so I've just seen this bug and your investigation. My feeling is that this is actually https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021698 so it might be interesting to check if it's fixed with 3.0.16-1. If the bug comes from libical, I can confirm that it has been fixed in the last release 3.0.16-1 which is now on testing. Can you check with the last packages if the bug is still present? /Nicolas
Bug#1014681: glewlwyd: Add build dependency to node-react-dom
10 juill. 2022 10 h 45 min 13 s Yadd : > Source: glewlwyd > Version: 2.7.1-1 > Severity: important > > Hi, > > node-react is going to be split into multiple packages. Please add build > dependency to node-react-dom to fix test. > This can be done right now since current node-react provides > node-react-dom virtual package. > > Regards, > Yadd Thanks Yadd for notifying I won't be able to upload a new package for the next 3 weeks though. If the package glewlwyd will ftbfs until then, can someone in the team upload a fixed package? Otherwise, I'll make the fix in August. /Nicolas
Bug#1009769: libhoel1.4: ABI break: h_exec_query_sqlite was dropped
He Andreas, thanks for the feedback! Le 2022-04-17 à 10 h 42, Andreas Metzler a écrit : Yes, a rebuild will get a binary which works against the new library, however (partial) upgrades from bookworm won't work. BTW, the symbol file seems to be wrong: | h_execute_query_sqlite@Base 1.4.15 the symbol is not available in 1.4.15, so the rebuilt glewlwyd would depend on the libhoel1.4 (>= 1.14) instead of >= 1.18. You're right, thanks I think the first step would be to talk to upstream. One should not break the ABI of a shraed library without need, when it must be done it should happen properly with a soname bump. Since I'm the upstream, I can fix that with a new version, and I'll try to forget my shame... ;-) My bad, I thought using a #define for backward compatibility was enough, I didn't think about ABI break... Afaict libhoel1.4 has only got glewlwyd as reverse depends? As plan B if upstream is unwilling you could either patch libhoel (with the downside that it would not be cross distribution compatible) or simply make two new sourceful uploads, with a) let new libhoel1.4 Breaks: glewlwyd (<= 2.6.2-2~) and have a fixed symbol file. and b) glewlwyd Build-Depend-ing on libhoel-dev >= 1.18-2 to get the correct Depends on libhoel1.4 (>= 1.18-2). I'll fix the packages then, thanks for the help! /Nicolas
Bug#1009769: libhoel1.4: ABI break: h_exec_query_sqlite was dropped
Hello, Le 2022-04-17 à 01 h 32, Andreas Metzler a écrit : i.e. the symbol h_exec_query_sqlite was dropped from the library ABI. This breaks all reverse dependencies built against 1.4.18, e.g. glewlwyd is now broken: (sid)ametzler@argenau:/dev/shm/GLEWY$ ldd -r /usr/bin/glewlwyd | tail -n1 undefined symbol: h_exec_query_sqlite (/usr/bin/glewlwyd) Thanks, the symbol has changed its name, but a macro was added to make it source compatible: https://sources.debian.org/src/hoel/1.4.20-1/include/hoel.h/#L534 Therefore the package glewlwyd-2.6.2 still builds with this new source. Glewlwyd 2.7.0 will use the new function h_execute_query_sqlite instead. What is the best approach to close this bug? - Should I patch hoel package to replace the #define h_exec_query_sqlite() with a redefinition of h_exec_query_sqlite()? - Should I re-upload glewlwyd 2.6.2 to force a rebuild? Thanks in advance for your advice /Nicolas
Bug#1009447: iddawc: FTBFS: Errors while running CTest
Hello, On Tue, 12 Apr 2022 20:41:02 +0200 Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on amd64. This has been fixed in iddawc-1.1.2-2, thanks! /Nicolas
Bug#1006379: libssh2: autopkgtest regression: FAIL: ssh2.sh
Hello, thanks for the bug report! Le 2022-02-24 à 11 h 10, Paul Gevers a écrit : Your package has an autopkgtest, great. However, recently it started failing in testing. I don't see the problem when I build on my computer, and I don't know precisely how to fix it, but the problem comes from the script test/ssh2.sh which fails. If I install openssh-server in Build-Depends, the build fails on my computer in schroot because it tries to run ssh2.sh, and fails.
Bug#1000471: glewlwyd FTBFS can't find functions.
Hello, Le 2021-11-23 à 15 h 20, peter green a écrit : Package: glewlwyd Version: 2.5.2-3 Severity: serious Tags: ftbfs Unfortunately it seems that even after the cross-fetch fix, glewlwyd still FTBFS as a result of changes in iddawc/rhonabwy. Thanks, that's because the dependencies were updated lately, and some api was changed. I have the package glewlwyd 2.6.0 ready to upload, as soon as node-i18next-http-backend 1.3.1+dfsg-3 will be available on my schroot, today or tomorrow. /Nicolas
Bug#997718: glewlwyd: FTBFS: Module not found: Error: Can't resolve 'cross-fetch' in '/<>/webapp-src/node_modules/i18next-http-backend/cjs'
Hello, The package node-cross-fetch is in the NEW queue [1]. When it will be accepted in unstable, a quick change in the package i18next-http-backend will fix glewlwyd's ftbfs. /Nicolas [1] https://ftp-master.debian.org/new/node-cross-fetch_3.1.4%2Bds.1-1.html
Bug#993176: libssh2 FTBFS: configure.ac:130: error: m4_undefine: undefined macro: backend
The package libssh2 1.10.0-2 has successfully migrated to testing so I believe this bug is fixed now
Bug#993176: libssh2 FTBFS: configure.ac:130: error: m4_undefine: undefined macro: backend
Hello, Le 2021-08-28 à 07 h 54, Helmut Grohne a écrit : libssh2 fails to build from source. A build ends as follows: I can reproduce that too, not sure why it fails now... libssh2 version 1.10 builds successfully though, and I'm currently working on packaging libssh2 1.10 with openssl 3.0. If that's ok with you I'll close this bug when version 1.10 will be uploaded to sid. /Nicolas
Bug#977348: ulfius: missing runtime zlib dependency?
On Mon, 14 Dec 2020 10:53:53 +0100 Gianfranco Costamagna wrote: Hello, looks like the new ulfius version is missing a zlib1g-dev dependency on the -dev package, leading to reverse-dependencies FTBFS in tests (e.g. in src:iddawc) Indeed, I missed that one, thanks! OpenPGP_0xFE82139440BD22B9.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#969570: ulfius: FTBFS on s390x
Hello,
Le 20-09-05 à 03 h 42, Gianfranco Costamagna a écrit :>
> Hello, your package FTBFS on s390x. Please have a look if possible
>
[...]
> Start 3: framework
> 3/4 Test #3: framework ***Failed0.65 sec
> Running suite(s): Ulfius framework function tests
> 86%: Checks: 15, Failures: 2, Errors: 0
[...]
> /<>/test/framework.c:1145:F:test_ulfius_framework:test_ulfius_send_smtp:0:
> Assertion 'ulfius_send_smtp_email("localhost", 2525, 0, 0, ((void *)0),
> ((void *)0), "from", "to", "cc", "bcc", "subject", "mail body") == 0' failed:
> ulfius_send_smtp_email("localhost", 2525, 0, 0, ((void *)0), ((void *)0),
> "from", "to", "cc", "bcc", "subject", "mail body") == 5, 0 == 0
> /<>/test/framework.c:1169:F:test_ulfius_framework:test_ulfius_send_rich_smtp:0:
> Assertion 'ulfius_send_smtp_rich_email("localhost", 2526, 0, 0, ((void *)0),
> ((void *)0), "from", "to", "cc", "bcc", "text/ulfius; charset=utf-42",
> "subject", "mail body") == 0' failed:
> ulfius_send_smtp_rich_email("localhost", 2526, 0, 0, ((void *)0), ((void
> *)0), "from", "to", "cc", "bcc", "text/ulfius; charset=utf-42", "subject",
> "mail body") == 5, 0 == 0
This is weird, there were no changes in this part of the library between
2.6.8 and 2.6.9, and in the previous version the build had no problem [1]
The failing tests are using TCP ports 2525 and 2526 for SMTP tests.
Is it possible that those ports were not available during the build,
leading to test fails? Maybe because another process is using them or
some other reason?
/Nicolas
[1] -
https://buildd.debian.org/status/fetch.php?pkg=ulfius=s390x=2.6.8-1=1594468505=0
Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined
Le 20-07-26 à 18 h 01, Pirate Praveen a écrit :
>
>>
>> File in node-lodash unstable package:
>> 4.17.19+dfsg-1 _baseOrderBy.js https://paste.debian.net/1157886/
>>
I made a dirty hack to check my theory and it looks like if I patch this
file by replacing 'isArray' with 'Array.IsArray' or if I append 'isArray
= require('./isArray')', I'm able to build broken packages like
node-babel7 or glewlwyd.
The only way I found to patch the package node-lodash is to manually
change the file lodash.js here:
https://salsa.debian.org/js-team/node-lodash/-/blob/master/lodash.js#L3724
and replacing 'isArray' with 'Array.IsArray'.
/Nicolas
Bug#965353: [Pkg-javascript-devel] Bug#965353: Bug#965353: Bug#965353: node-babel7 FTBFS: babel-plugin-dynamic-import-node/src/index.js: isArray is not defined
I'm not sure yet if this would fix the bug but in all the build log errors, I see that the file /usr/share/nodejs/lodash/_baseOrderBy.js is always the source of the error. The file _baseOrderBy.js in the package seems buggy for an unresolved reson. File in node-lodash unstable package: 4.17.19+dfsg-1 _baseOrderBy.js https://paste.debian.net/1157886/ File in node-lodash bullseye package 4.17.15+dfsg-2 _baseOrderBy.js https://paste.debian.net/1157887/ In the unstable version, the call to isArray line 24 is the root of errors. Also, I see that the upstream version 4.17.19 isn't tagged as latest release, 4.17.16 is, maybe it's worth a try to package 4.17.16 instead? https://github.com/lodash/lodash/releases
Bug#964512: openzwave-controlpanel: FTBFS with invalid type conversion
Hello,
On Wed, 08 Jul 2020 11:22:18 +0200 Andreas Beckmann wrote:
>
> openzwave-controlpanel recently started to FTBFS with
>
libmicrohttpd has recent API changes. The attached patch file should fix
the ftbfs with libmicrohttpd 0.9.71. It also fixes a gcc warning with
uninitialized value.
/Nicolas
Index: openzwave-controlpanel-0.2a+git20161006.a390f35/webserver.cpp
===
--- openzwave-controlpanel-0.2a+git20161006.a390f35.orig/webserver.cpp
+++ openzwave-controlpanel-0.2a+git20161006.a390f35/webserver.cpp
@@ -100,11 +100,11 @@ extern int debug;
* web_send_data
* Send internal HTML string
*/
-static int web_send_data (struct MHD_Connection *connection, const char *data,
+static enum MHD_Result web_send_data (struct MHD_Connection *connection, const char *data,
const int code, bool free, bool copy, const char *ct)
{
struct MHD_Response *response;
- int ret;
+ enum MHD_Result ret;
if (!copy && ! free)
response = MHD_create_response_from_buffer(strlen(data), (void *) data, MHD_RESPMEM_PERSISTENT);
@@ -148,14 +148,14 @@ void web_close_file (void *cls)
* web_send_file
* Read files and send them out
*/
-int web_send_file (struct MHD_Connection *conn, const char *filename, const int code, const bool unl)
+enum MHD_Result web_send_file (struct MHD_Connection *conn, const char *filename, const int code, const bool unl)
{
struct stat buf;
FILE *fp;
struct MHD_Response *response;
const char *p;
const char *ct = NULL;
- int ret;
+ enum MHD_Result ret;
if ((p = strchr(filename, '.')) != NULL) {
p++;
@@ -540,7 +540,7 @@ const char *Webserver::SendSceneResponse
char *fn;
int cnt;
int i;
- uint8 sid;
+ uint8 sid = 0;
TiXmlDeclaration* decl = new TiXmlDeclaration( "1.0", "utf-8", "" );
doc.LinkEndChild(decl);
TiXmlElement* scenesElement = new TiXmlElement("scenes");
@@ -644,7 +644,7 @@ const char *Webserver::SendSceneResponse
* Process poll request from client and return
* data as xml.
*/
-int Webserver::SendPollResponse (struct MHD_Connection *conn)
+enum MHD_Result Webserver::SendPollResponse (struct MHD_Connection *conn)
{
TiXmlDocument doc;
struct stat buf;
@@ -657,7 +657,7 @@ int Webserver::SendPollResponse (struct
char fntemp[32];
char *fn;
FILE *fp;
- int32 ret;
+ enum MHD_Result ret;
TiXmlDeclaration* decl = new TiXmlDeclaration( "1.0", "utf-8", "" );
doc.LinkEndChild(decl);
@@ -811,14 +811,14 @@ int Webserver::SendPollResponse (struct
* Process request for Device List from client and return
* data as xml.
*/
-int Webserver::SendDeviceListResponse (struct MHD_Connection *conn)
+enum MHD_Result Webserver::SendDeviceListResponse (struct MHD_Connection *conn)
{
TiXmlDocument doc;
char str[16];
int32 i, j;
char fntemp[32];
char *fn;
- int32 ret;
+ enum MHD_Result ret;
TiXmlDeclaration* decl = new TiXmlDeclaration( "1.0", "utf-8", "" );
doc.LinkEndChild(decl);
@@ -981,7 +981,7 @@ void web_controller_update (Driver::Cont
* Handle the post of the updated data
*/
-int web_config_post (void *cls, enum MHD_ValueKind kind, const char *key, const char *filename,
+enum MHD_Result web_config_post (void *cls, enum MHD_ValueKind kind, const char *key, const char *filename,
const char *content_type, const char *transfer_encoding,
const char *data, uint64_t off, size_t size)
{
@@ -1079,7 +1079,7 @@ int web_config_post (void *cls, enum MHD
/*
* Process web requests
*/
-int Webserver::HandlerEP (void *cls, struct MHD_Connection *conn, const char *url,
+enum MHD_Result Webserver::HandlerEP (void *cls, struct MHD_Connection *conn, const char *url,
const char *method, const char *version, const char *up_data,
size_t *up_data_size, void **ptr)
{
@@ -1088,11 +1088,11 @@ int Webserver::HandlerEP (void *cls, str
return ws->Handler(conn, url, method, version, up_data, up_data_size, ptr);
}
-int Webserver::Handler (struct MHD_Connection *conn, const char *url,
+enum MHD_Result Webserver::Handler (struct MHD_Connection *conn, const char *url,
const char *method, const char *version, const char *up_data,
size_t *up_data_size, void **ptr)
{
- int ret;
+ enum MHD_Result ret;
conninfo_t *cp;
if (debug)
Index: openzwave-controlpanel-0.2a+git20161006.a390f35/webserver.h
===
--- openzwave-controlpanel-0.2a+git20161006.a390f35.orig/webserver.h
+++ openzwave-controlpanel-0.2a+git20161006.a390f35/webserver.h
@@ -49,16 +49,16 @@ class Webserver {
string getAdminMessage() { return adminmsg; }
void setAdminMessage (string msg) { adminmsg = msg; }
private:
- static int HandlerEP(void *cls, struct MHD_Connection *conn, const char *url, const char *method,
+ static enum MHD_Result HandlerEP(void *cls, struct MHD_Connection *conn, const char *url, const char *method,
const char *version, const char *up_data, size_t *up_data_size, void **ptr);
- int Handler(struct
Bug#964384: [Debian-iot-maintainers] Bug#964384: ulfius: FTBFS with recent libmicrohttpd
> Hello, can you please apply the two patches below to fix the build failure > with new libmicrohttpd and to give a more useful error message in case curl > fails? > (I don't know yet why, but the autopkgtest is failing in Ubuntu) > Since I'm also the upstream author, I'll fix the ftbfs in the next release, very soon. But I must package new releases orcania and yder first. This should be done in a few days. > > also, help to track down the ubuntu failure is appreciated > http://autopkgtest.ubuntu.com/packages/u/ulfius/groovy/amd64 > In the log, the first error tells us that: framework.c:667:F:test_ulfius_framework:test_ulfius_net_type_endpoint:0: Assertion 'response.status == 200' failed: response.status == 503, 200 == 200 This test fails while getting "http://[::1]:8080/empty;, maybe there's an ipv6 issue in ubuntu autopkgtest environment? The last 2 errors will probably tell us more after the release since the error message will be fixed in ulfius_send_smtp_rich_email, thanks to you! /Nicolas signature.asc Description: OpenPGP digital signature
Bug#964136: [Debian-iot-maintainers] Bug#964136: glewlwyd build-depedencies unsatisfiable on armel, mipsel and mips64el
> > I was able to whip up the attatched patch which partially splits the > arch dependent and independent > builds (an arch only build now only builds the arch stuff but an indep > only build still builds > everything) and do a succesfull arch only build on armel. > Thanks a lot Peter, I was almost there with my fix as well, you beat me. Mine was similar except for the override_dh_auto_build-indep in d/rules. I'll use this override command instead of my if [ -x "/usr/bin/webpack" ] in override_dh_auto_build
Bug#964136: glewlwyd build-depedencies unsatisfiable on armel, mipsel and mips64el
Build has been fixed for mipsel and mips64el but it remains impossible on armel since nodejs isn't available on this platform. The thing is nodejs is used during package build only, to transpile the reactjs front-end single-page-application. Then the result is the same for all architecture. If we could separate the backend build (architecture: any) and the frontend build (architecture: all), we might have Glewlwyd available for armel, alpha, ia64, m68k, ppc64, riscv64, sh4, sparc64 and x32. signature.asc Description: OpenPGP digital signature
Bug#962875: [Debian-iot-maintainers] Processed: block 962875 with 962876 962877 962878 962879 962880 962881 962882 962883 962884 962885 962886 962887
This bug will be resolved when Glewlwyd 2.x will be packaged into unstable. I'm currently waiting for iddawc in the NEW queue to be accepted in experimental to move on. signature.asc Description: OpenPGP digital signature
Bug#951044: Revdeps which use the typelib FTBFS: dh_girepository: error: Could not find ICalGLib-3.0.typelib dependency
Le 20-02-11 à 06 h 26, Iain Lane a écrit : > > Thanks! Would you mind if I reschedule the NMU to be uploaded straight > away so we don't have to wait to be able to build evolution-data-server? > That's ok, I reupload the package 3.0.7-2 with your fix, it should be available in sid soon now. /Nicolas signature.asc Description: OpenPGP digital signature
Bug#951044: Revdeps which use the typelib FTBFS: dh_girepository: error: Could not find ICalGLib-3.0.typelib dependency
Le 20-02-10 à 06 h 02, Iain Lane a écrit : > > Since this is breaking the build of reverse dependencies, I'm proposing > to NMU a fix to DELAYED/5. The debdiff is attached. Feel free to fix it > yourself sooner, though. > Thanks for the patch, I apply it to the package now!
Bug#916855: [Debian-iot-maintainers] Bug#916855: glewlwyd: FTBFS: no dependency information found for /build/ulfius-build/libulfius.so.2.3
Hello, Thanks for the report. It's due to a change in the librairies header files recently. This change is incompatible with older glewlwyd cmake scripts. Glewlwyd 1.4.9 fixes that and the package will be uploaded soon.
