Bug#1086953: nmu: uwsgi-plugin-php_0.0.15 uwsgi-plugin-luajit_0.0.8
Package: release.debian.org Severity: normal X-Debbugs-Cc: uwsgi-plugin-...@packages.debian.org Control: affects -1 + src:uwsgi-plugin-php src:uwsgi srw:uwsgi-plugin-luajit User: release.debian@packages.debian.org Usertags: binnmu Hi, uwsgi.h has changed in the latest upstream, and externally built plugins need a rebuild to be aligned with this change. nmu uwsgi-plugin-luajit_0.0.8 . ANY . unstable . -m "rebuild against latest uwsgi.h (API change)" nmu uwsgi-plugin-php_0.0.15 . ANY . unstable . -m "rebuild against latest uwsgi.h (API change)" Thanks! -- Some context for this construct (debian/README.source): Native package shipping build of upstream code -- This is a Debian native package, yet is virtually empty and depends on and essentially builds from a *-src package from an upstream project. Reason for this construct is that the upstream project includes plugins for a wide range for programming languages and frameworks, causing headaches with transitions of those: By separating the build of each uwsgi plugin, changes to Perl ABI, MongoDB ABI, PHP ABI, etc. can transition independently of each other - and if a particular uwsgi plugin shows problematic for a transition then it can be dropped without affecting the rest of uwsgi.
Bug#1073005: transmission: consider switching back to vendored libb64
Hi, > > Regarding those valid points, because there is not reason to have the same > > source in multiple packages, there are only 2 paths compliant with the > > Debian > > policy: > > > > 1) Fix those points in src:libb64 for transmission and all rdepends > > 2) Remove src:libb64 from Debian and then vendor in transmission source > > I agree that it would be helpful if many of these issues were fixed > for all users of libb64. I've done it and proposed a pull request. https://salsa.debian.org/niol/libb64 Thanks, Alex
Bug#1085515: RM: uwsgi-plugin-mongo -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: uwsgi-plugin-mo...@packages.debian.org Control: affects -1 + src:uwsgi-plugin-mongo Hi, uwsgi-plugin-mongo is abandonned upstream[1] and prevents[2] removal of obosolete reverse build deps. [1] https://github.com/unbit/uwsgi/issues/1396 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085463 Please remove from the archive. Thanks, Alex
Bug#1085463: [pkg-uWSGI-devel] Bug#1085463: uwsgi-plugin-mongo: Depends on legacy mongodb driver which should go away
Hi, > Your package (build-)depends on mongo-cxx-driver-legacy, which clearly > should go away. > > Please either stop (build-)depending on mongo-cxx-driver-legacy, or if > your package is not useful anymore, file for RM of your package. Looking at popcon (4) and the fact that the obvious replacement buildep builds from src:mongo-cxx-driver is in experimental, I guess I'll file for RM in a few weeks unless advised otherwise. Thanks, Alex
Bug#1073203: libb64: switch to maintained fork
Hi, > >> The bug reporter of #1073005 has brought to my attention that src:libb64 > >> could switch to a better maintained fork to ease maintenance. > >> > >> He suggested > >> > >> https://github.com/libb64/libb64 > >> > >> But I would also suggest > >> > >> https://github.com/transmission/libb64/tree/post-2.0.0-transmission > >> > >> Also, switching to modern dh would be great. > >> > >> I could give it a try if you would confirm this would be okay for you. > >> I would prefer this package to be updated rather than going back embed > >> a copy in transmission source. > > what are the advantages of either fork? There doesn't seem to be much > development but only some cosmetics!? > Wouldn't it be possible to only have one version instead of three? I would then suggest to switch to the transmission maintained fork for thei following reasons: - security patches included - build system modernized - used by transmission thus tested That's what I propose in my work. Thanks, Alex
Bug#1073203: libb64: switch to maintained fork
Hi, > The bug reporter of #1073005 has brought to my attention that src:libb64 > could switch to a better maintained fork to ease maintenance. > > He suggested > > https://github.com/libb64/libb64 > > But I would also suggest > > https://github.com/transmission/libb64/tree/post-2.0.0-transmission > > Also, switching to modern dh would be great. > > I could give it a try if you would confirm this would be okay for you. > I would prefer this package to be updated rather than going back embed > a copy in transmission source. I've tackled this and have a working lintian clean package. https://salsa.debian.org/niol/libb64 Thanks, Alex
Bug#1076420: uwsgi: move away from cdbs - status update
Hi, > Then, when we are happy about the new addon package, we release it and > have it approved by ftpmasters. We can then simplify src:uwsgi to no > longer generate those same binary packages, and then repeat the cycle > for each of the other involved libraries. As you've seen, separate packaging for the plugins with complicated deps is in the NEW queue. > Independently from the above work we can look at other atomic changes to > simplify packaging, where one very narrow change (especially when done > *after* the above) is letting go of cdbs. You can see my work on > "atomifying" your draft in branch wip/simplify - it it still both > unfinished and untested, but gives an idea of the level of atomicity > that I find comfortable for understanding what is going on. Patches to drop cdbs once the plugin packages clear the NEW queue are drafted in: https://salsa.debian.org/uwsgi-team/uwsgi/-/tree/wip/drop-cdbs Feedback would be appreciated, thanks, Alex
Bug#1083025: RFP: lldap -- Light LDAP implementation for authentication
Package: wnpp Severity: wishlist * Package name: lldap Version : 0.5.0 Upstream Contact: Valentin Tolmer * URL : https://github.com/lldap/lldap * License : GPL-3.0 Programming Lang: Rust Description : Light LDAP implementation for authentication This project is a lightweight authentication server that provides an opinionated, simplified LDAP interface for authentication. It integrates with many backends, from KeyCloak to Authelia to Nextcloud and more! It comes with a frontend that makes user management easy, and allows users to edit their own details or reset their password by email. The goal is not to provide a full LDAP server; if you're interested in that, check out OpenLDAP. This server is a user management system that is: - simple to setup (no messing around with slapd), - simple to manage (friendly web UI), - low resources, - opinionated with basic defaults so you don't have to understand the subtleties of LDAP. It mostly targets self-hosting servers, with open-source components like Nextcloud, Airsonic and so on that only support LDAP as a source of external authentication. For more features (OAuth/OpenID support, reverse proxy, ...) you can install other components (KeyCloak, Authelia, ...) using this server as the source of truth for users, via LDAP. By default, the data is stored in SQLite, but you can swap the backend with MySQL/MariaDB or PostgreSQL. This should probably be maintained within the Debian Rust Packaging team.
Bug#1082658: libgdk-pixbuf-2.0-0: gnome-shell panel icons showing wheel icon, games cannot load svg
Hi,
> This may be related https://bugs.debian.org/669562
Please read #625203 (https://bugs.debian.org/625203) instead
('/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory)
Thanks,
Alex
Bug#1082658: libgdk-pixbuf-2.0-0: gnome-shell panel icons showing wheel icon, games cannot load svg
Package: libgdk-pixbuf-2.0-0 Version: 2.42.12+dfsg-1 Severity: normal Dear Maintainer, On a laptop that's used by someone who may have not ensured proper shutdown possibly during upgrades, I encountered the following situation. Please note that dpkg states were all clean and the machine was stuck in the described situation. Also, debsums was all ok. gnome-shell icons were showing the gear wheel in the launcher, and in notifications and in many other places. gnome-games were crashing after displaying many GTK warnings such as: Couldn't recognize the image file format for file '/foo/bar.svg' I fixed the problem on this particular machine with the following command: $ sudo /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \ --update-cache and close/open user session. I suspect ignoring error in the cache update script may have something to do with this problem, and I would expect a failed trigger/postinst flashes to the system administrator, probably prompting for a "apt --fix-broken install". debian/libgdk-pixbuf-2.0-0.postinst.in: /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \ $(find $LOADERS_DIR $LOADERS_DIR_OLD -name *.so 2> /dev/null | LC_ALL=C sort) \ > /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/2.10.0/loaders.cache || true ^^^ This may be related https://bugs.debian.org/669562 Thanks, Alex -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-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 libgdk-pixbuf-2.0-0 depends on: ii libc62.40-2 ii libgdk-pixbuf2.0-common 2.42.12+dfsg-1 ii libglib2.0-0t64 2.82.1-1 ii libjpeg62-turbo 1:2.1.5-3 ii libpng16-16t64 1.6.44-1 ii libtiff6 4.5.1+git230720-5 ii shared-mime-info 2.4-5 Versions of packages libgdk-pixbuf-2.0-0 recommends: ii libgdk-pixbuf2.0-bin 2.42.12+dfsg-1 libgdk-pixbuf-2.0-0 suggests no packages. -- no debconf information
Bug#1082002: openjdk-21-jre-headless: please provide shlibs info for libjvm.so
Package: openjdk-21-jre-headless Version: 21.0.5~6ea-1 Severity: normal Dear Maintainer, I'm building a plugin[1] for src:uwsgi that needs to link against libjvm.so . Currently dpkg-shlibdeps does not generate to correct dependecy to openjdk-21-jre-headless (which contains libjvm.so my plugin links against) and I need to hardcode the binary package dependency. I would guess this would all be done automatically and maybe provide appropriate debian/*shlibs or debian/*symbols files. Thanks, Alex [1] https://salsa.debian.org/uwsgi-team/uwsgi-plugin-java -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-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 openjdk-21-jre-headless depends on: ii ca-certificates-java 20240118 ii java-common 0.76 ii libc6 2.40-2 ii libgcc-s1 14.2.0-5 ii libjpeg62-turbo 1:2.1.5-3 ii liblcms2-22.14-2+b1 ii libnss3 2:3.103-1 ii libpcsclite1 2.3.0-1 ii libstdc++614.2.0-5 ii util-linux2.40.2-8 ii zlib1g1:1.3.dfsg+really1.3.1-1 Versions of packages openjdk-21-jre-headless recommends: ii libasound2t64 1.2.12-1 ii libcups2t64 2.4.10-1 ii libfontconfig1 2.15.0-1.1 ii libfreetype62.13.3+dfsg-1 ii libharfbuzz0b 9.0.0-1 Versions of packages openjdk-21-jre-headless suggests: ii fonts-dejavu-extra 2.37-8 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei | fonts-wqy-zenhei ii libnss-mdns0.15.1-4 -- no debconf information
Bug#1081966: ITP: uwsgi-plugin-lua -- Lua WSAPI plugin for uWSGI (Lua 5.1)
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-lua Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Lua WSAPI plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the Lua plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-lua Alex
Bug#1056206: graphite-web: saving graphs in dashboard is broken (only in stable version 1.1.8-2)
Hi, > graphite-web in bookworm (1.1.8-2) does not allow saving dashboards due to > missing function > htmlEncode from dashboard.js. Workaround is to install 1.1.10-1 from testing, > where > dashboard.js contains the definition of htmlEncode. > > As a note to others: js is cached in the browser for quite some time, so the > showing up of the bug was delayed > > Please consider the applied patch for bookwoorm which simply adds the missing > function. I would but uploads to stable need a bug with severity important (per policy § 5.5.1 [1]) or in a special cas (per policy § 5.5.2 [1]) which does not seem the case here. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#picking-a-distribution The simpler solution would be to use a backport. I use such backport, see http://deb.zincube.net/pool/main/g/graphite-web/graphite-web_1.1.10-8~bpo12+1_all.deb I would prepare an upload if a DD steps in and says that upload would be sponsored. Same for a backport. Otherwise, this can simply be closed. Thanks, Alex
Bug#1076420: Processed: ITPs block move away from cdbs
Hi, > > Bug #1076420 [src:uwsgi] uwsgi: move away from cdbs > > […] > > Added blocking bug(s) of 1076420: 1078557 > > Wrong bug number? #1078557 is for a leaf package and has nothing to do > with uwsgi or CDBS. Sorry for that, fixing my mess. Alex
Bug#1081281: ITP: uwsgi-plugin-psgi -- Perl PSGI and Coro::AnyEvent plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-psgi Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Perl PSGI and Coro::AnyEvent plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the psgi plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-psgi Alex
Bug#1081280: ITP: uwsgi-plugin-rados -- Ceph/RADOS storage plugin for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-rados Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Ceph/RADOS storage plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the rados plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-rados Alex
Bug#1081279: ITP: uwsgi-plugin-glusterfs -- GlusterFS storage plugin for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-glusterfs Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : GlusterFS storage plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the glusterfsplugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-glusterfs Alex
Bug#1081278: ITP: uwsgi-plugin-gccgo -- Go plugin for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-gccgo Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Go plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the Go plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-gccgo Alex
Bug#1080606: Missing Build-Depends on python3-setuptools
Hi, > This package failed build from source when test-built against a version of > dh-python without a python3-setuptools dependency. > > distutils is no longer part of the Python standard library, since 3.12. But a > minimal version of it becomes available when the python3-setuptools package is > installed. > > Please add a Build-Depends on python3-setuptools to your package, or migrate > the package's build system away from setuptools/distutils. A fixed package is awaiting sponsorship at: https://mentors.debian.net/debian/pool/main/g/graphite-carbon/graphite-carbon_1.1.10-2.dsc Thanks, Alex
Bug#1077619: graphite-carbon 1.1.10-2 sponsorship request
Hi, I think src:graphite-carbon users would benefit having this new release in Debian: it includes an autopkgtest which can help alert if broken in unstable. https://mentors.debian.net/debian/pool/main/g/graphite-carbon/graphite-carbon_1.1.10-2.dsc Thanks, Alex
Bug#1079881: Fix committed
Hi, A fix is awaiting review and sponsorship: https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/c3259147da042a0cde0428d6a3a45b8e99b874dc Thanks, Alex
Bug#732019: [pkg-uWSGI-devel] Bug#732019: PyPy plugin support for uWSGI
Hi, > Quoting Alexandre Rossi (2024-08-28 11:38:22) > > Is there still interest in this? > > I think it quite unteresting to offer support for PyPy3: That allows > experimenting with running Python-based services more lightweight. I managed to find patches to make it work. https://salsa.debian.org/uwsgi-team/uwsgi-plugin-pypy Alex
Bug#732019: PyPy plugin support for uWSGI
Hi, Is there still interest in this? I have preliminary packaging but it requires more work regarding some issues. The first one is that the libpypy-c.so filename is hardoced in the plugin, whereas it contains the version in Debian and there is no symlink (/usr/lib/x86_64-linux-gnu/libpypy3.9-c.so on my sid host). The second one is that the very basic "Hello world" autopkgtest fails in the same way described ias an upstream bug[1]. There seems to exist other issues[2][3] with the pypy plugin upstream. [1] https://github.com/unbit/uwsgi/issues/2342 [2] https://github.com/unbit/uwsgi/issues/2436 [3] https://github.com/unbit/uwsgi/issues/2534 It seems that the pypy plugin has never been ported to pypy3. Things do not seem to be moving upstream. >From the state of things, it does not seem reasonable to introduce this plugin into Debian. Thanks, Alex
Bug#1079857: ITP: uwsgi-plugin-ruby -- Ruby plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-ruby Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : ruby plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the ruby java plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-ruby Alex
Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI
On Wed Aug 21, 2024 at 9:54 AM CEST, Alexandre Rossi wrote: > > Regardless of the userbase being arguably significant, I am ok with the > > approach of trying to pull the plug on them, having a package ready if > > someone provides good reasons for reviving them. > > > > Will you try prepare dropping these alternatives? I imagine that in > > addition to removal of the code and the entries in the control file > > (see my related draft commit in the wip branch), it requires adding an > > entry in debian/NEWS. > > Will do, thanks for your input. Done. https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/c96dcf437e7a277e9da4e161fe720e3cccf9a525 >From our discussion, this ITP can be closed. Packaged apache2 modules could be reintroduced in the future using the work available at: https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Cheers, Alex
Bug#1078805: transmission-common: UPnP is non-functional in version 3.00 and later
forwarded 1078805 https://github.com/transmission/transmission/issues/1254 severity 1078805 normal thanks Hi, Lowering severity has this does not have "a major effect on the usability of [the] package", in my view. > UPnP doesn't work in versions 3.00 and up. This issue isn't specific to me as > other people are having this issue > (https://github.com/transmission/transmission/issues/1254) and I tested this > with another torrent client. Can you explain how this is tested and in which manner this fails? Can you confirm 4.0.6+dfsg-3 also does not work? Thanks, Alex
Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI
> Regardless of the userbase being arguably significant, I am ok with the > approach of trying to pull the plug on them, having a package ready if > someone provides good reasons for reviving them. > > Will you try prepare dropping these alternatives? I imagine that in > addition to removal of the code and the entries in the control file > (see my related draft commit in the wip branch), it requires adding an > entry in debian/NEWS. Will do, thanks for your input. Alex
Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI
Hi, > Work is happenning here: > > https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Work feels done unless further comments are coming. Now the question is, is this useful in the Debian archive? Remember, there are 3 available apache2 modules for the uwsgi protocol: - mod-proxy-uwsgi (built from src:apache2, popcon?, I use it) - mod-uwsgi (built from src:uwsgi, popcon 101) - mod-ruwsgi (built from src:uwsgi popcon 7) I do not see any reason to use anything other than mod-proxy-uwsgi. So my take on this is: 1) disable apache2 building in src:uwsgi 2) if someone complains, introduce this package in the archive The alternative is to not wait for someone to complain. Thanks, Alex
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Hi, > > > uwsgidecorators.py would make sense in this package but is not > > > provided by uwsgi-src. OK to add it? > > > > Yes: Anything needed for plugin/module packages should be included in > > uwsgi-src package. > > Waiting for an upload to uncomment uwsgidecorators.py stuff. Done, and finished for what I wanted to do unless you have further comments. https://salsa.debian.org/uwsgi-team/uwsgi-plugin-python Thanks, Alex
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Hi, I have finished what I think is needed for this package. > > uwsgidecorators.py would make sense in this package but is not > > provided by uwsgi-src. OK to add it? > > Yes: Anything needed for plugin/module packages should be included in > uwsgi-src package. Waiting for an upload to uncomment uwsgidecorators.py stuff. > > My packaging only builds for the default python version. Should we > > plan for multiple python versions supported in sid? My view on this is > > to wait for the need to arise. If ok with this, src:uwsgi should > > probably clean out all the alternatives provided. You view on this? > > I used to strongly favor offering each available version, but nowadays I > don't really care, so if you prefer to reduce to a single non-versioned > package then go ahead - but yes, then be careful to handle the migration > (personally I would find it simpler to *continue* with versioned > packages now that it has been established already, but I leave the > choice to you). Implemented. Left out the rtupdate stuff: very complicated for would require a binNMU in most cases. > > greenlet should be restricted to some archs, looking into that and > > considering specific source package. Advice? > > I recommend to use the same method that I have used. Done. I initially went for a debian/control.in template but later was confused and editing debian/control directly so now I understand your approach of having only debian/control. > You might consider adding support for pypy3, and close bug#732019. pypy is a different set of build deps, so a different source package I think. Thanks, Alex
Bug#1078539: schroot: fails to start in a systemd-nspawn container
Hi, > Can you try again with 1.6.13-4 and patching > /etc/schroot/setup.d/10mount and replace the line 306 which reads > > mknod -m700 "$CHROOT_PATH/dev/console" c 5 1 > > by > > touch "$CHROOT_PATH/dev/console" The problem disappears with the line changed. Alex
Bug#1078539: schroot: fails to start in a systemd-nspawn container
Hi, > > My sbuild setup now fails on my sid systemd-nspawn container. > > So I understand correctly this is a regression to -3? Downgrading to 1.6.13-3+b3 makes the problem disappear. > > $ sudo sbuild-update -u -d unstable > > E: 10mount: mknod: > > /var/run/schroot/mount/unstable-amd64-sbuild-c631feb3-ec9a-475b-b19a-407a3bacf44c/dev/console: > > Operation not permitted > > E: unstable-amd64-sbuild-c631feb3-ec9a-475b-b19a-407a3bacf44c: Chroot setup > > failed: stage=setup-start > > Chroot setup failed > > Error setting up unstable chroot > > > > The error comes from the mknod call at the end of > > /etc/schroot/setup.d/10mount . > > Commenting the associated lines works around the problem with no visible > > drawback for my usecase (sbuild). > > I reckon this was somehow introduced by the change in /etc/schroot/*/fstab, > can > you revert in the applicable file, in other words, replace (as in -4): > > | /dev/pts/dev/ptsdevpts > rw,newinstance,ptmxmode=666,mode=620,gid=5 0 0 > > with (up until -3): > > | /dev/pts/dev/ptsnonerw,bind 0 0 $ grep pts /etc/schroot/sbuild/fstab #/dev/pts/dev/ptsdevpts rw,newinstance,ptmxmode=666,mode=620,gid=5 0 0 /dev/pts/dev/ptsnonerw,bind 0 0 $ sudo sbuild-update -u -d unstable E: 10mount: mknod: /var/run/schroot/mount/unstable-amd64-sbuild-e939c22a-be21-404c-90dd-a145336da608/dev/console: Operation not permitted E: unstable-amd64-sbuild-e939c22a-be21-404c-90dd-a145336da608: Chroot setup failed: stage=setup-start Chroot setup failed Error setting up unstable chroot Chroot setup failed at /usr/bin/sbuild-update line 145. Still fails. Thanks, Alex
Bug#1078547: ITP: uwsgi-plugin-java -- java plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-java Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : java plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the java plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-java Alex
Bug#1078544: Moreinformation: dead since 2009
Hi, > The project is included in apache2 > > moreover top of website said: > The project is in maintenance mode (only bugfixes and updates for new > languages apis). Do not expect quick answers on github issues and/or pull > requests (sorry for that) A big thanks to all of the users and contributors > since 2009 > > As comaint of apache2 could you give use reason to use this ? There are 3 available apache2 modules for the uwsgi protocol: - mod-proxy-uwsgi (built from src:apache2, popcon?, I use it) - mod-uwsgi (built from src:uwsgi, popcon 101) - mod-ruwsgi (built from src:uwsgii, popcon 7) This ITP is about changing how mod-uwsgi and mod-ruwsgi are built and ease maintainance. We could as well drop them to force transition to mod-proxy-uwsgi. I just did not want to force this. Regarding uwsgi maintenance mode, I use it and care, and not alone (popcon vote ~1000). Thanks, Alex
Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-apache2-mod Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : apache2 modules for uWSGI uWSGI source packages build many plugins and even apache2 modules. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins and apache2 modules. This new source package proposes to build the apache2 modules packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Alex
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-apache2-mod Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : apache2 modules for uWSGI uWSGI source packages build many plugins and even apache2 modules. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins and apache2 modules. This new source package proposes to build the apache2 modules packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Alex
Bug#1078541: Questions/advices
uwsgidecorators.py would make sense in this package but is not provided by uwsgi-src. OK to add it? My packaging only builds for the default python version. Should we plan for multiple python versions supported in sid? My view on this is to wait for the need to arise. If ok with this, src:uwsgi should probably clean out all the alternatives provided. You view on this? greenlet should be restricted to some archs, looking into that and considering specific source package. Advice? Please bring up any other comment you might have. Thanks, Alex
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-python Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : python plugins for uWSGI uWSGI source packages build many plugins. Somes plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the python packages from a separate source package, as this has been done for php, mongo and luajit. Initial packaging is here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-python Alex
Bug#1078539: schroot: fails to start in a systemd-nspawn container
Package: schroot Version: 1.6.13-4 Severity: normal Dear Maintainer, My sbuild setup now fails on my sid systemd-nspawn container. $ sudo sbuild-update -u -d unstable E: 10mount: mknod: /var/run/schroot/mount/unstable-amd64-sbuild-c631feb3-ec9a-475b-b19a-407a3bacf44c/dev/console: Operation not permitted E: unstable-amd64-sbuild-c631feb3-ec9a-475b-b19a-407a3bacf44c: Chroot setup failed: stage=setup-start Chroot setup failed Error setting up unstable chroot The error comes from the mknod call at the end of /etc/schroot/setup.d/10mount . Commenting the associated lines works around the problem with no visible drawback for my usecase (sbuild). This is in a sid systemd-nspawn container running on a bookworm host. Adding Capability=CAP_MKNOD to the nspawn configuration does not help. I was not able to correlate this to a systemd upgrade on the host or in the container. Thanks, Alex -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-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 schroot depends on: ii debconf [debconf-2.0] 1.5.87 ii libboost-filesystem1.83.0 1.83.0-3.1 ii libboost-iostreams1.83.01.83.0-3.1 ii libboost-program-options1.83.0 1.83.0-3.1 ii libc6 2.39-6 ii libgcc-s1 14.2.0-2 ii libpam0g1.5.3-7 ii libstdc++6 14.2.0-2 ii libuuid12.40.2-6 ii lsb-base11.6 ii schroot-common 1.6.13-4 ii sysvinit-utils [lsb-base] 3.10-1 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-tools | unionfs-fuse pn btrfs-progs ii bzip2 1.0.8-5.1 ii debootstrap1.0.137 pn lvm2 pn qemu-user-static ii xz-utils 5.6.2-2 pn zfsutils-linux ii zstd 1.5.6+dfsg-1 -- Configuration Files: /etc/schroot/setup.d/10mount changed [not included] -- debconf information: schroot/bad-names:
Bug#1076420: uwsgi: move away from cdbs - status update
Hi, > > src:uwsgi-plugin-python3 > > building uwsgi-plugin-python3 > > building python3-uwsgidecorators > > building uwsgi-plugin-asyncio-python3 > > building uwsgi-plugin-gevent-python3 > > building uwsgi-plugin-greenlet-python3 > > building uwsgi-plugin-tornado-python3 > [...] > > Please confirm or comment, and I'll give it a go for python. > > The above looks good. Please create that, and test (e.g. with debdiff) > that it produces same binary packages as now generated with src:uwsgi > we can release that. No need to touch src:uwsgi at all for this work. I'm there. https://salsa.debian.org/uwsgi-team/uwsgi-plugin-python Issues/questions: uwsgidecorators.py would make sense in this package but is not provided by uwsgi-src. OK to add it? My packaging only builds for the default python version. Should we plan for multiple python versions supported in sid? My view on this is to wait for the need to arise. If ok with this, src:uwsgi should probably clean out all the alternatives provided. You view on this? greenlet should be restricted to some archs, looking into that and considering specific source package. Advice? Please bring up any other comment you might have. Thanks, Alex
Bug#1076420: uwsgi: move away from cdbs - status update
Hi, > > All this is currently implemented in GNU make syntax, so this is doable to > > move to debhelper and not introduce some helper script. I'll try to > > come up with something. However, I still think that the handling of the > > plugin build configuration would be easier to maintain with a more capable > > language than GNU make. > > The alternative you didn't list which I prefer is to branch out to > interpreter-specific source packages depending on uwsgi-source and using > dh helpers tailored for each interpreter - same as has been done already > for php and a few others. Now I see what you mean. Can you confirm the list of new src packages you think about? I can think of the following and all helper script to generate binNMUs when uwsgi-abi changes. src:uwsgi-libapache2-mods building libapache2-mod-ruwsgi building libapache2-mod-ruwsgi src:uwsgi-plugin-python3 building uwsgi-plugin-python3 building python3-uwsgidecorators building uwsgi-plugin-asyncio-python3 building uwsgi-plugin-gevent-python3 building uwsgi-plugin-greenlet-python3 building uwsgi-plugin-tornado-python3 src:uwsgi-plugin-ruby building uwsgi-plugin-fiber building uwsgi-plugin-rack building uwsgi-plugin-rbthreads src:uwsgi-plugin-gccgo src:uwsgi-plugin-glusterfs src:uwsgi-plugin-openjdk building uwsgi-plugin-jvm building uwsgi-plugin-jwsgi building uwsgi-plugin-ring building uwsgi-plugin-servlet src:uwsgi-plugin-lua51 src:uwsgi-plugin-mono src:uwsgi-plugin-psgi src:uwsgi-plugin-rados Please confirm or comment, and I'll give it a go for python. Once all done, this should make the move the dh easy with a static list of plugins to build. Thanks, Alex
Bug#1076420: uwsgi: move away from cdbs - status update
Hi, > Thanks for your work on migrating away from CDBS. I have stared at it > many times, and know that it must have been quite a challenge. > > Unfortunately, I don't like the changes. :-( No problem with that I wanted to start the discussion constructively. The good news is that now I have a good idea of what's needed to do that. > One problem is that you did the transition as one big git commit > (when the fixup patches assumably gets merged). That makes the change > difficult to follow, in case it turns out that some corner case is not > working as intended, and there is a need to understand what was meant in > more details with each detail of the change. I started with small changes, but moving away from cdbs requires from my experiments a complete overhaul of d/rules, and that makes making small commits really difficult. > The bigger problem, however, is that your transition replaces CDBS with > another even more unique chunk of code, written in Python that I will > not be comfortable maintaining. Although I think string manipulation involved in this packaging is better (as in more readable and less prone to mistakes) expressed in python than in GNU make, I understand what you mean. uwsgi packaging as we need it shall carry out at least the following functions. * produce debian packages current implementation : cdbs my choice of implementation: debhelper * build uwsgi-core current implementation : GNU make my choice of implementation: GNU make * define the list of plugins to try to build and associated parameters current implementation : GNU make my choice of implementation: python alternative: GNU make, or perl, conf file (JSON or other) * determine the list of plugins to build according to target arch current implementation : GNU make my choice of implementation: python alternative: GNU make, or perl * determine the list of plugins to build according to plugin flavours current implementation : GNU make my choice of implementation: python alternative: GNU make, or perl * build plugin flavours This involves for each plugin to manage a source plugin name, the target file according to flavour, and specific build command or environment. This also involves producing symlinks and specific manpages for a subset of the plugins. current implementation : GNU make my choice of implementation: python alternative: GNU make, or perl * templating for dh files and scripts for apache2 modules binary packages current implementation : GNU make my choice of implementation: python alternative: GNU make, or perl * templating for dh files and scripts for plugin binary packages current implementation : GNU make my choice of implementation: python alternative: GNU make, or perl * ease checking consistency of plugin archs vs build dep archs current implementation : shell script + sed my choice of implementation: python alternative: GNU make, or perl All this is currently implemented in GNU make syntax, so this is doable to move to debhelper and not introduce some helper script. I'll try to come up with something. However, I still think that the handling of the plugin build configuration would be easier to maintain with a more capable language than GNU make. Seeking your opinion on these ideas, Alex
Bug#1076420: uwsgi: move away from cdbs - status update
Status update. [x] Build uwsgi-core [x] Build plugins [x] Build apache2 modules [x] Skip build of plugins not available on specific archs [x] Generate uwsgi-abi substvar [ ] Correctly generate preinst/postrm maintscripts for plugin binary pkgs [x] Generate d/control descriptions substvars [x] Install systemd units and initscripts [x] Enable the build system to generate multiple flavours of plugins [ ] Lower the amount of binary packages and group plugins according to their binary dependencies [x] Ensure debdiff output between cdbs .deb's and dh .deb's is expected [x] builds in clean chroot [ ] Provide an easy way to check arch deps against archive (rmadison) Legend: [ ] not done [x] done My work is available at: https://salsa.debian.org/uwsgi-team/uwsgi/-/tree/drop-cdbs
Bug#1077754: transmission-qt: crashes after some seconds
Hi, > transmission crashes some seconds after adding a torrent. Sometimes > 3 seconds, sometimes 30. torrent does not seem to matter. > Applies to transmission-gtk as well. > > Here's a backtrace: > > Thread 8 "transmission-qt" received signal SIGPIPE, Broken pipe. [...] Can this be https://github.com/transmission/transmission/issues/7035 ? Can you reproduce if you downgrade libcurl4t64 to 8.9.0-3 ? http://snapshot.debian.org/package/curl/8.9.0-3/ Thanks, Alex
Bug#1077618: RFS: libjs-jush/2.0.2+git20210206+1-1 [ITP] -- JavaScript Syntax Highlighter
tag 1076718 -moreinfo thanks Hi, > I: libjs-jush source: composer-package-without-pkg-php-tools-builddep > [composer.json] composer actually not used for building, lintian override added. > I: libjs-jush: wrong-section-according-to-package-name web => javascript Fixed. > W: libjs-jush: embedded-javascript-library please use libjs-jquery-jush > [usr/share/javascript/jush/jquery.jush.js] This is actually to be fixed in lintian if libjs-jush ever reaches the Debian archive. Thanks, Alex
Bug#1075742: RFS: adminer/4.8.1-3 [RC] -- Web-based database administration tool
Hi, > > I: adminer: package-contains-empty-directory > > [usr/share/adminer/designs/hydra/] > > I: adminer: package-contains-empty-directory > > [usr/share/adminer/designs/pepa-linha-dark/] > > No clue as to where those directories come from, investigating. https://salsa.debian.org/debian/adminer/-/commit/0237f89c0dd9422ee686a96af9a6ecaa7a3ab69c Thanks, Alex
Bug#1077619: RFS: graphite-carbon/1.1.10-2 -- backend data caching and persistence daemon for Graphite
Package: sponsorship-requests Severity: normal X-Debbugs-CC: Jonas Genannt , Thomas Goirand Dear mentors, I am looking for a sponsor for my package "graphite-carbon": * Package name : graphite-carbon Version : 1.1.10-2 Upstream contact : Chris Davis * URL : https://github.com/graphite-project/carbon * License : Apache-2.0, Custom-AMQP-Working-Group * Vcs : https://salsa.debian.org/debian-graphite-team/graphite-carbon Section : utils The source builds the following binary packages: graphite-carbon - backend data caching and persistence daemon for Graphite To access further information about this package, please visit the following URL: https://mentors.debian.net/package/graphite-carbon/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/graphite-carbon/graphite-carbon_1.1.10-2.dsc Changes since the last upload: graphite-carbon (1.1.10-2) unstable; urgency=medium . * add autopkgtest to test carbon-cache running * fix py312 patch tagging * remove duplicate override_dh_installsystemd * remove carbon-client manpages (executable removed upstream) * provide manpage and service for carbon-aggregator-cache * fix manpages groff-message warning: cannot select font 'b * use -noawait trigger for twisted-plugins-cache Regards, -- Alexandre Rossi
Bug#1077618: RFS: libjs-jush/2.0.2+git20210206+1-1 [ITP] -- JavaScript Syntax Highlighter
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org Dear mentors, I am looking for a sponsor for my package "libjs-jush": * Package name : libjs-jush Version : 2.0.2+git20210206+1-1 * 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 Changes for the initial release: libjs-jush (2.0.2+git20210206+1-1) unstable; urgency=medium . * Initial release. (Closes: #1060071) This is a dependency of adminerevo which I request to maintain as a DM. An older and partial version is already in src:jquery-goodies, and I'll fill a bug to avoid duplication if this package ever reaches unstable. Regards, -- Alexandre Rossi
Bug#1076976: RFS: transmission/4.0.6+dfsg-3 -- lightweight BitTorrent client
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: "Barak A. Pearlmutter" , 1076...@bugs.debian.org Dear mentors, I am looking for a sponsor for my package "transmission": * Package name : transmission Version : 4.0.6+dfsg-3 * URL : https://transmissionbt.com/ * License : ISC, GPL-3 or LGPL-2.1, CC0-1.0, BSL-1.0, GPL-2, BSD-3-clause, GPL, GPL-2+-OpenSSL, Expat, GPL-3, Zlib * 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) libtransmission-dev - lightweight BitTorrent client (development library) 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.6+dfsg-3.dsc Changes since the last upload: transmission (4.0.6+dfsg-3) unstable; urgency=medium . * fix-up d/copyright * fix build with miniupnpc 2.2.8 (Closes: #1076694) Regards, -- Alex
Bug#1076420: uwsgi: move away from cdbs - status update
Status update. [x] Build uwsgi-core [x] Build plugins [x] Build apache2 modules [x] Skip build of plugins not available on specific archs [x] Generate uwsgi-abi substvar [ ] Correctly generate preinst/postrm maintscripts for plugin binary pkgs [x] Generate d/control descriptions substvars [x] Install systemd units and initscripts [s] Enable the build system to generate multiple flavours of plugins [ ] Lower the amount of binary packages and group plugins according to their binary dependencies [x] Ensure debdiff output between cdbs .deb's and dh .deb's is expected [ ] builds in clean chroot (strange jni.h not found error) [ ] Provide an easy way to check arch deps against archive (rmadison) Legend: [ ] not done [x] done [s] skipped, not planned, actually not used although the cdbs-based build system would handle it My work is available at: https://salsa.debian.org/uwsgi-team/uwsgi/-/tree/drop-cdbs
Bug#1076420: uwsgi: move away from cdbs - status update
Status update. [x] Build uwsgi-core [x] Build plugins [x] Build apache2 modules [x] Skip build of plugins not available on specific archs [x] Generate uwsgi-abi substvar [ ] Correctly generate preinst/postrm maintscripts for plugin binary pkgs [ ] Generate d/control descriptions substvars [ ] Install systemd units and initscripts [s] Enable the build system to generate multiple flavours of plugins [ ] Lower the amount of binary packages and group plugins according to their binary dependencies [ ] Ensure diffoscope output between cdbs .deb's and dh .deb's is expected Legend: [ ] not done [x] done [s] skipped, not planned, actually not used although the cdbs-based build system would handle it My work is available at: https://salsa.debian.org/uwsgi-team/uwsgi/-/tree/drop-cdbs
Bug#1076420: uwsgi: move away from cdbs
Source: uwsgi Version: 2.0.25.1-1 Severity: normal X-Debbugs-Cc: Jonas Smedegaard , Christian Hofstaedtler Dear Maintainer team, cdbs has been orphaned for 2 years and does not seem to be considered good practice for Debian packaging. src:uwsgi should move away from cdbs. I've began the work and it is available for comments. Although not usable yet, it shows the direction it's going. I'll follow-up here with my progress. https://salsa.debian.org/uwsgi-team/uwsgi/-/tree/drop-cdbs Alex -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-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#1073232: uwsgi: please drop deprecated 2to3 build dependency
Hi, The fix for this is awaiting sponsorship: https://mentors.debian.net/package/uwsgi/ Thanks, Alex
Bug#1075742: RFS: adminer/4.8.1-3 [RC] -- Web-based database administration tool
Hi, > 2. Lintian: Issue > > I: adminer source: composer-package-without-pkg-php-tools-builddep > [composer.json] composer is not used for building, false positive. https://salsa.debian.org/debian/adminer/-/commit/3aaa74ad22f411edba537271a9fd283cf7a92a18 > I: adminer: package-contains-empty-directory > [usr/share/adminer/designs/hydra/] > I: adminer: package-contains-empty-directory > [usr/share/adminer/designs/pepa-linha-dark/] No clue as to where those directories come from, investigating. > 3. Licenses: Issue > > d/copyright | licensecheck > > MIT | Expatdesigns/price/adminer.css > Apache-2.0 | Expatdesigns/rmsoft/adminer.css > Apache-2.0 | Expatdesigns/rmsoft_blue/adminer.css Those are false positives. Thanks, Alex
Bug#1075808: RFS: graphite-carbon/1.1.10-1 [RC] -- backend data caching and persistence daemon for Graphite
Package: sponsorship-requests Severity: important X-Debbugs-CC: Jonas Genannt , Thomas Goirand Dear mentors, I am looking for a sponsor for my package "graphite-carbon": * Package name : graphite-carbon Version : 1.1.10-1 Upstream contact : Chris Davis * URL : https://github.com/graphite-project/carbon * License : Custom-AMQP-Working-Group, Apache-2.0 * Vcs : https://salsa.debian.org/debian-graphite-team/graphite-carbon Section : utils The source builds the following binary packages: graphite-carbon - backend data caching and persistence daemon for Graphite To access further information about this package, please visit the following URL: https://mentors.debian.net/package/graphite-carbon/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/graphite-carbon/graphite-carbon_1.1.10-1.dsc Changes since the last upload: graphite-carbon (1.1.10-1) unstable; urgency=medium . [ Debian Janitor ] * Use secure copyright file specification URI. * Bump debhelper from old 10 to 13. + Replace python_distutils buildsystem with pybuild. + Use dh_installsystemd rather than deprecated dh_systemd_enable. + Use dh_installsystemd rather than deprecated dh_systemd_start. * Set debhelper-compat version in Build-Depends. * Replace /var/run with /run for the Service PIDFile. . [ Alexandre Rossi ] * update d/watch with move from md5 to sha256 * New upstream version 1.1.10 * Rules-Requires-Root: no * add myself to uploaders * add Pre-depends for --skip-systemd-native * declare compliance to policy 4.7.0 (no change) * port to py3.12 (Closes: #1074696, #1075712) * do not mess with python shebang (Closes: #1022922) * let dh do its cleaning magic (Closes: #1044615) * drop dep on lsb-base * StandardError= and StandardOutput= in unit files no longer support "syslog" Regards, -- Alexandre Rossi
Bug#1075743: RFS: uwsgi/2.0.26-1 -- fast, self-healing application container server
Hi, > A. piuparts problem [...] > The following packages have unmet dependencies: >libapache2-mod-ruwsgi : Conflicts: libapache2-mod-uwsgi but 2.0.26-1 is to > be installed >libapache2-mod-uwsgi : Conflicts: libapache2-mod-ruwsgi but 2.0.26-1 is to > be installed > E: Unable to correct problems, you have held broken packages. This is actually wanted, to modules actually conflict because they use the same apache2 configuration variables. Thanks, Alex
Bug#1075743: RFS: uwsgi/2.0.26-1 -- fast, self-healing application container server
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "uwsgi":
* Package name : uwsgi
Version : 2.0.26-1
Upstream contact : https://github.com/unbit/uwsgi/issues
* URL : http://projects.unbit.it/uwsgi/
* License : GPL-2+, GPL-2, Apache-2.0
* Vcs : https://salsa.debian.org/uwsgi-team/uwsgi
Section : httpd
The source builds the following binary packages:
libapache2-mod-ruwsgi - uwsgi module for Apache2 (mod_Ruwsgi)
libapache2-mod-ruwsgi-dbg - debugging symbols for Apache2 mod_Ruwsgi
libapache2-mod-uwsgi - uwsgi module for Apache2 (mod_uwsgi)
libapache2-mod-uwsgi-dbg - debugging symbols for Apache2 mod_uwsgi
python3-uwsgidecorators - module of decorators for elegant access to uWSGI
API (Python 3)
uwsgi - fast, self-healing application container server
uwsgi-app-integration-plugins - plugins for integration of uWSGI and
application
uwsgi-core - fast, self-healing application container server (core)
uwsgi-dbg - debugging symbols for uWSGI server and it's plugins
uwsgi-dev - fast, self-healing application container server (headers)
uwsgi-emperor - fast, self-healing application container server (emperor
scripts)
uwsgi-extra - fast, self-healing application container server (extra files)
uwsgi-infrastructure-plugins - infrastructure plugins for uWSGI
uwsgi-plugin-alarm-curl - cURL alarm plugin for uWSGI
uwsgi-plugin-alarm-xmpp - XMPP alarm plugin for uWSGI
uwsgi-plugin-asyncio-python3 - asyncio plugin for uWSGI (Python 3)
uwsgi-plugin-curl-cron - cron cURL plugin for uWSGI
uwsgi-plugin-emperor-pg - Emperor PostgreSQL plugin for uWSGI
uwsgi-plugin-fiber - Fiber plugin for uWSGI
uwsgi-plugin-gccgo - GNU Go plugin for uWSGI
uwsgi-plugin-geoip - GeoIP plugin for uWSGI
uwsgi-plugin-gevent-python3 - gevent plugin for uWSGI (Python 3)
uwsgi-plugin-glusterfs - GlusterFS storage plugin for uWSGI
uwsgi-plugin-graylog2 - graylog2 plugin for uWSGI
uwsgi-plugin-greenlet-python3 - greenlet plugin for uWSGI (Python 3)
uwsgi-plugin-jvm-openjdk-17 - Java plugin for uWSGI (OpenJDK 17)
uwsgi-plugin-jwsgi-openjdk-17 - JWSGI plugin for uWSGI (OpenJDK 17)
uwsgi-plugin-ldap - LDAP plugin for uWSGI
uwsgi-plugin-lua5.1 - Lua WSAPI plugin for uWSGI (Lua 5.1)
uwsgi-plugin-mono - Mono/ASP.NET plugin for uWSGI
uwsgi-plugin-psgi - Perl PSGI plugin for uWSGI
uwsgi-plugin-python3 - WSGI plugin for uWSGI (Python 3)
uwsgi-plugin-rack-ruby3.1 - Rack plugin for uWSGI (${uwsgi:RubyKind})
uwsgi-plugin-rados - Ceph/RADOS storage plugin for uWSGI
uwsgi-plugin-rbthreads - Ruby native threads plugin for uWSGI
(${uwsgi:RubyDefaultkind})
uwsgi-plugin-ring-openjdk-17 - Closure/Ring plugin for uWSGI (OpenJDK 17)
uwsgi-plugin-router-access - Access router plugin for uWSGI
uwsgi-plugin-servlet-openjdk-17 - JWSGI plugin for uWSGI (OpenJDK 17)
uwsgi-plugin-sqlite3 - SQLite 3 configurations plugin for uWSGI
uwsgi-plugin-tornado-python3 - tornado plugin for uWSGI (Python 3)
uwsgi-plugin-xslt - XSLT request plugin for uWSGI
uwsgi-plugins-all - all available plugins for uWSGI
uwsgi-src - sources for uWSGI plugins
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/uwsgi/
Alternatively, you can download the package with 'dget' using this command:
dget -x https://mentors.debian.net/debian/pool/main/u/uwsgi/uwsgi_2.0.26-1.dsc
Changes since the last upload:
uwsgi (2.0.26-1) unstable; urgency=medium
.
* New upstream version 2.0.26
* silence lintian on plugins needing linking to libc (uneeded)
* remove shebang on initscript modules that are only sourced
* remove obolete Provides/Conflicts of uwsgi-core
* uwsgi-emperor is arch independant
* drop useless build dep on libbz2-dev, libdb-dev, libonig-dev
* drop 1007_purge_lru-restore-fix.patch (already applied in source)
* unfuzz patches
* run upstream integration tests as autopkgtest
Regards,
--
Alexandre Rossi
Bug#1075742: RFS: adminer/4.8.1-3 [RC] -- Web-based database administration tool
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "adminer": * Package name : adminer Version : 4.8.1-3 * URL : https://www.adminer.org/ * License : Apache-2.0, MIT * Vcs : https://salsa.debian.org/debian/adminer Section : web The source builds the following binary packages: adminer - Web-based database administration tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/adminer/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/a/adminer/adminer_4.8.1-3.dsc Changes since the last upload: adminer (4.8.1-3) unstable; urgency=medium . * backport fixes for CVE-2023-45196 CVE-2023-45195 (Closes: #1074430) Regards, -- Alexandre Rossi
Bug#1075712: graphite-carbon: daemon does not start
Package: graphite-carbon Version: 1.1.7-1.2 Severity: grave Tags: patch upstream Justification: renders package unusable Dear Maintainer, The daemon fails to start with the following traceback. -- systemd[1]: Starting carbon-cache.service - Graphite Carbon Cache... carbon-cache[262]: Traceback (most recent call last): carbon-cache[262]: File "/usr/bin/carbon-cache", line 32, in carbon-cache[262]: run_twistd_plugin(__file__) carbon-cache[262]: File "/usr/lib/python3/dist-packages/carbon/util.py", line 71, in run_twistd_plugin carbon-cache[262]: from carbon.conf import get_parser carbon-cache[262]: File "/usr/lib/python3/dist-packages/carbon/conf.py", line 31, in carbon-cache[262]: from carbon.routers import DatapointRouter carbon-cache[262]: File "/usr/lib/python3/dist-packages/carbon/routers.py", line 1, in carbon-cache[262]: import imp carbon-cache[262]: ModuleNotFoundError: No module named 'imp' systemd[1]: carbon-cache.service: Control process exited, code=exited, status=1/FAILURE -- This seems to be fixed upstream. https://github.com/graphite-project/carbon/commit/dea2ddb038b01eff16f5da4a19c7282e438ec19a Thanks. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-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 graphite-carbon depends on: ii adduser3.137 ii debconf [debconf-2.0] 1.5.86 ii lsb-base 11.6 ii python33.12.2-1 ii python3-cachetools 5.3.3-1 ii python3-twisted24.3.0-2 ii python3-urllib32.0.7-2 ii python3-whisper1.1.4-2.2 ii sysvinit-utils [lsb-base] 3.09-2 graphite-carbon recommends no packages. Versions of packages graphite-carbon suggests: pn graphite-web -- debconf information: * graphite-carbon/postrm_remove_databases: false
Bug#1074430: adminer: CVE-2023-45196 CVE-2023-45195
Hi, > > It seems adminer is dead upstream and adminerevo picked up development, > > so most likely Debian should follow the new upstream? > > I have not been able to find[1] a sponsor for adminerevo although the > packaging > as a separate source package is done. > > I can easily switch src:adminer to use adminerevo source as I have DM upload > rights for adminer, but that is not what I have been instructed to do. Actually I don't have DM upload rights for adminer. So the fixed package is awaiting sponsorship: https://mentors.debian.net/package/adminer/ Thanks, Alex
Bug#1073005: transmission: consider switching back to vendored libb64
Hi, > > Regarding those valid points, because there is not reason to have the same > > source in multiple packages, there are only 2 paths compliant with the > > Debian > > policy: > > > > 1) Fix those points in src:libb64 for transmission and all rdepends > > 2) Remove src:libb64 from Debian and then vendor in transmission source > > > > I'll try to move towards 1) and see how it goes. So for now, this is a > > wontfix because against DFSG. > > I agree that it would be helpful if many of these issues were fixed > for all users of libb64. > > On the other hand, this does not fix the fact that libb64 has been > unmaintained since 2013 and therefore it still wouldn't be a good > candidate to complete Ubuntu's Main Inclusion process even if the > other issues were fixed. Therefore, Ubuntu will need to keep vendoring > libb64 in transmission. I am unaware of any maintained version of > libb64. > > I disagree that this violates the Debian Free Software Guidelines > although it does violate what is normally considered "best practice" > in Debian development. However, there are many exceptions to this best > practice in Debian and there is a lot of vendored code. (Even after > your recent work, transmission still has vendored code and that is not > a DFSG violation). Notably, Debian ftpmasters routinely accept new > packages that have vendored code as long as the code is correctly > documented in debian/copyright (which had been done for transmission). > See https://wiki.debian.org/EmbeddedCopies Debian policy 4.13: If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. I reckon *should* is not *must*. I'll seek advice on this. Thanks, Alex
Bug#1074430: adminer: CVE-2023-45196 CVE-2023-45195
Hi, Thanks a lot for reporting, I should have seen that. > It seems adminer is dead upstream and adminerevo picked up development, > so most likely Debian should follow the new upstream? I have not been able to find[1] a sponsor for adminerevo although the packaging as a separate source package is done. I can easily switch src:adminer to use adminerevo source as I have DM upload rights for adminer, but that is not what I have been instructed to do. Regarding the present bug report, I'll backport the fixes in the coming days. [1] https://bugs.debian.org/1065534 Thanks, Alex
Bug#1069641: nmu: uwsgi-plugin-php_0.0.15 uwsgi-plugin-luajit_0.0.8 uwsgi-plugin-mongo_0.0.9
Hi, Gentle reminder to ask for this to be scheduled, or any blockers to be raised so that I can fix those. Thanks, Alex -- 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_0.0.15 . ANY . unstable . -m "rebuild against new uwsgi.h" nmu uwsgi-plugin-luajit_0.0.8 . ANY . unstable . -m "rebuild against new uwsgi.h" nmu uwsgi-plugin-mongo_0.0.9 . ANY . unstable . -m "rebuild against new uwsgi.h"
Bug#1073763: transmission-daemon: move aliased files from / to /usr (DEP17)
Hi, This has been fixed[1] and is pending an upload. We'll surely upload before August 6th. [1] https://salsa.debian.org/debian/transmission/-/commit/4c54d7e15dbb7bd81cbb50f9f9dbc9c37e584966 Thanks for reporting, Alex
Bug#1073005: transmission: consider switching back to vendored libb64
block 1073005 by 1073203 thanks Hi, Thanks for raising this to our attention. [...] > - libb64 has been unmaintained since 2013 > https://sourceforge.net/p/libb64/git/commit_browser > - libb64 has several open bugs, some of which have security implications > https://sourceforge.net/p/libb64/bugs/ > - libb64 is missing a pkgconfig file which is a relatively simple > standard way for other software to use libb64 > https://launchpad.net/bugs/1534293 > - The Debian packaging is not using simple dh rules. The packaging > seems to otherwise be fairly modern but it's more complicated than > typical Debian packages. > https://salsa.debian.org/alteholz/libb64/-/blob/master/debian/rules Regarding those valid points, because there is not reason to have the same source in multiple packages, there are only 2 paths compliant with the Debian policy: 1) Fix those points in src:libb64 for transmission and all rdepends 2) Remove src:libb64 from Debian and then vendor in transmission source I'll try to move towards 1) and see how it goes. So for now, this is a wontfix because against DFSG. Thanks, Alex
Bug#1073203: libb64: switch to maintained fork
Source: libb64 Version: 1.2-5 Severity: normal Dear Maintainer, The bug reporter of #1073005 has brought to my attention that src:libb64 could switch to a better maintained fork to ease maintenance. He suggested https://github.com/libb64/libb64 But I would also suggest https://github.com/transmission/libb64/tree/post-2.0.0-transmission Also, switching to modern dh would be great. I could give it a try if you would confirm this would be okay for you. I would prefer this package to be updated rather than going back embed a copy in transmission source. Thanks for considering, Alex -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-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#1036775: transmission-gtk: Stuck / segfault on startup
Hi, I cannot reproduce with 4.x . Can you confirm this is all good? Thanks, Alex
Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Hi, > I saw that you just closed this bug a couple of hours ago. Coincidentally, > last night I finally had the time to recompile the package for > bullseye/arm64 and install it on my raspberry pi (I could not use your > backport as it is a different arch). I tested this problem, and I can > confirm that it is effectively fixed. Thanks a lot for you feedback. > PS: It would be great if you could upload the backport to debian too! Now that transmission is back in testing, that's an option. Will do if I fin sponsorship for this. Thanks, Alex
Bug#1071052: reportbug: proposed version for binNMU should be source package version
tag 1071052 patch thanks Hi, > When filling a binNMU for a package with fancy binary package versionning, it > appears that reportbug uses the binary package version instead of the source > package version. I've proposed a PR for this. https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/94 Thanks, Alex
Bug#1071052: reportbug: proposed version for binNMU should be source package version
Package: reportbug Version: 13.0.1 Severity: minor Dear Maintainer, When filling a binNMU for a package with fancy binary package versionning, it appears that reportbug uses the binary package version instead of the source package version. For instance, when filling a binNMU for src:uwsgi-plugin-php 0.0.15 with uwsgi-plugin-php version 2.0.22+4+0.0.15+b2 in unstable, reportbug detects 2.0.22+4+0.0.15+b2 as the version instead of 0.0.15 . $ reportbug release.debian.org [...] Please enter the name of the package: uwsgi-plugin-php Checking package information... Your report will be carbon-copied to the package maintainer. Latest version seems to be 2.0.22+4+0.0.15+b2, is this the proper one [Y|n|?]? reportbug should instead choose the source package version. Latest version seems to be 0.0.15, is this the proper one [Y|n|?]? ^^ Thanks, Alex -- Package-specific info: ** Environment settings: EDITOR="vi" VISUAL="vi" REPORTBUGEMAIL="Alexandre Rossi " EMAIL="Alexandre Rossi " DEBFULLNAME="Alexandre Rossi" INTERFACE="text" ** /home/niol/.reportbugrc: reportbug_version "3.31" mode standard ui text -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-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 reportbug depends on: ii apt2.9.2 ii python33.11.8-1 ii python3-reportbug 13.0.1 ii sensible-utils 0.0.22 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.86 ii debsums 3.0.2.1 pn default-mta | postfix | exim4 | mail-transport-agent pn dlocate pn emacs-bin-common ii file 1:5.45-3 ii gnupg 2.2.40-3 pn python3-urwid pn reportbug-gtk ii xdg-utils 1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.9.2 ii file 1:5.45-3 ii python33.11.8-1 ii python3-apt2.9.0 ii python3-debian 0.1.49 ii python3-debianbts 4.0.2 ii python3-requests 2.31.0+dfsg-1 ii sensible-utils 0.0.22 python3-reportbug suggests no packages. -- no debconf information
Bug#1051056: transmission-daemon: memory leaks lead to eventual memory exhaustion
Hi, Is this still an issue in 4 ? Thanks, Alex
Bug#858932: agressive disk write i/o load caused by logging subsystem
Hi, Is this still current? This seems to be fixed upstream, unreproductible for me. Thanks, Alex
Bug#841730: transmission: GUI dropdown menu size issue
Hi, As transmission-gtk correctly depends on libgtk-4-1 and correctly sizes that menu in 4.0.5-2, I guess this is fixed. I'll close this in a few days unless something is raised. Thanks, Alex
Bug#949969: transmission-gtk uses 100% of a CPU core
Hi, > > Downloading a torrent with transmission 4 from unstable does not use 100% > > CPU core. > > > > Can you reproduce? > > I have upgraded to 4.0.2-1 since then and I am now using the QT client. > But using the updated torrent (see http://osm.cquest.org/torrents) top > still reports Transmission using a full core: > > $ top -n1 | grep trans > 10472 fgouget 20 0 3520476 328540 62496 S 118.8 1.0 330:01.80 > transmi+ > > So 118% CPU. > > But in ps the CPU usage is stuck at 3.7%: > $ ps aux | grep trans > fgouget10472 3.7 1.0 3520476 329364 ? Sl Apr19 329:41 > /usr/bin/transmission-qt -session > 10cae0c76f00017076185990334600170_1710862333_885767 > > This is while downloading the current osm.pdf.torrent file at a reported > 150 MB/s average speed (1200 Mbps). While this is a 1 Gbps Internet > connection and it is indeed maxed out, that still at most 125 MB/s. So I > think the data must be compressed and transmission is reporting the > uncompressed data transfer rate. > > Also now that the transfer is complete transmission is back to 0% CPU > usage. > > So maybe transmission was just kept busy by the fast transfer rate? > (i7-4790K, verifying and uncompressing the data) I guess so, because when I download this torrent using transmission-daemon at 120 MB/s on a lower end machine, the CPU core usage changes between 10% and 120%. I guess this is all normal, fast transfer rates are demanding. Do you see other unsual CPU usage than can be linked with very low transfer rates? If not, I guess we can close this. Thanks, Alex
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
