Bug#843958: RFP: laika-boss -- object scanner and intrusion detection system

[Arturo Borrero Gonzalez]

Package: wnpp
Severity: wishlist

* Package name: laika-boss
  Version : 0.1
  Upstream Author : Lockheed Martin Corporation
* URL : https://github.com/lmco/laikaboss
* License : Apache 2.0
  Programming Lang: Python
  Description : laika is an object scanner and intrusion detection system

Laika BOSS: Object Scanning System
Whitepaper can be found:
  
http://lockheedmartin.com/content/dam/lockheed/data/isgs/documents/LaikaBOSS%20Whitepaper.pdf

Laika is an object scanner and intrusion detection system that strives to 
achieve the following goals:
 * Scalable
- Work across multiple systems
- High volume of input from many sources
 * Flexible
- Modular architecture
- Highly configurable dispatching and dispositioning logic
- Tactical code insertion (without needing restart)
 * Verbose
- Generate more metadata than you know what to do with

Each scan does three main actions on each object:

* Extract child objects
 - Some objects are archives, some are wrappers, and others are obfuscators. 
Whatever the case may be, find children objects that should be scanned 
recursively by extracting them out.

* Mark flags
 - Flags provide a means for dispositioning objects and for pivoting on future 
analysis.

* Add metadata
 - Discover as much information describing the object for future analysis.


Laika is composed of the following pieces:

* Framework (laika.py)
 - This is the core of Laika BOSS. It includes the object model and the 
dispatching logic.

* laikad
 - This piece contains the code for running Laika as a deamonized, networked 
service using the ZeroMQ broker.

* cloudscan
 - A command-line client for sending a local system file to a running service 
instance of Laika (laikad).

* modules
 - The scan itself is composed of the running of modules. Each module is its 
own program that focuses on a particular sub-component of the overall file 
analysis.

Bug#843957: [node-glob] Please update to 7.0.0

[Sruthi Chandran]

Package: node-glob
Version: 4.0.5-1
Severity: wishlist

--- Please enter the report below this line. ---
Please update to version 7.0.0. It is a dependency for Grunt

--- System information. ---
Architecture: amd64
Kernel: Linux 4.8.0-1-amd64

Debian Release: stretch/sid
500 unstable debian.sil.at

--- Package information. ---
Depends (Version) | Installed
==-+-
nodejs | 4.6.1~dfsg-1
node-minimatch (>= 0.2.11) | 3.0.3-1
node-inherits (>= 2) | 2.0.1-3
node-once | 1.4.0-2


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#811862: fixed in libqalculate 0.9.10-1

[Vincent Legout]

Hi Emilio,

On Sun, Nov 06, 2016 at 04:24:29PM +0100, Emilio Pozuelo Monfort wrote :
> Hi,
> 
> On Thu, 08 Sep 2016 07:00:09 + Vincent Legout  wrote:
> >  libqalculate (0.9.10-1) experimental; urgency=medium
> >  .
> >* Upload to experimental
> >* New upstream version
> >  - Fix FTBFS with gcc 6 (Closes: #811862)
> 
> This is still unfixed in unstable. Any plans for a fix there?

I apologize, I was planning to transition this new package to unstable but
didn't find the time to do so before the transition freeze. I guess it's now too
late for that, and Matthias uploaded a fix for this bug in the meantime (thanks
for that).

Thanks for your work,

Vincent

Bug#843956: override: gitlab:section:web

[Pirate Praveen]

package: ftp.debian.org
control: block 832224 by -1



signature.asc
Description: OpenPGP digital signature

Bug#833245: openssl-blacklist: Uses obsolete compressor for .deb data.tar member

[Moritz Muehlenhoff]

On Tue, Aug 02, 2016 at 04:05:45AM +0200, Guillem Jover wrote:
> Source: openssl-blacklist
> Source-Version: 0.5-3
> Severity: important
> User: debian-d...@lists.debian.org
> Usertags: dpkg-obsolete-deb-data-tar-compressor
> 
> Hi!
> 
> This source package builds one or more binary packages using the
> deprecated compressor bzip2. The default has been xz for a while now
> which should usually compress better than bzip2. If instead you'd like
> speed then switch to use gzip.
> 
> Using a deprecated compressor when building binary packages will
> become an error in the near future. Please update the packages.
> 
> See also .

Instead of fixing this, should we just remove the package? It's been almost
a decade since CVE-2008-0166 happened, I don't think it serves any purpose
any longer.

Cheers,
Moritz

Bug#843955: ITP: node-grunt-legacy-log -- The Grunt 0.4.x logger

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-grunt-legacy-log
  Version : 1.0.0
  Upstream Author : "Cowboy" Ben Alman (http://benalman.com/)
* URL : http://gruntjs.com/
* License : Expat
  Programming Lang: JavaScript
  Description : The Grunt 0.4.x logger

Bug#841096: espresso: FTBFS (make install fails)

[Graham Inggs]

Hi Santiago

On 9 November 2016 at 18:38, Santiago Vila  wrote:
> There are severl problems here:
>
> * The directory "test-suite" should be excluded but it isn't.
>
> * The output of "find" depends on filesystem ordering, it may be anything.
>
> * The "cp" commands are concatenated using ";" and not "&&", which means
> an intermediate "cp" command may fail as far as it's not the last one.
>
> * If we are unlucky enough that "test-suite" is the last one, the whole
> "install" target will fail, because copying a directory gives an error.

Thank you for your perseverance with this bug.

> The attached patch should probably work, it just ensures that the
> "test-suite" directory is excluded from the output of "find".
>
> I think it would be very good if you could forward this upstream so
> that they fix the Makefile.

Thanks also for the patch!

Regards
Graham

Bug#799781: found the upstream commit

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tag -1 +pending


Queued into jessie branch of git repo. Will be part of next Stable Jessie
upload.

Thanks.

On Fri, 2016-11-11 at 12:33 +0530, Ritesh Raj Sarraf wrote:
> On Fri, 2016-11-11 at 11:58 +1100, Vincent McIntyre wrote:
> > On Sun, 27 Sep 2015 20:04:06 +0530, Ritesh Raj Sarraf wrote:
> > 
> > > I have a problem here.
> > > 
> > > The fix, that you mentioned for the Shared Lock, does not seem to be
> > > committed upstream. Neither master, nor Hannes's suse-fixes branch.
> > 
> > It is there, please see
> 
> Yes. Hannes pushed his entire branch recently. This should also go into the
> stable update.
- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlglcVAACgkQpjpYo/Lh
dWmqqhAAsfBwQxmfZELjcf2WIaqv39R559H2EgDlKXh7QcavBgHuywu3MpusunQP
gGZJUzeWV4+WMsTEgVKpiJ/ZdLzkI8CpJpN4DOgCZX8ErdsbuSxNmjmLGIpHyCfZ
2J9jmy2mAdCN5v0a/I1IO813Zdp/QWpR/242nbQ6mYr58SG+PcYmWwE/1CU/WMgO
8LskR/XX35wGDwVRH1ucr6qM5YRNT6Dy1YeiSfs6rqGq/wiNP+wo82XfayfpMwnl
Zldp5nHim7PMJuEQGi8ZM71ID2K23qlFCYNtpUS6WKzlNyf44FU+kLXKor664UIg
ozpwDLVKs80ZaWTMJWUXuVdL/yolIGF1hmTXyynxYeimTP6e12smRmcjS0mXsHF3
H0dQt7vv9/kaR8MYh9Zyi0smhE4XSH4fFpihMkiEWAS2wf9Cja+7CTFLSFJBurFx
IAwo1QlhyvIcwS5CsTEs3ZXfKRYufH2Hd4j8ykI99SYwMNku8lq5Ix8Lk/X7pESx
TSfF1S5hgp1mUx8L8SHJG++84OaE/H8fr6teVh0dCIQK9C5B1PinVk0yHIbka0bq
8mA/8K+nXf/mUSder4gsSnKys36LAXwlw3Fr28vyK2WZJdKt9QLL7ixcy9p/kMYB
fkHFJcCXKJMh6xo7p1JgWILcHbWzLuB6edx4GYhnP2Wm4FsFfqs=
=rAaC
-END PGP SIGNATURE-

Bug#831448: gitlab: fails to install database

[Pirate Praveen]

Control: reassign -1 postgresql-server
> It is most likely an issue with your local setup. Can you reproduce it
> on a clean chroot without setting locale manually?
> 

reassigning to postgresql-server as createdb command is provided by
postgresql



signature.asc
Description: OpenPGP digital signature

Bug#843954: [node-which] Please update to 1.2.1

[Sruthi]

Package: node-which
Version: 1.0.5-2
Severity: wishlist

--- Please enter the report below this line. ---
Please update to version 1.2.1, it is required by grunt-legacy-util
which is a dependency for grunt.

--- System information. ---
Architecture: amd64
Kernel: Linux 4.8.0-1-amd64

Debian Release: stretch/sid
500 unstable debian.sil.at

--- Package information. ---
Depends (Version) | Installed
==-+-===
nodejs | 4.6.1~dfsg-1


Package's Recommends field is empty.

Package's Suggests field is empty.



signature.asc
Description: OpenPGP digital signature

Bug#843953: multipath-tools: LVM on internal disks + multipath-toosl = no multipaths

[Vincent McIntyre]

Package: multipath-tools
Version: 0.5.0-6+deb8u2
Severity: important

   * What led up to the situation?

   Upgrade working wheezy system to jessie
   Apply patch to fix multipath segfault, see #751993

   The system boots off an internal physical disk
   That disk has one / partition and an LVM partition
   /usr is one of the LVs on that disk
   There are two other internal disks, LVM is not used on these.
   The multipath devices are connected via a qlogic ISP2432-based card,
   through a FC switch to two Promise VTrak units.
   LVM is not used on the multipath devices.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   Cold-plug FC connection to external storage, boot system.

   * What was the outcome of this action?

   multipath -l shows no devices. no related device maps in /dev/mapper.

   The FC and SCSI layers all worked fine, I see lots of /dev/sdX devices.

   multipath -l -v3 shows the /dev/sdX devices as blacklisted
 ...
 sdd: blacklisted, udev property missing
 sde: blacklisted, udev property missing
 sdp: blacklisted, udev property missing
 ...etc

   * What outcome did you expect instead?

   usable multipaths to the configured devices
   /dev/mapper populated, including kpartx partitions

Related notes:

   On some reboots the system log shows multipath timing out. Below is 'sdd'.
   The timeout occurs 33 seconds after the disk was attached.
   I was unable to determine the cause of this or reproduce consistently.

   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] 25769805824 512-byte logical 
blocks: (13.1 TB/12.0 TiB)
   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Write Protect is off
   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Mode Sense: 97 00 10 08
   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Write cache: enabled, read cache: 
enabled, supports DPO and FUA
   Nov 11 11:11:53  kernel:  sdd: sdd1
   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Attached SCSI disk
   ...
   Nov 11 11:12:25  systemd-udevd[346]: timeout '/sbin/multipath -v0 /dev/sdd'
   Nov 11 11:12:26  systemd-udevd[346]: timeout: killing '/sbin/multipath -v0 
/dev/sdd' [459]
   Nov 11 11:12:26  systemd-udevd[346]: '/sbin/multipath -v0 /dev/sdd' [459] 
terminated by signal 9 (Killed)

   On some reboots, there was a bad interaction between LVM and multipathd
   and/or udev. On the console systemd showed it was waiting for tasks to
   complete for both of these.
   device-mapper would try to handle the multipath devices before the LVM
   ones, which sometimes caused the system to fail to boot; it went into
   emergency mode.
   I was unable to determine the cause of this or reproduce it consistently.
   I don't know where the multipath-tools-boot line comes from, that
   package is not even installed.

   You can however see the two running contemporaneously
   # journalctl |egrep -i -e '(multipath|lvm|-udev)'
   Nov 11 16:52:57 systemd[1]: Starting LVM2 metadata daemon socket.
   Nov 11 16:52:57 systemd[1]: Listening on LVM2 metadata daemon socket.
   Nov 11 16:52:57 systemd-udevd[317]: starting version 215
   Nov 11 16:52:58 systemd[1]: Starting LSB: early multipath boot script...
   Nov 11 16:52:58 kernel: device-mapper: multipath: version 1.7.0 loaded
   Nov 11 16:52:59 multipath-tools-boot[633]: Discovering and coalescing 
multipaths...done.
   Nov 11 16:52:59 systemd[1]: Started LSB: early multipath boot script.
   Nov 11 16:52:59 systemd[1]: Starting system-lvm2\x2dpvscan.slice.
   Nov 11 16:52:59 systemd[1]: Created slice system-lvm2\x2dpvscan.slice.
   Nov 11 16:52:59 systemd[1]: Starting LVM2 PV scan on device 8:2...
   Nov 11 16:52:59 systemd[1]: Starting Activation of LVM2 logical volumes...
   Nov 11 16:52:59 systemd[1]: Started LVM2 PV scan on device 8:2.
   Nov 11 16:52:59 lvm[676]: 10 logical volume(s) in volume group "testbox" now 
active
   Nov 11 16:53:00 systemd[1]: Started Activation of LVM2 logical volumes.
   Nov 11 16:53:00 systemd[1]: Starting Activation of LVM2 logical volumes...
   Nov 11 16:53:01 lvm[854]: 10 logical volume(s) in volume group "testbox" now 
active
   Nov 11 16:53:01 systemd[1]: Started Activation of LVM2 logical volumes.
   Nov 11 16:53:01 systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots 
etc. using dmeventd or progress polling...
   Nov 11 16:53:01 lvm[928]: 10 logical volume(s) in volume group "testbox" 
monitored
   Nov 11 16:53:01 systemd[1]: Started Monitoring of LVM2 mirrors, snapshots 
etc. using dmeventd or progress polling.
   Nov 11 16:53:09 systemd[1]: Starting LSB: multipath daemon...
   Nov 11 16:53:10 multipath-tools[1190]: Starting multipath daemon: multipathd.
   Nov 11 16:53:10 systemd[1]: Started LSB: multipath daemon.
   Nov 11 16:53:10 multipathd[1288]: path checkers start up



Further work:

First I applied the patch discussed in #799781 (shared lock with udev).
This didn't fix things but may have helped.

Then after reviewing #782487, I built sg3-utils v1.42 and installed it,
including 

Bug#827649: gitlab: Git pull/push over ssh fails with: "fatal: protocol error: bad line length character: API"

[Pirate Praveen]

Can you try again with 8.13.3+dfsg1-2 in unstable and see if this is
still an issue?



signature.asc
Description: OpenPGP digital signature

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Andreas Tille]

Hi,

On Thu, Nov 10, 2016 at 10:38:32PM +0100, Ole Streicher wrote:
> On 10.11.2016 21:07, Andreas Tille wrote:
> > So I confirm that the first problem we detected is solved but there is
> > another one breaking Debian Edu.  I have again no suspicion why the '\'
> > sign is not elimiunated from the list only in those few cases.
> 
> I can also just "poke in the fog" here. I thought that the multilines
> were already eaten up by lines 537-544, and should not appear again
> here. However, they do, as my "print" debugger shows. Perlists, please
> help!!!
> 
> The pragmatic solution here is to just remove the backslashes from the
> end of line. I can commit a patch that does this.
> 
> However, debian-edu keeps to be broken. Reason is that the tasks contain
> lines like (development)
> 
> Depends: fp-compiler, [...multiline... ], fp-units-fv
> Depends: lazarus
> 
> so, with two "Depends" in one section. Or (electronics):

That's definitely broken and not supported by other tools than
blends-dev and should be fixed.  Every Depends, Recommends and
Suggests should be in a separate paragraph.
 
