Bug#846275: provide a directory for hidden service socket files

[Peter Palfrader]

On Tue, 20 Dec 2016, Joey Hess wrote:

> Peter Palfrader wrote:
> > On Sun, 18 Dec 2016, Joey Hess wrote:
> > 
> > > But, I was able to get it to work using /var/lib/bla/sock
> > > when I tried once more.
> > 
> > Ok.  I guess that means we don't need any particular package config fu
> > here.  Maybe just some documentation.
> 
> It would be good to document where the sockets can be placed. Picking
> and documenting a specific directory would ensure that, if tor later
> gets locked down more, it would still be able to read sockets from that
> location.

Yes, see README.Debian in the most recent upload -
 https://gitweb.torproject.org/debian/tor.git/tree/debian/README.Debian

Please let me know if this is what you had in mind.  I'd appreciate any
suggestions (or patches) for improvement :)

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#848931: dgit: please add a configuration variable that prevents me from accidentally doing a non-source-only upload

[Johannes Schauer]

Quoting Sean Whitton (2016-12-21 08:43:27)
> On Tue, Dec 20, 2016 at 11:01:31PM +0100, Johannes Schauer wrote:
> > I just uploaded a new version of my package botch. But then I got an
> > email "Processing of botch_0.21-1_multi.changes" and I was like ugh... I
> > accidentally did "dgit push" without having done "dgit build-source"
> > first. So what got upload was the result of my "dgit sbuild". Would it
> > make sense to add a dgit configuration variable that would prevent me
> > from accidentally doing an upload that is not a source-only upload?
> > Like, a configuration option that would force me to add an option to the
> > command line if I *really* want to do an upload that is not source-only
> > which only happens rarely.
> 
> Good idea.  This option should be ignored when --new is present.

also related might be #801435 which asks for a feature that auto-detects if an
upload would go to NEW or binary-NEW.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#848740: pymc: FTBFS: ld: cannot find -lcblas

[Adrian Bunk]

Control: retitle -1 pymc FTBFS with test failure: ValueError: size is not 
compatible with inputs

On Mon, Dec 19, 2016 at 10:11:33PM +0100, Lucas Nussbaum wrote:
>...
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>/pymc-2.2+ds'
> > dh_auto_clean
> > dh_auto_clean: Compatibility levels before 9 are deprecated (level 7 in use)
> > python setup.py clean -a
> > /usr/lib/python2.7/dist-packages/numpy/distutils/system_info.py:572: 
> > UserWarning: 
> > Atlas (http://math-atlas.sourceforge.net/) libraries not found.
> > Directories to search for the libraries can be specified in the
> > numpy/distutils/site.cfg file (section [atlas]) or by setting
> > the ATLAS environment variable.
> >   self.calc_info()
> > /usr/bin/ld: cannot find -lcblas
> > collect2: error: ld returned 1 exit status
>...

The actual failure is a test failure later in the build:

...
==
ERROR: Failure: ValueError (size is not compatible with inputs)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 418, in 
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 47, in 
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 94, in 
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File 
"/<>/pymc-2.2+ds/build/lib.linux-x86_64-2.7/pymc/tests/test_special_methods.py",
 line 16, in 
pm.Binomial('x3',100,.4),
  File 
"/<>/pymc-2.2+ds/build/lib.linux-x86_64-2.7/pymc/distributions.py", 
line 270, in __init__
Stochastic.__init__(self, logp=logp, random=random, logp_partial_gradients 
= logp_partial_gradients, dtype=dtype, **arg_dict_out)
  File 
"/<>/pymc-2.2+ds/build/lib.linux-x86_64-2.7/pymc/PyMCObjects.py", 
line 705, in __init__
verbose=verbose)
  File "/<>/pymc-2.2+ds/build/lib.linux-x86_64-2.7/pymc/Node.py", 
line 201, in __init__
Node.__init__(self, doc, name, parents, cache_depth, verbose=verbose)
  File "/<>/pymc-2.2+ds/build/lib.linux-x86_64-2.7/pymc/Node.py", 
line 119, in __init__
self.parents = parents
  File "/<>/pymc-2.2+ds/build/lib.linux-x86_64-2.7/pymc/Node.py", 
line 140, in _set_parents
self.gen_lazy_function()
  File 
"/<>/pymc-2.2+ds/build/lib.linux-x86_64-2.7/pymc/PyMCObjects.py", 
line 730, in gen_lazy_function
self.value = self._random(**self._parents.value)
  File 
"/<>/pymc-2.2+ds/build/lib.linux-x86_64-2.7/pymc/distributions.py", 
line 110, in newfun
return randfun(size=shape, *args, **kwargs)
  File 
"/<>/pymc-2.2+ds/build/lib.linux-x86_64-2.7/pymc/distributions.py", 
line 724, in rbinomial
return np.random.binomial(np.ravel(n),np.ravel(p),size)
  File "mtrand.pyx", line 3788, in mtrand.RandomState.binomial 
(numpy/random/mtrand/mtrand.c:32376)
  File "mtrand.pyx", line 388, in mtrand.discnp_array 
(numpy/random/mtrand/mtrand.c:9960)
ValueError: size is not compatible with inputs

--
Ran 111 tests in 4.814s

FAILED (SKIP=7, errors=1)
Plotting disabled
debian/rules:41: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1


cu
Adrian

-- 

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

Bug#848944: grub-common: grub-probe fails for ZFS root pool on /dev/mapper device

[Fabian Grünbichler]

this is a duplicate of #824974 and thus fixed in stretch/sid's 
grub2/2.02~beta3-3

maybe a backport of that one for jessie-backports would help you? since ZoL is 
only available via -backports as well..

alternatively, you could try to build jessie with the single patch setting the 
environment variable to get "zpool status -P" behaviour (or even just set 
ZPOOL_VDEV_NAME_PATH when calling update-grub, not sure if the grub 
binaries/scripts propagate or sanitize the environment).

Bug#848959: git: malloc failed (tried to allocate 536870912 bytes)

[Heinrich Schuchardt]

Package: git
Version: 1:2.11.0-1
Severity: important

Dear Maintainer,

on a system with only 512 MB installed I received the following error:

$ free
  totalusedfree  shared  buff/cache   available
Mem: 474232  114984  1927601476  166488  348564
Swap: 0   0   0

$ git clone https://github.com/xypron/skyldav
Cloning into 'skyldav'...
fatal: Out of memory, malloc failed (tried to allocate 536870912 bytes)
fatal: The remote end hung up unexpectedly

https://www.debian.org/releases/stable/arm64/ch03s04.html.en
has the following requirements for headless systems:
minimum RAM: 128MiB
recommended: 512MiB
(I could not find the corresponding page for Stretch.)

Allocating 512MiB on git clone without fallback to a smaller quantity
is a violation of this policy.

A possible solution would be to limit the malloc call to 1/4 of the
physical memory (without swap).

Best regards

Heinrich Schuchardt

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

Kernel: Linux 4.9.0-next-20161212-r015-arm64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git depends on:
ii  dpkg 1.18.15
ii  git-man  1:2.11.0-1
ii  libc62.24-8
ii  libcurl3-gnutls  7.50.1-1
ii  liberror-perl0.17024-1
ii  libexpat12.2.0-1
ii  libpcre3 2:8.39-2
ii  perl 5.24.1~rc4-1
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages git recommends:
ii  less 481-2.1
ii  openssh-client [ssh-client]  1:7.3p1-5
ii  patch2.7.5-1
ii  rsync3.1.2-1

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-1
pn  git-arch  
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
ii  git-email 1:2.11.0-1
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

Bug#843207: ITP: man2texi -- man page to texinfo file converter

[Paul Hardy]

The plan to release a version 0.02 of man2texi has been cancelled.
There will be an even newer version of man2texi, which I will package
for Debian when it is done.  There are problems with man2texi and the
latest versions of texinfo producing consistent output across all
operating environments that Nelson Beebe is testing.  He is working
with the GNU texinfo maintainer to resolve these issues.

Unfortunately, this means that there will be no man2texi release in
time for the Debian stretch freeze.  I will post updates to this ITP
bug report when the situation changes.

Thanks,


Paul Hardy

Bug#848951: [pkg-gnupg-maint] Bug#848951: gnupg: Utilize multiple cores on CPU for encryption and decryption (and compression)

[Werner Koch]

On Wed, 21 Dec 2016 06:57, witold.bary...@gmail.com said:

> Using cipher and compression algorithms that can utilize multiple cores

It is not possible to parallelize encryption using the CFB mode as
required by OpenPGP.  In theory it would be possible to run the hashing
(which is also run on the plaintext) on a different thread.  However
that would complicate matters a lot and I doubt that there will be a
real benefit.

What would really improve throughput is a different encryption mode to
replace CFB and its SHA-1 based MDC.  My suggestion to the WG is the use
of OCB which would be a lot faster: On an X220 you get these values

 AES|  nanosecs/byte   mebibytes/sec   cycles/byte
CFB enc |  1.77 ns/B 537.9 MiB/s  4.08 c/B
CFB dec | 0.373 ns/B2557.6 MiB/s 0.858 c/B
OCB enc | 0.436 ns/B2189.4 MiB/s  1.00 c/B
OCB dec | 0.452 ns/B2107.9 MiB/s  1.04 c/B

|  nanosecs/byte   mebibytes/sec   cycles/byte
 SHA1   |  1.88 ns/B 507.7 MiB/s  4.32 c/B

Thus the theoretical speedup would be 

  CFBSHA1  OCB
 enc  1.77 + 1.88 = 3.65   0.44   8 times
 dec  0.37 + 1.88 = 2.25   0.45   5 times



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpijXZUWhdU1.pgp
Description: PGP signature

Bug#834790: aptitude hangs at "Loading cache" when unable to download package list

[Daniel Schröter]

Hi,

I could reproduce this after I have added
deb http://snapshot.debian.org/archive/debian/20161109T033315Z/ unstable
main

and didn't start aptitude with
aptitude -o Acquire::Check-Valid-Until=false

Version is
root@ivy:/mnt/sdb4/tmp# aptitude --version
aptitude 0.8.3
Compiler: g++ 6.2.0 20161103
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.10.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20161126
  cwidget version: 0.5.17
  Apt version: 5.0.1

Bye

Bug#848960: xserver-xorg segfaults after starting afterstep

[Frank Brokken]

Package: xserver-xorg
Version: 1:7.7+18
Severity: important

Dear Maintainer,

   * What led up to the situation?

Last week, after performing my weekly Debian update / upgrade session and
after rebooting my desktop computer the xserver segfaulted after logging in
and the (afterstep) window manager had started. Ususally it segfaults
immediately after starting up afterstep, occasionally after about 15 seconds
after showing afterstep's opening screen.

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

Assuming that the problem was related to the recent update I completely
removed xdm, xorg, xserver-xorg, and afterstep (and any libraries only used by
these packages) from my computer, and installed their stable versions (I'm
using Debian testing). The problem, however, remained.

Next I switched my window manager from afterstep to fvwm: the segfault no
longer appeared. Maybe the segfault somehow is related to using afterstep, but
in the end it's the X server that segfaults, which is why I filed the problem
as a xserver bug. 

I couldn't find hints as to what might be happening in the xserver-xorg log
(which is automatically included by reportbug in this bug report. If you want
a clean log file, generated after reinstalling the packages and rebooting,
then please let me know.

Xdm's log, however, did show the segfault:

Tue Dec 20 12:32:04 2016 xdm info (pid 16348): Starting
Tue Dec 20 12:32:04 2016 xdm info (pid 16348): Starting X server on :0

X.Org X Server 1.19.0
Release Date: 2016-11-15
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
Current Operating System: Linux suffix 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 
(2016-12-02) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=92e1ce07-b39b-462f-aad2-236f67bd86ef ro quiet
Build Date: 23 November 2016  07:20:23PM
xorg-server 2:1.19.0-2 (https://www.debian.org/support) 
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 20 12:32:04 2016
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
resize called 1680 1050
Tue Dec 20 12:32:05 2016 xdm info (pid 16358): sourcing /etc/X11/xdm/Xsetup
Tue Dec 20 12:32:17 2016 xdm info (pid 16358): sourcing 
/etc/X11/xdm/Xstartup
Tue Dec 20 12:32:17 2016 xdm info (pid 16374): executing session 
/etc/X11/xdm/Xsession
(EE) 
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4a) [0x55c9a2bfffea]
(EE) 1: /usr/lib/xorg/Xorg (0x55c9a2a47000+0x1bcd69) [0x55c9a2c03d69]
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd62c215000+0x11100) 
[0x7fd62c226100]
(EE) 3: ?? [0x55c9a52c1038]
(EE) 
(EE) Segmentation fault at address 0x55c9a52c1038
(EE) 
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
(EE) 
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) Server terminated with error (1). Closing log file.
Tue Dec 20 12:32:39 2016 xdm info (pid 16358): sourcing /etc/X11/xdm/Xreset
Tue Dec 20 12:32:39 2016 xdm info (pid 16348): Starting X server on :0
Tue Dec 20 12:32:39 2016 xdm error (pid 16348): Server for display :0 
terminated unexpectedly: 1536
Tue Dec 20 12:32:39 2016 xdm info (pid 16348): Starting X server on :0

