Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel

[Louis Bouchard]

Hello Salvatore,

Le 28/11/2022 à 19:22, Salvatore Bonaccorso a écrit :

Hi Louis,

The rough plan would be to have it included in the next bullseye point
release. That is scheduled to be on 17th of december[1]. It would be
great to recieve testing feedback actually on the change.

  [1] https://lists.debian.org/debian-live/2022/11/msg6.html

Regards,
Salvatore


Thank you for your quick & precise answer. I really appreciate.

Regards,
...Louis

Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel

[Louis Bouchard]

Hello Salvatore,


I will likely pick that change as well for the next 5.10.y based
upload via the upcoming point release (it might count as "enabling
furhter hardware support" allowed for stable release updates).

Regards,
Salvatore


This is a very good news.

Would you happen to have an idea on the timetable for the availability 
of the upcoming 5.10 kernel ?


I am currently working on building a custom kernel with this option 
enabled so we can make Bullseye available again on our SEV enabled offer 
until the backport becomes available. If it is expected to happen soon, 
we may elect to wait for an official kernel.


TIA,

Kind regards,

...Louis

Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel

[Louis Bouchard]

Package: src:linux
Version: 5.10.149-2
Severity: important
X-Debbugs-Cc: lbouch...@scaleway.com

Dear Kernel team,

A fix for bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989040 
is included in kernel 5.13 but still not available for the stable kernel.


Could you please backport the fix for that bug into the stable 5.10 
kernel so it becomes available in a standard Debian Bullseye 
installation. Without this fix, Debian Bullseye is unbootable in

a virtual machine which uses Secure Enhanced Virtualization (SEV).

The fix is the enablement of the CONFIG_AMD_MEM_ENCRYPT configuration 
option.


Kind regards,

... Louis Bouchard


-- Package-specific info:
** Version:
Linux version 5.10.0-19-cloud-amd64 (debian-ker...@lists.debian.org) 
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for 
Debian) 2.35.2) #1 SMP Debian 5.10.149-2 (2022-10-21)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-19-cloud-amd64 
root=UUID=25db7b8b-fbf8-47bd-b3c6-21fcf4de5f22 ro console=tty0 
console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0


** Not tainted

** Kernel log:
[1.808563] systemd[1]: Created slice system-systemd\x2dgrowfs.slice.
[1.810794] systemd[1]: Created slice User and Session Slice.
[1.812361] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[1.814189] systemd[1]: Started Forward Password Requests to Wall 
Directory Watch.
[1.816108] systemd[1]: Set up automount Arbitrary Executable File 
Formats File System Automount Point.

[1.818610] systemd[1]: Reached target Local Encrypted Volumes.
[1.820342] systemd[1]: Reached target Paths.
[1.821643] systemd[1]: Reached target Remote File Systems.
[1.823172] systemd[1]: Reached target Slices.
[1.824216] systemd[1]: Reached target Swap.
[1.825333] systemd[1]: Reached target System Time Set.
[1.826843] systemd[1]: Listening on Syslog Socket.
[1.827821] systemd[1]: Listening on fsck to fsckd communication Socket.
[1.829095] systemd[1]: Listening on initctl Compatibility Named Pipe.
[1.830420] systemd[1]: Listening on Journal Audit Socket.
[1.831536] systemd[1]: Listening on Journal Socket (/dev/log).
[1.832700] systemd[1]: Listening on Journal Socket.
[1.833727] systemd[1]: Listening on udev Control Socket.
[1.834743] systemd[1]: Listening on udev Kernel Socket.
[1.836088] systemd[1]: Mounting Huge Pages File System...
[1.837358] systemd[1]: Mounting POSIX Message Queue File System...
[1.838852] systemd[1]: Mounting Kernel Debug File System...
[1.840422] systemd[1]: Mounting Kernel Trace File System...
[1.841929] systemd[1]: Starting Create list of static device nodes 
for the current kernel...

[1.843833] systemd[1]: Starting Load Kernel Module configfs...
[1.845439] systemd[1]: Starting Load Kernel Module drm...
[1.846871] systemd[1]: Starting Load Kernel Module fuse...
[1.848423] systemd[1]: Started Nameserver information manager.
[1.851234] systemd[1]: Condition check resulted in Set Up Additional 
Binary Formats being skipped.
[1.852026] systemd[1]: Condition check resulted in File System Check 
on Root Device being skipped.

[1.853998] systemd[1]: Starting Journal Service...
[1.856523] systemd[1]: Starting Load Kernel Modules...
[1.858154] systemd[1]: Starting Remount Root and Kernel File Systems...
[1.859700] fuse: init (API version 7.32)
[1.859981] systemd[1]: Starting Coldplug All udev Devices...
[1.862214] systemd[1]: Mounted Huge Pages File System.
[1.863194] systemd[1]: Mounted POSIX Message Queue File System.
[1.864151] systemd[1]: Mounted Kernel Debug File System.
[1.865057] systemd[1]: Mounted Kernel Trace File System.
[1.866053] systemd[1]: Finished Create list of static device nodes 
for the current kernel.

[1.867461] systemd[1]: modprobe@configfs.service: Succeeded.
[1.868030] systemd[1]: Finished Load Kernel Module configfs.
[1.869046] systemd[1]: modprobe@drm.service: Succeeded.
[1.869620] systemd[1]: Finished Load Kernel Module drm.
[1.870609] systemd[1]: modprobe@fuse.service: Succeeded.
[1.871568] systemd[1]: Finished Load Kernel Module fuse.
[1.873149] systemd[1]: Finished Load Kernel Modules.
[1.875661] systemd[1]: Mounting FUSE Control File System...
[1.877313] systemd[1]: Mounting Kernel Configuration File System...
[1.879176] systemd[1]: Starting Apply Kernel Variables...
[1.880825] systemd[1]: Mounted FUSE Control File System.
[1.882063] systemd[1]: Mounted Kernel Configuration File System.
[1.895464] systemd[1]: Finished Apply Kernel Variables.
[1.897833] systemd[1]: Started Journal Service.
[1.904694] EXT4-fs (sda1): re-mounted. Opts: discard,errors=remount-ro
[1.917029] EXT4-fs (sda1): resizing filesystem from 491515 to 
2408634 blocks
[1.920492] systemd-journald[286]: Received client request to flush 
runtime journal.

[1.989419] EXT4-fs (sda1

Bug#1021590: iptables: segfault when renaming a chain

[Louis Bouchard]

Package: iptables
Version: 1.8.8-1
Severity: important
Tags: upstream
X-Debbugs-Cc: lbouch...@scaleway.com

This is the description for the upstream fix of this bug[1] :

This is an odd bug: If the number of chains is right and one renames the
last one in the list, libiptc dereferences a NULL pointer.

Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream.
This bug is to have the fix included in Debian in order to avoid such
segmentation faults.

For Sid, iptables uses the new nft libraries so the problem
does not appear unless the -legacy commands are used.

The following code (adapted from the upstream commit to work on Sid)
may be used to reproduce the issue :
8<
#!/bin/bash
#
# Cover for a bug in libiptc:
# - the chain 'node-98-tmp' is the last in the list sorted by name
# - there are 81 chains in total, so three chain index buckets
# - the last index bucket contains only the 'node-98-tmp' chain
# => rename temporarily removes it from the bucket, leaving a NULL
# bucket
# behind which is dereferenced later when inserting the chain again with
# new
# name again

(
 echo "*filter"
  for chain in node-1 node-10 node-101 node-102 node-104 node-107
  node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18
  node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27
  node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36
  node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45
  node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54
  node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62
  node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71
  node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9
  node-92 node-93 node-95 node-98-tmp; do
echo ":$chain - [0:0]"
   done
   echo "COMMIT"
  ) | $XT_MULTI iptables-legacy-restore
  $XT_MULTI iptables-legacy -E node-98-tmp node-98
  exit $?

>8

  [1] 
http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-cloud-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iptables depends on:
ii  libc62.35-3
ii  libip4tc21.8.8-1
ii  libip6tc21.8.8-1
ii  libmnl0  1.0.4-3
ii  libnetfilter-conntrack3  1.0.9-2
ii  libnfnetlink01.0.2-2
ii  libnftnl11   1.2.3-1
ii  libxtables12 1.8.8-1
ii  netbase  6.3

Versions of packages iptables recommends:
pn  nftables  

Versions of packages iptables suggests:
pn  firewalld  
ii  kmod   30+20220905-1

-- no debconf information

Bug#989040: linux-image-5.10.0-6-amd64: Missing CONFIG_AMD_MEM_ENCRYPT in kernel config makes SEV booting impossible

[Louis Bouchard]

Package: src:linux
Version: 5.10.28-1
Severity: important

Dear Kernel team,

As previously reported in bug #959069 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959069) for kernel 
5.5.0-2, the config parameter CONFIG_AMD_MEM_ENCRYPT is missing and, 
hence, booting an Debian Buster image in a SEV enabled VM is impossible.


No log may be provided as GRUB2 simply returns to the menu upon trying 
to boot the kernel.


Compilation of the kernel currently present in the testing pocket with 
this option enabled allows the kernel to boot normally.


Please include this kernel parameter so Debian Buster may be booted out 
of the box in a SEV enabled VM.


Kind regards,

...Louis Bouchard

-- Package-specific info:
** Version:
Linux version 5.10.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 
2.35.2) #1 SMP Debian 5.10.28-1 (2021-04-09)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-6-amd64 
root=UUID=2a32edc5-aef2-4dcc-93ee-9cd605341279 ro console=tty0 
console=ttyS0,115200 earlyprintk=ttyS0,115200 scsi_mod.use_blk_mq=Y


** Not tainted

** Kernel log:
[1.157475] virtio_net virtio0 enp0s1: renamed from eth0
[1.160360] ahci :00:1f.2: version 3.0
[1.161125] ahci :00:1f.2: AHCI 0001. 32 slots 6 ports 1.5 
Gbps 0x3f impl SATA mode

[1.162382] ahci :00:1f.2: flags: 64bit ncq only
[1.164175] scsi host1: ahci
[1.164778] scsi host2: ahci
[1.165438] scsi host3: ahci
[1.166113] scsi host4: ahci
[1.166971] scsi host5: ahci
[1.167592] scsi host6: ahci
[1.168067] ata1: SATA max UDMA/133 abar m4096@0x9000 port 
0x9100 irq 31
[1.169210] ata2: SATA max UDMA/133 abar m4096@0x9000 port 
0x9180 irq 31
[1.170158] ata3: SATA max UDMA/133 abar m4096@0x9000 port 
0x9200 irq 31
[1.170983] ata4: SATA max UDMA/133 abar m4096@0x9000 port 
0x9280 irq 31
[1.171765] ata5: SATA max UDMA/133 abar m4096@0x9000 port 
0x9300 irq 31
[1.172612] ata6: SATA max UDMA/133 abar m4096@0x9000 port 
0x9380 irq 31

[1.180922] sd 0:0:0:0: Power-on or device reset occurred
[1.182051] sd 0:0:0:0: [sda] 19531250 512-byte logical blocks: (10.0 
GB/9.31 GiB)

[1.182860] sd 0:0:0:0: [sda] 4096-byte physical blocks
[1.183439] sd 0:0:0:0: [sda] Write Protect is off
[1.183945] sd 0:0:0:0: [sda] Mode Sense: 63 00 00 08
[1.183988] sd 0:0:0:0: [sda] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA

[1.185019] sd 0:0:0:0: [sda] Optimal transfer size 4194304 bytes
[1.217913]  sda: sda1 sda14 sda15
[1.219876] sd 0:0:0:0: [sda] Attached SCSI disk
[1.485700] ata2: SATA link down (SStatus 0 SControl 300)
[1.487349] ata3: SATA link down (SStatus 0 SControl 300)
[1.488903] ata5: SATA link down (SStatus 0 SControl 300)
[1.490509] ata6: SATA link down (SStatus 0 SControl 300)
[1.492179] ata4: SATA link down (SStatus 0 SControl 300)
[1.493897] ata1: SATA link down (SStatus 0 SControl 300)
[1.671112] EXT4-fs (sda1): mounted filesystem with ordered data 
mode. Opts: (null)
[1.760312] Not activating Mandatory Access Control as 
/sbin/tomoyo-init does not exist.

[1.966827] systemd[1]: Inserted module 'autofs4'
[2.018048] systemd[1]: systemd 241 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
-PCRE2 default-hierarchy=hybrid)

[2.023560] systemd[1]: Detected virtualization kvm.
[2.024855] systemd[1]: Detected architecture x86-64.
[2.044339] systemd[1]: Set hostname to .
[2.324858] systemd[1]: Reached target Remote File Systems.
[2.327595] systemd[1]: Started Forward Password Requests to Wall 
Directory Watch.

[2.331404] systemd[1]: Reached target System Time Synchronized.
[2.334587] systemd[1]: Listening on udev Kernel Socket.
[2.337157] systemd[1]: Listening on Journal Socket (/dev/log).
[2.340047] systemd[1]: Created slice system-getty.slice.
[2.396217] EXT4-fs (sda1): re-mounted. Opts: discard,errors=remount-ro
[2.407729] EXT4-fs (sda1): resizing filesystem from 2408634 to 
2408634 blocks
[2.434805] systemd-journald[459]: Received request to flush runtime 
journal from PID 1
[2.562550] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4

[2.571579] pstore: Using crash dump compression: deflate
[2.572711] pstore: Registered efi as persistent store backend
[2.575821] iTCO_vendor_support: vendor-support=0
[2.581114] sd 0:0:0:0: Attached scsi generic sg0 type 0
[2.581344] ACPI: Power Button [PWRF]
[2.587588] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[2.588563] iTCO_wdt: Found a ICH9 TCO device (Version=2, TCOBASE=0x0660)
[2.590081] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[2.673312] cryptd: max_cpu_qlen set to 1000
[2.693446] AVX2

Bug#983923: linux-image-4.19.0-13-cloud-amd64: Please add CONFIG_MAXSMP to the linux-image-cloud-amd64 kernel

[Louis Bouchard]

Hello,



Do any of the cloud providers supported by the cloud kernel build
(primarily AWS and Azure) offer VMs with >64 physical cores?

noah



After doing more research, it appears that the use of the -smp 96 option 
without any other precision creates a VM with one core and 96 sockets.


When using the option --smp cores=96 the VM is created with 96 cores and 
one socket and the 4.19.0-13 boots correctly.


So the addition of MAXSMP is not required to have a VM correctly started 
with more than 64 cpus.


Thanks for you attention,

Kind regards,

...Louis

Bug#983923: linux-image-4.19.0-13-cloud-amd64: Please add CONFIG_MAXSMP to the linux-image-cloud-amd64 kernel

[Louis Bouchard]

Hello,

Le 03/03/2021 à 17:32, Salvatore Bonaccorso a écrit :

Gut feeling: This is out of scope for an update in stable. But if then
it would need probably discussion as well with the release team.

Ben, Bastian, opinions on this?

Salvatore



Thank you for the quick update. I just want to mention that this makes 
the Debian Buster cloud image unusable for any VM with more than 64 cpus.


Kind regards,

...Louis

Bug#983923: linux-image-4.19.0-13-cloud-amd64: Please add CONFIG_MAXSMP to the linux-image-cloud-amd64 kernel

[Louis Bouchard]

Package: src:linux
Version: 4.19.160-2
Severity: important

Dear maintainer,

Please enable the MAXSMP kernel config parameter for the
linux-image-cloud-amd64 kernel image. This is the configuration
currently used in kernel 5.10 package.

When being used on a server with the latest AMD EPYC 7543 processors
(Milan), starting a QEMU VM with more than 64 processors will trigger a
kernel panic in the VM.

This has been tested on a Ubuntu Bionic host with QEMU versions 1.2.11
as well as 4.2.3 (sorry but all of our QEMU hosts use Ubuntu)

Here is an example of the situation :

### Host configuration

# dmidecode -s processor-version
AMD EPYC 7543 32-Core Processor
# nproc
128

# wget
# 
http://cloud.debian.org/images/cloud/buster/daily/20210303-565/debian-10-genericcloud-amd64-daily-20210303-565.qcow2

# qemu-img create -F qcow2 -f qcow2 -b
# debian-10-genericcloud-amd64-daily-20210303-565.qcow2 buster.qcow2 10G
# cat startit
cp /usr/share/OVMF/OVMF_CODE.fd /tmp
cp /usr/share/OVMF/OVMF_VARS.fd /tmp
/usr/bin/qemu-system-x86_64 \
-enable-kvm \
-display none \
-monitor none \
-nodefaults \
-nographic \
-serial mon:stdio \
-cpu host \
-smp $2 \
-m 8G \
-drive if=pflash,format=raw,readonly,file=/tmp/OVMF_CODE.fd \
-drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd \
-drive file=./$1,if=none,id=disk0 \
-device virtio-blk-pci,drive=disk0,id=virblk0,bootindex=1 \
-netdev user,id=n1 \
-device virtio-net-pci,netdev=n1

### Proof that the script is working as expected

# ./startit buster.qcow2 64
...
Debian GNU/Linux 10 debian ttyS0

debian login: root
password:

root@debian:~# nproc
64

### Example of the kernel panic situation with more dans 64 CPUS
$ ./startit buster.qcow2 66
[0.007858] RSP: :af5d40ebfea0 EFLAGS: 00010202
[0.007858] RAX: a57bd440 RBX: 01ed RCX:
0002
[0.007858] RDX: 9bf33643c7b0 RSI: af5d40ebfec8 RDI:
01ed
[0.007858] RBP: af5d40ebff38 R08: 9bf336412000 R09:
9bf3360006d8
[0.007858] R10: 9bf336000700 R11:  R12:
af5d40ebfec8
[0.007858] R13: a423e706 R14:  R15:

