Bug#1067047: Buildng the package removes debian/.gitlab-ci.yml
Source: gnucash Version: 1:5.5-1.1 Severity: serious Simply build the package from source produces a source package that doesn't contain debian/.gitlab-ci.yml in debian.tar, one needs to rebuild the source package separately, skipping the clean target. The reason for that is that the file is listed debian/clean for some reason (alternatively, if it shouldn't be in the package, please remove it from the package). -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1065751: Incomplete fix for xz -T1
Package: pristine-tar Version: 1.50+nmu1 Severity: serious X-Debbugs-Cc: Sebastian Andrzej Siewior It looks like #1063252 was not enough to support tar.xz files created by new xz-utils. I've created a tarball, committed it into my gbp repo, checked it out and xz -lvv doesn't show the cu flags for it (and so it's not identical to the original one). As making a minimal example involving git sounds too complicated I tried to make a minimal example with raw commands, hopefully I did that correctly: $ mkdir 1 $ echo foo > 1/bar $ tar cJf 1.tar.xz 1 $ xz -lvv 1.tar.xz [...] Flags cu [...] $ pristine-tar gendelta 1.tar.xz 1.tar.xz.delta $ cd 1 $ pristine-tar gentar ../1.tar.xz.delta ../2.tar.xz $ xz -lvv ../2.tar.xz [...] Flags -- [...] -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pristine-tar depends on: ii bzip21.0.8-5+b2 ii libbz2-1.0 1.0.8-5+b2 ii libc62.37-15.1 ii libsys-cpuaffinity-perl 1.13~03-2+b3 ii pbzip2 1.1.13-1 ii perl 5.38.2-3.2 ii pixz 1.0.7-2 ii tar 1.35+dfsg-3 ii xdelta 1.1.3-10.6 ii xdelta3 3.0.11-dfsg-1.2 ii xz-utils 5.6.0-0.2 ii zlib1g 1:1.3.dfsg-3.1 pristine-tar recommends no packages. pristine-tar suggests no packages. -- debconf-show failed
Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'
On Tue, Mar 05, 2024 at 09:22:37AM +0300, Michael Tokarev wrote: > > Package: qemu-system-data > > Version: 1:8.2.2+ds-1 > > Severity: serious > > > > > > Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ... > > Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ... > > dpkg: error processing archive /var/cache/apt/archives/qemu-system- > > data_1%3a8.2.2+ds-1_all.deb (--unpack): > > trying to overwrite '/usr/share/doc/qemu-system- > > common/system/arm/aspeed.html', which is also in package qemu-system-common > > 1:8.2.1+ds-2 > > Hmm. > > In 8.2.2 I moved common docs from arch-dependent package qemu-system-common > to arch-indep package qemu-system-data. Current control fields for the > latter, among others, has: > > Breaks: qemu-system-common (<< 8.2.1+ds-3~), > Replaces: qemu-system-common (<< 8.2.1+ds-3~), > > so... what's going on here? q-s-d 8.2.2 replaces files from q-s-c 8.2.1 Can it be simply because the package has an epoch and relations should include it? -- WBR, wRAR signature.asc Description: PGP signature
Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'
Package: qemu-system-data Version: 1:8.2.2+ds-1 Severity: serious Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ... Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ... dpkg: error processing archive /var/cache/apt/archives/qemu-system- data_1%3a8.2.2+ds-1_all.deb (--unpack): trying to overwrite '/usr/share/doc/qemu-system- common/system/arm/aspeed.html', which is also in package qemu-system-common 1:8.2.1+ds-2 -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- debconf-show failed
Bug#1065315: libcurl4t64 Provides libcurl3-gnutls
Package: libcurl4t64 Version: 8.6.0-3.1 Severity: serious X-Debbugs-Cc: vor...@debian.org, aure...@debian.org Yet another case of wrong X-Time64-Compat, found by Aurelien. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcurl4t64 depends on: ii libbrotli11.1.0-2+b3 ii libc6 2.37-15.1 ii libgssapi-krb5-2 1.20.1-5+b1 ii libidn2-0 2.3.7-2 ii libldap-2.5-0 2.5.13+dfsg-5+b3 ii libnghttp2-14 1.59.0-1 ii libpsl5 0.21.2-1+b1 pn libpsl5t64 ii librtmp1 2.4+20151223.gitfa8646d.1-2+b2 ii libssh2-1t64 [libssh2-1] 1.11.0-4.1 ii libssl3t64 [libssl3] 3.1.5-1.1 ii libzstd1 1.5.5+dfsg2-2 ii zlib1g1:1.3.dfsg-3.1 Versions of packages libcurl4t64 recommends: ii ca-certificates 20240203 libcurl4t64 suggests no packages.
Bug#1065155: libpoppler-glib8t64 Provides libpoppler-cpp0v5 instead of libpoppler-glib8
Package: libpoppler-glib8t64 Version: 22.12.0-2.1 Severity: serious X-Debbugs-Cc: Steve Langasek Actually, looking at the diff in #1064282, all packages have "X-Time64-Compat: libpoppler-cpp0v5", I guess this is incorrect and a typo? -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpoppler-glib8t64 depends on: ii libc6 2.37-15.1 ii libcairo2 1.18.0-1+b1 ii libfreetype6 2.13.2+dfsg-1+b1 ii libglib2.0-0t64 2.78.4-2.1 pn libpoppler126t64 ii libstdc++614-20240221-2.1 libpoppler-glib8t64 recommends no packages. libpoppler-glib8t64 suggests no packages.
Bug#1065154: libqt5sql5t64 Provides libqt5core5a instead of libqt5sql5
Package: libqt5sql5t64 Version: 5.15.10+dfsg-7.1 Severity: serious X-Debbugs-Cc: vor...@debian.org I haven't checked but the same problem may also be present for other subpackages. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1008751: pytest-mpi: autopkgtest regression: versioned test depends only in experimental
On Fri, Apr 01, 2022 at 06:04:38PM +0200, Drew Parsons wrote: > From > /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources: > > flufl.lock Doesn't support Sybil 3.x in sid. The latest version, 7.0, supports it. It's most likely easy to patch the sid version. > pytest-mpi - > python-parsel The fix is committed upstream but there was no release since then. It should be easy to backport the fix. > python-public Doesn't support Sybil 3.x in sid. The latest version, 3.0.1, supports it. It's most likely easy to patch the sid version. > python-scrapy Fixed upstream but the upload is postponed until the next bugfix release. It should be easy to backport the fix. > python-testfixtures Should work. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1008751: pytest-mpi: autopkgtest regression: versioned test depends only in experimental
On Fri, Apr 01, 2022 at 05:42:36PM +0200, Drew Parsons wrote: > Source: pytest-mpi > Followup-For: Bug #1008751 > X-Debbugs-Cc: Andrey Rahmatullin > > Hi Andrey, > > I had pytest-mpi 0.6 quietly waiting in experimental for sybil 3 to be > uploaded. > > I saw that pytest-mpi finally got built (sybil 3 got uploaded), so > I got enthusiastic and immediately uploaded pytest-mpi to unstable. > > But I didn't think to check first what exactly had enabled pytest-mpi > 0.6 to build in experimental. I assumed it was updates in unstable, > but in fact it was python-sybil 3.0.1 from experimental. > > At this point python3-sybil has no other reverse dependencies. It has 6 reverse build-dependencies, most of which don't support 3.x, at least in sid but maybe at all. They need to be updated or patched first. > Therefore in order to work around my premature upload of pytest-mpi > 0.6, could we now upload python-sybil 3.0.1 to unstable? It should be > safe to do so since other packages are not using sybil yet. No, sorry, due to the above. Can you make pytest-mpi support both APIs? It's usually a simple try+except ImportError. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1001489: twodict: (autopkgtest) needs update for python3.10: 'collections' has no attribute 'KeysView'
I was looking at this bug report and while the patch is provided (and is trivial), the package had its only maintainer upload in 2018, the last upstream release was in 2016 (though one can say the software is perfect, as it's just 270 lines of code), and it has popcon 9. So maybe it's better to not spend effort on it. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1001371: pytest-twisted: (autopkgtest) needs update for python3.10: E {'warnings': 2} != {'warnings': 1}
The upstream report at https://github.com/pytest-dev/pytest-twisted/issues/146 was closed as the additional warning is produced by Twisted. The Twisted fix isn't merged yet. TBH as I don't need this package anymore (python3-scrapy doesn't use it anymore) I'm considering orphaning it. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1001009: Downloads external files on install
On Sun, Dec 05, 2021 at 09:56:02AM -0500, Tong Sun wrote: > Thanks Andrey, > > Two questions, > > By "moved to contrib", did you meant to change > > Section: net > > to > > Section: contrib > > in d/control? Please read https://www.debian.org/doc/debian-policy/ch-archive.html#archive-areas and https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections > Now, let's define what "package cannot function" actually means. If > functions normally without this or similar unpackaged file, but the > program is completely data driven, i.e., no ads sites from the list > are blocked unless the list is there. > > So, strictly speaking, the package indeed cannot function without this > or similar unpackaged file, right? And the solution is just above, > right? I don't know the current project consensus on this, if it exists. If the software can only work with certain non-free files it should go into contrib, if OTOH it can work with some user-provided files, or with free files if those exist, it can stay in main. But downloading external files in postinst is certainly not fit for main. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1001009: Downloads external files on install
Package: dbab Version: 1.3.2-1 Severity: serious The package runs `dbab-get-list` in postinst, which downloads http://pgl.yoyo.org/adservers/serverlist.php?hostformat=dnsmasq=0=plaintext If the package cannot function without this or similar unpackaged file, it should be moved to contrib. If it can, the downloading should be done by the user/administrator. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dbab depends on: ii bind9-dnsutils [dnsutils] 1:9.17.20-3 ii curl 7.79.1-2 pn dnsmasq ii perl 5.32.1-6 dbab recommends no packages. dbab suggests no packages.
Bug#1000824: The library package ships common files
Package: libxapp1 Version: 2.2.4-1 Severity: serious Policy 8.2 says "If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Otherwise, several versions of the shared library cannot be installed at the same time without filename clashes, making upgrades and transitions unnecessarily difficult." The package ships the following files that violate this: /etc/xdg/autostart/xapp-sn-watcher.desktop /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libxapp-gtk3-module.so /usr/lib/x86_64-linux-gnu/xapps/sn-watcher/xapp-sn-watcher -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libxapp1 depends on: ii libc62.32-4 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbusmenu-gtk3-4 18.10.20180917~bzr492+repack1-2+b1 ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 ii libglib2.0-0 2.70.1-1 pn libgnomekbd8 ii libgtk-3-0 3.24.30-3 ii libpango-1.0-0 1.48.10+ds1-1 ii libx11-6 2:1.7.2-2+b1 pn xapps-common libxapp1 recommends no packages. libxapp1 suggests no packages.
Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10
On Mon, Nov 29, 2021 at 05:58:47PM +0100, Andreas Tille wrote:
> ERROR: py310: could not install deps [django>=2.2.*, pytest, pytest-cov,
> pytest-django, pytest-xdist]; v =
> InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip install
> 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
> E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd
> /build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c
> /build/diskcache-5.2.1/tox.ini --sitepa
The actual error:
ERROR: Could not find a version that satisfies the requirement
typing-extensions>=3.6.4 (from importlib-metadata)
ERROR: No matching distribution found for typing-extensions>=3.6.4
--
WBR, wRAR
signature.asc
Description: PGP signature
Bug#999361: mypy ftbfs with python3.10 as supported (test failures)
On Wed, Nov 10, 2021 at 03:20:52PM +0100, Matthias Klose wrote: > mypy ftbfs with python3.10 as supported (test failures): > https://launchpadlibrarian.net/567976006/buildlog_ubuntu-jammy-amd64.mypy_0.910-3_BUILDING.txt.gz This just says "The typed_ast package is not installed." which sounds like it just wasn't rebuilt for 3.10 yet? 1.4.2-1 was used while only 1.4.3-1+b1 is rebuilt for 3.10. As far as I can see these problems don't happen anymore, though the package still FTBFS (see https://buildd.debian.org/status/package.php?p=mypy): FAILED mypy/test/testcmdline.py::PythonCmdlineSuite::testSrcPEP420Packages FAILED mypy/test/testsamples.py::SamplesSuite::test_stdlibsamples FAILED mypyc/test/test_commandline.py::TestCommandLine::testErrorOutput FAILED mypyc/test/test_run.py::TestRun::testAsync > python3-typed-ast is EOL according to upstream, so mypy needs to stop using > this. https://github.com/python/mypy/issues/10201 looks like mypy/typed_ast/3.10 problems are being properly tracked and fixed, also 1.5.0 was released on Nov 12; though this doesn't seem related to the current failures. -- WBR, wRAR signature.asc Description: PGP signature
Bug#989253: qbittorrent refuses to start after qt5 upgrade
Control: tags -1 moreinfo unreproducible I cannot reproduce this on a freshly installed package. -- WBR, wRAR signature.asc Description: PGP signature
Bug#986692: crash at startup
I can confirm this, and the backtrace looks similar: #0 0x00080005 in ?? () #1 0x77a1d879 in _Unwind_ForcedUnwind_Phase2 (exc=0x55614e90, context=0x7fffdd70, frames_p=0x7fffdc78) at ../../../src/libgcc/unwind.inc:170 #2 0x77a1e14d in _Unwind_Resume (exc=exc@entry=0x55614e90) at ../../../src/libgcc/unwind.inc:243 #3 0x55560c65 in __gnu_cxx::new_allocator::~new_allocator (this=, __in_chrg=) at /usr/include/c++/9/ext/new_allocator.h:89 #4 std::allocator::~allocator (this=0x7fffdeb0, __in_chrg=) at /usr/include/c++/9/bits/allocator.h:153 #5 std::__cxx11::basic_string, std::allocator >::_Alloc_hider::~_Alloc_hider (this=, __in_chrg=) at /usr/include/c++/9/bits/basic_string.h:150 #6 std::__cxx11::basic_string, std::allocator >::~basic_string (this=, __in_chrg=) at /usr/include/c++/9/bits/basic_string.h:658 #7 Levels::addLevel (this=, file="/usr/share/numptyphysics/L99_Gravity_Test.nph", rank=99, index=-1) at Levels.cpp:117 valgrind says: Invalid read of size 8 at 0x4DFA810: ??? (in /usr/lib/x86_64-linux-gnu/libgcc_s.so.1) by 0x4DFB14C: _Unwind_Resume (in /usr/lib/x86_64-linux-gnu/libgcc_s.so.1) by 0x114C64: ~new_allocator (new_allocator.h:89) by 0x114C64: ~allocator (allocator.h:153) by 0x114C64: ~_Alloc_hider (basic_string.h:150) by 0x114C64: ~basic_string (basic_string.h:658) by 0x114C64: Levels::addLevel(std::__cxx11::basic_string, std::allocator > const&, int, int) [clone .cold] (Levels.cpp:117) by 0x11C9B3: Levels::addPath(char const*) (Levels.cpp:93) by 0x11C8CD: Levels::addPath(char const*) (Levels.cpp:104) by 0x12C7FE: runGame (App.cpp:184) by 0x12C7FE: run (App.cpp:110) by 0x12C7FE: npmain(int, char**) (App.cpp:372) by 0x1174FA: main (OsFreeDesktop.cpp:133) Address 0x68ec6b8 is 0 bytes after a block of size 24 alloc'd at 0x4838DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x12BD89: runGame (App.cpp:173) by 0x12BD89: run (App.cpp:110) by 0x12BD89: npmain(int, char**) (App.cpp:372) by 0x1174FA: main (OsFreeDesktop.cpp:133) Some debugging suggests that the string being destroyed when it crashes is the "My Levels" std::string created from the static const char MISC_COLLECTION[] in Levels::addLevel() (no idea what is the problem with this code). -- WBR, wRAR signature.asc Description: PGP signature
Bug#985891: dicompyler doesn't start
Control: severity -1 grave On Thu, Mar 25, 2021 at 08:41:08PM +0100, Andreas Tille wrote: > > raise DistributionNotFound(req, requirers) > > pkg_resources.DistributionNotFound: The 'matplotlib<2.2,>=1.3.0' > > distribution > > was not found and is required by dicompyler > > This is a bit misleading error output. The problem is that the code > might work with some former matplotlib versions / Python3 versions but > it is using a private module of matplotlib[1] which is simply forbidden. (not really misleading, it says the installed matplotlib version is not suitable for it) > I have reported this issue upstream (see above). > > Since this makes dicompyler unusable I have bumped the bug severity to > serious ... which will possibly mean that dicompyler will not be > distributed with the next Debian release if upstream does not come > up with some solution in the next 2-3 weeks. See also https://github.com/bastula/dicompyler/issues/122 (it mentions using skimage.measure.find_contours instead but you'll probably need to write a patch yourself). -- WBR, wRAR signature.asc Description: PGP signature
Bug#985883: python3-pep8: Does not install /usr/bin/pep8
On Thu, Mar 25, 2021 at 07:30:14PM +1000, Russell Stuart wrote: > Justification: renders package unusable > python3-pep8 does not install the pep8 executable under /bin or > /usr/bin. There is no pep8 executable anymore, and the transitional package that shipped a symlink from it to pycodestyle was dropped in 1.7.1-9 in 2020. See https://pep8.readthedocs.io/ -- WBR, wRAR signature.asc Description: PGP signature
Bug#985705: courier-authlib: upgrades broken due the move of the tools
Control: tags -1 + moreinfo On Mon, Mar 22, 2021 at 09:10:29AM -0400, PICCORO McKAY Lenz wrote: > Package: courier-authlib > Version: 0.71.0-1 Why is this version set here? > i just try the upgrade case from stretch to lasted You can upgrade stretch only to buster. On the other hand, 0.71.0-1 is present only in old testing, not in any stable. > when i try to upgrade got this error: > > dpkg: error al procesar el archivo > /var/cache/apt/archives/courier-authdaemon_0.71.1-2_i386.deb > (--unpack): > intentando sobreescribir `/usr/sbin/authenumerate', que está también > en el paquete courier-authlib 0.71.0-1 > dpkg: considerando la desconfiguración de courier-authdaemon, ya que > lo rompería la instalación de `courier-base' ... I cannot reproduce this. You need to explain how to reproduce this. -- WBR, wRAR signature.asc Description: PGP signature
Bug#982381: AttributeError: lowlevel due to trio usage in s3ql/block_cache.py
On Thu, Feb 18, 2021 at 03:28:36PM +0100, Francesco P. Lovergine wrote: > I'm pretty sure this release should depend on >= 0.15, > even due to #981906. Unfortunately, it is not expressed in the package From setup.py: # Need trio.lowlevel 'trio >= 0.15', So it's expressed upstream but ignored in the Debian package, because dh_python3 ignores version reqs by default. -- WBR, wRAR signature.asc Description: PGP signature
Bug#983702: voltron: Update package with new upstream release
Control: retitle -1 Doesn't work with current werkzeug COntrol: tags -1 + upstream fixed-upstream patch On Sun, Feb 28, 2021 at 05:52:23PM +0100, Thomas Nyberg wrote: > The reason seems to be that the debian testing packaged version of werkzeug is > 1.0.1 while the packaged version of voltran does not support it. There is a > commit in the upstream repo that solves this problem: > > > https://github.com/snare/voltron/commit/ba413dcbc1914c511d03e1d95f3663a91daf349a > > Unfortunately that commit is not included in an official release. I'm unsure > if > that is required for it to be packaged with debian. Regardless, the older > version does not work as packaged (though the required changes are admittedly > quite minor). Assuming this patch fixes the problem, the correct way will be to apply it to the current version and upload it. -- WBR, wRAR signature.asc Description: PGP signature
Bug#982704: ofxstatement-plugins: FTBFS: TypeError: expected str, bytes or os.PathLike object, not NoneType
On Sat, Feb 13, 2021 at 06:06:54PM +0100, Lucas Nussbaum wrote: > > cd ofxstatement-be-argenta && python3 setup.py test > > running test > > [...] > > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line > > 1379, in __init__ > > self.module_path = os.path.dirname(getattr(module, '__file__', '')) > > File "/usr/lib/python3.9/posixpath.py", line 152, in dirname > > p = os.fspath(p) > > TypeError: expected str, bytes or os.PathLike object, not NoneType > > make[1]: *** [debian/rules:32: plugin_test_ofxstatement-be-argenta] Error 1 So Python tries to find tests here and fails. I tried to debug why it failes here but in ofxstatement-airbankcz and the difference seems to be caused by unittest.loader.TestLoader._find_test_path() finding ofxstatement/__init__.py here but not in ofxstatement-airbankcz. I'll leave this at this point to someone more familiar with test discovery, namespaces and packages. -- WBR, wRAR signature.asc Description: PGP signature
Bug#982712: tiledarray: FTBFS: gemm_helper.h:168:30: error: expected initializer before ‘const’
Control: -1 fixed-upstream Looks like this was caused by an update of libmadness-dev. Feel free to reassign this RC bug there, as it broke API compatibility when updated from 0.10.1~gite4aa500e-10.1 to 0.10.1+git20200818.eee5fd9f-1: now #defines "MADNESS_RESTRICT" instead of "restrict". This seems to be fixed upstream at https://github.com/ValeevGroup/tiledarray/commit/dbb665cb5e400aeebc39be12d015981078eff72b -- WBR, wRAR signature.asc Description: PGP signature
Bug#977308: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
On Fri, Dec 18, 2020 at 04:07:50PM +0100, Andreas Tille wrote: > On Fri, Dec 18, 2020 at 07:37:12PM +0500, Andrey Rahmatullin wrote: > > On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote: > > > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead > > > to: > > > > > > dpkg-shlibdeps: error: cannot find library > > > /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so > > > needed by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi: > > >'0201003e'; RPATH: '') > > Why are you linking an executable to a Python binary module? > > That's a good question. Its actually not me who did this. I think > that's done here: > >https://salsa.debian.org/med-team/shasta/-/blob/master/debian/rules#L27 Eww. But dynamicLibrary/README.md says: """ This directory builds the Shasta dynamic library `shasta.so`. This library is used in three ways: * It is linked in by the shasta dynamic executable `shastaDynamic`. * It can be imported by a python script via `import shasta` to provide Shasta Python bindings. * It can be statically linked in by other C++ code outside Shasta that uses Shasta as a library. """ So this sharing seems to be by design. That's unfortunate (can't say I'm surprised, though). > but I admit I have no idea why Shayan did so. Well, otherwise the binary wouldn't find the library. > I wonder what might be the proper way to do this to share the library > between Python modules and the executable. The proper way is to separate the common code from the Python bindings and link this correctly separated shared library into both the executable and the binary module libraries. -- WBR, wRAR signature.asc Description: PGP signature
Bug#977308: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote: > Hi, > > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead > to: > > dpkg-shlibdeps: error: cannot find library > /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed > by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi: > '0201003e'; RPATH: '') Why are you linking an executable to a Python binary module? -- WBR, wRAR signature.asc Description: PGP signature
Bug#959138: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')
On Tue, Dec 08, 2020 at 09:44:51PM +0100, Andreas Tille wrote: > > https://github.com/nipy/nipy/issues/461 > > As far as I can see that's included into 0.4.3~rc1. If by "it" you mean requiring sympy older than the Debian one then yes. But the package evidently doesn't enforce this requirement. -- WBR, wRAR signature.asc Description: PGP signature
Bug#959138: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')
On Tue, Dec 08, 2020 at 07:02:22PM +0100, Andreas Tille wrote: > TypeError: unsupported operand type(s) for *: 'GreaterThan' and 'Add' Consider starting to use Google to find at least some info related to questions you ask. https://github.com/nipy/nipy/issues/461 -- WBR, wRAR signature.asc Description: PGP signature
Bug#976779: Python3.9 issue: '"yield from" can't be applied to "Condition"' (Was: Bug#976779: mypy FTBFS with only python 3.9)
On Tue, Dec 08, 2020 at 01:27:57PM +0100, Andreas Tille wrote: > test-data/samples/crawl.py:750: error: "yield from" can't be applied to > "Condition" > test-data/samples/crawl.py:772: error: "yield from" can't be applied to > "Semaphore" > test-data/samples/crawl.py:778: error: "yield from" can't be applied to > "Condition" https://github.com/python/mypy/pull/9375 Also https://github.com/python/mypy/issues/9761 -- WBR, wRAR signature.asc Description: PGP signature
Bug#975953: libtorrent-rasterbar: diff for NMU version 1.2.9-0.2
Control: tags 975953 + patch Control: tags 975953 + pending Dear maintainer, I've prepared an NMU for libtorrent-rasterbar (versioned as 1.2.9-0.2) and uploaded it to DELAYED/0. Regards. -- WBR, wRAR diff -Nru libtorrent-rasterbar-1.2.9/debian/changelog libtorrent-rasterbar-1.2.9/debian/changelog --- libtorrent-rasterbar-1.2.9/debian/changelog 2020-11-25 13:34:56.0 +0500 +++ libtorrent-rasterbar-1.2.9/debian/changelog 2020-12-05 16:49:55.0 +0500 @@ -1,3 +1,11 @@ +libtorrent-rasterbar (1.2.9-0.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix building Python bindings with -std=c++14 (Closes: #975953), idea from +Holger Hoffstätte, https://bugs.gentoo.org/739654. + + -- Andrey Rahmatullin Sat, 05 Dec 2020 16:49:55 +0500 + libtorrent-rasterbar (1.2.9-0.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru libtorrent-rasterbar-1.2.9/debian/rules libtorrent-rasterbar-1.2.9/debian/rules --- libtorrent-rasterbar-1.2.9/debian/rules 2020-11-25 13:30:22.0 +0500 +++ libtorrent-rasterbar-1.2.9/debian/rules 2020-12-05 16:36:55.0 +0500 @@ -33,6 +33,8 @@ $(CONFIGURE_ARGS) mv build-py$*/bindings/python build/bindings/python$* cp -r bindings/python/* build/bindings/python$* + sed s/-std=c++11//g < build/bindings/python$*/compile_cmd > build/bindings/python$*/compile_cmd.new && \ + mv -f build/bindings/python$*/compile_cmd.new build/bindings/python$*/compile_cmd override_dh_auto_configure: override_dh_auto_configure-nopy $(ALLPY:%=override_dh_auto_configure-%) signature.asc Description: PGP signature
Bug#975953: Can't be imported, undefined symbol: _ZNK10libtorrent5entry4dictEv
On Sat, Nov 28, 2020 at 07:24:27PM +0500, Andrey Rahmatullin wrote: > * There is some magic parsing in bindings/python/setup.py related to extra > flags, with -std= being explicitly mentioned in a comment. This is indeed the cause. The "compile_cmd" file contains "g++ -std=c++11", which is the contents of the CXX autoconf variable. The setup.py code extracts the flags from this file and appends them to the extra_cmd var. That var is then put into the extra_compile_args var and so it gets appended to all compilation commands. This is of course wrong (in a normal CXX var substitution those flags would be at the beginning, not at the end), and nothing sane can be done about it. It also seems that I've repeated someone else's work: https://bugs.gentoo.org/739654 I will try a patch provided there. -- WBR, wRAR signature.asc Description: PGP signature
Bug#957206: dh_testroot: error: Package needs targeted root but builder has not provided a gain-root command via ${DEB_GAIN_ROOT_CMD}
On Tue, Dec 01, 2020 at 09:08:23PM +0100, Andreas Tille wrote: > Control: tags -1 pending > > Hi, > > upstream of fis-gtm package[1] confirmed that the build needs some root > permissions. Thus I've set > >Rules-Requires-Root: yes There is no "Rules-Requires-Root: yes", see the Policy. -- WBR, wRAR signature.asc Description: PGP signature
Bug#976135: Breaks tt-rss
Package: php-php-gettext
Version: 1.0.12-1
Severity: serious
Control: affects -1 tt-rss
After upgrading php-php-gettext from 1.0.12-0.1 to 1.0.12-1 my tt-rss
installation no longer works, showing some JS errors on load. Apache error.log
contains this traceback:
PHP Fatal error: Uncaught Error: Call to a member function evaluate() on null
in /usr/share/php/php-php-gettext/gettext.php:325
Stack trace:
#0 /usr/share/php/php-php-gettext/gettext.php(351):
gettext_reader->select_string()
#1 /usr/share/php/php-php-gettext/gettext.inc(293): gettext_reader->ngettext()
#2 /usr/share/tt-rss/www/include/functions.php(1725): _ngettext()
#3 /usr/share/tt-rss/www/index.php(114): init_js_translations()
#4 {main}
thrown in /usr/share/php/php-php-gettext/gettext.php on line 325, referer:
As far as I can see, gettext.php:325 was modified by
0002-Use-custom-parser-for-parsing-plural-expressions-ins.patch:
$plural = $plural_header->expression->evaluate($n);
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.5.0-1-amd64 (SMP w/1 CPU thread)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages php-php-gettext depends on:
ii php-mbstring2:7.4+76
ii php-pear1:1.10.9+submodules+notgz-1
ii php7.4-mbstring [php-mbstring] 7.4.11-1
php-php-gettext recommends no packages.
php-php-gettext suggests no packages.
-- no debconf information
Bug#976035: Doesn't work with Python 3.9
Package: mitmproxy
Version: 5.1.1-2
Severity: grave
Tags: upstream fixed-upstream
Control: forwarded -1 https://github.com/mitmproxy/mitmproxy/issues/4021
[...]
File "/usr/lib/python3/dist-packages/mitmproxy/utils/typecheck.py", line 73,
in check_option_type
elif not isinstance(value, typeinfo):
File "/usr/lib/python3.9/typing.py", line 697, in __instancecheck__
return self.__subclasscheck__(type(obj))
File "/usr/lib/python3.9/typing.py", line 700, in __subclasscheck__
raise TypeError("Subscripted generics cannot be used with"
TypeError: Subscripted generics cannot be used with class and instance checks
This is fixed at https://github.com/mitmproxy/mitmproxy/pull/4179 but there is
no release since it was merged.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mitmproxy depends on:
ii dpkg 1.20.5
ii fonts-font-awesome5.0.10+really4.7.0~dfsg-2
ii python3 3.9.0-3
ii python3-blinker 1.4+dfsg1-0.3
ii python3-brotli1.0.9-2+b1
ii python3-certifi 2020.6.20-1
ii python3-click 7.1.2-1
ii python3-cryptography 3.2.1-1
ii python3-flask 1.1.2-2
ii python3-h11 0.11.0-1
ii python3-h23.2.0-2
ii python3-hyperframe5.2.0-4
ii python3-kaitaistruct 0.8-3
ii python3-ldap3 2.7-2
ii python3-openssl 19.1.0-2
ii python3-passlib 1.7.2-2
ii python3-pkg-resources 50.3.0-1
ii python3-protobuf 3.12.3-2+b1
ii python3-publicsuffix2 2.20191221-2
ii python3-pyasn10.4.8-1
ii python3-pyparsing 2.4.7-1
ii python3-pyperclip 1.8.0-1
ii python3-ruamel.yaml 0.16.12-2
ii python3-sortedcontainers 2.1.0-2
ii python3-tornado 6.1.0-1
ii python3-urwid 2.1.1-1+b1
ii python3-wsproto 0.15.0-3
mitmproxy recommends no packages.
mitmproxy suggests no packages.
-- no debconf information
Bug#975953: Can't be imported, undefined symbol: _ZNK10libtorrent5entry4dictEv
On Fri, Nov 27, 2020 at 02:21:04PM +0500, Andrey Rahmatullin wrote: > >>> import libtorrent > Traceback (most recent call last): > File "", line 1, in > ImportError: > /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux- > gnu.so: undefined symbol: _ZNK10libtorrent5entry4dictEv > > $ ldd -r /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux- > gnu.so | fgrep undefined | fgrep -v Py > undefined symbol: _ZNK10libtorrent5entry4dictEv (/usr/lib/python3/dist- > packages/libtorrent.cpython-39-x86_64-linux-gnu.so) > undefined symbol: _ZN10libtorrent5entry4dictEv (/usr/lib/python3/dist- > packages/libtorrent.cpython-39-x86_64-linux-gnu.so) So far I see these interesting things: * These symbols are libtorrent::entry::dict() and the const version of it. * libtorrent-rasterbar.so.10 instead exports libtorrent::entry::dict[abi:cxx11](). * The most recent upload has "debian/rules: Pass --std=c++14" without any explanation (made with "export DEB_CXXFLAGS_MAINT_APPEND = -std=c++14"). * The build log shows that most compilation commands have both --std=c++11 and -std=c++14, 463 of them having -std=c++14 later and 80 having --std=c++11 later. All of the latter commands seem to be for Python bindings. * There is some magic parsing in bindings/python/setup.py related to extra flags, with -std= being explicitly mentioned in a comment. * There seem to be some ABI compatiblity hacks in the code itself, see TORRENT_CXX11_ABI (though it looks like it's only in CMakeLists.txt while the package uses autotools.), it's also says it's about "clients building with C++14 against libtorrent build with C++11" not vice versa. So it looks like the Python bindings are compiled incorrectly, but I don't see an obvious way to fix that, probably the setup.py magic needs fixing. -- WBR, wRAR signature.asc Description: PGP signature
Bug#975953: Can't be imported, undefined symbol: _ZNK10libtorrent5entry4dictEv
Package: python3-libtorrent Version: 1.2.9-0.1 Severity: grave Control: affects -1 + deluge deluged >>> import libtorrent Traceback (most recent call last): File "", line 1, in ImportError: /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux- gnu.so: undefined symbol: _ZNK10libtorrent5entry4dictEv $ ldd -r /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux- gnu.so | fgrep undefined | fgrep -v Py undefined symbol: _ZNK10libtorrent5entry4dictEv (/usr/lib/python3/dist- packages/libtorrent.cpython-39-x86_64-linux-gnu.so) undefined symbol: _ZN10libtorrent5entry4dictEv (/usr/lib/python3/dist- packages/libtorrent.cpython-39-x86_64-linux-gnu.so) -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-libtorrent depends on: ii libboost-python1.71.0 [libboost-python1.71.0-py39] 1.71.0-7+b1 pn libboost-python1.71.0-py38 ii libc6 2.31-4 ii libgcc-s1 10.2.0-19 ii libssl1.1 1.1.1h-1 ii libstdc++6 10.2.0-19 ii libtorrent-rasterbar10 1.2.9-0.1 ii python3 3.9.0-3 python3-libtorrent recommends no packages. python3-libtorrent suggests no packages. -- debconf-show failed
Bug#973526: FTBFS due to SIGABRT while running HTTP server tests, bug #973526
On Tue, Nov 10, 2020 at 05:17:26PM +0200, Juhani Numminen wrote: > Hi, > > Maarten L. Hekkelman as the package maintainer asked for my help with bug > #973526 > but I have to forward his request to debian-mentors. > > The package libzeep failed to build on amd64, apparently because of a SIGABRT > during > its HTTP server test. > https://buildd.debian.org/status/fetch.php?pkg=libzeep=amd64=5.0.0-3=1604607341=0 > > >> [0;39;49m>> test/http-test.cpp > >> test/http-test.cpp: In member function ‘void > >> connection_read::test_method()’: > >> test/http-test.cpp:74:17: note: ‘#pragma message: write test for > >> avail/used’ > >>74 | #pragma message "write test for avail/used" > >> | ^~~ > > building http-test > >> cd test; ./http-test > >> Running 7 test cases... > >> started daemon at port 5923 > >> terminate called after throwing an instance of > >> 'boost::wrapexcept' > >> what(): resolve: Host not found (authoritative) Looks like it tries to resolve something, and that usually implies Internet access, as otherwise you could just connect to localhost? Accessing the Internet is forbidden during building. -- WBR, wRAR signature.asc Description: PGP signature
Bug#971111: gubbins: FTBFS: pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse error at "'/build/g'": Expected W:(abcd...)
python/gubbins/common.py::parse_and_run() constructs an absolute path for the executable and then passes it to pkg_resources.get_distribution(). I have no idea what does this code want to achieve, as get_distribution() takes requirement specifications, not file paths. -- WBR, wRAR signature.asc Description: PGP signature
Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
On Mon, Oct 12, 2020 at 11:36:36AM +0200, Andreas Tille wrote: > Control: tags -1 help > > Hi, > > while I've fixed the issue for arm64 the new version of bowtie seems to > have some new assembly code where mips64el, ppc64el and others are > stumbling upon [1]: The reason it works on arm64 is ifeq (aarch64,$(shell uname -m)) POPCNT_CAPABILITY=0 endif in Makefile. It's clearly not supposed to run on anything else non-Intel but you can try patching this to also disable popcnt on other non-Intel. -- WBR, wRAR signature.asc Description: PGP signature
Bug#956700: kvirc: diff for NMU version 4:5.0.0+dfsg-2.1
On Fri, Jun 19, 2020 at 11:33:41AM +0300, Adrian Bunk wrote: > Control: tags 956700 + patch > Control: tags 956700 + pending > > Dear maintainer, > > I've prepared an NMU for kvirc (versioned as 4:5.0.0+dfsg-2.1) and > uploaded it to DELAYED/14. Please feel free to tell me if I should > cancel it. Thank you Adrian, I've just uploaded a -3 which includes a fix for this bug so you can cancel the NMU (if it won't be cancelled automatically). -- WBR, wRAR signature.asc Description: PGP signature
Bug#948926: Help for linking library needed (Was: Bug#948926: blasr ftbfs with libpbbam1.0.6)
On Wed, Jan 15, 2020 at 05:50:03PM +0100, Andreas Tille wrote: > Control: tags -1 help > > On Tue, Jan 14, 2020 at 09:48:10PM +0100, Paul Gevers wrote: > > Did not find CMake 'cmake' > > Found CMake: NO > > Run-time dependency pbbam found: NO > > > > meson.build:54:0: ERROR: Could not generate cargs for pbbam: > > Package pbcopper was not found in the pkg-config search path. > > Perhaps you should add the directory containing `pbcopper.pc' > > to the PKG_CONFIG_PATH environment variable > > Package 'pbcopper', required by 'pbbam', not found > > I've fixed this specific issue (and others) in Git[1] but I'm running > into trouble I have no idea to fix. > > > ... > [22/25] c++ -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq > -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial > -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time - > D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. > -fstack-protector-strong -Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 > -std=c++14 -Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl. a -pthread > -lblasr /usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata > -lpbihdf -Wl,--end-group '-Wl,-rpath,$ORIGIN/' > -Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/ > FAILED: toAfg > c++ -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq > -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial > -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time -D_FORTIFY_SOURCE=2 - > g -O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. -fstack-protector-strong > -Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 -std=c++14 > -Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl.a -pthread -lblasr / > usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata -lpbihdf > -Wl,--end-group '-Wl,-rpath,$ORIGIN/' > -Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/ > /usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol > '_ZN6PacBio3BAM9BamRecordD1Ev' > /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libpbbam.so.0.23.0: error adding > symbols: DSO missing from command line > collect2: error: ld returned 1 exit status It tells you to add libpbbam to the link command. > In the pbuilder chroot I tried to simplify the linker call and > reduced it to > > root@sputnik:/build/blasr-5.3.3+dfsg/build# c++ -o toAfg > 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq > -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -DHAVE_HDF5_1_10_1 -std=c++14 > -lhdf5_cpp -lhdf5 ./libblasr_impl.a -pthread -lz -lpbdata -lpbihdf -lpbihdf > -lblasr > /usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol > '_ZN6PacBio3BAM9BamRecordD1Ev' > /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libpbbam.so.0.23.0: error adding > symbols: DSO missing from command line > collect2: error: ld returned 1 exit status Indeed libpbbam is still missing here. > I've checked that the symbol which is not found exists in the linked > libraries: It's not linked. Also, using grep for this is very wrong, you need to use nm -D and check it's defined there (it is though). -- WBR, wRAR signature.asc Description: PGP signature
Bug#937262: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye)
On Fri, Dec 13, 2019 at 10:10:03PM +0100, Andreas Tille wrote:
> i$ pdb2pqr
> Traceback (most recent call last):
> File "/usr/bin/pdb2pqr", line 52, in
> from main import mainCommand
> File "/usr/share/pdb2pqr/main.py", line 77, in
> import extensions
> File "/usr/share/pdb2pqr/extensions/__init__.py", line 56, in
> extDict[extName] = __import__(extName,globals(),locals(),[], -1)
> ValueError: level must be >= 0
"""
level specifies whether to use absolute or relative imports. The default
is -1 which indicates both absolute and relative imports will be
attempted. 0 means only perform absolute imports. Positive values for
level indicate the number of parent directories to search relative to the
directory of the module calling __import__().
"""
https://docs.python.org/2.7/library/functions.html#__import__
-1 was removed in 3.3 as implicit relative import are not supported in
3.x. As this code seems to use relative imports you need to change -1 to
1.
> So I tried:
>
> --- a/extensions/__init__.py
> +++ b/extensions/__init__.py
> @@ -53,7 +53,7 @@ _extList = [name for _, name, _ in
> pkgutil.iter_modules(__path__)]
> extDict = {}
>
> for extName in _extList:
> -extDict[extName] = __import__(extName,globals(),locals(),[], -1)
> +extDict[extName] = __import__(extName,globals(),locals(),[], 0)^M
Mindlessly changing the code is almost always a bad idea...
> File "/usr/share/pdb2pqr/extensions/__init__.py", line 57, in
> extDict[extName] = __import__(extName,globals(),locals(),[], 0)
> ModuleNotFoundError: No module named 'chi'
This is expected as it now tries to do "import chi". With 1 it should try
"from . import chi". This fails later, as the source also has implicit
relative imports that needs to be fixed, for example "from aconf import"
in src/utilities.py.
--
WBR, wRAR
signature.asc
Description: PGP signature
Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))
On Fri, Dec 13, 2019 at 01:40:34PM +0100, Andreas Tille wrote: > > > g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so > > > -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os > > > -L/usr/lib -lpython3.7 > > > /usr/bin/ld: cannot find -lpython3.7 > > Actually, it's a different problem, sorry. > > There is no -lpython3.7, only -lpython3.7m. If the build system used > > pkgconfig it would know that. I guess the library name is hardcoded > > instead? I see that it got -I/usr/include/python3.7m from somewhere, so > > it's not completely broken. > > Thanks for that additional hint. I can confirm that I checked whether > pkgconfig can be used before I was asking here. But we seem to agree > that this is not the case. I admit I have no real clue how to convince > scons to link to the correct library name. :-( I have no idea either. It seems that it just uses the scons compilation code by creating an env.LoadableModule. -- WBR, wRAR signature.asc Description: PGP signature
Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))
On Fri, Dec 13, 2019 at 09:49:47AM +0100, Andreas Tille wrote: > g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so > -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib > -lpython3.7 > /usr/bin/ld: cannot find -lpython3.7 Actually, it's a different problem, sorry. There is no -lpython3.7, only -lpython3.7m. If the build system used pkgconfig it would know that. I guess the library name is hardcoded instead? I see that it got -I/usr/include/python3.7m from somewhere, so it's not completely broken. -- WBR, wRAR signature.asc Description: PGP signature
Bug#937330: Help with upgrading psychopy needed (Was: Python2 removal in sid/bullseye)
On Wed, Nov 20, 2019 at 10:11:03PM +0100, Andreas Tille wrote: > INTERNALERROR> pluggy.manager.PluginValidationError: unknown hook > 'pytest_namespace' in plugin '/build/psychopy-3.2.4+dfsg/.pybuild/cpython3_3.7/build/psychopy/tests/conftest.py'> > File > "/build/psychopy-3.2.4+dfsg/.pybuild/cpython3_3.7/build/psychopy/tests/conftest.py", > line 14, in pytest_sessionfinish > pytest.app.quit() > AttributeError: module 'pytest' has no attribute 'app' https://discourse.psychopy.org/t/how-to-run-unit-tests/7315/7 suggests they don't support recent pytest, which is also recorded in https://github.com/psychopy/psychopy/blob/master/requirements_dev.txt -- WBR, wRAR signature.asc Description: PGP signature
Bug#937244: [Python-modules-team] Bug#937244: paste: Python2 removal in sid/bullseye
On Thu, Sep 26, 2019 at 02:09:16PM -0400, Sandro Tosi wrote: > On Thu, Sep 26, 2019 at 1:45 PM peter green wrote: > > paste depends on the python-tempita binary package, which has already been > > dropped by the python-tempita source package. > > sigh, python-paste has 11 reverse deps that'd be broken if we remove > that binary package. CCing wrar who uploaded python-tempita recently Sorry, I was too eager to drop pylons deps that I did that in a wrong way and missed this dep. I'm going to reupload py2 tempita. -- WBR, wRAR signature.asc Description: PGP signature
Bug#941226: python-pyramid-zcml: diff for NMU version 1.0.0-1.2
Control: tags 941226 + patch Control: tags 941226 + pending Dear maintainer, I've prepared an NMU for python-pyramid-zcml (versioned as 1.0.0-1.2) and uploaded it. Regards. -- WBR, wRAR diff -Nru python-pyramid-zcml-1.0.0/debian/changelog python-pyramid-zcml-1.0.0/debian/changelog --- python-pyramid-zcml-1.0.0/debian/changelog 2019-09-17 22:37:08.0 +0500 +++ python-pyramid-zcml-1.0.0/debian/changelog 2019-09-26 23:17:51.0 +0500 @@ -1,3 +1,10 @@ +python-pyramid-zcml (1.0.0-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Upload without binaries (Closes: #941226). + + -- Andrey Rahmatullin Thu, 26 Sep 2019 23:17:51 +0500 + python-pyramid-zcml (1.0.0-1.1) unstable; urgency=medium * Non-maintainer upload. signature.asc Description: PGP signature
Bug#941225: python-pyramid-tm: diff for NMU version 0.5-1.2
Control: tags 941225 + patch Control: tags 941225 + pending Dear maintainer, I've prepared an NMU for python-pyramid-tm (versioned as 0.5-1.2) and uploaded it. Regards. -- WBR, wRAR diff -Nru python-pyramid-tm-0.5/debian/changelog python-pyramid-tm-0.5/debian/changelog --- python-pyramid-tm-0.5/debian/changelog 2019-09-17 21:22:59.0 +0500 +++ python-pyramid-tm-0.5/debian/changelog 2019-09-26 23:02:07.0 +0500 @@ -1,3 +1,10 @@ +python-pyramid-tm (0.5-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Upload without binaries (Closes: #941225). + + -- Andrey Rahmatullin Thu, 26 Sep 2019 23:02:07 +0500 + python-pyramid-tm (0.5-1.1) unstable; urgency=medium * Non-maintainer upload. signature.asc Description: PGP signature
Bug#935381: python-pyramid-multiauth: diff for NMU version 0.8.0-1.1
Control: tags 935381 + patch
Control: tags 935381 + pending
Dear maintainer,
I've prepared an NMU for python-pyramid-multiauth (versioned as 0.8.0-1.1) and
uploaded it.
Regards.
--
WBR, wRAR
diff -Nru python-pyramid-multiauth-0.8.0/debian/changelog python-pyramid-multiauth-0.8.0/debian/changelog
--- python-pyramid-multiauth-0.8.0/debian/changelog 2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/changelog 2019-09-23 20:34:29.0 +0500
@@ -1,3 +1,11 @@
+python-pyramid-multiauth (0.8.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop Python 2 support (Closes: #935381).
+ * Update the priority from extra to optional.
+
+ -- Andrey Rahmatullin Mon, 23 Sep 2019 20:34:29 +0500
+
python-pyramid-multiauth (0.8.0-1) unstable; urgency=medium
[ Denis Laxalde ]
diff -Nru python-pyramid-multiauth-0.8.0/debian/control python-pyramid-multiauth-0.8.0/debian/control
--- python-pyramid-multiauth-0.8.0/debian/control 2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/control 2019-09-23 20:32:43.0 +0500
@@ -1,13 +1,10 @@
Source: python-pyramid-multiauth
Section: python
-Priority: extra
+Priority: optional
Maintainer: David Douard
Build-Depends:
debhelper (>= 9),
dh-python,
- python-all,
- python-setuptools,
- python-pyramid,
python3-all,
python3-setuptools,
python3-pyramid,
@@ -16,16 +13,6 @@
Vcs-Browser: https://github.com/douardda/pyramid_multiauth
Vcs-Git: https://github.com/douardda/pyramid_multiauth.git
-Package: python-pyramid-multiauth
-Architecture: all
-Depends:
- ${python:Depends},
- ${misc:Depends}
-Description: authentication policy for the Pyramid web framework
- The pyramid_multiauth package provides MultiAuthenticationPolicy: a Pyramid
- authentication policy that proxies to a stack of other IAuthenticationPolicy
- objects, to provide a combined auth solution from individual pieces.
-
Package: python3-pyramid-multiauth
Architecture: all
Depends:
diff -Nru python-pyramid-multiauth-0.8.0/debian/python3-pyramid-multiauth.install python-pyramid-multiauth-0.8.0/debian/python3-pyramid-multiauth.install
--- python-pyramid-multiauth-0.8.0/debian/python3-pyramid-multiauth.install 2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/python3-pyramid-multiauth.install 1970-01-01 05:00:00.0 +0500
@@ -1 +0,0 @@
-usr/lib/python3*
diff -Nru python-pyramid-multiauth-0.8.0/debian/python-pyramid-multiauth.install python-pyramid-multiauth-0.8.0/debian/python-pyramid-multiauth.install
--- python-pyramid-multiauth-0.8.0/debian/python-pyramid-multiauth.install 2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/python-pyramid-multiauth.install 1970-01-01 05:00:00.0 +0500
@@ -1 +0,0 @@
-usr/lib/python2*
diff -Nru python-pyramid-multiauth-0.8.0/debian/rules python-pyramid-multiauth-0.8.0/debian/rules
--- python-pyramid-multiauth-0.8.0/debian/rules 2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/rules 2019-09-23 20:32:48.0 +0500
@@ -1,4 +1,4 @@
#!/usr/bin/make -f
%:
- dh $@ --with python2,python3 --buildsystem=pybuild
+ dh $@ --with python3 --buildsystem=pybuild
signature.asc
Description: PGP signature
Bug#915895: python-limits FTBFS: ERROR: Failure: ImportError (cannot import name b)
On Thu, Aug 15, 2019 at 11:10:37PM +0500, Andrey Rahmatullin wrote: > Control: reassign -1 src:redis-py-cluster/1.3.3-1 > Control: severity -1 grave > Control: forwarded -1 https://github.com/Grokzen/redis-py-cluster/issues/295 > Control: affects -1 src:python-limits > > On Sat, Feb 09, 2019 at 06:57:54PM +0100, Slavko wrote: > > while this of course affects the python-limits build, it is not its > > bug. As one can see, it is caused in test by importing rediscluster: > Exactly. Fixing the bug metadata accordingly. > Work in progress is at > https://github.com/Grokzen/redis-py-cluster/pull/296 and looks promising. This is fixed in the 2.0 release. -- WBR, wRAR signature.asc Description: PGP signature
Bug#782952: python-pyramid-zcml: diff for NMU version 1.0.0-1.1
Control: tags 782952 + patch
Control: tags 782952 + pending
Dear maintainer,
I've prepared an NMU for python-pyramid-zcml (versioned as 1.0.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
--
WBR, wRAR
diff -Nru python-pyramid-zcml-1.0.0/debian/changelog python-pyramid-zcml-1.0.0/debian/changelog
--- python-pyramid-zcml-1.0.0/debian/changelog 2013-06-06 15:06:42.0 +0600
+++ python-pyramid-zcml-1.0.0/debian/changelog 2019-09-17 22:37:08.0 +0500
@@ -1,3 +1,14 @@
+python-pyramid-zcml (1.0.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Switch from Python 2 to Python 3 (Closes: #782952).
+ * Add support for Python 3.7.
+ * Add support for Pyramid 1.8 and other modern libs.
+ * Disable tests using mako as pyramid_mako is not packaged.
+ * Update the priority from extra to optional.
+
+ -- Andrey Rahmatullin Tue, 17 Sep 2019 22:37:08 +0500
+
python-pyramid-zcml (1.0.0-1) unstable; urgency=low
* New upstream release
diff -Nru python-pyramid-zcml-1.0.0/debian/control python-pyramid-zcml-1.0.0/debian/control
--- python-pyramid-zcml-1.0.0/debian/control 2012-05-03 19:35:31.0 +0600
+++ python-pyramid-zcml-1.0.0/debian/control 2019-09-17 22:36:13.0 +0500
@@ -1,14 +1,18 @@
Source: python-pyramid-zcml
Section: python
-Priority: extra
+Priority: optional
Maintainer: Free Ekanayaka
-Build-Depends: debhelper (>= 7.0.50~), python-setuptools, python-all (>= 2.6.6-3)
+Build-Depends: debhelper (>= 7.0.50~), dh-python, python3-all,
+ python3-setuptools,
+ python3-pyramid,
+ python3-webtest,
+ python3-zope.configuration,
Standards-Version: 3.9.3
Homepage: http://pypi.python.org/pypi/pyramid_zcml
-Package: python-pyramid-zcml
+Package: python3-pyramid-zcml
Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
+Depends: ${python3:Depends}, ${misc:Depends}
Description: Declarative configuration for the Pyramid web framework
The pyramid_zcml package provides ZCML (Zope Configuration Markup Language)
directives for all "configurator" methods available in the Pyramid web
diff -Nru python-pyramid-zcml-1.0.0/debian/patches/fix-authkit.patch python-pyramid-zcml-1.0.0/debian/patches/fix-authkit.patch
--- python-pyramid-zcml-1.0.0/debian/patches/fix-authkit.patch 1970-01-01 05:00:00.0 +0500
+++ python-pyramid-zcml-1.0.0/debian/patches/fix-authkit.patch 2019-09-17 22:01:00.0 +0500
@@ -0,0 +1,24 @@
+From d041694f77215dcb692b65d33ab0ad64b07135f0 Mon Sep 17 00:00:00 2001
+From: Tres Seaver
+Date: Wed, 4 Feb 2015 12:25:02 -0500
+Subject: [PATCH] Accomodate updated AuthTkt.
+
+---
+ pyramid_zcml/tests/test_units.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/pyramid_zcml/tests/test_units.py b/pyramid_zcml/tests/test_units.py
+index a53d398..24b8941 100644
+--- a/pyramid_zcml/tests/test_units.py
b/pyramid_zcml/tests/test_units.py
+@@ -372,8 +372,8 @@ def callback(identity, request):
+ reg.registerUtility(object(), IAuthorizationPolicy)
+ _execute_actions(actions)
+ policy = reg.getUtility(IAuthenticationPolicy)
+-self.assertEqual(policy.cookie.path, '/sub/')
+-self.assertEqual(policy.cookie.http_only, True)
++self.assertEqual(policy.cookie.cookie_profile.path, '/sub/')
++self.assertEqual(policy.cookie.cookie_profile.httponly, True)
+ self.assertEqual(policy.cookie.secret, 'sosecret')
+ self.assertEqual(policy.callback, callback)
+
diff -Nru python-pyramid-zcml-1.0.0/debian/patches/fix-path.patch python-pyramid-zcml-1.0.0/debian/patches/fix-path.patch
--- python-pyramid-zcml-1.0.0/debian/patches/fix-path.patch 1970-01-01 05:00:00.0 +0500
+++ python-pyramid-zcml-1.0.0/debian/patches/fix-path.patch 2019-09-17 22:35:35.0 +0500
@@ -0,0 +1,23 @@
+From c32e7ee71c631a68206989055d027cee91a5021f Mon Sep 17 00:00:00 2001
+From: Tres Seaver
+Date: Tue, 8 Jan 2019 14:14:08 -0500
+Subject: [PATCH] Module's '__path__' is supposed to be a list ot strings, or
+ None.
+
+---
+ pyramid_zcml/tests/test_units.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pyramid_zcml/tests/test_units.py b/pyramid_zcml/tests/test_units.py
+index 2048aa1..7f1e438 100644
+--- a/pyramid_zcml/tests/test_units.py
b/pyramid_zcml/tests/test_units.py
+@@ -1227,7 +1227,7 @@ def __call__(self):
+ """ """
+
+ class DummyModule:
+-__path__ = "foo"
++__path__ = ["foo"]
+ __name__ = "dummy"
+ __file__ = ''
+ scanned = False
diff -Nru python-pyramid-zcml-1.0.0/debian/patches/fix-pyramid-1.8-2.patch python-pyramid-zcml-1.0.0/debian/patches/fix-pyramid-1.8-2.patch
--- python-pyramid-zcml-1.0.0/debian/patches/fix-pyramid-1.8-2.patch 1970-01-01 05:00:00.0 +0500
+++ python-pyramid-zcml-1.0.0/debian/patches/fix-pyramid-1.8-2.patch 2019-09-17 22:05:24.0 +
Bug#782951: python-pyramid-tm: diff for NMU version 0.5-1.1
Control: tags 782951 + patch
Control: tags 782951 + pending
Dear maintainer,
I've prepared an NMU for python-pyramid-tm (versioned as 0.5-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
--
WBR, wRAR
diff -Nru python-pyramid-tm-0.5/debian/changelog python-pyramid-tm-0.5/debian/changelog
--- python-pyramid-tm-0.5/debian/changelog 2012-09-03 01:50:39.0 +0600
+++ python-pyramid-tm-0.5/debian/changelog 2019-09-17 21:22:59.0 +0500
@@ -1,3 +1,11 @@
+python-pyramid-tm (0.5-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Switch from Python 2 to Python 3 (Closes: #782951).
+ * Update the priority from extra to optional.
+
+ -- Andrey Rahmatullin Tue, 17 Sep 2019 21:22:59 +0500
+
python-pyramid-tm (0.5-1) unstable; urgency=low
* New upstream release
diff -Nru python-pyramid-tm-0.5/debian/control python-pyramid-tm-0.5/debian/control
--- python-pyramid-tm-0.5/debian/control 2012-05-20 13:37:22.0 +0600
+++ python-pyramid-tm-0.5/debian/control 2019-09-17 21:12:12.0 +0500
@@ -1,14 +1,17 @@
Source: python-pyramid-tm
Section: python
-Priority: extra
+Priority: optional
Maintainer: Free Ekanayaka
-Build-Depends: debhelper (>= 7.0.50~), python-setuptools, python-all (>= 2.6.6-3)
+Build-Depends: debhelper (>= 7.0.50~), dh-python, python3-all,
+ python3-setuptools,
+ python3-pyramid,
+ python3-transaction,
Standards-Version: 3.9.3
Homepage: http://pypi.python.org/pypi/pyramid_tm
-Package: python-pyramid-tm
+Package: python3-pyramid-tm
Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
+Depends: ${python3:Depends}, ${misc:Depends}
Description: Transaction management for the Pyramid web framework
The pyramid_tm package allows Pyramid requests to join the active
transaction as provided by the transaction package.
diff -Nru python-pyramid-tm-0.5/debian/rules python-pyramid-tm-0.5/debian/rules
--- python-pyramid-tm-0.5/debian/rules 2012-04-12 18:16:52.0 +0600
+++ python-pyramid-tm-0.5/debian/rules 2019-09-17 21:08:37.0 +0500
@@ -1,4 +1,4 @@
#!/usr/bin/make -f
%:
- dh $@ --with python2
+ dh $@ --with python3 --buildsystem=pybuild
signature.asc
Description: PGP signature
Bug#938494: skimage (build-)depends on python-cloudpickle which has already been dropped
On Fri, Sep 13, 2019 at 05:16:30PM +0800, Drew Parsons wrote: > Python maintainers, remember, check your reverse dependencies before > dropping your python2 packages. > Check each of > > build-rdeps python-yourmodule > apt-rdepends -r python-yourmodule > > and confirm the package has rdeps=0 on Sandro's list at > http://sandrotosi.me/debian/py2removal/index.html And grep-dctrl -FTestsuite-triggers $pkg -sPackage /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources -- WBR, wRAR signature.asc Description: PGP signature
Bug#939511: /usr/bin/tifffile doesn't work
Package: tifffile Version: 20181128-1+b1 Severity: grave $ tifffile Traceback (most recent call last): File "/usr/bin/tifffile", line 4, in import tifffile ImportError: No module named tifffile The package ships a Python 3 module with a Python 2 wrapper script. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tifffile depends on: ii python 2.7.16-1 ii python3 3.7.3-1 ii python3-numpy [python3-numpy-abi9] 1:1.16.2-1+b1 Versions of packages tifffile recommends: pn python3-matplotlib tifffile suggests no packages. -- no debconf information
Bug#935812: FTBFS: FAIL: test_can_get_304_with_last_modified (tests.handlers.test_base_handler.ImageOperationsWithLastModifiedTestCase)
Package: src:thumbor Version: 6.7.0-1 Severity: serious I tried to rebuild the package without the python-celery B-D and got one test failure: FAIL: test_can_get_304_with_last_modified (tests.handlers.test_base_handler.ImageOperationsWithLastModifiedTestCase) -- Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/tornado/testing.py", line 125, in __call__ result = self.orig_method(*args, **kwargs) File "/<>/.pybuild/cpython2_2.7_thumbor/build/tests/handlers/test_base_handler.py", line 764, in test_can_get_304_with_last_modified expect(response.code).to_equal(304) File "/usr/lib/python2.7/dist-packages/preggy/core.py", line 285, in _assert_topic return _registered_assertions[method_name](self.topic, *args, **kw) File "/usr/lib/python2.7/dist-packages/preggy/core.py", line 58, in wrapper func(*args, **kw) File "/usr/lib/python2.7/dist-packages/preggy/core.py", line 126, in test_assertion raise AssertionError(err_msg) AssertionError: Expected topic(200) to equal 304 >> begin captured logging << thumbor: DEBUG: METRICS: inc: response.count:1 thumbor: DEBUG: [RESULT_STORAGE] getting from /tmp/tmpclUxcu/default/1e/b9/ead4e07ef924574371b97c573958beb3ad71 thumbor: DEBUG: METRICS: timing: result_storage.incoming_time:0 thumbor: DEBUG: METRICS: inc: result_storage.hit:1 thumbor: DEBUG: METRICS: inc: result_storage.bytes_read:5319 thumbor: DEBUG: [RESULT_STORAGE] IMAGE FOUND: /_wIUeSaeHw8dricKG2MGhqu5thk=/smart/image.jpg thumbor: DEBUG: Content Type of image/jpeg detected. tornado.access: INFO: 200 GET /_wIUeSaeHw8dricKG2MGhqu5thk=/smart/image.jpg (127.0.0.1) 2.15ms thumbor: DEBUG: METRICS: timing: response.time:1 thumbor: DEBUG: METRICS: timing: response.time.200:1 thumbor: DEBUG: METRICS: inc: response.status.200:1 thumbor: DEBUG: METRICS: inc: response.format.jpg:1 thumbor: DEBUG: METRICS: timing: response.time.jpg:1 thumbor: DEBUG: METRICS: inc: response.bytes.jpg:5319 preggy.utils: DEBUG: fetching assertion: 'to_equal' - >> end captured logging << - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#935449: Build-Depends on removed python-celery
Package: src:thumbor Version: 6.7.0-1 Severity: serious python-celery was recently removed and so this package cannot be built anymore. I don't see why that B-D is needed though. -- WBR, wRAR signature.asc Description: PGP signature
Bug#935447: Please drop the Python 2 subpackage
Package: src:python-raven Version: 6.3.0-2 Severity: serious User: debian-pyt...@lists.debian.org Usertag: py2removal py2leaf py3available python-celery was recently removed so python-raven can't be installed and the package can't be built. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#935438: Please update to Python 3 or remove
Package: src:chaussette Version: 1.3.0-1 Severity: serious User: debian-pyt...@lists.debian.org Usertag: py2removal py2leaf py2rm According to #855671 this package doesn't seem to be working for the last 2.5 years, has popcon of 3, doesn't have Python 3 support and depends on a lot of Python 2 module packages, so it will most likely be removed from Debian in some not very distant future unless it's fixed and switched to Python 3.
Bug#935335: Depends on removed python-zbar
Package: src:monkeysign Version: 2.2.4 Severity: serious As Python 2 versions of zbar and zbarpygtk were removed, this package should be updated to use Python 3 or removed. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#915895: python-limits FTBFS: ERROR: Failure: ImportError (cannot import name b)
Control: reassign -1 src:redis-py-cluster/1.3.3-1 Control: severity -1 grave Control: forwarded -1 https://github.com/Grokzen/redis-py-cluster/issues/295 Control: affects -1 src:python-limits On Sat, Feb 09, 2019 at 06:57:54PM +0100, Slavko wrote: > while this of course affects the python-limits build, it is not its > bug. As one can see, it is caused in test by importing rediscluster: Exactly. Fixing the bug metadata accordingly. Work in progress is at https://github.com/Grokzen/redis-py-cluster/pull/296 and looks promising. -- WBR, wRAR signature.asc Description: PGP signature
Bug#776246: MD4 collision/preimage attacks (CVE-2014-8242)
On Wed, Jul 10, 2019 at 11:45:53AM +0200, Laurent Bigonville wrote: > Now that buster has been released, do you think we could move forward with > uploading the last version of librsync in unstable? Yes, I plan to proceed with this soon. > I tried to rebuild duplicity and it's building fine. I tried rebuilding all revdeps some time ago, only rdiff-backup failed. -- WBR, wRAR signature.asc Description: PGP signature
Bug#924848: telegram-cli: FTBFS: build-dependency not installable: libwolfssl-dev
libwolfssl was removed from testing due to #918952. The shared lib was removed but this package was not, because it doesn't depend on the lib. Maybe the B-D can be safely removed. -- WBR, wRAR signature.asc Description: PGP signature
Bug#924383: ruby-coveralls: FTBFS (dh_installman: Cannot find "debian/coveralls.1")
On Tue, Mar 12, 2019 at 09:43:22AM +, Santiago Vila wrote: > TZ=UTC ronn --roff debian/coveralls.mkd > roff: debian/coveralls.mkd.1 [...] > dh_installman: Cannot find (any matches for) "debian/coveralls.1" (tried in > ., debian/tmp) So a change in ronn, I guess. The package in sid wasn't built on buildds so nothing to compare with. -- WBR, wRAR signature.asc Description: PGP signature
Bug#924329: xastir: FTBFS (magick/image-private.h: No such file or directory)
On Mon, Mar 11, 2019 at 05:09:58PM +, Santiago Vila wrote: > In file included from /usr/include/GraphicsMagick/magick/analyze.h:18, > from /usr/include/GraphicsMagick/magick/api.h:55, > from map_geo.c:137: > /usr/include/GraphicsMagick/magick/image.h:1108:10: fatal error: > magick/image-private.h: No such file or directory > #include "magick/image-private.h" > ^~~~ src/map_geo.c: """ #ifdef HAVE_GRAPHICSMAGICK /*#include */ /* Define MAGICK_IMPLEMENTATION to access private interfaces * such as DestroyImagePixels(). This may not be a good thing, * but DestroyImagePixels() has been in this code for a long * time. Defining MAGIC_IMPLEMENTATION eliminates the warning that is * now (9/28/2010) being seen on some distros (Ubuntu 10.04 and * OpenSuSE-11.3) */ #define MAGICK_IMPLEMENTATION #include """ Haha NOPE. -- WBR, wRAR signature.asc Description: PGP signature
Bug#923719: celery: FTBFS ("Download error", probably because of missing build-depends)
On Mon, Mar 04, 2019 at 11:16:02AM +, Santiago Vila wrote: > Searching for billiard<3.6.0,>=3.5.0.2 It's 3.6.0.0 in sid (was 3.5.0.4 when this package was uploaded). -- WBR, wRAR signature.asc Description: PGP signature
Bug#923529: giada: FTBFS (error: expected ')' before '*' token)
The code giving the errors is actually from juce-modules-source. The version used for building the current sid giada package is 5.3.2~repack-1, while the version in sid (which causes FTBFS) is 5.4.1+really5.4.1~repack-2. This seems to be related to #913915, I have no idea how can the current sid version work as some things in juce_VSTPluginFormat.cpp are not defined anywhere. -- WBR, wRAR signature.asc Description: PGP signature
Bug#923454: renderdoc: FTBFS (error: braces around scalar initializer for type 'int')
The problem here is the API compatibility break in glslang, described in https://github.com/KhronosGroup/glslang/issues/1538#issuecomment-431643795 Changes related to the new glslang version seem to be bundled in https://github.com/baldurk/renderdoc/commit/2ea6174c83c3c55f504c107303991d9bb2aa9af3 (I see 3 source files changed there). -- WBR, wRAR signature.asc Description: PGP signature
Bug#923466: lammps: FTBFS (dh_auto_configure fails)
The actual error message is """ CMake Error at CMakeLists.txt:298 (message): MPIIO package needs LAMMPS to be build with MPI Call Stack (most recent call first): CMakeLists.txt:304 (pkg_depends) """ It seems to mean MPI is not found. After removing QUIET from find_package(MPI): -- Found MPI_C: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so (found version "3.1") -- Found MPI_CXX: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so (found version "3.1") -- Could NOT find MPI_Fortran (missing: MPI_Fortran_WORKS) -- Could NOT find MPI (missing: MPI_Fortran_FOUND) (found version "3.1") CMake Error at CMakeLists.txt:298 (message): MPIIO package needs LAMMPS to be build with MPI Call Stack (most recent call first): CMakeLists.txt:304 (pkg_depends) The package B-D on fortran-compiler. The package is virtual, and we see here why is that considered a problem to B-D on a virtual package. Previously gfortran was installed during the build, now flang07 is installed. Yet mpif90 says "The Open MPI wrapper compiler was unable to find the specified compiler gfortran in your PATH." Install gfortran fixes this problem. -- WBR, wRAR signature.asc Description: PGP signature
Bug#923341: Doesn't depend on -dev it uses
Package: libradare2-dev Version: 3.2.1+dfsg-4 Severity: serious Control: block 923321 by -1 At least libuv and liblz4 are listed in Requires.private of the .pc files yet the -dev package doesn't depend on their -dev packages. This leads to pkg-config --cflags r_core failing. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Versions of packages libradare2-dev depends on: ii libcapstone-dev 4.0.1-3 ii libmagic-dev 1:5.35-2 ii libradare2-3.2 3.2.1+dfsg-4 libradare2-dev recommends no packages. libradare2-dev suggests no packages. -- WBR, wRAR signature.asc Description: PGP signature
Bug#923319: dynalogin: FTBFS (Makefile:366: pam_dynalogin_la-pam_dynalogin.lo)
On Tue, Feb 26, 2019 at 11:18:18AM +, Santiago Vila wrote:
> /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
> -DSYSCONFDIR='"/etc"' -I./../libdynaloginclient -Wdate-time
> -D_FORTIFY_SOURCE=2 -pthread -DLINUX -D_REENTRANT -D_GNU_SOURCE
> -I/usr/include/apr-1.0 -I/usr/include/liboath -c -o
> pam_dynalogin_la-pam_dynalogin.lo `test -f 'pam_dynalogin.c' || echo
> './'`pam_dynalogin.c
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -DSYSCONFDIR=\"/etc\"
> -I./../libdynaloginclient -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -DLINUX
> -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apr-1.0 -I/usr/include/liboath -c
> pam_dynalogin.c -fPIC -DPIC -o .libs/pam_dynalogin_la-pam_dynalogin.o
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -DSYSCONFDIR=\"/etc\"
> -I./../libdynaloginclient -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -DLINUX
> -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apr-1.0 -I/usr/include/liboath -c
> pam_dynalogin.c -o pam_dynalogin_la-pam_dynalogin.o >/dev/null 2>&1
> make[3]: *** [Makefile:366: pam_dynalogin_la-pam_dynalogin.lo] Error 1
I have no idea why libtool seems to call gcc twice, the first time
correctly, the second time without -DPIC and suppressing the output, but
the second command fails with the following output:
"""
pam_dynalogin.c:327:8: error: variable ‘_pam_dynalogin_modstruct’ has
initializer but incomplete type
struct pam_module _pam_dynalogin_modstruct = {
^~
pam_dynalogin.c:328:3: warning: excess elements in struct initializer
"pam_dynalogin",
^~~
pam_dynalogin.c:328:3: note: (near initialization for
‘_pam_dynalogin_modstruct’)
pam_dynalogin.c:329:3: warning: excess elements in struct initializer
pam_sm_authenticate,
^~~
pam_dynalogin.c:329:3: note: (near initialization for
‘_pam_dynalogin_modstruct’)
pam_dynalogin.c:330:3: warning: excess elements in struct initializer
pam_sm_setcred,
^~
pam_dynalogin.c:330:3: note: (near initialization for
‘_pam_dynalogin_modstruct’)
pam_dynalogin.c:331:3: warning: excess elements in struct initializer
NULL,
^~~~
pam_dynalogin.c:331:3: note: (near initialization for
‘_pam_dynalogin_modstruct’)
pam_dynalogin.c:332:3: warning: excess elements in struct initializer
NULL,
^~~~
pam_dynalogin.c:332:3: note: (near initialization for
‘_pam_dynalogin_modstruct’)
pam_dynalogin.c:333:3: warning: excess elements in struct initializer
NULL,
^~~~
pam_dynalogin.c:333:3: note: (near initialization for
‘_pam_dynalogin_modstruct’)
pam_dynalogin.c:334:3: warning: excess elements in struct initializer
NULL
^~~~
pam_dynalogin.c:334:3: note: (near initialization for
‘_pam_dynalogin_modstruct’)
pam_dynalogin.c:327:19: error: storage size of ‘_pam_dynalogin_modstruct’ isn’t
known
struct pam_module _pam_dynalogin_modstruct = {
^~~~
"""
This seems to be a direct consequence of missing -DPIC (via #ifndef PIC
#define PAM_STATIC).
--
WBR, wRAR
signature.asc
Description: PGP signature
Bug#921762: need help
On Tue, Feb 26, 2019 at 05:23:13PM +0800, Yanhao Mo wrote: > Control: tags -1 + pending > > Andrey Rahmatullin writes: > > > Control: tags -1 + upstream fixed-upstream > > > > On Wed, Feb 13, 2019 at 09:21:17PM +0800, Yanhao Mo wrote: > >> Control: tags -1 + confirmed help > > This seems to be fixed upstream: > > https://github.com/teejee2008/timeshift/issues/375 > > I see, thanks for reminding, new version will soon be uploaded. Please mind the freeze policy. -- WBR, wRAR signature.asc Description: PGP signature
Bug#921762: need help
Control: tags -1 + upstream fixed-upstream On Wed, Feb 13, 2019 at 09:21:17PM +0800, Yanhao Mo wrote: > Control: tags -1 + confirmed help This seems to be fixed upstream: https://github.com/teejee2008/timeshift/issues/375 -- WBR, wRAR signature.asc Description: PGP signature
Bug#923011: nuxwdog: FTBFS (/usr/include/keyutils.h:204:48: error: expected ',' or '...' before 'private')
On Fri, Feb 22, 2019 at 10:53:47PM +, Santiago Vila wrote: > In file included from src/com/redhat/nuxwdog/wdpwd.cpp:37: > /usr/include/keyutils.h:204:48: error: expected ',' or '...' before 'private' > extern long keyctl_dh_compute_kdf(key_serial_t private, key_serial_t prime, > ^~~ https://bugzilla.redhat.com/show_bug.cgi?id=1629878 https://lkml.org/lkml/2018/8/28/1051 (linked from there) -- WBR, wRAR signature.asc Description: PGP signature
Bug#921898: pilkit: FTBFS (AssertionError: '.apng' != '.png')
Control: tags -1 + upstr4eam fixed-upstream patch pending
On Sat, Feb 09, 2019 at 11:49:51PM +, Santiago Vila wrote:
> ==
> FAIL: tests.test_utils.test_format_to_extension_no_init
> --
> Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File
> "/<>/.pybuild/cpython2_2.7_pilkit/build/tests/test_utils.py",
> line 19, in test_format_to_extension_no_init
> eq_(format_to_extension('PNG'), '.png')
> AssertionError: '.apng' != '.png'
This seems to be fixed by
https://github.com/matthewwithanm/pilkit/commit/c3702a84ae603f4d06dec8827be66c43644a9683
--
WBR, wRAR
signature.asc
Description: PGP signature
Bug#922257: pyfr: FTBFS (dh_installman: Could not determine section for ./build/man/_static)
Control: tags -1 + patch On Wed, Feb 13, 2019 at 08:16:28PM +, Santiago Vila wrote: >dh_installman -i -O--buildsystem=pybuild > dh_installman: Could not determine section for ./build/man/_static This is caused by "build/man/*" in debian/pyfr.manpages. I think it's safe to assume that replacing that with "build/man/pyfr.1" should help. -- WBR, wRAR signature.asc Description: PGP signature
Bug#921787: kombu: FTBFS (failing tests)
Control: tags -1 + upstream fixed-upstream patch This seems to be fixed by https://github.com/celery/kombu/pull/978/files -- WBR, wRAR signature.asc Description: PGP signature
Bug#776246: Processed: severity of 776246 is grave
On Tue, Feb 19, 2019 at 10:00:34PM +0100, Moritz Mühlenhoff wrote: > If a transition (even though it's marginal in size) isn't an option at this > point That's not for me to decide. Should we ask the RT? -- WBR, wRAR signature.asc Description: PGP signature
Bug#921790: liquidsoap: FTBFS (ld: cannot find -lexif)
On Sun, Feb 17, 2019 at 04:58:58PM +0200, Kyle Robbertze wrote: > This is because version 1.0.1 of Camomile is in unstable. I am busy > packaging liquidsoap 1.3.4, which is compatible with newer versions of > Camomile and will fix both these issues. Please note the freeze policy. -- WBR, wRAR signature.asc Description: PGP signature
Bug#921790: liquidsoap: FTBFS (ld: cannot find -lexif)
On Sat, Feb 09, 2019 at 12:15:34AM +, Santiago Vila wrote: > OCAMLOPT -o liquidsoap > /usr/bin/ld: cannot find -lexif libexif-dev is indeed not installed but my build fails even earlier: OCAMLOPT -c tools/file_watcher.ml OCAMLOPT -c tools/file_watcher_mtime.ml OCAMLOPT -c configure.mli OCAMLOPT -c configure.ml File "configure.ml", line 25, characters 11-32: Error: Unbound module Camomile make[4]: *** [../Makefile.rules:193: configure.cmx] Error 2 make[4]: Leaving directory '/<>/src' -- WBR, wRAR signature.asc Description: PGP signature
Bug#915298: gdebi FTBFS with pyflakes 2.0.0-1
Here is the actual pyflakes3 output: ./gdebi-kde:92: local variable 'e' is assigned to but never used ./gdebi-gtk:80: local variable 'e' is assigned to but never used ./GDebi/KDEAptDialogs.py:147: local variable 'e' is assigned to but never used ./GDebi/GDebiKDE.py:363: local variable 'msg' is assigned to but never used ./GDebi/GDebiGtk.py:69: local variable 'e' is assigned to but never used gdebi-gtk:80: local variable 'e' is assigned to but never used gdebi-kde:92: local variable 'e' is assigned to but never used I don't think aborting on non-empty pyflakes output, just like compiling with -Werror, should be a part of a Debian package build. -- WBR, wRAR signature.asc Description: PGP signature
Bug#921803: python-scrapy: FTBFS (failing tests)
I cannot reproduce this on the current sid chroot. Unfortunately the log excerpt in the bug is not helpful and I couldn't access the RB website. -- WBR, wRAR signature.asc Description: PGP signature
Bug#776246: Processed: severity of 776246 is grave
On Sat, Feb 16, 2019 at 12:33:08PM +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > severity 776246 grave > Bug #776246 [librsync1] MD4 collision/preimage attacks (CVE-2014-8242) > Severity set to 'grave' from 'important' > > thanks > Stopping processing here. > > Please contact me if you need assistance. Fixing this requires a transition and removing or patching rdiff-backup so Checking reverse dependencies... # Broken Depends: burp: burp [amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel ppc64el s390x] csync2: csync2 duplicity: duplicity rdiff-backup: rdiff-backup # Broken Build-Depends: burp: librsync-dev csync2: librsync-dev duplicity: librsync-dev (>= 0.9.6) rdiff rdiff-backup: librsync-dev Unfortunately I was too demotivated by the initial state of new librsync (1.0+) and the API breakage affecting rdiff-backup to proceed with this during the release cycle. -- WBR, wRAR signature.asc Description: PGP signature
Bug#907624: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3
On Wed, Jan 09, 2019 at 10:49:48PM +0100, Andreas Tille wrote: > > > to find the exact code line[2] where the SIGSEGV is thrown. It turns out > > > that the elements of a structure are not accessible: > > > > > >(gdb) print entry->offset > > >Cannot access memory at address 0x7 > > It's because entry is 0x7. > > When I was running the code with some more debugging info activated[1] > I had pretty valid looking adresses 0x555666 And still SEGV? > > > The values of the structure are set in line 350[3] and are OK there. > > The problem is not about the structure fields but about the structure > > pointer itself though. > > ... > > You need to find out why one of the tree nodes has an invalid address. > > Can you propose any means to find this out? As usual: reading the code, debugging, printfs. Address sanitizer and/or valgrind may or may not help too. > I have no idea about specific compiler differences. I don't think pondering compiler differences can be helpful here, it's most likely bad code that is working file with some compilers but is still bad code. -- WBR, wRAR signature.asc Description: PGP signature
Bug#907624: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3
On Wed, Jan 09, 2019 at 09:42:43PM +0100, Andreas Tille wrote:
> to find the exact code line[2] where the SIGSEGV is thrown. It turns out
> that the elements of a structure are not accessible:
>
>(gdb) print entry->offset
>Cannot access memory at address 0x7
It's because entry is 0x7.
> In fact I tried in some more detailed debugging that any attempt to
> access one of the structure elements even for instance only injecting
> something like
>
>if ( !entry->offset ) {
Of course this won't work, entry is 0x7.
> The values of the structure are set in line 350[3] and are OK there.
The problem is not about the structure fields but about the structure
pointer itself though.
> The funktion that contains the failing line is action() [4] and called
> via a pointer to this function in line 563[5] (I admit I have no real
> idea why this pointer to a function should be needed. Its the only
> function that is used in this place and IMHO only adds an extra layer of
> complexity.)
No? line 563 calls twalkmisc() which walks the tree and calls action() for
each node.
You need to find out why one of the tree nodes has an invalid address.
--
WBR, wRAR
signature.asc
Description: PGP signature
Bug#916468: Conflict over /usr/bin/dune
Even firefox was renamed twice. -- WBR, wRAR signature.asc Description: PGP signature
Bug#912202: Uses git in debian/rules
Package: src:freeipa Version: 4.7.0~pre1+git20180411-1 Severity: serious override_dh_clean: gencontrol dh_clean if [ -f /usr/bin/git ]; then \ git checkout -- po; \ fi This is unacceptable for several reasons, main one being that the package FTBFS on systems with /usr/bin/git. You are also rewriting debian/control and you should remember that this is forbidden if the file actually changes (and a no-op otherwise). -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#911754: undefined symbol: _D7gobject7ObjectGQi5dorefMFZCQBcQxQz
Package: appstream-generator Version: 0.7.4-1 Severity: grave I've just installed appstream-generator and ran it: $ appstream-generator appstream-generator: symbol lookup error: appstream-generator: undefined symbol: _D7gobject7ObjectGQi5dorefMFZCQBcQxQz So it's either underlinked or some dependency dropped that symbol without bumping the soname, in which case please reassign the bug accordingly. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages appstream-generator depends on: ii libappstream40.12.3-1 ii libarchive13 3.2.2-5 ii libc62.27-6 ii libcairo21.16.0-1 ii libcurl3-gnutls 7.61.0-1 ii libdcontainers0 0.8.0~alpha.9-1 ii libfontconfig1 2.13.1-1 ii libfreetype6 2.8.1-2 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libglib2.0-0 2.58.1-2 ii libglibd-2.0-0 2.0.0-1+b1 ii libjs-highlight.js 9.12.0+dfsg1-4 ii libjs-jquery-flot0.8.3+dfsg-1 ii liblmdb0 0.9.22-1 ii libmustache-d0 0.1.3-3+b1 ii libpango-1.0-0 1.42.4-3 ii libphobos2-ldc-shared78 1:1.8.0-3 ii librsvg2-2 2.40.20-3 ii libstdx-allocator0 2.77.2-1 Versions of packages appstream-generator recommends: ii optipng 0.7.6-1.1 appstream-generator suggests no packages. -- no debconf information
Bug#884352: virtualenvwrapper: Python interpreter inside virtualenv breaks after system python upgrade
On Mon, Sep 24, 2018 at 03:46:09PM -0400, Nicholas D Steeves wrote: > > > after upgrading system-wide Python installation (in my case from 3.5.3 to > > > 3.5.4), > > > virtualenvs may break due to the outdated interpreter > > > (somevirtualenv/bin/python3) inside the venv, trying to work with a newer > > > stdlib. > > This is in no way specific to virtualenvwrapper which is just a wrapper. > > Hi Andrey! If this is the case would you please reassign this bug to > virtualenv? I don't see any real value in reassigning this bug and I don't want to find out the correct binary package name. > > > The problem is that mkvirtualenv copies rather than symlinks the python > > > interpreter binary, but symlinks the modules from standard library (e.g. > > > /usr/lib/python3.5). > > This is done by virtualenv, not mkvirtualenv, and it was always that way, > > and it's quite well known that the breakages happen and how to fix them > > (by running virtualenv again). It is done because otherwise Python would > > not find some files using relative paths. > > > > See also https://github.com/pypa/virtualenv/pull/1171 and note "only for > > Python 3.3 and higher". > > As a beginner to Python it seems to me that the current behaviour > (copied interpreter and symlinked modules) is incorrect and that there > are three correct solutions: > > 1) As proposed in that PR, symlink the interpreter. This will fix itself when the PR is merged, not sooner. > 2) Copy the libraries instead of symlinking them. Can't comment on this. > 3) Downgrade the severity of this bug to non-RC, because this is a > known and expected issue when using virtualenvs. Sure, but this is up to the maintainer. > I imagine that the current behaviour is useful because more > vulnerabilities are found in libraries than in interpreters, and so it > is beneficial for them to automatically follow system-wide security > updates. Of course apt isn't aware of all possible locations of > venvs, so [2] would be bad, unless there was NEWS on each security > update to "update all your virtualenvs". In terms of annoyance > factor, the [2] option (plus running virtualenv again) seems more > annoying (but more secure) than using pip install --upgrade inside the > venv. Can't comment on this. -- WBR, wRAR signature.asc Description: PGP signature
Bug#884352: virtualenvwrapper: Python interpreter inside virtualenv breaks after system python upgrade
On Thu, Dec 14, 2017 at 01:33:18PM +0100, Krzysztof Słychań wrote: > after upgrading system-wide Python installation (in my case from 3.5.3 to > 3.5.4), > virtualenvs may break due to the outdated interpreter > (somevirtualenv/bin/python3) inside the venv, trying to work with a newer > stdlib. This is in no way specific to virtualenvwrapper which is just a wrapper. > The problem is that mkvirtualenv copies rather than symlinks the python > interpreter binary, but symlinks the modules from standard library (e.g. > /usr/lib/python3.5). This is done by virtualenv, not mkvirtualenv, and it was always that way, and it's quite well known that the breakages happen and how to fix them (by running virtualenv again). It is done because otherwise Python would not find some files using relative paths. See also https://github.com/pypa/virtualenv/pull/1171 and note "only for Python 3.3 and higher". -- WBR, wRAR signature.asc Description: PGP signature
Bug#907806: How to disable tests for Python2 only?
On Mon, Sep 10, 2018 at 04:33:21PM +0200, Andreas Tille wrote: > Hi, > > looking at the bug log of scikit-learn[1] it seems to be a simple means to do > > --- a/debian/control > +++ b/debian/control > @@ -20,6 +20,7 @@ Build-Depends: debhelper (>= 9), dh-autoreconf, > python3-pytest, > python3-matplotlib, > python3-joblib (>= 0.9.2), > + python3-distributed , > libsvm-dev (>= 2.84.0), > libatlas3-base, > Build-Depends-Indep: I don't think that's how build profiles work. > However, it seems that due to the fact that this package uses > --buildsystem=python_distutils Which is already a problem, as it doesn't support py3. There is a lot of strange hacks in this rules file. I'm especially interested in "dh_autoreconf debian/rules -- clean_generated" but that's a question for another discussion. > Are there any other ways to exclude some tests for Python2 to make this > package build again? rules call nosetests directly so I guess find out how to do that with nosetests. -- WBR, wRAR signature.asc Description: PGP signature
Bug#905788: FTBFS: cannot find -lgpod
Package: src:libgpod Version: 0.8.3-11 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: ftbfs Trying to build the package in a fresh sid sbuild chroot I get libtool: warning: relinking '_gpod.la' libtool: install: (cd /<>/build/python2.7/bindings/python; /bin/bash "/<>/build/python2.7/libtool" --tag CC --mode=relink gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -module -avoid-version -shared -Wl,-z,relro -Wl,-O1 -Wl,--as-needed -o _gpod.la -rpath /usr/lib/python2.7/dist- packages/gpod _gpod_la-gpod_wrap.lo -lgobject-2.0 -lsqlite3 -lplist -Wl,-- export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lxml2 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lgobject-2.0 -lglib-2.0 ../../src/libgpod.la -inst- prefix-dir /<>/debian/tmp) Byte-compiling python modules (optimized versions) ... __init__.pygtkpod.pyipod.py Byte-compiling python modules (optimized versions) ... gpod.py libtool: relink: gcc -shared -fPIC -DPIC .libs/_gpod_la-gpod_wrap.o -L/<>/debian/tmp/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux- gnu -lsqlite3 -lplist -lgmodule-2.0 -lxml2 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lgpod -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-O1 -Wl,--as-needed -Wl,--export-dynamic -pthread -pthread -Wl,-soname -Wl,_gpod.so -o .libs/_gpod.so /usr/bin/ld: cannot find -lgpod collect2: error: ld returned 1 exit status libtool: error: error: relink '_gpod.la' with the above command before installing it -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash -- WBR, wRAR signature.asc Description: PGP signature
Bug#896230: python-gpod: gpod fails to import
On Mon, Apr 23, 2018 at 08:28:22PM +0100, Mark Williams wrote: > Installing python-gobject seems to work around this. Suggest this is added > to dependencies. Thank you for this observation, it seems dh_python2 --depends=gobject doesn't produce the correct depends on python-gobject-2. -- WBR, wRAR signature.asc Description: PGP signature
Bug#905327: Some apps hang randomly
Control: clone -1 -2 Control: reassign -2 kde-style-qtcurve-qt4 1.8.18+git20160320-3d8622c-5 On Fri, Aug 03, 2018 at 04:54:13PM +0500, Andrey Rahmatullin wrote: > Actually, it seems that any Qt5 app with a menu bar is easily hanged by > moving the pointer over the menu bar for some time (tested with kmag). Qt4 apps just segfault. -- WBR, wRAR signature.asc Description: PGP signature
Bug#902897: virtualbox broken by binutils master (new R_X86_64_PLT32 relocation type)
Actually, if you had virtualbox-ext-pack installed, you just need to install back/reinstall/upgrade it. -- WBR, wRAR signature.asc Description: PGP signature
Bug#902897: virtualbox broken by binutils master (new R_X86_64_PLT32 relocation type)
On Thu, Jul 12, 2018 at 10:16:36AM -0500, Kent West wrote: > > Note! This error could also mean that an incompatible version of the > > 'Oracle VM VirtualBox Extension Pack' is installed (VERR_NOT_FOUND). > While VirtualBox was broken this week, I had tried various things ( > snapshot.debian.org, virtualbox.org, etc), but once I learned that the fix > had been uploaded to stable, To unstable (the only place where it was broken). > But if I'm understanding this error, for some months (years?), I've been > pulling VirtualBox from virtualbox.org No, the extension pack can be installed on the Debian Virtualbox separately and I don't think it's installed by default even with the official package. > instead of from Debian, and whilst > doing that, had configured my VMs with USB support. And my fix should just > be to disable the USB support in my VMs The fix should be to upgrade the extension pack after you upgraded virtualbox itself... -- WBR, wRAR signature.asc Description: PGP signature
Bug#902897: virtualbox broken by binutils master (new R_X86_64_PLT32 relocation type)
On Thu, Jul 12, 2018 at 10:08:06AM -0500, Kent West wrote: > I just did an "aptitude udpate" and "aptitude dist-upgrade", and got a new > version of VirtualBox. > > When I try to start a virtual machine, I get a new error: > > > Implementation of the USB 2.0 controller not found! > > Because the USB 2.0 controller state is part of the saved VM state, the VM > cannot be started. To fix this problem, either install the > 'Oracle VM VirtualBox Extension Pack' or disable USB 2.0 support in the VM > settings. > > Note! This error could also mean that an incompatible version of the > 'Oracle VM VirtualBox Extension Pack' is installed (VERR_NOT_FOUND). Update the extension pack. -- WBR, wRAR signature.asc Description: PGP signature
Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED)
On Mon, Jul 09, 2018 at 08:56:16AM -0500, Kent West wrote: > > Obviously I merely downgraded to the last functioning version of > > virtualbox et. al. (5.2.12-dfsg-3) in unstable > > But how did you do this? debsnap I suppose. I personally just downgraded to the version in testing. -- WBR, wRAR signature.asc Description: PGP signature
Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED)
On Sun, Jul 08, 2018 at 02:54:02PM -0500, Steven R. Wright wrote: > This is a critical enough bug to warrant removing 5.2.14-dfsg-1 from the > repos. I have to do selective upgrades now to avoid pulling it in. apt-listbugs should be enough to mitigate this. -- WBR, wRAR signature.asc Description: PGP signature
Bug#902650: SyntaxError during package configuration with Python 3.7
Package: diffoscope Version: 97 Severity: grave Setting up diffoscope (97) ... File "/usr/lib/python3/dist-packages/diffoscope/comparators/json.py", line 41 file.magic_file_type.startswith(x) ^ SyntaxError: Generator expression must be parenthesized File "/usr/lib/python3/dist-packages/diffoscope/presenters/formats.py", line 112 x['klass'].supports_visual_diffs for x in self.config.values(), ^ SyntaxError: Generator expression must be parenthesized dpkg: error processing package diffoscope (--configure): installed diffoscope package post-installation script subprocess returned error exit status 1 >From the 3.7 release notes (https://docs.python.org/3.7/whatsnew/3.7.html#changes-in-python-behavior): """ Due to an oversight, earlier Python versions erroneously accepted the following syntax: f(1 for x in [1],) class C(1 for x in [1]): pass Python 3.7 now correctly raises a SyntaxError, as a generator expression always needs to be directly inside a set of parentheses and cannot have a comma on either side, and the duplication of the parentheses can be omitted only on calls. """ -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-rc7-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages diffoscope depends on: ii libpython3.6-stdlib3.6.6-1 ii python33.6.6-1 ii python3-distro 1.0.1-2 ii python3-distutils 3.6.6-1 ii python3-libarchive-c 2.1-3.1 ii python3-magic 2:0.4.15-1 ii python3-pkg-resources 39.2.0-1 Versions of packages diffoscope recommends: pn abootimg ii acl 2.2.52-3+b1 pn apktool pn binutils-multiarch ii bzip21.0.6-8.1 ii caca-utils 0.99.beta19-2+b3 ii colord 1.3.3-2 pn db-util ii default-jdk [java-sdk] 2:1.10-67 ii default-jdk-headless 2:1.10-67 pn device-tree-compiler pn docx2txt ii e2fsprogs1.44.2-1 pn enjarify pn fontforge-extras pn fp-utils ii genisoimage 9:1.1.11-3+b2 ii gettext 0.19.8.1-6+b1 pn ghc ii ghostscript 9.22~dfsg-2.1 pn giflib-tools pn gnumeric ii imagemagick 8:6.9.9.39+dfsg-1 ii imagemagick-6.q16 [imagemagick] 8:6.9.9.39+dfsg-1 pn jsbeautifier pn libarchive-tools pn llvm ii mono-utils 4.6.2.7+dfsg-2 pn odt2txt pn oggvideotools ii openjdk-10-jdk [java-sdk]10.0.1+10-4 ii openssh-client 1:7.7p1-2 pn pgpdump ii poppler-utils0.63.0-2 pn procyon-decompiler pn python3-argcomplete pn python3-binwalk ii python3-debian 0.1.32 pn python3-defusedxml pn python3-guestfs pn python3-jsondiff pn python3-progressbar pn python3-pyxattr ii python3-tlsh 3.4.4+20151206-1+b3 pn r-base-core pn sng ii sqlite3 3.24.0-1 ii squashfs-tools 1:4.3-6 ii tcpdump 4.9.2-3 ii unzip6.0-21 ii vim-common 2:8.1.0089-1 pn xmlutils ii xxd 2:8.1.0089-1 ii xz-utils 5.2.2-1.3 Versions of packages diffoscope suggests: ii libjs-jquery 3.2.1-1 -- debconf-show failed