X.Org X Server 1.19.0
Release Date: 2016-11-15
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
Current Operating System: Linux suffix 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 
(2016-12-02) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=92e1ce07-b39b-462f-aad2-236f67bd86ef ro quiet
Build Date: 23 November 2016  07:20:23PM
xorg-server 2:1.19.0-2 (https://www.debian.org/support) 
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 20 12:32:39 2016
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
resize called 1680 1050
Tue Dec 20 12:32:40 2016 xdm info (pid 16587): sourcing /etc/X11/xd

Bug#847567: [Pkg-fonts-devel] Bug#847567: ttf-dejavu: Probably removal needed

[Cyril Brulebois]

Hi,

Fabian Greffrath  (2016-12-14):
> control: reassign -1 ftp.debian.org
> control: retitle -1 RM: ttf-dejavu -- ROM
> 
> Am Freitag, den 09.12.2016, 15:52 +0100 schrieb Dr. Tobias Quathamer:
> > thanks for the hint, done now. I've now seen that the new upstream
> > is 
> > already packaged as fonts-dejavu. That package provides the (old) 
> > package name ttf-dejavu.
> > 
> > I guess that the old and now obsolete source package ttf-dejavu can 
> > safely be removed, right?
> > 
> > If so, please reassign this bug to ftp-master.debian.org, asking for 
> > removal.
> 
> Tobias is right, src:ttf-dejavu should get removed from unstable. It
> has been superceeded by fonts-dejavu which has also taken over its
> binary packages.

Please don't remove udebs too quickly. Even if ttf-dejavu-udeb isn't
listed as a build dependency of the debian-installer source package,
it's needed there during the build. This removal is therefore making
debian-installer FTBFS.

It would be great to check with debian-boot@ before handling such RM
requests (removal of udeb-producing packages). We would have had a
chance to switch to the “new” package.

Thanks for considering.


KiBi.


signature.asc
Description: Digital signature

Bug#848961: nano: please update syntax highlighting for nftables

[Arturo Borrero Gonzalez]

Package: nano
Version: 2.7.1-1
Severity: wishlist
Tags: patch

Dear nano maintainers,

thanks for working in my editor of choice. It's really appreciated.

I tried to generate a patch for the nftables syntax highlighting, but failed
to find the source repo (the current git link from the tracker points to an
empty repository).

So, please, would you take the new file from here the file and push it
yourself?:

https://raw.githubusercontent.com/aborrero/nftables-nano-syntax/master/nftables.nanorc

== 8< ==
## Here is an example for nftables.

syntax "nftables" "\.(nft|nftables)$"
header "^#!.*(nft|nftables)"
comment "#"

# Objects and operations
color green "\<(chain|hook|policy|priority|ruleset|set|table|type|v?map)\>"
color green "\<(define|include)\>"
color red "\<(add|delete|flush|insert|remove|replace)\>"

# Families
color yellow "\<(arp|bridge|inet|netdev|ingress|ip6?)\>"

# Terminal statements
color red "\<(drop|reject)\>"
color brightblue "\<(accept|continue|(d|s)nat|goto|jump|masquerade|return)\>"

# Comments
color cyan "(^|[[:space:]])#.*$"

# Trailing whitespace
color ,green "[[:space:]]+$"

# Strings and others
color yellow ""(\\.|[^"])*"" "'(\\.|[^'])*'"
color green "[{}():;|`$<>!=&\\]" "(\]|\[)"

# Basic variable names
color brightred "\$[[:alpha:]_-][[:alnum:]_.-]*"
color brightred "\@[[:alpha:]_-][[:alnum:]_.-]*"
== 8< ==

Bug#848815: camitk: FTBFS: make[2]: *** [sdk/libraries/core/CMakeFiles/library-camitkcore.dir/all] Error 2

[Adrian Bunk]

On Tue, Dec 20, 2016 at 10:55:33AM +0100, Andreas Tille wrote:
> Hi Emmanuel,
> 
> just to make sure you noticed this RC critical error.
> 
> On Mon, Dec 19, 2016 at 10:29:47PM +0100, Lucas Nussbaum wrote:
> > Source: camitk
> > Version: 4.0.4-1
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20161219 qa-ftbfs
> > Justification: FTBFS on amd64
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> > 
> > Relevant part (hopefully):
> 
> I admit I have nothing in this extract to get a clue about the problem.
> 
> > > make[2]: *** [sdk/libraries/core/CMakeFiles/library-camitkcore.dir/all] 
> > > Error 2
> > 
> > The full build log is available from:
> >http://aws-logs.debian.net/2016/12/19/camitk_4.0.4-1_unstable.log
> 
> Most probably you need to inspect the full log
>...

The error is:
  make[3]: *** No rule to make target '/usr/lib/libmpi.so', needed by 
'lib/libcamitkcore.so.4.0.4'.  Stop.

That's #848785 in libvtk6-dev, I'll merge this bug with the others.


> Kind regards
> 
>Andreas.

cu
Adrian

-- 

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

Bug#804429: python-libpcap: FTBFS: pcap.c:4397:37: error: '_wrap_pcap_doc_swigconstant' undeclared here (not in a function)

[Christoph Biedl]

Chris Lamb wrote...

> Source: python-libpcap
> Version: 0.6.4-1
> Severity: serious
> Justification: fails to build from source

>   pcap.c:4397:37: error: '_wrap_pcap_doc_swigconstant' undeclared here
>   (not in a function)
> { (char *)"pcap_doc_swigconstant", _wrap_pcap_doc_swigconstant,
> METH_VARARGS, _doc_pcap_doc_swigconstant },

Hi Chris,

I cannot reproduce this, build passed twice on an updated sid build
environment. Can you please re-check?

Christoph


signature.asc
Description: Digital signature

Bug#848648: RM: python-ffc [amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x] -- RoQA; now an arch:all package

[Drew Parsons]

The Architecture:all status is now fixed in the unstable archive;
python-ffc 2016.2.0-1 is now accessible to apt.

Thanks for the fixes,
Drew

Bug#764678: dh-systemd: Please support systemd user services

[Michael Biebl]

Am 24.11.2016 um 17:35 schrieb Michael Biebl:
> Am 23.11.2016 um 16:00 schrieb Daniel Kahn Gillmor:
>> On Mon 2016-10-31 15:49:29 -0400, Daniel Kahn Gillmor wrote:

>> Sorry to nag about this, but is there any alternative to my just
>> shipping symlinks?
> 
> Are those user services supposed to be enabled by default?
> If so, I'd just ship the symlinks in the package for now.
> 
> See for example dbus-user-session, which ships
> 
> /usr/lib/systemd/user/dbus.service
> /usr/lib/systemd/user/dbus.socket
> and
> /usr/lib/systemd/user/sockets.target.wants/dbus.socket

My earlier comment [1], that shipping the symlink in the package is
ugly, was specifically meant for doing it in /etc.
Shipping the symlinks in /usr/lib/systemd/user/foo.wants/ is imho an
acceptable solution for stretch, i.e.
/usr/lib/systemd/user/sockets.target.wants/gpg-agent.socket

I'm not sure if gpg-agent-ssh.socket and gpg-agent-extra.socket should
be enabled by default. Those look like they should be enabled on a
per-user basis and default to off?

In buster we should definitely add proper support for user services to
i-s-h and dh-systemd. For stretch this is too late and not going to
happen (anymore). Sorry about that.

Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678#15
-- 
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#815170: love: New upstream version available

[Alexandre Detiste]

2016-12-18 15:24 GMT+01:00 Markus Koschany :
> I think people are more interested in an up-to-date love engine at the
> moment, so I wouldn't worry too much about the documentation.

I guess the preivous documentation was spidered with wget or something;
but there isn't even custom a rule in debian/rules to re-do this step.

Bug#848726: shebang preseed

[Philip Hands]

Philipp Kern  writes:

> On 12/20/2016 09:26 PM, Geert Stappers wrote:
>> On Mon, Dec 19, 2016 at 10:00:57PM +0100, Geert Stappers wrote:
>>> This ticket is to discuss a "shebang" for preseed files,
>>> to have an interpreter directive.
>> Goal is having a "header" which make it possible
>> to check that actual a preseed file is being downloaded.
>> 
>> https://www.debian.org/releases/stable/example-preseed.txt shows clearly
>> that a preseed file can start with a comment.
>> 
>> What are the opinions about a two step approach like
>> 
>> Step 1:
>> ---
>> Document all "stretch" preseed files begining with '#!preseedV1'
>> 
>> 
>> Step 2:
>> ---
>> In "stretch+1", a.k.a. "buster", implement code that checks '#!preseedV1'
>> and informs user when not found.
>
> How would this change the outcome of the bug you encountered? If I
> understand you correctly it told you that the file was corrupt. Your
> proposal would just re-enforce that notion, at the expense of everyone
> needing to change their files? :)

This seems only to be an issue when using PXE booting, and is likely to
be particularly problematic when one does not have full control of the
DHCP server, or where it cannot be persuaded to offer different files to
different DHCP clients.

The problem is then that a non-preseed file may be offered in a way that
tricks d-i into trying to load it, at which point it will throw an
error.

So, how about this:

  We have a debconf value to select the severity of the error when
  failing to recognise the format of a preseed file.

  Normally, that should default to "error", as is now the case.

  For DHCP preseeding, the default should be changed to something less
  severe ("warn" or "ignore").

  We could then have something as a header, as you suggest, which could
  be used to decide to set the severity back to "error" if it is seen in
  a DHCP preseed file.

That way, all non-DHCP preseeding could continue just as it is now.

If one wants corrupt preseed files to throw an error, even when DHCP-ed,
then adding the header will achieve that (except when the header is
corrupted).

If one gets given the wrong sort of file via DHCP then it'll get
ignored or throw a warning.

We could at some point add another value for the severity setting, of
"magicrequired" that would implement the behaviour that Geert seems to
be advocating:
  throwing an error if file is seen that lacks magic.

(that could perhaps become the default for DHCP preseeding, but
 otherwise I doubt it's useful enough to render all existing preseed
 files broken.)

Cheers, Phil.

P.S. I don't think that using #! as part of the magic string is a great
idea -- it will make people incorrectly assume that there is an
interpreter being invoked somewhere.

P.P.S.  If we're considering putting magic comments into preseed files,
I would suggest that we also have a comment at the end, so that we can
check for the case of a truncated preseed file.  I suspect that such
errors never really happen though, so are probably not worth checking
for, in which case the only change needed is to make this not be an
error when the preseed URL arrived via DHCP.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#613040: retitle 613040 to desktop-base should depend or recommend plymouth-themes-script

[Holger Levsen]

control: retitle -1 desktop-base should depend or recommend 
plymouth-themes-script
#thanks

Hi,

I think a depends its totally fine. if one uses desktop-base,
one probably wants plymouth. At least I always do.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#848597: debian-installer: iPXE script in DHCP bootfile option is interpreted as preseed filename

[Philip Hands]

Pali Rohár  writes:

> Package: debian-installer
> Severity: normal
>
> Dear Maintainer,
>
> when DHCP server is configured to send bootfile option with iPXE script
> then debian-installer fails with following "red" error:
>
>   [!!] Download debconf preconfiguration file
>
>   Failed to process the preconfiguration file
>
>   The installer failed to process the preconfiguration file from .
>   The file may be corrupt.
>
> (where  is value of that DHCP option)
>
> It looks like debian-installer expects that DHCP bootfile option will
> contains correct preseed file. And if that DHCP option contains not
> Debian preseed file, then it show above "red" error message.

Is it the case that iPXE config files are the only things we need to
worry about here?  (seems probable given the lack of previous reports)

If so, we could just check for '#!ipxe' and if found downgrade the error
to a warning, or perhaps to log what happened but otherwise ignore it.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#848815: camitk: FTBFS: make[2]: *** [sdk/libraries/core/CMakeFiles/library-camitkcore.dir/all] Error 2

[Emmanuel Promayon]

On 21/12/16 09:39, Adrian Bunk wrote:

On Tue, Dec 20, 2016 at 10:55:33AM +0100, Andreas Tille wrote:

Hi Emmanuel,

just to make sure you noticed this RC critical error.

On Mon, Dec 19, 2016 at 10:29:47PM +0100, Lucas Nussbaum wrote:

Source: camitk
Version: 4.0.4-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20161219 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):

I admit I have nothing in this extract to get a clue about the problem.


make[2]: *** [sdk/libraries/core/CMakeFiles/library-camitkcore.dir/all] Error 2

The full build log is available from:
http://aws-logs.debian.net/2016/12/19/camitk_4.0.4-1_unstable.log

Most probably you need to inspect the full log
...

The error is:
   make[3]: *** No rule to make target '/usr/lib/libmpi.so', needed by 
'lib/libcamitkcore.so.4.0.4'.  Stop.

That's #848785 in libvtk6-dev, I'll merge this bug with the others.


Thank you Andreas and Adrian. I was just about to post a comment and say 
that the error can be seen at line 30981 of the full log and is probably 
link with #848793 in libvtk6-dev. Thank you Adrian for the bug merge. I 
suppose it will be seen as FTBS in all the packages that depends on 
libvtk6-dev to build.


What can I do to help from here?

Best regards,

Emmanuel

Bug#848583: cppcheck: --enable=unusedFunction does not work

[Joachim Reichel]

Hi Steve,

can you please mention the version that does not work and include a small repro
case?

Thanks,
  Joachim

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Christian Ehrhardt]

Background to explain the reasoning behind the change 1/7:

Commits:
0733afe * d/rules: Reorganize to ease maintenance
be360c3 changelog: d/rules: Reorganize to ease maintenance
45adecc * d/control: Wrap and sort to ease maintenance
00bcdba changelog: d/control: Wrap and sort to ease maintenance

Background:
Diffs to the enabling / disabling options turned out to be very noisy.
That is due to multiple options being on one line, so a diff can easily be
misread.
Is it adding something, or removing - or actually chaning.

A common recommendation to avoid this issue is to have the entries
"one-per-line" (to avoid the diff noise) and sorted (to avoid duplicates by
adding e.g. at the bottom while being already at the top).

Ubuntu did have the diff of 0733afe this as a Delta to d/rules for quite a
while - and the change is purely cosmetical and should have no
functional impact, but helps maintenance.

