Bug#920583: gcc-8-cross-mipsen should depend on binutils and c-t-b -mipsen packages
Package: src:gcc-8-cross-mipsen Version: 1~c1 Severity: serious Tags: sid buster gcc-8-cross-mipsen should build-depend on binutils and c-t-b -mipsen source packages not built from the -ports packages. It doesn't make sense to build those in the -ports packages. That splitting should be done before the buster release. Also you should add yourself as an uploader for these packages.
Bug#920525: freecad: autopkgtest failure
> From what I can see, I think the test itself passes, but it outputs > stuff to stderr, which causes autopkgtest to consider it as a failure. worked around by http://launchpadlibrarian.net/408472848/freecad_0.17+dfsg1-7_0.17+dfsg1-7ubuntu1.diff.gz however the tests still fail on i386 and s390x (regressions from the previous version), seen at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/i386/f/freecad/20190126_205423_961b9@/log.gz == FAIL: testSimpleAdditiveLoftCase (PartDesignTests.TestLoft.TestLoft) -- Traceback (most recent call last): File "/usr/share/freecad/Mod/PartDesign/PartDesignTests/TestLoft.py", line 48, in testSimpleAdditiveLoftCase self.assertAlmostEqual(self.AdditiveLoft.Shape.Volume, 1) AssertionError: 0.49994 != 1 within 7 places == FAIL: testSimpleSubtractiveLoftCase (PartDesignTests.TestLoft.TestLoft) -- Traceback (most recent call last): File "/usr/share/freecad/Mod/PartDesign/PartDesignTests/TestLoft.py", line 77, in testSimpleSubtractiveLoftCase self.assertAlmostEqual(self.SubtractiveLoft.Shape.Volume, 1) AssertionError: 2.0 != 1 within 7 places -- Ran 266 tests in 23.295s FAILED (failures=2) and https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/s390x/f/freecad/20190126_205754_961b9@/log.gz Save FreeCAD file for thermomech analysis to /tmp/FEM_unittests/FEM_ccx_Flow1D_thermomech/Flow1D_thermomech.fcstd... --- End of FEM tests FLow 1D thermomech analysis --- ok test_mesh_seg2_python (femtest.testmesh.FemMeshTest) ... ok test_mesh_seg3_python (femtest.testmesh.FemMeshTest) ... Program received signal SIGSEGV, Segmentation fault. #0 [0x3ffd1af9af6] #1 0x3ff72d87274 in DriverUNV_R_SMDS_Mesh::Perform() from /usr/lib/freecad/lib/libDriverUNV.so+0x123c #2 0x3ff77fa8dcc in SMESH_Mesh::UNVToMesh(char const*) from /usr/lib/freecad/lib/libSMESH.so+0x13c #3 0x3ff78952efa in Fem::FemMesh::read(char const*) from /usr/lib/freecad/lib/Fem.so+0xc2 #4 0x3ff7898d234 in Fem::Module::read(Py::Tuple const&) from /usr/lib/freecad/lib/Fem.so+0xac #5 0x3ff7898cd36 in Fem::Module::invoke_method_varargs(void*, Py::Tuple const&) from /usr/lib/freecad/lib/Fem.so+0x4e #6 /usr/lib/freecad/lib/libFreeCADBase.so(method_varargs_call_handler+0x1b4) [0x3ff7edfe4a4] #7 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x92ea) [0x3ff7ea2d462] #8 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x9bc8) [0x3ff7ea2dd40] #9 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x8c8) [0x3ff7ea237e0] #10 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(+0x1b4668) [0x3ff7eab4668] #11 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x5c) [0x3ff7eae35e4] #12 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x1356) [0x3ff7ea254ce] #13 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x8c8) [0x3ff7ea237e0] #14 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(+0x1b4554) [0x3ff7eab4554] #15 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x5c) [0x3ff7eae35e4] #16 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(+0x1cdfc2) [0x3ff7eacdfc2] #17 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x5c) [0x3ff7eae35e4] #18 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(+0x17644e) [0x3ff7ea7644e] #19 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x5c) [0x3ff7eae35e4] #20 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x34b0) [0x3ff7ea27628] #21 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x8c8) [0x3ff7ea237e0] #22 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(+0x1b4668) [0x3ff7eab4668] #23 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x5c) [0x3ff7eae35e4] #24 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x1356) [0x3ff7ea254ce] #25 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x8c8) [0x3ff7ea237e0] #26 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(+0x1b4554) [0x3ff7eab4554] #27 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x5c) [0x3ff7eae35e4] #28 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(+0x1cdfc2) [0x3ff7eacdfc2] #29 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x5c) [0x3ff7eae35e4] #30 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(+0x17644e) [0x3ff7ea7644e] #31 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x5c) [0x3ff7eae35e4] #32 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x34b0) [0x3ff7ea27628] #33 /usr/lib/s390x-linux-gnu/libpython2.7.so.1.
Bug#745696: Please split system-wide configuration into a separate package or remove it
On Mon, 12 Mar 2018 00:18:28 +0100 Samuel Thibault wrote: > Josh Triplett, on lun. 23 nov. 2015 22:11:18 -0800, wrote: > > one of the few packages left in a default desktop install that runs an > > init script with a default file disabling it. I'd like to remove that > > if possible. > > AIUI, with the addition of a systemd service file in version 0.8.8-3, > the actual concern here is avoided and thus the bug could be closed? The disabled-by-default /etc/init.d/speech-dispatcher should still not exist; init scripts disabled by /etc/default files are an anti-pattern. Thank you for providing a .service file, however!
Bug#920582: gcc -v --help prints some output to stderr, not just stdout
Package: gcc-8 Version: 8.2.0-15 Severity: normal "gcc -v --help" prints some of its output to stderr, rather than stdout, which makes it awkward to run "gcc -v --help | less" as the stderr output steps on the pager. I think that all of the output from "gcc -v --help" should go to stdout. ~$ gcc -v --help > /dev/null Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-15' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.2.0 (Debian 8.2.0-15) COLLECT_GCC_OPTIONS='-v' '--help' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/8/cc1 -quiet -v -imultiarch x86_64-linux-gnu help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --help -o /tmp/ccySaX4x.s GNU C17 (Debian 8.2.0-15) version 8.2.0 (x86_64-linux-gnu) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.2-rc1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '--help' '-mtune=generic' '-march=x86-64' as -v --64 --help -o /tmp/ccLXnLHJ.o /tmp/ccySaX4x.s GNU assembler version 2.31.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.31.1 COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '--help' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/8/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper -plugin-opt=-fresolution=/tmp/ccJX8YkV.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie --help /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/8 -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/8/../../.. /tmp/ccLXnLHJ.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o COLLECT_GCC_OPTIONS='-v' '--help' '-mtune=generic' '-march=x86-64'
Bug#920581: RM: mariadb-10.1 -- ROM; obsoleted by mariadb-10.3
Package: ftp.debian.org Severity: normal Please remove src:mariadb-10.1 and selected binaries it has created from unstable. MariaDB 10.1 has been replaced by MariaDB 10.3. The source package mariadb-10.3 produces slightly different binary packages than the old mariadb-10.1 and thus there are some binary packages left from src:mariadb-10.1 that hasn't been automatically obsoleted by the newer version from src:mariadb-10.3: libmariadbclient-dev-compat libmariadbd18 mariadb-client-core-10.1 mariadb-client-10.1 mariadb-server-core-10.1 mariadb-server-10.1 Thank you ftp-masters!
Bug#920580: ITP: golang-gitlab-lupine-go-mimedb -- library package
Package: wnpp Severity: wishlist Owner: Anoop M S * Package name : golang-gitlab-lupine-go-mimedb Version : 1.33.0-1 Upstream Author : Nick Thomas * URL : https://gitlab.com/lupine/go-mimedb (https://gitlab.com/lupine/go-mimedb) * License : MIT Programming Lang: Go Description : This Go package uses generators to convert this database into additions to the stdlib mime package. . Since all the work is done at compile time, the MIME types end up embedded in the binary,loading them on startup is fast, and you still get sensible results when /etc/mime.types is unavailable on your platform! . This work is somewhat inspired by mime-ext-go, which lacks the automatic generation (and so easy update) to be found in this package. It is a dependency package for gitlab-pages. GitLab Pages daemon used to serve static websites for GitLab users. So inorder to package gitlab-pages I have to package this dependency. I would like to package gitlab-pages and maintain it. Thank You
Bug#920578: gstreamer-vaapi: FTBFS on 32-bit architectures
Source: gstreamer-vaapi
Version: 1.15.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi,
gstreamer-vaapi/experimental FTBFS on the 32-bit architectures:
https://buildd.debian.org/status/package.php?p=gstreamer-vaapi&suite=experimental
from the i386 log:
/bin/bash ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../../../gst-libs/gst/vaapi -I../../.. -Wdate-time -D_FORTIFY_SOURCE=2
-DGST_USE_UNSTABLE_API -I../../../../gst-libs -I../../../gst-libs -pthread
-I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include -pthread
-I/usr/include/gstreamer-1.0 -I/usr/include/orc-0.4
-I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include -pthread
-I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include -DGST_USE_UNSTABLE_API
-fno-strict-aliasing -DG_THREADS_MANDATORY -DG_DISABLE_DEPRECATED -Wall
-Wdeclaration-after-statement -Wvla -Wpointer-arith -Wmissing-declarations
-Wmissing-prototypes -Wwrite-strings -Wformat-security -Wold-style-definition
-Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -Wnested-externs
-Werror -g -pthread -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include-g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -c -o libgstvaapi_la-gstvaapiwindow.lo `test -f
'gstvaapiwindow.c' || echo '../../../../gst-libs/gst/vaapi/'`gstvaapiwindow.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../gst-libs/gst/vaapi
-I../../.. -Wdate-time -D_FORTIFY_SOURCE=2 -DGST_USE_UNSTABLE_API
-I../../../../gst-libs -I../../../gst-libs -pthread
-I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include -pthread
-I/usr/include/gstreamer-1.0 -I/usr/include/orc-0.4
-I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include -pthread
-I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include -DGST_USE_UNSTABLE_API
-fno-strict-aliasing -DG_THREADS_MANDATORY -DG_DISABLE_DEPRECATED -Wall
-Wdeclaration-after-statement -Wvla -Wpointer-arith -Wmissing-declarations
-Wmissing-prototypes -Wwrite-strings -Wformat-security -Wold-style-definition
-Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -Wnested-externs
-Werror -g -pthread -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -c ../../../../gst-libs/gst/vaapi/gstvaapiwindow.c
-fPIC -DPIC -o .libs/libgstvaapi_la-gstvaapiwindow.o
In file included from /usr/include/gstreamer-1.0/gst/gst.h:55,
from ../../../../gst-libs/gst/vaapi/sysdeps.h:34,
from ../../../../gst-libs/gst/vaapi/gstvaapiwindow.c:30:
../../../../gst-libs/gst/vaapi/gstvaapiwindow.c: In function
'gst_vaapi_window_new_internal':
../../../../gst-libs/gst/vaapi/gstvaapiwindow.c:250:29: error: format '%lx'
expects argument of type 'long unsigned int', but argument 8 has type
'GstVaapiID' {aka 'unsigned int'} [-Werror=format=]
GST_DEBUG_OBJECT (window, "new window with id = 0x%08lx and size %ux%u", id,
^ ~~
/usr/include/gstreamer-1.0/gst/gstinfo.h:640:31: note: in definition of macro
'GST_CAT_LEVEL_LOG'
(GObject *) (object), __VA_ARGS__);\
^~~
../../../../gst-libs/gst/vaapi/gstvaapiwindow.c:250:3: note: in expansion of
macro 'GST_DEBUG_OBJECT'
GST_DEBUG_OBJECT (window, "new window with id = 0x%08lx and size %ux%u", id,
^~~~
cc1: all warnings being treated as errors
make[5]: *** [Makefile:1699: libgstvaapi_la-gstvaapiwindow.lo] Error 1
Andreas
Bug#920579: sipcrack: don't strip during build
Source: sipcrack
Version: 0.2-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap
sipcrack's upstream Makefile has a call to strip. This call breaks a
number of use cases:
* Cross building (because it uses the wrong strip).
* Generation of a -dbgsym package.
* DEB_BUILD_OPTIONS=nostrip.
Simply removing the call fixes all of these problems. Please consider
applying the attached patch.
Helmut
--- sipcrack-0.2.orig/Makefile
+++ sipcrack-0.2/Makefile
@@ -16,13 +16,11 @@
default: ${SIPCRACK} ${SIPDUMP} ${OBJS}
${CC} ${FLAGS} -o sipcrack ${OBJS} ${SIPCRACK} ${LIBS} ${LIBSSL}
${CC} ${FLAGS} -o sipdump ${OBJS} ${SIPDUMP} ${LIBS} ${LIBPCAP}
- strip sipcrack sipdump
@echo \* All done
no-openssl: ${SIPCRACK} ${SIPDUMP} ${OBJS} ${MD5}
${CC} ${FLAGS} -o sipcrack -DNO_OPENSSL ${OBJS} ${MD5} ${SIPCRACK} ${LIBS}
${CC} ${FLAGS} -o sipdump ${OBJS} ${SIPDUMP} ${LIBS} ${LIBPCAP}
- strip sipcrack sipdump
@echo \* All done
clean:
Bug#920577: ocsinventory-server: depends on no longer available libjs-select2.js
Package: ocsinventory-server Version: 2.6~RC+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package is not installable in experimental: The following packages have unmet dependencies: ocsinventory-reports : Depends: libjs-select2.js but it is not installable libjs-select2.js was removed after stretch. Cheers, Andreas
Bug#920576: linux: Please enable CONFIG_HSA_AMD
Source: linux Version: 4.20-trunk-amd64 Severity: normal Dear Maintainer, In order to use AMD's ROCM GPU compute stack with the upstream kernel, it is necessary that CONFIG_HSA_AMD is enabled, however $ grep AMD /boot/config-4.20.0-trunk-amd64 yields # CONFIG_HSA_AMD is not set It would be fantastic if HSA/AMD GPU compute were possible with upstream kernels in Debian. Thanks! Andreas -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#920575: copyright-without-copyright-notice assumes upstream has copyright notices
Package: lintian Version: 2.5.124 Severity: normal The check "copyright-without-copyright-notice" assumes that upstream has copyright notices to include. Given that copyright notices are not legally required (and copyright subsists in works without such notices), some upstreams avoid including such notices. In such a work, debian/copyright would have no such copyright notice to include. To forestall an obvious objection, namely "what about a copyright notice for the Debian packaging", the same thing applies to people writing Debian packaging as well. (This lintian issue currently leads me to have a build wrapper script generating debian/copyright, rather than just having a static debian/copyright file checked in.) Thanks, Josh Triplett
Bug#917812: (no subject)
I had the same issue (packagekit worked fine until gnome-software re-opened, where PK will crash), and on a hunch I followed http://allnightburger.com/solved-gnome-software-center-frozen-in-fedora/ but for Debian: sudo apt-get autoremove --purge packagekit gnome-software I noticed that the removal failed un-cleanly: rmdir: failed to remove '/var/cache/app-info/': Directory not empty So I removed the folder nroach44@woody:~$ tree /var/cache/app-info/ /var/cache/app-info/ └── xmls 1 directory, 0 files nroach44@woody:~$ sudo rm -rf /var/cache/app-info/ And reinstalled task-gnome-desktop (to cover the pre-reqs removed by autoremove above) sudo apt-get install task-gnome-desktop And then restarted gnome-software (left it running, whoops) and it started working fine. I figured it wasn't just a bug as my desktop (fully updated like this machine) didn't have the issue. Hopefully this helps narrow down the issue. pEpkey.asc Description: application/pgp-keys
Bug#920573: liferea: random crash (SIGSEGV)
Package: liferea Version: 1.12.6-1 Severity: normal Usertags: crash Today I had a random crash (SIGSEGV) in liferea. If the information below is not useful, please close this bug. $ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' --core /var/crash/1000/2838-1000-1000-11-1548564885-chianamo--usr-bin-liferea.core /usr/bin/liferea [New LWP 2838] [New LWP 5082] [New LWP 5084] [New LWP 6082] [New LWP 5087] [New LWP 2969] [New LWP 2930] [New LWP 2928] [New LWP 6080] [New LWP 5085] [New LWP 26447] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `liferea'. Program terminated with signal SIGSEGV, Segmentation fault. #0 liferea_web_view_on_menu (view=0x55678fabbfb0, context_menu=, event=0x0, hit_result=, user_data=) at liferea_web_view.c:229 229 liferea_web_view.c: No such file or directory. [Current thread is 1 (Thread 0x7f5aef044ac0 (LWP 2838))] #0 0x55678f45ea86 in liferea_web_view_on_menu (view=0x55678fabbfb0 [LifereaWebView], context_menu=, event=0x0, hit_result=, user_data=) at liferea_web_view.c:229 #1 0x7f5af06fb8ee in ffi_call_unix64 () at ../src/x86/unix64.S:76 #2 0x7f5af06fb2bf in ffi_call (cif=cif@entry=0x7ffefbc30f60, fn=fn@entry=0x55678f45e4b0 , rvalue=, avalue=avalue@entry=0x7ffefbc30e90) at ../src/x86/ffi64.c:525 #7 0x7f5af697790f in (instance=instance@entry=0x55678fabbfb0, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3447 #3 0x7f5af695b472 in g_cclosure_marshal_generic (closure=0x55678ff38100, return_gvalue=0x7ffefbc31130, n_param_values=, param_values=, invocation_hint=, marshal_data=) at ../../../gobject/gclosure.c:1496 #4 0x7f5af695ac7d in g_closure_invoke (closure=0x55678ff38100, return_value=0x7ffefbc31130, n_param_values=4, param_values=0x7ffefbc31190, invocation_hint=0x7ffefbc31110) at ../../../gobject/gclosure.c:810 #5 0x7f5af696e333 in signal_emit_unlocked_R (node=node@entry=0x55678f9fba00, detail=detail@entry=0, instance=instance@entry=0x55678fabbfb0, emission_return=emission_return@entry=0x7ffefbc312e0, instance_and_params=instance_and_params@entry=0x7ffefbc31190) at ../../../gobject/gsignal.c:3635 #6 0x7f5af6976983 in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=var_args@entry=0x7ffefbc31390) at ../../../gobject/gsignal.c:3401 #8 0x7f5af7d2f738 in webkitWebViewPopulateContextMenu(_WebKitWebView*, WTF::Vector const&, WebKit::WebHitTestResultData const&, _GVariant*) (webView=0x55678fabbfb0 [LifereaWebView], proposedMenu=..., hitTestResultData=..., userData=userData@entry=0x0) at ./Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:2319 #9 0x7f5af7d04403 in ContextMenuClient::getContextMenuFromProposedMenu(WebKit::WebPageProxy&, WTF::Vector >, 0ul, WTF::CrashOnOverflow, 16ul>&&, WebKit::WebContextMenuListenerProxy&, WebKit::WebHitTestResultData const&, API::Object*) (this=0x55678ff3ea20, proposedMenu=..., contextMenuListener=..., hitTestResultData=..., userData=) at ./Source/WebKit/UIProcess/API/glib/WebKitContextMenuClient.cpp:50 #10 0x7f5af7db772b in WebKit::WebContextMenuProxyGtk::show() (this=0x7f5adfe8a498) at ./obj-x86_64-linux-gnu/DerivedSources/ForwardingHeaders/wtf/Vector.h:365 #11 0x7f5af7c77762 in WebKit::WebPageProxy::showContextMenu(WebKit::ContextMenuContextData&&, WebKit::UserData const&) (this=0x7f5adfaf, contextMenuContextData=..., userData=...) at ./obj-x86_64-linux-gnu/DerivedSources/ForwardingHeaders/wtf/DumbPtrTraits.h:41 #12 0x7f5af7accc7f in IPC::callMemberFunctionImpl, 0ul, 1ul>(WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(WebKit::ContextMenuContextData&&, WebKit::UserData const&), std::tuple&&, std::integer_sequence) (args=..., function=(void (WebKit::WebPageProxy::*)(class WebKit::WebPageProxy * const, class WebKit::ContextMenuContextData &&, const class WebKit::UserData &)) 0x7f5af7c773d0 , object=0x7f5adfaf) at ./Source/WebKit/Platform/IPC/HandleMessage.h:45 #13 0x7f5af7accc7f in IPC::callMemberFunction, std::integer_sequence >(std::tuple&&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(WebKit::ContextMenuContextData&&, WebKit::UserData const&)) (function=(void (WebKit::WebPageProxy::*)(class WebKit::WebPageProxy * const, class WebKit::ContextMenuContextData &&, const class WebKit::UserData &)) 0x7f5af7c773d0 , object=0x7f5adfaf, args=...) at ./Source/WebKit/Platform/IPC/HandleMessage.h:47 #14 0x7f5af7accc7f in IPC::handleMessage(IPC::Decoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(WebKit::ContextMenuContextData&&, WebKit::UserData const&)) (decoder=..., object=object@entry=0x7f5adfaf, function=(void (WebKit::WebPageProxy::*)(class WebKit::WebPageProxy * const, class WebKit::ContextMenuContextData &&, const class WebKit::UserData &)) 0x7f5af7c773d0 ) at ./Source/WebKit/Platform/IPC/HandleMessage.h:127
Bug#920574: libvirt-daemon-system: conffiles not removed
Package: libvirt-daemon-system
Version: 5.0.0-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate
The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb
This bug report brought to you by adequate:
http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
$ pkg=libvirt-daemon-system ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n'
$pkg | grep obsolete
libvirt-daemon-system: obsolete-conffile /etc/logrotate.d/libvirtd.uml
/etc/logrotate.d/libvirtd.uml 9c5dbd5acdeb2d796fa02bf24a0cf8f3 obsolete
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
LANGUAGE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libvirt-daemon-system depends on:
ii adduser3.118
ii debconf [debconf-2.0] 1.5.70
ii gettext-base 0.19.8.1-9
ii iptables 1.8.2-3
ii libacl12.2.52-3+b1
ii libapparmor1 2.13.2-3
ii libaudit1 1:2.8.4-2
ii libblkid1 2.33.1-0.1
ii libc6 2.28-5
ii libcap-ng0 0.7.9-2
ii libdbus-1-31.12.12-1
ii libdevmapper1.02.1 2:1.02.155-1
ii libgnutls303.6.5-2
ii libnl-3-2003.4.0-1
ii libnl-route-3-200 3.4.0-1
ii libnuma1 2.0.12-1
ii libselinux12.8-1+b1
ii libvirt-clients5.0.0-1
ii libvirt-daemon 5.0.0-1
ii libvirt0 5.0.0-1
ii libxml22.9.4+dfsg1-7+b3
ii libyajl2 2.1.0-3
ii logrotate 3.14.0-4
ii lsb-base 10.2018112800
ii policykit-10.105-25
Versions of packages libvirt-daemon-system recommends:
ii dmidecode3.2-1
ii dnsmasq-base [dnsmasq-base] 2.80-1
ii ebtables 2.0.10.4+snapshot20181205-1
ii iproute2 4.20.0-2
ii parted 3.2-23
Versions of packages libvirt-daemon-system suggests:
ii apparmor2.13.2-3
pn auditd
pn nfs-common
pn open-iscsi
ii pm-utils1.4.1-18
pn radvd
ii systemd 240-4
pn systemtap
pn zfsutils
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#920572: RM: resiprocate -- RoQA; Multiple RC bugs, unmaintained
Package: ftp.debian.org Severity: normal Please remove resiprocate. It's one of the last few remaining packages blocking the OpenSSL removal, hasn't seen an upload since 1.5 years and has piled up 5 RC bugs at this point. Cheers, Moritz
Bug#920553: pkg-config: Undefined subroutine &main::warning called at /usr/share/pkg-config-dpkghook line 34.
]] Axel Beckert Hi, thanks for reporting this. > pkg-config fails to upgrade on two machines (1x amd64 with i386 as > foreign architecture, 1x pure i386) as follows for me: Both of those probably have a non-valid dpkg architecture enabled, such as «x86». What does dpkg --print-foreign-architectures on them output? [...] > It does though not happen on all of my sid machines, including other > amd64 machines. Maybe a missing dependency on some Perl module or so? It was a missing import; I've fixed this now, but if it's something else than what I think it is, then it'd be good to get the other bug fixed too, so it'd be good to get an answer to my question above. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#920571: Should this package be removed?
Source: zorp Severity: serious Should zorp be removed? It's incompatible with OpenSSL 1.1 and the bug has been unacknowledged since 15 months (859840). It's one of the few remaining packages blocking the removal at this point, so this doesn't get ported to OpenSSL 1.1, zorp should be removed along with src:openssl1.0. Cheers, Moritz
Bug#920570: RM: stunserver -- RoQA; Unmaintained, RC-buggy
Package: ftp.debian.org Severity: normal Please remove stunserver. It's unmaintained (last maintainer upload in 2015) and incompatible with OpenSSL 1.1. It's also removed from testing for over a year now. Cheers, Moritz
Bug#920569: php-yaml: Segfault when YAML array merge syntax is used with yaml_parse
Package: php-yaml
Version: 2.0.2+1.3.1-4
Severity: normal
Dear Maintainer,
I'm observing a repeatable PHP segfault then php-yaml attempts to parse any
file that uses the "<<" array-merge syntax. A minimal example:
- <<:
foo: bar
After placing this text in a file called "demo.yml", the markup can be parsed
via this command-line invovation of PHP:
php -r 'yaml_parse(file_get_contents("demo.yml"));'
The above command prints "Segmentation fault", and exits with code
139. A GDB session showing the stack trace:
$ gdb php
GNU gdb (Debian 8.2-1) 8.2
...
(gdb) run -r 'yaml_parse(file_get_contents("demo.yml"));'
Starting program: /usr/bin/php -r 'yaml_parse(file_get_contents("demo.yml"));'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x5580b82c in zend_hash_merge ()
(gdb) bt
#0 0x5580b82c in zend_hash_merge ()
#1 0x71023b49 in handle_mapping () from /usr/lib/php/20180731/yaml.so
#2 0x71023d16 in handle_sequence () from /usr/lib/php/20180731/yaml.so
#3 0x7102329b in handle_document () from /usr/lib/php/20180731/yaml.so
#4 0x7102350f in php_yaml_read_partial () from
/usr/lib/php/20180731/yaml.so
#5 0x71022983 in ?? () from /usr/lib/php/20180731/yaml.so
#6 0x74d598d5 in xdebug_execute_internal
(current_execute_data=0x74a1c0a0, return_value=0x7fffc868)
at ./build-7.3/xdebug.c:1977
#7 0x55651f16 in ?? ()
#8 0x5587ab67 in execute_ex ()
#9 0x74d58f03 in xdebug_execute_ex
(execute_data=0x74a1c030) at ./build-7.3/xdebug.c:1868
#10 0x55881097 in zend_execute ()
#11 0x557ed017 in zend_eval_stringl ()
#12 0x557ed0f9 in zend_eval_stringl_ex ()
#13 0x55883212 in ?? ()
#14 0x5566184f in ?? ()
#15 0x7703a09b in __libc_start_main (main=0x556613c0,
argc=3, argv=0x7fffe128, init=,
fini=, rtld_fini=,
stack_end=0x7fffe118) at ../csu/libc-start.c:308
#16 0x5566194a in _start ()
(gdb) quit
A file that does not use this syntax does not exhibit the issue, eg:
- foo: bar
There are similarities between this crash and an upstream bug which is
reportedly fixed in 1.3.2:
- https://bugs.php.net/bug.php?id=74886
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages php-yaml depends on:
ii libapache2-mod-php7.3 [phpapi-20180731] 7.3.1-1
ii libc62.28-5
ii libyaml-0-2 0.2.1-1
ii php-common 2:69
ii php7.3-cli [phpapi-20180731] 7.3.1-1
ii php7.3-phpdbg [phpapi-20180731] 7.3.1-1
php-yaml recommends no packages.
php-yaml suggests no packages.
Bug#920567: Wrong package got selected
control: reassign -1 debconf On Sat, Jan 26, 2019 at 10:24 PM wrote: > > Hi, > > This bug report is associated with package debconf, if I'm not wrong. > I'm comparatively new to using reportbug. So, python3-reportbug package > got selected as the affected package, while it would be debconf package. > Pardon my naivety. > > Thanks. > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#919324: CVE-2018-20450 CVE-2018-20452
On 26 January 2019 at 15:59, Jennifer Bryan wrote:
| I'll still wait a bit to see if libxls can get to an official release soon.
|
| But readxl builds and passes tests everywhere with the current libxls, so
| that's good news:
|
| https://github.com/tidyverse/readxl/pull/543
Nice -- should I fold that into an interim release to address the CVE?
I can then follow-up with real release whenever you push to CRAN.
Dirk
| -- Jenny
|
| On Sat, Jan 26, 2019 at 7:23 AM Evan Miller wrote:
|
| >
| > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel wrote:
| > >
| > >
| > > On 24 January 2019 at 19:54, Evan Miller wrote:
| > > |
| > > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel wrote:
| > > | >
| > > | >
| > > | > On 24 January 2019 at 16:36, Evan Miller wrote:
| > > | > |
| > > | > | > On Jan 23, 2019, at 01:16, Evan Miller
| > wrote:
| > > | > | >
| > > | > | > #34 and #35 have returned from the dead on GitHub. I’ll take a
| > closer look later this week.
| > > | > | >
| > > | > | > Evan
| > > | > |
| > > | > |
| > > | > | OK — I can confirm that all of the reported libxls bugs are fixed.
| > > | >
| > > | > As in: in the current libxls GH version? I can make a patched Debian
| > > | > release of that.
| > > |
| > > | Yes, they are fixed in master on GitHub. Note that there are quite a
| > few changes since 1.4 – I can’t promise that master has ABI compatibility
| > with the last official 1.4 release. But if you compile the new sources
| > using the old headers (or diff and merge manually) I don’t think there will
| > be an issue on that front.
| > >
| > > Maybe Jenny could take a look?
| > >
| > > It is her use of your library in her package that I stand behind for
| > Debian.
| >
| > Ah, okay, then the ABI doesn’t matter. I had assumed you were packaging
| > libxls as a runtime library + development headers.
| >
| > >
| > > Thanks for all your diligent work on this. It is great to see this move
| > in
| > > the right ("fuzzing") direction.
| >
| > Long overdue! :-)
| >
| > Evan
| >
| > >
| > > Dirk
| > >
| > > | Evan
| > > |
| > > | >
| > > | > | I have successfully integrated libxls into OSS-Fuzz, and have
| > added the researcher’s test files to the fuzzing corpus, so that this and
| > related issues should be caught by the address sanitizer in the future.
| > > | > |
| > > | > | OSS-Fuzz has turned up a number of other issues. I will plan to do
| > a release when they are all addressed.
| > > | >
| > > | > That is awesome.
| > > | >
| > > | > Thank you, Dirk
| > > | >
| > > | > | Evan
| > > | > |
| > > | > | >
| > > | > | >> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff > wrote:
| > > | > | >>
| > > | > | >> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel
| > wrote:
| > > | > | >>>
| > > | > | >>> Hi Evan,
| > > | > | >>>
| > > | > | >>> On 15 January 2019 at 11:18, Evan Miller wrote:
| > > | > | >>> |
| > > | > | >>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff <
| > j...@inutil.org > wrote:
| > > | > | >>> | >
| > > | > | >>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller
| > wrote:
| > > | > | >>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have
| > disappeared from GitHub. I don’t know if the original reporter intended to
| > close them, or what.
| > > | > | >>> | >>
| > > | > | >>> | >> I have an email copy of #34 but do not have access to the
| > PoC files. So without the cooperation of the reporter (Zhao Liang, Huawei
| > Weiran Labs) my ability to research will be limited.
| > > | > | >>> | >
| > > | > | >>> | > That's really strange, do you have the mail address of
| > Zhao, could you ask him what happened?
| > > | > | >>> |
| > > | > | >>> | His address may be leon.zha...@gmail.com leon.zha...@gmail.com> - I’ll try it. His GitHub profile is now a 404.
| > > | > | >>> |
| > > | > | >>> | >
| > > | > | >>> | > MITRE doesn't archive security content per se, they only
| > deal with the organisation and assignment
| > > | > | >>> | > of numbers. The Internet Archive's Wayback machine also
| > hasn't archived the Github pages.
| > > | > | >>> | >
| > > | > | >>> | > Cheers,
| > > | > | >>> | >Moritz
| > > | > | >>> |
| > > | > | >>> |
| > > | > | >>> | Here are the Google caches of #34 and #35:
| > > | > | >>> |
| > > | > | >>> |
| >
https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari
| > <
| >
https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari
| > >
| > > | > | >>> |
| > > | > | >>> |
| >
https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari
| > <
| >
https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us
Bug#920568: lintian: false positive command-with-path-in-maintainer-script in debhelper generated code
Package: lintian Version: 2.5.124 Severity: normal Hi, I get false positives for command-with-path-in-maintainer-script in my glx-alternatives package: W: glx-alternative-nvidia: command-with-path-in-maintainer-script postinst:214 /usr/sbin/update-initramfs W: glx-alternative-nvidia: command-with-path-in-maintainer-script postrm:11 /usr/sbin/update-initramfs postinst: #!/bin/sh set -e [...] # Automatically added by dh_installinitramfs/12 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then if [ -x /usr/sbin/update-initramfs ] && [ -e /etc/initramfs-tools/initramfs.conf ]; then update-initramfs -u fi fi # End automatically added section [...] postrm: #!/bin/sh set -e [...] # Automatically added by dh_installinitramfs/12 if [ "$1" = "remove" ]; then if [ -x /usr/sbin/update-initramfs ] && [ -e /etc/initramfs-tools/initramfs.conf ]; then update-initramfs -u fi fi # End automatically added section Andreas
Bug#920567: Wrong package got selected
Hi, This bug report is associated with package debconf, if I'm not wrong. I'm comparatively new to using reportbug. So, python3-reportbug package got selected as the affected package, while it would be debconf package. Pardon my naivety. Thanks.
Bug#920567: bash: dpkg-reconfigure: command not found
Package: python3-reportbug Version: 7.5.1 Severity: normal Tags: d-i Hi, I got the message "bash: dpkg-reconfigure: command not found " when I ran `dpkg-reconfigure fontconfig-config`. I ran this command as root. I then ran `echo $PATH` and the following appeared "/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games". I searched for solution online and came to know that dpkg-reconfigure is in /usr/sbin. So I added /usr/sbin in $PATH to .bashrc file. I rebooted the system and now `dpkg- reconfigure fontconfig-config` works. As the process described here worked, is this the right process or I missed something? Thanks. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-reportbug depends on: ii apt1.8.0~beta1 ii file 1:5.35-2 ii python33.7.1-3 ii python3-apt1.7.0 ii python3-debian 0.1.34 ii python3-debianbts 2.8.2 ii python3-requests 2.20.0-2 python3-reportbug recommends no packages. Versions of packages python3-reportbug suggests: ii reportbug 7.5.1 -- no debconf information
Bug#920566: ITP: radicale-auth-pam -- PAM authentication plugin for Radicale
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: radicale-auth-pam Version : 0.2 Upstream Author : Joseph Nahmias * URL : https://gitlab.com/jello/radicale_auth_PAM * License : GPL3 Programming Lang: Python Description : PAM authentication plugin for Radicale
Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init
Hi, I manage to reproduce this with systemd, in a Virtualbox VM. here are the steps, after booting with systemd as init * stop udev # systemctl stop systemd-udevd make sure there is no 'systemd-udevd' process list in pstree * start udev in background like this # setsid --fork /lib/systemd/systemd-udevd OR like this # start-stop-daemon --start --name systemd-udevd --exec /lib/systemd/systemd-udevd --background in any case make sure udedv is running * try one of the following (wait few seconds after prompt) # udevadm trigger --type=subsystems action=add # udevadm trigger --type=devices action=add # udevadm settle As a result all process belonging to you session are crashed and restarted; if you are doing this in a VT you get kicked out and the screen is cleared; if you are doing this in a graphical session you get the login screen of your display manager (I use slim + lxqt ). This is a bit different from what happens when init is not systemd, in that i belive systemd-logind is constraining the killing within the session ( or the slice), but ... Final Bonus Weirdness: if you start udevd in background in the VT session, then go to the graphic session and prompt a udevadm command from there, it's the VT session that get crashed. This was introduced in commit e803efca https://salsa.debian.org/systemd-team/systemd/commit/e803efca59978aa5bb1d8806247f986d0c0f7e67 when udevd is run in background and it's not detached with it's own '--daemonize' option, then a udevadm command is enough to kill everything. The commits uses 'start-stop-daemon' with '--background' option, so it triggered a bug that was already in the code since who-knows-when.. i can reproduce this also with another VM (stretch) that has systemd 232-25. Non-Systemd users can workaround this by using the init script from systemd 239-7 https://salsa.debian.org/systemd-team/systemd/blob/debian/239-7/debian/udev.init or by editing the current init script replacing the --background option with ' -- --daemonize". (some other adjustments are nedded to the script) Be aware that in both case this will reintroduce bug #791944 Dear Systemd Maintainers, still you can't reproduce this? Can you please say something? Lorenz Il giorno gio 24 gen 2019 alle ore 08:36 Gedalya ha scritto: > Hi, > > With the help of snapshot.d.o, I've found that the problem first appeared > in 239-8. > > I've also been able to trigger it by restarting udev and running 'udevadm > control --log-priority=debug'. > > Still no insight on what is the factor causing this to happen on some > machines and not on others. > > Regards, > > Gedalya > > >
Bug#920565: certbot modifies /etc/letsencrypt everytime certbot is executed.
Package: certbot Version: 0.10.2-1 When invoking 'certbot', with or without arguments, the directory timestamp of /etc/letsencrypt is modified. This is new behavior as of v0.10.2-1. It is recommended (citation needed!) to not modify files/dirs in /etc/ every time a cmd is executed, rather only when config files are modified. Debian/Stretch Linux host 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
Bug#920564: Unknown configuration: password_expiration, show_vacation and show_disabled
Package: Postfixadmin
Version: 3.2.1-1
Severity: minor
Tags: patch fixed-upstream upstream
Dear maintainer!
There are new bugs introduced with 3.2.1...
* Issue 235:
https://github.com/postfixadmin/postfixadmin/issues/235#issuecomment-456551448
* Patch 1:
https://github.com/postfixadmin/postfixadmin/commit/d9326a1f38bf0ffe33e627fada9df71e0a00cc17.patch
* Patch 2:
https://github.com/postfixadmin/postfixadmin/commit/477ede0175abb100889bcc594ee95885503aa5a2.patch
It would be great if you could add a patch for this issue before Buster
release. I've attached an alternative patch which fixes all mentioned
errors, use whatever you prefer.
--
With kind regards,
Christian Schrötter
--- a/functions.inc.php 2019-01-12 21:46:34.0 +0100
+++ b/functions.inc.php 2019-01-24 01:44:34.971950615 +0100
@@ -2137,42 +2137,6 @@ function gen_show_status($show_alias) {
}
}
-// Vacation CHECK
-if ( $CONF['show_vacation'] == 'YES' ) {
-$stat_result = db_query("SELECT * FROM ". $CONF['database_tables']['vacation'] ." WHERE email = '" . $show_alias . "' AND active = '" . db_get_boolean(true) . "'") ;
-if ($stat_result['rows'] == 1) {
-$stat_string .= "" . $CONF['show_status_text'] . " ";
-} else {
-$stat_string .= $CONF['show_status_text'] . " ";
-}
-}
-
-// Disabled CHECK
-if ( $CONF['show_disabled'] == 'YES' ) {
-$stat_result = db_query("SELECT * FROM ". $CONF['database_tables']['mailbox'] ." WHERE username = '" . $show_alias . "' AND active = '" . db_get_boolean(false) . "'");
-if ($stat_result['rows'] == 1) {
-$stat_string .= "" . $CONF['show_status_text'] . " ";
-} else {
-$stat_string .= $CONF['show_status_text'] . " ";
-}
-}
-
-// Expired CHECK
-if ( Config::bool('password_expiration') && Config::bool('show_expired') ) {
-$now = 'now()';
-if (db_sqlite()) {
-$now = "datetime('now')";
-}
-
-$stat_result = db_query("SELECT * FROM ". $CONF['database_tables']['mailbox'] ." WHERE username = '" . $show_alias . "' AND password_expiry <= $now AND active = '" . db_get_boolean(true) . "'");
-
-if ($stat_result['rows'] == 1) {
-$stat_string .= "" . $CONF['show_status_text'] . " ";
-} else {
-$stat_string .= $CONF['show_status_text'] . " ";
-}
-}
-
// POP/IMAP CHECK
if ($CONF['show_popimap'] == 'YES') {
$stat_delimiter = "";
Bug#911921: yubikey-manager new upstream version
Hello, Is anyone about to update this package or is any help needed? The current upstream version is now 2.0.0. regards Afif -- Afif Elghraoui | عفيف الغراوي https://afif.ghraoui.name
Bug#920563: dracut: fails to boot with bash 5 as /bin/sh
Package: dracut
Version: 048+80-1
Severity: important
Dear Maintainer,
When generating an initrd with bash 5.0-2 installed, the generated initrd
fails to boot with the error message:
> /lib/fs-lib.sh: line 109: _drv=e2fsck fsck_drv_com
The behaviour of "local" declared variables in POSIX mode seems to have
changed, which does no longer allow them to be overwritten by eval. This
is only the case if bash is executed as /bin/sh. Since "local" is not a
part of POSIX, I consider this to be dracut's fault and not bash's.
I wrote a small shell script (a reduced version of fs-lib.sh) to
demonstrates the problem:
#!/bin/sh
fsck_drv_com() {
echo "issuing $_drv"
_out=$($_drv)
}
fsck_single() {
local _drv="_drv=true fsck_drv_com"
eval "$_drv"
}
fsck_single
This works with /bin/bash as interpreter, also with /bin/sh linked to
dash, and it used to work with bash 4.4.18-3.1. It also produces the
correct output without the "local" keyword:
> issuing true
When /bin/sh is a link to bash 5.0-2 the script fails with the following
output:
> issuing _drv=true fsck_drv_com
> /tmp/bash-error.sh: line 5: _drv=true: command not found
I can currently think of three options:
- either dracut has to be rewritten to be fully POSIX-compliant
- dracut has to rely on a shell, that guarantees to enhance POSIX with
the local keyword
- dracut has to make sure /init is executed by /bin/bash when
/bin/sh is a symlink to bash.
The 3rd option could be easily accomplished by adding the following line
to the top of /init (/usr/lib/dracut/modules.d/99base/init.sh) after the
initial comment block:
[ -f /bin/bash ] && [ "$BASH" = "/bin/sh" ] && exec /bin/bash /init
Ingo
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.18-echse20190126 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dracut depends on:
ii dracut-core 048+80-1
dracut recommends no packages.
Versions of packages dracut suggests:
pn dracut-network
-- no debconf information
Bug#920562: ca-certificates-java: postinst fails under qemu-aarch64-static 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) with uncaught target signal 6
Package: ca-certificates-java Version: 20170531+nmu1 Severity: normal Dear Maintainer, We are using qemu-aarch64-static to bootstrap a system from scratch. We use the same method to bootstrap other Ubuntu releases without issue that include the Ubuntu version of this package. We attempted multiple times and it always fails. Setting up ca-certificates-java (20170531+nmu1) ... # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0040012db6c0, pid=14366, # tid=0x004001ad0200 # # JRE version: OpenJDK Runtime Environment (8.0_181-b13) (build # 1.8.0_181-8u181-b13-2~deb9u1-b13) # Java VM: OpenJDK 64-Bit Server VM (25.181-b13 mixed mode linux-aarch64 # compressed oops) # Problematic frame: # V [libjvm.so+0x7ba6c0] # # Failed to write core dump. Core dumps have been disabled. To enable # core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # //hs_err_pid14366.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # qemu: uncaught target signal 6 (Aborted) - core dumped /var/lib/dpkg/info/ca-certificates-java.postinst: line 43: 14364 Done echo -e "-diginotar_root_ca\n-diginotar_root_ca_pem" 14366 Aborted (core dumped) | java -Xmx64m -jar $JAR -storepass "$storepass" dpkg: error processing package ca-certificates-java (--configure): subprocess installed post-installation script returned error exit status 134 Errors were encountered while processing: ca-certificates-java E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 9.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 4.19.18-041918-generic (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages ca-certificates-java depends on: ii ca-certificates 20161130+nmu1+deb9u1 ii default-jre-headless [java7-runtime-headless]2:1.8-58 ii libnss3 2:3.26.2-1.1+deb9u1 ii openjdk-8-jre-headless [java7-runtime-headless] 8u181-b13-2~deb9u1 ca-certificates-java recommends no packages. ca-certificates-java suggests no packages. -- no debconf information
Bug#63995: Fwd: Sicherheitswarnung
-- Gesendet über myMail für Android Weitergeleitete Nachricht Von: Google no-re...@accounts.google.com An: tommi.leip...@gmail.com Datum: Sonntag, 06 Januar 2019, 04:57vorm. +01:00 Betreff: Sicherheitswarnung >*.googlesource.com wurde Zugriff auf Ihr Google-Konto gewährt >tommi.leip...@gmail.com > >Falls Sie keinen Zugriff gewährt haben, sollten Sie diese Aktivität prüfen und >Ihr Konto sichern. >Aktivität prüfen >Wir haben Ihnen diese E-Mail gesendet, um Sie über wichtige Änderungen zu >Ihrem Google-Konto und den Diensten von Google zu informieren. >© 2019 Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA >154674704100
Bug#920561: emacs-common: gnus can't find movemail
Package: emacs-common Version: 1:26.1+1-3 Severity: important Dear Maintainer, After an update in December gnus stopped being able to load mail from my local mail spool. When I finally got around to looking into it (in my case that's not the bulk of my mail) it turned out that the mail-source-movemail function in gnus/mail-source.el checks in exec-directory (/usr/lib/emacs/26.1/x86_64-linux-gnu, on my system) for the movemail executable if mail-source-movemail-program isn't set, rather than the path. movemail isn't there, so that fails with a rather unhelpful message in the minibuffer: Mail source (file :path /var/mail/nowan) error (Searching for program). Continue? (yes or no) It wasn't until I happened to check the messages buffer that I found a more complete message and realized the problem was with movemail. Setting mail-source-movemail-program to "/usr/bin/movemail" restored the expected behavior for me. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs-common depends on: ii emacsen-common 3.0.4 ii install-info6.5.0.dfsg.1-4+b1 Versions of packages emacs-common recommends: ii emacs-el 1:26.1+1-3 Versions of packages emacs-common suggests: pn emacs-common-non-dfsg ii ncurses-term 6.1+20181013-1 -- no debconf information
Bug#918746: pam-ssh-agent-auth alternative
Bálint Réczey writes: > I picked the patch used in Gentoo and FreeBSD to make the package > build again, but it does not resurrect upstream. > > I'd say with this change there is no immediate need for removal, but I > removed myself from uploaders since I did not have enough time to take > care of the package properly and let the final word on removal for the > Security Team. Thank you Bálint! You have done a great job keep it in shape. Yours, Benda
Bug#920560: RM: python-formalchemy -- RoQA; unusable, fails to import in python
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: rm python-formalchemy has not been usable since jessie because it fails to import into python (#896197), but noone noticed. The package has been removed from sid, and since it has no users, let's remove it from stable as well. $ python Python 2.7.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import formalchemy Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/formalchemy/__init__.py", line 9, in from formalchemy.tables import * File "/usr/lib/python2.7/dist-packages/formalchemy/tables.py", line 9, in from formalchemy.forms import FieldSet File "/usr/lib/python2.7/dist-packages/formalchemy/forms.py", line 42, in from formalchemy import fields File "/usr/lib/python2.7/dist-packages/formalchemy/fields.py", line 21, in from sqlalchemy import exceptions as sqlalchemy_exceptions ImportError: cannot import name exceptions anbe@coccia:~$ dak rm -Rn -s stable python-formalchemy Will remove the following packages from stable: python-formalchemy |1.4.2-1 | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x Maintainer: Shell Xu --- Reason --- -- Checking reverse dependencies... No dependency problem found. Andreas
Bug#920559: python-sqlalchemy: please add Breaks: python-formalchemy (<< 1.4.2-2)
Package: python-sqlalchemy Version: 0.9.8+dfsg-0.1 Severity: important In response to #896197 (python-formalchemy fails to import into python since jessie), which is caused by the renaming of 'sqlalchemy.exceptions' to 'sqlalchemy.exc', please add Breaks: python-formalchemy (<< 1.4.2-2) to python-sqlalchemy to ensure the unusable python-formalchemy package gets removed eventually. It is no longer available in sid, but may remain in systems upgraded from stretch or older. Thanks Andreas
Bug#920558: RFS: liboauth/1.0.3-2 [QA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "liboauth" * Package name: liboauth Version : 1.0.3-2 Upstream Author : Robin Gareus * URL : http://liboauth.sourceforge.net/ * License : Expat Section : libs It builds these binary packages: liboauth-dev - C library implementing OAuth Core 1.0a API (development files) liboauth0 - C library implementing OAuth Core 1.0a API (runtime) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/liboauth Alternatively, one can download the package with dget using this command: dget -ux https://mentors.debian.net/debian/pool/main/libo/liboauth/liboauth_1.0.3-2.dsc My changes have also been temporarily pushed to https://salsa.debian.org/e7appew-guest/liboauth.git. Changes since the last upload: * QA upload. * Update debian/gbp.conf to conform with DEP14 conventions. * Update VCS details. * Simplify LFS build rules. * Build verbosely. * Update Lintian override to use debian-watch-does-not-check-gpg-signature tag. * Build with Debhelper compat level 12. * Set "Rules-Requires-Root: no". * Add Build-Depends-Package details to symbols file. * Update debian/copyright. * Add machine-readable upstream metadata. * Update debian/watch. * Replace 03_man_page_typos.patch with 03_fix_typos.patch to fix more typos detected. * Indicate that the patches that I have personally authored have been forwarded upstream. * Indicate compliance with Debian Policy 4.3.0. Regards, Carlos Maddela
Bug#919324: CVE-2018-20450 CVE-2018-20452
I'll still wait a bit to see if libxls can get to an official release soon.
But readxl builds and passes tests everywhere with the current libxls, so
that's good news:
https://github.com/tidyverse/readxl/pull/543
-- Jenny
On Sat, Jan 26, 2019 at 7:23 AM Evan Miller wrote:
>
> > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel wrote:
> >
> >
> > On 24 January 2019 at 19:54, Evan Miller wrote:
> > |
> > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel wrote:
> > | >
> > | >
> > | > On 24 January 2019 at 16:36, Evan Miller wrote:
> > | > |
> > | > | > On Jan 23, 2019, at 01:16, Evan Miller
> wrote:
> > | > | >
> > | > | > #34 and #35 have returned from the dead on GitHub. I’ll take a
> closer look later this week.
> > | > | >
> > | > | > Evan
> > | > |
> > | > |
> > | > | OK — I can confirm that all of the reported libxls bugs are fixed.
> > | >
> > | > As in: in the current libxls GH version? I can make a patched Debian
> > | > release of that.
> > |
> > | Yes, they are fixed in master on GitHub. Note that there are quite a
> few changes since 1.4 – I can’t promise that master has ABI compatibility
> with the last official 1.4 release. But if you compile the new sources
> using the old headers (or diff and merge manually) I don’t think there will
> be an issue on that front.
> >
> > Maybe Jenny could take a look?
> >
> > It is her use of your library in her package that I stand behind for
> Debian.
>
> Ah, okay, then the ABI doesn’t matter. I had assumed you were packaging
> libxls as a runtime library + development headers.
>
> >
> > Thanks for all your diligent work on this. It is great to see this move
> in
> > the right ("fuzzing") direction.
>
> Long overdue! :-)
>
> Evan
>
> >
> > Dirk
> >
> > | Evan
> > |
> > | >
> > | > | I have successfully integrated libxls into OSS-Fuzz, and have
> added the researcher’s test files to the fuzzing corpus, so that this and
> related issues should be caught by the address sanitizer in the future.
> > | > |
> > | > | OSS-Fuzz has turned up a number of other issues. I will plan to do
> a release when they are all addressed.
> > | >
> > | > That is awesome.
> > | >
> > | > Thank you, Dirk
> > | >
> > | > | Evan
> > | > |
> > | > | >
> > | > | >> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff > wrote:
> > | > | >>
> > | > | >> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel
> wrote:
> > | > | >>>
> > | > | >>> Hi Evan,
> > | > | >>>
> > | > | >>> On 15 January 2019 at 11:18, Evan Miller wrote:
> > | > | >>> |
> > | > | >>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff <
> j...@inutil.org > wrote:
> > | > | >>> | >
> > | > | >>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller
> wrote:
> > | > | >>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have
> disappeared from GitHub. I don’t know if the original reporter intended to
> close them, or what.
> > | > | >>> | >>
> > | > | >>> | >> I have an email copy of #34 but do not have access to the
> PoC files. So without the cooperation of the reporter (Zhao Liang, Huawei
> Weiran Labs) my ability to research will be limited.
> > | > | >>> | >
> > | > | >>> | > That's really strange, do you have the mail address of
> Zhao, could you ask him what happened?
> > | > | >>> |
> > | > | >>> | His address may be leon.zha...@gmail.com leon.zha...@gmail.com> - I’ll try it. His GitHub profile is now a 404.
> > | > | >>> |
> > | > | >>> | >
> > | > | >>> | > MITRE doesn't archive security content per se, they only
> deal with the organisation and assignment
> > | > | >>> | > of numbers. The Internet Archive's Wayback machine also
> hasn't archived the Github pages.
> > | > | >>> | >
> > | > | >>> | > Cheers,
> > | > | >>> | >Moritz
> > | > | >>> |
> > | > | >>> |
> > | > | >>> | Here are the Google caches of #34 and #35:
> > | > | >>> |
> > | > | >>> |
> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari
> <
> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari
> >
> > | > | >>> |
> > | > | >>> |
> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari
> <
> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari
> >
> > | > | >>> |
> > | > | >>> | The PoC links are dead.
> > | > | >>> |
> > | > | >>> | Looking at the backtraces and the commit fixing #36 and #37 (
> https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e
> <
> https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e>)
> it is my belief that issues #34 and #35 are NOT fixed.
> > | > | >>> |
> > | > | >>> | I’ll look into the
Bug#888026:
Stop
Bug#920557: lua-cosmo: lua5.3 support
Package: lua-cosmo Version: 13.01.30-2 Please add lua5.3 support
Bug#920556: lua-md5: lua5.3 support
Source: lua-md5 Version: 1.2+git+1+8d87fee-1.1 Severity: normal It looks to me like lua5.3 support can be added by making symlinks for lua5.3.des56.dh-lua.conf and lua5.3.md5.dh-lua.conf. Is there any reason not to do this?
Bug#920460: nautilus: org.freedesktop.FileManager1.service conflict
> Until now, Nautilus was the only package providing this, Seems like dolphin as well provides the service in "org.kde.dolphin.FileManager1.service". That's why I thought renaming would be sufficient. For the concrete packaging of thunar 1.8.3: Arch solved it like that: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/thunar&id=c8928f211dbe01f9a3ba03bdc4b894cb3381d03e But today this one popped up: https://bugzilla.xfce.org/show_bug.cgi?id=15088 So I wonder if it possibly would be the safest to revert the related thunar commit ( c06074065460e63cf78ef1c5b7eb819fa6a86430 ) At least until it is clear which way to go.
Bug#920555: xmobar: compile flag with_alsa to support Volume command
Package: xmobar Version: 0.29.4-2 Severity: wishlist Are we able to get xmobar to compile with flag `with_alsa` to as needed by the Volume command? ref https://github.com/jaor/xmobar/issues/344 PS. I did try to submit a Merge Request on the Debian GitLab, but it gave me a 500 error when trying to fork the project. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64)
Bug#919370: deal.ii: FTBFS on s390x: p4est.debug test fails
Control: severity -1 normal On Tue, 15 Jan 2019 12:22:30 +0200 Graham Inggs wrote: > Recent rebuilds of deal.ii on s390x have been failing with the following > errors: deal.ii has been removed from s390x, downgrading the severity. Andreas
Bug#914150: pcmanfm: SIGSEGV, Segmentation fault on opening folder
Sure, I will do that. Il giorno sab 26 gen 2019, 23:42 Andriy Grytsenko ha scritto: > >Thread 30 (Thread 0x7f681634a700 (LWP 24728)): > >#0 0x7f6816c292c0 in () > >at > > >/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so > >#1 0x7f682029812d in () > >at /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 > >#2 0x7f6820298bd8 in gdk_pixbuf_loader_write () > >at /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 > >#3 0x7f6820296668 in gdk_pixbuf_get_file_info () > >at /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 > >#4 0x7f682095da06 in read_image_from_file > >(filename=0x7f680c001570 > >"/mnt/dati_linux/cns-doc/REGATE/RegateDOC/meteoCNS") at > >gtk/fm-thumbnail.c:142 > >w = 1 > >h = 1 > > Apparently this is a bug in gdk_pixbuf_get_file_info() function which > crashes reading your file /mnt/dati_linux/cns-doc/REGATE/RegateDOC/meteoCNS > That function is a part of package libgdk-pixbuf2.0-0. Could you try some > another version of that package, please, to check if this issue will be > fixed or not? Thank you. >
Bug#920018: Anyone?
Anyone? This is an extremely serious bug, AND there is a published fix for it.
Bug#920531: marked as done (libmono-system-native.so missing)
Whoops directhex@bubblegum:~/Projects/pkg-mono/mono$ git push origin master Counting objects: 15, done. Delta compression using up to 12 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (15/15), 1.71 KiB | 1.71 MiB/s, done. Total 15 (delta 11), reused 0 (delta 0) To salsa.debian.org:dotnet-team/mono.git 511ad1dddbe..731b958411d master -> master directhex@bubblegum:~/Projects/pkg-mono/mono$ git push origin debian/5.18.0.240+dfsg-2 Counting objects: 1, done. Writing objects: 100% (1/1), 187 bytes | 187.00 KiB/s, done. Total 1 (delta 0), reused 0 (delta 0) To salsa.debian.org:dotnet-team/mono.git * [new tag] debian/5.18.0.240+dfsg-2 -> debian/5.18.0.240+dfsg-2 It's there now On 26/01/2019 18:00, Paul Hebble wrote: > The link to the Homebrew issue in my previous email was incorrect, it should > be: > https://github.com/KSP-CKAN/CKAN/issues/2630 > I'm sorry for the confusion. >
Bug#918858: python-meep-*: fails to install: Exception: cannot get content of python-meep
Followup-For: Bug #918858 Looking at the maintainer scripts, they all seem to have been copied from the python-meep package without updating the referenced package name from "python-meep" to "python-meep-?" Instead of hardcoding the package name, you could also use "$DPKG_MAINTSCRIPT_PACKAGE" which is set by dpkg when running maintainer scripts. Andreas
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Robert Schindler, le dim. 27 janv. 2019 00:06:08 +0100, a ecrit: > But GNOME now uses Wayland by default. So the only solution > is disabling Wayland and switching back to Xorg, right? Yes. Wayland is really bringing many accessibility issues anyway. > Is there any replacement for xkbcomp under Wayland that Orca could > use instead to manipulate the keyboard? I don't know. And that's just one of the items on the list of things to be fixed for orca on Wayland. > Or is Xorg going to be a requirement for Orca users for the > foreseeable future? It is. Samuel
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Samuel Thibault wrote: > AIUI gnome is pushing to wayland... Disabled it via /etc/gdm3/daemon.conf. What a relief! Thank you very much for sorting this out with me. So to conclude this: Orca needs xkbcomp, which doesn't work under Wayland at all, as well as xmodmap etc. But GNOME now uses Wayland by default. So the only solution is disabling Wayland and switching back to Xorg, right? Is there any replacement for xkbcomp under Wayland that Orca could use instead to manipulate the keyboard? Or is Xorg going to be a requirement for Orca users for the foreseeable future? Best regards Robert signature.asc Description: PGP signature
Bug#919417: orca: Orca reads character by character when holding navigation keys pressed
Hello, After disabling Wayland, this one is resolved as well! Although I can't tell why. Best regards Robert signature.asc Description: PGP signature
Bug#918260: ruby-protected-attributes: Depends: ruby-activemodel (< 2:5.0) but 2:5.2.0+dfsg-2 is to be installed
Control: affects -1 redmine If I understood this right, this Gem provides extra functionality for ruby-rails, and is obsolete with rails 5.0 Problems: - rails is not migrated to testing yet - Autoremoval logic seems to want to remove way more packages than actually affected - redmine is the actual dependency as it seems Redmine (from its Gemfile) actually no longer mentions "protected_attibutes". Suggestion: Update redmine dependencies Still a problem: Why dependency resolver wants to remove seemingly unrelated packages? Anything I can help with? Cheers Markus Frosch Note from https://tracker.debian.org/pkg/ruby-protected-attributes: Version 1.1.4-2 of ruby-protected-attributes is marked for autoremoval from testing on Sun 17 Feb 2019. It is affected by #918260. The removal of ruby-protected-attributes will also cause the removal of (transitive) reverse dependencies: coquelicot, librarian-puppet, r10k, redmine, redmine-plugin-custom-css, redmine-plugin-local-avatars, redmine-plugin-pretend, ruby-fast-gettext, ruby-gettext-i18n-rails, ruby-gettext-i18n-rails-js, ruby-gettext-setup, ruby-haml-magic-translations, ruby-puppet-forge, samizdat. You should try to prevent the removal by fixing these RC bugs. -- mar...@lazyfrosch.de / lazyfro...@debian.org https://lazyfrosch.de signature.asc Description: OpenPGP digital signature
Bug#920531: marked as done (libmono-system-native.so missing)
The link to the Homebrew issue in my previous email was incorrect, it should be: https://github.com/KSP-CKAN/CKAN/issues/2630 I'm sorry for the confusion.
Bug#920531: marked as done (libmono-system-native.so missing)
Hi Jo, Thanks for the quick action on this! I'd like to understand the cause and fix to advise other third party packagers with similar problems (specifically the Homebrew project, https://github.com/KSP-CKAN/CKAN/issues/2664). I have been browsing Debian's source control and tried cloning https://salsa.debian.org/dotnet-team/mono to try to view commit fcb8084 so I could see what has changed, but I have not been able to find it. Is there a way that I can see what the fix for this bug looks like? Thanks for any tips!
Bug#870448: hw-detect - stop using modprobe -l
Control: tags -1 + pending
Holger Wansing wrote:
> Hi,
>
> Vincent McIntyre wrote:
> > On Wed, Aug 02, 2017 at 07:58:05PM +0100, Ben Hutchings wrote:
> > > On Wed, 2017-08-02 at 12:26 +1000, Vincent McIntyre wrote:
> > > > Package: hw-detect
> > > > Version: 1.124
> > > > Severity: normal
> > > > Tags: patch
> > > >
> > > > I keep seeing this in installer logs, back to jessie.
> > > >
> > > > Aug 2 01:52:11 main-menu[193]: (process:224): modprobe: invalid option
> > > > -- 'l'
> > > >
> > > >
> > > > I rated this normal rather than minor because the way it is working
> > > > now the is_available() function always returns 1 (failure)
> > > >
> > > > My suggestion is to use modinfo instead.
> > > > This will return multiline output inside the quotes but
> > > > a couple of tests suggests that is ok.
> > > > It does fail with some modules (nvidia), not sure if we care.
> > > >
> > > > diff --git a/hw-detect.sh b/hw-detect.sh
> > > > index 7977814..d8196c1 100755
> > > > --- a/hw-detect.sh
> > > > +++ b/hw-detect.sh
> > > > @@ -43,7 +43,7 @@ is_not_loaded() {
> > > > }
> > > >
> > > > is_available () {
> > > > - [ "$(modprobe -l $1)" ] || return 1
> > > > + [ "$(modinfo $1)" ] || return 1
> > > > }
> > >
> > > But this still prints error messages for missing modules. I think the
> > > function should be implemented as:
> > >
> > > is_available () {
> > > modprobe -qn "$1"
> > > }
> > >
> >
> > That seems much better, can someone please apply Ben's version?
> > Thanks for tickling this Holger.
>
> Any objections against this?
I've just committed this.
Tagging this bug as pending.
Holger
--
Holger Wansing
PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Robert Schindler, le sam. 26 janv. 2019 23:41:26 +0100, a ecrit: > Samuel Thibault wrote: > > Yes but setxkbmap is saying otherwise, so I believe gnome is somehow > > getting in the way. > > > > BTW, this isn't running under Wayland, is it perhaps? There are a lot > > of issues with it. > > It seems to... > > -- BEGIN -- > # ps aux|grep -i wayland > roschi1558 0.0 0.0 162324 528 tty2 Ssl+ Jan20 0:00 > /usr/lib/gdm3/gdm-wayland-session /usr/bin/gnome-session > roschi1625 0.0 1.6 561508 66440 tty2 Sl+ Jan20 6:17 > /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen 5 > -displayfd 6 > # env | grep -i wayland > WAYLAND_DISPLAY=wayland-0 > XDG_SESSION_TYPE=wayland > -- END -- > > But it must have switched to wayland automatically during upgrade from > stable to testing. Was that intended? AIUI gnome is pushing to wayland... Samuel
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Samuel Thibault wrote: > Yes but setxkbmap is saying otherwise, so I believe gnome is somehow > getting in the way. > > BTW, this isn't running under Wayland, is it perhaps? There are a lot > of issues with it. It seems to... -- BEGIN -- # ps aux|grep -i wayland roschi1558 0.0 0.0 162324 528 tty2 Ssl+ Jan20 0:00 /usr/lib/gdm3/gdm-wayland-session /usr/bin/gnome-session roschi1625 0.0 1.6 561508 66440 tty2 Sl+ Jan20 6:17 /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen 5 -displayfd 6 # env | grep -i wayland WAYLAND_DISPLAY=wayland-0 XDG_SESSION_TYPE=wayland -- END -- But it must have switched to wayland automatically during upgrade from stable to testing. Was that intended? Best regards Robert signature.asc Description: PGP signature
Bug#914150: pcmanfm: SIGSEGV, Segmentation fault on opening folder
>Thread 30 (Thread 0x7f681634a700 (LWP 24728)): >#0 0x7f6816c292c0 in () > at >/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so >#1 0x7f682029812d in () > at /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 >#2 0x7f6820298bd8 in gdk_pixbuf_loader_write () > at /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 >#3 0x7f6820296668 in gdk_pixbuf_get_file_info () > at /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 >#4 0x7f682095da06 in read_image_from_file > (filename=0x7f680c001570 >"/mnt/dati_linux/cns-doc/REGATE/RegateDOC/meteoCNS") at >gtk/fm-thumbnail.c:142 > w = 1 > h = 1 Apparently this is a bug in gdk_pixbuf_get_file_info() function which crashes reading your file /mnt/dati_linux/cns-doc/REGATE/RegateDOC/meteoCNS That function is a part of package libgdk-pixbuf2.0-0. Could you try some another version of that package, please, to check if this issue will be fixed or not? Thank you.
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Robert Schindler, le sam. 26 janv. 2019 23:30:48 +0100, a ecrit: > Samuel Thibault wrote: > > And is your keyboard layout really US as reported by setxkbmap? > > No, it's German as shown in /etc/default/keyboard, Yes but setxkbmap is saying otherwise, so I believe gnome is somehow getting in the way. BTW, this isn't running under Wayland, is it perhaps? There are a lot of issues with it. Samuel
Bug#920554: unixodbc-bin: Binaries listed in description don't match binaries provided
Package: unixodbc-bin Version: 2.3.0-4+b1 Severity: important Dear Maintainer, First of all, THANK YOU, for maintaining this package! Now, the problem: The package description lists three binaries that are to be included with the package, ODBCConfig, DataManager, and odbctest. However, none of these binaries are actually included. Also, the package does provide binaries ODBCCreateDataSourceQ4, and ODBCManageDataSourcesQ4. However, these are not mentioned in the package description. Please provide the ODBCConfig, DataManager and odbctest binaries in this package; and, please update the description to indicate that the package also provides ODBCCreateDataSourceQ4 and ODBCManageDataSourcesQ4. Thanks again! Gene -- System Information: Debian Release: 9.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages unixodbc-bin depends on: ii libc6 2.24-11+deb9u3 ii libgcc11:6.3.0-18+deb9u1 ii libodbc1 2.3.4-1 ii libodbcinstq4-12.3.0-4+b1 ii libqt4-network 4:4.8.7+dfsg-11 ii libqtassistantclient4 4.6.3-7+b1 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui4 4:4.8.7+dfsg-11 ii libstdc++6 6.3.0-18+deb9u1 ii odbcinst1debian2 2.3.4-1 unixodbc-bin recommends no packages. unixodbc-bin suggests no packages. -- no debconf information
Bug#810068: Some fonts are missing in the default install (verdana, ...)
Control: reassign -1 gnome Florent Le Saout wrote: >* What led up to the situation? I installed basic Debian testing from > netinstall > Then I installed gnome3, icedove and iceweasel and others. On some pages > or email > some text are replaced by square, for instance on gitlab. (I have screen > capture if needed) >* What exactly did you do (or not do) that was effective (or > ineffective)? I installed fonts-arkpandora which contains font > replacement for verdana, arial, etc.. >* What was the outcome of this action? It fixes the issue >* What outcome did you expect instead? >* Fix proposal : I propose that this package package or similar becomes a > dependency of any window manager Re-assigning to gnome, since those people might know which fonts are installed or needed for Gnome, and which not. Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Samuel Thibault wrote: > And is your keyboard layout really US as reported by setxkbmap? No, it's German as shown in /etc/default/keyboard, but I didn't set that manually anywhere after initial Debian installation. Best regards Robert signature.asc Description: PGP signature
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Robert Schindler, le sam. 26 janv. 2019 23:17:09 +0100, a ecrit: > Samuel Thibault wrote: > > Uh, these do not match. Which desktop are you using? Is that perhaps > > tinkering with the keyboard configuration? > > Hmm, I'm using GNOME 3 (gnome-shell) with gdm, as installed by > task-gnome-desktop. And is your keyboard layout really US as reported by setxkbmap? Samuel
Bug#920553: pkg-config: Undefined subroutine &main::warning called at /usr/share/pkg-config-dpkghook line 34.
Package: pkg-config Version: 0.29-5 Severity: serious pkg-config fails to upgrade on two machines (1x amd64 with i386 as foreign architecture, 1x pure i386) as follows for me: Setting up pkg-config (0.29-5) ... Undefined subroutine &main::warning called at /usr/share/pkg-config-dpkghook line 34. dpkg: error processing package pkg-config (--configure): installed pkg-config package post-installation script subprocess returned error exit status 255 Errors were encountered while processing: pkg-config In both cases the error message looks identical. It does though not happen on all of my sid machines, including other amd64 machines. Maybe a missing dependency on some Perl module or so? -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages pkg-config depends on: ii libc6 2.28-5 ii libdpkg-perl 1.19.4 ii libglib2.0-0 2.58.2-4 pkg-config recommends no packages. Versions of packages pkg-config suggests: ii dpkg-dev 1.19.4 -- no debconf information
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Samuel Thibault wrote: > Uh, these do not match. Which desktop are you using? Is that perhaps > tinkering with the keyboard configuration? Hmm, I'm using GNOME 3 (gnome-shell) with gdm, as installed by task-gnome-desktop. Best regards Robert signature.asc Description: PGP signature
Bug#915584: dicoweb: fails to install with python 3.7
On 2018-12-17 04:48, أحمد المحمودي wrote: > On Wed, Dec 05, 2018 at 03:15:59AM +0100, Andreas Beckmann wrote: >> Setting up python3 (3.7.1-2) ... >> [Errno 2] No such file or directory: '/usr/share/dicoweb/settings.py' > ---end quoted text--- > > '/usr/share/dicoweb/settings.py' is a symlink to > /etc/dicoweb/settings.py , could this be the cause of the problem ? If > so, what should be done? I think I now understood what is happening here. Both python3 and dicoweb are being installed in the same run. At the time python3 gets configured, dicoweb is already unpacked, but not yet configured and therefore /etc/dicoweb/settings.py does not yet exist (dpkg has only unpacked it as /etc/dicoweb/settings.py.dpkg-new). As part of the python3 configuration step the rtupdate hook is being run ... and explodes while accessing the dangling symlink. You should probably ask the python maintainers for help, since you are exploiting a corner case in their packaging helpers ... Andreas
Bug#920552: procps: Enable regular file and FIFO protection
Package: procps Version: 2:3.3.15-2 Severity: normal In analogy with bug #889098, procps should by default enabling the regular file and FIFO protection added in 4.19 by setting: fs.protected_regular = 1 fs.protected_fifos = 1 This will be done by default in systemd 241, but as Debian does not use Systemd's sysctl settings, it should be made in procps. References: https://github.com/torvalds/linux/commit/30aba6656f https://github.com/systemd/systemd/commit/2732587540035227fe59e4b64b60127352611b35 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889098 -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (400, 'unstable'), (250, 'stable'), (160, 'experimental'), (100, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages procps depends on: ii init-system-helpers 1.56+nmu1 ii libc62.28-5 ii libncurses6 6.1+20181013-1 ii libncursesw6 6.1+20181013-1 ii libprocps7 2:3.3.15-2 ii libtinfo66.1+20181013-1 ii lsb-base 10.2018112800 Versions of packages procps recommends: ii psmisc 23.2-1 procps suggests no packages. -- no debconf information
Bug#920551: RM: yade [mips mips64el mipsel] -- ROM; Some archs are to weak for this package
Package: ftp.debian.org Severity: normal Dear FTP team, please remove yade on mips mips64el mipsel. It fails to build often on those archs. I do not think that somebody uses this simulation package there. Thanks Anton Gladky
Bug#920538: [Pkg-javascript-devel] Bug#920538: node-date-now: flaky autopkgtest as it times out sometimes
Le sam. 26 janv. 2019 à 20:15, Paul Gevers a écrit : > ../.. > ok 6 should be truthy > > 1..6 > # tests 6 > # pass 4 > # fail 2 > > autopkgtest [14:34:45]: test command1: ---] > It's not a test timeout, but the test is flaky indeed. Trying to fix it. Jérémy
Bug#920545: python-intervaltree breaks python-intervaltree-bio autopkgtest
control: tag -1 patch * Paul Gevers: > With a recent upload of python-intervaltree the autopkgtest of > python-intervaltree-bio fails in testing when that autopkgtest is run > with the binary packages of python-intervaltree from unstable. It passes > when run with only packages from testing. In tabular form: > passfail > python-intervaltree from testing3.0.2-1 > python-intervaltree-bio from testing1.0.1-2 > all others from testingfrom testing Oops, my fault, sorry about that. And hooray for autopkgtests, I guess. Apparently, the .search() method was removed in intervaltree-3.0. Replacing all instances of .search(B,E) with .overlap(B,E) in the intervalltree-bio test code makes the tests pass once more. Here's a patch. Cheers, -Hilko >From 1fef621d6ec368fbd51f82eecbf98376b69055d4 Mon Sep 17 00:00:00 2001 From: Hilko Bengen Date: Sat, 26 Jan 2019 22:56:49 +0100 Subject: [PATCH] Replace all .search() calls with .overlap() in tests and documentation --- README.rst | 2 +- intervaltree_bio/__init__.py | 10 +- tests/genomeintervaltree_test.py | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/README.rst b/README.rst index b0f249f..b5ee422 100644 --- a/README.rst +++ b/README.rst @@ -34,7 +34,7 @@ The core example is loading the transcription regions of the ``knownGene`` table It is then possible to use the data structure to search known genes within given intervals:: ->> result = knownGene[b'chr1'].search(10, 138529) +>> result = knownGene[b'chr1'].overlap(10, 138529) It is possible to load other UCSC tables besides ``knownGene`` or specify custom URL or file to read the table from. Consult the docstring of the ``GenomeIntervalTree.from_table`` method for more details. diff --git a/intervaltree_bio/__init__.py b/intervaltree_bio/__init__.py index 083baca..ac8fe4d 100644 --- a/intervaltree_bio/__init__.py +++ b/intervaltree_bio/__init__.py @@ -125,10 +125,10 @@ class GenomeIntervalTree(defaultdict): >>> gtree = GenomeIntervalTree.from_bed(BytesIO(data)) >>> len(gtree) 1732 ->>> assert gtree[b'chr10'].search(22610878) == set([Interval(22610878, 22611813, [b'.', b'1000', b'.', b'471.725544438908', b'-1', b'3.21510858105313', b'389']), Interval(22610878, 22611813, [b'.', b'791', b'.', b'123.885507169449', b'-1', b'3.21510858105313', b'596'])]) ->>> assert gtree[b'chr10'].search(22611813) == set([]) ->>> assert gtree[b'chr1'].search(145036590, 145036594) == set([Interval(145036593, 145037123, [b'.', b'247', b'.', b'38.6720804428054', b'-1', b'3.06233123683911', b'265'])]) ->>> assert gtree[b'chr10'].search(145036594, 145036595) == set([]) +>>> assert gtree[b'chr10'].overlap(22610878) == set([Interval(22610878, 22611813, [b'.', b'1000', b'.', b'471.725544438908', b'-1', b'3.21510858105313', b'389']), Interval(22610878, 22611813, [b'.', b'791', b'.', b'123.885507169449', b'-1', b'3.21510858105313', b'596'])]) +>>> assert gtree[b'chr10'].overlap(22611813) == set([]) +>>> assert gtree[b'chr1'].overlap(145036590, 145036594) == set([Interval(145036593, 145037123, [b'.', b'247', b'.', b'38.6720804428054', b'-1', b'3.06233123683911', b'265'])]) +>>> assert gtree[b'chr10'].overlap(145036594, 145036595) == set([]) ''' # We collect all intervals into a set of lists, and then put them all at once into the tree structures @@ -187,7 +187,7 @@ class GenomeIntervalTree(defaultdict): >> knownGene = GenomeIntervalTree.from_table() >> len(knownGene) 82960 ->> result = knownGene[b'chr1'].search(10, 138529) +>> result = knownGene[b'chr1'].overlap(10, 138529) >> len(result) 1 >> list(result)[0].data['name'] diff --git a/tests/genomeintervaltree_test.py b/tests/genomeintervaltree_test.py index c016760..363ba9f 100644 --- a/tests/genomeintervaltree_test.py +++ b/tests/genomeintervaltree_test.py @@ -23,7 +23,7 @@ def test_knownGene(base_url): knownGene_localurl = 'file:///%s' % os.path.abspath(knownGene_file) knownGene = GenomeIntervalTree.from_table(url=knownGene_localurl, decompress=True) # Py3 downloads .gz files to local files with names not ending with .gz assert len(knownGene) == 82960 -result = knownGene[b'chr1'].search(10, 138529) +result = knownGene[b'chr1'].overlap(10, 138529) assert len(result) == 1 assert list(result)[0].data['name'] == b'uc021oeg.2' @@ -33,7 +33,7 @@ def test_knownGene(base_url): knownGene = GenomeIntervalTree.from_table(url=knownGene_localurl, mode='exons', decompress=True) assert len(knownGene) == 742493 -result = list(knownGene[b'chr1'].search(134772, 140566)) +result = list(knownGene[b'chr1'].overlap(134772, 140566)) assert len(resul
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Hello,
Samuel Thibault wrote:
> Ah, that is most probably very related indeed. Orca can't tinker with
> the keyboard mapping if xkbcomp can't work. You could send the output
> of
>
> setxkbmap -print
-- BEGIN --
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat{ include "complete" };
xkb_symbols { include "pc+us+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
-- END --
> and the content of /etc/default/keyboard?
-- BEGIN --
# KEYBOARD CONFIGURATION FILE
# Consult the keyboard(5) manual page.
XKBMODEL="pc105"
XKBLAYOUT="de"
XKBVARIANT=""
XKBOPTIONS=""
BACKSPACE="guess"
-- END --
Best regards
Robert
signature.asc
Description: PGP signature
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Robert Schindler, le sam. 26 janv. 2019 22:54:08 +0100, a ecrit:
> Samuel Thibault wrote:
> > Ah, that is most probably very related indeed. Orca can't tinker with
> > the keyboard mapping if xkbcomp can't work. You could send the output
> > of
> >
> > setxkbmap -print
>
> -- BEGIN --
> xkb_keymap {
> xkb_keycodes { include "evdev+aliases(qwerty)" };
> xkb_types { include "complete" };
> xkb_compat{ include "complete" };
> xkb_symbols { include "pc+us+inet(evdev)" };
> xkb_geometry { include "pc(pc105)" };
> };
> -- END --
>
> > and the content of /etc/default/keyboard?
>
> -- BEGIN --
> # KEYBOARD CONFIGURATION FILE
>
> # Consult the keyboard(5) manual page.
>
> XKBMODEL="pc105"
> XKBLAYOUT="de"
> XKBVARIANT=""
> XKBOPTIONS=""
>
> BACKSPACE="guess"
Uh, these do not match. Which desktop are you using? Is that perhaps
tinkering with the keyboard configuration?
Samuel
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Hello, Robert Schindler, le sam. 26 janv. 2019 21:43:42 +0100, a ecrit: > I just tried compiling the latest upstream version of Orca from git master > (38f170751, version 3.31.90pre). The issue still exists there. > > What I noticed is this warning when Orca starts: > > Warning: Could not load keyboard geometry for :0 > BadName (named color or font does not exist) > Resulting keymap file will not describe geometry > > The exact same warning is printed when running: > > xkbcomp $DISPLAY - > > Don't know whether that's related or not. Ah, that is most probably very related indeed. Orca can't tinker with the keyboard mapping if xkbcomp can't work. You could send the output of setxkbmap -print and the content of /etc/default/keyboard? Samuel
Bug#920550: ITP: icecream-sundae -- Commandline Monitor for Icecream (icecc)
Package: wnpp Severity: wishlist Owner: Anton Gladky * Package name: icecream-sundae Version : 1.0.0 * URL : https://github.com/JPEWdev/icecream-sundae * License : GPL-2+ Programming Lang: C++ Description : Commandline Monitor for Icecream (icecc) This program is a commandline Monitor for Icecream (icecc) for an overview of nodes connected to the icecream-scheduler, their loads and other useful statistical information.
Bug#907826: RFS: gnomint/1.3.0-1 [QA]
Control: reopen -1 This bug has been closed because the package was automatically removed from mentors.d.n (20 weeks without upload). On Sun, Sep 02, 2018 at 07:41:18PM +0300, Yavor Doganov wrote: > I'm looking for a sponsor for a QA upload of "gnomint". > gnomint- X.509 Certification Authority management tool for GNOME > dget -x > https://mentors.debian.net/debian/pool/main/g/gnomint/gnomint_1.3.0-1.dsc I reuploaded the package with three tiny changes: - Bumped Standards-Version to 4.3.0; - Deleted debian/source/options (custom compression settings); - Refreshed changelog timestamp.
Bug#920549: git-annex: flaky autopkgtest
Hi Sean, On 26-01-2019 21:54, Sean Whitton wrote: > I cannot dig into the flakiness problem myself -- I have just been > trying to keep git-annex in Debian up-to-date with upstream, after some > time of no real maintainance -- so shall I just move the test suite from > autopkgtest into debian/rules? > > It seems a shame to lose running the test suites on debci, but if it's > blocking other people's work then we'll just have to accept that. You can add the flaky restriction. Than it will not block, but you can still get the bounty and see the results. There is no need to remove the test. Paul signature.asc Description: OpenPGP digital signature
Bug#914886: chromium: SafeBrowsing is not working at all (sample included)
control: reopen -1 control: tag -1 - moreinfo On Sat, Jan 26, 2019 at 3:21 PM Michael Gilbert wrote: > From everything I can tell, this works correctly in current versions. > Please feel free to reopen if it can be demonstrated otherwise. This seems to be the same problem described in this gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=674504 Upstream has instituted quotas related to their API keys it seems: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/nEHAnX0mct0 Best wishes, Mike
Bug#876659: ledger: CVE-2017-2808: Ledger CLI Account Directive Use-After-Free Vulnerability
Hi Martin, On Sat, Jan 26, 2019 at 01:18:17PM -0300, Martin Michlmayr wrote: > * Salvatore Bonaccorso [2017-09-24 17:57]: > > the following vulnerability was published for ledger. > > > > CVE-2017-2808[0]: > > | An exploitable use-after-free vulnerability exists in the account > > This has been fixed upstream: > https://github.com/ledger/ledger/commit/f3bad93db256db07b6cb831d4d24f47543f57e4a > We're also working on releasing 3.1.2 with fixes for all 4 CVE items. Thanks for the update! > I consider this (and all the other CVE issues filed against ledger) > low impact. Salvatore/David, do you want to make a release for > stable? They were marked already no-dsa, so defintively to agree no DSA itself is needed. But if you think they are worh fixing in stable, then they can go via a upcoming point release. > Salvatore, can you tell me how to inform CVE/Mitre once 3.1.2 is out > that these CVEs have been addressed? You can request an update of the CVE entry adding details via the webform at https://cveform.mitre.org/ Hope this helps, Regards, Salvatore
Bug#920549: git-annex: flaky autopkgtest
Hello Paul, On Sat 26 Jan 2019 at 09:14PM +01, Paul Gevers wrote: > You packages fails regularly on the ci.debian.net infrastructure without > apparent changes. Just now, it was blocking migration of sqlite3 due to > a failure, but when I retrigged the test, it passed. Could you please > investigate and make your autopkgtest more robust? Please contact me if > you need help and you think I can provide that (I am not subscribed to > this bug). Hrm, failing about once per month does not strike me as particularly flaky. But you are the one dealing with test suite failures and package migration, so I am happy to defer to your judgement about what counts as flaky. I cannot dig into the flakiness problem myself -- I have just been trying to keep git-annex in Debian up-to-date with upstream, after some time of no real maintainance -- so shall I just move the test suite from autopkgtest into debian/rules? It seems a shame to lose running the test suites on debci, but if it's blocking other people's work then we'll just have to accept that. -- Sean Whitton signature.asc Description: PGP signature
Bug#901170: ostree: libostree/test-concurrency.py.test intermittently fails: opendir(staging-$RANDOM): No such file or directory
Control: severity -1 normal On Sat, 26 Jan 2019 at 21:25:43 +0100, Paul Gevers wrote: > We now have the flaky restriction. Do you want to mark the [test] flaky Thanks for the reminder, I'll re-enable it as a separate flaky test (similar to glib2.0) in the next upload. That might be post-buster at this point: I'm not going to upload just for this. > (and close this bug)? I'll leave it open at lower severity: it's a valid bug in either libostree or the test, but no longer a severe one. smcv
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Hello, I just tried compiling the latest upstream version of Orca from git master (38f170751, version 3.31.90pre). The issue still exists there. What I noticed is this warning when Orca starts: Warning: Could not load keyboard geometry for :0 BadName (named color or font does not exist) Resulting keymap file will not describe geometry The exact same warning is printed when running: xkbcomp $DISPLAY - Don't know whether that's related or not. Best regards Robert signature.asc Description: PGP signature
Bug#914984: texdoc: off-by-one error with -l
On Fri, Jan 25, 2019 at 10:52:34PM +0100, Hilmar Preuße wrote: > On 29.11.18 11:06, Julian Gilbey wrote: > > Hi Julian, > > > texdoc -l number > > reports: > > 44 results. Display them all? (y/N) > > but then only lists 43 results. Either the displayed count is wrong or > > the final result is not being displayed. > > > Are you still able to reproduce the issue? Upstream says, the issue has > been solved, but what I see is e.g.: > > hille@sid:~ $ texdoc --list nu > 316 results. Display them all? (y/N) > > ...and then 202 documents are listed. Hi Hilmar, I'm seeing the same behaviour on 2018.20181214-1 on my testing system as I reported. I've tried 2018.20190126-1 on a fairly small unstable chroot; this works with texdoc --list gyre (49 and 49), though texdoc --list number gives no results. Interestingly, though, with your example I get: (sid):~ $ texdoc --list nu 138 results. Display them all? (y/N) y and then only 27 documents listed. Hmmm. Best wishes, Julian
Bug#840400: Issue seems in nls_ascii module not available
I was hitting this exact error message during installation. I switched to another VT and did: mkfs.fat /dev/sda1 Then I switched back to the installer VT, and had it try again from "finalize the partition layout". Now it's proceeding with no error. I took the idea from this Ubuntu discussion: https://askubuntu.com/questions/502307/ It looks to me like the installer doesn't ensure the EFI partition contains a filesystem before trying to mount it. -- Aaron Bugher
Bug#901170: ostree: libostree/test-concurrency.py.test intermittently fails: opendir(staging-$RANDOM): No such file or directory
Hi Simon, On Mon, 11 Jun 2018 14:13:27 +0100 Simon McVittie wrote: > If autopkgtest/debci grow a way > to mark tests as flaky (so that the test is run for its logs, but its > failure is treated as though the test had been skipped and does not cause > failures or block migration), then I'll re-enable it and mark it as flaky. We now have the flaky restriction. Do you want to mark the bug flaky (and close this bug)? Paul signature.asc Description: OpenPGP digital signature
Bug#875621: linux: ThinkPad X270 Synaptics touchpad: please enable CONFIG_RMI4_SMB
In contrast to what I wrote earlier it appears that xserver-xorg-input-synaptics *does* need to be installed. I installed it and now xinput list-props is listing more features such as circular scrolling. In Plasma system settings touchpad features that were previously not available are now available. xinput list-props 12 Device 'Synaptics TM3053-003': Device Enabled (153): 1 Coordinate Transformation Matrix (155): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (285): 1 Device Accel Constant Deceleration (286): 2.50 Device Accel Adaptive Deceleration (287): 1.00 Device Accel Velocity Scaling (288): 12.50 Synaptics Edges (289): 77, 1863, 57, 1005 Synaptics Finger (290): 25, 48, 0 Synaptics Tap Time (291): 180 Synaptics Tap Move (292): 96 Synaptics Tap Durations (293): 180, 180, 100 Synaptics ClickPad (294): 1 Synaptics Middle Button Timeout (295): 0 Synaptics Two-Finger Pressure (296): 282 Synaptics Two-Finger Width (297): 7 Synaptics Scrolling Distance (298): 50, 50 Synaptics Edge Scrolling (299): 1, 0, 0 Synaptics Two-Finger Scrolling (300): 1, 0 Synaptics Move Speed (301): 1.00, 1.75, 0.537430, 0.00 Synaptics Off (302): 2 Synaptics Locked Drags (303): 1 Synaptics Locked Drags Timeout (304): 3 Synaptics Tap Action (305): 0, 0, 0, 0, 1, 3, 2 Synaptics Click Action (306): 1, 3, 2 Synaptics Circular Scrolling (307): 1 Synaptics Circular Scrolling Distance (308): 0.17 Synaptics Circular Scrolling Trigger (309): 0 Synaptics Circular Pad (310): 0 Synaptics Palm Detection (311): 0 Synaptics Palm Dimensions (312): 10, 200 Synaptics Coasting Speed (313): 20.00, 50.00 Synaptics Pressure Motion (314): 92, 160 Synaptics Pressure Motion Factor (315): 1.00, 1.00 Synaptics Grab Event Device (316): 0 Synaptics Gestures (317): 1 Synaptics Capabilities (318): 1, 0, 0, 1, 1, 1, 0 Synaptics Pad Resolution (319): 20, 20 Synaptics Area (320): 0, 0, 0, 0 Synaptics Soft Button Areas (321): 970, 0, 870, 0, 0, 0, 0, 0 Synaptics Noise Cancellation (322): 13, 13 Device Product ID (277): 1739, 0 Device Node (276): "/dev/input/event4" I did not have to change anything with xorg.conf. This is what was generated by Xorg -configure after installing xserver-xorg-input-synaptics: Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "built-ins" EndSection Section "Module" Load "glx" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "Accel" # [] #Option "AccelMethod" # #Option "Backlight" # #Option "CustomEDID" # #Option "DRI" # #Option "Present" # [] #Option "ColorKey" # #Option "VideoKey" # #Option "Tiling" # [] #Option "LinearFramebuffer" # [] #Option "HWRotation" # [] #Option "VSync" # [] #Option "PageFlip" # [] #Option "SwapbuffersWait" # [] #Option "TripleBuffer" # [] #Option "XvPreferOve
Bug#920549: git-annex: flaky autopkgtest
Source: git-annex Version: 7.20190122-1 Severity: important X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: flaky Dear maintainers, You packages fails regularly on the ci.debian.net infrastructure without apparent changes. Just now, it was blocking migration of sqlite3 due to a failure, but when I retrigged the test, it passed. Could you please investigate and make your autopkgtest more robust? Please contact me if you need help and you think I can provide that (I am not subscribed to this bug). Recent discussion of gating migration by autopkgtests on debian-devel [1] noted that if this is going to work, and in particular now we are *blocking* migration when it causes autopkgtest regressions, intermittent autopkgtest failures are likely to have to be considered RC due to their impact on the tested package's dependencies; for now I've filed it as important. Paul [1] https://lists.debian.org/debian-devel/2018/05/msg00061.html https://ci.debian.net/data/autopkgtest/testing/amd64/g/git-annex/1791938/log.gz get: 1 failed FAIL (0.15s) Test.hs:1508: get failed uninit (in git-annex branch): On branch master nothing to commit, working tree clean not supported in direct mode; skipping OK (0.14s) upgrade: On branch master nothing to commit, working tree clean OK (0.23s) whereis: On branch master nothing to commit, working tree clean whereis: 1 failed FAIL (0.15s) Test.hs:1526: whereis on non-present file failed hook remote: On branch master nothing to commit, working tree clean get: 1 failed FAIL (0.16s) Test.hs:1546: get of file failed directory remote: On branch master nothing to commit, working tree clean get: 1 failed FAIL (0.16s) Test.hs:1570: get of file failed rsync remote: On branch master nothing to commit, working tree clean get: 1 failed FAIL (0.16s) Test.hs:1585: get of file failed bup remote: On branch master nothing to commit, working tree clean OK (0.12s) crypto: On branch master nothing to commit, working tree clean git-annex: There is already a special remote named "foo". (Use enableremote to enable an existing special remote.) initremote: 1 failed get: 1 failed FAIL (0.25s) Test.hs:1643: get of file failed preferred content:On branch master nothing to commit, working tree clean get: 1 failed FAIL (0.16s) Test.hs:550: get --auto of file failed with default preferred content add subdirs: On branch master nothing to commit, working tree clean Automatic merge went well; stopped before committing as requested To /tmp/tmp.wo7OE4YXDe/.t/repo ae7c86c..522ac14 git-annex -> synced/git-annex da99c14..09870b7 annex/direct/master -> synced/master OK (0.41s) addurl: On branch master nothing to commit, working tree clean Configuration does not allow accessing file:///tmp/tmp.wo7OE4YXDe/.t/tmprepo291/myurl download failed: Configuration does not allow accessing file:///tmp/tmp.wo7OE4YXDe/.t/tmprepo291/myurl OK (0.20s) 19 out of 227 tests failed (119.30s) (Failures above could be due to a bug in git-annex, or an incompatibility with utilities, such as git, installed on this system.) autopkgtest [16:27:29]: test basics: ---] signature.asc Description: OpenPGP digital signature
Bug#908216: btrfs blocked for more than 120 seconds
Package: src:linux Version: 4.19.12-1~bpo9+1 Severity: important With the debilitating btrfs bugs in 4.19, it probably wasn't prudent to remove 4.17 and 4.18 from the repository, until 4.20 is released. Jan 25 17:17:50 vhost002 kernel: INFO: task btrfs-transacti:661 blocked for more than 120 seconds. Jan 25 17:17:50 vhost002 kernel: Tainted: GE 4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1 Jan 25 17:17:50 vhost002 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 25 17:17:50 vhost002 kernel: btrfs-transacti D0 661 2 0x8000 Jan 25 17:17:50 vhost002 kernel: Call Trace: Jan 25 17:17:50 vhost002 kernel: ? __schedule+0x3f5/0x880 Jan 25 17:17:50 vhost002 kernel: schedule+0x32/0x80 Jan 25 17:17:50 vhost002 kernel: btrfs_start_ordered_extent+0xed/0x120 [btrfs] Jan 25 17:17:50 vhost002 kernel: ? remove_wait_queue+0x60/0x60 Jan 25 17:17:50 vhost002 kernel: btrfs_wait_ordered_range+0xa0/0x100 [btrfs] Jan 25 17:17:50 vhost002 kernel: __btrfs_wait_cache_io+0x46/0x1c0 [btrfs] Jan 25 17:17:50 vhost002 kernel: btrfs_start_dirty_block_groups+0x1ad/0x4b0 [btrfs] Jan 25 17:17:50 vhost002 kernel: btrfs_commit_transaction+0xc8/0x8a0 [btrfs] Jan 25 17:17:50 vhost002 kernel: ? start_transaction+0x8f/0x3e0 [btrfs] Jan 25 17:17:50 vhost002 kernel: transaction_kthread+0x157/0x180 [btrfs] Jan 25 17:17:50 vhost002 kernel: kthread+0xf8/0x130 Jan 25 17:17:50 vhost002 kernel: ? btrfs_cleanup_transaction+0x500/0x500 [btrfs] Jan 25 17:17:50 vhost002 kernel: ? kthread_create_worker_on_cpu+0x70/0x70 Jan 25 17:17:50 vhost002 kernel: ret_from_fork+0x35/0x40 Jan 25 17:19:51 vhost002 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 25 17:19:51 vhost002 kernel: btrfs-transacti D0 661 2 0x8000 Jan 25 17:19:51 vhost002 kernel: Call Trace: Jan 25 17:19:51 vhost002 kernel: ? __schedule+0x3f5/0x880 Jan 25 17:19:51 vhost002 kernel: schedule+0x32/0x80 Jan 25 17:19:51 vhost002 kernel: btrfs_start_ordered_extent+0xed/0x120 [btrfs] Jan 25 17:19:51 vhost002 kernel: ? remove_wait_queue+0x60/0x60 Jan 25 17:19:51 vhost002 kernel: btrfs_wait_ordered_range+0xa0/0x100 [btrfs] Jan 25 17:19:51 vhost002 kernel: __btrfs_wait_cache_io+0x46/0x1c0 [btrfs] Jan 25 17:19:51 vhost002 kernel: btrfs_start_dirty_block_groups+0x1ad/0x4b0 [btrfs] Jan 25 17:19:51 vhost002 kernel: btrfs_commit_transaction+0xc8/0x8a0 [btrfs] Jan 25 17:19:51 vhost002 kernel: ? start_transaction+0x8f/0x3e0 [btrfs] Jan 25 17:19:51 vhost002 kernel: transaction_kthread+0x157/0x180 [btrfs] Jan 25 17:19:51 vhost002 kernel: kthread+0xf8/0x130 Jan 25 17:19:51 vhost002 kernel: ? btrfs_cleanup_transaction+0x500/0x500 [btrfs] Jan 25 17:19:51 vhost002 kernel: ? kthread_create_worker_on_cpu+0x70/0x70 Jan 25 17:19:51 vhost002 kernel: ret_from_fork+0x35/0x40 Jan 25 17:21:52 vhost002 kernel: INFO: task btrfs-transacti:661 blocked for more than 120 seconds. Jan 25 17:21:52 vhost002 kernel: Tainted: GE 4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1 Jan 25 17:21:52 vhost002 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 25 17:21:52 vhost002 kernel: btrfs-transacti D0 661 2 0x8000 Jan 25 17:21:52 vhost002 kernel: Call Trace: Jan 25 17:21:52 vhost002 kernel: ? __schedule+0x3f5/0x880 Jan 25 17:21:52 vhost002 kernel: schedule+0x32/0x80 Jan 25 17:21:52 vhost002 kernel: btrfs_start_ordered_extent+0xed/0x120 [btrfs] Jan 25 17:21:52 vhost002 kernel: ? remove_wait_queue+0x60/0x60 Jan 25 17:21:52 vhost002 kernel: btrfs_wait_ordered_range+0xa0/0x100 [btrfs] Jan 25 17:21:52 vhost002 kernel: __btrfs_wait_cache_io+0x46/0x1c0 [btrfs] Jan 25 17:21:52 vhost002 kernel: btrfs_start_dirty_block_groups+0x1ad/0x4b0 [btrfs] Jan 25 17:21:52 vhost002 kernel: btrfs_commit_transaction+0xc8/0x8a0 [btrfs] Jan 25 17:21:52 vhost002 kernel: ? start_transaction+0x8f/0x3e0 [btrfs] Jan 25 17:21:52 vhost002 kernel: transaction_kthread+0x157/0x180 [btrfs] Jan 25 17:21:52 vhost002 kernel: kthread+0xf8/0x130 Jan 25 17:21:52 vhost002 kernel: ? btrfs_cleanup_transaction+0x500/0x500 [btrfs] Jan 25 17:21:52 vhost002 kernel: ? kthread_create_worker_on_cpu+0x70/0x70 Jan 25 17:21:52 vhost002 kernel: ret_from_fork+0x35/0x40 Jan 25 17:23:53 vhost002 kernel: INFO: task btrfs-transacti:661 blocked for more than 120 seconds. Jan 25 17:23:53 vhost002 kernel: Tainted: GE 4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1 Jan 25 17:23:53 vhost002 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 25 17:23:53 vhost002 kernel: btrfs-transacti D0 661 2 0x8000 Jan 25 17:23:53 vhost002 kernel: Call Trace: Jan 25 17:23:53 vhost002 kernel: ? __schedule+0x3f5/0x880 Jan 25 17:23:53 vhost002 kernel: schedule+0x32/0x80 Jan 25 17:23:53 vhost002 kernel: btrfs_start_ordered_extent+0xed/0x120 [btrfs] Jan 25 17:23:53 vhost002 kernel: ? remove_wait_q
Bug#920548: golang-1.12: CVE-2019-6486
Source: golang-1.12 Version: 1.12~beta2-1 Severity: grave Tags: security upstream Forwarded: https://github.com/golang/go/issues/29903 Hi, The following vulnerability was published for golang-1.12, which was already fixed for the released version 1.11.5 and 1.10.8 upstream. CVE-2019-6486[0]: | Go before 1.10.8 and 1.11.x before 1.11.5 mishandles P-521 and P-384 | elliptic curves, which allows attackers to cause a denial of service | (CPU consumption) or possibly conduct ECDH private key recovery | attacks. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-6486 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6486 [1] https://github.com/golang/go/issues/29903 Regards, Salvatore
Bug#917582: Looks like a pandoc bug
On Wed, 23 Jan 2019 22:46:59 +0100 Fiona Klute wrote: > The easiest solution for the mod-gnutls package should be to remove the > PDF documentation, I realized the PDF documentation doesn't get installed anyway, so the easiest workaround will be to remove the pdf_DATA line in doc/Makefile.am to prevent it from getting built.
Bug#920546: dolfin: flaky autopkgtest as it times out sometimes
Source: dolfin Version: 2018.1.0.post1-13 Severity: important X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: flaky timeout Dear maintainers, Since you uploaded your package version 2018.1.0.post1-13, it has failed several times on your test-dolfin-cpp test on the ci.debian.net infrastructure due to timeouts of autopkgtest (after 1 seconds). Could you please investigate and make your autopkgtest more robust against this time out? Please contact me if you need help and you think I can provide that (I am not subscribed to this bug). Recent discussion of gating migration by autopkgtests on debian-devel [1] noted that if this is going to work, and in particular now we are *blocking* migration when it causes autopkgtest regressions, intermittent autopkgtest failures are likely to have to be considered RC due to their impact on the tested package's dependencies; for now I've filed it as important. I noticed this issue because the dolfin regression was blocking pkg-config. Paul [1] https://lists.debian.org/debian-devel/2018/05/msg00061.html https://ci.debian.net/data/autopkgtest/testing/amd64/d/dolfin/1764909/log.gz Total Test time (real) = 135.57 sec running C++ demos (MPI) Test project /tmp/autopkgtest-lxc.6bsy1myv/downtmp/build.toR/src/dolfin-demo Start 1: demo_poisson_mpi 1/48 Test #1: demo_poisson_mpi ... Passed 1.49 sec Start 3: demo_neumann-poisson_mpi 2/48 Test #3: demo_neumann-poisson_mpi ... Passed 1.88 sec Start 5: demo_biharmonic_mpi 3/48 Test #5: demo_biharmonic_mpi Passed 1.63 sec Start 7: demo_stokes-iterative_mpi 4/48 Test #7: demo_stokes-iterative_mpi .. Passed 33.78 sec Start 9: demo_built-in-meshes_mpi 5/48 Test #9: demo_built-in-meshes_mpi ... Passed 3.35 sec Start 11: demo_mixed-poisson_mpi 6/48 Test #11: demo_mixed-poisson_mpi . Passed 2.20 sec Start 13: demo_auto-adaptive-poisson_mpi 7/48 Test #13: demo_auto-adaptive-poisson_mpi . Passed 0.85 sec Start 15: demo_nonmatching-interpolation_mpi 8/48 Test #15: demo_nonmatching-interpolation_mpi . Passed 0.84 sec Start 17: demo_eigenvalue_mpi 9/48 Test #17: demo_eigenvalue_mpi Passed 2.25 sec Start 19: demo_periodic_mpi 10/48 Test #19: demo_periodic_mpi .. Passed 1.50 sec Start 21: demo_nonlinear-poisson_mpi 11/48 Test #21: demo_nonlinear-poisson_mpi . Passed 1.57 sec Start 23: demo_subdomains_mpi 12/48 Test #23: demo_subdomains_mpi Passed 0.82 sec Start 25: demo_singular-poisson_mpi 13/48 Test #25: demo_singular-poisson_mpi .. Passed 1.91 sec Start 27: demo_bcs_mpi 14/48 Test #27: demo_bcs_mpi ... Passed 2.72 sec Start 30: demo_navier-stokes_mpi 15/48 Test #30: demo_navier-stokes_mpi . Passed 30.14 sec Start 32: demo_parallel-refinement_mpi 16/48 Test #32: demo_parallel-refinement_mpi ... Passed 1.18 sec Start 34: demo_contact-vi-snes_mpi 17/48 Test #34: demo_contact-vi-snes_mpi ... Passed 2.84 sec Start 36: demo_multimesh-poisson_mpi 18/48 Test #36: demo_multimesh-poisson_mpi . Passed 0.85 sec Start 38: demo_dg-poisson_mpi 19/48 Test #38: demo_dg-poisson_mpi Passed 1.74 sec Start 40: demo_parameters_mpi 20/48 Test #40: demo_parameters_mpi Passed 0.91 sec Start 42: demo_contact-vi-tao_mpi 21/48 Test #42: demo_contact-vi-tao_mpi Passed 1.84 sec Start 44: demo_conditional_mpi 22/48 Test #44: demo_conditional_mpi ... Passed 2.10 sec Start 46: demo_lift-drag_mpi 23/48 Test #46: demo_lift-drag_mpi . Passed 1.26 sec Start 48: demo_time-series_mpi 24/48 Test #48: demo_time-series_mpi ... Passed 0.83 sec Start 50: demo_waveguide_mpi 25/48 Test #50: demo_waveguide_mpi . Passed 1.41 sec Start 52: demo_refinement_mpi 26/48 Test #52: demo_refinement_mpi Passed 1.80 sec Start 54: demo_extrapolation_mpi 27/48 Test #54: demo_extrapolation_mpi . Passed 0.82 sec Start 56: demo_ale_mpi 28/48 Test #56: demo_ale_mpi ... Passed 1.38 sec Start 58: demo_dg-advection-diffusion_mpi autopkgtest [03:49:59]: ERROR: timed out on command "su -s /bin/bash debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; . ~/.profile >/dev/null 2>&1 || true; buildtree="/tmp/autopkgtest-lxc.6bsy1myv/downtmp/build.toR/src"; mkdir -p -m 1777 -- "/tmp/autopkgtest-lxc.6bsy1myv/downtmp/test-dolfin-cpp-artifacts"; export AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.6bsy1myv/downtmp/test-dolfin-cpp-artifacts"; export ADT_ARTIFACTS="$AU
Bug#484805: marked as done (developers-reference: please make clone to tech-ctte the default)
Hello, On Sat 26 Jan 2019 at 12:11AM +00, Holger Levsen wrote: > On Fri, Jan 25, 2019 at 04:56:09PM -0700, Sean Whitton wrote: >> > which IMO is as good as it is. It also explicitly points to >> > http://www.debian.org/devel/tech-ctte for detailed information. >> At least for Policy bugs referred to the TC, they prefer a fresh bug >> where the first message is a summary of the situation, rather than a clone. > > so you suggest a reopening of this bug? > > (yes or no as an answer would be great, even greater in the case of > 'yes' would obviously be a patch, but many thanks already for this > feedback, we can write the patch later, if needed?!) ISTM that it would be useful to have this in dev-ref, yes. I'm not sure whether it should be a reopening or a new bug though :) I will leave this in the package maintainer's hands ;) -- Sean Whitton signature.asc Description: PGP signature
Bug#849574: gtkdataboxmm: FTBFS when built with dpkg-buildpackage -A (Makefile error)
Followup-For: Bug #849574 Hi, nowadays it also fails during the binary-arch build: debian/rules override_dh_install make[1]: Entering directory '/build/gtkdataboxmm-0.9.4' dh_install # Call d-shlibmove to comply with library packaging guide d-shlibmove --commit \ --multiarch \ --devunversioned \ --exclude-la \ --override s/libatkmm-1.6-1-dev/libatkmm-1.6-dev/ \ --override s/libcairomm-1.0-1-dev/libcairomm-1.0-dev/ \ --override s/libgdkmm-2.4-1-dev/libglibmm-2.4-dev/ \ --override s/libgiomm-2.4-1-dev/libglibmm-2.4-dev/ \ --override s/libglibmm-2.4-1-dev/libglibmm-2.4-dev/ \ --override s/libgtkdatabox-0.9.3-0-dev/libgtkdatabox-dev/ \ --override s/libgtkmm-2.4-1-dev/libgtkmm-2.4-dev/ \ --override s/libpangomm-1.4-1-dev/libpangomm-1.4-dev/ \ --override s/libsigc-2.0-0-dev/libsigc++-2.0-dev/ \ --movedev "debian/tmp/usr/include" usr \ --movedev "debian/tmp/usr/lib/*/pkgconfig/*.pc" usr/lib/x86_64-linux-gnu/pkgconfig \ debian/tmp/usr/lib/*/*.so Library package automatic movement utility --> libatk1.0-dev package exists. --> libatkmm-1.6-dev package exists.
Bug#915738: rules workaround
this rules change should disable unrolling for fortran on s390x. I'm currently checking if we can upload a new upstream without breaking rdeps, if not I'll add this to 1.11.0 build-python%: ifeq ($(DEB_HOST_ARCH),s390x) # gcc bug 906198 NPY_DISTUTILS_APPEND_FLAGS=1 FOPT="-fno-unroll-loops" python$* setup.py config_fc --noarch build; NPY_DISTUTILS_APPEND_FLAGS=1 FOPT="-fno-unroll-loops" python$*-dbg setup.py config_fc else python$* setup.py config_fc --noarch build; python$*-dbg setup.py config_fc endif signature.asc Description: OpenPGP digital signature
Bug#920545: python-intervaltree breaks python-intervaltree-bio autopkgtest
Source: python-intervaltree, python-intervaltree-bio Control: found -1 python-intervaltree/3.0.2-1 Control: found -1 python-intervaltree-bio/1.0.1-2 X-Debbugs-CC: debian...@lists.debian.org Severity: important User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainers, With a recent upload of python-intervaltree the autopkgtest of python-intervaltree-bio fails in testing when that autopkgtest is run with the binary packages of python-intervaltree from unstable. It passes when run with only packages from testing. In tabular form: passfail python-intervaltree from testing3.0.2-1 python-intervaltree-bio from testing1.0.1-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python-intervaltree to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=python-intervaltree https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-intervaltree-bio/1785537/log.gz === FAILURES === test_knownGene def test_knownGene(): # To speed up testing, we'll download the file and reuse the downloaded copy knownGene_url = 'http://hgdownload.cse.ucsc.edu/goldenpath/hg19/database/knownGene.txt.gz' # Mirror. Slightly faster and more stable, I believe: knownGene_url = 'http://kt.era.ee/distribute/pyintervaltree/knownGene.txt.gz' # To speed up testing, we'll download the file and reuse the downloaded copy knownGene_file, headers = urlretrieve(knownGene_url) knownGene_localurl = 'file:///%s' % os.path.abspath(knownGene_file) knownGene = GenomeIntervalTree.from_table(url=knownGene_localurl, decompress=True) # Py3 downloads .gz files to local files with names not ending with .gz assert len(knownGene) == 82960 > result = knownGene[b'chr1'].search(10, 138529) E AttributeError: 'IntervalTree' object has no attribute 'search' .pc/offline-test-data.patch/tests/genomeintervaltree_test.py:28: AttributeError test_knownGene[file:///tmp/autopkgtest-lxc.z3ra1nek/downtmp/build.Szw/src/debian/data/] base_url = 'file:///tmp/autopkgtest-lxc.z3ra1nek/downtmp/build.Szw/src/debian/data/' def test_knownGene(base_url): # To speed up testing, we'll download the file and reuse the downloaded copy knownGene_url = base_url + 'knownGene.txt.gz' # To speed up testing, we'll download the file and reuse the downloaded copy knownGene_file, headers = urlretrieve(knownGene_url) knownGene_localurl = 'file:///%s' % os.path.abspath(knownGene_file) knownGene = GenomeIntervalTree.from_table(url=knownGene_localurl, decompress=True) # Py3 downloads .gz files to local files with names not ending with .gz assert len(knownGene) == 82960 > result = knownGene[b'chr1'].search(10, 138529) E AttributeError: 'IntervalTree' object has no attribute 'search' signature.asc Description: OpenPGP digital signature
Bug#920540: opendmarc: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: opendmarc Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: PGP signature
Bug#920539: powerline: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: powerline Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: PGP signature
Bug#920544: s-nail: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: s-nail Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: PGP signature
Bug#920543: lxc: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: lxc Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: PGP signature
Bug#920533: asterisk: on upgrade from 13.23.1 to 16.1.1 RTP streams get misdirected to NAT devices
Tags: patch
This is the patch I have applied to my system which fixes the problem
locally
James
---
Index: BUILD/channels/chan_sip.c
===
--- BUILD.orig/channels/chan_sip.c
+++ BUILD/channels/chan_sip.c
@@ -10997,6 +10997,8 @@ static int process_sdp(struct sip_pvt *p
if (req->method == SIP_RESPONSE) {
start_ice(p->rtp, 1);
}
+ if (p->natdetected)
+ ast_sockaddr_copy(sa, &p->recv);
ast_sockaddr_set_port(sa, portno);
ast_rtp_instance_set_remote_address(p->rtp, sa);
if (debug) {
@@ -23891,6 +23893,8 @@ static void handle_response_invite(struc
int rtn;
struct ast_party_connected_line connected;
struct ast_set_party_connected_line update_connected;
+ char domain[MAXHOSTNAMELEN];
+ struct ast_sockaddr addr;
if (reinvite) {
ast_debug(4, "SIP response %d to RE-invite on %s call %s\n",
resp, outgoing ? "outgoing" : "incoming", p->callid);
@@ -23945,6 +23949,9 @@ static void handle_response_invite(struc
if (!reinvite) {
set_pvt_allowed_methods(p, req);
}
+ get_domain(sip_get_header(req, "To"), domain, sizeof(domain));
+ ast_sockaddr_resolve_first(&addr, domain, 0);
+ check_for_nat(&addr, p);
switch (resp) {
case 100: /* Trying */
Bug#920541: postgresql-11: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: postgresql-11 Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: PGP signature
