Bug#1095435: linux-source-6.1: fixes for XSA-466 (in linux 6.1.121+) can break Xen PVH domU boot
Package: linux-source-6.1 Version: 6.1.124-1 Severity: critical Justification: breaks the whole system Tags: patch Hi, It turns out the upstream changes made to fix XSA-466 / CVE-2024-53241 "x86/xen: remove hypercall page" [1] and "x86/xen: use new hypercall functions instead of hypercall page" [2] can leave an Xen PVH domU unbootable. These went into Debian in linux-image-6.1.0-29-amd64 (6.1.123-1) and upstream Linux in 6.1.121, and also into other kernel series, and mainline. Juergen Gross has already very helpfully diagnosed this problem and fixed it with a patch that's been accepted in mainline "x86/xen: fix xen_hypercall_hvm() to not clobber %rbx" [3] This bug report is to request this patch be incorporated into the Debian stable kernel. It seems quite variable whether systems are affected. Not everyone hits it, but we (Jump Networks, a VPS hosting provider) have seen it across multiple versions of Xen and on both Intel and AMD hardware. Symptoms are PVH domU immediately shutting down before any output from the kernel, even with earlyprintk=xen and CONFIG_X86_VERBOSE_BOOTUP. The xl log just shows that the domain shut down. Appending 'loglvl=all guest_loglvl=all' to the Xen host commandline produces something more useful in the 'xl dmesg' buffer after a guest crash, here's some characteristic output for anyone else wanting to know if they're hitting the same bug (garbled characters in original, and bug related). (d38) [0.00] Linux version 6.1.0-29-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.123-1 (2025-01 (d38) -02) (d38) @�!Linux version 6.1.0-29-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.123-1 (2025-01-02) (d38) 2) (d38) ���Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-29-amd64 root=PARTUUID=5650c9f4-01 ro console=tty0 console=hvc0 earlyprintk=xen net.ifnames=0 consoleblank=0=0 (d38) ���BIOS-provided physical RAM map:p: (d38) ���BIOS-e820: [mem 0x-0xfbff] usablec (d38) ���BIOS-e820: [mem 0xfc00-0xfc008fff] ACPI datac (d38) ���BIOS-e820: [mem 0xfeff8000-0xfeff] reservedc (d38) ���BIOS-e820: [mem 0x0001-0x000203ff] usablec (d38) �?Ħ @Ħ�AĦ�AĦ�AĦBĦCĦ@CĦDĦ�DĦ�DĦ�DĦ�DĦ�DĦEĦIĦIĦ@IĦ`IĦ�JĦ�JĦ�JĦ�JĦ@KĦKĦ�KĦ�� (d38) ���KĦ�KĦ�KĦLĦLĦ LĦPLĦ`LĦpLĦLĦLĦ�LĦ�LĦ�LĦ�LĦ�LĦMĦMĦ MĦ@MĦpRĦpSĦSĦ�SĦUĦPUĦ� (d38) UĦ@Ħ�ĦPĦ`Ħ�Ħ`�Ħ�Ħ�Ħ�Ħ@�Ħ`�Ħp�Ħ�Ħ�Ħ��Ħ��Ħ��ĦгĦ�Ħ`�Ħ�Ħ�Ħ@�ĦP�Ħp�Ħ��� (d38) ��Ħ�Ħ�Ħ �Ħ0�ĦP�Ħ�Ħ��ĦжĦ0�Ħ�Ħ��Ħ�Ħp�Ħ`�Ħ��Ħ �Ħ@�ĦPANIC: early exception 0x0e IP 10:a5e9606b error 0 c (d38) r2 0xa8e0 Thanks for your help, Andrew Kanaber Jump Networks [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4c24703978b44d4bb95413a6b85c3254a5fa9bc1 [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1a2471af32acd00378d07164d025eaf226f337c3 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/xen/xen-head.S?id=98a5cfd2320966f40fe049a9855f8787f0126825 -- System Information: Debian Release: 12.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.128 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-source-6.1 depends on: ii binutils 2.40-2 ii xz-utils 5.4.1-0.2 Versions of packages linux-source-6.1 recommends: ii bc1.07.1-3+b1 ii bison 2:3.8.2+dfsg-1+b1 ii build-essential 12.9 ii cpio 2.13+dfsg-7.1 ii flex 2.6.4-8.2 ii kmod 30+20221128-1 ii libelf-dev0.188-2.1 ii libssl-dev3.0.15-1~deb12u1 ii linux-config-6.1 6.1.124-1 ii rsync 3.2.7-1+deb12u2 Versions of packages linux-source-6.1 suggests: ii libncurses-dev [ncurses-dev] 6.4-4 pn pkg-config pn qtbase5-dev -- no debconf information
Bug#1092257: alsa-ucm-conf: internal microphone unavailable after upgrading to 1.2.13-1
Package: alsa-ucm-conf Version: 1.2.13-1 Followup-For: Bug #1092257 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** after upgrade to 1.2.13-1, previously-working built in microphone no longer works I tried applying the patch referred to at https://github.com/alsa-project/alsa-ucm-conf/commit/11b028a9a01e47fc9b48e4a566803752011902e2 but that disabled both speakers and microphone System is a Lenovo Thinkpad X1 00:1f.3 Audio device: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20) (prog-if 80) Subsystem: Lenovo Device 22d5 Flags: bus master, fast devsel, latency 64, IRQ 196, IOMMU group 13 Memory at 603d1c8000 (64-bit, non-prefetchable) [size=16K] Memory at 603d00 (64-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 3 Capabilities: [80] Vendor Specific Information: Len=14 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Kernel driver in use: sof-audio-pci-intel-tgl Kernel modules: snd_hda_intel, snd_soc_avs, snd_sof_pci_intel_tgl -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.12.11-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages alsa-ucm-conf depends on: ii libasound2t64 1.2.13-1+b1 alsa-ucm-conf recommends no packages. alsa-ucm-conf suggests no packages. -- no debconf information
Bug#981937: dh-sysuser: Reduce negative impact and assess overall utility
Hi everyone, On Wed, Jul 17, 2024 at 12:06:43PM +0100, Luca Boccassi wrote: > Having competing packaging APIs is confusing and detrimental to the > project. The standard interface the project has adopted for declarative > user/group creation is dh_installsysusers provided by debhelper. Having > a similarly named API, that is incompatible, does not actually use the > sysuser.d interface despite being named after it, and does not provide > the same advantages, is confusing for developers who might pick it by > mistake, and leads to needless divergence and bugs. This seems to me considerably less likely to happen with Lorenzo's pending change to rename the sysuser control file, the format convergence, the emergence of viable standalone sysusers packages (which wasn't assured before) and the fact that dh_installsysusers is at last in the default sequence. Maybe downgrade the severity a notch? > Hence I am bumping the severity of both bugs to serious, so that this > does not ship in Trixie. Please apply the suggested change, or an > equivalent one, in runit, and then please file an RM bug for dh- > sysuser. Thank you. Please don't do this, at least not for the sysuser-helper binary package in Trixie: the unsatisfiable runtime dependency breaks third party packages built for Debian 12, preventing them from being installed on Debian 13 when they otherwise could be. You need to be more conservative about the runtime helper (the version in Lorenzo's pending change still works, fortunately - I have tested it).
Bug#1092548: src:runit-services: fails to migrate to testing for too long
I didn't really follow the automatic bug closing rationale (much to learn about BTS...) but anyway it looks like this might be an incomplete fix here in the bin path test that only affects some architectures - it's the zcfan binary not being located: https://salsa.debian.org/debian/runit-services/-/commit/31da4883daf46ff0e35aa56a7018f4c7dd03d13c
Bug#1092549: src:runit: unsatisfied build dependency in testing: dh-buildinfo (>= 0.11+nmu1) | dh-buildinfo (>= 0.11+nmu1)
Hi Paul, On Wed, Jan 08, 2025 at 08:49:27PM +0100, Paul Gevers wrote: > Note: this bug report was sent after some quick manual checks using a > template. Please reach out to me if you believe I made a mistake in my > process. Isn't this bug a duplicate of #1090770 (runit: depends on unsatisfiable dh-buildinfo)? The maintainer has already merged a patch for this and marked that bug as pending, presumably anticipating wrapping other critical changes into his next upload - can we therefore resolve this bug as already in hand? Thanks!
Bug#1091557: [debian-mysql] Bug#1091557: mariadb: FTBFS on i386: make[1]: *** [debian/rules:146: override_dh_auto_test] Error 1
On Sat, Dec 28, 2024 at 08:17:28PM -0800, Otto Kekäläinen wrote: [...] > due to lacking builder isolation" and are sporadic by nature, so they > will go away on a new rebuild when the build host is less congested. [...] It took 21 hours but I just built this successfully on 32-bit bare metal! :-) dpkg-buildpackage -us -uc -ui -i -b dpkg-buildpackage: info: source package mariadb dpkg-buildpackage: info: source version 1:11.4.4-2 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Otto Kekäläinen dpkg-source -i --before-build . dpkg-buildpackage: info: host architecture i386 debian/rules clean dh clean debian/rules override_dh_auto_clean ... dpkg-deb: building package 'mariadb-plugin-s3-dbgsym' in '../mariadb-plugin-s3-dbgsym_11.4.4-2_i386.deb'. dpkg-genbuildinfo --build=binary -O../mariadb_11.4.4-2_i386.buildinfo dpkg-genchanges --build=binary -O../mariadb_11.4.4-2_i386.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source -i --after-build . dpkg-buildpackage: info: binary-only upload (no source included) Now running lintian mariadb_11.4.4-2_i386.changes ... W: mariadb-server: executable-not-elf-or-script [usr/bin/wsrep_sst_common] W: mariadb-test-data: executable-not-elf-or-script [usr/share/mariadb/mariadb-test/main/lowercase_table4.result] W: libmariadb3: mismatched-override hardening-no-fortify-functions [usr/lib/x86_64-linux-gnu/libmariadb3/plugin/caching_sha2_password.so] [usr/share/lintian/overrides/libmariadb3:2] W: libmariadb3: mismatched-override hardening-no-fortify-functions [usr/lib/x86_64-linux-gnu/libmariadb3/plugin/dialog.so] [usr/share/lintian/overrides/libmariadb3:3] W: libmariadb3: mismatched-override hardening-no-fortify-functions [usr/lib/x86_64-linux-gnu/libmariadb3/plugin/sha256_password.so] [usr/share/lintian/overrides/libmariadb3:4] W: libmariadbd19t64: mismatched-override exit-in-shared-library [usr/lib/x86_64-linux-gnu/libmariadbd.so.19] [usr/share/lintian/overrides/libmariadbd19t64:9] W: libmariadbd19t64: mismatched-override no-symbols-control-file usr/lib/x86_64-linux-gnu/libmariadbd.so.19 [usr/share/lintian/overrides/libmariadbd19t64:7] W: mariadb-plugin-mroonga: mismatched-override spelling-error-in-binary nam name [usr/lib/mysql/plugin/ha_mroonga.so] [usr/share/lintian/overrides/mariadb-plugin-mroonga:2] W: mariadb-server: mismatched-override hardening-no-fortify-functions [usr/lib/x86_64-linux-gnu/security/pam_user_map.so] [usr/share/lintian/overrides/mariadb-server:13] W: mariadb-test-data: mismatched-override repeated-path-segment rocksdb [usr/share/mariadb/mariadb-test/plugin/rocksdb/rocksdb/] [usr/share/lintian/overrides/mariadb-test-data:15] N: 0 hints overridden; 8 unused overrides Finished running lintian.
Bug#1074989: getdns: ftbfs with GCC-14
Control: tags 1074989 + patch upstream fixed-upstream
Dear getdns packaging team,
I have written a patch to fix this FTBFS error raised against getdns
when built with gcc-14.
According to <https://udd.debian.org/cgi-bin/autoremovals.cgi>, if I
have interpreted the list correctly, getdns is "flagged for removal in
44 hours", so this might be urgent!
On Wed, Jul 03, 2024 at 12:27:31PM +, Matthias Klose wrote:
> [This bug is targeted to the upcoming trixie release]
[...]
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
This patch fixes the following critical error wherein the two values to
be asserted as equal are instead presented as different arguments to the
assertion test function when not expected.
getdns-1.6.0/src/test/check_getdns_dict_set_bindata.h: In function
‘getdns_dict_set_bindata_4_fn’:
getdns-1.6.0/src/test/check_getdns_dict_set_bindata.h:115:60: error: passing
argument 4 of ‘_ck_assert_failed’ makes pointer from integer without a cast
[-Wint-conversion]
115 | ck_assert_msg(retrieved_bindata->size, second_bindata.size,
| ~~^
||
|size_t {aka
long unsigned int}
/usr/include/check.h:506:75: note: expected ‘const char *’ but argument is of
type ‘size_t’ {aka ‘long unsigned int’}
506 | const char *expr, const
char *msg,
My patch is available as a merge request at
<https://salsa.debian.org/dns-team/getdns/-/merge_requests/4> and I
would be grateful if you would consider merging it. I also attach the
patch to this message.
The fix for this bug is also included upstream and available in versions
1.7.0 onwards, therefore importing the latest upstream version would
also fix this bug. Debian bug #1025781 requests that upstream version
1.7.2 be imported.
Note that the salsa repository has not been updated to include the
contents of the crucial NMU for the t64 transition (1.6.0-3.1), bug
#1062103.
I hope this helps!
Thanks,
Andrew
From 5159e4aeb312143e685ac47fed03e67f0ea316f0 Mon Sep 17 00:00:00 2001
From: Andrew Bower
Date: Tue, 10 Dec 2024 19:17:12 +
Subject: [PATCH] Patch error in getdns tests to fix FTBFS with gcc-14.
(Closes: #1074989)
---
.../0006-Fix-incorrect-assertion.patch| 23 +++
debian/patches/series | 1 +
2 files changed, 24 insertions(+)
create mode 100644 debian/patches/0006-Fix-incorrect-assertion.patch
diff --git a/debian/patches/0006-Fix-incorrect-assertion.patch b/debian/patches/0006-Fix-incorrect-assertion.patch
new file mode 100644
index ..10f32521
--- /dev/null
+++ b/debian/patches/0006-Fix-incorrect-assertion.patch
@@ -0,0 +1,23 @@
+Description: Fix incorrectly-written assertion breaking builds with gcc-14.
+ An assertion in test code was written incorrectly in a way that would always
+ succeed. This patch was independently developed to fix the Debian build but
+ the bug is also fixed as part of a larger patch fixing compiler warnings
+ upstream and is present in v1.7.0~rc.1 onwards. Importing the latest
+ upstream release will obviate the need for this patch.
+Author: Andrew Bower
+Bug-Debian: https://bugs.debian.org/1074989
+Forwarded: not-needed
+Applied-Upstream: https://github.com/getdnsapi/getdns/commit/df2997d9b762d705d5f7add338e460686c9bd88f
+Last-Update: 2024-12-10
+
+--- getdns-1.6.0.orig/src/test/check_getdns_dict_set_bindata.h
getdns-1.6.0/src/test/check_getdns_dict_set_bindata.h
+@@ -112,7 +112,7 @@
+ ASSERT_RC(getdns_dict_get_bindata(this_dict, "bindata", &retrieved_bindata),
+ GETDNS_RETURN_GOOD, "Return code from getdns_dict_get_bindata()");
+
+- ck_assert_msg(retrieved_bindata->size, second_bindata.size,
++ ck_assert_msg(retrieved_bindata->size == second_bindata.size,
+ "Expected retrieved bindata size == %d, got: %d",
+ second_bindata.size, retrieved_bindata->size);
+
diff --git a/debian/patches/series b/debian/patches/series
index 68cf200a..fa69b47f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@
0003-Fix-install-path-for-cmake-build-since-we-use-GNUIns.patch
0004-Fix-stubby.yml-install-path-for-debian.patch
0005-Fix-FindLibidn2-cmake.patch
+0006-Fix-incorrect-assertion.patch
--
2.45.2
signature.asc
Description: PGP signature
Bug#1075218: libx86: ftbfs with GCC-14
Control: tags 1075218 patch
Dear libx86 maintainer,
I have developed a fix for this failure to build from source with gcc-14
for the forthcoming trixie release and would be grateful if you would
consider merging it, please!
The merge request is available at:
<https://salsa.debian.org/kkamagui/libx86/-/merge_requests/1>
This patch fixes the incorrect return type declared for a function used
as a function pointer by correcting a type assignment for 64-bit
targets.
On Wed, Jul 03, 2024 at 12:34:43PM +, Matthias Klose wrote:
[abridged quoting]
> [This bug is targeted to the upcoming trixie release]
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
Fixed by this patch:
> thunk.c:150:17: error: initialization of ‘x86emuu32 (*)(X86EMU_pioAddr)’ {aka
> ‘unsigned int (*)(short unsigned int)’} from incompatible pointer type ‘long
> unsigned int (*)(short unsigned int)’ [-Wincompatible-pointer-types]
> thunk.c:153:17: error: initialization of ‘void (*)(X86EMU_pioAddr,
> x86emuu32)’ {aka ‘void (*)(short unsigned int, unsigned int)’} from
> incompatible pointer type ‘void (*)(short unsigned int, long unsigned int)’
> [-Wincompatible-pointer-types]
Not fixed in this patch:
> x86emu/debug.c:220:13: warning: variable ‘current’ set but not used
> [-Wunused-but-set-variable]
> x86emu/debug.c:247:11: warning: variable ‘p’ set but not used
> [-Wunused-but-set-variable]
> x86-common.c:193:17: warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
> x86-common.c:200:17: warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
> thunk.c:168:18: warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
> thunk.c:200:26: warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
> x86emu/prim_ops.c:1836:5: warning: this ‘else’ clause does not guard...
> [-Wmisleading-indentation]
> x86emu/prim_ops.c:1861:5: warning: this ‘else’ clause does not guard...
> [-Wmisleading-indentation]
I hope this helps!
I notice that as well as the declared packaging repository in your
namespace on salsa, there is also one under the debian namespace. This
can be confusing for contributors like me when seeking to raise a merge
request. Would it be worth considering getting yourself added with
suitable rights to be able to use the debian/libx86 repo as the
authoritative one?
Thanks,
Andrew
signature.asc
Description: PGP signature
Bug#1075615: vbetool: ftbfs with GCC-14
Control: tags 1075615 patch
Dear maintainer,
I have developed a fix for this failure to build from source with gcc-14
for the forthcoming trixie release and would be grateful if you would
consider merging it, please!
The merge request is available at:
<https://salsa.debian.org/kkamagui/vbetool/-/merge_requests/2>
The first commit fixes the failure to build from source. The second,
optional, commit deals with some further warnings that were not treated
as errors, resulting in a clean compilation on i386.
On Wed, Jul 03, 2024 at 12:47:18PM +, Matthias Klose wrote:
[abridged quoting]
> [This bug is targeted to the upcoming trixie release]
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
Fixed by first commit:
> vbetool.c:120:32: error: passing argument 1 of ‘munmap’ makes pointer from
> integer without a cast [-Wint-conversion]
> vbetool.c:121:35: error: passing argument 1 of ‘mmap’ makes pointer from
> integer without a cast [-Wint-conversion]
Fixed by second commit:
> vbetool.c:117:31: warning: variable ‘rc’ set but not used
> [-Wunused-but-set-variable]
> vbetool.c:332:61: warning: format ‘%x’ expects argument of type ‘unsigned
> int’, but argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
> vbetool.c:359:17: warning: variable ‘num_written’ set but not used
> [-Wunused-but-set-variable]
Not fixed (affects amd64 builds):
> vbetool.c:257:16: warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
> vbetool.c:258:17: warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
> vbetool.c:339:16: warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
> vbetool.c:340:17: warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
> vbetool.c:528:28: warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
I hope this helps!
Thanks,
Andrew
signature.asc
Description: PGP signature
Bug#1088895: [request-tracker-maintainers] Bug#1088895: request-tracker4: FTBFS: failing tests
Hey Santiago, Thank you for the report. I can reproduce this, now to track down what is going on... Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1074781: request-tracker5: tests occasionally fail in CI
Control: tags -1 - serious Dropping severity from Serious as the the tests are now flagged as flaky, so will stop impacting other packages. There is at least one other test[0] that is failing intermittently, but looking at how it failed, it might affect other tests. Yes, seeing the same behaviour elsewhere[1]. 167s t/web/installer.t .. 167s ok 1 - started plack server ok 167s ok 2 - GET http://localhost:2335/__test_warnings 167s ok 3 - Got startup warning 167s ok 4 - GET http://localhost:2335 167s ok 5 - at installer 167s # Testing language change 167s ok 6 - change language to french 167s ok 7 - Content is like "(?^:Pour commencer)" 167s ok 8 - change language to english 167s ok 9 - Content is like "(?^:Getting started)" 167s # Walking through install screens setting defaults 167s ok 10 167s ok 11 - Content contains "DatabaseType" 167s ok 12 - found database MySQL 167s ok 13 - found database PostgreSQL 167s ok 14 - found database Oracle 167s ok 15 - found database SQLite 167s ok 16 - Content contains "DatabaseName" 167s ok 17 - Content contains "Connection succeeded" 167s ok 18 167s ok 19 - set root password 167s ok 20 - set admin email 167s ok 21 - set addresses 167s ok 22 - Content contains "database" 167s ok 23 - Content contains "/RT_SiteConfig.pm" 167s ok 24 - Content contains "Finish" 167s ok 25 - Content contains "Login" 167s DBD::SQLite::st execute failed: attempt to write a readonly database at /usr/share/perl5/DBIx/SearchBuilder/Handle.pm line 634. ... and then many many errors due to failed INSERTs ... Cheers, Andrew [0] https://ci.debian.net/packages/r/request-tracker5/unstable/amd64/52549710/ [1] https://ci.debian.net/packages/r/request-tracker5/unstable/armel/52427660/ -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1081411: request-tracker4: tests occasionally fail in CI
Control: tags -1 normal Hey, I believe that I've fixed the intermittent issue with the tests failing in 4.4.7+dfsg-3 with [0]. However as I'm not 100% sure yet, I've set the tests as flaky for now. I'll keep this bug open until I'm 100% confident the tests are reliable. My apologies for causing people to waste their time looking into these tests. I hadn't realised how flaky they were. Cheers, Andrew [0] https://salsa.debian.org/request-tracker-team/request-tracker4/-/blob/master/debian/patches/use-io-socket-inet-in-tests.diff?ref_type=heads -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1074781: request-tracker5: tests occasionally fail in CI
Control: tags -1 normal Hey, I believe that I've fixed the intermittent issue with the tests failing in 5.0.7+dfsg-2 with [0]. However as I'm not 100% sure yet, I've set the tests as flaky for now. I'll keep this bug open until I'm 100% confident the tests are reliable. My apologies for causing people to waste their time looking into these tests. I hadn't realised how flaky they were. Cheers, Andrew [0] https://salsa.debian.org/request-tracker-team/request-tracker5/-/commit/44497367f88096a9f91439682b3c0460bf905eb0 -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#979332: Anyone working on this ? Is it just need some packaging work?
Hi I would like to see some progress on this as I use dokuwiki. I am willing to help out but I don't know what the resolution would look like. Is it just a matter of re-packaging something more modern in a way that avoids a particular issue? I am certainly no PHP expert so it would be a fair amount of learning for me to work on that if that is required? Andrew
Bug#1069450: socket_wrapper and the time_t 64-bit is hard
Just a warning that trying to brute force a fix for this is likely to end badly. A lot of developer time was spent to get to this current delicate situation, which relied on the narrow behaviour that is now eliminated by the Debian time_t 64 transition rules. Socket-wrapper starts with: /* * Make sure we do not redirect (f)open(at)() or fcntl() to their 64bit * variants */ #undef _FILE_OFFSET_BITS This was added in https://gitlab.com/cwrap/socket_wrapper/-/commit/bbe14cc3200ca553b13ed49357e2e88ba487eeaa Setting -D_FILE_OFFSET_BITS=64 will break the fcntl64 wrapper and so break Samba's tests. I don't know if there is a good fix for this actually. Andrew Bartlett
Bug#1059222: src:pv: fails to migrate to testing for too long: FTBFS on armhf
> This is a quick word to let you know that I've disabled valgrind tests > on armhf in the Debian package. They were failing since the 1.8.5 upload > [...] Thank you, I agree with this approach. The evidence I have seen so far suggests that the failures are due to issues with the way valgrind itself behaves on that architecture. -- Andrew Wood
Bug#1014124: nomacs: CVE-2020-23884
I think this should be filled against https://tracker.debian.org/pkg/qtimageformats-opensource-src Explanation: https://github.com/nomacs/nomacs/issues/516#issuecomment-1578313635
Bug#1030510: Info received (Bug#1030510: Info received (Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout)))
Hi Paul, On 11/02/2023 20:17, Paul Gevers wrote: Well, the buildd's don't run bookworm, but they run stable (which currently is bullseye). Sorry, I was told this was Bookworm blocker when this was emailed to me, not a Bullseye one. If the intention is to release 10.11 for Bookworm, surely that is what should be tested? Given that the entire underlying base kernal and OS will be different? Or is the intention to release update Bullseye to have 10.11? Kind Regards -- Andrew (LinuxJedi) Hutchings Chief Contributions Officer MariaDB Foundation
Bug#1030510: Info received (Bug#1030510: Info received (Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout)))
Hi Otto, We are trying to figure this out but are going in completely blind as we don't have Bookworm on our S390x at the moment, and every other OS we test against is passing. This also doesn't look like anything 10.11 specific, some of this is code that hasn't been touched in a long time. I'm assuming other MariaDB versions are failing for you in similar ways on Bookworm? Some of these failurs are definitely this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020831 Are we 100% sure that Bookworm's kernel on S390x is good? Kind Regards Andrew On 07/02/2023 16:36, Otto Kekäläinen wrote: Control: severity -1 normal Control: tags -1 help The s390x build is still failing after 5 retries at https://buildd.debian.org/status/package.php?p=mariadb. The issue seems to be with Debian buildd, as the Launchpad s390x build passed just fine without the need to retry anything: https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.11/+builds?build_text=&build_state=all It seems to crash on different tests every time. I could disable the entire test suite, but that feels like a bad idea. I need help - if the s390x build does not pass, the 10.11 cannot enter Debian testing (Bookworm). (this email is for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030510) -- Andrew (LinuxJedi) Hutchings Chief Contributions Officer MariaDB Foundation
Bug#1029342: Fixed version of request-tracker5 released
Hi bert, Thank you for the detailed information, and the TL;DR;. I now have a working version of the request-tracker5 package, which I've just uploaded to unstable. So, our immediate concern is resolved. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1011845: FTBFS: make[1]: *** [Makefile:272: testdeps] Error 1
Hey Lucas, I expect the the output from rt-test-dependencies in this case is a false lead. I believe this is actually caused by the update of OpenSSL to 3.0 causing one of the tests to fail. I filed a bug for this yesterday: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013730 . Today I happened update our packaging to resolve the dependencies issue as mentioned in this bug report. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1013730: FTBFS: S/MIME test fails with OpenSSL 3.0
Package: request-tracker4 Version: 4.4.5+dfsg-1 Severity: serious Tags: ftbfs upstream Justification: fails to build from source To preempt other people reporting this. The unit test t/mail/smime/realmail.t fails with OpenSSL 3.0.x due to DES being deprecated and the sample emails used by the test use DES. I have a fix for this, but I want to hear from upstream first as I'm not convinced that enabling DES is the correct approach. This issue is also in 5.0-trunk. Cheers, Andrew -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages request-tracker4 depends on: ii dbconfig-common 2.0.21 ii debconf [debconf-2.0]1.5.79 ii fonts-droid-fallback 1:6.0.1r16-1.1 ii fonts-noto-hinted20201225-1 ii libapache-session-perl 1.94-1 ii libbusiness-hours-perl 0.13-1 ii libcgi-emulate-psgi-perl 0.23-2 ii libcgi-pm-perl 4.54-1 ii libcgi-psgi-perl 0.15-3 ii libclass-accessor-perl 0.51-1 ii libclone-perl0.45-1+b2 ii libconvert-color-perl0.12-1 ii libcpanel-json-xs-perl 4.29-1 ii libcrypt-eksblowfish-perl0.009-3 ii libcrypt-x509-perl 0.54-1 ii libcss-minifier-xs-perl 0.13-1+b1 ii libcss-squish-perl 0.10-1 ii libdata-guid-perl0.050-1 ii libdata-ical-perl0.24+dfsg-1 ii libdata-page-pageset-perl1.02-2 ii libdate-extract-perl 0.06-2 ii libdate-manip-perl 6.88-1 ii libdatetime-format-natural-perl 1.13-1 ii libdatetime-locale-perl 1:1.35-1 ii libdatetime-perl 2:1.57-1 ii libdbi-perl 1.643-3+b2 ii libdbix-searchbuilder-perl 1.71-2 ii libdevel-globaldestruction-perl 0.14-2 ii libemail-address-list-perl 0.06-1 ii libemail-address-perl1.912-1 ii libencode-perl 3.17-1 ii libfile-sharedir-perl1.118-1 ii libfile-which-perl 1.27-1 ii libgd-graph-perl 1.54~ds-3 ii libgd-text-perl 0.86-10 ii libgnupg-interface-perl 1.02-1 ii libgraphviz-perl 2.24-1 ii libhtml-formattext-withlinks-andtables-perl 0.07-2 ii libhtml-formattext-withlinks-perl0.15-2 ii libhtml-gumbo-perl 0.18-2+b4 ii libhtml-mason-perl 1:1.59-1 ii libhtml-mason-psgihandler-perl 0.53-2 ii libhtml-quoted-perl 0.04-2 ii libhtml-rewriteattributes-perl 0.05-2 ii libhtml-scrubber-perl0.19-1 ii libhttp-message-perl 6.37-1 ii libipc-run-perl 20200505.0-1 ii libipc-run3-perl 0.048-2 ii libjavascript-minifier-xs-perl 0.15-1+b1 ii libjson-perl 4.06000-1 ii liblist-moreutils-perl 0.430-2 ii liblocale-maketext-fuzzy-perl0.11-2 ii liblocale-maketext-lexicon-perl 1.00-2 ii liblog-dispatch-perl 2.70-1 ii libmailtools-perl2.21-1 ii libmime-tools-perl 5.509-2 ii libmime-types-perl 2.22-1 ii libmodule-refresh-perl 0.18-1 ii libmodule-versions-report-perl 1.06-3 ii libnet-cidr-perl 0.21-1 ii libnet-ip-perl 1.26-2 ii libnet-ldap-perl 1:0.6800+dfsg-1 ii libnet-ssleay-perl 1.92-2 ii libperlio-eol-perl 0.17-2 ii libplack-perl1.0048-1 ii libregexp-common-net-cidr-perl 0.03-1 ii libregexp-common-perl2017060201-2 ii libregexp-ipv6-perl 0.03-3 ii librole-basic-perl
Bug#1006369: re-installation Buster 10.10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 there is the follow-up report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006442 -BEGIN PGP SIGNATURE- iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCYhzblgAKCRDn6sEfJS3n C9CQAJ91gxj3o33yl4/XpLLB7Fsx0TNUTwCfRpyG/qUu3n1D7W2OEee6fs+IsOw= =ZX4M -END PGP SIGNATURE-
Bug#987360: swaylock: Occassional unlock without password entered
Pelle, Would you be able to add a stack trace? Here, or directly with the upstream: https://github.com/swaywm/swaylock/issues/181 Thanks.
Bug#984967: GHB build bulls-eye
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is the missing part for Debian-11 bulls-eye: > andrew@bulls-eye:~/HandBrake$ ate show libayatana-appindicator-dev > Package: libayatana-appindicator-dev > Version: 0.5.5-2 > State: installed > Automatically installed: no > Priority: optional > Section: libdevel > Maintainer: Ayatana Packagers > Architecture: amd64 > Uncompressed Size: 186 k > Depends: libgtk2.0-dev, gir1.2-ayatanaappindicator-0.1 (= 0.5.5-2), > libdbusmenu-glib-dev (>= 0.1.8), libayatana-appindicator1 (= > 0.5.5-2) Description: Ayatana Application Indicators (development files, > GTK-2+ version) A library and indicator to take menus from applications and > place them in the panel. > This package contains files that are needed to build applications (GTK-2+ > version). Homepage: > https://github.com/AyatanaIndicators/libayatana-appindicator Tags: > devel::library, role::devel-lib Referring to the build-dependencies: > https://handbrake.fr/docs/en/1.3.0/developer/install-dependencies-debian.html since this is missing in bullseye: > intltool > libappindicator-dev === > libdbus-glib-1-dev Now I seemingly have a complete build and install: > : gmake[4]: Leaving directory '/home/andrew/HandBrake/build/gtk/po' > : touch stamp-po > : gmake[3]: Leaving directory '/home/andrew/HandBrake/build/gtk/po' > : gmake[3]: Entering directory '/home/andrew/HandBrake/build/gtk' > : gmake[3]: Leaving directory '/home/andrew/HandBrake/build/gtk' > : gmake[2]: Leaving directory '/home/andrew/HandBrake/build/gtk' > : gmake[1]: Leaving directory '/home/andrew/HandBrake/build/gtk' > --- > time end: Thu May 13 17:01:01 2021 > duration: 25 minutes, 33 seconds (1533.05s) > result: SUCCESS > ------- > Build is finished! > You may now cd into ./build and examine the output. > andrew@bulls-eye:~/HandBrake$ ls -l > total 144 > -rw-r--r-- 1 andrew andrew 3557 May 13 16:33 AUTHORS.markdown > drwxr-xr-x 1 andrew andrew 128 May 13 17:00 build > -rw-r--r-- 1 andrew andrew 3261 May 13 16:32 CODE_OF_CONDUCT.md > -rwxr-xr-x 1 andrew andrew 629 May 13 16:32 configure > drwxr-xr-x 1 andrew andrew 438 May 13 16:33 contrib > -rw-r--r-- 1 andrew andrew 382 May 13 16:32 CONTRIBUTING.md > -rw-r--r-- 1 andrew andrew 18092 May 13 16:32 COPYING > drwxr-xr-x 1 andrew andrew 316 May 13 16:35 download > drwxr-xr-x 1 andrew andrew96 May 13 16:32 graphics > drwxr-xr-x 1 andrew andrew 470 May 13 16:35 gtk > drwxr-xr-x 1 andrew andrew 1596 May 13 16:33 libhb > -rw-r--r-- 1 andrew andrew 1029 May 13 16:32 LICENSE > drwxr-xr-x 1 andrew andrew 8494 May 13 16:33 macosx > drwxr-xr-x 1 andrew andrew 184 May 13 16:33 make > -rw-r--r-- 1 andrew andrew 89275 May 13 16:33 NEWS.markdown > drwxr-xr-x 1 andrew andrew 106 May 13 16:32 pkg > drwxr-xr-x 1 andrew andrew 162 May 13 16:33 preset > -rw-r--r-- 1 andrew andrew 2274 May 13 16:33 README.markdown > drwxr-xr-x 1 andrew andrew 312 May 13 16:33 scripts > -rw-r--r-- 1 andrew andrew 1219 May 13 16:32 SECURITY.md > drwxr-xr-x 1 andrew andrew 218 May 13 16:33 test > -rw-r--r-- 1 andrew andrew 2526 May 13 16:33 THANKS.markdown > -rw-r--r-- 1 andrew andrew 1720 May 13 16:33 TRANSLATION.markdown > drwxr-xr-x 1 andrew andrew 4 May 13 16:32 win > andrew@bulls-eye:~/HandBrake$ sudo make --directory=build install > [sudo] password for andrew: > make: Entering directory '/home/andrew/HandBrake/build' > /usr/bin/cp ./HandBrakeCLI /usr/local/bin/HandBrakeCLI > make -C ./gtk/ prefix=/usr/local install > make[1]: Entering directory '/home/andrew/HandBrake/build/gtk' > Making install in src > make[2]: Entering directory '/home/andrew/HandBrake/build/gtk/src' > make[3]: Entering directory '/home/andrew/HandBrake/build/gtk/src' > /usr/bin/mkdir -p '/usr/local/bin' > /bin/bash ../libtool --mode=install /usr/bin/install -c ghb > '/usr/local/bin' libtool: install: /usr/bin/install -c > ghb /usr/local/bin/ghb for icon in hb-icon.svg fr.handbrake.ghb.svg; do \ > mkdir -p //usr/local/share/icons/hicolor/scalable/apps/; \ > /usr/bin/install -c -m > 644 /home/andrew/HandBrake/build/../gtk/src/$icon > //usr/local/share/icons/hicolor/scalable/apps/$icon; > \ done Updating Gtk icon cache. > gtk-update-icon-cache: Cache file created successfully. > mkdir -p //usr/local/share/applications/; \ > /usr/bin/install -c -m > 644 /home/andrew/HandBrake/build/../gtk/src/fr.handbrake.ghb.desktop > //usr/loca
Bug#925134: grub-efi-amd64-signed: doesn't mount cryptodisk
For what it's worth, I am unable to reproduce it on the latest weekly build of Bullseye. Paolo, are you OK for this bug to be closed? -- Regards, A
Bug#981804: yubioath-desktop: fails to read yubikey
Any chance this bug is the root cause of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982157 ?
Bug#961076: NXNS Attack (CVE-2020-12667)
Dear Maintainers, Is there still a plan to backport a fix for CVE-2020-12667 into Buster? Looking at the changelog [1], there is nothing that indicates it is already fixed. [1] https://metadata.ftp-master.debian.org/changelogs//main/k/knot-resolver/knot-resolver_3.2.1-3_changelog -- With regards, A
Bug#970215: otb-bin: programs fail with symbol lookup error
Package: otb-bin Version: 7.1.0+dfsg-1+b1 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? otbcli -h * What was the outcome of this action? /usr/bin/otbApplicationLauncherCommandLine: symbol lookup error: /usr/lib/x86_64-linux-gnu/libOTBApplicationEngine-7.1.so.1: undefined symbol: _ZN3itk9Directory16GetNumberOfFilesEv * What outcome did you expect instead? no error -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages otb-bin depends on: ii libc62.31-3 ii libgcc-s110.2.0-7 ii libinsighttoolkit4.134.13.3withdata-dfsg1-2 ii libotb-apps 7.1.0+dfsg-1+b1 ii libotbcommandline-7.1-1 7.1.0+dfsg-1+b1 ii libotbcommon-7.1-1 7.1.0+dfsg-1+b1 ii libstdc++6 10.2.0-7 otb-bin recommends no packages. otb-bin suggests no packages. -- no debconf information
Bug#969224: cdimage.debian.org: Error installing Debian 10.5 from flash stick with Extlinux
This is not a well supported method. Just use dd to write a netinst or a DVD image straight to the stick and then boot from it directly. dd if=debian-10.5.0-amd64-DVD-1.iso of=/dev/sdX bs=4M oflag=sync status=progress That will put a bootable partition on the stick and then the install will proceed. You may need to use parted / fdisk afterwards to make the USB usable for any other purpose. This method is destructive of any data already on the stick. On Sat, Aug 29, 2020 at 2:18 PM Сергей Фёдоров wrote: > Package: cdimage.debian.org > Severity: critical > Justification: breaks the whole system > > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.7.0-3-amd64 (SMP w/8 CPU threads) > Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Created a USB flach stick using the" gparted " MBR-partition table. > GPT-partition table failed to get a working version of the Debian > installation. > Created an Ext4-partition and its label. Set the partition "boot" > attribute. > > Created a bootable flash drive: > > # dd conv=notrunc bs=440 count=1 if=/usr/lib/EXTLINUX/mbr. bin of=/dev/xxx > where xxx is the name of the u-VA, for example, sdf. > # extlinux --install "folder path" (for example " /media/u1/UP1/"), where" > UP1 " is partition name > > For Debian 10.4 copied from a folder: > > > http://ftp.nl.debian.org/debian/dists/Debian10.4/main/installer-amd64/current/images/hd-media/ > or from (for GTK) > > http://ftp.nl.debian.org/debian/dists/Debian10.4/main/installer-amd64/current/images/hd-media/gtk/ > > vmlinuz > initrd.gz > > and copied "debian-10.4.0-amd64-DVD-1.iso" > > or > > For Debian 10.5 copied from the folder: > > > http://ftp.nl.debian.org/debian/dists/Debian10.5/main/installer-amd64/current/images/hd-media/ > or from (for GTK) > > http://ftp.nl.debian.org/debian/dists/Debian10.5/main/installer-amd64/current/images/hd-media/gtk/ > > vmlinuz > initrd.gz > > and copied "debian-10.5.0-amd64-DVD-1.iso» > > In both cases, when installing Debian from a flash drive, I received the > message: > > Load installer components from an ISO installer. > > No modules were found. This pfobably is due to a mismatch between the > kernel > by this version of the installer and the kernel version available in the > archieve. > > and the installation had to be stopped. > > For Debian 10.3 copied from the folder: > > > http://ftp.nl.debian.org/debian/dists/Debian10.3/main/installer-amd64/current/images/hd-media/ > or from (for GTK) > > http://ftp.nl.debian.org/debian/dists/Debian10.3/main/installer-amd64/current/images/hd-media/gtk/ > > vmlinuz > initrd.gz > > and copied "debian-10.3.0-amd64-DVD-1.iso" > > and everything was established without problems. > > Copy Debian 10.3, 10.4, and 10.5 to a USB stick in the device root, > download > with it, the installation of Debian passes without problems. > > For example: > > dd if="./debian-10.5.0-amd64-DVD-1.iso" of=/dev/xxx bs=1M status=progress > where xxx is the name of the u-VA, for example, sdf. > > Installing Debian 10.3, 10.4, and 10.5 from a DVD does not cause these > problems. > >
Bug#967017: [request-tracker-maintainers] Bug#967017: Bug#967017: request-tracker4: FTBFS: can't exec /usr/bin/gpg
On Mon, 2020-08-03 at 15:48 +0100, Dominic Hargreaves wrote: > This seems related to changes in libgnupg-interface-perl, which on > the > face of it is ignoring the instruction to use 'gpg1' (configured via > the test_gnupg_interface_gpg1.diff patch). I can't immediately see > why > that's happening but it seems related to the recent changes > libgnupg-interface-perl. > > Andrew, any clues? Yes, this is related. I hadn't spotted it because I have both gpg and gpg1 installed on my workstation. If gpg isn't present, then I can reproduce this. The issue is with how GnuPG::Interface checks for the version of the gpg binary that is being run. A minor change to RT::Crypt::GnuPG in RT fixes this. I've written the patch to resolve this bug, pushed it to Salsa and raised a bug with Best Practical: https://rt.bestpractical.com/SelfService/Display.html?id=36623 I also find it a little puzzling though, I've checked the source in unstable and the patch name is test_gnupg-interface_gpg1.diff but the name of the patch used in the build log is test_gnupg- interface_gnupg.diff . This isn't in git, bullseye or unstable. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud:| This space intentionally left blank https://catalystcloud.nz|
Bug#964878: GnuPG::Interface doesn't work with Taint mode
Hey, Because of the use of "exec", GnuPG::Interface isn't Taint safe. I've prepared a patch and will hopefully have it uploaded soon. Reported upstream with a patch here: https://rt.cpan.org/Ticket/Display.html?id=133041 . Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud:| This space intentionally left blank https://catalystcloud.nz|
Bug#964879: [request-tracker-maintainers] Bug#964879: Bug#964879: request-tracker4: FTBFS: broken by libgnupg-interface-perl
Hey, It took a bit of digging. This is caused by an interaction between RT and GnuPG::Interface. I believe that RT is using the GnuPG::Interface correctly. GnuPG::Interface knows the version of the GPG binary being used, and uses the --pinentry-mode argument if that is supported - which needs gpg v2.2. If the binary is changed after the object has been instantiated then the version isn't changed. I've updated our libgnupg-interface-perl with a patch to fix this, and submitted it upstream here: https://rt.cpan.org/Ticket/Display.html?id=133021 Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud:| This space intentionally left blank https://catalystcloud.nz|
Bug#964879: [request-tracker-maintainers] Bug#964879: request-tracker4: FTBFS: broken by libgnupg-interface-perl
Hmmm, this is likely a bug in libgnupg-interface-perl v1.00. It should be able to work with both gpg v1 and v2.4, and certainly as I was reviewing the packaging for v1.00 it certainly tries to. Our RT v4.4.4 packages are forcing the use of gpg v1. I'll have a look at libgnupg-interface-perl tonight. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud:| This space intentionally left blank https://catalystcloud.nz|
Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency
On Mon, 2020-06-29 at 08:46 -0400, Michael Stone wrote: > Package: samba-libs > Version: 2:4.12.3+dfsg-2 > Severity: critical > Justification: breaks the whole system > > The new samba-libs package changes the soname of libndr from > libndr.so.0 to > libndr.so.1 without reflecting this change in the package name. sssd- > ad-common > has a dependency on samba-libs (>= 2:4.11.5+dfsg) and links to > libndr.so.0. > When the samba-libs package is updated and libndr.so.0 disappears > sssd fails to > start, which then makes a system's remote users unavailable. (Worse, > this > doesn't happen until the next time sssd restarts--which may not be > until the > next reboot.) > > It's not clear why the samba-libs package doesn't include the so > number, but at > the very least it needs a set of dependencies to avoid breaking sssd- > ad-common. We can't put a version number in samba-libs as there are multiple public libraries in there. (Upstream) Samba doesn't promise not to keep doing this - the underlying change has happened before, but this time we were honest and bumped the .so - so sssd may need to have a dependency on the Samba version it built against. Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba
Bug#962156: josm: Could not initialize class org.openstreetmap.josm.data.cache.JCSCacheManager
Package: josm
Version: 0.0.svn16538+dfsg-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I opened JOSM and tried to download an area of data from OSM but before the
JMapViewer window opened JOSM crashed with:
{{{
Revision:16538
Is-Local-Build:false
Build-Date:1970-01-23 23:34:59
Debian-Release:0.0.svn16538+dfsg-2
Build-Name:Debian
Identification: JOSM/1.5 (16538 Debian en_AU) Linux Debian GNU/Linux
bullseye/sid
Memory Usage: 441 MB / 3976 MB (138 MB allocated, but free)
Java version: 11.0.7+10-post-Debian-3, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
Java package: openjdk-11-jre:amd64-11.0.7+10-3
Java ATK Wrapper package: libatk-wrapper-java:all-0.38.0-1
libcommons-compress-java: libcommons-compress-java:all-1.20-1
libcommons-logging-java: libcommons-logging-java:all-1.2-2
fonts-noto: fonts-noto:all-20200323-1
liboauth-signpost-java: liboauth-signpost-java:all-1.2.1.2-3
VM arguments: [--add-modules=java.scripting,java.sql, -Djosm.restart=true,
-Djava.net.useSystemProxies=true]
Plugins:
+ Mapillary (1.5.23)
+ apache-commons (35362)
+ apache-http (35092)
+ buildings_tools (35474)
+ editgpx (35248)
+ javafx-unixoid (35375)
+ jna (35092)
+ photo_geotagging (35405)
+ photoadjust (35405)
+ poly (35248)
+ reverter (35474)
+ tageditor (35258)
+ turnlanes (35405)
+ turnlanes-tagging (283)
+ turnrestrictions (35405)
+ undelete (35474)
+ utilsplugin2 (35476)
Tagging presets:
+ /usr/share/josm/data/defaultpresets.xml
+
https://raw.githubusercontent.com/yopaseopor/traffic_signs_preset_JOSM/master/AU.zip
+ https://raw.githubusercontent.com/osmlab/name-suggestion-
index/master/dist/name-suggestions.presets.xml
Map paint styles:
- /usr/share/josm/styles/standard/potlatch2.mapcss
- https://raw.githubusercontent.com/yopaseopor/indoormap/master/indoormap-
style.mapcss
- https://josm.openstreetmap.de/josmfile?page=Styles/Admin_Boundaries&zip=1
-
https://josm.openstreetmap.de/josmfile?page=Styles/SlovakiaBicycleRoutes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Cycleways&zip=1
-
https://josm.openstreetmap.de/josmfile?page=Styles/Enhanced_Lane_and_Road_Attributes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/iD&zip=1
-
https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1
-
https://josm.openstreetmap.de/josmfile?page=Styles/LessObtrusiveNodes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/MTB&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Mountains&zip=1
- https://raw.githubusercontent.com/OpenSidewalks/OpenSidewalks-
Schema/master/open_sidewalks.mapcss
- https://josm.openstreetmap.de/josmfile?page=Styles/Osmc&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/PublicTransport&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/sac_scale&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Sidewalks&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Surface&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Fixme&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Noname&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/MapWithAI&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lit&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/LitObjects&zip=1
Validator rules:
+ /validator/indoorhelper.validator.mapcss
Last errors/warnings:
- E: Failed to locate image
'
https://koordinates.a.ssl.fastly.net/media/settings/branding/favicon-lds.ico
'
- E: Failed to locate image
'https://www.spatial.nsw.gov.au/__data/assets/file/0017/224801/favicon.ico'
- E: Failed to locate image
'https://www.spatial.nsw.gov.au/__data/assets/file/0017/224801/favicon.ico'
- E: Failed to locate image
'https://www.spatial.nsw.gov.au/__data/assets/file/0017/224801/favicon.ico'
- E: Failed to locate image
'https://www.spatial.nsw.gov.au/__data/assets/file/0017/224801/favicon.ico'
- W: javax.imageio.IIOException: Caught exception during read:. Cause:
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1
- E: Failed to locate image 'traffic_signs_presets/tunnel.png'
- W: Tunnel: Could not get presets icon traffic_signs_presets/tunnel.png
- E: Handled by bug report queue: java.lang.NoClassDefFoundError: Could not
initialize class org.openstreetmap.josm.data.cache.JCSCacheManager
- E: Handled by bug report queue: java.lang.NoClassDefFoundError: Could not
initialize class org.openstreetmap.josm.data.cache.JCSCacheManager
=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.
Warning issued by: BugReportExceptionHandler#handleException
=== STACK TRACE ===
Thread: AWT-EventQueue-0 (20) of main
java.lang.NoClassDefFoundError: Could not initialize class
org.openstreetmap.josm.data.cache.JCSCach
Bug#958533: [Python-modules-team] Bug#958533: pyxdg: autopkgtest regression: still tests Python2 package
On Thu, Apr 23, 2020 at 3:12 PM Emmanuel Arias wrote: > I've push to salsa the fix. I will need sponsorship Uploading now. Thanks for your work! -- Andrew Starr-Bochicchio Debian Developer <http://qa.debian.org/developer.php?login=asb> Ubuntu Developer <https://launchpad.net/~andrewsomething> PGP/GPG Key ID: 3B56E2BBD53FDCB1
Bug#953376: [Pkg-mailman-hackers] Bug#953376: Mailman 2 will be removed from Debian
Thijs Kinkhorst wrote: >On Sun, March 8, 2020 20:01, Scott Kitterman wrote: >> Package: src:mailman >> Version: 1:2.1.29-1 >> Severity: serious >> Justification: Policy 2.2.1 >> >> This package Depends/Build-Depends on python-dnspython which is an NBS >> cruft package. Please update your package to use python3-dnspython, >> which is still provided (if the package will be ported to python3). >Mailman 2.1.x is Python 2 only. >Upstream has explicitly indicated there will be no effort to port it to Python >3: >https://mail.python.org/pipermail/mailman-users/2019-April/084333.html >So it seems the time has come to remove Mailman 2 from Debian, and let people >migrate to Mailman 3. I thought this may be the case. I was looking at the possibility of whether I could build 2.1.30 even if it was to go in backports until the eventual removal of the package on the next Debian version, but would this removal cause problems for this? Andrew.
Bug#955432: closing 955432
close 955432 thanks
Bug#955474: [Pkg-samba-maint] Bug#955474: FTBFS: fatal error: stropts.h: No such file or directory
On Wed, 2020-04-01 at 11:18 +0200, Raphaël Hertzog wrote: > Source: samba > Version: 2:4.11.5+dfsg-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in > the past) > User: de...@kali.org > Usertags: origin-kali This is a python bug, it should not be setting HAVE_STROPTS_H. See bug 954582 -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba
Bug#954582: samba: FTBFS glibc/stropts/python issue.
On Tue, 2020-03-31 at 02:09 +0100, peter green wrote: > The samba FTBFS is blocking the python 3.8 transition in raspbian > bullseye, so I decided to take a look. Thanks for digging into this. I've updated the Samba bug below, and I think this is a Python bug and needs to be fixed in Python. The correct fix is for Python not to leak these defines. Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba
Bug#938305: marked as pending in pyxdg
Control: tag -1 pending Hello, Bug #938305 in pyxdg reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/modules/pyxdg/-/commit/fd785072b9b9947aeb15d7e90dbcf638accf8d65 Drop Python 2 package (Closes: #938305). (this message was generated automatically) -- Greetings https://bugs.debian.org/938305
Bug#940839: openshot-qt: cannot start, crashes immediately
ui_util:INFO Binding event MainWindow:actionTransitionsShowCommon_trigger
ui_util:INFO Binding event MainWindow:actionTimelineZoomIn_trigger
ui_util:INFO Binding event MainWindow:actionTimelineZoomOut_trigger
ui_util:INFO Binding event MainWindow:actionTitle_trigger
ui_util:INFO Binding event MainWindow:actionAnimatedTitle_trigger
ui_util:INFO Binding event MainWindow:actionFullscreen_trigger
ui_util:INFO Binding event MainWindow:actionAbout_trigger
ui_util:WARNING Icon theme gtk-info not found. Will use backup icon.
ui_util:INFO Binding event MainWindow:actionThumbnailView_trigger
ui_util:WARNING Icon theme view-list-icons not found. Will use backup
icon.
ui_util:INFO Binding event MainWindow:actionDetailsView_trigger
ui_util:WARNING Icon theme view-list-details not found. Will use backup
icon.
ui_util:INFO Binding event MainWindow:actionReportBug_trigger
ui_util:INFO Binding event MainWindow:actionAskQuestion_trigger
ui_util:WARNING Icon theme im-message-new not found. Will use backup icon.
ui_util:INFO Binding event MainWindow:actionTranslate_trigger
ui_util:WARNING Icon theme stock_person not found. Will use backup icon.
ui_util:INFO Binding event MainWindow:actionDonate_trigger
ui_util:INFO Binding event MainWindow:actionHelpContents_trigger
ui_util:INFO Binding event MainWindow:actionSimple_View_trigger
ui_util:INFO Binding event MainWindow:actionAdvanced_View_trigger
ui_util:WARNING Icon theme get-hot-new-stuff not found. Will use backup
icon.
ui_util:INFO Binding event MainWindow:actionFreeze_View_trigger
ui_util:WARNING Icon theme locked not found. Will use backup icon.
ui_util:INFO Binding event MainWindow:actionUn_Freeze_View_trigger
ui_util:WARNING Icon theme locked not found. Will use backup icon.
ui_util:INFO Binding event MainWindow:actionShow_All_trigger
ui_util:WARNING Icon theme document-open-recent not found. Will use backup
icon.
ui_util:INFO Binding event MainWindow:actionProfile_trigger
ui_util:INFO Binding event MainWindow:actionAdd_to_Timeline_trigger
ui_util:INFO Binding event MainWindow:actionPreview_File_trigger
ui_util:INFO Binding event MainWindow:actionRemove_from_Project_trigger
ui_util:INFO Binding event MainWindow:actionFile_Properties_trigger
ui_util:INFO Binding event MainWindow:actionRemoveTrack_trigger
ui_util:INFO Binding event MainWindow:actionRemoveMarker_trigger
ui_util:INFO Binding event MainWindow:actionAddTrackAbove_trigger
ui_util:INFO Binding event MainWindow:actionAddTrackBelow_trigger
ui_util:INFO Binding event MainWindow:actionRemoveEffect_trigger
ui_util:INFO Binding event MainWindow:actionSplitClip_trigger
ui_util:INFO Binding event MainWindow:actionProperties_trigger
ui_util:INFO Binding event MainWindow:actionRenameTrack_trigger
ui_util:WARNING Icon theme gtk-edit not found. Will use backup icon.
ui_util:INFO Binding event MainWindow:actionUpdate_trigger
ui_util:WARNING Icon theme package-upgrade not found. Will use backup
icon.
ui_util:INFO Binding event MainWindow:actionTutorial_trigger
ui_util:WARNING Icon theme im-message-new not found. Will use backup icon.
ui_util:INFO Binding event MainWindow:actionAnimation_trigger
ui_util:INFO Binding event MainWindow:actionLockTrack_trigger
ui_util:INFO Binding event MainWindow:actionUnlockTrack_trigger
ui_util:WARNING Icon theme transform-move not found. Will use backup icon.
ui_util:INFO Binding event MainWindow:actionEditTitle_trigger
ui_util:WARNING Icon theme gtk-edit not found. Will use backup icon.
ui_util:INFO Binding event MainWindow:actionDuplicateTitle_trigger
ui_util:INFO Binding event MainWindow:actionClearHistory_trigger
files_treeview:INFO currentChanged
files_model:INFO updating files model.
transition_model:INFO updating transitions model.
effects_model:INFO updating effects model.
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
effects_model:INFO category: Video
properties_model:INFO updating clip properties model.
transition_model:INFO updating transitions model.
version:INFO Found current version: {"openshot_version": "2.4.4"}
files_model:INFO updating files model.
main_window:INFO InitCacheSettings
main_window:INFO cache-mode: CacheMemory
main_window:INFO cache-limit-mb: 250
main_window:INFO Creating CacheMemory object with 262144000 byte limit
preview_thread:INFO QThread Start Method Invoked
preview_thread:INFO ini
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Hi, Is there going to be an ACK or NACK decision on this before the buster release? As an outsider I understand the advantages of Wayland, but I am concerned about the implications of Wayland as default at this point to a "stable" release. Having the whole session and apps lost if the shell crashes is a large regression compared to X11. Other issues such as screen-sharing not working will appear odd to users when it worked before (there is work upstream here so hopefully this will be fixed for the next stable release). And there also seem to be other known issues noted in previous comments such as drag and drop causing crashes and accessibility issues etc. Andrew
Bug#866898: Fwd: Re: Bug #866898 - Xorg issues
Forwarded Message Subject:Re: Bug #866898 - Xorg issues Date: Sun, 10 Mar 2019 20:44:24 + From: Matthew Vernon To: Andrew M.A. Cater Hi, On 10/03/2019 14:06, Andrew M.A. Cater wrote: Lurking in Debian BSP in Cambridge: does the above bug still apply? This was from an upgrade from Jessie -> Stretch and the end of the message chain suggests there's a workaround/ It's still a problem here, I'm afraid. I've not tried editing bash_logout, but as the issue is typically when switching out of X (rather than ending a login session), I doubt that'll fix it. Regards, Matthew
Bug#892812: Fwd: Libdrm-radeon1 bug
Julien, This version is no longer in Buster - kernel version is now 4.19 and libdrm-radeon1 is now at 2.4.97 rather than 2.4.90 . On an AMD E-300 with Radeon, I cannot reproduce this bug. Hardware here is a Lenovo x121e which reports AMD/ATI Wrestler [Radeon HD 6310] Is this still a problem for you?
Bug#895271: konqueror: crahses while running programms which try to start it
There have been two subsequent versions of Konqueror uploaded to Buster since this problem. Can't reproduce this on current version: 4.18.12.0-1 . Is this still a problem for you?
Bug#921637: Fixed in ronn-NG 0.8.1
Hi folks, I have released a non-beta Ronn-NG 0.8.1 release which includes this fix, if you wanted to include a version that does not require bugfix patches. Cheers, Andrew
Bug#921637: [pkg-go] Bug#921637: FTBFS: /usr/lib/ruby/vendor_ruby/ronn/roff.rb:165:in `block_filter': undefined method
I've confirmed this is the https://github.com/apjanke/ronn-ng/issues/24 bug in ronn-ng. It looks liike an easy fix and I have pushed a ronn-ng 0.8.1.beta.1 gem/release with the fix. Are you able to test against a prerelease gem? I've tested locally and it fixed the problem for git-lfs man generation. I've also added an ordered-list example to Ronn-NG's internal test suite. Cheers, Andrew
Bug#921637: [pkg-go] Bug#921637: FTBFS: /usr/lib/ruby/vendor_ruby/ronn/roff.rb:165:in `block_filter': undefined method
Hi folks. ronn-ng maintainer here. I've prioritized this bug since it's causing problems for Debian package builds. Cheers, Andrew Janke
Bug#921305: zfs-dkms: fails to upgrade from stretch
Similarly fails on fresh buster install from Debian Alpha5 install media. On Mon, 04 Feb 2019 03:47:36 +0100 Andreas Beckmann wrote: > Package: zfs-dkms > Version: 0.7.12-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'stretch'. > It installed fine in 'stretch', then the upgrade to 'buster' fails. > > The problem is the order chosen by apt to process the packages. > > * the new spl-dkms gets configured and builds modules for the stretch kernel > * the new zfs-dkms gets unpacked > * the buster kernel headers get unpacked > * the new zfs-dkms gets configured and attempts to build a module for the > buster kernel > * this fails due to a missing spl-dkms build for the buster kernel > * the buster kernel headers get configured > > From the attached log (scroll to the bottom...): > > [...] > Setting up spl-dkms (0.7.12-1) ... > Loading new spl-0.7.12 DKMS files... > It is likely that 4.13.2 belongs to a chroot's host > Building for 4.9.0-8-amd64 > Building initial module for 4.9.0-8-amd64 > Done. > [...] > DKMS: install completed. > [...] > Preparing to unpack .../zfs-dkms_0.7.12-2_all.deb ... > > Uninstall Beginning > Module: zfs > Version: 0.6.5.9 > Kernel: 4.9.0-8-amd64 (x86_64) > - > > Status: Before uninstall, this module version was ACTIVE on this kernel. > [...] > DKMS: uninstall completed. > > -- > Deleting module version: 0.6.5.9 > completely from the DKMS tree. > -- > Done. > Unpacking zfs-dkms (0.7.12-2) over (0.6.5.9-5) ... > [...] > Selecting previously unselected package linux-compiler-gcc-8-x86. > Preparing to unpack .../4-linux-compiler-gcc-8-x86_4.19.12-1_amd64.deb ... > Unpacking linux-compiler-gcc-8-x86 (4.19.12-1) ... > Selecting previously unselected package linux-headers-4.19.0-1-common. > Preparing to unpack .../5-linux-headers-4.19.0-1-common_4.19.12-1_all.deb ... > Unpacking linux-headers-4.19.0-1-common (4.19.12-1) ... > Selecting previously unselected package linux-kbuild-4.19.
Bug#909971: Bug #909971 in libcloud marked as pending
Control: tag -1 pending Hello, Bug #909971 in libcloud reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/python-team/modules/libcloud/commit/e344d530eacbe358ac9bfe7ceba60266afe14c43 d/control: Remove unneeded dependency on backports.ssl-match-hostname (Closes: #909971). (this message was generated automatically) -- Greetings https://bugs.debian.org/909971
Bug#905960: amdgpu: After login the screen is corrupted, it is unusable in this state
Sorry for the noise and the mis-direction. Thank you for the pointer to the real bug. Using EXA does workaround the issue. I can use my PC again after being broken for 4 days. Andrew
Bug#905960: Errors from dmesg
These errors show in dmesg [ 794.423036] radeon :01:00.0: evergreen_cs_track_validate_texture:855 texture bo too small (layer size 9338880, offset 0, max layer 1, depth 1, bo size 4096) (1920 1216) [ 794.423070] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream ! [ 798.068277] fuse init (API version 7.26) [ 809.632694] radeon :01:00.0: ring 0 stalled for more than 10240msec [ 809.632702] radeon :01:00.0: GPU lockup (current fence id 0x028f last fence id 0x0290 on ring 0) [ 809.950539] radeon :01:00.0: Saved 23 dwords of commands on ring 0. [ 809.950551] radeon :01:00.0: GPU softreset: 0x0019 [ 809.950553] radeon :01:00.0: GRBM_STATUS = 0xE5703CA0 [ 809.950555] radeon :01:00.0: GRBM_STATUS_SE0 = 0xFC07 [ 809.950557] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 809.950559] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 809.950561] radeon :01:00.0: SRBM_STATUS2 = 0x [ 809.950563] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x0100 [ 809.950565] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x00011000 [ 809.950567] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00068404 [ 809.950569] radeon :01:00.0: R_008680_CP_STAT = 0x80878647 [ 809.950571] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 809.951993] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 809.952046] radeon :01:00.0: SRBM_SOFT_RESET=0x0100 [ 809.953192] radeon :01:00.0: GRBM_STATUS = 0x3828 [ 809.953194] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 809.953196] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 809.953198] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 809.953199] radeon :01:00.0: SRBM_STATUS2 = 0x [ 809.953201] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 809.953203] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 809.953205] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 809.953207] radeon :01:00.0: R_008680_CP_STAT = 0x [ 809.953209] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 809.953220] radeon :01:00.0: GPU reset succeeded, trying to resume [ 809.976424] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 809.980840] [drm] PCIE GART of 1024M enabled (table at 0x00162000). [ 809.980931] radeon :01:00.0: WB enabled [ 809.980934] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x4033ff39 [ 809.980937] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0xf2e8ad02 [ 809.981685] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0x7f7ea565 [ 809.997885] [drm] ring test on 0 succeeded in 2 usecs [ 809.997896] [drm] ring test on 3 succeeded in 6 usecs [ 810.173646] [drm] ring test on 5 succeeded in 2 usecs [ 810.173654] [drm] UVD initialized successfully. [ 810.194052] [drm] ib test on ring 0 succeeded in 0 usecs [ 810.194129] [drm] ib test on ring 3 succeeded in 0 usecs [ 810.848908] [drm] ib test on ring 5 succeeded [ 821.089203] radeon :01:00.0: ring 0 stalled for more than 10092msec [ 821.089209] radeon :01:00.0: GPU lockup (current fence id 0x0295 last fence id 0x0296 on ring 0) [ 821.403656] radeon :01:00.0: Saved 23 dwords of commands on ring 0. [ 821.403668] radeon :01:00.0: GPU softreset: 0x0019 [ 821.403670] radeon :01:00.0: GRBM_STATUS = 0xE5703CA0 [ 821.403672] radeon :01:00.0: GRBM_STATUS_SE0 = 0xFC07 [ 821.403675] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 821.403677] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 821.403679] radeon :01:00.0: SRBM_STATUS2 = 0x [ 821.403681] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x0100 [ 821.403692] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x00011000 [ 821.403695] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00068404 [ 821.403699] radeon :01:00.0: R_008680_CP_STAT = 0x80878647 [ 821.403701] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 821.409670] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 821.409723] radeon :01:00.0: SRBM_SOFT_RESET=0x0100 [ 821.410868] radeon :01:00.0: GRBM_STATUS = 0x3828 [ 821.410870] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 821.410872] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 821.410874] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 821.410876] radeon :01:00.0: SRBM_STATUS2 = 0x
Bug#905960: Errors from dmesg
dmesg.txt MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit These errors show in dmesg
Bug#905960: System was ok, broken by dist-upgrade
System was working ok until I rebooted after dist-upgrade. Booting Ubuntu 18.04 live CD works ok. Login screen is ok.
Bug#905960: amdgpu: After login the screen is corrupted, it is unusable in this state
Package: xserver-xorg-video-amdgpu Version: 18.0.1-1+b1 Severity: critical File: amdgpu Justification: breaks the whole system -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Oct 7 2011 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Jul 1 18:07 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779] /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 4.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-26)) #1 SMP Debian 4.17.8-1 (2018-07-20) Xorg X server log files on system: -- -rw-r--r-- 1 ag ag 42666 Aug 12 12:52 /home/ag/.local/share/xorg/Xorg.0.log Contents of most recent Xorg X server log file (/home/ag/.local/share/xorg/Xorg.0.log): --- [ 790.408] (--) Log file renamed from "/home/ag/.local/share/xorg/Xorg.pid-5321.log" to "/home/ag/.local/share/xorg/Xorg.0.log" [ 793.189] X.Org X Server 1.20.0 X Protocol Version 11, Revision 0 [ 793.189] Build Operating System: Linux 4.9.0-6-amd64 x86_64 Debian [ 793.189] Current Operating System: Linux quad 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 [ 793.189] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.17.0-1-amd64 root=/dev/md0 ro quiet [ 793.189] Build Date: 01 July 2018 05:07:24PM [ 793.189] xorg-server 2:1.20.0-3 (https://www.debian.org/support) [ 793.189] Current version of pixman: 0.34.0 [ 793.189]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 793.189] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 793.189] (==) Log file: "/home/ag/.local/share/xorg/Xorg.0.log", Time: Sun Aug 12 12:51:32 2018 [ 793.207] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 793.259] (==) No Layout section. Using the first Screen section. [ 793.259] (==) No screen section available. Using defaults. [ 793.259] (**) |-->Screen "Default Screen Section" (0) [ 793.259] (**) | |-->Monitor "" [ 793.267] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 793.267] (==) Automatically adding devices [ 793.267] (==) Automatically enabling devices [ 793.267] (==) Automatically adding GPU devices [ 793.267] (==) Max clients allowed: 256, resource mask: 0x1f [ 793.267] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 793.267]Entry deleted from font path. [ 793.267] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 793.267] (==) ModulePath set to "/usr/lib/xorg/modules" [ 793.267] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 793.267] (II) Loader magic: 0x55d8c2a26de0 [ 793.267] (II) Module ABI versions: [ 793.267]X.Org ANSI C Emulation: 0.4 [ 793.267]X.Org Video Driver: 24.0 [ 793.267]X.Org XInput driver : 24.1 [ 793.267]X.Org Server Extension : 10.0 [ 793.268] (++) using VT number 2 [ 793.272] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_38 [ 793.273] (II) xfree86: Adding drm device (/dev/dri/card0) [ 793.275] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0 [ 793.281] (--) PCI:*(1@0:0:0) 1002:6779:174b:a004 rev 0, Mem @ 0xd000/268435456, 0xfade/131072, I/O @ 0xb000/256, BIOS @ 0x/131072 [ 793.281] (--) PCI: (6@0:5:0) 14f1:8800:0070:9002 rev 5, Mem @ 0xfd00/16777216 [ 793.281] (II) LoadModule: "glx" [ 793.301] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 793.366] (II) Module glx: vendor="X.Org Foundation" [ 793.366]compiled for 1.20.0, module version = 1.0.0 [ 793.366]ABI class: X.Org Server Extension, version 10.0 [ 793.366] (II) Applying OutputClass "Radeon" to /dev/dri/card0 [ 793.366]loading driver: radeon [ 793.366] (==) Matched radeon as autoconfigured driver 0 [ 793.366] (==) Matched ati as autoconfigured driver 1 [ 793.366] (==) Matched modesetti
Bug#903322: firmware-qlogic: firmware checksum fails for qla2100 and qla2000 FC cards with kernel 4.x
Package: firmware-qlogic Version: 20170823-1 Severity: grave Justification: renders package unusable Dear Maintainer, after upgrading to any kernel above 3.x, such as 4.9 or 4.16 on booting, qla2xxx module fails with: Failed to initialize adapter Setup chip FAILED ISP Firmware failed checksum this happens with qla2100 and qla2200 FC cards. This happens regardless of the FC cards BIOS settings about loading RISC code. This happens regardless of which version of firmware-qlogic is installed, from what I have found. After going back and booting a 3.x kernel such as 3.16 , the problem is not there. -- System Information: Debian Release: 9.4 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/2 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) firmware-qlogic depends on no packages. firmware-qlogic recommends no packages. Versions of packages firmware-qlogic suggests: ii initramfs-tools 0.130 -- no debconf information
Bug#902883: [Pkg-samba-maint] Bug#902883: FTBFS on arch != amd64 because different libpytalloc-util.*.so name
On Mon, 2018-07-02 at 22:15 +0200, Mathieu Parent wrote: > Package: src:talloc > Version: 2.1.13-1 > Severity: serious > > Regression since python3 support: > > [...] > dh_makeshlibs -ppython-talloc -ppython3-talloc -Xtalloc. -- -c3 > dpkg-gensymbols: warning: new libraries appeared in the symbols file: > libpytalloc-util.cpython-36m-aarch64-linux-gnu.so.2 > dpkg-gensymbols: warning: some libraries disappeared in the symbols file: > libpytalloc-util.cpython-36m-x86-64-linux-gnu.so.2 > dpkg-gensymbols: warning: debian/python3-talloc/DEBIAN/symbols doesn't match > completely debian/python3-talloc.symbols See also https://github.com/samba-team/samba/pull/110 for BaT trying to fix this kind of thing on FreeBSD. Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Development and Support, Catalyst IT https://catalyst.net.nz/services/samba
Bug#896550: kazam: Binding 'R' failed!
On Sun, Apr 22, 2018 at 4:48 AM, Davide Prina wrote: > And the key for start/stop registration don't work. > So I can set to save the screencast, start it, bug I cannot stop it (I can do > it with Ctrl-C or kill command, but I don't have the screencast with > something usable: I see a movie with area subdivided into black and withe > squares). Hi, Could you please provide a bit more info about your set up to help track down the root cause here? What desktop environment is in use? I was not able to reproduce this in a new Debian Testing VM running Gnome. Thanks for the report. -- Andrew Starr-Bochicchio Debian Developer <http://qa.debian.org/developer.php?login=asb> Ubuntu Developer <https://launchpad.net/~andrewsomething> PGP/GPG Key ID: 3B56E2BBD53FDCB1
Bug#896251: Bug #896251 in python-changelog marked as pending
Control: tag -1 pending Hello, Bug #896251 in python-changelog reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/python-team/modules/python-changelog/commit/46f9873ea3eafa53c69e13f17e0228c0ea543a01 Build-depend on sphinx, don't use compat code Closes: #896251 (this message was generated automatically) -- Greetings https://bugs.debian.org/896251
Bug#862899: rsync: insufficient escaping/quoting of arguments
Control: severity -1 normal On Thu, 18 May 2017 13:16:23 +0200 Thorsten Glaser wrote: > Package: rsync > Version: 3.1.2-2 > Severity: serious > Tags: security upstream > Justification: security-relevant Since there wasn’t any activity on this bug, and there’s no sign of this to be fixed any time soon, and rsync provides ways to work this around, I don’t think having this bug marked as serious is justified. If you disagree, please comment/update. -- Cheers, Andrew
Bug#895320: ps2pdf crashes
Control: reassign -1 ghostscript It doesn't seem like a bug in mk-configure, I don't see anything criminal in the .tex source. -- Cheers, Andrew
Bug#894025: python-certbot-dns-cloudflare: Fails to build from source
On Sun, Mar 25, 2018 at 11:15 PM, Harlan Lieberman-Berg < hlieber...@debian.org> wrote: > Hm, so, we've never shipped the testdata. All the way back to the first > tag (0.0.0.dev20151104-1), we've removed the testdata. It's only for the > test cases, so we don't ship it out in the debs. > It looks like the test data slipped back into the package at some point. Inspecting the 0.21.1-1 from testing: $ dpkg --contents python3-certbot_0.21.1-1_all.deb | grep rsa512_key.pem -rw-r--r-- root/root 493 2018-01-25 14:29 ./usr/lib/python3/dist-packages/certbot/tests/testdata/rsa512_key.pem It's not actually clear to me if any of these packages really depend on that test data. It seems that it is only due to them importing dns_test_common which defines the key globally. https://salsa.debian.org/letsencrypt-team/certbot/certbot/blob/master/certbot/plugins/dns_test_common.py#L16 But taking a quick look at the packages that are failing, I don't actually see KEY referenced in their tests. So we could patch potentially that out in the main certbot package. -- Andrew Starr-Bochicchio Debian Developer <http://qa.debian.org/developer.php?login=asb> Ubuntu Developer <https://launchpad.net/~andrewsomething> PGP/GPG Key ID: 3B56E2BBD53FDCB1
Bug#894025: python-certbot-dns-cloudflare: Fails to build from source
On Sun, Mar 25, 2018 at 9:47 AM, Jeremy Bicha wrote: > > error: [Errno 2] No such file or directory: > '/usr/lib/python3/dist-packages/certbot/tests/testdata/rsa512_key.pem' > > Full build log at > https://launchpad.net/ubuntu/+source/python-certbot-dns- > cloudflare/0.22.0-1/+build/14491162 > Looks like this was caused by this change in the main certbot package: https://salsa.debian.org/letsencrypt-team/certbot/certbot/commit/8bb2938afb15594cb79f8661d951724323f0e754 Harlan, any more context on that or concerns about reverting? Thanks, -- Andrew Starr-Bochicchio Debian Developer <http://qa.debian.org/developer.php?login=asb> Ubuntu Developer <https://launchpad.net/~andrewsomething> PGP/GPG Key ID: 3B56E2BBD53FDCB1
Bug#888928: gource FTBFS with libglm-dev 0.9.9~a2-1
This bug was triggered by the libglm-dev package being updated to an alpha version of glm 0.9.9 a2. I believe this was done to fix an issue compiling with GCC 7.3 present in the current release 0.9.8.5. While it's relatively trivial for me to add the extra define to get it to get my software to compile, this version of GLM also includes a major change of behavior by removing the default initialization of vector, matrix and quaternion types. In the case of gource and logstalgia, there is quite a bit of code relying on the previous behavior so this has created a number of uninitialized value bugs. Any other software using libglm-dev that depends on this behavior will have the same issue. I've raised a bug with the upstream regarding this change: https://github.com/g-truc/glm/issues/735 IMO the best solution is for libglm-dev to continue to package the current release 0.9.8.5 but apply a patch fixing the GCC compilation issue. On Wed, Jan 31, 2018 at 10:23 PM, Adrian Bunk wrote: > Source: gource > Version: 0.47-1 > Severity: serious > > https://tests.reproducible-builds.org/debian/rb-pkg/ > unstable/amd64/gource.html > > ... > In file included from /usr/include/glm/gtx/norm.hpp:18:0, > from src/core/vectors.h:37, > from src/core/gl.h:27, > from src/core/texture.h:34, > from src/gource_settings.h:23, > from src/user.h:21, > from src/action.h:21, > from src/action.cpp:18: > /usr/include/glm/gtx/quaternion.hpp:23:3: error: #error "GLM: > GLM_GTX_quaternion is an experimental extension and may change in the > future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you > really want to use it." > # error "GLM: GLM_GTX_quaternion is an experimental extension and may > change in the future. Use #define GLM_ENABLE_EXPERIMENTAL before including > it, if you really want to use it." >^ >
Bug#885570: After upgrade I can continue to reproduce this
I updated to the stretch-proposed-updates version and am very happy thus far. Sorry for the noise and thank you for the fix. # uname -a Linux lappy7 4.9.0-5-amd64 #1 SMP Debian 4.9.80-2 (2018-02-09) x86_64 GNU/Linux # dmesg | grep 915 [ 15.124116] snd_hda_intel :00:03.0: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 15.124123] [drm] Initialized i915 1.6.0 20160919 for :00:02.0 on minor 0 [ 16.332502] i915 :00:02.0: fb0: inteldrmfb frame buffer device On Sun, Feb 11, 2018 at 2:11 PM, Andrew Latham wrote: > Yves-Alexis > > Thank you. Would enabling that repo/branch and testing help at all with > this? > > My confusion is that https://packages.debian.org/stretch/linux-image-amd64 > and https://packages.debian.org/stretch/linux-image-4.9.0-5-amd64 did not > match up. I wonder if this is a mistake. I will go back and re-read the > pages. > > On Sun, Feb 11, 2018 at 1:59 PM, Yves-Alexis Perez > wrote: > >> On Sun, 2018-02-11 at 13:33 -0600, Andrew Latham wrote: >> > Related info in dmesg >> > [0.00] Linux version 4.9.0-5-amd64 >> (debian-ker...@lists.debian.org) >> > (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65- >> > 3+deb9u2 (2018-01-04) >> > [ 273.787162] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO >> > underrun >> >> This is not the fixed version. You want to upgrade to 4.9.80-1 (or -2) >> which >> is currently sitting in stable-proposed-updates and will be available in >> the >> next point release. >> >> Regards, >> -- >> Yves-Alexis > > > > > -- > - Andrew "lathama" Latham - > -- - Andrew "lathama" Latham -
Bug#885570: After upgrade I can continue to reproduce this
Yves-Alexis Thank you. Would enabling that repo/branch and testing help at all with this? My confusion is that https://packages.debian.org/stretch/linux-image-amd64 and https://packages.debian.org/stretch/linux-image-4.9.0-5-amd64 did not match up. I wonder if this is a mistake. I will go back and re-read the pages. On Sun, Feb 11, 2018 at 1:59 PM, Yves-Alexis Perez wrote: > On Sun, 2018-02-11 at 13:33 -0600, Andrew Latham wrote: > > Related info in dmesg > > [0.00] Linux version 4.9.0-5-amd64 (debian-kernel@lists.debian. > org) > > (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65- > > 3+deb9u2 (2018-01-04) > > [ 273.787162] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO > > underrun > > This is not the fixed version. You want to upgrade to 4.9.80-1 (or -2) > which > is currently sitting in stable-proposed-updates and will be available in > the > next point release. > > Regards, > -- > Yves-Alexis -- - Andrew "lathama" Latham -
Bug#885570: After upgrade I can continue to reproduce this
Thinkpad X1 Carbon Gen3 Intel HD Graphics 5500 Broadwell - WQHD (2560x1440) Simple Debian Stretch install, updated, using KDE desktop No bells or tweaks, standard install. Reproduce 1. Open Google Chrome web browser 2. Open KDE Konsole app 3. Press enter or type a char 4. Screen scrolls horizontally wildly 5. Attempt to use CTRL ALT F2 6. Screen still scrolls horizontally wildly 7. From another system login over SSH and kill both Google Chrome and Konsole 8. System returns to usable state. 9 Open Google Chrome and type this email 10. From remote system gather debug info and find little if any mention that there was an issue. Related info in dmesg [0.00] Linux version 4.9.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) [ 273.787162] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun lspci 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) 00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09) 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) 00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03) 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-LM (rev 03) 00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #2 (rev e3) 00:1c.1 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3) 00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03) 00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03) 00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP Thermal Management Controller (rev 03) 04:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) Please advise what I can do to help troubleshoot this issue. -- - Andrew "lathama" Latham -
Bug#887886: Patch
common fields of updated and compatible versions. */
struct
{
- /* Pointer to the previous cleanup buffer. */
- struct pthread_unwind_buf *prev;
-
- /* Backward compatibility: state of the old-style cleanup
- handler at the time of the previous new-style cleanup handler
- installment. */
- struct _pthread_cleanup_buffer *cleanup;
-
- /* Cancellation type before the push call. */
- int canceltype;
-} data;
- } priv;
+ __jmp_buf jmp_buf;
+ int mask_was_saved;
+} cancel_jmp_buf[1];
+struct updated_pthread_unwind_buf updated;
+struct compat_pthread_unwind_buf compat;
+ };
};
+/* Get pointer to the priv field from THREAD_SELF, "self", and pointer
+ to the cleanup buffer, "p". By default, the compatible version is
+ used. If a target defines NEED_SAVED_MASK_IN_CANCEL_JMP_BUF, it
+ must provide its own version of UNEIND_BUF_PRIV. */
+#ifndef UNWIND_BUF_PRIV
+# ifdef NEED_SAVED_MASK_IN_CANCEL_JMP_BUF
+# error "UNWIND_BUF_PRIV is undefined!"
+# endif
+# define UNWIND_BUF_PRIV(self,p) (&((p)->compat.priv))
+#endif
/* Opcodes and data types for communication with the signal handler to
change user/group IDs. */
diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c
index caaf07c134..77647dcbae 100644
--- a/nptl/pthread_create.c
+++ b/nptl/pthread_create.c
@@ -428,8 +428,8 @@ START_THREAD_DEFN
struct pthread_unwind_buf unwind_buf;
/* No previous handlers. */
- unwind_buf.priv.data.prev = NULL;
- unwind_buf.priv.data.cleanup = NULL;
+ unwind_buf.updated.priv.data.prev = NULL;
+ unwind_buf.updated.priv.data.cleanup = NULL;
int not_first_call;
not_first_call = setjmp ((struct __jmp_buf_tag *) unwind_buf.cancel_jmp_buf);
@@ -701,6 +701,11 @@ __pthread_create_2_1 (pthread_t *newthread, const
pthread_attr_t *attr,
THREAD_COPY_POINTER_GUARD (pd);
#endif
+ /* Copy additonal info. */
+#ifdef THREAD_COPY_ADDITONAL_INFO
+ THREAD_COPY_ADDITONAL_INFO (pd);
+#endif
+
/* Verify the sysinfo bits were copied in allocate_stack if needed. */
#ifdef NEED_DL_SYSINFO
CHECK_THREAD_SYSINFO (pd);
diff --git a/nptl/unwind.c b/nptl/unwind.c
index b37a063c53..f58be0ee5f 100644
--- a/nptl/unwind.c
+++ b/nptl/unwind.c
@@ -66,7 +66,8 @@ unwind_stop (int version, _Unwind_Action actions,
/* Handle the compatibility stuff. Execute all handlers
registered with the old method which would be unwound by this
step. */
- struct _pthread_cleanup_buffer *oldp = buf->priv.data.cleanup;
+ struct _pthread_cleanup_buffer *oldp
+ = UNWIND_BUF_PRIV (self, buf)->data.cleanup;
void *cfa = (void *) (_Unwind_Ptr) _Unwind_GetCFA (context);
if (curp != oldp && (do_longjump || FRAME_LEFT (cfa, curp, adj)))
@@ -133,6 +134,7 @@ __pthread_unwind_next (__pthread_unwind_buf_t *buf)
{
struct pthread_unwind_buf *ibuf = (struct pthread_unwind_buf *) buf;
- __pthread_unwind ((__pthread_unwind_buf_t *) ibuf->priv.data.prev);
+ __pthread_unwind ((__pthread_unwind_buf_t *)
+ UNWIND_BUF_PRIV (THREAD_SELF,
ibuf)->data.prev);
}
hidden_def (__pthread_unwind_next)
diff --git a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
index 247a62e9a0..a3076bf980 100644
--- a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
+++ b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
@@ -23,7 +23,7 @@
extern struct pthread_unwind_buf pthread_unwind_buf_private;
-_Static_assert (sizeof (pthread_unwind_buf_private.cancel_jmp_buf)
+_Static_assert (sizeof (pthread_unwind_buf_private.updated.cancel_jmp_buf)
>= sizeof (struct __jmp_buf_tag),
"size of cancel_jmp_buf < sizeof __jmp_buf_tag");
diff --git a/sysdeps/unix/sysv/linux/x86/pthreaddef.h
b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
index a405a65666..899fcd6743 100644
--- a/sysdeps/unix/sysv/linux/x86/pthreaddef.h
+++ b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
@@ -20,3 +20,17 @@
/* Need saved_mask in cancel_jmp_buf. */
#define NEED_SAVED_MASK_IN_CANCEL_JMP_BUF 1
+
+/* Wee need to copy feature_1 in pthread_create. */
+#define THREAD_COPY_ADDITONAL_INFO(descr)
\
+ ((descr)->header.feature_1
\
+ = THREAD_GETMEM (THREAD_SELF, header.feature_1))
+
+/* Use the compatible struct __cancel_jmp_buf_tag if shadow stack is
+ disabled. */
+#undef UNWIND_BUF_PRIV
+#define UNWIND_BUF_PRIV(self,p) \
+ (__extension__ ({
\
+ unsigned int feature_1 = THREAD_GETMEM (self, header.feature_1);
\
+ (((feature_1 & (1 << 1)) == 0)
Bug#888235: closing 888235
close 888235 thanks -- -- Cheers, Andrew
Bug#833507: wpasupplicant: Unable to connect WLAN (wlan0: CTRL-EVENT-SCAN-FAILED ret=-22)
On 9 December 2017 at 17:25, YOSHINO Yoshihito wrote: > Package: wpasupplicant > Version: 2:2.6-13 > Followup-For: Bug #833507 > > Dear Maintainer, > > I use /etc/network/interfaces to configure networking, not network-manager. > Upgrading wpasupplicant to >= 2:2.6 my machine (MacBook Air with broadcom-sta > wl module) fails to connect to a wi-fi network, with a lot of syslog messages > of "CTRL-EVENT-SCAN-FAILED ret=-22". > Downgrading the package to 2:2.4-1.1 restores it to work fine. > > I do not know how to configure ifupdown to disable random mac address > usage just as how network-manager does in > /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf . So how about NM? Does it work for you if you use NM? -- Cheers, Andrew
Bug#833507: [pkg-wpa-devel] Bug#833507: Bug#833507: wpasupplicant: workaround wifi.scan-rand-mac-address=no
On 05/12/17 09:31, Noël Köthe wrote: > Hello Andrew, > > Am Dienstag, den 05.12.2017, 08:57 +0100 schrieb Andrew Shadura: > >>> I remember a workaround for this problem from the past to add >>> into /etc/NetworkManager/NetworkManager.conf the following: >>> >>> [device] >>> wifi.scan-rand-mac-address=no >>> >>> which fixed it again for me. > >> Just to be sure, are you absolutely sure it doesn't work with the >> latest wpasupplicant without the NM snippet? > > Yes. Wifi worked until Tue or Wed last week and with my daily sid > update I didn't get it working again. Module unloading and loading or > network-manager restarts or complete reboots didn't helped. > Until yesterday when I added the NM lines again. Thanks. >> I have put a similar one >> into the wpasupplicant package, but a driver-specific one. > > OK. > >> Could you please let me know what driver are you using? > > wl module/driver with the broadcom-sta-dkms 6.30.223.271-7 > > 03:00.0 Network controller: Broadcom Limited BCM4360 802.11ac Wireless > Network Adapter (rev 03) on a MacBook Pro > 03:00.0 0280: 14e4:43a0 (rev 03) > >> You should be able to find out by running: >> >> nmcli -f GENERAL.DRIVER,GENERAL.DRIVER-VERSION device show > > # nmcli -f GENERAL.DRIVER,GENERAL.DRIVER-VERSION device show > GENERAL.DRIVER: tg3 > GENERAL.DRIVER-VERSION: 3.137 > > GENERAL.DRIVER: wl > GENERAL.DRIVER-VERSION: 6.30.223.271 (r587334) Right, so it is wl indeed. > GENERAL.DRIVER: bridge > GENERAL.DRIVER-VERSION: 2.3 > > GENERAL.DRIVER: unknown > GENERAL.DRIVER-VERSION: -- > > GENERAL.DRIVER: tun > GENERAL.DRIVER-VERSION: 1.6 > >> Please bear in mind the file I'm shipping doesn't work with old NM, >> what version are you using? > > network-manager 1.10.0-1 This should be recent enough. > It is a sid system with no package on hold. > > If I can help you with more information just tell me. Thanks. Please have a look at /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf. There should be a line: match-device=driver:rtl8723bs,… Please add driver:wl to this comma-separated list, remove your previos NetworkManager.conf addition, restart NM and try again. If this helps, we can close the bug. If it doesn't, please check whether the config is being parsed at all by runnin /usr/sbin/NetworkManager --print-config. Thanks! -- Cheers, Andrew
Bug#833507: [pkg-wpa-devel] Bug#833507: wpasupplicant: workaround wifi.scan-rand-mac-address=no
On 4 December 2017 at 20:29, Noël Köthe wrote: > Package: wpasupplicant > Version: 2:2.6-11 > Followup-For: Bug #833507 > > Dear Maintainer, > > with one of the sid updates last week my wireless stop > working again with the > wpa_supplicant[737]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 > > I remember a workaround for this problem from the past to add > into /etc/NetworkManager/NetworkManager.conf the following: > > [device] > wifi.scan-rand-mac-address=no > > which fixed it again for me. > > ... > network-manager (1.4.0-4) unstable; urgency=medium > ... > * Fix MAC address randomization. > Cherry-pick a couple of upstream commits which work around driver bugs > when MAC address randomization is used. (Closes: #835822, #835553) > ... > > Because the last network-manager was from 2017-11-10 and my wlan problem > started last week I'm a bit unsure where the root cause is. > > Maybe the workaround helps someone. Just to be sure, are you absolutely sure it doesn't work with the latest wpasupplicant without the NM snippet? I have put a similar one into the wpasupplicant package, but a driver-specific one. Could you please let me know what driver are you using? You should be able to find out by running: nmcli -f GENERAL.DRIVER,GENERAL.DRIVER-VERSION device show Please bear in mind the file I'm shipping doesn't work with old NM, what version are you using? Thanks. -- Cheers, Andrew
Bug#849122: unmerging 849122, bug 849122 is forwarded to https://github.com/lwfinger/rtl8188eu/issues/237
unmerge 849122 forwarded 849122 https://github.com/lwfinger/rtl8188eu/issues/237 severity 849122 normal thanks Hi, I'm unmerging 849122 as should be a separate bug. It should have been worked around since I uploaded an NM snippet to blacklist it for MAC address randomisation, so I'm downgrading the severity. lwfinger's repository seems to be the upstream, so I have reported the bug there. Please let me know if this is still an issue with the latest wpasupplicant upload. -- Cheers, Andrew
Bug#849077: [pkg-wpa-devel] Bug#849077: please upgrade wpa and report your experience
On 27/11/17 22:52, Nicolas Kuttler wrote: > On 2017-11-25 10:06, Andrew Shadura wrote: >> I've just uploaded wpa 2.6 into unstable once again. Please upgrade, >> test and let me know if it works for you. > > Hm, installing wpasupplicant:amd64 2:2.6-8 lead to me not being able to > connect to wireless networks again. > > Adding the following lines to /etc/NetworkManager/NetworkManager.conf > fixed this problem: > > [device] > wifi.scan-rand-mac-address=no Okay, thanks. I'm losing my patience with this issue, so I am just going to ship this snippet within the wpasupplicant package. -- Cheers, Andrew
Bug#849077: please upgrade wpa and report your experience
Hi, I've just uploaded wpa 2.6 into unstable once again. Please upgrade, test and let me know if it works for you. -- Cheers, Andrew
Bug#866194: etcd service fails to start on ppc64le architecture when installing etcd
Control: tags -1 moreinfo On Wed, 28 Jun 2017 01:54:08 -0500 Harish Sriram wrote: > Package: etcd > Version: 3.1.8+dfsg-1 > Severity: serious > Justification: 4 > > Dear Maintainer, > Service fails to start while installing etcd package > > I tried installing the etcd package and service of the package failed to > start on ppc64le. > > Expected: Service should be up and running Could you please test the latest package version? Thanks! -- Cheers, Andrew
Bug#878542: marked as pending
tag 878542 pending
thanks
Hello,
Bug #878542 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:
https://anonscm.debian.org/cgit/python-modules/packages/libcloud.git/commit/?id=89e3f06
---
commit 89e3f06f5213bfe565bd52a9664d863681539767
Author: Andrew Starr-Bochicchio
Date: Wed Oct 18 23:23:17 2017 -0400
Resolves FTBFS with Python 3.6 (Closes: #878542).
diff --git a/debian/changelog b/debian/changelog
index b9fe44d..8e04350 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ libcloud (2.2.1-1) UNRELEASED; urgency=medium
[ Andrew Starr-Bochicchio ]
* New upstream release.
+ - Resolves FTBFS with Python 3.6 (Closes: #878542).
* debian/control: Remove deprecated XS-Testsuite field.
* Build depend on python{3}-pytest and python{3}-pytest-runner.
* Bump Standards-Version to 4.1.0.
Bug#849077: [pkg-wpa-devel] Bug#849122: Please adjust the BTS version tracking info
Hi, On 1 July 2017 at 23:32, Francesco Poli wrote: > Dear Debian wpasupplicant Maintainers, > I noticed that these 3 RC bugs (#849122, #849077, #849875) are marked > as found in wpa/2.6-2, which is now superseded by versions with epoch 2. > What seems to have happened (please correct me, if I am wrong) is that > the upstream version 2.4 was reintroduced into unstable (with epoch 2) > and then migrated to stretch (before the stretch release as stable). > > Hence, I would say that those three bugs only affect experimental and > are not in stretch, buster or sid. > > Could you please confirm that these 3 bugs should be marked as fixed in > wpa/2:2.4-1 and found in wpa/2:2.6-4 ? Yes, your understanding is correct, sorry for not replying earlier, somehow this whole thread fell through the cracks in my email processing. -- Cheers, Andrew
Bug#866656: sparkleshare and webkit1
On 11 August 2017 at 23:16, Jeremy Bicha wrote: > On Fri, Aug 11, 2017 at 11:09 PM, Andrew Shadura wrote: >> That's quite a surprise to me. The weekend starts in less than an hour, and >> I get to know only now? > > I apologize. I think the problem is that you were only listed as > Uploader instead of Maintainer. I believe the Maintainer gets emails > about autoremovals in advance. And the maintainer should have received > my initial RC bug. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866656 > > You can subscribe to your packages you are interested in with the new > Debian package tracker: > https://tracker.debian.org/pkg/sparkleshare > > My understanding of autoremovals is that simply *commenting* on the RC > bug will reset the timer so you have more time before the removal > happens. > > > Check out this page > https://udd.debian.org/cgi-bin/autoremovals.cgi > > It lists these packages of interest to you: > Andrew Shadura >nfstrace: flagged for removal in 7.8 days >sparkleshare: buggy deps webkitgtk-sharp3, flagged for removal in 37 hours >webkitgtk-sharp3: flagged for removal in 37 hours >wxhexeditor: flagged for removal in 7.8 days Okay, let's see. -- Cheers, Andrew
Bug#867426: marked as pending
tag 867426 pending thanks Hello, Bug #867426 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/python-modules/packages/python-django-contact-form.git/commit/?id=0a8883d --- commit 0a8883d5ec85f079cf42cc89acb54f2380f59ebd Author: Andrew Starr-Bochicchio Date: Fri Jul 14 21:36:13 2017 -0400 debian/control: Fix incorrect dependencies for python3-django-contact-form (Closes: #867426). diff --git a/debian/changelog b/debian/changelog index 0f67c3a..ec51f25 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +python-django-contact-form (1.4.2-2) UNRELEASED; urgency=medium + + * debian/control: Fix incorrect dependencies for +python3-django-contact-form (Closes: #867426). + + -- Andrew Starr-Bochicchio Fri, 14 Jul 2017 21:33:59 -0400 + python-django-contact-form (1.4.2-1) unstable; urgency=medium * New upstream release (Closes: #865941).
Bug#868209: CVE-2017-11103: MitM attack, impersonation of the Kerberos client, known as Orpheus Lyre
On Thu, 2017-07-13 at 18:05 +1200, Andrew Bartlett wrote: > On Thu, 2017-07-13 at 07:14 +0200, Raphael Hertzog wrote: > > Source: samba > > Severity: grave > > Tags: security patch > > Version: 2:4.1.11+dfsg-1 > > > > Hi, > > > > the following vulnerability was published for samba (due to its embedded > > copy of heimdal). I checked the build logs for unstable and apparently it > > does use this copy (I don't know the status for older releases). > > > > CVE-2017-11103[0]: MitM attack, impersonation of the Kerberos client, know > > as Orpheus Lyre > > > > A dedicated website is here: > > https://orpheus-lyre.info/ > > > > The samba announce and patch are here: > > https://www.samba.org/samba/security/CVE-2017-11103.html > > https://download.samba.org/pub/samba/patches/security/samba-4.x.y-CVE-2017-11103.patch > > > > 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-2017-11103 > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11103 > > > > Please adjust the affected versions in the BTS as needed. > > Proposed updates are in jessie and stretch branches at: > > git://git.samba.org/abartlet/samba-debian.git > > I've only built them, not tested them. Then again, the upstream > patches were not manually tested either (we relied on autobuild), such > was the rush... > > I can upload the built binaries if you want to test them or comment. Unsigned packages (sorry) are at: https://seafile.catalyst.net.nz/d/8f9c648216c3452497cb/ -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Bug#868209: CVE-2017-11103: MitM attack, impersonation of the Kerberos client, known as Orpheus Lyre
On Thu, 2017-07-13 at 07:14 +0200, Raphael Hertzog wrote: > Source: samba > Severity: grave > Tags: security patch > Version: 2:4.1.11+dfsg-1 > > Hi, > > the following vulnerability was published for samba (due to its embedded > copy of heimdal). I checked the build logs for unstable and apparently it > does use this copy (I don't know the status for older releases). > > CVE-2017-11103[0]: MitM attack, impersonation of the Kerberos client, know as > Orpheus Lyre > > A dedicated website is here: > https://orpheus-lyre.info/ > > The samba announce and patch are here: > https://www.samba.org/samba/security/CVE-2017-11103.html > https://download.samba.org/pub/samba/patches/security/samba-4.x.y-CVE-2017-11103.patch > > 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-2017-11103 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11103 > > Please adjust the affected versions in the BTS as needed. Proposed updates are in jessie and stretch branches at: git://git.samba.org/abartlet/samba-debian.git I've only built them, not tested them. Then again, the upstream patches were not manually tested either (we relied on autobuild), such was the rush... I can upload the built binaries if you want to test them or comment. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Bug#865941: marked as pending
tag 865941 pending thanks Hello, Bug #865941 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/python-modules/packages/python-django-contact-form.git/commit/?id=3c4c2a7 --- commit 3c4c2a7bd99e75395df56221f78fb6428551402b Author: Andrew Starr-Bochicchio Date: Mon Jul 3 10:46:16 2017 -0400 New upstream release (Closes: #865941). diff --git a/debian/changelog b/debian/changelog index 064616d..b6126ef 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +python-django-contact-form (1.4.2-1) UNRELEASED; urgency=medium + + * New upstream release (Closes: #865941). + + -- Andrew Starr-Bochicchio Mon, 03 Jul 2017 10:45:40 -0400 + python-django-contact-form (1.3-1) unstable; urgency=medium * New upstream release.
Bug#862611: [/master] Check if template files exist and raise 404 if not in order to protect webui against directory traversal (Closes: #862611).
tag 862611 pending thanks Date: Mon May 15 20:09:36 2017 -0400 Author: Andrew Starr-Bochicchio Commit ID: 3d1b3b4500f155a25bc2e5e92ae56437fa728041 Commit URL: https://anonscm.debian.org/cgit/collab-maint/deluge.git;a=commitdiff;h=3d1b3b4500f155a25bc2e5e92ae56437fa728041 Patch URL: https://anonscm.debian.org/cgit/collab-maint/deluge.git;a=commitdiff_plain;h=3d1b3b4500f155a25bc2e5e92ae56437fa728041 Check if template files exist and raise 404 if not in order to protect webui against directory traversal (Closes: #862611).
Bug#859812: atom4: Exception: Unable to load tile pixmap from: (null)
Package: atom4
Version: 4.1-7
Severity: grave
Dear Maintainer,
After upgrading atom4 following the fix for bug 859498, the package
files are now present.
However, when I attempt to launch the program, I get:
$ atom4
Exception: Unable to load tile pixmap from: (null)
An strace run reveals (among other things) that shortly before the
exception message is printed, the following call occurs:
open("debian/atom4/usr/share/games/atom4/tritile12.xpm", O_RDONLY) =
-1 ENOENT (No such file or directory)
which seems to indicate that the hardcoded pixmap paths in the built
executable are relative to the build directory, rather than pointing to
the location where the package actually installs those files. (strings
on the binary confirms that those paths are present there.) The file
/usr/share/games/atom4/tritile12.xpm does exist.
I am reporting this as grave, because I can't see how this can work on
any computer. If it does/can on some, please feel free to downgrade to
important.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages atom4 depends on:
ii libc62.24-9
ii libgcc1 1:6.3.0-11
ii libncurses5 6.0+20161126-1
ii libstdc++6 6.3.0-11
ii libtinfo56.0+20161126-1
ii libx11-6 2:1.6.4-3
ii libxpm4 1:3.5.12-1
atom4 recommends no packages.
atom4 suggests no packages.
-- debconf-show failed
Bug#859498: atom4: no package files present
Package: atom4 Version: 4.1-6+b5 Severity: grave Justification: renders package unusable Dear Maintainer, Within the past few days, I have installed atom4 from Debian testing, using 'apt-get install atom4'. After having done so, I get the following: $ dpkg -c /var/cache/apt/archives/atom4_4.1-6+b5_amd64.deb drwxr-xr-x root/root 0 2013-07-31 12:20 ./ drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/ drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/games/ drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/ drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/doc/ drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/doc/atom4/ -rw-r--r-- root/root 3093 2003-03-13 09:03 ./usr/share/doc/atom4/README.gz -rw-r--r-- root/root 216 2013-07-31 12:20 ./usr/share/doc/atom4/changelog.Debian.amd64.gz -rw-r--r-- root/root 1967 2013-07-31 12:20 ./usr/share/doc/atom4/changelog.Debian.gz -rw-r--r-- root/root 388 2013-07-31 12:20 ./usr/share/doc/atom4/copyright drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/games/ drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/games/atom4/ drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/man/ drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/man/man6/ drwxr-xr-x root/root 0 2013-07-31 12:20 ./usr/share/menu/ -rw-r--r-- root/root 244 2013-07-31 12:20 ./usr/share/menu/atom4 $ dlocate atom4 atom4: /. atom4: /usr atom4: /usr/games atom4: /usr/share atom4: /usr/share/doc atom4: /usr/share/doc/atom4 atom4: /usr/share/doc/atom4/README.gz atom4: /usr/share/doc/atom4/changelog.Debian.amd64.gz atom4: /usr/share/doc/atom4/changelog.Debian.gz atom4: /usr/share/doc/atom4/copyright atom4: /usr/share/games atom4: /usr/share/games/atom4 atom4: /usr/share/man atom4: /usr/share/man/man6 atom4: /usr/share/menu atom4: /usr/share/menu/atom4 By comparison, I also get: $ apt-file search atom4 atom4: /usr/games/atom4 atom4: /usr/share/doc/atom4/README.gz atom4: /usr/share/doc/atom4/changelog.Debian.amd64.gz atom4: /usr/share/doc/atom4/changelog.Debian.gz atom4: /usr/share/doc/atom4/copyright atom4: /usr/share/games/atom4/blackball12.xpm atom4: /usr/share/games/atom4/blueball12.xpm atom4: /usr/share/games/atom4/greenball12.xpm atom4: /usr/share/games/atom4/purpleball12.xpm atom4: /usr/share/games/atom4/redball12.xpm atom4: /usr/share/games/atom4/tritile12.xpm atom4: /usr/share/games/atom4/turqball12.xpm atom4: /usr/share/games/atom4/wheel12-1.xpm atom4: /usr/share/games/atom4/wheel12-2.xpm atom4: /usr/share/games/atom4/wheel12-3.xpm atom4: /usr/share/games/atom4/wheel12-4.xpm atom4: /usr/share/games/atom4/wheel12-5.xpm atom4: /usr/share/games/atom4/wheel12-6.xpm atom4: /usr/share/games/atom4/whiteball12.xpm atom4: /usr/share/games/atom4/yellowball12.xpm atom4: /usr/share/man/man6/atom4.6.gz atom4: /usr/share/menu/atom4 games-thumbnails: /usr/share/games/thumbnails/atom4.png lammps-doc: /usr/share/doc/lammps-doc/Eqs/compute_sna_atom4.jpg but that is a listing of files known to (a local record of the contents of) the archive as being in this package, not files actually installed on my system. Reinstalling the package from the same .deb file changes nothing. As far as I can tell, this package does not actually install any files outside of /usr/share/doc/, except for the menu file. I am reporting this as grave, because I see nothing to indicate that this would not happen the same way on any and every computer, and if that is the case this package is completely unusable. Please A: figure out why these files are missing from the currently installable package and correct that, B: determine that they are not missing from the .deb in the repositories and help me figure out why they are missing on my own machine, or C: have this package removed from the archive, or at least from testing for the release. (The last, obviously, is the least preferable option.) -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- debconf-show failed
Bug#858078: Kernel hangs most of the times when modeset=1 on the i915
Date: Sat, 18 Mar 2017 01:53:09 0100 >From: Santiago Garcia Mantinan >- >Body: --jssievwxx6bi6meh >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline > >Package: src:linux >Version: 4.9.13-1 >Severity: critical > >I just upgraded this machine from Jessie to Stretch and found the kernel >crashing (computer completelly frozen) most of the times, even if X is not >started. I then tried to use the kernel from Jessie with current packages >from Stretch and found that it works perfectly, like it used to on Jessie. > >One of the things I tried was to pass modeset=0 parameter to the i915 >module and it fixed things, so it seems that the problem is with modesetting >on the i915 module. > >I have gotten the messages from the kernel when it boots ok, I'll try to >attach them to the bugreport: > >4.9 messages when it boots ok and X finally starts >4.9noX messages when it boots but without starting X >4.9nomodeset messages when modeset is disabled and no X is started, never hangs > >If you need any other info just let me know. > >Regards. > >-- Package-specific info: >** Version: >Linux version 4.9.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170221 (Debian 6.3.0-8) )
Bug#856271: xfonts-base: FTBFS on arm64 due to out of date autoconf files
cipe for target 'debian/stamps/build-font-arabic-misc' failed make: *** [debian/stamps/build-font-arabic-misc] Error 1 make: *** Waiting for unfinished jobs debian/rules:49: recipe for target 'debian/stamps/build-font-cursor-misc' failed make: *** [debian/stamps/build-font-cursor-misc] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 - -- Cheers, Andrew -BEGIN PGP SIGNATURE- iQExBAEBCAAbBQJYs//SFBxhbmRyZXdzaEBkZWJpYW4ub3JnAAoJEJ1bI/kYT6UU I8kH/AicZVPu67jdpEPHvOyXXd588wfiJ33o8xqaaqXmWsTsUSO+b/4iJU6Q6NIj xgzGa+61uLCgSjrS9O6U2PQJ36i5NPJDWCZsTe8L0p/Ch73DU4HfiySYuM/We+gv cfrPiAHF9tW+qO9J3FmK8CCfi8IdNAo8xgLu4gTrdYNvTNH062wEAqNiiKaxEUPJ 09xOMTcSFKw9dBAChuxB3SPKqydKYvpkFJyX9EXxOtuJkFXi48vi2gY3fFkS7ZA5 v0+ejSCKHyNk9LEzrFrnoD8tUCA2TM3H33YTI6tlNO1cHu8BeRkksNuDWLfP2non 9wSj2B7Rsev8VtJ2c6ltdT2Gj5g= =0ekO -END PGP SIGNATURE-
Bug#856259: [pkg-wpa-devel] Bug#856259: wpasupplicant: missing dependency on ifupdown
Control: tags -1 moreinfo On 27/02/17 04:33, Michael Gilbert wrote: > package: wpasupplicant > severity: serious > justification: policy 3.5 > version: 2.5-2+v2.4-3, 2:2.4-1 > > wpasupplicant relies on ifupdown, but there is no relationship to it > declared in the packaging. > > For example, without ifupdown installed running these commands: > > # ifconfig wlan0 create wlandev iwn0 > # wpa_supplicant -i wlan0 -c wpa.conf > > causes the wpa_supplicant process to hang using 100% CPU. > > Once ifupdown is installed, the exact same set of commands and same > conf file, wpasupplicant correctly connects to my access point. wpa_supplicant doesn't require ifupdown and doesn't use it in any way on its own. Please provide more logs or debug info. -- Cheers, Andrew
Bug#849077: [pkg-wpa-devel] Bug#849077: new version of wpa-supplicant uploaded -- please test
Hi, On 23 February 2017 at 19:37, Scott Mcdermott wrote: > On Thu, 26 Jan 2017 18:36:08 +0100 Andrew Shadura wrote: >> I have cherry-picked a few patches from the upstream Git repository. > > I tried this on my mbpr 11,1 with wl.ko and still same result. Scan failure > in endless loop return -22 just like in my previously attached log dump. > >> Please test this version, ensuring you have the latest NM/wicd/whatever > > Again I'm NOT using NetworkManager, wicd or anything else. Just > wpa_supplicant with a dead simple configuration and an ordinary > WAP. > > 2.5-2+v2.4-3+b1 is the last version that works. Right. Please report this to the upstream at hos...@lists.infradead.org. Please bear in mind "2.5-2+v2.4-3+b1" is, in fact, 2.4, not 2.5, despite the confusing version number. I will upload another update to 2.4 with a fix for another bug fixed in 2.5 soon. 2.6 will be available in experimental. -- Cheers, Andrew
Bug#854719: [pkg-wpa-devel] Bug#854719: Bug#854719: hostapd: Failed to set beacon parameters
On 10/02/17 00:05, Vincent Danjean wrote: > Le 09/02/2017 à 23:20, Andrew Shadura a écrit : >> Hi, >> >> On 9 February 2017 at 21:10, Vincent Danjean wrote: >>> Package: hostapd >>> Version: 1:2.5-2+v2.4-3+b1 >>> Severity: grave >>> Justification: renders package unusable >>> >>> Hi, >>> >>> I just upgraded a machine from jessie to stretch. With the stretch >>> version of hostapd, the deamon does not start: >>> # hostapd /etc/hostapd/hostapd.conf >>> Configuration file: /etc/hostapd/hostapd.conf >>> Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1" >>> Failed to set beacon parameters >>> Interface initialization failed >>> wlan0: interface state UNINITIALIZED->DISABLED >>> wlan0: AP-DISABLED >>> wlan0: Unable to setup interface. >>> wlan0: interface state DISABLED->DISABLED >>> wlan0: AP-DISABLED >>> hostapd_free_hapd_data: Interface wlan0_2 wasn't started >>> wlan0: AP-DISABLED >>> hostapd_free_hapd_data: Interface wlan0_1 wasn't started >>> wlan0: AP-DISABLED >>> hostapd_free_hapd_data: Interface wlan0 wasn't started >>> nl80211: deinit ifname=wlan0 disabled_11b_rates=0 >>> # >>> >>> If I downgrade the hostapd package to the jessie version >>> (1:2.3-1+deb8u4), then it works perfectly: >>> # apt-get install --reinstall hostapd/jessie >>> [...] >>> Les paquets suivants seront mis à une VERSION INFÉRIEURE : >>> hostapd >>> 0 mis à jour, 0 nouvellement installés, 1 remis à une version inférieure, 0 >>> à enlever et 44 non mis à jour. >>> [...] >>> Préparation du dépaquetage de .../hostapd_1%3a2.3-1+deb8u4_amd64.deb ... >>> Dépaquetage de hostapd (1:2.3-1+deb8u4) sur (1:2.5-2+v2.4-3+b1) ... >>> Paramétrage de hostapd (1:2.3-1+deb8u4) ... >>> [...] >>> # hostapd /etc/hostapd/hostapd.conf >>> Configuration file: /etc/hostapd/hostapd.conf >>> Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1" >>> Using interface wlan0_1 with hwaddr f4:ec:38:c5:fd:95 and ssid "dino" >>> Using interface wlan0_2 with hwaddr f4:ec:38:c5:fd:96 and ssid >>> "dino-guess" >>> wlan0: interface state UNINITIALIZED->ENABLED >>> wlan0: AP-ENABLED >>> [.. and then authentifications from client...] >>> >>> So, it seems there is a major regression in the hostapd package. >>> Feel free to ask more information if required. >> >> I'm going to ask you to tell me what hardware you use. > > From lspci: > 04:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter > (PCI-Express) (rev 01) > If you need more information, just tell me where to look at. > >> Also, please try >> and get more logs please, especially those wpa_supplicant produces with >> -dt (you can add it with a systemd override file). > > I do not use wpa_supplicant. I only run hostapd. I use this computer > (and this wireless card) as an AP at home. > You can find in attachment the output of > # hostapd -dd /etc/hostapd/hostapd.conf > - for the testing version > - for the stable version > - for the unstable version Here, I meant hostapd. However, wpa_supplicant and hostapd are two parts of the same software package, and they use the same drivers AFAIK. >>> Note that the unstable version works. So I will mark this bug as fixed >>> for the 1:2.6-3 version as soon as I get its number >> >> That's pretty much a bad news, as 2.6 breaks networking for lot more >> people, it seems. >> >> There's a thread about a related issue: >> http://lists.infradead.org/pipermail/hostap/2017-January/037042.html >> >> Please have a look and let me know whether what you're observing is the >> same bug or not, and whether the patch works. > > I'm not using wpa_supplicant, so it does not seem the same bug. > Moreover, the proposed patch in > http://lists.infradead.org/pipermail/hostap/2017-January/037060.html > do not apply at all for the testing sources. > In the testing sources, in the wpa_driver_nl80211_set_ap function, > the "if (beacon_set)" test do not have any "else" clause to patch. That doesn't sound good. Maybe try emailing the hostap mailing list? -- Cheers, Andrew
Bug#854719: [pkg-wpa-devel] Bug#854719: hostapd: Failed to set beacon parameters
Hi, On 9 February 2017 at 21:10, Vincent Danjean wrote: > Package: hostapd > Version: 1:2.5-2+v2.4-3+b1 > Severity: grave > Justification: renders package unusable > > Hi, > > I just upgraded a machine from jessie to stretch. With the stretch > version of hostapd, the deamon does not start: > # hostapd /etc/hostapd/hostapd.conf > Configuration file: /etc/hostapd/hostapd.conf > Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1" > Failed to set beacon parameters > Interface initialization failed > wlan0: interface state UNINITIALIZED->DISABLED > wlan0: AP-DISABLED > wlan0: Unable to setup interface. > wlan0: interface state DISABLED->DISABLED > wlan0: AP-DISABLED > hostapd_free_hapd_data: Interface wlan0_2 wasn't started > wlan0: AP-DISABLED > hostapd_free_hapd_data: Interface wlan0_1 wasn't started > wlan0: AP-DISABLED > hostapd_free_hapd_data: Interface wlan0 wasn't started > nl80211: deinit ifname=wlan0 disabled_11b_rates=0 > # > > If I downgrade the hostapd package to the jessie version > (1:2.3-1+deb8u4), then it works perfectly: > # apt-get install --reinstall hostapd/jessie > [...] > Les paquets suivants seront mis à une VERSION INFÉRIEURE : > hostapd > 0 mis à jour, 0 nouvellement installés, 1 remis à une version inférieure, 0 à > enlever et 44 non mis à jour. > [...] > Préparation du dépaquetage de .../hostapd_1%3a2.3-1+deb8u4_amd64.deb ... > Dépaquetage de hostapd (1:2.3-1+deb8u4) sur (1:2.5-2+v2.4-3+b1) ... > Paramétrage de hostapd (1:2.3-1+deb8u4) ... > [...] > # hostapd /etc/hostapd/hostapd.conf > Configuration file: /etc/hostapd/hostapd.conf > Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1" > Using interface wlan0_1 with hwaddr f4:ec:38:c5:fd:95 and ssid "dino" > Using interface wlan0_2 with hwaddr f4:ec:38:c5:fd:96 and ssid > "dino-guess" > wlan0: interface state UNINITIALIZED->ENABLED > wlan0: AP-ENABLED > [.. and then authentifications from client...] > > So, it seems there is a major regression in the hostapd package. > Feel free to ask more information if required. I'm going to ask you to tell me what hardware you use. Also, please try and get more logs please, especially those wpa_supplicant produces with -dt (you can add it with a systemd override file). > Note that the unstable version works. So I will mark this bug as fixed > for the 1:2.6-3 version as soon as I get its number That's pretty much a bad news, as 2.6 breaks networking for lot more people, it seems. There's a thread about a related issue: http://lists.infradead.org/pipermail/hostap/2017-January/037042.html Please have a look and let me know whether what you're observing is the same bug or not, and whether the patch works. Thanks! -- Cheers, Andrew
Bug#852513: grub-efi-amd64: during configuration: "No space left on device"
On Wed, 25 Jan 2017 12:46:55 0900 Norbert Preining wrote: > > > Could not delete variable: No space left on device > > The problem is with efibootmgr that cannot add new entries. > > It turns out that there were incredible many entries in > /sys/fs/pstore > related to some dumps. I have removed all of them. Thank you for that! I had a broken system due to the exact same error as you for a few months now (needing to bootstrap boot with rEFInd each time), and deleting the contents of /sys/fs/pstore and then doing this grub upgrade fixed it.
Bug#850230: fabric: FTBFS (sbuild hangs)
On Thu, Jan 5, 2017 at 5:05 AM, Santiago Vila wrote: > The bug should be reproducible with sbuild on a single CPU virtual machine. > It always fail for me (I tried 10 times in different autobuilders), and > it also fails here: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fabric.html Hi Santiago, Thanks for the report. I had been unable to reproduce this. I tried locally with both sbuild and pbuilder with no issues. So I spun up a single CPU VM with an sbuild environment and was able to reproduce this issue there. Adding another core to the VM, it built successfully again. After some further debugging, I seem to have tracked the issue down to a specific test: https://github.com/fabric/fabric/blob/1.13.1/tests/test_tasks.py#L420 It's going to require some more detective work to find the root cause, but for now I'm going to disable it as part of the package build. Thanks, -- Andrew Starr-Bochicchio Debian Developer <http://qa.debian.org/developer.php?login=asb> Ubuntu Developer <https://launchpad.net/~andrewsomething> PGP/GPG Key ID: 3B56E2BBD53FDCB1
Bug#849122: [pkg-wpa-devel] Bug#849122: Wifi stop working with wpasupplicant 2.6-2
Hi, On 14 Jan 2017 16:16, "marcelomen...@gmail.com" wrote: Hi, I'm having this issue as well. For weeks now, every time I forget about it and do an aptitude upgrade I have to manually downgrade to 2.5-2+v2.4-3+b1 because my dongle USB stop working. I'm afraid that in some more upgrades the package won't install and I get stuck without wifi! :-) Device: Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter dmesg got filled with: [ 1182.365621] IPv6: ADDRCONF(NETDEV_UP): wlxe8de271f313a: link is not ready [ 1183.650554] R8188EU: ERROR indicate disassoc /var/log/syslog Jan 14 10:56:18 debian wpa_supplicant[3966]: Successfully initialized wpa_supplicant Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9175] supplicant: wpa_supplicant running Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9182] device (wlxe8de271f313a): supplicant interface state: init -> starting Jan 14 10:56:18 debian wpa_supplicant[3966]: nl80211: Driver does not support authentication/association or connect commands Jan 14 10:56:18 debian wpa_supplicant[3966]: nl80211: deinit ifname=wlxe8de271f313a disabled_11b_rates=0 Jan 14 10:56:18 debian wpa_supplicant[3966]: ioctl[SIOCSIWAP]: Operation not permitted Jan 14 10:56:18 debian wpa_supplicant[3966]: ioctl[SIOCSIWENCODEEXT]: Invalid argument Jan 14 10:56:18 debian wpa_supplicant[3966]: ioctl[SIOCSIWENCODEEXT]: Invalid argument Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9751] sup-iface[0x55d776f7c0a0,wlxe8de271f313a]: supports 1 scan SSIDs Jan 14 10:56:18 debian kernel: [ 1232.450878] IPv6: ADDRCONF(NETDEV_UP): wlxe8de271f313a: link is not ready Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9761] device (wlxe8de271f313a): supplicant interface state: starting -> ready Jan 14 10:56:18 debian NetworkManager[3929]: [1484405778.9762] device (wlxe8de271f313a): state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] Jan 14 10:56:18 debian kernel: [ 1232.457289] R8188EU: ERROR indicate disassoc Jan 14 10:56:19 debian NetworkManager[3929]: [1484405779.0836] device (wlxe8de271f313a): set-hw-addr: new MAC address XX:XX:XX:XX:XX:XX not successfully set (scanning) -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com ___ Pkg-wpa-devel mailing list pkg-wpa-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-wpa-devel It seems it's the randomisation issue. Have you tried 2.6 with an upgraded NetworkManager, and if that doesn't help, try disabling MAC randomisation? -- Cheers, Andrew
Bug#851204: libdigidoc: drop the uninstallable libdigidoc-dbg package
Control: reopen -1 On 13 January 2017 at 20:11, Andrew Shadura wrote: > On 12 January 2017 at 23:12, Andreas Beckmann wrote: >> the libdigidoc package builds both a -dbg and a -dbgsym package. The >> libdigidoc-dbg is now uninstallable in sid - please remove it from >> debian/control. > > Thanks for the bug report. I don't plan to ship this package in > stretch, so I will fix it as soon as testing migrations stop. To be honest, I’m fairly unhappy that you went ahead and uploaded an NMU without asking me first and without pasting an nmudiff in this bug. I explicitly mentioned this intention in the other bug discussion, I’m not sure why you have decided to ignore it. Please avoid doing so in the future. Thanks. -- Cheers, Andrew
Bug#851204: libdigidoc: drop the uninstallable libdigidoc-dbg package
Hi, On 12 January 2017 at 23:12, Andreas Beckmann wrote: > the libdigidoc package builds both a -dbg and a -dbgsym package. The > libdigidoc-dbg is now uninstallable in sid - please remove it from > debian/control. Thanks for the bug report. I don't plan to ship this package in stretch, so I will fix it as soon as testing migrations stop. -- Cheers, Andrew
Bug#849122: Fwd: With 2.6-2 i dont have the wifi adapter in the (network-manager) list available.
-- Forwarded message -- From: data cruncher Date: 11 January 2017 at 03:40 Subject: Re: With 2.6-2 i dont have the wifi adapter in the (network-manager) list available. To: Andrew Shadura Hi Unfortunately not really, there are no error messages nor similar in the log files. When i update to 2.6.2, it continues working, until the next reboot, then i cannot "access" the device anymore (although visible with ifconfig -a i cant ifup nor ifconfig wlx... up, nor network-manager sees the device). When downgrading to 2.5-2+v2.4-3+b1 (and reboot), everything works normally again. I recompiled the nic driver having wpasuplicant 2.6.2 installed, didnt help. Restarting network-manager, wpa_supplicant, all didnt help. I suspect dbus as it happens after the restart, but can't be sure... Also it seems only to happen when one has compiled the module himself, other (usb) cards works fine. If you know what information you would need just let me know. Regards On Tue, Jan 10, 2017 at 5:14 PM, Andrew Shadura wrote: > > Control: tag -1 moreinfo > > On Thu, 22 Dec 2016 20:41:31 +0100 cruncher wrote: > > Me too, i have also that problem. > > > > When installing 2.6-2, i cant see even the device anywhere (ifconfig nor > > network-manager), downgrading to 2.5-2+v2.4-3+b1 works again. > > > > I'm building the driver module (8188eu) also myself for this device: > > Wifi adapter: 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n > > Wireless > > Network Adapter > > Have you resolved this issue? Could you please provide more details, > logs, anything? > > -- > Cheers, > Andrew -- Cheers, Andrew