The same applies to most files in debian/*. It is such a common need that
there is actually a Tool which does most of that for you "wrap and sort".
I realized while explaining we should add that right away as well,
so this 6872c7c is fixing up d/control by using that tool.
​

Bug#774415: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Holger Levsen]

On Wed, Dec 21, 2016 at 08:14:23AM +0100, Johannes Schauer wrote:
> > as long as there's a short version of --rebuild-and-verify=foo.buildinfo
> > such as (for example) -rb=foo.buildinfo fine with me… :)
> the -r short option is still free.
 
sounds good.

> > (though I'm not sure I fully understand why not assume -rb if foo.buildinfo
> > is given - I do understand for foo.changes…)
> 
>  - Because I'm not so sure that the user is aware that passing a .buildinfo
>file will mean that sbuild is querying snapshot.d.n without asking the user
>for further consent.

what's the problem with that? (especially compared to downloading
packages from ftp.*.debian.org, which is also done…)

>  - Because then we would only allow .buildinfo files that include the source
>package hash as well which I find quite limiting - especially considering
>how the Debian autobuilders will exclusively generate .buildinfo files of
>that kind

why? If I call "sbuild foo.buildinfo" and that .buildinfo file has no
source hashes, then sbuild should fail. Easy. (?!?!)

You seem to imply that the Debian autobuilders will generate .buildinfo
files without source hashes - I think *that* is a problem - how can we
fix it?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#845383: sponsored upload instead of NMU

[Arturo Borrero Gonzalez]

Hi,

as you can see, I pushed a sponsored upload instead of a NMU.
I think sponsoring is less invasive than the NMU.

Please, feel free to blame me if you didn't like this approach.

best regards.

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Christian Ehrhardt]

Background to explain the reasoning behind the change 2/7:

Commits:
944a3c7 * d/rules: Make override_dh_strip a nop.
b7754fe changelog: d/rules: Make override_dh_strip a nop

The (to be enabled in a later commit in this series) plugin "integrity-test"
provides a useful extra feature for the cautious strongswan admin.
It stores checksums of its libraries and can check non-malicious errors to
avoid accidentially loading bad libraries.
See https://wiki.strongswan.org/projects/strongswan/wiki/IntegrityTest for
more.

It is an experimental feature, but out there for a while and was enabled in
Ubuntu per user request, so I assume it has its use in the field.

To be able to do so it stores the checksums as part of the build process.
But to match those sums later on the build is not allowed to strip the
plugins.
That is listed in the "conflicts" section of the Wiki page.

Therefore override "override_dh_strip:" with a comment that explains why
strip
is skipped.
​

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Christian Ehrhardt]

Background to explain the reasoning behind the change 3/7:

Commits:
0af16a2 * d/rules: Set minimal TESTS_REDUCED_KEYLENGTHS
e024f7e changelog: d/rules: Set minimal TESTS_REDUCED_KEYLENGTHS to avoid
hanging builds

There were several cases where low entropy build environments stalled.
This was up to an amount that sometimes builds failed with timeouts.

Obviously the more options that are enabled the more will be tested and the
bigger the effect of this is.

Fortunately the strongswan build/test has an environment variable to control
this behavior and if set to 1 all tests will still be run, but require much
less entropy.
See
https://wiki.strongswan.org/projects/strongswan/wiki/DeveloperDocumentation
for the Strongswan documentation on this option.
​

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Christian Ehrhardt]

 Background to explain the reasoning behind the change 4/7:

Commits:
59e9a0b * add and install apparmor profiles
3d124a4 changelog: Add and install strongswan apparmor profiles

Make the usage of strongswan even more secure by providing an apparmor
profile
for it.

This change add the necessary build dependencies, installs the profiles and
provides profiles for charon, lookip and stroke.

As usual best practise in case the profiles turn out to be too restrictive
for
a very special not considered setup they all provide includes to local
overrides. That allows to modify the rules as needed without causing file
conflicts on further updates to the package delivered profiles.
​

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Christian Ehrhardt]

I hope that these more detailed explanations help to clarify the reasoning.
I'm likely away for the rest of the Year soon, but please let me know what
might still be missing (or on what particular point you'd like to discuss
some bits).
I really want to work with you to get us in sync as much as possible for
the benefit
of both of us.

P.S. hopefully no debbug spam detector now hates me after this mail flood
:-)

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Christian Ehrhardt]

Background to explain the reasoning behind the change 6/7:

Commits:
514dc31 * Add updated logcheck rules to match recent strongswan output
ab32a3f changelog: Add updated logcheck rules to match recent strongswan
output

When using logcheck with strongswan as of today there are a lot of unknown
messages reported.
This change updates it to the now used log output, so that logcheck can
ignore
those expected messages.

This change is a carry forward for a while now, we might have to update
it to match strongswan 5.5, yet it should match better than the currently
supplied logcheck files - so it should be a good first step.

Note: The new rules make no difference on the logcheck report levels
anymore.
​

Bug#808634: cadabra in Debian

[Kasper Peeters]

> Uploaded last night. The build failed on a bunch of architectures
> (arm64, armel, armhf, pppc64el, powerpc, s390x)) due to failing tests.
> It was always the test fieldtheory which hang on these architectures
> and was killed after reaching an timeout.
> 
> My current suspicion is that lie doesn't behave as expected on these
> architectures. Haven't checked it explicitly, though.

I would not waste more time on this; the bit that requires LiE is only
a very small part of the total functionality, and this dependency will
go away in 2.x anyway. Just disabling that test is fine with me.

Cheers,
Kasper

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Christian Ehrhardt]

Background to explain the reasoning behind the change 5/7:

Commits:
6bf2bf5 * Add basic DEP8 tests
6f408a9 changelog: Add basic DEP8 tests

As basic CI dep8 based autopkgtests provide a very useful level of automated
sanity checks to become part of debci at https://ci.debian.net/.
See https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
for
basics.

This commit adds some basic smoke tests for strongswan:
- admin-strongswan-charon and admin-strongswan-starter: are the commands
for an
  admin built, installed by the right package and executable.
- daemon: are the daemons running after a default installation
- plugins: check if all expected-to-be-loaded plugins are loaded and vice
versa
  check that all expected-not-to-be-loaded (default off) plugins are not.
​

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Christian Ehrhardt]

Background to explain the reasoning behind the change 7/7:

Commits:
0271917 * Enable more features to to cover more use-cases
bd04b06 changelog: Enable more features to to cover more use-cases

Note: Many of those changes are so correlated that this is a one big change
for
now. If needed and ok that interim commits might not be buildable I could
split
it in maybe 3-5 logical pieces. But for now just explaining all the
reasoning
in Detail.

This change enable more features to to cover more use-cases by the packages
strongswan.

As a start it enables this enables all stable plugins according to
https://wiki.strongswan.org/projects/strongswan/wiki/Pluginlist

The intention is to make the default packages strongswan more usable without
forcing users to rebuild more more sophisticated setups.
Yet on the other hand we don't want to proliferate plugins so most of the
plugins are added to the extra-plugin package.
- This is a (late) follow on to the discussion started in 2014 with the
subject
  "Ubuntu strongSwan changes" on pkg-swan-devel list.
- Some Features might not show up as change in the configure step. That is
  because they are enabled by default or as dependency to others, and get
now
  "enabled" indirectly due to the additional build dependencies.
  "pool" is such an example.
- Of course to be able to enable all stable plugins I had to add several
  additional build-deps to libjson-c-dev, libldns-dev, libmysqlclient-dev,
  libpcsclite-dev, libtspi-dev, libsoup2.4-dev and libunbound-dev.
- In d/control I mention all addtionally enabled plugins in the package
  descriptions.
- d/libbstrongswan-*-plugins.install got all the added plugins, libs and
conf
  files.

On top of the stable default plugins/features this enables two more
functions
based on user request.
- Also enable kernel-libipsec which is not in upstreams "stable" plugins
  list. This is based on user requests to make strongswan more useful in
  userspace of containers.
  To avoid conflicts it is disabled by default via
  d/p/dont-load-kernel-libipsec-plugin-by-default.patch as
  upstream recommends to not load kernel-libipsec by default.
- integrity-test is another feature people sometimes ask for. It can be
  considered as a little step (clearly not enough) towards FIPS compliance.
  It can help the cautious admin to detect accidentially modified plugins.

Additionally Ubuntu got user requests to make charons default plugin
installation more useful (pad.lv/1640826).
That is eap-mschapv2 for Windows 7+ and modern OSX/iOS using IKEv2 and
xauth-generic for Android and older OSX/iOS using IKEv1 and XAUTH.
To be able to do so the change is following the example of the libstrongswan
plugin packaging and moves those common cases from the
"libcharon-extra-plugins"
to the newly added "libcharon-default-plugins" package

Furthermore it was identified that the whole use case around TNC seems to be
a very selective user group.
See https://wiki.strongswan.org/projects/1/wiki/trustednetworkconnect
Those users (again as with other cases mentioned) might not want to install
all
of the extra-plugins that are needed today. Therefore related functionality
is
moved into packages of its own.
This allows to use TNC without installing extra-plugins package.

Debian already stopped to ship libfast as Ubuntu did for a while.
But it did still mention the associated (and now nor more built) medcli and
medsrv elements.
Also it did not disable it on the configure step which should be done if not
shipping it anyway.
Therefore drop it from d/control and d/rules accordingly.

Due to the new plugins and features there are also more libraries being
built.
Those are only needed by plugins in the extras-plugins package, so add the
libraries there.
- libtpmtss.so available since 5.5
- libnttfft.so available since 5.5
- libmgf1.so available since 5.5.1
​

Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)

[Adrian Bunk]

On Tue, Dec 20, 2016 at 09:01:31AM -0500, Sandro Tosi wrote:
> > it seems the recent upgrade of numpy has broken some tests in other
> > packages like for instance this one in python-skbio.  I wonder whether
> > you are either able to suggest patches to get the tests working with the
> > new interface of numpy again or whether it might be sensible to revert
> > the upgrade of python-numpy to the previous version considering that we
> > are quite close to the freeze.
> 
> There is still a month to the freeze for the existing package, so
> let's not panic already. I'd suggest contacting the upstream of the
> projects with failing test and ask for support

For python-skbio it is *really* time to panic *right now*.

python-skbio is currently not in testing.

For python-skbio to have any chance of being part of stretch, the
latest possible date for an upload of a package without any RC bugs
is Christmas Day (and then not touch the package for 10 days).

If this issue is not resolved by Christmas, your Christmas present for 
the python-skbio maintainers is that their package will definitely not
be part of stretch.

cu
Adrian

-- 

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

Bug#848597: debian-installer: iPXE script in DHCP bootfile option is interpreted as preseed filename

[Philip Hands]

Philip Hands  writes:

> Pali Rohár  writes:
>
>> Package: debian-installer
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> when DHCP server is configured to send bootfile option with iPXE script
>> then debian-installer fails with following "red" error:
>>
>>   [!!] Download debconf preconfiguration file
>>
>>   Failed to process the preconfiguration file
>>
>>   The installer failed to process the preconfiguration file from .
>>   The file may be corrupt.
>>
>> (where  is value of that DHCP option)
>>
>> It looks like debian-installer expects that DHCP bootfile option will
>> contains correct preseed file. And if that DHCP option contains not
>> Debian preseed file, then it show above "red" error message.
>
> Is it the case that iPXE config files are the only things we need to
> worry about here?  (seems probable given the lack of previous reports)
>
> If so, we could just check for '#!ipxe' and if found downgrade the error
> to a warning, or perhaps to log what happened but otherwise ignore it.

It occurs to me that we could fix this by adding a feature.

If we had something that looked out for some string, and would interpret
it as an instruction to immediately chain into a new file, ignoring the
rest of the current file, then one could specify the preseed to use in
the iPXE config, by adding something like this near the start:

  # DEBCONF_CHAIN_LOAD(preseed.cfg)

If we were looking for /DEBCONF_CHAIN_LOAD([^(]*)/ then it would
probably work in anything that has a way of specifying comments, since
it could as easily find it after '// ', '

Bug#721611: RFS: tinycon.js 0.6.5

[Paolo Greppi]

Hi,

I have packaged tinycon.js, see the ITP I am CC-ing and
the repo:
https://anonscm.debian.org/git/pkg-javascript/tinycon.js.git

This is a requirement of etherpad-lite (https://bugs.debian.org/576998).

Please someone more experienced than me review it and if it's OK sponsor
its upload.

Thanks,

Paolo

Bug#848874: terminator: Scrollbar appears when split terminal window using ctrl+o or ctrl+e

[stefan]

 

This might not be related, but when I have my terminator window active
and press "alt+return" to open a new window it opens a new window in the
background and I have to do alt+tab two times in order to get it active.


On 2016-12-20 21:43, Emilio Pozuelo Monfort wrote: 

> On 20/12/16 20:02, ste...@tjugotre.se wrote:
> 
>> Yea, it's exact same behavior in regards to scrollbar. But I want to add 
>> this: Open terminator, ctrl+o to split horizontally result is scrollbars 
>> appear and terminator does not get "splitted" at all. Ctrl+o again and it 
>> gets splitted the way I thought it should have been in the first place, but 
>> I now have three virtual terminals in same window, just one of them is 
>> hidden, If I close the last one by using ctrl+d, the one created with first 
>> ctrl+o keystroke shows up.. I mean, the behaviour is so weird that I have to 
>> send a video to explain it.. :-) These bugs is bad enough I have to 
>> downgrade until it's fixed.
> 
> No need for a video, I know what's going on as it happens to me too.
> 
> That would be:
> 
> https://bugs.launchpad.net/terminator/+bug/1646257 [1]
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846307 [2]
> 
> I'd like to get this fixed, but I haven't had the time yet. Obviously feel 
> free
> to investigate.
> 
> Cheers,
> Emilio
 

Links:
--
[1] https://bugs.launchpad.net/terminator/+bug/1646257
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846307

Bug#804429: python-libpcap: FTBFS: pcap.c:4397:37: error: '_wrap_pcap_doc_swigconstant' undeclared here (not in a function)

[Chris Lamb]

Hi Christoph,

> I cannot reproduce this, build passed twice on an updated sid build
> environment. Can you please re-check?

Seems to work for me now :)  (Closing in BCC.)


Regards,

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

Bug#848852: [Android-tools-devel] Bug#848852: adb command error with backtrace

[Senthil Kumaran S]

On Tuesday 20 December 2016 04:11 PM, Hans-Christoph Steiner wrote:
> what about the sid and stretch instances?  Do they also have the package
> version mismatch?

No they won't, since it is a fresh installation of sid and stretch
within a qemu device on top of jessie host.

-- 
Senthil Kumaran S
http://www.stylesen.org/
http://www.sasenthilkumaran.com/



signature.asc
Description: OpenPGP digital signature

Bug#848962: nqc: Segfaults with -TSwan -L

[Petter Reinholdtsen]

Package: nqc
Version: 3.1.r6-1

Running nqc with -TSwan -L segfaults.  Here is a demonstration:

% cat web2.nqc 
task main()
{
}
% valgrind nqc -TSwan -L web2.nqc
==26607== Memcheck, a memory error detector
==26607== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==26607== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==26607== Command: nqc -TSwan -L web2.nqc
==26607== 
==26607== 
==26607== Process terminating with default action of signal 11 (SIGSEGV)
==26607==  Bad permissions for mapped region at address 0x43D4E0
==26607==at 0x41BC6D: ??? (in /usr/bin/nqc)
==26607==by 0x41BEB5: ??? (in /usr/bin/nqc)
==26607==by 0x41F375: ??? (in /usr/bin/nqc)
==26607==by 0x404259: ??? (in /usr/bin/nqc)
==26607==by 0x402275: ??? (in /usr/bin/nqc)
==26607==by 0x56F42B0: (below main) (libc-start.c:291)
==26607== 
==26607== HEAP SUMMARY:
==26607== in use at exit: 229,107 bytes in 4,197 blocks
==26607==   total heap usage: 5,845 allocs, 1,648 frees, 427,541 bytes allocated
==26607== 
==26607== LEAK SUMMARY:
==26607==definitely lost: 32 bytes in 1 blocks
==26607==indirectly lost: 27 bytes in 2 blocks
==26607==  possibly lost: 65,512 bytes in 2,562 blocks
==26607==still reachable: 163,536 bytes in 1,632 blocks
==26607== suppressed: 0 bytes in 0 blocks
==26607== Rerun with --leak-check=full to see details of leaked memory
==26607== 
==26607== For counts of detected and suppressed errors, rerun with: -v
==26607== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault
%

I came across this problem in Ubuntu,
https://bugs.launchpad.net/ubuntu/+source/nqc/+bug/436456 >.
--
Happy hacking
Petter Reinholdtsen

Bug#848961: nano: please update syntax highlighting for nftables

[Jordi Mallach]

Hi Arturo,

El dc 21 de 12 de 2016 a les 09:26 +0100, en/na Arturo Borrero Gonzalez
va escriure:
> Package: nano
> Version: 2.7.1-1
> Severity: wishlist
> Tags: patch
> 
> Dear nano maintainers,
> 
> thanks for working in my editor of choice. It's really appreciated.
> 
> I tried to generate a patch for the nftables syntax highlighting, but
> failed
> to find the source repo (the current git link from the tracker points
> to an
> empty repository).
> 
> So, please, would you take the new file from here the file and push
> it
> yourself?:
> 
> https://raw.githubusercontent.com/aborrero/nftables-nano-syntax/maste
> r/nftables.nanorc

Can you submit this to nano-de...@gnu.org? I hope there'll be a release
soonish and it can be included in stretch.

If you prefer, I can bring it up there for you, too.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

Bug#848867: RFS: xalan/1.11-6

[Bill Blough]

On Wed, Dec 21, 2016 at 07:05:52AM +, Gianfranco Costamagna wrote:
> Hi
> 
> 
> a quick look seems to show a progress when removing debian/autoreconf file.
> http://debomatic-amd64.debian.net/distribution#unstable/xalan/1.11-6.1/buildlog
> G.

Yes, it looks like using debian/autoreconf with --sourcedirectory causes
autoreconf to get called on/from (depending on your perspective) the
wrong directory.

Thanks for looking at it.  Now I just need to figure out why the build
is failing.  I hope to have some time later today.

Bug#848961: nano: please update syntax highlighting for nftables

[Arturo Borrero Gonzalez]

On 21 December 2016 at 10:47, Jordi Mallach  wrote:
> Can you submit this to nano-de...@gnu.org? I hope there'll be a release
> soonish and it can be included in stretch.
>
> If you prefer, I can bring it up there for you, too.

I would prefer this path. Please go ahead :-)

thanks.

Bug#774415: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Johannes Schauer]

Hi,

Quoting Holger Levsen (2016-12-21 10:32:07)
> On Wed, Dec 21, 2016 at 08:14:23AM +0100, Johannes Schauer wrote:
> > > (though I'm not sure I fully understand why not assume -rb if
> > > foo.buildinfo is given - I do understand for foo.changes…)
> > 
> >  - Because I'm not so sure that the user is aware that passing a .buildinfo
> >file will mean that sbuild is querying snapshot.d.n without asking the 
> > user
> >for further consent.
> 
> what's the problem with that? (especially compared to downloading
> packages from ftp.*.debian.org, which is also done…)

because somebody who *does* care about this and uses their own local mirror
will have their setup subverted by this feature without any warning.

> >  - Because then we would only allow .buildinfo files that include the
> >  source package hash as well which I find quite limiting - especially
> >  considering how the Debian autobuilders will exclusively generate
> >  .buildinfo files of that kind
> 
> why? If I call "sbuild foo.buildinfo" and that .buildinfo file has no
> source hashes, then sbuild should fail. Easy. (?!?!)

Why should it then fail in your opinion?

Sure, it's easy to implement but I wonder if this restrictions makes sense. Why
do you think it does?

> You seem to imply that the Debian autobuilders will generate .buildinfo files
> without source hashes - I think *that* is a problem - how can we fix it?

Autobuilders only generate the arch:all and arch:any binary packages from the
source package they are given. They do not regenerate the source package. Thus,
they will call dpkg-buildpackage with --build=any or --build=all which in turn
will create a .buildinfo that doesn't contain the source hash.

If one tries passing --buildinfo-option=--build=full to dpkg-buildpackage then
this will lead to a build failure if dpkg-buildpackage was not also called with
--build=full. This makes sense on the level of dpkg-buildpackage because it's
possible to build binary packages without having the source package. But on the
autobuilder level the source package always exists. It would thus probably have
to be sbuilds job to mangle the buildinfo file and insert the source package
hash in it. But if you do that then you get to disparities between people
generating their buildinfo with sbuild/pbuilder and people who just use
dpkg-buildpackage...

cheers, josch


signature.asc
Description: signature

Bug#774415: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Holger Levsen]

Hi,

On Wed, Dec 21, 2016 at 10:52:54AM +0100, Johannes Schauer wrote:
> because somebody who *does* care about this and uses their own local mirror
> will have their setup subverted by this feature without any warning.

well, I (the user) feed it with a .buildinfo files, which needs old
versions. So I basically *ask* for snapshot.d.o to be used.

I'd *expect* that snapshot.d.o is being used!

> > why? If I call "sbuild foo.buildinfo" and that .buildinfo file has no
> > source hashes, then sbuild should fail. Easy. (?!?!)
> 
> Why should it then fail in your opinion?
 
because for rebuilding purposes, .buildinfo files without source hashes
are broken. (And as .buildinfo files are made for rebuilding, I'd say
.buildinfo files without source hashes are always broken.)

> Sure, it's easy to implement but I wonder if this restrictions makes sense. 
> Why
> do you think it does?

Because I dont expect there are .buildinfo files without source hashes.

> > You seem to imply that the Debian autobuilders will generate .buildinfo 
> > files
> > without source hashes - I think *that* is a problem - how can we fix it?
> 
> Autobuilders only generate the arch:all and arch:any binary packages from the
> source package they are given. They do not regenerate the source package. 
> Thus,
> they will call dpkg-buildpackage with --build=any or --build=all which in turn
> will create a .buildinfo that doesn't contain the source hash.

SIGH.

This is a *major* problem, I think.

> If one tries passing --buildinfo-option=--build=full to dpkg-buildpackage then
> this will lead to a build failure if dpkg-buildpackage was not also called 
> with
> --build=full. This makes sense on the level of dpkg-buildpackage because it's
> possible to build binary packages without having the source package. But on 
> the
> autobuilder level the source package always exists. It would thus probably 
> have
> to be sbuilds job to mangle the buildinfo file and insert the source package
> hash in it. But if you do that then you get to disparities between people
> generating their buildinfo with sbuild/pbuilder and people who just use
> dpkg-buildpackage...

makes sense and sucks. Need to think more about this.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#846485: Acknowledgement (gitlab: no syntax highlighting)

[Xavier Bestel]

Hi,

This is fixed with the latest gitlab package (8.13.6+dfsg2-2).
Please close the bug.

Thanks,
Xav

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Yves-Alexis Perez]

On Wed, 2016-12-21 at 10:32 +0100, Christian Ehrhardt wrote:
> Commits:
> 0733afe * d/rules: Reorganize to ease maintenance
> be360c3 changelog: d/rules: Reorganize to ease maintenance
> 45adecc * d/control: Wrap and sort to ease maintenance
> 00bcdba changelog: d/control: Wrap and sort to ease maintenance

Looks good. I've applied the first two locally, and will include the latter
ones after reviewing the other changes (since the changelog commit won't apply
right now).

Regards,
-- 
Yves-Alexis

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

Bug#808634: cadabra in Debian

[Axel Beckert]

Hi Kasper,

Kasper Peeters wrote:
> > Uploaded last night. The build failed on a bunch of architectures
> > (arm64, armel, armhf, pppc64el, powerpc, s390x)) due to failing tests.
> > It was always the test fieldtheory which hang on these architectures
> > and was killed after reaching an timeout.
> > 
> > My current suspicion is that lie doesn't behave as expected on these
> > architectures. Haven't checked it explicitly, though.
> 
> I would not waste more time on this; the bit that requires LiE is only
> a very small part of the total functionality, and this dependency will
> go away in 2.x anyway. Just disabling that test is fine with me.

That's what I have done and what already helped: All architectures
which failed with that test have now passed the test suite and built
fine. Additionally all release (i.e. relevant) architectures already
built fine, too:

https://buildd.debian.org/status/package.php?p=cadabra&suite=unstable

So it looks quite good now. Will nevertheless keep an eye on it.

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

Bug#848963: logcheck: Regular expressions for rsyslog no longer match

[Helge Kreutzmann]

Package: logcheck
Version: 1.3.17
Severity: normal

Currently, rsyslog has the following regexps:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: \[origin software="rsyslogd" 
swVersion="[0-9.]+" x-pid="[0-9]+" x-info="http://www.rsyslog.com"\] start$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: \[origin software="rsyslogd" 
swVersion="[0-9.]+" x-pid="[0-9]+" x-info="http://www.rsyslog.com"\] exiting on 
signal [0-9]+.$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: \[origin software="rsyslogd" 
swVersion="[0-9.]+" x-pid="[0-9]+" x-info="http://www.rsyslog.com"\] rsyslogd 
was HUPed$

However, for a few weeks the following lines appear in the logs:
Dec 19 17:26:51 samd liblogging-stdlog:  [origin software="rsyslogd" 
swVersion="8.23.0" x-pid="806" x-info="http://www.rsyslog.com";] start
Dec 19 17:31:52 samd liblogging-stdlog:  [origin software="rsyslogd" 
swVersion="8.23.0" x-pid="806" x-info="http://www.rsyslog.com";] rsyslogd was 
HUPed

(Note rsyslogd → liblogging-stdlog)

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

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

Versions of packages logcheck depends on:
ii  adduser3.115
ii  cron   3.0pl1-128
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC6-1
ii  lockfile-progs 0.1.17
ii  logtail1.3.17
ii  mime-construct 1.11+nmu2
ii  rsyslog [system-log-daemon]8.23.0-2

Versions of packages logcheck recommends:
ii  logcheck-database  1.3.17

Versions of packages logcheck suggests:
pn  syslog-summary  

-- Configuration Files:
/etc/logcheck/logcheck.conf [Errno 13] Keine Berechtigung: 
u'/etc/logcheck/logcheck.conf'
/etc/logcheck/logcheck.logfiles [Errno 13] Keine Berechtigung: 
u'/etc/logcheck/logcheck.logfiles'

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#848964: ITP: node-rx -- The Reactive Extensions for JavaScript

[Paolo Greppi]

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

* Package name: node-rx
  Version : 4.1.0
  Upstream Author : Cloud Programmability Team
(https://github.com/Reactive-Extensions/RxJS/blob/master/authors.txt)
* URL : https://github.com/Reactive-Extensions/RxJS
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : The Reactive Extensions for JavaScript

 A set of libraries to compose asynchronous and event-based
 programs using observable collections andArray#extras style
 composition in JavaScript.
 .
 Node.js is an event-based server-side JavaScript engine.

It is required for node-inquirer (ITP: https://bugs.debian.org/848364)
which in turn is required by node-yarnpkg 0.18 (ITP:
https://bugs.debian.org/843021).

My intention is to package it within the javascript maintainers team.

The repo will be on alioth:
https://anonscm.debian.org/git/pkg-javascript/node-rx.git

Paolo

Bug#848959: git: malloc failed (tried to allocate 536870912 bytes)

[Heinrich Schuchardt]

The problem stemmed from an entry http.postbuffer in .gitconfig.

Please close the bug report.

On 12/21/2016 09:18 AM, Heinrich Schuchardt wrote:
> Package: git
> Version: 1:2.11.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> on a system with only 512 MB installed I received the following error:
> 
> $ free
>   totalusedfree  shared  buff/cache   
> available
> Mem: 474232  114984  1927601476  166488  
> 348564
> Swap: 0   0   0
> 
> $ git clone https://github.com/xypron/skyldav
> Cloning into 'skyldav'...
> fatal: Out of memory, malloc failed (tried to allocate 536870912 bytes)
> fatal: The remote end hung up unexpectedly
> 
> https://www.debian.org/releases/stable/arm64/ch03s04.html.en
> has the following requirements for headless systems:
> minimum RAM: 128MiB
> recommended: 512MiB
> (I could not find the corresponding page for Stretch.)
> 
> Allocating 512MiB on git clone without fallback to a smaller quantity
> is a violation of this policy.
> 
> A possible solution would be to limit the malloc call to 1/4 of the
> physical memory (without swap).
> 
> Best regards
> 
> Heinrich Schuchardt
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 4.9.0-next-20161212-r015-arm64 (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages git depends on:
> ii  dpkg 1.18.15
> ii  git-man  1:2.11.0-1
> ii  libc62.24-8
> ii  libcurl3-gnutls  7.50.1-1
> ii  liberror-perl0.17024-1
> ii  libexpat12.2.0-1
> ii  libpcre3 2:8.39-2
> ii  perl 5.24.1~rc4-1
> ii  zlib1g   1:1.2.8.dfsg-4
> 
> Versions of packages git recommends:
> ii  less 481-2.1
> ii  openssh-client [ssh-client]  1:7.3p1-5
> ii  patch2.7.5-1
> ii  rsync3.1.2-1
> 
> Versions of packages git suggests:
> ii  gettext-base  0.19.8.1-1
> pn  git-arch  
> pn  git-cvs   
> pn  git-daemon-run | git-daemon-sysvinit  
> pn  git-doc   
> pn  git-el
> ii  git-email 1:2.11.0-1
> pn  git-gui   
> pn  git-mediawiki 
> pn  git-svn   
> pn  gitk  
> pn  gitweb
> 
> -- no debconf information
> 

Bug#847100: [#ICF-674-66436]: Bug#847100: Acknowledgement (mirror listing update for debian.mirror.globo.tech)

[GloboTech]

Greetings,

We are trying to update the record debian.mirror.gtcomm.net by 
debian.mirror.globo.tech since more than two weeks now, can you please see 
what's going on with this case ?
And let us know if there is anything missing on your side; Thank you in advance,

847100: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847100

GloboTech Team.

==
Sebastien Francois
System Administrator
GloboTech Communications
Phone: 1-514-907-0050
Toll Free: 1-(888)-GTCOMM1
Fax: 1-(514)-907-0750
supp...@globo.tech
https://globo.tech


Ticket Details
-
Ticket ID: ICF-674-66436
Department: Support
Type: Issue
Status: In Progress
Priority: Medium

Support Center: http://support.globo.tech/index.php?

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Yves-Alexis Perez]

On Wed, 2016-12-21 at 10:32 +0100, Christian Ehrhardt wrote:
> Background to explain the reasoning behind the change 2/7:
> 
> Commits:
> 944a3c7 * d/rules: Make override_dh_strip a nop.
> b7754fe changelog: d/rules: Make override_dh_strip a nop

I don't think this one is ok. Stripping the binaries is a Debian Policy
*should*.
> 
> The (to be enabled in a later commit in this series) plugin "integrity-test"
> provides a useful extra feature for the cautious strongswan admin.
> It stores checksums of its libraries and can check non-malicious errors to
> avoid accidentially loading bad libraries.
> See https://wiki.strongswan.org/projects/strongswan/wiki/IntegrityTest for
> more.
> 
> It is an experimental feature, but out there for a while and was enabled in
> Ubuntu per user request, so I assume it has its use in the field.

I have my opinion on this, but I'll keep them to that latter mail.
> 
> To be able to do so it stores the checksums as part of the build process.
> But to match those sums later on the build is not allowed to strip the
> plugins.
> That is listed in the "conflicts" section of the Wiki page.

I think it'd be best to store the checksum of the stripped binaries in any
case.
> 
> Therefore override "override_dh_strip:" with a comment that explains why
> strip
> is skipped.
> 

Regards,
-- 
Yves-Alexis

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

Bug#847567: [Pkg-fonts-devel] Bug#847567: ttf-dejavu: Probably removal needed

[Fabian Greffrath]

Cyril Brulebois wrote:
> It would be great to check with debian-boot@ before handling such RM
> requests (removal of udeb-producing packages). We would have had a
> chance to switch to the “new” package.

Oh, I am sorry for this. I hope the actual switch is as easy as I imagine
(s/ttf/fonts/)?

Cheers,

Fabian

Bug#848965: midori: Icon not shown in menu after installation

[gabry2105]

Package: midori
Version: 0.5.11-ds1-4
Severity: minor

Dear Maintainer,

I removed firefox browser to install midori instead. After installation I note
that there is not the icon in the relative menu item.

Steps to reproduce:
 1. Remove firefox:
   > sudo apt-get remove firefox-esr
 2. Install midori
   > sudo apt-get install midori
 3. Open the menu: Applications > Internet > Midori

Result:
 There is two items: Midori and Midori Private Browser botw without icon.

Expected Result:
 Midori and Midori Private Browser item should have an icon on the left.

Desktop Environment: Xfce 4.12 with Xfce-dusk theme.



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

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

Versions of packages midori depends on:
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-7
ii  libcairo2   1.14.6-1.1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libgck-1-0  3.20.0-3
ii  libgcr-base-3-1 3.20.0-3
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.2-2
ii  libgtk2.0-0 2.24.31-1
ii  libjavascriptcoregtk-1.0-0  2.4.11-3
ii  libp11-kit0 0.23.2-5
ii  libpango-1.0-0  1.40.3-3
ii  libpangocairo-1.0-0 1.40.3-3
ii  libpangoft2-1.0-0   1.40.3-3
ii  libsoup-gnome2.4-1  2.56.0-1
ii  libsoup2.4-12.56.0-1
ii  libsqlite3-03.15.2-1
ii  libwebkitgtk-1.0-0  2.4.11-3
ii  libx11-62:1.6.3-1
ii  libxml2 2.9.4+dfsg1-2.1
ii  libxss1 1:1.2.2-1
ii  libzeitgeist-2.0-0  0.9.16-0.2

Versions of packages midori recommends:
ii  gnome-icon-theme  3.12.0-2
ii  gnome-keyring 3.20.0-3

midori suggests no packages.

-- no debconf information

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Yves-Alexis Perez]

On Wed, 2016-12-21 at 10:32 +0100, Christian Ehrhardt wrote:
> Background to explain the reasoning behind the change 3/7:
> 
> Commits:
> 0af16a2 * d/rules: Set minimal TESTS_REDUCED_KEYLENGTHS
> e024f7e changelog: d/rules: Set minimal TESTS_REDUCED_KEYLENGTHS to avoid
> hanging builds
> 
> There were several cases where low entropy build environments stalled.
> This was up to an amount that sometimes builds failed with timeouts.
> 
> Obviously the more options that are enabled the more will be tested and the
> bigger the effect of this is.
> 
> Fortunately the strongswan build/test has an environment variable to control
> this behavior and if set to 1 all tests will still be run, but require much
> less entropy.
> See
> https://wiki.strongswan.org/projects/strongswan/wiki/DeveloperDocumentation
> for the Strongswan documentation on this option.
> 
We did enable REDUCED_KEYLENGTH at one point on !linux and !x86, but it still
wasn't enough, so we completely disabled the test suite on !x86. I'd rather
not disable more of the test suite, to be honest.

Regards,
-- 
Yves-Alexis

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

Bug#799285: [Uptade] ITP: mailman3-postorius -- Django web user interface for accessing GNU Mailman3

[Pierre-Elliott Bécue]

Control: retitle -1 ITP: mailman3-postorius -- Django web user interface for 
accessing GNU Mailman3
Control: owner -1 Pierre-Elliott Bécue 

Waiting for a python3.5 compatible version of mailman3 core for a RFS.
-- 
PEB

Bug#848966: enigmail needs "gnupg-agent --use-standard-socket"

[Harald Dunkel]

Package: gnupg2
Version: 2.0.26-6+deb8u1

To make pinentry work enigmail needs a gpg-agent started with
"--use-standard-socket", but /etc/X11/Xsession.d/90gpg-agent
ignores the appropriate setting in .gnupg/gpg-agent.conf . The
command gpg-agent command line (as shown by ps -ef) is

/usr/bin/gpg-agent --daemon --sh 
--write-env-file=/home/user/.gnupg/gpg-agent-info-hostname.example.com 
/usr/bin/dbus-launch --exit-with-session /home/user/.xsession

If I kill this gpg-agent and start a new one using

/usr/bin/gpg-agent --use-standard-socket --daemon --sh 
--write-env-file=/home/user/.gnupg/gpg-agent-info-hostname.example.com 
/usr/bin/dbus-launch --exit-with-session /home/user/.xsession

then enigmail is happy.


gpg-agent.conf:

###+++--- GPGConf ---+++###
default-cache-ttl 300
max-cache-ttl 3000
###+++--- GPGConf ---+++### Wed Aug 13 09:01:21 2014 CEST
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.

default-cache-ttl 36000
default-cache-ttl-ssh 36000
max-cache-ttl 36000
max-cache-ttl-ssh 36000

use-standard-socket


Regards
Harri

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Yves-Alexis Perez]

On Wed, 2016-12-21 at 10:33 +0100, Christian Ehrhardt wrote:
> Commits:
> 59e9a0b * add and install apparmor profiles
> 3d124a4 changelog: Add and install strongswan apparmor profiles
> 
> Make the usage of strongswan even more secure by providing an apparmor
> profile
> for it.

Thanks! I've applied them locally and I'll test them in the next few days but
I'm not sure if we want to push them just before the Debian freeze. I'll let
you know.

Regards,
-- 
Yves-Alexis

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

Bug#848869: Error: could not create default cluster. Please create it manually with

[Christoph Berg]

Control: tags -1 moreinfo

Re: Darshaka Pathirana 2016-12-20 
<20161220110151.19348.48480.reportbug@invincible>
>   Error: The locale requested by the environment is invalid.

> Locale looks like this:
> 
>   % locale
>   LANG=en_US.UTF-8
>   LANGUAGE=en_US:en

Hi,

on package installation (only), the locale used for pg_createcluster
(= initdb) is not determined by your environment (which "locale" looks
at), but by the system configuration in /etc/environment and
/etc/default/locale.

Could you check what you have configured in these files?

Christoph

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Yves-Alexis Perez]

On Wed, 2016-12-21 at 10:33 +0100, Christian Ehrhardt wrote:
> Commits:
> 6bf2bf5 * Add basic DEP8 tests
> 6f408a9 changelog: Add basic DEP8 tests
> 
> As basic CI dep8 based autopkgtests provide a very useful level of automated
> sanity checks to become part of debci at https://ci.debian.net/.
> See https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
> for
> basics.

Thanks, included. The shell scripts seem to lack a bit of defensive
programming (quoted variable etc.) but that can be fixed later.

Regards,
-- 
Yves-Alexis

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

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Christoph Biedl]

Guillem Jover wrote...

> [ Please remember to CC people, otherwise only the maintainer and
> people subscribed to the bug (hich requires explicit action) might
> see your replies. :) I just noticed when scanning the web interface. ]

Well, this makes the recipient list pretty long then ...

Status update: I took the liberty to contact upstream (Bernhard) and
got an answer. Sharing the essential bits, although a bit indiscreet
but I guess you all are somewhat concerned already: He is working on
it, and he is aware of the release schedule.

Christoph


signature.asc
Description: Digital signature

Bug#848054: debci: FTBFS randomly (failing tests)

[Antonio Terceiro]

On Tue, Dec 13, 2016 at 05:34:46PM +0100, Santiago Vila wrote:
> Package: src:debci
> Version: 1.5
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> dh build-indep --with systemd
>dh_testdir -i
>dh_update_autotools_config -i
>dh_auto_configure -i
>dh_auto_build -i
>   make -j1
> make[1]: Entering directory '/<>'
> Makefile:3: links.mk: No such file or directory
> awk '{ print("LINKS +=", $1); print($1, ":"); print("\tmkdir -p $(shell 
> dirname ", $1, ")"); print("\tln -sf", $2, $1)}' links > links.mk
> rm -f public/doc/js/jquery.js
> yardoc --markup markdown --output-dir public/doc --main README.md lib - 
> README.md docs/INSTALL.md docs/TUTORIAL.md docs/HACKING.md docs/RUBYAPI.md 
> docs/MAINTAINERS.md lib/debci.rb lib/debci/config.rb lib/debci/repository.rb 
> lib/debci/html.rb lib/debci/blacklist.rb lib/debci/package.rb 
> lib/debci/graph.rb lib/debci/status.rb
> Files:   8
> 
> [... snipped ...]
> 
> 
> Finished in 0.13522 seconds (files took 0.08575 seconds to load)
> 86 examples, 0 failures
> 
> 
> 
> ??? Functional tests  
>???
> 
> 
> test/runall.sh
> ./test_list_packages.sh
> test_with_whitelist
> test_with_blacklist
> test_executable_whitelist
> test_remove_duplicates
> 
> Ran 4 tests.
> 
> OK
> ??? ./test_list_packages.sh passed all tests
> ./test_generate_html.sh
> test_almost_empty_data_dir
> 
> Ran 1 test.
> 
> OK
> ??? ./test_generate_html.sh passed all tests
> ./test_blame.sh
> test_package_that_never_passed_a_test_cant_blame
> test_failing_test_blames_dependencies
> test_updated_dependency_of_already_failing_package_is_not_blamed
> test_new_dependency_of_already_failing_package_is_not_blamed
> test_passing_the_test_resets_the_blame
> test_blame_updated_dependency
> test_updated_dependencies_dont_get_blamed_when_package_is_also_updated
> test_package_is_not_blamed_for_its_own_failure
> 
> Ran 8 tests.
> 
> OK
> ??? ./test_blame.sh passed all tests
> ./test_basics.sh
> Error: process_not_running
> opening socket to localhost:5677opening socket to localhost:5677
> 
> opening socket to localhost:5677
> E: Build killed with signal TERM after 60 minutes of inactivity
> 
> 
> This is just one of the way it fails (build hangs), but not the only one.
> I attach a bunch of failed build logs.

I was already able to reproduce the issue, but not consistently. Do you
have an estimate of how frequent the failures are (in % for example)?


signature.asc
Description: PGP signature

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Yves-Alexis Perez]

On Wed, 2016-12-21 at 10:34 +0100, Christian Ehrhardt wrote:
> Commits:
> 514dc31 * Add updated logcheck rules to match recent strongswan output
> ab32a3f changelog: Add updated logcheck rules to match recent strongswan
> output

Thanks, applied.

Regards,
-- 
Yves-Alexis

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

Bug#848967: linux-image: Power button of Dell XPS13 does not send any events

[Paul Menzel]

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

Dear Debian folk,


pressing the power button on the Dell XPS13 no event is sent.

Neither `xev` nor `acpi_listen` shows something.

If I remember correctly, it worked on the shipped Ubuntu 16.04 from Dell.


Kind regards,

Paul Menzel

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


** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=2809c0c6-7152-4e35-a6da-a26e7400e556 ro quiet


** Not tainted

** Kernel log:
[2.356558] Bluetooth: HCI UART protocol Intel registered
[2.356568] Bluetooth: HCI UART protocol BCM registered
[2.356568] Bluetooth: HCI UART protocol QCA registered
[2.362373] ACPI: Battery Slot [BAT0] (battery present)
[2.362520] wmi: Mapper loaded
[2.363711] idma64 idma64.0: Found Intel integrated DMA 64-bit
[2.364301] intel-lpss :00:15.1: enabling device ( -> 0002)
[2.364519] idma64 idma64.1: Found Intel integrated DMA 64-bit
[2.364872] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[2.366919] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:04F3:2234.0001/input/input8

[2.368091] mei_me :00:16.0: enabling device ( -> 0002)
[2.368133] hid-multitouch 0003:04F3:2234.0001: 
input,hiddev0,hidraw0: USB HID v1.10 Device [ELAN Touchscreen] on 
usb-:00:14.0-4/input0

[2.369771] input: PC Speaker as /devices/platform/pcspkr/input/input10
[2.381350] usbcore: registered new interface driver btusb
[2.382577] bluetooth hci0: firmware: failed to load 
qca/rampatch_usb_0302.bin (-2)
[2.382751] bluetooth hci0: Direct firmware load for 
qca/rampatch_usb_0302.bin failed with error -2
[2.382753] Bluetooth: hci0: failed to request rampatch file: 
qca/rampatch_usb_0302.bin (-2)

[2.383359] i801_smbus :00:1f.4: SMBus using PCI interrupt
[2.471578] dcdbas dcdbas: Dell Systems Management Base Driver 
(version 5.6.0-3.2)

[2.480502] [drm] Memory usable by graphics device = 4096M
[2.480504] [drm] Replacing VGA console driver
[2.483581] ath10k_pci :3a:00.0: pci irq msi oper_irq_mode 2 
irq_mode 0 reset_mode 0

[2.484252] Console: switching to colour dummy device 80x25
[2.487901] intel_rapl: Found RAPL domain package
[2.487903] intel_rapl: Found RAPL domain core
[2.487903] intel_rapl: Found RAPL domain uncore
[2.487904] intel_rapl: Found RAPL domain dram
[2.490884] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.490885] [drm] Driver supports precise vblank timestamp query.
[2.492445] iTCO_vendor_support: vendor-support=0
[2.493325] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[2.493484] iTCO_wdt: Found a Intel PCH TCO device (Version=4, 
TCOBASE=0x0400)

[2.493628] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[2.496855] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[2.497712] i915 :00:02.0: firmware: direct-loading firmware 
i915/kbl_dmc_ver1_01.bin

[2.498292] [drm] Finished loading i915/kbl_dmc_ver1_01.bin (v1.1)
[2.504002] [drm] GuC firmware load skipped
[2.542973] ACPI: Video Device [GFX0] (multi-head: yes  rom: no 
post: no)
[2.543853] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input11
[2.544275] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[2.544279] [drm] Initialized i915 1.6.0 20160711 for :00:02.0 on 
minor 0

[2.553300] fbcon: inteldrmfb (fb0) is primary device
[2.608135] snd_hda_codec_realtek hdaudioC0D0: autoconfig for 
ALC3246: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[2.608136] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[2.608137] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)

[2.608137] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[2.608138] snd_hda_codec_realtek hdaudioC0D0:inputs:
[2.608139] snd_hda_codec_realtek hdaudioC0D0:  Headset Mic=0x19
[2.608139] snd_hda_codec_realtek hdaudioC0D0:  Headphone Mic=0x1a
[2.608140] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[2.622922] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input12
[2.624693] input: HDA Intel PCH Headphone Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input13
[2.624748] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[2.624791] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[2.624866] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input16

[2.720318] random: crng init done
[2.734006] input: DLL075B:01 

Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)

[Andreas Tille]

Hi Adrian and Anton,

On Wed, Dec 21, 2016 at 11:40:16AM +0200, Adrian Bunk wrote:
> On Tue, Dec 20, 2016 at 09:01:31AM -0500, Sandro Tosi wrote:
> > > it seems the recent upgrade of numpy has broken some tests in other
> > > packages like for instance this one in python-skbio.  I wonder whether
> > > you are either able to suggest patches to get the tests working with the
> > > new interface of numpy again or whether it might be sensible to revert
> > > the upgrade of python-numpy to the previous version considering that we
> > > are quite close to the freeze.
> > 
> > There is still a month to the freeze for the existing package, so
> > let's not panic already. I'd suggest contacting the upstream of the
> > projects with failing test and ask for support
> 
> For python-skbio it is *really* time to panic *right now*.
> 
> python-skbio is currently not in testing.
> 
> For python-skbio to have any chance of being part of stretch, the
> latest possible date for an upload of a package without any RC bugs
> is Christmas Day (and then not touch the package for 10 days).
> 
> If this issue is not resolved by Christmas, your Christmas present for 
> the python-skbio maintainers is that their package will definitely not
> be part of stretch.

Thanks for confirming that I was not actually panicing. ;-)

Sandro, would you reconsider my suggestion to revert this
mini-transition?  I do not see a realistic chance that upstream will
come up with fixes in the next two days.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#848889: hplip-data: There are no PPDs in the package

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le mardi, 20 décembre 2016, 15.09:16 h CET Brian Potkin a écrit :
>   This package contains data files for the HP Linux Printing
>   and Imaging System.
> 
> would reflect the situation better.

Thanks for this patch. I should really go with you through the steps of giving 
you commit access (and confidence) so as to let you do the enhancements like 
this one  yourself. It would reduce our combined work!

Do you already have an Alioth account ?

-- 
Cheers,
OdyX

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

Bug#848931: dgit: please add a configuration variable that prevents me from accidentally doing a non-source-only upload

[Ian Jackson]

Sean Whitton writes ("Bug#848931: dgit: please add a configuration variable 
that prevents me from accidentally doing a non-source-only upload"):
> Good idea.  This option should be ignored when --new is present.

I was thinking about this some more and I wonder if a different
approach would be better.

If we're doing a source-only upload, the user might not want to do
binary-build-for-upload at all.  It is only binary-builds-for-upload
that need to be done in a clean chroot: source packages can (I think,
and dgit relies on this) safely be manipulated in the user's working
environment.

So I was thinking that maybe there should be a `dgit push-source'
subcommand which does not depend on the existence, or look for, any
previously built artefacts.  It would build the source package afresh
(a la dgit `build-source') and upload it, in one subcommand.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#848931: dgit: please add a configuration variable that prevents me from accidentally doing a non-source-only upload

[Johannes Schauer]

Hi,

Quoting Ian Jackson (2016-12-21 12:10:38)
> Sean Whitton writes ("Bug#848931: dgit: please add a configuration variable 
> that prevents me from accidentally doing a non-source-only upload"):
> > Good idea.  This option should be ignored when --new is present.
> 
> I was thinking about this some more and I wonder if a different
> approach would be better.
> 
> If we're doing a source-only upload, the user might not want to do
> binary-build-for-upload at all.  It is only binary-builds-for-upload
> that need to be done in a clean chroot: source packages can (I think,
> and dgit relies on this) safely be manipulated in the user's working
> environment.
> 
> So I was thinking that maybe there should be a `dgit push-source'
> subcommand which does not depend on the existence, or look for, any
> previously built artefacts.  It would build the source package afresh (a la
> dgit `build-source') and upload it, in one subcommand.

solving this issue like that might fix another issue I usually have.

I usually do:

 - dgit sbuild # checking that everything works fine
 - dgit build-source
 - dgit push

Unfortunately, between the first and the second step, I have to manually remove
the *.changes files that the "dgit sbuild" step left. I understand that this is
because there would otherwise be an ambiguity about which .changes to upload.

With a "dgit push-source" subcommand, this ambiguity would be gone and I might
no longer have to manually rm the .changes files created by sbuild.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#782763: Seeking for a dedicated personal assistant

[Daniel tax services llc]

We are looking for someone who can dedicate 4-5 hrs M-F in getting a particular 
task done ..Will work from home and will be flexible. You will be trained on 
some specific job . Experience is not necessary but willingness to perform a 
task dutifully is of utmost importance. RequirementA computer with internet 
accessA printerOpen availablity Payment$400 weeklyDaniel PenningsRecruitment 
and Staffing9196007109

Bug#782763: Seeking for a dedicated personal assistant

[Daniel tax services llc]

We are looking for someone who can dedicate 4-5 hrs M-F in getting a particular 
task done ..Will work from home and will be flexible. You will be trained on 
some specific job . Experience is not necessary but willingness to perform a 
task dutifully is of utmost importance. RequirementA computer with internet 
accessA printerOpen availablity Payment$400 weeklyDaniel PenningsRecruitment 
and Staffing9196007109

Bug#848968: piuparts.debian.org: should have a sid-merged-usr test

[Andreas Beckmann]

Package: piuparts.debian.org
Severity: normal

with debootstrap in stretch defaulting to --merged-usr, we need
a) running debootstrap by default with --no-merged-usr in stretch+
b) have another sid suite with a separate tarball and --merged-usr
   ignoring /bin and /lib symlinks

Andreas

Bug#848969: RFS: dvdisaster/0.79.5-1~exp1

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "dvdisaster"

 * Package name: dvdisaster
   Version : 0.79.5-1~exp1
   Upstream Author : Carsten Gnörlich 
 * URL : http://dvdisaster.net/
 * License : GPL-3
   Section : otherosfs

It builds those binary packages:

 dvdisaster - data loss/scratch/aging protection for CD/DVD media
 dvdisaster-doc - data loss/scratch/aging protection for CD/DVD media 
(documentation)

To access further information about this package, please visit the following 
URL:

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

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dvdisaster/dvdisaster_0.79.5-1~exp1.dsc

The changes I have made have also been pushed into the _experimental
branch of https://github.com/e7appew/pkg-dvdisaster.git.

Changes since the last upload:

  dvdisaster (0.79.5-1~exp1) experimental; urgency=medium

* Team upload.
* New upstream version [0.79.5].
* Update uscan rules.
* Drop debian/dvdisaster.menu file in favour of desktop file.
* Convert copyright file into proper DEP5 format and update.
* Fix installation of desktop file and icon images.
* Tidy up installation of doc files.
* Drop no longer required debian/pixmaps/dvdisaster.xpm.
* Add debian/dvdisaster-doc.doc-base file.
* Add link to html docs in dvdisaster-doc package.
* Fix clean up rules.
* Update docs to install.
* Separate binary-arch and binary-indep rules.
* Fix all compilations warnings we can fix and silence the ones we can't.
* Package upstream manual.pdf for the time being, since we can't
  build it reproducibly.
* debian/control:
  + Update to Standards Version 3.9.8.
  + Update VCS details.
  + Remove obsolete DM-Upload-Alllowed control field.
  + Perform wrap and sort.
  + Mark dvdisaster-doc as a multi-arch foreign package.
* debian/rules:
  + Build with all hardening flags set.
  + Link required libraries as needed.
  + Don't build with source path embedded as this makes unreproducible
builds.
* debian/patches/*:
  + Refresh patches.
  + Fix patch headers to work with git-buildpackage, retaining as
much meta info as possible.
  + Fix GNU Make detection.
  + Use non-size-specific icon and add keywords to desktop file.
  + Fix spelling: upto -> up to
  + Fix missing language fields in PO files.
  + Use the Debian changelog details to derive a build number and date,
so that we can make reproducible binaries.
  + Update help dialog to show GPL-3 license and new Debian package
tracker.
  + Fix generated man pages. The generated man pages incorrectly direct
users to the directory of the old HTML documentation, which is no
longer available.
  + Fix display of manual.pdf. The PDF file is automatically compressed
by Debhelper, so we need to account for this.
  + Update copyright notice in about dialog.
  + Allow ShowTextFile() to work with absolute path names.
  + Fix display of changelog, credits and to-do files.
  + Resurrect old code to support opening URLs in a browser.

   -- Carlos Maddela   Wed, 21 Dec 2016 14:30:02 +1100

Regards,
  Carlos Maddela

Bug#848966: enigmail needs "gnupg-agent --use-standard-socket"

[Harald Dunkel]

PS: Apparently its not the missing "--use-standard-socket", but
the way how or when 90gpg-agent starts gpg-agent. Adding this
option to 90gpg-agent didn't help; enigmail still cannot connect
to gpg-agent.

If I omit the whole XWindow session and run "startx" on the
console instead, then enigmail can connect to pinentry.

Regards
Harri

Bug#848971: ITP: rdma-core -- RDMA Core Userspace Libraries and Daemons

[Talat Batheesh]

Package: wnpp
Severity: wishlist
Owner: Talat Batheesh 

* Package name: rdma-core
  Version : v12
  Upstream Author : Doug Ledford , Leon Romanovsky 

* URL : https://github.com/linux-rdma/rdma-core
* License : GPLv2+ and BSD
  Programming Lang: Bourne Shell, Bash, C, python, perl
  Description : RDMA Core Userspace Libraries and Daemons

Overview

rdma-core handles userspace components for the Linux Kernel's 
drivers/infiniband subsystem.

This package re-organizing how to deliver the source code, Instead of > 20 
small repositories of packages that are already included in debian [1] we 
are combining them into a single source tree.

The main changes are that the providers are combined into a single package 
called 'ibverbs-providers', and upstream content that has never been packaged
for Debian is included.

The main advantages of maintaining a single package are 
* Eliminate code duplications 
* Scalable solution - new provider can easily be added (no need for new 
packaging process)
* Common RDMA support across different distros.
* Reduce complexity of the package dependency chain.

The userspace component of the libibverbs RDMA kernel drivers are included
under the providers/ directory. Support for the following Kernel RDMA drivers
is included:

 - iw_cxgb3.ko
 - iw_cxgb4.ko
 - hfi1.ko
 - hns-roce.ko
 - i40iw.ko
 - ib_qib.ko
 - mlx4_ib.ko
 - mlx5_ib.ko
 - ib_mthca.ko
 - iw_nes.ko
 - ocrdma.ko
 - qedr.ko
 - rdma_rxe.ko

Additional service daemons are provided for:
- srp_daemon (ib_srp.ko)
- iwpmd (for iwarp kernel providers)

You can read more on the subject in the discussion on the linux-rdma mailing 
list [2].

[1]

ibacm
libibcm
libibumad
libibverbs
librdmacm
libipathverbs
libnes
srptools
libcxgb3
libmlx4
libmlx5
libmthca

[2]

http://www.spinics.net/lists/linux-rdma/msg39026.html
http://www.spinics.net/lists/linux-rdma/msg39328.html
http://www.spinics.net/lists/linux-rdma/msg40014.html
http://www.spinics.net/lists/linux-rdma/msg40086.html

Bug#848970: ITP: node-jsonminify -- Minify blocks of JSON-like content into valid JSON

[Paolo Greppi]

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

* Package name: node-jsonminify
  Version : 0.4.1
  Upstream Author : Kei Funagayama 
(https://github.com/fkei)
* URL : https://github.com/fkei/JSON.minify
* License : Expat
  Programming Lang: JavaScript
  Description : Minify blocks of JSON-like content into valid JSON

 Node.js module to minify blocks of JSON-like content into
 valid JSON by removing all whitespace *and* comments.
 .
 Node.js is an event-based server-side JavaScript engine.

This is a requirement of etherpad-lite (https://bugs.debian.org/576998).

My intention is to package it within the javascript maintainers team.

The repo will be on alioth:
https://anonscm.debian.org/git/pkg-javascript/node-jsonminify.git

Paolo

Bug#848972: console-setup-linux: Datei /tmp/tmpkbd.BRzn8j kann nicht geöffnet werden

[Helge Kreutzmann]

Package: console-setup-linux
Version: 1.154
Severity: normal

For quite some time I get the above error message in my logs at every
reboot (translated it says: File /tmp/tmpkbd.BRzn8j cannot be opened).

It appears to be a partly stable random name.

A few days after installation (~ June) it was:
Jun 11 11:43:58 samd keyboard-setup.sh[185]: Datei /tmp/tmpkbd.8qI6qr kann 
nicht geöffnet werden.

Then it disappeared until Oct 29, when it became
Oct 29 11:50:52 samd keyboard-setup.sh[368]: Datei /tmp/tmpkbd.eRnip8 kann 
nicht geöffnet werden.

It remained this way until Nov. 19th, when it disappeared,
and it reappaered on Nov. 29th as
Nov 29 20:17:34 samd keyboard-setup.sh[308]: Datei /tmp/tmpkbd.BRzn8j kann 
nicht geöffnet werden.

Its been present on any system boot since then.

In /var/log/apt/history.*.log I see the following changes:
Oct. 28th:
console-setup-linux:amd64 (1.151, 1.152)
Nov. 19th: 
console-setup-linux:amd64 (1.152, 1.153)
Nov. 28th:
console-setup-linux:amd64 (1.153, 1.154)

So these (dis)appearance coincide with new versions of console-setup.

I haven't noticed anything strange with the keyboard, neither in X nor
on the (heavily used) text consoles.

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

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

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.46
ii  initscripts 2.88dsf-59.8
ii  kbd 2.0.3-2
ii  keyboard-configuration  1.154

console-setup-linux recommends no packages.

Versions of packages console-setup-linux suggests:
ii  console-setup  1.154

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.59
ii  liblocale-gettext-perl  1.07-3+b1

Versions of packages console-setup depends on:
ii  debconf 1.5.59
ii  keyboard-configuration  1.154
ii  xkb-data2.18-1

Versions of packages console-setup suggests:
ii  locales   2.24-8
ii  lsb-base  9.20161125

Versions of packages console-setup-linux is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.3-2
ii  systemd   232-7

-- debconf information:
  console-setup/codesetcode: Lat15
  keyboard-configuration/unsupported_config_options: true
* keyboard-configuration/other:
* keyboard-configuration/variantcode:
* keyboard-configuration/optionscode: terminate:ctrl_alt_bksp
  console-setup/framebuffer_only:
* keyboard-configuration/layoutcode: de
* keyboard-configuration/xkb-keymap: de
  console-setup/guess_font:
  keyboard-configuration/unsupported_config_layout: true
  keyboard-configuration/unsupported_layout: true
* keyboard-configuration/switch: No temporary switch
* console-setup/fontface47: Terminus
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/model: Generische PC-Tastatur mit 105 Tasten (Intl)
  debian-installer/console-setup-udeb/title:
* console-setup/charmap47: UTF-8
* keyboard-configuration/altgr: The default for the keyboard layout
* keyboard-configuration/modelcode: pc105
* keyboard-configuration/compose: No compose key
* keyboard-configuration/toggle: No toggling
  console-setup/fontsize-text47: 8x16
  keyboard-configuration/unsupported_options: true
* keyboard-configuration/ctrl_alt_bksp: true
* keyboard-configuration/variant: Deutsch
  console-setup/fontsize: 8x16
  console-setup/store_defaults_in_debconf_db: true
* console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
  console-setup/use_system_font:
* console-setup/fontsize-fb47: 8x16
* keyboard-configuration/layout:

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#848968: [Piuparts-devel] Bug#848968: piuparts.debian.org: should have a sid-merged-usr test

[Holger Levsen]

control: retitle 848968 piuparts.debian.org: should have a sid-merged-usr test 
once buster development has begun

On Wed, Dec 21, 2016 at 12:24:02PM +0100, Andreas Beckmann wrote:
> with debootstrap in stretch defaulting to --merged-usr, we need

this has been reverted and wont come back before buster…

> a) running debootstrap by default with --no-merged-usr in stretch+
> b) have another sid suite with a separate tarball and --merged-usr
>ignoring /bin and /lib symlinks

*then* this will become useful indeed :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#848973: ITP: openvas -- Metapackage for OpenVAS

[林上智]

Package: wnpp

Severity: wishlist

Owner: SZ Lin (林上智) 

X-Debbugs-CC: debian-de...@lists.debian.org,
pkg-security-t...@lists.alioth.debian.org


* Package name: openvas

  Version : 9.0.0

  Upstream Author : Greenbone Networks GmbH

* URL :  http://www.openvas.org/

* License : GPL-2+

  Programming Lang: C, Shell

  Description :  metapackage providing recommended packages for
openvas.


Maintainer of this package will be the pkg-security Team

--
Sun-Ze Lin  (林上智)

Bug#848961: nano: please update syntax highlighting for nftables

[Jordi Mallach]

Hey Benno! You're awesome. :D

El dc 21 de 12 de 2016 a les 12:29 +0100, en/na Benno Schulenberg va
escriure:
> Hello Arturo and Jordi,
> 
> On 2016-12-21 10:50, Arturo Borrero Gonzalez wrote:
> > On 21 December 2016 at 10:47, Jordi Mallach 
> > wrote:
> > > Can you submit this to nano-de...@gnu.org? I hope there'll be a
> > > release
> > > soonish and it can be included in stretch.
> > > 
> > > If you prefer, I can bring it up there for you, too.
> > 
> > I would prefer this path. Please go ahead :-)
> 
> No need to bring it to nano-devel -- I am subscribed to the Debian
> nano bugs.  :)  I will grab Arturo's file later today.  Is it okay
> if I add a Signed-off line to the commit message, Arturo?
> 
> Before when do you want a release, Jordi, in order to get it into
> Stretch still?

I'd say around the 22nd of January will be the last dates where normal
uploads will make it. On the 5th of Feb, the gates close for non-
serious bugfixes/security issues. Uploads now have a 10 day delay
before migration to stretch, so in principle the 25 would be ok still
*if* all buildds cooperate, if no issues arise with the new version,
etc., so that's why I'd give it a few more days just in case.

Benno, there's also #801103, which I've been wondering about.

Thanks to both!

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

Bug#848961: nano: please update syntax highlighting for nftables

[Benno Schulenberg]

Hello Arturo and Jordi,

On 2016-12-21 10:50, Arturo Borrero Gonzalez wrote:
> On 21 December 2016 at 10:47, Jordi Mallach  wrote:
>> Can you submit this to nano-de...@gnu.org? I hope there'll be a release
>> soonish and it can be included in stretch.
>>
>> If you prefer, I can bring it up there for you, too.
> 
> I would prefer this path. Please go ahead :-)

No need to bring it to nano-devel -- I am subscribed to the Debian
nano bugs.  :)  I will grab Arturo's file later today.  Is it okay
if I add a Signed-off line to the commit message, Arturo?

Before when do you want a release, Jordi, in order to get it into
Stretch still?

Regards,

Benno

Bug#848970: RFS: node-jsonminify 0.4.1

[Paolo Greppi]

Hi,

I have packaged node-jsonminify, see the ITP I am CC-ing and
the repo:
https://anonscm.debian.org/git/pkg-javascript/node-jsonminify.git

Please someone more experienced than me review it and if it's OK sponsor
its upload.

Thanks,

Paolo

Bug#848353: status update

[Paolo Greppi]

The repo on alioth is ready:
https://anonscm.debian.org/git/pkg-javascript/node-css-select.git

I'm waiting for the dependency node-domutils
(https://bugs.debian.org/848324) to enter unstable to emit the RFS.

Paolo

Bug#848961: nano: please update syntax highlighting for nftables

[Arturo Borrero Gonzalez]

On 21 December 2016 at 12:29, Benno Schulenberg  wrote:
>
> Hello Arturo and Jordi,
>
> On 2016-12-21 10:50, Arturo Borrero Gonzalez wrote:
>> On 21 December 2016 at 10:47, Jordi Mallach  wrote:
>>> Can you submit this to nano-de...@gnu.org? I hope there'll be a release
>>> soonish and it can be included in stretch.
>>>
>>> If you prefer, I can bring it up there for you, too.
>>
>> I would prefer this path. Please go ahead :-)
>
> No need to bring it to nano-devel -- I am subscribed to the Debian
> nano bugs.  :)  I will grab Arturo's file later today.  Is it okay
> if I add a Signed-off line to the commit message, Arturo?
>

Sure!

Signed-off-by: Arturo Borrero Gonzalez 

Bug#848974: ftp.debian.org: override: coz-profiler:devel/optional

[Lluís Vilanova]

Package: ftp.debian.org
Severity: normal

I mis-stated the section due to c&p in previous releases of the package (was set
to "net", which is incorrect for a program profiling tool).

Thanks!

Bug#848975: bash-completion: Fails to auto-complete /etc/hosts hostnames after ~/.ssh/config file created

[Miel Donkers]

Package: bash-completion
Version: 1:2.1-4.3
Severity: normal

Dear Maintainer,

Initially, auto-completion of hosts was working as expected, auto-completing 
hosts defined in /etc/hosts.
After adding a ~/.ssh/config file, auto-completion of hosts defined in 
/etc/hosts no longer works. When moving
the config file out of the way, auto-completion works normally again. 
Auto-completion of hosts defined in
~/.ssh/config _does_ work, but only those defined there.

As my /etc/hosts file is quite extensive, and I only need the ssh config file 
for one small setting, I don't
want to include all hosts in the ssh config file. I would expect to 
auto-complete hostnames from /etc/hosts 
even when a ~/.ssh/config file is present.

BR,
Miel

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

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

Versions of packages bash-completion depends on:
ii  bash  4.4-2
ii  dpkg  1.18.15

bash-completion recommends no packages.

bash-completion suggests no packages.

-- no debconf information

Bug#820825: [Pkg-fonts-devel] Bug#820825: fonts-freefont-ttf: Monospaced face doesn't set correct PANOSE value

[Fabian Greffrath]

Hi Shaun,

Shaun Walbridge wrote:
> Currently, the monospaced variant of the font (FreeMono.ttf) doesn't
> correctly set the PANOSE proportion value (bProportion) for the font.
> The version directly provided by the FreeFont project contains the
> correct PANOSE proportion value.

does this problem still persist with the fonts-freefont packages currently
in testing and unstable? I am asking because they were built with a much
newer fontforge version.

Thanks,

 - Fabian

Bug#843063: systemd: does not show failed nfs mount when nfs server not available on booting the client

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

On Thu, 03 Nov 2016 16:31:21 +0100 Martin Steigerwald 
 wrote:
> root@webserver01:~# systemctl status srv-web.mount
> ● srv-web.mount - /srv/web
>Loaded: loaded (/etc/fstab)
>Active: active (mounted) (Result: timeout) since Do 2016-11-03 16:03:09 
> CET; 21min ago
> Where: /srv/web
>  What: fileserver:web
>  Docs: man:fstab(5)
>man:systemd-fstab-generator(8)
> 
> Nov 03 16:01:39 webserver01 systemd[1]: Mounting /srv/web...
> Nov 03 16:03:09 webserver01 systemd[1]: srv-web.mount mounting timed out. 
> Stopping.
> Nov 03 16:03:09 webserver01 systemd[1]: Mounted /srv/web.
> 
> In my oppinion the third line in the log is crap. Systemd didn´t mount


It seems I can't reproduce the problem.
I've tried with a jessie VM with 215-17+deb8u5 and added to fstab

10.20.30.40:/srv/nfs /mnt nfs _netdev 0 0

(that IP doesn't exist).

on boot, systemd waits for the mount and eventually times out.
After that, the system is in degraded state and the output is

● mnt.mount - /mnt
   Loaded: loaded (/etc/fstab)
   Active: failed (Result: timeout) since Mi 2016-12-21 12:51:59 CET; 57s ago
Where: /mnt
 What: 10.20.30.40:/srv/nfs
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)
  Process: 329 ExecMount=/bin/mount -n 10.20.30.40:/srv/nfs /mnt -t nfs -o 
_netdev (code=killed, signal=TERM)

Dez 21 12:51:56 debian systemd[1]: mnt.mount mounting timed out. Stopping.
Dez 21 12:51:56 debian systemd[1]: Mounted /mnt.
Dez 21 12:51:59 debian systemd[1]: Unit mnt.mount entered failed state.


I have no idea, why here it shows
 Active: failed (Result: timeout)
and for you (with afaics basically the same setup) it shows
 Active: active (mounted) (Result: timeout)


The upstream commit in [1] doesn't look like it's a trivial cherry-pick either,
and I'm worried it has regression potential changing core logic.


Michael

[1] https://github.com/systemd/systemd/issues/4275
-- 
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#845304: west-chamber just needs rebuild

[Arturo Borrero Gonzalez]

Hi,

by the time of this email, west-chamber is the only package left for
this transition.

I just tested in my machine, and the package builds fine in unstable
with the new libxtables12.

Bug#848869: Error: could not create default cluster. Please create it manually with

[Darshaka Pathirana]

On 2016-12-21 11:38, Christoph Berg wrote:
> Control: tags -1 moreinfo
> 
> Re: Darshaka Pathirana 2016-12-20 
> <20161220110151.19348.48480.reportbug@invincible>
>>   Error: The locale requested by the environment is invalid.
> 
>> Locale looks like this:
>>
>>   % locale
>>   LANG=en_US.UTF-8
>>   LANGUAGE=en_US:en
>
> on package installation (only), the locale used for pg_createcluster
> (= initdb) is not determined by your environment (which "locale" looks
> at), but by the system configuration in /etc/environment and
> /etc/default/locale.
> 
> Could you check what you have configured in these files?

Hmm. The files look like this:

  % cat /etc/environment
  % cat /etc/default/locale
  #  File generated by update-locale
  LANG=en_US.UTF-8
  LANGUAGE=en_US:en

Regards,
 - Darsha



signature.asc
Description: OpenPGP digital signature

Bug#818961: [Debian-ha-maintainers] Freeze status, Heartbeat plans

[Patrick Matthäi]

Am 21.12.2016 um 11:50 schrieb Christoph Berg:
> Re: Valentin Vidic 2016-12-20 
> <20161220134034.grvwdktsmtbij...@gavran.carpriv.carnet.hr>
>> And if there are big issues with systemd support I think there would be
>> more bug reports for the jessie version of this package already?
> It might be that with the previously poor state of HA in Jessie, users
> aren't really reporting issues of that kind anymore :(
>
> I guess the basic question is if we want to continue to ship&support
> heartbeat, or if that ship has sailed and we simply drop it.
>
> There are still users of the "simple" v1 mode. I'd assume they know
> that for anything more complex they should switch to
> corosync+pacemaker, so the question would be how much of the v1 mode
> is still working. If the "average" case is broken on systemd systems,
> we should fix or remove heartbeat. If the average case still works, we
> can continue to ship it.
>
> Patrick, what's your position here?
>
> The drbd/fs/ip/apache example shown in the serverfault question looks
> simple enough. Maybe someone could try a test setup?
>
> Christoph

We tried out many test cases, workarounds, debugging on this issue and
the result was, that the v1 mode of heartbeat can not deal with the
dependency system of systemd and will never support it.

Unfortunately I also do not have the logs from IRC anymore and no time
until the next freeze step to provide this setup again :/

I still think, this is the best solution (since only v1 mode is affected):
"IMO the package should warn (debconf dialog prio high?) the user if he
upgrades heartbeat and systemd+v1 config is in use."

Removing the whole heartbeat package would not be a good solution, since
it is still required?

-- 
/*
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
*/