> Depends: qucs, gpsim, oregano
> Recommends: education-menus, xoscope
> Suggests: kicad, kicad-doc-en, kicad-doc-de, kicad-doc-es, kicad-doc-fr
> Suggests: electric, pcb, xcircuit, freehdl, gtkwave
> Responsible: ?
> NeedConfig:  no
> 
> two "Suggests". This does not work anymore (no idea why), but is also
> IMO forbidden by RFC834.

The web sentinel code does not even allow one Depends and Suggests in a
common paragraph.
 
> I have no idea why this works without RFC834 continuation, but not with
> them.
> 
> On the other hand, we *win* one more dependency: in "common", the
> "firmware-ralink" dependency line was *not* preceded one with a
> backslash. This shows that the backslash is just a bad idea for
> continuation lines.

Meanwhile I'm fully convinced that you are right here and we should fix
this soon since also in Debian Science some missing backslashes caused
loss of Dependencies in the resulting metapackages.
 
> --> debian-edu tasks are just broken. They don't follow any rule, and
> depending from the parser one will get always different results. Maybe
> we should fix that? remove all backslash continuation lines and
> duplicated keywords from the tasks files?

I think it should be sufficient to add line breaks where needed.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#843952: ITP: node-grunt-legacy-util -- Some old grunt utils provided for backwards compatibility

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-grunt-legacy-util
  Version : 1.0.0
  Upstream Author : "Cowboy" Ben Alman (http://benalman.com/)
* URL : http://gruntjs.com/
* License : Expat
  Programming Lang: JavaScript
  Description : Some old grunt utils provided for backwards
compatibility

Bug#799781: found the upstream commit

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2016-11-11 at 11:58 +1100, Vincent McIntyre wrote:
> On Sun, 27 Sep 2015 20:04:06 +0530, Ritesh Raj Sarraf wrote:
> 
> > I have a problem here.
> > 
> > The fix, that you mentioned for the Shared Lock, does not seem to be
> > committed upstream. Neither master, nor Hannes's suse-fixes branch.
> 
> It is there, please see

Yes. Hannes pushed his entire branch recently. This should also go into the
stable update.

If there are other bug reports too, please bring them up. I'll queue them up for
the stable update.

Thanks

- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlglbTgACgkQpjpYo/Lh
dWmM+xAAhGR8xKfHLq9y9fCAXHAcULei9lYvr7oyThS19Us1MPKC3sGK8JXLt+YZ
44vqGJw8iAG4r36wYseFSSB3QALapKtLlOnu5aVdzmsDp+Tq8iMPfT2+h3twdXDB
65eHKOMrsp+6exGkMV3QxqvU1RNnTeIvCOfnQ6YbR505JhgOf/4xSekH/qDGLnnb
zOtJwZvdp/RMQq3qJ8giz8sI1f0a+UUnhVOhHgHqGsiKNse6Tn8cTe9t5MSvqgKT
YlPyNDuUXpZ1jZ7+AOOwTzQRm69VdgV5y9xmfJC5mKQskKtKKQwwvj0HSJoFq5U3
Ch+XCpxh3JoaqDqWQl/c/PftlQggIekQ1UMcUsTfj4UWJ3IEkb8cWIZWAVZ6AX7K
7SoXax6LW1g9RPbVMhuVYBIMYRh5gj6uFtjqtbSdQcjxhZdvBXcb7ivPH8bWhrCt
91HI+u+GX179nMLTCCRqzrcCScflSZmfCrEjjUKIu11REKx4q79NOncE++p+S73A
CZmitUihduSQ6iA/8UEfJ8fs9QFPJTJMSCk4hcV5xCW6iKOKnMYdAnpiz0bND/Qd
/UJSJ56tVylRlwZccS992ep3LhDBuJVD9iXq+EgGZumaXDEykouAFi1L8YeLRW/t
RuGGyTrHG7eON5D4q/Dp7jhemHyXchBRGDl0znFMXmFJvMVEoBc=
=oRLY
-END PGP SIGNATURE-

Bug#822291: Should have been resolved

[Scott Kitterman]

Is it still a problem?

Bug#794496: No stored procedure support upstream

[Scott Kitterman]

http://s.co.tt/2012/01/12/using-postfix-with-mysql-stored-procedures-or-use-functions/
 has a reasonable discussion of the issue.  Upstream has said they 
aren't going to implement this on their own.  Someone will have to provide a 
high quality patch (bad ones have already been provided).

Scott K

Bug#843951: [node-async] Please update to version 1.5.2

[Sruthi]

Package: node-async
Version: 0.8.0-1
Severity: wishlist

--- Please enter the report below this line. ---
Please update to version 1.5.2 - required by grunt-legacy-utils, a
dependency for grunt.

--- System information. ---
Architecture: amd64
Kernel: Linux 4.8.0-1-amd64

Debian Release: stretch/sid
500 unstable debian.sil.at

--- Package information. ---
Depends (Version) | Installed
==-+-===
nodejs | 4.6.1~dfsg-1


Package's Recommends field is empty.

Package's Suggests field is empty.



signature.asc
Description: OpenPGP digital signature

Bug#843950: linux-image-4.7.0-0.bpo.1-amd64: Suspend 2 ram problems. Kernel oops and panic on wakeup

[arjun]

Package: src:linux
Version: 4.7.8-1~bpo8+1
Severity: important

Wakeup from suspend to ram fails after fourth or fifth suspend and
wakeup event.  I followed the kernel documentation for s2ram. I get the same 
crashes with
in kernel 4.7.6 with pm_trace enabled. 

$ cat /proc/sys/pm_trace_dev_match
shows

input
microsoft

The magic number that shows up in dmesg (I don't know if this is relevant is)
[1.254974]   Magic number: 8:694:2

There are no lines of the form "hash matched". In a previous run, I got

$ cat /sys/power/pm_trace_dev_match

tty
usb

Full logs to be found here: 
https://dl.dropboxusercontent.com/u/96020841/configs/misc/crash-logs/arjundesktop-2016-11-07.tar.gz
 

Similar crash on kernel 4.7.6 but compiled with some extra pm debugging
options: 
https://dl.dropboxusercontent.com/u/96020841/configs/misc/crash-logs/arjundesktop-2016-11-07.tar.gz

The error messages I see on wakeup are not in the log. The tail end of
the call trace can be found in the following pictures.

4.7.0-0.bpo.1-amd64

https://goo.gl/photos/oxy4KxLNehcf5NCx5

4.7.6

https://goo.gl/photos/9NBjmThT9HhQYpqW7


-- Package-specific info:
** Version:
Linux version 4.7.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.7.0-0.bpo.1-amd64 
root=/dev/mapper/samsung_850evo_lvm-rootdebian ro initcall_debug 
ignore_loglevel "dyndbg=file suspend.c +p" systemd.unit=graphical.target 
no_console_suspend=1 resume=/dev/mapper/samsung_850evo_lvm-swap

** Not tainted

** Kernel log:
Nov 10 00:13:55 arjundesktop dbus[2767]: [system] Activating via systemd: 
service name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service'
Nov 10 00:13:55 arjundesktop systemd[1]: Reached target Sleep.
Nov 10 00:13:55 arjundesktop systemd[1]: Starting Suspend...
Nov 10 00:13:55 arjundesktop systemd[1]: Starting Network Manager Script 
Dispatcher Service...
Nov 10 00:13:55 arjundesktop systemd-sleep[17949]: Suspending system...
Nov
 10 07:37:10 arjundesktop rsyslogd: [origin software="rsyslogd" 
swVersion="8.4.2" x-pid="2838" x-info="http://www.rsyslog.com;] start

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: H97M-D3H
product_version: To be filled by O.E.M.
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: F7
board_vendor: Gigabyte Technology Co., Ltd.
board_name: H97M-D3H
board_version: To be filled by O.E.M.

** Loaded modules:
ctr
ccm
binfmt_misc
nfsd
auth_rpcgss
nfs_acl
nfs
lockd
grace
fscache
sunrpc
arc4
snd_hda_codec_hdmi
nls_ascii
nls_cp437
vfat
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
fat
iTCO_wdt
iTCO_vendor_support
kvm_intel
kvm
irqbypass
crct10dif_pclmul
crc32_pclmul
ghash_clmulni_intel
hmac
drbg
ansi_cprng
rt2800usb
rt2x00usb
rt2800lib
rt2x00lib
mac80211
aesni_intel
efi_pstore
cfg80211
aes_x86_64
lrw
gf128mul
glue_helper
ablk_helper
cryptd
pcspkr
crc_ccitt
rfkill
serio_raw
efivars
sg
i2c_i801
joydev
i915
evdev
snd_hda_codec_realtek
snd_hda_codec_generic
mei_me
mei
snd_hda_intel
snd_soc_rt5640
snd_hda_codec
snd_soc_ssm4567
snd_soc_rl6231
drm_kms_helper
lpc_ich
mfd_core
snd_hda_core
snd_soc_core
drm
snd_hwdep
snd_compress
shpchp
snd_pcm
i2c_algo_bit
snd_timer
snd
battery
snd_soc_sst_acpi
video
elan_i2c
snd_soc_sst_match
soundcore
dw_dmac
i2c_designware_platform
dw_dmac_core
i2c_designware_core
button
tpm_infineon
acpi_pad
tpm_tis
tpm
fuse
parport_pc
ppdev
lp
parport
efivarfs
autofs4
ext4
crc16
jbd2
mbcache
dm_mod
hid_microsoft
sd_mod
hid_generic
usbhid
crc32c_intel
ahci
libahci
psmouse
libata
xhci_pci
xhci_hcd
ehci_pci
ehci_hcd
usbcore
r8169
scsi_mod
mii
usb_common
thermal
fan
fjes
i2c_hid
hid
sdhci_acpi
sdhci
mmc_core

** Network interface configuration:
source-directory /etc/network/interfaces.d

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state 
DOWN group default qlen 1000
link/ether 74:d4:35:ad:c8:50 brd ff:ff:ff:ff:ff:ff
3: wlan0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 7c:dd:90:83:1c:15 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.200/24 brd 192.168.0.255 scope global wlan0
   valid_lft forever preferred_lft forever
inet6 2601:681:4102:54f0:7edd:90ff:fe83:1c15/64 scope global noprefixroute 

Bug#823330: its working for me

[gustavo panizzo (gfa)]

Control:
merge 472001 -1
notfound -1 1.8beta5+ds1-1
thanks

Hello 

works for me

$ tsocks wget -q -O - icanhazip.com 
XXX.XXX.95.55

$ wget -q -O - icanhazip.com 
XXX.XXX.43.177


$ grep ^server /etc/tsocks.conf 
server = localhost
server_type = 5
server_port = 1081

I'm using tsocks 1.8beta5+ds1-1 but that particular patch hasn't changed

if you confirm it works for you, i'll proceed to close this bug

thanks!

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa

Bug#729188: [Pkg-openssl-devel] Bug#706423: Bug#706423: Bug#706423: openssl: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:

[Scott Kitterman]

On Tue, 12 Nov 2013 19:52:19 +0100 Kurt Roeckx  wrote:
> On Sun, Nov 10, 2013 at 01:37:34AM +0100, Kurt Roeckx wrote:
> > > http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
> > 
> > Can I suggest that we just change the default cipher list the
> > postfix sends to the server?
> > 
> > I currently see this in postfix's config:
> > tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
> > tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
> > tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
> > tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
> > tls_null_cipherlist = eNULL:!aNULL
> > 
> > smtpd_tls_ciphers = export
> > smtp_tls_mandatory_ciphers = medium

For what it's worth, this is now a bit different (3.1.3):

tls_export_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH
tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH 
tls_low_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:+RC4:@STRENGTH
tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL

smtpd_tls_ciphers = medium
smtp_tls_mandatory_ciphers = medium

Are people still having this problem?

Scott K

Bug#759896: postfix: newaliases fails under qemu-user-static chroot

[Scott Kitterman]

On Tue, 8 Nov 2016 10:53:48 +0100 Tzafrir Cohen  wrote:
...
> It seems qemu fails to implement a certain kernel detail needed for
> netlink. I didn't dig deep enough down there to see why it was needed
> for newaliases.
...

Then that's not a postfix bug.

Scott K

Bug#838734: fixed in plasma-discover 5.8.3-1

[Scott Kitterman]

This is currently blocked from migrating to Testing by the Qt5.7.1 transition.  
Eventually, we'll get there.

Scott K

Bug#843949: mysql-workbench: Cannot Connect to Database Server

[Ivan Zharenkov]

Package: mysql-workbench
Version: 6.2.3+dfsg-7
Severity: important

Dear Maintainer,

fresh installed mysql-workbench cannot connect to local mysql server with
error:

Your connection attempt failed for user 'root' from your host to server at
localhost:3306:
  Cannot start SSH tunnel manager



-- System Information:
Debian Release: 8.6
  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=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mysql-workbench depends on:
ii  libatkmm-1.6-12.22.7-2.1
ii  libc6 2.19-18+deb8u6
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libcairomm-1.0-1  1.10.0-1.1
ii  libctemplate2 2.2-4
ii  libgcc1   1:4.9.2-10
ii  libgdal1h 1.10.1+dfsg-8+b3
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglib2.0-0  2.42.1-1+b1
ii  libglibmm-2.4-1c2a2.42.0-1
ii  libgnome-keyring0 3.12.0-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libgtkmm-2.4-1c2a 1:2.24.4-1.1
ii  libmysqlclient18  5.5.53-0+deb8u1
ii  libmysqlcppconn7  1.1.3-6
ii  libodbc1  2.3.1-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangomm-1.4-1  2.34.0-1.1
ii  libpcre3  2:8.35-3.3+deb8u4
ii  libpcrecpp0   2:8.35-3.3+deb8u4
ii  libpython2.7  2.7.9-2+deb8u1
ii  libsigc++-2.0-0c2a2.4.0-1
ii  libstdc++64.9.2-10
ii  libtinyxml2.6.2   2.6.2-2
ii  libuuid1  2.25.2-6
ii  libvsqlitepp3 0.3.13-3
ii  libx11-6  2:1.6.2-3
ii  libxml2   2.9.1+dfsg1-5+deb8u3
ii  libzip2   0.11.2-1.2
ii  mysql-workbench-data  6.2.3+dfsg-7
ii  python-mysql.connector1.2.3-2
ii  python-paramiko   1.15.1-1
ii  python-pexpect3.2-1
ii  python-pyodbc 3.0.6-2
ii  python-pysqlite2  2.6.3-3
ii  python2.7 2.7.9-2+deb8u1
pn  python:any

Versions of packages mysql-workbench recommends:
ii  mysql-client-5.5 [virtual-mysql-client]  5.5.53-0+deb8u1
ii  mysql-utilities  1.3.5-2
ii  ttf-bitstream-vera   1.10-8

Versions of packages mysql-workbench suggests:
ii  gnome-keyring  3.14.0-1+b1

-- debconf-show failed

Bug#843947: html5lib: new upstream release (0.999999999/1.0b10)

[Paul Wise]

Source: html5lib
Severity: wishlist

There have been several new releases, latest is 0.9/1.0b10:

https://github.com/html5lib/html5lib-python/releases
https://pypi.python.org/pypi/html5lib#change-log

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#843948: duck: [PATCH] Add exception for Emacs M-x shell (no colors)

[Jari Aalto]

Package: duck
Version: 0.10
Severity: wishlist
Tags: patch

By default program enables color. However if run inside standard Emacs
M-x shell, the color cored are not interpreted and the output looks
garbled.

Please consider applying the following patch which adds exception for
Emacs.

Consideration not to enable colors by default
---

(1) In general, it might be considered that programs wouldn't use
colors by default. It's quite impossible to select correct colors for
various terminals considering that user may have chosen their own
default backgrounds and foregrounds -- thus the program's choices may
not play well with the users' selected colors.

(2) Typically features are enabled by request.

E.g in git(1) colors are enabled explicitly.
>From e35a09133f782a205396288bbc5a52b7fba188ed Mon Sep 17 00:00:00 2001
From: Jari Aalto 
Date: Fri, 11 Nov 2016 06:32:26 +0200
Subject: [PATCH] Disable colors in Emacs M-x shell
Organization: Private
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Signed-off-by: Jari Aalto 
---
 duck | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/duck b/duck
index e89d982..8d09c9c 100755
--- a/duck
+++ b/duck
@@ -67,7 +67,17 @@ my $checksdir='/usr/share/duck/lib/checks';
 
 my $try_https=0;
 my $nocolor=0;
+
 our $enforceColor="auto";
+
+if (exists $ENV{'INSIDE_EMACS'})
+{
+# Program is being run inside
+# Emacs M-x shell buffer
+
+$enforceColor = "never";
+}
+
 my @allowedColorVals=qw/always auto never/;
 my $showMissingHelpers;
 my $urlFixEnableOptions;
-- 
2.9.3

Bug#843946: add-apt-repository fails to import the key

[Simon Bernier St-Pierre]

Package: software-properties-common
Version: 0.96.20.2-1

When trying to add a new ppa using software-properties-common,
I get an error. The system is left in an inconsistent state
where the source entry is added, but the key isn't.

Output:

simon@mu:~$ sudo add-apt-repository ppa:webupd8team/atom
 PPA for Atom text editor: https://atom.io

Now available for both 32bit and 64bit!

More info, report packaging bugs, feedback, etc.: 
http://www.webupd8.org/2014/05/install-atom-text-editor-in-ubuntu-via-ppa.html


Report non-packaging Atom bugs here: https://github.com/atom/atom/issues
 More info: https://launchpad.net/~webupd8team/+archive/ubuntu/atom
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keybox '/tmp/tmprdeggb3d/pubring.gpg' created
gpg: /tmp/tmprdeggb3d/trustdb.gpg: trustdb created
gpg: key C2518248EEA14886: public key "Launchpad VLC" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:   imported: 1
gpg: no valid OpenPGP data found.
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
  File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
  File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", 
line 688, in addkey_func

func(**kwargs)
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 
386, in add_key

return apsk.add_ppa_signing_key()
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 
273, in add_ppa_signing_key

cleanup(tmp_keyring_dir)
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 
234, in cleanup

shutil.rmtree(tmp_keyring_dir)
  File "/usr/lib/python3.5/shutil.py", line 474, in rmtree
_rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.5/shutil.py", line 432, in _rmtree_safe_fd
onerror(os.unlink, fullname, sys.exc_info())
  File "/usr/lib/python3.5/shutil.py", line 430, in _rmtree_safe_fd
os.unlink(name, dir_fd=topfd)
FileNotFoundError: [Errno 2] No such file or directory: 
'S.gpg-agent.extra'

Bug#843072: mumble-server: README.Debian mention a mumble-server-web package not available on debian 8

[Chris Knadle]

Leonardo Boselli:
> Package: mumble-server
> Version: 1.2.8-2
> Severity: minor
> 
> Dear Maintainer,
> on the file README.Debian there is a mention a mumble-server-web package not
> available on debian 8

Yep, verified.  (First verified on November 5th but I wanted to look
further before replying.)  Unfortunately it's also true for 1.2.17-1 in
Sid and Stretch, and might be too late to change now before the upcoming
Stable release.  mumble-server-web was dropped just before the release
of Wheezy by Ron Lee in 2012 (1.2.3-349-g315b5f5-2):

   https://tracker.debian.org/news/389580

I would like to fix this because I would like to give users correct
information, but I likely wouldn't be able to do an upload for this
alone without there being a more serious problem I could add this to.
Uploads to Stable are limited to fairly serious bugs, and then get
included in Point Releases when they happen (usually once every three
months).  This is explained in the Debian Developer's Reference here:


https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable

It's good to get this kind of feedback regardless, because it lets me
know I need to audit the package a bit more closely.

Thanks for reporting this -- it's a good thing.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#828475: openssh: FTBFS with openssl 1.1.0

[Colin Watson]

On Sat, Nov 05, 2016 at 08:10:37PM +0200, Adrian Bunk wrote:
> On Sat, Nov 05, 2016 at 03:40:02PM +, Colin Watson wrote:
> > I know it isn't the option you'd prefer, but I've uploaded openssh
> > 1:7.3p1-3 with an adjusted Build-Depends ("libssl1.0-dev | libssl-dev
> > (>= 0.9.8g)") so that it uses OpenSSL 1.0 for now.
> 
> Correct would be "libssl1.0-dev | libssl-dev (<< 1.1.0~)".
> 
> ">= 0.9.8g" is irrelevant because this is true since at least wheezy, 
> but people trying to build OpenSSH on a system where libssl-dev from 
> OpenSSL 1.1.0 is installed will happen.

Fair enough, thanks.  Applied.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#843925: dpkg-dev: dpkg-buildpackage should sign buildinfo files

[Guillem Jover]

Control: severity -1 wishlist

On Thu, 2016-11-10 at 19:49:03 +0100, Ximin Luo wrote:
> Package: dpkg-dev
> Version: 1.18.13
> Severity: important

> We would like dpkg-buildpackage to clearsign the buildinfo files that are
> created. This allows them to be uploaded to services similar to keyservers,
> for auditing and attestation purposes, that may be run independently of the
> FTP archive.

Yeah I know, and I had noticed this already just after the upload, but
just notced it down with the other things I'd like to discuss
regarding the buildinfo files, which I'll try to start this week, once
the current uploads settle down a bit.

> I'm happy to write this patch myself. That will take a little bit more time - 
> I
> wanted to file this bug report early to check that you're not opposed to this
> idea - and before too many other tools start assuming that buildinfo files are
> unsigned. I think this should not be the case by default, just as you rarely
> see an unsigned .dsc being distributed.
> 
> There would also be a -ub option added, along the same lines as -us and -uc.
> Then debsign from devscripts will also need to be updated, and I'll be happy 
> to
> write the patch for this too.

I'm planning on finishing up and merging the dpkg-sign branch, so this
would be probably wasteful. I'll include the necessary changes there.

Thanks,
Guillem

Bug#843944: tracker.debian.org: please add “changes” anchor in news entries

[Cyril Brulebois]

Control: tag -1 patch

Cyril Brulebois  (2016-11-11):
> It would be nice if an anchor could be added on the “Changes:” line of
> the news entry. For example, when trying to point to recent grub2
> changes, this link would lead to a page full of descriptions (one for
> each binary):
>   https://tracker.debian.org/news/811622
> 
> while the following link could lead directly to the Changes: part which
> is filled according to debian/changelog:
>   https://tracker.debian.org/news/811622#changes
> 
> grub2 isn't too bad; linux is… I seem to be needing 11 page downs to get
> to the changes part on this entry, for example:
>   https://tracker.debian.org/news/811137
> 
> Thanks for considering.

I think the attached patch should do the job.

But I suspect the following bits from the CSS might need updating (the
naked “a” part notably), since this anchor gets highlighted in blue,
which might not be too desirable?
| a, a:hover, a:focus {
| color: #0530D7;
| }


KiBi.
From 669f0459a86e2902e4972ecae9224f888977f6ba Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Fri, 11 Nov 2016 04:13:38 +0100
Subject: [PATCH] auto_news: add a "changes" anchor.

This way, one can share links pointing directly to the interesting part
of a news page (Closes: #843944).

Signed-off-by: Cyril Brulebois 
---
 distro_tracker/auto_news/tracker_tasks.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/distro_tracker/auto_news/tracker_tasks.py b/distro_tracker/auto_news/tracker_tasks.py
index ecd8089..186950d 100644
--- a/distro_tracker/auto_news/tracker_tasks.py
+++ b/distro_tracker/auto_news/tracker_tasks.py
@@ -49,7 +49,7 @@ class GenerateNewsFromRepositoryUpdates(BaseTask):
 # Add changelog entries since last update...
 changelog_content = package_version.get_changelog_entry()
 if changelog_content:
-content = content + '\nChanges:\n' + changelog_content
+content = content + '\nChanges:\n' + changelog_content
 
 return content
 
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#843787: [pkg-go] Bug#843787: Bug#843787: golang-github-jacobsa-crypto-dev: hash_64bit.go misses ppc64(el)

[Michael Hudson-Doyle]

That PR got merged, so an upstream update will fix this (I can't do that,
only a DM still :-p)

On 10 November 2016 at 08:06, Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

> I made a PR: https://github.com/jacobsa/crypto/pull/7
>
> On 10 November 2016 at 05:10, Aaron M. Ucko  wrote:
>
>> Package: golang-github-jacobsa-crypto-dev
>> Version: 0.0~git20160410.0.42daa9d-2
>> Severity: important
>>
>> Builds of gocryptfs on ppc64el and the non-release architecure ppc64
>> have been failing:
>>
>>   obj-powerpc64le-linux-gnu/src/github.com/jacobsa/crypto/cmac/hash.go:97:
>> undefined: xorBlock
>>
>> The issue appears to be that the "// +build" setting in hash_64bit.go
>> misses these architectures.  Per https://golang.org/pkg/go/build/, it
>> looks like there's no generic tag you can use here.  Instead, I
>> suppose you'll just have to add ppc64 and ppc64le there, per
>> https://github.com/golang/go/issues/8654#user-content-c27.
>>
>> Could you please take a look?
>>
>> Thanks!
>>
>> --
>> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
>> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finge
>> r/?a...@monk.mit.edu
>>
>> ___
>> Pkg-go-maintainers mailing list
>> pkg-go-maintain...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-
>> go-maintainers
>>
>
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>

Bug#843945: RM: ayttm -- ROM; Dead unstream, RC buggy

[Kartik Mistry]

Package: ftp.debian.org
Severity: normal

ayttm is not maintained upstream since 2010 and I've not seen any recent
activities. Also, it is RC buggy and likely to fix at upstream. There
are plenty of alternatives available with (almost) same functionalities
too.

Thanks.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#843944: tracker.debian.org: please add “changes” anchor in news entries

[Cyril Brulebois]

Package: tracker.debian.org
Severity: wishlist

Hi,

It would be nice if an anchor could be added on the “Changes:” line of
the news entry. For example, when trying to point to recent grub2
changes, this link would lead to a page full of descriptions (one for
each binary):
  https://tracker.debian.org/news/811622

while the following link could lead directly to the Changes: part which
is filled according to debian/changelog:
  https://tracker.debian.org/news/811622#changes

grub2 isn't too bad; linux is… I seem to be needing 11 page downs to get
to the changes part on this entry, for example:
  https://tracker.debian.org/news/811137

Thanks for considering.


KiBi.

Bug#751105: Re: netcat-openbsd: New upstream version available

[Guilhem Moulin]

On Thu, 10 Nov 2016 at 18:14:31 +0800, Aron Xu wrote:
> On Thu, Nov 10, 2016 at 5:04 PM, Guilhem Moulin  wrote:
>> Right.  Aron, if you need help with this package, would you be
>> interested in co-maintenance?  The package is in collab-maint already so
>> hopefully it won't be too much overhead to jump in.  Would be great to
>> ship 1.159 (the netcat version found in OpenBSD 6.0) in Stretch :-)
> 
> More than happy to see someone to help, :-)

Sure :-)  I've imported upstream versions 1.109 to 1.130 (corresponding
to OpenBSD 5.2 to 5.8), and rebased the Debian patches on top of each.
Would you like me to push that directly into collab maint?  I can also
create a new branch or push into another another remote if you prefer.

I stopped at 1.130 because the more recent OpenBSD ship an SSL-capable
nc(1), and I'm not sure whether we should link against or wrap the code
around #ifdef/#endif.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#843942: Obsolete build dependencies

[Michael Biebl]

Source: simple-scan
Version: 3.21.90-1
Severity: normal
Tags: patch

Hi,

looking at configure.ac and the sources, the build dependencies on
libdbus-glib-1-dev and libsqlite3-dev are no longer needed and can be
dropped safely

Regards,
Michael


-- Package-specific info:

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 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)

