Bug#845385: Pending fixes for bugs in the tomcat8 package

[pkg-java-maintainers]

tag 845385 + pending
thanks

Some bugs in the tomcat8 package are closed in revision
e8cd8585faebe1ba1312ef6452ced16d6e7998c7 in branch '  experimental'
by Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/commit/?id=e8cd858

Commit message:

The tomcat8 user is no longer removed when the package is purged (Closes: 
#845385)

Bug#761146: Re-ITPing

[Ole Streicher]

Control: retitle -1 ITP: casacore-data -- Data for Common Astronomy Software 
Applications core library
Control: owner -1 Ole Streicher 

To keep the casacore data packages together, I plan 
to use the original package as a metapackage that
depends on the individual ones, currently:

* casacore-data-tai-utc
* casacore-data-irgf
* casacore-data-lines
* casacore-data-observatories
* casacore-data-sources

Once the remaining packages are there, they will
be added as dependencies as well:

* casacore-data-eop (ITP #842933)
* casacore-data-jplde (ITP #842931)
* casacore-data-predict (ITP #842934)

but this will not happen for stretch: They are not
buildable with the current version of casacore due to
https://github.com/casacore/casacore/issues/537

Best regards

Ole

Bug#846364: RFS: discover/2.1.2-7.1 [NMU]

[Andrey Rahmatullin]

Control: tags -1 + moreinfo

I've built this package and installed it and `sudo discover` crashes. It
doesn't crash when installed from sid.

(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x7747b1ce in __GI___strdup (s=0x ) at strdup.c:41
#2  0x77bd4901 in discover_get_devices (bus=PCI, status=0x55759050) 
at ../../lib/sysdep.c:271
#3  0x66e1 in bus_summary (busname=) at 
../../discover/discover.c:505
#4  0x60b1 in main (argc=0, argv=0x7fffec60) at 
../../discover/discover.c:858


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#846366: ITP: bcc -- Command line tools for BPF Compiler Collection (BCC)

[Sébastien Delafond]

Hi Ritesh,

I agree with you, there is no reason we can't coexist :)

However, perf-tools-unstable doesn't seem to be much more updated these
days, and it sorta worries me, especially since Brendan Gregg mentions
on his blog that bcc seems to be the future: in that light, do you still
see a need for perf-tools-unstable at all ?

If you do, would you be willing to take over its maintainership ? I'm
trying to save more time to contribute to security work in Debian, so
you'd be welcome to do that :)

Anyway, let me know what you think and we'll take it from there.

Cheers,

--Seb

On Nov/30, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello Sebastien,
> 
> First of all, thanks for maintaining perf-tools-unstable. I use it many a 
> times.
> 
> I just completed the major chunk of bcc packaging. I intend to maintain it 
> under
> collab-maint/ too.
> 
> 
> The binary file names are conflicting for bcc and perf-tools-unstable. I don't
> see a reason why one cannot co-install both the packages and use. But in its
> current form, it'll fail complaining file overwrites.
> 
> Personally, I don't think the alternatives route may be of much use because
> apart from this 2 packages, I don't see any other package using these names.
> Also, IMO, the alternatives feature is usually useful for common tools like
> editor, pager etc.
> 
> One option could be that we append the names of the binaries explicitly.
> Example, for bcc => execsnoop-bcc, perf-tools => execsnoop-perf
> 
> What do you say ? Or if you have any suggestions, please do mention.
> 
> Thanks,
> Ritesh
> 
> On Wed, 2016-11-30 at 22:50 +0530, Ritesh Raj Sarraf wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ritesh Raj Sarraf 
> > 
> > * Package name: bcc
> >   Version : 0.2.0
> >   Upstream Author : IO Visor Project (https://github.com/iovisor)
> > * URL : https://github.com/iovisor/bcc
> > * License : Apache 2.0
> >   Programming Lang: C, Python
> >   Description : Tools for BPF Compiler Collection (BCC)
> > 
> >  BPF Compiler Collection (BCC) is a toolkit for creating efficient
> >  kernel tracing and manipulation programs
> >  .
> >  It makes use of extended BPF (Berkeley Package Filter) and provides tools
> >  for BPF based Linux IO analysis, networking, monitoring and more
> > 
> > This is a great tool to debug and instrument your kernel and
> > applications. It also is a a performance characterization and analysis
> > tool
> > 
> > I have an interest in Debugging and Analysis and I intend to use and
> > maintain it under Debian.
> > 
> > As with most of my packages, I intend to maintain it under collab-maint
> - -- 
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlg/EPQACgkQpjpYo/Lh
> dWle6xAAsRRfIO3oUvk6wN4NXanqQark//nvE5ezt2RPlx4SUYWA3WWJas1bbGA8
> AdnJMKvqYD1wkBmuSRU5S+Ne6kXjat8GQCPiYBi1IS1mcUQXRT/MoKce3YmxJGvt
> p6jxGBP8d9CeUZe7eOHujKmsBj4OYghX1e6VmYtwdGeaCEw4x5vnxO7GuX8ZkgxZ
> XE/zSyuKB7GLAJUbg11VGUKoLVEP0kOprflj17DsNofXFNDrETL2OykDTNNIsJTP
> c+RuTQE2xlD4EGCbnrYQ5A4tVl6ZtFao8LZXzcOmmAu9yR+6aYVMdEJnFe6iXTSY
> M74pIBLZs3gq5gkhfm0x+sVadkXx/xuG3fslFxHYJIUWXS2aaB1pryrvDKdP1SF7
> F1RzJe6JtflzkkRu0DNBvZdkOztoX+jhldeoWXjZ7qcwKNFC7COvT4piEi+ivIXb
> q3gvuadoGN4SL8M4sJJD2nbmKiDo74UuQ+HisY1xrAM6+ksf+/DxwVHOOX1Akpii
> b77uguwPf6kxmScfI0VrL7LJr9y3vOI4GeQsAqq1ttUghi59u/dZ6qGjbA3xEnTz
> a2w9kHGtwVUTIZaMT3v2nXveI87P+vHNhVDA9GyTmDvdqdVpTQp3nfCMzeCj1/L6
> 5fK78HJnQkdhMcITGVYmgcUAuegws2X1f0pw2/9jzpGWE39Sjjc=
> =YYEe
> -END PGP SIGNATURE-
> 
> 

Bug#844303: closed by Rapha??l Hertzog <hert...@debian.org> (Bug#844303: fixed in ncrack 0.5-3)

[Salvatore Bonaccorso]

reopen 844303 
severity 844303 important
unblock 827061 with 844303
thanks

Hi

Rationale: the package would still FTBFS with OpenSSL 1.1. Thus
(bacause it is now explicitly build depending on 1.0 version), lower
the severity and in particular unblock the OpenSSL 1.1 transition bug.

Let me know though in case I missed something for the above.

Regards,
Salvatore

Bug#845425: Tomcat security update

[Emmanuel Bourg]

Le 30/11/2016 à 23:30, Markus Koschany a écrit :

> Since I haven't heard anything yet I'm going to backport
> ResourceLinkFactory.java as a precaution and release the security
> announcement tomorrow.

Sorry, I haven't spotted the cause of the regression yet.

Emmanuel Bourg

Bug#820229: Xorg: "no screens found(EE)"

[Russell Klopfer]

I believe my issue is different from the one originally reported. I was 
able to resolve my problem by installing 'virtualbox-guest-x11'.


On Tue, 29 Nov 2016 20:39:37 -0500 Russell Klopfer wrote:
> Package: xorg
> Version: 1:7.7+18
> Followup-For: Bug #820229
>
> Dear Maintainer,
>
> X failed to start and I see the same message at the end of the log.
>
> * What led up to the situation?
> - Fresh install (no desktop)
> - apt-get install xorg
> - startx
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> - startx
>
> * What was the outcome of this action?
> - aforementioned error message at the end of Xorg.log
> - I also saw something like:
> "Screens found, but none with a usable configuration."
>
> * What outcome did you expect instead?
> - an XWindows session
>
>
> -- Package-specific info:
> /etc/X11/X does not exist.
> /etc/X11/X is not a symlink.
> /etc/X11/X is not executable.
>
> VGA-compatible devices on PCI bus:
> --
> 00:02.0 VGA compatible controller [0300]: InnoTek Systemberatung GmbH 
VirtualBox Graphics Adapter [80ee:beef]

>
> /etc/X11/xorg.conf does not exist.
>
> /etc/X11/xorg.conf.d does not exist.
>
> /etc/modprobe.d contains no KMS configuration files.
>
> Kernel version (/proc/version):
> ---
> Linux version 4.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc 
version 5.4.1 20160904 (Debian 5.4.1-2) ) #1 SMP Debian 4.7.8-1 (2016-10-19)

>
> Xorg X server log files on system:
> --
> -rw-r--r-- 1 r r 7608 Nov 29 20:18 /home/r/.local/share/xorg/Xorg.0.log
>
> Contents of most recent Xorg X server log file 
(/home/r/.local/share/xorg/Xorg.0.log):
> 
--

> [ 811.549]
> X.Org X Server 1.18.4
> Release Date: 2016-07-19
> [ 811.550] X Protocol Version 11, Revision 0
> [ 811.551] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
> [ 811.552] Current Operating System: Linux debian 4.7.0-1-amd64 #1 
SMP Debian 4.7.8-1 (2016-10-19) x86_64
> [ 811.553] Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-4.7.0-1-amd64 root=/dev/sda1 ro quiet

> [ 811.554] Build Date: 06 September 2016 01:32:44PM
> [ 811.555] xorg-server 2:1.18.4-2 (https://www.debian.org/support)

Bug#846411: linux-image-4.8.0-1-amd64: Webcam Logitech C910 mix doesn't work properly

[Mikhail V. Zhukov]

Package: src:linux
Version: 4.8.7-1
Severity: normal

Dear Maintainer,

I have problem with my Logitech C910 after update linux-image-4.8.0-1-amd64
package from 4.8.5 to 4.8.7-1. I can see such lines in dmesg :
[ 2714.851108] usb 3-9.1: 1:3: cannot set freq 32000 to ep 0x86
[ 2735.843040] usb 3-9.1: 1:3: cannot set freq 32000 to ep 0x86
[ 2752.995121] usb 3-9.1: 1:3: cannot set freq 32000 to ep 0x86

And sound input does not work. pulseaudio log have such lines:
D: [alsa-source-USB Audio] alsa-util.c: Got POLLERR from ALSA
D: [alsa-source-USB Audio] alsa-util.c: Got POLLIN from ALSA
D: [alsa-source-USB Audio] alsa-util.c: PCM state is SUSPENDED
I: [alsa-source-USB Audio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_RESUME failed
(-38)
I: [alsa-source-USB Audio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed
(-71)
I: [alsa-source-USB Audio] (alsa-lib)pcm.c: cannot recovery from suspend,
prepare failed: Ошибка протокола
W: [alsa-source-USB Audio] alsa-util.c: Could not recover from
POLLERR|POLLNVAL|POLLHUP and SUSPENDED: Ошибка протокола

It look like https://bugzilla.kernel.org/show_bug.cgi?id=44281 bug. But I
didn't see it before on my devices.

If I do such commands
rmmod snd-usb-audio
modprobe snd-usb-audio
all work fine



-- Package-specific info:
** Version:
Linux version 4.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.7-1 (2016-11-13)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-1-amd64 
root=UUID=f8fcbe53-1f55-4a1d-8026-4a484a839012 ro quiet noresume 
cgroup_enable=memory swapaccount=1

** Not tainted

** Kernel log:
[2.790933] snd_hda_codec_realtek hdaudioC1D2:mono: mono_out=0x0
[2.790934] snd_hda_codec_realtek hdaudioC1D2:dig-out=0x11/0x1e
[2.790934] snd_hda_codec_realtek hdaudioC1D2:inputs:
[2.790935] snd_hda_codec_realtek hdaudioC1D2:  Rear Mic=0x18
[2.790936] snd_hda_codec_realtek hdaudioC1D2:  Front Mic=0x19
[2.790936] snd_hda_codec_realtek hdaudioC1D2:  Line=0x1a
[2.790937] snd_hda_codec_realtek hdaudioC1D2:  CD=0x1c
[2.790937] snd_hda_codec_realtek hdaudioC1D2:dig-in=0x1f
[2.791694] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[2.793413] intel_rapl: Found RAPL domain package
[2.793414] intel_rapl: Found RAPL domain core
[2.793416] intel_rapl: Found RAPL domain uncore
[2.793417] intel_rapl: Found RAPL domain dram
[2.797174] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[2.797501] acpi device:70: registered as cooling_device13
[2.797560] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7
[2.804554] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card1/input6
[2.805581] input: HDA Intel PCH Rear Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input8
[2.805611] input: HDA Intel PCH Front Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input9
[2.805642] input: HDA Intel PCH Line as 
/devices/pci:00/:00:1b.0/sound/card1/input10
[2.805678] input: HDA Intel PCH Line Out Front as 
/devices/pci:00/:00:1b.0/sound/card1/input11
[2.805709] input: HDA Intel PCH Line Out Surround as 
/devices/pci:00/:00:1b.0/sound/card1/input12
[2.805740] input: HDA Intel PCH Line Out CLFE as 
/devices/pci:00/:00:1b.0/sound/card1/input13
[2.805773] input: HDA Intel PCH Line Out Side as 
/devices/pci:00/:00:1b.0/sound/card1/input14
[2.820636] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[2.820650] [drm] Initialized i915 1.6.0 20160711 for :00:02.0 on minor 0
[2.837257] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT 
filesystems, filesystem will be case sensitive!
[2.839341] fbcon: inteldrmfb (fb0) is primary device
[2.853284] usb 3-10.3: New USB device found, idVendor=045e, idProduct=07a5
[2.853285] usb 3-10.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[2.853285] usb 3-10.3: Product: Microsoft\xffc2\xffae 2.4GHz 
Transceiver v9.0
[2.853286] usb 3-10.3: Manufacturer: Microsoft
[2.855249] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input15
[2.855321] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input16
[2.855397] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input17
[2.867430] Console: switching to colour frame buffer device 160x64
[2.874716] hidraw: raw HID events driver (C) Jiri Kosina
[2.876614] media: Linux media interface: v0.10
[2.880173] Linux video capture interface: v2.00
[2.882755] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[2.891427] usbcore: registered new interface driver usbhid
[2.891428] usbhid: USB HID core driver
[2.893430] hid-generic 

Bug#845614: RFS: acorn/4.0.3-1

[Julien Puydt]

Hi,

On 29/11/2016 09:48, Gianfranco Costamagna wrote:

Hi, still bad

http://debomatic-amd64.debian.net/distribution#unstable/acorn/4.0.3-1/buildlog


It's strange : amd64 is precisely what I have here, so if my pbuilder
was happy... why isn't debomatic?

not sure... different environment? some exports that aren't working?
HOME set to /nonexistent?
different user?
a lot of things differs between sbuild and pbuilder, I tried some export on 
pbuilder
and I can't reproduce too.


Sorry but this seems to be a blocker, since buildds are using sbuild.

also: Ubuntu zesty in a ppa (sbuild) is good
https://launchpadlibrarian.net/295366745/buildlog_ubuntu-zesty-amd64.acorn_4.0.3-1_BUILDING.txt.gz

G.


I tried with sbuild too:
+--+
| Summary 
  |

+--+

Build Architecture: amd64
Build-Space: 4124
Build-Time: 14
Distribution: unstable
Host Architecture: amd64
Install-Time: 42
Job: /home/jpuydt/Debian/build/acorn_4.0.3-1.dsc
Machine Architecture: amd64
Package: acorn
Package-Time: 61
Source-Version: 4.0.3-1
Space: 4124
Status: successful
Version: 4.0.3-1

I'm really at loss as to why it fails on debomatic :-/

Snark on #debian-js

Bug#844692: Upload in progress

[Mathieu Parent]

2016-11-30 12:27 GMT+01:00 Raphael Hertzog :
> On Wed, 30 Nov 2016, Mathieu Parent wrote:
>> NB: The version is 23-nmu3, as my request on alioth to be part of the
>> team has not been approved (yet).
>
> I think you are wrong. I saw you on the list of admins in the project.
> Alioth does not automatically send any notification when you are added.
> :-(

OK thanks.

I've dcut-ed dh-lua_23-nmu3 from deferred and re-uploaded version 24
(also pushed on git).

Cheers

-- 
Mathieu

Bug#844255: Possible solution

[SZALAY Attila]

Hi,

Meanwhile I traced down the issue and found that although the
satisfy_dependencies_string and the install_apt do have
shell_on_failure option, install_deos do not, therefore the chain is
broken.

I created a small patch to add this option to the required places.
diff --git a/lib/adt_testbed.py b/lib/adt_testbed.py
index dda1a69..cb2b8e9 100644
--- a/lib/adt_testbed.py
+++ b/lib/adt_testbed.py
@@ -330,7 +330,7 @@ class Testbed:
 self._opened(pl)
 self.modified = False
 
-def install_deps(self, deps_new, recommends):
+def install_deps(self, deps_new, recommends, shell_on_failure=False):
 '''Install dependencies into testbed'''
 adtlog.debug('install_deps: deps_new=%s, recommends=%s' % (deps_new, recommends))
 
@@ -338,7 +338,7 @@ class Testbed:
 self.recommends_installed = recommends
 if not deps_new:
 return
-self.satisfy_dependencies_string(', '.join(deps_new), 'install-deps', recommends)
+self.satisfy_dependencies_string(', '.join(deps_new), 'install-deps', recommends, shell_on_failure=shell_on_failure)
 
 def needs_reset(self):
 # show what caused a reset
diff --git a/runner/autopkgtest b/runner/autopkgtest
index 79d5751..4482b28 100755
--- a/runner/autopkgtest
+++ b/runner/autopkgtest
@@ -157,7 +157,7 @@ def run_tests(tests, tree):
 adtlog.info('test %s: preparing testbed' % t.name)
 testbed.reset(t.depends, 'needs-recommends' in t.restrictions)
 binaries.publish()
-testbed.install_deps(t.depends, 'needs-recommends' in t.restrictions)
+testbed.install_deps(t.depends, 'needs-recommends' in t.restrictions, opts.shell_fail)
 
 testbed.run_test(tree, t, opts.env, opts.shell_fail, opts.shell,
  opts.build_parallel)

Bug#845559: micro-evtd: service start failed since kernel 4.8

[Ryan Tandy]

On Wed, Nov 30, 2016 at 09:02:26PM -0800, Ryan Tandy wrote:
It looks like micro-evtd just uses the GPIO to watch for the power 
button being pressed. The feature is optional (guarded by #define). If 
we could get the kernel to do that instead, we could omit the GPIO 
monitoring.


Actually, the fallback code to poll the microcontroller for button 
presses seems to work just fine as well.


Roger, would you be willing to try the attached patch on your devices? I 
can upload a .deb somewhere if that would help.
diff -Nru micro-evtd-3.4/debian/changelog micro-evtd-3.4/debian/changelog
--- micro-evtd-3.4/debian/changelog	2016-02-15 14:10:29.0 -0800
+++ micro-evtd-3.4/debian/changelog	2016-11-30 21:19:30.0 -0800
@@ -1,3 +1,11 @@
+micro-evtd (3.4-4) UNRELEASED; urgency=medium
+
+  * Bump to dh compat level 9 to get dpkg-buildflags support.
+  * Add -DNO_GPIO to CPPFLAGS to workaround /dev/mem no longer being 
+readable since CONFIG_STRICT_DEVMEM was enabled. (Closes: #845559)
+
+ -- Ryan Tandy   Wed, 30 Nov 2016 21:19:30 -0800
+
 micro-evtd (3.4-3) unstable; urgency=medium
 
   * Support device-tree enabled kernel
diff -Nru micro-evtd-3.4/debian/compat micro-evtd-3.4/debian/compat
--- micro-evtd-3.4/debian/compat	2016-02-13 00:59:30.0 -0800
+++ micro-evtd-3.4/debian/compat	2016-11-30 21:19:30.0 -0800
@@ -1 +1 @@
-7
+9
diff -Nru micro-evtd-3.4/debian/control micro-evtd-3.4/debian/control
--- micro-evtd-3.4/debian/control	2016-02-13 00:59:30.0 -0800
+++ micro-evtd-3.4/debian/control	2016-11-30 21:19:30.0 -0800
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Ryan Tandy 
-Build-Depends: debhelper (>= 8)
+Build-Depends: debhelper (>= 9)
 Standards-Version: 3.9.3.0
 Homepage: http://www.sourceforge.net/projects/ppc-evtd
 
diff -Nru micro-evtd-3.4/debian/rules micro-evtd-3.4/debian/rules
--- micro-evtd-3.4/debian/rules	2016-02-13 00:59:30.0 -0800
+++ micro-evtd-3.4/debian/rules	2016-11-30 21:19:00.0 -0800
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+export DEB_CPPFLAGS_MAINT_APPEND = -DNO_GPIO
+
 %:
 	dh $@
 

Bug#843962: rails: gitlab activerecord problems

[Yavuz Selim Komur]

ruby-grape-entity_0.6.0 

received last day. You may close this issue, Thanks for your time.

On Fri, 2016-11-11 at 13:37 -0200, Antonio Terceiro wrote:
> On Fri, Nov 11, 2016 at 11:31:45AM +0200, Yavuz Selim Komur wrote:
> > Package: rails
> > Version: 2:4.2.7.1-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > 
> > 
> > ruby-activerecord
> > 
> >    * What led up to the situation?
> >    all gitlab versions. first time get like below
> > 
> > Started GET "/api/v3/projects/all?private_token=[FILTERED]" for
> > xxx.xxx.xxx.xxx at 2016-04-1 2 12:39:52 +0300
> > 
> > NoMethodError (undefined method `[]=' for
> > #
> > Did you mean?  []):
> >    /usr/lib/ruby/vendor_ruby/active_record/serialization.rb:14:in
> > `serializable_hash'
> >    /usr/lib/ruby/vendor_ruby/carrierwave/orm/activerecord.rb:65:in
> > `serializable_hash'
> > 
> > 
> > after gitlab-8.13.3
> > Completed 500 Internal Server Error in 149ms (ActiveRecord: 8.3ms)
> > 
> > NoMethodError (undefined method `sha' for
> > "619cd3b08008fb388ca0426241c52a487620302c":String):
> >   app/models/repository.rb:1081:in `update_branch_with_hooks'
> > --
> > 
> > Sorry for my
> 
> This does not look like an issue in rails at all. Would you
> ellaborate
> on why you think that?

Bug#846321: [Pkg-libvirt-maintainers] Bug#846321: libvirt-daemon should declare a dependency on iptables

[Pirate Praveen]

On വ്യാഴം 01 ഡിസംബര്‍ 2016 12:24 രാവിലെ, Guido Günther wrote:
> libvirt-daemon-system recommends iptables since ages. Do you have
> iptables rules defined? Please provide more logs and domain
> configurations.

May be that should be depends then or may be its a bug in apt-get
dist-upgrade. I did an apt-get dist-upgrade and iptables got removed
(after an apt-get dist-upgrade, lxc stopped working and looking deeper I
found bridge was not getting started and there was an error in
libvirtd). libvirt-daemon-system is installed.




signature.asc
Description: OpenPGP digital signature

Bug#845559: micro-evtd: service start failed since kernel 4.8

[Ryan Tandy]

It looks like micro-evtd just uses the GPIO to watch for the power 
button being pressed. The feature is optional (guarded by #define). If 
we could get the kernel to do that instead, we could omit the GPIO 
monitoring.


Something like
https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-keys.txt
or
https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-keys-polled.txt
maybe...

Bug#846067: RM: glpi -- RoQA; unmaintained; RC-buggy

[Scott Kitterman]

On Wed, 30 Nov 2016 16:32:49 -0200 Eriberto Mota  wrote:
> Please,
> 
> Give me 3 days and I will try ressurrect this package as new
> maintainer. I will go back soon to say my opinion.

Tagged moreinfo to give you a bit of time.

Scott K

Bug#842880: emacs25: Does not enable dynamic modules

[Rob Browning]

Michael Myers  writes:

> Please consider building with the --with-modules flag to enable the dynamic 
> module
> feature added in 25.1.

Hmm.  While I'm not strictly opposed, I'd left it out initially, given
the disclaimer in NEWS about it being experimental and so disabled by
default.  Perhaps worth seeing if upstream has a preference.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#842852: segmentation fault

[Rob Browning]

Juliusz Chroboczek  writes:

> I confirm this -- running 25.1+1-2 on amd64, I get the exact same backtrace:

If you get a chance, could you try 25.1+1-3 and see if it behaves
better?  Hopefully it has fixed a problem with the choice of allocator
which might be related.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#846410: kdevelop crahses when starting (5.0.1)

[choury]

Package: kdevelop
Version: 4:5.0.1-2
Severity: important

Dear Maintainer,

kdevelop crashes every time when i starting it.
And the stack:

Application: KDevelop (kdevelop), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fd9feab0040 (LWP 5739))]

Thread 5 (Thread 0x7fd9e3de8700 (LWP 5743)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fda101242c4 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5
#2  0x7fda10124309 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5
#3  0x7fda14bd0464 in start_thread (arg=0x7fd9e3de8700) at 
pthread_create.c:333
#4  0x7fda1ad9a9df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 4 (Thread 0x7fd9e9369700 (LWP 5742)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x7fda1b480b86 in QWaitCondition::wait(QMutex*, unsigned long) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x7fda18e9a438 in ?? () from 
/usr/lib/x86_64-linux-gnu/libKDevPlatformLanguage.so.10
#3  0x7fda1b47fd88 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fda14bd0464 in start_thread (arg=0x7fd9e9369700) at 
pthread_create.c:333
#5  0x7fda1ad9a9df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 3 (Thread 0x7fd9f72e0700 (LWP 5741)):
#0  0x7fda1ad9156d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7fda129be9f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fda129beb0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fda1b6af6fb in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fda1b65907a in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fda1b47b0d3 in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fda1d7756d5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7fda1b47fd88 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7fda14bd0464 in start_thread (arg=0x7fd9f72e0700) at 
pthread_create.c:333
#9  0x7fda1ad9a9df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 2 (Thread 0x7fd9fc94f700 (LWP 5740)):
#0  0x7fda1ad9156d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7fda0ee11150 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7fda0ee12ee9 in xcb_wait_for_event () from 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7fd9fe674b69 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7fda1b47fd88 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fda14bd0464 in start_thread (arg=0x7fd9fc94f700) at 
pthread_create.c:333
#6  0x7fda1ad9a9df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 1 (Thread 0x7fd9feab0040 (LWP 5739)):
[KCrash Handler]
#6  0x7fd9eb6bf6ad in llvm::cl::Option::setArgStr(llvm::StringRef) () from 
/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1
#7  0x7fd95a929acb in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1
#8  0x7fd95a929d08 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1
#9  0x7fda1d5fa5da in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0x7ffc186d67a8, env=env@entry=0x7ffc186d67b8) at dl-init.c:72
#10 0x7fda1d5fa6eb in call_init (env=0x7ffc186d67b8, argv=0x7ffc186d67a8, 
argc=1, l=) at dl-init.c:30
#11 _dl_init (main_map=main_map@entry=0xf3a490, argc=1, argv=0x7ffc186d67a8, 
env=0x7ffc186d67b8) at dl-init.c:120
#12 0x7fda1d5fec68 in dl_open_worker (a=a@entry=0x7ffc186d5110) at 
dl-open.c:575
#13 0x7fda1d5fa484 in _dl_catch_error 
(objname=objname@entry=0x7ffc186d5100, 
errstring=errstring@entry=0x7ffc186d5108, 
mallocedp=mallocedp@entry=0x7ffc186d50ff, operate=operate@entry=0x7fda1d5fe880 
, args=args@entry=0x7ffc186d5110) at dl-error.c:187
#14 0x7fda1d5fe419 in _dl_open (file=0xf3a398 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kdevplatform/25/kdevclangsupport.so", 
mode=-2147483647, caller_dlopen=0x7fda1b6571be, nsid=-2, argc=, 
argv=, env=0x7ffc186d67b8) at dl-open.c:660
#15 0x7fda12c88ee9 in dlopen_doit (a=a@entry=0x7ffc186d5340) at dlopen.c:66
#16 0x7fda1d5fa484 in _dl_catch_error (objname=0x91b1a0, 
errstring=0x91b1a8, mallocedp=0x91b198, operate=0x7fda12c88e90 , 
args=0x7ffc186d5340) at dl-error.c:187
#17 0x7fda12c89521 in _dlerror_run (operate=operate@entry=0x7fda12c88e90 
, args=args@entry=0x7ffc186d5340) at dlerror.c:163
#18 0x7fda12c88f82 in __dlopen (file=, mode=) 
at dlopen.c:87
#19 0x7fda1b6571be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x7fda1b650285 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x7fda1c494d9a in KPluginLoader::load() () from 
/usr/lib/x86_64-linux-gnu/libKF5CoreAddons.so.5
#22 

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Russ Allbery]

Benjamin Kaduk  writes:
> On Wed, Nov 30, 2016 at 08:55:02PM -0300, Felipe Sateler wrote:

>> Well, this command imports an environment variable from the current
>> environment into the systemd --user one. Therefore, it would need to be
>> run after each time that environment variable is set...

> So, libpam_krb5?

Urk.  I definitely want to avoid forking external programs in PAM modules
if possible.

Isn't there a way to configure a set of environment variables that are
automatically populated into the systemd user environment from the user's
session?  I mean, this stuff is all set up at login, which I assume is
before systemd --user spawns.

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

Bug#824603: meld gives python traceback on first use after installation.

[Andrey Gursky]

Hi,

the exception occurs since commit [1]. Not only GtkShortcutsWindow, but
also set_help_overlay() function for GtkApplicationWindow have been
introduced in GTK+ 3.20 [2].

No requirements bump needed. Please try the patch, I've proposed on [3].

Thanks,
Andrey

[1] 
https://git.gnome.org/browse/meld/commit/?id=0039034eb8f67e27464dfb3c1bf05dc54dbc0698
[2] 
https://git.gnome.org/browse/gtk+/commit/?id=f6d9f9f93de1c3c5a7ab5d9c64783e941189d9b5
[3] https://bugzilla.gnome.org/show_bug.cgi?id=775439

Bug#846404: Missing dependency on glib introspection data

[Andrey Gursky]

Hi,

there is no need to bump the glib version requirement. This bug has
been reported and fixed 1.5 months ago. The missing function will be
just ignored [1].

Regards,
Andrey

[1] https://bugzilla.gnome.org/show_bug.cgi?id=772678

Bug#821051: [PATCH v5 0/3] Add byhand script to perform code signing for secure boot

[Helen Koike]

Publish the signature of packages automatically when the package is processed 
based on previous
package prepared by the maintainer with all the efi images and linux modules.

The maintainer prepare a ${package}-code-sign_${version}_${arch}.tar.xz with 
all the efi images
and/or linux modules, and a changelog file. When processing the package from 
the queue, the
byhand-code-sign script is called, read this .tar.xz package, sign all the efi 
or modules inside
it and publish a tarball with all the signatures at
$ftpdir/dists/$suitedir/main/code-sign/$(sha256sum "$IN_DIR/changelog" | head 
-c 64)_$ARCH.tar.xz
This signature are then retrieved by the maintainers of the *-signed packages 
(e.g. linux-signed,
grub2-signed, fwupdate-signed) to construct the *-signed versions.

NOTE: The maintainers of the main package and the -signed package will have to 
coordinate their
uploads to reduce de propagation delay of a security fix to be incorporated in 
the -signed package

Script used for testing byhand-code-sign-user:
https://github.com/helen-fornazier/dak-codesign-test/blob/master/dak-codesign-test.sh
Check each commit message for more information on testing

Patches are also available here: 
https://github.com/helen-fornazier/dak/tree/review

Changes since v4:
Apend _$ARCH in the end of the tar.xz file
Remove extra new line

diff --git a/scripts/debian/byhand-code-sign b/scripts/debian/byhand-code-sign
index 40afdc6..86abd6e 100755
--- a/scripts/debian/byhand-code-sign
+++ b/scripts/debian/byhand-code-sign
@@ -53,9 +53,8 @@ if [ ! -f "$IN_DIR/changelog" ]; then
error "Can't find changelog file in $IN_TARBALL"
 fi
 
-
 TARGET="$ftpdir/dists/$suitedir/main/code-sign"
-OUT_TARBALL="$TARGET/$(sha256sum "$IN_DIR/changelog" | head -c 64).tar.xz"
+OUT_TARBALL="$TARGET/$(sha256sum "$IN_DIR/changelog" | head -c 
64)_$ARCH.tar.xz"
 
 # Check that this source/arch/version hasn't already been signed
 if [ -e "$OUT_TARBALL" ]; then

Helen Koike (3):
  byhand-code-sign-user: signing script for efi images and linux modules
  byhand-code-sign: intermediate script for code sign
  dak.conf: add packages that trigger byhand-code-sign

 config/debian-security/byhand-code-sign.conf |  43 +++
 config/debian-security/dak.conf  |  24 +++
 config/debian/byhand-code-sign.conf  |  43 +++
 config/debian/dak.conf   |  21 ++
 scripts/debian/byhand-code-sign  |  67 +
 scripts/debian/byhand-code-sign-user | 103 +++
 6 files changed, 301 insertions(+)
 create mode 100644 config/debian-security/byhand-code-sign.conf
 create mode 100644 config/debian/byhand-code-sign.conf
 create mode 100755 scripts/debian/byhand-code-sign
 create mode 100755 scripts/debian/byhand-code-sign-user

-- 
2.7.4

Bug#821051: [PATCH v5 2/3] byhand-code-sign: intermediate script for code sign

[Helen Koike]

This script is meant to be called by AutomaticByHandPackages mechanism,
it will receive the a .tar.xz file with efi images and/or linux
modules, call byhand-code-sign-user as codesign user to generate another
.tar.xz with detached signatures and publish it in the 
$ftpdir/dists/$suitedir/main/code-sign/

Contributions:
Ben Hutchings 
---

This patch series is based on https://ftp-master.debian.org/git/dak.git master
Patches are also available here: 
https://github.com/helen-fornazier/dak/tree/review

Changes since v4:
Append _$ARCH in the end of the tar.xz file
Remove extra new line
---
 scripts/debian/byhand-code-sign | 67 +
 1 file changed, 67 insertions(+)
 create mode 100755 scripts/debian/byhand-code-sign

diff --git a/scripts/debian/byhand-code-sign b/scripts/debian/byhand-code-sign
new file mode 100755
index 000..86abd6e
--- /dev/null
+++ b/scripts/debian/byhand-code-sign
@@ -0,0 +1,67 @@
+#!/bin/bash
+
+set -u
+set -e
+set -o pipefail
+
+if [ $# -lt 5 ]; then
+   echo "Usage: $0 filename version arch changes_file suite"
+   exit 1
+fi
+
+IN_TARBALL="$1"# Tarball to read, compressed with xz
+VERSION="$2"
+ARCH="$3"
+CHANGES="$4"   # Changes file for the upload
+SUITE="$5"
+
+error() {
+   echo >&2 "E: $*"
+   exit 1
+}
+
+# Read dak configuration for security or main archive.
+# Also determine subdirectory for the suite.
+case "$0" in
+/srv/security-master.debian.org/*)
+   configdir="/srv/security-master.debian.org/dak/config/debian-security"
+   suitedir="$SUITE/updates"
+   ;;
+/srv/ftp-master.debian.org/*)
+   configdir="/srv/ftp-master.debian.org/dak/config/debian"
+   suitedir="$SUITE"
+   ;;
+*)
+   error "$0: Can't tell if security or not"
+   ;;
+esac
+. "$configdir/vars"
+
+# cleanup the temporary directories on EXIT
+IN_DIR=
+cleanup() {
+   test -z "$IN_DIR" || rm -rf "$IN_DIR"
+}
+trap cleanup EXIT
+
+# Extract the data from stdin into the input directory
+IN_DIR="$(mktemp -td byhand-code-sign-in.XX)"
+tar xaf "$IN_TARBALL" --directory="$IN_DIR"
+
+# Check if tarball contain the changelog file
+if [ ! -f "$IN_DIR/changelog" ]; then
+   error "Can't find changelog file in $IN_TARBALL"
+fi
+
+TARGET="$ftpdir/dists/$suitedir/main/code-sign"
+OUT_TARBALL="$TARGET/$(sha256sum "$IN_DIR/changelog" | head -c 
64)_$ARCH.tar.xz"
+
+# Check that this source/arch/version hasn't already been signed
+if [ -e "$OUT_TARBALL" ]; then
+   error "Signature tarball already exists: $OUT_TARBALL"
+fi
+
+mkdir -p "${OUT_TARBALL%/*}"
+
+sudo -u codesign "${0%/*}/byhand-code-sign-user" 
"$configdir/byhand-code-sign.conf" < "$IN_TARBALL" > "$OUT_TARBALL"
+echo "I: Created $OUT_TARBALL"
-- 
2.7.4

Bug#821051: [PATCH v5 1/3] byhand-code-sign-user: signing script for efi images and linux modules

[Helen Koike]

The byhand-code-sign-user script receives a .tar.xz file (that can
contain efi images and linux modules) in stdin, sign them using keys as
configured in the configuration file and generate a .tar.xz with all the
signatures in stdout

This script is meant to be called by another byhand script which will
run it as a different user.
stdin and stdout is used for passing the .tar.xz files as this script
may not have permission to access the .tar.xz

It can sign using a token as a Yubikey or through a certificate database
depending on the configuration

Contributions:
Julien Cristau 
Ben Hutchings 

---

This patch series is based on https://ftp-master.debian.org/git/dak.git master
Patches are also available here: 
https://github.com/helen-fornazier/dak/tree/review

TESTS
-
I tested the byhan-code-sign-user using the script here:
https://github.com/helen-fornazier/dak-codesign-test/blob/master/dak-codesign-test.sh

That covers with and without an Yubikey and creating a
privkey with or without a password

To execute it, create a test.tar.xz files with efi and linux modules,
install gnutls-bin, yubico-piv-tool, libnss3-tools and run
./dak-codesign-test.sh test.tar.xz
It should work with a yubikey with default configuration (key and pin
code), otherwise you will need to adjust those parameters in the script.

Changes from last version:
None

---
 config/debian-security/byhand-code-sign.conf |  43 +++
 config/debian/byhand-code-sign.conf  |  43 +++
 scripts/debian/byhand-code-sign-user | 103 +++
 3 files changed, 189 insertions(+)
 create mode 100644 config/debian-security/byhand-code-sign.conf
 create mode 100644 config/debian/byhand-code-sign.conf
 create mode 100755 scripts/debian/byhand-code-sign-user

diff --git a/config/debian-security/byhand-code-sign.conf 
b/config/debian-security/byhand-code-sign.conf
new file mode 100644
index 000..7818b8d
--- /dev/null
+++ b/config/debian-security/byhand-code-sign.conf
@@ -0,0 +1,43 @@
+# Configuration for byhand-sign shell script
+
+# The directory of the certificate database created with certutil
+# where the certificate and possibly the private key (if a token
+# is not used) for signing efi images are stored
+#EFI_CERT_DIR=/etc/dak/efi/certdir
+EFI_CERT_DIR=
+
+# The name that identifies the certificate in the certificate
+# database or in the token.
+# Yubikey is usually "Certificate for Digital Signature"
+# The label can be verified by executing:
+# pkcs11-tool --module=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -O
+EFI_CERT_NAME="Certificate for Digital Signature"
+
+# The label of the token as shown in `p11tool --list-tokens`
+# Set to "NSS Certificate DB" if the private key is in the certificate
+# database and a token will not be used
+#EFI_TOKEN_NAME="NSS Certificate DB"
+EFI_TOKEN_NAME="PIV_II (PIV Card Holder pin)"
+
+# The token pin or the certificate database slot password (if a
+# token is not used) for signing efi images. This is optional in
+# case a token is not used and no slot password is set
+#EFI_SIGN_PIN=123456
+
+# The sign-file linux program to sign modules
+#LINUX_SIGNFILE=/usr/lib/linux-kbuild-4.6/scripts/sign-file
+LINUX_SIGNFILE=
+
+# The private key to use to sign the kernel modules or the token URI
+# as shown by `p11tool --list-tokens`
+#LINUX_MODULES_PRIVKEY=/etc/dak/efi/kernel-key.rsa
+LINUX_MODULES_PRIVKEY="pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29"
+
+# The certificate to verify the kernel modules signature
+#LINUX_MODULES_CERT=/etc/dat/efi/kernel-cert.pem
+LINUX_MODULES_CERT=
+
+# The token pin or the certificate database slot password (if a
+# token is not used) for signing kernel modules. This is optional in
+# case no slot password is set
+#LINUX_SIGN_PIN=123456
diff --git a/config/debian/byhand-code-sign.conf 
b/config/debian/byhand-code-sign.conf
new file mode 100644
index 000..7818b8d
--- /dev/null
+++ b/config/debian/byhand-code-sign.conf
@@ -0,0 +1,43 @@
+# Configuration for byhand-sign shell script
+
+# The directory of the certificate database created with certutil
+# where the certificate and possibly the private key (if a token
+# is not used) for signing efi images are stored
+#EFI_CERT_DIR=/etc/dak/efi/certdir
+EFI_CERT_DIR=
+
+# The name that identifies the certificate in the certificate
+# database or in the token.
+# Yubikey is usually "Certificate for Digital Signature"
+# The label can be verified by executing:
+# pkcs11-tool --module=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -O
+EFI_CERT_NAME="Certificate for Digital Signature"
+
+# The label of the token as shown in `p11tool --list-tokens`
+# Set to "NSS Certificate DB" if the private key is in the certificate
+# database and a token will not be used
+#EFI_TOKEN_NAME="NSS Certificate DB"
+EFI_TOKEN_NAME="PIV_II (PIV Card Holder pin)"
+
+# The token pin or 

Bug#821051: [PATCH v5 3/3] dak.conf: add packages that trigger byhand-code-sign

[Helen Koike]

Add linux, grub2 and fwupdate to publish their signatures by calling
byhand-code-sign as they are supposed to have a *-signed version

Contributions:
Ben Hutchings 

---

This patch series is based on https://ftp-master.debian.org/git/dak.git master
Patches are also available here: 
https://github.com/helen-fornazier/dak/tree/review

To test it, after building the package (grub, linux or fwupdate) create
a file called ${package}-code-sign_${version}_${arch}.tar.xz
with the efi images or kernel modules to be signed

After building the package, add the file in the changes file:

> changestool ${package}-code-sign_${version}_${arch}.changes addrawfile 
> ${package}-code-sign_${version}_${arch}.tar.xz

Edit the .changes file to replace the double dashes by "byhand optional"

> sed -i -e "s/- - ${package}-code-sign_${version}_${arch}.tar.xz/byhand 
> optional ${package}-code-sign_${version}_${arch}.tar.xz/g" 
> ${package}-code-sign_${version}_${arch}.changes

Sign the .changes file
> gpg --clearsign ${package}-code-sign_${version}_${arch}.changes
> mv ${package}-code-sign_${version}_${arch}.changes.asc 
> ${package}-code-sign_${version}_${arch}.changes

Add to uncheck queue
> cp -r ../* /srv/dak/queue/unchecked/

Process the package
> dak process-upload -d /srv/dak/queue/unchecked
---

Changes since last version:
None

 config/debian-security/dak.conf | 24 
 config/debian/dak.conf  | 21 +
 2 files changed, 45 insertions(+)

diff --git a/config/debian-security/dak.conf b/config/debian-security/dak.conf
index f342a55..dbf5395 100644
--- a/config/debian-security/dak.conf
+++ b/config/debian-security/dak.conf
@@ -127,6 +127,30 @@ SuiteMappings
   "reject oldoldstable";
 };
 
+AutomaticByHandPackages
+{
+  "linux-code-sign" {
+Source "linux";
+Section "byhand";
+Extension "tar.xz";
+Script 
"/srv/security-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
+  "grub2-code-sign" {
+Source "grub2";
+Section "byhand";
+Extension "tar.xz";
+Script 
"/srv/security-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
+  "fwupdate-code-sign" {
+Source "fwupdate";
+Section "byhand";
+Extension "tar.xz";
+Script 
"/srv/security-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+};
+
 Dir
 {
   Base "/srv/security-master.debian.org/";
diff --git a/config/debian/dak.conf b/config/debian/dak.conf
index 10322cc..6de05f2 100644
--- a/config/debian/dak.conf
+++ b/config/debian/dak.conf
@@ -185,6 +185,27 @@ AutomaticByHandPackages {
 Script "/srv/ftp-master.debian.org/dak/scripts/debian/byhand-di";
   };
 
+  "linux-code-sign" {
+Source "linux";
+Section "byhand";
+Extension "tar.xz";
+Script "/srv/ftp-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
+  "grub2-code-sign" {
+Source "grub2";
+Section "byhand";
+Extension "tar.xz";
+Script "/srv/ftp-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
+  "fwupdate-code-sign" {
+Source "fwupdate";
+Section "byhand";
+Extension "tar.xz";
+Script "/srv/ftp-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
   "tag-overrides" {
 Source "tag-overrides";
 Section "byhand";
-- 
2.7.4

Bug#845058: [Pkg-fonts-devel] Bug#845058: Bug#845058: fonts-noto: Installing the package freezes all graphical applications.

[陳昌倬]

On Wed, Nov 23, 2016 at 01:00:18AM +0100, Jonas Smedegaard wrote:
> Could you please look into the above, Valentian.
> 
> I now reassigned this bug to fonts-noto-cjk, as that is more likely to 
> be the cause of this than fonts-noto.

My computer needs around 5 mins to install fonts-noto-cjk with
apt/aptitude. During the installation, UI responsiveness is very bad due
to high resource usage. So I think this is indeed caused by huge font
size in fonts-noto-cjk.


To Valentian,

Could you help to install fonts-noto-cjk and wait for a while to see if
it will be finished or not. Maybe it just needs more time to finish the
installation.


-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#846366: ITP: bcc -- Command line tools for BPF Compiler Collection (BCC)

[Ben Hutchings]

On Thu, 2016-12-01 at 00:56 +0530, Ritesh Raj Sarraf wrote:
> Hello Karsten,
> 
> On Wed, 2016-11-30 at 20:05 +0100, Karsten Merker wrote:
> > Hello,
> > 
> > bcc is a package (and executable) name that is already in use for
> > another program in Debian. From https://packages.debian.org/sid/bcc:
> 
> I'm aware of it. bcc is an already packaged binary package. It build from 
> source package: linux86
> 
> For this package, I've tried to be close to what upstream has already named.
> So, for Debian, only the source package name is: bcc.
[...]

Please don't do this.  When the same name is used for a binary package
and for a source package that doesn't build that binary, it tends to
result in mis-assigned bugs as BTS users don't consistently specify
which they mean.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai
Stevenson



signature.asc
Description: This is a digitally signed message part

Bug#846409: xserver-xorg-video-r128: Bug #602531 G4 with r128 crashes after installation without linux-firmware-nonfree package

[Brock Wittrock]

Package: xserver-xorg-video-r128
Version: 6.9.2-1+b2
Severity: important
Tags: upstream

Just want to note that I have a couple of G4 PowerMacs (Quicksilvers, so not
the Cube model) with Rage 128 cards I could test this out on with a fresh
install of Jessie.  I seem to remember this still being an issue though when I
first installed Jessie on a G4 system I still use daily. I had to do something
similar of ssh'ing into the system and installing the linux-firmware-nonfree
package before I had a usable desktop.

I'll do the install tomorrow and report back unless I hear otherwise.



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 May  3  2015 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2498728 Feb 10  2015 /usr/bin/Xorg

The server is using local libraries!

libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x6fbb1000)

VGA-compatible devices on PCI bus:
--
:00:10.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] RV200 [Radeon 7500/7500 LE] [1002:5157]

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 89 Aug 23  2015 01-module-path.conf.old

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 3.16.0-4-powerpc-smp (debian-ker...@lists.debian.org) (gcc 
version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 37628 May  3  2015 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 56913 Nov 30 11:55 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[52.476] 
X.Org X Server 1.16.4
Release Date: 2014-12-20
[52.476] X Protocol Version 11, Revision 0
[52.476] Build Operating System: Linux 3.2.0-4-powerpc64 ppc Debian
[52.476] Current Operating System: Linux Enigma 3.16.0-4-powerpc-smp #1 SMP 
Debian 3.16.36-1+deb8u2 (2016-10-19) ppc
[52.476] Kernel command line: 
root=UUID=76f68002-35c2-4897-9b26-12c391959670 video=offb:off radeon.agpmode=-1 
[52.476] Build Date: 11 February 2015  01:13:01AM
[52.477] xorg-server 2:1.16.4-1 (http://www.debian.org/support) 
[52.477] Current version of pixman: 0.32.6
[52.477]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[52.477] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[52.477] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Nov 26 11:26:22 
2016
[52.943] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[53.225] (==) No Layout section.  Using the first Screen section.
[53.225] (==) No screen section available. Using defaults.
[53.225] (**) |-->Screen "Default Screen Section" (0)
[53.225] (**) |   |-->Monitor ""
[53.226] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[53.226] (==) Automatically adding devices
[53.226] (==) Automatically enabling devices
[53.226] (==) Automatically adding GPU devices
[54.508] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/cyrillic,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[54.508] (==) ModulePath set to "/usr/lib/xorg/modules"
[54.508] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[54.567] (II) Loader magic: 0x208d6698
[54.567] (II) Module ABI versions:
[54.567]X.Org ANSI C Emulation: 0.4
[54.567]X.Org Video Driver: 18.0
[54.567]X.Org XInput driver : 21.0
[54.567]X.Org Server Extension : 8.0
[54.568] (II) xfree86: Adding drm device (/dev/dri/card0)
[54.570] (--) PCI:*(0:0:16:0) 1002:5157:1002:5157 rev 0, Mem @ 
0x9800/134217728, 0x9000/65536, I/O @ 0x0400/256, BIOS @ 
0x/131072
[54.625] (II) LoadModule: "glx"
[54.699] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[56.253] (II) Module glx: vendor="X.Org Foundation"
[56.254]compiled for 1.16.4, module version = 1.0.0
[56.254]ABI class: X.Org Server Extension, version 8.0
[56.254] (==) AIGLX enabled
[56.387] (==) Matched ati as autoconfigured driver 0
[56.387] (==) Matched ati as autoconfigured driver 1
[56.387] (==) Matched modesetting as 

Bug#846408: brasero: Burning Blu-Ray: HL-DT-ST BD-RE BH16NS55 (1.00) fails to burn Blu-Ray

[Adrian Immanuel Kiess]

Package: brasero
Version: 3.12.1-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Try to burn data Blu-Ray with brasero using a HL-DT-ST BD-RE  BH16NS55
(1.00) burner
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Insert blanc Blu-Ray and hit "burn" button
   * What was the outcome of this action?
 Error message that burning failed
   * What outcome did you expect instead?
 brasero burning a data Blu-Ray

burning a data Blu-Ray within Debian/testing using brasero currently fails.

The hardware is as following:

root@g6 (~) % hwinfo --cdrom
27: SCSI 500.0: 10602 CD-ROM (DVD)
  [Created at block.249]
  Unique ID: KD9E.9bpIAC0VFM6
  Parent ID: w7Y8.9Y91nXK0sjC
  SysFS ID: /class/block/sr0
  SysFS BusID: 5:0:0:0
  SysFS Device Link:
/devices/pci:00/:00:1f.2/ata6/host5/target5:0:0/5:0:0:0
  Hardware Class: cdrom
  Model: "HL-DT-ST BD-RE  BH16NS55"
  Vendor: "HL-DT-ST"
  Device: "BD-RE  BH16NS55"
  Revision: "1.00"
  Driver: "ahci", "sr"
  Driver Modules: "ahci", "sr_mod"
  Device File: /dev/sr0 (/dev/sg6)
  Device Files: /dev/sr0, /dev/cdrom, /dev/cdrw, /dev/disk/by-id/ata-HL-DT-
ST_BD-RE_BH16NS55_SIK95FAF8300, /dev/disk/by-path/pci-:00:1f.2-ata-6,
/dev/dvd, /dev/dvdrw
  Device Number: block 11:0 (char 21:6)
  Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL,
BD, BD-R, BD-RE, DVD-RAM
  Drive status: no medium
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #18 (SATA controller)
  Drive Speed: 48

Thank you very much in advance.

With many greetings,

Adrian Immanuel Kieß
http://www.immanuelK.net




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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 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 brasero depends on:
ii  brasero-common  3.12.1-4
ii  gstreamer1.0-plugins-base   1.10.1-1
ii  gvfs1.30.2-2
ii  libbrasero-media3-1 3.12.1-4
ii  libc6   2.24-5
ii  libcairo2   1.14.6-1.1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.2-2
ii  libgstreamer-plugins-base1.0-0  1.10.1-1
ii  libgstreamer1.0-0   1.10.1-1
ii  libgtk-3-0  3.22.4-1
ii  libnautilus-extension1a 3.22.1-2
ii  libpango-1.0-0  1.40.3-3
ii  libtotem-plparser18 3.10.7-1
ii  libtracker-sparql-1.0-0 1.10.1-1
ii  libxml2 2.9.4+dfsg1-2.1

Versions of packages brasero recommends:
ii  brasero-cdrkit  3.12.1-4
ii  yelp3.22.0-1

Versions of packages brasero suggests:
ii  libdvdcss2  1.4.0-dmo1
ii  tracker 1.10.1-1
ii  vcdimager   0.7.24+dfsg-0.2

-- no debconf information

Bug#821051: [PATCH v4 0/3] Add byhand script to perform code signing for secure boot

[Ben Hutchings]

On Wed, 2016-11-30 at 23:12 -0200, Helen Koike wrote:
> Publish the signature of packages automatically when the package is processed 
> based on previous
> package prepared by the maintainer with all the efi images and linux modules.
> 
> The maintainer prepare a ${package}-code-sign_${version}_${arch}.tar.xz with 
> all the efi images
> and/or linux modules, and a changelog file. When processing the package from 
> the queue, the
> byhand-code-sign script is called, read this .tar.xz package, sign all the 
> efi or modules inside
> it and publish a tarball with all the signatures at
> $ftpdir/dists/$suitedir/main/code-sign/$(sha256sum "$IN_DIR/changelog" | head 
> -c 64).tar.xz
> This signature are then retrieved by the maintainers of the *-signed packages 
> (e.g. linux-signed,
> grub2-signed, fwupdate-signed) to construct the *-signed versions.

I missed a bit here.  The output tarball filename needs to include the
architecture name as well as the changelog hash.

> NOTE: this causes a delay between publishing embargoed updates and publishing 
> *-signed packages that can
> be a problem since we avoid to leak the existence of a security flaw before 
> its fix has being released.
> The proposed solution for this is by making dak to publish the *-signed 
> packages automatically.
[...]

I don't follow this.  I've been assuming that the process would be
something like:

1. Mantainer uploads main source package
2. Security team accepts it into the embargoed queue
3. Buildds upload unsigned binary packages
4. Security team accepts these into the embargoed queue.
   By-hand script generates and immediately publishes signatures.
5. Maintainer downloads signatures and prepares signed source package
6. Maintainer uploads signed source package
7. Security team accepts it into the embargoed queue
8. Buildds upload signed binary packages
9. Security team accepts these into the embargoed queue
10. Security team publishes both sets of source and binary packages

Is that not correct/possible?

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai
Stevenson



signature.asc
Description: This is a digitally signed message part

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Benjamin Kaduk]

On Wed, Nov 30, 2016 at 08:55:02PM -0300, Felipe Sateler wrote:
> On 30 November 2016 at 20:39, Russ Allbery  wrote:
> >
> > Apologies for my lack of knowledge of systemd in user mode -- it's really
> > neat but I haven't had a chance to play with it yet.  Who would run this
> > command?  Is it something that libpam-afs-session would run from a
> > postinst maintainer script, or is it something more complicated than that?
> 
> Well, this command imports an environment variable from the current
> environment into the systemd --user one. Therefore, it would need to
> be run after each time that environment variable is set...

So, libpam_krb5?

-Ben

Bug#846282: [pkg-go] Bug#846282: ITP: go-toml -- Go library for the TOML language

[Potter, Tim (HPE Linux Support)]

On 1 Dec 2016, at 11:35 AM, Potter, Tim (HPE Linux Support) 
 wrote:
> 
> On 30 Nov 2016, at 7:20 AM, Dr. Tobias Quathamer  wrote:
>> 
>> Package: wnpp
>> Severity: wishlist
>> Owner: Dr. Tobias Quathamer 
>> 
>> * Package name: go-toml
>> Version : 0.3.5-1
>> Upstream Author : Thomas Pelletier
>> * URL : https://github.com/pelletier/go-toml
>> * License : TODO
>> Programming Lang: Go
>> Description : Go library for the TOML language
>> 
>> This library supports TOML (Tom's Obvious, Minimal Language)
>> version v0.4.0.
>> .
>> TOML aims to be a minimal configuration file format that's
>> easy to read due to obvious semantics. TOML is designed
>> to map unambiguously to a hash table. TOML should be
>> easy to parse into data structures in a wide variety
>> of languages.
> 
> Hi Tobias.  I think the name for this package should be, according to the 
> pkg-go
> standards[1] golang-github-pelletier-go-toml.
> 
> We already have a TOML parser (but more are OK since it's a dependency for
> another package) with a source package named golang-toml, but it was created 
> before
> the particular version of the standard came into effect.

After looking at the code a bit I think the package name was created 
automatically
since dh-make-golang detected that binaries are created.

Here's what I do for packages like this.

* Run "dh-make-golang -type library github.com/foo/bar" to always create a 
library.  Source
package is called golang-github-foo-bar and it produces a 
golang-github-foo-bar-dev package.

* If there is a binary being created add a binary package stanza to d/control 
and add
the appropriate binaries.  Take care not to package test binaries etc.

* Think up a name for the binary package.  This is tricky.  (-:

Regarding binary packaging naming my thoughts are If it's a major app then
the binary and source package should be called the app name, e.g influxdb.

For smaller utilities I usually name the binary package golang-foo, e.g for the 
TOML
parser golang-toml but that name is already taken.  And the full 
golang-github-pelletier-toml
is pretty unwieldy.  Not sure what to do here.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#846407: piglit: creates files in /tmp during build

[Simon Richter]

Package: piglit
Version: 0~git20150829-59d7066-1
Severity: normal

Hi,

after building the piglit package, I found a directory in /tmp that was
named after my user, prefixed with "piglit-". This seems to have been
created during the package build.

The name of this directory is predictable, which might make this a security
problem -- placing data under this name might influence package builds by
other users, and the package build should not create any files outside of
the build tree (probably except for gcc's temporary files).

   Simon

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

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

Versions of packages piglit depends on:
ii  libc62.24-5
ii  libdrm-intel12.4.73-1
ii  libdrm2  2.4.73-1
ii  libegl1-mesa [libegl1-x11]   12.0.4-2
ii  libgcc1  1:6.2.0-13
ii  libgl1-mesa-glx [libgl1] 12.0.4-2
ii  libglu1-mesa [libglu1]   9.0.0-2.1
ii  libpng12-0   1.2.50-2+deb8u2
ii  libstdc++6   6.2.0-13
ii  libwaffle-1-01.5.2-2
ii  libx11-6 2:1.6.3-1
ii  libxcb-dri2-01.12-1
ii  libxrender1  1:0.9.9-2
ii  ocl-icd-libopencl1 [libopencl1]  2.2.9-2
ii  python-six   1.10.0-3
pn  python:any   
ii  zlib1g   1:1.2.8.dfsg-2+b3

piglit recommends no packages.

piglit suggests no packages.

-- no debconf information

Bug#821051: [PATCH v4 1/3] byhand-code-sign-user: signing script for efi images and linux modules

[Helen Koike]

The byhand-code-sign-user script receives a .tar.xz file (that can
contain efi images and linux modules) in stdin, sign them using keys as
configured in the configuration file and generate a .tar.xz with all the
signatures in stdout

This script is meant to be called by another byhand script which will
run it as a different user.
stdin and stdout is used for passing the .tar.xz files as this script
may not have permission to access the .tar.xz

It can sign using a token as a Yubikey or through a certificate database
depending on the configuration

Contributions:
Julien Cristau 
Ben Hutchings 

---

This patch series is based on https://ftp-master.debian.org/git/dak.git master
Patches are also available here: 
https://github.com/helen-fornazier/dak/tree/review

TESTS
-
I tested the byhan-code-sign-user using the script here:
https://github.com/helen-fornazier/dak-codesign-test/blob/master/dak-codesign-test.sh

That covers with and without an Yubikey and creating a
privkey with or without a password

To execute it, create a test.tar.xz files with efi and linux modules,
install gnutls-bin, yubico-piv-tool, libnss3-tools and run
./dak-codesign-test.sh test.tar.xz
It should work with a yubikey with default configuration (key and pin
code), otherwise you will need to adjust those parameters in the script.

Changes from last version:
Skip the changelog file

/scripts/debian/byhand-code-sign-user
@@ -52,6 +52,10 @@ tar xJ --directory="$in_dir" <&0
 out_dir="$(mktemp -td byhand-code-sign-out.XX)"

 while read filename; do
+   # Skip changelog
+   if [ "$filename" == changelog ]; then
+   continue
+   fi
mkdir -p "$out_dir/${filename%/*}"
case "${filename##*/}" in
*.efi | vmlinuz-*)
---
 config/debian-security/byhand-code-sign.conf |  43 +++
 config/debian/byhand-code-sign.conf  |  43 +++
 scripts/debian/byhand-code-sign-user | 103 +++
 3 files changed, 189 insertions(+)
 create mode 100644 config/debian-security/byhand-code-sign.conf
 create mode 100644 config/debian/byhand-code-sign.conf
 create mode 100755 scripts/debian/byhand-code-sign-user

diff --git a/config/debian-security/byhand-code-sign.conf 
b/config/debian-security/byhand-code-sign.conf
new file mode 100644
index 000..7818b8d
--- /dev/null
+++ b/config/debian-security/byhand-code-sign.conf
@@ -0,0 +1,43 @@
+# Configuration for byhand-sign shell script
+
+# The directory of the certificate database created with certutil
+# where the certificate and possibly the private key (if a token
+# is not used) for signing efi images are stored
+#EFI_CERT_DIR=/etc/dak/efi/certdir
+EFI_CERT_DIR=
+
+# The name that identifies the certificate in the certificate
+# database or in the token.
+# Yubikey is usually "Certificate for Digital Signature"
+# The label can be verified by executing:
+# pkcs11-tool --module=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -O
+EFI_CERT_NAME="Certificate for Digital Signature"
+
+# The label of the token as shown in `p11tool --list-tokens`
+# Set to "NSS Certificate DB" if the private key is in the certificate
+# database and a token will not be used
+#EFI_TOKEN_NAME="NSS Certificate DB"
+EFI_TOKEN_NAME="PIV_II (PIV Card Holder pin)"
+
+# The token pin or the certificate database slot password (if a
+# token is not used) for signing efi images. This is optional in
+# case a token is not used and no slot password is set
+#EFI_SIGN_PIN=123456
+
+# The sign-file linux program to sign modules
+#LINUX_SIGNFILE=/usr/lib/linux-kbuild-4.6/scripts/sign-file
+LINUX_SIGNFILE=
+
+# The private key to use to sign the kernel modules or the token URI
+# as shown by `p11tool --list-tokens`
+#LINUX_MODULES_PRIVKEY=/etc/dak/efi/kernel-key.rsa
+LINUX_MODULES_PRIVKEY="pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29"
+
+# The certificate to verify the kernel modules signature
+#LINUX_MODULES_CERT=/etc/dat/efi/kernel-cert.pem
+LINUX_MODULES_CERT=
+
+# The token pin or the certificate database slot password (if a
+# token is not used) for signing kernel modules. This is optional in
+# case no slot password is set
+#LINUX_SIGN_PIN=123456
diff --git a/config/debian/byhand-code-sign.conf 
b/config/debian/byhand-code-sign.conf
new file mode 100644
index 000..7818b8d
--- /dev/null
+++ b/config/debian/byhand-code-sign.conf
@@ -0,0 +1,43 @@
+# Configuration for byhand-sign shell script
+
+# The directory of the certificate database created with certutil
+# where the certificate and possibly the private key (if a token
+# is not used) for signing efi images are stored
+#EFI_CERT_DIR=/etc/dak/efi/certdir
+EFI_CERT_DIR=
+
+# The name that identifies the certificate in the certificate
+# database or in the token.
+# Yubikey is usually "Certificate for Digital Signature"
+# The label can be verified by executing:

Bug#821051: [PATCH v4 0/3] Add byhand script to perform code signing for secure boot

[Helen Koike]

Publish the signature of packages automatically when the package is processed 
based on previous
package prepared by the maintainer with all the efi images and linux modules.

The maintainer prepare a ${package}-code-sign_${version}_${arch}.tar.xz with 
all the efi images
and/or linux modules, and a changelog file. When processing the package from 
the queue, the
byhand-code-sign script is called, read this .tar.xz package, sign all the efi 
or modules inside
it and publish a tarball with all the signatures at
$ftpdir/dists/$suitedir/main/code-sign/$(sha256sum "$IN_DIR/changelog" | head 
-c 64).tar.xz
This signature are then retrieved by the maintainers of the *-signed packages 
(e.g. linux-signed,
grub2-signed, fwupdate-signed) to construct the *-signed versions.

NOTE: this causes a delay between publishing embargoed updates and publishing 
*-signed packages that can
be a problem since we avoid to leak the existence of a security flaw before its 
fix has being released.
The proposed solution for this is by making dak to publish the *-signed 
packages automatically.

Since we already have this problem anyway, we can add this patch in dak and add
the mechanism to automatically publish the *-signed packages latter in 
incremental basis as
we advance constructing the *-signed source packages

Script used for testing byhand-code-sign-user:
https://github.com/helen-fornazier/dak-codesign-test/blob/master/dak-codesign-test.sh
Check each commit message for more information on testing

Patches are also available here: 
https://github.com/helen-fornazier/dak/tree/review

Changes since v3:
Use hash of changelog file to generate the output tarball name with the 
signatures

diff --git a/scripts/debian/byhand-code-sign b/scripts/debian/byhand-code-sign
index f3eceab..40afdc6 100755
--- a/scripts/debian/byhand-code-sign
+++ b/scripts/debian/byhand-code-sign
@@ -37,9 +37,25 @@ case "$0" in
 esac
 . "$configdir/vars"
 
-TARGET="$ftpdir/dists/$suitedir/main/code-sign/"
-OUT_TARBALL="$TARGET/${IN_TARBALL##*/}"
-OUT_TARBALL="${OUT_TARBALL%.tar.xz}_sigs.tar.xz"
+# cleanup the temporary directories on EXIT
+IN_DIR=
+cleanup() {
+   test -z "$IN_DIR" || rm -rf "$IN_DIR"
+}
+trap cleanup EXIT
+
+# Extract the data from stdin into the input directory
+IN_DIR="$(mktemp -td byhand-code-sign-in.XX)"
+tar xaf "$IN_TARBALL" --directory="$IN_DIR"
+
+# Check if tarball contain the changelog file
+if [ ! -f "$IN_DIR/changelog" ]; then
+   error "Can't find changelog file in $IN_TARBALL"
+fi
+
+
+TARGET="$ftpdir/dists/$suitedir/main/code-sign"
+OUT_TARBALL="$TARGET/$(sha256sum "$IN_DIR/changelog" | head -c 64).tar.xz"
 
 # Check that this source/arch/version hasn't already been signed
 if [ -e "$OUT_TARBALL" ]; then
diff --git a/scripts/debian/byhand-code-sign-user 
b/scripts/debian/byhand-code-sign-user
index 91520d6..3477d6c 100755
--- a/scripts/debian/byhand-code-sign-user
+++ b/scripts/debian/byhand-code-sign-user
@@ -52,6 +52,10 @@ tar xJ --directory="$in_dir" <&0
 out_dir="$(mktemp -td byhand-code-sign-out.XX)"
 
 while read filename; do
+   # Skip changelog
+   if [ "$filename" == changelog ]; then
+   continue
+   fi
mkdir -p "$out_dir/${filename%/*}"
case "${filename##*/}" in
*.efi | vmlinuz-*)

Helen Koike (3):
  byhand-code-sign-user: signing script for efi images and linux modules
  byhand-code-sign: intermediate script for code sign
  dak.conf: add packages that trigger byhand-code-sign

 config/debian-security/byhand-code-sign.conf |  43 +++
 config/debian-security/dak.conf  |  24 +++
 config/debian/byhand-code-sign.conf  |  43 +++
 config/debian/dak.conf   |  21 ++
 scripts/debian/byhand-code-sign  |  68 ++
 scripts/debian/byhand-code-sign-user | 103 +++
 6 files changed, 302 insertions(+)
 create mode 100644 config/debian-security/byhand-code-sign.conf
 create mode 100644 config/debian/byhand-code-sign.conf
 create mode 100755 scripts/debian/byhand-code-sign
 create mode 100755 scripts/debian/byhand-code-sign-user

-- 
2.7.4

Bug#846406: mirror submission for ftp.harukasan.org

[Jongmin Kim]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: ftp.harukasan.org
Aliases: iori.harukasan.org
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
IPv6: no
Archive-upstream: ftp.kr.debian.org
Updates: four
Maintainer: Jongmin Kim 
Country: KR Korea, Republic of

Bug#821051: [PATCH v4 2/3] byhand-code-sign: intermediate script for code sign

[Helen Koike]

This script is meant to be called by AutomaticByHandPackages mechanism,
it will receive the a .tar.xz file with efi images and/or linux
modules, call byhand-code-sign-user as codesign user to generate another
.tar.xz with detached signatures and publish it in the 
$ftpdir/dists/$suitedir/main/code-sign/

Contributions:
Ben Hutchings 
---

This patch series is based on https://ftp-master.debian.org/git/dak.git master
Patches are also available here: 
https://github.com/helen-fornazier/dak/tree/review

Changes since last version:
Check if file changelog is present in the IN_TARBALL
Generate the OUT_TARBALL using the sha256sum of the changelog

/scripts/debian/byhand-code-sign
@@ -37,9 +37,25 @@ case "$0" in
 esac
 . "$configdir/vars"

-TARGET="$ftpdir/dists/$suitedir/main/code-sign/"
-OUT_TARBALL="$TARGET/${IN_TARBALL##*/}"
-OUT_TARBALL="${OUT_TARBALL%.tar.xz}_sigs.tar.xz"
+# cleanup the temporary directories on EXIT
+IN_DIR=
+cleanup() {
+   test -z "$IN_DIR" || rm -rf "$IN_DIR"
+}
+trap cleanup EXIT
+
+# Extract the data from stdin into the input directory
+IN_DIR="$(mktemp -td byhand-code-sign-in.XX)"
+tar xaf "$IN_TARBALL" --directory="$IN_DIR"
+
+# Check if tarball contain the changelog file
+if [ ! -f "$IN_DIR/changelog" ]; then
+   error "Can't find changelog file in $IN_TARBALL"
+fi
+
+
+TARGET="$ftpdir/dists/$suitedir/main/code-sign"
+OUT_TARBALL="$TARGET/$(sha256sum "$IN_DIR/changelog" | head -c 64).tar.xz"

 # Check that this source/arch/version hasn't already been signed
 if [ -e "$OUT_TARBALL" ]; then
---
 scripts/debian/byhand-code-sign | 68 +
 1 file changed, 68 insertions(+)
 create mode 100755 scripts/debian/byhand-code-sign

diff --git a/scripts/debian/byhand-code-sign b/scripts/debian/byhand-code-sign
new file mode 100755
index 000..40afdc6
--- /dev/null
+++ b/scripts/debian/byhand-code-sign
@@ -0,0 +1,68 @@
+#!/bin/bash
+
+set -u
+set -e
+set -o pipefail
+
+if [ $# -lt 5 ]; then
+   echo "Usage: $0 filename version arch changes_file suite"
+   exit 1
+fi
+
+IN_TARBALL="$1"# Tarball to read, compressed with xz
+VERSION="$2"
+ARCH="$3"
+CHANGES="$4"   # Changes file for the upload
+SUITE="$5"
+
+error() {
+   echo >&2 "E: $*"
+   exit 1
+}
+
+# Read dak configuration for security or main archive.
+# Also determine subdirectory for the suite.
+case "$0" in
+/srv/security-master.debian.org/*)
+   configdir="/srv/security-master.debian.org/dak/config/debian-security"
+   suitedir="$SUITE/updates"
+   ;;
+/srv/ftp-master.debian.org/*)
+   configdir="/srv/ftp-master.debian.org/dak/config/debian"
+   suitedir="$SUITE"
+   ;;
+*)
+   error "$0: Can't tell if security or not"
+   ;;
+esac
+. "$configdir/vars"
+
+# cleanup the temporary directories on EXIT
+IN_DIR=
+cleanup() {
+   test -z "$IN_DIR" || rm -rf "$IN_DIR"
+}
+trap cleanup EXIT
+
+# Extract the data from stdin into the input directory
+IN_DIR="$(mktemp -td byhand-code-sign-in.XX)"
+tar xaf "$IN_TARBALL" --directory="$IN_DIR"
+
+# Check if tarball contain the changelog file
+if [ ! -f "$IN_DIR/changelog" ]; then
+   error "Can't find changelog file in $IN_TARBALL"
+fi
+
+
+TARGET="$ftpdir/dists/$suitedir/main/code-sign"
+OUT_TARBALL="$TARGET/$(sha256sum "$IN_DIR/changelog" | head -c 64).tar.xz"
+
+# Check that this source/arch/version hasn't already been signed
+if [ -e "$OUT_TARBALL" ]; then
+   error "Signature tarball already exists: $OUT_TARBALL"
+fi
+
+mkdir -p "${OUT_TARBALL%/*}"
+
+sudo -u codesign "${0%/*}/byhand-code-sign-user" 
"$configdir/byhand-code-sign.conf" < "$IN_TARBALL" > "$OUT_TARBALL"
+echo "I: Created $OUT_TARBALL"
-- 
2.7.4

Bug#821051: [PATCH v4 3/3] dak.conf: add packages that trigger byhand-code-sign

[Helen Koike]

Add linux, grub2 and fwupdate to publish their signatures by calling
byhand-code-sign as they are supposed to have a *-signed version

Contributions:
Ben Hutchings 

---

This patch series is based on https://ftp-master.debian.org/git/dak.git master
Patches are also available here: 
https://github.com/helen-fornazier/dak/tree/review

To test it, after building the package (grub, linux or fwupdate) create
a file called ${package}-code-sign_${version}_${arch}.tar.xz
with the efi images or kernel modules to be signed

After building the package, add the file in the changes file:

> changestool ${package}-code-sign_${version}_${arch}.changes addrawfile 
> ${package}-code-sign_${version}_${arch}.tar.xz

Edit the .changes file to replace the double dashes by "byhand optional"

> sed -i -e "s/- - ${package}-code-sign_${version}_${arch}.tar.xz/byhand 
> optional ${package}-code-sign_${version}_${arch}.tar.xz/g" 
> ${package}-code-sign_${version}_${arch}.changes

Sign the .changes file
> gpg --clearsign ${package}-code-sign_${version}_${arch}.changes
> mv ${package}-code-sign_${version}_${arch}.changes.asc 
> ${package}-code-sign_${version}_${arch}.changes

Add to uncheck queue
> cp -r ../* /srv/dak/queue/unchecked/

Process the package
> dak process-upload -d /srv/dak/queue/unchecked

Changes since last version:
No changes

---
 config/debian-security/dak.conf | 24 
 config/debian/dak.conf  | 21 +
 2 files changed, 45 insertions(+)

diff --git a/config/debian-security/dak.conf b/config/debian-security/dak.conf
index f342a55..dbf5395 100644
--- a/config/debian-security/dak.conf
+++ b/config/debian-security/dak.conf
@@ -127,6 +127,30 @@ SuiteMappings
   "reject oldoldstable";
 };
 
+AutomaticByHandPackages
+{
+  "linux-code-sign" {
+Source "linux";
+Section "byhand";
+Extension "tar.xz";
+Script 
"/srv/security-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
+  "grub2-code-sign" {
+Source "grub2";
+Section "byhand";
+Extension "tar.xz";
+Script 
"/srv/security-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
+  "fwupdate-code-sign" {
+Source "fwupdate";
+Section "byhand";
+Extension "tar.xz";
+Script 
"/srv/security-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+};
+
 Dir
 {
   Base "/srv/security-master.debian.org/";
diff --git a/config/debian/dak.conf b/config/debian/dak.conf
index 10322cc..6de05f2 100644
--- a/config/debian/dak.conf
+++ b/config/debian/dak.conf
@@ -185,6 +185,27 @@ AutomaticByHandPackages {
 Script "/srv/ftp-master.debian.org/dak/scripts/debian/byhand-di";
   };
 
+  "linux-code-sign" {
+Source "linux";
+Section "byhand";
+Extension "tar.xz";
+Script "/srv/ftp-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
+  "grub2-code-sign" {
+Source "grub2";
+Section "byhand";
+Extension "tar.xz";
+Script "/srv/ftp-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
+  "fwupdate-code-sign" {
+Source "fwupdate";
+Section "byhand";
+Extension "tar.xz";
+Script "/srv/ftp-master.debian.org/dak/scripts/debian/byhand-code-sign";
+  };
+
   "tag-overrides" {
 Source "tag-overrides";
 Section "byhand";
-- 
2.7.4

Bug#846396: screen: display corruption with bce due to wide character

[Axel Beckert]

Control: tag -1 - confirmed + moreinfo

Hi Vincent,

JFTR: IMHO this issue has not "a major effect on the usability of
the package" (c.f. https://www.debian.org/Bugs/Developer#severities),
but since I'm rather sick of playing severity ping-pong, I'll leave it
as is, at least for now.

Vincent Lefevre wrote:
> > Nevertheless, there is an even partially persistent workaround: Press
> > Ctrl-L inside mutt and the problem vanishes even until after the next
> > detaching and reattaching. Only restarting mutt inside the screen
> > session and then detaching and reattaching again causes it to show up
> > again. Hence downgrading the severity.
> 
> This is incorrect.

Well, then we either see different issues or this is even more a
corner case which requires more variables to have the right values
(font availability maybe? init system maybe? sysvinit here.) than we
know so far.

> With my incoming mailbox, the bug is reproducible
> after doing Ctrl-L. For instance, Page Up + Page Down yields display
> issues, e.g.
> 
>2931 N   2016-11-30 ...
>2932 2016-11-30 ...
>9337 N + 2016-11-30 ...
>2934 N + 2016-11-30 ...
> 
> Also, switching screen [obvious stuff deleted] also yields upward
> shift.

Not here either. Ctrl-L works fine here permanently until I quit
mutt — in both, urxvt and gnome-terminal.

So it's not even that the symtomps are slightly different inside an
urxvt since we see even different behaviour inside gnome-terminal. And
as mentioned above, I'm not even able to reproduce these issues in
uxterm at all (as I don't see the wide character there despite it
should be possible as it is in urxvt.

So I'm no more sure that we actually look at the same issue.

Do you by chance know which font you use in uxterm?

> One major problem is that due to the shift, the arrow can be on the
> wrong message (the arrow is at the right place, but the contents had
> been shifted upwards), and if I type 'd' to delete the message, the
> D mark appears on the wrong message for the same reason.

It would be an issue if you can't fix that with Ctrl-L. But even if it
comes back more often for you than for me, Ctrl-L seems to help at
least immediately as I understand your mail.

> Note that it may not be obvious that the contents have shifted
> upwards, in particular because in my normal config, the help line is
> not shown.

At least for me it always was obvious in the past (e.g. on Squeeze and
Wheezy), especially with mutt and wide characters. And there were
quite some of these bugs in the past…

Especially I'm very used to the fact that screen window switching to
mutt while having displayed the mail index with mails with subjects
containing wide character (usually spam in my case) yields such a
corruption as you describe it, even with uxterm and Ctrl-L only
helping once and not persistently — but I only experience these issues
nowadays with screen from Debian 7 Wheezy — and comparing Sid with
Wheezy on these kind of issues, Sid got much better for me. I also
tried a Screen session on Sid inside a gnome-terminal (as well as
uxterm), then SSHing into a Wheezy box and opening mutt with my spam
archive — which usually triggers such bugs in the screen version in
Wheezy, but screen seems to have improved at lot since then.

E.g. the attached mbox with a single spam message causes the issues
you described for me (even without a wide character as far as I can
see), but only with screen in Wheezy and no more with screen 4.4.0-6
from Sid. So I'm actually a little bit surprised that still see this
issues in Sid with the same intensity as I see them only on Wheezy.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


spam-which-causes-display-corruption-with-mutt-inside-screen-on-wheezy-but-not-sid.xz
Description: Binary data

Bug#846405: dpkg-shlibdeps: scales badly for many binaries

[Simon Richter]

Package: dpkg
Version: 1.18.15
Severity: minor

Hi,

when building the piglit package, the dpkg-shlibdeps invocations take
upwards of 30 minutes (on an i7, building inside a tmpfs). Most of the
time seems to be spent spawning several thousand instances of dpkg-query.

Is there a way to speed this up, e.g. with a cache?

   Simon

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.24-5
ii  liblzma5 5.2.2-1.2
ii  libselinux1  2.6-3
ii  tar  1.29b-1.1
ii  zlib1g   1:1.2.8.dfsg-2+b3

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.3.1

-- no debconf information

Bug#846404: Missing dependency on glib introspection data

[Andrey Gursky]

Package: meld
Version: 3.16.3-1
Severity: normal
Tags: patch

Dear Maintainer,

after update 3.16.2 --> 3.16.3 Meld refused to start:


Traceback (most recent call last):
  File "/usr/bin/meld", line 281, in 
setup_glib_logging()
  File "/usr/bin/meld", line 264, in setup_glib_logging
GLib.log_set_handler(log_domain, level_flag, log_adapter, None)
  File "/usr/lib/python2.7/dist-packages/gi/overrides/__init__.py", line 39, in 
__getattr__
return getattr(self._introspection_module, name)
  File "/usr/lib/python2.7/dist-packages/gi/module.py", line 137, in __getattr__
self.__name__, name))
AttributeError: 'gi.repository.GLib' object has no attribute 'log_set_handler'
^

I've investigated this further. It turns out, the call to
log_set_handler() is new [1]. But this being from the very beginning
glib function is not introspectable. A new function
g_log_set_handler_full() has been added in glib 2.46 [2]. For now meld
package doesn't track the dependency on gir1.2-glib-2.0, which can be
solved by the patch:

diff -rupN debian.orig/control debian/control
--- debian.orig/control 2016-09-26 15:18:27.0 +0200
+++ debian/control  2016-12-01 01:45:53.742123583 +0100
@@ -29,6 +29,7 @@ Depends: ${python:Depends},
  libgtk-3-0 (>= 3.14),
  python-gi (>= 3.8),
  libgtksourceview-3.0-1 (>= 3.14),
+ gir1.2-glib-2.0 (>= 1.46),
  gir1.2-gtksource-3.0 (>= 3.14),
  python-gi-cairo,
  libcanberra-gtk3-module,
diff -rupN debian.orig/control.in debian/control.in
--- debian.orig/control.in  2016-07-13 18:29:28.0 +0200
+++ debian/control.in   2016-12-01 01:41:32.154127932 +0100
@@ -25,6 +25,7 @@ Depends: ${python:Depends},
  libgtk-3-0 (>= 3.14),
  python-gi (>= 3.8),
  libgtksourceview-3.0-1 (>= 3.14),
+ gir1.2-glib-2.0 (>= 1.46),
  gir1.2-gtksource-3.0 (>= 3.14),
  python-gi-cairo,
  libcanberra-gtk3-module,

It's confusing, but 1 in 1.46 is not a typo, since glib introspection
data is packaged not in the glib package.

Regards,
Andrey

[1] 
https://git.gnome.org/browse/meld/commit/?id=137154ed2f6696ef35d5a81a69faade326d8b686
[2] 
https://git.gnome.org/browse/glib/commit/?id=2471d9cf8697b07d4e86b6f143eda7b779be02a9

Bug#846282: [pkg-go] Bug#846282: ITP: go-toml -- Go library for the TOML language

[Potter, Tim (HPE Linux Support)]

On 30 Nov 2016, at 7:20 AM, Dr. Tobias Quathamer  wrote:
> 
> Package: wnpp
> Severity: wishlist
> Owner: Dr. Tobias Quathamer 
> 
> * Package name: go-toml
>  Version : 0.3.5-1
>  Upstream Author : Thomas Pelletier
> * URL : https://github.com/pelletier/go-toml
> * License : TODO
>  Programming Lang: Go
>  Description : Go library for the TOML language
> 
> This library supports TOML (Tom's Obvious, Minimal Language)
> version v0.4.0.
> .
> TOML aims to be a minimal configuration file format that's
> easy to read due to obvious semantics. TOML is designed
> to map unambiguously to a hash table. TOML should be
> easy to parse into data structures in a wide variety
> of languages.

Hi Tobias.  I think the name for this package should be, according to the pkg-go
standards[1] golang-github-pelletier-go-toml.

We already have a TOML parser (but more are OK since it's a dependency for
another package) with a source package named golang-toml, but it was created 
before
the particular version of the standard came into effect.


Tim.

[1] https://pkg-go.alioth.debian.org/packaging.html


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#838169: duck: temporary file issues: mkdtemp deprecated, hardcodes /tmp

[Paul Wise]

On Wed, 2016-11-30 at 20:34 +0100, Simon Kainz wrote:

> To: Paul Wise , cont...@bugs.debian.org

Looks like you forgot to CC the bug. I've bounced your mail to it.

> fixed in repo, commit a018caca6f910954f1be861e1e546bc765449292

I think you meant 78187128991cf923728fa247d8cf23c870d2616c

That commit mashes together a lot of completely unrelated things.
I would suggest separating unrelated changes into different commits.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#845453: [pkg-go] Bug#845453: even more issues

[Martín Ferrari]

On 30/11/16 19:59, Martín Ferrari wrote:
> I was trying to solve this bug, but then I realised this package
> actually only contains pre-generated files, without source. And the
> upstream project is gone.
> 
> It should be replaced with https://github.com/google/go-genproto
> 
> For now I will pull the sources from upstream and regenerate the protos.
> 

Actually, I don't think I can solve this. I am already packaging its
replacement (and what newer versions of google-cloud need),
golang-google-genproto.

-- 
Martín Ferrari (Tincho)

Bug#838169: duck: temporary file issues: mkdtemp deprecated, hardcodes /tmp

[Simon Kainz]

tags 838169 pending
thanks

Hi,

fixed in repo, commit a018caca6f910954f1be861e1e546bc765449292

Thanks for your suggestions.

Bye,

Simon


Am 2016-09-18 um 04:01 schrieb Paul Wise:
> Package: duck
> Version: 0.10
> Severity: normal
> Usertags: tmp
> 
> I override the various environment variables that allow you to select a
> different location for temporary files. DUCK completely ignores that
> and hard-codes /tmp/duckXX as the argument to mkdtemp. The mkdtemp
> function should no longer be used for new code. The File::Temp
> functions newdir or tempdir should be used instead of mkdtemp.
> 
> http://perldoc.perl.org/File/Temp.html
> 
> pabs@chianamo ~ $ env | egrep 'TE?MP'
> TMPDIR=/tmp/user/1000
> TEMP=/tmp/user/1000
> TEMPDIR=/tmp/user/1000
> TMP=/tmp/user/1000
> pabs@chianamo ~ $ env | grep TE?MP^C
> pabs@chianamo ~ $ duck -v http://example.org/foo.dsc
> Downloading to /tmp/duckbhcrLK
> dget: retrieving http://example.org/foo.dsc
> 
> 
> dpkg-source: error: cannot read foo.dsc: No such file or directory
> pabs@chianamo ~ $ grep /tmp /usr/bin/duck
> my $tempdir=mkdtemp("/tmp/duckXX");
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages duck depends on:
> ii  devscripts   2.16.7
> ii  dpkg-dev 1.18.10
> ii  libconfig-inifiles-perl  2.89-1
> ii  libconfig-simple-perl4.59-6
> ii  libdomain-publicsuffix-perl  0.14.1-1
> ii  libfile-which-perl   1.21-1
> ii  libmailtools-perl2.13-1
> ii  libnet-dns-perl  1.06-1
> ii  libparse-debcontrol-perl 2.005-4
> ii  libpath-class-perl   0.37-1
> ii  libregexp-common-email-address-perl  1.01-4
> ii  libregexp-common-perl2016060801-1
> ii  libstring-similarity-perl1.04-1+b3
> ii  libwww-curl-perl 4.17-2+b1
> ii  libxml-xpath-perl1.37-1
> ii  libyaml-libyaml-perl 0.63-1
> ii  lynx 2.8.9dev9-1
> ii  perl 5.22.2-5
> ii  publicsuffix 20160805-1
> 
> duck recommends no packages.
> 
> Versions of packages duck suggests:
> ii  bzr 2.7.0+bzr6619-1
> ii  git 1:2.9.3-1
> ii  mercurial   3.9.1-1
> ii  subversion  1.9.4-3
> 
> -- no debconf information
> 



signature.asc
Description: OpenPGP digital signature

Bug#846402: ITP: golang-google-genproto -- Generated Go packages for common protocol buffer types

[Martín Ferrari]

Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari" 

* Package name: golang-google-genproto
  Version : 0.0~git20161115.08f135d-1
  Upstream Author : Google Inc.
* URL : https://godoc.org/google.golang.org/genproto
* License : Apache-2.0
  Programming Lang: Golang
  Description : Generated Go packages for common protocol buffer types
 This repository contains the generated Go packages for common protocol buffer
 types, and the generated gRPC code necessary for interacting with Google's
 gRPC APIs.
 .
 It provides similar functionality to the now abandoned
 golang-github-googleapis-proto-client-go.
 .
 There are two sources for the proto files used in this repository:
 .
 * google/protobuf: the code in the protobuf and ptypes subdirectories is
   derived from this repo. The messages in protobuf are used to describe
   protocol buffer messages themselves. The messages under ptypes define the
   common well-known types.
 * googleapis/googleapis: the code in the googleapis is derived from this repo.
   The packages here contain types specifically for interacting with Google
   APIs.

Bug#846403: piglit: please build in parallel

[Simon Richter]

Package: piglit
Version: 0~git20150829-59d7066-1
Severity: wishlist
Tags: patch

Hi,

building in parallel speeds up the compilation process significantly.
Unless there are incorrect dependencies in the build process, this should
not have adverse effects.

   Simon

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

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

Versions of packages piglit depends on:
ii  libc6   2.24-5
ii  libdrm-intel1   2.4.73-1
ii  libdrm2 2.4.73-1
ii  libegl1-mesa [libegl1-x11]  12.0.4-2
ii  libgcc1 1:6.2.0-13
ii  libgl1-mesa-glx [libgl1]12.0.4-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libstdc++6  6.2.0-13
ii  libwaffle-1-0   1.5.2-2
ii  libx11-62:1.6.3-1
ii  libxcb-dri2-0   1.12-1
ii  libxcb1 1.12-1
ii  python-six  1.10.0-3
pn  python:any  

piglit recommends no packages.

piglit suggests no packages.

-- no debconf information
diff -Nru piglit-0~git20150829-59d7066/debian/rules piglit-0~git20150829-59d7066/debian/rules
--- piglit-0~git20150829-59d7066/debian/rules	2015-11-09 08:44:36.0 +0100
+++ piglit-0~git20150829-59d7066/debian/rules	2016-12-01 01:29:08.0 +0100
@@ -4,7 +4,7 @@
 DEB_DESTDIR := $(CURDIR)/debian/piglit
 
 %:
-	dh $@ --buildsystem cmake --with python2
+	dh $@ --parallel --buildsystem cmake --with python2
 
 override_dh_auto_configure:
 	dh_auto_configure -- \

Bug#845549: piglit: OpenCL tests do not work

[Simon Richter]

Package: piglit
Version: 0~git20150829-59d7066-1
Followup-For: Bug #845549

Hi,

this patch adds OpenCL support.

   Simon

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

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

Versions of packages piglit depends on:
ii  libc6   2.24-5
ii  libdrm-intel1   2.4.73-1
ii  libdrm2 2.4.73-1
ii  libegl1-mesa [libegl1-x11]  12.0.4-2
ii  libgcc1 1:6.2.0-13
ii  libgl1-mesa-glx [libgl1]12.0.4-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libstdc++6  6.2.0-13
ii  libwaffle-1-0   1.5.2-2
ii  libx11-62:1.6.3-1
ii  libxcb-dri2-0   1.12-1
ii  libxcb1 1.12-1
ii  python-six  1.10.0-3
pn  python:any  

piglit recommends no packages.

piglit suggests no packages.

-- no debconf information
diff -Nru piglit-0~git20150829-59d7066/debian/control piglit-0~git20150829-59d7066/debian/control
--- piglit-0~git20150829-59d7066/debian/control	2015-11-09 08:44:36.0 +0100
+++ piglit-0~git20150829-59d7066/debian/control	2016-12-01 01:29:01.0 +0100
@@ -11,6 +11,7 @@
libgl1-mesa-dev | libgl-dev,
libglu1-mesa-dev | libglu-dev,
libxcb1-dev,
+   ocl-icd-opencl-dev | opencl-dev,
libwaffle-dev (>= 1.3),
pkg-config,
python (>= 2.7),
@@ -27,5 +28,5 @@
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Pre-Depends}, ${misc:Depends},
  ${python:Depends}, python-six
-Description: Open-source test suite for OpenGL implementations
- Piglit is an open-source test suite for OpenGL implementations.
+Description: Open-source test suite for OpenGL and OpenCL implementations
+ Piglit is an open-source test suite for OpenGL and OpenCL implementations.
diff -Nru piglit-0~git20150829-59d7066/debian/rules piglit-0~git20150829-59d7066/debian/rules
--- piglit-0~git20150829-59d7066/debian/rules	2015-11-09 08:44:36.0 +0100
+++ piglit-0~git20150829-59d7066/debian/rules	2016-12-01 01:29:08.0 +0100
@@ -14,6 +14,7 @@
 		-DPIGLIT_BUILD_GLES1_TESTS=1 \
 		-DPIGLIT_BUILD_GLES2_TESTS=1 \
 		-DPIGLIT_BUILD_GLES3_TESTS=1 \
+		-DPIGLIT_BUILD_CL_TESTS=1 \
 		-DPIGLIT_USE_WAFFLE=1
 
 override_dh_auto_install:

Bug#846401: ITP: fswatch -- File change monitor that receives notifications on file or directory changes

[Alf Gaida]

Package: wnpp
Severity: wishlist
Owner: Alf Gaida 

* Package name: fswatch
  Version : 1.9.96
  Upstream Author : Enrico M. Crisostomo 
* URL : https://github.com/emcrisostomo/fswatch
* License : GPL-3+
  Programming Lang: C, C++
  Description : File change monitor that receives notifications on file or 
directory changes

fswatch is a file change monitor that receives notifications when the contents 
of the specified
files or directories are modified. fswatch implements four kinds of monitors:
 * A monitor based on the File System Events API of Apple OS X.
 * A monitor based on kqueue, a notification interface introduced in FreeBSD 
4.1 (and supported
   on most *BSD systems, including OS X).
 * A monitor based on the File Events Notification API of the Solaris kernel 
and its derivatives.
 * A monitor based on inotify, a Linux kernel subsystem that reports file 
system changes to applications.
 * A monitor based on ReadDirectoryChangesW, a Microsoft Windows API that 
reports changes to a directory.
 * A monitor which periodically stats the file system, saves file modification 
times in memory, and
   manually calculates file system changes (which works anywhere stat (2) can 
be used).

fswatch should build and work correctly on any system shipping either of the 
aforementioned APIs.

Bug#845648: [debian-mysql] Bug#845648: mention how to deal with Pre-4.1 password hash found. It is deprecated and will be removed in a future release. Please upgrade it to a new format warning

[積丹尼 Dan Jacobson]

> "NHR" == Norvald H Ryeng  writes:

NHR> I think you need to specify the authentication plugin for those users,
NHR> e.g., "mysql_native_password".

NHR> Please read http://dev.mysql.com/doc/refman/5.7/en/alter-user.html for
NHR> details about the ALTER USER command.

Well it says

The default plugin is mysql_native_password unless the
default_authentication_plugin system variable is set otherwise.

Still

ALTER USER 'wikiuser'@'localhost.localdomain' IDENTIFIED WITH 
mysql_native_password BY '...';
ERROR 1396 (HY000) at line 1: Operation ALTER USER failed for 
'wikiuser'@'localhost.localdomain'

and aren't these the ones
WHERE plugin != ''

OK now trying

ALTER USER 'wikiuser'@'localhost.localdomain' IDENTIFIED WITH '' BY '...';"
ERROR 1396 (HY000) at line 1: Operation ALTER USER failed for 
'wikiuser'@'localhost.localdomain'

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Felipe Sateler]

On 30 November 2016 at 20:39, Russ Allbery  wrote:
> Felipe Sateler  writes:
>> On 30 November 2016 at 19:20, Michael Biebl  wrote:
>>> Am 30.11.2016 um 23:12 schrieb Russ Allbery:
>
 Anyway, it certainly could be registered in -noninteractive (there was
 some reason why I didn't do that), but I think the Kerberos ticket
 cache problem will still be an issue.  Is there some mechanism to
 convey the value of KRB5CCNAME from the user's login environment to
 systemd --user?
>
>>> systemctl --user set-environment
>>> might be what you are looking for.
>
>> `systemctl --user import-environment KRB5CCNAME` might be more
>> appropriate if this variable should be copied from an already existing
>> environment.
>
> Apologies for my lack of knowledge of systemd in user mode -- it's really
> neat but I haven't had a chance to play with it yet.  Who would run this
> command?  Is it something that libpam-afs-session would run from a
> postinst maintainer script, or is it something more complicated than that?

Well, this command imports an environment variable from the current
environment into the systemd --user one. Therefore, it would need to
be run after each time that environment variable is set...

-- 

Saludos,
Felipe Sateler

Bug#846400: usbguard: Missing init script for systems without systemd

[Axel Beckert]

Package: usbguard
Version: 0.5.14+ds1-2

Dear Maintainer,

on Debian installations with a different init system than systemd,
e.g. sysvinit or openrc, the usbguard daemon s not being started due to
a missing init script in /etc/init.d/. Please ship one with the Debian
package. TIA!

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages usbguard depends on:
ii  init-system-helpers  1.46
ii  libc62.24-7
ii  libcap-ng0   0.7.7-3
ii  libdbus-1-3  1.10.14-1
ii  libdbus-glib-1-2 0.108-1
ii  libgcc1  1:6.2.1-5
ii  libglib2.0-0 2.50.2-2
ii  libqb0   1.0-1
ii  libseccomp2  2.3.1-2.1
ii  libstdc++6   6.2.1-5
ii  libusbguard0 0.5.14+ds1-2

usbguard recommends no packages.

usbguard suggests no packages.

-- Configuration Files:
/etc/usbguard/usbguard-daemon.conf changed:
RuleFile=/etc/usbguard/rules.conf
ImplicitPolicyTarget=block
PresentDevicePolicy=keep
PresentControllerPolicy=keep
IPCAllowedUsers=root abe
IPCAllowedGroups=root
DeviceRulesWithPort=false


-- no debconf information

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Benjamin Kaduk]

On Wed, Nov 30, 2016 at 07:31:24PM -0300, Felipe Sateler wrote:
> 
> `systemctl --user import-environment KRB5CCNAME` might be more
> appropriate if this variable should be copied from an already existing
> environment.

But when would this run, and what package would be responsible for causing
it to be run?  (I would prefer to not require that the user is responsible
for causing it to be run.)


Michael Biebl  writes:

> This was mentiond on IRC:
>
> >  afaik, AFS tokens are stored as special keys in the
> > keyring, nowadays... so it might work if afs was patched to look in
> > the 'user' keyring, or if regular logins somehow joined systemd's
> > session keyring instead of creating a new one
> >  (CIFS has the same problem)

The AFS tokens are scoped to a specific PAG (Process Authentication Group),
which can provide cross-process isolation.  Processes can request to be
put in a new PAG explicitly if they desire separation, and PAGS are
identified by the afs_pag key type in the session keyring.  We generally
don't want to use the user keyring since that could lead to neutering of
the cross-process isolation that the PAGs are expected to provide.

-Ben

P.S. Looking more closely at the linked google doc, it was more likely
to be Jonathan Billings than Dave Botsch who wrote it.

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Russ Allbery]

Felipe Sateler  writes:
> On 30 November 2016 at 19:20, Michael Biebl  wrote:
>> Am 30.11.2016 um 23:12 schrieb Russ Allbery:

>>> Anyway, it certainly could be registered in -noninteractive (there was
>>> some reason why I didn't do that), but I think the Kerberos ticket
>>> cache problem will still be an issue.  Is there some mechanism to
>>> convey the value of KRB5CCNAME from the user's login environment to
>>> systemd --user?

>> systemctl --user set-environment
>> might be what you are looking for.

> `systemctl --user import-environment KRB5CCNAME` might be more
> appropriate if this variable should be copied from an already existing
> environment.

Apologies for my lack of knowledge of systemd in user mode -- it's really
neat but I haven't had a chance to play with it yet.  Who would run this
command?  Is it something that libpam-afs-session would run from a
postinst maintainer script, or is it something more complicated than that?

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

Bug#845802: padsp 32 bits application issue on 64 bits system

[Felipe Sateler]

Control: forwarded -1 
https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-November/027199.html

On 26 November 2016 at 16:58, Nicolas DEFFAYET  wrote:
> Package: pulseaudio-utils
> Version: 5.0-13
> Severity: normal
>
>
> Issue
> -
>
> padsp provided in pulseaudio-utils:amd64 support only 64 bits
> applications.
>
> 32 bits applications run on 64 bits system (multiarch) fail with:
> ERROR: ld.so: object
> '/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsedsp.so' from LD_PRELOAD
> cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
>
>
> Where is the bug ?
> --
>
> The bug is due to the fact padsp provided in pulseaudio-utils:amd64
> always load 64 bit version of libpulsedsp.so. This can't work for 32
> bits applications as they require 32 bit version of libpulsedsp.so.
>
>
> How fix the issue ?
> ---
>
> # cp /usr/bin/padsp /usr/bin/padsp32
> # sed -i 's/\/usr\/lib\/x86_64-linux-gnu\/pulseaudio\/libpulsedsp.so/ =>
> \/usr\/lib\/i386-linux-gnu\/pulseaudio
> \/libpulsedsp.so/g' /usr/bin/padsp32
>
> /usr/bin/padsp32 must be provided in pulseaudio-utils:amd64 in addition
> of /usr/bin/padsp.
>
> Expected usage is:
> /usr/bin/padsp 
> /usr/bin/padsp32 

A better fix would be to have padsp load the correct library according
to the binary being loaded. Upstream patch proposed at the url above.

I don't think this will be fixed in jessie though. This would be too
intrusive a change.

-- 

Saludos,
Felipe Sateler

Bug#846399: RFS: rush/1.8+dfsg-1 -- New upstream's release.

[Mats Erik Andersson]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor of the package "rush":

  Package name: rush
  Version : 1.8+dfsg-1
  Upstream Author : Sergey Poznyakoff 
  URL : http://puszcza.gnu.org.ua/projects/rush/
  License : GPL-3+
  Section : shells

It builds a single binary package:

  rush  - restricted user shell

Further information about this package upload is located at

  https://mentors.debian.net/package/rush

A direct download of the package itself is simple:

  dget -x https://mentors.debian.net/debian/pool/main/r/rush/rush_1.8+dfsg-1.dsc

Changes since last upload:

  * New upstream release.
  * Increase hardening level.
+ debian/rules: Updated.
  * Verifying original source archive while rebuilding it.
+ debian/upstream/signing-key.pgp: New file.
+ debian/source/include-binaries: New file.
+ debian/rules: Expand target 'get-orig-source' with a step that
  verifies the source archive fetched from upstream's location.
  * Review patches.
+ debian/patches/dfsg_reduction.diff: Updated.
+ debian/patches/tcpmux_service.diff: Updated, partially applied.
+ debian/patches/chroot_then_chdir.diff: Updated.
+ debian/patches/gets_removed.diff: Obsolete.
+ debian/patches/cve_2013_6889.diff: Removed, applied by Upstream.
+ debian/patches/help_text.diff: Likewise.
+ debian/patches/format_security.diff: New file.
  * Upstream author now provides manual pages.
+ debian/patches/manpages.diff: New file.
+ debian/rules: Preserve the manual pages during target get-orig-source.
  Override dh_installman.
+ debian/rush.manpages: Refreshed list.
  * debian/copyright: Updated.
  * [lintian] Mend spelling errors in README.Debian.


Best regards,
  Mats Erik Andersson

Bug#846396: screen: display corruption with bce due to wide character

[Vincent Lefevre]

Control: severity -1 important

On 2016-11-30 23:44:20 +0100, Axel Beckert wrote:
> I was able to reproduce this issue inside an urxvt, but not inside an
> uxterm — there I just got a question mark inside a filled circle
> instead of a wide character.

Strange, I can reproduce it with uxterm (note that xterm with UTF-8
locales is my usual terminal) and GNOME Terminal.

> And if you type cursor down, you get two arrows, one below the line
> with no. 2, i.e. where the line should be, but isn't.

I get a single arrow, below the line no 2.

> Nevertheless, there is an even partially persistent workaround: Press
> Ctrl-L inside mutt and the problem vanishes even until after the next
> detaching and reattaching. Only restarting mutt inside the screen
> session and then detaching and reattaching again causes it to show up
> again. Hence downgrading the severity.

This is incorrect. With my incoming mailbox, the bug is reproducible
after doing Ctrl-L. For instance, Page Up + Page Down yields display
issues, e.g.

   2931 N   2016-11-30 ...
   2932 2016-11-30 ...
   9337 N + 2016-11-30 ...
   2934 N + 2016-11-30 ...

Also, switching screen (which I do quite often, this is one of the main
feature of GNU screen) also yields upward shift. One major problem is
that due to the shift, the arrow can be on the wrong message (the arrow
is at the right place, but the contents had been shifted upwards), and
if I type 'd' to delete the message, the D mark appears on the wrong
message for the same reason. This means that the message that will be
deleted is not the one I expected from the display (I already deleted
a wrong mail in the past due to a similar bug, which was this time a
character whose wcwdith was 0). Note that it may not be obvious that
the contents have shifted upwards, in particular because in my normal
config, the help line is not shown.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#845185: init-system-helpers: deb-system-invoke starts disabled systemd service on package install/upgrade (backport request)

[Felipe Sateler]

On 21 November 2016 at 05:37, Yury V. Zaytsev  wrote:
> Package: init-system-helpers
> Version: 1.22
> Severity: important
>
> Hi,
>
> In short, on Jessie, when a systemd-only package is installed and/or
> upgraded, the service is started even when disabled, which is a very
> annoying and unsafe behavior; please refer to the original bug for the
> details: #768456. The bug was fixed and the fix has been out in the wild for
> quite some time, but, very unfortunately, it didn't make it into Jessie.
>
> I'm filing this bug as discussed on #debian-systemd, requesting to kindly
> backport the relevant commit and push the new package to -updates:
>
> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=a4e43fcdabf7962d2a765b6b0e11a51734afb5f0

I've been thinking about this, and the fix would be incomplete without
addressing #768450 too. Unfortunately, this means also an update of
src:sysvinit (as invoke-rc.d was moved to i-s-h post-jessie) is needed
but I don't really want to touch that...

-- 

Saludos,
Felipe Sateler

Bug#846384: apt-listbugs: allow to pin bugs manually

[Martin Steigerwald]

Am Mittwoch, 30. November 2016, 23:39:40 CET schrieb Francesco Poli:
[…]
> On Wed, 30 Nov 2016 21:31:41 +0100 Martin Steigerwald wrote:
[…]
> Hello Martin,
> thanks for your bug report.

Thank you for your detailed answer.

[…]
> > cause Michael downgraded the severity of that bug to "normal" and thus
> > from
> > what I understand apt-listbug would not protect my system from upgrading
> > to
> > the newer broken chromium version in unstable.
> 
> Well, what will happen is that apt-listbugs will remove the pin, since
> the bug that you fear was downgraded to a severity ("normal") that
> apt-listbugs ignores.

Hmmm, okay.

> To avoid the automatic pin removal, you have two possible strategies
> (that I can think of):
> 
>  (a) you may include "normal" in the list of severities to be considered
> by apt-listbugs (see option AptListbugs::Severities
> in /etc/apt/apt.conf.d/10apt-listbugs ; this option may for instance be
> set to "critical,grave,serious,important,normal")
> 
>  (b) you may create a manual pin outside of apt-listbugs jurisdiction
> (without Explanation fields and in files other
> than /etc/apt/preferences.d/apt-listbugs ; for instance in
> /etc/apt/preferences.d/chromium-pin )

I know how to manually pin and I chose that approach now.

I just had the hope that I could use apt-listbugs as that would automatically 
remove the pin for me if the bug was solved.

> > I do hope that apt-listbugs will automatically remove it once the bug is
> > fixed,
> 
> I am afraid apt-listbugs will remove the pin on the next run of its
> cron daily job...

I would help to ease handling of bugs with lower severity that I personally 
determine as being critical like in this case where Chromium is basically 
unuseable due to the crashes at every second click on a webpage.

> > I didn´t see a way to do it after looking at the manpage of apt-listbugs
> > tough.
> 
> Indeed, apt-listbugs is not intended to be an on-demand package pin
> generator. It will generate pins for packages that would introduce
> bugs (of one of the configured severities) into your system.

Hmmm, I understand. So for apt-listbugs I need to rely on the judgement of the 
Debian developer or maintainer or confront myself with lots of uncritical bug 
reports.

Well it was an idea and I thought a useful one. You are maintaining and 
developing (?) apt-listbugs, so… its your call. Feel free to close the report 
as wontfix if you do not intend to create such a feature.

Ciao,
-- 
Martin

Bug#756109: systemd: Please copy 70-uaccess.rules and 71-seat.rules in the initramfs

[Martin Pitt]

Control: tag -1 pending

Bonsoir Laurent,

Laurent Bigonville [2016-11-30 21:13 +0100]:
> I quickly retested with that rules file and plymouth seems happy with it.

Cool, thanks!

  https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=4f6f3035b9

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#771159: yasnippet: Reports `flet' is an obsolete macro

[Sean Whitton]

control: reopen 771159

On Wed, Nov 30, 2016 at 03:41:21PM -0700, Sean Whitton wrote:
> This is indeed fixed in more recent upstream versions, including the one
> now on its way into Debian unstable.

Whoops, it was #846047 that was fixed.  Sorry for the noise.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#846397: winff: Desktop and icon files missing

[asciiwolf]

Oops, I see the desktop/icon files are there, but are in winff-data package,
not in the main winff package. So the problem with GNOME Software is 
probably a bug in the AppStream generator.

Bug#385737: screen: Screen not properly redrawn when viewing Devanagari script in mutt

[Axel Beckert]

Control: tag -1 + moreinfo

Hi Laurant,

Laurent Fousse wrote:
> * Jan Christoph Nordholz [Sun, Sep 23, 2007 at 05:17:18PM +0200]:
> > Hi Laurent,
> > 
> > can you still reproduce this? I've just done some tests (using
> > '-efont-fixed-medium-r-normal--16-160-75-75-c-160-iso10646-1'
> > inside uxterm+screen) and my screen gets cleaned properly.
> 
> I'm using screen 4.0.3-0.3+b1 with gnome-terminal and I can reproduce
> the bug locally. I have 4.0.3-4 on a remote machine where I can
> reproduce the bug too (still using gnome-terminal locally).

That was Debian 6 Squeeze's version of screen. I can no more reproduce
the bug on Debian Unstable/Testing, neither inside gnome-terminal
(where the glyphys look fine), nor inside uxterm nor urxvt (which both
only show placeholder squares instead of the expected glyphs).

Can you check if you still have this issue in either Debian Stable or
Unstable/Testing?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#354709: screen corrupts my display when viewing certain spam mails (via mutt)

[Axel Beckert]

Control: tag -1 + moreinfo

Hi Jon,

Jon Dowland wrote:
> On Sun, Sep 23, 2007 at 06:01:27PM +0200, Jan Christoph Nordholz wrote:
> > the UTF is invalid. "Regular" shells and ones inside screen behave
> > differently, presumably caused by that extra layer of indirection
> snip
> > I will try to find the exact cause, but I'm lowering the severity
> > since this only happens with invalid sequences.
> 
> Thanks. I'm vaguely worried that this could be exploited in some
> fashion. At present, the corruption is sufficient to have one row in
> mutt "overwrite" another, so you can delete the wrong mail etc., and
> that's by accident. I'm wondering what could be achieved on purpose...

I could no more reproduce this issue on Debian Sid, neither inside
uxterm nor inside urxvt nor inside gnome-terminal.

Can you check if you still have this issue?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#844408: python-mimeparse: Vcs-Browser and Vcs-Git are broken

[Free Ekanayaka]

Hi Mathias,

On 30 November 2016 at 20:48, Mathias Ertl  wrote:

> Hi,
>
> On 11/26/2016 06:37 PM, Free Ekanayaka wrote:
> >> but email confirmation fails with an undescriptive error
> >> message.
> >
> > Hum, would you mind pasting the error message (even if it seems
> > undescriptive, I could forward it to Alioth admins)?
> >
> > Could you please also try to resend the confirmation email and retry? You
> > can do it from:
> >
> > https://alioth.debian.org/account/pending-resend.php
>
> So I just tried registration again - my first account was "mathiasertl",
> now I tried "mathiasertl2":
>
> 1. I do get a confirmation email.
>

Good.


> 2. On the confirmation page
> (https://alioth.debian.org/account/verify.php?confirm_hash=...) I do not
> really get an error, BUT I see a  element with no
> content. This might just be rendering issue or something, but it might
> also indicate an incorrectly displayed error.
>

I *think* it's just a bug in the HTML that gets generated, but not a "real"
problem.


> 3. When I submit the form, I get the headline "Beendigung mit Fehler" (a
> very bad translation of "an error occured") and the error message "Could
> Not Get User".
>

I tried the whole process myself, and got the same result. However I just
realized that most probably the issue is actually a stupid one: when you
get to this step 3, in the "Login name:" field of the form you have to
append "-guest" to your user name. For example:

Login name:
[mathiasertl-guest]

Password:
[**]

(or "mathiasertl2-guest" if you use the confirmation URL from your second
attempt).

I'm afraid it's not obvious at all, but I hope it will solve the problem.
Please let me know if it is the case.

See also this FAQ:

https://wiki.debian.org/Alioth/FAQ#Why_do_I_have_a_.22-guest.22_suffix_on_my_account_.3F

It doesn't directly explain this, but it's what made me think about it.

Free

Bug#827061: transition: openssl

[Adrian Bunk]

On Wed, Nov 30, 2016 at 07:43:36PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-05 21:59:27 [+0100], Sebastian Andrzej Siewior wrote:
> > I've been playing with ben. I tried a few things and this is the best I
> > was able to achieve [0]:
> > 
> > title = "openssl 1.0";
> > is_affected = .build-depends ~ /libssl1.0-dev/;
> > is_good = .depends ~ /libssl1.0.2/;
> > is_bad = .depends ~ /libssl1.1/;
> > 
> > And
> > 
> > title = "openssl 1.1";
> > is_affected = .build-depends ~ /libssl-dev/;
> > is_good = .depends ~ /libssl1\.1/;
> > is_bad = .depends ~ /libssl1\.0\.2/;
> 
> This does not cover packages which link against 1.0.2 but do not depend
> on libssl-dev (but inherit their dependencies).
> So it is up to you what you setup but something should be done because
> the auto tracker is gone.

Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev"
give a reasonably small superset of all packages that need a binNMU?

> Sebastian

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#640765: screen: -U even with UTF-8 locale results in garbled ncurses apps

[Axel Beckert]

Control: tag -1 + moreinfo

Hi,

Daniel Dickinson wrote:
> Package: screen
> Version: 4.0.3-14
> 
> Use of screen -U results in corrupted screen for ncurses apps, even if locale 
> is UTF-8.

This is a very general description of an issue, so it's difficult to
check if the issue is still present.

Can you check with either a current Debian Stable (i.e. Jessie) or
Debian Testing/Unstable if this is still happening for you.

I know there are still known issues with screen
4.1.0~20120320gitdb59704-7 in Wheezy (currently oldstable) which are
no more present in Debian Unstable (and others which are still there).

Folkert van Heusden wrote:
> I can confirm this problem.
> Directly on the ssh prompt, things run fine. Then when i invoke screen
> and run a program, then all lines are garbled.
> See for example this:
> http://keetweej.vanheusden.com/~folkert/fi-screen.png

Can't access that URL anymore. Can you please sent the picture to the
bug report (if the issue still appears for you in Debian Stable,
Testing or Unstable) instead?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Felipe Sateler]

On 30 November 2016 at 19:20, Michael Biebl  wrote:
> Am 30.11.2016 um 23:12 schrieb Russ Allbery:
>> Anyway, it certainly could be registered in -noninteractive (there was
>> some reason why I didn't do that), but I think the Kerberos ticket cache
>> problem will still be an issue.  Is there some mechanism to convey the
>> value of KRB5CCNAME from the user's login environment to systemd --user?
>
> systemctl --user set-environment
> might be what you are looking for.

`systemctl --user import-environment KRB5CCNAME` might be more
appropriate if this variable should be copied from an already existing
environment.


-- 

Saludos,
Felipe Sateler

Bug#846158: closed by Emilio Pozuelo Monfort <po...@debian.org> (Re: Bug#846158: Xorg: -logfile /dev/null not allowed, prevents xrdp from working)

[Thorsten Glaser]

Debian Bug Tracking System dixit:

>#846158: Xorg: -logfile /dev/null not allowed, prevents xrdp from working
>
>It has been closed by Emilio Pozuelo Monfort .

I agree with it not being RC any more (sorry about that),
but not with closing it (as I still believe -logfile /dev/null
should work and therefore suggest to keep it open with wishlist
severity, or just patch it in some next upload).

Thanks,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#846113: polygraph loses SSL support when compiled with OpenSSL 1.1

[Adrian Bunk]

On Wed, Nov 30, 2016 at 09:43:48PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-30 01:16:09 [+0200], Adrian Bunk wrote:
> > > I though we agreed not to tag this as a patch
> > 
> > Where did I agree to that?
> 
> The last time I pointed it out and you replied that the problem is that
> "two things are tracked in one bug but it can't be cloned".

I definitely did not agree to no longer tagging the RC bugs.

Tagging makes it visible that there is a workaround for the RC issue.

> > > but as a hint what can be
> > > done if the maintainer chooses to stay with 1.0.
> > 
> > Reality in Debian is that a large amount of packages is not well 
> > maintained, polygraph is actually orphaned.
> 
> It received uploads since I orphaned it so I wouldn't say that it is not
> well maintained. However the last upload lost SSL on its way to the
> archive so it is 50-50 :)
> 
> > > Do you expect this bug
> > > to be closed once it switches to libsl1.0-dev?
> > 
> > The thing I do care about is not the patch tag, the thing I do care 
> > about is that we are not losing any packages in stretch due to the
> > whole OpenSSL situation.
> 
> Yes? So you switch to 1.0.2 for a package that is not well maintained
> and we get back here in Buster but we don't lose a package in Stretch?

The problem here is the schedule.

We are now 3 months after the release of 1.1.0, and the same point for 
buster will be 2 years after the release of 1.1.0

For buster 1.1.0 support will for many packages just be present 
automatically from upstream.

> It has low popcon and if it wouldn't be you, then we probably would have
> polygraph without SSL. And looking at my tracker there are more packages
> that depend on libssl-dev and don't link against it.

I did check every single binary package that did depend on libssl1.0.2 
in unstable before libssl-dev was changed to 1.1.0, and that does not
depend on libssl1.0.2 or libssl1.1 now (and I'll run this regularly
in the future until the whole OpenSSL situation is sorted out).

polygraph was the only one I found so far (in addition to the ones Hilko 
already reported) where the dependency was silently and unintentionally 
dropped.

> > A patch tag makes it visible that there is a solution for the RC issue 
> > in stretch.
> 
> I attached a patch which builds against 1.1.0. Lets see if somebody is
> able to test it.

Many of the build-fixes for 1.1.0 you previously provided were AFAIK 
only build-tested and won't get any runtime testing until binNMUs
will happen.

Please make a QA upload with your patch soon, having it in unstable is 
the only realistic chance of getting bug reports in case polygraph does
for some reason not work properly with 1.1.0

> > Who is going to do the uploads for the ~ 100 not well maintained 
> > packages that need to be switched to 1.0.2?
> > 
> > Will you do these?
> If the release team says we have to finish the asap then I will step up
> and try my best.
> 
> > It should be your job for making dual 1.0.2/1.1 work.
> > 
> > Or will you at least sponsor me, if I send you a batch of 100 NMUs and 
> > QA uploads switching packages to 1.0.2?
> 
> If the 100 NMUs are tested and not just switched the build-depends then
> maybe. But as you see here, you don't need special powers to get things
> compiled with 1.1.0.

I have no experience in OpenSSL programming, and I have no desire to 
learn about it any time soon.

> I actually spent more time writing this email than
> the patch. And I would like to avoid switching B-D now and looking at it
> again after the release.

This is the actual root of the conflict between you and me.

There are ~ 100 packages in unstable that need a fix/workaround for
the OpenSSL RC bug, and this must be uploaded during the next 3 weeks
or the package will not be in stretch.

I am really not happy about the prospect that I might end up sending
100 separate "RFS: [NMU, RC]" in a few days for getting this done.

I know that you are mostly interested in 1.1.0, but with 1.1.0 as 
default the part of the archive that is not ready for 1.1.0 must
be manually switched to use 1.0.2

> Sebastian

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#846398: GNOME Software catalog entry missing for Hardinfo

[asciiwolf]

Package: hardinfo
Version: 0.5.1-1.5
Severity: normal

The Hardinfo package cannot be found and/or installed using GNOME Software 
because the hardinfo.desktop file contained in the package is missing a 
"Comment" section that is required by AppStream to generate correct 
metadata.

https://appstream.debian.org/sid/main/issues/hardinfo.html

[Test Case]
1. Open the GNOME Software application.
2. Type "Hardinfo" into the search bar.

Bug#846396: screen: display corruption with bce due to wide character

[Axel Beckert]

Control: tag -1 + confirmed upstream
Control: severity -1 normal

Hi Vincent,

Vincent Lefevre wrote:
> A wide character can corrupt the display, as shown by the following
> example with Mutt. The mailbox file "mbox" and config file "muttrc"
> are attached.

Thanks for the very detailed bug report and the attached examples.

I was able to reproduce this issue inside an urxvt, but not inside an
uxterm — there I just got a question mark inside a filled circle
instead of a wide character.

> I get:
> 
> 
>   1 Nov 30 a@x.invalid (   1) mail 1
> ->2 Nov 30 b@x.invalid (   1) XX mail 2
> 
> i.e. the contents have shifted upwards.
> 
> 5. Type the up arrow.
> 
> Nothing changes, i.e. the arrow still seems to be over mail 2,
> while the current message is mail 1.

And if you type cursor down, you get two arrows, one below the line
with no. 2, i.e. where the line should be, but isn't.

Nevertheless, there is an even partially persistent workaround: Press
Ctrl-L inside mutt and the problem vanishes even until after the next
detaching and reattaching. Only restarting mutt inside the screen
session and then detaching and reattaching again causes it to show up
again. Hence downgrading the severity.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#846384: apt-listbugs: allow to pin bugs manually

[Francesco Poli]

Control: tags -1 + moreinfo


On Wed, 30 Nov 2016 21:31:41 +0100 Martin Steigerwald wrote:

[...]
> Dear Maintainer,

Hello Martin,
thanks for your bug report.

> 
> I manually added:
> 
> merkaba:/etc/apt> cat preferences.d/apt-listbugs 
> Explaination: Pinned manually
> Explaination:   #845785: chromium crashes on certain websites

This is a typo (it should be "Explanation")...

> Package: chromium
> Pin: version *
> Pin-Priority: -3

This would prevent the *installation* of chromium, if your system did
not have it already installed.
On the other hand, if you have version x.y-z installed on your system
and you want to prevent the upgrade to newer versions, you should write:

  Package: chromium
  Pin: version x.y-z
  Pin-Priority: 3

> 
> cause Michael downgraded the severity of that bug to "normal" and thus from
> what I understand apt-listbug would not protect my system from upgrading to
> the newer broken chromium version in unstable.

Well, what will happen is that apt-listbugs will remove the pin, since
the bug that you fear was downgraded to a severity ("normal") that
apt-listbugs ignores.

To avoid the automatic pin removal, you have two possible strategies
(that I can think of):

 (a) you may include "normal" in the list of severities to be considered
by apt-listbugs (see option AptListbugs::Severities
in /etc/apt/apt.conf.d/10apt-listbugs ; this option may for instance be
set to "critical,grave,serious,important,normal")

 (b) you may create a manual pin outside of apt-listbugs jurisdiction
(without Explanation fields and in files other
than /etc/apt/preferences.d/apt-listbugs ; for instance in
/etc/apt/preferences.d/chromium-pin )

If you follow strategy (a), apt-listbugs will warn you about all normal
bugs, and there will probably be several of them for each package to be
installed/upgraded. Maybe a bit inconvenient...

If instead you follow strategy (b), apt-listbugs will never touch your
pin and you will have to manage it by hand (that is to say, you'll have
to keep an eye on the bug and decide when the pin should be manually
removed). 

> 
> I do hope that apt-listbugs will automatically remove it once the bug is
> fixed,

I am afraid apt-listbugs will remove the pin on the next run of its
cron daily job...

> but I also would like a way to manually pin a bug from command line
> in order to avoid having to make up an entry like above myself.

I think this would be of very little usefulness, because of the above
explained facts.

If you configure apt-listbugs to also care about bugs of "normal"
severity, everything will work as usual, with the only downside that
you will see lots of bugs at each installation/upgrade attempt.

If you instead decide to manage the pin by hand, you may as well create
it by hand... After all, it's not that hard, once you understand the
meaning of the fields!

> 
> I didn´t see a way to do it after looking at the manpage of apt-listbugs
> tough.

Indeed, apt-listbugs is not intended to be an on-demand package pin
generator. It will generate pins for packages that would introduce
bugs (of one of the configured severities) into your system.

I hope this clarifies.
Please let me know.
 

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp1y_Y_1G524.pgp
Description: PGP signature

Bug#845193: [Pkg-openssl-devel] Bug#845193: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Kurt Roeckx]

On Wed, Nov 30, 2016 at 11:43:13PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-30 21:22:38 [+], Thorsten Glaser wrote:
> > Kurt Roeckx dixit:
> > 
> > >But the errors I've always been seeing is a segfault during the
> > >tests, and I have no idea what that is about.
> > 
> > That didn't happen for me, but I found a wrong codegen bug in a
> > testsuite recently (probably not the cause here), we had kernel
> > issues (4.7 is broken, 4.8 is mostly ok though) and are still
> > trying to figure out libc issues that differ depending on CPU
> > model (stuff like AMD vs. Intel)… this is all a minefield.
> 
> just deboostraped x32 and have:
> ii dpkg  1.18.15 x32 Debian package management system
> ii gcc-6 6.2.1-5 x32 GNU C compiler
> 
> installed. I managed to rebuild 1.1.0c-2_x32. What do I miss here? 

That 1.1.0 works and 1.0.2 fails.


Kurt

Bug#845193: [Pkg-openssl-devel] Bug#845193: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Sebastian Andrzej Siewior]

On 2016-11-30 21:22:38 [+], Thorsten Glaser wrote:
> Kurt Roeckx dixit:
> 
> >But the errors I've always been seeing is a segfault during the
> >tests, and I have no idea what that is about.
> 
> That didn't happen for me, but I found a wrong codegen bug in a
> testsuite recently (probably not the cause here), we had kernel
> issues (4.7 is broken, 4.8 is mostly ok though) and are still
> trying to figure out libc issues that differ depending on CPU
> model (stuff like AMD vs. Intel)… this is all a minefield.

just deboostraped x32 and have:
ii dpkg  1.18.15 x32 Debian package management system
ii gcc-6 6.2.1-5 x32 GNU C compiler

installed. I managed to rebuild 1.1.0c-2_x32. What do I miss here? 

> bye,
> //mirabilos

Sebastian

Bug#846397: winff: Desktop and icon files missing

[asciiwolf]

Package: winff
Version: 1.5.5-1
Severity: normal

The WinFF package does not contain any desktop and icon files. Because of 
that, WinFF cannot be launched from the desktop menu and cannot be found/
installed using GNOME Software.

Bug#845425: Tomcat security update

[Markus Koschany]

On 26.11.2016 17:00, Markus Koschany wrote:
> On 22.11.2016 11:17, Emmanuel Bourg wrote:
>> Three more CVEs have just been announced, a bit more serious this time :
>>  CVE-2016-6816 Apache Tomcat Information Disclosure
>>  CVE-2016-8735 Apache Tomcat Remote Code Execution
>>  CVE-2016-6817 Apache Tomcat Denial of Service
>>
>> I'll prepare the stable and jessie-backports updates for tomcat7 and
>> tomcat8 today. testing/unstable already have the fixed versions.
>>
> 
> Hi,
> 
> I have pushed the updates for Wheezy which is only affected by
> CVE-2016-6816 and CVE-2016-8735. Could you isolate the bug in
> CVE-2016-6797.patch? What exactly was missing from ResourceLinkFactory.java?
> 

Since I haven't heard anything yet I'm going to backport
ResourceLinkFactory.java as a precaution and release the security
announcement tomorrow.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Michael Biebl]

Am 30.11.2016 um 23:20 schrieb Michael Biebl:
> Am 30.11.2016 um 23:12 schrieb Russ Allbery:
>> It's a little weird to me that systemd --user loads
>> common-session-interactive and then apparently starts xterms in this
>> particular situation.  Those are kind of interactive.  But presumably it's
>> assuming xterm will open its own interactive session?
> 
> We originally used common-session.
> See #739676 for why this was changed

Fwiw, the processes started by systemd --user are not really
interactive. See dconf for example.
xterm is not started as a user service. I assume you meant the
gnome-terminal-server.service user service, which is the background
process and for which gnome-terminal is a frontend.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#845949: guake: depends on python-gnome2 which deprecated

[Daniel Echeverry]

forwarded 845949 https://github.com/Guake/guake/issues/863
thanks

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#845105: mk-freebsd: bsd.cpu.mk sets -mfloat-abi=softfp on armhf

[Steven Chamberlain]

Adrian Bunk wrote:
> The root cause of this ctfutils FTBFS is that -mfloat-abi=softfp
> is passed to the compiler on armhf, which seems to come from
> /usr/share/mk-freebsd/bsd.cpu.mk

Thanks for pointing that out!

All arm* architectures were being mapped to the FreeBSD MACHINE_TYPE
"armv6" which targets the soft-float ABI.

I've defined a new MACHINE_TYPE "armv6hf" and mapped armhf to that
instead (as well as kfreebsd-armhf, for when it exists).

ctfutils was given back and rebuild successfully after this change.
armel should work as before.  We don't yet have arm64 support;  that
will happen in time.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Michael Biebl]

Am 30.11.2016 um 23:12 schrieb Russ Allbery:
> It's a little weird to me that systemd --user loads
> common-session-interactive and then apparently starts xterms in this
> particular situation.  Those are kind of interactive.  But presumably it's
> assuming xterm will open its own interactive session?

We originally used common-session.
See #739676 for why this was changed

> Anyway, it certainly could be registered in -noninteractive (there was
> some reason why I didn't do that), but I think the Kerberos ticket cache
> problem will still be an issue.  Is there some mechanism to convey the
> value of KRB5CCNAME from the user's login environment to systemd --user?

systemctl --user set-environment
might be what you are looking for.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Russ Allbery]

Felipe Sateler  writes:
> On 30 November 2016 at 17:30, Russ Allbery  wrote:

>> I don't suppose there's any way to get systemd --user to open a PAM
>> session on behalf of the user before starting to run programs?  That
>> would probably solve the problem (although there may still be some
>> complications in making sure it has correct visibility to the Kerberos
>> ticket cache).

> systemd --user does open a pam session (with the systemd-user name).
> Maybe the problem is that libpam-afs-session (is this the right
> module?) registers itself in the common-session include file but
> systemd-user loads only common-session-noninteractive ?

That's the right module.  Hm, yeah, it's probably a combination of that
plus the fact that it doesn't know how to find the Kerberos ticket cache
and therefore can't get a token.

It's a little weird to me that systemd --user loads
common-session-interactive and then apparently starts xterms in this
particular situation.  Those are kind of interactive.  But presumably it's
assuming xterm will open its own interactive session?

Anyway, it certainly could be registered in -noninteractive (there was
some reason why I didn't do that), but I think the Kerberos ticket cache
problem will still be an issue.  Is there some mechanism to convey the
value of KRB5CCNAME from the user's login environment to systemd --user?

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

Bug#846395: dpkg: man page is wrong about force-confmiss option

[Sven Joachim]

Package: dpkg
Version: 1.16.4
Severity: minor

Commit 4bcc6b8e0a587b432b145fafa642674607cd introduced an error in
the description of the force-confmiss option.  This option does, as
mentioned by "dpkg --force-help", always install missing conffiles, and
has done so since its introduction in dpkg 1.4.1.15 back in 1999.

Bug#846396: screen: display corruption with bce due to wide character

[Vincent Lefevre]

Package: screen
Version: 4.4.0-6
Severity: important

A wide character can corrupt the display, as shown by the following
example with Mutt. The mailbox file "mbox" and config file "muttrc"
are attached.

1. Start "screen" with "defbce on" in the .screenrc file.

2. Open this mailbox with: mutt -F muttrc -f mbox

On a 60-column terminal, I get:


q:Quit  d:Del  u:Undel  s:Save  m:Mail  r:Reply  g:Group  ?:
  1 Nov 30 a@x.invalid (   1) mail 1
->2 Nov 30 b@x.invalid (   1) XX mail 2

where XX (which corresponds to U+1F534 LARGE RED CIRCLE) depends
on the terminal, but takes 2 columns.

3. Detach the screen session.

4. Reattach the screen session.

I get:


  1 Nov 30 a@x.invalid (   1) mail 1
->2 Nov 30 b@x.invalid (   1) XX mail 2

i.e. the contents have shifted upwards.

5. Type the up arrow.

Nothing changes, i.e. the arrow still seems to be over mail 2,
while the current message is mail 1.

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 screen depends on:
ii  libc6  2.24-7
ii  libpam0g   1.1.8-3.3
ii  libtinfo5  6.0+20160917-1

screen recommends no packages.

Versions of packages screen suggests:
pn  byobu | screenie | iselect  
ii  ncurses-term6.0+20160917-1

-- no debconf information
>From a@x.invalid Wed Nov 30 19:59:33 2016
From: a@x.invalid
Subject: mail 1
Date: Wed, 30 Nov 2016 19:58:44 +0100
MIME-Version: 1.0
Content-Type: text/plain
Status: RO

mail 1

>From b@x.invalid Wed Nov 30 20:06:58 2016
From: b@x.invalid
Date: Wed, 30 Nov 2016 20:06:53 +0100 (CET)
Subject: =?UTF-8?Q?=F0=9F=94=B4_mail_2?=
MIME-Version: 1.0
Content-Type: text/plain
Status: RO

mail 2

set arrow_cursor

Bug#846394: boinc-manager: Boincmgr fails for mismatch between the program and library build versions

[Aldo Maggi]

Package: boinc-manager
Version: 7.6.33+dfsg-5exp1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

for some reasons some days ago I started boincmgr from the xterminal and
a warning appeared:
21:51:07: Warning: Mismatch between the program and library build
versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx
containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
containers,compatible with 2.8).

but it started anyway, yesterday evening I updated my system and now,
when I try to launch boincmgr it gives the same error but it doesn't
start.
This afternoon I've decided to file a bug report and reportbug suggested
to upgrade boinc-manager to the version which is in experimental, I
followed the advice but with no avail.

Thank you,
Aldo


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

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

Versions of packages boinc-manager depends on:
ii  boinc-client 7.6.33+dfsg-5
ii  libboinc77.6.33+dfsg-5
ii  libc62.24-5
ii  libgcc1  1:6.2.0-13
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-1
ii  libnotify4   0.7.7-1
ii  libsqlite3-0 3.15.1-1
ii  libstdc++6   6.2.0-13
ii  libwxbase3.0-0v5 3.0.2+dfsg-2
ii  libwxgtk-webview3.0-0v5  3.0.2+dfsg-2
ii  libwxgtk3.0-0v5  3.0.2+dfsg-2

boinc-manager recommends no packages.

Versions of packages boinc-manager suggests:
ii  libgl1-mesa-glx  12.0.4-2
ii  libxt6   1:1.1.5-1

-- no debconf information

Bug#846301: live-wrapper: builds should honour SOURCE_DATE_EPOCH

[Chris Lamb]

[Adding reproduble-builds@ to CC]

Hi,

> live-wrapper: builds should honour SOURCE_DATE_EPOCH

Worth looking at are (at least):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831379
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832998

There are also some patches of mine in the Tails repository:

  https://git-tails.immerda.ch/live-build/log/?h=tails%2Fdebian-old-2.0


Regards,

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

Bug#846393: Build aspell-en-huge/insane from scowl? more integration of iamerican-* with scowl?

[Don Armstrong]

Package: scowl
Severity: minor
Control: affects -1 aspell-en iamerican-insane iamerican-huge

I found myself getting annoyed that aspell didn't have very large
dictionaries (-huge and/or -insane) available, and then realized that
aspell-en was built pretty much directly from scowl.

Would it be reasonable for scowl to build and provide aspell-en-huge and
aspell-en-insane? Or possibly for aspell-en and iamerican-insane to be
more tightly coupled with scowl?

I'm totally flexible with whatever decision ends up happening; I'd just
like a larger default dictionary because I routinely use weird words.

Creating this bug to track the discussion.

-- 
Don Armstrong  https://www.donarmstrong.com

Let the victors, when they come,
When the forts of folly fall
Find thy body by the wall!
 -- Matthew Arnold

Bug#846025: FTBFS randomly (segfaults during build)

[Damyan Ivanov]

Control: clone -1 -2
Control: retitle -2 random crashes when browsing employee.fdb during build
Control: severity -2 important
Control: close -1 3.0.1.32609.ds4-11

-=| Santiago Vila, 28.11.2016 16:11:28 +0100 |=-
> retitle 846025 firebird3.0: FTBFS randomly (segfaults during build)
> thanks
> 
> On Mon, Nov 28, 2016 at 01:50:42PM +, Damyan Ivanov wrote:
> 
> > Santiago, can you still reproduce the crash on current stretch?
> 
> Yes (see attach).
> 
> The failure happens randomly. I said it in the previous email but I
> forgot to put it clearly in the subject. Retitling accordingly.
> 
> If you are trying to reproduce this yourself, please try to build it a
> lot of times.

Did that for two days. One in a stretch VM (~200 attempts), the other 
in a stretch sbuild chroot on a jessie VM (~60 attempts) -- all 
successful.

Regardless, I will just make that part non fatal in -11 via ||true 
since I believe it is not indicative of a real problem.

Cloning a severity:important bug for future reference.

-- Damyan


signature.asc
Description: Digital signature

Bug#846366: ITP: bcc -- Command line tools for BPF Compiler Collection (BCC)

[Christian Seiler]

On 11/30/2016 10:32 PM, Karsten Merker wrote:
> On Thu, Dec 01, 2016 at 12:56:14AM +0530, Ritesh Raj Sarraf wrote:
>> On Wed, 2016-11-30 at 20:05 +0100, Karsten Merker wrote:
>>> bcc is a package (and executable) name that is already in use for
>>> another program in Debian. From https://packages.debian.org/sid/bcc:
>>
>> I'm aware of it. bcc is an already packaged binary package. It
>> build from source package: linux86
>>
>> For this package, I've tried to be close to what upstream has already named.
>> So, for Debian, only the source package name is: bcc.
>> The binary packages are:
>>
>> rrs@learner:~/rrs-home/Community/Packaging/bcc (master)$ grep Package: 
>> debian/control 
>> Package: libbcc
>> Package: libbcc-dev
>> Package: python-bcc
>> Package: bcc-tools
>> Package: bcc-lua
>> 2016-12-01 / 00:52:49 ♒♒♒  ☺  
>>
>> Does it make sense ?
>>
>> If you have suggestions, please mention them, because it'll be
>> easier to make the name changes now.
> 
> many thanks for the explanation, so from a technical point of
> view there is no package naming conflict, although it is somewhat
> counter-intuitive to end up with a source-package "bcc" and a
> binary-package "bcc" where the latter isn't built from the former
> but instead contains a completely different application.

Maybe the new source package could be named bpf-bcc? That way there
would be no confusion with respect to bin:bcc vs. src:bcc, and the
source package name is still quite short, yet descriptive. Just a
suggestion.

Regards,
Christian

Bug#846391: munin-plugins-core: if_ plugin doesn't work for virtio cards

[Aurelien Jarno]

Package: munin-plugins-core
Version: 2.0.27-1
Severity: normal
Tags: upstream patch

Dear Maintainer,

Interface speed doesn't make sense for virtio devices. Therefore the
kernel used to report an "Invalid argument" error, which was ignored by
the if_ plugin. On recent kernel though, the -1 speed is returned
instead. This causes the if_ plugin to report a negative up.max and
down.max, which in turns causes munin-update to fail to create the
corresponding rrd file.

This has been fixed upstream by the two following commits:

|  commit f982751aefe5fa4c419c4b0859dde2adac908e40
|  Author: Kim B. Heino 
|  Date:   Fri Dec 11 13:24:26 2015 +0200
|
|  if_: check for non-empty and >0 before reporting speed (thanks to ssm)

|  commit 78c3c3aaf8f358f065005ca6b1dcca5d65a34646
|  Author: Kim B. Heino 
|  Date:   Sun Dec 6 11:49:45 2015 +0200
|
|  if_: /sys/class/net/ reports speed 0 for some devices

Would it be possible to apply them?

Thanks,
Aurelien

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

Kernel: Linux 4.8.0-1-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 munin-plugins-core depends on:
ii  munin-common  2.0.27-1
ii  perl  5.24.1~rc3-3

Versions of packages munin-plugins-core recommends:
pn  libnet-snmp-perl  

Versions of packages munin-plugins-core suggests:
pn  conntrack
pn  libcache-cache-perl  
pn  libdbd-mysql-perl
ii  libnet-dns-perl  1.06-1
pn  libnet-netmask-perl  
pn  libnet-telnet-perl   
pn  libxml-parser-perl   
ii  python   2.7.11-2
pn  ruby | ruby-interpreter  

-- no debconf information

Bug#846390: openjpeg2: out of date debian/README.source

[Raphael Geissert]

Source: openjpeg2
Version: 2.1.2-1
Severity: minor

Hi,

The README.source file recommends installing the now-removed openjpeg 1.x 
packages.

Perhaps it would be more useful to point the reader to the test suite, how to 
obtain the test data and how to run it.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Bug#845788: plasma-desktop: Incorrect values in ~/.config/plasma*

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 30 de noviembre de 2016 18:01:12 ART Dmitry Shachnev wrote:
> ¡Hola Maximiliano!
> 
> On Tue, Nov 29, 2016 at 02:43:44PM +0100, Maximiliano Curia wrote:
> > Mmh, I see the en_NL option in the formats kcm, which isn't a valid
> > locales
> > value. This seems to be a qt issue, the combos are filled calling:
> > QList allLocales = QLocale::matchingLocales(QLocale::AnyLanguage,
> > QLocale::AnyScript, QLocale::AnyCountry);
> FWIW Qt does not maintain its own locales database, it uses a C++ file
> generated from CLDR data instead. It looks like en_NL was added in CLDR v29.
> 
> See:
> 
> - https://code.qt.io/cgit/qt/qtbase.git/commit?id=eb26f2b19babf8cd
>   (in this commit the English/Latin/Netherlands line was added)
> 
> -
> http://www.unicode.org/cldr/charts/latest/supplemental/territory_language_i
> nformation.html#NL
> 
> (This is just a side note, I do not yet reject this bug.)

Nor do I. Moreover I just digged out that locales are generated using 
src:qtbase/util/local_database

I don't know exactly hw to use it, but we might regenerate the locale database 
at build time with Debian's db, if that helps at all.


-- 
"Los promotores del software privativo demonizan algo tan básico y ético como
el hecho de compartir imponiendo términos como el de 'pirata'. Equiparan
ayudar al prójimo con atacar barcos. Cuando me preguntan qué pienso de la
piratería musical e informática digo que atacar barcos es muy malo y,
que yo sepa, los piratas no usan computadoras.”
  Richard Stallman, 05/11/2008, anexo de la Cámara de Diputados, Argentina

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Paul Gevers]

Control: tags 845504 pending patch

Hi,

On 29-11-16 20:55, Abou Al Montacir wrote:
> The dependency on linker package could be fixed easily as you said.

But how should we do this in reality?
Depends:  binutils | binutils-aarch64-linux-gnu |
binutils-alpha-linux-gnu |  etc?

> For the /etc/fpc.cfg, this could be solved by adding liens like:
> 
> # path to the gcclib
> 
> #ifdef cpui386
> 
> -Fl/usr/lib/gcc/x86_64-linux-gnu/6/32
> 
> #endif
> 
> #ifdef cpux86_64
> 
> -Fl/usr/lib/gcc/x86_64-linux-gnu/6
> 
> #endif

Is this instead of what we now add in fp-compiler.postinst? (By the way,
shouldn't we be using ucf for that there?)

> The file itself is installed by an arch independent package polled by
> all fp-compiler packages. This way we have a platform config file

You mean arch-dependent, right? fp-compiler-3.0.0 is now creating and
installing that. Should we revise this then?

> Instead of writing a tool to hack all this, I'd propose you submit
> patches and join the maintain team.

Yes, you are welcome.

@Ben, do you think the multi-arch hinter on the tracker is correct
(action needed section of: https://tracker.debian.org/pkg/fpc)

Paul
PS: I'll upload soon for the other bug and stuff that is already
pending. Would be nice if we could get further on this bug as well.



signature.asc
Description: OpenPGP digital signature

Bug#846389: plasma-workspace: To every moment it cracks the plasmashell.

[Santiago José López Borrazás]

Package: plasma-workspace
Version: 4:5.8.4-1
Severity: important

Dear Maintainer,

It does not give me a lot of information of this bug, but advance that,
occasionally, on having gone from one window to other one, the plasmashell
cracks.

The curious thing is, that I have a script that for from time to time I
have to kill the plasmashell as it continues:

#!/bin/sh
killall plasmashell &
sleep 5
plasmashell --shut-up &

In the previous version of the plasma - workspace this was not happening to
me.

Although, it is something rare that does not show me in console any
reference to be able to copy and stick to give information. The case is,
that when there changes just the title of the window (the bar of title), it
chats without reason and I have to kill it to be able to touch with the
cursor. But, I cannot do the rapid work.

Something says to me that it is rather, a treatment error that another
thing.

Thanks.

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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.10.14-1
ii  frameworkintegration 5.28.0-1
ii  gdb  7.11.1-2+b1
ii  iso-codes3.71-1
ii  kactivitymanagerd5.8.4-1
ii  kde-cli-tools4:5.8.4-1
ii  kded55.28.0-1
ii  kinit5.28.0-1
ii  kio  5.28.0-1
ii  kpackagetool55.28.1-1
ii  libc62.24-7
ii  libcln6  1.3.4-2
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-1
ii  libgcc1  1:6.2.1-5
ii  libgps22 3.16-4
ii  libice6  2:1.0.9-1+b1
ii  libkf5activities55.28.0-1
ii  libkf5auth5  5.28.0-1
ii  libkf5baloo5 5.28.0-1
ii  libkf5bookmarks5 5.28.0-1
ii  libkf5calendarevents55.28.0-1
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-1
ii  libkf5configgui5 5.28.0-1
ii  libkf5configwidgets5 5.28.0-1
ii  libkf5coreaddons55.28.0-1
ii  libkf5crash5 5.28.0-1
ii  libkf5dbusaddons55.28.0-1
ii  libkf5declarative5   5.28.0-1
ii  libkf5globalaccel-bin5.28.0-1
ii  libkf5globalaccel5   5.28.0-1
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5holidays5  16.04.2-1
ii  libkf5i18n5  5.28.0-1
ii  libkf5iconthemes55.28.0-1
ii  libkf5idletime5  5.28.0-1
ii  libkf5itemviews5 5.28.0-1
ii  libkf5jobwidgets55.28.0-1
ii  libkf5js55.28.0-1
ii  libkf5jsembed5   5.28.0-1
ii  libkf5kdelibs4support5   5.28.0-1
ii  libkf5kiocore5   5.28.0-1
ii  libkf5kiofilewidgets55.28.0-1
ii  libkf5kiowidgets55.28.0-1
ii  libkf5networkmanagerqt6  5.28.0-1
ii  libkf5newstuff5  5.28.0-1
ii  libkf5notifications5 5.28.0-1
ii  libkf5notifyconfig5  5.28.0-1
ii  libkf5package5   5.28.1-1
ii  libkf5plasma55.28.0-1
ii  libkf5plasmaquick5   5.28.0-1
ii  libkf5quickaddons5   5.28.0-1
ii  libkf5runner55.28.0-1
ii  libkf5service-bin5.28.0-1
ii  libkf5service5   5.28.0-1
ii  libkf5solid5 5.28.0-1
ii  libkf5texteditor55.28.0-1
ii  libkf5textwidgets5   5.28.0-1
ii  libkf5wallet-bin 5.28.0-1
ii  libkf5wallet55.28.0-1
ii  libkf5waylandclient5 4:5.28.0-1
ii  libkf5widgetsaddons5 5.28.0-1
ii  libkf5windowsystem5  5.28.0-1
ii  libkf5xmlgui55.28.0-1
ii  libkf5xmlrpcclient5  5.28.0-1
ii  libkscreenlocker55.8.4-1
ii  libksgrd74:5.8.4-1
ii  libkworkspace5-5

Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl

[Thorsten Glaser]

Kurt Roeckx dixit:

>But the errors I've always been seeing is a segfault during the
>tests, and I have no idea what that is about.

That didn't happen for me, but I found a wrong codegen bug in a
testsuite recently (probably not the cause here), we had kernel
issues (4.7 is broken, 4.8 is mostly ok though) and are still
trying to figure out libc issues that differ depending on CPU
model (stuff like AMD vs. Intel)… this is all a minefield.

bye,
//mirabilos
-- 
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh").  [aus dasr]

Bug#846388: gitlab: install (postinst?) fails

[cloos]

Package: gitlab
Version: 8.13.6+dfsg1-3
Severity: normal

Apt-get install gitlab fails with:

Verifying we have all required libraries...
Could not find gem 'grape-entity (~> 0.5.0)' in any of the gem sources listed in
your Gemfile or available on this machine.
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 7
Processing triggers for libc-bin (2.24-7) ...
Errors were encountered while processing:
 gitlab
E: Sub-process /usr/bin/dpkg returned an error code (1)


The installed version of ruby-grape-entity is 0.6.0-1.

[Running reportbug on a different sid box; below info edited to match the 
actual gitlab box.]
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Felipe Sateler]

On 30 November 2016 at 17:30, Russ Allbery  wrote:
>
> Michael Biebl  writes:
>
> > Should we assign this to openafs? Is there something which needs to be
> > done on the systemd side, and if so, further information and help would
> > be welcome.
>
> I don't suppose there's any way to get systemd --user to open a PAM
> session on behalf of the user before starting to run programs?  That would
> probably solve the problem (although there may still be some complications
> in making sure it has correct visibility to the Kerberos ticket cache).

systemd --user does open a pam session (with the systemd-user name).
Maybe the problem is that libpam-afs-session (is this the right
module?) registers itself in the common-session include file but
systemd-user loads only common-session-noninteractive ?


-- 

Saludos,
Felipe Sateler

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Michael Biebl]

Am 30.11.2016 um 21:42 schrieb Benjamin Kaduk:
> On Wed, Nov 30, 2016 at 09:11:58PM +0100, Michael Biebl wrote:
>> Am 30.11.2016 um 20:01 schrieb Dirk Heinrichs:
>>
>> Afaics, this will affect any service which was started as a systemd
>> --user service. dbus is just one of them.
> 
> I have not absorbed the full report yet, but wanted to note that Dave Botsch 
> (IIRC)
> put together some notes on using AFS with systemd --user at:
> https://docs.google.com/document/d/1P27fP1uj-C8QdxDKMKtI-Qh00c5_9zJa4YHjnpB6ODM/pub

Just a quick side-note while reading that document:

> Unfortunately, to get the service to start when you log in, you need to 
> set up systemd --user directories and symlinks.  
> 
> Create a $HOME/.config/systemd/user/default.target.wants directory
> Create a symlink in that directory to /etc/systemd/user/aklog.service

You can just add a

[Install]
WantedBy=default.target

to the service file and then run systemctl enable --user aklog.service
This will make sure to create all necessary directories and symlinks.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#846387: psmisc: prtstat man page has two OPTIONS sections

[David A. Parker]

Package: psmisc
Version: 22.21-2
Severity: minor

The man page for prtstat(1) contains two identical OPTIONS sections.

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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 psmisc depends on:
ii  libc6  2.19-18+deb8u4
ii  libtinfo5  5.9+20140913-1+b1

psmisc recommends no packages.

psmisc suggests no packages.

-- no debconf information