Bug#701674: apf-firewall doesn't work with kernel-version >= 3.0

[Christoph Biedl]

Hello everybody,

Edi Meier wrote...

> kernel-version >= 3.0 is not supported:
> cf. apf-9.7-1/files/internals/functions.apf
> 
> if [ "$KREL" == "2.4" ]; then
> MEXT="o"
> elif [ "$KREL" == "2.6" ]; then
> MEXT="ko"
> elif [ ! "$KREL" == "2.4" ] && [ ! "$KREL" == "2.6" ]; then
> if [ ! "$SET_VERBOSE" == "1" ]; then
> echo "Kernel version not equal to 2.4.x or 2.6.x, aborting."
> fi
> eout "{glob} kernel version not equal to 2.4.x or 2.6.x, aborting."
> exit 1
> else
> if [ ! "$SET_VERBOSE" == "1" ]; then
> echo "Kernel version not equal to 2.4.x or 2.6.x, aborting."
> fi
> eout "{glob} kernel version not equal to 2.4.x or 2.6.x, aborting."
> exit 1
> fi

Since apf-firewall will not be a part of stretch unless this gets fixed:
Can you please test on a sid or a least stretch installation whether
using a modified functions.apf makes apf-firewall working again?

(...)
if [ "$KREL" == "2.4" ]; then
MEXT="o"
elif [ "$KREL" == "2.6" ]; then
MEXT="ko"
elif [[ "$KREL" =~ "3." ]]; then
MEXT="ko"
elif [[ "$KREL" =~ "4." ]]; then
MEXT="ko"
elif [ ! "$KREL" == "2.4" ] && [ ! "$KREL" == "2.6" ] && [[ ! "$KREL" =~ "3." 
]] && [[ ! "$KREL" =~ "4." ]]; then
if [ ! "$SET_VERBOSE" == "1" ]; then
(...)