-- no debconf information
>From 94f011609ed8642bae2e948ee02e78cf45909ee1 Mon Sep 17 00:00:00 2001
From: Michael Biebl 
Date: Fri, 11 Nov 2016 03:27:16 +0100
Subject: [PATCH] Drop obsolete Build-Depends

The Build-Depends on libdbus-glib-1-dev and libsqlite3-dev are no longer
needed and can be dropped safely.
---
 debian/control | 2 --
 1 file changed, 2 deletions(-)

diff --git a/debian/control b/debian/control
index 9e61795..2b8559c 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,6 @@ Build-Depends:
  gnome-pkg-tools (>= 0.10),
  libcairo2-dev,
  libcolord-dev,
- libdbus-glib-1-dev,
  libglib2.0-dev (>= 2.32),
  libgtk-3-dev,
  libgdk-pixbuf2.0-dev (>=2.31.1),
@@ -20,7 +19,6 @@ Build-Depends:
  libxml2-utils,
  python-rsvg,
  python-scour,
- libsqlite3-dev,
  valac (>= 0.22),
  yelp-tools,
  zlib1g-dev (>= 1.2.7)
-- 
2.10.2

Bug#843943: debian-cd: please mention the dinstall serial in a trace file

[Cyril Brulebois]

Package: debian-cd
Severity: normal

(X-D-Cc: debian-b...@lists.debian.org)

Hi,

Since pettersson has a mirror with project/trace, which gives us access
to archive serial, it would be nice to have a look when the build starts
and to report this, maybe in a trace file alongside cdimage.debian.org?

Also, as as side question, do we prevent the mirror from being updated
during the n-hours build of all images?


Some context: This would help figure out what changed between two d-i
releases, in addition to log parsing scripts I'm already running (which
only accounts for udebs installed during the build, plus build-deps):
looking at packages getting ACCEPTED between two dates in my
debian-boot@ mailbox is not practical and is missing non-debian-boot@
packages; plus: those udebs might not have reached testing anyway.

Thanks for considering.


KiBi.

Bug#843940: libvirt-daemon: "Permission denied" errors in VMM/virt-manager when dynamic_ownership=0

[J Mo]

Package: libvirt-daemon
Version: 2.4.0-1+b1
Severity: important

I discovered today that setting "dynamic_ownership = 0" in
/etc/libvirt/qemu.conf seems to break the creation of new VMs.

I set dynamic_ownership=0 because libvirt was improperly seizing 
ownership of read-only ISO images.

Unfortunately, libvirt doesn't seem to be smart enough to change the
permission of newly created .qcow2 files under /var/lib/libvirt/images
when dynamic_ownership=0.

I get the following error with VMM/virt-manager when attempting to
create a new VM:



Unable to complete install: 'internal error: qemu unexpectedly closed the 
monitor: 2016-11-11T02:00:33.137524Z qemu-system-x86_64: -drive 
file=/var/lib/libvirt/images/Debian_stable_test2.qcow2,format=qcow2,if=none,id=drive-virtio-disk0:
 Could not open '/var/lib/libvirt/images/Debian_stable_test2.qcow2': Permission 
denied'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 2288, in 
_do_async_install
guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 461, in start_install
doboot, transient)
  File "/usr/share/virt-manager/virtinst/guest.py", line 396, in _create_guest
self.domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3777, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error: qemu unexpectedly closed the monitor: 
2016-11-11T02:00:33.137524Z qemu-system-x86_64: -drive 
file=/var/lib/libvirt/images/Debian_stable_test2.qcow2,format=qcow2,if=none,id=drive-virtio-disk0:
 Could not open '/var/lib/libvirt/images/Debian_stable_test2.qcow2': Permission 
