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,
t;
> 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
>
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
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:
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
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
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
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
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
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
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
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
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
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
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.
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
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
Hi,
Thanks for reporting.
> /usr/src/uwsgi/plugins/php/php_plugin.c: In function ‘php_uwsgi_startup’:
> /usr/src/uwsgi/plugins/php/php_plugin.c:610:13: error: too many arguments to
> function ‘php_module_startup’
> 610 | if (php_module_startup(_sapi_module,
> _module_entry,
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
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
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
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
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 (HEAD ->
> > > > > 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:
> > > >
> > > >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
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
>
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
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
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 -
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.
>
>
> >> 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
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
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 :
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
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
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:
>> 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
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
>>
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 module
parser.print_help()
File /usr/lib/python2.7/optparse.py, line 1670, in print_help
file.write(self.format_help().encode(encoding, replace))
File
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
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 the
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 the
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
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:
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 module
vboxgtk.main()
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
65 matches
Mail list logo