Then I can take care of the rest. However, given the stretch release
schedule this requires very swift action from your side, please respond
by Dec 23rd the latest.

Christoph


signature.asc
Description: Digital signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Holger

On 20.12.2016 15:27, Holger Levsen wrote:
> On Tue, Dec 20, 2016 at 03:16:50PM +0100, Ole Streicher wrote:
>> Again: the installer is there to test for 6 months now, but if it is
>> inacceptably bad: why are there no complaints?
> 
> the complaints have been there for months, you just choose to consider
> them invalid. some people dont like to repeat themselves.

After six months of testing, I would expect that the fears that were
expressed at that times were supported by some real solid experiences.
This is a big difference and in no way a repetition.

Ole

Bug#818961: [Debian-ha-maintainers] Freeze status, Heartbeat plans

[Valentin Vidic]

On Wed, Dec 21, 2016 at 01:15:12PM +0100, Patrick Matthäi wrote:
> We tried out many test cases, workarounds, debugging on this issue and
> the result was, that the v1 mode of heartbeat can not deal with the
> dependency system of systemd and will never support it.

Not sure what could be the problem with systemd dependencies.
Do you remember which services were involved so we can do a
quick test?

-- 
Valentin

Bug#793749: ITP: telegraf -- plugin-driven server agent for reporting metrics into InfluxDB