denied




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

Kernel: Linux 4.6.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 libvirt-daemon depends on:
ii  libapparmor12.10.95-4
ii  libaudit1   1:2.6.5-1
ii  libavahi-client30.6.32-1
ii  libavahi-common30.6.32-1
ii  libblkid1   2.28-6
ii  libc6   2.23-4
ii  libcap-ng0  0.7.7-3
ii  libdbus-1-3 1.10.8-1
ii  libdevmapper1.02.1  2:1.02.130-1
ii  libfuse22.9.7-1
ii  libgnutls30 3.5.6-2
ii  libnetcf1   1:0.2.8-1
ii  libnl-3-200 3.2.27-1
ii  libnl-route-3-200   3.2.27-1
ii  libnuma12.0.11-1
ii  libparted2  3.2-15
ii  libpcap0.8  1.7.4-2
ii  libpciaccess0   0.13.4-1
ii  librados2   0.80.11-1
ii  librbd1 0.80.11-1
ii  libsasl2-2  2.1.26.dfsg1-15
ii  libselinux1 2.5-3
ii  libssh2-1   1.7.0-1
ii  libudev1231-1
ii  libvirt02.4.0-1+b1
ii  libxen-4.8  4.8.0~rc3-1
ii  libxenstore3.0  4.6.0-1+nmu2
ii  libxml2 2.9.3+dfsg1-1.2
ii  libyajl22.1.0-2

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-1+b1
ii  netcat-openbsd  1.105-7
ii  qemu1:2.6+dfsg-3.1
ii  qemu-kvm1:2.6+dfsg-3.1

Versions of packages libvirt-daemon suggests:
ii  libvirt-daemon-system  2.4.0-1+b1

-- no debconf information

Bug#843941: New upstream release 3.22.0.1 available

[Michael Biebl]

Source: simple-scan
Version: 3.21.90-1
Severity: wishlist

Hi,

there is a new upstream release available. Would be great if you can
update the package accordingly so we don't ship stretch with a
development version.

Regards,
Michael


-- Package-specific info:

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 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)

-- no debconf information

Bug#843847: unixodbc: please package the latest patchlevel release

[Steve Langasek]

Hi Ferenc,

On Thu, Nov 10, 2016 at 09:18:08AM +0100, Ferenc Wágner wrote:
> unixODBC 2.3.4 was released on 2015-08-31 with fixes for several bugs
> which are critical in our setup.  I'd be grateful if you could get it
> into squeeze.  If you can't spare the time to package it, I'm willing
> to help out: the jessie package I created more than a year ago a for
> our internal use is available (though does not show much) at
> http://apt.niif.hu/debian/pool/main/u/unixodbc/unixodbc_2.3.4-1~bpo8+1.dsc
> Please let me know if you'd be fine with an NMU or open to any form
> of collaboration aiming at getting unixODBC 2.3.4 into squeeze.

I was looking at this recently, and wanted to get things set up properly to
use a debian/watch file.  Do you happen to know why the following watch file
doesn't find the new release with 'uscan'?

  version=3
  ftp://ftp.unixodbc.org/pub/unixODBC/unixODBC-(.+)\.tar\.gz

I'd like to get this sorted so that I can do a "proper" update now and going
forward, but uscan syntax and behavior has always seemed unnecessarily
opaque to me.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#843916: debian-installer: fails to FTBFS when u-boot bits go missing

[Cyril Brulebois]

Control: tag -1 patch pending

Cyril Brulebois  (2016-11-10):
> That being said, there's still the issue of debian-installer's build
> system not detecting this issue, which is what this bug report is
> about.

Looking at while loops under build/, only a few arm* bits seemed
affected. Should be fixed with:
| commit 44a203535217322402ad1f10294c76bd99fc1f51
| Author: Cyril Brulebois 
| Date:   Fri Nov 11 03:10:53 2016 +0100
| 
| Make sure errors in while loops are reported (Closes: #843916).


KiBi.


signature.asc
Description: Digital signature

Bug#843829: dpkg-parsechangelog incorrectly claims May is only a 'full' month on date parse failure

[Guillem Jover]

Control: severity -1 normal

On Wed, 2016-11-09 at 16:24:23 -0800, Nishanth Aravamudan wrote:
> Package: dpkg
> Version: 1.18.10ubuntu1
> Severity: important
> Tags: patch

I've lowered the severity because this is really not important in the
grand scheme of things. It might even be minor, but normal seems
better. :)

