Hi,
> * What led up to the situation?
> Launching transmission-gtk
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
>Lauching either by CLI or through another software
> * What was the outcome of this action?
> transmission-gtk runs for a while (no more
close 1105144
thanks
This was fixed with the binNMU documented in #1104206.
Hi,
> > > It turns out that current src:uwsgi-plugin-python has unsatisfiable
> > > dependencies on uwsgi-abi-fd03c85edfee33327ac760f246543e10 [0].
> > >
> > > Filing as serious because this bug causes migration stalls in sid for
> > > piuparts testing of reverse dependencies [1].
> >
> > I was a
Hi,
> I guess this could be related to #1104206, but filing as a separate bug
> at your discretion.
Yes it is.
> It turns out that current src:uwsgi-plugin-python has unsatisfiable
> dependencies on uwsgi-abi-fd03c85edfee33327ac760f246543e10 [0].
>
> Filing as serious because this bug causes mig
close 1094637 2.0.28-6
thanks
close 1094637 0.0.2+b1
thanks
Control: -1 tag patch
Hi,
The patch added[1] to uwsgi source should fix this.
[1]
https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/821b8660058e0040cc34b3120a9a8a44ce788578
Thanks,
Alex
Hi,
> we see autopkgtest failures of uwsgi-plugin-ruby with our recent uploads of
> Ruby 3.3 and others.
This report is confusing because all is well in unstable. Not so in testing.
> So I tried to build the package and run autopkgtest myself. The first error
> that comes up is:
>
> > FileNotFou
Package: python3-pil
Version: 11.1.0-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
The basic import that most use from PIL fails:
$ python3
Python 3.13.1 (main, Jan 3 2025, 10:26:34) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more inf
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 replacem
close 1074430 4.8.1-4
thanks
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 (
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:adm
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
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, i
>
> 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.
>
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-buildpackag
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
Hi,
> > please push this packaging effort to a personal (but publicly
> > accessible) git repo on salsa, so that i can cherry pick the changes i
> > like, thanks
>
> Here:
>
>
> https://salsa.debian.org/niol/transmission/-/tree/master-candidate?ref_type=heads
I've also updated my pull requ
Hi,
> > A fixed version is awaiting sponsorship at:
> >
> > https://mentors.debian.net/package/transmission/
>
> please push this packaging effort to a personal (but publicly
> accessible) git repo on salsa, so that i can cherry pick the changes i
> like, thanks
Here:
https://salsa.deb
Hi,
A fixed version is awaiting sponsorship at:
https://mentors.debian.net/package/transmission/
I'll also do my best to fix any issues regarding this proposed 4.0.5-1 update.
Thanks,
Alex
severity 1053988 important
thanks
Hi,
Lowering severity as transmission-daemon works well.
Thanks,
Alex
> The source package contains:
>
> web/public_html/index.html
> web/public_html/transmission-app.js
>
> These files are copied into the binary package as:
>
> /usr/share/transmission/public_html/index.html
> /usr/share/transmission/public_html/transmission-app.js
>
> Those files should be built
close 1052845 1:0.5.0-5
thanks
Hi,
Seems like this is fixed in:
https://salsa.debian.org/python-team/packages/python-django-tagging/-/merge_requests/2
Thanks,
Alex
Hi Jonas,
> > If I get some advice on the best practrices for having d/control.in with
> > template variables, I would be happy to work on this.
>
> I assume you mean the debian/control file (as the uwsgi source package
> currently contains no debian/control.in file).
> That file gets mangled whe
Hi,
Following attempted fixes of #1051752, please not that I seem to have fixed it
(tested on i386) in
https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/5cdb4e37be8dd93cefdcceeb199efe990b2eb918
.
If I get some advice on the best practrices for having d/control.in with
template variables, I wou
Hi,
> > > > > Your package still depends on the old, obsolete PCRE3[0] libraries
> > > > > (i.e. libpcre3-dev). This has been end of life for a while now, and
> > > > > upstream do not intend to fix any further bugs in it. Accordingly, I
> > > > > would like to remove the pcre3 libraries from Debi
Hi,
> > > Your package still depends on the old, obsolete PCRE3[0] libraries
> > > (i.e. libpcre3-dev). This has been end of life for a while now, and
> > > upstream do not intend to fix any further bugs in it. Accordingly, I
> > > would like to remove the pcre3 libraries from Debian, preferably i
Hi,
> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). This has been end of life for a while now, and
> upstream do not intend to fix any further bugs in it. Accordingly, I
> would like to remove the pcre3 libraries from Debian, preferably in
> time for the
Source: transmission
Version: 4.0.1-1
Severity: serious
Justification: Policy 2.2.1
Hi,
The source package contains:
web/public_html/index.html
web/public_html/transmission-app.js
These files are copied into the binary package as:
/usr/share/transmission/public_html/index.html
/usr/share/trans
tag patch fixed-upstream
thanks
Hi,
> davmail.connection - DISCONNECT - 127.0.0.1:41156 60s Exception in thread
> "Shutdown" java.lang.IllegalMonitorStateException: current thread is not
> owner
> 60s 2023-06-24 23:58:12,579 INFO [Shutdown] davmail - DavMail gateway
> stopped
> 60s at java
Hi,
> Attempting to unpack davmail-server/6.0.1.3390-6 from Debian bookworm
> on a minimal Debian bullseye with davmail/5.5.1.3299-5
> installed, causes an unpack error from dpkg due to
> /etc/davmail/davmail.properties being contained in both packages.
Yes I can reproduce. You should remove davm
Hi,
All is good now, #1028374 is fixed. No change regarding this is required in
davmail.
Thanks,
Alex
Hi,
> > Thanks a lot but looks like the fix was not complete.
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029908
> >
> > Can you upload a version with the fix available in the bug report?
>
> Done. This time I merged the commit from your repo on Salsa, and also
> ran the autopkg
Hi,
> The update looks good to me and a rebuild of rdeps with ratt was
> successful. Or more precisely, was successful for the packages that
> also build against 5.12.1. So I have just uploaded to the archive.
Thanks a lot but looks like the fix was not complete.
https://bugs.debian.org/cgi-bi
Hi,
> > Sorry, but I fail to see any problem here.
> >
> > uwsgi _does_ build against the default Python.
>
> Yes, but the default Python it builds against in unstable is not necessarily
> the default Python in testing.
>
> Right now, it is built against Python 3.11, while the default Python in
Hi,
I prepared an updated package with the new upstream version.
https://mentors.debian.net/package/libjna-java/
My commits are available at: https://salsa.debian.org/niol/libjna-java/
Thanks,
Alex
Hi,
> The fix seems straightforward, I'll see if I can provide a patch.
The fix was indeed straightforward and tested successfully.
https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/36aaa1dd685b446d0240f89e000b04fc6031e324
@Jonas, please ping me if you need some help to prepare the upload of u
Hi,
Thanks for reporting.
> /usr/src/uwsgi/plugins/php/php_plugin.c: In function ‘php_uwsgi_startup’:
> /usr/src/uwsgi/plugins/php/php_plugin.c:610:13: error: too many arguments to
> function ‘php_module_startup’
> 610 | if (php_module_startup(&uwsgi_sapi_module,
> &uwsgi_module_entry
Hi,
Thanks for reporting, had seen this.
My understanding is that the bug is in libjna-java and I've reproduced
it, see #1028374.
Plan A: I succeed to have a fix for libjna-java and get it uploaded before
the end of January.
Plan B: I revert debian/patches/sd-notify.patch to drop the dependecy o
Hi,
Thanks for your report.
> When trying to update davmail / install davmail-server I get:
>
>
> Setting up davmail-server (6.0.1.3390-3) ...
> insserv: script davmail-server: service davmail already provided!
> update-rc.d: error: no runlevel symlinks to modify, aborting!
> dpkg: error processi
Hi,
> > This change wasn't necessary (but is harmless).
> >
> > The actual bug (#1007254) was fixed in apache2-dev.
>
> Thanks for the notice, Adrian - I'll drop that needless build-dependency
> for next release.
Sorry to have missed this, I just noticed that the mirror I use is
off by nearly
Hi,
> /usr/bin/ld: cannot find -lpcre2-8: No such file or directory
I've pushed the necessary fix.
https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/0955366dcf19b7ec9a0134eab1e81ec216d12a96
Thanks,
Alex
Source: uwsgi
Version: 2.0.20-2.2
Severity: serious
Tags: ftbfs
Justification: Policy 4.9
Dear Maintainer,
uwsgi fails to build from source in a sbuild chroot with the following error.
/usr/share/apr-1.0/build/libtool --mode=link --tag=disable-static
x86_64-linux-gnu-gcc -Wl,--as-needed -Wl,-z
Hi,
> My current policy was to Suggest: deps required by the ui components.
> This enables server users to skip those. I think I'll add default-jre
> as a Suggest: for the mean time
Moving on with the above solution.
Thanks, and sorry for the misinterpretation of bug severity values.
Alex
close 962496 0.0.9
thanks
CI result is good.
https://ci.debian.net/data/autopkgtest/testing/amd64/u/uwsgi-plugin-php/5834204/log.gz
Thanks,
Alex
Hi,
> You recently added an autopkgtest to your package uwsgi-plugin-php,
> great. However, it fails. Currently this failure is blocking the
> migration to testing [1]. Can you please investigate the situation and
> fix it?
This is the same as #962186 which should be fixed by the freshly uploaded
d
> > make[1]: Entering directory '/<>'
> > uwsgi --build-plugin /usr/src/uwsgi/plugins/php
> > make[1]: *** [debian/rules:29: override_dh_auto_build] Error 1
The following patch fixes the problem.
Thanks,
Alex
commit f3fc84b5e9c73d3cda24306df62cb334cb5d33f7 (H
> > > > > I have a patch but I have not been able to test it yet because
> > > > > the py2 removal makes the package FTBS... I'm close to fix it
> > > > > though. I'll post an update here by wednesday.
> > > >
> > > > The patch I want to test is here:
> > > > https://sml.zincube.net/~niol/repos
> > > >Do you require some assistance regarding a new upload of uwsgi? I'm
> > > >eager to dedicate some time to it if you can't do so. :)
> > >
> > > I have a patch but I have not been able to test it yet because the py2
> > > removal makes the package FTBS... I'm close to fix it though. I'll po
Hi,
> >Do you require some assistance regarding a new upload of uwsgi? I'm
> >eager to dedicate some time to it if you can't do so. :)
>
> I have a patch but I have not been able to test it yet because the py2
> removal makes the package FTBS... I'm close to fix it though. I'll post an
> update
Le 13 octobre 2019 01:04:46 GMT+02:00, "Pierre-Elliott Bécue"
a écrit :
>Le jeudi 03 octobre 2019 à 11:50:48+0200, Jonas Smedegaard a écrit :
>> Quoting Alexandre Rossi (2019-10-02 15:04:54)
>> > > > > > Do you have plans/solutions regarding this issu
> > > > Do you have plans/solutions regarding this issue? Is it possible
> > > > to drop uwsgi-core dependency on libmatheval1?
> > >
> > > It should be as simple as not building the matheval plugin which is
> > > not critical to uwsgi. Should I go on with this?
> >
> > Yeah, I just wasn't sure
Hi,
> uwsgi-core depends on libmatheval1, which future in the archive seems
> compromised, this implies that src:uwsgi and all packages which depend
> on it will get out of the archive sooner or later.
>
> Do you have plans/solutions regarding this issue? Is it possible to drop
> uwsgi-core depen
close 911514 5.0.0.2801-2~bpo9+1
thanks
> > unfortunately davmail fails to build from source with
> > libjackrabbit-java 2.18.0. Long deprecated methods have been removed.
> > Your package build-depends on a very old version of jackrabbit (2.4.3).
This is too much work and I'm afraid if I do not get help I'll miss
the 2019-02-12 - Soft-
Hi,
> unfortunately davmail fails to build from source with
> libjackrabbit-java 2.18.0. Long deprecated methods have been removed.
> Your package build-depends on a very old version of jackrabbit (2.4.3).
>
> See also the deprecated list that explains which methods should be
> used instead.
>
> h
> >> I've prepared updates for the davmail backport and its libhtmlcleaner
> >> dependency :
> >> https://sml.zincube.net/~niol/tmp/
>
> building the libhtmlcleaner-java backport in stretch fails:
> Error: Could not find or load main class
> org.apache.maven.surefire.booter.ForkedBooter
I've upda
Hi Geert,
> I've prepared updates for the davmail backport and its libhtmlcleaner
> dependency :
> https://sml.zincube.net/~niol/tmp/
>
> Those are awaiting sponsorship (the process for granting me upload
> rights also to backports is ongoing).
Granting me upload rights to the backports archive d
tag 911514 pending
thanks
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
I've prepared updates for the davmail backport and its libhtmlcleaner
dependency :
https:/
Hi,
> The latest version of davmail fails to execute from initscripts if
> ENABLE_DAEMON is set to true. Appears to be because
> /usr/share/java/davmail-4.9.0.2652.jar does not have execute permissions.
> chmod +x to the target resolves the problem.
Thanks a lot for reporting and providing a work
Hi,
> This is a jarwrapper bug, the CheckProperty class was compiled without
> specifying the source/target level, thus defaulting to Java 10 bytecode
> (version 54.0).
Thanks but the second part of the stacktrace is still on davmail.
I need to investigate between these options:
1) make the bina
Hi,
Thanks for reporting.
Debian buster has java10 as default java. I cannot make davmail run
with java8 and java10 and at the same time compile it with java10. I'm
seeking advice for now about how to solve.
You can work around the bug by running davmail with java10:
$ sudo update-alternatives -
Control: tag -1 pending
Hello,
Bug #896730 in lazygal reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
https://salsa.debian.org/python-team/applications/lazygal/commit/25f3c71ad39a7211b
>> FYI, I would be happy to move on with this but I'm stuck with the
>> program segfaulting when used with the proposed patch. It works
>> correctly if launched like this :
>> SWT_GTK3=0 davmail
>>
>> I'm still investigating as to why.
>>
>> Alex
>>
>>
>> (SWT:24928): GLib-GObject-WARNING
Hi,
> Because this is in a way blocking the removal of the unmaintained
> webkitgtk from Debian Testing, I am bumping the severity.
>
> See https://bugs.debian.org/880470
FYI, I would be happy to move on with this but I'm stuck with the
program segfaulting when used with the proposed patch. It wo
Hi,
> The davmail program don't start: it stay hang and no ports are
> listening.
This should be fixed by the version awaiting sponsorship on mentors.d.o
https://mentors.debian.net/package/davmail
Alex
Hi,
>> The change done in unison 2.48 to overcome this looks pretty big... I'm
>> not sure I'll be able/willing to provide a unison2.40.102 any more.
>> Moreover, this package was created to provide compatibility with
>> previous Debian releases, but another change in OCaml 4.02 makes it
>> incomp
> 1) After an update one of lazygal's dependencies, the following
> program fails. Maybe it is not good to mix gi bindings with old ones.
This is a change in either Gstreamer or GObject.
$ cat gst-import-error.py
#!/usr/bin/env python
from gi.repository import GObject
import gobject
import pygst
Hi,
> lazygal -o /tmp/test test
> Traceback (most recent call last):
> File "/usr/bin/lazygal", line 166, in
> parser.print_help()
> File "/usr/lib/python2.7/optparse.py", line 1670, in print_help
> file.write(self.format_help().encode(encoding, "replace"))
> File "/usr/lib/python2.
tag 753954 pending
thanks
Hi,
> Your package seems to include some files that lack sources
> in prefered forms of modification:
>
> data/htdocs/js/lib/jquery.js
Fixed package is awaiting sponsorship.
http://mentors.debian.net/debian/pool/main/d/deejayd/deejayd_0.10.0-7.dsc
I added debian/p
>> With the recent update of python-gi from 3.10 to 3.12, lazygal is rendered
>> unusable. Every time it starts scanning a source directory, it dies with the
>> traceback pasted below.
> [...]
>> TypeError: metaclass conflict: the metaclass of a derived class must be a
>> (non-strict) subclass of
Hi,
> With the recent update of python-gi from 3.10 to 3.12, lazygal is rendered
> unusable. Every time it starts scanning a source directory, it dies with the
> traceback pasted below.
[...]
> TypeError: metaclass conflict: the metaclass of a derived class must be a
> (non-strict) subclass of th
Hi,
I can confirm that the following line fixed this for me :
$ sudo pam-auth-update --force
Thanks,
Alex
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
> Lazygal exits immediately with an error, because the "defaults.conf"
> file is missing from the package.
Sorry, I was bitten by a distutils bug as I made the mistake of
building the source tarball in squeeze.
Upstream version 0.7.4 fixes this and only this.
Thanks,
Alex
--
To UNSUBSCR
Hi,
> it seems that there is something going badly wrong wrt to python/exif
> prohibiting lazygal even to show the help page, rendering it completely
> unusable:
[...]
> ImportError: /usr/lib/pymodules/python2.5/libpyexiv2.so: undefined symbol:
> _ZN5Exiv28ExifData5eraseEN9__gnu_cxx17__normal_ite
Package: vboxgtk
Version: 0.5.0-1
Severity: grave
Justification: renders package unusable
When launched, vboxgtk fails with a unhelpful error message. Maybe it is dued
to the new virtualbox version.
Traceback (most recent call last):
File "/usr/bin/vboxgtk", line 90, in
vboxgtk.main()
Fi
FYI, I installed svn snapshot 8066 from :
http://kernel-archive.buildserver.net/debian-kernel/pool/main/l/linux-2.6/linux-image-2.6.18-4-vserver-amd64_2.6.18-9~snapshot.8066_amd64.deb
and I cannot reproduce this bug.
Thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsub
79 matches
Mail list logo