[Guillem Jover]

Hey!

On Mon, 2016-10-17 at 23:47:23 +0200, Guillem Jover wrote:
> On Sun, 2015-07-26 at 23:32:17 -0400, Alexandre Viau wrote:
> > Package: wnpp
> > Severity: wishlist
> 
> > * Package name: telegraf
> >   Upstream Author : InfluxDB inc.
> > * URL : https://github.com/influxdb/telegraf
> > * License : Expat
> >   Programming Lang: Go

> Ok, all necessary parts have either bugs filed against existing packages
> in Debian, or RFP filed with packaging patches. And are blocking this
> bug.

I've now updated against the upstream 1.1.2, plus some packaging
cleanups and fixes. Filed additional RFPs needed (marked also as
blocking) or got required dependencies in Debian updated.

> Attached is a working and tested packaging delta against
> . The
> missing part is updating that repo to version 1.0.1, which is the
> latest upstream release, and what I've been working against. Please
> let me know if something smells fishy.

Same situation but against 1.1.2.

Thanks,
Guillem
From 2708ecc851abe62e482c98115a20e8d370a8 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 17 Oct 2016 23:32:53 +0200
Subject: [PATCH] Update packaging to 1.1.2

---
 debian/.gitignore  |7 +
 debian/changelog   |   37 +-
 debian/control |  102 +-
 debian/copyright   |   11 +-
 .../excise-unavailable-plugins-in-debian.patch |   98 ++
 debian/patches/series  |3 +
 debian/patches/testsuite-no-network.patch  |   23 +
 debian/patches/use-licenseful-module.patch |   26 +
 debian/rules   |   39 +-
 debian/telegraf-dev.install|1 +
 debian/telegraf.conf   | 1456 
 debian/telegraf.dirs   |3 +
 debian/telegraf.init   |  121 ++
 debian/telegraf.install|2 +
 debian/telegraf.lintian-overrides  |3 +
 debian/telegraf.logrotate  |   10 +
 debian/telegraf.postinst   |   42 +
 debian/telegraf.postrm |   28 +
 18 files changed, 1979 insertions(+), 33 deletions(-)
 create mode 100644 debian/.gitignore
 create mode 100644 debian/patches/excise-unavailable-plugins-in-debian.patch
 create mode 100644 debian/patches/series
 create mode 100644 debian/patches/testsuite-no-network.patch
 create mode 100644 debian/patches/use-licenseful-module.patch
 create mode 100644 debian/telegraf-dev.install
 create mode 100644 debian/telegraf.conf
 create mode 100644 debian/telegraf.dirs
 create mode 100755 debian/telegraf.init
 create mode 100644 debian/telegraf.install
 create mode 100644 debian/telegraf.lintian-overrides
 create mode 100644 debian/telegraf.logrotate
 create mode 100644 debian/telegraf.postinst
 create mode 100644 debian/telegraf.postrm

