Bug#931255: marked as done (regexps used seems to be incompatible with libpcre2 10.32)
Your message dated Sun, 14 Jul 2019 06:49:19 +
with message-id
and subject line Bug#931255: fixed in php-horde-text-filter 2.3.6-1
has caused the Debian Bug report #931255,
regarding regexps used seems to be incompatible with libpcre2 10.32
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
931255: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931255
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: php-horde-text-filter
Version: 2.3.5-3
Severity: grave
Tags: patch
On buster with PHP 7.3 the tabs used on the horde settings webpage are empty
instead of the usual General/Database etc.
With PHP 7.2 from packages.surey.org they work fine. They are linked against
libpcre3 2:8.42
Log says:
WARN: HORDE [horde] PHP ERROR: preg_replace_callback(): Compilation failed:
invalid range in character class at offset 68 [pid 21655 on line 99 of
"/usr/share/php/Horde/Text/Filter.php"]
Problem seems to be that it doestn't like anymore ranges like [\w-+]. The
hyphen needs to be first
Attached patch fixes it for me.
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages php-horde-text-filter depends on:
ii php-common 2:69
ii php-horde-exception 2.0.8-4
ii php-horde-idna 1.1.1-3
ii php-horde-util 2.5.8-3
Versions of packages php-horde-text-filter recommends:
pn php-horde-test
ii php-horde-text-flowed 2.0.3-5
ii php-horde-translation 2.2.2-3
pn php-tidy
Versions of packages php-horde-text-filter suggests:
pn php-horde-text-filter-jsmin
-- no debconf information
diff --git a/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php
b/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php
index ad760b9..929d829 100644
--- a/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php
+++ b/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php
@@ -61,7 +61,7 @@ class Horde_Text_Filter_Emails extends Horde_Text_Filter_Base
((?(1)\s*\]))
|
# Version 2 Pattern 9 and 10: simple email addresses.
-(^|\s|<|<|\[)([\w-+.=]+@[-A-Z0-9.]*[A-Z0-9])
+(^|\s|<|<|\[)([-\w+.=]+@[-A-Z0-9.]*[A-Z0-9])
# Pattern 11 to 13: Optional parameters
((\?)([^\s"<]*[\w+#?\/&=]))?
# Pattern 14: Optional closing bracket
diff --git a/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Linkurls.php
b/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Linkurls.php
index a88dc12..72e19ec 100644
--- a/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Linkurls.php
+++ b/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Linkurls.php
@@ -86,7 +86,7 @@ class Horde_Text_Filter_Linkurls extends
Horde_Text_Filter_Base
(?:\b|^)
( # Capture 1: entire matched URL
(
- (?:[a-z][\w-+]{0,19})?:/{1,3} # URL protocol and colon followed by 1-3
+ (?:[a-z][-\w+]{0,19})?:/{1,3} # URL protocol and colon followed by 1-3
# slashes, or just colon and slashes (://)
| # - or -
(?--- End Message ---
--- Begin Message ---
Source: php-horde-text-filter
Source-Version: 2.3.6-1
We believe that the bug you reported is fixed in the latest version of
php-horde-text-filter, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 931...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Mathieu Parent (supplier of updated php-horde-text-filter
package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 14 Jul 2019 08:19:50 +0200
Source: php-horde-text-filter
Binary: php-horde-text-filter
Architecture: source all
Version: 2.3.6-1
Distribution: unstable
Urgency: medium
Maintainer: Horde Maintainers
Changed-By: Mathieu Parent
Description:
php-horde-text-filter -
Closes: 931255
Changes:
php-horde-text-filter (2.3.6-1) unstable; urgency=medium
Processed: control
Processing commands for cont...@bugs.debian.org: > reassign 931778 emacs-gtk Bug #931778 [emacs] emacs: Emacs crash when one particual char is shown Bug reassigned from package 'emacs' to 'emacs-gtk'. No longer marked as found in versions emacs/1:26.1+1-3.2. Ignoring request to alter fixed versions of bug #931778 to the same values previously set > forcemerge 929567 931778 Bug #929567 [emacs-gtk] libgtk-3-0:amd64: Emacs constantly crashes on startup with "X protocol error: BadLength..." Bug #931778 [emacs-gtk] emacs: Emacs crash when one particual char is shown Set Bug forwarded-to-address to 'https://debbugs.gnu.org/30045'. Severity set to 'grave' from 'normal' Marked as found in versions emacs/1:25.2+1-11 and emacs/1:26.1+1-3.2. Added tag(s) fixed-upstream, pending, patch, and upstream. Merged 929567 931778 > End of message, stopping processing here. Please contact me if you need assistance. -- 929567: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929567 931778: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931778 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#932015: wireguard-dkms: Wireguard dkms module build fails with gcc-8 on arm for 4.19.0-5-armmp-lpae kernel
Package: wireguard-dkms Version: 0.0.20190702-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, * What led up to the situation? Upgrading to buster and to kernel 4.19.0-5-armmp-lpae * What exactly did you do (or not do) that was effective (or ineffective)? dkms build -m wireguard -v 0.0.20190702 * What was the outcome of this action? Kernel preparation unnecessary for this kernel. Skipping... Building module: cleaning build area... make -j2 KERNELRELEASE=4.19.0-5-armmp-lpae -C /lib/modules/4.19.0-5-armmp-lpae/build M=/var/lib/dkms/wireguard/0.0.20190702/build(bad exit status: 2) Error! Bad return status for module build on kernel: 4.19.0-5-armmp-lpae (armv7l) Consult /var/lib/dkms/wireguard/0.0.20190702/build/make.log for more information. cat /var/lib/dkms/wireguard/0.0.20190702/build/make.log DKMS make.log for wireguard-0.0.20190702 for kernel 4.19.0-5-armmp-lpae (armv7l) Sun 14 Jul 2019 02:23:42 AM CEST make: Entering directory '/usr/src/linux-headers-4.19.0-5-armmp-lpae' gcc-8: internal compiler error: Segmentation fault signal terminated program cc1 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gcc-8: internal compiler error: Segmentation fault signal terminated program cc1 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Segmentation fault CC [M] /var/lib/dkms/wireguard/0.0.20190702/build/main.o CC [M] /var/lib/dkms/wireguard/0.0.20190702/build/noise.o gcc-8: internal compiler error: Segmentation fault signal terminated program cc1 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[3]: *** [/usr/src/linux-headers-4.19.0-5-common/scripts/Makefile.build:308: /var/lib/dkms/wireguard/0.0.20190702/build/main.o] Error 4 make[3]: *** Waiting for unfinished jobs gcc-8: internal compiler error: Segmentation fault signal terminated program cc1 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[3]: *** [/usr/src/linux-headers-4.19.0-5-common/scripts/Makefile.build:308: /var/lib/dkms/wireguard/0.0.20190702/build/noise.o] Error 4 make[2]: *** [/usr/src/linux-headers-4.19.0-5-common/Makefile:1539: _module_/var/lib/dkms/wireguard/0.0.20190702/build] Error 2 make[1]: *** [Makefile:146: sub-make] Error 2 make: *** [Makefile:8: all] Error 2 make: Leaving directory '/usr/src/linux-headers-4.19.0-5-armmp-lpae' * What outcome did you expect instead? module should compile -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable'), (90, 'unstable') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-5-armmp-lpae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireguard-dkms depends on: ii dkms 2.6.1-4 Versions of packages wireguard-dkms recommends: ii wireguard-tools 0.0.20190702-1 wireguard-dkms suggests no packages. -- no debconf information
Bug#927921: marked as done (Modeset: Invalid argument. No GUI.)
Your message dated Sun, 14 Jul 2019 00:02:54 +0100 with message-id <51f696d461e6e0ffcc4642b456b0af83da3d251a.ca...@decadent.org.uk> and subject line Re: Modeset: Invalid argument. No GUI. has caused the Debian Bug report #927921, regarding Modeset: Invalid argument. No GUI. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 927921: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927921 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:linux Version: 4.19.28-2 Severity: important Dear maintainer, I have two kernels installed: 4.19.0-2 and 4.19.0-4 (both amd64 from buster). The described problems happen only when 4.19.0-4 is booted. Basically, any (Xorg) GUI start fails, and /var/log/Xorg.0.log contains eg. this line: (EE) modeset(0): Failed to set mode: Invalid argument I have not much ideas what additional information could help, please tell me anything you'd like to know. Note that I have installed bumblebee and nvidia driver, but run intel driver usually. Completely removing bumblebee and anything nvidia-related doesn't change the situation. Thank you -- Package-specific info: ** Version: Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15) ** Command line: BOOT_IMAGE=/vmlinuz-4.19.0-4-amd64 root=/dev/mapper/sda4_crypt ro rootflags=subvol=main quiet ** Tainted: OE (12288) * Out-of-tree module has been loaded. * Unsigned module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Dell Inc. product_name: Precision 7520 product_version: chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: 1.13.0 board_vendor: Dell Inc. board_name: 09Y5WW board_version: A00 ** Loaded modules: pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) fuse i2c_dev cmac bnep bbswitch(OE) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic nls_ascii nls_cp437 vfat fat ext4 mbcache jbd2 fscrypto ecb ip6t_REJECT nf_reject_ipv6 cdc_mbim arc4 cdc_wdm cdc_ncm usbnet qcserial usb_wwan mii usbserial xt_hl ip6_tables ip6t_rt ipt_REJECT nf_reject_ipv4 dell_rbtn mei_wdt dell_wmi wmi_bmof mxm_wmi intel_rapl x86_pkg_temp_thermal intel_powerclamp ppdev coretemp nft_limit dell_laptop dell_smbios kvm_intel dell_wmi_descriptor iwlmvm btusb btrtl dcdbas btbcm kvm btintel dell_smm_hwmon irqbypass mac80211 sg bluetooth intel_cstate xt_limit drbg joydev evdev ansi_cprng serio_raw xt_addrtype xt_tcpudp ecdh_generic efi_pstore snd_hda_intel iwlwifi intel_uncore crc16 intel_rapl_perf snd_hda_codec i915 xt_conntrack snd_hda_core nft_compat rtsx_pci_ms efivars snd_hwdep cfg80211 snd_pcm iTCO_wdt memstick iTCO_vendor_support snd_timer snd soundcore rfkill drm_kms_helper idma64 nft_counter drm mei_me mei processor_thermal_device parport_pc ie31200_edac i2c_algo_bit intel_soc_dts_iosf parport intel_pch_thermal battery int3403_thermal dell_smo8800 wmi intel_hid int3400_thermal int3402_thermal video sparse_keymap acpi_thermal_rel int340x_thermal_zone pcc_cpufreq acpi_pad ac button nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink efivarfs ip_tables x_tables autofs4 btrfs xor zstd_decompress zstd_compress xxhash raid6_pq libcrc32c crc32c_generic algif_skcipher af_alg sr_mod cdrom uas usb_storage usbhid dm_crypt dm_mod sd_mod hid_alps hid_generic crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc rtsx_pci_sdmmc mmc_core ahci xhci_pci libahci xhci_hcd aesni_intel aes_x86_64 libata crypto_simd psmouse cryptd e1000e glue_helper usbcore scsi_mod i2c_hid i2c_i801 rtsx_pci hid intel_lpss_pci intel_lpss usb_common thermal ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:5918] (rev 05) Subsystem: Dell Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [1028:07b0] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ie31200_edac Kernel modules: ie31200_edac 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 05) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B
Bug#919348: is it still unfit for Bullseye?
On Sat, Jul 13, 2019 at 04:40:31PM +0200, Yves-Alexis Perez wrote: > On Thu, 2019-07-11 at 10:34 +0200, Adam Borowski wrote: > > So... is there any reason to not let xfce4-screensaver go to Bullseye? > > Any day that a human being suffers from light-locker is a bad day. > > Hi Adam, > > could you please refrain from such statements? Some people, volunteers mostly, > have taken time to actual write that software, package it etc. I find this > rude, to be honest. Well, there is no problem in software X having bugs -- any non-trivial program is buggy, and especially a novel approach like that tried by light-locker is bound to run into problems. But, pushing a thoroughly buggy piece of code, that's in my opinion not fit for release, as the default for a major desktop environment, and the only allowed by that DE's task, is not a good idea. Apologies for expressing myself too emphatically -- but with my (indeed rude) wording aside, the point stands. > > If you're afraid about yet-unknown bugs, more exposure to users early > > in the release cycle would be a good idea. > > For a locker screen, I'd really like someone to take a look at the code (even > if only the differences with gnome-screensaver). I'm afraid I have no experience at all with X coding, all I can offer is testing as a mere user. But I do run a diverse set of machines, ranging four archs (amd64 i386 x32 arm64), ages (2004-2018), types (desktops, SoC, laptops), GPUs, rc systems (sysv-rc, openrc -- with one notable omission :p), etc -- thus I believe my good opinion about xfce4-screensaver carries some weight. > The light-locker code in the process which does the locking is actually > quite simple (no complicated UI, no screensaver at all etc.) Yet the way it offloads the task to lightdm is fragile. > > On the other hand, light-locker suffers from a multitude of known > > problems (see the recent debian-devel thread), and you hate the third > > alternative, xscreensaver > > Actually no-one seems to know which package(s) is buggy. My gut feeling is > that the drivers handle vt-switches and backlight off badly, not a bug in > light-locker. But again no-one seems interested to find out. This particular problem may be indeed hard to track, but none of the alternatives (xscreensaver, xfce4-screensaver) suffer from it. Nor from the others (no visual feedback that you're logged in, pointless vt switches, not working when started not from a DM, ... [I haven't retried in a while, some of those might have been fixed]). Unless you have a particular reason to stick with light-locker, fixing it may be a waste of your time. > If you volunteer, I welcome any help on this, whether by finding the issues > with the light-locker/lightdm/DDX stack or actually making sure there's no > security issue in xfce4-screensaver. I'm afraid I have neither the tuits nor expertise to help with fixing or dedicated QA here, just testing as a part of using the product of your efforts in my daily work and hacking. And there's a reason I annoy you rather than Mate, KDE, *shudder* Gnome, or Gnustep folks :) But, in this case, I am very excited that you have a replacement for something I find to be hopelessly buggy -- and the replacement seems near-perfect. Thus, if you switch, you save a lot of time, and any bit of time you save is a bit of time you can spend catering to my other whims. :) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned ⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem? ⠈⠳⣄
Bug#902828: pgpdump: autopkgtest regression: sh: 0: Can't open debian/test
control: tags -1 pending Hello, since the package is collaboratively maintained, I went ahead and committed the changes on git, and uploaded in deferred/7. Feel free to delete or speed it up if possible, thanks Gianfranco
Processed: Re: pgpdump: autopkgtest regression: sh: 0: Can't open debian/test
Processing control commands: > tags -1 pending Bug #902828 [src:pgpdump] pgpdump: autopkgtest regression: sh: 0: Can't open debian/test Added tag(s) pending. -- 902828: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902828 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#932000: libgssapi-krb5-2: gss_krb5int_set_allowable_enctypes breaks NFSv4 after removal of deprecated DES enctypes in 1.17-4
I think gss_krb5int_set_allowable_enctypes() should filter out invalid enctypes, and only fail if no enctypes remain after filtering. The current logic would also fail if the kernel supported an enctype which libkrb5 did not (e.g. if the kernel gained support for the aes-sha2 enctypes, and someone upgraded to a new kernel on a system with krb5-1.14 or previous).
Processed: ruby-mini-magick: diff for NMU version 4.9.2-1.1
Processing control commands: > tags 931932 + patch Bug #931932 [ruby-mini-magick] CVE-2019-13574 Added tag(s) patch. > tags 931932 + pending Bug #931932 [ruby-mini-magick] CVE-2019-13574 Added tag(s) pending. -- 931932: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931932 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931932: ruby-mini-magick: diff for NMU version 4.9.2-1.1
Control: tags 931932 + patch
Control: tags 931932 + pending
Dear maintainer,
I've prepared an NMU for ruby-mini-magick (versioned as 4.9.2-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
Regards,
Salvatore
diff -Nru ruby-mini-magick-4.9.2/debian/changelog ruby-mini-magick-4.9.2/debian/changelog
--- ruby-mini-magick-4.9.2/debian/changelog 2018-12-27 12:36:03.0 +0100
+++ ruby-mini-magick-4.9.2/debian/changelog 2019-07-13 21:51:59.0 +0200
@@ -1,3 +1,10 @@
+ruby-mini-magick (4.9.2-1.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Don't allow remote shell execution (CVE-2019-13574) (Closes: #931932)
+
+ -- Salvatore Bonaccorso Sat, 13 Jul 2019 21:51:59 +0200
+
ruby-mini-magick (4.9.2-1) unstable; urgency=medium
* Team upload
diff -Nru ruby-mini-magick-4.9.2/debian/patches/Don-t-allow-remote-shell-execution.patch ruby-mini-magick-4.9.2/debian/patches/Don-t-allow-remote-shell-execution.patch
--- ruby-mini-magick-4.9.2/debian/patches/Don-t-allow-remote-shell-execution.patch 1970-01-01 01:00:00.0 +0100
+++ ruby-mini-magick-4.9.2/debian/patches/Don-t-allow-remote-shell-execution.patch 2019-07-12 17:30:44.0 +0200
@@ -0,0 +1,71 @@
+From: =?UTF-8?q?Janko=20Marohni=C4=87?=
+Date: Sun, 26 May 2019 17:30:14 +0200
+Subject: Don't allow remote shell execution
+Origin: https://github.com/minimagick/minimagick/commit/4cd5081e58810d3394d27a67219e8e4e0445d851
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-13574
+Bug-Debian: https://bugs.debian.org/931932
+
+Kernel#open accepts a string of format "| " which
+executes the specified shell command and otherwise presumably acts as
+IO.popen. The open-uri standard library overrides Kernel#open to also
+accept URLs.
+
+However, the overridden Kernel#open just delegates to URI#open, so we
+switch to using that directly and avoid the remote shell execution
+vulnerability. For files we just use File.open, which should have the
+same behaviour as Kernel#open.
+---
+ lib/mini_magick/image.rb | 14 ++
+ spec/lib/mini_magick/image_spec.rb | 8
+ 2 files changed, 14 insertions(+), 8 deletions(-)
+
+diff --git a/lib/mini_magick/image.rb b/lib/mini_magick/image.rb
+index a1f47c6dd67f..0ac478026dda 100644
+--- a/lib/mini_magick/image.rb
b/lib/mini_magick/image.rb
+@@ -82,17 +82,15 @@ module MiniMagick
+ def self.open(path_or_url, ext = nil, options = {})
+ options, ext = ext, nil if ext.is_a?(Hash)
+
+- ext ||=
+-if File.exist?(path_or_url)
+- File.extname(path_or_url)
+-else
+- File.extname(URI(path_or_url).path)
+-end
++ uri = URI(path_or_url.to_s)
+
++ ext ||= File.extname(uri.path)
+ ext.sub!(/:.*/, '') # hack for filenames or URLs that include a colon
+
+- Kernel.open(path_or_url, "rb", options) do |file|
+-read(file, ext)
++ if uri.is_a?(URI::HTTP) || uri.is_a?(URI::FTP)
++uri.open(options) { |file| read(file, ext) }
++ else
++File.open(uri.to_s, "rb", options) { |file| read(file, ext) }
+ end
+ end
+
+diff --git a/spec/lib/mini_magick/image_spec.rb b/spec/lib/mini_magick/image_spec.rb
+index 192d834082dc..00f9cb060a40 100644
+--- a/spec/lib/mini_magick/image_spec.rb
b/spec/lib/mini_magick/image_spec.rb
+@@ -76,6 +76,14 @@ require "webmock/rspec"
+ expect(File.extname(image.path)).to eq ".jpg"
+ end
+
++it "doesn't allow remote shell execution" do
++ expect {
++described_class.open("| touch file.txt") # Kernel#open accepts this
++ }.to raise_error(URI::InvalidURIError)
++
++ expect(File.exist?("file.txt")).to eq(false)
++end
++
+ it "accepts open-uri options" do
+ stub_request(:get, "http://example.com/image.jpg";)
+ .with(headers: {"Foo" => "Bar"})
+--
+2.22.0
+
diff -Nru ruby-mini-magick-4.9.2/debian/patches/series ruby-mini-magick-4.9.2/debian/patches/series
--- ruby-mini-magick-4.9.2/debian/patches/series 2018-12-27 12:36:03.0 +0100
+++ ruby-mini-magick-4.9.2/debian/patches/series 2019-07-12 17:30:49.0 +0200
@@ -2,3 +2,4 @@
remove-rubygems
remove-deprecated-test.patch
imagemagick-json-change.patch
+Don-t-allow-remote-shell-execution.patch
Processed: pysolfc issues in upstream bug tracker
Processing commands for cont...@bugs.debian.org: > forwarded 781663 https://github.com/shlomif/PySolFC/issues/78 Bug #781663 [pysolfc] pysolfc: Does not start when no sound card is available, even when sound is disabled Set Bug forwarded-to-address to 'https://github.com/shlomif/PySolFC/issues/78'. > forwarded 931851 https://github.com/shlomif/PySolFC/issues/108 Bug #931851 [pysolfc] pysolfc: pythonfc fails to start since python upgrades, new version with fix available upstream Set Bug forwarded-to-address to 'https://github.com/shlomif/PySolFC/issues/108'. > End of message, stopping processing here. Please contact me if you need assistance. -- 781663: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781663 931851: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931851 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931781: rsync: Buster hangs when rsyncing large (400M) files over ssh. Same hardware works OK with Stretch
Paul Slootman kirjoitti 13.7.2019 14:49: Seeing the error messages you are getting, it sounds like there is a memory shortage, possibly the vmware ballooning driver is failing to provide sufficient memory in time. It does not look like rsync is to blame for your problems. Paul Indeed, I have investigated this further. The issues seems to be somehow related to the combination of the megaraid_sas driver, RAID controller fw and the linux kernel I am using. I have now repeated this issue on both Debian 10 and Ubuntu 18.04. I will continue the examination and report to the correct forum. I apologize for the erroneous bug report on rsync. This bug can be closed. Antti
Processed: Re: Bug#932000: libgssapi-krb5-2: gss_krb5int_set_allowable_enctypes breaks NFSv4 after removal of deprecated DES enctypes in 1.17-4
Processing control commands: > severity -1 grave Bug #932000 [libgssapi-krb5-2] libgssapi-krb5-2: gss_krb5int_set_allowable_enctypes breaks NFSv4 after removal of deprecated DES enctypes in 1.17-4 Severity set to 'grave' from 'important' -- 932000: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932000 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#919348: is it still unfit for Bullseye?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2019-07-11 at 10:34 +0200, Adam Borowski wrote: > So... is there any reason to not let xfce4-screensaver go to Bullseye? > Any day that a human being suffers from light-locker is a bad day. Hi Adam, could you please refrain from such statements? Some people, volunteers mostly, have taken time to actual write that software, package it etc. I find this rude, to be honest. > > If you're afraid about yet-unknown bugs, more exposure to users early > in the release cycle would be a good idea. For a locker screen, I'd really like someone to take a look at the code (even if only the differences with gnome-screensaver). The light-locker code in the process which does the locking is actually quite simple (no complicated UI, no screensaver at all etc.) > On the other hand, > light-locker suffers from a multitude of known problems (see the recent > debian-devel thread), and you hate the third alternative, xscreensaver Actually no-one seems to know which package(s) is buggy. My gut feeling is that the drivers handle vt-switches and backlight off badly, not a bug in light-locker. But again no-one seems interested to find out. If you volunteer, I welcome any help on this, whether by finding the issues with the light-locker/lightdm/DDX stack or actually making sure there's no security issue in xfce4-screensaver. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0p7V8ACgkQ3rYcyPpX RFukHgf/ZnnS9kS/YG0jO2hB1ztalDxZ6UeQqgCGBiJXnlha228HtDD5Xku2noUZ 1Ke/pGAzULmugjbbhHGc8AmbgIJGgRP+WdjCy9aaVghLvVPdW3y31hh2GSQgUOTV aqFT9t0PqoLH/71UwmON0WT4/6BUlcm8dcmpZ80lv2Z1nd1nCuVJ/52sM8NY342m DwBU7NB4d17liKTmLp4opH5+JVA77DbJkXx7SsJBI5Lkkp/71sv8FLQv+nNSGSH5 7rf8xg1JLaMflVdcmk2IPYgYlkZT4pfJWgnma6onz7cQURjco8sZ0Iinzei4E5xC K3Ay7gY7+aYNAewN2AgT04euMHwWOg== =holV -END PGP SIGNATURE-
Bug#929439: marked as done (minetest-mod-pipeworks: Missing dependency)
Your message dated Sat, 13 Jul 2019 16:08:30 +0200 with message-id and subject line Fixed in 20190607.1-1 has caused the Debian Bug report #929439, regarding minetest-mod-pipeworks: Missing dependency to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 929439: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929439 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: minetest-mod-pipeworks Version: 20190430-1 Severity: serious Justification: Policy 3.5. Dependencies Dear Maintainer, Package lacks a dependency on "basic_materials" (minetest-mod-basic-materials). -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages minetest-mod-pipeworks depends on: ii minetest 0.4.17.1+repack-1+b1 Versions of packages minetest-mod-pipeworks recommends: ii minetest-mod-mesecons 1:1.2.1-1 minetest-mod-pipeworks suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Hi, I forgot to mark it in the changelog, but that bug report was fixed by last upload! Cheers, JP--- End Message ---
Bug#931985: file: Experimental file breaks package creation at dh_shlibdeps stage due to file command
On Sat, 13 Jul 2019 14:33:00 +0200 Christoph Biedl wrote: > Control: tags 931985 pending > > So here's the story: The dh_shlibdepends program runs under fakeroot, > and libfakeroot will be loaded be the file binary as well. Nothing new. > > Enter seccomp: The version of file in experimental is the first one to > have seccomp support enabled. The syscalls used by libffakeroot are not > whitelisted, so msgsend or getpid case program abort. You should have > seen according messages in the kernel log as well. > > A sane solution will take time. For the moment the only sane choice will > do to re-disable seccomp support. > > Christoph Is it possible to patch the code to skip the seccomp support only under fakeroot? While we are slowly reducing the number of packages relying on fakeroot, it will probably take a decade or more to be completely free from it. But I think it would be unfortunate not to have the seccomp filtering until then. Thanks, ~Niels
Bug#931985: file: Experimental file breaks package creation at dh_shlibdeps stage due to file command
Niels Thykier wrote... > Is it possible to patch the code to skip the seccomp support only under > fakeroot? While we are slowly reducing the number of packages relying > on fakeroot, it will probably take a decade or more to be completely > free from it. But I think it would be unfortunate not to have the > seccomp filtering until then. A quicker solution was to add the --no-sandbox option to any file invocation. But right now that option triggers an error if file was built without seccomp support - but seccomp is not available on all architectures. The right place to deal with this is improving file's tunables wrt seccomp support, working on that. I'll get back to you when there are results. Christoph signature.asc Description: PGP signature
Bug#931881: marked as done (diffoscope: undeclared versioned dependency on file)
Your message dated Sat, 13 Jul 2019 13:50:10 +
with message-id
and subject line Bug#931881: fixed in diffoscope 118
has caused the Debian Bug report #931881,
regarding diffoscope: undeclared versioned dependency on file
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
931881: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931881
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: diffoscope
Version: 117
Severity: serious
Justification: autopkgtest failures and runtime failures
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan
Dear maintainers,
diffoscope 117 is not migratable to testing because its autopkgtests are
failing, due to runtime errors complaining about a wrong version of the
'file' command:
[...]
=== FAILURES ===
_ test_text_proper_indentation _
args2 = (), kwargs2 = {}
def inner(*args2, **kwargs2):
if args[0]: # i.e. the condition of the skipif() is True
> return pytest.fail(msg)
E Failed: requires file >= 5.37 (5.35 detected)
(DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS=1)
args = (True,)
args2 = ()
kwargs2= {}
msg= ('requires file >= 5.37 (5.35 detected) '
'(DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS=1)')
tests/utils/tools.py:77: Failed
[...]
(https://ci.debian.net/packages/d/diffoscope/testing/amd64/)
file 5.37 is only present in Debian experimental, and the diffoscope package
declares no dependency on file >= 5.37.
At the very least, it seems this should be a versioned test dep on file (>=
5.37), but perhaps it should also be a versioned runtime dependency. I
haven't looked to see what the impact is of the wrong version of 'file' when
DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS is not set.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Source: diffoscope
Source-Version: 118
We believe that the bug you reported is fixed in the latest version of
diffoscope, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 931...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Chris Lamb (supplier of updated diffoscope package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sat, 13 Jul 2019 10:23:29 -0300
Source: diffoscope
Binary: diffoscope
Architecture: source all
Version: 118
Distribution: unstable
Urgency: medium
Maintainer: Reproducible builds folks
Changed-By: Chris Lamb
Description:
diffoscope - in-depth comparison of files, archives, and directories
Closes: 931881
Changes:
diffoscope (118) unstable; urgency=medium
.
* Don't fail in autopkgtests when, for example, we do not have sufficiently
newer or older version of file. (Closes: #931881)
* Also include python3-tlsh in test dependencies.
* Tidy handling of DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS:
- Merge two previously-overlapping environment variables.
- Use repr(..)-style output when printing test status.
- Add some explicit return values to appease pylint.
Checksums-Sha1:
884fda29574f5c3b6f9b5ebe62c7500d608acc08 4660 diffoscope_118.dsc
f8d75b50d51b8b63117a2baef2b5ad7e2c7a8ab2 1118532 diffoscope_118.tar.xz
1ce2ea7292cde0574773966ce71b227a68a419b6 131316 diffoscope_118_all.deb
fa889c2d3790016b2b6e13d3d5ea8cfc33745b12 26267 diffoscope_118_amd64.buildinfo
Checksums-Sha256:
c2bd53c5427e7b62fea26b2ce5f30cca846c372f9a7710f818e8388c1a37113d 4660
diffoscope_118.dsc
59f1a3155be52b0a7b4f055618e89674621e4c9d4de6dc1d19302da35fd0058a 1118532
diffoscope_118.tar.xz
e3798b149b27b77a24920338f943c31e9f29d8fd3f5526d832820517e7f394b9 131316
diffoscope_118_all.deb
56dae6a5acd1f64d75653af0578d77c1c5b7f18705785f7a40cd5f821200e665 26267
diffoscope_118_amd64.buildinfo
Files:
15c8dd13d6915f8
Bug#931932: CVE-2019-13574
Hi, On Fri, Jul 12, 2019 at 03:58:05PM +0200, Moritz Muehlenhoff wrote: > Package: ruby-mini-magick > Severity: grave > Tags: security > > Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13574 FTR, for stretch and buster adressed this in DSA 4481-1. For sid/bullseye might be sensible to just move to 4.9.4. Regards, Salvatore
Processed: python-xarray: needs source-only upload
Processing commands for cont...@bugs.debian.org: > retitle 931971 python-xarray: needs source-only upload Bug #931971 [src:python-xarray] python-xarray: autopkgtest failure block netcdf4-python migration Changed Bug title to 'python-xarray: needs source-only upload' from 'python-xarray: autopkgtest failure block netcdf4-python migration'. > reassign 931971 src:python-xarray 0.12.1-1 Bug #931971 [src:python-xarray] python-xarray: needs source-only upload Ignoring request to reassign bug #931971 to the same package Bug #931971 [src:python-xarray] python-xarray: needs source-only upload Marked as found in versions python-xarray/0.12.1-1; no longer marked as found in versions python-xarray/0.11.3-2. > thanks Stopping processing here. Please contact me if you need assistance. -- 931971: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931971 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931971: python-xarray: autopkgtest failure block netcdf4-python migration
On Sat, 13 Jul 2019 at 12:10, Graham Inggs wrote: > So I think netcdf4-python needs to add a: > > Breaks: python-xarray (<< 0.12.1-1) > > or so, to ensure the correct versions are tested together. Actually, a Breaks is not needed since these packages do need to migrate together, python-xarray can migrate before netcdf4-python and as per its excuses [1], the only blocker here is: Not built on buildd: arch all binaries uploaded by mckinstry So python-xarray needs a source-only upload before it can migrate. [1] https://qa.debian.org/excuses.php?package=python-xarray
Processed: Re: Bug#931985: file: Experimental file breaks package creation at dh_shlibdeps stage due to file command
Processing control commands: > tags 931985 pending Bug #931985 [file] file: Experimental file breaks package creation at dh_shlibdeps stage due to file command Added tag(s) pending. -- 931985: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931985 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931985: file: Experimental file breaks package creation at dh_shlibdeps stage due to file command
Control: tags 931985 pending So here's the story: The dh_shlibdepends program runs under fakeroot, and libfakeroot will be loaded be the file binary as well. Nothing new. Enter seccomp: The version of file in experimental is the first one to have seccomp support enabled. The syscalls used by libffakeroot are not whitelisted, so msgsend or getpid case program abort. You should have seen according messages in the kernel log as well. A sane solution will take time. For the moment the only sane choice will do to re-disable seccomp support. Christoph signature.asc Description: PGP signature
Bug#926551: marked as done (libykpiv1: Security issues in versions prior to 1.7.0)
Your message dated Sat, 13 Jul 2019 12:20:04 + with message-id and subject line Bug#926551: fixed in yubico-piv-tool 1.7.0-1 has caused the Debian Bug report #926551, regarding libykpiv1: Security issues in versions prior to 1.7.0 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 926551: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926551 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libykpiv1 Version: 1.6.2-1 Severity: serious Tags: security buster sid upstream fixed-upstream pending Justification: Security issue Hi, Yubico released a new version of libykpiv, mentionning “security fixes” in the NEWS file, but without publishing a new security advisory. I believe this refers to the following issues (quoting changelog entries): * Memory unsafety: * lib/internal.h, lib/ykpiv.c: lib: tlv length buffer checks * lib/internal.h, lib/util.c: lib: correct overflow checks in _write_certificate * lib/util.c, lib/ykpiv.c: lib: resolves potential reads of uninitialized data * Correctly erasing secrets from memory after use: * lib/util.c: lib: clear secrets in set_protected_mgm * lib/ykpiv.c: lib: clear secrets in ykpiv_import_private_key * lib/ykpiv.c: lib: clear secrets in auth api * lib/internal.c, lib/ykpiv.c: lib: clear buffers containing key material * lib/internal.h, lib/util.c: lib: use secure zero memory platform functions * lib/ykpiv.c: lib: check internal authentication crypt errors Given the absence of an advisory, I assume those issues are not known to be exploitable. However, I believe it would be worth fixing them before the release of Buster. Please let me know if a fix should be backported to stretch. Best, nicoo -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 libykpiv1 depends on: ii libc6 2.28-8 ii libpcsclite1 1.8.24-1 ii libssl1.1 1.1.1b-1 Versions of packages libykpiv1 recommends: ii pcscd 1.8.24-1 libykpiv1 suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Source: yubico-piv-tool Source-Version: 1.7.0-1 We believe that the bug you reported is fixed in the latest version of yubico-piv-tool, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 926...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Nicolas Braud-Santoni (supplier of updated yubico-piv-tool package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 06 Apr 2019 22:35:22 +0200 Source: yubico-piv-tool Architecture: source Version: 1.7.0-1 Distribution: unstable Urgency: high Maintainer: Debian Authentication Maintainers Changed-By: Nicolas Braud-Santoni Closes: 926551 Changes: yubico-piv-tool (1.7.0-1) unstable; urgency=high (security fixes) . [ Nicolas Braud-Santoni ] * New upstream version 1.7.0 + Security fixes. (Closes: #926551) + ykcs11: Fix ECDSA signatures. + Documentation fixes. + libykpiv1: Update symbols file, add Build-Depends-Package metadata . * debian/upstream: Update keyring and its generation script . * debian/control + Update Uploader's email address + Bump Standards-Version to 4.3.0 No change required. . * Switch to debhelper 12 * debian/rules + Avoid unnecessary override_dh_install + Don't set rpath at build-time, rather than overriding + Replace `dh_install --fail-missing` with `dh_missing` . * ykcs11: Add Lintian overrides for PKCS#11 quirks * libykpiv-dev: Do not ship pkgconfig metadata for ykcs11
Bug#931081: marked as done (libyubikey-udev: missing Breaks+Replaces: libykpers-1-1 (<< 1.19.3))
Your message dated Sat, 13 Jul 2019 12:20:13 + with message-id and subject line Bug#931081: fixed in yubikey-personalization 1.20.0-1 has caused the Debian Bug report #931081, regarding libyubikey-udev: missing Breaks+Replaces: libykpers-1-1 (<< 1.19.3) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 931081: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931081 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libyubikey-udev Version: 1.19.3-3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'stretch'. It installed fine in 'stretch', then the upgrade to 'buster' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../libyubikey-udev_1.19.3-3_all.deb ... Unpacking libyubikey-udev (1.19.3-3) ... dpkg: error processing archive /var/cache/apt/archives/libyubikey-udev_1.19.3-3_all.deb (--unpack): trying to overwrite '/lib/udev/rules.d/69-yubikey.rules', which is also in package libykpers-1-1:amd64 1.17.3-1 Errors were encountered while processing: /var/cache/apt/archives/libyubikey-udev_1.19.3-3_all.deb The version (<< 1.19.3) is based on this changelog entry in 1.19.3-1: * Replace custom udev rules with libu2f-udev. Also drop build dependency on udev cheers, Andreas libykpers-1-1=1.17.3-1_libyubikey-udev=1.19.3-3.log.gz Description: application/gzip --- End Message --- --- Begin Message --- Source: yubikey-personalization Source-Version: 1.20.0-1 We believe that the bug you reported is fixed in the latest version of yubikey-personalization, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 931...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Nicolas Braud-Santoni (supplier of updated yubikey-personalization package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 13 Jul 2019 14:09:27 +0200 Source: yubikey-personalization Architecture: source Version: 1.20.0-1 Distribution: unstable Urgency: high Maintainer: Debian Authentication Maintainers Changed-By: Nicolas Braud-Santoni Closes: 931081 Changes: yubikey-personalization (1.20.0-1) unstable; urgency=high (RC bug and security) . * New upstream release 1.20.0 (2019-07-03) + Clear sensitive material from buffers + Documentation fixes + Fix potential buffer overflow. . * debian/control + Add missing Break+Replaces on libyubikey-udev Closes: #931081 + Declare compliance with policy v4.4.0. No change required + Shorten the extended description of libyubikey-udev Checksums-Sha1: cb76901875dec96c5430d7961083bb7f5fb7680f 2538 yubikey-personalization_1.20.0-1.dsc 6174d131ca447e66bfbc5de58bd032d8e448d254 523134 yubikey-personalization_1.20.0.orig.tar.gz dcdf4d3cf066565b7e8ce8428a5cf5f27c08fc88 53536 yubikey-personalization_1.20.0-1.debian.tar.xz f0f2651a1a7979c7d1b53b934a4e6014366935a6 7513 yubikey-personalization_1.20.0-1_amd64.buildinfo Checksums-Sha256: 3ebc2721d8c53b348aac413d9d34f3f85abc85e8ecad8c3360f29c4aa80fd325 2538 yubikey-personalization_1.20.0-1.dsc 0ec84d0ea862f45a7d85a1a3afe5e60b8da42df211bb7d27a50f486e31a79b93 523134 yubikey-personalization_1.20.0.orig.tar.gz 68c58c0a54a2edb081e1339cdb86615b20af04a093479b1f2bf5b9907a714da7 53536 yubikey-personalization_1.20.0-1.debian.tar.xz c852fad6a528a8693a8ca308dc8e5284048ebd80359872fa95bf6110d500aed7 7513 yubikey-personalization_1.20.0-1_amd64.buildinfo Files: b7c608e337e02429c9161c168273cb72 2538 utils optional yubikey-personalization_1.20.0-1.dsc 8749113ce5a0164fe2b429b61242ba0f 523134 utils optional yubikey-personalization_1.20.0.orig.tar.gz 9561d3eaedf16cdd71bd957178589923 53536 utils optional yubikey-personalization_1.20.0-1.debian.tar.xz 25f1cd628be9c86a34c5f5eae37fb55f 7513 utils optional yubikey-personalization_1.20.0-1_amd64.bui
Bug#931781: rsync: Buster hangs when rsyncing large (400M) files over ssh. Same hardware works OK with Stretch
Seeing the error messages you are getting, it sounds like there is a memory shortage, possibly the vmware ballooning driver is failing to provide sufficient memory in time. It does not look like rsync is to blame for your problems. Paul
Processed: tagging 931081
Processing commands for cont...@bugs.debian.org: > tags 931081 + confirmed pending Bug #931081 [libyubikey-udev] libyubikey-udev: missing Breaks+Replaces: libykpers-1-1 (<< 1.19.3) Added tag(s) pending and confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 931081: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931081 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931971: python-xarray: autopkgtest failure block netcdf4-python migration
Hi Bas, Alastair On Sat, 13 Jul 2019 at 07:57, Bas Couwenberg wrote: > The autopkgtest failures for python-xarray are blocking the testing migration > of netcdf4-python. > > Please fix the tests in your package or remove them. The tests of python-xarray 0.12.1-1 are passing [1]. So I think netcdf4-python needs to add a: Breaks: python-xarray (<< 0.12.1-1) or so, to ensure the correct versions are tested together. Regards Graham [1] https://ci.debian.net/packages/p/python-xarray/unstable/amd64/
Processed: Re: Bug#931985: file: Experimental file breaks package creation at dh_shlibdeps stage due to file command
Processing control commands: > tags 931985 confirmed Bug #931985 [file] file: Experimental file breaks package creation at dh_shlibdeps stage due to file command Added tag(s) confirmed. -- 931985: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931985 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931985: file: Experimental file breaks package creation at dh_shlibdeps stage due to file command
Control: tags 931985 confirmed At first, thanks for reporting, thus avoiding a lot of noise. Eric Valette wrote... > I know it is experimental but anyway That's what experimental is for :) Did you just stumble over it or do you do build checks incluing experimental on a regular base? In the latter case, I am happy to add you to my list¹ of recipicients I notify when uploading a new upstream version of file. These uploads always go to experimental first - experience taught new upstream versions break things. Christoph, now exploring the cause of the breakage ¹ https://sources.debian.org/src/file/1:5.37-1/debian/README.Maintainer/ signature.asc Description: PGP signature
Bug#931903: closed by Xavier (Fixed after recent node-acorn-dynamic-import downgrade)
Control: reopen -1 This is also reproducible with node-acorn-dynamic-import 4.0.0+really3.0.0-1: Preparing to unpack .../node-acorn_6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1_all.deb ... Unpacking node-acorn (6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1) over (5.5.3+ds3-3) ... dpkg: error processing archive /var/cache/apt/archives/node-acorn_6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1_all.deb (--unpack): trying to overwrite '/usr/lib/nodejs/acorn-dynamic-import/lib/index.js', which is also in package node-acorn-dynamic-import 4.0.0+really3.0.0-1 Errors were encountered while processing: /var/cache/apt/archives/node-acorn_6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1_all.deb Andreas
Bug#931985: file: Experimental file breaks package creation at dh_shlibdeps stage due to file command
Package: file Version: 1:5.37-1 Severity: critical Justification: breaks unrelated software I know it is experimental but anyway it should be fixed and if you build pacakges, you cannot anymore. Tried on two pacakges, same error. dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info dh_shlibdeps: Compatibility levels before 9 are deprecated (level 5 in use) dh_shlibdeps: Compatibility levels before 9 are deprecated (level 5 in use) dh_shlibdeps: file -e apptype -e ascii -e encoding -e cdf -e compress -e tar debian/tvheadend/usr/bin/tv_meta_tmdb.py died with signal 31 dh_shlibdeps: Aborting due to earlier error -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.58 (SMP w/8 CPU cores; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages file depends on: ii libc62.28-10 ii libmagic11:5.37-1 ii libseccomp2 2.3.3-4 ii zlib1g 1:1.2.11.dfsg-1 file recommends no packages. file suggests no packages. -- no debconf information
Processed: Re: Bug#931903 closed by Xavier (Fixed after recent node-acorn-dynamic-import downgrade)
Processing control commands:
> reopen -1
Bug #931903 {Done: Xavier } [node-acorn] node-acorn: fails to
upgrade from 'sid' - trying to overwrite
/usr/lib/nodejs/acorn-dynamic-import/lib/index.js
Bug reopened
Ignoring request to alter fixed versions of bug #931903 to the same values
previously set
--
931903: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931903
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#916375: marked as done (apache2: Segmentation fault when mod_perl.so is enabled)
Your message dated Sat, 13 Jul 2019 11:35:22 +0300 with message-id and subject line Closing issue has caused the Debian Bug report #916375, regarding apache2: Segmentation fault when mod_perl.so is enabled to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 916375: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916375 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: apache2 Version: 2.4.25-3+deb9u6 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, For communication with our customers we use the OTRS Ticket System. The server was reinstalled about a year ago and worked fine until it was rebooted three days ago. Since then the Apache web server crashes reproducibly as soon as it has to process a request. Here is a stacktrace: cd /etc/apache2 . envvars gdb /usr/sbin/apache2 gdb> set args -X gdb> run # ... now use the webbrowser to send an http request to the apache2 server: http://otrs-testing/otrs/index.pl?Action=Admin gdb> Thread 1 "/opt/otrs/bin/cgi-bi" received signal SIGSEGV, Segmentation fault. gdb> bt #0 0x7fffdcd290c7 in free_defaults () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #1 0x7fffdcd29422 in free_defaults () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #2 0x7fffdcd29461 in free_defaults () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #3 0x7fffdcd29637 in free_defaults () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #4 0x7fffdccf5868 in mysql_options4 () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #5 0x7fffdd2cabc8 in mysql_dr_connect () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so #6 0x7fffdd2ccc69 in ?? () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so #7 0x7fffdd2ccd71 in mysql_db_login () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so #8 0x7fffdd2d9651 in ?? () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so #9 0x73901950 in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #10 0x738f9e96 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #11 0x73879d5b in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #12 0x7fffea84c2e9 in XS_DBI_dispatch () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBI/DBI.so #13 0x73901950 in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #14 0x738f9e96 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #15 0x7387a10e in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #16 0x73c32c68 in modperl_callback () from /usr/lib/apache2/modules/mod_perl.so #17 0x73c33606 in modperl_callback_run_handlers () from /usr/lib/apache2/modules/mod_perl.so #18 0x73c33d9f in modperl_callback_per_dir () from /usr/lib/apache2/modules/mod_perl.so #19 0x73c2e0fb in ?? () from /usr/lib/apache2/modules/mod_perl.so #20 0x73c2e32c in modperl_response_handler_cgi () from /usr/lib/apache2/modules/mod_perl.so #21 0x555abc40 in ap_run_handler () #22 0x555ac1d6 in ap_invoke_handler () #23 0x555c3e13 in ap_process_async_request () #24 0x555c3f20 in ap_process_request () #25 0x555bffdd in ?? () #26 0x555b5ab0 in ap_run_process_connection () #27 0x740686bf in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so #28 0x740688f2 in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so #29 0x74069e37 in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so #30 0x5558f00e in ap_run_mpm () #31 0x55587c4d in main () We are using unattended upgrades (security only)
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
On 2019-07-12 23:24 +0200, Diederik de Haas wrote: > Package: grub-efi-amd64 > Followup-For: Bug #931896 > > I don't have grub-efi-amd64 installed, but I ran into the same problem. > The only enabled lines in /etc/default/grub are these: > GRUB_DEFAULT=0 > GRUB_TIMEOUT=5 > GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` > GRUB_CMDLINE_LINUX_DEFAULT="quiet" > GRUB_CMDLINE_LINUX="" > > Which, afaik, is the default. > The versions reported are what's currently installed as with 2.04 my > system doesn't boot. > > I'm not sure/don't understand what Colin meant with 'firmware'. My guess > would be my BIOS, but I haven't changed that recently. It is the system's firmware, called UEFI on modern systems or BIOS on older ones, where you would install grub-pc rather than grub-efi-amd64. > But up until version 2.04 grub2 has worked perfectly well and I don't > recall me having configured anything manually, so I wouldn't know why > it would be misconfigured. Most likely you had grub configured to install to the wrong disk, this is what happened to me. When I installed an SSD into my old PC back in December 2016, I copied all files from the already present hard drive, ran "grub-install /dev/sdb" and told the BIOS to boot from the SSD (which is /dev/sdb). Everything was working fine until I upgraded grub-pc to version 2.04. What I finally figured out after getting my system to boot again, is that grub was still configured to install its core image to /dev/sda, the old hard disk. This configuration is apparently only stored in the debconf database and nowhere else. > I can send my grub.cfg in a separate email if that would help. > (How can I do a followup with bugreport so that the full output is > reported as you'd get with an initial filing of a bug?) You can run "reportbug --template grub-pc" and paste the output to your preferred mailer. Cheers, Sven