[0.007858]  ? start_secondary+0x156/0x200
[0.007858]  ? start_secondary+0x156/0x200
[0.007858]  _get_random_bytes+0x7d/0x1b0
[0.007858]  ? rcu_cpu_starting+0x136/0x150
[0.007858]  ? cpumask_next+0x16/0x20
[0.007858]  ? speculative_store_bypass_ht_init+0x6d/0xb0
[0.007858]  start_secondary+0x156/0x200
[0.007858]  secondary_startup_64+0xa4/0xb0
[0.007858] Modules linked in:
[0.007858] CR2: 022d
[0.007858] BUG: unable to handle kernel NULL pointer dereference at
022d
[0.007858] PGD 0 P4D 0 [0.007858] Oops:  [#26] SMP NOPTI
[0.007858] CPU: 64 PID: 0 Comm: swapper/64 Tainted: G  D
4.19.0-14-cloud-amd64 #1 Debian 4.19.171-2
[0.007858] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 0.0.0 02/06/2015

### Example with a locally compiled kernel using the documentation at
https://wiki.debian.org/DebianKernel/GitBisect with MAXCPU enabled :

$ ./startit buster.qcow2 128
...
Debian GNU/Linux 10 debian ttyS0

debian login: root
password:

root@debian:~# nproc
128

root@debian:~# uname -a
Linux debian 4.19.171-maxcpu #88 SMP Wed Mar 3 10:43:25 UTC 2021 x86_64
GNU/Linux

root@debian:~# egrep "NR_CPUS|MAXSMP" /boot/config-4.19.171-maxcpu
CONFIG_MAXSMP=y
CONFIG_NR_CPUS_RANGE_BEGIN=8192
CONFIG_NR_CPUS_RANGE_END=8192
CONFIG_NR_CPUS_DEFAULT=8192
CONFIG_NR_CPUS=8192

Please be aware that the same test done on an older version of the AMD
EPYC CPU (namely AMD EPYC 7401P 24-Core Processor) will not trigger this
problem.



-- Package-specific info:
** Version:
Linux version 4.19.0-13-cloud-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.160-2 (2020-11-28)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-13-cloud-amd64 
root=UUID=daf85f0d-98b3-4a1c-870f-cd2b3cd58684 ro console=tty0 
console=ttyS0,115200 earlyprintk=ttyS0,115200 scsi_mod.use_blk_mq=Y


** Not tainted

** Kernel log:

** Model information
[0.717177] pci :00:01.0: Activating ISA DMA hang workarounds
[0.718238] PCI: CLS 0 bytes, default 64
[0.718336] Unpacking initramfs...
[1.129371] Freeing initrd memory: 12788K
[1.131669] Initialise system trusted keyrings
[1.132620] Key type blacklist registered
[1.134165] workingset: timestamp_bits=40 max_order=19 bucket_order=0
[1.138488] zbud: loaded
[1.328162] Key type asymmetric registered
[1.333078] Asymmetric key parser 'x509' registered
[1.333768] Block layer SCSI generic (bsg) driver version 0.4 loaded 
(major 250)

[1.334783] io scheduler noop registered (default)
[1.335519] io scheduler deadline registered
[1.336409] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[1.359657] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) 
is a 16550A
[1.361880] i8042: PNP: PS/2 Controller 

Bug#887181: sosreport should depend on e2fsprogs explicitly

[Louis Bouchard]

Hello Andreas,

Sorry for the late reply.

sosreport is in fact designed to silently ignore situations where commands
issued are not available. So I do thing, as you suggest, that a Recommend
would be more suitable in that context.

I will do my best to fix that as soon as possible.

Kind regards,

...Louis

2018-01-21 9:59 GMT+01:00 Andreas Henriksson :

> On Sun, Jan 14, 2018 at 08:11:31PM +0100, Helmut Grohne wrote:
> > Package: sosreport
> [...]
> > /usr/share/sosreport/sos/plugins/cman.py contains debugfs. According to
> file it is a C++ source, ASCII text
> > /usr/share/sosreport/sos/plugins/dlm.py contains debugfs. According to
> file it is a C++ source, ASCII text
> > /usr/share/sosreport/sos/plugins/filesys.py contains dumpe2fs.
> According to file it is a C++ source, ASCII text
> > /usr/share/sosreport/sos/plugins/gfs2.py contains debugfs. According to
> file it is a C++ source, ASCII text
> > /usr/share/sosreport/sos/plugins/kvm.py contains debugfs. According to
> file it is a C++ source, ASCII text
> [...]
>
> All the debugfs matches seems to be false positives, but filesys.py is
> interesting.
>
> The following commands seems to be used (but I'm not sure exactly what
> the impact of them missing are, if only the information will be missing
> from report or complete failure):
> mount, df, findmnt, lsof, dumpe2fs
>
> It thus looks like the package might need to add the following
> dependencies:
> mount, lsof, e2fsprogs
>
> If command failure is ok, then a recommends might be more suitable.
> Would be great to hear something from the maintainer on this matter.
>
> Regards,
> Andreas Henriksson
>

Bug#877250: conffile /etc/default/kdump-tools changed by maintainer scripts

[Louis Bouchard]

Hello Thadeu,

Le 24/10/2017 à 16:30, Thadeu Lima de Souza Cascardo a écrit :
> Package: kdump-tools
> Followup-For: Bug #877250
>
> Here is a patch for the issue.

Thank you very much for your patch !

Now that I've sorted out my GPG worries, I'll be able to include your
patch and upload a new version, so makedumpfile doesn't get dropped out
of testing.

Kind regards,

...Louis

Bug#877250: conffile /etc/default/kdump-tools changed by maintainer scripts

[Louis Bouchard]

Hello,

I based my change on the kexec prompting, but I now realise that kexec
doesn't touch a conffile.

I'm split between your suggestion of using a template (more complex) and
simply leaving the file as a conffile and making it enabled by default
which is closer to what is expected from a package which should be ready
to be used one installed.

Any suggestion ?

Kind regards,

...Louis

Bug#863858: checkup

[Louis Bouchard]

Hello Dann,

Le 14/08/2017 à 19:54, dann frazier a écrit :
> hey Louis!
>   I wonder if you've had time to take a look at my proposed fix for
> this. If you're generally OK with the approach but lacking time to
> prepare the upload, I'd be happy to prepare an NMU.
>
>   -dann

I'm sorry that I dropped the ball on this one.

I'll look at it now and will do my best to upload it by EOD or tomorrow.
If I see it slip, I'll wave at you for your NMU proposal.


Kind regards,


...Louis

Bug#863858: issues with grub config symlinks

[Louis Bouchard]

Hello Dan,

Le 01/06/2017 à 06:11, dann frazier a écrit :
> Package: kdump-tools
> Version: 1:1.6.1-1
> Severity: normal
>
> In 1.5.9-6, a facility was added to make /etc/default/grub.d/kdump-tools.cfg a
> symlink, pointing to an appropriate architecture-specific config, with
> ppc64el as the initial user. There are a couple of issues with this:
>
>   - It doesn't work on ppc64el today. Reason being that the postinst
> uses the "arch" command to ID the architecture. That returns the
> kernel arch name (ppc64*le*), not the Debian port name
> (ppc64*el*), so the intended symlink is not created.
>   - This method requires that we install all of the arch-specific
> configs on every arch, even though they aren't needed.
>
> I wonder if we could simplify this by doing the default config file
> selection at build time instead of installtime. That should still solve
> preserve the behavior of dpkg only considering the file to be modified
> if the user manually edited it.
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.11.0-trunk-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 kdump-tools depends on:
> ii  bsdmainutils   9.0.12+nmu1
> ii  debconf [debconf-2.0]  1.5.61
> ii  init-system-helpers1.48
> ii  kexec-tools1:2.0.14-1
> ii  lsb-base   9.20161125
> ii  makedumpfile   1:1.6.1-1
>
> kdump-tools recommends no packages.
>
> kdump-tools suggests no packages.
>
> -- Configuration Files:
> /etc/default/kdump-tools changed [not included]
>
> -- debconf information:
> * kdump-tools/use_kdump: false

This is definitively a better solution than a symlink hack. Let's figure
out how to handle the upgrade & I'll hapilly merge it in.


Kind regards,


..Louis

Bug#862411: kdump-tools does not work on system with multipath root

[Louis Bouchard]

Package: kdump-tools
Severity: important

The scsi_dh_alua module is missing from the kdump specific
initrd.img.

It needs to be added in order for a kernel dump to work on
system with multipath root (See Ubuntu bug LP: #1635597)


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64
 (x86_64)

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

Bug#809669: RC Bug NMU diff

[Louis Bouchard]

Hello,

Le 06/05/2017 à 20:09, Gaudenz Steinlin a écrit :
> 
> Hi
> 
> I uplaoded an NMU to unstable to fix this bug. I mostly used the debdiff
> prepared by Louis Bouchard but fixed the version number to be
> 0.93.1+nmu1 instead of 0.93.2 and actually fixed the systemd unit in the
> way proposed in this bug. The debdiff attached to the bug missed the
> critical changes.
> 
> Gaudenz
> 
> 
> 
> 

Thank you for the upload. Sorry for the missing bits; I new I'd get bitten by my
two separate Ubuntu uploads.

I will send the fix upsteam in a few minutes.

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer,
Ubuntu Developer / Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#809669: unattended-upgrades: files got created under /var/ mountpoint

[Louis Bouchard]

Hello,

The debdiff that I provided contains two typos in a comment :

> 64 +# Explicitely enable and start the service.i Debian Bug #797108 for

It should read Explicitly and "start the service. Debian"

Just let me know if you want an updated debdiff or if you will be fixing it up
yourself.

Kind regards,

...Louis


-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61



signature.asc
Description: OpenPGP digital signature

Bug#809669: unattended-upgrades: files got created under /var/ mountpoint

[Louis Bouchard]

Hello,

Here is the patch for this issue that I uploaded to Ubuntu. It is slightly
adapted to take into account the possibility of being install on a non-systemd
installation.

I tried to make the changelog entry as explicit as possible but here are some
details.

As outlined previously, the systemd unit is changed to be an ExecStart instead
of an ExecStop. RequiresMountsFor= are added for /var/log, /var/run, /var/lib &
/boot. Disabling DefaultDependencies is removed so, as outlined previously,
local-fs.target might be superfluous.  RemainAfterExit is set to Yes so the unit
is seen as started. WantedBy is set to multi-user.target

This introduces a problem since Bug #797108[1] is causing the unit not to be
enabled upon upgrade. The following is done to work around this issue:

1) On systemd enabled system, postinst forces the unattended-upgrades service to
be disabled before deb-systemd-helper is executed so the previous
shutdown.target symlink does not remain.

2) At the end of the postinst script, after the deb-systemd-helper has been run,
manually enable and start the service. This will leave the service correctly
configured, as if the deb-systemd-helper had no bug.

3) systemctl enable requires the SysV init script to have a Default-Start
statement in the header otherwise it fails. Add the header in the script.

4) Remove the override_dh_installinit since it uses the 'stop' option which is
no longer available hence switching to 'default' which is the normal installinit
behavior. The postinst script also needs to cleanup the faulty stop symlink
created previously otherwise the systemclt enable fails.

5) Add DEP8 tests to verify that the unit is correctly started and that
InstallOnShutdown works as expected.

I have only tested the upgrade from 0.93.1 to 0.93.2 on Debian/Sid but I have
done extensive testing on Ubuntu which includes :

 * do-release-upgrade from Trusty(upstart) to Xenial(systemd)
 * upgrade on Xenial, Yakkety, Zesty & Artful

Please let me know if I can help with any more testing.

Kind regards,