> Running dpkg-parsechangelog on changelogs that produce date parsing
> problems, e.g.:
> 
> Tue, 17 May 2008 10:93:55 -0500
> 
> (don't ask me how it got there, but it happened in one Ubuntu publish).
> 
> ends up with an error like, "uses full instead of abbreviated month name
> 'May'", which is obviously not the actual problem. I think there is
> actually a bug in dpkg (introduced in:
> https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/scripts/Dpkg/Changelog/Entry/Debian.pm?id=21f5898d846a1cd69bdc6849e2097168cde02fdf),
> in that if a full month is found to be used, it's not checked that the
> full month is *also* an abbreviated month (only true for May, though).

Ah, indeed. I've merged your patch, thanks for that. Will be included
in the upcoming dpkg 1.18.14 release that I'm rolling out right now.

> I tested a fix with below patch on my local system. It feels like it
> might be cleaner to special-case May as the only affected month, but I
> think the logic was simply incorrect before either way -- it only makes
> sense to check if a full month was used if an abbreviated month wasn't.

Yeah, I don't like special casing this kind of things.

Thanks,
Guillem

Bug#799781: found the upstream commit

[Vincent McIntyre]

On Sun, 27 Sep 2015 20:04:06 +0530, Ritesh Raj Sarraf wrote:

> I have a problem here.
> 
> The fix, that you mentioned for the Shared Lock, does not seem to be
> committed upstream. Neither master, nor Hannes's suse-fixes branch.

It is there, please see

http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=5ec07b3af8d1c3a6c7ba1680af20b80ddce4f962
libmultipath: use a shared lock to co-operate with udev

That line of code is still there in the latest git.

Regards
Vince

Bug#811825: FaCT++ Debian package removal

[Tobias Hansen]

Hi Roberto,

I noticed today that ppl was removed from Debian testing due to two RC
bugs. The problem is that ppl 1.2 has a new soname (14), that means it
requires a library transition. We are now already past the library
transition freeze for Debian stretch. Are you shure that the ABI of ppl
changed with version 1.2, i.e. that this soname bump is required?

It would now probably be best to patch version 1.1 of ppl to have at
least this version in the next Debian release. The previous mails from
this bug report suggest that the patch that was discussed was not enough
to fix the build with gcc 6. Could you provide a new patch for this?

Best,
Tobias

On Sat, 6 Aug 2016 14:34:14 +0200 Roberto Bagnara 
wrote:
> The new version upstream (PPL 1.2, released in February 2016) solves
> all problems wrt GCC 6.  If upgrading to the latest upstream release
> is not wanted (why?), then patches have been provided in this very issue.
> Kind regards,
> 
>Roberto
> 

Bug#843939: radare2: FTBFS on arm64: user_pt_regs and NT_PRSTATUS unknown

[Aaron M. Ucko]

Source: radare2
Version: 1.0+dfsg-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

The latest arm64 build of radare2 failed, per the log excerpt below.
Could you please take a look, and ensure that linux_debug.h includes
all necessary headers?

Thanks!

  p/native/linux/linux_debug.c: In function 'linux_handle_signals':
  p/native/linux/linux_debug.c:67:2: warning: #warning DO MORE RDEBUGREASON 
HERE [-Wcpp]
   #warning DO MORE RDEBUGREASON HERE
^~~
  p/native/linux/linux_debug.c: In function 'print_fpu':
  p/native/linux/linux_debug.c:376:2: warning: #warning not implemented for 
this platform [-Wcpp]
   #warning not implemented for this platform
^~~
  p/native/linux/linux_debug.c: In function 'linux_reg_read':
  p/native/linux/linux_debug.c:466:3: warning: #warning not implemented for 
this platform [-Wcpp]
#warning not implemented for this platform
 ^~~
  p/native/linux/linux_debug.c:473:18: error: storage size of 'regs' isn't known
  R_DEBUG_REG_T regs;
^~~~
  p/native/linux/linux_debug.c:482:41: error: 'NT_PRSTATUS' undeclared (first 
use in this function)
  ret = ptrace (PTRACE_GETREGSET, pid, NT_PRSTATUS, io);
   ^~~
  p/native/linux/linux_debug.c:482:41: note: each undeclared identifier is 
reported only once for each function it appears in
  p/native/linux/linux_debug.c:473:18: warning: unused variable 'regs' 
[-Wunused-variable]
  R_DEBUG_REG_T regs;
^~~~
  p/native/linux/linux_debug.c:381:7: warning: variable 'showfpu' set but not 
used [-Wunused-but-set-variable]
bool showfpu = false;
 ^~~
  p/native/linux/linux_debug.c: In function 'linux_reg_write':
  p/native/linux/linux_debug.c:528:16: warning: initialization discards 'const' 
qualifier from pointer target type [-Wdiscarded-qualifiers]
  .iov_base = buf,
  ^~~
  In file included from p/native/linux/linux_debug.c:14:0:
  p/native/linux/linux_debug.h:44:23: error: invalid application of 'sizeof' to 
incomplete type 'struct user_pt_regs'
   #define R_DEBUG_REG_T struct user_pt_regs
 ^
  p/native/linux/linux_debug.c:529:23: note: in expansion of macro 
'R_DEBUG_REG_T'
  .iov_len = sizeof (R_DEBUG_REG_T)
 ^
  p/native/linux/linux_debug.c:531:49: error: 'NT_PRSTATUS' undeclared (first 
use in this function)
 int ret = ptrace (PTRACE_SETREGSET, dbg-pid, NT_PRSTATUS, io);
   ^~~
  In file included from p/native/linux/linux_debug.c:14:0:
  p/native/linux/linux_debug.h:44:23: error: invalid application of 'sizeof' to 
incomplete type 'struct user_pt_regs'
   #define R_DEBUG_REG_T struct user_pt_regs
 ^

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#843938: gnupg2: FTBFS on sparc64: tests all crash

[James Clarke]

Control: forcemerge 843826 -1

On Thu, Nov 10, 2016 at 07:48:27PM -0500, Aaron M. Ucko wrote:
> Source: gnupg2
> Version: 2.1.15-9
> Severity: important
> Justification: fails to build from source (but built successfully in the past)
>
> The latest sparc64 build of gnupg2 failed with test suite crashes:
>
> [...]
>
> Could you please take a look?
>
> Thanks!

This is actually caused by a recent regression in dpkg-dev; please see
the bug mentioned above.

Regards,
James

Bug#826297: really should document the Debian way to create /shutdown-log.txt

[積丹尼 Dan Jacobson]

> "MB" == Michael Biebl  writes:

MB> With merged-usr this will be obsolete

OK. What should I mention in the patch do deal with both cases, pre
merged-usr and post merged-usr? Or maybe I can make one sized fits all
instructions?

Bug#826297: really should document the Debian way to create /shutdown-log.txt

[Michael Biebl]

Am 11.11.2016 um 01:05 schrieb 積丹尼 Dan Jacobson:
> found 826297 232-3
> retitle 826297 really should document the Debian way to create 
> /shutdown-log.txt
> thanks
> 
> Many Debian users will read
> https://freedesktop.org/wiki/Software/systemd/Debugging/#diagnosingshutdownproblems
> and scratch their heads about why no /shutdown-log.txt is produced.
> 
> Therefore, please in /usr/share/doc/systemd/README.Debian.gz at
> Debugging boot/shutdown problems
> mention the *Debian way* of making /shutdown-log.txt,
> namely just without the /usr prepended to
> /lib/systemd/system-shutdown/debug.sh !

With merged-usr this will be obsolete

Anyway, feel free to send us a patch with updates to README.Debian.

-- 
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#843938: gnupg2: FTBFS on sparc64: tests all crash

[Aaron M. Ucko]

Source: gnupg2
Version: 2.1.15-9
Severity: important
Justification: fails to build from source (but built successfully in the past)

The latest sparc64 build of gnupg2 failed with test suite crashes:

  srcdir=../../tests GNUPGHOME=`/bin/pwd` GPG_AGENT_INFO= LC_ALL=C 
GPGSM=../sm/gpgsm ../../tests/runtest ../../tests/inittests
  Segmentation fault
  Segmentation fault
  Segmentation fault
  echo timestamp >./inittests.stamp
  make[5]: Leaving directory '/<>/build/tests'
  [...]
  make[4]: Entering directory '/<>/build/common'
  /bin/bash: line 5: 221671 Segmentation fault  ${dir}$tst
  FAIL: t-stringhelp
  /bin/bash: line 5: 221676 Segmentation fault  ${dir}$tst
  FAIL: t-timestuff
  /bin/bash: line 5: 221681 Segmentation fault  ${dir}$tst
  FAIL: t-convert
  /bin/bash: line 5: 221686 Segmentation fault  ${dir}$tst
  FAIL: t-percent
  /bin/bash: line 5: 221691 Segmentation fault  ${dir}$tst
  FAIL: t-gettime
  /bin/bash: line 5: 221696 Segmentation fault  ${dir}$tst
  FAIL: t-sysutils
  /bin/bash: line 5: 221701 Segmentation fault  ${dir}$tst
  FAIL: t-sexputil
  /bin/bash: line 5: 221706 Segmentation fault  ${dir}$tst
  FAIL: t-session-env
  /bin/bash: line 5: 221711 Segmentation fault  ${dir}$tst
  FAIL: t-openpgp-oid
  /bin/bash: line 5: 221716 Illegal instruction ${dir}$tst
  FAIL: t-ssh-utils
  /bin/bash: line 5: 221721 Bus error   ${dir}$tst
  FAIL: t-mapstrings
  /bin/bash: line 5: 221726 Segmentation fault  ${dir}$tst
  FAIL: t-zb32
  /bin/bash: line 5: 221731 Segmentation fault  ${dir}$tst
  FAIL: t-mbox-util
  /bin/bash: line 5: 221736 Illegal instruction ${dir}$tst
  FAIL: t-iobuf
  /bin/bash: line 5: 221741 Segmentation fault  ${dir}$tst
  FAIL: t-strlist
  /bin/bash: line 5: 221746 Segmentation fault  ${dir}$tst
  FAIL: t-name-value
  /bin/bash: line 5: 221751 Segmentation fault  ${dir}$tst
  FAIL: t-ccparray
  /bin/bash: line 5: 221756 Segmentation fault  ${dir}$tst
  FAIL: t-recsel
  /bin/bash: line 5: 221761 Segmentation fault  ${dir}$tst
  FAIL: t-exechelp
  /bin/bash: line 5: 221766 Segmentation fault  ${dir}$tst
  FAIL: t-exectool
  ===
  20 of 20 tests failed
  Please report to https://bugs.gnupg.org
  ===

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#842642: clang-3.9: memory sanitizer segfaults immediately

[Norbert Lange]

BTW. make check-sanitizer would have likely found this issue, might
want to enable it?
I believe it knows which sanitizers should work

2016-11-11 0:46 GMT+01:00 Norbert Lange :
> Tags: patch
>
>
> Hi,
>
> I got it working, seems that from the 3 related patched, one is already 
> applied.
> The attached archive is the 3 patches and a edited "series" file,
> it should be painless for you to integrate it into the debian/patches
> directory for 3.9
>
> I did not try with 3.8 yet (possibly more difficult), building llvm
> takes quite a while.
>
> Kind Regards,
> Norbert
>
> 2016-11-09 11:04 GMT+01:00 Norbert Lange :
>> Hi,
>>
>> researched a bit further and the same compiled programm will run fine
>> on debian jessie.
>> I tracked it down to being caused by a newer glibc version [1][2],
>> apparently during loading of shared libs, glibc can now allocate
>> memory which messes up sanitzers (mostly in more subtile ways than the
>> memory sanitizer).
>>
>> The result is, that if stretch will ship with the current glibc, clang
>> and gcc (I dont think its patched there either), then the sanitizers
>> won`t be usable.
>> 1) revert the fix in glibc. Would have the advantage that "sanitized"
>> binaries compiled from current and older clang/gcc versions will work
>> 2) adopt the fixed from upstream [3][4] (possibly more) into clang
>> (and possibly gcc).
>> or maybe both?
>>
>> Kind Regards,
>> Norbert
>>
>> PS. shouldn`t the testsuite catch these bugs?
>>
>> [1] 
>> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f
>> [2] https://llvm.org/bugs/show_bug.cgi?id=27310
>> [3] 
>> https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1078fc7c7da287984a7ba4563390589
>> [4] 
>> https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a6f90b0370a86535cbde6738d0ccf67
>>
>> 2016-10-31 21:43 GMT+01:00 Norbert Lange :
>>> On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru  
>>> wrote:
 Le 31/10/2016 à 00:39, Norbert Lange a écrit :
 > Package: clang-3.9
 > Version: 1:3.9-2
 > Severity: normal
 >
 > Dear Maintainer,
 >
 > The memory sanitizer is unusable as it segfaults during initialization.
 > To reproduce:
 > echo 'int main() { return 0; }' >/tmp/test.c
 > clang -fsanitize=memory -o test test.c
 can you try with clang-3.9 instead?
>>>
>>> Same thing, output:
>>>
>>> $ clang-3.9 -fsanitize=memory -o test test.c -v
>>> clang version 3.9.0-2 (tags/RELEASE_390/final)
>>> Target: x86_64-pc-linux-gnu
>>> Thread model: posix
>>> InstalledDir: /usr/bin
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.2.0
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
>>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.2.0
>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
>>> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>>> Candidate multilib: .;@m64
>>> Candidate multilib: 32;@m32
>>> Candidate multilib: x32;@mx32
>>> Selected multilib: .;@m64
>>>  "/usr/lib/llvm-3.9/bin/clang" -cc1 -triple x86_64-pc-linux-gnu
>>> -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
>>> -discard-value-names -main-file-name test.c -mrelocation-model static
>>> -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
>>> -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu
>>> x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
>>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0 -internal-isystem
>>> /usr/local/include -internal-isystem
>>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
>>> -internal-externc-isystem /usr/include/x86_64-linux-gnu
>>> -internal-externc-isystem /include -internal-externc-isystem
>>> /usr/include -fdebug-compilation-dir /tmp -ferror-limit 19
>>> -fmessage-length 135 -fsanitize=memory
>>> -fsanitize-blacklist=/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/msan_blacklist.txt
>>> -fno-assume-sane-operator-new -fobjc-runtime=gcc
>>> -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-2d4d2c.o -x
>>> c test.c
>>> clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target
>>> x86_64-pc-linux-gnu
>>> ignoring nonexistent directory "/include"
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>>  

Bug#826297: really should document the Debian way to create /shutdown-log.txt

[積丹尼 Dan Jacobson]

found 826297 232-3
retitle 826297 really should document the Debian way to create /shutdown-log.txt
thanks

Many Debian users will read
https://freedesktop.org/wiki/Software/systemd/Debugging/#diagnosingshutdownproblems
and scratch their heads about why no /shutdown-log.txt is produced.

Therefore, please in /usr/share/doc/systemd/README.Debian.gz at
Debugging boot/shutdown problems
mention the *Debian way* of making /shutdown-log.txt,
namely just without the /usr prepended to
/lib/systemd/system-shutdown/debug.sh !

P.S., won't the advice
'For shutdown problems, run "systemctl start debug-shell" as root, then shut 
down.'
often just make something that flies off the screen and then the computer
goes blank? Hence you really need to document the method to make
/shutdown-log.txt !

P.P.S., also please mention any hazards to leaving
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=10M enforcing=0
on the kernel command line and always producing /shutdown-log.txt just
in case one time one would like to look at it. Will the system run
slower etc.?

Bug#842642: clang-3.9: memory sanitizer segfaults immediately

[Norbert Lange]

Tags: patch


Hi,

I got it working, seems that from the 3 related patched, one is already applied.
The attached archive is the 3 patches and a edited "series" file,
it should be painless for you to integrate it into the debian/patches
directory for 3.9

I did not try with 3.8 yet (possibly more difficult), building llvm
takes quite a while.

Kind Regards,
Norbert

2016-11-09 11:04 GMT+01:00 Norbert Lange :
> Hi,
>
> researched a bit further and the same compiled programm will run fine
> on debian jessie.
> I tracked it down to being caused by a newer glibc version [1][2],
> apparently during loading of shared libs, glibc can now allocate
> memory which messes up sanitzers (mostly in more subtile ways than the
> memory sanitizer).
>
> The result is, that if stretch will ship with the current glibc, clang
> and gcc (I dont think its patched there either), then the sanitizers
> won`t be usable.
> 1) revert the fix in glibc. Would have the advantage that "sanitized"
> binaries compiled from current and older clang/gcc versions will work
> 2) adopt the fixed from upstream [3][4] (possibly more) into clang
> (and possibly gcc).
> or maybe both?
>
> Kind Regards,
> Norbert
>
> PS. shouldn`t the testsuite catch these bugs?
>
> [1] 
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f
> [2] https://llvm.org/bugs/show_bug.cgi?id=27310
> [3] 
> https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1078fc7c7da287984a7ba4563390589
> [4] 
> https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a6f90b0370a86535cbde6738d0ccf67
>
> 2016-10-31 21:43 GMT+01:00 Norbert Lange :
>> On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru  
>> wrote:
>>> Le 31/10/2016 à 00:39, Norbert Lange a écrit :
>>> > Package: clang-3.9
>>> > Version: 1:3.9-2
>>> > Severity: normal
>>> >
>>> > Dear Maintainer,
>>> >
>>> > The memory sanitizer is unusable as it segfaults during initialization.
>>> > To reproduce:
>>> > echo 'int main() { return 0; }' >/tmp/test.c
>>> > clang -fsanitize=memory -o test test.c
>>> can you try with clang-3.9 instead?
>>
>> Same thing, output:
>>
>> $ clang-3.9 -fsanitize=memory -o test test.c -v
>> clang version 3.9.0-2 (tags/RELEASE_390/final)
>> Target: x86_64-pc-linux-gnu
>> Thread model: posix
>> InstalledDir: /usr/bin
>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.2.0
>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.2.0
>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
>> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>> Candidate multilib: .;@m64
>> Candidate multilib: 32;@m32
>> Candidate multilib: x32;@mx32
>> Selected multilib: .;@m64
>>  "/usr/lib/llvm-3.9/bin/clang" -cc1 -triple x86_64-pc-linux-gnu
>> -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
>> -discard-value-names -main-file-name test.c -mrelocation-model static
>> -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
>> -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu
>> x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0 -internal-isystem
>> /usr/local/include -internal-isystem
>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
>> -internal-externc-isystem /usr/include/x86_64-linux-gnu
>> -internal-externc-isystem /include -internal-externc-isystem
>> /usr/include -fdebug-compilation-dir /tmp -ferror-limit 19
>> -fmessage-length 135 -fsanitize=memory
>> -fsanitize-blacklist=/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/msan_blacklist.txt
>> -fno-assume-sane-operator-new -fobjc-runtime=gcc
>> -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-2d4d2c.o -x
>> c test.c
>> clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target
>> x86_64-pc-linux-gnu
>> ignoring nonexistent directory "/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  /usr/local/include
>>  /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
>>  /usr/include/x86_64-linux-gnu
>>  /usr/include
>> End of search list.
>>  "/usr/bin/ld" --hash-style=both --eh-frame-hdr -m elf_x86_64
>> -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test
>> 

Bug#843937: syslog-ng: Error opening include file; filename='/usr/share/include/scl/system/tty10.conf', depth='1'

[J Mo]

Package: syslog-ng
Version: 3.8.1-5
Severity: important

This build is obviously broken by default.

Please test new builds with the default config before shipping them out.

Nov 09 18:53:14.197521 testhost1 syslog-ng[3968]:
[2016-11-09T18:53:14.196635] WARNING: Configuration file format is too
old, syslog-ng is running in compatibility mode Please update it
Nov 09 18:53:14.250931 testhost1 syslog-ng[3968]:
[2016-11-09T18:53:14.250015] Error opening include file;
filename='/usr/share/include/scl/system/tty10.conf', depth='1'
Nov 09 18:53:14.251509 testhost1 syslog-ng[3968]:
[2016-11-09T18:53:14.250100] Include file/directory not found;
filename='/usr/share/include/scl/system/tty10.conf', include-path='/etc/
Nov 09 18:53:14.252070 testhost1 syslog-ng[3968]: Error parsing pragma,
Error including /usr/share/include/scl/system/tty10.conf in
/etc/syslog-ng/syslog-ng.conf at line 3, column 10:
Nov 09 18:53:14.252536 testhost1 syslog-ng[3968]: @include
"`scl-root`/system/tty10.conf"
Nov 09 18:53:14.252981 testhost1 syslog-ng[3968]:
^^
Nov 09 18:53:14.253435 testhost1 syslog-ng[3968]: syslog-ng
documentation:
http://www.balabit.com/support/documentation/?product=syslog-ng
Nov 09 18:53:14.254010 testhost1 syslog-ng[3968]: mailing list:
https://lists.balabit.hu/mailman/listinfo/syslog-ng
Nov 09 18:53:14.254787 testhost1 syslog-ng[3968]: Error parsing config,
syntax error, unexpected LL_ERROR, expecting $end in
/etc/syslog-ng/syslog-ng.conf at line 3, column 1:
Nov 09 18:53:14.255296 testhost1 syslog-ng[3968]: @include
"`scl-root`/system/tty10.conf"
Nov 09 18:53:14.255947 testhost1 syslog-ng[3968]: ^
Nov 09 18:53:14.256401 testhost1 syslog-ng[3968]: syslog-ng
documentation:
http://www.balabit.com/support/documentation/?product=syslog-ng
Nov 09 18:53:14.256918 testhost1 syslog-ng[3968]: mailing list:
https://lists.balabit.hu/mailman/listinfo/syslog-ng




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

Kernel: Linux 4.7.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 syslog-ng depends on:
ih  syslog-ng-core 3.8.1-5
iu  syslog-ng-mod-json 3.8.1-5
iu  syslog-ng-mod-mongodb  3.8.1-5
iu  syslog-ng-mod-sql  3.8.1-5

Versions of packages syslog-ng recommends:
iu  syslog-ng-mod-add-contextual-data  3.8.1-5
iu  syslog-ng-mod-amqp 3.8.1-5
iu  syslog-ng-mod-geoip3.8.1-5
iu  syslog-ng-mod-graphite 3.8.1-5
ii  syslog-ng-mod-journal  3.8.1-5
iu  syslog-ng-mod-python   3.8.1-5
iu  syslog-ng-mod-redis3.8.1-5
iu  syslog-ng-mod-riemann  3.8.1-5
iu  syslog-ng-mod-smtp 3.8.1-5
iu  syslog-ng-mod-stomp3.8.1-5

syslog-ng suggests no packages.

-- no debconf information

Bug#843532: [Pkg-dns-devel] Bug#843532: dnssec-trigger: broken by OpenSSL 1.1.0

[Sebastian Andrzej Siewior]

On 2016-11-10 12:10:41 [+0100], Ondřej Surý wrote:
> Sebastian,

Hi Ondřej,

> thanks for the patch. The 0.13~svn685-7 version in unstable includes
> your patch,
> and I would really appreciate if someone could test whether
> dnssec-trigger now
> works.

I managed to get around to test it. So the initial error is gone - the
daemon can be started. Are going the forward the two patches upstream or
should I do it?

> Ondrej

Sebastian

Bug#843512: Bug#843511: libqt5widgets5: Some Qt applications segfault on startup

[Alf Gaida]

Control: severity -1 normal
> However, with no additional dependency being added, this means Qt 5.7
> will move to testing before the new lxqt-qtplugin does, breaking every
> LXQt out there -- correct?
May be, but both packages will migrate in the same cycle or a cycle 
later. So it will eventually break some systems - and these systems can 
be repaired a) with purging lxqt-plugins b) waiting c) take 
lxqt-qtplugins from sid for the time being.


We are aware of the possible breaks, but we will find a solution in Qt 
upstream or Qt packaging before the stable release to picking up the 
qt-abi dependency correctly.

Bug#828556: sslscan: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-11-10 12:10:04 [+0200], Adrian Bunk wrote:
> On Thu, Sep 01, 2016 at 09:55:46PM +0200, Sebastian Andrzej Siewior wrote:
> > control: forwarded -1 https://github.com/rbsec/sslscan/issues/108
> 
> Sebastian, Marvin, what is the status regarding getting this patch that 
> was applied upstream included in Debian?

Adrian: which patch?
Marvin: unless Adrian pulls out a patch I suggest you prepare a package
to build against libssl1.0-dev. I have currently no better suggestion. I
can sponsor the upload if you want me to.

> Thanks
> Adrian

Sebastian

Bug#843936: Need newer iwlwifi firmware for Linux 4.9-rc kernels

[Josh Triplett]

Package: firmware-iwlwifi
Version: 20160824-1
Severity: normal

The iwlwifi driver in Linux 4.9-rc kernels and newer, as packaged in
experimental, no longer supports the versions of the 7265D firmware (and
likely others) packaged in firmware-iwlwifi.  Please consider updating
firmware-iwlwifi to include iwlwifi-7265D-26.ucode .

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.125

-- no debconf information

Bug#843784: [Openjdk] Bug#843784: openjdk-7-jre: After last security update, icedtea-plugin fails all applets

[Tiago Daitx]

Hi Alain,

Please try out the deb files @
https://keybase.pub/tdaitx/icedtea-web-1.6.2/ and let me know if they
do solve the problem.

If they don't, I would need you to point me to a public online applet
that was known to work on the older openjdk version and is now failing
on the new one, otherwise I'm stuck as I have no way to reproduce the
issue.

-thanks

Bug#842326: ncmpc: NMU uploaded in deferred/queue

[Sebastian Harl]

Hi,

On Thu, Nov 10, 2016 at 08:34:44AM +0100, Gianfranco Costamagna wrote:
> On Mon, 31 Oct 2016 14:26:57 +0100 Gianfranco Costamagna 
>  wrote:
> > I uploaded the following NMU in deferred/10, please let me know if I can 
> > speed it up or cancel it
> > 
> > Attaching the debdiff for the new release (mostly autoconf fixes), and the 
> > filtered debdiff for the debian directory.
> > 
> 
> attaching the new debdiffs, since I forgot to close this bug

Thank you very much for taking care of this.

Merged as https://git.tokkee.org/?p=pkg-ncmpc.git;h=ncmpc-0.25-0.1

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#843935: "ReferenceError: $ is not defined" when opening "Server side filters" tab

[Willem Mulder]

Package: xul-ext-sieve
Version: 0.2.3h+dfsg-1
Severity: normal

Dear Maintainer,

I just installed the addon, but when I open the "Server side filters"
tab in the "Message filters" window in Thunderbird, it shows the
following error:

ReferenceError: $ is not defined
chrome://sieve/content/libs/libSieveDOM/SieveSimpleGui.html 48

Connecting through Account Settings -> Sieve settings -> Edit filters...
works properly.


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

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

