Bug#949969: transmission-gtk uses 100% of a CPU core
Hi, The example torrent is not available anymore. Downloading a torrent with transmission 4 from unstable does not use 100% CPU core. Can you reproduce? Special parameters? Thanks, Alex
Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Hi, > I suppose it must be fixed in 4.x then. Sadly, I cannot test this as my box > running transmission-daemon is on stable.. backporting is straightforward (no change) and I publish[1] a built backport if you want to try. [1] http://deb.zincube.net/ Thanks, Alex
Bug#1069641: right versions
Hi, With the right versions, sorry for the noise. nmu uwsgi-plugin-php_2.0.22+4+0.0.15+b2 . ANY . unstable . -m "rebuild against new uwsgi.h" nmu uwsgi-plugin-luajit_2.0.22+4+0.0.8+b2 . ANY . unstable . -m "rebuild against new uwsgi.h" nmu uwsgi-plugin-mongo_2.0.24+3+0.0.9+b3 . ANY . unstable . -m "rebuild against new uwsgi.h" Thanks.
Bug#1069641: nmu: uwsgi-plugin-php_2.0.22+1+0.0.15+b1 uwsgi-plugin-luajit_2.0.22+1+0.0.8+b1 uwsgi-plugin-mongo_2.0.22+1+0.0.9+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: uwsgi-plugin-...@packages.debian.org, d...@jones.dk Control: affects -1 + src:uwsgi-plugin-php Control: affects -1 + src:uwsgi-plugin-luajit Control: affects -1 + src:uwsgi-plugin-mongo Hi, uwsgi.h changed again, and uwsgi ABI id is derived from that file, so a rebuild is required for plugins to depend on the correct uwsgi-abi binary package. nmu uwsgi-plugin-php_2.0.22+1+0.0.15+b1 . ANY . unstable . -m "rebuild against new uwsgi.h" nmu uwsgi-plugin-luajit_2.0.22+1+0.0.8+b1 . ANY . unstable . -m "rebuild against new uwsgi.h" nmu uwsgi-plugin-mongo_2.0.22+1+0.0.9+b1 . ANY . unstable . -m "rebuild against new uwsgi.h" Thanks!
Bug#996433: transmission-daemon: Transmission fails to send mail using exim4
Hi, The transmission-daemon documentation was updated[1]. [1] https://github.com/transmission/transmission/commit/b34b5193ca5de83ae85cac3c971214b17c3035f2 To customize systemd services, you should user overrides. $ sudo systemctl edit transmission-daemon.service and add the following content to the override: [Service] NoNewPrivileges=false and that override will be kept untouched by package upgrades. (you should not modify /lib/systemd/system/ files) So this can be closed I think? Thanks, Alex
Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Hi, > Today I noticed transmission-daemon being down after a reboot, and saw it is > crashing with a malloc error. After some debugging, I found out that this only > happens if I am using the `--portmap` option *and* a local minissdpd is > running. Does this still happen with 4.x? What is the setup to reproduce? $ sudo apt install minissdpd [...] $ /usr/bin/transmission-daemon -f --log-debug --portmap WARN: --log-debug is deprecated. Use --log-level=debug [...] [2024-04-12 11:57:46.232] dbg port-forwarding-natpmp.cc:38 initnatpmp succeeded (0) (port-forwarding-natpmp.cc:38) [2024-04-12 11:57:46.232] dbg port-forwarding-natpmp.cc:38 sendpublicaddressrequest succeeded (2) (port-forwarding-natpmp.cc:38) [2024-04-12 11:57:46.232] inf port-forwarding.cc:215 State changed from 'Not forwarded' to 'Starting' (port-forwarding.cc:215) [...] [2024-04-12 11:57:54.230] dbg port-forwarding-natpmp.cc:42 readnatpmpresponseorretry failed. Natpmp returned -7 (the gateway does not support nat-pmp); errno is 111 (Connexion refusée) (port-forwarding-natpmp.cc:42) [2024-04-12 11:57:54.230] dbg port-forwarding-upnp.cc:290 UPNP_GetValidIGD failed: Connexion refusée (111) (port-forwarding-upnp.cc:290) [2024-04-12 11:57:54.230] dbg port-forwarding-upnp.cc:291 If your router supports UPnP, please make sure UPnP is enabled! (port-forwarding-upnp.cc:291) [2024-04-12 11:57:54.230] inf port-forwarding.cc:215 State changed from 'Starting' to '???' (port-forwarding.cc:215) [2024-04-12 11:58:02.738] inf session.cc:1328 Transmission version 4.0.5 (a6fe2a64aa) shutting down (session.cc:1328) [...] Closing transmission session... done. ** does not crash ** Thanks, Alex
Bug#1004499: transmission-daemon segfault in libgnutls.so.30.13.1 and libc-2.24.so
Hi, I have run transmission-daemon 3.x and 4.x for days without experiencing a segfault. Is this still current? Thanks, Alex
Bug#1068436: transmission RFS
Hi, > Well, given that the main maintainer dropped themselves from the > debian/control file, I think the package can be freely adopted, > keeping Leo Antunes on of course in case he reappears. I'll drop the > two of them a note asking for objections, and assuming there are none, > I'd suggest we go ahead with that. What do you think? This would be: > > Maintainer: Leo Antunes > Uploaders: Alexandre Rossi , >Barak A. Pearlmutter > > and would allow "proper" uploads, not just NMUs. Perfect, the end goal being having transmission back in testing ASAP. > I merged your "fix build on bookworm" patch, but the package still > builds fine on a chroot on my own machine, and fails to build on > salsa, > https://salsa.debian.org/bap/transmission/-/pipelines Should be fixed, d/control syntax issue. > If you feel like preparing a serious 4.0.5-2 candidate with > *everything* you think belongs included, rather than just a minimal > NMU, that would be great! Done. https://mentors.debian.net/debian/pool/main/t/transmission/transmission_4.0.5-2.dsc Changes can be reviewed on salsa: https://salsa.debian.org/niol/transmission > What I meant with the pre-built javascript business was that it's more > robust to set things up so *if* the tools to do so are available, that > stuff is rebuilt. But if not, e.g., if someone is building for a small > platform or porting or just wants to build a local copy and doesn't > want to install that stuff, it would use pre-built files instead. This > also makes it easier for porters. This seems like pretty much what > upstream advocates in web/README.md, except the idea is to automate > it. With that stuff in place, it's a lot easier to argue that using > the prebuilt files under some particular circumstance (like some > package is missing from Debian for the moment) is not serious enough > of an issue to delay progression to testing etc. Ok, this feels against DFSG in the sense of including prebuild files in source, and upstream does it, so I do not see clearly a role for Debian regarding this. Do you mean removing the Files-Excluded stanzas in d/copyright? > And yes, your "proper" cmake-test-based -latomic fix is the "right" > way to do it, unlike the sleazy hack I put in debian/rules. Incuded your hack for the mean time, and will initiate work with upstream today to have a proper fix in place. Thanks, Alex
Bug#918324: Unix permission issue
Hi, This is a unix permission issue, either change transmission-daemon to run as user, or add a group write permissions to the download folder. Thanks, Alex
Bug#1068436: transmission RFS
Hi, > In the meantime, I note that Sandro Tosi has dropped his > maintainership of the package, but pushed a debian/4.0.5-2 tag without > uploading. Do you know the status of that? I have had no answer from both listed maintainers since last January. I have tried to contact them through salsa comment, bug reports and direct e-mail. > The two top bugs are a missing -latomic on ARM, which should be easy > enough to work around in debian/rules using > include /usr/share/dpkg/architecture.mk > if ... Maybe this fix should be upstreamed with something looking like a similar change: https://patch-diff.githubusercontent.com/raw/ccache/ccache/pull/723.patch > and the prebuilt javascript business, which I note from MR/16 you've > been working on. One suggestion I have for that is to set things up so > that *if* the tools are available, the javascript can be rebuilt; but > if not, pre-built versions are used anyway. This would make things > robust, and would I think allow the bug to be downgraded. I fail to understand how using prebuild versions would fix the bug or how handling the case where the tools are not available would help. Would you elaborate on the use case? > I'm also not thrilled with how the build process adds a git hook if it > can. Should probably hot-wire that off, because it seems to present a > potential security issue. Just a quilt patch to disable the entire > if(GIT_FOUND) thing at the end of CMakeLists.txt seems about right. > (The Source Control System is supposed to control the build, not vice > versa!) I completely agree but as we are in the context of a NMU, I wanted to keep focused. To sum things up, I understand that my upload needs an update for the missing -latomic issue. I'll prepare an update. Thanks for your interest, Alex
Bug#1067650: davmail: O365Interactive fails with "superclass access check failed: class davmail.exchange.auth.O365InteractiveAuthenticatorFrame"
Hi, > Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: > superclass access check failed: class > davmail.exchange.auth.O365InteractiveAuthenticatorFrame$2 (in unnamed module > @0x112d0a71) cannot access class sun.net.www.protocol.https.Handler (in > module java.base) because module java.base does not export > sun.net.www.protocol.https to unnamed module @0x112d0a71 Upstream points out that davmail should be launched with: $ /usr/bin/java \ -Xmx512M -Dsun.net.inetaddr.ttl=60 \ --add-exports java.base/sun.net.www.protocol.https=ALL-UNNAMED \ -jar /usr/share/davmail/davmail.jar Do you confirm this fixes the problem? Thanks, Alex
Bug#1068436: RFS: transmission/4.0.5-1.2 [NMU] [RC] -- lightweight BitTorrent client
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for the package "transmission": * Package name : transmission Version : 4.0.5-1.2 * URL : https://transmissionbt.com/ * License : GPL-3 or LGPL-2.1, ISC, Expat, GPL-2, GPL-3, public-domain, BSD-3-clause, GPL-2+-OpenSSL, Zlib, GPL * Vcs : https://salsa.debian.org/debian/transmission Section : net The source builds the following binary packages: transmission - lightweight BitTorrent client transmission-common - lightweight BitTorrent client (common files) transmission-cli - lightweight BitTorrent client (command line programs) transmission-gtk - lightweight BitTorrent client (GTK+ interface) transmission-qt - lightweight BitTorrent client (Qt interface) transmission-daemon - lightweight BitTorrent client (daemon) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/transmission/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/t/transmission/transmission_4.0.5-1.2.dsc Changes since the last upload: transmission (4.0.5-1.2) unstable; urgency=medium . [ Alexandre Rossi] * Non-maintainer upload. * build webapp from source (Closes: #1041519) * fix build on bookworm . [ Sandro Tosi ] * remove myself from this package maintainership I have not been able to get feedback from the maintainers and I feel they lack time or interest in the package. My fix has been provided as a PR[1] for a couple of weeks now. As I am a user and a DM, I could take over maintainance if that's wanted, or provide any level of required support in that context. lintian error note: my upload contains a lintian error source-is-missing and source-ships-excluded-file. As this is a NMU, I chose not to change upstream tarball and restrict to fixing the RC bug and FTBS in bookworm for backports. Again, if I get ack from maintainers, I can prepare an upload cleaning up these. Regards, -- Alexandre Rossi
Bug#1067625: FTBFS on armel: undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0'
Hi, > /usr/bin/ld: ../../libtransmission/libtransmission.a(web.cc.o): undefined > reference to symbol '__atomic_load_8@@LIBATOMIC_1.0' > /usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: error adding symbols: DSO > missing from command line As transmission does not link directly to libatomic, it is likely that this bug should be reassigned to the dependency that brings in libatomic, maybe gcc. Thanks, Alex
Bug#1041519: transmission: contains prebuilt javascript without source
Hi, > This bug has been open for eight months now. It caused transmission to be > removed from testing twice, in August and March. It's labeled "severity: > serious" and "tags: patch". > > How can we help to get the patch applied and the bug fixed? > > I would love to use this package in testing, and more importantly I really > want to use this in the next stable. > > Thanks a lot for your work, everyone! > > Alexandre Rossi: > > I gave it a try and published my current status. Advice will be > > appreciated. > > https://salsa.debian.org/debian/transmission/-/merge_requests/16 I'm also available to prepare an upload, but would need sponsorship. >From my point of view, the solution provided is satisfactory and fixes the problem. I'm a user have been happily running a build with my patch for months. I've had no feedback from the maintainers since January I think. Thanks, Alex
Bug#1063911: davmail-server.service fails in a LXC container
Hi, > > PR_SET_MM_ARG_START failed: Operation not permitted > > > > run-rd2fa855982314217b00729153ec6dd8b.service: Failed to update dynamic > > user credentials: Permission denied > > > > run-rd2fa855982314217b00729153ec6dd8b.service: Failed at step USER spawning > > /usr/bin/true: Permission denied > > This seems similar to this old issue. > > https://github.com/systemd/systemd/issues/9493 > > What is your host kernel version? > > What is your lxc conf? Feeling like this is an old issue and not related to davmail, I'm closing this. Feel free to come back to me if you feel like I'm wrong. Cheers, Alex
Bug#1065996: uwsgi: Please drop dependencies on python3-distutils
Hi, > This package has dependencies, build-dependencies and/or autopkgtest > dependencies on python3-distutils. The python3-distutils binary > package will soon be dropped from python3-stdlib-extensions. > > In fact, there is no module for Python 3.12 in python3-distutils, so > these dependencies may already be unnecessary. Fixed in https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/393456a602352e8ad0373dc72aa1a40fd09c333f Thanks, Alex
Bug#1065460: uwsgi: the package fails to build from source due to missing 'plugins/rack_ruby32'
Hi, > The package fails to build in sid chroot with the following error: > > -- > *** uWSGI building and linking plugin plugins/rack_ruby32 *** > Error: unable to find directory 'plugins/rack_ruby32' > make: *** [debian/rules:429: debian/stamp-uwsgi-plugin-rack-ruby3.2] Error 1 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 > > Build finished at 2024-03-04T23:36:17Z There is something strange because the default ruby version in sid is 3.1 and uwsgi 2.0.24-2 builds just fine on my sid chroot, see below. Thanks, Alex -- UWSGICONFIG_RUBYPATH=/usr/bin/ruby3.1 \ CFLAGS="-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" python3 uwsgiconfig.py -v --plugin plugins/rack debian/buildconf/uwsgi-plugin.ini rack_ruby31 using profile: debian/buildconf/uwsgi-plugin.ini detected include path: ['/usr/lib/gcc/x86_64-linux-gnu/13/include', '/usr/local/include', '/usr/include/x86_64-linux-gnu', '/usr/include'] *** uWSGI building and linking plugin plugins/rack *** x86_64-linux-gnu-gcc -fPIC -shared -o ./rack_ruby31_plugin.so -I. -O2 -I. -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wformat-signedness -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -DUWSGI_HAS_IFADDRS -DUWSGI_ZLIB -DUWSGI_LOCK_USE_MUTEX -DUWSGI_EVENT_USE_EPOLL -DUWSGI_EVENT_TIMER_USE_TIMERFD -DUWSGI_EVENT_FILEMONITOR_USE_INOTIFY -DUWSGI_PCRE2 -DUWSGI_ROUTING -DUWSGI_CAP -DUWSGI_UUID -DUWSGI_VERSION="\"2.0.24-debian\"" -DUWSGI_VERSION_BASE="2" -DUWSGI_VERSION_MAJOR="0" -DUWSGI_VERSION_MINOR="24" -DUWSGI_VERSION_REVISION="0" -DUWSGI_VERSION_CUSTOM="\"debian\"" -DUWSGI_YAML -DUWSGI_LIBYAML -I/usr/include/yajl -DUWSGI_JSON -DUWSGI_JSON_YAJL -DUWSGI_SSL -I/usr/include/libxml2 -DUWSGI_XML -DUWSGI_XML_LIBXML2 -DUWSGI_PLUGIN_DIR="\".\"" -g -O2 -ffile-prefix-map=BUILDDIR=. -fstack-protector-strong -fstack-clash-protection -fcf-protection -fPIC -DRUBY19 -DRUBY27 -I/usr/include/ruby-3.1.0 -I/usr/lib/x86_64-linux-gnu/ruby/3.1.0 -I/usr/lib/x86_64-linux-gnu/ruby/3.1.0/x86_64-linux-gnu -I/usr/include/ruby-3.1.0/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu/ruby-3.1.0 -Drack_plugin=rack_ruby31_plugin plugins/rack/rack_plugin.c plugins/rack/rack_api.c -Wl,-z,relro -L. -Wl,-z,now -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,--no-as-needed -L/usr/lib -lm -lruby-3.1 build time: 2 seconds *** rack_ruby31 plugin built and available in ./rack_ruby31_plugin.so *** touch debian/stamp-uwsgi-plugin-rack-ruby3.1
Bug#1065535: RFS: libjs-jush/2.0.2+git20210206+1-1 [ITP] -- JavaScript Syntax Highlighter
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libjs-jush": * Package name : libjs-jush Version : 2.0.2+git20210206+1-1 Upstream contact : Jakub Vrana * URL : https://jush.sourceforge.io/ * License : Apache-2.0 * Vcs : https://salsa.debian.org/js-team/libjs-jush Section : web The source builds the following binary packages: libjs-jush - JavaScript Syntax Highlighter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libjs-jush/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libj/libjs-jush/libjs-jush_2.0.2+git20210206+1-1.dsc This is a dependency of adminerevo which I request to maintain as a DM. An older and partial version is already in src:javascript-goodies, and I'll fill a bug to avoid duplication if this package ever reaches unstable. Regards, -- Alexandre Rossi
Bug#1065534: RFS: adminerevo/4.8.3-1 [ITP] -- Web-based database administration tool
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "adminerevo": * Package name : adminerevo Version : 4.8.3-1 Upstream contact : Lionel Laffineur * URL : https://docs.adminerevo.org/ * License : MIT, Apache-2.0 * Vcs : https://salsa.debian.org/debian/adminerevo Section : web The source builds the following binary packages: adminerevo - Web-based database administration tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/adminerevo/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/a/adminerevo/adminerevo_4.8.3-1.dsc This is a fork of adminer which is already in Debian and seems unmaintained upstream. Iv'e been maintaining adminer for some time as a DM and would like to continue with adminerevo. Regards, -- Alexandre Rossi
Bug#1063911: davmail-server.service fails in a LXC container
Hi, Relevant lines: > PR_SET_MM_ARG_START failed: Operation not permitted > > run-rd2fa855982314217b00729153ec6dd8b.service: Failed to update dynamic > user credentials: Permission denied > > run-rd2fa855982314217b00729153ec6dd8b.service: Failed at step USER spawning > /usr/bin/true: Permission denied This seems similar to this old issue. https://github.com/systemd/systemd/issues/9493 What is your host kernel version? What is your lxc conf? Thanks, Alex
Bug#1063911: davmail-server.service fails in a LXC container
Hi, > The issue is repeatable with a fresh install of a Debian 12 LXC container: > [...] > The problem goes away if DynamicUser is commented out in service unit: > [...] > I have no idea why it would work in a VM and not in a LXC container. I doubt this is a problem that will need a change in davmail. Container related issues are usually not fixed in user applications. What is the result of the following line in a LXC container? (lxc)$ systemd-run --property=DynamicUser=yes /usr/bin/true Are there any kernel messages (i.e. journalctl -t kernel) when the failure happens? We're looking for some permission denied stuff. My guess is that your lxc setup requires extra permissions for this to work. Thanks, Alex
Bug#770331: graphite-web: aliasByNode() gets upset by 'odd' characters in data paths
Version: 1.0.2+debian-1 Hi, This seems to have been fixed in upstream commit: https://github.com/graphite-project/graphite-web/commit/b71f0e01b7b8b90f8124fabcc591c1f77e04ffc3 And released in 1.0.0 (from what I can see in the changelog). Feel free to reopen if I'm mistaken. Thanks, Alex
Bug#1061752: Opened MR
Hi, I opened a MR to fix the issue. I can also prepare an upload if wanted. https://salsa.debian.org/python-team/packages/python-django-tagging/-/merge_requests/3 Thanks, Alex
Bug#1061469: fix awaiting sponsorhip
Hi, Fix awaiting sponsorship at mentors.d.o . https://mentors.debian.net/package/adminer/ Thanks, Alex
Bug#1061469: phpX.Y-mysql does not provide php-mysql virtual package
Hi,
Thanks for the report.
> As per Ondřej's note below, with regards to MySQL support, from a glance
> through the source code (adminer/drivers/mysql.inc.php) it seems that
> adminer should depend on php-mysql (real metapackage) OR php-mysqli
> (virtual package provided by real phpX.Y-mysql package - i.e. currently
> php8.2-mysql).
>
> On 25/1/24 16:05, Ondřej Surý wrote:
> > The extension package provide names of the extensions actually provided by
> > the said package. “mysql” extension has been removed from PHP a quite a
> > while ago and is not provided by php8.2-mysql package. (Similar situation
> > can be found in php8.2-xml package.)
> >
> > This needs to be fixed in the adminer, so it actually depends on an
> > extension it actually uses.
> >
> > Ondrej
> > --
> > Ondřej Surý (He/Him)
> >
>
> Please find a patch attached to resolve this issue - #1061469. Hopefully
> I got it right?
I've been wrapping my head around this and still fail to understand
the actual problem.
php-mysql depends on php8.2-mysql which provides php-mysqli and
contains mysqli.so
For adminer, adding an alternate dependency to php-mysqli would
tighten (adminer actually requires mysqli.so or pdo_mysql.so loaded in
PHP for mysql interaction). But then why keep the dependency on
php-mysql?
The patch becomes:
diff --git a/debian/control b/debian/control
index 35a3f2a..43b2d7d 100644
--- a/debian/control
+++ b/debian/control
@@ -14,11 +14,11 @@ Package: adminer
Architecture: all
Depends:
libapache2-mod-php | php-cgi | php-fpm | php,
- php-mysql | php-sqlite3 | php-pgsql,
+ php-mysqli | php-pdo-mysql | php-sqlite3 | php-pgsql,
${misc:Depends},
Recommends:
php-cli,
- php-mysql,
+ php-mysqli,
php-pgsql,
php-sqlite3,
${misc:Recommends},
Or is there something I missed?
Alex
Bug#1055329: Offer of support/assistance
Hi, > My name is Jeremy and I'd like to offer you my support and assistance in > your efforts to package and maintain AdminerEvo if that's of any use to you? Many thanks for your offer and your are welcome to help for this. I had forgotten to post a status update on this particular work item: the work is essentially done, I'm just seeking a Debian developper (I'm not) to upload the new package to the Debian archive and grant me access for further uploads. Thanks, Alex
Bug#1054574: adminer seems dead upstream, switch to adminerevo ?
Hi, Status update: the work is done. src:adminerevo and packaged dependency are awaiting sponsorship. https://mentors.debian.net/package/libjs-jush/ https://mentors.debian.net/package/adminerevo/ Thanks, Alex
Bug#1040603: Bug#1042027: transmission 4.0.5-1
Hi, > > please push this packaging effort to a personal (but publicly > > accessible) git repo on salsa, so that i can cherry pick the changes i > > like, thanks > > Here: > > > https://salsa.debian.org/niol/transmission/-/tree/master-candidate?ref_type=heads I've also updated my pull request to make it easier to review cherry-picking the appropriate change. https://salsa.debian.org/debian/transmission/-/merge_requests/16 Thanks, Alex
Bug#998024: rsass as alternative
Hi, rsass can appropriately compile sass files which is convenient for Debian packaging. Thanks, Alex
Bug#1040603: Bug#1042027: transmission 4.0.5-1
Hi, > > A fixed version is awaiting sponsorship at: > > > > https://mentors.debian.net/package/transmission/ > > please push this packaging effort to a personal (but publicly > accessible) git repo on salsa, so that i can cherry pick the changes i > like, thanks Here: https://salsa.debian.org/niol/transmission/-/tree/master-candidate?ref_type=heads Thanks, Alex
Bug#1040603: transmission 4.0.5-1
Hi, A fixed version is awaiting sponsorship at: https://mentors.debian.net/package/transmission/ I'll also do my best to fix any issues regarding this proposed 4.0.5-1 update. Thanks, Alex
Bug#1060071: ITP: libjs-jush -- JavaScript Syntax Highlighter
> Package: wnpp > Severity: wishlist > > * Package name: libjs-jush > Version : 2.0.2+git20210206+1 > Upstream Contact: Jakub Vrana > * URL : https://jush.sourceforge.io/ > * License : Apache-2.0 > Programming Lang: JavaScript > Description : JavaScript Syntax Highlighter Preliminary packaging available at https://salsa.debian.org/niol/libjs-jush Alex
Bug#1060071: ITP: libjs-jush -- JavaScript Syntax Highlighter
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: libjs-jush Version : 2.0.2+git20210206+1 Upstream Contact: Jakub Vrana * URL : https://jush.sourceforge.io/ * License : Apache-2.0 Programming Lang: JavaScript Description : JavaScript Syntax Highlighter JavaScript Syntax Highlighter can be used for client-side syntax highlighting of following languages: HTML, CSS, JavaScript, PHP, SQL, HTTP and SMTP protocol, php.ini and Apache config. This is required to build the database web interface adminerevo (ITP #1055329). This has been embedded in src:adminer for years. Part of it is available in src:jquery-goodies .
Bug#1053988: transmission-gtk 3.00-1 : *** invalid %N$ use detected *** - Abandon
tag 1053988 fixed-upstream tag 1053988 patch fixed 1053988 4.0.1-1 thanks Hi, This appears to be the same as https://github.com/transmission/transmission/issues/1353 This appears to be specific to LANG=fr_FR.utf8 . A workaround is launching with: $ LANG=C transmission-gtk The fix appears to be: diff -Nru transmission-3.00.old/po/fr.po transmission-3.00/po/fr.po --- transmission-3.00.old/po/fr.po 2020-05-22 13:04:23.446805271 +0200 +++ transmission-3.00/po/fr.po 2023-12-08 14:37:09.754589884 +0100 @@ -1345,7 +1345,7 @@ #: ../gtk/torrent-cell-renderer.c:268 #, c-format msgid "Downloading from %1$'d of %2$'d %3$s and %4$'d %5$s" -msgstr "Téléchargement à partir %1$'d sur %2'd %3$s et %4$'d %5$s" +msgstr "Téléchargement à partir %1$'d sur %2$'d %3$s et %4$'d %5$s" #: ../gtk/torrent-cell-renderer.c:270 ../gtk/torrent-cell-renderer.c:276 msgid "web seed" I can prepare a stable upload if someone is interested to sponsor the upload. Thanks, Alex
Bug#1053988: transmission-gtk 3.00-1 : *** invalid %N$ use detected *** - Abandon
severity 1053988 important thanks Hi, Lowering severity as transmission-daemon works well. Thanks, Alex
Bug#1056067: ITP: node-sass-loader -- css loader module for webpack
Hi, Package is awaiting sponsorship at https://mentors.debian.net/package/node-sass-loader/ Packaging is available at https://salsa.debian.org/niol/node-sass-loader Thanks, Alex
Bug#1056067: ITP: node-sass-loader -- css loader module for webpack
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: node-sass-loader Version : 13.3.2 Upstream Contact: J. Tangelder * URL : https://github.com/webpack-contrib/sass-loader * License : MIT Programming Lang: Javascript Description : css loader module for webpack Webpack takes code targeted at node.js and makes it run in the browser. Node.js comes with API of its own that is not available in the browsers. Webpack exposes this code to programs that are unaware they are running in a browser. Sass is a CSS preprocessor to include features that don’t exist in CSS yet like nesting, mixins, inheritance, and other nifty goodies that help write robust, maintainable CSS. This package is enables webpack to include and compile Sass files into a web application bundle. Node.js is an event-based server-side JavaScript engine. This is required to build some webapps. I'll be seeking a sponsor for this. Thanks, Alex
Bug#1041519: transmission: contains prebuilt javascript without source
> The source package contains: > > web/public_html/index.html > web/public_html/transmission-app.js > > These files are copied into the binary package as: > > /usr/share/transmission/public_html/index.html > /usr/share/transmission/public_html/transmission-app.js > > Those files should be built from source with no network connection. Hi, I gave it a try and published my current status. Advice will be appreciated. https://salsa.debian.org/debian/transmission/-/merge_requests/16 Thanks, Alex
Bug#1055329: ITP: adminerevo -- Web-based database administration tool
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: adminerevo Version : 4.8.3 Upstream Contact: Lionel Laffineur * URL : https://docs.adminerevo.org/ * License : Apache-2.0 Programming Lang: PHP Description : Web-based database administration tool Adminerevo (forked from adminer) is a full-featured database management tool written in PHP. Conversely to phpMyAdmin, it is a light weight application with these priorities in order: security, user experience, performance, feature set and size. adminerevo is a community maintained version of adminer. Ultimately, src:adminer will be removed from the archive. adminerevo would then provide a transitional dummy pakage. This will be maintained on salsa in the Debian group. I already maintain src:adminer as a DM and will need a sponsor for this new package. Thanks, Alex
Bug#1054574: adminer seems dead upstream, switch to adminerevo ?
Hi, > according to git activity and comments in the issues, adminer seems dead > upstream. > > Part of the community have forked it into adminerevo: > > https://docs.adminerevo.org/ > > Would you consider packaging that instead of adminer ? Yes, I'm thinking about it and I'm wondering on the strategy regarding upgrades. Options are: 1) new package src:adminerevo providing adminer and removal of src:adminer Advantages : explicit branding 2) src:adminer using adminerevo source and building adminer pkg Advantages : easy upgrade path (no Provides:, Conflicts:, no conffile moving around in postinst) 3) src:adminer using adminerevo source and building adminerevo pkg Advantages : explicit branding for binary package and easier going back if src:adminer ever comes back alive Maybe Chris can advise here. Thanks, Alex
Bug#1052845: python-django-tagging: FTBFS: raise FullResultSet
Hi, Seems like this is fixed in: https://salsa.debian.org/python-team/packages/python-django-tagging/-/merge_requests/2 Thanks, Alex
Bug#1053146: nmu: uwsgi-plugin-php_2.0.22+1+0.0.15+b1 uwsgi-plugin-luajit_2.0.22+1+0.0.8+b1 uwsgi-plugin-mongo_2.0.22+1+0.0.9+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: uwsgi-plugin-...@packages.debian.org, d...@jones.dk Control: affects -1 + src:uwsgi-plugin-php Control: affects -1 + src:uwsgi-plugin-luajit Control: affects -1 + src:uwsgi-plugin-mongo Hi, uwsgi.h changed again, and uwsgi ABI id is derived from that file, so a rebuild is required for plugins to depend on the correct uwsgi-abi binary package. nmu uwsgi-plugin-php_2.0.22+1+0.0.15+b1 . ANY . unstable . -m "rebuild against new uwsgi.h" nmu uwsgi-plugin-luajit_2.0.22+1+0.0.8+b1 . ANY . unstable . -m "rebuild against new uwsgi.h" nmu uwsgi-plugin-mongo_2.0.22+1+0.0.9+b1 . ANY . unstable . -m "rebuild against new uwsgi.h" Thanks!
Bug#1051752: [pkg-uWSGI-devel] Bug#1051752: uwsgi: remove uwsgi-plugin-glusterfs on 32 bit architectures)
Hi Jonas, > > If I get some advice on the best practrices for having d/control.in with > > template variables, I would be happy to work on this. > > I assume you mean the debian/control file (as the uwsgi source package > currently contains no debian/control.in file). > That file gets mangled when the following command is executed: > > DEB_MAINTAINER_MODE=1 debian/control clean I thought that using some template engine and introducing d/control.in would be easier to maintain, debug than the current mangling and was wondering what was considered good practice for this in Debian packaging. I'll research. Thanks for the upload, Alex
Bug#1051752: [pkg-uWSGI-devel] Bug#1051752: uwsgi: remove uwsgi-plugin-glusterfs on 32 bit architectures)
Hi, Following attempted fixes of #1051752, please not that I seem to have fixed it (tested on i386) in https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/5cdb4e37be8dd93cefdcceeb199efe990b2eb918 . If I get some advice on the best practrices for having d/control.in with template variables, I would be happy to work on this. Thanks, Alex
Bug#1052033: davmail: Davmail uses too much memory
Hi, > Upon launch Davmail uses 7.5GiB of virtual memory and 107.8MiB of > resident memory but, after using it for about a day, 7.6GiB of virtual > memory and 686MiB of resident memory. Given that davmail only needs to > keep a very small state, that seems to point to a memory leak. I have prepared a change that may improve things a bit following upstream suggested JVM arguments. I would add that in Java, memory is mostly not managed by the program so memory leaks cannot happen (although useless mamory usage can happen). Regrading Java applications memory usage, you can read[1]. I'm not sure more can be done on this. [1] https://stackoverflow.com/a/561450 Thanks, Alex
Bug#1039408: uwsgi: ships sysv-init script without systemd unit
Hi, > uwsgi has been flagged by Lintian as shipping a sysv-init script > without a corresponding systemd unit file. The default init system in > Debian is systemd, and so far this worked because a transitional > sysv-init-to-unit generator was shipped by systemd. This is in the > process of being deprecated and will be removed by the time Trixie > ships, so the remaining packages that ship init scripts without > systemd units will stop working. [...] > In case this is a false positive, please add a Lintian override to > silence it and then close this bug. My view on this is that the following template units provided by uwsgi-core enable the initscript functionality. /lib/systemd/system/uwsgi-app@.service /lib/systemd/system/uwsgi-app@.socket See full change[1] for documentation. >From the initscript documentation[2] and a quick look at the script, it seems that it manages multiple uwsgi services from a directory of configuration files. I think think if using systemd that it is better managed using template units. The above template lack supports for multiple type of configuration files, assume INI, but this is easily fixable by overriding the units. uwsgi-emperor[3], from my understanding, does the same, and thus does not need an initscript or systemd service unit. My conclusion is that this is already fixed and that a lintian override is relevant here, but I do not know if I'm missing something. Thanks. [1] https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/bfb4ef445ad0168483638301090dc2d56e8e2278 [2] https://salsa.debian.org/uwsgi-team/uwsgi/-/blob/bfb4ef445ad0168483638301090dc2d56e8e2278/debian/uwsgi.README.Debian [3] https://uwsgi-docs.readthedocs.io/en/latest/Emperor.html
Bug#1042524: nmu: uwsgi-plugin-luajit_2.0.21+3+0.0.8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: uwsgi-plugin-lua...@packages.debian.org Control: affects -1 + src:uwsgi-plugin-luajit Hi, The uwsgi ABI has changed and some of the plugin need a binNMU. Many thanks. nmu uwsgi-plugin-luajit_2.0.21+3+0.0.8 . ANY . unstable . -m "rebuild against changed uwsgi ABI"
Bug#1042523: nmu: uwsgi-plugin-mongo_2.0.21+3+0.0.9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: uwsgi-plugin-mo...@packages.debian.org Control: affects -1 + src:uwsgi-plugin-mongo Hi, The uwsgi ABI has changed and some of the plugin need a binNMU. Many thanks. nmu uwsgi-plugin-mongo_2.0.21+3+0.0.9 . ANY . unstable . -m "rebuild against changed uwsgi ABI"
Bug#1042522: nmu: uwsgi-plugin-php_2.0.21+4+0.0.15
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: uwsgi-plugin-...@packages.debian.org Control: affects -1 + src:uwsgi-plugin-php Hi, The uwsgi ABI has changed and some of the plugin need a binNMU. Many thanks. nmu uwsgi-plugin-php_2.0.21+4+0.0.15 . ANY . unstable . -m "rebuild against changed uwsgi ABI"
Bug#999936: uwsgi: depends on obsolete pcre3 library
Hi,
> > > > > Your package still depends on the old, obsolete PCRE3[0] libraries
> > > > > (i.e. libpcre3-dev). This has been end of life for a while now, and
> > > > > upstream do not intend to fix any further bugs in it. Accordingly, I
> > > > > would like to remove the pcre3 libraries from Debian, preferably in
> > > > > time for the release of Bookworm.
> > > >
> > > > I gave it go, it compiles.
> > > > https://github.com/unbit/uwsgi/pull/2543
> > > >
> > > > Hopefully, I will find time in the coming weeks to test with some
> > > > routing patterns.
> > >
> > > Sounds great. Thanks for looking into this!
> >
> > I have something that seems to work. Do you want me to prepare an upload
> > and *force* feedback through unstable or wait for feedback as is?
>
> I am ok taking the risk of releasing it to unstable. Let me do that
> right away...
Seems like uwsgi-plugin-{luajit,mongo,php} need a binNMU or an upload
due to uwsgi ABI change.
Let me know if help is needed regarding this.
Alex
Bug#999936: uwsgi: depends on obsolete pcre3 library
Hi, > > > Your package still depends on the old, obsolete PCRE3[0] libraries > > > (i.e. libpcre3-dev). This has been end of life for a while now, and > > > upstream do not intend to fix any further bugs in it. Accordingly, I > > > would like to remove the pcre3 libraries from Debian, preferably in > > > time for the release of Bookworm. > > > > I gave it go, it compiles. > > https://github.com/unbit/uwsgi/pull/2543 > > > > Hopefully, I will find time in the coming weeks to test with some > > routing patterns. > > Sounds great. Thanks for looking into this! I have something that seems to work. Do you want me to prepare an upload and *force* feedback through unstable or wait for feedback as is? Alex
Bug#999936: uwsgi: depends on obsolete pcre3 library
Hi, > Your package still depends on the old, obsolete PCRE3[0] libraries > (i.e. libpcre3-dev). This has been end of life for a while now, and > upstream do not intend to fix any further bugs in it. Accordingly, I > would like to remove the pcre3 libraries from Debian, preferably in > time for the release of Bookworm. I gave it go, it compiles. https://github.com/unbit/uwsgi/pull/2543 Hopefully, I will find time in the coming weeks to test with some routing patterns. Alex
Bug#1041519: transmission: contains prebuilt javascript without source
Source: transmission Version: 4.0.1-1 Severity: serious Justification: Policy 2.2.1 Hi, The source package contains: web/public_html/index.html web/public_html/transmission-app.js These files are copied into the binary package as: /usr/share/transmission/public_html/index.html /usr/share/transmission/public_html/transmission-app.js Those files should be built from source with no network connection. The corresponding lintian overrides are wrong: the files are not generated during build. # these are generated from web/src/* transmission source: source-is-missing [web/public_html/index.html] transmission source: source-is-missing [web/public_html/transmission-app.js] The sad way to solve this would be to remove the webui (and I'm a user!). The better way to solve this would be to build and would begin like the following but requires packaging some of the below npm deps. I can help and would appreciate some guidance or pointers to good examples of source packages that have solved this problem. --- a/debian/control +++ b/debian/control @@ -21,7 +21,9 @@ Build-Depends: cmake, qttools5-dev-tools, qttools5-dev, libqt5svg5-dev, - zlib1g-dev + zlib1g-dev, + node-webpack, + node-mini-css-extract-plugin Standards-Version: 4.6.2 Rules-Requires-Root: no Vcs-Browser: https://salsa.debian.org/debian/transmission diff --git a/debian/rules b/debian/rules index 09fe4f7d..bfed98c1 100755 --- a/debian/rules +++ b/debian/rules @@ -2,12 +2,13 @@ #export DH_VERBOSE=1 export DEB_BUILD_MAINT_OPTIONS = hardening=+all +export NPM_CONFIG_OFFLINE=true %: dh $@ override_dh_auto_configure: - dh_auto_configure -- -DENABLE_GTK=ON -DENABLE_QT=ON -DENABLE_CLI=ON -DINSTALL_LIB=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo + dh_auto_configure -- -DENABLE_GTK=ON -DENABLE_QT=ON -DENABLE_CLI=ON -DINSTALL_LIB=OFF -DREBUILD_WEB=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo override_dh_auto_test: @echo "skipping auto test" Thanks, Alex -- transmission.git/web$ npm2deb depends package.json Dependencies: NPM Debian transmission-web (FIX_ME version) None └─ lodash.isequal (^4.5.0)node-lodash (4.17.21+dfsg+~cs8.31.198.20210220-9) Build dependencies: NPM Debian @babel/core (^7.20.12)node-babel (6.26.0+repack-3~bpo10+1) @babel/eslint-parser (^7.19.1) None @babel/plugin-proposal-class-properties (^7.18.6) None @primer/stylelint-config (^12.7.0)None css-loader (^6.7.3) node-css-loader (6.7.2+~cs14.0.11-1) css-minimizer-webpack-plugin (^4.2.2) None eslint (^8.32.0) None eslint-plugin-sonarjs (^0.18.0) None eslint-plugin-unicorn (^45.0.2) None file-loader (^6.2.0) node-file-loader (6.2.0-3) mini-css-extract-plugin (^2.7.2) node-mini-css-extract-plugin (2.4.6+~2.4.0-4)npm-run-all (^4.1.5) None prettier (^2.8.3) None sass (^1.57.1)None sass-loader (^13.2.0) None style-loader (^3.3.1) node-style-loader (3.3.1-2) stylelint (^14.16.1) None stylelint-config-prettier (^9.0.4)None stylelint-config-sass-guidelines (^9.0.1) None stylelint-config-standard (^29.0.0) None terser-webpack-plugin (^5.3.6)None webpack (^5.76.0) node-webpack (5.76.1+dfsg1+~cs17.16.16-1)webpack-bundle-analyzer (^4.7.0) None webpack-cli (^4.10.0) None webpack-dev-server (^4.11.1) None Warnings occurred: [warning] prettier: Useless in Debian compilation, see node-jest for an example -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1039509: davmail: autopkgtest regression on ppc64el: Exception in thread "Shutdown"
tag patch fixed-upstream
thanks
Hi,
> davmail.connection - DISCONNECT - 127.0.0.1:41156 60s Exception in thread
> "Shutdown" java.lang.IllegalMonitorStateException: current thread is not
> owner
> 60s 2023-06-24 23:58:12,579 INFO [Shutdown] davmail - DavMail gateway
> stopped
> 60s at java.base/java.lang.Object.notifyAll(Native Method)
> 60s at davmail.DavGateway$1.run(DavGateway.java:100)
> 60s autopkgtest [23:58:12]: test binary-starts
This does not happen a lot and I cannot reproduce.
This seems to be fixed upstream in:
https://github.com/mguessan/davmail/commit/853854fda70f7731af2caff7504d8b7bc7653db4
So I'll upload a new revision with this fix cherry-picked and hope for the best.
Thanks,
Alex
>From 853854fda70f7731af2caff7504d8b7bc7653db4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micka=C3=ABl=20Guessant?=
Date: Mon, 20 Mar 2023 08:55:01 +
Subject: [PATCH] Fix from audit
git-svn-id: https://svn.code.sf.net/p/davmail/code/trunk@3424
3d1905a2-6b24-0410-a738-b14d5a86fcbd
---
src/java/davmail/DavGateway.java | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/java/davmail/DavGateway.java b/src/java/davmail/DavGateway.java
index 34d81ab3..f7a17995 100644
--- a/src/java/davmail/DavGateway.java
+++ b/src/java/davmail/DavGateway.java
@@ -96,7 +96,9 @@ public static void main(String[] args) {
public void run() {
DavGatewayTray.debug(new
BundleMessage("LOG_GATEWAY_INTERRUPTED"));
DavGateway.stop();
-LOCK.notifyAll();
+synchronized (LOCK) {
+LOCK.notifyAll();
+}
}
});
Bug#1035007: davmail-server: missing Breaks+Replaces for davmail when upgrading from bullseye
Hi, > Attempting to unpack davmail-server/6.0.1.3390-6 from Debian bookworm > on a minimal Debian bullseye with davmail/5.5.1.3299-5 > installed, causes an unpack error from dpkg due to > /etc/davmail/davmail.properties being contained in both packages. Yes I can reproduce. You should remove davmail before. > Please ensure that davmail-server has sufficient Breaks and Replaces > declarations. I'm not sure I should add anything, because the upgrade works well: (bullseye-amd64-sbuild)root@skade:~# apt install davmail [...] (bullseye-amd64-sbuild)root@skade:~# sed -i 's/bullseye/bookworm/' /etc/apt/sources.list.d/debian.sources (bullseye-amd64-sbuild)root@skade:~# cat /etc/apt/sources.list.d/debian.sources Types: deb URIs: http://deb.debian.org/debian Suites: bookworm Components: main contrib non-free (bullseye-amd64-sbuild)root@skade:~# apt update [...] (bullseye-amd64-sbuild)root@skade:~# apt update && apt install davmail [...] Setting up davmail (6.0.1.3390-6) ... Removing obsolete conffile /etc/init.d/davmail ... [...] and all is well. Maybe this requires apt. Or do you suggest this manual install should be supported? Thanks, Alex
Bug#1032509: davmail: O365Interactive mode does not open web logon window - libraries not found on java path
Hi, Can you provide the exact error message in the console? Thanks, Alex When davmail tries to open a window to display the 365 logon screen it > fails because it can't find appropriate prism_*.so files. > > I had to change the -Djava.library.path=/usr/lib/jni argument in the > launch script to > -Djava.library.path=/usr/lb/jni:/usr/x86_64-linux-gnu/jni > to get it to work. (Obviously this is architecture dependent.) >
Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy
Hi, > I'm +1 for the change, but at this point I propose we wait for bookworm > to release. I'm not sure what could go wrong, but it seems late in the > release cycle for this change. How about an upload to experimental? An upload to experimental would be great. Thanks, Alex
Bug#1028350: davmail: autopkgtest regression on arm64, armhf and ppc64el
Hi, All is good now, #1028374 is fixed. No change regarding this is required in davmail. Thanks, Alex
Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64
Hi, > > Thanks a lot but looks like the fix was not complete. > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029908 > > > > Can you upload a version with the fix available in the bug report? > > Done. This time I merged the commit from your repo on Salsa, and also > ran the autopkgtest on armhf. Thanks a lot. I also had ran the autopkgtest on armhf. It seems all is good now. FYI, the fix has been submitted upstream: https://github.com/java-native-access/jna/pull/1499 Many Thanks, Alexandre
Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64
Hi, > The update looks good to me and a rebuild of rdeps with ratt was > successful. Or more precisely, was successful for the packages that > also build against 5.12.1. So I have just uploaded to the archive. Thanks a lot but looks like the fix was not complete. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029908 Can you upload a version with the fix available in the bug report? Do not hesitate if you need some help to prepare the upload. Thanks a lot, Alex
Bug#1029908: libjna-java: JNA HelloWorld fails on armhf
Package: libjna-java Version: 5.13.0-1 Severity: normal Tags: patch Dear Maintainer, When trying the JNA tutorial Helloworld on aarch64, it fails with the following error message: autopkgtest [12:34:07]: test helloworld: [--- Jan 28, 2023 12:34:09 PM com.sun.jna.Native loadNativeDispatchLibrary INFO: Looking in /usr/lib/jni/libjnidispatch.system.so Jan 28, 2023 12:34:09 PM com.sun.jna.Native loadNativeDispatchLibrary INFO: Looking in /usr/lib/arm-linux-gnueabi/jni/libjnidispatch.system.so Jan 28, 2023 12:34:09 PM com.sun.jna.Native extractFromResourcePath INFO: Looking in classpath from jdk.internal.loader.ClassLoaders$AppClassLoader@19e0bfd for /com/sun/jna/linux-arm/libjnidispatch.so Exception in thread "main" java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/linux-arm/libjnidispatch.so) not found in resource path (debian/tests:/usr/share/java/jna.jar) at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1062) at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:1018) at com.sun.jna.Native.(Native.java:221) at HelloWorld$CLibrary.(HelloWorld.java:8) at HelloWorld.main(HelloWorld.java:14) autopkgtest [12:34:09]: test helloworld: ---] I succesfully tested a fix. https://salsa.debian.org/niol/libjna-java/-/commit/c69675faa352652e95439f528d6a3e1fda0d90ed Feel free to come back to me for a ready to upload package. Cheers, Alex -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libjna-java depends on: ii libjna-jni 5.13.0-1 libjna-java recommends no packages. libjna-java suggests no packages. -- no debconf information
Bug#1029076: closed by Jonas Smedegaard (reply to 1029...@bugs.debian.org) (Re: Bug#1029076: uwsgi-plugin-python3: built against non-default libpython3.11 / should always build agains
Hi, > > Sorry, but I fail to see any problem here. > > > > uwsgi _does_ build against the default Python. > > Yes, but the default Python it builds against in unstable is not necessarily > the default Python in testing. > > Right now, it is built against Python 3.11, while the default Python in > testing is 3.10. Hence, it does not work in testing (have you actually tried > that after my bug report?). What should be the correct fix for this? I see only : - hardcode the python version uwsgi builds against and follow testing Are their facilities providing the default python version that is in testing and available in sid? Or is this discrepancy between the default python in testing and in sid an rare event that we should workaround this time only? Thanks, Alex
Bug#958895: libevhtp-dev: libtool arguments failure
Hi, > > Now that the blocking bug is fixed, I thing the patch should be uploaded to > > unstable. > > Do you want me to prepare a build for you to upload? > > Yes, please do. An updated package is available on mentors. https://mentors.debian.net/package/libevhtp/ My commits are published at: https://sml.zincube.net/~niol/repositories.git/libevhtp/ Thanks, Alex
Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64
Hi, I prepared an updated package with the new upstream version. https://mentors.debian.net/package/libjna-java/ My commits are available at: https://salsa.debian.org/niol/libjna-java/ Thanks, Alex
Bug#995461: graphite-web: GRAPHITE_SETTINGS_MODULE should default to 'local_settings' when using graphite.wsgi
Hi, If I can help provide a build ready to upload for this, do not hesitate to ping me. Alex
Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy
Hi, If I can help providing a build ready to upload for this, do not hesitate to ping me. Alex
Bug#1000151: certbot.service: please provide some logs in journal
Hi, If I can help providing a build ready to upload for this, do not hesitate to ping me. Alex
Bug#958895: libevhtp-dev: libtool arguments failure
Hi, Now that the blocking bug is fixed, I thing the patch should be uploaded to unstable. Do you want me to prepare a build for you to upload? Thanks, Alex
Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64
tag 1028374 patch thanks > I suspect debian/patches/04-load-native-code-from-fs.patch needs fixing. Fix available for aarch64, and maybe the others (needs to get through CI to know). https://salsa.debian.org/java-team/libjna-java/-/merge_requests/1/diffs?commit_id=bdc5980e070e033e0c3b04bdb93a73506ac04791 Please advise as to how to move on. Thanks, Alex
Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64
Hi, With -Djna.debug_load.jna=true : niol@aarch64:~/libjna-java$ debian/tests/helloworld Jan 10, 2023 6:46:28 PM com.sun.jna.Native loadNativeDispatchLibrary INFO: Looking in /usr/lib/jni/libjnidispatch.system.so Jan 10, 2023 6:46:29 PM com.sun.jna.Native loadNativeDispatchLibrary INFO: Looking in /usr/lib/arm-linux-gnueabi/jni/libjnidispatch.system.so Jan 10, 2023 6:46:29 PM com.sun.jna.Native extractFromResourcePath INFO: Looking in classpath from jdk.internal.loader.ClassLoaders$AppClassLoader@73d16e93 for /com/sun/jna/linux-aarch64/libjnidispatch.so Exception in thread "main" java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/linux-aarch64/libjnidispatch.so) not found in resource path (debian/tests:/usr/share/java/jna.jar) at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1086) at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:1042) at com.sun.jna.Native.(Native.java:221) at HelloWorld$CLibrary.(HelloWorld.java:8) at HelloWorld.main(HelloWorld.java:14) libjna search for libjnidispatch.so as: /usr/lib/arm-linux-gnueabi/jni/libjnidispatch.system.so but it is present on the Debian system as: niol@aarch64:~/libjna-java$ dpkg -L libjna-jni | grep libjni /usr/lib/aarch64-linux-gnu/jni/libjnidispatch.system.so I suspect debian/patches/04-load-native-code-from-fs.patch needs fixing. Cheers, Alex
Bug#1028092: [pkg-uWSGI-devel] Bug#1028092: uwsgi-plugin-php FTBFS with PHP 8.2
Hi, > The fix seems straightforward, I'll see if I can provide a patch. The fix was indeed straightforward and tested successfully. https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/36aaa1dd685b446d0240f89e000b04fc6031e324 @Jonas, please ping me if you need some help to prepare the upload of uwsgi and uwsgi-plugin-php . Thanks, Alex
Bug#1028092: [pkg-uWSGI-devel] Bug#1028092: uwsgi-plugin-php FTBFS with PHP 8.2
Hi,
Thanks for reporting.
> /usr/src/uwsgi/plugins/php/php_plugin.c: In function ‘php_uwsgi_startup’:
> /usr/src/uwsgi/plugins/php/php_plugin.c:610:13: error: too many arguments to
> function ‘php_module_startup’
> 610 | if (php_module_startup(_sapi_module,
> _module_entry, 1)==FAILURE) {
> | ^~
> In file included from /usr/src/uwsgi/plugins/php/common.h:3,
> from /usr/src/uwsgi/plugins/php/php_plugin.c:1:
> /usr/include/php/20220829/main/php_main.h:28:20: note: declared here
>28 | PHPAPI zend_result php_module_startup(sapi_module_struct *sf,
> zend_module_entry *additional_module);
> |^~
Seems to be related to:
5. SAPI changes
* The signature of php_module_startup() has changed from
int php_module_startup(sapi_module_struct *sf, zend_module_entry
*additional_modules, uint32_t num_additional_modules)
to
zend_result php_module_startup(sapi_module_struct *sf, zend_module_entry
*additional_module)
as only one additional module was ever provided.
(from https://raw.githubusercontent.com/php/php-src/PHP-8.2/UPGRADING.INTERNALS
)
The fix seems straightforward, I'll see if I can provide a patch.
Thanks,
Alex
Bug#1028350: davmail: autopkgtest regression on arm64, armhf and ppc64el
Hi, Thanks for reporting, had seen this. My understanding is that the bug is in libjna-java and I've reproduced it, see #1028374. Plan A: I succeed to have a fix for libjna-java and get it uploaded before the end of January. Plan B: I revert debian/patches/sd-notify.patch to drop the dependecy on libjna-java and ensure transition to testing. Cheers, Alex
Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64 (and probably armhf, ppc64el)
Package: libjna-java Version: 5.12.1-1 Severity: important Dear Maintainer, When trying the JNA tutorial Helloworld on aarch64, it fails with the following error message: Exception in thread "main" java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/linux-aarch64/libjnidispatch.so) not found in resource path (debian/tests:/usr/share/java/jna.jar) at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1086) at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:1042) at com.sun.jna.Native.(Native.java:221) at HelloWorld$CLibrary.(HelloWorld.java:8) at HelloWorld.main(HelloWorld.java:14) The testcase has been proposed as an autopkgtest: https://salsa.debian.org/java-team/libjna-java/-/merge_requests/1 Reading autpkgtest results for davmail[1], it also fails with the same error on armhf and ppc64el. I have reproduced in a qemu arm64 image, although reporting this on amd64. I have tried with -Djava.library.path=/usr/lib/jni but it is not better. I can rebuild, and test and maybe look into this but would appreciate some guidance. Thank you, Alex -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libjna-java depends on: ii libjna-jni 5.12.1-1 libjna-java recommends no packages. libjna-java suggests no packages. -- no debconf information
Bug#1026975: ITP: python-toml -- library for parsing and creating TOML
Le dim. 25 déc. 2022 à 09:11:29 -03:00:00, Josenilson Ferreira da Silva a écrit : Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-toml Version : 0.10.2 Upstream Author : William Pearson * URL : https://github.com/uiri/toml * License : MIT/expat Programming Lang: Python Description : library for parsing and creating TOML this package is a dependency for "dom-toml" Where "dom-toml" is a required dependency for the "whey" package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021204 Already done? https://packages.debian.org/sid/python3-toml Alex
Bug#1027020: davmail-server: fails to install: insserv: script davmail-server: service davmail already provided!
Hi,
Thanks for your report.
> When trying to update davmail / install davmail-server I get:
>
>
> Setting up davmail-server (6.0.1.3390-3) ...
> insserv: script davmail-server: service davmail already provided!
> update-rc.d: error: no runlevel symlinks to modify, aborting!
> dpkg: error processing package davmail-server (--configure):
> installed davmail-server package post-installation script subprocess
> returned error exit status 1
[...]
> The reason seems to be that /etc/init.d/davmail is still around (and
> has "Provides. davmail")
Thanks for the pointer.
I'm tempted to do the following. Do you have an easy way to confirm it
works for you?
As the fix requires sysvinit, testing it will take me a bit more time.
Thanks,
Alex
--- a/debian/control
+++ b/debian/control
@@ -34,7 +34,7 @@ Package: davmail
Architecture: all
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends},
- davmail-server,
+ davmail-server (= ${binary:Version}),
default-jre,
libswt-cairo-gtk-4-jni,
libopenjfx-java,
diff --git a/debian/davmail-server.init b/debian/davmail-server.init
index eaa866c6..252141f2 100755
--- a/debian/davmail-server.init
+++ b/debian/davmail-server.init
@@ -1,6 +1,6 @@
#! /bin/sh
### BEGIN INIT INFO
-# Provides: davmail
+# Provides: davmail-server
# Required-Start:$local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
Bug#1025959: Feedback regarding RFS: davmail/6.0.1.3390-2
Hi, > > > * Review / improve the `prepare-service` > > > > This history behind this script is detailed in: > > > > startup script that copies keystoreFile to StateDirectory (Closes: #968236) > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968236 > > Seen the "adduser _davmail" advice. > And seeing that "adduser _davmail" in debian/davmail-server.postinst > (I didn't see that post install script yesterday) > > > The point is to make available private keys to the daemon. Do you think I > > need > > to add comments to the script to explain the purpose? > > Yes please, elaborate purpose AND elaborate the > > if keystore is a file then create keystore file https://salsa.debian.org/debian/davmail/-/commit/be580785dbd6a4232a2fe408c144ccfc80f93017 > What about doing this development in a git branch? https://salsa.debian.org/debian/davmail/-/tree/unstable-wip Many thanks for your review, Alexandre
Bug#1025959: Feedback regarding RFS: davmail/6.0.1.3390-2
Hi, > * Add the release "davmail (6.0.1.3390-1.1)" to packaging git repo Pushed. Further changes are awaiting upload to unstable before being pushed. > * Review / improve the `prepare-service` This history behind this script is detailed in: startup script that copies keystoreFile to StateDirectory (Closes: #968236) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968236 The point is to make available private keys to the daemon. Do you think I need to add comments to the script to explain the purpose? > * Make that `davmail-service` makes it into `davmail-server` package Fixed, thanks and sorry for that. > * Ping me New source package is on mentors. Alexandre
Bug#1025959: RFS: davmail/6.0.1.3390-2 -- POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway
Hi, > > The source builds the following binary packages: > > > > davmail - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway - GUI > > davmail-server - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway > > - headless > > The -server package is probably new. That's why I need a sponsor. > What about D.M. upload privileges? I have those, but because the -server package goes through NEW, it does not apply. Cheers and thanks, Alexandre
Bug#1025959: RFS: davmail/6.0.1.3390-2 -- POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "davmail": * Package name : davmail Version : 6.0.1.3390-2 Upstream contact : Mickaël Guessant * URL : http://davmail.sourceforge.net/ * License : GPL-2+-CE, CC0-1.0, GPL-2+, MIT * Vcs : https://salsa.debian.org/debian/davmail Section : net The source builds the following binary packages: davmail - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway - GUI davmail-server - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway - headless To access further information about this package, please visit the following URL: https://mentors.debian.net/package/davmail/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/davmail/davmail_6.0.1.3390-2.dsc Changes since the last upload: davmail (6.0.1.3390-2) unstable; urgency=medium . [ Gioele Barabucci ] * d/postinst: Check systemd via /sbin/init . [ Alexandre Rossi ] * Acknowledge 6.0.1.3390-1.1 NMU * add sd-notify.patch * update to policy 4.6.1.0 (no change) * fix depends-on-essential-package-without-using-version * update d/copyright year * clarify depends: split davmail (GUI) and davmail-server (Closes: #1018809) Regards, -- Alexandre Rossi
Bug#1018809: davmail: Depends: are too weak
Hi, > $ davmail > > Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load > library: /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so > at > java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2633) > > > I don't have this file on my system. If this file is required for > davmail to work, then the dependencies should have pulled it in. I see: > > $ apt-file find /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so > > openjdk-11-jre: /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so > > So I guess we need > > Depends: openjdk-11-jre The concept is: - for people who want to run headless, pull minimal dependencies - for people who want to run the graphical client, install more dependencies (see Suggests: default-jre, libswt-cairo-gtk-4-jni, libopenjfx-java) I do not see how to do it better, maybe switch to Recommends: ? Cheers, Alex
Bug#969251: 1.1.10
Hi, 1.1.10 seems to work well. Also in my MR: https://salsa.debian.org/debian-graphite-team/graphite-web/-/merge_requests/4 Alex
Bug#960396: web security flaws in src:adminer/4.7.1-1 in stable?
Hi, > > > We're in the process of arranging the final point release for > > > buster, > > > as support for it moves to the new LTS team. > > > > > > Is this something you're still interested in updating in buster? > > > > Yes, I even still have the built package ready for upload on > > mentors.d.o . > > > > In that case please feel free to get it uploaded, bearing in mind the > time constraints mentioned. After REJECTED (signature too old), debsign, REJECTED (not allowed as DM), the source upload is awaiting comments or sponsorship at mentors.d.o . https://mentors.debian.net/package/adminer/ https://mentors.debian.net/debian/pool/main/a/adminer/adminer_4.7.1-1+deb10u1.dsc Any issues, do not hesitate to come back to me. Many Thanks, Alexandre
Bug#960396: web security flaws in src:adminer/4.7.1-1 in stable?
Hi, > > > Thanks. Can you attach the debdiff between the current version in > > > buster and the proposed one to this bug? > > > > Here it is. > > > > Apologies for letting this sit for so long without a follow-up. No worries. > We're in the process of arranging the final point release for buster, > as support for it moves to the new LTS team. > > Is this something you're still interested in updating in buster? Yes, I even still have the built package ready for upload on mentors.d.o . Alex
Bug#1008965: lazygal: Crashes with illegal chars in IPTC keywords
Hi,
> > > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 2:
> > > invalid
> > > start byte
> > [...]
> > > File "/usr/lib/python3/dist-packages/lazygal/metadata.py", line 406, in
> > > get_keywords
> > > values = self._metadata.get_tag_multiple(key)
> > > SystemError: returned a result with an error set
>
> I do not have the same error.
> I have "double free or corruption (out)".
>
> $ exiv2 -g Iptc.Application2.Keywords lazygaltest/sample-bad-iptc-keywords.jpg
> Iptc.Application2.Keywords String 5 Anton
> Iptc.Application2.Keywords String 5 Bjrn
> So this is not a bug in exiv2 which correctly ignores the bad char.
>
> The raw tag reads b'Anton\x1c\x1c\x1c\x1cBj\xf6rn'. It is encoded in
> 'latin-1'.
>
> >>> b'\xf6'.decode('latin-1')
> 'ö'
> >>> 'ö'.encode('utf-8')
> b'\xc3\xb6'
>
> lazygal assumes utf-8 everywhere. I'll see what I can do to ignore this.
This is related to https://gitlab.gnome.org/GNOME/pygobject/-/issues/327 .
I may be wrong by I do not see any obvious way to fix this in lazygal.
Alex
Bug#1008965: lazygal: Crashes with illegal chars in IPTC keywords
Hi,
> > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 2:
> > invalid
> > start byte
> [...]
> > File "/usr/lib/python3/dist-packages/lazygal/metadata.py", line 406, in
> > get_keywords
> > values = self._metadata.get_tag_multiple(key)
> > SystemError: returned a result with an error set
I do not have the same error.
I have "double free or corruption (out)".
$ exiv2 -g Iptc.Application2.Keywords lazygaltest/sample-bad-iptc-keywords.jpg
Iptc.Application2.Keywords String 5 Anton
Iptc.Application2.Keywords String 5 Bjrn
So this is not a bug in exiv2 which correctly ignores the bad char.
The raw tag reads b'Anton\x1c\x1c\x1c\x1cBj\xf6rn'. It is encoded in 'latin-1'.
>>> b'\xf6'.decode('latin-1')
'ö'
>>> 'ö'.encode('utf-8')
b'\xc3\xb6'
lazygal assumes utf-8 everywhere. I'll see what I can do to ignore this,
Thanks,
Alex
Bug#1008965: lazygal: Crashes with illegal chars in IPTC keywords
Hi, > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 2: > invalid > start byte [...] > File "/usr/lib/python3/dist-packages/lazygal/metadata.py", line 406, in > get_keywords > values = self._metadata.get_tag_multiple(key) > SystemError: returned a result with an error set Can you provide a minimal failing image so I can reproduce? Thanks, Alex
Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy
Hi, > > I vaguely remember that replacing a symlink with a file during a package > > update was causing some issues (i.e. the target is updated but the symlink > > Wasn’t that only for directories? Seems to work: $ ls -la /usr/share/java/htmlcleaner* lrwxrwxrwx 1 root root 15 18 mars 18:20 /usr/share/java/htmlcleaner-2.26.jar -> htmlcleaner.jar -rw-r--r-- 1 root root 176219 18 mars 18:20 /usr/share/java/htmlcleaner.jar $ sudo dpkg -i oss/debian/davmail/libhtmlcleaner-java_2.26-1+fix+bad+jar+name+1_all.deb [...] $ ls -la /usr/share/java/htmlcleaner* -rw-r--r-- 1 root root 176219 23 mars 15:27 /usr/share/java/htmlcleaner-2.26.jar lrwxrwxrwx 1 root root 20 23 mars 15:27 /usr/share/java/htmlcleaner.jar -> htmlcleaner-2.26.jar Alex
Bug#1008143: nmu: uwsgi-plugin-php_2.0.20+2+0.0.13+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu uwsgi-plugin-php_2.0.20+2+0.0.13+b1 . ANY . unstable . -m "rebuilt against uwsgi-src 2.0.20+4 to fix #1007774" uwsgi-plugin-php is currently broken in unstable (see #1007774). src:uwsgi contains the source files for uwsgi-plugin-php and has been updated to include the fix in 2.0.20+4 .
Bug#1007774: [pkg-uWSGI-devel] Bug#1007774: Bug#1007774: uwsgi: php plugin broken with php8
Hi, > > For the uwsgi-plugin-php fix, a binNMU will then be required. > > I'll issue a release :-) Should we ask for the binNMU or do you have updates queued for uwsgi-plugin-php ? Alex
Bug#1007774: [pkg-uWSGI-devel] Bug#1007774: uwsgi: php plugin broken with php8
Hi, > > The following patch should fix the problem although I could not test yet > > because of > > #1007773 . > > > > https://github.com/unbit/uwsgi/commit/3c23cc311cbe9b698d05e4f436a497f615afc2bb > > I notice you added the above as a patch for the Debian package, but also made > other changes and it is not clear to me if you consider those ready for > release. > > Whenever you consider the HEAD of our git release-ready, and if you need > me to issue a release, please tell me :-) Sorry for not being explicit. I consider the changes I've published to be release-ready. For the uwsgi-plugin-php fix, a binNMU will then be required. Would you please issue a release? Thank you, Alexandre
Bug#1007923: maven-debian-helper: comply to java policy and fix W: bad-jar-name
Package: maven-debian-helper
Version: 2.6
Severity: normal
Tags: patch
Dear Maintainer,
When I build a package, for instance libhtmlcleaner-java, with
maven-debian-helper,
I get in my lintian output:
W: bad-jar-name usr/share/java/htmlcleaner.jar
Debian Java packaging policy states (§ 2.4):
Their classes must be in jar archive(s) in the directory /usr/share/java,
with the name packagename[-extraname]-fullversion.jar. The extraname
is optional and used internally within the package to separate the
different jars provided by the package. The fullversion is the version
of that jar file. In some cases that is not the same as the package
version.
Some package must also provide a symbolic link from
packagename-extraname.jar to the most compatible version of the available
packagename-extraname-version.jar files.
But as installed I have:
$ ls -l /usr/share/java/htmlcleaner*
/usr/share/java/htmlcleaner-2.24.jar -> htmlcleaner.jar
/usr/share/java/htmlcleaner.jar
I understand from the policy that the symbolic link should be the version-less
path.
The following path seems to fix the problem.
---
a/debian-maven-plugin/src/main/java/org/debian/maven/plugin/SysInstallMojo.java
+++
b/debian-maven-plugin/src/main/java/org/debian/maven/plugin/SysInstallMojo.java
@@ -592,12 +592,10 @@ public class SysInstallMojo extends AbstractMojo {
if (jarFile.exists()) {
getLog().info("Install jar for " + artifactId + " into
/usr/share/java");
mkdir(compatSharePath());
-if (noUsjVersionless) {
-FileUtils.copyFile(jarFile, new
File(versionedFullCompatPath()));
-} else {
-FileUtils.copyFile(jarFile, new File(fullCompatPath()));
-link(destUsjJarName(), fullCompatPath());
-link(destUsjJarName(), versionedFullCompatPath());
+FileUtils.copyFile(jarFile, new File(versionedFullCompatPath()));
+if (!noUsjVersionless) {
+link(destUsjVersionnedJarName(), fullCompatPath());
+link(destUsjVersionnedJarName(), versionedFullCompatPath());
}
}
}
@@ -611,11 +609,7 @@ public class SysInstallMojo extends AbstractMojo {
mkdir(fullRepoPath());
String targetPath = "";
-if (noUsjVersionless) {
-targetPath = versionedFullCompatPath();
-} else {
-targetPath = fullCompatPath();
-}
+targetPath = versionedFullCompatPath();
link(DirectoryUtils.relativePath(fullRepoPath(), targetPath),
jarDestPath());
if (debianVersion != null && !debianVersion.equals(version)) {
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-12-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages maven-debian-helper depends on:
ii default-jdk 2:1.11-72
ii default-jdk-headless2:1.11-72
ii libmaven-clean-plugin-java 3.1.0-1
ii libmaven-compiler-plugin-java 3.8.1-4
ii libmaven-jar-plugin-java3.1.2-1
ii libmaven-resources-plugin-java 3.1.0-1
ii libmaven-site-plugin-java 3.6-4
ii libplexus-velocity-java 1.2-3.1
ii libsurefire-java2.22.3-1
ii libxml2-utils 2.9.13+dfsg-1
ii maven 3.6.3-5
ii maven-repo-helper 1.10
ii unzip 6.0-26
ii velocity1.7-6
maven-debian-helper recommends no packages.
Versions of packages maven-debian-helper suggests:
ii apt-file 3.2.2
ii libmaven-javadoc-plugin-java 3.0.1-4
ii licensecheck 3.2.14-2
pn subversion
-- no debconf information
Bug#1007773: [pkg-uWSGI-devel] Bug#1007773: uwsgi: FTBS with /usr/bin/ld: cannot find -lpcre2-8
Hi, > > This change wasn't necessary (but is harmless). > > > > The actual bug (#1007254) was fixed in apache2-dev. > > Thanks for the notice, Adrian - I'll drop that needless build-dependency > for next release. Sorry to have missed this, I just noticed that the mirror I use is off by nearly 3 days now which made me miss the apache2-dev fix. Alex
Bug#1007774: uwsgi: php plugin broken with php8
Hi, > The PHP plugin has been broken since PHP8 has been uploaded to unstable. This > is visible > in the autopkgtest[1]. > > [1] > https://ci.debian.net/data/autopkgtest/unstable/amd64/u/uwsgi-plugin-php/19736763/log.gz > > The following patch should fix the problem although I could not test yet > because of > #1007773 . > > https://github.com/unbit/uwsgi/commit/3c23cc311cbe9b698d05e4f436a497f615afc2bb Both the above patch and the following one are required to fix the problem. I'll push fixes to salsa when the repository is up to date with the 2.0.20-3 upload. https://github.com/unbit/uwsgi/commit/8ca18da9a01eee19156243c5c0d28d2572698e4a Thanks, Alex
Bug#1007773: uwsgi: FTBS with /usr/bin/ld: cannot find -lpcre2-8
Hi, > /usr/bin/ld: cannot find -lpcre2-8: No such file or directory I've pushed the necessary fix. https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/0955366dcf19b7ec9a0134eab1e81ec216d12a96 Thanks, Alex
Bug#1007774: uwsgi: php plugin broken with php8
Source: uwsgi
Version: 2.0.20-2.2
Severity: normal
Tags: upstream patch
Dear Maintainer,
The PHP plugin has been broken since PHP8 has been uploaded to unstable. This
is visible
in the autopkgtest[1].
[1]
https://ci.debian.net/data/autopkgtest/unstable/amd64/u/uwsgi-plugin-php/19736763/log.gz
The following patch should fix the problem although I could not test yet
because of
#1007773 .
https://github.com/unbit/uwsgi/commit/3c23cc311cbe9b698d05e4f436a497f615afc2bb
Thanks,
Alex
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-12-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
From: gdam...@gmail.com
Date: Wed, 29 Dec 2021 14:02:32 +0100
Subject: [PATCH] fix: missing arginfo when compiling against PHP 8
Origin: upstream,
https://github.com/unbit/uwsgi/commit/3c23cc311cbe9b698d05e4f436a497f615afc2bb
---
plugins/php/php_plugin.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/plugins/php/php_plugin.c b/plugins/php/php_plugin.c
index 717d6317b..d336adddc 100644
--- a/plugins/php/php_plugin.c
+++ b/plugins/php/php_plugin.c
@@ -497,21 +497,24 @@ PHP_FUNCTION(uwsgi_signal) {
RETURN_NULL();
}
+ZEND_BEGIN_ARG_INFO_EX(arginfo_void, 0, 0, 0)
+ZEND_END_ARG_INFO()
+
zend_function_entry uwsgi_php_functions[] = {
- PHP_FE(uwsgi_version, NULL)
- PHP_FE(uwsgi_setprocname, NULL)
- PHP_FE(uwsgi_worker_id, NULL)
- PHP_FE(uwsgi_masterpid, NULL)
- PHP_FE(uwsgi_signal, NULL)
-
- PHP_FE(uwsgi_rpc, NULL)
-
- PHP_FE(uwsgi_cache_get, NULL)
- PHP_FE(uwsgi_cache_set, NULL)
- PHP_FE(uwsgi_cache_update, NULL)
- PHP_FE(uwsgi_cache_del, NULL)
- PHP_FE(uwsgi_cache_clear, NULL)
- PHP_FE(uwsgi_cache_exists, NULL)
+ PHP_FE(uwsgi_version, arginfo_void)
+ PHP_FE(uwsgi_setprocname, arginfo_void)
+ PHP_FE(uwsgi_worker_id, arginfo_void)
+ PHP_FE(uwsgi_masterpid, arginfo_void)
+ PHP_FE(uwsgi_signal, arginfo_void)
+
+ PHP_FE(uwsgi_rpc, arginfo_void)
+
+ PHP_FE(uwsgi_cache_get, arginfo_void)
+ PHP_FE(uwsgi_cache_set, arginfo_void)
+ PHP_FE(uwsgi_cache_update, arginfo_void)
+ PHP_FE(uwsgi_cache_del, arginfo_void)
+ PHP_FE(uwsgi_cache_clear, arginfo_void)
+ PHP_FE(uwsgi_cache_exists, arginfo_void)
{ NULL, NULL, NULL},
};
Bug#1007773: uwsgi: FTBS with /usr/bin/ld: cannot find -lpcre2-8
Source: uwsgi Version: 2.0.20-2.2 Severity: serious Tags: ftbfs Justification: Policy 4.9 Dear Maintainer, uwsgi fails to build from source in a sbuild chroot with the following error. /usr/share/apr-1.0/build/libtool --mode=link --tag=disable-static x86_64-linux-gnu-gcc -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -lpcre2-8 -L/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0-o apache2/mod_Ruwsgi.la -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -lapr-1 -laprutil-1 -rpath /usr/lib/apache2/modules -module -avoid-versionapache2/mod_Ruwsgi.lo libtool: link: x86_64-linux-gnu-gcc -shared -fPIC -DPIC apache2/.libs/mod_Ruwsgi.o -lpcre2-8 -L/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 -L/usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libapr-1.so /usr/lib/x86_64-linux-gnu/libaprutil-1.so -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -pthread -Wl,-soname -Wl,mod_Ruwsgi.so -o apache2/.libs/mod_Ruwsgi.so /usr/bin/ld: cannot find -lpcre2-8: No such file or directory collect2: error: ld returned 1 exit status apxs:Error: Command failed with rc=65536 . make: *** [debian/rules:517: debian/stamp-libapache2-mod-ruwsgi] Error 1 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Thanks, Alex -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-12-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#1001684: [Davmail-users] Davmail and the CVE-2021-44228-Log4j?
Hi, > > We have installed davmail 6.0.1 dated Dec. 3, 2021 as an RPM on CentOS 7.9. > > However, it's only a few days ago that the Vulnerability in Apache Log4j > > (CVE-2021-44228-Log4j) was announced. We note that Davmail includes a log4j [...] > > Question: Is davmail vulnerable to log4j? If so, when could we expect a > > security fix? > > Qouting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001684#22 > Debian maintainer of Davmail, Alexandre Rossi: > > > Also, since a while already, Java now has its own internal logging > > framework (java.util.logging.Logger), so there should be less and > > less reason to use potentially unsafe third-party logging libraries > > (but switching to java's internal logging might be more difficult > > to do in the short run than just upgrading to a newer version). > > I'll try to report this upstream. To clarify the log4j1 situation, it appears that it is not vulnerable unless you use JMSAppender which davmail does not. (there is also CVE-2019-17571 with SocketAppender which is disabled but usable in davmail). To clarify the Debian situation, the Debian package does not use the embedded jar but the system shared jar. In the case of davmail, I would say that there is a good chance that the current provided compiled zip in 6.0.1 is not vulnerable to CVE-2021-44228 because it does not use JMSAppender. Alex
Bug#1001684: Davmail should use log4j 2.16 rather than 1.2
tag 1001684 -moreinfo +upstream severity 1001684 wishlist thanks > I only stumbled upon this when examining our servers for instances > vulnerable to CVE-2021-44228. Forums seem to claim that versions log4j > versions 1 are not safe either (different vulnerabilities), but without > giving any specifics. However, log4j team itself says versions 1.x are > "end of life" and should be avoided. So, it's more a case of "better be > safe than sorry" than any concrete exploit. > > Also, since a while already, Java now has its own internal logging > framework (java.util.logging.Logger), so there should be less and less > reason to use potentially unsafe third-party logging libraries (but > switching to java's internal logging might be more difficult to do in > the short run than just upgrading to a newer version). I'll try to report this upstream. Alex
Bug#1001684: Davmail should use log4j 2.16 rather than 1.2
tag 1001684 moreinfo thanks Hi, > According to https://github.com/jagornet/dhcp/issues/20 , log4j 1.2 is > vulnerable to CVE-2019-17571, so davmail should use log4j 2.15 or 2.16 > instead. According to the debian security tracker[1], this has been fixed in log4j so davmail uses a fixed version. https://security-tracker.debian.org/tracker/source-package/apache-log4j1.2 Do you have exploit code that works against davmail or any other clue that davmail needs fixing? Thanks, Alex