diff --git a/debian/.gitignore b/debian/.gitignore
new file mode 100644
index ..30f7739e
--- /dev/null
+++ b/debian/.gitignore
@@ -0,0 +1,7 @@
+*.debhelper
+*.substvars
+*.log
+files
+tmp
+telegraf
+telegraf-dev
diff --git a/debian/changelog b/debian/changelog
index 24cf6077..92acea85 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,38 @@
-telegraf (0.1.8~dfsg1-1) UNRELEASED; urgency=low
+telegraf (1.1.2-0.1) UNRELEASED; urgency=low
 
-  * Initial release. (Closes: #XX)
+  [ Alexandre Viau ]
+  * Initial release. (Closes: #793749)
+
+  [ Guillem Jover ]
+  * New upstream release 1.1.2.
+- Update Build-Depends and telegraf-dev Depends.
+  * Fix SNMP plugin to build and pass the test suite.
+  * Fix test suite to avoid a flaky test.
+  * Run test suite in short mode, to skip tests that require running services.
+  * Use the github.com/kballard/go-shellquote module instead of
+github.com/gonuts/go-shellquote, which has no license as is not in Debian.
+  * Use dpkg Makefile fragments to get the upstream version, and set
+main.version with it.
+  * Use current import path, and switch from DH_GOPKG to XS-Go-Import-Path.
+  * Wrap and sort (-ast) debian/control fields.
+  * Add a Built-Using field to the telegraf binary.
+  * Change the Architecture field for telegraf from all to any.
+  * Set the builddirectory to build.
+  * Set DH_GOLANG_INSTALL_EXTRA to the list of required testdata files.
+  * Set DH_GOLANG_EXCLUDES to the plugins that pull dependencies not present
+in Debian, and that are peripheral. And disable those plugins from the
+code with a patch. They can be re-enabled once the dependencies get
+packaged in Debian.
+  * Use https in the debian/copyright Format field.
+  * Install a default telegraf configuration file.
+  * Install a logrotate file for telegraf.
+  * Create postinst and prerm maintaner

Bug#847567: [Pkg-fonts-devel] Bug#847567: ttf-dejavu: Probably removal needed

[Cyril Brulebois]

Fabian Greffrath  (2016-12-21):
> Cyril Brulebois wrote:
> > It would be great to check with debian-boot@ before handling such RM
> > requests (removal of udeb-producing packages). We would have had a
> > chance to switch to the “new” package.
> 
> Oh, I am sorry for this. I hope the actual switch is as easy as I
> imagine (s/ttf/fonts/)?

To make d-i build again, it looks that way, yeah. Need to double check
there are no regressions with the resulting images though.


KiBi.


signature.asc
Description: Digital signature

Bug#780028: init: aptitude upgrade from wheezy to jessie does not install systemd-sysv

[Felipe Sateler]

On 20 December 2016 at 23:13, Paul Wise  wrote:
> Control: reopen -1
>
> On Tue, 2016-12-20 at 19:55 -0300, Felipe Sateler wrote:
>
>> Unfortunately, I think the ship to fix this has sailed, as jessie was
>> released a while ago already. I'm therefore closing this bug.
>
> There is still the possibility of fixing this in a jessie point release
> so I think it should remain open unless you aren't going to bother. If
> that is the case then the bug should be marked as wontfix and closed.

Did anyone else besides Michael verify if the proposed solution (add
systemd-sysv to recommends) works and doesn't bring undesired
effects? From my POV, this is a high risk change with fairly little
payoff[1].

[1] 
https://qa.debian.org/popcon-graph.php?packages=systemd-sysv%2Csysvinit-core%2Csysvinit&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
This shows a fairly constant path for sysvinit-core, and that
systemd-sysv | sysvinit-core is already installed for about 75-80% of
the the peak sysvinit installation usage. That means the transition is
mostly done.

-- 

Saludos,
Felipe Sateler

Bug#843761: invoke-rc.d: Kill 600 birds with one stone (a.k.a. automatic policy-rc.d for init-less chroots)

[Felipe Sateler]

Control: tags -1 pending

On 20 December 2016 at 21:52, Michael Biebl  wrote:
> Am 21.12.2016 um 01:29 schrieb Felipe Sateler:
>
>> Michael, from the discussion on IRC I did not end up entirely clear if
>> you are OK with this change or not. Could you please comment, if we
>> can apply this patch?
>>
>
> I'm ok with this change. My reservation on IRC was mainly about this not
> directly solving the lsb-base issue.
> But the patch on itself is fine.

Thanks, applied.


-- 

Saludos,
Felipe Sateler

Bug#848597: debian-installer: iPXE script in DHCP bootfile option is interpreted as preseed filename

[Pali Rohár]

On Wednesday 21 December 2016 10:16:24 Philip Hands wrote:
> Pali Rohár  writes:
> > Package: debian-installer
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > when DHCP server is configured to send bootfile option with iPXE
> > script
> > 
> > then debian-installer fails with following "red" error:
> >   [!!] Download debconf preconfiguration file
> >   
> >   Failed to process the preconfiguration file
> >   
> >   The installer failed to process the preconfiguration file from
> >   . The file may be corrupt.
> > 
> > (where  is value of that DHCP option)
> > 
> > It looks like debian-installer expects that DHCP bootfile option
> > will contains correct preseed file. And if that DHCP option
> > contains not Debian preseed file, then it show above "red" error
> > message.
> 
> Is it the case that iPXE config files are the only things we need to
> worry about here?  (seems probable given the lack of previous
> reports)

I do not know. Maybe there are other applications which uses DHCP 
bootfile option for own setup...

> If so, we could just check for '#!ipxe' and if found downgrade the
> error to a warning, or perhaps to log what happened but otherwise
> ignore it.

As DHCP bootfile can be served for any application, I think that Debian 
Installer should check that file is for him, not that file is for PXE...

With your way, to just check for '#!ipxe' can be broken again in future 
once there will be another application which will use bootfile option. 
And it could be any fork of ipxe with new name... as it was before with 
gpxe...

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#848907: frequent crashes of Xorg

[Andrei Mikhailov]

Sorry I made a misprint. That was Stretch, not Squeeze. Debian Testing/Stretch.

On Tue, 20 Dec 2016 15:38:42 -0200 Andrei Mikhailov  wrote:
> Package: base
> 
> Frequent crashes of Xorg , usually when switching windows but sometimes
> spontaneously.
> 
> Debian testing (squeeze) with systemd, Linux 4.8.0-2-amd64 x86_64
> VGA compatible controller AMD/ATI Radeon HD4250
> using packages:  xserver-xorg-video-radeon firmware-amd-graphics
> 
> Crashes started after the following update:
> 
> 2016-12-19 09:57:13 upgrade xserver-xorg-input-evdev:amd64 1:2.10.4-1
> 1:2.10.4-1+b1
> 2016-12-19 09:57:16 upgrade xserver-xorg-video-ati:amd64 1:7.8.0-1
> 1:7.8.0-1+b1
> 2016-12-19 09:57:20 upgrade xserver-xorg-video-mach64:amd64 6.9.5-1+b1
> 6.9.5-1+b2
> 2016-12-19 09:57:23 upgrade xserver-xorg-video-tdfx:amd64 1:1.4.6-2
> 1:1.4.6-2+b1
> 2016-12-19 09:57:26 upgrade xserver-xorg-video-cirrus:amd64 1:1.5.3-1+b1
> 1:1.5.3-1+b2
> 2016-12-19 09:57:29 upgrade xserver-xorg-video-amdgpu:amd64 1.2.0-1
> 1.2.0-1+b1
> 2016-12-19 09:57:33 upgrade xserver-xorg-video-vesa:amd64 1:2.3.4-1+b1
> 1:2.3.4-1+b2
> 2016-12-19 09:57:36 upgrade xserver-xorg-video-radeon:amd64 1:7.8.0-1
> 1:7.8.0-1+b1
> 2016-12-19 09:57:40 upgrade xserver-xorg-video-trident:amd64 1:1.3.7-2
> 1:1.3.7-2+b1
> 2016-12-19 09:57:45 upgrade xserver-xorg-video-vmware:amd64 1:13.2.1-1
> 1:13.2.1-1+b1
> 2016-12-19 09:57:49 upgrade xserver-xorg-video-neomagic:amd64 1:1.2.9-1
> +b1 1:1.2.9-1+b2
> 2016-12-19 09:57:53 upgrade xserver-xorg-video-openchrome:amd64 1:0.3.3
> +git20160310-1 1:0.3.3+git20160310-1+b1
> 2016-12-19 09:57:58 upgrade xserver-xorg-video-mga:amd64 1:1.6.4-2
> 1:1.6.4-2+b1
> 2016-12-19 09:58:03 upgrade xserver-xorg-video-savage:amd64 1:2.3.8-2
> 1:2.3.8-2+b1
> 2016-12-19 09:58:08 upgrade xserver-xorg-video-fbdev:amd64 1:0.4.4-1+b4
> 1:0.4.4-1+b5
> 2016-12-19 09:58:12 upgrade xserver-xorg-video-nouveau:amd64 1:1.0.13-1
> 1:1.0.13-1+b1
> 2016-12-19 09:58:17 upgrade xserver-xorg-video-qxl:amd64 0.1.4-3+b1
> 0.1.4+20161126git4d7160c-1
> 2016-12-19 09:58:21 upgrade xserver-xorg-video-r128:amd64 6.10.1-2
> 6.10.1-2+b1
> 2016-12-19 09:58:26 upgrade xserver-xorg-video-intel:amd64 2:2.99.917
> +git20161105-1 2:2.99.917+git20161105-1+b1
> 2016-12-19 09:58:34 upgrade xserver-xorg-input-mouse:amd64 1:1.9.2-1
> 1:1.9.2-1+b1
> 2016-12-19 09:58:39 upgrade xserver-xorg-input-synaptics:amd64 1.9.0-1
> 1.9.0-1+b1
> 2016-12-19 09:58:45 upgrade xserver-xorg-input-wacom:amd64 0.33.0-1
> 0.33.0-1+b1
> 2016-12-19 09:58:51 upgrade xserver-xorg-input-libinput:amd64 0.22.0-1
> 0.22.0-1+b1
> 2016-12-19 09:58:58 upgrade xserver-xorg-core:amd64 2:1.18.4-2
> 2:1.19.0-2
> 2016-12-19 10:00:39 upgrade xserver-common:all 2:1.18.4-2 2:1.19.0-2

Bug#848597: debian-installer: iPXE script in DHCP bootfile option is interpreted as preseed filename

[Pali Rohár]

On Wednesday 21 December 2016 10:36:30 Philip Hands wrote:
> Philip Hands  writes:
> > Pali Rohár  writes:
> >> Package: debian-installer
> >> Severity: normal
> >> 
> >> Dear Maintainer,
> >> 
> >> when DHCP server is configured to send bootfile option with iPXE
> >> script
> >> 
> >> then debian-installer fails with following "red" error:
> >>   [!!] Download debconf preconfiguration file
> >>   
> >>   Failed to process the preconfiguration file
> >>   
> >>   The installer failed to process the preconfiguration file from
> >>   . The file may be corrupt.
> >> 
> >> (where  is value of that DHCP option)
> >> 
> >> It looks like debian-installer expects that DHCP bootfile option
> >> will contains correct preseed file. And if that DHCP option
> >> contains not Debian preseed file, then it show above "red" error
> >> message.
> > 
> > Is it the case that iPXE config files are the only things we need
> > to worry about here?  (seems probable given the lack of previous
> > reports)
> > 
> > If so, we could just check for '#!ipxe' and if found downgrade the
> > error to a warning, or perhaps to log what happened but otherwise
> > ignore it.
> 
> It occurs to me that we could fix this by adding a feature.
> 
> If we had something that looked out for some string, and would
> interpret it as an instruction to immediately chain into a new file,
> ignoring the rest of the current file, then one could specify the
> preseed to use in the iPXE config, by adding something like this
> near the start:
> 
>   # DEBCONF_CHAIN_LOAD(preseed.cfg)
> 
> If we were looking for /DEBCONF_CHAIN_LOAD([^(]*)/ then it would
> probably work in anything that has a way of specifying comments,
> since it could as easily find it after '// ', '