Versions of packages xul-ext-sieve depends on:
ii  icedove   1:45.4.0-1
ii  libjs-jquery  1.12.4-1

xul-ext-sieve recommends no packages.

xul-ext-sieve suggests no packages.

-- no debconf information




signature.asc
Description: OpenPGP digital signature

Bug#843890: apt install limitcpu

[Thomas Grainger]

> At any rate, I don't think the Debian cpulimit package can be "upgraded"
to CPUlimit on GitHub.

Sorry I used the term "upgrade" because I didn't know about the two
packages.

> 4. The new CPULimit includes some nice features like tracking child
processes.

I do need this feature for cpulimit (I'm trying to stop sbt  (SBT build
tool) slowing down the rest of my machine)

> Yes, it's a confusing mess.

Not enough of a confusing mess for me: perhaps GitHub's cpulimit could be
released as limitcpu?

Bug#841348: Request to Steam to fix the issue

[Gabriel Mainberger]

The issue is resolved in the package version 1.0.0.52-3.

Bug#821114: nginx: Please use KillSignal=SIGQUIT in systemd service

[Michael Biebl]

On Tue, 8 Nov 2016 11:20:45 +0200 Christos Trochalakis
 wrote:
> On Fri, Apr 15, 2016 at 06:54:55PM +0200, Laurent Bigonville wrote:
> >Package: nginx
> >Version: 1.6.2-3
> >Severity: normal
> >User: pkg-systemd-maintain...@lists.alioth.debian.org
> >
> >Hi,
> >
> >Wouldn't it be better to use KillSignal=SIGQUIT in the .service file
> >rather than using this hack?
> >
> >ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile 
> >/run/nginx.pid
> >
> >Is it necessary really necessary to send QUIT, then TERM and then KILL?
> >
> 
> By using KillSignal=SIGQUIT systemd would forcibly (SIGKILL) nginx after
> the timeout is reached.
> 
> SIGQUIT triggers graceful shutdown so it waits for all existing client
> connections to terminate. If for example you have websocket or SSE long
> running clients you will hit the timeout. In such cases we don't want
> systemd to SIGKILL nginx.
> 
> The current solution fallbacks to SIGTERM that forces systemd to close
> existing clients and terminate.
> 
> 

Would
ExecStop=/bin/kill -QUIT $MAINPID

work?
This would first send SIQUIT to the main process, after TimeoutStopSec=
it would send SIGTERM to all remaining processes and after another
TimeoutStopSec=, SIGKILL.
Is this the behaviour you want?

It feels a bit more systemdish to me then involving start-stop-daemon


-- 
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#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas, Petter and all,

On 10.11.2016 21:07, Andreas Tille wrote:
> So I confirm that the first problem we detected is solved but there is
> another one breaking Debian Edu.  I have again no suspicion why the '\'
> sign is not elimiunated from the list only in those few cases.

I can also just "poke in the fog" here. I thought that the multilines
were already eaten up by lines 537-544, and should not appear again
here. However, they do, as my "print" debugger shows. Perlists, please
help!!!

The pragmatic solution here is to just remove the backslashes from the
end of line. I can commit a patch that does this.

However, debian-edu keeps to be broken. Reason is that the tasks contain
lines like (development)

Depends: fp-compiler, [...multiline... ], fp-units-fv
Depends: lazarus

so, with two "Depends" in one section. Or (electronics):

Depends: qucs, gpsim, oregano
Recommends: education-menus, xoscope
Suggests: kicad, kicad-doc-en, kicad-doc-de, kicad-doc-es, kicad-doc-fr
Suggests: electric, pcb, xcircuit, freehdl, gtkwave
Responsible: ?
NeedConfig:  no

two "Suggests". This does not work anymore (no idea why), but is also
IMO forbidden by RFC834.

I have no idea why this works without RFC834 continuation, but not with
them.

On the other hand, we *win* one more dependency: in "common", the
"firmware-ralink" dependency line was *not* preceded one with a
backslash. This shows that the backslash is just a bad idea for
continuation lines.

--> debian-edu tasks are just broken. They don't follow any rule, and
depending from the parser one will get always different results. Maybe
we should fix that? remove all backslash continuation lines and
duplicated keywords from the tasks files?

Best regards

Ole

Bug#843890: CPULimit upgrade

[gregor herrmann]

On Thu, 10 Nov 2016 10:02:01 -0400, Jesse Smith wrote:

> I am the maintainer of LimitCPU, the software currently packaged in
> Debian as CPUlimit and I'd like to weigh in and clear up a few things.

Hi Jesse,

I continue to be amazed by the speed you respond to bugs in the
Debian BTS!

Thanks for the complete and accurate summary of the situation. I have
nothing to add, just one comment from my point of view:
 
> Personally, I'd rather work with the Debian maintainers to keep LimitCPU
> as the upstream project and try to sort out bugs and missing features. I
> think that will provide a smoother path forward with less work, but I'm
> naturally biased.

I share your bias :)

I very much appreciate the excellent cooperation with you, and I
don't see any point in switching to the new cpulimit version or in
packaging both. Although the situation with cpulimit (old) and
limitcpu (packaged as cpulimit) and cpulimit (new) is a bit
confusing, in my opinion every alternative to continuing with
limitcpu would result in an even bigger mess and more confusion for
no visible gain for our users.

Thanks again for all your work!


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Beatles


signature.asc
Description: Digital Signature

Bug#843922: stockfish: FTBFS: g++: error: unrecognized command line option '-m32'

[Milan Zamazal]

Thanks for the report.  I changed the default build architecture to
general-64, I guess that's a good default these days.  Let's see what
happens (I'm afraid this package will require a bit more experiments
before it builds on all architectures, sorry about that).

Regards,
Milan

-- 
http://www.zamazal.org

Bug#837186: Loading certain (SSL?) sites like google.com and facebook.com aborts

[Christopher Sasarak]

Package: firefox-esr
Version: 45.4.0esr-2
Followup-For: Bug #837186

Dear Maintainer,

This bug also exists for me, sometimes the page will also load but some assets 
like CSS are missing 
so the page looks totally wrong. I'm not sure what this means either, but the 
problem
also exists when I run a copy of Firefox 49 (without EME) that I got from 
Mozilla. 

If I download a page using Curl there's no problem with SSL, nor did I see a 
problem in Midori
when I tried to go to a page which breaks in firefox. 



-- Package-specific info:

-- Extensions information
Name: ADB Helper
Location: ${PROFILE_EXTENSIONS}/adbhel...@mozilla.org
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: enabled

Name: Firefox Hello Beta
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: Greasemonkey
Location: ${PROFILE_EXTENSIONS}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}.xpi
Status: enabled

Name: Html Validator
Location: ${PROFILE_EXTENSIONS}/{3b56bcc7-54e5-44a2-9b44-66c3ef58c13e}
Status: enabled

Name: HTTPS Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org.xpi
Status: enabled

Name: REST Easy
Location: ${PROFILE_EXTENSIONS}/rest-e...@quickmediasolutions.com.xpi
Status: enabled

Name: Shumway
Location: ${PROFILE_EXTENSIONS}/shum...@research.mozilla.org
Status: app-disabled

Name: Tab Groups
Location: ${PROFILE_EXTENSIONS}/tabgro...@quicksaver.xpi
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: uMatrix
Location: ${PROFILE_EXTENSIONS}/umat...@raymondhill.net.xpi
Status: enabled

Name: User-Agent Switcher
Location: ${PROFILE_EXTENSIONS}/jid1-kyxeacwua7b...@jetpack.xpi
Status: enabled

Name: Valence
Location: ${PROFILE_EXTENSIONS}/fxdevtools-adapt...@mozilla.org
Status: enabled

Name: VimFx
Location: ${PROFILE_EXTENSIONS}/vi...@akhodakivskiy.github.com.xpi
Status: enabled

Name: XPath Checker
Location: ${PROFILE_EXTENSIONS}/{7eb3f691-25b4-4a85-9038-9e57e2bcd537}.xpi
Status: enabled

-- Plugins information
Name: GNOME Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled


-- Addons package information
ii  firefox-esr45.4.0esr-2  amd64Mozilla Firefox web browser - Ext
ii  gnome-shell3.22.1-1 amd64graphical shell for the GNOME des
ii  icedtea-8-plug 1.6.2-3  amd64web browser plugin based on OpenJ
ii  rhythmbox-plug 3.4.1-2  amd64plugins for rhythmbox music playe

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-5
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.12-1
ii  libdbus-glib-1-2  0.108-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.0-10
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.1-1
ii  libgtk2.0-0   2.24.31-1
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.3-2
ii  libsqlite3-0  3.15.0-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.2.0-10
ii  libvpx4   1.6.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.2-1
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-2
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages firefox-esr recommends:
ii  gstreamer1.0-libav 1.10.0-1
ii  gstreamer1.0-plugins-good  1.10.0-1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-3
pn  libgnomeui-0   
ii  libgssapi-krb5-2   

Bug#843934: ITP: django-redis-sessions -- Redis database backend for your sessions

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: django-redis-sessions
  Version : 0.5.6
  Upstream Author : Martin Rusev 
* URL : http://github.com/martinrusev/django-redis-sessions
* License : BSD
  Programming Lang: Python
  Description : Redis database backend for your Django sessions

 Session backend for Django that stores sessions in a Redis database 

I intend to maintain this within the Debian Python Modules Team.

Bug#843933: sbuild: include generated .buildinfo contents in the build log

[Niko Tyni]

Package: sbuild
Version: 0.72.0-2
Severity: wishlist
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Now that dpkg-buildpackage generates .buildinfo files by default, it
would be nice if sbuild included them in the build log like it does for
the .changes file and the binary package contents.

Many thanks for your work,
-- 
Niko Tyni   nt...@debian.org

Bug#827339: Please revert patch for cmd, and fix default pattern

[Thomas Liske]

Hi,

this is a negative lookbehind assertion - quoting from perlre(1):

   "(? writes:

> Am 30.10.2016 um 12:31 schrieb Stephan Sürken:
>> Hi Evgeni, Patrick,
>>
>> fwiw (probably this is already worked on), i have fixed up my system by
>>
>> * reverting 01-grep-syntax-error.diff
>>
>> This actually totally breaks things, as this now uses "P" as pattern,
>> practically matching always:
>>
>> --
>> grep -aiqseP "$AD_HIST_ERRPATTERN" "$AD_HIST_PATH/typescript"
>> --
>>
>> I would actually like to see call grep (in the cmd script) called like so
>>
>> --
>> grep -a -q -i -s -P -e "$AD_HIST_ERRPATTERN" "$AD_HIST_PATH/typescript"
>> --
>>
>> (however, '-aiqsPe' should work as well).
>>
>> * Use custom err-pattern
>>
>> I don't really know what's wrong with the default perl regex (should
>> the '' stuff be actually be in the final string?), I am just using
>> a simpler one now that works. On a shell you can see the error via
>>
>> --
>> grep -P -e '((?!no )error|(?!insserv: )warning|fail(ed)?)'
>> --
>>
>> (That's the same string you also see in the "meta" debug file, using
>> all defaults for err-pattern).
>>
>> So for me it seems:
>>
>> * With the default pattern in place (and pre-patch), the grep would
>> always fail, meaning it would never detect an actual error in
>> typescript.
>> * With the broken patch, it always wrongly finds errors (while showing
>> an empty log via less).
>>
>> So please remove 01-grep-syntax-error.diff, and somehow fix the default
>> pattern ;).
>>
>> Hth!
>>
>> S
> I already noticed, that my patch always matches and removed it in my
> vcs. On my cmd it worked..
> Anyway with "grep -a -q -i -s -P -e" and "grep -P -e '((?!no
> )error|(?!insserv: )warning|fail(ed)?)'" I get again a syntax error
> on jessie. Maybe Thomas could say us, what he wanted to match and how we
> should fix it now.
>
> -- 
> /*
> Mit freundlichem Gruß / With kind regards,
>  Patrick Matthäi
>  GNU/Linux Debian Developer
>
>   Blog: http://www.linux-dev.org/
> E-Mail: pmatth...@debian.org
> patr...@linux-dev.org
> */
>

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#843922: stockfish: FTBFS: g++: error: unrecognized command line option '-m32'

[Sven Joachim]

On 2016-11-10 21:41 +0100, Milan Zamazal wrote:

> Thanks for the report.  I changed the default build architecture to
> general-64, I guess that's a good default these days.

I haven't looked at the stockfish source, but I can imagine that this is
not going to improve the situation on 32-bit arches.  If the config
machinery cannot find out the pointer size by itself, dpkg-architecture
provides DEB_HOST_ARCH_BITS for you.

Cheers,
   Sven

Bug#843932: dev-pkg-without-shlib-symlink: Please consider *.so links in /lib

[Martin Pitt]

Package: lintian
Version: 2.5.49

Hello,

libsystemd-dev currently ships

  /lib/x86_64-linux-gnu/libsystemd.so -> libsystemd.so.0.17.0

as the development/compiler symlink. This causes a a lintian warning
[1] about dev-pkg-without-shlib-symlink, apparently because lintian
only checks for the *.so symlink in /usr. It justifies that with the
policy 8.4 [2], but contrary to what the lintian help says there is
not actually a requirement for the *.so symlink to be in /usr, just
that it must exists. The example just happens to have both the library
and the .so symlink in /usr as that's certainly the common case.

I don't see any technical reason why a *.so symlink in /lib would be
bad. It most certainly works (gcc/ld look there), the cost is
negligible (just one inode more on the root partition), and with
merged /usr it doesn't matter at all.

The main reason why it matters is that apparently automake has no
declarative method (that we know of) to put the library into /lib but
the *.so into /usr/lib. This leads to hacks and hard to
maintain/understand code like [3]. If there is a declarative/easy
solution I'd be interested in hearing it. But independently of that,
I would like to ask you to reconsider this lintian check.

Thanks,

Martin

[1] 
https://lintian.debian.org/maintainer/pkg-systemd-maintain...@lists.alioth.debian.org.html#systemd
[2] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev
[3] https://github.com/systemd/systemd/pull/4585/files
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

[Bálint Réczey]

Hi Mark,

2016-09-07 14:29 GMT+02:00 Mark Sumner :
> Hi,
> I had this issue using version 3.16.0-1 and it still occurs for me now that I
> have updated to 3.16.2-1:
>
> 2:~$ mkdir /tmp/fake-home meld

The meld here seems to be obsolete.

> 2:~$ cp .Xauthority /tmp/fake-home/
> 2:~$ HOME=/tmp/fake-home meld
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/meld/meldapp.py", line 72, in 
> do_startup
> self.new_window()
>   File "/usr/lib/python2.7/dist-packages/meld/meldapp.py", line 138, in 
> new_window
> window = meldwindow.MeldWindow()
>   File "/usr/lib/python2.7/dist-packages/meld/meldwindow.py", line 266, in 
> __init__
> self.widget.set_help_overlay(shortcut_window)
> AttributeError: 'ApplicationWindow' object has no attribute 'set_help_overlay'
...

Could not reproduce it with 3.16.3-1 on latest stretch.

Cheers,
Balint

Bug#821642: Bumping severity of PHP 7.0 transition bugs to serious

[Sebastiaan Couwenberg]

On Thu, 5 May 2016 10:20:57 +0200 Ondřej Surý wrote:
> I am bumping the severity of this bug to serious, as we are going to
> remove src:php5 from Debian and your package is blocking the first
> step which is removal of php5 from testing.  Please either update your
> package to support PHP 7.0 or remove the package from Debian unstable
> alltogether.

Since upstream has no plans for PHP 7 support [0],
removing pnp4nagios from unstable is the best option.

[0] https://github.com/lingej/pnp4nagios/issues/125

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#842112: digikam: Export menu does not open - workaround