...Louis

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797108
--
Louis Bouchard
Software engineer,
Ubuntu Developer / Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61
@@ -1,3 +1,34 @@
+unattended-upgrades (0.93.2) unstable; urgency=medium
+
+  [ Louis Bouchard ]
+  * Fix the unattended-upgrades.service unit not correctly working:
+- d/rules : Remove the override_dh_installinit. The stop option is no 
longer
+  available so the command falls back to default. This is the normal
+  behavior so the override is not required
+- d/unattended-upgrades.init : Add Default-Start runlevels, otherwise the
+  unattended-upgrades.service unit cannot be enabled on boot
+- d/postinst : Cleanup the stop symlinks created by the wrong
+  override_dh_installinit. Without that, the systemd unit cannot be
+  enabled correctly.
+  Force disable the service before deb-systemd-helper runs so the old
+  symlink is not left dangling (workaround for Debian Bug #797108).
+  Force enable and start of the systemd unit to work around Debian Bug 
#797108
+  which fails to enable systemd units correctly when WantedBy= statement
+  is changed which is the case here.
+- d/unattended-upgrades.service : Fix the service so it runs correctly on
+  shutdown :
+Remove DefaultDependencies=no : Breaks normal shutdown dependencies
+Set After= to network.target and local-fs.target. Since our service is
+now ExecStop, it will run before network and local-fs become 
unavailable.
+Add RequiresMountsFor=/var/log /var/run /var/lib /boot : Necessary if
+/var is a separate file system. Set WantedBy= to multi-user.target
+- Add DEP8 tests to verify the following :
+  Verify that the unattended-upgrades.service unit is enabled and started.
+  Verify that InstallOnShutdown works when configured.
+(Closes: #809669)
+
+ -- Louis Bouchard <lo...@ubuntu.com>  Mon, 24 Apr 2017 14:42:01 +0200
+
 unattended-upgrades (0.93.1) unstable; urgency=medium
 
   [ Brian Murray ]
diff -Nru unattended-upgrades-0.93.1/debian/postinst 
unattended-upgrades-0.93.2/debian/postinst
--- unattended-upgrades-0.93.1/debian/postinst  2016-12-11 11:31:26.0 
+0100
+++ unattended-upgrades-0.93.2/debian/postinst  2017-04-24 14:42:01.0 
+0200
@@ -61,6 +61,20 @@
 && [ -f /etc/rc6.d/S[0-9][0-9]unattended-upgrades ] ; then
 update-rc.d -f unattended-upgrades remove
 fi
+# Recover from broken dh_installinit override in versions < 0.93.2
+if dpkg --compare-versions "$2" lt "0.93.2"; then
+if [ -f /etc/rc0.d/K[0-9][0-9]unattended-upgrades ] \
+&& [ -f /etc/rc6.d/K[0-9][0-9]unattended-upgrades ] ; then
+   update-rc.d -f unattended-upgrades remove
+   fi
+   # If runni

Bug#809669: unattended-upgrades: files got created under /var/ mountpoint

[Louis Bouchard]

Hello,

Le 20/04/2017 à 12:27, Simon McVittie a écrit :
> On Tue, 11 Apr 2017 at 17:25:00 +, Niels Thykier wrote:
>> On Thu, 2 Mar 2017 17:59:02 +0100 Louis Bouchard
>> <louis.bouch...@canonical.com> wrote:
>>> It now tests correctly and I am preparing an upload to our development 
>>> release.
>>
>> Any news on this?  I cannot see an upload to unstable yet, did something
>> hold you up?
> 
> The "us" referred to in "our development release" appears to have been
> Ubuntu, not Debian.
> 
> However, the systemd unit proposed by Scott Leggett is not actually the
> same as the one now shipped in Ubuntu zesty. Is this deliberate? Here
> is a diff:
> 
> --- ubuntu/debian/unattended-upgrades.service
> +++ scott/debian/unattended-upgrades.service
> @@ -1,7 +1,6 @@
>  [Unit]
>  Description=Unattended Upgrades Shutdown
> -DefaultDependencies=no
> -Before=shutdown.target reboot.target halt.target network.target 
> local-fs.target
> +After=network.target
>  Documentation=man:unattended-upgrade(8)
>  
>  [Service]
> @@ -11,4 +10,4 @@ 
> ExecStop=/usr/share/unattended-upgrades/unattended-upgrade-shutdown
>  TimeoutStopSec=900
>  
>  [Install]
> -WantedBy=shutdown.target
> +WantedBy=multi-user.target
> 
> I'm concerned that the version now shipped in Ubuntu might in fact be shut
> down *after* the network is taken down, because Before/After dependencies
> are about the order of startup: shutdown happens in the reverse order.
> So if unattended-upgrades.service has After=network.target, as in Scott's
> proposed unit, it will be started (which now does nothing) after
> network.target is started, but stopped (which is where the real work
> happens) before network.target is stopped. That seems like the right
> thing, and the version in Ubuntu zesty seems like only a partial fix.
> 
> S
> 

First of all, I am sorry for not keeping up with my work in both bug reports.
Recent events at my employer have made things a bit more difficult, including
the recent release of Ubuntu Zesty.

The fix in Zesty is indeed incomplete, but final freeze prevented me for
including the definitive fix in Zesty. This should happen shortly.

I am also preparing a .debdiff of a proposed debian fix that I will create and
test today and tomorrow. In the meantime, here is the final unit that will be
shiped :

> [Unit]
>  
> Description=Unattended Upgrades Shutdown  
>  
> After=network.target local-fs.target  
>  
> RequiresMountsFor=/var/log /var/run /var/lib /boot
>  
> Documentation=man:unattended-upgrade(8)   
>  
>   
>  
> [Service] 
>  
> Type=oneshot  
>  
> RemainAfterExit=yes   
>  
> ExecStop=/usr/share/unattended-upgrades/unattended-upgrade-shutdown   
>  
> TimeoutStopSec=900
>  
>   
>  
> [Install] 
>  
> WantedBy=multi-user.target
>  

DefaultDependencies=no Needs to be removed as switching from shutdown.target to
multi-user.target requires to have the DefaultDependencies

RequireMountsFor= provides adequate dependencies when /var is separate.

In changing WantedBy= I ran into Debian Bug #797108 which causes the service to
not be properly enabled on upgrade. Working around that took longer than 
expected.

So hopefully I will provide a final proposition for this by End of week.

Kind regards,

...Louis


-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#797108: init-system-helpers: deb-systemd-helper doesn't remove old links when changing WantedBy= at package upgrade

[Louis Bouchard]

Hello,

I have tested the patch proposed in this bug and it doesn't work for me.

It does indeed remove the old WantedBy= link, but doesn't create the new one and
the two lines (old & new) remain in the dsh_state file.

Without the patch, the two lines are present in the dsh_state file, but the
second one is never created since in enable() :

> my $create_links = 0;
> if (debian_installed($scriptname)) {
> $create_links = 1 unless no_link_installed($scriptname, 
> $service_path);

no_link_installed() will return false for the second entry in the dsh_state
file, which is the link to be created for the modified WantedBy=

HTH,

Kind regards,

...Louis
-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#858821: unattended-upgrades.service systemd unit fails to start correctly

[Louis Bouchard]

Package: unattended-upgrades
Version: 0.93.1
Severity: important



Dear Maintainer,

After installation, the unattended-upgrades.service fails to start
correctly and is left in an invalid state :

# systemctl status unattended-upgrades.service
 unattended-upgrades.service - Unattended Upgrades Shutdown
   Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; 
vendor preset: enabled)
   Active: inactive (dead)
   Docs: man:unattended-upgrade(8)

This is caused by the fact that the debian/rules's
override_dh_installinit forces an update-rc.d stop which is no longer
supported. It then reverts to update-rc.d default which only applies the
Default-Stop in the SysV script.

When the unit is enabled by systemd, it fails with the following message
since there is no Default-Start :

systemctl enable unattended-upgrades.service
Synchronizing state of unattended-upgrades.service with SysV service
script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable unattended-upgrades
update-rc.d: error: unattended-upgrades Default-Start contains no
runlevels, aborting.

A patch fixing this problem will follow soon.

Please review this patch for inclusion in a new version of the package.

Kind regards,

Louis Bouchard

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-67-generic (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unattended-upgrades depends on:
ii  apt1.4~rc2
ii  apt-utils  1.4~rc2
ii  debconf [debconf-2.0]  1.5.60
ii  init-system-helpers1.47
ii  lsb-base   9.20161125
ii  lsb-release9.20161125
ii  python33.5.3-1
ii  python3-apt1.4.0~beta2
ii  ucf3.0036
ii  xz-utils   5.2.2-1.2+b1

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-128+b1

Versions of packages unattended-upgrades suggests:
pn  bsd-mailx  
ii  exim4-daemon-light [mail-transport-agent]  4.89-1
pn  needrestart

-- debconf information:
  unattended-upgrades/origins_pattern: 
"origin=Debian,codename=${distro_codename},label=Debian-Security";
  unattended-upgrades/enable_auto_updates: true

Bug#809669: unattended-upgrades: files got created under /var/ mountpoint

[Louis Bouchard]

Hello,

Le 21/02/2017 à 12:31, Scott Leggett a écrit :
> Hi Louis,
> 
> On Wed, 15 Feb 2017 14:34:58 +0100 Louis Bouchard 
> <louis.bouch...@canonical.com> wrote:
>> Hello,
>>
>> I may be wrong, but this clearly shows that the Unattended Upgrades Shutdown
>> unit starts once the target Network is being brought down :
> 
> I don't think the replacement unit I proposed was installed correctly on
> your system. Could you double check?
> 
>> Pinging google for 4 seconds is not sufficient, the Unattended upgrade 
>> shutdown
>> can run for saveral minutes before completing.
> 
> This is the express purpose of network.target. Here's the relevant
> snippet from `man systemd.special`:
> 
>   network.target
> This unit is supposed to indicate when network functionality is
> available, but it is only very weakly defined what that is supposed
> to mean, with one exception: at shutdown, a unit that is ordered
> after network.target will be stopped before the network — to
> whatever level it might be set up then — is shut down. It is hence
> useful when writing service files that require network access on
> shutdown, which should order themselves after this target, but not
> pull it in. Also see Running Services After the Network is up[1] for
> more information. Also see network-online.target described above.
> 

The unit was correctly installed but another issue made it show as an incorrect
behavior.

It now tests correctly and I am preparing an upload to our development release.

Thanks

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61



signature.asc
Description: OpenPGP digital signature

Bug#809669: unattended-upgrades: files got created under /var/ mountpoint

[Louis Bouchard]

Hello,

I may be wrong, but this clearly shows that the Unattended Upgrades Shutdown
unit starts once the target Network is being brought down :

> Feb 15 12:35:52 ZunattendedUpgrade systemd[1]: Stopped target Network is 
> Online.
> Feb 15 12:35:52 ZunattendedUpgrade systemd[1]: Stopped target Network.
> Feb 15 12:35:52 ZunattendedUpgrade systemd[1]: Started Unattended Upgrades 
> Shutdown.
> Feb 15 12:35:52 ZunattendedUpgrade systemd[1]: Stopping ifup for ens3...
> Feb 15 12:35:52 ZunattendedUpgrade systemd[1]: Stopping Raise network 
> interfaces...
> Feb 15 12:35:52 ZunattendedUpgrade systemd[1]: Reloading.
> Feb 15 12:35:52 ZunattendedUpgrade systemd[1]: Reloading.
> Feb 15 12:35:52 ZunattendedUpgrade dhclient[2799]: Killed old client process
> Feb 15 12:35:52 ZunattendedUpgrade ifdown[2765]: Killed old client process
> Feb 15 12:35:52 ZunattendedUpgrade systemd[1]: Reloading.
> Feb 15 12:35:52 ZunattendedUpgrade systemd[1]: Stopped Raise network 
> interfaces.
> Feb 15 12:35:53 ZunattendedUpgrade dhclient[2799]: Internet Systems 
> Consortium DHCP Client 4.3.3
> Feb 15 12:35:53 ZunattendedUpgrade ifdown[2765]: Internet Systems Consortium 
> DHCP Client 4.3.3
> Feb 15 12:35:53 ZunattendedUpgrade ifdown[2765]: Copyright 2004-2015 Internet 
> Systems Consortium.
> Feb 15 12:35:53 ZunattendedUpgrade ifdown[2765]: All rights reserved.
> Feb 15 12:35:53 ZunattendedUpgrade ifdown[2765]: For info, please visit 
> https://www.isc.org/software/dhcp/
> Feb 15 12:35:53 ZunattendedUpgrade dhclient[2799]: Copyright 2004-2015 
> Internet Systems Consortium.
> Feb 15 12:35:53 ZunattendedUpgrade dhclient[2799]: All rights reserved.
> Feb 15 12:35:53 ZunattendedUpgrade dhclient[2799]: For info, please visit 
> https://www.isc.org/software/dhcp/
> Feb 15 12:35:53 ZunattendedUpgrade dhclient[2799]: 
> Feb 15 12:35:53 ZunattendedUpgrade dhclient[2799]: Listening on 
> LPF/ens3/52:54:00:69:a4:c4
> Feb 15 12:35:53 ZunattendedUpgrade ifdown[2765]: Listening on 
> LPF/ens3/52:54:00:69:a4:c4
> Feb 15 12:35:53 ZunattendedUpgrade ifdown[2765]: Sending on   
> LPF/ens3/52:54:00:69:a4:c4
> Feb 15 12:35:53 ZunattendedUpgrade ifdown[2765]: Sending on   Socket/fallback
> Feb 15 12:35:53 ZunattendedUpgrade dhclient[2799]: Sending on   
> LPF/ens3/52:54:00:69:a4:c4
> Feb 15 12:35:53 ZunattendedUpgrade dhclient[2799]: Sending on   
> Socket/fallback
> Feb 15 12:35:53 ZunattendedUpgrade dhclient[2799]: DHCPRELEASE on ens3 to 
> 192.168.1.1 port 67 (xid=0x3e07e0e5)
> Feb 15 12:35:53 ZunattendedUpgrade ifdown[2765]: DHCPRELEASE on ens3 to 
> 192.168.1.1 port 67 (xid=0x3e07e0e5)
> Feb 15 12:35:53 ZunattendedUpgrade systemd[1]: Stopped ifup for ens3.

Pinging google for 4 seconds is not sufficient, the Unattended upgrade shutdown
can run for saveral minutes before completing.

HTH,

Kind regards,

...Louis


-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#809669: unattended-upgrades: files got created under /var/ mountpoint

[Louis Bouchard]

Hi,

The proposed systemd unit change would break :

Unattended-Upgrade::InstallOnShutdown "true";

as the network is no longer available to fetch the archive.

As outlined in the systemd documentation :

"Given two units with any ordering dependency between them, if one unit is shut
down and the other is started up, the shutdown is ordered before the start-up.
It doesn't matter if the ordering dependency is After= or Before=."

In that context, the network needs to remain available until completion of
unattended-upgrade.service.

I'm still looking for a combination that will work in all cases.

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#809669: unattended-upgrades: files got created under /var/ mountpoint

[Louis Bouchard]

Hello,

For info, this also has the potential effect of blocking shutdown (see Ubuntu's
LP: #1654600 [1]) for details.

The unattended-upgrade-shutdown script uses a lock in /var/run to check if an
upgrade job is running. After /var is unmounted, /var/run is no longer present
and  apt_pkg.get_lock() return -1 which normally means that the lock cannot be
taken. In this case, -1 is caused by the fact that the /var/run path no longer
exists. The lock appears to be present, so unattended-upgrade-shutdown waits for
it to go away. The delay to timeout is 10 minutes so the shutdown may block for
10 minutes.

Thought it was worth mentionning.

Kind regards,

...Louis

[1] https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600
-- 
Louis Bouchard
Software engineer,
Ubuntu Developer / Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#851882: crash 7.1.7-1 fails when used on live post 4.8 kernels

[Louis Bouchard]

Package: crash
Version: 7.1.7-1
Severity: normal

Dear Maintainer,

When running a live crash session on a 4.8 kernel or newer, the
crash command will fail with :

WARNING: kernel relocated [382MB]: patching 89934 gdb minimal_symbol values
crash: read error: kernel virtual address: 99c44aa8  type: 
"page_offset_base"
crash: this kernel may be configured with CONFIG_STRICT_DEVMEM, which
   renders /dev/mem unusable as a live memory source.
crash: trying /proc/kcore as an alternative to /dev/mem

crash: seek error: kernel virtual address: 99c44aa8  type: 
"page_offset_base"

This issue is fixed by upstream commit ad1a44f5d9b9a41d2c43bb386c765913275f05bf 
:

From: Dave Anderson <ander...@redhat.com>
Date: Fri, 13 Jan 2017 15:38:39 -0500
Subject: [PATCH] Fix for support of /proc/kcore as the live memory source in
 Linux 4.8 and later x86_64 kernels configured with CONFIG_RANDOMIZE_BASE,
 which randomizes the unity-mapping PAGE_OFFSET value.  Without the patch, the
 crash session fails during session initialization with the error message
 "crash: seek error: kernel virtual address:  type:
 page_offset_base". (ander...@redhat.com)

Running crash on a real crash file works correctly.

Kind Regards,

...Louis Bouchard

-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)

Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#850922: sosreport displays wrong version when run

[Louis Bouchard]

Package: sosreport
Version: 3.3+git50-g3c0349b-1
Severity: minor

Dear Maintainer,

When running sosreport 3.3, version 3.2 is shown.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages sosreport depends on:
ii  python3-six  1.10.0-3
pn  python3:any  

sosreport recommends no packages.

sosreport suggests no packages.

-- no debconf information

Bug#822564: kdump-tools: kdump location (i.e. /var/crash) does not prompt for encrypted LUKS password

[Louis Bouchard]

Hello,

The prompt for the LUKS password is handled by the /scripts/local-top/cryptroot
script which is where the prompt for the passphrase happens. So the kdump-tools
scripts have no way to interact with that phase of the boot.

The problem you seem to be facing is console redirection. When testing with
Debian stable in a VM, the password prompt do appear but most often in the
middle of garbled console output.

If the console is redirected to TTYS0 (by adding console=ttyS0 to the boot
params), it does appear at the console :

> [   81.689863] Call Trace:
> [   81.690088]  [] ? __handle_sysrq+0xe5/0x140
> [   81.690592]  [] ? write_sysrq_trigger+0x2b/0x30
> [   81.691243]  [] ? proc_reg_write+0x3d/0x60
> [   81.691826]  [] ? vfs_write+0xb3/0x1a0
> [   81.692382]  [] ? SyS_write+0x52/0xc0
> [   81.692927]  [] ? SyS_dup2+0x95/0x100
> [   81.693719]  [] ? system_call_fast_compare_end+0xc/0x96
> [   81.694456] Code: c4 08 48 c7 c7 a1 04 23 8d 5b 5d 41 5c 41 5d 41 5e 41 5f 
> e9 a1 96 d0 ff 90 66 66 66 66 90 c7 05 b9 2a 89 00 01 00 00 00 0f ae f8  
> 04 25 00 00 00 00 01 c3 0f 1f 44 00 00 66 66 66 66 90 53 8d
> [   81.698673] RIP  [] sysrq_handle_crash+0x12/0x20
> [   81.699379]  RSP 
> [   81.699746] CR2: 
>   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
>   Volume group "debian8-vg" not found
>   Cannot process volume group debian8-vg
>   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
>   Volume group "debian8-vg" not found
>   Cannot process volume group debian8-vg
> Please unlock disk vda5_crypt:

So kexec-tools has no solution for this issue as it lies outside of its control.
The problem happens long before kdump-tools even gets involved.

Kind regards,

...Louis
-- 
Louis Bouchard
Software engineer,
Ubuntu Developer / Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#847920: kdump-tools uses hardcoded NFS options. Please turn them into parameters

[Louis Bouchard]

Package: kdump-tools
Version: 1:1.6.0-3
Severity: normal

Dear Maintainer,

kdump-config uses hardcoded timeo and retrans values which
are set to very low values.

Please turn those options into parameters defined in the 
/etc/default/kdump-tools and use the default NFS values.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-51-generic (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kdump-tools depends on:
ii  bsdmainutils   9.0.12
ii  debconf [debconf-2.0]  1.5.59
ii  init-system-helpers1.46
ii  kexec-tools1:2.0.12-1
ii  makedumpfile   1:1.6.0-3

kdump-tools recommends no packages.

kdump-tools suggests no packages.

-- debconf information:
* kdump-tools/use_kdump: true

Bug#842019: makedumpfile issues many readpage_elf: Attempt to read non-existent page

[Louis Bouchard]

Package: makedumpfile
Version: 1:1.6.0-2
Severity: grave

Dear maintainer,

When running on kernel 4.8 and higher, makedumpfile will reportthe
following errors when running :

 readpage_elf: Attempt to read non-existent page

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-26-generic (SMP w/4 CPU cores)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages makedumpfile depends on:
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.24-5
ii  libdw1  0.166-2.2
ii  libelf1 0.166-2.2
ii  liblzo2-2   2.08-1.2
pn  perl:any
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages makedumpfile recommends:
ii  crash7.1.5-4
ii  kexec-tools  1:2.0.12-1

makedumpfile suggests no packages.

-- debconf information excluded

Bug#834935: makedumpfile: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Louis Bouchard]

Hello,

Le 20/08/2016 18:47, Adriano Rafael Gomes a écrit :
> Package: makedumpfile
> Tags: l10n patch
> Severity: wishlist
> 
> Hello,
> 
> Please, Could you update the Brazilian Portuguese Translation?
> 
> Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
> tested with msgfmt and podebconf-display-po.
> 
> Kind regards.
> 

I don't know if this is to be expected, but the translation in pt_BR generates
the following output (notice the end of lines #3,4 & #6) :

>  ┌─┤ Configurando kdump-tools 
> ├─┐  
>  │
>   │  
>  │ Se vocescolher essa opo, o mecanismo kdump-tools serhabilitado. Uma 
> reinicializao do sistema ainda   │  
>  │ necessia para habilitar o paretro crashkernel do kernel.   
> │
>  │
>   │  
>  │ O kdump-tools deve ser habilitado por padr?
> │
>  │
>   │  
>  │   
>   │  
>  │
>   │  
>  
> └──┘
>   

Anything specific to be done to get the debconf output to correctly align ?

Kind regards,

...Louis


-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61



signature.asc
Description: OpenPGP digital signature

Bug#838497: libtfm1: Please add basic test coverage to build process

[Louis Bouchard]

Package: libtfm1
Version: 0.13-3
Severity: normal

Package: libtfm1
Version: 0.13-3
Severity: normal

Dear Maintainer,

Ubuntu Main Inclusion Request require some level of build-time
testing for new package inclusion.

debian/rules files states the following :

# the test compiles only mtest which does not really what we want   
  
override_dh_auto_test:

A very basic test is available :
make -f makefile.shared stest   
  
./stest 
  
Could you please consider adding the following test to the 
debian/rules's override so some level of library testing
is performed during the build process ?

Thank you for your attention,

Kind Regards,

Louis Bouchard


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-36-generic (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libtfm1 depends on:
ii  libc6  2.24-3

libtfm1 recommends no packages.

libtfm1 suggests no packages.

-- no debconf information

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-36-generic (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libtfm1 depends on:
ii  libc6  2.24-3

libtfm1 recommends no packages.

libtfm1 suggests no packages.

-- no debconf information

Bug#826889: kdump-tools: Typo in kdump-tools.default (missing unit)

[Louis Bouchard]

Hello,

Le 09/06/2016 21:55, Arnout Boelens a écrit :
> Package: kdump-tools
> Version: 1:1.5.9-7
> Severity: normal
> 
> I found that with the default line is kdump-tools.default
> 
> GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384-:128M"
> 
> running 
> 
> dmesg | grep -i crash
> 
> does not give anything back, suggesting no memory is reserved. Changing the 
> line to
> 
> GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT 
> crashkernel=384M-2G:64M,2G-:128M"
> 

While I am not able to reproduce your situation, I agree that the unit should be
present.

Are you sure that you rebooted after installation of kdump-tools ?

Here is what I have :


> root@sid-kdumptools:~# uname -a
> Linux sid-kdumptools 4.5.0-1-amd64 #1 SMP Debian 4.5.1-1 (2016-04-14) x86_64 
> GNU/Linux
> root@sid-kdumptools:~# dmesg | grep -i crash
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.5.0-1-amd64 
> root=UUID=1fdf5f82-607f-439a-93f8-f4aa41c37c5a ro console=ttyS0,115200 
> crashkernel=384-:128M
> [0.00] Reserving 128MB of memory at 736MB for crashkernel (System 
> RAM: 1023MB)
> [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.5.0-1-amd64 
> root=UUID=1fdf5f82-607f-439a-93f8-f4aa41c37c5a ro console=ttyS0,115200 
> crashkernel=384-:128M
> root@sid-kdumptools:~# kdump-config show
> DUMP_MODE:kdump
> USE_KDUMP:1
> KDUMP_SYSCTL: kernel.panic_on_oops=1
> KDUMP_COREDIR:/var/crash
> crashkernel addr: 0x2e00
>/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.5.0-1-amd64
> kdump initrd: 
>/var/lib/kdump/initrd.img: symbolic link to 
> /var/lib/kdump/initrd.img-4.5.0-1-amd64
> current state:ready to kdump
> 
> kexec command:
>   /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.5.0-1-amd64 
> root=UUID=1fdf5f82-607f-439a-93f8-f4aa41c37c5a ro console=ttyS0,115200 
> irqpoll maxcpus=1 nousb systemd.unit=kdump-tools.service" 
> --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

Anyway, I'm preparing a new release of makedumpfile following upstream's new
release to I will take your suggestion in account.

Kind regards,

...Louis
-- 
Louis Bouchard
Software engineer,
Ubuntu Developer / Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61



signature.asc
Description: OpenPGP digital signature

Bug#826126: corosync: Memory Leak when new cluster configuration is formed.

[Louis Bouchard]

Package: corosync
Version: 2.3.5-3
Severity: important
Tags: patch
User: louis.bouch...@ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

The following patch has been applied to version 2.3.5-3 of 
Ubuntu Xenial to correct a memory leak situation. Bug report
is : https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1563089

Application of this fix from upstream has lead to a solution of the
problem.


  * debian/patches/Totempg-Fix-memory-leak.patch: Fixes memory leak on 
Totempg. (LP: #1563089).

Please consider applying the proposed patch to your package.

Kind regards,

Louis Bouchard



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

Kernel: Linux 4.4.0-23-generic (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru corosync-2.3.5/debian/libtotem-pg5.symbols corosync-2.3.5/debian/libtotem-pg5.symbols
--- corosync-2.3.5/debian/libtotem-pg5.symbols	2015-10-21 17:27:29.0 +0200
+++ corosync-2.3.5/debian/libtotem-pg5.symbols	2016-04-01 15:52:10.0 +0200
@@ -2,7 +2,6 @@
 * Build-Depends-Package: libtotem-pg-dev
  active_algo@Base 1.99.9
  assembly_list_free@Base 1.99.9
- assembly_list_free_trans@Base 2.3.0
  assembly_list_inuse@Base 1.99.9
  assembly_list_inuse_trans@Base 2.3.0
  callback_token_received_handle@Base 1.99.9
diff -Nru corosync-2.3.5/debian/patches/series corosync-2.3.5/debian/patches/series
--- corosync-2.3.5/debian/patches/series	2015-10-22 15:36:41.0 +0200
+++ corosync-2.3.5/debian/patches/series	2016-04-01 15:52:10.0 +0200
@@ -25,3 +25,4 @@
 Use-debian-changelog-timestamp-for-the-build-time-of.patch
 cmap_track_add.3.in-fix-typo-bellow-below.patch
 totemip.h-uses-list.h.patch
+Totempg-Fix-memory-leak.patch
diff -Nru corosync-2.3.5/debian/patches/Totempg-Fix-memory-leak.patch corosync-2.3.5/debian/patches/Totempg-Fix-memory-leak.patch
--- corosync-2.3.5/debian/patches/Totempg-Fix-memory-leak.patch	1970-01-01 01:00:00.0 +0100
+++ corosync-2.3.5/debian/patches/Totempg-Fix-memory-leak.patch	2016-04-01 15:52:10.0 +0200
@@ -0,0 +1,118 @@
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1563089
+Origin: upstream, https://github.com/corosync/corosync/commit/600fb4084adcbfe7678b44a83fa8f3d3550f48b9
+
+---
+
+From 600fb4084adcbfe7678b44a83fa8f3d3550f48b9 Mon Sep 17 00:00:00 2001
+From: Jan Friesse <jfrie...@redhat.com>
+Date: Wed, 10 Feb 2016 12:36:52 +0100
+Subject: [PATCH] totempg: Fix memory leak
+
+Previously there were two free lists. One for operational and one for
+transitional state. Because every node starts in transitional state and
+always ends in the operational state, assembly was always put to normal
+state free list and never in transitional free list, so new assembly
+structure was always allocated after new node connected.
+
+Solution is to have only one free list.
+
+Signed-off-by: Jan Friesse <jfrie...@redhat.com>
+Reviewed-by: Christine Caulfield <ccaul...@redhat.com>
+Reviewed-by: Steven Dake <std...@cisco.com>
+---
+ exec/totempg.c | 26 +++---
+ 1 file changed, 7 insertions(+), 19 deletions(-)
+
+diff --git a/exec/totempg.c b/exec/totempg.c
+index fe111b1..0b46782 100644
+--- a/exec/totempg.c
 b/exec/totempg.c
+@@ -212,12 +212,13 @@ static int callback_token_received_fn (enum totem_callback_token_type type,
+ 
+ DECLARE_LIST_INIT(assembly_list_inuse);
+ 
++/*
++ * Free list is used both for transitional and operational assemblies
++ */
+ DECLARE_LIST_INIT(assembly_list_free);
+ 
+ DECLARE_LIST_INIT(assembly_list_inuse_trans);
+ 
+-DECLARE_LIST_INIT(assembly_list_free_trans);
+-
+ DECLARE_LIST_INIT(totempg_groups_list);
+ 
+ /*
+@@ -291,14 +292,11 @@ static struct assembly *assembly_ref (unsigned int nodeid)
+ 	struct assembly *assembly;
+ 	struct list_head *list;
+ 	struct list_head *active_assembly_list_inuse;
+-	struct list_head *active_assembly_list_free;
+ 
+ 	if (totempg_waiting_transack) {
+ 		active_assembly_list_inuse = _list_inuse_trans;
+-		active_assembly_list_free = _list_free_trans;
+ 	} else {
+ 		active_assembly_list_inuse = _list_inuse;
+-		active_assembly_list_free = _list_free;
+ 	}
+ 
+ 	/*
+@@ -318,8 +316,8 @@ static struct assembly *assembly_ref (unsigned int nodeid)
+ 	/*
+ 	 * Nothing found in inuse list get one from free list if available
+ 	 */
+-	if (list_empty (active_assembly_list_free) == 0) {
+-		assembly = list_entry (active_assembly_list_free->next, struct assembly, list);
++	if (list_empty (_list_free) == 0) {
++		assembly = list_entry (assembly_list_free.next, struct assembly, list);
+ 		list_del (>list);
+ 		list_add (>list, active_assembly_list_inuse);
+ 		assembly->nodeid = nodeid;
+@@ -350,16 +348,9 @@ static struct assembly *assembly_ref (unsigned int nod

Bug#825189: kexec-tools: Fix kexec failure when compiled with gcc > v5 (see LP: #1546260)

[Louis Bouchard]

Package: kexec-tools
Version: 1:2.0.10-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

The following bug was reported and fixed in the latest ubuntu version
(16.04 Xenial) :

 https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1546260

Would you please consider it for inclusion into the latest kexec-tools
package ? Detailed analysis and test results are described in the cited
bug above.


*** /tmp/tmpAyQrrj/bug_body

In Ubuntu, the attached patch was applied to achieve the following:



  * [PowerPC64] Fix failure in purgatory when compiled with gcc5
Application of upstream fixes so kexec-tools work with gcc5 on PowerPC64

commit 4a2ae3a39c64dc43e9d094be9541253234ff4822,
1e423dc297d10eb7ff25c829d2856ef12fc81d77,
3debb8cf3272216119cb2e59a4963ce3c18fe8e3
[lp: #1546260]
   

Thanks for considering the patch.


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

Kernel: Linux 4.4.0-22-generic (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru kexec-tools-2.0.10/debian/control kexec-tools-2.0.10/debian/control
--- kexec-tools-2.0.10/debian/control	2015-12-03 21:44:02.0 +0100
+++ kexec-tools-2.0.10/debian/control	2016-05-24 14:17:39.0 +0200
@@ -2,8 +2,7 @@
 Section: admin
 Homepage: http://kernel.org/pub/linux/utils/kernel/kexec/
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Khalid Aziz 
+Maintainer: Khalid Aziz 
 Build-Depends: debhelper (>= 7.0.0), dh-autoreconf, gnu-efi (>=3.0a-4)[ia64], libz-dev[ia64], po-debconf
 Standards-Version: 3.9.6
 
diff -Nru kexec-tools-2.0.10/debian/patches/lp1546260-fix-purgatory-fail-gcc5.patch kexec-tools-2.0.10/debian/patches/lp1546260-fix-purgatory-fail-gcc5.patch
--- kexec-tools-2.0.10/debian/patches/lp1546260-fix-purgatory-fail-gcc5.patch	1970-01-01 01:00:00.0 +0100
+++ kexec-tools-2.0.10/debian/patches/lp1546260-fix-purgatory-fail-gcc5.patch	2016-03-25 16:55:53.0 +0100
@@ -0,0 +1,265 @@
+Description: [PowerPC64] Fix failure in purgatory when compiled with gcc5
+ Application of upstream fixes so kexec-tools work with gcc5 on PowerPC64
+
+ commit	4a2ae3a39c64dc43e9d094be9541253234ff4822
+ Pass struct mem_sym into machine_apply_elf_rel()
+ On PowerPC64 ABIv2 we need to look at the symbol to determine
+ if it has a local entry point. Pass struct mem_sym into
+ machine_apply_elf_rel() so we can.
+
+ commit	1e423dc297d10eb7ff25c829d2856ef12fc81d77
+ ppc64: purgatory: Handle local symbols in ELF ABIv2
+ The PowerPC64 ELF ABIv2 has the concept of global and local symbols
+ and information on this is encoded in sym->st_other. When doing a
+ R_PPC64_REL24 branch we want to hit the local entry point, so adjust
+ it as necessary.
+
+ commit	3debb8cf3272216119cb2e59a4963ce3c18fe8e3
+ Properly align powerpc64 .toc
+ gcc leaves .toc byte aligned, relying on the linker to align the section.
+ 	* kexec/arch/ppc64/kexec-elf-rel-ppc64.c (machine_verify_elf_rel):
+	  Fudge alignment of .toc section.
+
+Author: Anton Blanchard , Alan Modra 
+Origin: 
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1546260
+--- a/kexec/arch/arm/kexec-elf-rel-arm.c
 b/kexec/arch/arm/kexec-elf-rel-arm.c
+@@ -18,8 +18,9 @@
+ 	return 1;
+ }
+ 
+-void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), unsigned long r_type,
+-	void *location, unsigned long address, unsigned long value)
++void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr),
++	struct mem_sym *UNUSED(sym), unsigned long r_type, void *location,
++	unsigned long address, unsigned long value)
+ {
+ 	switch(r_type) {
+ 	case R_ARM_ABS32:
+--- a/kexec/arch/cris/kexec-elf-rel-cris.c
 b/kexec/arch/cris/kexec-elf-rel-cris.c
+@@ -29,8 +29,9 @@
+ 	return 1;
+ }
+ 
+-void machine_apply_elf_rel(struct mem_ehdr *ehdr, unsigned long r_type,
+-	void *location, unsigned long address, unsigned long value)
++void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr),
++	struct mem_sym *UNUSED(sym), unsigned long r_type, void *location,
++	unsigned long address, unsigned long value)
+ {
+ 	switch(r_type) {
+ 
+--- a/kexec/arch/i386/kexec-elf-rel-x86.c
 b/kexec/arch/i386/kexec-elf-rel-x86.c
+@@ -18,8 +18,9 @@
+ 	return 1;
+ }
+ 
+-void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), unsigned long r_type,
+-	void *location, unsigned long address, unsigned long value)
++void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr),
++	struct mem_sym *UNUSED(sym), unsigned long r_type, void *location,
++	unsigned long address, unsigned long value)
+ {
+ 	switch(r_type) {
+ 	case R_386_32:
+--- 

Bug#819546: vsftpd no longer starts with systemd because of listen_ipv6=NO from Bug: #803999

[Louis Bouchard]

Hello,

To summarize :

1) This reverts an expected and accepted behavior in the Debian community where
daemons should start when installed with an adequate and secure configuration.
Other ftpd packages like pure-ftpd, twoftpd, tftpd-hpa and muddleftpd among
other all do start upon install.

2) This breaks the DEP8 test debian/tests/smoke that expects the vsftpd service
to be running. You might want to fix this or disable the test. This is how the
change in behavior got detected.

3) The installed vsftpd configuration is not considered secure enough to be
enabled by default.

Thank you for looking into this.

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer,
Ubuntu developer / Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

-- 
Louis Bouchard
Software engineer,
Ubuntu Developer / Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61



signature.asc
Description: OpenPGP digital signature

Bug#824525: makedumpfile: kdump on VM's running under hyper-v fails

[Louis Bouchard]

Hello,

The issue I have with your patch is that it will apply
ata_piix.prefer_ms_hyperv=0 no matter what hypervisor is being used.

I am currently working on a solution to implement architecture specific
configurations to kdump-tools. If I can identify an element that will tell me
that we are running on HyperV, then I will apply this HyperV specific change to
/etc/default/kdump-tools so it is taken into account when kdump-config runs.

If you are aware of a command or file that could tell me that kdump-tools is
being installed on an HyperV VM, this would help me out.

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer,
Ubuntu
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#824525: makedumpfile: kdump on VM's running under hyper-v fails

[Louis Bouchard]

Hello Robert,

Thank you for reporting this bug and the associated fix.

I am preparing a new release to address other architecture specific issues with
the kexec command so I'll make sure to include your fix.

Thanks again,

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer,
Ubuntu
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#819546: vsftpd no longer starts with systemd because of listen_ipv6=NO from Bug: #803999

[Louis Bouchard]

Hello,

Le 31/03/2016 06:04, Jörg Frings-Fürst a écrit :
> severity 819546 normal
> thanks
> 
> Hello Louis,
> 
> thank you for spending your time helping to make Debian better with
> this bug report.
> 
> I think that no configuration of vsftpd should be activated without
> verification.
> 
> FTP is also not a service that is absolutely necessary immediately
> after a new installation for the system functionality.
> 
> And there are many examples configurations in the documentation.
> 
> I do not close this bug because when installing no notice will be
> posted.
> 
> CU
> Jörg
> 
> 
> 

I must disagree. First of all, it is an accepted policy that daemons on Debian
do start upon installation of the package. This was the case with vsftpd up
until vsftpd_3.0.2 and only got change with Bug: #803999.

This bug introduces a regression, including on debian/stable which also sets
listen_ipv6=YES.

As a side note, this is not uncommon to set configuration options that diverge
from the default as we can see in man ssh_config :

" Note that the Debian openssh-client package sets several options as
standard in /etc/ssh/ssh_config which are not the
 default in ssh(1):

   ·   SendEnv LANG LC_*
   ·   HashKnownHosts yes
   ·   GSSAPIAuthentication yes"

I do believe that listen_ipv6 should be brought back to YES to avoid the
regression and that the manpage should be updated to indicate such a 
modification.

vsftpd's anonymous access is disabled by default so the systematic enablement of
vsftpd is what should be expected.

Kind regards,

...Louis


-- 
Louis Bouchard
Software engineer,
Ubuntu DeveloperDebian Mainainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61



signature.asc
Description: OpenPGP digital signature

Bug#819546: vsftpd no longer starts with systemd because of listen_ipv6=NO from Bug: #803999

[Louis Bouchard]

Package: vsftpd
Version: 3.0.3-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Bug #803999 sets listen_ipv6=NO as stated in the manpage. In doing so, it
breaks the systemd unit vsftpd which tries to do the following :

 ExecStart=/usr/sbin/vsftpd /etc/vsftpd.conf

Running the command manually leads to :

# /usr/sbin/vsftpd /etc/vsftpd.conf
500 OOPS: vsftpd: not configured for standalone, must be started from inetd

Switching back listen_ipv6=YES allows the vsftpd daemon to start correctly.

Right now, installing vsftpd in a fresh debian/sid will lead to a failure to
start unless the parameter is set to listen_ipv6=YES.

This can be easily shown by running the DEP8 test :

Setting up adt-satdep (0) ...
Processing triggers for systemd (229-3ubuntu1) ...
(Reading database ... 87432 files and directories currently installed.)
Removing adt-satdep (0) ...
adt-run [10:50:30]: test smoke: [---
+ sed -i s/^#\(write_enable=YES\)$/\1/ /etc/vsftpd.conf
+ service vsftpd reload
vsftpd.service is not active, cannot reload.
adt-run [10:50:31]: test smoke: ---]
adt-run [10:50:32]: test smoke:  - - - - - - - - - - results - - - - - - - - - -
smokeFAIL non-zero exit status 1

The systemd service will clearly not work with such a configuration. So either 
the
default in the manpage needs to be changed, or the unit needs to force the 
option
with :
 /usr/sbin/vsftpd /etc/vsftpd.conf -olisten_ipv6=YES

In such a case, it should be outlined somewhere in the manpage.


-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13.0-83-generic (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vsftpd depends on:
ii  adduser3.114
ii  debconf [debconf-2.0]  1.5.59
ii  init-system-helpers1.29
ii  libc6  2.22-4
ii  libcap21:2.24-12
ii  libpam-modules 1.1.8-3.2
ii  libpam0g   1.1.8-3.2
ii  libssl1.0.21.0.2g-1
ii  libwrap0   7.6.q-25
ii  netbase5.3

Versions of packages vsftpd recommends:
ii  logrotate  3.8.7-2
ii  ssl-cert   1.0.37

vsftpd suggests no packages.

-- debconf information:
  vsftpd/username: ftp
  vsftpd/directory: /srv/ftp
# Example config file /etc/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
#
# Run standalone?  vsftpd can run either from an inetd or as a standalone
# daemon started from an initscript.
listen=NO
#
# This directive enables listening on IPv6 sockets. By default, listening
# on the IPv6 "any" address (::) will accept connections from both IPv6
# and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6
# sockets. If you want that (perhaps because you want to listen on specific
# addresses) then you must run two copies of vsftpd with two configuration
# files.
listen_ipv6=NO
#
# Allow anonymous FTP? (Disabled by default).
anonymous_enable=NO
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
#write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
#local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
#anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# If enabled, vsftpd will display directory listings with the time
# in  your  local  time  zone.  The default is to display GMT. The
# times returned by the MDTM FTP command are also affected by this
# option.
use_localtime=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/vsftpd.log
#
# If you 

Bug#817798: crash fails to load with 4.4+ kernels

[Louis Bouchard]

Package: crash
Version: 7.1.4-1ubuntu1
Severity: normal

Dear Maintainer,

When loading a crash dump on 4.4+ kernel, crash fails to load with the 
following msg :

root@DEVAC02:/var/crash/201603092003# crash 
/usr/lib/debug/boot/vmlinux-4.4.0-11-generic dump.201603092003

crash 7.1.4
Copyright (C) 2002-2015 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390x-ibm-linux-gnu"...

please wait... (gathering module symbol data)
crash: invalid structure member offset: module_core_size
   FILE: kernel.c LINE: 3422 FUNCTION: module_init()

[/usr/bin/crash] error trace: 2aa19f62a78 => 2aa19fe1de6 => 2aa1a026e2c => 
2aa1a026d88

This has been reported upstream here :

https://www.redhat.com/archives/crash-utility/2016-January/msg00031.html

Crash version on Xenial should be upgraded to crash-7.1.5

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages crash depends on:
ii  binutils 2.26-5ubuntu1
ii  libc62.21-0ubuntu6
ii  libncurses5  6.0+20160213-1ubuntu1
ii  libtinfo56.0+20160213-1ubuntu1
ii  zlib1g   1:1.2.8.dfsg-2ubuntu4

crash recommends no packages.

Versions of packages crash suggests:
ii  kexec-tools   1:2.0.10-1ubuntu1
ii  makedumpfile  1:1.5.9-5

-- no debconf information

Bug#809844: sosreport: Please backport CVE-2015-7529 to the stable release

[Louis Bouchard]

Hello,

Le 05/01/2016 11:11, Sébastien Delafond a écrit :
> On Jan/04, Louis Bouchard wrote:
>> Package: sosreport
>> Version: 3.2-2
>> Severity: critical
>> Tags: security
>> Justification: root security hole
> 
> This issue is marked "no-dsa" in the security tracker[1] (because it is
> mitigated by the use of fs.protected_symlinks).
> 
> It could, however, possibly be included into stable via
> stable-proposed-updated, if both:
> 
>   - the maintainer is OK to backport the relevant fix against the
> version currently in stable
> 
>   - release managers are OK to include it in the next SPU
> 
> Cheers,
> 
> --Seb
> 
> [1] https://security-tracker.debian.org/tracker/CVE-2015-7529
> 

Thanks for the review.

I'm fine with backporting the fix; matter of fact, I was preparing an email to
the security team with the debdiff so the backport is ready.

Now how do I know about the release managers being OK for inclusion ?

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer,
Ubuntu
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#809844: sosreport: Please backport CVE-2015-7529 to the stable release

[Louis Bouchard]

severity: important

-- 
Louis Bouchard
Software engineer,
Ubuntu
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Bug#809844: sosreport: Please backport CVE-2015-7529 to the stable release

[Louis Bouchard]

Package: sosreport
Version: 3.2-2
Severity: critical
Tags: security
Justification: root security hole



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sosreport depends on:
ii  python3-six  1.8.0-1
pn  python3:any  

sosreport recommends no packages.

sosreport suggests no packages.

-- debconf information excluded

Bug#807047: Acknowledgement (gtimelog: Drop fix-icon-path patch)

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Tags: patch

Here is the debdiff for a proposed fix.

Kind regards,

...Louis

- -- 
Louis Bouchard
Software engineer,
Ubuntu
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWYahQAAoJEFZStL2qfwOtZxUP/i2kXg16PRaySB+MvL75+igJ
Y86+2cRaO2/8vRXppRnwI7tiEHzHMBQSmrWCxhstg/e7Zfhj0SyipmWBqKYazk4q
gK4Hfy9VHqJKehVCv/XslI3gcytUxWMIW8WDU5j8WWmhyGLf7Bl+PbtSeTqN7dZE
RFOHuMYGd8y+uyW3AhnQ8SkEknqMsI68kbHtOMiPjkv8/3wnuqmaZefIDb+4/5Du
RVKV1KPno/eKfo22OBHIprkR4ejhX0agCfvLnXrAYz+MnsyAUyHf0wyMbXS2o6Xs
pT8I9Wj8/Mc6HDWNdTpautFLy6uN83CLKyhcIrqN0XsevzljJc9rkPaQobfrGNXP
dKCo4L4/9XfzAEDpO1YNxhQtCaVLNDBYzvbe0D9uh0LBCqYdbtQchQNqbbTbGNHL
xQsUrRlJVyk0GvqkHoGGB1ciuTUbs0nohrF6e/zSQ5uMCZjcItmYV9LgOjEcEtIC
1qyoPP6qOPo0NbLKc6auxb5J9NtDbfxFcd0hrUmrcnWoIErYb1TCjDYHZjlt/6rO
LU3Rp5SvxgdgQK1OYujsyFqChe7svUwdOFuuuM3VVH3WZe3B1GtYmCrpxJThoqu8
DDJlZc7v/D0Ui12NE52LYgKaVSYVxeoa9KXQfFQs7BoUEqFU9D0c4ixhWITa4k/C
Zj72rn5YH4onNDIG6hDg
=Nbbg
-END PGP SIGNATURE-
diff -Nru gtimelog-0.9.2/debian/changelog gtimelog-0.9.2/debian/changelog
--- gtimelog-0.9.2/debian/changelog 2015-07-22 19:09:52.0 +0200
+++ gtimelog-0.9.2/debian/changelog 2015-12-04 15:45:37.0 +0100
@@ -1,3 +1,10 @@
+gtimelog (0.9.2-2) sid; urgency=medium
+
+  * Drop fix-icon patch as it is no longer needed and
+it breaks what it is supposed to fix (Closes: 807047)
+
+ -- Louis Bouchard <louis.bouch...@ubuntu.com>  Fri, 04 Dec 2015 15:39:02 +0100
+
 gtimelog (0.9.2-1build1) wily; urgency=medium
 
   * No-change rebuild for python3.5 transition
diff -Nru gtimelog-0.9.2/debian/patches/fix-icon-path 
gtimelog-0.9.2/debian/patches/fix-icon-path
--- gtimelog-0.9.2/debian/patches/fix-icon-path 2013-12-07 01:37:23.0 
+0100
+++ gtimelog-0.9.2/debian/patches/fix-icon-path 1970-01-01 01:00:00.0 
+0100
@@ -1,13 +0,0 @@
-Description: Use full icon pathname
-Author: Marius Gedminas <mar...@gedmin.as>
-Bug-Ubuntu: https://bugs.launchpad.net/bugs/1104303
-
 gtimelog-0.9.0.orig/gtimelog.desktop
-+++ gtimelog-0.9.0/gtimelog.desktop
-@@ -5,5 +5,5 @@ Exec=gtimelog
- Terminal=false
- Type=Application
- StartupNotify=true
--Icon=gtimelog
-+Icon=/usr/share/pyshared/gtimelog/gtimelog.png
- Categories=Application;Utility;
diff -Nru gtimelog-0.9.2/debian/patches/series 
gtimelog-0.9.2/debian/patches/series
--- gtimelog-0.9.2/debian/patches/series2015-06-11 16:43:41.0 
+0200
+++ gtimelog-0.9.2/debian/patches/series2015-12-04 15:38:49.0 
+0100
@@ -1 +0,0 @@
-fix-icon-path

Bug#807047: gtimelog: Drop fix-icon-path patch

[Louis Bouchard]

Package: gtimelog
Version: 0.9.2-1build1
Severity: normal

Dear Maintainer,

Please drop the fix-icon-path patch that is no longer
required and breaks icon visibility.


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gtimelog depends on:
ii  gir1.2-appindicator3-0.1  12.10.1+15.04.20141110-0ubuntu1
ii  gir1.2-gtk-3.03.18.5-1ubuntu2
ii  gir1.2-pango-1.0  1.38.1-1
ii  python3   3.5.0-2
ii  python3-gi3.18.2-2
ii  python3-setuptools18.4-2
pn  python3:any   

gtimelog recommends no packages.

Versions of packages gtimelog suggests:
pn  mutt   
ii  vim-gnome  2:7.4.826-1ubuntu1

-- no debconf information

Bug#805463: quassel-client: missing dependancy to phonon4qt5-backend-gstreamer

[Louis Bouchard]

Package: quassel-client
Version: 0.12.2-2
Severity: normal
Tags: patch

Dear Maintainer,

quassel-client sound notifications do not work unless
phonon4qt5-backend-gstreamer package is added.  It should
be added as a dependancy, or at least a Recommends:


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-19-generic (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru quassel-0.12.2/debian/control quassel-0.12.2/debian/control
--- quassel-0.12.2/debian/control	2015-04-27 10:11:12.0 +0200
+++ quassel-0.12.2/debian/control	2015-11-18 12:08:53.0 +0100
@@ -52,7 +52,7 @@
 Package: quassel-client
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
- quassel-data (= ${source:Version})
+ quassel-data (= ${source:Version}), phonon4qt5-backend-gstreamer
 Recommends: oxygen-icon-theme
 Breaks: quassel-client-qt4 (<< 0.11.0-0ubuntu2)
 Replaces: quassel-client-qt4 (<< 0.11.0-0ubuntu2)

Bug#785101: FTBFS on kfreebsd-* due to test-suite failures

[Louis Bouchard]

Package: rsyslog
Version: 8.12.0-1
Followup-For: Bug #785101
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu wily ubuntu-patch

Dear Maintainer,

While investigating FTBS on Ubuntu for i386 and powerpc, I fixed a bug in
tcpflood.c which you may be interested in. It has been submitted as issue
#506 upstream.

Kind regards,

...Louis

*** /tmp/tmpOUr_xN/bug_body

In Ubuntu, the attached patch was applied to achieve the following:


  * debian/patches/fix-testbench-buffer-overflow-ftbs.patch
- Fix FTBS on i386 and powerpc caused by buffer overflow
  detection while running rsyslog testbench.


Thanks for considering the patch.


-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-3-generic (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru rsyslog-8.12.0/debian/patches/fix-testbench-buffer-overflow-ftbs.patch rsyslog-8.12.0/debian/patches/fix-testbench-buffer-overflow-ftbs.patch
--- rsyslog-8.12.0/debian/patches/fix-testbench-buffer-overflow-ftbs.patch	1970-01-01 01:00:00.0 +0100
+++ rsyslog-8.12.0/debian/patches/fix-testbench-buffer-overflow-ftbs.patch	2015-09-02 15:07:21.0 +0200
@@ -0,0 +1,25 @@
+Description: Fix potential buffer overflow detection
+ On some architectures, calculation of edLen may lead to a
+ negative value when the value returned by rand() is less
+ than extraDataLen away from RAND_MAX. The negative value
+ passed to memset() triggers a glibc error. Forcing the
+ cast of rand() to be unsigned avoid the return of a negative
+ value.
+
+Author: Louis Bouchard <louis.bouch...@canonical.com>
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1464201
+Forwarded: https://github.com/rsyslog/rsyslog/issues/506
+---
+Index: rsyslog-8.12.0/tests/tcpflood.c
+===
+--- rsyslog-8.12.0.orig/tests/tcpflood.c	2015-07-08 16:31:07.0 +0200
 rsyslog-8.12.0/tests/tcpflood.c	2015-09-02 14:36:56.168433982 +0200
+@@ -398,7 +398,7 @@
+ 			}
+ 		} else {
+ 			if(bRandomizeExtraData)
+-edLen = ((long) rand() + extraDataLen) % extraDataLen + 1;
++edLen = ((unsigned long) rand() + extraDataLen) % extraDataLen + 1;
+ 			else
+ edLen = extraDataLen;
+ 			memset(extraData, 'X', edLen);
diff -Nru rsyslog-8.12.0/debian/patches/series rsyslog-8.12.0/debian/patches/series
--- rsyslog-8.12.0/debian/patches/series	2015-08-16 18:46:13.0 +0200
+++ rsyslog-8.12.0/debian/patches/series	2015-09-02 15:07:21.0 +0200
@@ -1,2 +1,3 @@
 Don-t-create-a-database.patch
 Don-t-explicitly-link-tcpflood-against-lgcrypt.patch
+fix-testbench-buffer-overflow-ftbs.patch

Bug#791963: Please support ARM64 (upstream work in progress)

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Martin,

While support for arm64 has been added to makedumpfile, the main issue is that
kexec is still not available in the kernel.

So if your requirement is to use makedumpfile on custom kernels that have been
compiled with kexec support, I could backport the patch into 1.5.8. Otherwise,
it will become available with the upcoming release of makedumpfile.

Can you please let me know if you need the backport ?

Kind regards,

...Louis

- -- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVrhhjAAoJEIs9hnyCPnphoUIQAMwfRQVbRIZroa1DfqfUuzPT
Q9n2gLCjql0FqyyabdSFj8CxNhq0zgAHDw9VsvQXbfg/3eKoJxL8wNdMurRsQD2c
B9R9bvnJ9ut+Ah06IUkAVbtktdwhb5eVQWNft7fWv/aO2JNFUhHXhMVKOd/jvQOd
uwJbZ/0sAfjGZVZIJZIMJRUgY8qD3RWg5Sf0r0/PvcmocWT7yjrNLwUGeKFYnoKD
lWdqGTv+nXmTPqABwTqua0nySKJP/EMxt2hZXmDWAgMOxJ8g0WO/MYCg7ScCFPtW
8W0aNSKC5B8FkpREF518O4IAt/W96IXaV5eZeAwU5RP1tXgpKG7uVJweeuchha5P
HKwCCsv8GJ/61DA8xjIQyc8tFZn1qqz7M3D8oQoxv/DO9VN4Mj2WFUvk8PRybdCQ
F6lbRoQXAMemIz+ie8i6Uw1TkNQzJp5AYpb8vDgGDymcDvyk0buDSidyheM3vNan
PLwoM86pgqNwy/JIURSrjw8Q5OBPfOKxunuYkDBsG0AZ8O+unU4fFM1Jlhljdzhm
vvgNkilcRCkemSiayVUgra3fzDxgXGRFAlzoo5OGrz2Z+jqjH+O1wKtTfBsoCJd4
yRFbOizgILdVUgBNdIttWWrPrCztwsg5vOIk1WI4pxF1pFujBfrUSE0BLqHXM1ga
PaF1rhb3V7ZIGr8zWaLZ
=lG08
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792732: sosreport: generating report with --all-logs option results in 0 byte logs

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Heather,

Thank you for reporting this bug on the debian package.

The issue that you are seeing is an upstream bug that has been reported here :

 https://github.com/sosreport/sos/issues/586

While sosreport is actively kept bilingual (i.e. py2 and py3), it is by no
mean exempt from bugs and some of them may be specific to python3.

This situation is currently being actively investigated and, given the recent
activity in the upstream bug, I will try to help out to reproduce and
eventually identify a fix for the problem.

Once the bug is fixed upstream, I will backport the patch to the current
Debian version.

Kind regards,

...Louis
- -- 
Louis Bouchard
Software engineer,
Ubuntu
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVrLRMAAoJEIs9hnyCPnphLywP/ArLVrKXWjkfe63+mhrYi6TR
URo1IIIgyfwvxPy8ZcljXT/mAldfWNFGOJ6DSQM4uBhtCddUj01Opxzglmk6l83t
nuzW5NcQquYHRxXyFhs9Q7TAKSe4ugVmZjWkA2cjBIlfHs1c1pTWnR7OBSSySxpC
eOV+plBj1oXTRbJNhbcL09MVnI0AAvPo8QqFawO3XevfY/TZKWoejz6jXrE9vwgc
5Ch4kwgnSZY0OicxJ36ttKh6AWLLbKuPl5vhmuCeXnUtEbqzoM2fjjAJa2tHnCT2
YZi3LTZ+JBPecVUBixNgTVCS2ohccuh0cEkv7ozBtAcOsPrMmQmPr8Fns4umbGjc
+kCpiqsgqOIDvzDObBc3C7ERcoIMT0kKc9wVzIbJlHqJ9ittq4Ee2ZgHHldbA+J0
qAjVNqMW3tnA8D+lsEUNohEV9BIFqEUoi2fB4Z35UjNqqnm1A65BIk49/rCSH7vq
mzcBh69pamkX7qsDKpOsPHuNlp5aHHjdoezEv2fzsIPsMnZDIjFhPbD+dZcT4n1V
LLYVTtbQOLaKze3RlDSpi0Xk1AGqqgmxL83MorWdRM7wlTJaUF7UZ2L/RQjChD0q
zKjilGyJtV9z/vYBXSrsG6JijOPeN7l2WeQuBzJB9goTr1FvXbllEvLTJ5i6llPS
LIOmtNUU/9Qmczj+3Lk4
=tV0u
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#791906: ifenslave uses obsolete /sys/class/net/{bond}/slave_ naming

[Louis Bouchard]

Package: ifenslave
Version: 2.6
Severity: important
Tags: patch

Dear Maintainer,

Starting with kernel 3.13
(commit 
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=5831d66e8097aedfa3bc35941cf265ada2352317),
 /sys/class/net/{bond}/slave_{ifname} (notice the slave_) no longer exist.

It has been replaced by /sys/class/net/{bond}/lower_{ifname}. The proposed 
patch adds
support for the new naming while remaining backward compatible.

Without this patch, trying to add a bond when this one is already defined
leads to the following obscure error :

root@sid-ifenslave:/sbin# ifenslave bond0 eth1 eth2
sh: echo: I/O error
eth1: could not add interface


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages ifenslave depends on:
ii  ifupdown  0.7.50
ii  iproute2  3.16.0-2

Versions of packages ifenslave recommends:
ii  net-tools  1.60-26+b1

ifenslave suggests no packages.

-- no debconf information
From: Louis Bouchard louis.bouch...@ubuntu.com
Date: Thu Jul  9 13:57:54 CEST 2015
Subject: Fix change in /sys/class/net/{bond}/slave_ naming after k3.13

Starting in kernel 3.13, slave_{ifname} is no longer present and
has been replaced by lower_{ifname}. Take this change into account
to avoid ambiguous error when ifenslave is run with existing bond
defined.
Ubuntu-Bug: http://bugs.launchpad.net/bugs/1326854

--- a/ifenslave.orig	2015-07-09 10:04:42.18800 +0200
+++ b/ifenslave	2014-07-09 13:38:57.06800 +0200
@@ -93,7 +93,8 @@
 	[ -d /sys/class/net/$slave ] || error $slave: no such interface
 
 	if [ -z $DETACH ]; then
-		if [ -h /sys/class/net/$master/slave_$slave ]; then
+		if [ -h /sys/class/net/$master/slave_$slave ] ||
+		   [ -h /sys/class/net/$master/lower_$slave ]; then
 			echo $slave: already enslaved to $master 2
 			continue
 		fi
@@ -107,7 +108,8 @@
 		ip link set $slave down
 		echo +$slave /sys/class/net/$master/bonding/slaves || error $slave: could not add interface
 	else
-		if [ ! -h /sys/class/net/$master/slave_$slave ]; then
+		if [ ! -h /sys/class/net/$master/slave_$slave ] ||
+		   [ ! -h /sys/class/net/$master/lower_$slave ]; then
 			echo $slave: is not enslaved to $master 2
 			continue
 		fi

Bug#789058: kdump-tools: kdump-tool sysVinit script does not check for upstart

[Louis Bouchard]

Package: kdump-tools
Version: 1:1.5.8-2
Severity: normal

Dear Maintainer,

Bug #788313 introduced an upstart job but the corresponding sysVinit script
does not verify if upstart is the init system. Hence the sysVinit script can
be started even if the upstart job has already run.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages kdump-tools depends on:
ii  init-system-helpers  1.23
ii  kexec-tools  1:2.0.7-5.1
ii  makedumpfile 1:1.5.8-2

kdump-tools recommends no packages.

kdump-tools suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788313: makedumpfile does not have an upstart job

[Louis Bouchard]

Package: makedumpfile
Version: 1:1.5.8-1
Severity: normal

Dear Maintainer,

makedumpfile does not provide a valid upstart job for
systems that do make use of upstart.

Please provide an upstart job.

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

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

Versions of packages makedumpfile depends on:
ii  libbz2-1.0  1.0.6-7+b3
ii  libc6   2.19-18
ii  libdw1  0.159-4.2
ii  libelf1 0.159-4.2
ii  perl5.20.2-4
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages makedumpfile recommends:
ii  crash7.0.8-1
ii  kexec-tools  1:2.0.7-5.1

makedumpfile suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780264: Bug #780264 : Improved fix for M2Crypto incompatibility

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Following an email discussion with Sam Hartman (hartm...@debian.org), I
improved the fix for this issue.

It will now work with or without the availability of SSL.SSLTimeoutError.

Please consider this patch for inclusion in the python-pywbem package.

Kind Regards,

...Louis

- -- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVQOxrAAoJEIs9hnyCPnphSDUP/AlNgUPdnEYoLIHBNU8/NZES
ReGB9cmTIQw+wL1zgBRlpPXe0MVj3FH36hA29RNZapqBEovidEzq//ZpvaXsrWVz
U7uSgw98mR+1wPu4ejFyIq1b7Fk+r6iqlQg2wb82ZPixyh/v/qROssaQSzOSqV0e
LgcnpDnHtMfwIqDAI2YOalJZUjWeej4AQGfqB2nLdUBNUVMpGjNmNIbtjd/5Yhc1
5jnYcI7GIRYGYsKiSSyyC0HJK9UFZapSiJLVIMcopbtpz2rhzv1mVb6jh8wx8CvA
8jFZYQ++Kpg/Ez54746W3/gbuyu3/GtV+RAuT5tR6k96/73oF3CP/LlQmTN1U9Q9
3gKGVFvO4AiObxPZmN5CIwuVdSvSLDu70obCJKQrL/vxyOeGpbqShrqqNzEaf4RK
2AM0YJBXAS9BDJi1nVhcK8wa7+w35TAaQKBxuMLHFBv/2ittPZf5pJdhdpj8INWn
Y3tYHdVM22H739HTy4i13p0GyRQVpG+Gr1fNKkXnbprA9zPk5k50savLxdedymHx
lGcGfLuLCA+nlaC9ZW8c6DZv7rGNDWG2vrZVcb20wOpygCfd3pbZD7e1EN1gWfis
9qDFLHiScbWL5UC7EA6574DCfVw7pgMCNMbH6OiwWgPpiGF8TYOxB9RYDdGAB97W
08a3FpIwAv7ouNNNwaoh
=fx2S
-END PGP SIGNATURE-
Description: Fix incompatibility with M2Crypto, missing SSLTimeoutError
Author: Louis Bouchard louis.bouch...@ubuntu.com
Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780264
---
--- cim_http.py.orig	2015-04-29 15:56:44.928475095 +0200
+++ cim_http.py	2015-04-29 15:56:16.320979327 +0200
@@ -168,8 +168,8 @@
 if not check(self.sock.get_peer_cert(), self.host):
 raise Error('SSL error: post connection check failed')
 return ret
-except ( Err.SSLError, SSL.SSLError, SSL.SSLTimeoutError
-   , SSL.Checker.WrongHost), arg:
+except ( Err.SSLError, SSL.SSLError, SSL.Checker.WrongHost, 
+getattr(SSL,'SSL.SSLTimeoutError',())), arg:
 raise Error(SSL error: %s % arg)
 
 class FileHTTPConnection(HTTPBaseConnection, httplib.HTTPConnection):

Bug#780264: Bug #780264 : Proposed fix for incompatibility

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainer,

I am working on the same issue on Ubuntu :

https://bugs.launchpad.net/ubuntu/+source/pywbem/+bug/1434991

This bug is caused by the fact that SSLTimeoutError does not exist in teh
M2Crypto python module and, according to the upstream git repository, has
never existed.

Here is a proposed patch that fixes this issue.

Please let me know if this is acceptable.

Kind regards,

...Louis

- -- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu developer   Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVLoMAAAoJEIs9hnyCPnphJKcP/3l6SZuZSA7Y7gO7YCAa24Ry
hClYldE5OuBOyAzXgwjJsXk4EToMMqNTewbsHjvANHg24cBD0fxv1zdos42bYew6
xT9/x3+77EOtnukVfBEUu5lAIfLRVs9nIyt1LLWFS5rEx4yadB4ZMAbQskp8yMIa
RTWqyyVwp6EBTbx8o3lrgA5fG6qFTOxuQAt2v0025fqB91XAVIwPf8AXhS9zz3QN
K+S9KnKL0jgCyZgL8loLMTB7WbSoUooL7hFMyIs/SB/j+MKzgVg9JrApbAenh/2S
1VeSDjDJEX7KGPYs7xlPwoqbp85R/p6xCEvsbg8/SN4T5uIfSs/7mSLzk96CFBM2
wn9f/N1Nmai5pHkua64lDWH9qng/A6Cpk31pRGjV2rFqAsdjj0Fy7pNas5CggM5B
cTZYw++0oUm1j4wHLxmL6YmVZGm8pYlI9xoI/82d5Y+l5zYcCUuiB1GWwoPrm8I0
K7ziUDjeaSDixaAXOCloxZpDt8b38Agp0OOP3dHpkn5jEAeIgPzNKt/tA96sL+As
H9FrRmTY1fO/otFEYy9SFmnN5kchJFV7OJK8fmduGmJ94sr0t+n8Fx/kmNWBWTHk
eDwBB4QVmlOW/LbgkwjxXeZOE/QIiLTswMymv3PoSBGiNZbzjXlObyzkz/jCEf99
TrlNUtQBk3IJv0mAv5O6
=jZup
-END PGP SIGNATURE-
diff -u pywbem-0.8.0~dev650/debian/changelog 
pywbem-0.8.0~dev650/debian/changelog
--- pywbem-0.8.0~dev650/debian/changelog
+++ pywbem-0.8.0~dev650/debian/changelog
@@ -1,3 +1,11 @@
+pywbem (0.8.0~dev650-2) sid; urgency=medium
+
+  * pywbem/cim_http.c
+- Remove SSLTimeoutError exception as this exception
+  is inexistant in M2Crypto (Closes: #780264)
+
+ -- Louis Bouchard louis.bouch...@ubuntu.com  Wed, 15 Apr 2015 08:59:30 -0500
+
 pywbem (0.8.0~dev650-1) unstable; urgency=low
 
   [ Bernd Zeimetz ]
only in patch2:
unchanged:
--- pywbem-0.8.0~dev650.orig/pywbem/cim_http.py
+++ pywbem-0.8.0~dev650/pywbem/cim_http.py
@@ -168,8 +168,7 @@
 if not check(self.sock.get_peer_cert(), self.host):
 raise Error('SSL error: post connection check 
failed')
 return ret
-except ( Err.SSLError, SSL.SSLError, SSL.SSLTimeoutError
-   , SSL.Checker.WrongHost), arg:
+except ( Err.SSLError, SSL.SSLError, SSL.Checker.WrongHost), arg:
 raise Error(SSL error: %s % arg)
 
 class FileHTTPConnection(HTTPBaseConnection, httplib.HTTPConnection):

Bug#776582: makedumpfile: Handling of panic_on_oops definition is incorrect

[Louis Bouchard]

Package: makedumpfile
Version: 1:1.5.7-4
Severity: normal

Dear Maintainer,

The handling of the definition of kernel.panic_on_oops is incorrect.

sysctl -a returns all definitions and disregard the value of KDUMP_SYSCTL
so the test is invariably true no matter what the definition of
kernel.panic_on_oops is.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages makedumpfile depends on:
ii  libbz2-1.0  1.0.6-5
ii  libc6   2.19-1
ii  libdw1  0.159-4.1
ii  libelf1 0.159-4.1
ii  perl5.18.2-4
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages makedumpfile recommends:
ii  crash7.0.8-1
ii  kexec-tools  1:2.0.7-5

makedumpfile suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776574: makedumpfile: Please enable firmware assisted dump

[Louis Bouchard]

Package: makedumpfile
Version: 1:1.5.7-4
Severity: normal

Dear Maintainer,

Starting from POWER6, the firmware now has a capability to preserve the
partition memory dump during system crash and boot into a fresh copy of the
kernel with fully-reset system. This feature adds the necessary support to
exploit the dump capture capability provided by Power firmware. With this
feature support, the production kernel will register for firmware-assisted dump
using RTAS (Runtime Abstraction Service) calls and builds required ELF header
which then gets exported through '/proc/vmcore' in the second kernel after
crash. This feature improves Power serviceability by making it more robust
compared to current kdump mechanism on Linux

The proposed patch from Ubuntu enable the capture of firmware assisted dumps


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages makedumpfile depends on:
ii  libbz2-1.0  1.0.6-5
ii  libc6   2.19-1
ii  libdw1  0.159-4.1
ii  libelf1 0.159-4.1
ii  perl5.18.2-4
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages makedumpfile recommends:
ii  crash7.0.8-1
ii  kexec-tools  1:2.0.7-5

makedumpfile suggests no packages.

-- no debconf information
diff -Nru makedumpfile-1.5.7/debian/changelog makedumpfile-1.5.7/debian/changelog
--- makedumpfile-1.5.7/debian/changelog	2014-12-05 03:12:02.0 -0600
+++ makedumpfile-1.5.7/debian/changelog	2015-01-28 21:02:52.0 -0600
@@ -1,3 +1,10 @@
+makedumpfile (1:1.5.7-4ubuntu1) vivid; urgency=medium
+
+  [ Hari Bathini hbath...@linux.vnet.ibm.com ]
+  * Add powerpc firmware-assisted dump (fadump) for kdump-config
+
+ -- Chris J Arges chris.j.ar...@ubuntu.com  Wed, 28 Jan 2015 21:00:17 -0600
+
 makedumpfile (1:1.5.7-4) experimental; urgency=medium
 
   * Enable kdump-tools to work as a systemd service
diff -Nru makedumpfile-1.5.7/debian/kdump-config makedumpfile-1.5.7/debian/kdump-config
--- makedumpfile-1.5.7/debian/kdump-config	2014-12-05 05:17:00.0 -0600
+++ makedumpfile-1.5.7/debian/kdump-config	2015-01-28 21:04:38.0 -0600
@@ -55,8 +55,19 @@
 # Constants
 vmcore_file=/proc/vmcore
 sys_kexec_crash=/sys/kernel/kexec_crash_loaded
+sys_fadump_enabled=/sys/kernel/fadump_enabled
+sys_fadump_registered=/sys/kernel/fadump_registered
 kexec_cmd_file=$KDUMP_COREDIR/kexec_cmd
 
+# DUMP_MODE = kdump/fadump
+# The default dump mode is kdump.
+DUMP_MODE=kdump
+
+# If /sys/kernel/fadump_enabled is set to `1`, use fadump as dump mechanism
+if [ -e $sys_fadump_enabled ]  [ `cat $sys_fadump_enabled` -eq 1 ]; then
+	DUMP_MODE=fadump
+fi
+
 # Utility Functions
 #
 function kdump_help()
@@ -65,14 +76,19 @@
 Usage:
 kdump-config {help|test|show|status|load|unload|savecore|propagate}
   help  - print this page
-  test  - Do a dry-run of the load command.  Show the kernels and
-  parameters that will be used and echo the kexec command.
-  The kexec command will not be executed.
-  show  - Show kdump status, kexec command, and any current parameters.
-  status- evaluate /sys/kernel/kexec_crash_loaded and print a message
+  test  - Do a dry-run of kdump kernel load command by showing
+  the kernels and parameters that will be used and echo'ing
+  the kexec command. The kexec command will not be executed.
+  If using fadump, check if required sysfs directories exist.
+  show  - Show dump mode, status, any current parameters.
+  Show kexec command for kdump.
+  status- evaluate /sys/kernel/{kexec_crash_loaded,fadump_registered}
+  depending on dump mode. Print appropriate message
   load  - Locate the kdump kernel, debug kernel, and establish links for
   makedumpfile.  Then load the kdump kernel using kexec
+  If using fadump, register.
   unload- unload the kdump kernel using kexec
+  If using fadump, unregister.
   savecore  - use previously made links to save /proc/vmcore
   propagate - Send public ssh key to remote host for passwordless connection
 
@@ -81,10 +97,13 @@
 
 function kdump_show()
 {
+	echo DUMP_MODE:$DUMP_MODE
 	echo USE_KDUMP:$USE_KDUMP
 	echo KDUMP_SYSCTL: $KDUMP_SYSCTL
 	echo KDUMP_COREDIR:$KDUMP_COREDIR
-	echo crashkernel addr: $IOMEM_ADDR
+	if [ $DUMP_MODE == kdump ]; then
+		echo crashkernel addr: $IOMEM_ADDR
+	fi
 
 	if [ -n $SSH ];then
 		echo SSH:  $SSH
@@ -100,6 +119,16 @@
 		echo HOSTTAG:  $HOSTTAG
 	fi
 
+	if [ $DUMP_MODE == fadump ]; then
+		if [ -e $sys_fadump_registered ] 
+			[ `cat $sys_fadump_registered` -eq 1 ] ; then
+			echo current state:ready to fadump;
+		else
+			echo current state:Not ready to fadump;
+		fi
+		return 

Bug#771798: unblock: makedumpfile/1:1.5.3-2

[Louis Bouchard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

   The packages makedumpfile and kdump-tools, part of the makedumpfile
source mackage are currently broken because of incompatibilities with the
3.16 kernel available in testing.

Its usage in conjunction with systemd provokes an erratic behavior during
the kernel crash dump capture : the system rebooted under kexec control
reaches multi-user (systemd default.target) while the kernel crash dump
capture happens which should not be the case.

The new package backports the changes required to make version 1.5.3
compatible with kernel 3.16. The backported commits were provided by the
upstream developer and are part of the 1.5.7 release.

It also implements the required service file to render kdump-tools
compatible with systemd and forces the kernel booted by kexec to block
at the kdump-tools.service while the kernel dump capture happens. The
kernel is rebooted after completion of the capture like it did previously.

Compatibility with sysVinit remains unchanged.

Debdiff against the package in testing is attached to the bug.

unblock makedumpfile/1:1.5.3-2

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
diff -Nru makedumpfile-1.5.3/debian/changelog makedumpfile-1.5.3/debian/changelog
--- makedumpfile-1.5.3/debian/changelog	2013-04-01 05:45:39.0 +0200
+++ makedumpfile-1.5.3/debian/changelog	2014-12-02 14:18:37.0 +0100
@@ -1,3 +1,17 @@
+makedumpfile (1:1.5.3-2) unstable; urgency=medium
+
+  * Adapt to kernel 3.16 changes in symbols :
+- Work around removal of struct vmlist in kernel 3.16
+- Fix dump_dmesg accordingly
+- Backported commits are : 759b78c, cee64e3, 8145e41, e203095,
+  150b58eb, 846ab2e, 1202589, 8a0236c, 9d38132, e24dc53
+Closes: #719943
+  * Implement systemd service and correct mechanism
+to capture kernel dumps under systemd control
+Closes: #771210
+
+ -- Louis Bouchard louis.bouch...@ubuntu.com  Mon, 02 Dec 2014 15:17:43 +0100
+
 makedumpfile (1.5.3-1) unstable; urgency=low
 
   [ Louis Bouchard ]
diff -Nru makedumpfile-1.5.3/debian/control makedumpfile-1.5.3/debian/control
--- makedumpfile-1.5.3/debian/control	2013-04-01 05:08:24.0 +0200
+++ makedumpfile-1.5.3/debian/control	2014-12-01 15:35:47.0 +0100
@@ -4,7 +4,8 @@
 Maintainer: John Wright j...@debian.org
 Uploaders: Louis Bouchard louis.bouch...@ubuntu.com
 Standards-Version: 3.8.2
-Build-Depends: debhelper (= 7.0.50), libelf-dev, libz-dev, libdw-dev (= 0.141-2ubuntu1), libbz2-dev
+Build-Depends: debhelper (= 7.0.50), libelf-dev, libz-dev, libdw-dev (= 0.141-2ubuntu1),
+		 libbz2-dev, dh-systemd (=1.5)
 Vcs-Git: git://git.debian.org/collab-maint/makedumpfile.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/makedumpfile.git;a=summary
 
diff -Nru makedumpfile-1.5.3/debian/kdump-config makedumpfile-1.5.3/debian/kdump-config
--- makedumpfile-1.5.3/debian/kdump-config	2013-04-01 05:08:24.0 +0200
+++ makedumpfile-1.5.3/debian/kdump-config	2014-12-01 16:38:06.0 +0100
@@ -44,7 +44,7 @@
 # Set up defaults
 KDUMP_SYSCTL=${KDUMP_SYSCTL:=kernel.panic_on_oops=1}
 KDUMP_COREDIR=${KDUMP_COREDIR:=/var/crash}
-KDUMP_CMDLINE_APPEND=${KDUMP_CMDLINE_APPEND:=irqpoll maxcpus=1 nousb}
+KDUMP_CMDLINE_APPEND=${KDUMP_CMDLINE_APPEND:=irqpoll maxcpus=1 nousb systemd.unit=kdump-tools.service}
 [ -d $KDUMP_COREDIR ] || mkdir -p $KDUMP_COREDIR ;
 
 IOMEM_ADDR=`grep -i Crash kernel /proc/iomem | sed s/-..*// | sed s/^[ 0]*/0x/`
@@ -420,6 +420,7 @@
 		mv $KDUMP_CORETEMP $KDUMP_COREFILE
 		log_success_msg $NAME: saved vmcore in $KDUMP_STAMPDIR
 		logger -t $NAME saved vmcore in $KDUMP_STAMPDIR
+		sync
 	else
 		log_failure_msg $NAME: failed to save vmcore in $KDUMP_STAMPDIR
 		logger -t $NAME failed to save vmcore in $KDUMP_STAMPDIR
@@ -437,6 +438,7 @@
 	if [ $ERROR == 0 ]; then
 		log_success_msg $NAME: saved dmesg content in $KDUMP_STAMPDIR
 		logger -t $NAME saved dmesg content in $KDUMP_STAMPDIR
+		sync
 		return 0;
 	else
 		log_failure_msg $NAME: failed to save dmesg content in $KDUMP_STAMPDIR
diff -Nru makedumpfile-1.5.3/debian/kdump-tools.default makedumpfile-1.5.3/debian/kdump-tools.default
--- makedumpfile-1.5.3/debian/kdump-tools.default	2013-04-01 05:08:24.0 +0200
+++ makedumpfile-1.5.3/debian/kdump-tools.default	2014-12-01 16:38:06.0 +0100
@@ -64,7 +64,7 @@
 # for the kdump kernel.  If unset, it defaults to irqpoll maxcpus=1 nousb
 #KDUMP_KEXEC_ARGS=
 #KDUMP_CMDLINE=
-#KDUMP_CMDLINE_APPEND=irqpoll maxcpus=1 nousb
+#KDUMP_CMDLINE_APPEND=irqpoll maxcpus=1 nousb systemd.unit=kdump-tools.service

Bug#771671: /sbin/kexec: Unable to load kdump kernel on i386

[Louis Bouchard]

Package: kexec-tools
Version: 1:2.0.7-5
Severity: grave
File: /sbin/kexec
Justification: renders package unusable

Dear Maintainer,

When running kdump-config on an i386 VM configured with 2048M
of memory and crashkernel=256M, kexec is unable to load the
kdump kernel and exit with the following message :

# kdump-config load
Could not find a free area of memory of 0x9f000 bytes...
locate_hole failed
failed to load kdump kernel ... failed!

The equivalent kexec command launched by kdump-config is the 
following :

# kexec -p --command-line=BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-686-pae 
root=UUID=91d2c84d-c523-4185-8297-4f903cc6ef4e ro console=ttyS0 irqpoll 
maxcpus=1 nousb --initrd=/boot/initrd.img-3.16.0-4-686-pae 
/boot/vmlinuz-3.16.0-4-686-pae
Could not find a free area of memory of 0x9f000 bytes...
locate_hole failed

The equivalent command on an 64 bit kernel under the same configuration works
as expected.

The same behavior exists on Debian Jessie which makes kernel crash dump
unusable.

Kind regards

...Louis

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kexec-tools depends on:
ii  debconf [debconf-2.0]  1.5.54
ii  libc6  2.19-13

kexec-tools recommends no packages.

kexec-tools suggests no packages.

-- debconf information:
  kexec-tools/use_grub_config: false
* kexec-tools/load_kexec: false


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706655: kexec-tools: Please consider including integration for kdump auto-dumping

[Louis Bouchard]

This is an old bug that has since been introduced into kdump-tools which is now
used in ubuntu as well.

closing the bug


-- 
Louis Bouchard
Software engineer,
Ubuntu
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771210: kdump-tools fails to complete when run with systemd

[Louis Bouchard]

Package: kdump-tools
Version: 1.5.3-1
Severity: normal

Dear Maintainer,

When used in the current version of Jessie, the kdump-tools
sysVinit script fails to complete correctly. kdump-tools should
be converted to systemd to avoid this situation. It also triggers
bug #719943, since the version in testing remained at 1.5.3.


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

Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kdump-tools depends on:
ii  kexec-tools   1:2.0.7-3
ii  makedumpfile  1.5.3-1

kdump-tools recommends no packages.

kdump-tools suggests no packages.

-- Configuration Files:
/etc/default/kdump-tools changed [not included]
/etc/init.d/kdump-tools [Errno 2] No such file or directory: 
u'/etc/init.d/kdump-tools'

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769521: sosreport: Starting with v3.2, archives are created with read permissions for everyone

[Louis Bouchard]

Package: sosreport
Version: 3.2-1
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

sosreport 3.2 now creates the tar archive in /tmp with group and world readable.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sosreport depends on:
ii  python3-six  1.8.0-1
pn  python3:any  none

sosreport recommends no packages.

sosreport suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768317: kdump-tools: remote kdump needs makedumpfile flat format to generate valid dumps

[Louis Bouchard]

Package: kdump-tools
Version: 1.5.7-1
Severity: normal

Dear Maintainer,

While testing remote dump functionality, it appears that the
collected dump filtered by makedumpfile is unusable unless the
flat format is used.

Please adapt the makedumpfile command accordingly


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kdump-tools depends on:
ii  kexec-tools   1:2.0.7-4
ii  makedumpfile  1.5.7-1

kdump-tools recommends no packages.

kdump-tools suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758802: irqbalance: Add support for $OPTIONS variable in upstart script

[Louis Bouchard]

Package: irqbalance
Version: 1.0.6-2
Severity: normal
Tags: patch

Dear Maintainer,
The SysV start script does make use of the $OPTIONS variable which is not
the case for the upstart script.

The proposed patch correct this situation and adds support for the $OPTIONS
variable for upstart as well.
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages irqbalance depends on:
ii  debconf [debconf-2.0]  1.5.53
ii  libc6  2.19-1
ii  libcap-ng0 0.7.3-1.1
ii  libglib2.0-0   2.40.0-3
ii  libnuma1   2.0.9-1.1
ii  lsb-base   4.1+Debian12
ii  sysv-rc2.88dsf-53

irqbalance recommends no packages.

irqbalance suggests no packages.

-- debconf information:
  irqbalance/enable: true
  irqbalance/oneshot: false
--- debian/irqbalance.upstart.orig	2014-08-21 16:03:01.356664546 +0200
+++ debian/irqbalance.upstart	2014-08-21 15:37:11.508624862 +0200
@@ -20,6 +20,6 @@
 		DOPTIONS=--oneshot
 	fi
 
-	exec /usr/sbin/irqbalance $DOPTIONS
+	exec /usr/sbin/irqbalance $OPTIONS $DOPTIONS
 
 end script

Bug#750647: libpam-runtime: Please include pam_limits module to /etc/pam.d/common-session to make it available systemwide

[Louis Bouchard]

Package: libpam-runtime
Version: 1.1.8-3
Severity: normal

Dear Maintainer,

pam_limit.so is installed  but for some reason, it is not
included into /etc/pam.d/common-session. This means that
there is no possibility to define system wide or per-user
limitations.

Please add the module to the common-session file to make
it available.
*** End of the template - remove these template lines ***


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libpam-runtime depends on:
ii  debconf [debconf-2.0]  1.5.53
ii  libpam-modules 1.1.3-7.1

libpam-runtime recommends no packages.

libpam-runtime suggests no packages.

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747173: Make dmesg dump configurable

[Louis Bouchard]

Hello Juerg, John,

I have applied your patch and pushed a new branch to alioth :

http://anonscm.debian.org/gitweb/?p=collab-maint/makedumpfile.git;a=shortlog;h=refs/heads/bug-747173-configurable-dmesg

John, could you please merge it  sponsor the upload ?

I did a minor edit to your comment : I do think that it is valuable to have the
dmesg content in a production environment : this avoids having to send
multi-gigabyte of vmcore just to get the backtrace of what caused the kernel
panic to happen.

-- 
Louis Bouchard
Software engineer,
Ubuntu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747173: Make dmesg dump configurable

[Louis Bouchard]

Hello Juerg, John,

Le 22/05/2014 08:19, John Wright a écrit :
 Hi Juerg,
 
 On Tue, May 20, 2014 at 10:28:24AM +0200, Juerg Haefliger wrote:
 John,

 Any thoughts on this?
 
 I haven't had time to look at it (sorry) but it seems like a reasonable
 feature to add.  Louis Bouchard has been actively maintaining
 makedumpfile, and I believe he is working on adding some features to the
 kdump-tools script.  Louis, can you take a look at this?  Juerg filed a
 wishlist bug including a patch: http://bugs.debian.org/747173
 

Juerg, happy to hear from you again.

The patch seems reasonable so I'll apply it to 1.5.6 and ask John to upload it
to Sid.

I don't want to tie it to the new features I'm working on (networked kdump) as I
don't know when they will land.

So I'll update the bug once I get your patch in.

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer,
Ubuntu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743868: Proposed fix for this bug

[Louis Bouchard]

Hello,

Here is a debdiff of a proposed fix for this bug.

Kind regards,

...Louis
-- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu support: http://canonical.com/support
diff -Nru sosreport-3.1/debian/changelog sosreport-3.1/debian/changelog
--- sosreport-3.1/debian/changelog  2014-01-27 12:52:39.0 +0100
+++ sosreport-3.1/debian/changelog  2014-04-08 11:28:47.0 +0200
@@ -1,3 +1,10 @@
+sosreport (3.1-1.1) sid; urgency=medium
+
+  * Fix spurrious command not found messages when running
+Closes: #743868
+
+ -- Louis Bouchard louis.bouch...@ubuntu.com  Tue, 08 Apr 2014 11:24:11 +0200
+
 sosreport (3.1-1) sid; urgency=low
 
   * New upstream release v3.1
diff -Nru sosreport-3.1/debian/patches/0001-fix-command-not-found.patch 
sosreport-3.1/debian/patches/0001-fix-command-not-found.patch
--- sosreport-3.1/debian/patches/0001-fix-command-not-found.patch   
1970-01-01 01:00:00.0 +0100
+++ sosreport-3.1/debian/patches/0001-fix-command-not-found.patch   
2014-04-07 17:55:49.0 +0200
@@ -0,0 +1,38 @@
+commit 0338a955a930286beaa7b66c5167be9b15d34d78
+Author: Bryn M. Reeves b...@redhat.com
+Date:   Mon Feb 3 12:09:57 2014 +
+
+Fix verbose file logging
+
+Prior versions of sos enable debug logging to the embedded log
+file (sos_logs/sos.log) when a single '-v' is given. Restore this
+behaviour and ensure that command-not-found messages are reported
+at 'info' rather than 'warning' level.
+
+Signed-off-by: Bryn M. Reeves b...@redhat.com
+
+diff --git a/sos/plugins/__init__.py b/sos/plugins/__init__.py
+index 7c63631..8df430d 100644
+--- a/sos/plugins/__init__.py
 b/sos/plugins/__init__.py
+@@ -488,7 +488,7 @@ class Plugin(object):
+ self.soslog.warning(command '%s' timed out after %ds
+ % (prog, timeout))
+ if status == 127:
+-self.soslog.warning(could not run '%s': command not found % 
prog)
++self.soslog.info(could not run '%s': command not found % prog)
+ return (status, output, runtime)
+ 
+ def call_ext_prog(self, prog, timeout=300):
+diff --git a/sos/sosreport.py b/sos/sosreport.py
+index 4b52572..0faa364 100644
+--- a/sos/sosreport.py
 b/sos/sosreport.py
+@@ -659,6 +659,7 @@ class SoSReport(object):
+ flog.setLevel(logging.DEBUG)
+ elif self.opts.verbosity and self.opts.verbosity  0:
+ console.setLevel(logging.INFO)
++flog.setLevel(logging.DEBUG)
+ else:
+ console.setLevel(logging.WARNING)
+ self.soslog.addHandler(console)
diff -Nru sosreport-3.1/debian/patches/series 
sosreport-3.1/debian/patches/series
--- sosreport-3.1/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ sosreport-3.1/debian/patches/series 2014-04-07 17:55:49.0 +0200
@@ -0,0 +1 @@
+0001-fix-command-not-found.patch -p1

Bug#743868: Please fix typo in the changelog

[Louis Bouchard]

Hello,

When uploading, can you please fix the spurious typo in the changelog ? This
doesn't look right.

Kind regards,

...Louis
-- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu support: http://canonical.com/support


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743868: sosreport: Spurrious command not found messages displayed when running sosreport

[Louis Bouchard]

Package: sosreport
Version: 3.1-1
Severity: normal

Dear Maintainer,

Running latest sosreport 3.1.1 on debian/sid leads to the following output :

root@sid:~# sosreport -a --batch [27/750]

sosreport (version 3.1)

TL;DW

could not run 'brctl show': command not found
 Running plugins. Please wait ...

  Running 9/64: boot... could not run 'lsinitrd': command not found
  Running 13/64: dmraid... could not run 'dmraid -V': command not found
could not run 'dmraid -b': command not found
could not run 'dmraid -r': command not found
could not run 'dmraid -s': command not found
could not run 'dmraid -tay': command not found
could not run 'dmraid -rD': command not found
  Running 17/64: general... could not run 'tree /var/lib': command not found
  Running 18/64: general... could not run 'tree /var/lib': command not found
  Running 20/64: grub2... could not run 'grub2-mkconfig': command not found
  Running 23/64: java... could not run 'alternatives --display java': command 
not found
  Running 24/64: juju... could not run 'juju -v status': command not found
could not run 'juju -v get-constraints': command not found
  Running 25/64: kernel... could not run 'dkms status': command not found

etc until the end.

Thos command not found message did not appear previously


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sosreport depends on:
ii  python3-six  1.6.1-1
pn  python3:any  none

sosreport recommends no packages.

sosreport suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734356: backuppc: libtime-modules-perl repeated twice in Depends: statement of debian/control

[Louis Bouchard]

Package: backuppc
Version: 3.3.0-1
Severity: normal

Dear Maintainer,

While merging latest version of the backuppc package in ubuntu, I 
noticed that the libtime-modules-perl dependancy is repeated twice
in the Depends: statement.

Could you please remove the second occurrence of the statement as it
is useless.

Kind regards,

Louis
-- System Information:
Debian Release: wheezy/sid
  APT prefers saucy-updates
  APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy'), 
(100, 'saucy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11.0-15-generic (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725797: [Pkg-stud-maintainers] Bug#725797: stud: Fix failure to run stud restart

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Le 12/10/2013 10:07, Vincent Bernat a écrit :
 
 OK, sorry, I didn't understand that the first time. Since the other
 way to kill stud does not play nice with the multiple instance
 feature, what about put a sleep 1 between stop and start? This is
 unfortunate and may somewhat break but this is still often done.
 
 Other solutions would be to provide Upstart/systemd scripts or to
 modify stud to wait for its children before terminating. I can do a
 patch for the later.
 

Sorry for being late in replying.

I'm working on a patch for stud that would handle propagating the
SIGTERM to its children. I should be able to update shortly.

Kind regards,

...Louis
- -- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu support: http://canonical.com/support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJo8IAACgkQDvqokHrhnCy03QCgp6T2ZR6hmkb+kFYzwwhGB4E6
ao8Aniu98p1Q4bIoagBBBt5wqA1WzDS/
=IZ5D
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725797: [Pkg-stud-maintainers] Bug#725797: stud: Fix failure to run stud restart

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bonjour Vincent,

Le 12/10/2013 10:07, Vincent Bernat a écrit :
 Other solutions would be to provide Upstart/systemd scripts or to
 modify stud to wait for its children before terminating. I can do a
 patch for the later.
 

As expressed in my previous comment, here is a patch for stud that will
handle the termination of the children started by stud's main process.

If the patch is adequate, I will use the same one for Ubuntu. It would
also be good to have it sent upstream, though there seems to be very
limited activity over there.

Kind regards,

...Louis
- -- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu support: http://canonical.com/support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJpH8wACgkQDvqokHrhnCzq4wCg4OINezeEznK02Ia9PMvzIDY8
aIAAoPIwSIPdpqjxbFrY1r6ISQlQo88W
=UhRR
-END PGP SIGNATURE-
diff -Nru stud-0.3/debian/changelog stud-0.3/debian/changelog
--- stud-0.3/debian/changelog   2013-06-08 23:11:29.0 +0200
+++ stud-0.3/debian/changelog   2013-10-24 15:09:09.0 +0200
@@ -1,3 +1,11 @@
+stud (0.3-5.1) sid; urgency=low
+
+  * debian/patches/kill-children-on-sigterm.patch
+Fix stud to handle termination of children processes
+Closes: #725797
+
+ -- Louis Bouchard louis.bouch...@ubuntu.com  Thu, 24 Oct 2013 14:54:19 +0200
+
 stud (0.3-5) unstable; urgency=low
 
   * Fix FTBFS when using --as-needed on non x86 arch.
diff -Nru stud-0.3/debian/patches/kill-children-on-sigterm.patch 
stud-0.3/debian/patches/kill-children-on-sigterm.patch
--- stud-0.3/debian/patches/kill-children-on-sigterm.patch  1970-01-01 
01:00:00.0 +0100
+++ stud-0.3/debian/patches/kill-children-on-sigterm.patch  2013-10-24 
15:23:45.0 +0200
@@ -0,0 +1,64 @@
+Description: Fix to handle children termination
+ 
+Author: Louis Bouchard louis.bouch...@ubuntu.com
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725797
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/stud/+bug/1123950
+---
+
+Index: stud-0.3/stud.c
+===
+--- stud-0.3.orig/stud.c   2013-10-24 15:05:33.624471842 +0200
 stud-0.3/stud.c2013-10-24 15:07:41.504479870 +0200
+@@ -1217,6 +1217,21 @@
+ }
+ }
+ 
++/* Handle children process termination.
++   Display error if needed but continue  and
++   exits at the end of the list */
++static void terminate_children()
++{
++int i=0;
++
++for ( i = 0; i  OPTIONS.NCORES; i++) {
++if (kill(child_pids[i],SIGTERM)  0) {
++  perror(stud:terminate_children - );
++  }
++}
++exit(0);
++}
++
+ void init_signals() {
+ struct sigaction act;
+ 
+@@ -1238,6 +1253,21 @@
+ fail(sigaction - sigchld);
+ }
+ 
++
++/* Enable specific SIGTERM handling by the parent proc
++   It becomes responsible for terminating children. */
++void handle_sigterm() {
++struct sigaction act;
++
++sigemptyset(act.sa_mask);
++act.sa_flags = 0;
++
++act.sa_handler = terminate_children;
++
++if (sigaction(SIGTERM, act, NULL)  0)
++fail(sigaction - sigterm);
++}
++
+ /* Process command line args, create the bound socket,
+  * spawn child (worker) processes, and respawn if any die */
+ int main(int argc, char **argv) {
+@@ -1262,6 +1292,8 @@
+ 
+ start_children(0, OPTIONS.NCORES);
+ 
++handle_sigterm();
++
+ for (;;) {
+ /* Sleep and let the children work.
+  * Parent will be woken up if a signal arrives */
diff -Nru stud-0.3/debian/patches/series stud-0.3/debian/patches/series
--- stud-0.3/debian/patches/series  2013-06-08 23:11:29.0 +0200
+++ stud-0.3/debian/patches/series  2013-10-24 15:07:28.0 +0200
@@ -2,3 +2,4 @@
 enable-hardening.diff
 kfreebsd-no-keepidle.patch
 as-needed.patch
+kill-children-on-sigterm.patch

Bug#725797: [Pkg-stud-maintainers] Bug#725797: stud: Fix failure to run stud restart

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Le 11/10/2013 22:55, Vincent Bernat a écrit :
 
 It has been some time since I run stud. I just tried and I notice
 that I have a parent process that is supervising childrens and
 restarting them when they die. And the PID registered works as
 expected:
 
 ├─stud(3933)─┬─stud(3950) │├─stud(3951) │
 ├─stud(3952) │└─stud(3953)
 
 $ cat /var/run/stud.take1.conf.pid 3933
 
 I don't understand why this is not your case.
 

It is my case; there is a PID file for each stud configuration
started. The problem is that, when using --pidfile option,
start-stop-daemon only sends the TERM signal to the parent process
then returns. This happens fast enough for the do_start to be executed
before the children processes have time to terminate.

This causes the port used by stud to be busy when do_start executes in
the 'restart' sequence so stud do not get restarted correctly. Using
- --pidfile also make the --retry option to be active only on the parent
process and not on the children.

It is easy to confirm the statement by adding a lsof -i
@127.0.0.1:8445 in the do_start function, just before
start-stop-daemon gets executed.  The stud children are still present.

Removing --pidfile in do_stop's start-stop-daemon forces it to ack on
the parent process and all the children process and makes --retry wait
for termination of all of them.

So in short, when using --pidfile, it only acts on the parent process
and do not wait for the children to terminate.

Kind regards,

...Louis

- -- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu support: http://canonical.com/support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJY9vMACgkQDvqokHrhnCybxwCdFl0qy91t9oDgsCkssyhO1EDj
vT0AoJpDMDG4JgNylRol7nUxcHN0k0/u
=8fYD
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725797: [Pkg-stud-maintainers] Bug#725797: stud: Fix failure to run stud restart

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Le 09/10/2013 17:48, Vincent Bernat a écrit :
 If by multiple instances you mean many configuration files in 
 /etc/stud I haven't tested. If you mean multiple children (or
 cores) started by the -n option, this is indeed what it is trying
 to fix.
 
 Yes, I mean multiple configuration files. But OK, I see what you 
 mean. Well, I don't know how to concile the two approaches. Being
 able to run multiple instances is important.
 

True, I hadn't thought of that. So I ran new tests with two configs
and as you stated, my patch doesn't work.

Turns out that removing --pidfile is only needed in the do_stop. This
way, we keep the possibility of running multiple instances, while
fixing the restart part, especially since the pidfiles are cleaned up
anyway.

So here is a new and simpler patch

 I am usually never on IRC. I should try to get there because you
 are not the first trying to reach me this way.
 

This is not by any mean mandatory, I just happen to be there all the
time for work-related requirements.

Kind regards,

...Louis

- -- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu support: http://canonical.com/support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJWewcACgkQDvqokHrhnCwuOwCff1RBzG6BgO0hI+TlrGpsNkBV
m6YAn0r4lC29tAp5Cw2tGj0h4sqDAS63
=YoHj
-END PGP SIGNATURE-
diff -Nru stud-0.3/debian/changelog stud-0.3/debian/changelog
--- stud-0.3/debian/changelog   2013-06-08 23:11:29.0 +0200
+++ stud-0.3/debian/changelog   2013-10-10 11:35:24.0 +0200
@@ -1,3 +1,13 @@
+stud (0.3-5.1) UNRELEASED; urgency=low
+
+  * Fixes failure to run invoke-rc.d stud restart 
+Closes: #725797
+Use of --pidfile with start-stop-daemon failed to kill the children.
+It is important to avoid running stud as 'root' as stated in the README.md
+since running invoke-rc.d stud stop will kill the initscript.
+
+ -- Louis Bouchard louis.bouch...@ubuntu.com  Thu, 10 Oct 2013 11:35:58 +0200
+
 stud (0.3-5) unstable; urgency=low
 
   * Fix FTBFS when using --as-needed on non x86 arch.
diff -Nru stud-0.3/debian/stud.init.d stud-0.3/debian/stud.init.d
--- stud-0.3/debian/stud.init.d 2013-06-08 23:11:29.0 +0200
+++ stud-0.3/debian/stud.init.d 2013-10-10 11:34:45.0 +0200
@@ -86,7 +86,7 @@
PIDFILE=/var/run/stud.${BASE}.pid
. $conf
start-stop-daemon --stop --quiet --retry=TERM/10/KILL/5 
\
-   --pidfile $PIDFILE --name $NAME
+   --name $NAME --user $USER
RETVAL=$?
if [ $RETVAL = 2 ]; then
[ $VERBOSE != no ]  log_progress_msg 
[Unable to stop: ${BASE}]

Bug#725797: [Pkg-stud-maintainers] Bug#725797: stud: Fix failure to run stud restart

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bonjour,

Le 09/10/2013 08:47, Vincent Bernat a écrit :
 
 How does this work for multiple stud instances? I didn't know that 
 start-stop-daemon does not wait for the process to terminate by 
 default. Maybe we should use --retry instead.
 

If by multiple instances you mean many configuration files in
/etc/stud I haven't tested. If you mean multiple children (or cores)
started by the -n option, this is indeed what it is trying to fix.

By default, stud starts a main process and one child (-n1). When
- --pidfile is in use, only the main process gets killed as implied in
the manpage of start-stop-daemon :

Note: unless --pidfile is specified, start-stop-daemon behaves
similar to killall(1).
...
For daemons which have long-lived children which need to live through
a --stop, you must specify a pidfile.

So when using --pidfile, children are not sent the signal, only the
main process. This is what I have witnessed by inserting an 'lsof -i
@127.0.0.1:8445 at the beginning of do_start : there are still
processes present.

Regarding using --retry, it is already being used :

start-stop-daemon --stop --quiet --retry=TERM/10/KILL/5 \
--pidfile $PIDFILE --name $NAME

Here again, --retry only touches the main process, not the children
when used in conjunction with --pidfile.

Testing this is rather easy : just run invoke-rc.d stud restart and
you will notice that stud processes do not come back. This is caused
by the fact that the first test in do_start also uses --pidfile and,
since the main process is gone, it concludes that it can go ahead but
when it starts stud, other processes still have to socket open so the
start fails.

Removing the --pidfile will make sure that the main process and all
remaining children get killed.

Adding --user $USER is required otherwise the initscript itself gets
killed (since it is also named stud). The only problematic situation
is if stud is run as root ($USER=root) where --user cannot discriminate.

I have been trying to find you on OFTC without success. You can reach
me there, my nick is caribou.

Kind regards,

...Louis
- -- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu support: http://canonical.com/support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJVHbUACgkQDvqokHrhnCwBRQCfTQH6gQCdrFFJR7XjKtwdRRL8
+c8An2Mc6gO3T2CCzEpsSZ0oaynaHrkA
=fJMr
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725797: stud: Fix failure to run stud restart

[Louis Bouchard]

Package: stud
Version: 0.3-5
Severity: important

Dear Maintainer,

This bug report follows a previously reported bug on Ubuntu :
  https://bugs.launchpad.net/bugs/1123950

Utilization of invoke-rc.d stud restart is failing to restart
the stud daemon correctly.

This is caused by the use of --pidfile that does not wait for the
children to terminate. Removing --pidfile and -m fixes the problem

start-stop-daemon now uses --user to identify the appropriate process
to kill, otherwise the 'stud' init script will be killed as well.

This works as long as the user running is not 'root', which is highly
discouraged in the README.md file anyway.


-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages stud depends on:
ii  adduser  3.113+nmu3
ii  libc62.17-93
ii  libev4   1:4.15-3
ii  libssl1.0.0  1.0.1c-4

stud recommends no packages.

stud suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725797: Proposed patch to fix the restart problem

[Louis Bouchard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Attached to this mail is a debdiff against sid's version of stud which
includes the identical patch that I am planning to apply to Ubuntu's
version of the stud package.

If possible, could someone in the maintaining team review the proposed
patch and let me know if this is satisfactory to you ?

Kind regards,

...Louis

- -- 
Louis Bouchard
Software engineer, Cloud  Sustaining eng.
Canonical Ltd
Ubuntu support: http://canonical.com/support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJUFNsACgkQDvqokHrhnCyfWQCeLPkV0spsNfuFFbN/GlV/QEfc
3wUAoIlBd5yS4M4DlY2tN1avnCJOzlhz
=WQX8
-END PGP SIGNATURE-
diff -Nru stud-0.3/debian/changelog stud-0.3/debian/changelog
--- stud-0.3/debian/changelog   2013-06-08 23:11:29.0 +0200
+++ stud-0.3/debian/changelog   2013-10-08 16:07:09.0 +0200
@@ -1,3 +1,13 @@
+stud (0.3-5.1) UNRELEASED; urgency=low
+
+  * Fixes failure to run invoke-rc.d stud restart 
+Closes: #725797
+Use of --pidfile with start-stop-daemon failed to kill the children.
+It is important to avoid running stud as 'root' as stated in the README.md
+since running invoke-rc.d stud stop will kill the initscript.
+
+ -- Louis Bouchard louis.bouch...@ubuntu.com  Tue, 08 Oct 2013 15:02:58 +0200
+
 stud (0.3-5) unstable; urgency=low
 
   * Fix FTBFS when using --as-needed on non x86 arch.
diff -Nru stud-0.3/debian/stud.init.d stud-0.3/debian/stud.init.d
--- stud-0.3/debian/stud.init.d 2013-06-08 23:11:29.0 +0200
+++ stud-0.3/debian/stud.init.d 2013-10-08 15:57:53.0 +0200
@@ -52,12 +52,12 @@
BASE=$(basename $conf)
PIDFILE=/var/run/stud.${BASE}.pid
. $conf
-   if ! start-stop-daemon --start --quiet --pidfile 
$PIDFILE \
+   if ! start-stop-daemon --start --quiet \
--exec $DAEMON --test  /dev/null; then
[ $VERBOSE != no ]  log_progress_msg 
[Already running: ${BASE}]
else
-   start-stop-daemon --start --quiet --pidfile 
$PIDFILE \
-   --exec $DAEMON -b -m -- \
+   start-stop-daemon --start --quiet \
+   --exec $DAEMON -b -- \
$COMMON_OPTIONS $OPTIONS $CERT \
|| {
[ $VERBOSE != no ]  
log_progress_msg [Failed: ${BASE}]
@@ -86,7 +86,7 @@
PIDFILE=/var/run/stud.${BASE}.pid
. $conf
start-stop-daemon --stop --quiet --retry=TERM/10/KILL/5 
\
-   --pidfile $PIDFILE --name $NAME
+   --name $NAME --user $USER
RETVAL=$?
if [ $RETVAL = 2 ]; then
[ $VERBOSE != no ]  log_progress_msg 
[Unable to stop: ${BASE}]
@@ -111,7 +111,7 @@
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
-   start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name 
$NAME
+   start-stop-daemon --stop --signal 1 --quiet --name $NAME
return 0
 }
 

Bug#714153: sysstat: Fails to build due to concurrency problems

[Louis Bouchard]

Package: sysstat
Version: 10.1.6-1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy ubuntu-patch

Dear Maintainer,

A build failure was identify to be a concurrency issue. The problem
is fixed by carrying over one makefile rule already present and identified
as a concurrency fix.

The Ubuntu package modified with the fix now builds correctly


In Ubuntu, the attached patch was applied to achieve the following:

Avoid a failure to build from source.

  * New 11-fix-concurrency-build-issue.patch :Extend
explicit rules to avoid build issues occuring during
parallel build


Thanks for considering the patch.


-- System Information:
Debian Release: wheezy/sid
  APT prefers raring-updates
  APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 
'raring'), (100, 'raring-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8.0-25-generic (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru sysstat-10.1.6/debian/changelog sysstat-10.1.6/debian/changelog
diff -Nru sysstat-10.1.6/debian/patches/11-fix-concurrency-build-issue.patch sysstat-10.1.6/debian/patches/11-fix-concurrency-build-issue.patch
--- sysstat-10.1.6/debian/patches/11-fix-concurrency-build-issue.patch	1970-01-01 01:00:00.0 +0100
+++ sysstat-10.1.6/debian/patches/11-fix-concurrency-build-issue.patch	2013-06-26 10:50:32.0 +0200
@@ -0,0 +1,23 @@
+From: Louis Bouchard louis.bouch...@ubuntu.com
+Date: Tue, 25 June 2013 16:23:14 +0200
+Subject: 11-fix-concurrency-build-issue.patch
+
+Extend explicit rules to avoid build issues occuring
+during parallel build
+---
+--- a/Makefile.in
 b/Makefile.in
+@@ -202,9 +202,11 @@
+ libsyscom.a: common.o ioconf.o
+ 	$(AR) rvs $@ $?
+ 
+-librdstats.a: librdstats.a(rd_stats.o count.o)
++librdstats.a: rd_stats.o count.o
++	$(AR) rvs $@ $?
+ 
+-librdsensors.a: librdsensors.a(rd_sensors.o)
++librdsensors.a: rd_sensors.o
++	$(AR) rvs $@ $?
+ 
+ sadc.o: sadc.c sa.h version.h common.h ioconf.h sysconfig.h rd_stats.h rd_sensors.h
+ 
diff -Nru sysstat-10.1.6/debian/patches/series sysstat-10.1.6/debian/patches/series
--- sysstat-10.1.6/debian/patches/series	2013-06-13 22:28:07.0 +0200
+++ sysstat-10.1.6/debian/patches/series	2013-06-26 10:50:32.0 +0200
@@ -8,3 +8,4 @@
 08-scripts.patch
 09-format-warning.patch
 10-isag-menu-refresh.patch
+11-fix-concurrency-build-issue.patch

Bug#698755: Acknowledgement (makedumpfile --dump-dmesg fails on 3.5 kernels and later)

[Louis Bouchard]

A patch for the upstream version of makedumpfile has been accepted by
the maintainer :

http://lists.infradead.org/pipermail/kexec/2013-February/007925.html

This patch will most probablly be included in the upcoming debian
version of makedumpfile 1.5.1 due to be uploaded soon.

..Louis


--
Louis Bouchard
https://launchpad.net/~louis-bouchard


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#698755: makedumpfile --dump-dmesg fails on 3.5 kernels and later

[Louis Bouchard]

Package: makedumpfile
Version: 1.5.0-1
Severity: important
Tags: upstream

Dear Maintainer,
When used on Debian running kernel 3.5 and later the makedumpfile --dump-dmesg 
/proc/vmcore /tmp/dmesg fails with the following error :

# makedumpfile --dump-dmesg /proc/vmcore /tmp/dmesg
dump_dmesg: Can't find some symbols for log_buf.

makedumpfile Failed.

This is caused by the change from byte-buffer structure to
variable-length record buffer of the kernel log buffer introduced by
this commit :

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7ff9554bb578ba02166071d2d487b7fc7d860d62


-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages makedumpfile depends on:
ii  libbz2-1.0  1.0.6-4
ii  libc6   2.13-37
ii  libdw1  0.153-2
ii  libelf1 0.152-1+wheezy1
ii  perl5.14.2-16
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages makedumpfile recommends:
ii  crash6.1.0-1
ii  kexec-tools  1:2.0.3-1

makedumpfile suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696386: makedumpfile fails with elf_readall error

[Louis Bouchard]

Package: makedumpfile
Version: 1.5.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
Testing packaging of new 1.5.1 version of makedumpfile.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Ran normal kernel panic test.

   * What was the outcome of this action?
The following output came out when makedumpfile tried to run :

Starting kdump-tools: [info] running makedumpfile -c -d 31 -x 
/usr/lib/debug/boot/vmlinux-3.2.0-4-amd64 /proc/vmcore /var/crash/201212201000/d
ump-incomplete.
makedumpfile: elf_readall.c:94: __libelf_readall: Unexpected error: Resource 
deadlock avoided.
/usr/sbin/kdump-config: line 387:  2243 Aborted makedumpfile 
$MAKEDUMP_ARGS $vmcore_file $KDUMP_CORETEMP
[FAIL] kdump-tools: makedumpfile failed, falling back to 'cp' ... failed!

Since this was while testing makedumpfile 1.5.1 for packaging, I tested the
current packaged 1.5.0-1 which tested successfully previously and it also 
fails. This might be a regression from another package.

It is important to note that makedumpfile correctly runs on the dump file once
the system is back to multi-user.

   * What outcome did you expect instead?
makedumpfile correctly process the /proc/vmcore file

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages makedumpfile depends on:
ii  libbz2-1.0  1.0.6-4
ii  libc6   2.13-37
ii  libdw1  0.153-2
ii  libelf1 0.153-2
ii  perl5.14.2-16
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages makedumpfile recommends:
ii  crash6.1.0-1
ii  kexec-tools  1:2.0.3-1

makedumpfile suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org