Bug#884063: vlc-plugin-base: fails to upgrade from 'sid' - trying to overwrite /usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libzvbi_plugin.so

[Andreas Beckmann]

Package: vlc-plugin-base
Version: 3.0.0~rc1~20171210-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' 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/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package vlc-plugin-base:amd64.
  Preparing to unpack .../155-vlc-plugin-base_3.0.0~rc1~20171210-2_amd64.deb ...
  Unpacking vlc-plugin-base:amd64 (3.0.0~rc1~20171210-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-PUAXac/155-vlc-plugin-base_3.0.0~rc1~20171210-2_amd64.deb 
(--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libzvbi_plugin.so', which is also 
in package vlc-plugin-zvbi:amd64 2.2.8-2+b1
  Errors were encountered while processing:
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
   
/tmp/apt-dpkg-install-PUAXac/155-vlc-plugin-base_3.0.0~rc1~20171210-2_amd64.deb


cheers,

Andreas


vlc-plugin-zvbi=2.2.8-2+b1_vlc-plugin-base=3.0.0~rc1~20171210-2.log.gz
Description: application/gzip

Bug#883731: audacious: Debian packaging has incorrect license

[John Lindgren]

On 12/10/2017 06:12 PM, Nicholas D Steeves wrote:
> In particular I'm concerned about lines like this from
> d/copyright:
> 
> "po/uk.po" is © 2005 Mykola Lynnyk and is distributed under the terms of the
>  GPL.
> 
> Where the new po/uk.po is GPL-incompatible 2-clause BSD:

The line "Copyright (C) 2005 Mykola Lynnyk <...>" appears to have been
lost accidentally in commit 1a013156d209b, when we switched over to
Transifex.  I'll see about restoring it.

As far as our Git history goes back (to October 2005), uk.po had no
license declaration and was assumed to be under the same license as the
source files it translated (which at the time was GPLv2+). At the time
of the BSD relicense, we took the liberty of assuming that such
translations would automatically switch to the new license along with
the source files they translated.  No one (to my knowledge) has
contacted us in the five years since to clarify that their translations
were intended to be forever GPL-only, but I suppose that to take a more
cautious approach, Debian could still distribute the package as GPL in
total.

> Oh, and if
> everything goes according to plan we'll have a qt variant again
> sometime in 2018 (one src:package will build the gtk variant, cleanup,
> build the qt variant, and then package the two variants separately).

+1 from me!

John

Bug#884069: Kernel crash on boot on IBM BladeCenter HS22

[Bernhard Schmidt]

Control: severity -1 critical

On Mon, Dec 11, 2017 at 09:14:27AM +0200, Rolandas Naujikas wrote:

Hi,

> Package: linux-image-3.16.0-4-amd64
> Version: 3.16.51-2
> 
> Loading Linux 3.16.0-4-amd64 ...
> Loading initial ramdisk ...
> [0.604128] general protection fault:  [#1] SMP
> [0.609303] Modules linked in:
> [0.612493] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
> 3.16.0-4-amd64 #1 Debian 3.16.51-2
> [0.621685] Hardware name: IBM BladeCenter HS22 -[7870SGX]-/68Y8077,
> BIOS -[P9E163AUS-1.24]- 09/17/2014
> [0.631141] task: 8803731392d0 ti: 88037313c000 task.ti:
> 88037313c000
> [0.638684] RIP: 0010:[]  []
> build_sched_domains+0x72d/0xcf0
> [0.647609] RSP: :88037313fdf8  EFLAGS: 00010216
> [0.652982] RAX:  RBX:  RCX:
> 0012
> [0.660175] RDX: 00016f48 RSI:  RDI:
> 0200
> [0.667372] RBP: 880372f5d698 R08: 880372f5e0e0 R09:
> 0139
> [0.674566] R10:  R11: 88037313fb06 R12:
> 880372f5e0c0
> [0.681761] R13: 0200 R14: 880672e640c0 R15:
> 0200
> [0.688958] FS:  () GS:88037fc0()
> knlGS:
> [0.697110] CS:  0010 DS:  ES:  CR0: 8005003b
> 
> [0.702914] CR2: 88067000 CR3: 01813000 CR4:
> 07f0
> [0.710109] Stack:
> [0.712183]  8806 880372f5e0d8 880372f5d600
> 880672e640c0
> [0.719940]    
> 880372f53e00
> [0.727715]   f1c8 
> 
> [0.735501] Call Trace:
> [0.738022]  [] ? sched_init_smp+0x398/0x452
> 
> [0.743930]  [] ? mutex_lock+0xe/0x2a
> [0.749229]  [] ? put_online_cpus+0x23/0x80
> 
> [0.755050]  [] ? stop_machine+0x2c/0x40
> 
> [0.760618]  [] ? kernel_init_freeable+0xdd/0x1e1
> 
> [0.766963]  [] ? rest_init+0x80/0x80
> [0.772264]  [] ? kernel_init+0xa/0xf0
> 
> [0.777652]  [] ? ret_from_fork+0x58/0x90
> 
> [0.783298]  [] ? rest_init+0x80/0x80
> [0.788595] Code: c0 0f 85 46 05 00 00 48 8b 74 24 08 48 c7 c2 00 dd
> a6 81 bf ff ff ff ff e8 91 78 21 00 48 98 49 8b 56 10 48 8b 04 c5 a0 1e
> 8e 81 <48> 8b 14 10 b8 01 00 00 00 49 89 54 24 10 f0 0f c1 02 85 c0 75
> 
> [0.812501] RIP  [] build_sched_domains+0x72d/0xcf0
> 
> [0.819101]  RSP 
> [0.822668] ---[ end trace b6ea7a8f78a6ba93 ]---
> [0.827375] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> [0.827375]
> [0.836621] ---[ end Kernel panic - not syncing: Attempted to kill
> init! exitcode=0x000b
> [0.836621]

Seeing the same on two Dell R610 after the point release.

Bernhard

Bug#884069: the same problem on different hardware

[Rolandas Naujikas]

Loading Linux 3.16.0-4-amd64 ...
Loading initial ramdisk ...
[0.349165] general protection fault:  [#1] SMP
[0.352000] Modules linked in:
[0.352000] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
3.16.0-4-amd64 #1 Debian 3.16.51-2
[0.352000] Hardware name: Sun Microsystems Sun Fire X2200 M2
/S39  , BIOS S39_3B27 02/04/2009


[0.352000] task: 88021b4dd2d0 ti: 88021b4f task.ti:
88021b4f
[0.352000] RIP: 0010:[]  []
build_sched_domains+0x72d/0xcf0
[0.352000] RSP: :88021b4f3df8  EFLAGS: 00010216

[0.352000] RAX:  RBX:  RCX:
0002
[0.352000] RDX: 00016cc8 RSI:  RDI:
0200
[0.352000] RBP: 88021b5d1d98 R08: 88021b5d0760 R09:
00f4
[0.352000] R10:  R11: 88021b4f3b06 R12:
88021b5d0740
[0.352000] R13: 0200 R14: 88021b58cac0 R15:
0200
[0.352000] FS:  () GS:880223c0()
knlGS:
[0.352000] CS:  0010 DS:  ES:  CR0: 8005003b

[0.352000] CR2: 880323fff000 CR3: 01813000 CR4:
07f0
[0.352000] Stack:
[0.352000]  8802 88021b5d0758 88021b5d1d00
88021b58cac0
[0.352000]    
880323418e00
[0.352000]   f1c8 

[0.352000] Call Trace:
[0.352000]  [] ? sched_init_smp+0x398/0x452

[0.352000]  [] ? mutex_lock+0xe/0x2a
[0.352000]  [] ? put_online_cpus+0x23/0x80

[0.352000]  [] ? stop_machine+0x2c/0x40

[0.352000]  [] ? kernel_init_freeable+0xdd/0x1e1

[0.352000]  [] ? rest_init+0x80/0x80
[0.352000]  [] ? kernel_init+0xa/0xf0

[0.352000]  [] ? ret_from_fork+0x58/0x90

[0.352000]  [] ? rest_init+0x80/0x80
[0.352000] Code: c0 0f 85 46 05 00 00 48 8b 74 24 08 48 c7 c2 00 dd
a6 81 bf ff ff ff ff e8 91 78 21 00 48 98 49 8b 56 10 48 8b 04 c5 a0 1e
8e 81 <48> 8b 14 10 b8 01 00 00 00 49 89 54 24 10 f0 0f c1 02 85 c0 75

[0.352000] RIP  [] build_sched_domains+0x72d/0xcf0

[0.352000]  RSP 
[0.352006] ---[ end trace 68d23c2290c77ca9 ]---
[0.356017] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.356017]
[0.36] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x000b
[0.36]

Bug#884068: Suggested change to test http2

[Christian Ehrhardt]

Hi,
please check out the http2 test with

browser: 
https://code.launchpad.net/~paelzer/apache2/+git/apache2/+ref/test-for-http2
git: git clone -b test-for-http2 https://git.launchpad.net/~paelzer/apache2

Looking forward to your review, kind regards
Christian Ehrhardt

Bug#883938: HP ProLiant DL360 Gen9

[Stephane Lapie]

Hi,

I also got some hardware refusing to boot with this bug :
HP ProLiant DL360 Gen9

The crash is instant, right after GRUB loads the kernel and initramfs.

Partial backtrace (re-typed from a KVM screen capture) :
[0.649289] Call Trace:
[0.649362]  [] ? sched_init_smp+0x398/0x452
[0.649437]  [] ? mutex_lock+0xe/0x2a
[0.649512]  [] ? put_online_cpus+0x23/0x80
[0.649587]  [] ? stop_machine+0x2c/0x40
[0.649662]  [] ? kernel_init_freeable+0xdd/0x1e1
[0.649738]  [] ? rest_init+0x80/0x80
[0.649813]  [] ? kernel_init+0xa/0xf0
[0.649888]  [] ? ret_from_fork+0x58/0x90
[0.649963]  [] ? rest_init+0x80/0x80
[0.650037] Code: c0 0f 85 46 05 00 00 48 8b 74 24 08 48 c7 c2 00 dd a6
81 bf ff ff ff ff e8 91 78 21 00 48 98 49 8b 56 10 48 8b 04 c5 a0 1e 8e 81
<48> 8b 14 10 b8 01 00 00 00 49 89 54 24 10 f0 0f c1 02 85 c0 75
[0.653853] RIP  [] build_sched_domains+0x72d/0xcf0
[0.653986]  RSP 
[0.654061] ---[ end trace 5d1a1ddbcedef31d ]---
[0.654145] Kernel panic - not syncing: Attempted to kill init! exit
code=0x000b
[0.654145]
[0.654252] ---[ end Kernel panic - not syncing: Attempted to kill init!
exit code=0x000b
[0.654252]

I could only fix the issue by downgrading.
It should be noted that even after the downgrade, it reports this error, if
there is any chance of relevance :
[0.059876] [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR
38d is 330)

Cheers,
-- 
ラピー ステファン Lapie Stephane
株式会社朝日ネット システム部
AsahiNet, Inc. - System Division

Bug#884066: Debian mirror ftp.halifax.rwth-aachen.de: out-of-date

[Bastian Blank]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem may-auto-close
Control: submitter -1 mirr...@debian.org

Hi

You receive this mail because you are listed as contact for:
  ftp.halifax.rwth-aachen.de

Your mirror have not finished a single sync since almost three days.
Please investigate.

In the meantime, I pointed ftp2.de.debian.org to another system.

Regards,
Bastian

-- 
We Klingons believe as you do -- the sick should die.  Only the strong
should live.
-- Kras, "Friday's Child", stardate 3497.2

Bug#883938: same issue

[Tomáš Thiemel]

Have the same issue (kernel panic) after kernel upgade this night. I had to 
restore the old kernel+initrd+modules from backup (Linux xxx 3.16.0-4-amd64 #1 
SMP Debian 3.16.43-2+deb8u5 (2017-09-19) x86_64 GNU/Linux).
 
Server: HP ProLiant DL380 G6
# lspci
00:00.0 Host bridge: Intel Corporation 5520 I/O Hub to ESI Port (rev 13)
00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root 
Port 1 (rev 13)
00:02.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root 
Port 2 (rev 13)
00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root 
Port 3 (rev 13)
00:04.0 PCI bridge: Intel Corporation 5520/X58 I/O Hub PCI Express Root Port 4 
(rev 13)
00:05.0 PCI bridge: Intel Corporation 5520/X58 I/O Hub PCI Express Root Port 5 
(rev 13)
00:06.0 PCI bridge: Intel Corporation 5520/X58 I/O Hub PCI Express Root Port 6 
(rev 13)
00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root 
Port 7 (rev 13)
00:08.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root 
Port 8 (rev 13)
00:09.0 PCI bridge: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express 
Root Port 9 (rev 13)
00:0a.0 PCI bridge: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express 
Root Port 10 (rev 13)
00:0d.0 Host bridge: Intel Corporation Device 343a (rev 13)
00:0d.1 Host bridge: Intel Corporation Device 343b (rev 13)
00:0d.2 Host bridge: Intel Corporation Device 343c (rev 13)
00:0d.3 Host bridge: Intel Corporation Device 343d (rev 13)
00:0d.4 Host bridge: Intel Corporation 7500/5520/5500/X58 Physical Layer Port 0 
(rev 13)
00:0d.5 Host bridge: Intel Corporation 7500/5520/5500 Physical Layer Port 1 
(rev 13)
00:0d.6 Host bridge: Intel Corporation Device 341a (rev 13)
00:0e.0 Host bridge: Intel Corporation Device 341c (rev 13)
00:0e.1 Host bridge: Intel Corporation Device 341d (rev 13)
00:0e.2 Host bridge: Intel Corporation Device 341e (rev 13)
00:0e.3 Host bridge: Intel Corporation Device 341f (rev 13)
00:0e.4 Host bridge: Intel Corporation Device 3439 (rev 13)
00:14.0 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub System Management 
Registers (rev 13)
00:14.1 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad 
Registers (rev 13)
00:14.2 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub Control Status and 
RAS Registers (rev 13)
00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root 
Port 1
00:1c.2 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root 
Port 3
00:1d.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #1
00:1d.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #2
00:1d.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #3
00:1d.3 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI 
Controller #6
00:1d.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI 
Controller #1
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90)
00:1f.0 ISA bridge: Intel Corporation 82801JIB (ICH10) LPC Interface Controller
01:03.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
ES1000 (rev 02)
01:04.0 System peripheral: Compaq Computer Corporation Integrated Lights Out 
Controller (rev 03)
01:04.2 System peripheral: Compaq Computer Corporation Integrated Lights Out  
Processor (rev 03)
01:04.4 USB controller: Hewlett-Packard Company Integrated Lights-Out Standard 
Virtual USB Controller
01:04.6 IPMI SMIC interface: Hewlett-Packard Company Integrated Lights-Out 
Standard KCS Interface
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit 
Ethernet (rev 20)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit 
Ethernet (rev 20)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit 
Ethernet (rev 20)
03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit 
Ethernet (rev 20)
04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers 
(rev 01)
14:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 
Gb/s controller (rev 11)
3e:00.0 Host bridge: Intel Corporation Xeon 5600 Series QuickPath Architecture 
Generic Non-core Registers (rev 02)
3e:00.1 Host bridge: Intel Corporation Xeon 5600 Series QuickPath Architecture 
System Address Decoder (rev 02)
3e:02.0 Host bridge: Intel Corporation Xeon 5600 Series QPI Link 0 (rev 02)
3e:02.1 Host bridge: Intel Corporation Xeon 5600 Series QPI Physical 0 (rev 02)
3e:02.2 Host bridge: Intel Corporation Xeon 5600 Series Mirror Port Link 0 (rev 
02)
3e:02.3 Host bridge: Intel Corporation Xeon 5600 Series Mirror Port Link 1 (rev 
02)
3e:02.4 Host bridge: Intel Corporation Xeon 5600 Series QPI Link 1 (rev 02)
3e:02.5 Host bridge: Intel Corporation Xeon 5600 Series QPI Physical 1 (rev 02)
3e:03.0 Host bridge: Intel Corporation Xeon 5600 Series Integrated Memory 
Controller Registers (rev 02)
3e:03.1 

Bug#884067: GIO lists removable storage devices even after they have been unplugged when using Linux kernel v4.14

[Torbjörn Andersson]

Package: libglib2.0-0
Version: 2.54.2-1

Dear maintainer,

After upgrading the Linux kernel to linux-image-4.14.0-1-amd64 , version 
4.14.2-1 (I'm using Debian sid), I noticed that when plugging in my 
phone via USB I would see an icon for it in my file manager (Thunar) and 
on my desktop (Xfce), but when unplugging the phone the icon would no 
longer disappar. Plugging in the phone again would give me a second 
icon. Doing it again a third, and so on.


This did not happen when I tried KDE's file manager, Dolphin, which 
suggests that the problem might be Glib-related, unless it's even 
further down. I'm still not sure where it actually gets the information, 
but the following program gave me the same list as the file manager, 
including the duplicates:


#include 
#include 

int main() {
  GVolumeMonitor *monitor = g_volume_monitor_get();
  GList *volumes = g_volume_monitor_get_volumes(monitor);
  GList *lp;

  for (lp = volumes; lp != NULL; lp = lp->next) {
GVolume *volume = lp->data;
char *volume_name = g_volume_get_name(volume);
printf("%s\n", g_volume_get_name(volume));
g_free(volume_name);
  }

  g_object_unref(monitor);
  g_list_free(volumes);

  return 0;
}

I don't know if it's relevant, but I also tried running "udevadm 
monitor" while plugging in and removing the phone. This is what I got 
with a 4.13 kernel (4.13.13-1):


KERNEL[50.806104] add  /devices/pci:00/:00:14.0/usb3/3-9 (usb)
KERNEL[50.806778] add 
/devices/pci:00/:00:14.0/usb3/3-9/3-9:1.0 (usb)

UDEV  [50.811697] add  /devices/pci:00/:00:14.0/usb3/3-9 (usb)
UDEV  [50.815390] add 
/devices/pci:00/:00:14.0/usb3/3-9/3-9:1.0 (usb)
KERNEL[54.278046] remove 
/devices/pci:00/:00:14.0/usb3/3-9/3-9:1.0 (usb)

KERNEL[54.278584] remove   /devices/pci:00/:00:14.0/usb3/3-9 (usb)
UDEV  [54.279883] remove 
/devices/pci:00/:00:14.0/usb3/3-9/3-9:1.0 (usb)

UDEV  [54.281104] remove   /devices/pci:00/:00:14.0/usb3/3-9 (usb)

And this is what I got with the aforementioned 4.14 kernel:

KERNEL[69.838042] add  /devices/pci:00/:00:14.0/usb1/1-9 (usb)
KERNEL[69.838679] add 
/devices/pci:00/:00:14.0/usb1/1-9/1-9:1.0 (usb)

KERNEL[69.838770] bind /devices/pci:00/:00:14.0/usb1/1-9 (usb)
UDEV  [69.843453] add  /devices/pci:00/:00:14.0/usb1/1-9 (usb)
UDEV  [69.845072] add 
/devices/pci:00/:00:14.0/usb1/1-9/1-9:1.0 (usb)

UDEV  [69.849294] bind /devices/pci:00/:00:14.0/usb1/1-9 (usb)
KERNEL[73.46] remove 
/devices/pci:00/:00:14.0/usb1/1-9/1-9:1.0 (usb)

KERNEL[73.667196] unbind   /devices/pci:00/:00:14.0/usb1/1-9 (usb)
KERNEL[73.667273] remove   /devices/pci:00/:00:14.0/usb1/1-9 (usb)
UDEV  [73.668520] remove 
/devices/pci:00/:00:14.0/usb1/1-9/1-9:1.0 (usb)

UDEV  [73.670060] unbind   /devices/pci:00/:00:14.0/usb1/1-9 (usb)
UDEV  [73.670446] remove   /devices/pci:00/:00:14.0/usb1/1-9 (usb)

Regards,

Torbjörn Andersson

Bug#884069: Kernel crash on boot on IBM BladeCenter HS22

[Rolandas Naujikas]

Package: linux-image-3.16.0-4-amd64
Version: 3.16.51-2

Loading Linux 3.16.0-4-amd64 ...
Loading initial ramdisk ...
[0.604128] general protection fault:  [#1] SMP
[0.609303] Modules linked in:
[0.612493] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
3.16.0-4-amd64 #1 Debian 3.16.51-2
[0.621685] Hardware name: IBM BladeCenter HS22 -[7870SGX]-/68Y8077,
BIOS -[P9E163AUS-1.24]- 09/17/2014
[0.631141] task: 8803731392d0 ti: 88037313c000 task.ti:
88037313c000
[0.638684] RIP: 0010:[]  []
build_sched_domains+0x72d/0xcf0
[0.647609] RSP: :88037313fdf8  EFLAGS: 00010216
[0.652982] RAX:  RBX:  RCX:
0012
[0.660175] RDX: 00016f48 RSI:  RDI:
0200
[0.667372] RBP: 880372f5d698 R08: 880372f5e0e0 R09:
0139
[0.674566] R10:  R11: 88037313fb06 R12:
880372f5e0c0
[0.681761] R13: 0200 R14: 880672e640c0 R15:
0200
[0.688958] FS:  () GS:88037fc0()
knlGS:
[0.697110] CS:  0010 DS:  ES:  CR0: 8005003b

[0.702914] CR2: 88067000 CR3: 01813000 CR4:
07f0
[0.710109] Stack:
[0.712183]  8806 880372f5e0d8 880372f5d600
880672e640c0
[0.719940]    
880372f53e00
[0.727715]   f1c8 

[0.735501] Call Trace:
[0.738022]  [] ? sched_init_smp+0x398/0x452

[0.743930]  [] ? mutex_lock+0xe/0x2a
[0.749229]  [] ? put_online_cpus+0x23/0x80

[0.755050]  [] ? stop_machine+0x2c/0x40

[0.760618]  [] ? kernel_init_freeable+0xdd/0x1e1

[0.766963]  [] ? rest_init+0x80/0x80
[0.772264]  [] ? kernel_init+0xa/0xf0

[0.777652]  [] ? ret_from_fork+0x58/0x90

[0.783298]  [] ? rest_init+0x80/0x80
[0.788595] Code: c0 0f 85 46 05 00 00 48 8b 74 24 08 48 c7 c2 00 dd
a6 81 bf ff ff ff ff e8 91 78 21 00 48 98 49 8b 56 10 48 8b 04 c5 a0 1e
8e 81 <48> 8b 14 10 b8 01 00 00 00 49 89 54 24 10 f0 0f c1 02 85 c0 75

[0.812501] RIP  [] build_sched_domains+0x72d/0xcf0

[0.819101]  RSP 
[0.822668] ---[ end trace b6ea7a8f78a6ba93 ]---
[0.827375] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.827375]
[0.836621] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x000b
[0.836621]

Bug#883938: HP ProLiant DL360 Gen9

[Stephane Lapie]

One more bit of info if it helps.

I noticed that I had some ProLiant DL360 Gen9 servers that booted fine with
that version.
The main difference between the ones that failed booting had more CPU cores
detected than the ones that succeeded.
For reference, the successful one had 20, the failed one had 32.
Given the kernel panic seems to be scheduler related, are there any chances
this is an edge case for servers with tons of CPUs?

Cheers,
-- 
ラピー ステファン Lapie Stephane
株式会社朝日ネット システム部
AsahiNet, Inc. - System Division

Bug#884068: autopkgtest to ensure http2 builds and works correctly

[Christian Ehrhardt]

Package: apache2
Version: 2.4.29-1

Hi,
I recently followed Debian and enabled http2 in Ubuntu.
Along that I thought http2 is "new enough" to be reasonable to add at
least a basic test for it.
I have done so and it worked fine on all architectures - one example
at [1] and the overview at [2].

I'll propose a change that you can review and pick in a bit, just need
a bug number to reference first.

[1]: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/a/apache2/20171208_113209_4302b@/log.gz
[2]: http://autopkgtest.ubuntu.com/packages/apache2


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#877992: 9.3 still a problem

[jaltek]

Can confirm that the problem still persists after upgrade to 9.3 and a
reboot.

Like Kurt (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877992#40)
mentioned, I had to

systemctl enable postfix@-

followed by

systemctl start postfix@-

to get Postfix back running.

Before the above mentioned enable/start procedure, systemclt reported
the following:

# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor
preset: enabled)
   Active: active (exited) since Mon 2017-12-11 08:47:03 CET; 41s ago
  Process: 1033 ExecReload=/bin/true (code=exited, status=0/SUCCESS)
  Process: 640 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 640 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
   CGroup: /system.slice/postfix.service

Cheers,

Jan




On 12/10/2017 04:11 PM, Thomas Leister wrote:
> Haven't checked it myself yet, but I've heard that this issue indeed
> still exists in Debian 9.3. So you're not the only one. I hope this gets
> resolved by a skilled dev / packager (or another responsible person)
> soon as workarounds are no real solution.
> 
> Kind regards,
> Thomas
> 
> 
> Am 10.12.2017 um 09:05 schrieb b4d:
>> Hi, any info of resolution to this problem, as in 9.3 it still exists
>> for me?
>>
>> Deni
>>
> 

Bug#872305: diaspora: Package fails to install

[Joseph Nuthalapati]

reopen 872305 !
tag 872305 + patch
thanks

Was able to reproduce this.

Steps to reproduce:

1. Install diaspora and diaspora-common
2. Uninstall diaspora but not diaspora-common
3. Install diaspora package - the above error will be thrown

diaspora package shouldn't be deleting symlinks from diaspora-common.
The attached patch is to fix this issue.

-- 
Thanks,
Joseph Nuthalapati
From 810201286f5b4ed8400977ba39058aa60b0690fc Mon Sep 17 00:00:00 2001
From: Joseph Nuthalapati 
Date: Mon, 11 Dec 2017 13:01:46 +0530
Subject: [PATCH] Don't remove files that are created/removed by
 diaspora-common

The following symlinks are removed when diaspora-common is removed:

/usr/share/diaspora/public
/usr/share/diaspora/.bundle
/usr/share/diaspora/Gemfile.lock
/usr/share/diaspora/tmp
/usr/share/diaspora/app/assets

The following files are removed as part of postrm purge of diaspora-common:

/var/lib/diaspora/app-assets

/usr/share/diaspora/.eye is never created only /var/lib/diaspora/.eye exists.

Signed-off-by: Joseph Nuthalapati 
---
 debian/postrm | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/debian/postrm b/debian/postrm
index 3ed8fa7..295877b 100644
--- a/debian/postrm
+++ b/debian/postrm
@@ -18,13 +18,6 @@ case "$1" in
 # This package is being removed, but its configuration has not yet
 # been purged.
 :
-
-rm -rf /usr/share/diaspora/tmp
-rm -rf /usr/share/diaspora/public
-rm -rf /usr/share/diaspora/app/assets/images
-rm -rf /usr/share/diaspora/.bundle
-rm -rf /usr/share/diaspora/.eye
-rm -rf /usr/share/diaspora/Gemfile.lock
 
 # Remove diversion
 # ldconfig is NOT needed during removal of a library, only during
-- 
2.15.0



signature.asc
Description: OpenPGP digital signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Christian PERRIER]

Quoting Raymond Burkholder (r...@oneunified.net):
> > 
> > I think its totally adequate to assume people want automatic security
> > updates, on all kinds of systems, unless they opt out.
> 
> Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.
> 
> For my infrastructure, updates, of what ever kind, need to be incorporated 
> into the test/build/roll-out cycle.
> 
> Unless I misunderstand the intent of this thread.
> 
> So, as an accommodation,  a flag in the preseed mechanism to enable/disable 
> would be helpful.  But would need to be exposed in maybe the expert mode 
> menus, which I think was already mentioned.


You mean something like:

emplate: pkgsel/update-policy
Type: select
Default: unattended-upgrades
Choices-C: none, unattended-upgrades
__Choices: No automatic updates, Install security updates automatically
_Description: Updates management on this system:
 Applying updates on a frequent basis is an important part of keeping the
 system secure.
 .
 By default, security updates are automatically installed by the
 unattended-upgrades package. Alternatively, you can opt-out from
 this system and apply updates manually using standard package management
 tools.


pkgsel/update-policy=none thus seem the perfect preseed choice for
your use case.




signature.asc
Description: PGP signature

Bug#884043: obfsproxy: Ship an AppArmor profile again

[intrigeri]

Hi,

I suggest first checking why we're still including obfsproxy:
I suspect most of the reverse-dependency relationships might be
obsolete nowadays (the last upstream version was released 3 years ago,
and AFAIK obfs4proxy is the future).

If obfsproxy is still useful in contexts where AppArmor confining
matters, I'm fine with us including a profile again *if* someone
commits to maintaining it, which apparently is hard to do properly
without routinely using it on testing/sid.

Thanks!

Cheers,
-- 
intrigeri

Bug#881936: apparmor: support usrmerge

[intrigeri]

Control: tag -1 + fixed-upstream

Héctor Orón Martínez:
> FYI patch got merged upstream:
> https://gitlab.com/apparmor/apparmor/commit/b24a1c4d546a6825f252d27243e09c80d04cf484

Congrats! Tagging this bug accordingly :)

Bug#884065: mariadb-10.2: CVE-2017-10378 CVE-2017-10268 CVE-2017-15365

[Salvatore Bonaccorso]

Control: retitle -1 mariadb-10.2 CVE-2017-10378 CVE-2017-10268 CVE-2017-15365 
CVE-2017-3636 CVE-2017-3641 CVE-2017-3653 CVE-2017-10320 CVE-2017-10365 
CVE-2017-10379 CVE-2017-10384 CVE-2017-10286 CVE-2017-3257 

On Mon, Dec 11, 2017 at 07:19:22AM +0100, Salvatore Bonaccorso wrote:
> Source: mariadb-10.2
> Version: 10.2.7-1
> Severity: grave
> Tags: security upstream
>
> Hi,
>
> the following vulnerabilities were published for mariadb-10.2, these
> are fixed in 10.2.10.

There are the following more as well adressend in 10.2.8:

CVE-2017-3636
CVE-2017-3641
CVE-2017-3653
CVE-2017-10320
CVE-2017-10365
CVE-2017-10379
CVE-2017-10384
CVE-2017-10286
CVE-2017-3257

Cf. https://mariadb.com/kb/en/library/mariadb-1028-release-notes/

Regards,
Salvatore

Bug#884066: Debian mirror ftp.halifax.rwth-aachen.de: out-of-date

[Carsten Otto]

Hi Bastian,

thank you, we noticed related issues and are investigating. I'll keep
you posted.

Thanks,
Carsten
-- 
Dr. Carsten Otto
http://verify.rwth-aachen.de/otto/


signature.asc
Description: PGP signature

Bug#884059: libnunit-core-interfaces2.6.3-cil fails to install

[A. Maitland Bottoms]

Source: nunit
Version: 2.6.4+dfsg-1
Severity: important

Rebuilding libiio in unstable fails in recent months:

Setting up libnunit-core-interfaces2.6.3-cil (2.6.4+dfsg-1) ...
Segmentation fault
Use of uninitialized value $_ in scalar chomp at 
/usr/share/cli-common/runtimes.d/mono line 275.
Use of uninitialized value $fullname in concatenation (.) or string at 
/usr/share/cli-common/runtimes.d/mono line 225.
Segmentation fault
E: installing Assembly 
/usr/share/cli-common/policies.d/libnunit-core-interfaces2.6.3-cil/policy.2.6.nunit.core.interfaces.dll
 failed
E: Installation of policy.2.6.nunit.core.interfaces with 
/usr/share/cli-common/runtimes.d/mono failed
dpkg: error processing package libnunit-core-interfaces2.6.3-cil (--configure):
 installed libnunit-core-interfaces2.6.3-cil package post-installation script 
subprocess returned error exit status 1

Setting up libnunit-framework2.6.3-cil (2.6.4+dfsg-1) ...
Segmentation fault
W: removing assembly:  failed!
Segmentation fault
Use of uninitialized value $_ in scalar chomp at 
/usr/share/cli-common/runtimes.d/mono line 275.
Use of uninitialized value $fullname in concatenation (.) or string at 
/usr/share/cli-common/runtimes.d/mono line 225.
Segmentation fault
E: installing Assembly 
/usr/share/cli-common/policies.d/libnunit-framework2.6.3-cil/policy.2.6.nunit.framework.dll
 failed
E: Installation of policy.2.6.nunit.framework with 
/usr/share/cli-common/runtimes.d/mono failed
dpkg: error processing package libnunit-framework2.6.3-cil (--configure):
 installed libnunit-framework2.6.3-cil package post-installation script 
subprocess returned error exit status 1

This Build-Depends: is uninstallable:
Build-Depends: bison,
   cli-common-dev [amd64 arm64 armel armhf i386 mipsel ppc64el 
s390x kfreebsd-any powerpc ppc64],
   cmake (>= 2.8),
   debhelper (>= 9),
   dh-python,
   doxygen,
   flex,
   libserialport-dev,
   libudev-dev [linux-any],
   libusb-1.0-0-dev [linux-any],
   libusb2-dev [kfreebsd-any],
   libxml2-dev,
   python

Adding mono-devel and mono-runtime-common does not help.

-Maitland

Bug#884064: ITP: jsonrpclib-pelix -- This project is an implementation of the JSON-RPC v2.0 specification (backwards-

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann 

* Package name: jsonrpclib-pelix
  Version : 0.3.1
  Upstream Author : Thomas Calmant 
* URL : http://github.com/tcalmant/jsonrpclib/
* License : Apache License 2.0
  Programming Lang: Python
  Description : This project is an implementation of the JSON-RPC v2.0 
specification (backwards-

Binary package names: python3-jsonrpclib-pelix

This is a fork of jsonrpclib used by electrum for Python 3 support; I intend
not to ship the Python 2 package to avoid conflicts with python-jsonrpclib.

Bug#883156: version 1.1

[Paolo Greppi]

Il 10/12/2017 21:16, Samuel Thibault ha scritto:
> Hello,
> 
> Paolo Greppi, on lun. 04 déc. 2017 18:24:46 +0100, wrote:
>> P.S. IMHO it would make sense to separate the libttspico-utils binary 
>> package from the svox source package.
>> In this way it would have its own version number, plus the code would not be 
>> in a patch 
>> but in plaintext.
> 
> Indeed, it makes a lot of sense, it "just needs" to be done, any taker ? :)
> (it means: submitting the ITP, setting up a repo on alioth for the
> debian packaging, writing the packaging bits, and upload. I can quickly
> do the last step if all the previous steps are done).
> 
> Samuel

I can do the ITP and the packaging.

I propose to name the new source pico2wave.
It would produce a new binary pico2wave and a transitional libttspico-utils as 
per:
https://wiki.debian.org/RenamingPackages

Re. the repo on alioth, as a DM I can not write in 
git.debian.org:/git/collab-maint
so somebody should create the pico2wave.git directory in there and assign the 
owner to paolog-guest.
Or we place the repo somewhere else.

Paolo

Bug#878063: ansible-pull broke fully after update from 2.3 to 2.4

[Lee]

Hi Klaus,

can you test if ansible 2.4.2 from sid fixes it for you? This version and the
one before has several fixes around ansible-pull.

Greets,
Lee

On Mon, 9 Oct 2017 11:02:19 +0100 Klaus Ethgen  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Package: ansible
> Version: 2.4.0.0+dfsg-1
> Severity: important
> 
> See https://github.com/ansible/ansible/issues/31449
> 
> - -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (400, 'unstable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.11.12 (SMP w/8 CPU cores)
> Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=de_DE:en 
> (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages ansible depends on:
> ii  python2.7.14-1
> ii  python-crypto 2.6.1-7+b1
> ii  python-cryptography   1.9-1
> ii  python-httplib2   0.9.2+dfsg-1
> ii  python-jinja2 2.9.6-1
> ii  python-netaddr0.7.18-2
> ii  python-paramiko   2.0.0-1
> ii  python-pkg-resources  36.2.7-2
> ii  python-yaml   3.12-1+b1
> 
> Versions of packages ansible recommends:
> pn  python-jmespath   
> pn  python-kerberos   
> pn  python-libcloud   
> pn  python-selinux
> pn  python-winrm  
> pn  python-xmltodict  
> 
> Versions of packages ansible suggests:
> pn  cowsay   
> ii  sshpass  1.06-1
> 
> - -- Configuration Files:
> /etc/ansible/ansible.cfg changed:
> [defaults]
> gathering = smart
> ansible_managed = Ansible managed file
> retry_files_enabled = False
> [inventory]
> [privilege_escalation]
> become_method = su
> [paramiko_connection]
> [ssh_connection]
> pipelining = True
> [persistent_connection]
> [accelerate]
> [selinux]
> [colors]

Bug#884008: [Filesystems-devel] Bug#884008: aufs-dkms: aufs triggers kernel WARN during boot

[sfjro]

Hello Jan,

Jan Luca Naumann:
> the following Debian bug (see also webpage [1]) seems to be a upstream
> problem of the aufs-kernel-module. Could you take a look into it?

Please provide me these necessary info.

(from aufs README file)
--
When you have any problems or strange behaviour in aufs, please let me
know with:
- /proc/mounts (instead of the output of mount(8))
- /sys/module/aufs/*
- /sys/fs/aufs/* (if you have them)
- /debug/aufs/* (if you have them)
- linux kernel version
  if your kernel is not plain, for example modified by distributor,
  the url where i can download its source is necessary too.
- aufs version which was printed at loading the module or booting the
  system, instead of the date you downloaded.
- configuration (define/undefine CONFIG_AUFS_xxx)
- kernel configuration or /proc/config.gz (if you have it)
- behaviour which you think to be incorrect
- actual operation, reproducible one is better
- mailto: aufs-users at lists.sourceforge.net
--


J. R. Okajima

Bug#879801: ftbfs with icu from experimental

[Norbert Preining]

> Not sure if it is useful: I've replaced "rm -f" by "rm -fv". Now the
> build runs OK and reports which files are really found (and removed).

Very useful!

I think I have removed now all useless rm statements (the
fmtutil.cnf/updmap.cfg and the long with ep2all etc ... interesting).

Thanks a lot!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#879639: squid takes 30 seconds to restart, should be < 1 second

[Amos Jeffries]

Package: squid
Version: 4.0.21-1~exp5

This should be fixed in the upcoming Squid-4 packages.

Amos Jeffries

Bug#878115: plymouthd: random crash (SIGSEGV) during shutdown for reboot

[Paul Wise]

Control: retitle -1 plymouthd: crash (SIGSEGV) during shutdown for reboot
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=104204

On Tue, 10 Oct 2017 11:53:26 +0800 Paul Wise wrote:

> During the shutdown process for rebooting I got a random crash
> (SIGSEGV) of the plymouthd process.

Looks like it isn't random and happens every time I reboot.
I've forwarded the crash to upstream, URL is available above.

$ sudo gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt 
full' --core /var/crash/0/765-0-0-11-1512873881-chianamo--sbin-plymouthd.core 
/sbin/plymouthd
[New LWP 765]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `@sbin/plymouthd --mode=shutdown --attach-to-session'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
#0  0x7f917f290f46 in strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x7f917f290c6e in __GI___strdup (s=0x0) at strdup.c:41
#2  0x7f917f5c0fb0 in ply_renderer_load_plugin (module_path=0x7f917f5c52b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so", renderer=0x562aa6b81a60) 
at ply-renderer.c:160
#3  0x7f917f5c0fb0 in ply_renderer_open_plugin (plugin_path=0x7f917f5c52b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so", renderer=0x562aa6b81a60) 
at ply-renderer.c:238
#4  0x7f917f5c0fb0 in ply_renderer_open 
(renderer=renderer@entry=0x562aa6b81a60) at ply-renderer.c:281
#5  0x7f917f5b8b82 in create_devices_for_terminal_and_renderer_type 
(manager=0x562aa6b80440, device_path=0x0, terminal=0x562aa6b804e0, 
renderer_type=PLY_RENDERER_TYPE_AUTO) at ply-device-manager.c:683
#6  0x562aa622653b in load_devices 
(flags=PLY_DEVICE_MANAGER_FLAGS_IGNORE_UDEV, state=0x7ffc246e3a50) at 
main.c:1130
#7  0x562aa622653b in main (argc=3, argv=0x7ffc246e4c38) at main.c:2368

Thread 1 (Thread 0x7f917fbbeb80 (LWP 765)):
#0  0x7f917f290f46 in strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x7f917f290c6e in __GI___strdup (s=0x0) at strdup.c:41
len = 
new = 
#2  0x7f917f5c0fb0 in ply_renderer_load_plugin (module_path=0x7f917f5c52b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so", renderer=0x562aa6b81a60) 
at ply-renderer.c:160
get_renderer_backend_interface = 
i = 
known_plugins = {{type = PLY_RENDERER_TYPE_X11, path = 0x7f917f5c52b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so"}, {type = 
PLY_RENDERER_TYPE_DRM, path = 0x7f917f5c52f0 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so"}, {type = 
PLY_RENDERER_TYPE_FRAME_BUFFER, path = 0x7f917f5c5328 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/frame-buffer.so"}, {type = 
PLY_RENDERER_TYPE_NONE, path = 0x0}}
__func__ = "ply_renderer_open"
#3  0x7f917f5c0fb0 in ply_renderer_open_plugin (plugin_path=0x7f917f5c52b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so", renderer=0x562aa6b81a60) 
at ply-renderer.c:238
i = 
known_plugins = {{type = PLY_RENDERER_TYPE_X11, path = 0x7f917f5c52b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so"}, {type = 
PLY_RENDERER_TYPE_DRM, path = 0x7f917f5c52f0 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so"}, {type = 
PLY_RENDERER_TYPE_FRAME_BUFFER, path = 0x7f917f5c5328 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/frame-buffer.so"}, {type = 
PLY_RENDERER_TYPE_NONE, path = 0x0}}
__func__ = "ply_renderer_open"
#4  0x7f917f5c0fb0 in ply_renderer_open 
(renderer=renderer@entry=0x562aa6b81a60) at ply-renderer.c:281
i = 
known_plugins = {{type = PLY_RENDERER_TYPE_X11, path = 0x7f917f5c52b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so"}, {type = 
PLY_RENDERER_TYPE_DRM, path = 0x7f917f5c52f0 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so"}, {type = 
PLY_RENDERER_TYPE_FRAME_BUFFER, path = 0x7f917f5c5328 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/frame-buffer.so"}, {type = 
PLY_RENDERER_TYPE_NONE, path = 0x0}}
__func__ = "ply_renderer_open"
#5  0x7f917f5b8b82 in create_devices_for_terminal_and_renderer_type 
(manager=0x562aa6b80440, device_path=0x0, terminal=0x562aa6b804e0, 
renderer_type=PLY_RENDERER_TYPE_AUTO) at ply-device-manager.c:683
old_renderer = 0x0
renderer = 0x562aa6b81a60
keyboard = 0x0
__func__ = "create_devices_for_terminal_and_renderer_type"
#6  0x562aa622653b in load_devices 
(flags=PLY_DEVICE_MANAGER_FLAGS_IGNORE_UDEV, state=0x7ffc246e3a50) at 
main.c:1130
state = {loop = 0x562aa6b79150, boot_server = 0x562aa6b7bb30, 
boot_splash = 0x0, session = 0x562aa6b7bc50, boot_buffer = 0x562aa6b7be30, 
progress = 0x562aa6b801a0, keystroke_triggers = 0x562aa6b7aaa0, entry_triggers 
= 0x562aa6b7aac0, entry_buffer = 0x562aa6b7aae0, messages = 0x562aa6b7bb10, 
command_parser = 0x562aa6b79010, mode = PLY_MODE_SHUTDOWN, 

Bug#884060: iproute2: Upgrade from 4.9.0-2 to 4.9.0-2.1 breaks wireless.

[Van]

Package: iproute2
Version: 4.9.0-2
Severity: normal

Dear Maintainer,

Upgrade back in November broke wireless.  Downgrading to 4.9.0-2 fixes
the issue.  If you need log info, please tell me what you need.  This is
my first bug report, so I'm a newbie.
Wireless Info:
Broadcom BCM4352 802.11ac
Driver:  r8169

Using broadcom-sta-dkms version 6.30.223.271-7


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iproute2 depends on:
ii  libc62.25-3
ii  libdb5.3 5.3.28-13.1+b1
ii  libelf1  0.170-0.1
ii  libmnl0  1.0.4-2
ii  libselinux1  2.7-2

Versions of packages iproute2 recommends:
pn  libatm1   
ii  libxtables12  1.6.1-2+b1

Versions of packages iproute2 suggests:
pn  iproute2-doc  

-- no debconf information

Bug#874706:

[nurupo]

Looks like this bug got resolved. Had the same issue before, but it got
fixed in the latest (4:17.08.3-1) version of the package.

Bug#884061: linux-image-4.9.0-4-amd64: screen scrolls wildly

[Vagrant Cascadian]

Package: src:linux
Version: 4.9.65-3
Severity: normal

Since upgrading to 4.9.65-3, my screen occasionally starts rapidly
scrolling sideways, flashing on and off repeatedly... looks almost like
the refresh rate or sync was off, and it's displaying the leftmost part
of the screen on the rightmost or the top of the display in the middle
of the screen and other similar behaviors...

When this starts to happen, usually there is a log in the dmesg output
like this:

  [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

Closing the lid and openening it again seems to fix it for a while, or
makes it less severe (e.g. brief moments where the screen slides around
or flickers).

I'm going to try to find the last kernel version before I upgraded and
see if I the issue is also triggered on that...

live well,
  vagrant


-- Package-specific info:
** Version:
Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3 (2017-12-03)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-4-amd64 root=/dev/mapper/yucca--vg-root ro quiet

** Not tainted

** Kernel log:
[   15.039432] tun: Universal TUN/TAP device driver, 1.6
[   15.039434] tun: (C) 1999-2004 Max Krasnyansky 
[   20.700661] input: BYDPS/2 BYD TouchPad as 
/devices/platform/i8042/serio1/input/input16
[   80.954137] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
[  170.836656] PM: Syncing filesystems ... done.
[  170.842268] PM: Preparing system for sleep (mem)
[  170.842382] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  170.843569] Freezing remaining freezable tasks ... (elapsed 0.003 seconds) 
done.
[  170.846679] PM: Suspending system (mem)
[  170.846687] Suspending console(s) (use no_console_suspend to debug)
[  170.846858] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  170.847683] sd 0:0:0:0: [sda] Stopping disk
[  171.622232] PM: suspend of devices complete after 775.439 msecs
[  171.641624] PM: late suspend of devices complete after 19.389 msecs
[  171.642387] xhci_hcd :00:14.0: System wakeup enabled by ACPI
[  171.681571] PM: noirq suspend of devices complete after 39.943 msecs
[  171.681842] ACPI: Preparing to enter system sleep state S3
[  171.681903] ACPI : EC: event blocked
[  171.681903] ACPI : EC: EC stopped
[  171.681904] PM: Saving platform NVS memory
[  171.681905] Disabling non-boot CPUs ...
[  171.683157] smpboot: CPU 1 is now offline
[  171.683865] Broke affinity for irq 49
[  171.684874] smpboot: CPU 2 is now offline
[  171.685248] Broke affinity for irq 1
[  171.685255] Broke affinity for irq 9
[  171.685260] Broke affinity for irq 12
[  171.685273] Broke affinity for irq 47
[  171.685274] Broke affinity for irq 49
[  171.686288] smpboot: CPU 3 is now offline
[  171.687652] ACPI: Low-level resume complete
[  171.687705] ACPI : EC: EC started
[  171.687706] PM: Restoring platform NVS memory
[  171.688023] Suspended for 4.062 seconds
[  171.688050] Enabling non-boot CPUs ...
[  171.688106] x86: Booting SMP configuration:
[  171.688106] smpboot: Booting Node 0 Processor 1 APIC 0x1
[  171.690656]  cache: parent cpu1 should not be sleeping
[  171.690885] CPU1 is up
[  171.690936] smpboot: Booting Node 0 Processor 2 APIC 0x3
[  171.693606]  cache: parent cpu2 should not be sleeping
[  171.694177] CPU2 is up
[  171.694277] smpboot: Booting Node 0 Processor 3 APIC 0x2
[  171.697493]  cache: parent cpu3 should not be sleeping
[  171.698318] CPU3 is up
[  171.706857] ACPI: Waking up from system sleep state S3
[  171.727103] xhci_hcd :00:14.0: System wakeup disabled by ACPI
[  171.747157] PM: noirq resume of devices complete after 40.223 msecs
[  171.747360] PM: early resume of devices complete after 0.186 msecs
[  171.747431] ACPI : EC: event unblocked
[  171.747529] ath: phy0: ASPM enabled: 0x43
[  171.757620] sd 0:0:0:0: [sda] Starting disk
[  171.820062] rtc_cmos 00:03: System wakeup disabled by ACPI
[  172.070341] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  172.070732] ata1.00: supports DRM functions and may not be fully accessible
[  172.072477] ata1.00: disabling queued TRIM support
[  172.073107] ata1.00: supports DRM functions and may not be fully accessible
[  172.073834] ata1.00: disabling queued TRIM support
[  172.074067] ata1.00: configured for UDMA/133
[  172.175151] PM: resume of devices complete after 427.782 msecs
[  172.175516] PM: Finishing wakeup.
[  172.175518] Restarting tasks ... done.
[  172.267311] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[  172.295044] usb 1-5: new full-speed USB device number 6 using xhci_hcd
[  172.309093] r8169 :02:00.0 enp2s0: link down
[  172.309140] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[  172.310073] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[  172.415056] usb 1-5: device descriptor read/64, error -71
[  172.643192] usb 1-5: device descriptor read/64, error -71
[  172.875059] usb 1-5: new full-speed USB 

Bug#875572: unifont FTCBFS: many reasons

[Paul Hardy]

On Tue, Oct 31, 2017 at 1:52 PM, Manuel A. Fernandez Montecelo
 wrote:
> Control: tags -1 + pending

I just want to note that this has not fallen off my radar.  I have
already applied the patch in the upcoming version.

I am hoping to provide a resolution to over 40 bug reports that
someone has made against Unifont over the past few months on Savannah:

https://savannah.gnu.org/bugs/?group=unifont

I hope to get through most of those over the next month, and then
provide an updated version for Debian.  I had worked through many more
for the current Unifont release.

This Debian bug was mentioned as being low priority, so I would like
to submit the next release with as many updates as possible versus a
"micro-release".

I also recently helped the HarfBuzz maintainer identify a HarfBuzz
bug.  HarfBuzz renders glyphs for Pango, which in turn renders text
for GNOME.  I was not sure if there was something deep down in
Unifont's structure that I would have to update, but that turns out
not to be the case:

https://bugzilla.gnome.org/show_bug.cgi?id=787284

If anyone does need this patch applied urgently, let me know and I
will be able to fix it the following weekend.  Otherwise, I am
planning for a Unifont update with a lot of glyph fixes.

Thank you,


Paul Hardy

Bug#875433: The packages "list of files" data has not been updated for at least TWO YEARS

[David Steele]

severity -1 important

On the packages.d.o binary packages pages, a "list of files" link is offered 
for every supported
architecture. For (at least many) packages that have been introduced in the 
last two years, that link points to a page that says "No such package in this 
suite on this architecture".

https://packages.debian.org/sid/net/comitup
https://packages.debian.org/sid/all/comitup/filelist

https://packages.debian.org/sid/gocryptfs
https://packages.debian.org/sid/arm64/gocryptfs/filelist

https://packages.debian.org/sid/golang-github-rfjakob-eme-dev
https://packages.debian.org/sid/all/golang-github-rfjakob-eme-dev/filelist

For older packages, the information is way stale. The gnome-gmail package 
introduced the file gnomegmail.py in 2015, but it is not represented in the 
displayed list of files.

https://packages.debian.org/sid/gnome/gnome-gmail
https://packages.debian.org/sid/all/gnome-gmail/filelist

This feature should be fixed or removed in the short term.

Bumping severity because two years.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#884062: python-cryptography: please update to 2.1.4

[Sandro Tosi]

Package: python-cryptography
Version: 1.7.1-3
Severity: wishlist

Hello,
the latest pyopenssl release (17.5.0) depends on cryptography 2.1.4, but debian
currently has 2.1.3 - could you please update it?

Thanks,
Sandro

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-cryptography depends on:
ii  libc62.24-11
ii  libssl1.11.1.0f-3
ii  python   2.7.13-2
pn  python-cffi-backend-api-max  
pn  python-cffi-backend-api-min  
ii  python-enum341.1.6-1
ii  python-idna  2.2-1
ii  python-ipaddress 1.0.17-1
ii  python-pyasn10.1.9-2
ii  python-setuptools33.1.1-1
ii  python-six   1.10.0-4

python-cryptography recommends no packages.

Versions of packages python-cryptography suggests:
pn  python-cryptography-doc  
pn  python-cryptography-vectors  

-- no debconf information

Bug#883966: debian-policy: please add MIT/Expat to common licenses

[Russ Allbery]

Markus Koschany  writes:

> as discussed on debian-devel [1] I would like to see that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are just allowed to reference them.

> License: MIT / Expat
> Source: https://opensource.org/licenses/mit-license.php
> Example packages: https://wiki.debian.org/DFSGLicenses#The_MIT_License

I continue to be concerned that adding any version of this license to
common-licenses will create a trap for the unwary.  There are very
frequent wording differences in the exact terms of this license between
different packages, and any version that doesn't exactly match the wording
that we include in common-licenses still legally needs to be reproduced in
the package's copyright file.  And this is an error that's very hard to
find with Lintian.

-- 
Russ Allbery (r...@debian.org)   

Bug#884065: mariadb-10.2: CVE-2017-10378 CVE-2017-10268 CVE-2017-15365

[Salvatore Bonaccorso]

Source: mariadb-10.2
Version: 10.2.7-1
Severity: grave
Tags: security upstream

Hi,

the following vulnerabilities were published for mariadb-10.2, these
are fixed in 10.2.10.

CVE-2017-10378[0]:
| Vulnerability in the MySQL Server component of Oracle MySQL
| (subcomponent: Server: Optimizer). Supported versions that are
| affected are 5.5.57 and earlier, 5.6.37 and earlier and 5.7.11 and
| earlier. Easily exploitable vulnerability allows low privileged
| attacker with network access via multiple protocols to compromise
| MySQL Server. Successful attacks of this vulnerability can result in
| unauthorized ability to cause a hang or frequently repeatable crash
| (complete DOS) of MySQL Server. CVSS 3.0 Base Score 6.5 (Availability
| impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

CVE-2017-10268[1]:
| Vulnerability in the MySQL Server component of Oracle MySQL
| (subcomponent: Server: Replication). Supported versions that are
| affected are 5.5.57 and earlier, 5.6.37 and earlier and 5.7.19 and
| earlier. Difficult to exploit vulnerability allows high privileged
| attacker with logon to the infrastructure where MySQL Server executes
| to compromise MySQL Server. Successful attacks of this vulnerability
| can result in unauthorized access to critical data or complete access
| to all MySQL Server accessible data. CVSS 3.0 Base Score 4.1
| (Confidentiality impacts). CVSS Vector:
| (CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N).

CVE-2017-15365[2]:
Replication in sql/event_data_objects.cc occurs before ACL checks

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-10378
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10378
[1] https://security-tracker.debian.org/tracker/CVE-2017-10268
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10268
[2] https://security-tracker.debian.org/tracker/CVE-2017-15365
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15365

Regards,
Salvatore

Bug#883761: libgdamm5.0: Includes "docs/reference/html/jquery.js" listed in Files-Excluded header

[Jeremy Bicha]

Control: severity -1 normal

On Thu, Dec 7, 2017 at 5:20 AM, Chris Lamb  wrote:
> libgdamm5.0 lists "docs/reference/html/jquery.js" in the Files-Excluded field 
> in
> debian/copyright but the source tree contain docs/reference/html/jquery.js.
>
> This is probably a DFSG violation, or at the upstream tarball was not
> repacked as intended. Alternatively, the field is simply out of date.

What really happened here is that I intentionally used the original
tarball so that the updated packaging could be synced to Ubuntu, which
requires the original tarball to match.

I don't think this is at all a DFSG violation (or if it is, it is very
minor) since the bundled jquery.js is intentionally not included in
the binary packages. This will all be fixed whenever upstream releases
a new version.

I'm lowering the severity because there is no need to kick the package
out of Testing for this.

goocanvasmm-2.0 has the same situation.

Thanks,
Jeremy Bicha

Bug#866758: upgrade-reports: Gnome3 boots only to Wayland session

[Roger Takeshi Imai]

Package: upgrade-reports
Followup-For: Bug #866758


Following the Debian upgrade below, GDM3 boots to a blank *graphical desktop* 
when Default X11 login is selected. Desktop shuts down automatically after 
several minutes, (usually.)

The cursor is active at login prompt, then disappears if 'System X11 Default,' 
'Gnome,' 'Gnome Classic,' is selected and the login button is pressed. An 
unresponsive desktop background displays with no cursor.

The desktop appears to start normally only when 'Gnome on Wayland' is selected. 
(However, some applications still have display issues on Wayland, including 
Gedit. Therefore, this workaround is not very satisfactory.)


Commandline: /usr/bin/unattended-upgrade
Upgrade: libxcursor1:amd64 (1:1.1.14-1+b4, 1:1.1.14-1+deb9u1)
End-Date: 2017-12-09  00:11:57

Start-Date: 2017-12-10  19:54:15
Commandline: packagekit role='update-packages'
Upgrade: dbus-x11:amd64 (1.10.22-0+deb9u1, 1.10.24-0+deb9u1), libdbus-1-3:amd64 
(1.10.22-0+deb9u1, 1.10.24-0+deb9u1), linux-libc-dev:amd64 (4.9.51-1, 
4.9.65-3), fig2dev:amd64 (1:3.2.6a-2, 1:3.2.6a-2+deb9u1), transfig:amd64 
(1:3.2.6a-2, 1:3.2.6a-2+deb9u1), dbus:amd64 (1.10.22-0+deb9u1, 
1.10.24-0+deb9u1), python2.7-minimal:amd64 (2.7.13-2, 2.7.13-2+deb9u2), 
libsqlite3-0:amd64 (3.16.2-5, 3.16.2-5+deb9u1), libicu57:amd64 (57.1-6, 
57.1-6+deb9u1), liblouis12:amd64 (3.0.0-3+b1, 3.0.0-3+deb9u1), 
linux-image-4.9.0-4-amd64:amd64 (4.9.51-1, 4.9.65-3), libpython2.7:amd64 
(2.7.13-2, 2.7.13-2+deb9u2), python2.7:amd64 (2.7.13-2, 2.7.13-2+deb9u2), 
python3-louis:amd64 (3.0.0-3, 3.0.0-3+deb9u1), 
linux-headers-4.9.0-4-common:amd64 (4.9.51-1, 4.9.65-3), 
linux-compiler-gcc-6-x86:amd64 (4.9.51-1, 4.9.65-3), gdm3:amd64 (3.22.3-3, 
3.22.3-3+deb9u1), gir1.2-gdm-1.0:amd64 (3.22.3-3, 3.22.3-3+deb9u1), 
libxkbcommon-x11-0:amd64 (0.7.1-1, 0.7.1-2~deb9u1), libgdm1:amd64 (3.22.3-3, 
3.22.3-3+deb9u1), linux-kbuild-4.9
 :amd64 (4.9.51-1, 4.9.65-3), iproute2:amd64 (4.9.0-1, 4.9.0-1+deb9u1), 
openssh-client:amd64 (1:7.4p1-10+deb9u1, 1:7.4p1-10+deb9u2), 
libpython2.7-minimal:amd64 (2.7.13-2, 2.7.13-2+deb9u2), liblouis-data:amd64 
(3.0.0-3, 3.0.0-3+deb9u1), linux-headers-4.9.0-4-amd64:amd64 (4.9.51-1, 
4.9.65-3), dbus-user-session:amd64 (1.10.22-0+deb9u1, 1.10.24-0+deb9u1), 
libpython2.7-stdlib:amd64 (2.7.13-2, 2.7.13-2+deb9u2), libxkbcommon0:amd64 
(0.7.1-1, 0.7.1-2~deb9u1), base-files:amd64 (9.9+deb9u2, 9.9+deb9u3)
End-Date: 2017-12-10  19:56:04

~$ uname -r
4.9.0-4-amd64

~$ lsb_release -d
Description:Debian GNU/Linux 9.3 (stretch)

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#884047: [Pkg-crosswire-devel] Bug#884047: bibledit: please make the build reproducible

[Teus Benschop]

Thank you for that, I will look into this, and see that such build-files
won't make it to the data directory, as it indeed should not. Thanks again
for noticing this!

On Sun, 10 Dec 2017 at 21:33 Chris Lamb  wrote:

> Source: bibledit
> Version: 5.0.331-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the Reproducible Builds effort [0], we noticed
> that bibledit could not be built reproducibly.
>
> This is because it uselessly ships config.log etc. in the binary
> packages which include all sorts of environment-specific data.
>
> Patch attached that simply doesn't install these files... BUT it looks
> like there is a whole bunch of cruft in the -data package anyway,
> essentially including the build-directory itself (with Makefile.am etc.
> etc.)
>
> In other words, only specifying the stuff bibledit really needs in
> bibledit-data.install would be the superior solution. :)
>
>  [0] https://reproducible-builds.org/
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
> ___
> Pkg-crosswire-devel mailing list
> pkg-crosswire-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-crosswire-devel

Bug#883980: Fifth Manifestation

[Gerard M. Vignes]

I was using the latest, built-in version of Firefox ESR 52.5.2 (64-bit), 
and I noticed that I got the same, consistent problem as with Chromium.


When I move the mouse cursor between surrounding page and embedded video 
(either direction), the screen goes black for 1 second. This behavior is 
identical to what I experience in Chromium.


This is the list of applications for which I have seen this problem so far:
Chromium
Terminator
Terminal running Bash
Software
Firefox ESR

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Gudjon I. Gudjonsson]

Hi Sven and Andreas

I'm terribly sorry for having missed the bug.
There is a new version in SVN (27) that is not fully prepared but will
be in the next few days. If somebody is willing to sponsor it I will be
very happy.

Andreas: Moving from SVN to git is fine by me, I will try to find out how to do 
that.

Regards
Gudjon

Bug#884023: [Pkg-crosswire-devel] Bug#884023: bibledit: Installs same file as bibledit-gtk

[Teus Benschop]

Thank you for the remark about the same file that gets shipped in
"bibledit-gtk" and in "bibledit".
Recently we had a fix for this on Ubuntu too, not sure why this fix didn't
make it to Debian.
I'll have a look at this one to get it fixed.
Thanks!

On Sun, 10 Dec 2017 at 16:18 Jeremy Bicha  wrote:

> Source: bibledit
> Version: 5.0.331-1
> Severity: serious
>
> Both bibledit-gtk and bibledit ship the same file:
> /usr/share/pixmaps/bibledit.xpm
>
> See § 7.6.1 of Debian Policy which recommends that you use Breaks/Replaces
> here.
> https://www.debian.org/doc/debian-policy/#document-ch-relationships
>
> Also, I highly recommend that you add a transitional package so that
> people using bibledit-gtk will be upgraded to bibledit.
>
> Thanks,
> Jeremy Bicha
>
> ___
> Pkg-crosswire-devel mailing list
> pkg-crosswire-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-crosswire-devel

Bug#884014: apparmor: AppArmor does not allow Thunderbird to open Hyperlinks with Chromium

[intrigeri]

Control: tag -1 + upstream
Control: tag -1 + fixed-upstream

Hi Martin!

Martin:
> if Chromium is configured as the default web browser, then clicking a 
> hyperlink
> in Thunderbird has no effect. The following error message is printed:

>   Failed to execute child process “/usr/bin/chromium” (Permission denied).

Thanks for reporting.

> After having a look at /etc/apparmor.d/abstractions/ubuntu-browsers, I noticed
> that the only lines referring to chromium are the following:

>   /usr/bin/chromium-browser Cx -> sanitized_helper,
>   /usr/lib/chromium-browser/chromium-browser Cx -> sanitized_helper,

> These paths appear to be incorrect. On Debian testing at least, they should
> read as follows:

>   /usr/bin/chromium Cx -> sanitized_helper,
>   /usr/lib/chromium/chromium Cx -> sanitized_helper,

Right, we've fixed this upstream a few months ago:
https://gitlab.com/apparmor/apparmor/commit/cc5a23d4c1236a0221f7bae0fd3d59f583ec9a1d

> However, while this does allow Thunderbird to execute /usr/bin/chromium, it
> still doesn't fix the problem. Clicking on a hyperlink now prints the 
> following
> stack trace to the console:

> /usr/lib/chromium/chrome-sandbox: error while loading shared libraries:

I believe an update of abstractions/ubuntu-helpers is needed to fix
that, see the second part of the commit I've linked to above.
Can you please confirm?

So this should be fixed in Debian once we package AppArmor 2.11.95
(aka. 2.12~beta1), unless someone wants to cherry-pick this commit as
a Debian patch for now.

Cheers,
-- 
intrigeri

Bug#884069: system cannot boot after upgrade to Debian 8.10

[Rolandas Naujikas]

Severity: critical

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Andreas Tille]

Hi Gudjon,

On Mon, Dec 11, 2017 at 06:58:10AM +0100, Gudjon I. Gudjonsson wrote:
> I'm terribly sorry for having missed the bug.
> There is a new version in SVN (27) that is not fully prepared but will
> be in the next few days. If somebody is willing to sponsor it I will be
> very happy.

I'll do.
 
> Andreas: Moving from SVN to git is fine by me, I will try to find out how to 
> do that.

I have a migration script and will run this, move to Git and will tell
you once it is done.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#883997: libkscreenlocker5: screen lock with photo slideshow eats up all memory and triggers oom killer

[Philipp Huebner]

Package: libkscreenlocker5
Version: 5.10.5.1-1
Severity: important

Hi,

I'm using the screenlocker's slideshow feature to display another photo
every 5 seconds out of a choice of ~4000.

After a couple of hours sddm freezes completely, no reaction to any
mouse or keyboard input, except the magic key combination ctrl+alt+b to force an
immediate reboot.

Looking at syslog after the reboot, I see that oom killer was triggered
several times, as there was no free RAM and no free SWAP left any more.
It also shows that libkscreenlocker5 is using by far the most memory,
and every time oom killer is invoked, libkscreenlocker5 is using even
more memory than before, e.g. total_vm 7549136 -> 7589587.

For reference: this box has 16 GB of memory + 16 GB of swap and only
runs standard office applications.


Regards,
Philipp


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libkscreenlocker5 depends on:
ii  kpackagetool5 5.37.0-2
ii  libc6 2.25-3
ii  libkf5configcore5 5.37.0-2
ii  libkf5configgui5  5.37.0-2
ii  libkf5coreaddons5 5.37.0-2
ii  libkf5crash5  5.37.0-2
ii  libkf5declarative55.37.0-2+b1
ii  libkf5globalaccel55.37.0-2
ii  libkf5i18n5   5.37.0-2
ii  libkf5idletime5   5.37.0-2
ii  libkf5notifications5  5.37.0-2
ii  libkf5package55.37.0-2
ii  libkf5quickaddons55.37.0-2+b1
ii  libkf5waylandclient5  4:5.37.0-2
ii  libkf5waylandserver5  4:5.37.0-2
ii  libkf5windowsystem5   5.37.0-2
ii  libpam0g  1.1.8-3.6
ii  libqt5core5a  5.9.2+dfsg-6
ii  libqt5dbus5   5.9.2+dfsg-6
ii  libqt5gui55.9.2+dfsg-6
ii  libqt5network55.9.2+dfsg-6
ii  libqt5qml55.9.2-3
ii  libqt5quick5  5.9.2-3
ii  libqt5widgets55.9.2+dfsg-6
ii  libqt5x11extras5  5.9.2-1
ii  libstdc++67.2.0-17
ii  libwayland-client01.14.0-1+b1
ii  libwayland-server01.14.0-1+b1
ii  libx11-6  2:1.6.4-3
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb1   1.12-1
ii  libxi62:1.7.9-1

Versions of packages libkscreenlocker5 recommends:
ii  kde-config-screenlocker  5.10.5.1-1

libkscreenlocker5 suggests no packages.

-- no debconf information

Bug#883765: cups-client: Unsupported document-format "application/octet-stream".

[P V Mathew]

thanks.

On 2017-12-10 01:34, Brian Potkin wrote:

tags 883765 unreproducible
thanks.


On Sat 09 Dec 2017 at 20:06:28 +0530, P V Mathew wrote:


Sorry for the delay.
Unfortunately had to downgrade my desktop to Debian stretch. That is okay
now.

At least you are printing now.

Yes, from stretch.

The same errors occur on laptop(Debian Buster) also.  Hence, will send the
details.
Tried lp -d PDF a.ps. The subject error is printed again.

I am unable to reproduce this behaviour with printer-driver-cups-pdf.


The error_log remains empty.

Or this. Please try (as root)

  cupsfilter -p /etc/cups/PDF.ppd -m printer/foo -e /etc/services > 2>log > 
out.ps

log attached


Post log here.


The access_log remains empty.
The cups-pdf_log remains empty.
cupsd.conf is attached.

Your cupsd.conf worked for me.


also output of dpkg --get-selections |grep cups is attached.

Seems ok.

Do you have apparmor running?

Installed but not running.

regards

Mathew



log.bz2
Description: application/bzip

Bug#813525: lintian: Please make --no-tag-display-limit configurable

[Chris Lamb]

tags 813525 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=dec91f2722f6f5325e99b05a547b67e308805803


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#884000: libtcod fails to build on big endian targets

[Matthias Klose]

Package: src:libtcod
Version: 1.6.4+dfsg-1
Severity: serious
Tags: sid buster

libtcod fails to build on big endian targets

see https://buildd.debian.org/status/package.php?p=libtcod

Bug#884003: FDT overlay support

[Andre Heider]

Source: flash-kernel
Severity: wishlist

Recent u-boot versions support fdt overlays. It can load a base dtb, 
apply various overlays to it, and pass the final device tree to the kernel.


To be able to use such overlays:
1) u-boot has to be compiled with CONFIG_OF_LIBFDT_OVERLAY
2) the base dtb has to be compiled with "-@" / "--symbols"
3) all overlays have to be compiled with "-@" / "--symbols"

1: already given for debian's u-boot for ti's beagle bone black, which 
is what I tested this on

2: not the default for the kernel dtb files, I used [1] as a quick hack
3: this should just be the user's responsibility for now (until there's 
a centralized repository or something debian could just package)


With the quick boot script [2] I can then successfully boot 
debian's kernel with applied overlays of my choosing.


That's great, especially since it's way to painful to just enable basic 
stuff like spi. Now we "just" need a way for flash-kernel to support it ;)


One way could be:
- overlays need to be in /boot/dtbs/overlays
- user sets a list of overlays in /etc/defaults/flash-kernel
  like "OVERLAYS=am335x-bone-black-disable-video 
am335x-bone-black-disable-audio am335x-bone-black-spidev0 
am335x-bone-black-spidev1"

- flash-kernel passes the list of overlays to it's u-boot boot script
- the boot script loads and applies all requested overlays

[1]
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 04b5633df1cf..e339d40c02d1 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -308,7 +308,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
 quiet_cmd_dtc = DTC $@
 cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
$(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
-   $(DTC) -O dtb -o $@ -b 0 \
+   $(DTC) -@ -O dtb -o $@ -b 0 \
$(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \
-d $(depfile).dtc.tmp $(dtc-tmp) ; \
cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)

[2]
load mmc 1 $fdt_addr_r am335x-boneblack.dtb
fdt addr $fdt_addr_r
fdt resize 8192
load mmc 1 $ramdisk_addr_r am335x-bone-black-disable-video.dtb
fdt apply $ramdisk_addr_r
load mmc 1 $ramdisk_addr_r am335x-bone-black-disable-audio.dtb
fdt apply $ramdisk_addr_r
load mmc 1 $ramdisk_addr_r am335x-bone-black-spidev0.dtb
fdt apply $ramdisk_addr_r
load mmc 1 $ramdisk_addr_r am335x-bone-black-spidev1.dtb
fdt apply $ramdisk_addr_r
...

Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Guido Günther]

Hi,
On Sun, Dec 10, 2017 at 12:51:38PM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> On Sun, Dec 10, 2017 at 10:00:55AM +0100, Salvatore Bonaccorso wrote:
> > Hi
> > 
> > Cc'ing explicitly Guido and Raphael, who commented before.
> > 
> > On Sat, Dec 09, 2017 at 03:25:14PM +0100, Markus Koschany wrote:
> > > Hi,
> > > 
> > > I have updated my patch for reportbug. Now emails are sent only to one
> > > of the team mailing lists based on the release number in the version
> > > string. There is apparently no simple way to determine the relationship
> > > between release number, code name, suite and whether this is a LTS
> > > release. So we came up with a simple json file which provides this kind
> > > of information and can be adjusted as time goes by. We think that
> > > security-tracker.debian.org would be a good place for this file but I'd
> > > appreciate it if someone from the security team told us the exact 
> > > location.
> > > 
> > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45
> > 
> > So let me first understand the information you would need from that
> > file (here in sort-of-yaml):
> > 
> > cut-cut-cut-cut-cut-cut-
> > wheezy:
> >   major-version: 7
> >   support: lts
> > jessie:
> >   major-version: 8
> >   support: security
> > stretch:
> >   major-version: 9
> >   support: security
> > buster:
> >   major-version: 10
> >   support: none
> > bullseye:
> >   major-version: 11
> >   support: none
> > cut-cut-cut-cut-cut-cut-
> 
> But rather in JSON than YAML. Florian would not recommend using YAML, and
> furthermore it's more consistent with the tracker itself.
> 
> cut-cut-cut-cut-cut-cut-
> {
>   "wheezy": {
> "major-version": "7",
> "support": "lts"
>   },
>   "jessie": {
> "major-version": "8",
> "support": "security"
>   },
>   "stretch": {
> "major-version": "9",
> "support": "security"
>   },
>   "buster": {
> "major-version": "10",
> "support": "none"
>   },
>   "bullseye": {
> "major-version": "11",
> "support": "none"
>   }
> }
> cut-cut-cut-cut-cut-cut-
> 
> and beeing accessible under 
> https://security-tracker.debian.org/tracker/distributions.json

That makes as lot of sense! (I used YAML in the example for readability,
output of the tracker should be JSON). The main reason why I'd prefer
the tracker is that we can update the file ourselves when switching
releases.
Cheers,
 -- Guido

Bug#884007: systemtap FTBFS on ia64

[Jason Duerstock]

Source: systemtap
Severity: normal
Tags: patch

Dear Maintainer,

systemtap fails to build from source on ia64.  The attached patch should 
correct the problem spots.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- systemtap-3.1/includes/sys/sdt.h2017-12-10 06:50:27.0 -0500
+++ systemtap-3.1.orig/includes/sys/sdt.h   2017-12-10 06:32:44.722028094 
-0500
@@ -84,8 +84,12 @@
 # define _SDT_ARGFMT(no)   %n[_SDT_S##no]@_SDT_ARGTMPL(_SDT_A##no)
 
 # ifndef STAP_SDT_ARG_CONSTRAINT
+# ifdef __ia64__
+# define STAP_SDT_ARG_CONSTRAINTnr
+# else
 # define STAP_SDT_ARG_CONSTRAINTnor
 # endif
+# endif
 
 # define _SDT_STRINGIFY(x)  #x
 # define _SDT_ARG_CONSTRAINT_STRING(x)  _SDT_STRINGIFY(x)
--- systemtap-3.1/python/HelperSDT/_HelperSDT.c 2017-02-17 12:37:01.0 
-0500
+++ systemtap-3.1.orig/python/HelperSDT/_HelperSDT.c2017-12-10 
06:31:28.625516044 -0500
@@ -154,7 +154,11 @@
// it with the asm() statement. Otherwise we get a @GOTPCREL
// reference which stap can't parse.
void *fptr = _GenericGetAttr;
+#ifdef __ia64__
+   asm ("nop 0" : "=r"(fptr) : "r"(fptr));
+#else
asm ("nop" : "=r"(fptr) : "r"(fptr));
+#endif
STAP_PROBE2(HelperSDT, Init, stap_module, fptr);
 }
 return module;

Bug#863612: opendmarc: still ignore inet SOCKET configuration

[FOSS]

The whole issue is with the systemd unit hardcoding the paths, which is 
what that patch addresses.


I've been bitten by this as well, and I put a modified systemd unit in 
/etc/systemd/system, so as long as this doesn't get fixed any package 
upgrades don't break opendmarc.


Stijn

On Tue, 31 Oct 2017 16:11:40 -0700 Jack Bates <3ou...@nottheoilrig.com> 
wrote:

> Control: tags -1 patch
>
> I ran into this issue as well -- the following patch fixed it for me:
> http://nottheoilrig.com/options.patch
>
> I copied the default settings from opendmarc.service to 
opendmarc.conf

> (PidFile, Socket, and UserID). The administrator can continue to
> override the service, as before (with
> /etc/systemd/system/opendmarc.service.d/override.conf or "systemctl 
edit
> opendmarc"). However if they don't, the settings in 
/etc/opendmarc.conf
> are respected. Likewise the administrator can continue to configure 
the

> SysV init in /etc/default/opendmarc, as before.
>
> Whether or not the administrator has overridden the service, this 
change
> won't alter their settings: If the override.conf exists, then it'll 
be
> used, same as before. Otherwise the default settings are the same as 
before.

>
> When I added the settings to debian/opendmarc.conf I also harmonized 
the

> existing settings templates with the upstream opendmarc.conf.sample.
>
>

Bug#883995: ITP: plexus-languages -- Plexus Languages

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: plexus-languages
  Version : 0.9.5
  Upstream Author : The Apache Software Foundation
* URL : https://github.com/codehaus-plexus/plexus-languages
* License : Apache-2.0
  Programming Lang: Java
  Description : Plexus Languages

Plexus Languages maintains shared language features used by the Plexus
components, such as parsing or extracting modules information in various
ways for the Java language.

This library is required to upgrade the Plexus/Maven components and address
the compatibility issues with Java 9 or later. The package will be maintained
by the Java Team.

Bug#823664: debsecan: reports new and available kernel security updates that, well, aren't

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo
Control: retitle -1 debsecan: confused if a newer version as in 
$codename-security is accepted via $codename-updates

Hi

I think the issue arises when the following situation is given:

Package has recieved an update via security: Version 1.2-3+debXuY

Via $codename-updates before a point release, and if a user has
$codename-updates in sources.list, there is an update for the package,
1.2-3+debXuZ, with 1.2-3+debXuZ > 1.2-3+debXuY but 1.2-3+debXuZ is
not in $codename yet, and only available via $codename-updates.

Recently for the point release on 2017-12-09 this happened e.g. for
bind9, which got an updates 1:9.10.3.dfsg.P4-12.3+deb9u2 via
stretch-security, but before the point release an update
1:9.10.3.dfsg.P4-12.3+deb9u3 was accepted via stretch-updates for the
DNSSEC KSK-2017 update.

Regards,
Salvatore

Bug#884001: linux-image-4.9.0-4-amd64: Severe graphics corruption on intel graphics after kernel upgrade

[Andreas Berger]

Package: src:linux
Version: 4.9.65-3
Severity: important

Hello,

After upgrading the kernel from 4.9.51-1 to 4.9.65-3 i got severe graphics 
corruption (Screen content shifts sideways, flickers, screen goes black). This 
gets progressively worse so the system is unusable about 15 minutes after 
reboot. Often the shifting and flickering seems to be triggered by keystrokes 
(any, as far as i can tell). This occured right after the upgrade and 
subsequent reboot. Switching to an older kernel fixes the issue. dmesg says:

[drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

i'll attach the file

regards,
Andi



-- Package-specific info:
** Version:
Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3 (2017-12-03)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-4-amd64 root=/dev/mapper/vg1-lv1 ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20DSS02300
product_version: ThinkPad L450
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: JDET49WW (1.11 )
board_vendor: LENOVO
board_name: Intel powered classmate PC
board_version: Not Defined

** Loaded modules:
ctr
ccm
binfmt_misc
snd_hda_codec_hdmi
btusb
btrtl
btbcm
btintel
bluetooth
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_core
videodev
snd_hda_codec_realtek
snd_hda_codec_generic
media
snd_hda_intel
iTCO_wdt
snd_hda_codec
iTCO_vendor_support
arc4
snd_hda_core
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
snd_hwdep
i915
irqbypass
snd_pcm
iwlmvm
mac80211
iwlwifi
intel_cstate
rtsx_pci_ms
memstick
drm_kms_helper
drm
snd_timer
intel_uncore
intel_rapl_perf
joydev
evdev
i2c_algo_bit
serio_raw
pcspkr
thinkpad_acpi
nvram
mei_me
mei
lpc_ich
cfg80211
snd
rfkill
sg
ac
wmi
battery
video
shpchp
soundcore
button
intel_pch_thermal
sunrpc
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
crc32c_generic
fscrypto
ecb
mbcache
algif_skcipher
af_alg
dm_crypt
dm_mod
sd_mod
hid_generic
usbhid
hid
rtsx_pci_sdmmc
mmc_core
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
ahci
libahci
aesni_intel
aes_x86_64
lrw
gf128mul
glue_helper
ablk_helper
cryptd
rtsx_pci
mfd_core
psmouse
libata
i2c_i801
scsi_mod
xhci_pci
i2c_smbus
ehci_pci
xhci_hcd
ehci_hcd
e1000e
ptp
usbcore
pps_core
usb_common
thermal

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI 
[8086:1604] (rev 09)
Subsystem: Lenovo Broadwell-U Host Bridge -OPI [17aa:503c]
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: bdw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 
[8086:1616] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo HD Graphics 5500 [17aa:503c]
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: i915
Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller 
[8086:160c] (rev 09)
Subsystem: Lenovo Broadwell-U Audio Controller [17aa:503c]
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: snd_hda_intel
Kernel modules: snd_hda_intel

00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI 
Controller [8086:9cb1] (rev 03) (prog-if 30 [XHCI])
Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller [17aa:503c]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation Wildcat Point-LP MEI 
Controller #1 [8086:9cba] (rev 03)
Subsystem: Lenovo Wildcat Point-LP MEI Controller [17aa:503c]
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: mei_me
Kernel modules: mei_me

00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) 
I218-V [8086:15a3] (rev 03)
Subsystem: Lenovo Ethernet Connection (3) I218-V [17aa:503c]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- 

Bug#884005: imagemagick-6.q16: should not connect to irc ports and timeout

[Marc Lehmann]

Package: imagemagick-6.q16
Version: 8:6.9.7.4+dfsg-11+deb9u3
Severity: normal

Dear Maintainer,

at some point after upgrading, we found that imagemagick commands hang for
extended periods of time without any activity.

strace showed the reason to be it trying to connect to the local irc
server (running on port 6668), waiting for some specific response.

as it turns out, this is due to the distributed pixel cache feature of
imagemagick.

I think there are a number of problems with that:

1) imagemagick should not try to connect a distributed pixel cache
   that isn't configured.
2) it definitely shouldn't use a port used by a well-known protocol,
   in this case, irc (which uses ports 6660-6669 or higher for decades).

Arguably, 1) is a security issue, as any local user can bind to port
6668, and this might unexpectedly leak personal data, as the shared
secret in debian is not per-user and stored in a world-readable file
(/etc/ImageMagick-6/policy.xml) and apparently defaults to "passphrase".

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
compare:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
convert:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
composite:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
conjure:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
display:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
identify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
import:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
mogrify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
montage:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
stream:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.15-1
ii  libc6  2.24-11+deb9u1
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-11+deb9u3
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-11+deb9u3

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.20~dfsg-3.2+deb9u1
ii  libmagickcore-6.q16-3-extra  8:6.9.7.4+dfsg-11+deb9u3
ii  netpbm   2:10.0-15.3+b2

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace
ii  cups-bsd [lpr]   2.2.1-8
ii  curl 7.52.1-5+deb9u3
ii  enscript 1.6.5.90-3
ii  ffmpeg   10:3.3.5-dmo1+deb9u1
ii  fig2dev [transfig]   1:3.2.6a-2
ii  gimp 2.8.18-1
ii  gnuplot  5.0.5+dfsg1-6+deb9u1
pn  grads
ii  graphviz 2.38.0-17
ii  groff-base   1.22.3-9
pn  hp2xx
pn  html2ps  
pn  imagemagick-doc  
ii  libwmf-bin   0.2.8.4-10.6
ii  mplayer  4:1.3.0~20170413.svn37931-dmo3+deb9u2
pn  povray   
ii  radiance 4R1+20120125-1.1+b1
ii  sane-utils   1.0.25-4.1
ii  texlive-binaries [texlive-base-bin]  2016.20160513.41080.dfsg-2
ii  transfig 1:3.2.6a-2
ii  ufraw-batch  0.22-1.1
ii  xdg-utils1.1.1-1

-- no debconf information

Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

[Marek Skrobacki]

​FWIW, I run into exact same kernel panic on R810. Downgrading
to 3.16.43-2+deb8u5 "resolved" the problem.


-- Marek

Bug#883994: ICE in libphobos build with trunk 20171209

[Matthias Klose]

Package: src:gcc-8
Version: 8-20171209-1

while it claims to be non-reproducible, it's seen on all x86 targets (armhf
still building)

https://buildd.debian.org/status/package.php?p=gcc-8=experimental

0x685c47 build3(tree_code, tree_node*, tree_node*, tree_node*, tree_node*)
../../src/gcc/tree.c:4537
0x833ec9 IRVisitor::visit(SwitchStatement*)
../../src/gcc/d/toir.cc:881
0x831042 IRVisitor::build_stmt(Statement*)
../../src/gcc/d/toir.cc:249
0x831042 IRVisitor::visit(CompoundStatement*)
../../src/gcc/d/toir.cc:1022
0x830d1f IRVisitor::build_stmt(Statement*)
../../src/gcc/d/toir.cc:249
0x830d1f build_function_body(FuncDeclaration*)
../../src/gcc/d/toir.cc:1425
0x825ec1 DeclVisitor::visit(FuncDeclaration*)
../../src/gcc/d/decl.cc:858
0x825547 DeclVisitor::visit(AttribDeclaration*)
../../src/gcc/d/decl.cc:217
0x826627 DeclVisitor::visit(ClassDeclaration*)
../../src/gcc/d/decl.cc:359
0x8235b1 build_decl_tree(Dsymbol*)
../../src/gcc/d/decl.cc:898
0x82eff0 build_module_tree(Module*)
../../src/gcc/d/modules.cc:716
0x82567b DeclVisitor::visit(Module*)
../../src/gcc/d/decl.cc:137
0x8235b1 build_decl_tree(Dsymbol*)
../../src/gcc/d/decl.cc:898
0x81db8e d_parse_file()
../../src/gcc/d/d-lang.cc:1224
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
Makefile:2796: recipe for target 'core/thread.lo' failed
make[6]: *** [core/thread.lo] Error 1
Makefile:412: recipe for target 'all-recursive' failed
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory '/<>/build/x86_64-linux-gnu/libphobos'
Makefile:322: recipe for target 'all' failed
make[4]: *** [all] Error 2
make[4]: Leaving directory '/<>/build/x86_64-linux-gnu/libphobos'
Makefile:22103: recipe for target 'all-target-libphobos' failed
make[3]: *** [all-target-libphobos] Error 2

Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi

Cc'ing explicitly Guido and Raphael, who commented before.

On Sat, Dec 09, 2017 at 03:25:14PM +0100, Markus Koschany wrote:
> Hi,
> 
> I have updated my patch for reportbug. Now emails are sent only to one
> of the team mailing lists based on the release number in the version
> string. There is apparently no simple way to determine the relationship
> between release number, code name, suite and whether this is a LTS
> release. So we came up with a simple json file which provides this kind
> of information and can be adjusted as time goes by. We think that
> security-tracker.debian.org would be a good place for this file but I'd
> appreciate it if someone from the security team told us the exact location.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45

So let me first understand the information you would need from that
file (here in sort-of-yaml):

cut-cut-cut-cut-cut-cut-
wheezy:
  major-version: 7
  support: lts
jessie:
  major-version: 8
  support: security
stretch:
  major-version: 9
  support: security
buster:
  major-version: 10
  support: none
bullseye:
  major-version: 11
  support: none
cut-cut-cut-cut-cut-cut-

For reportbug I do not see a need for the alias mapping, so we should
not add it it yet, or why would you need to know that wheezy is
oldoldstable for it? AFAICS, what you need for is a value to decide if
it's lts or security team supported, that is what I'm aiming for in
the above format with the support field. Once jessie moves to lts
supported, we just need to update that value. Then on reportbug side,
if the support is for lts, X-Debbugs-CC the debian-lts list, if it's
support 'security', X-Debbugs-CC the security team.

Possibly we could add a static file exporting this information on the
security-tracker which only would be needed to extend once a suite
goes over to lts support and new known releases are added. Then could
be available under
https://security-tracker.debian.org/tracker/distributions.yaml

How does your current patch for reportbug look like?

Please add my on Cc directly for replies.

Regards,
Salvatore

Bug#883998: RM: libkmahjongg -- ROM; old version, no more used

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove src:libkmahjongg, as it is the old version of it based on
kdelibs 4.x, and nothing uses it anymore.

Thanks,
-- 
Pino

Bug#883055: postgresql-contrib-9.6 (re-)installs alternative manpages of postgresql-9.6

[Christoph Berg]

Re: Michael Stapelberg 2017-11-29 
<151194305065.23272.18242117195881690843.report...@midna.lan>
> The intended state is that only the package which ships the manpage
> (postgresql-9.6 in this case) makes the update-alternatives call.
> 
> Could you please change the postinst script to not make duplicate
> update-alternatives calls? Thank you!

PG 9.6 has just been removed from unstable. For the record,
postgresql-10 should not have this problem, because the contrib
package has been merged into the main server package, so there's
nothing to call twice.

Still, the alternatives handling around PG is pretty involved (we are
still carrying legacy code around for upgrades from 9.1, where some
binary move from one package to another), and I fear the day when the
legacy "postmaster" symlink to "postgres" is going away, which we have
been using as anchor for the alternatives group so far.

Please let us know if there's any more trouble for manpages which we
could fix on the PG side.

Christoph

Bug#884004: mumudvb: DVR Read error : Value too large for defined data type (Probably kernel driver problem)

[Benoit Panizzon]

Package: mumudvb
Version: 1.7.1-1+b1
Severity: normal

Dear Maintainer,

I am using an RTL2838 DVB Stick to experiment around with multicast streaming.

When I capture the full transponder with mumdvb I get this error:

DVR Read error : Value too large for defined data type

And the stream has a hicpu every time this error occurs, about once per second.

Google tells me others observe the same problem and it is caused by a too smal 
receive
buffer in the kernel. So I don't know if this can be fixed on the mumudvb side 
or
if a kernel patch is required.

https://ubuntuforums.org/showthread.php?t=2262966=2
https://mailman.videolan.org/pipermail/dvblast-devel/2013-July/001203.html

-Benoît-


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_CH:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mumudvb depends on:
ii  adduser   3.116
ii  dvb-apps  1.1.1+rev1500-1.1+b1
ii  libc6 2.25-2

mumudvb recommends no packages.

Versions of packages mumudvb suggests:
pn  dvbtune  

-- no debconf information

Bug#883935: linux-image-4.9.0-4-amd64: i915 GPU hang after every suspend or hibernate (Hang on render ring)

[Christoph Wiedemann]

Package: src:linux
Version: 4.9.65-3
Followup-For: Bug #883935

Dear Maintainer,

I have the same issue, and I find it very annoying. As a workaround I use 
kernel linux-image-4.12.0-1-amd64, which mostly
manages to wake correctly from hibernation. But honestly, I'm a bit 
overstrained in using a testing kernel on an otherwise
stable system. I was hoping that the recent update of 4.9.0 kernel maybe fixed 
the issue, but unfortunately not. It would
be very nice if this could be fixed with a future update.

Thank you in advance!
Christoph


-- Package-specific info:
** Version:
Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3 (2017-12-03)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-4-amd64 
root=UUID=39cb1350-d7bf-43e6-9a89-f1821f0ae9b9 ro quiet 
i915.preliminary_hw_support=1

** Tainted: PUO (4161)
 * Proprietary module has been loaded.
 * Userspace-defined naughtiness.
 * Out-of-tree module has been loaded.

** Kernel log:
[  167.358244] ata1.00: supports DRM functions and may not be fully accessible
[  167.358695] ata1.00: configured for UDMA/133
[  167.383405] usb 1-4: reset high-speed USB device number 2 using xhci_hcd
[  167.643093] usb 1-7: reset full-speed USB device number 5 using xhci_hcd
[  167.903455] usb 1-6: reset full-speed USB device number 3 using xhci_hcd
[  167.910793] psmouse serio1: synaptics: queried max coordinates: x [..5676], 
y [..4758]
[  167.946771] psmouse serio1: synaptics: queried min coordinates: x [1266..], 
y [1096..]
[  168.163211] usb 1-9: reset full-speed USB device number 8 using xhci_hcd
[  168.422910] usb 1-8: reset high-speed USB device number 7 using xhci_hcd
[  168.830965] usb 1-4.2: reset low-speed USB device number 6 using xhci_hcd
[  169.387447] usb 1-4.1: reset low-speed USB device number 4 using xhci_hcd
[  169.720828] PM: restore of devices complete after 2684.862 msecs
[  169.721308] usb 1-7:1.0: rebind failed: -517
[  169.721313] usb 1-7:1.1: rebind failed: -517
[  169.721665] PM: Image restored successfully.
[  169.721774] PM: Basic memory bitmaps freed
[  169.721780] Restarting tasks ... done.
[  169.731277] thermal thermal_zone2: failed to read out thermal zone (-5)
[  169.739769] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[  169.746776] Bluetooth: hci0: Device revision is 5
[  169.746777] Bluetooth: hci0: Secure boot is enabled
[  169.746778] Bluetooth: hci0: OTP lock is enabled
[  169.746779] Bluetooth: hci0: API lock is enabled
[  169.746779] Bluetooth: hci0: Debug lock is disabled
[  169.746780] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[  169.751150] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-11-5.sfi
[  169.751153] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
[  169.865935] e1000e: eth1 NIC Link is Down
[  169.867438] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  170.075048] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  170.075720] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[  170.079558] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  170.082036] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  170.212136] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  170.212626] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  170.309080] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[  170.321546] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  170.323628] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  170.458950] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  170.459265] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  170.491370] [drm] RC6 on
[  170.553392] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[  170.603365] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[  170.629381] psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[  170.825772] input: TPPS/2 IBM TrackPoint as 
/devices/platform/i8042/serio1/serio2/input/input23
[  171.338681] Bluetooth: hci0: Waiting for firmware download to complete
[  171.338772] Bluetooth: hci0: Firmware loaded in 1562047 usecs
[  171.338958] Bluetooth: hci0: Waiting for device to boot
[  171.349737] Bluetooth: hci0: Device booted in 10636 usecs
[  171.349930] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-11-5.ddc
[  171.349932] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc
[  171.353746] Bluetooth: hci0: Applying Intel DDC parameters completed
[  174.173465] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[  182.459087] [drm] GPU HANG: ecode 9:0:0x81ba3c75, in Xorg [709], reason: 
Hang on render ring, action: reset
[  182.459089] [drm] GPU hangs can indicate a bug anywhere in the entire gfx 
stack, including userspace.
[  182.459090] [drm] Please file a _new_ bug report on bugs.freedesktop.org 
against DRI -> DRM/Intel
[  182.459091] [drm] drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.
[  182.459092] [drm] The 

Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi

On Sun, Dec 10, 2017 at 10:00:55AM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> Cc'ing explicitly Guido and Raphael, who commented before.
> 
> On Sat, Dec 09, 2017 at 03:25:14PM +0100, Markus Koschany wrote:
> > Hi,
> > 
> > I have updated my patch for reportbug. Now emails are sent only to one
> > of the team mailing lists based on the release number in the version
> > string. There is apparently no simple way to determine the relationship
> > between release number, code name, suite and whether this is a LTS
> > release. So we came up with a simple json file which provides this kind
> > of information and can be adjusted as time goes by. We think that
> > security-tracker.debian.org would be a good place for this file but I'd
> > appreciate it if someone from the security team told us the exact location.
> > 
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45
> 
> So let me first understand the information you would need from that
> file (here in sort-of-yaml):
> 
> cut-cut-cut-cut-cut-cut-
> wheezy:
>   major-version: 7
>   support: lts
> jessie:
>   major-version: 8
>   support: security
> stretch:
>   major-version: 9
>   support: security
> buster:
>   major-version: 10
>   support: none
> bullseye:
>   major-version: 11
>   support: none
> cut-cut-cut-cut-cut-cut-

But rather in JSON than YAML. Florian would not recommend using YAML, and
furthermore it's more consistent with the tracker itself.

cut-cut-cut-cut-cut-cut-
{
  "wheezy": {
"major-version": "7",
"support": "lts"
  },
  "jessie": {
"major-version": "8",
"support": "security"
  },
  "stretch": {
"major-version": "9",
"support": "security"
  },
  "buster": {
"major-version": "10",
"support": "none"
  },
  "bullseye": {
"major-version": "11",
"support": "none"
  }
}
cut-cut-cut-cut-cut-cut-

and beeing accessible under 
https://security-tracker.debian.org/tracker/distributions.json

Regards,
Salvatore

Bug#883672: Poppler 0.61 Rendering issue

[Emilio Pozuelo Monfort]

On 09/12/17 19:29, Marcus Britanicus wrote:
> I upgraded my system to the latest, and tried out viewing the same file in 
> GNOME, using evince, cinnamon, and atril in Mate. Alas nothing works. I 
> perhaps 
> should tryout a fresh install of sid and check if the issue pops up. For the 
> record, its not just that file, there are quite a few files that give this 
> issue 
> with poppler. Also for the record, a few upgrades before, I really have not 
> much 
> idea, all the rendering was quite fine.

What's the output of these two commands?

$ ldd /usr/bin/evince

$ find /usr/local/lib

Emilio

Bug#833507: wpasupplicant: Unable to connect WLAN (wlan0: CTRL-EVENT-SCAN-FAILED ret=-22)

[Andrew Shadura]

On 9 December 2017 at 17:25, YOSHINO Yoshihito  wrote:
> Package: wpasupplicant
> Version: 2:2.6-13
> Followup-For: Bug #833507
>
> Dear Maintainer,
>
> I use /etc/network/interfaces to configure networking, not network-manager.
> Upgrading wpasupplicant to >= 2:2.6 my machine (MacBook Air with broadcom-sta
> wl module) fails to connect to a wi-fi network, with a lot of syslog messages
> of "CTRL-EVENT-SCAN-FAILED ret=-22".
> Downgrading the package to 2:2.4-1.1 restores it to work fine.
>
> I do not know how to configure ifupdown to disable random mac address
> usage just as how network-manager does in
> /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf .

So how about NM? Does it work for you if you use NM?

-- 
Cheers,
  Andrew

Bug#883999: man page improper header usage

[積丹尼 Dan Jacobson]

Package: bitcoin-qt
Version: 0.15.1~dfsg-1
Severity: minor
File: /usr/share/man/man1/bitcoin-qt.1.gz

Please make this

 NAME
bitcoin-qt - manual page for bitcoin-qt v0.15.0.1

 DESCRIPTION
Bitcoin Core version v0.15.0.1-dirty (64-bit) Usage:

   bitcoin-qt [command-line options]

better conform to example:

 NAME
cat - concatenate files and print on the standard output

 SYNOPSIS
cat [OPTION]... [FILE]...

 DESCRIPTION
Concatenate FILE(s) to standard output.

Bug#883944: ejabberd: Upstream AppArmor profile

[Philipp Huebner]

Hi

> Since Debian has ongoing experiment to have AppArmor enabled by default in 
> Buster, I believe
> it would be usefull to have AppArmor profile made good enought to be enabled 
> by default for
> this internet-facing daemon too. Maybe this suggestion could make this 
> possible?

I like your proposal as long as it doesn't add too much delay when
changes are necessary.

The current "ejabberd" profile in apparmor-profiles is completely
useless and I have basically rewritten the current "ejabberdctl" profile
from scratch.

You're welcome to replace the one in apparmor-profiles with mine
and make things happen the way you described them.

Thanks!

Best wishes,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Moritz Mühlenhoff]

On Fri, Sep 15, 2017 at 03:27:58PM +0100, Steve McIntyre wrote:
> On Fri, Sep 15, 2017 at 11:45:13AM +0200, Raphaël Hertzog wrote:
> >Source: pkgsel
> >Version: 0.45
> >Severity: wishlist
> >
> >Ubuntu has a patch adding a "pkgsel/update-policy" debconf question which
> >is used to control the installation of unattended-upgrades. I want to
> >merge this into Debian.
> >
> >The biggest question in this work is the default value and priority of
> >the question.
> >
> >Ubuntu defaults to "none" (no automatic installation) but asks the
> >question at high priority on netboot (non-cdrom) images or on their
> >server images.
> >
> >For Debian, I don't think that making such a difference makes sense.
> >We should:
> >- either always show the question with its default value of "none"
> >  (thus making sure that they have a chance to opt-in to this feature)
> >- or not show the question (priority "medium") but make it default
> >  to install unattended-upgrades so that they get updates by default but
> >  have a chance to disable that with preseeding
> >
> >Given the last discussion on -devel
> >(https://lists.debian.org/debian-devel/2016/11/threads.html#00117) I think
> >we should make a bold choice and do the latter.
> >
> >I'm going to submit a tested patch later on.
> 
> Sounds reasonable, yes.

I don't think so.

This is not an adequate default for non-Desktop setups, this should rather be
pulled in via some of the desktop tasksel tasks, but not in general.

Cheers,
Moritz

Bug#857954: libdevmapper-dev: broken symlink: /usr/lib//libdevmapper-event-lvm2.so -> /lib//libdevmapper-event-lvm2.so.2.02

[August Karlstrom]

On Sat, 9 Dec 2017 17:50:30 +0100 August Karlstrom 
 wrote:

On Thu, 9 Nov 2017 16:29:24 +0100 Bastian Blank  wrote:
> On Thu, Nov 09, 2017 at 04:11:00PM +0100, Andreas Beckmann wrote:
> > The broken symlink has returned:
> 
> Ah, yes.  But please describe why this is a problem.


Because it breaks the upgrade to Debian 9.3:

Reinstalling libdevmapper solved the issue for me:

# apt-get install --reinstall libdevmapper1.02.1


-- August

Bug#884008: aufs-dkms: aufs triggers kernel WARN during boot

[Ralf Jung]

Package: aufs-dkms
Version: 4.9+20161219-1
Severity: normal

Dear Maintainer,

we have aufs installed on our server to be able to run docker.  During boot, I
see the following arror a couple dozen times:

S Sun Dec 10 12:10:27 2017 p4 kernel: aufs au_opts_verify:1607:dockerd[1339]: 
dirperm1 breaks the protection by the permission bits on the lower branch
S Sun Dec 10 12:10:27 2017 p4 kernel: [ cut here ]
S Sun Dec 10 12:10:27 2017 p4 kernel: WARNING: CPU: 0 PID: 1490 at 
/var/lib/dkms/aufs/4.9+20161219/build/fs/aufs/cpup.c:423 
au_cp_regular+0x16c/0x250 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel: .wh..wh.setup_maker_elements-i.ri.0007
Please report this warning to aufs-users ML
S Sun Dec 10 12:10:27 2017 p4 kernel: Modules linked in:
S Sun Dec 10 12:10:27 2017 p4 kernel:  aufs(O) xenfs xen_privcmd joydev 
hid_generic usbhid hid ppdev sg pcspkr parport_pc parport serio_raw evdev 
ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb 
glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 mbcache sr_mod cdrom 
ata_generic xen_netfront xen_blkfront crc32c_intel ata_piix psmouse cirrus ttm 
drm_kms_helper drm i2c_piix4 uhci_hcd ehci_hcd usbcore usb_common libata 
scsi_mod floppy button
S Sun Dec 10 12:10:27 2017 p4 kernel: CPU: 0 PID: 1490 Comm: auplink Tainted: G 
  O4.9.0-4-amd64 #1 Debian 4.9.65-3
S Sun Dec 10 12:10:27 2017 p4 kernel: Hardware name: Xen HVM domU, BIOS 
4.4.1-xs116341 01/13/2016
S Sun Dec 10 12:10:27 2017 p4 kernel:   a8928e84 
bba581ee7a60 
S Sun Dec 10 12:10:27 2017 p4 kernel:  a8675efe bba581ee7d58 
bba581ee7ab8 
S Sun Dec 10 12:10:27 2017 p4 kernel:  9512c3ab3800 9512c50e2d00 
95128a6ec780 a8675f7f
S Sun Dec 10 12:10:27 2017 p4 kernel: Call Trace:
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
dump_stack+0x5c/0x78
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? __warn+0xbe/0xe0
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
warn_slowpath_fmt+0x5f/0x80
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
au_cp_regular+0x16c/0x250 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
au_cp_regular+0x241/0x250 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
au_cp_regular+0x1b7/0x250 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
cpup_entry+0x73c/0x890 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
vfsub_lookup_one_len+0x44/0xf0 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? sprintf+0x56/0x70
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
au_cpup_single.constprop.23+0x187/0x760 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? dput+0x38/0x250
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
au_cpup_simple+0x5b/0xa0 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
au_do_sio_cpup_simple+0xcf/0xf0 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
au_pin_and_icpup+0x2a3/0x4e0 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
aufs_setattr+0x4e4/0x620 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
xattr_resolve_name+0xa2/0xc0
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
notify_change+0x2ef/0x460
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
chown_common+0x165/0x1c0
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
strncpy_from_user+0x48/0x160
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
SyS_chown+0x94/0xd0
S Sun Dec 10 12:10:27 2017 p4 kernel:  [] ? 
system_call_fast_compare_end+0xc/0x9b
S Sun Dec 10 12:10:27 2017 p4 kernel: ---[ end trace fc137d6061ab0b9c ]---
S Sun Dec 10 12:10:27 2017 p4 kernel: [ cut here ]
S Sun Dec 10 12:10:27 2017 p4 kernel: WARNING: CPU: 0 PID: 1490 at 
/var/lib/dkms/aufs/4.9+20161219/build/fs/aufs/cpup.c:423 
au_cp_regular+0x16c/0x250 [aufs]
S Sun Dec 10 12:10:27 2017 p4 kernel: .wh..wh.resources-i.ri.000b
Please report this warning to aufs-users ML
S Sun Dec 10 12:10:27 2017 p4 kernel: Modules linked in:
S Sun Dec 10 12:10:27 2017 p4 kernel:  aufs(O) xenfs xen_privcmd joydev 
hid_generic usbhid hid ppdev sg pcspkr parport_pc parport serio_raw evdev 
ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb 
glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 mbcache sr_mod cdrom 
ata_generic xen_netfront xen_blkfront crc32c_intel ata_piix psmouse cirrus ttm 
drm_kms_helper drm i2c_piix4 uhci_hcd ehci_hcd usbcore usb_common libata 
scsi_mod floppy button
S Sun Dec 10 12:10:27 2017 p4 kernel: CPU: 0 PID: 1490 Comm: auplink Tainted: G 
   W  O4.9.0-4-amd64 #1 Debian 4.9.65-3
S Sun Dec 10 12:10:27 2017 p4 kernel: Hardware name: Xen HVM domU, BIOS 
4.4.1-xs116341 01/13/2016
S Sun Dec 10 12:10:27 2017 p4 kernel:   a8928e84 
bba581ee7a60 
S Sun Dec 10 12:10:27 2017 p4 kernel:  a8675efe bba581ee7d58 
bba581ee7ab8 
S Sun Dec 10 12:10:27 2017 p4 kernel:  9512c3ab3800 95128a932000 
951289d38300 a8675f7f
S Sun Dec 10 12:10:27 2017 p4 kernel: Call Trace:
S Sun Dec 10 12:10:27 2017 p4 kernel:  

Bug#836934: frobtads: FTBFS with GCC-7: error: ISO C++ forbids comparison between pointer and integer

[Juhani Numminen]

Control: tags 871215 + patch
Control: tags 836934 + patch

On Mon, 07 Aug 2017 01:45:33 +0200 Andreas Beckmann wrote:


frobtads FTBFS since GCC-7 was made the default compiler:

g++ -DHAVE_CONFIG_H -I. -I/build/frobtads-1.2.3/.  -DFROBTADS -DTC_TARGET_T3 -DTADSNET  -DOS_DECLARATIVE_TLS  
-DVMGLOB_VARS  -D_M_IX86_64 -DRUNFAST -I/build/frobtads-1.2.3/./src -I/build/frobtads-1.2.3/./tads2 
-I/build/frobtads-1.2.3/./tads3 -I/build/frobtads-1.2.3/./tads3/unix  
-DT3_INC_DIR=\"/usr/share/frobtads/tads3/include\" -DT3_LIB_DIR=\"/usr/share/frobtads/tads3/lib\" 
-DT3_RES_DIR=\"/usr/share/frobtads/tads3/res\" -DT3_LOG_FILE=\"/tmp/frob.log\" 
-I/build/frobtads-1.2.3/./src -I/build/frobtads-1.2.3/./tads2 -I/build/frobtads-1.2.3/./src 
-I/build/frobtads-1.2.3/./tads3 -I/build/frobtads-1.2.3/./tads3/test -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/build/frobtads-1.2.3=. -fstack-protector-strong -Wformat -Werror=format-security 
-fno-strict-aliasing -pthread -c -o tads3/tct3stm.o /build/frobtads-1.2.3/./tads3/tct3stm.cpp
/build/frobtads-1.2.3/./tads3/tct3stm.cpp: In static member function 'static 
void CTPNVarIn::gen_iter_init(CTcPrsNode*, int, const char*)':
/build/frobtads-1.2.3/./tads3/tct3stm.cpp:318:24: error: ISO C++ forbids 
comparison between pointer and integer [-fpermissive]
 if (create_iter != VM_INVALID_PROP)
^~~
Makefile:6604: recipe for target 'tads3/tct3stm.o' failed


On Sat, 24 Sep 2016 22:05:34 +0200 Andreas Beckmann wrote:


On 2016-09-24 20:46, Sebastian Ramacher wrote:

On 2016-09-07 13:09:40, Andreas Beckmann wrote:

frobtads FTBFS since the default compiler was switched to GCC 6 (which
defaults to -std=c++14):

g++ -DHAVE_CONFIG_H -I. -I/build/frobtads-1.2.3/.  -DFROBTADS -DTC_TARGET_T3 -DTADSNET  -DOS_DECLARATIVE_TLS  
-DVMGLOB_VARS  -D_M_IX86_64 -DRUNFAST -I/build/frobtads-1.2.3/./src -I/build/frobtads-1.2.3/./tads2 
-I/build/frobtads-1.2.3/./tads3 -I/build/frobtads-1.2.3/./tads3/unix  
-DT3_INC_DIR=\"/usr/share/frobtads/tads3/include\" -DT3_LIB_DIR=\"/usr/share/frobtads/tads3/lib\" 
-DT3_RES_DIR=\"/usr/share/frobtads/tads3/res\" -DT3_LOG_FILE=\"/tmp/frob.log\" 
-I/build/frobtads-1.2.3/./src -I/build/frobtads-1.2.3/./tads2 -I/build/frobtads-1.2.3/./src 
-I/build/frobtads-1.2.3/./tads3 -I/build/frobtads-1.2.3/./tads3/test -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/build/frobtads-1.2.3=. -fstack-protector-strong -Wformat -Werror=format-security 
-fno-strict-aliasing -pthread -c -o tads3/tcprs.o /build/frobtads-1.2.3/./tads3/tcprs.cpp
In file included from /build/frobtads-1.2.3/./tads3/tcprs.cpp:39:0:
/build/frobtads-1.2.3/./tads3/vmbignum.h: In static member function 'static 
vm_obj_id_t CVmObjBigNum::create(int, const bignum_t*)':
/build/frobtads-1.2.3/./tads3/vmbignum.h:585:45: error: exception cleanup for 
this placement new selects non-placement operator delete [-fpermissive]
 new (vmg_ id) CVmObjBigNum(vmg_ prec);



frobtads builds fine in todays sid. Closing.


Nope. It builds fine on amd64, but fails on i386 (both in pbuilder on an
amd64 host).



Hello,

Sending this message to 871215 and 836934 since they seem to be fixed by 
the same patch, and to 853629 because tads3/tct3stm.cpp is the same file 
in both qtads and frobtads.


Using an older standard of C++ seems to have done it for Arch Linux 
users, based on a comment at

https://aur.archlinux.org/packages/frobtads

In this patch that applies to frobtads, I add -std=gnu++98 because that 
was the default before GCC 6 changed it to -std=gnu++14.


Thanks,
Juhani
diff -Nru frobtads-1.2.3/debian/rules frobtads-1.2.3/debian/rules
--- frobtads-1.2.3/debian/rules	2013-07-15 00:42:57.0 +0300
+++ frobtads-1.2.3/debian/rules	2017-12-10 13:25:29.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+DEB_CXXFLAGS_MAINT_APPEND = -std=gnu++98
+
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
 

Bug#882382: Vignettes run into infinite loop

[Andreas Tille]

Hi Bendix,

in the Debian package of Epi we are trying to recreate the vignettes as 
a test of the functionality of the package.  I realised that two of the
vignettes run into infinite loops.  Here you can see the script

   
https://anonscm.debian.org/cgit/debian-med/r-cran-epi.git/tree/debian/tests/run-unit-test

... may be you check from line 13.

For the moment I simply excluded the affected tests but wanted to let
you know that something seems to be wrong.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#883996: Could not import PyQt4 on Linux systems

[積丹尼 Dan Jacobson]

Package: electrum
Version: 2.9.3-1
Severity: grave

# aptitude install electrum
$ electrum
Error: Could not import PyQt4 on Linux systems, you may try 'sudo apt-get 
install python-qt4'
Exception in thread Thread-9 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
  File "/usr/lib/python2.7/dist-packages/electrum/interface.py", line 208, in 
run17:10 1 ~$ 

Bug#794295: lintian: please complain about development packages that make cross building impossible

[Chris Lamb]

Hi Helmut,

> TL;DR: I suggest ignoring Multi-Arch: foreign packages for the purpose of
> this tag to remove false positives.

Won't these binaries in /usr/bin (etc.) be picked up by:

  arch-dependent-file-not-in-arch-specific-directory

?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#812756: lintian: please make -v imply --no-tag-display-limit

[Chris Lamb]

tags 812756 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=97aa2baab8b733ff2cdec7501f261eb5487ab356


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi Guido,

On Sun, Dec 10, 2017 at 12:59:05PM +0100, Guido Günther wrote:
> Hi,
> On Sun, Dec 10, 2017 at 12:51:38PM +0100, Salvatore Bonaccorso wrote:
> > Hi
> > 
> > On Sun, Dec 10, 2017 at 10:00:55AM +0100, Salvatore Bonaccorso wrote:
> > > Hi
> > > 
> > > Cc'ing explicitly Guido and Raphael, who commented before.
> > > 
> > > On Sat, Dec 09, 2017 at 03:25:14PM +0100, Markus Koschany wrote:
> > > > Hi,
> > > > 
> > > > I have updated my patch for reportbug. Now emails are sent only to one
> > > > of the team mailing lists based on the release number in the version
> > > > string. There is apparently no simple way to determine the relationship
> > > > between release number, code name, suite and whether this is a LTS
> > > > release. So we came up with a simple json file which provides this kind
> > > > of information and can be adjusted as time goes by. We think that
> > > > security-tracker.debian.org would be a good place for this file but I'd
> > > > appreciate it if someone from the security team told us the exact 
> > > > location.
> > > > 
> > > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088#45
> > > 
> > > So let me first understand the information you would need from that
> > > file (here in sort-of-yaml):
> > > 
> > > cut-cut-cut-cut-cut-cut-
> > > wheezy:
> > >   major-version: 7
> > >   support: lts
> > > jessie:
> > >   major-version: 8
> > >   support: security
> > > stretch:
> > >   major-version: 9
> > >   support: security
> > > buster:
> > >   major-version: 10
> > >   support: none
> > > bullseye:
> > >   major-version: 11
> > >   support: none
> > > cut-cut-cut-cut-cut-cut-
> > 
> > But rather in JSON than YAML. Florian would not recommend using YAML, and
> > furthermore it's more consistent with the tracker itself.
> > 
> > cut-cut-cut-cut-cut-cut-
> > {
> >   "wheezy": {
> > "major-version": "7",
> > "support": "lts"
> >   },
> >   "jessie": {
> > "major-version": "8",
> > "support": "security"
> >   },
> >   "stretch": {
> > "major-version": "9",
> > "support": "security"
> >   },
> >   "buster": {
> > "major-version": "10",
> > "support": "none"
> >   },
> >   "bullseye": {
> > "major-version": "11",
> > "support": "none"
> >   }
> > }
> > cut-cut-cut-cut-cut-cut-
> > 
> > and beeing accessible under 
> > https://security-tracker.debian.org/tracker/distributions.json
> 
> That makes as lot of sense! (I used YAML in the example for readability,
> output of the tracker should be JSON). The main reason why I'd prefer
> the tracker is that we can update the file ourselves when switching
> releases.

Yes I can understand why you prefer the security-tracker itself. My
convern was (and still in back on my head), we add more mappings. But
with eabove, we do not need to take care of stable->oldstable, etc ...
just add the who-is-supporting field.

A version of the above is live on the security-tracker, but I have not
yet commited the changes. I would first like to know: are you happy
with the 'major-version' nomenclature, otherwise we could change it to
'version'. 'support' should maybe 'support-by'?

Regards,
Salvatore

Bug#794295: lintian: please complain about development packages that make cross building impossible

[Helmut Grohne]

On Sun, Dec 10, 2017 at 09:52:41AM +, Chris Lamb wrote:
> Hi Helmut,
> 
> > TL;DR: I suggest ignoring Multi-Arch: foreign packages for the purpose of
> > this tag to remove false positives.
> 
> Won't these binaries in /usr/bin (etc.) be picked up by:
> 
>   arch-dependent-file-not-in-arch-specific-directory
> 
> ?

I think you are confusing something here. That tag only fires for
M-A:same packages, but that's a totally different story. If you put
ELF binaries in /usr/bin of a M-A:same package you immediately get a
file conflict.

What I'm trying to say is that it can be legitimate to put ELF binaries
in libdevel packages if such packages are marked M-A:foreign. My initial
request and your initial implementation will thus have false positives.

The tag I am requesting here mostly targets packages that lack any
Multi-Arch header (i.e. not covered by the above tag).

Hope this helps.

Helmut

Bug#879801: ftbfs with icu from experimental

[Norbert Preining]

Very interesting ... and very surprising ... it seems that the
forced reautoconf in all directories *did* change something ...

We need to compare the actual file lists in -7 and -8 before we can do
these kind of things ...

Ahh ... wait ... I guess I have an idea ... there is the patch 
  debian/patches/debian-no-tl-scripts
which changes a .am file down there. It probably never had any effect
until I found out the dh_autoreconf does not what I thought it does.

That would explain the discrepancy, as these files are tl_script files
and that is removed.

I guess we have to simply remove the files from the rules. I will do
this and other checks before actually uploading.

Thanks for your insistency!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#883950: debian-policy: allow specifying common licenses with only the identifier

[Simon McVittie]

On Sat, 09 Dec 2017 at 19:57:26 +0100, Mattia Rizzolo wrote:
> First of all, I'd like policy to stop being unclear on this matter, or
> state whether the correct form is [a brief license reference] or
> [the full license grant].

This is not really Policy's decision: it's the ftp team (cc'd) who decide
what they are willing to accept into Debian, and they require the license
grant[1] to be reproduced[2]. As far as I'm aware, it isn't documented
anywhere *why* it is required. ftp team: please could you clarify this?
The main possibilities seem to be:

* it might be a legal requirement imposed on us by copyright
  holders/copyright laws (in which case we must continue; but this seems
  unlikely, since Fedora is backed by a US corporation that is a much
  more attractive target for lawsuits than Debian, and they seem happy
  with their 1-line summaries);
* it might be a self-imposed requirement in order to meet some goal
  (in which case whether to continue is a Debian project decision,
  hopefully based on comparing the cost/work of keeping this requirement
  with the benefit of meeting that goal)

I would like the amount of debian/copyright work that is enforced by RC
bugs and package removals to be as small as it can be, but we can't know
which parts are critical and which parts are nice-to-have without knowing
why they're required. If some deficiencies in d/copyright are harmful
to a Debian goal but do not threaten redistributability or the Social
Contract, then the severity of the resulting bugs can be set according
to the importance of that goal, and the bugs can be fixed by the people
who care most about that goal, in Debian's usual "do-ocracy" way.

[1] https://lists.debian.org/debian-devel/2015/05/msg00473.html
[2] https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
(in that mail Joerg called the license grant the "license headers",
but I believe the canonical jargon term is that it's a license grant)

> Secondly (which would overcome the first matter as well), I'd like to
> propose to just stop wasting time/bytes in dumping such useless
> boilerplte in our `debian/copyright`s when a license is available in
> /usr/share/common-licenses.

I would like this too, but only if the ftp team will actually accept it:
it would be actively harmful to clarify Policy in a direction that
doesn't match what is allowed through the NEW queue.

smcv

Bug#883598: [Pkg-emacsen-addons] Bug#883598: elpa-pdf-tools: doesn't auto-activate

[David Bremner]

Rémi Vanicat  writes:

> Le 05 décembre 2017, David Bremner a écrit:
>
>> Package: elpa-pdf-tools
>> Version: 0.80-1
>> Severity: normal
>>
>> I guess this is probably an upstream bug, but in Debian we should at
>> least document the necessity of calling #'pdf-tools-install before
>> pdf-tools will do anything.
>
> I've wrote and push on git a README.Debian for this. I am hesitating
> between this solution and auto-activation, the latter being simpler for
> the user, but make the package diverge from upstream way of doing this.

Is there a chance upstream would take your auto-activation solution?

d

Bug#884011: bareos-filedaemon: bareos-fd crashes - fills /var/lib/bareos/ with core files

[Philipp Matthias Hahn]

Package: bareos-filedaemon
Version: 16.2.6-3
Severity: important

Dear Maintainer,

my backup system is running Debian-Stretch, but I also backup my
Debian-Sid development system. There bareos-fd crashes regularly:

> # ls -gGtr /var/lib/bareos
> insgesamt 5929744
> drwxrwxr-x 2  4096 Apr 22  2016 storage
> -rw-r- 1 152255384 Okt 30 19:29 bareos-fd.core.1810
> -rw-r- 1   713 Okt 30 19:29 bareos.1810.traceback
> -rw-r- 1   183 Okt 30 19:29 scout-fd.1810.bactrace
> -rw-r- 1 152255384 Okt 30 19:59 bareos-fd.core.3553
> -rw-r- 1   713 Okt 30 19:59 bareos.3553.traceback
> -rw-r- 1   183 Okt 30 19:59 scout-fd.3553.bactrace
> -rw-r- 1 152255384 Okt 30 20:29 bareos-fd.core.3838
> -rw-r- 1   711 Okt 30 20:29 bareos.3838.traceback
> -rw-r- 1   183 Okt 30 20:29 scout-fd.3838.bactrace
> -rw-r- 1 152255384 Okt 30 20:59 bareos-fd.core.4057
> -rw-r- 1   711 Okt 30 20:59 bareos.4057.traceback
> -rw-r- 1 152255384 Okt 30 21:30 bareos-fd.core.4243
> -rw-r- 1   715 Okt 30 21:30 bareos.4243.traceback
> -rw-r- 1 152255384 Okt 30 22:00 bareos-fd.core.4466
> -rw-r- 1   715 Okt 30 22:00 bareos.4466.traceback
> -rw-r- 1   183 Okt 30 22:00 scout-fd.4466.bactrace
> -rw-r- 1 152255384 Okt 30 22:30 bareos-fd.core.4675
> -rw-r- 1   711 Okt 30 22:30 bareos.4675.traceback
> -rw-r- 1 152255384 Okt 31 13:32 bareos-fd.core.1677
> -rw-r- 1   715 Okt 31 13:32 bareos.1677.traceback
> -rw-r- 1   183 Okt 31 13:32 scout-fd.1677.bactrace
> -rw-r- 1 152255384 Okt 31 14:02 bareos-fd.core.3422
> -rw-r- 1   716 Okt 31 14:02 bareos.3422.traceback
> -rw-r- 1 152255384 Okt 31 14:32 bareos-fd.core.17961
> -rw-r- 1   717 Okt 31 14:32 bareos.17961.traceback
> -rw-r- 1 154385712 Okt 31 15:02 bareos-fd.core.19198
> -rw-r- 1   854 Okt 31 15:02 bareos.19198.traceback
> -rw-r- 1 152255384 Okt 31 15:32 bareos-fd.core.6969
> -rw-r- 1   713 Okt 31 15:32 bareos.6969.traceback
> -rw-r- 1   183 Okt 31 15:32 scout-fd.6969.bactrace
> -rw-r- 1 152255384 Okt 31 16:02 bareos-fd.core.6432
> -rw-r- 1   715 Okt 31 16:02 bareos.6432.traceback
> -rw-r- 1 152255384 Okt 31 16:32 bareos-fd.core.6619
> -rw-r- 1   711 Okt 31 16:32 bareos.6619.traceback
> -rw-r- 1   183 Okt 31 16:32 scout-fd.6619.bactrace
> -rw-r- 1 152255384 Okt 31 17:02 bareos-fd.core.7072
> -rw-r- 1   713 Okt 31 17:02 bareos.7072.traceback
> -rw-r- 1   183 Okt 31 17:02 scout-fd.7072.bactrace
> -rw-r- 1 152255384 Okt 31 17:32 bareos-fd.core.7323
> -rw-r- 1   713 Okt 31 17:32 bareos.7323.traceback
> -rw-r- 1 152255384 Okt 31 18:02 bareos-fd.core.7515
> -rw-r- 1   713 Okt 31 18:02 bareos.7515.traceback
> -rw-r- 1   183 Okt 31 18:02 scout-fd.7515.bactrace
> -rw-r- 1 152255384 Okt 31 18:32 bareos-fd.core.7699
> -rw-r- 1   713 Okt 31 18:32 bareos.7699.traceback
> -rw-r- 1 152255384 Okt 31 19:02 bareos-fd.core.7966
> -rw-r- 1   713 Okt 31 19:02 bareos.7966.traceback
> -rw-r- 1 152255384 Okt 31 19:32 bareos-fd.core.8130
> -rw-r- 1   713 Okt 31 19:32 bareos.8130.traceback
> -rw-r- 1   183 Okt 31 19:32 scout-fd.8130.bactrace
> -rw-r- 1 152255384 Okt 31 20:02 bareos-fd.core.8339
> -rw-r- 1   713 Okt 31 20:02 bareos.8339.traceback
> -rw-r- 1 152255384 Okt 31 20:32 bareos-fd.core.8515
> -rw-r- 1   713 Okt 31 20:32 bareos.8515.traceback
> -rw-r- 1 152255384 Okt 31 21:02 bareos-fd.core.8702
> -rw-r- 1   711 Okt 31 21:02 bareos.8702.traceback
> -rw-r- 1 152255384 Okt 31 21:32 bareos-fd.core.8931
> -rw-r- 1   715 Okt 31 21:32 bareos.8931.traceback
> -rw-r- 1 152255384 Okt 31 22:02 bareos-fd.core.9135
> -rw-r- 1   715 Okt 31 22:02 bareos.9135.traceback
> -rw-r- 1 152255384 Okt 31 22:32 bareos-fd.core.9311
> -rw-r- 1   711 Okt 31 22:32 bareos.9311.traceback
> -rw-r- 1 152255384 Nov  4 12:20 bareos-fd.core.1761
> -rw-r- 1   711 Nov  4 12:20 bareos.1761.traceback
> -rw-r- 1   183 Nov  4 12:20 scout-fd.1761.bactrace
> -rw-r- 1 152255384 Nov  8 22:10 bareos-fd.core.1694
> -rw-r- 1   713 Nov  8 22:10 bareos.1694.traceback
> -rw-r- 1 152255384 Nov 15 20:41 bareos-fd.core.1720
> -rw-r- 1   713 Nov 15 20:41 bareos.1720.traceback
> -rw-r- 1   183 Nov 15 20:41 scout-fd.1720.bactrace
> -rw-r- 1 152255384 Nov 18 07:59 bareos-fd.core.1691
> -rw-r- 1   715 Nov 18 07:59 bareos.1691.traceback
> -rw-r- 1   183 Nov 18 07:59 scout-fd.1691.bactrace
> -rw-r- 1 152259480 Nov 19 18:18 bareos-fd.core.1704
> -rw-r- 1   715 Nov 19 18:18 bareos.1704.traceback
> -rw-r- 1   183 Nov 19 18:18 scout-fd.1704.bactrace
> -rw-r- 1 152259480 Nov 24 07:12 bareos-fd.core.1772
> -rw-r- 1   711 Nov 24 07:12 bareos.1772.traceback
> -rw-r- 1 152259480 Dez  6 19:39 

Bug#831870: devscripts: [mk-origtargz] Fails to create tar with Files-Excluded

[Mattia Rizzolo]

On Wed, Jul 20, 2016 at 05:10:01PM +0530, Chirayu Desai wrote:
> I'm working with the Android Tools team. We're seeing a failure with 
> mk-origtargz.
> The package is src:android-platform-frameworks-base [1]. The output can be 
> viewed at [2].
> The output is basically:
> mk-origtargz --repack --compression xz android-6.0.1_r43.tar.gz
> No files matched excluded pattern as the last matching glob: *.zip
> No files matched excluded pattern as the last matching glob: core/tests
> No files matched excluded pattern as the last matching glob: media/tests
> tar: tools/preload/sorttable.js: Not found in archive
> tar: : Not found in archive
> tar: Exiting with failure status due to previous errors

I was called upone debugging the very same error for another package,
the tarball can be found at [1] (and it's a way smaller test case…)

The thing is definitely tar's fault, I could trigger the same error with
cat gocryptfs_v1.4.2_src-deps.tar | tar --delete 
gocryptfs_v1.4.2_src-deps/vendor/github.com/jacobsa/crypto/.travis.yml > out.tar
i.e. without involving mk-origtargz at all.

I noticed that I can workaround the issue by firstly retarring the
tarball, i.e. the following sequence worked for me:
tar xaf gocryptfs_v1.4.2_src-deps.tar.gz
tar caf gocryptfs_v1.4.2_src-deps.tar.gz gocryptfs_v1.4.2_src-deps
cd packaging_dir
mk-origtargz -v 1.4.2 ../gocryptfs_v1.4.2_src-deps.tar.gz

Diffoscoping the original tarball and the retarred one I noticed that:
1) the original tarball has mixed file owners, some files are owned by
   root, others by an actual user
2) the tarball was not created by GNU tar (i.e. `file` reports "POSIX
   tar archive" instead of "POSIX tar archive (GNU)")


Just dumping here some findings.  Probably somebody should file a bug at
GNU tar.


[1] 
https://github.com/rfjakob/gocryptfs/releases/download/v1.4.2/gocryptfs_v1.4.2_src-deps.tar.gz

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#884018: yamcha: FTBFS with debhelper >= 10.9.2: dh_systemd_enable is no longer used in compat >= 11, please use dh_installsystemd instead

[Andreas Beckmann]

Source: yamcha
Version: 0.33-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

yamcha FTBFS since debhelper changed w.r.t. systemd handling:

dh_systemd_enable -pyamcha 
dh_systemd_enable: dh_systemd_enable is no longer used in compat >= 11, please 
use dh_installsystemd instead
/usr/share/cdbs/1/rules/debhelper.mk:233: recipe for target 
'binary-install/yamcha' failed
make: *** [binary-install/yamcha] Error 25


Andreas


yamcha_0.33-2.log.gz
Description: application/gzip

Bug#880661: RFP to ITP: python3-ratelimiter

[chrysn]

retitle 880661 ITP: python3-ratelimiter -- simple Python library for limiting 
the rate of operations
thanks

The snakemake workaround broke, and we'll need that anyway; starting to
package this in the style of DPMT policy with the intention of
maintaining it within the team.

Best regards
chrysn


signature.asc
Description: PGP signature

Bug#884021: nut: Can't open /etc/nut/upsd.users: Permission denied

[Roger Price]

Package: nut
Version: 2.7.4-5
Severity: normal

Dear Maintainer,

I installed nut 2.7.4-5 on a fresh Debian 9.2.1 system.
I updated the configuration files, started nut in standalone mode, and got the
error message

   Can't open /etc/nut/upsd.users: Permission denied

This is because the file has ownership and permissions

   -rw---   1 root nut 91 Aug  3 11:44 upsd.users

I changed the ownership and permissions in /etc/nut/ to

   drwxr-xr-x   2 root nut   4096 Dec  7 18:32 ./
   drwxr-xr-x 140 root root 12288 Dec  9 12:39 ../
   -rw-r-   1 root nut   1411 Dec  7 18:32 nut.conf
   -rw-r-   1 nut  nut290 Jul 14 20:16 ups.conf
   -rw---   1 nut  nut290 Jun 20 14:39 upsd.conf
   -rw---   1 nut  nut 91 Aug  3 11:44 upsd.users
   -rw---   1 nut  nut   1623 Jul  1 15:41 upsmon.conf
   -rw-r-   1 nut  nut   1348 Jul  1 09:39 upssched.conf

and the error message disappeared. I was then able to start nut.

Roger



-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nut depends on:
ii  nut-client  2.7.4-5
ii  nut-server  2.7.4-5

nut recommends no packages.

nut suggests no packages.

-- debconf-show failed

Bug#878318: nyquist FTBFS with gcc 7: undefined references

[Juhani Numminen]

Control: tags -1 patch

Juhani Numminen kirjoitti 04.12.2017 klo 00:39:


A FreeBSD bug from 2012 looks similar, there the fix was
s|inline void|static inline void|.[1]
That change entered upstream repository earlier in 2012.[2]
Debian's version doesn't have it.[3]


A patch is attached. Build was successful using cowbuilder, sid i386.

Juhani
Description: Fix FTBFS with gcc 7: undefined references
Origin: https://sourceforge.net/p/nyquist/code/73/tree/trunk/nyquist/ffts/src/fftlib.c?diff=50d0ad1227184648a86e886f:72
Author: Roger B. Dannenberg 
Bug-Debian: https://bugs.debian.org/878318
Bug-FreeBSD: https://bugs.freebsd.org/174376
Last-Update: 2017-12-10

--- a/ffts/src/fftlib.c
+++ b/ffts/src/fftlib.c
@@ -1,6 +1,8 @@
 /***
 lower level fft stuff including routines called in fftext.c and fft2d.c
 ***/
+/* inline declarations modified by RBD for C99 compiler */
+
 #include "fftlib.h"
 #include 
 #define	MCACHE	(11-(sizeof(float)/8))	// fft's with M bigger than this bust primary cache
@@ -61,8 +63,8 @@
 parts of ffts1
 */
 
-inline void bitrevR2(float *ioptr, long M, short *BRLow);
-inline void bitrevR2(float *ioptr, long M, short *BRLow){
+//inline void bitrevR2(float *ioptr, long M, short *BRLow);
+static inline void bitrevR2(float *ioptr, long M, short *BRLow){
 /*** bit reverse and first radix 2 stage of forward or inverse fft ***/
 float	f0r;
 float	f0i;
@@ -198,8 +200,8 @@
 };
 }
 
-inline void fft2pt(float *ioptr);
-inline void fft2pt(float *ioptr){
+//inline void fft2pt(float *ioptr);
+static inline void fft2pt(float *ioptr){
 /***   RADIX 2 fft	***/
 float f0r, f0i, f1r, f1i;
 float t0r, t0i;
@@ -229,8 +231,8 @@
 }
 
 
-inline void fft4pt(float *ioptr);
-inline void fft4pt(float *ioptr){
+//inline void fft4pt(float *ioptr);
+static inline void fft4pt(float *ioptr){
 /***   RADIX 4 fft	***/
 float f0r, f0i, f1r, f1i, f2r, f2i, f3r, f3i;
 float t0r, t0i, t1r, t1i;
@@ -284,8 +286,8 @@
 ioptr[7] = f3i;
 }
 
-inline void fft8pt(float *ioptr);
-inline void fft8pt(float *ioptr){
+//inline void fft8pt(float *ioptr);
+static inline void fft8pt(float *ioptr){
 /***   RADIX 8 fft	***/
 float w0r = 1.0/MYROOT2; /* cos(pi/4)	*/
 float f0r, f0i, f1r, f1i, f2r, f2i, f3r, f3i;
@@ -403,8 +405,8 @@
 ioptr[15] = f6i;
 }
 
-inline void bfR2(float *ioptr, long M, long NDiffU);
-inline void bfR2(float *ioptr, long M, long NDiffU){
+//inline void bfR2(float *ioptr, long M, long NDiffU);
+static inline void bfR2(float *ioptr, long M, long NDiffU){
 /*** 2nd radix 2 stage ***/
 unsigned long	pos;
 unsigned long	posi;
@@ -512,8 +514,8 @@
 }
 }
 
-inline void bfR4(float *ioptr, long M, long NDiffU);
-inline void bfR4(float *ioptr, long M, long NDiffU){
+//inline void bfR4(float *ioptr, long M, long NDiffU);
+static inline void bfR4(float *ioptr, long M, long NDiffU){
 /*** 1 radix 4 stage ***/
 unsigned long	pos;
 unsigned long	posi;
@@ -721,8 +723,8 @@
 
 }
 
-inline void bfstages(float *ioptr, long M, float *Utbl, long Ustride, long NDiffU, long StageCnt);
-inline void bfstages(float *ioptr, long M, float *Utbl, long Ustride, long NDiffU, long StageCnt){
+// inline void bfstages(float *ioptr, long M, float *Utbl, long Ustride, long NDiffU, long StageCnt);
+static inline void bfstages(float *ioptr, long M, float *Utbl, long Ustride, long NDiffU, long StageCnt){
 /***   RADIX 8 Stages	***/
 unsigned long	pos;
 unsigned long	posi;
@@ -1125,8 +1127,8 @@
 parts of iffts1
 */
 
-inline void scbitrevR2(float *ioptr, long M, short *BRLow, float scale);
-inline void scbitrevR2(float *ioptr, long M, short *BRLow, float scale){
+// inline void scbitrevR2(float *ioptr, long M, short *BRLow, float scale);
+static inline void scbitrevR2(float *ioptr, long M, short *BRLow, float scale){
 /*** scaled bit reverse and first radix 2 stage forward or inverse fft ***/
 float	f0r;
 float	f0i;
@@ -1262,8 +1264,8 @@
 };
 }
 
-inline void ifft2pt(float *ioptr, float scale);
-inline void ifft2pt(float *ioptr, float scale){
+//inline void ifft2pt(float *ioptr, float scale);
+static inline void ifft2pt(float *ioptr, float scale){
 /***   RADIX 2 ifft	***/
 float f0r, f0i, f1r, f1i;
 float t0r, t0i;
@@ -1292,8 +1294,8 @@
 ioptr[3] = scale*f1i;
 }
 
-inline void ifft4pt(float *ioptr, float scale);
-inline void ifft4pt(float *ioptr, float scale){
+// inline void ifft4pt(float *ioptr, float scale);
+static inline void ifft4pt(float *ioptr, float scale){
 /***   RADIX 4 ifft	***/
 float f0r, f0i, f1r, f1i, f2r, f2i, f3r, f3i;
 float t0r, t0i, t1r, t1i;
@@ -1347,8 +1349,8 @@
 ioptr[7] = scale*f3i;
 }
 
-inline void ifft8pt(float *ioptr, float scale);
-inline void ifft8pt(float *ioptr, float scale){
+//inline void ifft8pt(float *ioptr, float scale);
+static inline void ifft8pt(float *ioptr, float scale){
 

Bug#879857: xserver-xorg-video-intel: [i915] GPU hang after every suspend or hibernate on Debian 9 stretch

[Ferdinand Rau]

Dear Maintainer,

There are reports that this issue is resolved when using the same version of 
xserver-xorg-video-intel, but another kernel version. Therefore, I now assume 
that this issue is caused by a kernel bug, not a bug in your package.

I filed a new bug report against src:linux here:
https://bugs.debian.org/883935

I will post any updates or new information there. Feel free to close this bug 
any time.

Kind regards,
Ferdinand

Bug#884024: bibledit-data: Installs unneeded files

[Jeremy Bicha]

Source: bibledit
Version: 5.0.331-1
X-Debbugs-CC: teusjanne...@gmail.com, robe...@debian.org

These files are installed by bibledit-data and look wrong:

/usr/share/bibledit/.pc/
/usr/share/bibledit/AUTHORS
/usr/share/bibledit/ChangeLog
/usr/share/bibledit/DEVELOP
/usr/share/bibledit/INSTALL
/usr/share/bibledit/Makefile
/usr/share/bibledit/Makefile.am
/usr/share/bibledit/Makefile.in
/usr/share/bibledit/NEWS
/usr/share/bibledit/README
/usr/share/bibledit/aclocal.m4
/usr/share/bibledit/compile
/usr/share/bibledit/config.guess
/usr/share/bibledit/config.h.in
/usr/share/bibledit/config.log
/usr/share/bibledit/config.status
/usr/share/bibledit/config.sub
/usr/share/bibledit/configure
/usr/share/bibledit/configure.ac
/usr/share/bibledit/debcomp
/usr/share/bibledit/stamp-h1

There are also several empty directories in /usr/share/bibledit/ but I
don't know enough about this app to know if they are safe to remove.

Thanks,
Jeremy Bicha

Bug#794295: lintian: please complain about development packages that make cross building impossible

[Chris Lamb]

Hi Helmut,

> The tag I am requesting here mostly targets packages that lack any
> Multi-Arch header (i.e. not covered by the above tag).

Thank you for the clarification. :)  I have just pushed the following:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=8705ed43bd19cb40ada45897333ca56fcd187738


Best wishes.

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#853629: frobtads: FTBFS with GCC-7: error: ISO C++ forbids comparison between pointer and integer

[Juhani Numminen]

Juhani Numminen kirjoitti 10.12.2017 klo 14:31:


...
On Sat, 24 Sep 2016 22:05:34 +0200 Andreas Beckmann wrote:
... >> Nope. It builds fine on amd64, but fails on i386 (both in pbuilder on an

amd64 host).

...
In this patch that applies to frobtads, I add -std=gnu++98 because that 
was the default before GCC 6 changed it to -std=gnu++14.


Forgot to mention: I tested the patch on current sid amd64 and i386, 
using cowbuilder on an amd64 host.



Juhani

Bug#884009: firmware: failed to load pci errors in syslog

[Frederique]

Package: firmware-atheros
Version: 20170823-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Error showing up during boot.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Start my computer.

   * What was the outcome of this action?
My computer started.

   * What outcome did you expect instead?
Explosions.

Dec 10 13:24:42 fdt kernel: [1.405461] ath10k_pci :04:00.0: firmware:
failed to load ath10k/pre-cal-pci-:04:00.0.bin (-2)
Dec 10 13:24:42 fdt kernel: [1.405471] ath10k_pci :04:00.0: firmware:
failed to load ath10k/cal-pci-:04:00.0.bin (-2)

Dec 10 13:24:42 fdt kernel: [1.406338] ath10k_pci :04:00.0: firmware:
direct-loading firmware ath10k/QCA6174/hw3.0/firmware-6.bin
Dec 10 13:24:42 fdt kernel: [1.406341] ath10k_pci :04:00.0: qca6174
hw3.2 target 0x0503 chip_id 0x00340aff sub 1a56:1535
Dec 10 13:24:42 fdt kernel: [1.406343] ath10k_pci :04:00.0: kconfig
debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
Dec 10 13:24:42 fdt kernel: [1.406672] ath10k_pci :04:00.0: firmware
ver WLAN.RM.4.4-00022-QCARMSWPZ-2 api 6 features wowlan,ignore-otp crc32
4d458559



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-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)

firmware-atheros depends on no packages.

firmware-atheros recommends no packages.

Versions of packages firmware-atheros suggests:
ii  initramfs-tools  0.130

-- no debconf information

Bug#884015: kalgebra-common: Kalgebra-common can't be updated in 4:17.08.3-1

[merlin]

Package: kalgebra-common
Version: 4:16.08.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
The update of kalgebra-common from 4:16.08.3-1 to 4:17.08.3-1 led to a conflict
with kde-l10n-fr 4:16.04.3-7
dpkg: erreur de traitement de l'archive /var/cache/apt/archives/kalgebra-
common_4%3a17.08.3-1_amd64.deb (--unpack) :
 tentative de remplacement de « /usr/share/locale/fr/LC_MESSAGES/kalgebra.mo »,
qui appartient aussi au paquet kde-l10n-fr 4:16.04.3-7
Sorry for the error message in french
Recently i have the same problem with kstars an it was corrected by Pino
Toscano



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages kalgebra-common depends on:
ii  plasma-framework 5.37.0-2
pn  qml-module-org-kde-analitza  

kalgebra-common recommends no packages.

kalgebra-common suggests no packages.

-- no debconf information

Bug#880467: jasperreports: CVE-2017-14941, CVE-2017-5528, CVE-2017-5529

[Markus Koschany]

Am 10.12.2017 um 00:49 schrieb Emmanuel Bourg:
> Le 10/12/2017 à 00:07, Markus Koschany a écrit :
> 
>> However we should always be able to assess security vulnerabilities.
>> Just hoping that nobody will ever use the Debian library in some other
>> context is negligent. I would be really disappointed when I built an
>> Java app with Debian's system libraries and then I have to find out that
>> it is basically unsupported and contains security holes because it is
>> "just" a build-dependency for some other project.
> 
> I tend to disagree with this reasoning. We can't support any usage of
> the libraries we ship, we don't have the resources for that. Our
> responsibility should be limited to the code that we actually use in
> Debian. Java developers don't use the system libraries anyway, they
> typically pull the jars from Maven Central and bundle them with their
> applications. Patching unused features would really be a waste of time.

We usually do support this use case. Take for example the recent
libpam4j update. No package in Debian is using it at the moment. The
whole purpose of this piece of software is authentication with PAM and
if you can circumvent the PAM auth mechanism, then it is obviously
broken, in a very bad way. To ignore such bugs would be a disservice to
any Debian user if we can fix them.

Yes, Java developers download their libraries from Maven Central and
bundle everything. But how can you be so sure that someone is not using
Debian libraries in production because they are stable and receive
security support? Why do you package libspring-java in the first place?
Because you don't want that people build web applications with this
package? Sorry, but that makes no sense to me.

I agree we have not enough human resources to support every use case.
But by packaging stuff we also make a promise to support packages in
stable releases. We can't do that if we don't even know the severity of
security issues. Then the only sensible way is to remove the software.
Ignoring issues is and has never been a good option.

>> To be fair: CVE-2017-5533 and CVE-2017-5528 probably do not affect us
>> because we ship the Jasperreports Library and not the server. Please
>> correct me if I am wrong.
> 
> I don't know, I'm not familiar enough with jasperreports. I can just.
> observe that the Spring modules depending on it are nowhere used in
> Debian yet.

I'm not familiar with jasperreports either. I just did a major upgrade
two years ago. But apparently it is not very important. So why all the fuss?
>> Thus said maybe you are able to find the relevant changes or you get a
>> more helpful reply from the support guys. Otherwise I would try to
>> disable jasperreports in libspring-java which appears to be optional. (I
>> know probably requires another patch...)
> 
> libspring-java is already quite complicated. An additional patch to
> maintain would be a hindrance, especially for disabling the usage of a
> library we don't really care about. On the other hand maintaining such a
> patch is maybe less complicated than regularly upgrading jasperreports,
> that's probably worth investigating. If we go that route I'd rather see
> libspring-java upgraded to the version 5.0 before patching it.

Jasperreports has lots of dependencies. My first thought was to backport
the latest upstream release but this would probably require other
backports. The same procedure for every security issue? No thanks. Then
I would rather suggest to disable the spring module.

>> For reference here is the link to my support request:
>>
>> https://community.jaspersoft.com/questions/1072461/security-update-cve-2017-14941-cve-2017-5528-cve-2017-5529
> 
> I'm not convinced they understood the context and our point of view.
> Upgrading the library was just the obvious solution to the issue raised,
> that doesn't make the answer hostile or uncooperative. I'd suggest
> asking the developers directly instead of going through a sales or
> customer support representative.

Upgrading to the latest version is always the recommended upstream way.
Good upstreams document their fixes though. I think it was sensible to
ask this question in the community forum. At least I gave it a try, if
you can find out more, please do.

> Emmanuel Bourg

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#884020: python3-sphinx: versioned dependency on jinja2 is too loose

[Sandro Tosi]

Package: python3-sphinx
Version: 1.6.5-2
Severity: normal

Hello,
i had an outdated version on jinja2 on my machine (2.9.5-1) and when building a
package i got the error:

  Error: The 'jinja2.asyncsupport' module cannot be found. Did you install
  Sphinx and its dependencies correctly?

after upgrading python3-jinja2 to 2.10-1, the error went away.

Python3-sphinx declare this dep on jinja2: 'python3-jinja2 (>= 2.3)', probably
you need a tigher one

thanks,
sandro

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-sphinx depends on:
ii  python33.6.3-2
ii  python3-alabaster  0.7.8-1
ii  python3-babel  2.3.4+dfsg.1-2
ii  python3-docutils   0.13.1+dfsg-2
ii  python3-imagesize  0.7.1-1
ii  python3-jinja2 2.10-1
ii  python3-pygments   2.2.0+dfsg-1
ii  python3-requests   2.18.1-1
ii  python3-six1.10.0-4
ii  sphinx-common  1.6.5-2

Versions of packages python3-sphinx recommends:
ii  python3-pil  4.3.0-2

Versions of packages python3-sphinx suggests:
ii  dvipng 1.14-2+b3
ii  imagemagick-6.q16  8:6.9.7.4+dfsg-11
pn  latexmk
ii  libjs-mathjax  2.7.0-2
ii  python3-sphinx-rtd-theme   0.2.4-1
ii  sphinx-doc 1.4.9-2
ii  texlive-fonts-recommended  2016.20170123-5
ii  texlive-generic-extra  2016.20170123-5
ii  texlive-latex-extra2016.20170123-5
ii  texlive-latex-recommended  2016.20170123-5

-- no debconf information

Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Am 10.12.2017 um 13:35 schrieb Salvatore Bonaccorso:
[...]
>>> and beeing accessible under 
>>> https://security-tracker.debian.org/tracker/distributions.json
>>
>> That makes as lot of sense! (I used YAML in the example for readability,
>> output of the tracker should be JSON). The main reason why I'd prefer
>> the tracker is that we can update the file ourselves when switching
>> releases.
> 
> Yes I can understand why you prefer the security-tracker itself. My
> convern was (and still in back on my head), we add more mappings. But
> with eabove, we do not need to take care of stable->oldstable, etc ...
> just add the who-is-supporting field.
> 
> A version of the above is live on the security-tracker, but I have not
> yet commited the changes. I would first like to know: are you happy
> with the 'major-version' nomenclature, otherwise we could change it to
> 'version'. 'support' should maybe 'support-by'?

Hi,

IMO my version of distributions.json did the same thing. We only can
deduce the version from the package, so the version was the key and the
values were "lts", "oldstable", "stable". Everything else is not supported.

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=878088;filename=distribution.json;msg=45

For the next LTS this file would look like

8: "lts"
9: "stable"

and then

8: "lts"
9: "oldstable"
10: "stable"


More information is not required. The code looks like that:

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=878088;filename=reportbug.debdiff;msg=45


Of course I can also use the new json file. If I don't hear any further
objections I am going to use

https://security-tracker.debian.org/tracker/distributions.json

from now on. I intend to release an update of reportbug for Wheezy next
week. Please contact me if you are interested in an upgrade for Jessie
and Stretch as well.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#879801: ftbfs with icu from experimental

[Norbert Preining]

Hi Hilmar,

thanks for testing.

> (new log attached). I've tried to document all not existing files in my
> debian/rules file. Maybe I've overdone it.

Yes, that is the problem. Look for example into the first patch
@@ -168,14 +168,14 @@
# remove various man pages
for i in latex pdflatex lamed amstex fmtutil-sys kpsexpand kpsepath \
 mktexfmt updmap-sys updmap fmtutil ; do \
- rm debian/texlive-binaries/usr/share/man/man1/$$i.1* ; \
+ rm -f debian/texlive-binaries/usr/share/man/man1/$$i.1* ; \
done


Here the removal of
  latex pdflatex lamed amstex
are correct, but the others are wrong.

-   rm debian/texlive-binaries/usr/share/man/man5/fmtutil.cnf.5*
-   rm debian/texlive-binaries/usr/share/man/man5/updmap.cfg.5*
+   rm -f debian/texlive-binaries/usr/share/man/man5/fmtutil.cnf.5*
+   rm -f debian/texlive-binaries/usr/share/man/man5/updmap.cfg.5*

I wasn't sure about those, but it seems they are correct - my guess.

# remove tex4ht links, they are shipped with tl-htmlxml
for i in ht htcontext htlatex htmex httex httexi htxelatex htxetex 
mk4ht xhlatex ; do \
- rm debian/texlive-binaries/usr/bin/$$i ; \
+ rm -f debian/texlive-binaries/usr/bin/$$i ; \
done

Here again, are really *all* of the "for i in ..." not existing?

@@ -184,8 +184,8 @@
for i in e2pall allec mktexfmt kpsexpand kpsepath allcm allneeded 
dvi2fax dvired \
 fontinst kpsetool kpsewhere ps2frag pslatex rubibtex 
rumakeindex \
 texconfig-dialog texconfig-sys texconfig texlinks ; do \
- rm debian/texlive-binaries/usr/bin/$$i ; \
- rm debian/texlive-binaries/usr/share/man/man1/$$i.1* ; \
+ rm -f debian/texlive-binaries/usr/bin/$$i ; \
+ rm -f debian/texlive-binaries/usr/share/man/man1/$$i.1* ; \
done

And the sam ehere! I guess that
  texconfig*
  kpse*
etc need to be deleted, but things like e2pall etc aren't?

So I don't want to blindly add rm -f, and I need to delete those files
that are shipped in the nonarch packages, so I cannot blindly remove the
whole part.

Don't worry if you have no time, I will build by hand and check for the
files in due time.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#884022: kcachegrind: FTBFS with recent Qt5: Could not find a package configuration file provided by "Qt5LinguistTools"

[Andreas Beckmann]

Source: kcachegrind
Version: 4:17.08.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

kcachegrind/experimental recently started to FTBFS:

 debian/rules build
/usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.pl --with=kf5,pkgkde-symbolshelper 
dpkg-buildflags --export=make > debian/dhmk_env.mk
/usr/bin/make -f debian/rules dhmk_run_configure_commands 
DHMK_TARGET="configure"
make[1]: Entering directory '/build/kcachegrind-17.08.1'
dh_testdir  
dh_auto_configure '--buildsystem=kf5' --parallel  
cd obj-i686-linux-gnu && cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAG
E_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_BUILD_TYPE=Debian -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DKDE_INSTALL_USE_QT_SYS_PATHS=ON
-- The C compiler identification is GNU 7.2.1
-- The CXX compiler identification is GNU 7.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could not set up the appstream test. appstreamcli is missing.
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Failed
-- Performing Test HAVE_DATE_TIME
-- Performing Test HAVE_DATE_TIME - Success
-- Found KF5Archive: 
/usr/lib/i386-linux-gnu/cmake/KF5Archive/KF5ArchiveConfig.cmake (found version 
"5.37.0") 
-- Found KF5CoreAddons: 
/usr/lib/i386-linux-gnu/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake (found 
version "5.37.0") 
-- Found KF5DocTools: 
/usr/lib/i386-linux-gnu/cmake/KF5DocTools/KF5DocToolsConfig.cmake (found 
version "5.37.0") 
-- Found KF5WidgetsAddons: 
/usr/lib/i386-linux-gnu/cmake/KF5WidgetsAddons/KF5WidgetsAddonsConfig.cmake 
(found version "5.37.0") 
-- Found KF5XmlGui: 
/usr/lib/i386-linux-gnu/cmake/KF5XmlGui/KF5XmlGuiConfig.cmake (found version 
"5.37.0") 
-- Found Gettext: /usr/bin/msgmerge (found version "0.19.8.1") 
-- Found PythonInterp: /usr/bin/python (found version "2.7.14") 
-- Found KF5I18n: /usr/lib/i386-linux-gnu/cmake/KF5I18n/KF5I18nConfig.cmake 
(found version "5.37.0") 
-- Found KF5Config: 
/usr/lib/i386-linux-gnu/cmake/KF5Config/KF5ConfigConfig.cmake (found version 
"5.37.0") 
-- Found KF5KIO: /usr/lib/i386-linux-gnu/cmake/KF5KIO/KF5KIOConfig.cmake (found 
version "5.37.0") 
-- Found KF5: success (found version "5.37.0") found components:  Archive 
CoreAddons DocTools WidgetsAddons XmlGui I18n Config KIO 
-- The following REQUIRED packages have been found:

 * ECM (required version >= 1.7.0)
 * Qt5Core
 * Qt5DBus
 * Qt5Gui
 * Qt5Widgets
 * Qt5 (required version >= 5.2.0)
 * KF5Archive
 * KF5CoreAddons
 * KF5DocTools
 * KF5WidgetsAddons
 * KF5XmlGui
 * Gettext
 * PythonInterp
 * KF5I18n
 * KF5Config
 * KF5KIO
 * KF5

CMake Error at /usr/share/ECM/modules/ECMPoQmTools.cmake:144 (find_package):
  Could not find a package configuration file provided by "Qt5LinguistTools"
  with any of the following names:

Qt5LinguistToolsConfig.cmake
qt5linguisttools-config.cmake

  Add the installation prefix of "Qt5LinguistTools" to CMAKE_PREFIX_PATH or
  set "Qt5LinguistTools_DIR" to a directory containing one of the above
  files.  If "Qt5LinguistTools" provides a separate development package or
  SDK, be sure it has been installed.
Call Stack (most recent call first):
  /usr/share/ECM/modules/ECMPoQmTools.cmake:220 (ecm_process_po_files_as_qm)
  CMakeLists.txt:57 (ecm_install_po_files_as_qm)


-- Configuring incomplete, errors occurred!


Andreas


kcachegrind_4%17.08.1-1.log.gz
Description: application/gzip

Bug#884024: bibledit-data: Installs unneeded files

[Teus Benschop]

Hello Jeremy,

Thank you for spotting the list of files installed by bibledit-data that
look wrong.

I'll have a look at them, then create an updated package.

Thanks,

Teus.

On Sun, 10 Dec 2017 at 16:33 Jeremy Bicha  wrote:

> Source: bibledit
> Version: 5.0.331-1
> X-Debbugs-CC: teusjanne...@gmail.com, robe...@debian.org
>
> These files are installed by bibledit-data and look wrong:
>
> /usr/share/bibledit/.pc/
> /usr/share/bibledit/AUTHORS
> /usr/share/bibledit/ChangeLog
> /usr/share/bibledit/DEVELOP
> /usr/share/bibledit/INSTALL
> /usr/share/bibledit/Makefile
> /usr/share/bibledit/Makefile.am
> /usr/share/bibledit/Makefile.in
> /usr/share/bibledit/NEWS
> /usr/share/bibledit/README
> /usr/share/bibledit/aclocal.m4
> /usr/share/bibledit/compile
> /usr/share/bibledit/config.guess
> /usr/share/bibledit/config.h.in
> /usr/share/bibledit/config.log
> /usr/share/bibledit/config.status
> /usr/share/bibledit/config.sub
> /usr/share/bibledit/configure
> /usr/share/bibledit/configure.ac
> /usr/share/bibledit/debcomp
> /usr/share/bibledit/stamp-h1
>
> There are also several empty directories in /usr/share/bibledit/ but I
> don't know enough about this app to know if they are safe to remove.
>
> Thanks,
> Jeremy Bicha
>

Bug#884026: kalgebra-common: file conflict with kde-l10n-*: /usr/share/locale/*/LC_MESSAGES/kalgebra.mo

[Andreas Beckmann]

Package: kalgebra-common
Version: 4:17.08.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts ... well you should know the sermon by now :-)

  Selecting previously unselected package kalgebra-common.
  Preparing to unpack .../362-kalgebra-common_4%3a17.08.3-1_amd64.deb ...
  Unpacking kalgebra-common (4:17.08.3-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-w3sjeI/362-kalgebra-common_4%3a17.08.3-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/share/locale/ar/LC_MESSAGES/kalgebra.mo', which is 
also in package kde-l10n-ar 4:16.04.3-7
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-w3sjeI/148-analitza-common_4%3a17.08.3-1_all.deb
   /tmp/apt-dpkg-install-w3sjeI/362-kalgebra-common_4%3a17.08.3-1_amd64.deb


cheers,

Andreas