[Łukasz Michalak]

I had the same issue on my setup.
Installing kipi-plugins package solved the problem for me.
Shouldn't kipi-plugins be in dependencies of digikam package?

Regards,
Łukasz Michalak

Bug#784451: Do you have resources to look after ball? [progress info]

[Andreas Tille]

Hi Danny,

thanks a lot for your quick response to analyse the problems in the ball
package.  I take the freedom to turn this discussion into a public one
and CC the relevant bugs to leave a record there that something is
happening.

On Thu, Nov 10, 2016 at 03:26:30PM +0100, Danny Edel wrote:
> On 11/09/2016 03:39 PM, Andreas Tille wrote:
> > Sure you can't give a time line.  I think when we start our Advent bug
> > squashing party we need to tackle it somehow - but having this sorted
> > out before to enable some testing would be great.
> 
> I have had some time to look into this, there are three failures, and
> all are perfectly reproducible.  Investigating (with core dumps) revealed:
> 
> 1. PoseClustering_Test depends on verbatim boost::serialisation output,
> which changes with every library version update.  Upstream has already
> fixed this by ignoring the actual file contents, and instead feeding the
> file to the de-serializer and check if the resulting object compares equal.

Sounds good.
 
> 2. DefaultProcessors_test segfaults after trying to use an optimized-out
> variable.  This looks like a legitimate upstream bug to me.
> 
> 3. XDRPersistenceManager_test segfaults after following a null pointer.
> Also looks like an upstream bug.
> 
> While backporting the fix for (1) is straightforward, the code paths
> responsible for (2) and (3) have seen quite some activity in the
> meantime, with the relevant commits changing lots of other files.

Hmmm, may be we should base the packaging on a later upstream commit?

> Among
> other things, upstream also migrated from Qt4 to Qt5, and incorporated a
> few fixes for recent boost.

