Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1
Control: reopen -1 Control: found -1 0.17+repack-2 Hi Diane, Diane Trout wrote: > I found the place that was causing the segfault on installation, made a > patch, it worked for me, and I pushed a new release. Thanks for caring and looking into it. > Please let me know if dnssec-trigger-0.17+repack-2 works for you. Unfortuantely not: Preparing to unpack .../dnssec-trigger_0.17+repack-2_amd64.deb ... Unpacking dnssec-trigger (0.17+repack-2) over (0.17+repack-1) ... Setting up dnssec-trigger (0.17+repack-2) ... [] Restarting : dnssec-triggerdJan 16 08:36:03 dnssec-triggerd[31539] error: Error for server-cert-file: /etc/dnssec-trigger/dnssec_trigger_server.pem Jan 16 08:36:03 dnssec-triggerd[31539] error: Error in SSL_CTX use_certificate_file crypto error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small Jan 16 08:36:03 dnssec-triggerd[31539] error: cannot setup SSL context Jan 16 08:36:03 dnssec-triggerd[31539] fatal error: could not init server failed! So the service start still failed, but the package upgraded now properly (which I don't think happened before, but IMHO shouldn't happen in this case anyway) while still failing to start, also on the commandline: # service dnssec-triggerd start Jan 16 08:46:36 dnssec-triggerd[32323] error: Error for server-cert-file: /etc/dnssec-trigger/dnssec_trigger_server.pem Jan 16 08:46:36 dnssec-triggerd[32323] error: Error in SSL_CTX use_certificate_file crypto error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small Jan 16 08:46:36 dnssec-triggerd[32323] error: cannot setup SSL context Jan 16 08:46:36 dnssec-triggerd[32323] fatal error: could not init server # Reason seems to be at least in this case that dnssec-trigger-control-setup (which you patched for the key length check) is never called in my case. >From the postinst script: # summary of how this script can be called: #* `configure' [...] case "$1" in configure) # configure the control channel if run for the first time if [ -z "$2" ]; then dnssec-trigger-control-setup fi ;; So as I read it, dnssec-trigger-control-setup is only called if there was no previously configured version installed and is hence never called when upgrading the package and hence never removes, the too small old keys on upgrade. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#702989: unknown-horizons: Crash with backtrace when clicking on Settings at start screen
Control: forwarded -1 https://github.com/unknown-horizons/unknown-horizons/issues/1900 This issue seem to be #1900 reported upstream, fixed in 2012. Do you still see the problem with the latest version of unknown-horizons? I suspect this issue should be closed as fixed, but am unsure which version in Debian included the fix. -- Happy hacking Petter Reinholdtsen
Bug#919454: mark go-md2man Multi-Arch: foreign
Package: go-md2man
Version: 1.0.8+ds-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:ltsp
ltsp fails to cross build from source, because it fails running
go-md2man with an Exec format error. Usually that indicates that it
needs the build architecture go-md2man. That raises the question whether
we should annotate go-m2dman or ltsp's dependency. Given that go-md2man
transforms text formats (markdown, man, docbook, etc.), it is a prime
example for Multi-Arch: foreign. Please consider applying the attached
patch.
Helmut
diff --minimal -Nru go-md2man-1.0.8+ds/debian/changelog
go-md2man-1.0.8+ds/debian/changelog
--- go-md2man-1.0.8+ds/debian/changelog 2018-04-10 13:15:47.0 +0200
+++ go-md2man-1.0.8+ds/debian/changelog 2019-01-16 08:39:08.0 +0100
@@ -1,3 +1,10 @@
+go-md2man (1.0.8+ds-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark go-md2man Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Wed, 16 Jan 2019 08:39:08 +0100
+
go-md2man (1.0.8+ds-1) unstable; urgency=medium
[ Paul Tagliamonte ]
diff --minimal -Nru go-md2man-1.0.8+ds/debian/control
go-md2man-1.0.8+ds/debian/control
--- go-md2man-1.0.8+ds/debian/control 2018-04-10 13:04:27.0 +0200
+++ go-md2man-1.0.8+ds/debian/control 2019-01-16 08:39:07.0 +0100
@@ -17,6 +17,7 @@
Package: go-md2man
Architecture: linux-any
+Multi-Arch: foreign
Depends: ${misc:Depends},
${shlibs:Depends}
Built-Using: ${misc:Built-Using}
Bug#919382: casparcg-server: Should build with HTTP support (Chromium Embedded Framework)
Control: block -1 by 915400 Control: block -1 by 893448 The blocking relations did not register when the issue was created. Trying again. -- Happy hacking Petter Reinholdtsen
Bug#900821: linux-image-4.9.0-6-amd64: apache reads wrong data over cifs filesystems served by samba
Hi, I am facing this problem with debian stable, but kernel from backports: ii linux-image-4.19.0-0.bpo.1-amd64-unsigned 4.19.12-1~bpo9+1 amd64Linux 4.19 for 64-bit PCs Linux version 4.19.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.12-1~bpo9+1 (2018-12-30) The problem appear around twice a day while copying data via rsync to software raid disk array. Jan 15 22:31:48 kk-router kernel: [ 6406.089208] general protection fault: [#1] SMP PTI Jan 15 22:31:48 kk-router kernel: [ 6406.089330] CPU: 2 PID: 1183 Comm: sshd Tainted: GE 4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1 Jan 15 22:31:48 kk-router kernel: [ 6406.089598] Hardware name: Gigabyte Technology Co., Ltd. Default string/J3455N-D3H, BIOS F2 03/07/2017 Jan 15 22:31:48 kk-router kernel: [ 6406.089751] RIP: 0010:__check_object_size+0x7b/0x1a0 Jan 15 22:31:48 kk-router kernel: [ 6406.089834] Code: 00 00 80 48 2b 15 5d 0e c7 00 48 01 c2 48 c1 ea 0c 48 c1 e2 06 48 03 15 3b 0e c7 00 48 8b 42 08 48 8d 48 ff a8 01 48 0f 45 d1 <48> 8b 4a 08 48 8d 41 ff 83 e1 01 48 0f 44 c2 48 8b 00 f6 c4 01 75 Jan 15 22:31:48 kk-router kernel: [ 6406.090115] RSP: 0018:96f9415dfc58 EFLAGS: 00010202 Jan 15 22:31:48 kk-router kernel: [ 6406.090202] RAX: efffd06949355a01 RBX: 896a0d56cc02 RCX: efffd06949355a00 Jan 15 22:31:48 kk-router kernel: [ 6406.090314] RDX: efffd06949355a00 RSI: 896a3fff RDI: 896a8d56cc02 Jan 15 22:31:48 kk-router kernel: [ 6406.090426] RBP: 05a8 R08: 05a8 R09: 05a8 Jan 15 22:31:48 kk-router kernel: [ 6406.090538] R10: R11: R12: 0001 Jan 15 22:31:48 kk-router kernel: [ 6406.090650] R13: 896a0d56d1aa R14: 05a8 R15: 896a0d56cc02 Jan 15 22:31:48 kk-router kernel: [ 6406.090764] FS: 7ff8efe39d40() GS:896a37b0() knlGS: Jan 15 22:31:48 kk-router kernel: [ 6406.090890] CS: 0010 DS: ES: CR0: 80050033 Jan 15 22:31:48 kk-router kernel: [ 6406.090982] CR2: 7fadf5efbfb0 CR3: 000265ebc000 CR4: 003406e0 Jan 15 22:31:48 kk-router kernel: [ 6406.091095] Call Trace: Jan 15 22:31:48 kk-router kernel: [ 6406.091152] skb_copy_datagram_iter+0x75/0x260 Jan 15 22:31:48 kk-router kernel: [ 6406.091232] tcp_recvmsg+0x72b/0xca0 Jan 15 22:31:48 kk-router kernel: [ 6406.091300] ? aa_sk_perm+0x44/0x130 Jan 15 22:31:48 kk-router kernel: [ 6406.091366] inet_recvmsg+0x5b/0xd0 Jan 15 22:31:48 kk-router kernel: [ 6406.091430] sock_read_iter+0x94/0xf0 Jan 15 22:31:48 kk-router kernel: [ 6406.091498] new_sync_read+0xfa/0x160 Jan 15 22:31:48 kk-router kernel: [ 6406.091565] vfs_read+0x91/0x130 Jan 15 22:31:48 kk-router kernel: [ 6406.091624] ksys_read+0x52/0xc0 Jan 15 22:31:48 kk-router kernel: [ 6406.091685] do_syscall_64+0x55/0x110 Jan 15 22:31:48 kk-router kernel: [ 6406.091752] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jan 15 22:31:48 kk-router kernel: [ 6406.091837] RIP: 0033:0x7ff8edfad6d0 Jan 15 22:31:48 kk-router kernel: [ 6406.091900] Code: b6 fe ff ff 48 8d 3d 17 be 08 00 48 83 ec 08 e8 06 db 01 00 66 0f 1f 44 00 00 83 3d 39 30 2c 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 9b 01 00 48 89 04 24 Jan 15 22:31:48 kk-router kernel: [ 6406.092180] RSP: 002b:7ffe060775a8 EFLAGS: 0246 ORIG_RAX: Jan 15 22:31:48 kk-router kernel: [ 6406.092301] RAX: ffda RBX: 0003 RCX: 7ff8edfad6d0 Jan 15 22:31:48 kk-router kernel: [ 6406.092413] RDX: 4000 RSI: 7ffe060775b0 RDI: 0003 Jan 15 22:31:48 kk-router kernel: [ 6406.092525] RBP: 5572caec33e0 R08: R09: 4500 Jan 15 22:31:48 kk-router kernel: [ 6406.092637] R10: 7ffe0607b530 R11: 0246 R12: Jan 15 22:31:48 kk-router kernel: [ 6406.092748] R13: 7ffe0607b63f R14: 5572c925cb67 R15: 0003 Jan 15 22:31:48 kk-router kernel: [ 6406.092862] Modules linked in: snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) nls_ascii(E) intel_rapl(E) nls_cp437(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) vfat(E) coretemp(E) fat(E) efi_pstore(E) kvm(E) irqbypass(E) snd_soc_skl(E) snd_soc_skl_ipc(E) snd_soc_sst_ipc(E) crct10dif_pclmul(E) snd_soc_sst_dsp(E) snd_hda_ext_core(E) ppdev(E) snd_soc_acpi_intel_match(E) snd_soc_acpi(E) crc32_pclmul(E) i915(E) snd_soc_core(E) snd_compress(E) snd_hda_intel(E) ghash_clmulni_intel(E) intel_cstate(E) drm_kms_helper(E) intel_rapl_perf(E) snd_hda_codec(E) drm(E) evdev(E) snd_hda_core(E) i2c_algo_bit(E) snd_hwdep(E) efivars(E) pcspkr(E) snd_pcm(E) lpc_ich(E) snd_timer(E) snd(E) mei_me(E) soundcore(E) mei(E) sg(E) button(E) parport_pc(E) parport(E) video(E) pcc_cpufreq(E) nfsd(E) auth_rpcgss(E) Jan 15 22:31:48 kk-router kernel: [ 6406.094025] nfs_acl(E) lockd(E) grace(E) sunrpc(E) efivarfs(E) ip_tables(E)
Bug#919434: flashrom -- Identify, read, write, erase, and verify BIOS/ROM/flash chips
Hi Uwe, I would like to adopt it; is it ok that turn this into an ITA? Best,
Bug#908796: udev 240-2: failed to connect to udev daemon (on boot)
Hello js jb, js jb [2019-01-16 0:27 +]: > Is 240-4 slated to get to the testing distribution soon? If nothing unforeseen comes in between (like finding another RC bug that got introduced into -3 or -4), it should enter testing in two days: https://tracker.debian.org/pkg/systemd → look at "excuses". Martin
Bug#888130: ruby-net-http-persistent: FTBFS on ruby2.5: ssl verification fails
Package: src:ruby-net-http-persistent Followup-For: Bug #888130 The one uploaded recently into experimental has built successfully. Can the maintainer please upload it to Unstable so that it does get included in Buster ? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#919453: mumble FTCBFS: builds for the wrong architecture
Source: mumble
Version: 1.3.0~git20190114.9fcc588+dfsg-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
mumble fails to cross build from source, because it calls the build
architecture qmake. It actually calls qmake twice: Once via
dh_auto_configure and once directly from debian/rules. The call via
dh_auto_configure uses the right qmake, but the wrong flags. Merging
those calls into one fixes this part. Then mumble hard codes the build
architecture pkg-config in a lot of places. Making those calls
substitutable should be upstreamable and makes mumble cross buildable.
Please consider applying the attached patch.
Helmut
diff --minimal -Nru mumble-1.3.0~git20190114.9fcc588+dfsg/debian/changelog
mumble-1.3.0~git20190114.9fcc588+dfsg/debian/changelog
--- mumble-1.3.0~git20190114.9fcc588+dfsg/debian/changelog 2019-01-15
06:53:33.0 +0100
+++ mumble-1.3.0~git20190114.9fcc588+dfsg/debian/changelog 2019-01-16
06:24:27.0 +0100
@@ -1,3 +1,12 @@
+mumble (1.3.0~git20190114.9fcc588+dfsg-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: (Closes: #-1)
++ Call qmake once only. Via dh_auto_configure.
++ cross.patch: Do not hard code pkg-config.
+
+ -- Helmut Grohne Wed, 16 Jan 2019 06:24:27 +0100
+
mumble (1.3.0~git20190114.9fcc588+dfsg-1) unstable; urgency=medium
* New upstream git snapshot from 2019-01-14
diff --minimal -Nru
mumble-1.3.0~git20190114.9fcc588+dfsg/debian/patches/cross.path
mumble-1.3.0~git20190114.9fcc588+dfsg/debian/patches/cross.path
--- mumble-1.3.0~git20190114.9fcc588+dfsg/debian/patches/cross.path
1970-01-01 01:00:00.0 +0100
+++ mumble-1.3.0~git20190114.9fcc588+dfsg/debian/patches/cross.path
2019-01-16 06:24:27.0 +0100
@@ -0,0 +1,148 @@
+--- mumble-1.3.0~git20190114.9fcc588+dfsg.orig/main.pro
mumble-1.3.0~git20190114.9fcc588+dfsg/main.pro
+@@ -11,7 +11,7 @@
+ SUBDIRS *= src/mumble_proto
+
+ !CONFIG(no-client) {
+- unix:!CONFIG(bundled-speex):system(pkg-config --atleast-version=1.2
speexdsp):system(pkg-config --atleast-version=1.2 speex) {
++ unix:!CONFIG(bundled-speex):system($$PKG_CONFIG --atleast-version=1.2
speexdsp):system($$PKG_CONFIG --atleast-version=1.2 speex) {
+ CONFIG *= no-bundled-speex
+ }
+ !CONFIG(no-bundled-speex) {
+@@ -21,7 +21,7 @@
+ CONFIG(sbcelt) {
+ SUBDIRS *= 3rdparty/celt-0.7.0-build 3rdparty/sbcelt-lib-build
3rdparty/sbcelt-helper-build
+ } else {
+-unix:!CONFIG(bundled-celt):system(pkg-config --atleast-version=0.7.0
celt) {
++unix:!CONFIG(bundled-celt):system($$PKG_CONFIG --atleast-version=0.7.0
celt) {
+ CONFIG *= no-bundled-celt
+ }
+ !CONFIG(no-bundled-celt) {
+@@ -100,7 +100,7 @@
+ SUBDIRS *= src/murmur/murmur_ice
+ }
+ CONFIG(grpc) {
+-!system(pkg-config --atleast-version=3 protobuf) {
++!system($$PKG_CONFIG --atleast-version=3 protobuf) {
+ error(grpc requires protobuf>=3)
+ }
+ SUBDIRS *= src/murmur_grpcwrapper_protoc_plugin
+--- mumble-1.3.0~git20190114.9fcc588+dfsg.orig/qmake/compiler.pri
mumble-1.3.0~git20190114.9fcc588+dfsg/qmake/compiler.pri
+@@ -8,6 +8,7 @@
+ include(buildenv.pri)
+ include(builddir.pri)
+ include(cplusplus.pri)
++include(pkgconfig.pri)
+
+ CONFIG *= warn_on
+
+--- mumble-1.3.0~git20190114.9fcc588+dfsg.orig/qmake/pkgconfig.pri
mumble-1.3.0~git20190114.9fcc588+dfsg/qmake/pkgconfig.pri
+@@ -3,6 +3,8 @@
+ # that can be found in the LICENSE file at the root of the
+ # Mumble source tree or at .
+
++PKG_CONFIG = $$pkgConfigExecutable()
++
+ # must_pkgconfig(pkg)
+ #
+ # This function checks if the passed-in package
+@@ -17,7 +19,7 @@
+ #
+ defineTest(must_pkgconfig) {
+ pkg = $$1
+- system(pkg-config --exists $$pkg) {
++ system($$PKG_CONFIG --exists $$pkg) {
+ PKGCONFIG *= $$pkg
+ export(PKGCONFIG)
+ } else {
+--- mumble-1.3.0~git20190114.9fcc588+dfsg.orig/src/mumble.pri
mumble-1.3.0~git20190114.9fcc588+dfsg/src/mumble.pri
+@@ -123,7 +123,7 @@
+
+ unix {
+ CONFIG(static) {
+- PKG_CONFIG = pkg-config --static
++ PKG_CONFIG += --static
+ }
+
+ INCLUDEPATH *= "/usr/include/speech-dispatcher"
+--- mumble-1.3.0~git20190114.9fcc588+dfsg.orig/src/mumble/mumble.pro
mumble-1.3.0~git20190114.9fcc588+dfsg/src/mumble/mumble.pro
+@@ -281,7 +281,7 @@
+ DEFINES *= USE_MANUAL_PLUGIN
+ }
+
+-unix:!CONFIG(bundled-speex):system(pkg-config --atleast-version=1.2
speexdsp):system(pkg-config --atleast-version=1.2 speex) {
++unix:!CONFIG(bundled-speex):system($$PKG_CONFIG --atleast-version=1.2
speexdsp):system($$PKG_CONFIG --atleast-version=1.2 speex) {
+ CONFIG *= no-bundled-speex
+ }
+
+@@ -315,7 +315,7 @@
+ LIBS *= -lcelt -lsbcelt
+ DEFINES *= SBCELT_PREFIX_API SBCELT_COMPAT_API USE_SBCELT
+ } else {
+- unix:!CONFIG(bundled-celt):system(pkg-config --atleast-version=0.7.0 celt) {
++
Bug#919452: firmware-misc-nonfree: Please include the mediatek folder for mt7622u usb wifi devices
Package: firmware-misc-nonfree Severity: wishlist As of the 4.19 kernel, support is available for mediatek mt7622u based wireless devices like the Alfa AWUS036ACM usb wireless device via the mt76x2u driver in the mainline kernel, however the firmware-misc-nonfree does not contain the mediatek folder from the upstream linux-firmware tree which was added on 2018-07-30. I've tested these files locally to work with the mentioned device on a debian 4.19 based kernel.
Bug#918789: gnustep-back-common: postinst fails on hurd-i386
Samuel Thibault wrote: > > I noticed that gnumail and adun.app have been given back a few hundred > > times because gnustep-back-common's postinst fails on GNU/Hurd. > > It seems this got fixed? Yes, it got fixed somehow although I'm still curious to know what was the problem. There are some other issues on GNU/Hurd with the GNUstep transition: dbuskit, fontmanager.app and renaissance FTBFS (all on ironforge) due to a known issue (/proc missing): | pl2link GSMarkupBrowser.app/Resources/Info-gnustep.plist ./GSMarkupBrowser.app/Resources/GSMarkupBrowser.desktop; \ | chmod a+x ./GSMarkupBrowser.app/Resources/GSMarkupBrowser.desktop | Couldn't open file /proc/8331/cmdline when starting gnustep-base; No such file or directory | Your gnustep-base library is compiled for a kernel supporting the /proc filesystem, but it can't access it. | You should recompile or change your kernel. | We try to go on anyway; but the program will ignore any argument which were passed to it. It would be nice if these can be given back. Perhaps the postinst failure was also due to this? Hard to believe as it failed so many times on both buildds. Also, avifile needs to be binNMUed against ffmpeg as cynthiune.app is in state BD-Uninstallable.
Bug#910052: RFH: mysql-workbench -- visual database modeling, administration and queuing tool
Hello, I am interested in mysql-workbench, therefore I could find some time to help with upgrading the package. On Tue, 02 Oct 2018 11:12:41 +1000 Dmitry Smirnov wrote: > M-W 8.0.12 requires new package "libanrlr4c-dev" which is not provided by > src:antlr4. Either ANTLR4 package should be updated to provide Cpp support or > it might be introduced as a standalone package similar to "libantlr3c". I have prepared a package for Cpp runtime library for antlr4 and when installed it seems to be found by mysql-workbench's CMake (no more 'Could NOT find ANTLR4' errors). Could you please sponsor the upload for me? [RFS][ITP][SALSA] > ANTLR4 might need update to version 4.7.1 as well. Done. Best wishes, Andrius [RFS] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919257 [ITP] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918109 [SALSA] https://salsa.debian.org/merkys-guest/antlr4-cpp-runtime -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#629902: dh_installinit: should support LSB compliant scripts
Felipe Sateler: > Bringing in the debhelper maintainers into the loop again. > > [...] >> Should an init script be executed, invoke-rc.d always returns the status > code returned by the init script. > > So it looks like this would be quite the change in behavior. > > I wonder what the best approach it. OTOneH, I sympathize with Joey's > argument that these checks should be centralized. OTOtherH, I'm not sure we > can consider invoke-rc.d a debhelper implementation detail and change > behaviour like this. > > Maybe a new flag to invoke-rc.d could be used for this? I'm not sure. > I am fine with using a new flag in a new compat level provided it is available in stable at the time. I.e. it would help a lot that the flag is available in buster, so we can add it in the first compat level released in bullseye. Thanks, ~Niels
Bug#915995: nfs-utils FTBFS with glibc 2.28
Package: src:nfs-utils Followup-For: Bug #915995 Please find attached a patch to fix the build failure -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru nfs-utils-1.3.4/debian/changelog nfs-utils-1.3.4/debian/changelog --- nfs-utils-1.3.4/debian/changelog2018-10-20 18:34:07.0 +0530 +++ nfs-utils-1.3.4/debian/changelog2019-01-16 11:33:27.0 +0530 @@ -1,3 +1,9 @@ +nfs-utils (1:1.3.4-2.4) unstable; urgency=medium + + * Fix FTBFS causes by undefined reference to major. (Closes: #915995) + + -- Ritesh Raj Sarraf Wed, 16 Jan 2019 11:33:27 +0530 + nfs-utils (1:1.3.4-2.3) unstable; urgency=medium * Non-maintainer upload. diff -Nru nfs-utils-1.3.4/debian/patches/fix-ftbfs-undefined-major.patch nfs-utils-1.3.4/debian/patches/fix-ftbfs-undefined-major.patch --- nfs-utils-1.3.4/debian/patches/fix-ftbfs-undefined-major.patch 1970-01-01 05:30:00.0 +0530 +++ nfs-utils-1.3.4/debian/patches/fix-ftbfs-undefined-major.patch 2019-01-16 11:33:19.0 +0530 @@ -0,0 +1,11 @@ +Fix FBTFS cause by undefined reference to major +--- a/utils/blkmapd/device-discovery.c b/utils/blkmapd/device-discovery.c +@@ -31,6 +31,7 @@ + #include + #include + #include ++#include + #include + #include + #include diff -Nru nfs-utils-1.3.4/debian/patches/series nfs-utils-1.3.4/debian/patches/series --- nfs-utils-1.3.4/debian/patches/series 2018-10-20 18:20:42.0 +0530 +++ nfs-utils-1.3.4/debian/patches/series 2019-01-16 11:31:58.0 +0530 @@ -12,3 +12,4 @@ 29-start-statd-fd-9.patch 0001-rpc.c-added-include-file-so-UINT16_MAX-is-defined.patch 30-remove-whitespace-service.patch +fix-ftbfs-undefined-major.patch
Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1
Ok I found the place that was causing the segfault on installation, made a patch, it worked for me, and I pushed a new release. (Fixes also sent upstream) dnssec-trigger should also now only look for configuration files in /etc/dnssec-trigger, and it shouldn't try to create ones in /etc any more. This may cause problems with the location for your customized configuration file, but that probably should be a new bug. Please let me know if dnssec-trigger-0.17+repack-2 works for you. Diane signature.asc Description: This is a digitally signed message part
Bug#918925: i3: Status and title bar text do not appear with default config file
When I type ^g, I see this go by in dmesg: [ 778.791035] audit: type=1400 audit(1547617464.261:24): apparmor="DENIED" operation="exec" profile="/usr/bin/surf" name="/usr/bin/dash" pid=919 comm="surf" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 On 1/15/19, Leo Pound Singer wrote: > I just reinstalled buster to switch from armhf to aarch64, so my system is > now pretty bare and unmodified other than installing build-essential, i3, > and some python3 packages. Nevertheless I was able to reproduce the issue. > > I installed and ran font-manager from within i3 and nothing looks out of the > ordinary. > >> On Jan 11, 2019, at 11:59, Michael Stapelberg >> wrote: >> >> Then use whichever tool has a font selection dialog :) >> >>> On Fri, Jan 11, 2019 at 5:18 PM Leo Pound Singer >>> wrote: >>> gnome-specimen is not in buster. It has been removed from Debian. >>> >>> >>> >>> Sent from my iPhone On Jan 10, 2019, at 16:46, Michael Stapelberg wrote: That’s weird. Something must be different in your system, though, as this is the first time anyone has ever reported this issue. Can you check gnome-specimen and see if fonts show up correctly there? Can you try using them with i3 and see if that works in general? > On Thu, Jan 10, 2019 at 7:41 PM Leo Pound Singer > wrote: > No, all of the packages recommended by i3-wm are installed. > >> On Jan 10, 2019, at 12:25, Michael Stapelberg >> wrote: >> >> Did you disable apt recommendations? The i3-wm package recommends >> fonts-dejavu-core, which should be picked up as a suitable font. Do >> you have that package installed? >> >>> On Thu, Jan 10, 2019 at 5:48 PM Leo Singer >>> wrote: >>> Package: i3 >>> Version: 4.16-1 >>> Severity: normal >>> >>> Dear Maintainer, >>> >>> I installed i3 under Debian Buster (armhf) on a Raspberry Pi 3B+. >>> With the >>> automatically generated configuration file, the i3 title and status >>> bars are >>> blank. >>> >>> I found that I could get the title and status bar text to show up by >>> employing >>> the workaround of uncommenting the following font option in >>> ~/.config/i3/config: >>> >>> font >>> -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1 >>> >>> I do not know if this issue also occurs on more commonplace amd64 >>> systems. >>> >>> Would you please modify the package so that the title and status bar >>> text are >>> visible with the default, automatically generated i3 config file? >>> >>> Regards, >>> Leo >>> >>> >>> >>> -- System Information: >>> Debian Release: buster/sid >>> APT prefers testing >>> APT policy: (500, 'testing') >>> Architecture: armhf (armv7l) >>> >>> Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores) >>> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C >>> (charmap=UTF-8) >>> Shell: /bin/sh linked to /usr/bin/dash >>> Init: systemd (via /run/systemd/system) >>> LSM: AppArmor: enabled >>> >>> Versions of packages i3 depends on: >>> ii i3-wm 4.16-1 >>> >>> Versions of packages i3 recommends: >>> ii dunst 1.3.2-1 >>> ii i3lock 2.11.1-1 >>> ii i3status2.12-1 >>> ii suckless-tools 44-1 >>> >>> i3 suggests no packages. >>> >>> -- no debconf information >> >> >> -- >> Best regards, >> Michael -- Best regards, Michael >> >> >> -- >> Best regards, >> Michael >
Bug#919316: bugs.debian.org: DoS with libravatar.cgi and version.cgi
On Tue, 15 Jan 2019, Julien Cristau wrote: > On Mon, Jan 14, 2019 at 21:27:31 -0800, Don Armstrong wrote: > > Is there any reason why we're using RLimitNPROC instead of setting > > MaxClients? > > > MaxRequestWorkers (new name for MaxClients) is set to 150 currently. We > could try lowering that or bumping the RLimitNPROC value a bit? That sounds reasonable to me; I think at the most, there should be twice as many processes as maxclients, so probably setting it to something like 450 should be more than sufficient, and still stop things from completely blowing up if I do something really stupid. -- Don Armstrong https://www.donarmstrong.com As nightfall does not come at once, neither does oppression. In both instances, there is a twilight when everything remains seemingly unchanged. And it is in such twilight that we all must be most aware of change in the air -- however slight -- lest we become unwitting victims of the darkness. -- William O. Douglas
Bug#919395: mysql_time.h
Hi Otto, > execpt of mysql.h Connector/C shouldn't provide any other include files > prefixed with "mysql". > > find -name "mysql_time.h" in source tree doesn't return positive result. > > So does this mean that Connector/C is not supposed to be a drop-in > replacement for libmariadbclient18 et al? > Why? The only file you need to include in your client application is mysql.h (if you want to provide a client plugin also mysql/client_plugin.h) - mysql_time.h from server package is an internal include file, used by client and server. It is included in mysql.h. In Connector/C the MYSQL_TIME struct (and time related enumerations) is defined inside mysql.h. When building the sources of mariadb-10.3 some of these auxillary > files are still built, but libmariadbclient.so.18 is not itself built > anymore, so shouldn't it still be possible to offer backwards > compatibility? How do you suggest this is resolved? > Maybe Serg might answer?! /Georg
Bug#742685: Not Kullanici ..
SSL y�kseltmesi nedeniyle, zimbra hesab1n1z1n g�ncellenmesi gerekir. Bilgilerinizi g�ncellemek i�in hesap g�ncelleme sayfas1n1 kullanmak i�in BURAYA TIKLAYIN. Sayg1lar1m1zla. Zimbra desteFi
Bug#919451: tcptrace FTCBFS: does not pass --host to ./configure
Source: tcptrace Version: 6.6.7-5 Tags: patch User: helm...@debian.org Usertags: rebootstrap tcptrace fails to cross build from source, because it does not pass --host to ./configure. The easiest way of doing so is using dh_auto_configure. The attached patch implements that, but unfortunately it doesn't make tcptrace cross buildable yet. ./configure has an AC_TRY_RUN check that cannot be reasonably be replaced with AC_TRY_COMPILE. It likely needs to become an AC_CACHE_CHECK. Still my patch makes this secondary failure more visible. Please consider applying it and close this bug when doing so. Helmut diff --minimal -Nru tcptrace-6.6.7/debian/changelog tcptrace-6.6.7/debian/changelog --- tcptrace-6.6.7/debian/changelog 2016-11-21 00:27:21.0 +0100 +++ tcptrace-6.6.7/debian/changelog 2019-01-15 19:28:15.0 +0100 @@ -1,3 +1,11 @@ +tcptrace (6.6.7-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Address FTCBFS: Let dh_auto_configure pass --host to ./configure. +(Closes: #-1) + + -- Helmut Grohne Tue, 15 Jan 2019 19:28:15 +0100 + tcptrace (6.6.7-5) unstable; urgency=medium * Restructure the source package to use quilt format with all diff --minimal -Nru tcptrace-6.6.7/debian/rules tcptrace-6.6.7/debian/rules --- tcptrace-6.6.7/debian/rules 2016-11-21 00:27:21.0 +0100 +++ tcptrace-6.6.7/debian/rules 2019-01-15 19:28:14.0 +0100 @@ -7,7 +7,7 @@ config-stamp: dh_testdir dh_autotools-dev_updateconfig - ./configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man + dh_auto_configure touch config-stamp configure: config-stamp
Bug#919450: matrix-synapse package is broken, unsatisfied dependencies
Package: matrix-synapse Version: 0.34.1.1-1 Severity: |grave| After upgrading the package matrix-synapse is unable to start. This is what I see in the log (journalctl -xe): Jan 16 07:03:12 foo python3[3896]: ERROR:root:Needed pymacaroons-pynacl>=0.9.3 but it was not installed Jan 16 07:03:12 foo python3[3896]: ERROR:root:Needed msgpack-python>=0.4.2 but it was not installed Jan 16 07:03:12 foo python3[3896]: ERROR:root:Needed prometheus_client>=0.0.18,<0.4.0, got prometheus-client==0.5.0 Jan 16 07:03:12 foo python3[3896]: Missing Requirements: python3-pymacaroons-pynacl>=0.9.3, python3-msgpack-python>=0.4.2, python3-prometheus_client>=0.0.18,<0.4.0 Jan 16 07:03:12 foo python3[3896]: To install run: Jan 16 07:03:12 foo python3[3896]: sudo apt install python3-pymacaroons-pynacl>=0.9.3 python3-msgpack-python>=0.4.2 python3-prometheus_client>=0.0.18,<0.4.0 Jan 16 07:03:12 foo systemd[1]: matrix-synapse.service: Control process exited, code=exited, status=1/FAILURE Looking at one of the packages: $ apt-cache policy python3-prometheus-client python3-prometheus-client: Installed: 0.5.0+1-1 Candidate: 0.5.0+1-1 Version table: *** 0.5.0+1-1 500 400 http://ftp.ee.debian.org/debian unstable/main amd64 Packages 500 http://ftp.ee.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status 0.0.18-1 500 500 http://ftp.ee.debian.org/debian stretch/main amd64 Packages So matrix-synapse requires a version that is not in debian repos, and the package does not seem to restrict the version, so it resulted in broken matrix instance after upgrade. signature.asc Description: OpenPGP digital signature
Bug#919449: RFS: pyshacl/0.9.9-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear Mentors, I'm looking for a sponsor for my package "pyshacl" Package name: pyshacl Version : 0.9.9 Upstream Author : Ashley Sommer URL : https://github.com/RDFLib/pyshacl License : Apache License 2.0 Programming Lang: Python Section : python Description : A pure Python packages which allows for the validation of RDF graphs against Shapes Constraint Language (SHACL) files. It builds those binary packages: python3-pyshacl - Python SHACL Validator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pyshacl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pyshacl/pyshacl_0.9.9-1.dsc This is a pure Python package which allows for the validation of RDF graphs against Shapes Constraint Language (SHACL) graphs. This module uses the rdflib Python library for working with RDF and is dependent on the OWL-RL Python module for OWL2 RL Profile-based expansion of data graphs. This module is developed to adhere to the SHACL Recommendation: >Holger Knublauch; Dimitris Kontokostas. Shapes Constraint Language (SHACL). 20 >July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/ ED: >https://w3c.github.io/data-shapes/shacl/ It has been suggested to me by several users that they find pySHACL to be a very useful tool and would like to see it available as a debian package. I agree. I am the lead developer of pySHACL and I maintain the release on pypi. As well as rdflib, this packages relies on the owlrl python module as a prerequisite. I've already filed an ITP for and RFS for owlrl. I am looking for a sponsor to get this software packaged, perhaps the maintainer for rdflib could help with sponsorship. Blocked By: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919446 Regards, Ashley Sommer
Bug#919448: libgssapi-krb5-2: adequate reports obsolete-conffile for libgssapi-krb5-2
Package: libgssapi-krb5-2 Version: 1.16.2-1 Severity: normal User: debian...@lists.debian.org Usertags: obsolete-conffile adequate Dear Maintainer, Thank you for maintaining libgssapi-krb5-2 . While updating adequate showed me the following - $ adequate libgssapi-krb5-2 libgssapi-krb5-2 obsolete-conffile /etc/gss/mech.d/README Please fix the same. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'stable-debug'), (100, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8), LANGUAGE=en_IN.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgssapi-krb5-2 depends on: ii libc62.28-4 ii libcom-err2 1.44.5-1 ii libk5crypto3 1.16.2-1 ii libkeyutils1 1.5.9-9.3 ii libkrb5-31.16.2-1 ii libkrb5support0 1.16.2-1 libgssapi-krb5-2 recommends no packages. Versions of packages libgssapi-krb5-2 suggests: pn krb5-doc pn krb5-user -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#919447: [asterisk] [1329393.987739] asterisk[27758]: segfault at 10 ip 00007facf79d5233 sp 00007facc14428d0 error 4 in libiksemel.so.3.1.1[7facf79ce000+d000]
On Wed, 16 Jan 2019 00:33:55 -0300 Fernando Toledo wrote: > Package: asterisk > Version: 1:11.13.1~dfsg-2+deb8u6 > Severity: normal > > --- Please enter the report below this line. --- > > i found that my asterisk crash in dmesg on stretch: > > [1329393.987739] asterisk[27758]: segfault at 10 ip 7facf79d5233 sp > 7facc14428d0 error 4 in libiksemel.so.3.1.1[7facf79ce000+d000] > > I need help to know how to get more info/debug. The > /var/log/astersk/messages no do have any error related to this. > > Sorry i mean jessie not strech. -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar
Bug#919317: [Pkg-shadow-devel] Bug#919317: shadow: French documentation translation update
Hi, it would be great if you could open a pull request at https://github.com/shadow-maint/shadow/
Bug#917126: Bug#874003: Nautilus does not launch applications
On Mon, Dec 24, 2018 at 12:18:15PM +, Simon McVittie wrote: > On Sat, 22 Dec 2018 at 20:06:26 -0800, Ross Vandegrift wrote: > > Untested patch attached. I'm travelling the next week and may not have > > time to > > test/package until January. > > I don't use enlightenment myself, but the patch looks like what I had > in mind. Patch is tested, works as expected. I've let upstream know and will prepare an upload. > > I don't know the fdo specs well, but this behavior of x-scheme-handler/file > > seems like a pretty bad misfeature to me. Does it exist only for the gdm3 > > use-case? > > x-scheme-handler/file isn't really a feature at all, more a consequence > of a more general feature that *is* useful. Thanks for the explanation Simon, very helpful. Ross
Bug#600276: mumble: Need to switch speech synthesis language according to translations
Mumble 1.3.0~git20190114.9fcc588+dfsg-1 was uploaded to Debian today which should contain a fix to this bug. I'm going to close the bug now -- if it doesn't work as expected, please re-open the bug. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#919447: [asterisk] [1329393.987739] asterisk[27758]: segfault at 10 ip 00007facf79d5233 sp 00007facc14428d0 error 4 in libiksemel.so.3.1.1[7facf79ce000+d000]
Package: asterisk Version: 1:11.13.1~dfsg-2+deb8u6 Severity: normal --- Please enter the report below this line. --- i found that my asterisk crash in dmesg on stretch: [1329393.987739] asterisk[27758]: segfault at 10 ip 7facf79d5233 sp 7facc14428d0 error 4 in libiksemel.so.3.1.1[7facf79ce000+d000] I need help to know how to get more info/debug. The /var/log/astersk/messages no do have any error related to this.
Bug#919446: RFS: owlrl/5.2.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear Mentors, I'm looking for a sponsor for my package "owlrl" Package name: owlrl Version : 5.2.0 Upstream Author : Ivan Herman URL : https://github.com/RDFLib/OWL-RL License : W3C Programming Lang: Python Section : python Description : A simple implementation of the OWL2 RL Profile on top of RDFLib: it expands the graph with all possible triples that RDFS and OWL-RL defines. It can be used together with RDFLib to expand an RDFLib Graph object, or as a stand alone service with its own serialization. It builds those binary packages: python3-owlrl - OWL-RL and RDFS based RDF Closure inferencing To access further information about this package, please visit the following URL: https://mentors.debian.net/package/owlrl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/owlrl/owlrl_5.2.0-1.dsc The useful python application called RDFClosure by Ivan Herman was recently updated to v5 and released on pypi. I am an active developer on owlrl and I maintain the pypi release. I intend to package another tool called pySHACL for debian, but it relies on owlrl, so I need owlrl released as a debian package first. The only requirement of owlrl is rdflib, which is already an actively maintained debian package. I intend to personally be the active maintainer of this package (via a sponsor). I have not released a debain package before, I will be looking for a sponsor to get this (owlrl) and pySHACL packaged and published, perhaps the maintainer or rdflib would like to sponsor this package. Regards, Ashley Sommer
Bug#911616: emacs-common: copyright file missing after upgrade of emacs-nox from stretch
Followup-For: Bug #911616
Control: tag -1 patch
Control: found -1 1:26.1+1-3
Hi,
attached you can find a patch that should properly handle the
dir_to_symlink conversion manually. I tested this on the
stretch->buster upgrade path of two previously failing packages
in my piuparts engine.
Andreas
>From d205f2459ad0f7be2f4f37b37a095c86b904f5eb Mon Sep 17 00:00:00 2001
From: Andreas Beckmann
Date: Wed, 16 Jan 2019 03:37:44 +0100
Subject: [PATCH] Really handle the emacs-{gtk,lucid,nox} doc dir transition
manually
reimplementing the guts of dir_to_symlink is quite easy:
in the postinst replace the empty directory with the intended symlink
caveats compared to dpkg-maintscript-helper:
* fails during postinst (not preinst) if the directory is not empty
* absolutely no rollback or downgrade support
---
debian/emacsVAR.postinst | 14 ++
debian/emacsVAR.preinst | 23 ---
debian/rules | 3 ---
3 files changed, 14 insertions(+), 26 deletions(-)
delete mode 100644 debian/emacsVAR.preinst
diff --git a/debian/emacsVAR.postinst b/debian/emacsVAR.postinst
index 8dadd23a896..fcadb1c4540 100644
--- a/debian/emacsVAR.postinst
+++ b/debian/emacsVAR.postinst
@@ -2,6 +2,20 @@
set -e
+# Manual dir_to_symlink conversion since dpkg-maintscript-helper does not
+# handle this in combination with arch:all to arch:any switches (#813455).
+# Keep this code for buster and bullseye to ease backports.
+if [ "$1" = "configure" ] && dpkg --compare-versions "$2" lt-nl "1:26.1+1-4~"
+then
+ test -n '@PKG_NAME@'
+ if [ -d /usr/share/doc/@PKG_NAME@ ] && [ ! -h /usr/share/doc/@PKG_NAME@
]
+ then
+ # This will intentionally fail if the directory is not empty.
+ rmdir /usr/share/doc/@PKG_NAME@
+ ln -sv emacs-common /usr/share/doc/@PKG_NAME@
+ fi
+fi
+
update-alternatives \
--install /usr/bin/emacs emacs \
/usr/bin/emacs-@X_SUPPORT@ @BIN_PRIORITY@ \
diff --git a/debian/emacsVAR.preinst b/debian/emacsVAR.preinst
deleted file mode 100644
index 26aac393c65..000
--- a/debian/emacsVAR.preinst
+++ /dev/null
@@ -1,23 +0,0 @@
-#!/bin/sh
-
-set -e
-
-doc_dir=/usr/share/doc/@PKG_NAME@
-
-test '@PKG_NAME@'
-
-case "$1" in
-install|upgrade)
-# Before the unversioning, emacs-{gtk,lucid,nox} packages were
-# in a different source package (emacs-defaults) and were arch
-# all, and dpkg can't handle dir to symlink transitions.
-rm -rf "$doc_dir"
-;;
-abort-upgrade)
-;;
-*)
-echo "unexpected $(basename "$0") argument"
-;;
-esac
-
-#DEBHELPER#
diff --git a/debian/rules b/debian/rules
index 6a3c40a2833..b2bd4931fcc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -129,12 +129,9 @@ nonpersistent_autogen_install_files := \
debian/emacs-common.postinst \
debian/emacs-common.prerm \
debian/emacs-nox.postinst \
- debian/emacs-nox.preinst \
debian/emacs-nox.prerm \
debian/emacs-lucid.postinst \
- debian/emacs-lucid.preinst \
debian/emacs-lucid.prerm \
- debian/emacs-gtk.preinst \
debian/emacs-gtk.postinst \
debian/emacs-gtk.prerm
--
2.11.0
Bug#912799: doxygen switch to llvm-toolchain-7
Hello,
On Mon, 3 Dec 2018 12:54:45 +0100 Paolo Greppi wrote:
> Hi, in preparation for this switch I am building doxygen from source
with:
>
> sudo apt install llvm-7-dev # for
/usr/lib/llvm-7/lib/cmake/llvm/LLVMConfig.cmake
> sudo apt install clang-7 # for
/usr/lib/llvm-7/lib/cmake/clang/ClangConfig.cmake
> git clone https://github.com/doxygen/doxygen
> cd doxygen
> mkdir build
> cd build
> LLVM_DIR=/usr/lib/llvm-7/lib/cmake/llvm/
Clang_DIR=/usr/lib/llvm-7/lib/cmake/clang/ cmake -Duse_libclang=ON -G
"Unix Makefiles" ..
> make
>
> It builds, but the resulting binary fails to start with:
> ./bin/doxygen
> : CommandLine Error: Option 'help-list' registered more than once!
> LLVM ERROR: inconsistency in registered CommandLine options
I have been able to build the package successfully without this problem
by patching the source with the attached llvm-7 patch. That was with
release version 1.8.15.
I also needed an updated watch file and an updated no-rpath patch.
I hope to see a new version of doxymacs built against llvm 7 in Debian soon.
Regards
Jiri Palecek
Index: doxygen-1.8.15/src/CMakeLists.txt
===
--- doxygen-1.8.15.orig/src/CMakeLists.txt
+++ doxygen-1.8.15/src/CMakeLists.txt
@@ -279,4 +279,6 @@ target_link_libraries(doxygen
${CLANG_LIBS}
)
+set_target_properties(doxygen PROPERTIES SKIP_BUILD_RPATH TRUE)
+
install(TARGETS doxygen DESTINATION bin)
Index: doxygen-1.8.15/src/CMakeLists.txt
===
--- doxygen-1.8.15.orig/src/CMakeLists.txt
+++ doxygen-1.8.15/src/CMakeLists.txt
@@ -261,12 +261,13 @@ if (use_libclang)
endif()
include_directories(${LLVM_INCLUDE_DIRS})
add_definitions(${LLVM_DEFINITIONS})
-llvm_map_components_to_libnames(llvm_libs support core option)
+llvm_config(doxygen USE_SHARED support core option)
target_compile_definitions(doxygen PRIVATE ${LLVM_DEFINITIONS})
-set(CLANG_LIBS libclang clangTooling ${llvm_libs})
+set(CLANG_LIBS libclang clangTooling)
endif()
target_link_libraries(doxygen
+ PRIVATE
_doxygen
doxycfg
qtools
Bug#919315: geeqie: Orientation keys ('[' and ']') don't work in latest geeqie release
Andreas Ronnquist writes: >> Hi. These appear to not work anymore. >> >> With the geeqie in stable (1:1.3-1+b1) I can load any image, press >> [ and see the image rotate in response. >> >> With the latest (1:1.4+git20190106-1) when I press '[', the text in >> the Exif pane gets a different text label 'Orientation: xxx', but the >> displayed image does not change. >> > In the menu Edit -> Orientation > > there is a checkbox for "Exif Rotate" - keyboard shortcut Alt-X - Is > this checked on your system? Thank you very much for the reply. With "exif rotate" UNCHECKED, the [/] keys do NOT work With "exif rotate" CHECKED, the [/] keys DO work I just tried this with an older version of geeqie I had lying around on a different machine: 1:1.4-3. On that version things appear functional with or without that option being checked. Thanks again
Bug#918026: ruby-sinatra-contrib: uninstallable; depends on versions not present in the archive
On Fri, 4 Jan 2019 10:22:08 -0300 Antonio Terceiro wrote: > Are you working on updating sinatra? I started working on a new sinatra > upstream release to unbreak debci after a new rack was uploaded, and > could build binaries for ruby-sinatra-contrib (and ruby-rack-protection, > which was also moved into sinatra) from the ruby-sinatra source in one > go. Thanks Antonio for updating sinatra package! And now I've found that ruby-sinatra-contrib was removed from repository, is that intended? See https://ftp-master.debian.org/removals.txt -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#919322: CVE-2019-6245 CVE-2019-6247
I have prepared a new version of libagg-dev that fixes #377270 and I was about to ask the package sponsor to upload it when this issue surfaced. I will fold in fixes for the new bugs too. -- john On Mon, 14 Jan 2019 23:27:23 +0100 Moritz Muehlenhoff wrote: > Source: agg > Severity: grave > > Please see > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6245 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6247 > > Given that the package isn't exactly fast-moving, how about > revisiting #377270 for buster? Right now we need to coordinate > rebuilds against the fixed agg... > > Cheers, > Moritz > >
Bug#904152: Request: Rename "ubuntu-archive-keyring" package to "ubuntu-keyring" for consistency with Ubuntu
On Mon, 14 Jan 2019 19:21:31 -0500 Jeremy Bicha wrote: > I believe you need a transitional package so that people with the old > package install will get upgraded to the new version. Thanks for your suggestion! I've updated it and re-upload to NEW queue. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp http://wiki.debian.org/HidekiYamane
Bug#919315: geeqie: Orientation keys ('[' and ']') don't work in latest geeqie release
Control: On Mon, 14 Jan 2019 13:09:21 -0800 Dima Kogan wrote: > Package: geeqie > Version: 1:1.3-1+b1 > Severity: normal > > Hi. These appear to not work anymore. > > With the geeqie in stable (1:1.3-1+b1) I can load any image, press > [ and see the image rotate in response. > > With the latest (1:1.4+git20190106-1) when I press '[', the text in > the Exif pane gets a different text label 'Orientation: xxx', but the > displayed image does not change. > > Thanks > In the menu Edit -> Orientation there is a checkbox for "Exif Rotate" - keyboard shortcut Alt-X - Is this checked on your system? /Andreas Rönnquist gus...@debian.org
Bug#919445: curl: Please update to 7.63.0
On Wed, 16 Jan 2019 10:05:22 +0900 Hideki Yamane wrote: > Could you consider to update to the latest upstream version 7.63.0, > released on 12th of December 2018, please? If there's any blocker > for it, it'd be better to note. I've heard that HTTP digest authentication bug was fixed in 7.63.0, so update to it is good for some users at least :) https://github.com/curl/curl/issues/3353 https://github.com/curl/curl/pull/3356 -- Hideki Yamane
Bug#919335: openmpi/hurd/stdin bug
This bug occurs for reading from stdin in C too.
Again on an exodar schroot on sid:
CONTEXT:
$ dpkg -l |egrep "tree.*puzzle|openmpi|pmix|gfortran|gcc|mpifort|libc[-0]"
ii gcc4:8.2.0-2 hurd-i386
GNU C compiler
ii gcc-8 8.2.0-14hurd-i386
GNU C compiler
ii gcc-8-base:hurd-i386 8.2.0-14hurd-i386
GCC, the GNU Compiler Collection (base package)
ii gfortran 4:8.2.0-2 hurd-i386
GNU Fortran 95 compiler
ii gfortran-8 8.2.0-14hurd-i386
GNU Fortran compiler
ii gromacs-openmpi2018.4-1hurd-i386
Molecular dynamics sim, binaries for OpenMPI parallelization
ii libc-bin 2.28-5 hurd-i386
GNU C Library: Binaries
ii libc-dev-bin 2.28-5 hurd-i386
GNU C Library: Development binaries
ii libc-l10n 2.28-5 all
GNU C Library: localization files
ii libc0.3:hurd-i386 2.28-5 hurd-i386
GNU C Library: Shared libraries
ii libc0.3-dev:hurd-i386 2.28-5 hurd-i386
GNU C Library: Development Libraries and Header Files
ii libgcc-8-dev:hurd-i386 8.2.0-14hurd-i386
GCC support library (development files)
ii libgcc1:hurd-i386 1:8.2.0-14 hurd-i386
GCC support library
ii libgfortran-8-dev:hurd-i3868.2.0-14hurd-i386
Runtime library for GNU Fortran applications (development files)
ii libgfortran5:hurd-i386 8.2.0-14hurd-i386
Runtime library for GNU Fortran applications
ii libopenmpi-dev:hurd-i386 3.1.3-9 hurd-i386
high performance message passing library -- header files
ii libopenmpi3:hurd-i386 3.1.3-9 hurd-i386
high performance message passing library -- shared library
ii libpmix2:hurd-i386 3.1.0~rc4-1 hurd-i386
Process Management Interface (Exascale) library
ii openmpi-bin3.1.3-9 hurd-i386
high performance message passing library -- binaries
ii openmpi-common 3.1.3-9 all
high performance message passing library -- common files
ii tree-puzzle5.2-11 hurd-i386
Reconstruction of phylogenetic trees by maximum likelihood
ii tree-puzzle-doc5.2-11 all
Reconstruction of phylogenetic trees by maximum likelihood (doc)
$ mpicc --showme
gcc -I/usr/lib/i386-gnu/openmpi/include/openmpi
-I/usr/lib/i386-gnu/openmpi/include -pthread -L/usr/lib/i386-gnu/openmpi/lib
-lmpi
REPRODUCE THE BUG:
$ cat hurd_C_minimal.c
#include
#include
int main(void){
int i = 178;
int j;
printf("i = %d\n",i);
scanf("%10d",);
printf("j = %d\n",j);
return 0;
}
$ cat infile
414
$ gcc hurd_C_minimal.c && time ./a.out < infile
i = 178
j = 414
real0m0.010s
user0m0.000s
sys 0m0.000s
$ mpicc src/hurd_C_minimal.c && (time mpirun -n 1 --mca plm_rsh_agent /bin/false
./a.out < infile ) &
[2] 21871
i = 178
Runs for at least 30 seconds cpu time at about 10% cpu before I killed it.
REPRODUCE THE BUG - tree-puzzle:
This bug should affect all other openmpi packages which read from stdin,
such as tree-puzzle 5.2-11:
Again on an exodar schroot on sid:
(0) prepare 2-line input file:
$ cp -pv /usr/share/doc/tree-puzzle/examples/primates.b .
$ printf "primates.b\ny\n" > infile.tree-puzzle
(1) without mpi
$ time tree-puzzle < infile.tree-puzzle > /dev/null && ls -lt out
Using SPRNG -- Scalable Parallel Random Number Generator
WARNING from init_rng: Parameter not valid. Using Default param
real0m0.020s
user0m0.000s
sys 0m0.000s
-rw-r--r-- 1 boud-guest boud-guest 284 Jan 16 01:04 outdist
-rw-r--r-- 1 boud-guest boud-guest 7095 Jan 16 01:04 outfile
-rw-r--r-- 1 boud-guest boud-guest 130 Jan 16 01:04 outtree
(2) with mpi
$ (time mpirun -n 1 --mca plm_rsh_agent /bin/false tree-puzzle < infile.tree-puzzle >
/dev/null && ls -lt out) &
[1] 13122
Using SPRNG -- Scalable Parallel Random Number Generator
WARNING from init_rng: Parameter not valid. Using Default param
Runs at about 10-20% of cpu for at least 80 seconds of cpu time.
Bug#919384: python-matplotlib: The Gtk3 backend requires PyGObject or pgi
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
> Due to bug#889137 I modified one program line from this:
>
> from matplotlib.backends.backend_gtkagg import
> NavigationToolbar2GTKAgg
>
> to this:
>
> from matplotlib.backends.backend_gtk3agg import
> NavigationToolbar2GTKAgg
the proper way to switch backend is either by using the matplotlibrc
configuration file or using `matplotlib.use(backend)` command, like:
>>> import matplotlib as mpl
>>> mpl.use('Gtk3Agg')
>>> import matplotlib.pyplot as plt
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi
Bug#629902: dh_installinit: should support LSB compliant scripts
Bringing in the debhelper maintainers into the loop again. On Sun, Jan 13, 2019 at 10:31 AM Dmitry Bogatov wrote: > > [ Do you want me to re-submit this patch as merge request? ] > Not necessary (yet) > > [2019-01-11 14:58] Felipe Sateler > > > [2011-06-14 11:39] Joey Hess > > > > > > > > part 1 text/plain 618 > > > > Helmut Grohne wrote: > > > > > A failure from the update-rc.d cannot make postinst fail, because > the > > > > > exit code is not checked. > > > > > > > > Yes it is (set -x), but I meant invoke-rc.d anyway, obviously > > > > > > > > So in my view the reason for a postinst failure is unrelated to > > > > > update-rc.d. Can you explain your reasoning? > > > > > > > > Simple separation of concerns, invoke-rc.d is responsible for running > > > > the init script and determining if it fails and propigating a failing > > > > exit status. debhelper allows it to do do. The right way to make 6 be > > > > ignored is to get invoke-rc.d to ignore it, not add cruft to every > > > > postinst that calls it. > > > > > Here I propose patch to implement just that: > > > [...] > > I'm wary of unintended consequences here. Do we have services that return > > exit code 6 but as a failure code? > > Seems there is nobody, who use exit code 6 for another purposes. You can > make sure by checking is output of 'grep -R "exit 6" -C6' in directory > with all init scripts unpacked: > Rereading invoke-rc.d manpage, it says quite explicitly: > Should an init script be executed, invoke-rc.d always returns the status code returned by the init script. So it looks like this would be quite the change in behavior. I wonder what the best approach it. OTOneH, I sympathize with Joey's argument that these checks should be centralized. OTOtherH, I'm not sure we can consider invoke-rc.d a debhelper implementation detail and change behaviour like this. Maybe a new flag to invoke-rc.d could be used for this? I'm not sure. -- Saludos, Felipe Sateler
Bug#919445: curl: Please update to 7.63.0
package: curl Hi, Could you consider to update to the latest upstream version 7.63.0, released on 12th of December 2018, please? If there's any blocker for it, it'd be better to note. # and hope consider to look https://bugs.debian.org/897950 too :) On my laptop, just update to 7.63.0 and build is fine, with dropping debian/patches/12_fix-runtests-curl.patch that was merged to upstream and attached symbols update. -- Hideki Yamane curl.symbols Description: Binary data
Bug#916504: pulseaudio FTBFS on Alpha; return of the volume-test failure
Control: forwarded -1 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/619 Control: retitle -1 pulseaudio: uses -ffinite-math but might deal with infinity Hi, Sorry for the delay. On Sat, Dec 15, 2018 at 3:24 AM Michael Cree wrote: > Source: pulseaudio > Version: 12.2-2 > Severity: important > Justification: fails to build from source but built in the past. > User: debian-al...@lists.debian.org > Usertags: alpha > Tags: patch > > Pulseaudio FTBFS on alpha due to the volume-test test failing due to > a floating-point exception which in turn is due to an infinity in > floating-point calculations when volume-test is compiled with finite > math options. > > This is bug #798248 reappearing but in a subtlely different guise. > There the non-finite math was protected against by checking that the > arguments are finite before performing floating point calculations, > but it now seems that gcc takes the specification of finite math, > being "[a]llow optimizations for floating-point arithmetic that > assume that arguments and results are not NaNs or +-Infs" so > pedantically true, that it is fair game to optimise away any calls > to isfinite() because the argument must be finite: it was said so > on the command line! > > Whatever, examination of the object code shows that the calls to > isfinite() are eliminated thus the floating-point arithmetic is no > longer protected. > I think if infinities might happen, then using -ffinite-math is wrong. I have forwarded the issue upstream. I have disabled -ffast-math in the meantime, since I think correctness is more important than speed. > > Fortunately we can work out whether the arguments to the offending > arithmetic are finite by other means and I attach a patch doing > just that. With this patch pulseaudio builds to completion on > Alpha. > This is insufficient as there is a call to isnan() in the core lib. -- Saludos, Felipe Sateler
Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
On Fri, Jan 04, 2019 at 05:30:22PM -0500, Thomas Dickey wrote: > On Fri, Jan 04, 2019 at 08:13:53PM +0100, Alexander Meyer wrote: > > Would this warrant to add "affects" tags for firefox and chromium to > > this bug? Not sure about the Debian policy here. In this case, the > > no - see https://www.debian.org/Bugs/server-control#affects > > (since you're the only one to report it so far) ...while testing this, I noticed that fc-match also dumps core (same bug). Also, the changes I made in #343 had no effect on this bug - still happens with the same configuration. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature
Bug#919342: [Pkg-phototools-devel] Bug#919342: darktable: Segfault when moving drawn mask
Control: tag -1 unreproducible moreinfo Charlie Hagedorn writes: > > Opened up an image, did some edits to an image, and then created my > first drawn mask with the upgraded version. It wasn't quite in the > right place, so I clicked-and-dragged in the middle of the image. The > mask outline disappeared, I may have clicked in a few spots/faffed a > little bit, and darktable crashed. I don't use drawn masks normally, but I tried drawing a few circles and elipses and dragging them around. I didn't experience any strange behaviour. What module were you using? > The image was missing from the lighttable when I restarted darktable, > so I reapplied the same edits, switched back to the lighttable in > order to save my progress, I don't understand this part. If the image was missing from the lighttable, how did you edit it? Is there some duplication going on? > 1. That mask is now saved, and if I call it up from the list of masks, > darktable crashes. I don't know enough about library.db to call it up > and submit it. If a developer with enough darktable-fu can tell me > how, I'll add it to this bug. Yeah, me neither unfortunately. > 2. Moving any drawn mask on any image I have tried so far yields an > instantaneous jump of the mask down and right by ~500-1000 > pixels. Dragging is then successful, and darktable does not crash. In > ~5 tries, I have not been able to generate another segfaulting mask. Hmm. You'd think I'd have noticed this. > 3. When segfaulting, Darktable consistently stores > > " > this is darktable 2.6.0 reporting a segfault: > > warning: Currently logging to /tmp/darktable_bt_5AAEVZ.txt. Turn the logging > off and on to make the new setting effective. > /usr/share/darktable/gdb_commands:2: Error in sourced command file: > No stack. > " > to a logfile in /tmp. Internet search suggests that I'd get more debug output > with darktable-dbg, but as it is not in Debian testing, I don't want to > install it. > You want darktable-dbgsym. To install it you will need a line like deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main in sources.list
Bug#919300: ubuntu-keyring: [INTL:nl] Dutch translation of debconf messages
Hi, On Mon, 14 Jan 2019 20:15:52 +0100 Frans Spiesschaert wrote: > Please find attached the Dutch translation of ubuntu-keyring > debconf messages. > It has been submitted for review to the debian-l10n-dutch mailing > list. > Please add it to your next package revision. Thanks for filing translation, but as #917352, templates in this package was reviewed and updated. Could you update attached file, please? -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp nl.po Description: Binary data
Bug#919222: ubuntu-keyring: [INTL:pt] Updated Portuguese translation - debconf messages
On Sun, 13 Jan 2019 20:25:41 + Américo Monteiro wrote: > Updated Portuguese translation for ubuntu-keyring's debconf messages > Translator: Américo Monteiro > Feel free to use it. Thanks for filing translation, but as #917352, templates in this package was reviewed and updated. Could you update attached file, please? -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp pt.po Description: Binary data
Bug#918522: No sound with PulseAudio when an NVidia GPU is installed - workaround
On Wed, Jan 9, 2019 at 2:40 PM Julien Aubin wrote: > Le mer. 9 janv. 2019 à 12:48, Felipe Sateler a > écrit : > > > > > > > > On Wed, Jan 9, 2019, 08:36 Julien Aubin >> > >> > >> > >> Le mer. 9 janv. 2019 à 12:33, Felipe Sateler a > écrit : > >>> > >>> Control: tags -1 moreinfo > >>> > >>> On Tue, Jan 8, 2019, 16:33 Julien Aubin > Hi, > > Could reproduce this bug on an host without an NVidia GPU. > > Workaround is still the same. > >>> > >>> > >>> > >>> Could you please attach a verbose log of pulseaudio when the problem > occurs? Sounds like the udev module is not doing its job > >> > >> > >> Hi > >> > >> How do I get the verbose log ? > > > > > > Use: > > > > systemctl --user --runtime --full edit pulseaudio > > > > Append a '-' to the ExecStart line > > > > systemctl --user restart pulseaudio > > > > And then get the log > > > > journalctl --user-unit pulseaudio --since=sometimebeforerestarting > > pulse log > > > > (You might need root to get the logs) > > > > Verify that the log is not empty, and then attach it. > > > > Saludos > > > > > > Hi, > > Attached the logs. > > > The log says: module-udev-detect.c: /devices/pci:00/:00:1b.0/sound/card0 is busy: yes Some other program appears to be holding the device busy. Common culprits include espeakup and timidity. You can further inspect with: sudo lsof /dev/snd/* -- Saludos, Felipe Sateler
Bug#919444: postfix: document real-world smarthost configuration
Package: postfix
Version: 3.3.2-1
Severity: normal
Tags: patch
Hi,
Debconf offers a 'satellite system' configuration option, where "All
mail is sent to another machine, called a 'smarthost', for delivery."
but this merely points Postfix toward the smarthost. With real-world,
third-party smarthosts, a number of other steps are required to make
this actually work, which are not explained to the user. I've included
a slightly Debian-centric guide to this configuration for inclusion with
the Postfix package, if deemed appropriate.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages postfix depends on:
ii adduser3.118
ii cpio 2.12+dfsg-6
ii debconf [debconf-2.0] 1.5.69
ii dpkg 1.19.2
ii e2fsprogs 1.44.5-1
ii libc6 2.28-5
ii libdb5.3 5.3.28+dfsg1-0.2
ii libicu63 63.1-5
ii libsasl2-2 2.1.27~rc8-1
ii libssl1.1 1.1.1a-1
ii lsb-base 10.2018112800
ii netbase5.5
ii ssl-cert 1.0.39
Versions of packages postfix recommends:
ii python3 3.7.1-3
Versions of packages postfix suggests:
pn dovecot-common
ii libsasl2-modules 2.1.27~rc8-1
ii mailutils [mail-reader] 1:3.5-2
pn postfix-cdb
ii postfix-doc 3.3.2-1
pn postfix-ldap
pn postfix-lmdb
pn postfix-mysql
ii postfix-pcre 3.3.2-1
pn postfix-pgsql
pn postfix-sqlite
pn procmail
ii resolvconf 1.79
ii sasl2-bin2.1.27~rc8-1
ii sylpheed [mail-reader] 3.7.0-4
pn ufw
-- debconf information excluded
Postfix can be configured to relay mail to a 'smarthost' for delivery. In
practice, with real world smarthosts, considerable configuration is required to
make this work. Some of this configuration can be done via debconf
('dpkg-reconfigure postfix'), but much of it will usually need to be done
manually. This document provides instructions for such configuration.
1. Set the smarthost
This can be set via debconf. To do it manually, add a line like the following
to /etc/postfix/main.cf:
relayhost = [relayhost.example.com]:465
If the port number is omitted, the default is 25. Most smarthosts use TLS/SSL,
and accordingly generally use either 465 or 587. Consult the smarthost's
documentation for the port used.
2. Enable TLS/SSL
As above, most smarthosts use TLS/SSL. To configure Postfix to use TLS, add the
following lines to main.cf:
smtp_tls_security_level = verify
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
If 'encrypt' is used instead of 'verify', the second line may be omitted, in
which case TLS will be used but Postfix will not verify the smarthost's
certificate, potentially allowing a man-in-the-middle attack and the stealing
of the smarthost authentication credentials. See postconf(5) for details.
If 'legacy' SMTPS (sometimes called 'SSL', usually used in conjunction with
port 465) is desired, add the following additional line to main.cf:
smtp_tls_wrappermode = yes
For STARTTLS (usually used in conjunction with port 587), omit this line (or
use the value 'no'). Consult the smarthost's documentation for the version of
TLS/SSL used.
3. Configure authentication
Most smarthosts require authentication. To enable it, ensure that the package
'libsasl2-modules' is installed, and add the following lines to main.cf:
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
[See postconf(5) for more information about 'security options'. The above
version, with no options, is generally fine.]
To specify the authentication credentials, create an arbitrarily named file
(e.g., '/etc/postfix/example-passwd'), with appropriately restrictive
permissions (e.g., 600) containing a single line of the following form:
smtp.example.com usern...@example.com:secret_password
Where 'smtp.example.com' is the name of the smarthost, 'usern...@example.com'
is the login name, and 'secret_password' is the login password.
After creating the file, run the command:
postmap /etc/postfix/example.com-passwd
and add the following line to main.cf:
smtp_sasl_password_maps = hash:/etc/postfix/example-passwd
4. Address rewriting
Most smarthosts require that the sender (envelope FROM and perhaps also the
email From: header) be set to the user's correct mail address with the
smarthost. Postfix therefore needs to be configured to rewrite the sender
address accordingly. There are multiple ways to do this, including canonical
mapping
Bug#919439: bash: new alias behavior may freeze interpreter
On Tue, Jan 15, 2019 at 3:03 PM Étienne Mollier wrote: > > Package: bash > Version: 5.0-1 > Severity: normal > > Dear Maintainer, > > While doing my regular upgrade of Sid, I happily discovered that > brand new bash version 5.0-1 in the set of installed packages, > so I gave it a try. :^) > > I ran the command `ls` which stuck without showing the output of > my home directory while it usually did, and while /bin/ls did > show it without much issues. Remembering a similar situation in > a long forgotten past in Csh, I ran `unalias ls` and the > situation went back to normal. > > Alas, in my foolishness, I dug deeper in my login scripts to > understand why this was affecting me, thinking I introduced a > loop of some sort. Instead I discovered that: if an alias ends > with a tabulation character, then the hang reappears. Example: > > $ alias reproducer='true' > $ reproducer > _ FYI, this issue was reported upstream in https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00084.html. This was fixed in the `devel' branch in git, but I'm not sure if a patch for 5.0 has been released yet. The issue is caused by bash improperly handling the case where an alias has trailing tab characters.
Bug#918607: ITP: kthresher -- Purge Unused Kernels
Hi, Am 07.01.2019 um 19:30 schrieb Darshaka Pathirana: > * Package name: kthresher > Version : 1.3.1 > Upstream Author : Rackspace US, Inc. > * URL : https://github.com/rackerlabs/kthresher > * License : Apache > Programming Lang: Python > Description : Purge Unused Kernels > > Tool to remove unused kernels that were installed automatically > This tool removes those kernel packages marked as candidate for autoremoval. > Those packages are generally installed via Unattended upgrade or > meta-packages. By default the latest kernel and manual installations are > marked to Never Auto Remove. it looks like this doesn't support Python 3 yet and I suspect that new packages should. I'd suggest that instead of distutils' LooseVersion, which was never meant for that, you use apt_pkg.version_compare. To be fair it's not quite a Debian revision to parse but it's close enough that the tokenization from our algorithm should work fine to sort kernel versions. Kind regards Philipp Kern
Bug#444980: udev not restarted after exiting runlevel 1
On Sun, Jan 13, 2019 at 10:31 AM Dmitry Bogatov wrote: > > [2019-01-11 14:34] KatolaZ > > On Fri, Jan 11, 2019 at 12:36:36PM +, Dmitry Bogatov wrote: > > > > > > [2019-01-08 14:32] Michael Biebl > > > > Am 08.01.19 um 13:37 schrieb Dmitry Bogatov: > > > > > > > > > > control: tags -1 +moreinfo > > > > > > > > > > Seems old discussion did not ended in solution. Let us try again. > > > > > > > > > > Dear udev maintainers, did anything changed? Are there still > problems > > > > > running /etc/init.d/udev from runlevel 1 (when udev daemon was > killed) > > > > > manually by sysadmin to restart it? > > > > > > > > > > > > > That's not what this bug report is about. > > > > > > > > It's about udev being killed when switching to runlevel 1 and not > being > > > > restarted automatically when switching back to say runlevel 2. > > > > > > > > That issue is still valid today. > > > > > > I understand. Perfect solution would be move udev script (or part, that > > > actually starts process/es) to stages (2 3 4 5)? Is it feasible today? > > > > > > > I don't think it is possible, since udev gets started in early boot, > > before filesystems are mounted, but I might be wrong. > > Yes, I see, that `mountdefsubsys', `procps' and number of other declare > soft dependency (Should-Start:) on udev. Any idea, where can I find > reasoning, why it is so? > I don't think you can move udev out of runlevel S. For example, mdadm relies on udev to assemble arrays, so if you move udev out., you probably won't be able to mount mdadm arrays. -- Saludos, Felipe Sateler
Bug#919443: ifupdown2: leaves diversion after upgrade from stretch
Package: ifupdown2 Version: 1.2.2-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to remove some diversions after upgrading from stretch and removing the package afterwards. >From the attached log (scroll to the bottom...): 0m51.2s ERROR: FAIL: Installed diversions (dpkg-divert) not removed by purge: diversion of /sbin/ifreload to /sbin/ifreload.disabled by ifupdown2 diversion of /etc/bash_completion.d/ifdown to /etc/bash_completion.d/ifdown.disabled by ifupdown2 diversion of /usr/share/man/man8/ifup.8.gz to /usr/share/man/man8/ifup.8.gz.disabled by ifupdown2 diversion of /usr/share/man/man8/ifquery.8.gz to /usr/share/man/man8/ifquery.8.gz.disabled by ifupdown2 diversion of /usr/share/bash-completion/completions/ifquery to /usr/share/bash-completion/completions/ifquery.disabled by ifupdown2 diversion of /usr/share/bash-completion/completions/ifdown to /usr/share/bash-completion/completions/ifdown.disabled by ifupdown2 diversion of /sbin/ifquery to /sbin/ifquery.disabled by ifupdown2 diversion of /sbin/ifdown to /sbin/ifdown.disabled by ifupdown2 diversion of /etc/bash_completion.d/ifup to /etc/bash_completion.d/ifup.disabled by ifupdown2 diversion of /sbin/ifup to /sbin/ifup.disabled by ifupdown2 diversion of /usr/share/man/man5/interfaces.5.gz to /usr/share/man/man5/interfaces.5.gz.disabled by ifupdown2 diversion of /usr/share/man/man8/ifreload.8.gz to /usr/share/man/man8/ifreload.8.gz.disabled by ifupdown2 diversion of /usr/share/man/man8/ifdown.8.gz to /usr/share/man/man8/ifdown.8.gz.disabled by ifupdown2 diversion of /usr/share/bash-completion/completions/ifreload to /usr/share/bash-completion/completions/ifreload.disabled by ifupdown2 diversion of /etc/bash_completion.d/ifquery to /etc/bash_completion.d/ifquery.disabled by ifupdown2 diversion of /etc/bash_completion.d/ifreload to /etc/bash_completion.d/ifreload.disabled by ifupdown2 diversion of /usr/share/bash-completion/completions/ifup to /usr/share/bash-completion/completions/ifup.disabled by ifupdown2 If these diversions were used in stretch, but not afterwards, you should remove them in the postinst script, i.e. on package upgrade. cheers, Andreas ifupdown2_1.2.2-1.log.gz Description: application/gzip
Bug#775912: Accepting patch upstream
I am applying the provided patch upstream. Looks like this should have been the default behaviour, at least in kernel versions after the 2.6 series. The patch will be included in insserv-1.19.0, likely published around the end of February 2019. - Jesse
Bug#919442: python-dmidecode-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Package: python-dmidecode-dbg Version: 3.12.2-6 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: stretch -> buster For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): 0m37.0s ERROR: FAIL: silently overwrites files via directory symlinks: /usr/share/doc/python-dmidecode-dbg/AUTHORS (python-dmidecode-dbg) != /usr/share/doc/python-dmidecode/AUTHORS (python-dmidecode) /usr/share/doc/python-dmidecode-dbg -> python-dmidecode /usr/share/doc/python-dmidecode-dbg/AUTHORS.upstream (python-dmidecode-dbg) != /usr/share/doc/python-dmidecode/AUTHORS.upstream (python-dmidecode) /usr/share/doc/python-dmidecode-dbg -> python-dmidecode /usr/share/doc/python-dmidecode-dbg/README (python-dmidecode-dbg) != /usr/share/doc/python-dmidecode/README (python-dmidecode) /usr/share/doc/python-dmidecode-dbg -> python-dmidecode /usr/share/doc/python-dmidecode-dbg/README.types (python-dmidecode-dbg) != /usr/share/doc/python-dmidecode/README.types (python-dmidecode) /usr/share/doc/python-dmidecode-dbg -> python-dmidecode /usr/share/doc/python-dmidecode-dbg/README.upstream.gz (python-dmidecode-dbg) != /usr/share/doc/python-dmidecode/README.upstream.gz (python-dmidecode) /usr/share/doc/python-dmidecode-dbg -> python-dmidecode /usr/share/doc/python-dmidecode-dbg/changelog.Debian.gz (python-dmidecode-dbg) != /usr/share/doc/python-dmidecode/changelog.Debian.gz (python-dmidecode) /usr/share/doc/python-dmidecode-dbg -> python-dmidecode /usr/share/doc/python-dmidecode-dbg/changelog.gz (python-dmidecode-dbg) != /usr/share/doc/python-dmidecode/changelog.gz (python-dmidecode) /usr/share/doc/python-dmidecode-dbg -> python-dmidecode /usr/share/doc/python-dmidecode-dbg/copyright (python-dmidecode-dbg) != /usr/share/doc/python-dmidecode/copyright (python-dmidecode) /usr/share/doc/python-dmidecode-dbg -> python-dmidecode cheers, Andreas python-dmidecode-dbg_3.12.2-6.log.gz Description: application/gzip
Bug#905200: closed by Yangfl ()
Control: reopen -1 Control: found -1 20150609-6 On 2019-01-06 17:45, Debian Bug Tracking System wrote: > This should have been fixed: natpmp-utils gets maintscript and > libnatpmp-dev gets its symlink back The .maintscript does not work thanks to a completely bogus version. Please bump the version in the .maintscript to 20150609-7~ with your next upload (which will probably be 20150609-7) >From the dpkg-maintscript-helper manpage: prior-version Defines the latest version of the package whose upgrade should trigger the operation. It is important to calculate prior-version correctly so that the operations are correctly performed even if the user rebuilt the package with a local version. If prior-version is empty or omitted, then the operation is tried on every upgrade (note: it's safer to give the version and have the operation tried only once). If the conffile has not been shipped for several versions, and you are now modifying the maintainer scripts to clean up the obsolete file, prior-version should be based on the version of the package that you are now preparing, not the first version of the package that lacked the conffile. This applies to all other actions in the same way. For example, for a conffile removed in version 2.0-1 of a package, prior-version should be set to 2.0-1~. This will cause the conffile to be removed even if the user rebuilt the previous version 1.0-1 as 1.0-1local1. Or a package switching a path from a symlink (shipped in version 1.0-1) to a directory (shipped in version 2.0-1), but only performing the actual switch in the maintainer scripts in version 3.0-1, should set prior-version to 3.0-1~. Andreas
Bug#918753: xscreensaver: xdg desktop files miss many items from debian menu file
On Wed, Jan 9, 2019 at 3:09 AM Matthew Gabeler-Lee wrote: > I noticed on an upgrade that I lost (in wmaker) many menu items related to > xscreensaver. On investigation this is because these menu items are only > provided in xscreensaver in the legacy Debian menu system and not in the > modern xdg / freedesktop .desktop files, which is all that many things > support these days. Hi, thanks for your report. > > Of particular note to me personally was the menu item to lock the screen > immediately, which was very useful. The command for this would be "/usr/bin/xscreensaver-command -lock". Maybe you can make a suitable desktop file, test it, and submit it here? Regards, Tormod
Bug#919397: apcalc FTBFS on 32bit big endian
tags 919397 pending
thanks
Thanks for your report. I already noticed the problem and a fix is in the
pipeline.
Martin
On Tue, Jan 15, 2019 at 04:31:30PM +0200, Adrian Bunk wrote:
> Source: apcalc
> Version: 2.12.7.2-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=apcalc
>
> ...
> In file included from qmath.h:32,
> from cmath.h:32,
> from value.h:33,
> from calc.h:33,
> from file.c:39:
> file.c: In function 'filepos2z':
> zmath.h:85:46: error: incompatible types when assigning to type 'HALF' {aka
> 'long unsigned int'} from type 'FILEPOS' {aka 'struct _G_fpos_t'}
> #define SWAP_HALF_IN_B32(dest, src) (*(dest) = *(src))
> ^
> fposval.h:15:42: note: in expansion of macro 'SWAP_HALF_IN_B32'
> #define SWAP_HALF_IN_FILEPOS(dest, src) SWAP_HALF_IN_B32(dest, src)
> ^~~~
> file.c:1370:2: note: in expansion of macro 'SWAP_HALF_IN_FILEPOS'
> SWAP_HALF_IN_FILEPOS(ret.v, );
> ^~~~
> make[1]: *** [Makefile:2364: file.o] Error 1
Bug#919438: libgsm1-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Package: libgsm1-dev Version: 1.0.18-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: stretch -> buster For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): 0m26.1s ERROR: FAIL: silently overwrites files via directory symlinks: /usr/share/doc/libgsm1-dev/MACHINES (libgsm1-dev:amd64) != /usr/share/doc/libgsm1/MACHINES (libgsm1:amd64) /usr/share/doc/libgsm1-dev -> libgsm1 /usr/share/doc/libgsm1-dev/README (libgsm1-dev:amd64) != /usr/share/doc/libgsm1/README (libgsm1:amd64) /usr/share/doc/libgsm1-dev -> libgsm1 /usr/share/doc/libgsm1-dev/changelog.Debian.gz (libgsm1-dev:amd64) != /usr/share/doc/libgsm1/changelog.Debian.gz (libgsm1:amd64) /usr/share/doc/libgsm1-dev -> libgsm1 /usr/share/doc/libgsm1-dev/changelog.gz (libgsm1-dev:amd64) != /usr/share/doc/libgsm1/changelog.gz (libgsm1:amd64) /usr/share/doc/libgsm1-dev -> libgsm1 /usr/share/doc/libgsm1-dev/copyright (libgsm1-dev:amd64) != /usr/share/doc/libgsm1/copyright (libgsm1:amd64) /usr/share/doc/libgsm1-dev -> libgsm1 cheers, Andreas libgsm1-dev_1.0.18-1.log.gz Description: application/gzip
Bug#919440: ITP: owlrl -- A simple implementation of the OWL2 RL Profile on top of RDFLib: it expands the graph with all possible triples that RDFS and OWL-RL defines. It can be used together with RDF
Package: wnpp Severity: wishlist Owner: Ashley Sommer * Package name: owlrl Version : 5.2.0 Upstream Author : Ivan Herman * URL : https://github.com/RDFLib/OWL-RL * License : W3C Programming Lang: Python Description : A simple implementation of the OWL2 RL Profile on top of RDFLib: it expands the graph with all possible triples that RDFS and OWL-RL defines. It can be used together with RDFLib to expand an RDFLib Graph object, or as a stand alone service with its own serialization. The useful python application called RDFClosure by Ivan Herman was recently updated to v5 and released on pypi. I am an active developer on owlrl and I maintain the pypi release. I indend to package another tool called pySHACL for debian, but it relies on owlrl, so I need owlrl released as a debian package first. The only requirement of owlrl is rdflib, which is already an actively maintained debian package. I intend to personally be the active maintainer of this package (via a sponsor). I have not released a debain package before, I will be looking for a sponsor to get this (owlrl) and pySHACL packaged and published, perhaps the maintainer or rdflib would like to sponsor this package.
Bug#919441: ITP: pyshacl -- A pure Python packages which allows for the validation of RDF graphs against Shapes Constraint Language (SHACL) files.
Package: wnpp Severity: wishlist Owner: Ashley Sommer * Package name: pyshacl Version : 0.9.9 Upstream Author : Ashley Sommer * URL : https://github.com/RDFLib/pyshacl * License : Apache License 2.0 Programming Lang: Python Description : A pure Python packages which allows for the validation of RDF graphs against Shapes Constraint Language (SHACL) files. This is a pure Python package which allows for the validation of RDF graphs against Shapes Constraint Language (SHACL) graphs. This module uses the rdflib Python library for working with RDF and is dependent on the OWL-RL Python module for OWL2 RL Profile-based expansion of data graphs. This module is developed to adhere to the SHACL Recommendation: >Holger Knublauch; Dimitris Kontokostas. Shapes Constraint Language (SHACL). 20 >July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/ ED: >https://w3c.github.io/data-shapes/shacl/ It has been suggested to me by several users that they find pySHACL to be a very useful tool and would like to see it available as a debian package. I agree. I am the lead developer of pySHACL and I maintain the release on pypi. As well as rdflib, this packages relies on the owlrl python module as a prerequisite. I've already filed an ITP for owlrl. I will be looking for a sponsor to get this software packaged, perhaps the maintainer for rdflib could help with sponsorship.
Bug#919439: bash: new alias behavior may freeze interpreter
Package: bash Version: 5.0-1 Severity: normal Dear Maintainer, While doing my regular upgrade of Sid, I happily discovered that brand new bash version 5.0-1 in the set of installed packages, so I gave it a try. :^) I ran the command `ls` which stuck without showing the output of my home directory while it usually did, and while /bin/ls did show it without much issues. Remembering a similar situation in a long forgotten past in Csh, I ran `unalias ls` and the situation went back to normal. Alas, in my foolishness, I dug deeper in my login scripts to understand why this was affecting me, thinking I introduced a loop of some sort. Instead I discovered that: if an alias ends with a tabulation character, then the hang reappears. Example: $ alias reproducer='true' $ reproducer _ ...and you should see your shell running at 100% in a monitor like `top`. I'm not sure if I broke something with my nonstandard system, but in case some other maniac of well aligned quote has the same issue, at least this entry exists. As an additional symptom, or lack of, an `strace bash` output of the shell does not show system calls while the interpreter is looping so, either there is no system call during the loop, or I don't strace the right process. Kind Regards, -- Étienne Mollier -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.8-fusion (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bash depends on: ii base-files 10.1 ii debianutils 4.8.6 ii libc62.28-5 ii libtinfo66.1+20181013-1 Versions of packages bash recommends: ii bash-completion 1:2.8-5 Versions of packages bash suggests: pn bash-doc -- no debconf information
Bug#919437: winff: [INTL:pt] Updated Portuguese translation - prog messages
Package: winff Version: 1.5.5-5 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for winff messages Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro - winff_1.5.5-5_winff.pt.po.gz Description: application/gzip
Bug#807886: Error in `/usr/sbin/apache2': free(): invalid next size (fast): -- /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3
Just experienced the same issue: apt purge php-gmagick followed by systemctl restart apache2 solved that issue Debian 9.6 ii apache2 2.4.25-3+deb9u6 amd64 Apache HTTP Server ii libapache2-mod-php7.0 7.0.30-0+deb9u1 amd64 server-side, HTML-embedded scripting language (Apache 2 module) ii php-imagick 3.4.3~rc2-2 amd64 Provides a wrapper to the ImageMagick library removed this one: ii php-gmagick 2.0.4~rc1+1.1.7~rc3-1 amd64 Provides a wrapper to the GraphicsMagick library
Bug#919436: lvm2: adequate reports obsolete-conffile for lvm2
Package: lvm2 Version: 2.03.02-1 Severity: normal User: debian...@lists.debian.org Usertags: obsolete-conffile adequate Dear Maintainer, Thank you for maintaining lvm2 . While updating a system, adequate informs me this - $ adequate lvm2 lvm2: obsolete-conffile /etc/init.d/lvm2 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'stable-debug'), (100, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8), LANGUAGE=en_IN.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lvm2 depends on: ii dmeventd 2:1.02.155-1 ii dmsetup 2:1.02.155-1 ii libaio1 0.3.111-1 ii libblkid1 2.33.1-0.1 ii libc6 2.28-4 ii libdevmapper-event1.02.1 2:1.02.155-1 ii libdevmapper1.02.12:1.02.155-1 ii libreadline5 5.2+dfsg-3+b2 ii libselinux1 2.8-1+b1 ii libsystemd0 240-2 ii libudev1 240-2 ii lsb-base 10.2018112800 Versions of packages lvm2 recommends: ii thin-provisioning-tools 0.7.4-2 lvm2 suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#917352: ubuntu-archive-keyring: Debconf template hard to understand (needs review)
control: tags -1 +pending Hi, On Wed, 26 Dec 2018 13:43:47 +0100 Helge Kreutzmann wrote: > Please present your debconf template to debian-l10n-english for review > and improvements. After that please use podebconf-report-po(1) to ask > translators to update the translation (and new ones to provide them). Thanks for pointing this out, I've posted it to l10n-english and got a review. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#919050: ITS: flashrom
Hi, On Mon, Jan 14, 2019 at 09:42:26AM +0100, Gürkan Myczko wrote: > > I've been thinking about RFA'ing the package for a while now, I > > currently don't have sufficient spare time to properly maintain it. > > > > If you're a DD and want to take over the package, please go ahead. > > I'm not, however I can add myself as co-maintainer and do some help, if that > is okay for you, I've filed an RFA over here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919434 Please coordinate with whoever wants to grab the package wrt. co-maintaining etc. Cheers, Uwe. -- http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org
Bug#717636: latex-sanskrit package
reassign 717636 texlive-lang-other
found 717636 2018.20181214-1
stop
On 13.10.14 13:34, intrigeri wrote:
> On current sid, with texlive-lang-indic installed:
>
> $ t1disasm
> /usr/share/texlive/texmf-dist/fonts/type1/public/sanskrit/sktb10.pfb | grep
> start
> dup 3 {systemdict /internaldict known not {pop 3} {1183615869 systemdict
> /internaldict get exec dup /startlock known {/startlock get exec} {dup
> /strtlck known {/strtlck get exec} {pop 3} ifelse} ifelse} ifelse}
> executeonly put
>
Still there:
root@amd64-sid:~# t1disasm
/usr/share/texlive/texmf-dist/fonts/type1/public/sanskrit-t1/sktb10.pfb
|grep start
dup 3 {systemdict /internaldict known not {pop 3} {1183615869 systemdict
/internaldict get exec dup /startlock known {/startlock get exec} {dup
/strtlck known {/strtlck get exec} {pop 3} ifelse} ifelse} ifelse}
executeonly put
found and reassign.
H.
--
#206401 http://counter.li.org
signature.asc
Description: OpenPGP digital signature
Bug#919435: texi2any.[1|pl]: Misformatted paragraph for the option "-o" in the manual
Package: texinfo
Version: 6.5.0.dfsg.1-4+b1
Severity: minor
Tags: patch
Dear Maintainer,
The extra indent in the paragraph for the option "-o" creats a
malformatted text in the manual (which is made with "help2man").
--- texi2any.pl 2019-01-15 20:23:34.0 +
+++ texi2any.pl.new 2019-01-15 20:24:52.0 +
@@ -720,10 +720,10 @@ the behavior is identical, and does not
default is on.
-o, --output=DEST output to DEST.
With split output, create DEST as a directory
- and put the output files there.
+and put the output files there.
With non-split output, if DEST is already
- a directory or ends with a /,
- put the output file there.
+a directory or ends with a /,
+put the output file there.
Otherwise, DEST names the output file.\n")
."\n";
$makeinfo_help .= sprintf(__("Options for Info and plain text:
-- System Information:
Debian Release: buster/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.144-1 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages texinfo depends on:
ii libc6 2.28-5
ii libtext-unidecode-perl 1.30-1
ii libxml-libxml-perl 2.0132+dfsg-2+b1
ii perl5.28.1-3
pn perlapi-5.28.0
ii tex-common 6.10
texinfo recommends no packages.
Versions of packages texinfo suggests:
ii texinfo-doc-nonfree 6.5.0-1
ii texlive-base 2018.20181214-1
ii texlive-fonts-recommended2018.20181214-1
pn texlive-generic-recommended
ii texlive-latex-base 2018.20181214-1
-- no debconf information
--
Bjarni I. Gislason
Bug#919434: RFA: flashrom -- Identify, read, write, erase, and verify BIOS/ROM/flash chips
Package: wnpp Severity: normal I request an adopter for the flashrom package. The package description is: flashrom is a tool for identifying, reading, writing, verifying and erasing flash chips. It's often used to flash BIOS/EFI/coreboot/firmware/optionROM images in-system using a supported mainboard, but it also supports flashing of network cards (NICs), SATA controller cards, and other external devices which can program flash chips. . It supports a wide range of DIP32, PLCC32, DIP8, SO8/SOIC8, TSOP32/40/48, and BGA chips, which use various protocols such as LPC, FWH, parallel flash, or SPI. . The tool can be used to flash BIOS/firmware images for example -- be it proprietary BIOS images or coreboot (previously known as LinuxBIOS) images. . It can also be used to read the current existing BIOS/firmware from a flash chip. . Currently supported programmers include: . * internal (for in-system flashing in the mainboard) * dummy (virtual programmer for testing flashrom) * nic3com (for flash ROMs on 3COM network cards) * nicrealtek (for flash ROMs on Realtek and SMC 1211 network cards) * nicnatsemi (for flash ROMs on National Semiconductor DP838* network cards) * nicintel (for parallel flash ROMs on Intel 10/100Mbit network cards) * gfxnvidia (for flash ROMs on NVIDIA graphics cards) * drkaiser (for flash ROMs on Dr. Kaiser PC-Waechter PCI cards) * satasii (for flash ROMs on Silicon Image SATA/IDE controllers) * satamv (for flash ROMs on Marvell SATA controllers) * atahpt (for flash ROMs on Highpoint ATA/RAID controllers) * atavia (for flash ROMs on VIA VT6421A SATA controllers) * atapromise (for flash ROMs on Promise PDC2026x ATA/RAID controllers) * it8212 (for flash ROMs on ITE IT8212F ATA/RAID controller) * ft2232_spi (for SPI flash ROMs attached to an FT2232/FT4232H/FT232H family based USB SPI programmer), including the DLP Design DLP-USB1232H, FTDI FT2232H Mini-Module, FTDI FT4232H Mini-Module, openbiosprog-spi, Amontec JTAGkey/JTAGkey-tiny/JTAGkey-2, Dangerous Prototypes Bus Blaster, Olimex ARM-USB-TINY/-H, Olimex ARM-USB-OCD/-H, TIAO/DIYGADGET USB Multi-Protocol Adapter (TUMPA), TUMPA Lite, GOEPEL PicoTAP, Google Servo v1/v2, and FIC OpenMoko Neo1973 Debug board. * serprog (for flash ROMs attached to a programmer speaking serprog), including AVR flasher by Urja Rannikko, AVR flasher by eightdot, Arduino Mega flasher by fritz, InSystemFlasher by Juhana Helovuo, and atmegaXXu2-flasher by Stefan Tauner. * buspirate_spi (for SPI flash ROMs attached to a Bus Pirate) * dediprog (for SPI flash ROMs attached to a Dediprog SF100) * rayer_spi (for SPI flash ROMs attached to a RayeR parport based programmer) * pony_spi (for SPI flash ROMs attached to a SI-Prog serial port bitbanging adapter) * nicintel_spi (for SPI flash ROMs on Intel Gigabit network cards) * ogp_spi (for SPI flash ROMs on Open Graphics Project graphics card) * linux_spi (for SPI flash ROMs accessible via /dev/spidevX.Y on Linux) * usbblaster_spi (for SPI flash ROMs attached to an Altera USB-Blaster) * nicintel_eeprom (for SPI EEPROMs on Intel Gigabit network cards) * mstarddc_spi (for SPI flash ROMs accessible through DDC in MSTAR-equipped displays) * pickit2_spi (for SPI flash ROMs accessible via Microchip PICkit2) * ch341a_spi (for SPI flash ROMs attached to WCH CH341A) Uwe. -- http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org
Bug#918925: i3: Status and title bar text do not appear with default config file
I just reinstalled buster to switch from armhf to aarch64, so my system is now pretty bare and unmodified other than installing build-essential, i3, and some python3 packages. Nevertheless I was able to reproduce the issue. I installed and ran font-manager from within i3 and nothing looks out of the ordinary. > On Jan 11, 2019, at 11:59, Michael Stapelberg wrote: > > Then use whichever tool has a font selection dialog :) > >> On Fri, Jan 11, 2019 at 5:18 PM Leo Pound Singer wrote: >> gnome-specimen is not in buster. It has been removed from Debian. >> >> >> >> Sent from my iPhone >>> On Jan 10, 2019, at 16:46, Michael Stapelberg wrote: >>> >>> That’s weird. Something must be different in your system, though, as this >>> is the first time anyone has ever reported this issue. >>> >>> Can you check gnome-specimen and see if fonts show up correctly there? Can >>> you try using them with i3 and see if that works in general? >>> On Thu, Jan 10, 2019 at 7:41 PM Leo Pound Singer wrote: No, all of the packages recommended by i3-wm are installed. > On Jan 10, 2019, at 12:25, Michael Stapelberg > wrote: > > Did you disable apt recommendations? The i3-wm package recommends > fonts-dejavu-core, which should be picked up as a suitable font. Do you > have that package installed? > >> On Thu, Jan 10, 2019 at 5:48 PM Leo Singer wrote: >> Package: i3 >> Version: 4.16-1 >> Severity: normal >> >> Dear Maintainer, >> >> I installed i3 under Debian Buster (armhf) on a Raspberry Pi 3B+. With >> the >> automatically generated configuration file, the i3 title and status bars >> are >> blank. >> >> I found that I could get the title and status bar text to show up by >> employing >> the workaround of uncommenting the following font option in >> ~/.config/i3/config: >> >> font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1 >> >> I do not know if this issue also occurs on more commonplace amd64 >> systems. >> >> Would you please modify the package so that the title and status bar >> text are >> visible with the default, automatically generated i3 config file? >> >> Regards, >> Leo >> >> >> >> -- System Information: >> Debian Release: buster/sid >> APT prefers testing >> APT policy: (500, 'testing') >> Architecture: armhf (armv7l) >> >> Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores) >> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C >> (charmap=UTF-8) >> Shell: /bin/sh linked to /usr/bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled >> >> Versions of packages i3 depends on: >> ii i3-wm 4.16-1 >> >> Versions of packages i3 recommends: >> ii dunst 1.3.2-1 >> ii i3lock 2.11.1-1 >> ii i3status2.12-1 >> ii suckless-tools 44-1 >> >> i3 suggests no packages. >> >> -- no debconf information > > > -- > Best regards, > Michael >>> >>> >>> -- >>> Best regards, >>> Michael > > > -- > Best regards, > Michael
Bug#918789: gnustep-back-common: postinst fails on hurd-i386
Hello, Yavor Doganov, le mer. 09 janv. 2019 13:39:46 +0200, a ecrit: > Package: gnustep-back-common > Version: 0.26.2-4 > Severity: important > User: debian-h...@lists.debian.org > Usertags: hurd-i386 > > I noticed that gnumail and adun.app have been given back a few hundred > times because gnustep-back-common's postinst fails on GNU/Hurd. I would > appreciate if you investigate and see what's going wrong, is it mknfonts > that fails or something else? It seems this got fixed? Samuel
Bug#908796: udev 240-2: failed to connect to udev daemon (on boot)
On Tue, 15 Jan 2019 20:35:59 +, js jb wrote: > = > NOTE: udev 240-2 failed to connect to udev daemon on boot, so had to > downgrade to the > previous version, 239-15 on which this bug report is made, in order to > get a > workable system with mouse and sound. This bug is most likely fixed in 240-4. Maybe you could try this version and report back? Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Cat Stevens: The Foreigner Suite signature.asc Description: Digital Signature
Bug#918926: Surf still cannot start dmenu due to permission denied error
Control: reopen -1 On Tue, Jan 15, 2019 at 04:34:47PM -0500, Leo Pound Singer wrote: > I just did a fresh installation of buster on my Rapsberry Pi to switch from > armhf to aarch64, and I am still finding that surf cannot start dmenu due to > the same permission denied error. I have surf-2.0+git20181009-2. Can you please check the kernel log (dmesg), if there are apparmor-related messages? Thanks! Kind regards, Reiner signature.asc Description: PGP signature
Bug#918926: Surf still cannot start dmenu due to permission denied error
I just did a fresh installation of buster on my Rapsberry Pi to switch from armhf to aarch64, and I am still finding that surf cannot start dmenu due to the same permission denied error. I have surf-2.0+git20181009-2.
Bug#919433: RFS: ca-certificates/20190110 [RC;Security]
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "ca-certificates"
* Package name: ca-certificates
Version : 20190110
* License : GPL-2+, MPL-2.0
Section : misc
It builds those binary packages:
ca-certificates - Common CA certificates
ca-certificates-udeb - Common CA certificates - udeb (udeb)
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/ca-certificates
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20190110.dsc
Changes since the last upload:
ca-certificates (20190110) unstable; urgency=high
* debian/control:
Depend on openssl (>= 1.1.1).
Set Standards-Version: 4.3.0.1.
Set Build-Depends: debhelper-compat (= 12); drop d/compat
Remove trailing whitespace from d/changelog.
* debian/ca-certificates.postinst:
Fix permissions on /usr/local/share/ca-certificates when using symlinks.
Closes: #916833
* sbin/update-ca-certificates:
Remove orphan symlinks found in /etc/ssl/certs to prevent `openssl
rehash` from exiting with an error. Closes: #895482, #895473
This will also fix removal of user CA certificates from /usr/local
without
needing to run --fresh. Closes: #911303
* mozilla/{certdata.txt,nssckbi.h}:
Update Mozilla certificate authority bundle to version 2.28.
The following certificate authorities were added (+):
+ "GlobalSign Root CA - R6"
+ "OISTE WISeKey Global Root GC CA"
The following certificate authorities were removed (-):
- "Certplus Root CA G1"
- "Certplus Root CA G2"
- "OpenTrust Root CA G1"
- "OpenTrust Root CA G2"
- "OpenTrust Root CA G3"
- "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
- "Visa eCommerce Root"
-- Michael Shuler Thu, 10 Jan 2019 19:31:31 -0600
--
Kind regards,
Michael
signature.asc
Description: OpenPGP digital signature
Bug#916796: IEEEfull.bib: cannot be read in encoding 'utf8' by biber
On 15.01.19 09:59, Damir Islamov wrote: Hi Damir, > I got response from Michael Shell, maintainer of IEEEtran.bst package. > Please make sure the file uploaded to CTAN, else we won't get the fix. Many thanks! Hilmar -- #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#919432: yaml-cpp: CVE-2019-6285
Source: yaml-cpp Version: 0.6.2-4 Severity: important Tags: security upstream Forwarded: https://github.com/jbeder/yaml-cpp/issues/660 Hi, The following vulnerability was published for yaml-cpp. CVE-2019-6285[0]: | The SingleDocParser::HandleFlowSequence function in yaml-cpp (aka | LibYaml-C++) 0.6.2 allows remote attackers to cause a denial of service | (stack consumption and application crash) via a crafted YAML file. the issue looks similar to CVE-2019-6292 but does not seem to be a duplicate. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-6285 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6285 [1] https://github.com/jbeder/yaml-cpp/issues/660 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#915025: libopenmpi-dev: fails to upgrade from 'stretch': new libopenmpi-dev package pre-installation script subprocess returned error exit status 2
Followup-For: Bug #915025 Control: found -1 3.1.3-9 Preparing to unpack .../45-libopenmpi-dev_3.1.3-9_amd64.deb ... dpkg: error processing archive /tmp/apt-dpkg-install-bUBTzo/45-libopenmpi-dev_3.1.3-9_amd64.deb (--unpack): new libopenmpi-dev package pre-installation script subprocess returned error exit status 2 update-alternatives: using /usr/lib/x86_64-linux-gnu/openmpi/include to provide /usr/include/mpi (mpi) in auto mode Andreas libopenmpi-dev_3.1.3-9.log.gz Description: application/gzip
Bug#919431: dkms: adequate reports dkms has an obsolete conffile
Package: dkms Version: 2.6.1-3 Severity: normal User: debian...@lists.debian.org Usertags: obsolete-conffile adequate Dear Maintainer, Thank you for maintaining dkms. Today while upgrading came across the following - $ adequate dkms dkms: obsolete-conffile /etc/bash_completion.d/dkms Please fix the same. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'stable-debug'), (100, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8), LANGUAGE=en_IN.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dkms depends on: ii build-essential 12.5 ii coreutils8.30-1 ii dpkg-dev 1.19.2 ii gcc 4:8.2.0-2 ii kmod 25-2 ii make 4.2.1-1.2 ii patch2.7.6-3 Versions of packages dkms recommends: ii fakeroot 1.23-1 ii linux-headers-amd64 4.19+101 ii lsb-release 10.2018112800 ii sudo 1.8.26-2 Versions of packages dkms suggests: ii menu2.1.47+b1 ii python3-apport 2.20.4-2 -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#919430: yaml-cpp: CVE-2019-6292
Source: yaml-cpp Version: 0.6.2-4 Severity: important Tags: security upstream Forwarded: https://github.com/jbeder/yaml-cpp/issues/657 Hi, The following vulnerability was published for yaml-cpp. CVE-2019-6292[0]: | An issue was discovered in singledocparser.cpp in yaml-cpp (aka | LibYaml-C++) 0.6.2. Stack Exhaustion occurs in YAML::SingleDocParser, | and there is a stack consumption problem caused by recursive stack | frames: HandleCompactMap, HandleMap, HandleFlowSequence, | HandleSequence, HandleNode. Remote attackers could leverage this | vulnerability to cause a denial-of-service via a cpp file. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-6292 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6292 [1] https://github.com/jbeder/yaml-cpp/issues/657 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#919429: displaycal: removal of displaycal makes files disappear from dispcalgui
Package: displaycal Version: 3.7.1.3-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts replaces-without-breaks Hi, during a test with piuparts and DOSE tools I noticed your package causes removal of files that also belong to another package. This is caused by using Replaces without corresponding Breaks. The installation sequence to reproduce this problem is apt-get install dispcalgui/stretch # (1) apt-get install displaycal/buster apt-get remove displaycal # (2) The list of installed files at points (1) and (2) should be identical, but the following files have disappeared: /etc/xdg/autostart/z-displaycal-apply-profiles.desktop owned by: displaycal /usr/bin/displaycalowned by: displaycal /usr/bin/displaycal-3dlut-makerowned by: displaycal /usr/bin/displaycal-apply-profiles owned by: displaycal /usr/bin/displaycal-curve-viewer owned by: displaycal /usr/bin/displaycal-profile-info owned by: displaycal ... /usr/share/man/man1/displaycal-scripting-client.1.gz owned by: displaycal /usr/share/man/man1/displaycal-synthprofile.1.gz owned by: displaycal /usr/share/man/man1/displaycal-testchart-editor.1.gz owned by: displaycal /usr/share/man/man1/displaycal-vrml-to-x3d-converter.1.gz owned by: displaycal /usr/share/man/man1/displaycal.1.gzowned by: displaycal This is a serious bug violating policy 7.6, see https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces and also see the footnote that describes this incorrect behavior: https://www.debian.org/doc/debian-policy/ch-relationships.html#id13 The displaycal package has the following relationships with dispcalgui: Conflicts: n/a Breaks:n/a Replaces: dispcalgui Since dispcalgui is a transitional package since 3.6.1.0-1 you should add/update Breaks+Replaces: dispcalgui (<< 3.6.1.0) in the displaycal package. >From the attached log (scroll to the bottom...): 0m41.7s ERROR: FAIL: After purging files have disappeared: /etc/xdg/autostart/z-displaycal-apply-profiles.desktop owned by: displaycal /usr/bin/displaycalowned by: displaycal /usr/bin/displaycal-3dlut-makerowned by: displaycal /usr/bin/displaycal-apply-profiles owned by: displaycal /usr/bin/displaycal-curve-viewer owned by: displaycal /usr/bin/displaycal-profile-info owned by: displaycal ... /usr/share/man/man1/displaycal-scripting-client.1.gz owned by: displaycal /usr/share/man/man1/displaycal-synthprofile.1.gz owned by: displaycal /usr/share/man/man1/displaycal-testchart-editor.1.gz owned by: displaycal /usr/share/man/man1/displaycal-vrml-to-x3d-converter.1.gz owned by: displaycal /usr/share/man/man1/displaycal.1.gzowned by: displaycal 0m41.7s ERROR: FAIL: After purging files have been modified: /etc/mailcap not owned /var/lib/dpkg/info/dispcalgui.list not owned cheers, Andreas dispcalgui=3.2.2.0-1_displaycal=3.7.1.3-4.log.gz Description: application/gzip
Bug#917909: NMU for fribidi 1.0.5-3.1
Hi all, Samuel Thibault wrote: > Hugh McMaster, le mer. 09 janv. 2019 22:18:52 +1100, a ecrit: > > I have prepared an NMU for fribidi, fixing bugs 907792 and 917909. > > Thanks! > > I can confirm that today's daily build has RtL fixed in textmode. this issue has been reported as being fixed recently. Maybe you want to give it a try, use the debian-testing-amd64-netinst.iso from https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/ and try the text-based installer there. Thanks Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#919428: flex: CVE-2019-6293: stack consumption
Source: flex Version: 2.6.4-6.2 Severity: normal Tags: security upstream Forwarded: https://github.com/westes/flex/issues/414 Hi, The following vulnerability was published for flex. CVE-2019-6293[0]: | An issue was discovered in the function mark_beginning_as_normal in | nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the | mark_beginning_as_normal function making recursive calls to itself in | certain scenarios involving lots of '*' characters. Remote attackers | could leverage this vulnerability to cause a denial-of-service. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-6293 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6293 [1] https://github.com/westes/flex/issues/414 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#919427: emacspeak eterm does not speak several key commands
package: emacspeak severity: important tags: patch version: 47.0+dfsg-6 Hi. several of the key eterm commands don't speak. I'm opening a bug that I already have a patch for; expect a merge request shortly.
Bug#919426: netplan.io breaks in autopkgtest setup on ci.debian.net
Source: netplan.io Version: 0.40.2-1 Control: found -1 0.95-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: issue Dear maintainer, Your package has an autopkgtest, great. However, your autopkgtest breaks in the setup of ci.debian.net. As your tests runs successfully on Ubuntu infrastructure, I suspect that also the last test needs a "Restriction: isolation-machine" instead of isolation-container. Please reassign to autopkgtest if you believe the test should be supported by lxc and autopkgtest isn't doing the right thing (but please provide more background if you do). I'll blacklist the package for now on our infrastructure as running this test currently is useless. I'll raise the blockage when this bug is fixed. Paul https://ci.debian.net/data/autopkgtest/testing/amd64/n/netplan.io/1708693/log.gz autopkgtest [19:12:26]: test autostart: [--- INFO: Doing initial check that there is no existing netplan config. ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-networkd.service(8) INFO: systemd-networkd is fine, rebooting... bash: line 1: 708 Killed /tmp/autopkgtest-lxc.x0i05ey3/downtmp/build.Ci8/src/debian/tests/autostart 2> >(tee -a /tmp/autopkgtest-lxc.x0i05ey3/downtmp/autostart-stderr >&2) > >(tee -a /tmp/autopkgtest-lxc.x0i05ey3/downtmp/autostart-stdout) autopkgtest [19:12:26]: test process requested reboot with marker noconfig INFO: Verifying that the test bridge is not up and writing config. INFO: Configuration written, rebooting... bash: line 1: 191 Killed /tmp/autopkgtest-lxc.x0i05ey3/downtmp/build.Ci8/src/debian/tests/autostart 2> >(tee -a /tmp/autopkgtest-lxc.x0i05ey3/downtmp/autostart-stderr >&2) > >(tee -a /tmp/autopkgtest-lxc.x0i05ey3/downtmp/autostart-stdout) autopkgtest [19:12:44]: test process requested reboot with marker config autopkgtest-virt-lxc [19:13:56]: ERROR: WARNING: Cannot kill timed out process ['sudo', 'lxc-attach', '--name', 'ci-1547579505', '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target']: [Errno 1] Operation not permitted Unexpected error: Traceback (most recent call last):https://ci.debian.net/data/autopkgtest/testing/amd64/n/netplan.io/1708693/log.gz File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 738, in mainloop command() File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 667, in command r = f(c, ce) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 363, in cmd_reboot caller.hook_wait_reboot() File "/usr/bin/autopkgtest-virt-lxc", line 304, in hook_wait_reboot wait_booted(lxc_container_name) File "/usr/bin/autopkgtest-virt-lxc", line 128, in wait_booted VirtSubproc.check_exec(sudoify(['lxc-attach', '--name', lxc_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target']), timeout=60) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec stdout=stdout, stderr=subprocess.PIPE) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout (out, err) = sp.communicate(instr) File "/usr/lib/python3.5/subprocess.py", line 791, in communicate stderr = self.stderr.read() File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler raise Timeout() VirtSubproc.Timeout autopkgtest [19:13:57]: ERROR: testbed failure: cannot send to testbed: [Errno 32] Broken pipe signature.asc Description: OpenPGP digital signature
Bug#919423: Acknowledgement (nova: [INTL:de] updated German debconf translation)
Hello, accidentially I sent the wrong file, please use the one attached to this e-mail. An upload before the Freeze would be much appreciated. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ # GERMAN TRANSLATION OF THE NOVA DEBCONF TEMPLATE. # Copyright (c) 2010 OpenStack LLC. # This file is distributed under the same license as the NOVA package. # Copyright of this file Erik Pfannenstein 2012, # Chris Leick 2013-2018. msgid "" msgstr "" "Project-Id-Version: nova 2:18.0.3-3\n" "Report-Msgid-Bugs-To: n...@packages.debian.org\n" "POT-Creation-Date: 2018-11-11 11:15+0100\n" "PO-Revision-Date: 2019-01-15 21:17+0100\n" "Last-Translator: Chris Leick \n" "Language-Team: German \n" "Language: de\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" #. Type: multiselect #. Description #: ../nova-common.templates.in:2001 msgid "API to activate:" msgstr "API, die aktiviert werden soll:" #. Type: multiselect #. Description #: ../nova-common.templates.in:2001 msgid "" "Openstack Nova supports different API services, each of them binding on a " "different port. Select which one nova-api should support." msgstr "" "Openstack Nova unterstützt verschiedene API-Dienste, von denen jeder " "einzelne an einen anderen Port gebunden ist. Wählen Sie aus, welche von " "»nova-api« unterstützt werden sollen." #. Type: multiselect #. Description #: ../nova-common.templates.in:2001 msgid "" "If it is a compute node that you are setting-up, then you only need to run " "the metadata API server. If you run Cinder, then you don't need osapi_volume " "(you cannot run osapi_volume and cinder-api on the same server: they bind on " "the same port)." msgstr "" "Falls Sie einen Rechenknoten einrichten, müssen Sie nur den Metadaten-API-" "Server ausführen. Falls Sie Cinder ausführen, benötigen Sie »osapi_volume« " "nicht (Sie können »osapi_volume« und »cinder-api« nicht auf demselben Server " "ausführen, sie binden sich an den selben Port)." #. Type: string #. Description #: ../nova-common.templates.in:3001 msgid "Value for my_ip:" msgstr "Wert für »my_ip«:" #. Type: string #. Description #: ../nova-common.templates.in:3001 msgid "This value will be stored in the my_ip directive of nova.conf." msgstr "" "Dieser Wert wird im Eintrag »my_ip« der »nova.conf« gespeichert." #. Type: string #. Description #: ../nova-common.templates.in:4001 msgid "Neutron server URL:" msgstr "URL des Neutron-Servers:" #. Type: string #. Description #: ../nova-common.templates.in:4001 msgid "Please enter the URL of the Neutron server." msgstr "Bitte geben Sie die URL des Neutron-Servers ein." #. Type: string #. Description #: ../nova-common.templates.in:5001 msgid "Neutron admin tenant name:" msgstr "Tenant-Name des Neutron-Administrators:" #. Type: string #. Description #: ../nova-common.templates.in:5001 msgid "" "Nova needs to be able to communicate with Neutron through Keystone. " "Therefore Nova needs to know the Neutron admin tenant, username and password." msgstr "" "Nova muss mit Neutron über Keystone kommunizieren. Daher muss Nova den " "Tenant, Benutzernamen und das Passwort des Neutron-Administrators kennen." #. Type: string #. Description #: ../nova-common.templates.in:5001 msgid "Please enter the name of the admin tenant for Neutron." msgstr "Bitte geben Sie den Namen des Administrator-Tenants für Neutron ein." #. Type: string #. Description #: ../nova-common.templates.in:6001 msgid "Neutron administrator username:" msgstr "Benutzername des Neutron-Administrators:" #. Type: string #. Description #: ../nova-common.templates.in:6001 msgid "Please enter the username of the Neutron administrator." msgstr "Bitte geben Sie den Benutzernamen des Neutron-Administrators ein." #. Type: password #. Description #: ../nova-common.templates.in:7001 msgid "Neutron administrator password:" msgstr "Passwort des Neutron-Administrators:" #. Type: password #. Description #: ../nova-common.templates.in:7001 msgid "Please enter the password of the Neutron administrator." msgstr "Bitte geben Sie das Passwort des Neutron-Administrators ein." #. Type: password #. Description #: ../nova-common.templates.in:8001 msgid "Metadata proxy shared secret:" msgstr "Gemeinsam benutztes Geheimnis des Metadaten-Proxys:" #. Type: password #. Description #: ../nova-common.templates.in:8001 msgid "" "VM instances using Neutron to handle networking retrieve their metadata " "through the Neutron metadata agent, which serves as a proxy to the Nova " "metadata REST API server." msgstr "" "VM-Instanzen, die Neutron verwenden, um sich um die Vernetzung zu kümmern, " "fragen ihre Metadaten über den Neutron-Metadatenagenten ab. Er
Bug#916468: whitedune: diff for NMU version 0.30.10-2.2
tags 916468 + patch tags 916468 + pending Dear maintainer, I've prepared an NMU for whitedune (versioned as 0.30.10-2.2) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. I have based my NMU on top of what is currently in the salsa archive, so it includes a bit more than needed to fix this bug. Regards. Paul diff -Nru whitedune-0.30.10/debian/changelog whitedune-0.30.10/debian/changelog --- whitedune-0.30.10/debian/changelog 2016-03-07 17:19:38.0 +0100 +++ whitedune-0.30.10/debian/changelog 2019-01-15 20:45:29.0 +0100 @@ -1,3 +1,24 @@ +whitedune (0.30.10-2.2) unstable; urgency=medium + + * Non-maintainer upload. + + [ Johannes Brandstätter ] + * Update watch file to new upstream release page + + [ Ondřej Nový ] + * d/control: Set Vcs-* to salsa.debian.org + + [ Felipe Sateler ] + * Change maintainer address to debian-multime...@lists.debian.org + + [ Ondřej Nový ] + * d/rules: Remove trailing whitespaces + + [ Paul Gevers ] + * Drop /usr/bin/dune softlink (Closes: #916468) + + -- Paul Gevers Tue, 15 Jan 2019 20:45:29 +0100 + whitedune (0.30.10-2.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru whitedune-0.30.10/debian/control whitedune-0.30.10/debian/control --- whitedune-0.30.10/debian/control2016-01-09 21:12:53.0 +0100 +++ whitedune-0.30.10/debian/control2019-01-15 20:45:29.0 +0100 @@ -1,7 +1,7 @@ Source: whitedune Section: graphics Priority: optional -Maintainer: Debian Multimedia Maintainers +Maintainer: Debian Multimedia Maintainers Uploaders: Philippe Coval Build-Depends: autoconf, @@ -20,8 +20,8 @@ x11proto-core-dev Standards-Version: 3.9.6 Homepage: http://vrml.cip.ica.uni-stuttgart.de/dune/ -Vcs-Git: git://anonscm.debian.org/pkg-multimedia/whitedune.git -Vcs-Browser: https://anonscm.debian.org/cgit/pkg-multimedia/whitedune.git +Vcs-Git: https://salsa.debian.org/multimedia-team/whitedune.git +Vcs-Browser: https://salsa.debian.org/multimedia-team/whitedune Package: whitedune Architecture: any diff -Nru whitedune-0.30.10/debian/NEWS whitedune-0.30.10/debian/NEWS --- whitedune-0.30.10/debian/NEWS 1970-01-01 01:00:00.0 +0100 +++ whitedune-0.30.10/debian/NEWS 2019-01-15 20:45:29.0 +0100 @@ -0,0 +1,6 @@ +whitedune (0.30.10-2.2) unstable; urgency=medium + + The /usr/bin/dune softlink was dropped because there was a namespace +clash. + + -- Paul Gevers Tue, 15 Jan 2019 20:42:23 +0100 diff -Nru whitedune-0.30.10/debian/rules whitedune-0.30.10/debian/rules --- whitedune-0.30.10/debian/rules 2016-01-09 21:44:44.0 +0100 +++ whitedune-0.30.10/debian/rules 2019-01-15 20:45:29.0 +0100 @@ -113,6 +113,6 @@ dh_builddeb -a binary: binary-indep binary-arch -.PHONY: build clean binary-indep binary-arch binary install +.PHONY: build clean binary-indep binary-arch binary install #eof "$Id: rules -- rzr $" diff -Nru whitedune-0.30.10/debian/watch whitedune-0.30.10/debian/watch --- whitedune-0.30.10/debian/watch 2016-01-09 16:22:17.0 +0100 +++ whitedune-0.30.10/debian/watch 2019-01-15 20:45:29.0 +0100 @@ -1,3 +1,3 @@ version=3 -http://vrml.cip.ica.uni-stuttgart.de/dune/down.html \ - http://129.69.35.12/dune/white_dune-(\d*\.\d*pl\d*)\.tar\.gz +http://wdune.ourproject.org/ \ + ftp://ftp.ourproject.org/pub/wdune/wdune-(\d*\.\d*pl\d*)\.tar\.bz2 diff -Nru whitedune-0.30.10/debian/whitedune.links whitedune-0.30.10/debian/whitedune.links --- whitedune-0.30.10/debian/whitedune.links2016-01-09 16:40:49.0 +0100 +++ whitedune-0.30.10/debian/whitedune.links1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -/usr/bin/whitedune /usr/bin/dune signature.asc Description: OpenPGP digital signature
Bug#887465: Please update to new upstream version
HI Fabian, On Di 15 Jan 2019 20:17:05 CET, Fabián Rodríguez wrote: Package: guacamole Version: 0.9.9+dfsg-1 Followup-For: Bug #887465 Dear Maintainer, A newer version 0.9.14 was released on 2018-01-18: http://guacamole.apache.org/releases/1.0.0/ It introduces important changes, see: http://guacamole.apache.org/releases/1.0.0/#deprecation--compatibility-notes Does this version now build against FreeRDP v2? If not, we can upload this new upstream version, but we need to disable FreeRDP support (which makes it less usable for most end users). Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgp0zwCwwhsA7.pgp Description: Digitale PGP-Signatur
Bug#656828: speech-dispatcher: HelloWorld example only speaks 'once' using Python API
Hi Samuel,
On 01-01-2019 20:32, Samuel Thibault wrote:
> Paul Gevers, le sam. 04 janv. 2014 09:05:32 +0100, a ecrit:
>> On 22-01-12 01:59, Tim Skillman wrote:
>>> I tried the sample code given for the Python speech API which is
>>>
>>> import speechd
>>> client = speechd.SSIPClient('test')
>>> client.set_output_module('festival')
>>> client.set_language('en')
>>> client.set_punctuation(speechd.PunctuationMode.SOME)
>>> client.speak("Hello World!")
>>> client.close()
>>>
>>> 1) After running the script there was a pause and "Hello World" was spoken.
>>
>> If I try this, the sound is awful. If I pause before close() than it
>> sounds normal.
>
> That part is most probably https://github.com/brailcom/speechd/issues/198
On January 1, I could reproduce that straight away, now I can't (maybe
nothing else is asking for sound).
>>> 2) I then stopped the script and ran it again and the script immediately
>>> stopped with no errors and no speech!
>>
>> Indeed, but if I pause before close() than the next time it works also.
>
> I'm not getting this issue, does it still happen on your system? It
> might have been fixed in the meanwhile.
I couldn't reproduce this anymore, but as the first part also sometimes
fails to reproduce I don't know what that means.
Paul
signature.asc
Description: OpenPGP digital signature
Bug#919423: nova: [INTL:de] updated German debconf translation
Package: nova Version: 2:18.0.3-5 Severity: wishlist Tags: patch l10n Please find the updated German debconf translation for nova attached. Please place this file in debian/po/ as de.po for your next upload. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Greetings Helge # GERMAN TRANSLATION OF THE NOVA DEBCONF TEMPLATE. # Copyright (c) 2010 OpenStack LLC. # This file is distributed under the same license as the NOVA package. # Copyright of this file Erik Pfannenstein 2012, # Chris Leick 2013-2018. msgid "" msgstr "" "Project-Id-Version: nova 2:18.0.3-3\n" "Report-Msgid-Bugs-To: n...@packages.debian.org\n" "POT-Creation-Date: 2018-11-11 11:15+0100\n" "PO-Revision-Date: 2019-01-08 17:35+0100\n" "Last-Translator: Chris Leick \n" "Language-Team: German \n" "Language: de\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" #. Type: multiselect #. Description #: ../nova-common.templates.in:2001 msgid "API to activate:" msgstr "API, die aktiviert werden soll:" #. Type: multiselect #. Description #: ../nova-common.templates.in:2001 msgid "" "Openstack Nova supports different API services, each of them binding on a " "different port. Select which one nova-api should support." msgstr "" "Openstack Nova unterstützt verschiedene API-Dienste, von denen jeder " "einzelne an einen anderen Port gebunden ist. Wählen Sie aus, welche von " "»nova-api« unterstützt werden sollen." #. Type: multiselect #. Description #: ../nova-common.templates.in:2001 msgid "" "If it is a compute node that you are setting-up, then you only need to run " "the metadata API server. If you run Cinder, then you don't need osapi_volume " "(you cannot run osapi_volume and cinder-api on the same server: they bind on " "the same port)." msgstr "" "Falls Sie einen Rechenknoten einrichten, müssen Sie nur den Metadaten-API-" "Server ausführen. Falls Sie Cinder ausführen, benötigen Sie »osapi_volume« " "nicht (Sie können »osapi_volume« und »cinder-api« nicht auf demselben Server " "ausführen, sie binden sich an den selben Port)." #. Type: string #. Description #: ../nova-common.templates.in:3001 msgid "Value for my_ip:" msgstr "Wert für »my_ip«:" #. Type: string #. Description #: ../nova-common.templates.in:3001 msgid "This value will be stored in the my_ip directive of nova.conf." msgstr "" "Dieser Wert wird im Eintrag »my_ip« der »nova.conf« gespeichert." #. Type: string #. Description #: ../nova-common.templates.in:4001 msgid "Neutron server URL:" msgstr "URL des Neutron-Servers:" #. Type: string #. Description #: ../nova-common.templates.in:4001 msgid "Please enter the URL of the Neutron server." msgstr "Bitte geben Sie die URL des Neutron-Servers ein." #. Type: string #. Description #: ../nova-common.templates.in:5001 msgid "Neutron admin tenant name:" msgstr "Tenant-Name des Neutron-Administrators:" #. Type: string #. Description #: ../nova-common.templates.in:5001 msgid "" "Nova needs to be able to communicate with Neutron through Keystone. " "Therefore Nova needs to know the Neutron admin tenant, username and password." msgstr "" "Nova muss mit Neutron über Keystone kommunizieren. Daher muss Nova den " "Tenant, Benutzernamen und das Passwort des Neutron-Administrators kennen." #. Type: string #. Description #: ../nova-common.templates.in:5001 msgid "Please enter the name of the admin tenant for Neutron." msgstr "Bitte geben Sie den Namen des Administrator-Tenants für Neutron ein." #. Type: string #. Description #: ../nova-common.templates.in:6001 msgid "Neutron administrator username:" msgstr "Benutzername des Neutron-Administrators:" #. Type: string #. Description #: ../nova-common.templates.in:6001 msgid "Please enter the username of the Neutron administrator." msgstr "Bitte geben Sie den Benutzernamen des Neutron-Administrators ein." #. Type: password #. Description #: ../nova-common.templates.in:7001 msgid "Neutron administrator password:" msgstr "Passwort des Neutron-Administrators:" #. Type: password #. Description #: ../nova-common.templates.in:7001 msgid "Please enter the password of the Neutron administrator." msgstr "Bitte geben Sie das Passwort des Neutron-Administrators ein." #. Type: password #. Description #: ../nova-common.templates.in:8001 msgid "Metadata proxy shared secret:" msgstr "Gemeinsam benutztes Geheimnis des Metadaten-Proxys:" #. Type: password #. Description #: ../nova-common.templates.in:8001 msgid "" "VM instances using Neutron to handle networking retrieve their metadata " "through the Neutron metadata agent, which serves as a proxy to the Nova " "metadata REST API server." msgstr "" "VM-Instanzen, die Neutron verwenden, um sich um die Vernetzung zu kümmern, " "fragen ihre Metadaten über den Neutron-Metadatenagenten ab. Er dient "
Bug#919425: minissdpd: [INTL:de] updated German debconf translation
Package: minissdpd Version: 1.5.20180223-4 Severity: wishlist Tags: patch l10n Please find the updated German debconf translation for minissdpd attached. Please place this file in debian/po/ as de.po for your next upload. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Greetings Helge # German translation of Debconf template for minissdpd # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the minissdpd package. # Helge Kreutzmann , 2018, 2019. # msgid "" msgstr "" "Project-Id-Version: minissdpd 1.5.20180223-4\n" "Report-Msgid-Bugs-To: miniss...@packages.debian.org\n" "POT-Creation-Date: 2019-01-07 15:57+0800\n" "PO-Revision-Date: 2019-01-15 20:38+0100\n" "Last-Translator: Helge Kreutzmann \n" "Language-Team: german \n" "Language: de\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: note #. Description #: ../minissdpd.templates:1001 msgid "MiniSSDP daemon configuration" msgstr "Konfiguration des MiniSSDP-Daemons" #. Type: note #. Description #: ../minissdpd.templates:1001 msgid "" "If you see this message but never manually install MiniSSDP, then most " "probably this package is automatically pulled as a recommendation for " "libminiupnpc, which is the UPnP support library for many applications." msgstr "" "Falls Sie diese Nachricht sehen aber MiniSSDP niemals manuell installiert " "haben, dann wird das Paket höchstwahrscheinlich als Empfehlung für " "libminiupnpc automatisch hereingezogen. Libminiupnpc ist eine UPnP-" "Unterstützungsbibliothek für viele Anwendungen." #. Type: note #. Description #: ../minissdpd.templates:1001 msgid "" "MiniSSDP is a daemon used by MiniUPnPc to speed up device discoveries. Due " "to a potential security issue, an out-of-box default configuration can not " "be provided anymore, thus a explicit configuration is required." msgstr "" "MiniSSDP ist ein von MiniUPnPc verwandter Daemon, um die Geräteerkennung zu " "beschleunigen. Aufgrund eines möglichen Sicherheitsproblems kann keine " "vorgefertigte Konfiguration mehr bereitgestellt werden und daher wird eine " "explizite Konfiguration benötigt." #. Type: note #. Description #: ../minissdpd.templates:1001 msgid "" "You can simply ignore this configuration / remove this package. MiniSSDP " "**won't work** with the old default configuration, but MiniUPnPc (and your " "UPnP applications) will still function properly (despite some performance " "loss)." msgstr "" "Sie können diese Konfiguration einfach ignorieren und das Paket entfernen. " "MiniSSDP funktioniert mit der alten Vorgabekonfiguration *nicht*, aber " "MiniUPnPc (und Ihre UPnP-Anwendungen) werden weiterhin korrekt funktionieren " "(wenn auch mit Leistungsverlusten)." #. Type: boolean #. Description #: ../minissdpd.templates:3001 msgid "Start the MiniSSDP daemon automatically?" msgstr "Den MiniSSDP-Daemon automatisch starten?" #. Type: boolean #. Description #: ../minissdpd.templates:3001 msgid "" "Choose this option if the MiniSSDP daemon should start automatically, now " "and at boot time." msgstr "" "Wählen Sie diese Option, falls der Daemon MiniSSDP jetzt und zum " "Systemstartzeitpunkt automatisch starten soll." #. Type: string #. Description #: ../minissdpd.templates:4001 msgid "Interface to listen on for UPnP queries:" msgstr "Schnittstelle, an der auf UPnP-Anfragen gewartet werden soll:" #. Type: string #. Description #: ../minissdpd.templates:4001 msgid "" "The MiniSSDP daemon will listen for requests on one interface, and drop all " "queries that do not come from the local network. Please enter the LAN " "interface or IP address (in CIDR notation) that it should listen on." msgstr "" "Der MiniSSDP-Daemon wird auf einer Schnittstelle auf Anfragen warten und " "alle Anfragen verwerfen, die nicht vom lokalen Netzwerk stammen. Bitte geben " "Sie die LAN-Schnittstelle oder die IP-Adresse (in CIDR-Notation) ein, an der " "auf Anfragen gewarten werden soll." #. Type: string #. Description #: ../minissdpd.templates:4001 msgid "" "Interface name is preferred, and required if you plan to enable IPv6 port " "forwarding." msgstr "" "Der Schnittstellenname wird bevorzugt. Falls Sie vorhaben, eine IPv6-" "Portweiterleitung zu aktivieren, ist er erforderlich." #. Type: boolean #. Description #: ../minissdpd.templates:5001 msgid "Enable IPv6 listening?" msgstr "Auf IPv6-Anfragen warten?" #. Type: boolean #. Description #: ../minissdpd.templates:5001 msgid "" "Please specify whether the MiniSSDP daemon should listen for IPv6 queries." msgstr "" "Bitte geben Sie an, ob der MiniSSDP-Daemon auf IPv6-Anfragen warten soll."
Bug#919424: docker.io: Docker writes GigaBytes of logs leading to out of disk space
Package: docker.io Version: 18.06.1+dfsg1-2 Severity: important Dear Maintainer, running docker leads to gigabytes of logs written per *minute* with all messages being the same: Jan 7 14:49:15 localhost dockerd[391]: time="2019-01-07T14:49:13.726551740+01:00" level=error msg="failed to get event" error="rpc error: code = Internal desc = connection error: desc = \"transport: error while dialing: dial unix:///var/run/docker/containerd/docker-containerd.sock: timeout\"" module=libcontainerd namespace=moby Writing the same message 1,400 times in as single second into three log files simply makes no sense. In messages.1 alone 5,596,864,516 bytes were written in less then 3 minutes. As these log entries flood my disk it renders the package unusable. Please, provide rate limiting. Best regards Heinrich -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-1-arm64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages docker.io depends on: ii adduser 3.118 ii iptables1.8.2-3 ii libc6 2.28-2 ii libdevmapper1.02.1 2:1.02.155-1 ii libltdl72.4.6-6 ii libnspr42:4.20-1 ii libnss3 2:3.41-1 ii libseccomp2 2.3.3-3 ii libsystemd0 240-2 ii lsb-base10.2018112800 ii runc1.0.0~rc5+dfsg1-4 ii tini0.18.0-1 Versions of packages docker.io recommends: ii ca-certificates 20170717 ii cgroupfs-mount 1.4 ii git 1:2.20.1-1 ii needrestart 3.3-2 ii xz-utils 5.2.2-1.3 Versions of packages docker.io suggests: pn aufs-tools pn btrfs-progs ii debootstrap 1.0.112 pn docker-doc ii e2fsprogs1.44.5-1 pn rinse pn xfsprogs pn zfs-fuse | zfsutils -- no debconf information
Bug#919416: debhelper: dh_strip fails when cross-compiling
On Tue, 2019-01-15 at 19:07 +, Niels Thykier wrote: > Control: tags -1 moreinfo > > On Tue, 15 Jan 2019 15:43:31 + Luca Boccassi > wrote: > > Package: debhelper > > Version: 12 > > Severity: normal > > Control: found -1 10.10.6 > > > > Dear Maintainer, > > > > While changing build environment from Debian 9 to Debian 10, a > > package > > that does cross compilation now fails to run dh_strip. > > The debhelper compat level has not changed, it stayed at level 8. > > > > Hi, > > I am sorry to hear it breaks for you. Sorry again for the noise, already closed this a few minutes ago, you are indeed right and it's the build env that was borken. D'oh! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892656: even more tests fail with version 2.0.2
Hi Paolo, On 14-01-2019 08:24, Paolo Greppi wrote: > Hi Paul, seems like npm registry now has is-descriptor 3.0.0: > https://www.npmjs.com/package/is-descriptor > > but even define-property 2.0.2 still wants is-descriptor 1.0.2: > https://github.com/jonschlinkert/define-property/blob/master/package.json#L27 > > Now that we consider acceptable to embed tiny node modules (and is-descriptor > certainly is tiny) we have two options: > 1. (old #3) downgrade node-is-descriptor to 1.0.2 > 2. remove node-is-descriptor 2.0.0 and embed is-descriptor 1.0.2 into > node-define-property I hope you can make the call yourself as I am a mere bystander. But I do want to get rid of RC bugs as they are delaying the release. Paul signature.asc Description: OpenPGP digital signature
Bug#919395: mysql_time.h
ti 15. tammik. 2019 klo 20.27 Georg Richter (ge...@mariadb.com) kirjoitti: > > Hi Otto, > > execpt of mysql.h Connector/C shouldn't provide any other include files > prefixed with "mysql". > find -name "mysql_time.h" in source tree doesn't return positive result. So does this mean that Connector/C is not supposed to be a drop-in replacement for libmariadbclient18 et al? When building the sources of mariadb-10.3 some of these auxillary files are still built, but libmariadbclient.so.18 is not itself built anymore, so shouldn't it still be possible to offer backwards compatibility? How do you suggest this is resolved? Below is the file listing I sent you on December 10th, which I did not get much replies to. Maybe you want to re-review it and comment if something is misplaced? ti 11. jouluk. 2018 klo 10.38 Otto Kekäläinen (o...@debian.org) kirjoitti: > > Below is a comparison of what the binary release of Connector/C has > and what the upstream MariaDB Server Debian repository packages > contain. > > Do you spot any misplaced files or anticipate problems here? > > At least the auth_gssapi is in another package in the server, and > remote.io.so is not included in the server produced libmariadb3.deb at > all. And there are way too many header files shipped in > libmariadb-dev. > > Connector/C binary release from MariaDB.org > > drwxr-xr-x ./lib > drwxr-xr-x ./lib/pkgconfig > -rw-r--r-- ./lib/pkgconfig/libmariadb.pc > drwxr-xr-x ./lib/mariadb > -rw-r--r-- ./lib/mariadb/libmariadb.so.3 > drwxr-xr-x ./lib/mariadb/plugin > -rw-r--r-- ./lib/mariadb/plugin/mysql_clear_password.so > -rw-r--r-- ./lib/mariadb/plugin/sha256_password.so > -rw-r--r-- ./lib/mariadb/plugin/auth_gssapi_client.so > -rw-r--r-- ./lib/mariadb/plugin/remote_io.so > -rw-r--r-- ./lib/mariadb/plugin/dialog.so > lrwxrwxrwx ./lib/mariadb/libmariadb.so -> libmariadb.so.3 > -rw-r--r-- ./lib/mariadb/libmariadbclient.a > drwxr-xr-x ./include > drwxr-xr-x ./include/mariadb > -rw-r--r-- ./include/mariadb/mariadb_ctype.h > -rw-r--r-- ./include/mariadb/ma_list.h > -rw-r--r-- ./include/mariadb/ma_tls.h > -rw-r--r-- ./include/mariadb/mariadb/ma_io.h > -rw-r--r-- ./include/mariadb/errmsg.h > -rw-r--r-- ./include/mariadb/mysqld_error.h > -rw-r--r-- ./include/mariadb/mariadb_dyncol.h > -rw-r--r-- ./include/mariadb/mariadb_com.h > -rw-r--r-- ./include/mariadb/ma_pvio.h > drwxr-xr-x ./include/mariadb/mariadb > -rw-r--r-- ./include/mariadb/mysql.h > drwxr-xr-x ./include/mariadb/mysql > -rw-r--r-- ./include/mariadb/mysql/plugin_auth.h > -rw-r--r-- ./include/mariadb/mysql/client_plugin.h > -rw-r--r-- ./include/mariadb/mysql/plugin_auth_common.h > -rw-r--r-- ./include/mariadb/mariadb_stmt.h > -rw-r--r-- ./include/mariadb/mariadb_version.h > drwxr-xr-x ./bin > -rwxr-xr-x ./bin/mariadb_config > > > MariaDB Server 10.3/10.4 from MariaDB.org > > libmariadb3 > drwxr-xr-x root/root ./ > drwxr-xr-x root/root ./usr/ > drwxr-xr-x root/root ./usr/lib/ > drwxr-xr-x root/root ./usr/lib/mysql/ > drwxr-xr-x root/root ./usr/lib/mysql/plugin/ > -rw-r--r-- root/root ./usr/lib/mysql/plugin/client_ed25519.so > -rw-r--r-- root/root ./usr/lib/mysql/plugin/dialog.so > -rw-r--r-- root/root ./usr/lib/mysql/plugin/mysql_clear_password.so > -rw-r--r-- root/root ./usr/lib/mysql/plugin/sha256_password.so > drwxr-xr-x root/root ./usr/lib/x86_64-linux-gnu/ > -rw-r--r-- root/root ./usr/lib/x86_64-linux-gnu/libmariadb.so.3 > drwxr-xr-x root/root ./usr/share/ > drwxr-xr-x root/root ./usr/share/doc/ > drwxr-xr-x root/root ./usr/share/doc/libmariadb3/ > -rw-r--r-- root/root ./usr/share/doc/libmariadb3/changelog.gz > -rw-r--r-- root/root ./usr/share/doc/libmariadb3/copyright > > libmariadb3-compat > drwxr-xr-x root/root ./ > drwxr-xr-x root/root ./usr/ > drwxr-xr-x root/root ./usr/lib/ > drwxr-xr-x root/root ./usr/lib/x86_64-linux-gnu/ > lrwxrwxrwx root/root ./usr/lib/x86_64-linux-gnu/libmysqlclient.so.19 > lrwxrwxrwx root/root ./usr/lib/x86_64-linux-gnu/libmysqlclient.so.20 > drwxr-xr-x root/root ./usr/share/ > drwxr-xr-x root/root ./usr/share/doc/ > drwxr-xr-x root/root ./usr/share/doc/libmariadb3-compat/ > -rw-r--r-- root/root ./usr/share/doc/libmariadb3-compat/changelog.gz > -rw-r--r-- root/root ./usr/share/doc/libmariadb3-compat/copyright > > libmariadbclient18 > drwxr-xr-x root/root ./ > drwxr-xr-x root/root ./usr/ > drwxr-xr-x root/root ./usr/lib/ > drwxr-xr-x root/root ./usr/lib/x86_64-linux-gnu/ > lrwxrwxrwx root/root ./usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 > drwxr-xr-x root/root ./usr/share/ > drwxr-xr-x root/root ./usr/share/doc/ > drwxr-xr-x root/root ./usr/share/doc/libmariadbclient18/ > -rw-r--r-- root/root ./usr/share/doc/libmariadbclient18/changelog.gz > -rw-r--r-- root/root ./usr/share/doc/libmariadbclient18/copyright > > libmariadb-dev > drwxr-xr-x root/root ./ > drwxr-xr-x root/root ./usr/ > drwxr-xr-x root/root ./usr/bin/ >
Bug#919395: Fwd: Help request: analyze build failures in packages that depend on MariaDB
-- Forwarded message -
From: Sergei Golubchik
Hi, Otto!
On Jan 15, Otto Kekäläinen wrote:
> Hello!
>
> Introducing MariaDB 10.3 (and the libmaraidb3 it includes) changed
> somewhat how packages build compared to MariaB 10.1. In effect there
> are bunch of regressions on those depending packages that need to be
> addressed either in those other programs, or by fixing something in
> MariaDB.
>
> This is quite a big task and I need help. Please check out the latest
> status of this in the bug report
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395
Here are all different errors:
error: 'MYSQL' {aka 'struct st_mysql'} has no member named 'reconnect'
This is not a bug. MYSQL.reconnect was not part of the API, even in 5.5
https://dev.mysql.com/doc/refman/5.5/en/c-api-auto-reconnect.html
error: 'MYSQL_SERVER_VERSION' undeclared
this looks like a bug. MYSQL_SERVER_VERSION is documented here:
https://dev.mysql.com/doc/refman/5.5/en/c-api-server-client-versions.html
error: 'MYSQL_PORT' undeclared here
I couldn't find it documented, but I think it should be fixed too
fatal error: mysql/mysql_time.h: No such file or directory
this doesn't seem to be a part of the API,
one should only include mysql.h
Bug#919421: src:g810-led: FTBFS when /usr/bin/systemd-run isn't available
Package: src:g810-led Version: 0.3.1-1 Severity: serious Justification: ftbfs Dear Maintainer, g810-led FTBFS when /usr/bin/systemd-run isn't available. Regards, The Maintainer -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#919402: devscripts: [salsa] documentation mentions both SALSA_TOKEN and SALSA_PRIVATE_TOKEN
Le 15/01/2019 à 17:12, Daniel Kahn Gillmor a écrit : > Package: devscripts > Version: 2.19.2 > Severity: minor > > > from "man salsa", i see: > > - >If you choose to link another file, it must contain a line with >something like: > > SALSA_PRIVATE_TOKEN= > SALSA_TOKEN= > - > > But nothing else anywhere about SALSA_PRIVATE_TOKEN= -- and i don't > see SALSA_PRIVATE_TOKEN anywhere in > /usr/share/perl5/Devscripts/Salsa/Config.pm. maybe that line should be > removed from the example in the documentation? > > Thanks for your work on devscripts! > >--dkg Hello, this feature allows one to use another file that contains one of this fields. This permits compatibility with dpt(1) tool (from pkg-perl-tools) which uses a ~/.dpt.conf that contains DPT_SALSA_PRIVATE_TOKEN= So this is not a bug ;-). Maybe documentation isn't clear on this. Cheers, Xavier
Bug#919420: 389-ds-base: postinst maintainer script depends on 389-ds-base-legacy-tools (setup-ds)
Package: 389-ds-base Version: 1.4.0.20-2 Severity: normal Dear Maintainer, during upgrade from previous version od 389-ds-base the postinst script failed with 127 exit code. The utility setup-ds is moved to a new package 389-ds-base-legacy-tools now and postinst maintainer script needs it. Regards Thanks -- Zito -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages 389-ds-base depends on: ii 389-ds-base-libs 1.4.0.20-2 ii acl 2.2.52-3+b1 ii adduser 3.118 ii debconf [debconf-2.0]1.5.69 ii ldap-utils 2.4.47+dfsg-2 ii libc62.28-5 ii libcrack22.9.6-2 ii libdb5.3 5.3.28+dfsg1-0.2 ii libevent-2.1-6 2.1.8-stable-4 ii libicu63 63.1-5 ii libldap-2.4-22.4.47+dfsg-2 ii libnspr4 2:4.20-1 ii libnss3 2:3.41-1 ii libpam0g 1.1.8-4 ii libpci3 1:3.5.2-1 ii libperl4-corelibs-perl 0.004-1 ii libsasl2-2 2.1.27~rc8-1 ii libsasl2-modules-gssapi-mit 2.1.27~rc8-1 ii libsensors5 1:3.5.0-3 ii libsnmp305.7.3+dfsg-5 ii libssl1.11.1.1a-1 ii libsystemd0 240-4 ii libwrap0 7.6.q-27 ii perl 5.28.1-3 ii python 2.7.15-3 ii python3 3.7.1-3 ii python3-lib389 1.4.0.20-2 ii python3-selinux 2.8-1+b1 ii python3-semanage 2.8-2 ii python3-sepolicy 2.8-3 ii systemd 240-4 389-ds-base recommends no packages. 389-ds-base suggests no packages. -- Configuration Files: /etc/dirsrv/config/certmap.conf [Errno 13] Permission denied: '/etc/dirsrv/config/certmap.conf' /etc/dirsrv/config/ldap-agent.conf [Errno 13] Permission denied: '/etc/dirsrv/config/ldap-agent.conf' /etc/dirsrv/config/slapd-collations.conf [Errno 13] Permission denied: '/etc/dirsrv/config/slapd-collations.conf' /etc/dirsrv/config/template-initconfig [Errno 13] Permission denied: '/etc/dirsrv/config/template-initconfig' /etc/dirsrv/schema/99user.ldif [Errno 13] Permission denied: '/etc/dirsrv/schema/99user.ldif' -- no debconf information
Bug#887465: Please update to new upstream version
Package: guacamole Version: 0.9.9+dfsg-1 Followup-For: Bug #887465 Dear Maintainer, A newer version 0.9.14 was released on 2018-01-18: http://guacamole.apache.org/releases/1.0.0/ It introduces important changes, see: http://guacamole.apache.org/releases/1.0.0/#deprecation--compatibility-notes