We somehow should target to Qt5 anyway (see #784451) better sooner than
later.
 
> I tried building upstream master to see if it still contained the bugs.
> It did not, however one other test fails
> (AssignBondOrderProcessor_Test), which is related to upstream issue 576.
> 
> I will try to isolate and backport fixes for the three issues, and
> report back afterwards.

Again thanks a lot for your contribution

 Andreas.

-- 
http://fam-tille.de

Bug#843931: libgtkdatabox-0.9.3-0-{, lib}glade: fails to upgrade from 'testing' - trying to overwrite /usr/lib/glade/modules/libgladedatabox.a, ...

[Andreas Beckmann]

Package: libgtkdatabox-0.9.3-0-glade,libgtkdatabox-0.9.3-0-libglade
Version: 1:0.9.3.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

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

  Selecting previously unselected package libgtkdatabox-0.9.3-0-glade.
  Preparing to unpack 
.../libgtkdatabox-0.9.3-0-glade_1%3a0.9.3.0+dfsg-1_amd64.deb ...
  Unpacking libgtkdatabox-0.9.3-0-glade (1:0.9.3.0+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libgtkdatabox-0.9.3-0-glade_1%3a0.9.3.0+dfsg-1_amd64.deb
 (--unpack):
   trying to overwrite '/usr/lib/glade/modules/libgladedatabox.a', which is 
also in package libgtkdatabox-0.9.2-0-glade 1:0.9.2.0+dfsg-1

  Selecting previously unselected package libgtkdatabox-0.9.3-0-libglade.
  Preparing to unpack 
.../libgtkdatabox-0.9.3-0-libglade_1%3a0.9.3.0+dfsg-1_amd64.deb ...
  Unpacking libgtkdatabox-0.9.3-0-libglade (1:0.9.3.0+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libgtkdatabox-0.9.3-0-libglade_1%3a0.9.3.0+dfsg-1_amd64.deb
 (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libglade/2.0/libdatabox.a', 
which is also in package libgtkdatabox-0.9.2-0-libglade 1:0.9.2.0+dfsg-1


cheers,

Andreas


libgtkdatabox-0.9.2-0-glade=1%0.9.2.0+dfsg-1_libgtkdatabox-0.9.3-0-glade=1%0.9.3.0+dfsg-1.log.gz
Description: application/gzip

Bug#843558: squidguard: Problem in update-squidguard and tabs in squidguard.conf

[Joachim Wiedorn]

Hello Wolfgang,


Wolfgang Hotwagner wrote on 2016-11-07 18:26:

> I have a tab instead of a whitespace in my squidguar.conf in the following 
> line:
> dbhome/var/lib/squidguard/db

That is a classic failure. Please use whitespaces as shown in the example
config file. Perhaps I will add a workaround for that in the future, but
for definite work of the configuration you should always use the defined
rules of a specific config file to don't get errors.

---
Have a nice day.

Joachim (Germany)


pgppNrhEciZsM.pgp
Description: Digitale Signatur von OpenPGP

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Andreas Tille]

Hi,

On Thu, Nov 10, 2016 at 01:53:20PM +0100, Ole Streicher wrote:
> >
> > gbp clone ssh://git.debian.org/git/blends/projects/med.git
> > cd med
> > make dist
> > grep ^, debian/control

Debian Med and Debian Science are OK with the patch, however:

   gbp clone ssh://git.debian.org/git/debian-edu/debian-edu.git
   cd debian-edu
   make dist
   grep '\\' debian/control | head
Suggests: \ cpqarrayd,
 \ isag,
 \ lshw,
Suggests: \  gnome-accessibility-themes,
Suggests: \ kde-full,
 \ kdeaccessibility,
 \ kdegraphics-thumbnailers,
 \ kdf,
 \ kfloppy,
 \ kinfocenter,

So for some reason in the Debian Edu case '\' signs will not be
ignored but added to the d/control file.

> This is what I meant, and it is fixed by my last commit. Please try
> again ;-)

So I confirm that the first problem we detected is solved but there is
another one breaking Debian Edu.  I have again no suspicion why the '\'
sign is not elimiunated from the list only in those few cases.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#841373: (no subject)

[Marcos Mobley]

just adding this to the report to help those who find it and want a
working alternative. hope that's okay.

https://gist.github.com/ruario/215c365facfe8d3c5071




signature.asc
Description: OpenPGP digital signature

Bug#840566: bash uses over 1 GB of memory

[Claus Färber]

I ran into the same issue. After increasing swap, I am now able to login again.

However, every bash process now uses over 1 GB of virtual memory:

18541 pts/2Ss 0:00241  1021 1069166 4828  0.4 /bin/bash
18553 pts/3Ss 0:01120  1021 1069234 1628  0.1 /bin/bash
18639 pts/4Ss+0:01 22  1021 1069166 6740  0.6 /bin/bash
18647 pts/2S+ 0:01 76  1021 1069170 740240 72.5 bash

It seems that there is some typo that causes bash to allocate 800 MB + 8 Bytes 
instead of just 8 Bytes ("xmalloc: cannot allocate 80008“), and this fails 
on systems with limited memory.

Bug#843874: dpkg: segfaults installing desktop-base 9.0.0~exp1 on amd64

[Andreas Beckmann]

On 2016-11-10 16:34, Guillem Jover wrote:
>> If you can still reproduce at will, I might like to provide a patch to
>> make sure the fix works for you? If you could test this, probably
>> later today, that'd be awesome!
> 
> Ok, it was too trivial to leave alone. :) Attached the proposed patch.

That seems to work:

# ./dpkg-buggy --configure --pending
Setting up desktop-base (9.0.0~exp1) ...
dpkg: error processing package desktop-base (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
Segmentation fault

# ./dpkg-fixed --configure --pending
Setting up desktop-base (9.0.0~exp1) ...
dpkg: error processing package desktop-base (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 desktop-base

and I can run an arbitrary sequence of these two commands and get
always the same output.


Andreas

Bug#843930: dh_installinit generates code for non-existing init script

[Michael Biebl]

Package: debhelper
Version: 10.2.2
Severity: normal
File: /usr/bin/dh_installinit

The urfkill package ships a systemd service file, but not SysV init
script. Still, dh_installinit generates code to run update-rc.d and
invoke-rc.d.

This results in
https://lintian.debian.org/maintainer/ken...@lexical.tw.html#urfkill

I've attached the generated maintainer scripts files.



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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 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 debhelper depends on:
ii  autotools-dev20160430.1
ii  binutils 2.27.51.20161108-1
ii  dh-autoreconf12
ii  dh-strip-nondeterminism  0.028-1
ii  dpkg 1.18.13
ii  dpkg-dev 1.18.13
ii  file 1:5.29-1
ii  libdpkg-perl 1.18.13
ii  man-db   2.7.5-1
ii  perl 5.24.1~rc3-3
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information
# Automatically added by dh_systemd_start
if [ -d /run/systemd/system ]; then
deb-systemd-invoke stop urfkill.service >/dev/null
fi
# End automatically added section
# Automatically added by dh_installinit
if [ -x "/etc/init.d/urfkill" ]; then
invoke-rc.d urfkill stop || exit $?
fi
# End automatically added section
# Automatically added by dh_systemd_start
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
fi
# End automatically added section
# Automatically added by dh_installinit
if [ "$1" = "purge" ] ; then
update-rc.d urfkill remove >/dev/null
fi


# In case this system is running systemd, we make systemd reload the unit files
# to pick up changes.
if [ -d /run/systemd/system ] ; then
systemctl --system daemon-reload >/dev/null || true
fi
# End automatically added section
# Automatically added by dh_systemd_enable
if [ "$1" = "remove" ]; then
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper mask urfkill.service >/dev/null
fi
fi

if [ "$1" = "purge" ]; then
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper purge urfkill.service >/dev/null
deb-systemd-helper unmask urfkill.service >/dev/null
fi
fi
# End automatically added section
# Automatically added by dh_systemd_enable
# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask urfkill.service >/dev/null || true

# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled urfkill.service; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable urfkill.service >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state urfkill.service >/dev/null || true
fi
# End automatically added section
# Automatically added by dh_installinit
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
if [ -x "/etc/init.d/urfkill" ]; then
update-rc.d urfkill defaults >/dev/null
invoke-rc.d urfkill start || exit $?
fi
fi
# End automatically added section
# Automatically added by dh_systemd_start
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
deb-systemd-invoke start urfkill.service >/dev/null || true
fi
# End automatically added section

Bug#763822: FWD: Clarification regarding FTP resource constraints for buildinfo files

[Holger Levsen]

Hi,

actually forwarding this to the bug.

And adding a small note that since August we now have
buildinfo.debian.net, so maybe for a start it would be sufficient if dak
would submit these .buildinfo files via curl/https to buildinfo.d.n!?!

- Forwarded message from Ximin Luo  -

Date: Wed, 24 Aug 2016 13:16:00 +
From: Ximin Luo 
To: ftpmas...@debian.org
Cc: Reproducible Builds discussion list 

Subject: [Reproducible-builds] Clarification regarding FTP resource constraints 
for buildinfo files
Reply-To: Reproducible Builds discussion list 


Hi, I'm emailing to follow-up regarding #763822. I know we have not yet come up
with a concrete proposal on that, and that is largely because we were waiting
for comments regarding the resource constraints of ftp-master and mirrors.

There is broad understanding across the R-B team that you'd prefer a design
that does not involve "lots of small files", but there's a lot of breadth in
this statement, and none of us know the precise details involved. Originally
Lunar proposed a design with 1 large file, but there are issues with this as
well, such as the performance of updates.

Here are our current main requirements as stated by dkg in message #10, and I
confirm they're still accurate as of today:

1. We want an archive user to be able to find and fetch all .buildinfo files 
that produced a given binary package
2. We want the eventual possibility of multiple .buildinfo files per 

3. We understsand that mirror operators don't like small files because rsync 
gets fussy with them.
4. We want both buildds and debian developers to be able to upload .buildinfo 
files.

(4) by itself is easy; people have already written code to allow dak to accept
such files and discard them.

So we need to figure out how to reconcile (1,2,3). For this, it would be good
if you could tell me in more detail what the restriction (3) consists of.

We would never be uploading 10,000k buildinfo files at once, but Mattia tells
me that 1k might happen during medium binNMU transitions, growing up to 4k for
large transitions (but this would be over several days, i.e. split across
multiple runs of dinstall). Each buildinfo file is about 5.4k (median), with
7.7k as the 75% percentile, though the largest is 148k. [1]

There is also the distinction between uploading vs mirroring. Just because we
might upload 1k files over a short time, does not mean that we have to transfer
these to mirrors as 1k files. We could tar some of them up and compress them.

So could you clarify some details regarding upload resource limits, as well as
mirroring resource limits?

For example, is one extra file per source-package OK or "too much"? Or one
extra file per binary upload? How about one extra file-update, of the same
file, per binary upload? (I assume that rsync means we are free to update any
files that we store in pool/, if we need to?)

More clarifications to the above, regarding what we *don't* need:

N1. It's not essential to store 1 uploaded-buildinfo-file per 
file-in-the-archive, as long as we can still do (1).
N2. We don't care particularly about being able to get *a specific 
buildinfo-file*, as long as we can still do (1).
N3. It's OK to over-satisfy (1) with extra irrelevant data, then the user can 
just filter this out locally.

We have more ideas, but I think it's best to keep this email short for now.
Also I don't know what is feasible until I hear more details about the
constraints, and it would be pointless to skip further ahead to potentially
unfeasible things.

X

[1] (use wget, too big for browser) 
https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/?C=S;O=A

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

___
Reproducible-builds mailing list
reproducible-bui...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

- End forwarded message -


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#843929: ming: CVE-2016-9264 CVE-2016-9265 CVE-2016-9266

[Chris Lamb]

Package: ming
Severity: serious
Tags: security

Hi,

the following vulnerabilities were published for ming.

CVE-2016-9264[0]:
global-buffer-overflow in printMP3Headers (listmp3.c)

CVE-2016-9265[1]:
divide-by-zero in printMP3Headers (listmp3.c)

CVE-2016-9266[2]:
left shift in listmp3.c

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9264
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9264
[1] https://security-tracker.debian.org/tracker/CVE-2016-9265
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9265
[2] https://security-tracker.debian.org/tracker/CVE-2016-9266
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9266
Please adjust the affected versions in the BTS as needed.


Regards,

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

Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

On Thu 2016-11-10 04:50:08 -0800, Vincent Lefevre wrote:
> No, this is wrong. In this case, the user isn't necessarily using
> the graphical session.

as far as the graphical session is aware, the user is using it.

> I don't use gnome-keyring, but the dependency on pinentry comes
> from gnupg-agent, which has:
>
> Depends: pinentry-curses | pinentry, [...]
>
> However, pinentry-curses is not installed by default because
> pinentry-gnome3 is already installed via gnome.

yes, via evolution → gnome-keyring.  that's why i'm recommending that
you reassign this bug to gnome-keyring

> Perhaps it should have a Recommends on pinentry-curses or
> pinentry-gtk2 to make sure that by default, pinentry-gnome3 is not the
> only one installed.

No, not pinentry-curses -- pinentry-curses is unable to talk to
gnome-keyring's secretservice.  gnome-keyring should Depend: on pinentry
packages that can talk to the secretservice.  

> IMHO, the correct solution would be to detect whether GNOME is used,
> and with a wrapper, select pinentry-gnome3 in this case, and
> pinentry-gtk2 otherwise when available.

how do you propose to detect whether GNOME is used?  Who will maintain
such a wrapper?

> Note that pinentry-gtk2 remains superior for non-GNOME users (and
> for GNOME users who connect by SSH), because it will still be able
> to display a graphic window (which users may prefer to curses) even
> with SSH + X forwarding, contrary to pinentry-gnome3, if I understand
> correctly.

I beg to differ -- i'm a non-GNOME user and pinentry-gnome3 works quite
well with gcr on my machine.

> Otherwise, test some environment variable(s), either in pinentry-gnome3
> or in Gcr via a communication of the value with pinentry-gnome3 (but
> I think that the communication would be overkill in practice).

Please be concrete.  This back-and-forth is causing me to miss out on
other productive work.

  --dkg


signature.asc
Description: PGP signature

Bug#843928: ming: CVE-2016-9264 CVE-2016-9265 CVE-2016-9266

[Salvatore Bonaccorso]

Source: ming
Version: 1:0.4.4-1.1
Severity: important
Tags: security upstream

Hi,

the following vulnerabilities were published for ming.

The issues cannot be seen directly with the given reproducers
apparently since covered by other issues. But according to Agostine
SArubbo they are found in 0.4.7 and there were no changes from 0.4.5
to 0.4.7 in listmp3.c.

CVE-2016-9264[0]:
global-buffer-overflow in printMP3Headers (listmp3.c)

CVE-2016-9265[1]:
divide-by-zero in printMP3Headers (listmp3.c)

CVE-2016-9266[2]:
left shift in listmp3.c

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9264
[1] https://security-tracker.debian.org/tracker/CVE-2016-9265
[2] https://security-tracker.debian.org/tracker/CVE-2016-9266

Btw, should ming be rather be removed completely from Debian? It is
currently not in testing, and will not be in stretch.

Regards,
Salvatore

Bug#843927: ruby-jquery-ui-rails: symlinks broken

[李健秋]

Package: ruby-jquery-ui-rails
Version: 5.0.5-4
Severity: important

Dear Maintainer,

Please check the symlinks. Most of the symlinks in
/usr/share/ruby-jquery-ui-rails/app/assets/javascripts/ seem broken.

eg:
$ less 
/usr/share/ruby-jquery-ui-rails/app/assets/javascripts/jquery.ui.widget.js
/usr/share/ruby-jquery-ui-rails/app/assets/javascripts/jquery.ui.widget.js:
No such file or directory

Best regards,

-Andrew

Bug#801796: nikola: New upstream release: 7.7.3

[Chris Warrick]

Control: retitle -1 nikola: New upstream release: 7.8.1

Nikola v7.8.1 has been out for 4 weeks. The current Debian package is still
v7.6.4, which was released on 2015-08-22 (over 1 year and 2 months ago).
The Debian package is harmful to Nikola. We get bug reports because of it,
which are about either incompatibilities between versions (plugins assuming
newer Nikola versions), or things we’ve fixed in the past 14 months. Debian
users trust that their repositories have a *good* package, but this is not
the case with Nikola.

Please get your act together and update this package. And if you can’t take
care of a package, why bother maintaining it and having it altogether?
Updating Nikola between versions is generally painless; we might add
dependencies rarely, but we do our best to keep the base requirements list
unchanged.

Yours,
Chris Warrick
Nikola co-maintainer

Bug#822792: your mail

[Michael Lustfield]

On Thu, Nov 10, 2016 at 6:35 AM, Elrond
 wrote:
> On Wed, Nov 09, 2016 at 18:47:15 -0600, Michael Lustfield wrote:
>> I'd like to get something like _provider_php available via php-fpm as well as
>> uwsgi-plugin-php.
>
> Okay, so if an admin only wants to handle local .php files
> on the default server they have to:
>
> 1. Install php-fpm, which then would hopefully bring
>/etc/nginx/conf.d/pkg_php-fpm.conf
>
> 2. Create /etc/nginx/apps.d/local_php.conf
>containing a global .php -> _provider_php entry
>
> Did I get that right?

Yup, if a user is creating a local/custom app, that's what would be expected.

In the same way, apps.d/pkg_drupal7.conf would have whatever php
settings it needs, but then just assume an upstream _provider_php
exists and pass to that.

>> Doing it this way would reduce security, but I'm thinking it's to a very
>> negligible degree and not very concerned.
>
> Could you elaborate on the security issues?

If we were using uwsgi, we could try to chroot/jail the web
application. It, however, prevents nice easy generic providers which
probably make more sense. I don't think this is worth worrying about,
though.

>> > 2. Do we have recommended naming for files added by the
>> >local admin to apps.d?
>>
>> We could suggest custom_.conf.
>
> local_.conf?

I like this better, yes.


I've attached a potential drupal7.conf, but this raises a concern...
php-fpm and uwsgi need different *_pass directives. Since conf.d/* is
loaded first, it might be possible to set a configuration variable.
$provider_php_pass = (uwsgi|proxy)

I don't like that because it means using an if later, but it could work.


pkg_drupal7.conf
Description: Binary data

Bug#843925: dpkg-dev: dpkg-buildpackage should sign buildinfo files

[Ximin Luo]

Package: dpkg-dev
Version: 1.18.13
Severity: important

Dear Maintainer,

We would like dpkg-buildpackage to clearsign the buildinfo files that are
created. This allows them to be uploaded to services similar to keyservers,
for auditing and attestation purposes, that may be run independently of the
FTP archive.

Furthermore, we would like user-side tools to download and perform other
security-related logic on the signed buildinfo files - e.g. being able to see
how many, and exactly who else, managed to *actually reproduce* the binaries
that one has installed.

Neither these services nor user-tools need to perform archive-related duties
or operations, and therefore would prefer to work directly with signed
buildinfo files, rather than with signed .changes files plus an unsigned
.buildinfo file (which is what the current situation would force).

For more discussion on the rationale and intent see here:

https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles#Signatures
https://wiki.debian.org/ReproducibleBuilds/BuildinfoInfrastructure

An analogy that might be helpful is X509 certificates. These are signed
attestations by a CA (the signer) that "(I believe) key K belongs to entity E".
Compare this with a signed buildinfo file, which is a signed attestation that
"I built binary X from [etc]".

I'm happy to write this patch myself. That will take a little bit more time - I
wanted to file this bug report early to check that you're not opposed to this
idea - and before too many other tools start assuming that buildinfo files are
unsigned. I think this should not be the case by default, just as you rarely
see an unsigned .dsc being distributed.

There would also be a -ub option added, along the same lines as -us and -uc.
Then debsign from devscripts will also need to be updated, and I'll be happy to
write the patch for this too.

X

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

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.27-9+b1
ii  bzip2 1.0.6-8
ii  libdpkg-perl  1.18.13
ii  make  4.1-9
ii  patch 2.7.5-1
pn  perl:any  
ii  tar   1.29b-1
ii  xz-utils  5.2.2-1.2

Versions of packages dpkg-dev recommends:
ii  build-essential  12.2
ii  clang-3.5 [c-compiler]   1:3.5.2-5
ii  fakeroot 1.21-2
ii  gcc [c-compiler] 4:6.1.1-1
ii  gcc-6 [c-compiler]   6.2.0-10
ii  gnupg2.1.15-4
ii  gnupg2   2.1.15-4
ii  gpgv 2.1.15-4
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2016.09.04

-- no debconf information

Bug#843924: ITP: django-wkhtmltopdf -- Django module that provides views to wrap HTML to PDF conversions

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: django-wkhtmltopdf
  Version : 3.1.0
  Upstream Author : Incuna Ltd 
* URL : https://github.com/incuna/django-wkhtmltopdf
* License : MIT/Expat
  Programming Lang: Python
  Description : Django module that provides views to wrap HTML to PDF 
conversions

 Django Wkhtmltopdf provides Django views to wrap the HTML to PDF conversion
 of the `wkhtmltopdf `_ binary.

I intend to maintain this in the Debian Python Modules Team

Upstream did neglect to include the LICENSE file in the tarball (it's in git).
I already sent them a pull request to fix it and I'll add it locally for now.

Bug#842878: Asterisk crashes with pjproject 2.5.5

[Gedalya]

On 11/10/2016 05:26 AM, Bernhard Schmidt wrote:
> I have just uploaded 2.5.5~dfsg-3 with all patches bundled in Asterisk
> applied. Please take a look, should be available shortly.

Installed, works just fine.

Bug#843923: dos2unix FTCBFS: uses build architecture compiler

[Helmut Grohne]

Source: dos2unix
Version: 7.3.4-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

dos2unix fails to cross build from source, because it uses the build
architecture compiler. By indirecting the make invocation through
dh_auto_build, the cross build can be made work, because dh_auto_build
knows how to pass cross compilers. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru dos2unix-7.3.4/debian/changelog 
dos2unix-7.3.4/debian/changelog
--- dos2unix-7.3.4/debian/changelog 2016-10-26 06:36:02.0 +0200
+++ dos2unix-7.3.4/debian/changelog 2016-11-10 19:38:20.0 +0100
@@ -1,3 +1,10 @@
+dos2unix (7.3.4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 10 Nov 2016 19:38:20 +0100
+
 dos2unix (7.3.4-2) unstable; urgency=medium
 
   * debian/control
diff --minimal -Nru dos2unix-7.3.4/debian/rules dos2unix-7.3.4/debian/rules
--- dos2unix-7.3.4/debian/rules 2016-10-26 06:36:02.0 +0200
+++ dos2unix-7.3.4/debian/rules 2016-11-10 19:38:18.0 +0100
@@ -21,7 +21,7 @@
echo "rule: override_dh_auto_build"
env
env LANG=en_US.utf8 \
-   $(MAKE) LDFLAGS_USER="$(LDFLAGS)" CFLAGS_USER="$(CPPFLAGS) $(CFLAGS)"
+   dh_auto_build -- LDFLAGS_USER="$(LDFLAGS)" CFLAGS_USER="$(CPPFLAGS) 
$(CFLAGS)"
 
 override_dh_clean:
dh_clean

Bug#832931: jemalloc hard codes page size during build

[Thadeu Lima de Souza Cascardo]

clone -1 -2
reassign -2 libjemalloc1
retitle -2 jemalloc uses a hard coded page size detected during build
bye


So, I traced this to jemalloc using the incorrect page size during
runtime. In fact, it detects the page size during build and set it up.
This has a large potential for a mess. And what a mess!

So, jemalloc in jessie has been built on a 4KiB-page system, and, this,
has a hard-coded page size of 4KiB. While jemalloc in sid has a
64KiB-page size. When we try to build mariadb on jessie on a 4KiB-page
size system, everything goes well. When we build it on partch, with a
64-bit 64KiB-page size kernel, things break, if it's a jessie jemalloc.

Later upstream versions seem to support multiple page sizes during
build.

For MariaDB specifically, one option would be to build it without
jemalloc. Other users would still be likely affected, however.

Cascardo.

Bug#843921: tofrodos FTCBFS: uses build architecture compiler

[Helmut Grohne]

Source: tofrodos
Version: 1.7.13+ds-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

tofrodos fails to cross build from source, because it uses the build
architecture compiler. In the attached patch, I opted for indirecting
the make invocation via dh_auto_build, because the latter knows how to
pass cross compilers to make. Arguably, debian/rules got simpler in that
process. Please consider applying the attached patch.

Helmut
diff --minimal -Nru tofrodos-1.7.13+ds/debian/changelog 
tofrodos-1.7.13+ds/debian/changelog
--- tofrodos-1.7.13+ds/debian/changelog 2015-10-28 23:17:17.0 +0100
+++ tofrodos-1.7.13+ds/debian/changelog 2016-11-10 19:28:30.0 +0100
@@ -1,3 +1,10 @@
+tofrodos (1.7.13+ds-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross flags. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 10 Nov 2016 19:28:30 +0100
+
 tofrodos (1.7.13+ds-2) unstable; urgency=medium
 
   * Vcs-Browser: Switch to cgit and https.
diff --minimal -Nru tofrodos-1.7.13+ds/debian/rules 
tofrodos-1.7.13+ds/debian/rules
--- tofrodos-1.7.13+ds/debian/rules 2015-10-28 23:17:17.0 +0100
+++ tofrodos-1.7.13+ds/debian/rules 2016-11-10 19:28:28.0 +0100
@@ -7,18 +7,17 @@
 
 
 %:
-   dh $@
+   dh $@ --sourcedirectory=src
 
 override_dh_auto_clean:
-   cd $(CURDIR)/src \
-   && $(MAKE) clean \
-   && $(RM) -r -v fromdos todos
+   dh_auto_clean
+   $(RM) -r -v src/fromdos src/todos
 
 override_dh_auto_build:
-   cd $(CURDIR)/src && $(MAKE) CDEBUG="$(CFLAGS)" LDEBUG="$(LDFLAGS)"
+   dh_auto_build -- CDEBUG="$(CFLAGS)" LDEBUG="$(LDFLAGS)"
 
 override_dh_auto_install:
-   cd $(CURDIR)/src && $(MAKE) install \
+   dh_auto_install -- \
BINDIR=$(CURDIR)/debian/tofrodos/usr/bin \
MANDIR=$(CURDIR)/debian/tofrodos/usr/share/man/man1
 

Bug#842646: now 644 not found

[積丹尼 Dan Jacobson]

reopen 842646
thanks

HEAD 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.644.sha512.i386.pgp.asc
User-Agent: lwp-request/6.15 libwww-perl/6.15

301 Moved Permanently
HEAD 
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.644.sha512.i386.pgp.asc
User-Agent: lwp-request/6.15 libwww-perl/6.15

404 Not Found

Bug#843922: stockfish: FTBFS: g++: error: unrecognized command line option '-m32'

[Sven Joachim]

Source: stockfish
Version: 8-1
Severity: serious

Your package fails to build on most architectures, because it calls g++
with the '-m32' option which is not generally supported.  Besides that,
the Config information looks very wrong on some architectures,
e.g. arm64[1], s390x[2] and mips64el[3] are apparently all wrongly
recognized as 32-bit architectures.

Could you please have a look?


1. 
https://buildd.debian.org/status/fetch.php?pkg=stockfish=arm64=8-1=1478719816
2. 
https://buildd.debian.org/status/fetch.php?pkg=stockfish=s390x=8-1=1478721845
3. 
https://buildd.debian.org/status/fetch.php?pkg=stockfish=mips64el=8-1=1478734250

Bug#837597: network-manager: NetworkManager start times out during boot

[Andreas Metzler]

On 2016-11-06 Andreas Metzler  wrote:
[...]
> This is included in GnuTLS 3.5.6.

... which hit experimental two days ago and will be in unstable with
the next mirror pulse.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#843838: [pkg-bacula-devel] Bug#843838: Bug#843838: Bug#843838: Fail to access config file

[Sven Hartge]

On 10.11.2016 18:51, Jörg Frings-Fürst wrote:

> I guess that the error is the wrong group.

Of course, this is obvious.

> But the error comes not from use rsync without --numeric-ids.
> I don't use rsync, I have moved the hard disk with dd.
> 
> But also I have no idea from where the dirmngr comes.

I also have no idea, but I find it very suspicious that every group that
should be "bacula" is "dirmngr" on your system, as if someone/something
changed /etc/group or replaced it with a one not belonging to the system.

> A note:
> 
> If you change "the way the daemons are started" please check and change
> the required user/group.

I tested this change on several systems, some newly installed Sid, some
upgraded from Jessie, some even upgraded from Squeeze and older.

Every sane system had the correct groups and users for /etc/bacula/*.

The only change for permissions and owners was needed for
/etc/bacula/bacula-sd.conf and this is done in bacula-sd.postinst.

In my opinion this problem is not a bug in the bacula package but your
system was broken to begin with and this change just exposed it.

You need to find out who or what made the changes to /etc/group as more
problems may linger.

I personally also don't see an obligation for Debian packages to check
every possible angle an administrator could have manually broken their
system and try to work around this, but YMMV.

Just broadly changing and overwriting every permission in /etc/bacula/
is also wrong, as the administrator might have made working changes
which we don't want to destroy.

Grüße,
Sven.





signature.asc
Description: OpenPGP digital signature