Bug#798476: Returning to the requirement that Uploaders: contain humans

[Tobias Frost]

Am Donnerstag, den 03.08.2017, 23:09 + schrieb Clint Adams:
> On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > What I don't understand in the point of view of the "keep
> > Uploaders"
> > proponents: What does this information, whether correct or not,
> > actually give others? Are they going to email or phone these
> > persons
> > privately when emails to the BTS or the maintainer/team list are
> > ignored? And what happens if they ignore these communications as
> > well?
> 
> I agree.  This information is useless, and even if it's not, the
> source
> package is entirely the wrong place for it.  Let's get rid of the
> Uploaders field entirely.

please note that than also the DDPO will stop working. This is our
major information source to determine if someone is MIA -- before
sending the fist mail.
With only teams in the Maintainer field and no other source of
information to get that information easily, the MIA team will go
defunct or it will make the work by magnitues harder.

And as the fallacy is keeping showing up repeatily in other answers:
The perl team is extraoridnary. They are very well organized and there
it works. But the mayority of teams is not the perl team.

Have to go for $DAYJOB now.

--
tobi

Bug#870230: fixed in libpng1.6 1.6.31-1~exp1

[Tobias Frost]

Control: notfixed -1 libpng1.6/1.6.31-1~exp1

Sorry for the noise. The changelog entry in libpng was wrong. Removing
the indication that the bug has been fixed in libpng (it was a issue in
debhelper but already fixed)

-- 
tobi

Bug#870664: hkl: build-depends on obsolete emacs24

[PICCA Frederic-Emmanuel]

Hello,

I need to work on the hkl library next week for my work.
I must backport this for jessie-backport. I think that I will use emacs instead 
of emacs25/emacs24

Cheers

Fred

Bug#870688: sagemath: new upstream release 8.0

[Andreas Beckmann]

Package: sagemath
Version: 7.6-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

sagemath depends on python-cysignals-pari, but the new
python-cysignals-pari in sid has
  Breaks: sagemath (<< 8.0~)


Cheers,

Andreas

Bug#865740: wxMaxima is caused segmentaion fault by ctrl+k

[Gunter Königsmann]

Thanks for this bug report!

I seem to be unable to reproduce this bug on my own system. Which makes
it nearly impossible to find it. Which means I need your help:

 - install wxmaxima-dbg (this package contains the info which line
number is to be found at which address)
 - type into a terminal

  gdb wxmaxima

 - make the program crash
 - and type into the terminal

  backtrace

With a little bit of luck gdb will now print out the line number the
program crashed at - and what lead to this. ...which most of the times
makes fixing the bugs trivial.

Thanks in advance,
and Kind regards,

 Gunter.

Bug#870687: ITP: rss-bridge -- generate ATOM feeds for websites that don't have them

[Johannes Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer 

* Package name: rss-bridge
  Version : 2017-08-03
  Upstream Author : sebsauvage 
Mitsukarenai 
Pierre Mazière 
logmanoriginal 
* URL : https://github.com/RSS-Bridge/rss-bridge
* License : public domain
  Programming Lang: PHP
  Description : generate ATOM feeds for websites that don't have them

Generates ATOM feeds for facebook, twitter, youtube, flickr, google,
instagram, pinterest and more than 130 other web services which do not
provide ATOM or RSS feeds themselves. The software acts as a proxy
between the web service and an RSS reader software. It scrapes the
provided HTML to extract the necessary information. To prevent banning,
the results are cached.

Bug#870467: varnish: diff for NMU version 5.0.0-7.1

[Salvatore Bonaccorso]

Control: tags 870467 + pending

Dear maintainer,

I've prepared an NMU for varnish (versioned as 5.0.0-7.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru varnish-5.0.0/debian/changelog varnish-5.0.0/debian/changelog
--- varnish-5.0.0/debian/changelog	2017-03-02 18:16:05.0 +0100
+++ varnish-5.0.0/debian/changelog	2017-08-04 06:43:38.0 +0200
@@ -1,3 +1,13 @@
+varnish (5.0.0-7.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Correctly handle bogusly large chunk sizes.
+This fixes a denial of service attack vector where bogusly large chunk
+sizes in requests could be used to force restarts of the Varnish server.
+(Closes: #870467)
+
+ -- Salvatore Bonaccorso   Fri, 04 Aug 2017 06:43:38 +0200
+
 varnish (5.0.0-7) unstable; urgency=medium
 
   * Remove reload from varnish.service (Closes: #749272)
diff -Nru varnish-5.0.0/debian/patches/5.0-Correctly-handle-bogusly-large-chunk-sizes.patch varnish-5.0.0/debian/patches/5.0-Correctly-handle-bogusly-large-chunk-sizes.patch
--- varnish-5.0.0/debian/patches/5.0-Correctly-handle-bogusly-large-chunk-sizes.patch	1970-01-01 01:00:00.0 +0100
+++ varnish-5.0.0/debian/patches/5.0-Correctly-handle-bogusly-large-chunk-sizes.patch	2017-08-04 06:43:38.0 +0200
@@ -0,0 +1,109 @@
+From e32377f0455ddf7a7836cc0d21d78906e9938119 Mon Sep 17 00:00:00 2001
+From: Martin Blix Grydeland 
+Date: Thu, 27 Jul 2017 11:52:58 +0200
+Subject: [PATCH] Correctly handle bogusly large chunk sizes
+
+This fixes a denial of service attack vector where bogusly large chunk
+sizes in requests could be used to force restarts of the Varnish
+server.
+
+This is Varnish Security Vulnerability VSV1
+
+For more information visit: https://varnish-cache.org/security/VSV1
+
+Fixes: #2379
+---
+ bin/varnishd/http1/cache_http1_vfp.c |  2 +-
+ bin/varnishtest/tests/f1.vtc | 67 
+ 2 files changed, 68 insertions(+), 1 deletion(-)
+ create mode 100644 bin/varnishtest/tests/f1.vtc
+
+diff --git a/bin/varnishd/http1/cache_http1_vfp.c b/bin/varnishd/http1/cache_http1_vfp.c
+index b836cd3..ded1550 100644
+--- a/bin/varnishd/http1/cache_http1_vfp.c
 b/bin/varnishd/http1/cache_http1_vfp.c
+@@ -155,7 +155,7 @@ v1f_pull_chunked(struct vfp_ctx *vc, struct vfp_entry *vfe, void *ptr,
+ 		if (q == NULL || *q != '\0')
+ 			return (VFP_Error(vc, "chunked header number syntax"));
+ 		cl = (ssize_t)cll;
+-		if((uintmax_t)cl != cll)
++		if (cl < 0 || (uintmax_t)cl != cll)
+ 			return (VFP_Error(vc, "bogusly large chunk size"));
+ 
+ 		vfe->priv2 = cl;
+diff --git a/bin/varnishtest/tests/f1.vtc b/bin/varnishtest/tests/f1.vtc
+new file mode 100644
+index 000..46dbe94
+--- /dev/null
 b/bin/varnishtest/tests/f1.vtc
+@@ -0,0 +1,67 @@
++varnishtest "Check that we handle bogusly large chunks correctly"
++
++# Check that the bug has been fixed
++
++server s1 {
++	rxreq
++	txresp
++
++	accept
++	rxreq
++	txresp
++} -start
++
++varnish v1 -vcl+backend {
++} -start
++
++client c1 {
++	send "POST / HTTP/1.1\r\n"
++	send "Transfer-Encoding: chunked\r\n\r\n"
++	send "FFED\r\n"
++	send "0\r\n\r\n"
++
++	rxresp
++	expect resp.status == 503
++} -run
++
++# Check that the published workaround does not cause harm
++
++varnish v1 -cliok "param.set vcc_allow_inline_c true"
++
++varnish v1 -vcl+backend {
++sub exploit_workaround {
++# This needs to be defined before your vcl_recv function
++# Make sure that the runtime parameter vcc_allow_inline_c is set to true
++if (req.http.transfer-encoding ~ "(?i)chunked") {
++C{
++struct dummy_req {
++unsignedmagic;
++int step;
++int req_body_status;
++};
++((struct dummy_req *)ctx->req)->req_body_status = 5;
++}C
++
++return (synth(503, "Bad request"));
++}
++}
++
++sub vcl_recv {
++# Call this early in your vcl_recv function
++call exploit_workaround;
++}
++}
++
++client c1 {
++	send "POST / HTTP/1.1\r\n"
++	send "Transfer-Encoding: chunked\r\n\r\n"
++	send "FFED\r\n0\r\n\r\n"
++
++	expect_close
++} -run
++
++client c1 {
++	txreq
++	rxresp
++	expect resp.status == 200
++} -run
+-- 
+2.1.4
+
diff -Nru varnish-5.0.0/debian/patches/series varnish-5.0.0/debian/patches/series
--- varnish-5.0.0/debian/patches/series	2017-03-02 18:16:05.0 +0100
+++ varnish-5.0.0/debian/patches/series	2017-08-04 06:43:38.0 +0200
@@ -1 +1,2 @@
 0001-Ensure-package-builds-reproducibly.patch
+5.0-Correctly-handle-bogusly-large-chunk-sizes.patch

Bug#575644: marked as done (pptp-linux mtu & mru bug)

[James Cameron]

Thanks Christoph.

Ivan's workaround of --clamp-mss-to-pmtu was valid for a path MTU
discovery failure where intermediate hosts refuse to forward ICMP
fragmentation needed responses.

http://pptpclient.sourceforge.net/howto-diagnosis.phtml#connections_freeze

In that scenario, changing network interface MTU using the mru and mtu
pppd options is effective for the interface, but doesn't solve the
problem, because the cause is somewhere else in the network, not on
the host running Debian.

Perhaps Ivan thought it could be a feature of pptp, but with Network
Manager taking over these corner cases we're unlikely to take the idea
upstream in pptp.

-- 
James Cameron
http://quozl.netrek.org/

Bug#870686: libglvnd: not ready for testing, yet

[Andreas Beckmann]

Source: libglvnd
Version: 0.2.999+git20170802-2
Severity: serious

Since the mesa packaging hasn't switched to glvnd, yet, there are file
conflicts between several packages from src:mesa and src:libglvnd.
So let's keep libglvnd out of testing until this transition progresses.


Andreas

Bug#870685: libhtml5parser-java, libhtmlparser-java: error when trying to install together

[Andreas Beckmann]

Package: libhtml5parser-java,libhtmlparser-java
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 1.4+r1.3.1-2
Control: found -1 1.6.20060610.dfsg0-6

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Selecting previously unselected package libhtmlparser-java.
  Preparing to unpack .../libhtmlparser-java_1.6.20060610.dfsg0-6_all.deb ...
  Unpacking libhtmlparser-java (1.6.20060610.dfsg0-6) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libhtmlparser-java_1.6.20060610.dfsg0-6_all.deb 
(--unpack):
   trying to overwrite '/usr/share/java/htmlparser.jar', which is also in 
package libhtml5parser-java 1.4+r1.3.1-2
  Errors were encountered while processing:
   /var/cache/apt/archives/libhtmlparser-java_1.6.20060610.dfsg0-6_all.deb

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  usr/share/java/htmlparser.jar

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may
also register in the BTS that the other package is affected by the bug.

Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html


libhtml5parser-java=1.4+r1.3.1-2_libhtmlparser-java=1.6.20060610.dfsg0-6.log.gz
Description: application/gzip

Bug#870565: percona-toolkit: pt-heartbeat cannot be started / compilation failed error

[Dario Minnucci]

severity 870565 normal
tags 870565 = moreinfo unreproducible
thanks


Hi Andreas,

On Wed, 02 Aug 2017 23:20:02 +0200 Andreas Leathley  wrote:
> Package: percona-toolkit
> Version: 2.2.20-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> When trying to use percona-toolkit, specifically pt-heartbeat, on
> stretch, it does not work anymore. The following worked with jessie:
> 
> pt-heartbeat --database statistics --check --host localhost --port 8573
> --user ptheartbeat --password supersecret --utc --charset utf8
> --master-server-id 99
> 


I'm unable to reproduce this issue on a fresh stretch environment.

# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 9.1 (stretch)
Release:9.1
Codename:   stretch

# pt-heartbeat --version
pt-heartbeat 2.2.20

# pt-heartbeat --database ptheartbeat --check --host localhost --port 8573 
--user USER --password
PASS --utc --charset utf8 --master-server-id 22
107.00


Please, send some more info in order to track this issue.

Thanks for your report.

-- 
 Dario Minnucci 
 Phone: +34 902021030 | Fax: +34 902024417
 Key fingerprint = BAA1 7AAF B21D 6567 D457  D67D A82F BB83 F3D5 7033

Bug#870684: gitlab: fails to install: could not find compatible versions for gem "mime-types"

[Andreas Beckmann]

Package: gitlab
Version: 8.13.11+dfsg1-10
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Selecting previously unselected package gitlab.
  (Reading database ... 
(Reading database ... 33760 files and directories currently installed.)
  Preparing to unpack .../gitlab_8.13.11+dfsg1-10_all.deb ...
  Unpacking gitlab (8.13.11+dfsg1-10) ...
  Setting up gitlab (8.13.11+dfsg1-10) ...
  Creating/updating gitlab user account...
  adduser: Warning: The home directory `/var/lib/gitlab' does not belong to the 
user you are currently creating.
  Making gitlab owner of /var/lib/gitlab...
  [ESC][31mBundler could not find compatible versions for gem "mime-types":
In Gemfile:
  fog-azure (~> 0.0) was resolved to 0.0.2, which depends on
azure (~> 0.6) was resolved to 0.7.9, which depends on
  mime-types (< 4.0, >= 1)
  
  carrierwave (~> 0.10.0) was resolved to 0.10.0, which depends on
mime-types (>= 1.16)
  
  github-linguist (~> 4.7) was resolved to 4.7.2, which depends on
mime-types (>= 1.19)
  
  gollum-rugged_adapter (~> 0.4.2) was resolved to 0.4.2, which depends on
mime-types (>= 1.15)
  
  gitlab-flowdock-git-hook (>= 1.0.1, ~> 1.0) was resolved to 1.0.1, which
  depends on
grit (>= 2.4.1) was resolved to 2.5.0, which depends on
  mime-types (~> 2.6)[ESC][0m
  dpkg: error processing package gitlab (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   gitlab


cheers,

Andreas


gitlab_8.13.11+dfsg1-10.log.gz
Description: application/gzip

Bug#870637: [Pkg-gridengine-devel] gridengine-client: qstatus does not set default value for SGE_ROOT

[Afif Elghraoui]

Hi, Liang,

Thanks for the report. I suspect there are other tools that expect
SGE_ROOT to be defined globally as well. I'll have to see about whether
they should not expect this or whether these variables should just be
defined globally.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#870683: ghc: DFSG incompatible file included in src

[Shengjing Zhu]

Source: ghc
Severity: serious
Justification: Policy 2.1

Dear Maintainer,

I find your package contains the following file,

http://sources.debian.net/src/ghc/8.0.2-5/libraries/bytestring/tests/data/

which is licensed under The Project Gutenberg License.

I have a package that meets the same problem, and I asked at debian-legal.
Someone suggests this license fails the DFSG[1].

Please consider to remove this file from source.

[1] https://lists.debian.org/debian-legal/2017/08/msg1.html

Thanks,
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#851569: isn't this the same as #748081 ?

[Legimet]

Control: unblock -1 by 703949

This addon uses WebExtensions now, so it no longer depends on the Addon SDK.

On Wednesday, July 12, 2017 9:18:26 PM EDT Ben Finney wrote:
> Control: retitle -1 RFP: privacy-badger -- web browser plug-in that blocks
> spying ads and invisible trackers Control: block -1 by 703949
> Control: merge 748081 -1
> 
> On 16-Jun-2017, Jeffrey Cliff wrote:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748081 sure looks
> > like a duplicate of this request.
> 
> Yes, it is. Thanks for the catch.
> 
> I am merging the two reports now.

Bug#870409: webkit2gtk: FTBFS on hppa - WebKitEnumTypes.h:27:0: error: unterminated #ifndef

[Jeremy Bicha]

On Thu, Aug 3, 2017 at 3:25 AM, Alberto Garcia  wrote:
> This change is not necessary because the problem will be fixed in glib
> (see bug #870310).

By the way, the fixed glib2.0 is now in unstable.

Thanks,
Jeremy Bicha

Bug#870682: a2ps does not install files in (x)emacs paths

[David Bremner]

Package: a2ps
Version: 1:4.14-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The .el files are in the binary package, but I guess the postinst
doesn't follow debian emacs policy to get the files byte compiled and
installed in the right place.

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

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

Versions of packages a2ps depends on:
ii  file   1:5.30-1
ii  libc6  2.24-12
ii  libpaper1  1.1.24+nmu5
ii  psutils1.17.dfsg-4

Versions of packages a2ps recommends:
ii  bzip2   1.0.6-8.1
ii  cups-bsd [lpr]  2.2.4-3
ii  wdiff   1.2.2-2

Versions of packages a2ps suggests:
ii  emacsen-common   2.0.8
ii  ghostscript  9.21~dfsg-1
pn  groff
pn  gv   
pn  html2ps  
ii  imagemagick  8:6.9.7.4+dfsg-15
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-15
pn  t1-cyrillic  
ii  texlive-binaries [texlive-base-bin]  2017.20170613.44572-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlmD5j0ACgkQ8gKXHaSn
niyeDgv/ZLJ5lU8bfqLC/iLvOidJF9PLuWDwhpTjHOttUivgpPgS7vXOXynQDs33
xEG8FFZ6FCBC+hlrJ8ECxHcktcYU4vrUPtjdnYgeNXTDG1Abbc/sdLeRgJirQuLD
P3nDZGU1olwqDprgTsBkqw2ESTDFAvG1bhrvIbDtUII9UEYwxhpzrVp3J4qsZ/2G
yJzA3nRcF2LHINlG8xac6YRxF8ccUkxhNc/PMJfTKpLfPkX5OBpFtaSf9ofIe1xi
qKgiBZp2lXeu4dQycQDGE21dVqxAc/SruTR89KOPv1RovPYajzvwDYEpg4W8nkK7
rCwEe6rqvYHiMllfXz52ZmT+yQlP1CaN6v2ASyzIgWChrZyRhvgJRc1hHzQspWy7
xZSEu9qYP+8DCkVHONZKAHShwJEoDMtgXMF5AEeS4I8V2tBNNclGaBa2lmv7FmkH
wwzgLeNptSM/CXzf2hcw4kjBCFlDL4wcGskF+BfJJgQiY+twlWvsJJH3rXS7c5n3
z9HLStSz
=uh0R
-END PGP SIGNATURE-

Bug#870681: lintian: [checks/python] Check for python-foo without python3-foo

[Chris Lamb]

tags 870681 + pending
thanks

Fixed in Git:

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


Regards,

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

Bug#805002: libvirt-client: "virsh attach-disk" fails with AppArmor enabled

[Guido Günther]

Hi,
On Thu, Aug 03, 2017 at 10:48:47AM -0400, intrigeri wrote:
> Hi,
> 
> Guido Günther:
> > According to
> 
> >   https://www.redhat.com/archives/libvir-list/2017-March/msg01612.html
> 
> > on Jessie with
> 
> > Kernel 4.9.11
> > Apparmor 2.10
> 
> > unbreaks attaching disks.
> 
> for the record, the Linux kernel commit John referred to (ec34fa2)
> made it into Linux 4.8.
> 
> Sadly, it seems that some aspect of reloading profiles is still
> somewhat broken for me on current sid, either in the parser or in the
> kernel (tested on apparmor 2.11.0-6+b2, Linux 4.11.0-2-amd64 version
> 4.11.11-1+b1).
> 
> I've used the same testing procedure as Guido
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805002#109), i.e.
> without involving virt-aa-helper.
> 
> I see a denial logged:
> 
>   AVC apparmor="DENIED" operation="open"
>   profile="libvirt-213ff882-ce4b-035d-e2b1-9059d66cd67d"
>   name="/var/lib/libvirt/images/Jessie.qcow2" pid=20033
>   comm="qemu-system-x86" requested_mask="rw" denied_mask="rw"
>   fsuid=119 ouid=119
> 
> … while apparmor_parser --debug -r 
> libvirt-213ff882-ce4b-035d-e2b1-9059d66cd67d
> says access is allowed:
> 
>   Mode:   rwa:rwa Name:   (/var/lib/libvirt/images/Jessie.qcow2)
> 
> John, is there anything I can do on my side to help debug this?
> 
> Guido, Frank, Carlo: can you reproduce my results on Stretch and/or
> current sid?

Yes, I can still reproduce this on Buster.
Cheers,
 -- Guido

Bug#870681: lintian: [checks/python] Check for python-foo without python3-foo

[Chris Lamb]

Package: lintian
Version: 2.5.52
Severity: wishlist

The 2.x series of Python is due for deprecation and will not be
maintained past 2020.

We should therefore warn about packages not providing a corresponding
Python 3 version.


Regards,

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

Bug#869399: unlock keyring automatically at startup

[積丹尼 Dan Jacobson]

Or maybe I can like https://superuser.com/a/141232 use
   -l, --login
   This argument tells the daemon it is being run by PAM. It reads all
   of stdin (including any newlines) as a login password and does not
   complete actual initialization.

(But I will not touch PAM stuff as any tinkering could lock me out forever.)

Bug#869399: unlock keyring automatically at startup

[積丹尼 Dan Jacobson]

https://ubuntuforums.org/showthread.php?t=192281=2524785#post2524785
got me thinking, maybe I can write a script...

I see the gnome-keyring-daemon man page has --unlock.
Maybe I can do
echo "my password"| gnome-keyring-daemon --unlock
in my bash profile, and then the rest of the day all apps would just work?

In fact in my .xsession I already have

m=`gnome-keyring-daemon --start` # https://bugs.debian.org/806169 midori
# https://wiki.archlinux.org/index.php/GNOME/Keyring#Without_a_display_manager
if test $? -eq 0
then export $m
else echo $0: install gnome-keyring first.|mail -s $0 $USER
fi #What a hassle. Other browsers don't need this.

So maybe all I need to do is add
echo "my password"| gnome-keyring-daemon --unlock
after it?

Bug#870680: bbdb: diff for NMU version 2.36-4.1

[David Bremner]

Control: tags 870680 + patch
Control: tags 870680 + pending

Dear maintainer,

I've prepared an NMU for bbdb (versioned as 2.36-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

David

diff -Nru bbdb-2.36/debian/changelog bbdb-2.36/debian/changelog
--- bbdb-2.36/debian/changelog	2014-02-24 07:17:51.0 -0500
+++ bbdb-2.36/debian/changelog	2017-08-03 22:22:54.0 -0400
@@ -1,3 +1,10 @@
+bbdb (2.36-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace emacs24 with emacs25 as a (build)-dependency. Leave emacs24 for backports.
+
+ -- David Bremner   Thu, 03 Aug 2017 22:22:54 -0400
+
 bbdb (2.36-4) unstable; urgency=medium
 
   * engage dh autoreconf, rm ./configure, relax regarding ./configure +x bit
diff -Nru bbdb-2.36/debian/control bbdb-2.36/debian/control
--- bbdb-2.36/debian/control	2014-02-24 07:09:20.0 -0500
+++ bbdb-2.36/debian/control	2017-08-03 22:18:43.0 -0400
@@ -7,7 +7,7 @@
 dh-autoreconf
 Build-Depends-Indep: texinfo, texi2html, ghostscript,
 texlive-base, texlive-latex-base,
-emacs24-nox | emacs24 | emacs23-nox | emacs23 | emacs
+emacs25-nox | emacs25 | emacs24-nox | emacs24 | emacs
 Standards-Version: 3.9.5
 Vcs-Git: git://github.com/barak/BBDB.git
 Vcs-Browser: http://github.com/barak/BBDB
@@ -15,7 +15,7 @@
 
 Package: bbdb
 Architecture: all
-Depends: make, emacs24 | emacs23 | emacsen, ${misc:Depends}, ${perl:Depends}
+Depends: make, emacs25 | emacs24 | emacsen, ${misc:Depends}, ${perl:Depends}
 Suggests: vm, w3m-el, gnuserv, gnus|t-gnus, perl
 Description: The Insidious Big Brother Database (email rolodex) for Emacs
  BBDB is a rolodex-like database program for GNU Emacs.  BBDB stands


signature.asc
Description: PGP signature

Bug#870680: bbdb: please upgrade deps emacs24 -> emacs25

[Sean Whitton]

Source: bbdb
Version: 2.36-4
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs24-removal

Dear maintainer,

Your package has a dependency and/or build dependency on emacs24, which
will shortly be removed from the archive.  Please update the package to
depend on emacs25 instead.

David Bremner is preparing an NMU of your package and will momentarily
upload it to DELAYED/5.  Please let us know if he should delay it
further.  An nmudiff will follow-up this bug.

If this package need not build for xemacs, please also consider
transitioning the package to build using dh-elpa.  This will also avoid
future bugs like this one, since the Emacs major version is updated
once, centrally, in dh-elpa.

Once the emacs24 removal process starts, this bug will be upgraded to RC
severity.

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#549233: docbook-to-man: Does not accept (some) (unicode) characters

[Paul Hardy]

Helge,

I looked at this bug report because I was looking into other things
related to DocBook and man pages.  I think this is not a bug.

If you look at the file you attached with "less", you will see
characters such as "" and "".  Those are the hexadecimal
values of Latin1 characters, not parts of UTF-8 characters.  Maybe you
accidentally attached the wrong file; I don't know.  That would
explain why there are no complaints when you try to convert this as a
Latin1 document though.

I am attaching a version of your document re-encoded as UTF-8 for you
to experiment with.  I did not try to process it.

I also changed the "doctype" word on the first line to "DOCTYPE"; I
think it is always supposed to be upper-case even if some tools don't
complain.

Because this is a DocBook file, you could try giving the filename the
suffix ".xml" and insert this as a first line in the file to declare
its encoding as UTF-8:

 

You might also need to modify the system identifier in the DOCTYPE line.

In summary, I think the problem is that the document you attached is
not a valid UTF-8 document.  There might be other reasons why it is
also not a valid SGML document.

The "emacs" editor will recognize SGML documents as such if the
filename ends in ".sgml".  I do not know how well it validates general
SGML files though.  If you end the filename in ".xml", you can enable
Nxml mode in emacs.  See
https://www.emacswiki.org/emacs/UsingNxmlModeWithDocBook for more
information.  Note that some older emacs instructions might say you
need to download the Nxml package and install it for emacs, but recent
versions of emacs include it.

I do not know what other validation tools are available for general
SGML files on Debian, apart from xsltproc.

I am not the maintainer of this package, and DocBook 4.1 is very, very
old at this point, but I am posting this in case it helps you resolve
this bug.  Hopefully, this is also enough information for you to
decide to close the bug.

Good luck,


Paul Hardy
FIXME">
  Niedermeyer">
  FIXME 2009">
  1">
  chias...@bsi.bund.de">
  
  CHIASMUS">
  

  Debian">
  GNU">
  GPL">
  ">
]>

 

  
   

  
 
  
  
FIXME 2009
   
  
   

 
 




 
 
  
  Demo for docbook-to-man problems
 
 


  -hilfe
 
 

  -beispiel
 
 
 
  BESCHREIBUNG
  
   is some programme 


Für Hinweise zur Sicherheit siehe "HINWEISE", für erste Schritte siehe 
"EINFÜHRUNG" und für weiter Anwendungsbeispiele "BEISPIELE".

Testing ß.


 
 
  OPTIONEN
  
Zwischen einer Option und dem zugehörigen Parameter können, müssen aber keine 
Leerzeichen stehen. Die Optionen können in beliebiger Reihenfolge angegeben 
werden. Wird eine Option mehrfach angegeben, so wird nur das letzte Auftreten 
der Option (bzw. der zugehörige Parameter) ausgewertet. Wildcards werden von 
chiasmus nicht unterstützt.


  
   
-hilfe

 
   Gibt eine kurze Hilfe aus.
 

   

   
  -beispiel

 
   Gibt Beispiele zur Verwendung von Chiasmus aus.
 

   

   
  -m something

	
	some text
 

 
Beispiele: 
 
 
	 
	 
		 a. This is something
	 
	   


	b. Something else



	 
		 c. Even more so 
	 


	 
		 d. A fourth item
	  


	 
		 e. A fifth item 
	 
	 
 

 

   
-q something

	
	Does somthing more
 
 
	 Beispiele: 
 
  
  
	  
	  a. Should be a) (restarted)
	  
   
   
   
	   b.  Should be b)
% demo something ...
   
   
   
   
Hinweis: Die Option -q braucht nicht mit angegeben zu werden. Das Kommando 
% demo something else 
leistet dasselbe wie das Kommando in Beispiel a.
 

   
 
   
-z Options

 
FIXME
 
 
	 some text
 
 
Beispiele: 
 
  
  
	  
	  a.  Should be again a)  
   
   
   
	   b.  Should  be again b)
 
 
 
   
 
  
 

Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img

[Vagrant Cascadian]

Control: severity 870615 important

On 2017-08-03, Vagrant Cascadian wrote:
> On 2017-08-03, Cyril Brulebois wrote:
>> d-i now FTBFSes on armhf, due to:
>> ,---[ hd-media ]---
>> | gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot-spl.rksd at 
>> sector 64 ...
>> | gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot.img at 
>> sector 256 ...
>> | config/armhf//hd-media.cfg:33: recipe for target 
>> 'hd-media_images_concatenateable' failed
...
>> I suppose this is due to this change in u-boot on 2017-08-01:
>> |  u-boot (2017.07+dfsg1-2) unstable; urgency=medium
>> |  .
>> |* u-boot-rockchip:
>> |  - Ship u-boot.bin in firefly-rk3288 instead of u-boot.img.
>> |  - Add NEWS file explaining the change for firefly-rk3288.
>>
>> See https://tracker.debian.org/news/860117
...
> This may actually require changing the d-i code(the new method requires
> appending two things together before dd'ing them, rather that dd'ing two
> things at specific locations), or more changes to u-boot (I could
> pregenerate that part in u-boot, though that means shipping redundant
> bits).
>
> Might be best to temporarily disable the firefly-rk3288 in d-i until I
> figure out what's best to do...

I've disabled it in git for now, will explore a proper fix soon.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#870679: ghostscript: Annotate debian/conrol for DEB_BUILD_PROFILES=stage1

[Daniel Schepler]

Source: ghostscript
Version: 9.21~dfsg-1
Severity: wishlist

It would be nice if the source package could be updated with build
profile annotations for libcups2-dev  and libcupsimage2-dev
.  Of course, then you would probably either need to split
off the cups driver into a separate package ghostscript-cups (though I
don't know if it's even supported to build the driver as a plugin, as
ghostscript-x support is).  Or otherwise, it would need to produce a
ghostscript-stage1 package since it would have different binary
contents from the full ghostscript package.
-- 
Daniel Schepler

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Adrian Bunk  writes:
> On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
>> Adrian Bunk  writes:

>>> Regressing on being able to orphan all packages of a known-MIA/retired
>>> maintainer would be very bad.

>> I agree, but that's not directly relevant here, since we're talking
>> about team-maintained packages.  The whole *point* of team maintenance
>> is that there's no reason to orphan a package just because one team
>> member went away.  If that weren't the case, the package is, *by
>> definition*, not team-maintained (or the team itself is MIA, which is a
>> different issue as discussed below).

> Your definition is completely detached from the reality in Debian.

> Many (likely the majority) of teams in Debian have not more than 1
> active member.

Then when that one member disappears, that team becomes MIA, which is
something that would need to be detected by an MIA process for teams,
which I agree should exist, but which I think is detectable via other
mechanisms than Uploaders.  One approach as Holger points out: look for
packages where all the recent uploads have been by the MIA member, which
doesn't require the Uploaders field at all.

I stand by my statement that as long as the team *does* have more than one
member, not having to change anything abot package maintenance when one
team member disappears is kind of the whole point of having team
maintenance.  If the team is not providing that, it feels like there's not
much point in having a team, although I guess it could be aspirational.

> When all members of a team are confirmed to be MIA/retired, this should
> result in an orphaning of all packages maintained by the team.

One of the whole points of this discussion is that this "members of a
team" concept is not well-defined in Debian and is probably not something
that we *can* make well-defined in Debian.  Or, more to the point, *want*
to make well-defined.

>> No, I'm not -- as I pointed out in a separate message, this is a
>> problem worth solving, but this is an MIA team problem that I think is
>> best tackled from that angle.  If all of a team's packages are
>> bitrotting, then the team's packages should be orphaned just like we do
>> with an MIA single maintainer.

> This would create both longer bitrot for packages and more work for
> an already overworked team.

Why?  I don't see how this follows; in fact, I believe the exact opposite.
The current work that the MIA team does to track down Uploaders that
mention MIA people on team-maintained packages and file a bunch of bugs to
have them removed is work that they *don't* have to do in this model.
Instead, just treat the team like another maintainer and look at whether
that maintainer's packages are being maintained and whether that team is
active and orphan packages if they aren't.

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

Bug#840089: [git-buildpackage/master] export_orig: new command to export orig tarballs from git

[Guido Günther]

tag 840089 pending
thanks

Date:   Thu Aug 3 17:54:33 2017 -0300
Author: Guido Günther 
Commit ID: ae7ed14ef68abe7a97e82224594140c626cf7820
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=ae7ed14ef68abe7a97e82224594140c626cf7820
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=ae7ed14ef68abe7a97e82224594140c626cf7820

export_orig: new command to export orig tarballs from git

Closes: #840089

  

Bug#870595: [git-buildpackage/master] Use python3-notify2

[Guido Günther]

tag 870595 pending
thanks

Date:   Thu Aug 3 21:20:22 2017 -0300
Author: Guido Günther 
Commit ID: d9b535e5c0fba267150fd3a7d0cbf00245860bec
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=d9b535e5c0fba267150fd3a7d0cbf00245860bec
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=d9b535e5c0fba267150fd3a7d0cbf00245860bec

Use python3-notify2

Closes: #870595
Thanks: Alexandre Detiste

  

Bug#870678: winff autopkgtests fail with ffmpeg 3.3.3: No such filter: 'asyncts'

[Steve Langasek]

Source: winff
Version: 1.5.5-2
Severity: grave
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful autopkgtest

Hi Paul,

A data point for your autopkgtest BoF ;)

With the upload of ffmpeg 3.3, the winff autopkgtests are now failing on
ci.debian.net with the following error:

[swscaler @ 0x55a0e475e5c0] deprecated pixel format used, make sure you did set 
range correctly
[AVFilterGraph @ 0x55a0e4734160] No such filter: 'asyncts'
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:1
Conversion failed!
autopkgtest [15:42:41]: test check-presets: ---]
autopkgtest [15:42:41]: test check-presets:  - - - - - - - - - - results - - - 
- - - - - - -
check-presetsFAIL non-zero exit status 1

  https://ci.debian.net/packages/w/winff/unstable/amd64/

This is explained in the ffmpeg upstream changelog:

  version 3.3:
  [...]
  - Removed asyncts filter (use af_aresample instead)

I've confirmed that this autopkgtest is testing the same presets.xml which
is installed by winff in the winff-data package, so it appears that this
will genuinely cause winff to fail at runtime (i.e., this is not just a bug
in the test).  I'm therefore marking it 'grave'.  Feel free to downgrade if
you think this is wrong - it looks like only the presets for three Nokia
devices are affected.

I would tag this bug 'sid', except that since autopkgtests don't gate
testing in Debian, this autopkgtest regression does not stop the new ffmpeg
from migrating to testing and breaking winff there.

I don't know the fix for this issue, as I'm not conversant with ffmpeg and
so am not sure how to map the existing asyncts filter settings to the
recommended af_aresample filter.  There does not appear to be a fix upstream
for this yet in the winff github repo.

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


signature.asc
Description: PGP signature

Bug#757834: libtext-charwidth-perl: Creates empty /usr/lib/perl5 directory when built with perl 5.20

[intrigeri]

Hi,

Niko Tyni (Fri, 4 Nov 2016 12:41:54 +0200):
> On Mon, Aug 11, 2014 at 07:54:08PM +0200, gregor herrmann wrote:
>> The "patch" is trivial:
>> rm debian/dirs
>> 
>> (It's not needed anyway).

> Hi, this is one of the two packages left shipping /usr/lib/perl5 on my
> system. Please consider fixing it so we can get that transition finished
> and the confusing now useless directory removed.

> Alternatively, would you be OK with an NMU or even adoption by the
> pkg-perl team?

I've uploaded to DELAYED/15 with the following diff (simply removing
the offending line from debian/dirs — I didn't dare removing the other
line in a NMU, even though I'm pretty sure gregor is right):

diff -Nru libtext-charwidth-perl-0.04/debian/changelog 
libtext-charwidth-perl-0.04/debian/changelog
--- libtext-charwidth-perl-0.04/debian/changelog2011-07-19 
20:54:58.0 -0400
+++ libtext-charwidth-perl-0.04/debian/changelog2017-08-03 
21:12:28.0 -0400
@@ -1,3 +1,10 @@
+libtext-charwidth-perl (0.04-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop shipping an empty /usr/lib/perl5 directory (Closes: #757834).
+
+ -- intrigeri   Fri, 04 Aug 2017 01:12:28 +
+
 libtext-charwidth-perl (0.04-7) unstable; urgency=low
 
   [ Steve McIntyre ]
diff -Nru libtext-charwidth-perl-0.04/debian/dirs 
libtext-charwidth-perl-0.04/debian/dirs
--- libtext-charwidth-perl-0.04/debian/dirs 2008-02-28 04:21:57.0 
-0500
+++ libtext-charwidth-perl-0.04/debian/dirs 2017-08-03 21:12:13.0 
-0400
@@ -1,2 +1 @@
-usr/lib/perl5
 usr/share/man/man3


Cheers,
-- 
intrigeri

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
> Adrian Bunk  writes:
> 
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
> 
> I agree, but that's not directly relevant here, since we're talking about
> team-maintained packages.  The whole *point* of team maintenance is that
> there's no reason to orphan a package just because one team member went
> away.  If that weren't the case, the package is, *by definition*, not
> team-maintained (or the team itself is MIA, which is a different issue as
> discussed below).

Your definition is completely detached from the reality in Debian.

Many (likely the majority) of teams in Debian have not more
than 1 active member.

> >> Currently, when the MIA team finds someone who is no longer active,
> >> teams have to go do a bunch of work to strip their name out of uploader
> >> fields.  That work doesn't really make Debian any better; it's just
> >> bookkeeping.  When the team has other ways of knowing the health of
> >> their packages, I'd like to let them not do this bookkeeping.
> 
> > You are assuming that the team notices without the current notifications
> > from the MIA team that a team member is no longer active in Debian.
> 
> I'm really not.  I'm pointing out that for a lot of teams, that literally
> *does not matter at all*.  Absolutely nothing changes about the
> maintenance status of many team-maintained packages if the person who last
> worked on that package disappears.
> 
> Teams often don't notice that someone is MIA because *it doesn't matter*
> for their workflow; they're happy to have people come and go.

When all members of a team are confirmed to be MIA/retired,
this should result in an orphaning of all packages maintained
by the team.

> > You are assuming that the team has a non-zero number of active members
> > left after a member becomes MIA.
>
> No, I'm not -- as I pointed out in a separate message, this is a problem
> worth solving, but this is an MIA team problem that I think is best
> tackled from that angle.  If all of a team's packages are bitrotting, then
> the team's packages should be orphaned just like we do with an MIA single
> maintainer.

This would create both longer bitrot for packages and more work for
an already overworked team.

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#869399: unlock keyring automatically at startup

[Ryan Tandy]

On Fri, Aug 04, 2017 at 09:04:39AM +0800, 積丹尼 Dan Jacobson wrote:

Thank you! But please tell me how to do it without installing seahorse.


I don't know that, sorry. My best guess would be that you want to send a 
command to the gnome-keyring daemon over DBus. The ChangeLock method 
looks relevant, for example.


This is sounding less and less like a nodm bug report, though. Perhaps 
it might be best to move this conversation to the debian-user list.


thanks,
Ryan

Bug#870677: nvidia-kernel-dkms: Doesn't compile with kernel 4.11 (and probably later)

[Jiri Palecek]

Package: nvidia-kernel-dkms
Version: 378.13-1
Severity: normal

Dear Maintainer,

-- Package-specific info:
uname -a:
Linux debian 4.11.0-2-686-pae #1 SMP Debian 4.11.11-1 (2017-07-22) i686 
GNU/Linux

/proc/version:
Linux version 4.11.0-2-686-pae (debian-ker...@lists.debian.org) (gcc version 
6.4.0 20170704 (Debian 6.4.0-1) ) #1 SMP Debian 4.11.11-1 (2017-07-22)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86 Kernel Module  375.82  Wed Jul 19 20:16:02 PDT 
2017
GCC version:  gcc version 6.4.0 20170704 (Debian 6.4.0-1) 

lspci 'VGA compatible controller [0300]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF106 [GeForce GTS 
450] [10de:0dc4] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GF106 [GeForce GTS 450] [1043:8366]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video 226,   0 Aug  3 17:55 /dev/dri/card0
crw-rw+ 1 root video 226, 128 Aug  3 17:55 /dev/dri/renderD128
crw-rw-rw-  1 root root  195, 254 Aug  3 18:01 /dev/nvidia-modeset
crw-rw-rw-  1 root root  195,   0 Aug  3 18:01 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Aug  3 18:01 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Aug  3 17:55 pci-:02:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Aug  3 17:55 pci-:02:00.0-render -> ../renderD128
video:x:44:

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 2167 May 13  2016 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root   15 Sep 25  2016 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   47 Jun 26 14:53 
/etc/alternatives/glx--libEGL.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   42 Sep 25  2016 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   46 Jun 26 14:53 
/etc/alternatives/glx--libGL.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   46 Jun 26 14:53 
/etc/alternatives/glx--libGL.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   41 Sep 25  2016 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Sep 25  2016 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   48 Sep 25  2016 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   48 Sep 25  2016 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Jun 26 14:53 
/etc/alternatives/glx--libGLESv2.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   50 Jun 26 14:53 
/etc/alternatives/glx--libGLESv2.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   45 Sep 25  2016 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   45 Sep 25  2016 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   49 Sep 25  2016 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Sep 25  2016 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Sep 25  2016 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Sep 25  2016 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Sep 25  2016 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Sep 25  2016 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Sep 25  2016 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 Sep 25  2016 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   22 Jun 26 14:53 /etc/alternatives/libGL.so-master 
-> /usr/lib/mesa-diverted
lrwxrwxrwx 1 root root   23 Aug  3 17:54 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   50 Aug  3 17:54 
/etc/alternatives/nvidia--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libEGL.so.1
lrwxrwxrwx 1 root root   

Bug#869399: unlock keyring automatically at startup

[積丹尼 Dan Jacobson]

RT> I believe it's possible to store the GNOME keyring unencrypted, if
RT> that's what you want (based on reading your comments in the upstream
RT> report). In seahorse ("Passwords and Encryption Keys") you should be
RT> able to change the keyring password to an empty password. If I'm
RT> remembering correctly, that should remove the prompts to unlock - with
RT> the tradeoff that you are storing your secrets on disk *completely
RT> unsecured*.

Thank you! But please tell me how to do it without installing seahorse.
I just need to know what file to change. I will be reproducing the
solution you tell me across many machines non-interactively. So even if
I installed the 7 megs to install seahorse just to change one line
somewhere. I would still need to copy that file to many machines.

Bug#870676: ffmpeg requires NEON on armhf, which is not part of the ARMv7 ABI

[Steve Langasek]

Package: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch autopkgtest

Dear maintainers,

The latest release of ffmpeg enables NEON support by default when building
on armhf; however, NEON support is not a standard part of the ARMv7 ABI, and
Debian supports running armhf on chips that do not implement NEON.

Using NEON based on runtime detection of support for it is fine, but the
existing ffmpeg implementation doesn't appear to do this, instead using NEON
based on build-time configuration with no fallback.

This issue was noticed in Ubuntu only because the autopkgtests for ffmpeg
and x264 triggered an unaligned access in the NEON code, which is *also* not
a portable assumption on armhf; however, if the NEON code had not had any
unaligned access, the fact that NEON was used would have gone unnoticed on
Ubuntu infrastructure.

  http://autopkgtest.ubuntu.com/packages/f/ffmpeg/artful/armhf
  http://autopkgtest.ubuntu.com/packages/x/x264/artful/armhf

(And if upstream does fix their code to support runtime detection of NEON
support, then there will be a different bug for us to worry about fixing!)

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ffmpeg-3.3.3/debian/rules ffmpeg-3.3.3/debian/rules
--- ffmpeg-3.3.3/debian/rules   2017-08-01 07:33:41.0 -0700
+++ ffmpeg-3.3.3/debian/rules   2017-08-03 17:43:44.0 -0700
@@ -127,6 +127,14 @@
--enable-libiec61883
 endif
 
+# upstream does not implement runtime detection of NEON support at runtime;
+# therefore NEON must be disabled at build time.  (This also works around
+# the fact that the NEON implementation does unaligned access, which is not
+# a portable assumption for armhf.)
+ifeq ($(DEB_HOST_ARCH),armhf)
+   CONFIG += --disable-neon
+endif
+
 # Some build-dependencies are not installable on some architectures.
 ifeq (,$(filter $(DEB_HOST_ARCH),powerpcspe))
CONFIG_extra += --enable-netcdf

Bug#845806: librdf-crypt-perl: uses deprecated Any::Moose

[gregor herrmann]

On Thu, 03 Aug 2017 20:53:57 -0400, intrigeri wrote:

> > so I'm tagging this as a possible candidate for removal.
> Yes. I'll proceed if another team member approves.

Sure, please go ahead, and thanks for doing this job!

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#845770: libanyevent-gearman-perl: uses deprecated Any::Moose

[gregor herrmann]

On Thu, 03 Aug 2017 20:46:25 -0400, intrigeri wrote:

> > so perhaps a candidate for removal?
> Definitely IMO. I'll file the RM request if another team member
> approves (nobody objected to Niko's suggestion in 8 months).

$approve++;


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#845804: libpath-dispatcher-perl: uses deprecated Any::Moose

[gregor herrmann]

On Thu, 03 Aug 2017 20:50:38 -0400, intrigeri wrote:

> > So these two packages seem like removal candidates too.
> Yes. I'll proceed if another team member approves.

I'm fully happy if Niko and you already agree after evaluating the
situation, so:

$approve->{gregoa} = 1 if ($approve->{ntyni} && $approve->{intrigeri});

:)

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#845806: librdf-crypt-perl: uses deprecated Any::Moose

[intrigeri]

Niko Tyni:
> The upstream ticket has had no comment from the maintainer in 1.5 years.
> There are no reverse dependencies in Debian,

Still the case (modulo time flies). Last upstream release was in 2012.
popcon is low (Inst = 5, Vote = 1).

> so I'm tagging this as a possible candidate for removal.

Yes. I'll proceed if another team member approves.

Cheers,
-- 
intrigeri

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 08:16:30PM -0400, gregor herrmann wrote:
> On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:
> 
> > On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > > What I don't understand in the point of view of the "keep Uploaders"
> > > proponents: What does this information, whether correct or not,
> > > actually give others? Are they going to email or phone these persons
> > > privately when emails to the BTS or the maintainer/team list are
> > > ignored? And what happens if they ignore these communications as
> > > well?
> > 
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5
> > 
> > These "Updating the  Uploaders list" bugs.
> > 
> > When the MIA team has determined that a person is MIA,[1]
> > it can send bugs informing all packages where that person
> > is listed in Uploaders that the person is no longer active.
> 
> Ok, that's a good example:
> 
> So, when we (pkg-perl) get such a list of bug reports (or, which is
> less work, a single mail from the MIA team about XY being inactive)
> what happens is that
> - we probably know that already (but it's still good to have the
>   offical confirmation)
> - we remove them from Uploaders in git
> - nothing else changes: the package will be uploaded when there's any
>   reason for it (new release, bugfix) as before when XY was still
>   mentioned in Uploaders
> 
> Dropping the Uploaders field would mean that we save the work (which
> can be quite tedious when we have to add the right bug numbers to the
> right packages' changelog entry) without any other changes to the
> maintenance of the package.

But then the information who is currently part of pkg-perl is needed in
machine-readable form and displayed by tools like DDPO and tracker for:
1. being able to inform a team that a member is MIA and inform the team, and
2. being able to detect when the last team member is MIA

Policy equally applies to packages where point 2 is far more likely to 
happen than for pkg-perl.

Autogenerating Uploaders like GNOME does [1] would be an alternative
approach.

> Cheers,
> gregor 

cu
Adrian

[1] https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/

-- 

   "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#845804: libpath-dispatcher-perl: uses deprecated Any::Moose

[intrigeri]

Niko Tyni:
> The upstream ticket is 3.5 years old, with no comment from
> the maintainer.  There are no reverse dependencies besides
> libpath-dispatcher-declarative-perl; they seem to have been in the
> archive to support the prophet package, which was recently removed from
> sid (see #845541).

All this is still correct, and popcon is low (Inst = 35, Vote = 6).

> So these two packages seem like removal candidates too.

Yes. I'll proceed if another team member approves.

Cheers,
-- 
intrigeri

Bug#845770: libanyevent-gearman-perl: uses deprecated Any::Moose

[intrigeri]

Niko Tyni:
> There's an upstream ticket that's almost three years old, with
> a suggested fix but no comment from the maintainer. The latest
> upstream release is also almost three years old.

> No reverse dependencies in Debian AFAICS,

This + popcon is very low.

> so perhaps a candidate for removal?

Definitely IMO. I'll file the RM request if another team member
approves (nobody objected to Niko's suggestion in 8 months).


Cheers,
-- 
intrigeri

Bug#845770: libanyevent-gearman-perl: uses deprecated Any::Moose

[intrigeri]

Niko Tyni:
> There's an upstream ticket that's almost three years old, with
> a suggested fix but no comment from the maintainer. The latest
> upstream release is also almost three years old.

> No reverse dependencies in Debian AFAICS,

This + popcon is very low.

> so perhaps a candidate for removal?

Definitely IMO.

Cheers,
-- 
intrigeri

Bug#870675: apt: Strangely hangs without any meaningful error message if apt-transport-https is not installed

[Askar Safin]

Package: apt
Version: 1.4.7
Severity: normal

I just wrote this to sources.list:

deb https://deb.debian.org/debian stretch main
deb https://deb.debian.org/debian-security stretch/updates main

And then I run "apt-get update". I saw:

# apt-get update
0% [Working]

I waited, and waited and waited.

And then I suddenly understand that the package apt-transport-https is missing.

So, if sources.list contains some schema which has no corresponding 
apt-transport-* package installed, then meaningful error message should
be printed instead of just hanging.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-3-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "false";
APT::Compressor::xz::Cost "200";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "false";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "false";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--suffix=";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--suffix=";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::mirrors "mirrors/";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Adrian Bunk  writes:

> Regressing on being able to orphan all packages of a known-MIA/retired
> maintainer would be very bad.

I agree, but that's not directly relevant here, since we're talking about
team-maintained packages.  The whole *point* of team maintenance is that
there's no reason to orphan a package just because one team member went
away.  If that weren't the case, the package is, *by definition*, not
team-maintained (or the team itself is MIA, which is a different issue as
discussed below).

>> Currently, when the MIA team finds someone who is no longer active,
>> teams have to go do a bunch of work to strip their name out of uploader
>> fields.  That work doesn't really make Debian any better; it's just
>> bookkeeping.  When the team has other ways of knowing the health of
>> their packages, I'd like to let them not do this bookkeeping.

> You are assuming that the team notices without the current notifications
> from the MIA team that a team member is no longer active in Debian.

I'm really not.  I'm pointing out that for a lot of teams, that literally
*does not matter at all*.  Absolutely nothing changes about the
maintenance status of many team-maintained packages if the person who last
worked on that package disappears.

Teams often don't notice that someone is MIA because *it doesn't matter*
for their workflow; they're happy to have people come and go.

> You are assuming that the team has a non-zero number of active members
> left after a member becomes MIA.

No, I'm not -- as I pointed out in a separate message, this is a problem
worth solving, but this is an MIA team problem that I think is best
tackled from that angle.  If all of a team's packages are bitrotting, then
the team's packages should be orphaned just like we do with an MIA single
maintainer.

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

Bug#870657: [pkg-octave/master] d/control: drop useless Build-Depends on libftgl-dev.

[Mike Miller]

tag 870657 pending
thanks

Date: Thu Aug 3 12:48:47 2017 -0700
Author: Mike Miller 
Commit ID: e9f204d1c39bb54ab15e37909373370230660368
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave.git;a=commitdiff;h=e9f204d1c39bb54ab15e37909373370230660368
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave.git;a=commitdiff_plain;h=e9f204d1c39bb54ab15e37909373370230660368

d/control: drop useless Build-Depends on libftgl-dev.

Closes: #870657
  

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:11:07PM -0700, Russ Allbery wrote:
> Tobias Frost  writes:
> 
> > Some time ago I did some spring cleaning going over DDs that have
> > retired but still in the Maintainer/Uploader fields: There were quite a
> > lot "team maintained" packages where the team did not recognize that the
> > (sole) Uploader wasn't there anymore and the packages were
> > bitrotting. Without the Uploader field there would have been excactly
> > zero change to find those packages and get them back into maintainance
> > again.
> 
> I'm dubious about this assertion and would like to dig into it a bit more.
> 
> The way we hopefully would find bitrotting packages is that they are,
> well, bitrotting.  This is based on lack of uploads, open bugs, old Policy
> versions, incomplete transitions, and in serious cases, missing from
> stable releases.  While we can *also* find bitrotting packages via the MIA
> process, it shouldn't be our primary or even a major way of finding them
> since it's entirely possible for someone to be quite active in Debian
> while still neglecting some of their packages.
>...

Regressing on being able to orphan all packages of a known-MIA/retired
maintainer would be very bad.

Think of it as a 3 step process:
1. a bitrotting package indicates a potentially MIA maintainer
2. the maintainer agrees to orphaning all packages, or after several 
   failed contact attempts the MIA team declares that the maintainer is MIA
3. for every package where the maintainer is in Maintainer or Uploaders
   the MIA team either orphans the package, or informs team or 
   co-maintainers through an "Updating the  Uploaders list" bug.

Just by going through bugs, I compiled during the past 10 months a list 
of currently 250 (sic) names of people listed in Maintainer or Uploaders
of packages in unstable where I suspect the person might be MIA.

Automating this part would not be a problem, the intersection of
"in Maintainer or Uploaders of a package in unstable" and
"no email to a Debian list or the BTS in the past 12 months"
should give approximately a superset of my list.

Step 2 is actually a lot of work.

The part where removing the Uploaders: requirement could cause 
regressions is step 3.

Give for a person a complete list of all packages where this person was 
active" - if we regress on this, it means that packages will continue to
bitrot in cases where they can currently be orphaned.

> Currently, when the MIA team finds someone who is no longer active, teams
> have to go do a bunch of work to strip their name out of uploader fields.
> That work doesn't really make Debian any better; it's just bookkeeping.
> When the team has other ways of knowing the health of their packages, I'd
> like to let them not do this bookkeeping.
>...

You are assuming that the team notices without the current notifications 
from the MIA team that a team member is no longer active in Debian.

You are assuming that the team has a non-zero number of active members 
left after a member becomes MIA.

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#870674: apt autoremove leaves behind packages

[Lucas Reed]

Package: apt
Version: 1.4.7
Severity: normal

I check my number of packages, I have say 1350. I install a package 'Z' through
apt and have say 1400 packages.

I then remove and autoremove and purge package 'Z', and when I check the number
of packages, I have 1380 packages instead of 1350. What happened?



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "true";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-3-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:

> On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > What I don't understand in the point of view of the "keep Uploaders"
> > proponents: What does this information, whether correct or not,
> > actually give others? Are they going to email or phone these persons
> > privately when emails to the BTS or the maintainer/team list are
> > ignored? And what happens if they ignore these communications as
> > well?
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5
> 
> These "Updating the  Uploaders list" bugs.
> 
> When the MIA team has determined that a person is MIA,[1]
> it can send bugs informing all packages where that person
> is listed in Uploaders that the person is no longer active.

Ok, that's a good example:

So, when we (pkg-perl) get such a list of bug reports (or, which is
less work, a single mail from the MIA team about XY being inactive)
what happens is that
- we probably know that already (but it's still good to have the
  offical confirmation)
- we remove them from Uploaders in git
- nothing else changes: the package will be uploaded when there's any
  reason for it (new release, bugfix) as before when XY was still
  mentioned in Uploaders

Dropping the Uploaders field would mean that we save the work (which
can be quite tedious when we have to add the right bug numbers to the
right packages' changelog entry) without any other changes to the
maintenance of the package.


Cheers,
gregor 

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


signature.asc
Description: Digital Signature

Bug#870673: cryptsetup causes piuparts test to fail

[Alberto Bertogli]

Package: cryptsetup
Version: 2:1.7.3-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

A new version of the kxc package fails piuparts due to cryptsetup not being
able to be removed correctly.

I belive this is unrelated to kxc itself, and it's blocking the move to
testing.

https://piuparts.debian.org/sid/fail/kxc_0.13+git20170730.6182dc8-1.log

Relevant extract from the log (output of apt-get remove):

  Removing kxc (0.13+git20170730.6182dc8-1) ...
  Removing cryptsetup (2:1.7.3-4) ...
  /dev/mapper/control: open failed: No such device
  Failure to communicate with kernel device-mapper driver.
  Check that device-mapper is available in the kernel.
  Incompatible libdevmapper 1.02.137 (2016-11-30) and kernel driver (unknown 
version).
  Command failed


Interestingly, the same output is in the passing cryptsetup piupart run
(https://piuparts.debian.org/sid/pass/cryptsetup_2:1.7.3-4.log), but I cannot
see anything else failing so I'm hoping you can take a look and see if you
know why this would cause a failure on an unrelated package.

Thanks a lot!
Alberto

Bug#869807: qemu: [regression] unknown CPU feature __kvm_hv_spinlocks after upgrade to +deb9u1

[Christian Seiler]

Hi,

On 08/02/2017 11:58 PM, Christian Seiler wrote:
>  - first of all I'll try to upgrade qemu and then reboot
>the entire system before restarting the VM (to make sure
>it's not some caching issue you mentioned)

Rebooting after upgrading qemu doesn't change anything.

>  - recompile both 1:2.8+dfsg-6 and 1:2.8+dfsg-6+deb9u1
>in a clean Stretch build environment and see if I can
>reproduce the issue with self-built packages

I've recompiled both 1:2.8+dfsg-6 and 1:2.8+dfsg-6+deb9u1 in a
clean stretch sbuild environment (I can provide sbuild logs if
necessary) and I get the same results:

 - the version without +deb9u1 works

 - the version with +deb9u1 has precisely this bug

This is really weird. I even debdiff'd the source packages (to
see if perhaps the uploaded package didn't correspond to the
git repo, but the source package in the archive is fine) - and
I really don't understand it: nothing in the debdiff touches
any file that has to do with CPU features, as far as I can
tell...

Any ideas? My guess would be to selectively enable different
patches in debian/patches/series and try to figure out which
once of these actually causes the issue. (Could take me a
while though.) Or do you have any better suggestions?

Regards,
Christian

Bug#504027: Provide a generic "copy to chroot" functionality instead?

[Kevin Locke]

On Sun, 2011-02-20 at 21:25 +0100, Loïc Minier wrote:
> [...]
> 
>  Perhaps a sensible approach would be for the init script to:
>  * support all config options which are set by default or via debconf as
>it does not -- including etc/hosts, resolv.conf etc.
>  * also always copy the whole of etc/postfix over into the chroot
>  * provide a mean to copy additional files

I second the request for a means of copying additional files into the
chroot.  The Red Hat package runs /etc/postfix/chroot-update for this
purpose.  Perhaps /usr/lib/postfix/configure-instance.sh could call
/etc/postfix/chroot-update, if it exists, as a hook for admins to make
local chroot changes?

Thanks for considering,
Kevin

P.S.  My current use case is that pgsql tables appear to require (a
subset of) /etc/passwd to be present in the chroot when using peer
auth via UNIX domain socket.  When not present, it causes table
lookups to fail with errors such as the following:

postfix/trivial-rewrite[19003]: warning: connect to pgsql server
unix:/var/run/postgresql: could not look up local user ID 111: No such
file or directory?

This use seems niche enough that it wasn't worth supporting
out-of-the-box.  If you disagree, I can file a separate bug for it.

-- 
Cheers,  |  ke...@kevinlocke.name| XMPP: ke...@kevinlocke.name
Kevin|  https://kevinlocke.name  | IRC:   kevinoid on freenode

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
>...
> What I don't understand in the point of view of the "keep Uploaders"
> proponents: What does this information, whether correct or not,
> actually give others? Are they going to email or phone these persons
> privately when emails to the BTS or the maintainer/team list are
> ignored? And what happens if they ignore these communications as
> well?
>...

https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5

These "Updating the  Uploaders list" bugs.

When the MIA team has determined that a person is MIA,[1]
it can send bugs informing all packages where that person
is listed in Uploaders that the person is no longer active.

For small teams (e.g. 2 people in a team maintaining 1 package)
this is also a way for seeing when 0 team members are left who
are still active in Debian.

> Cheers,
> gregor

cu
Adrian

[1] or retired, all this is about what happens after it has been
determined that a person is no longer active in Debian

-- 

   "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#870664: hkl: build-depends on obsolete emacs24

[Sean Whitton]

On Thu, Aug 03, 2017 at 05:51:15PM -0400, Sean Whitton wrote:
> I have prepared an NMU of your package and will momentarily upload it to
> DELAYED/5.

I can't NMU thanks to #868481.  Hope you can fix this bug yourself!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870672: cdimage.debian.org: Cannot install packages from update DVD for Stretch 9.1.0

[Nicholas Dreyer]

Package: cdimage.debian.org
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Tried to upgrade to 9.1.0 from basic 9.0.0 instalation using the 9.1.0 update 
DVD

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Built iso image, then burnt it to a DVD using jigdo information from here:
  
http://cdimage.debian.org/debian-cd/current/i386/jigdo-dvd/debian-update-9.1.0-i386-DVD-1.jigdo
Ran "apt-cdrom add /dev/cdrom" on the DVD
Ran "apt-get update"
Ran "apt-get upgrade"

   * What was the outcome of this action?
/etc/apt/sources.list got new source line:
deb cdrom:[Debian GNU/Linux 9.1.0 Update DVD 20170722: i386 DVD 1]/ stretch 
contrib main non-free

Package instalation for every file selected for upgrade failed with message 
such as
Err:0 cdrom://[Debian GNU/Linux 9.1.0 Update DVD 20170722: i386 DVD 1] 
stretch/main i386 base-files i386 9.9+deb9u1
  Insufficient information available to perform this download securely
  Hashes of expected file:
   - MD5Sum:47bf7b3f66c3f43f733724ec07ad4a26 [weak]
   - Filesize:67180 [weak]

A more extensive description of actions taken and resulting outcomes can be 
found here:
http://forums.debian.net/viewtopic.php?f=17=134131

   * What outcome did you expect instead?
Package installation to work


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

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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Clint Adams]

On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> What I don't understand in the point of view of the "keep Uploaders"
> proponents: What does this information, whether correct or not,
> actually give others? Are they going to email or phone these persons
> privately when emails to the BTS or the maintainer/team list are
> ignored? And what happens if they ignore these communications as
> well?

I agree.  This information is useless, and even if it's not, the source
package is entirely the wrong place for it.  Let's get rid of the
Uploaders field entirely.

Bug#787647: optipng: opng_reduce_palette_bits: Assertion `src_bit_depth == dest_bit_depth' failed

[Daniel Stender]

This has been found out [1] coming from a bug in libpng older than 1.6.19, 
1.5.24, 1.4.17, 1.2.54 and
1.0.64 (CVE-2015-8126).

DS

[1] 
https://sourceforge.net/p/png-mng/mailman/png-mng-implement/thread/CA%2BPdXcuhLXJ89s6qjOEcm%2B99eWLmPBFcYSwcwJkajkLrNRLTeQ%40mail.gmail.com/#msg34581085

-- 
4096R/DF5182C8 (sten...@debian.org)
http://www.danielstender.com/

Bug#870671: urweb: diff for NMU version 20170720+dfsg-1.1

[Sean Whitton]

Control: tags 870671 + patch
Control: tags 870671 + pending

Dear maintainer,

I've prepared an NMU for urweb (versioned as 20170720+dfsg-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I should delay
it longer.

Regards.

-- 
Sean Whitton
diff -Nru urweb-20170720+dfsg/debian/changelog urweb-20170720+dfsg/debian/changelog
--- urweb-20170720+dfsg/debian/changelog	2017-07-23 09:50:04.0 -0400
+++ urweb-20170720+dfsg/debian/changelog	2017-08-03 18:54:05.0 -0400
@@ -1,3 +1,10 @@
+urweb (20170720+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump build-dep emacs24 -> emacs25 (Closes: #870671).
+
+ -- Sean Whitton   Thu, 03 Aug 2017 18:54:05 -0400
+
 urweb (20170720+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru urweb-20170720+dfsg/debian/control urweb-20170720+dfsg/debian/control
--- urweb-20170720+dfsg/debian/control	2017-07-23 09:43:46.0 -0400
+++ urweb-20170720+dfsg/debian/control	2017-08-03 18:20:11.0 -0400
@@ -14,7 +14,7 @@
  sqlite3,
  uthash-dev
 Build-Depends-Indep:
- emacs24 | emacsen,
+ emacs25 | emacsen,
  texlive-fonts-recommended,
  texlive-latex-extra
 Standards-Version: 4.0.0


signature.asc
Description: PGP signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Holger Levsen]

On Thu, Aug 03, 2017 at 06:04:17PM -0400, gregor herrmann wrote:
> On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:
> […]
> Thanks for putting my thoughts (again!) into better words than I ever
> could!

+1
  
> > (I am entirely in favor of giving the MIA team more actual power.)
> (Me too. And, tangential to this discussion but still: maybe also to
> packaging teams, like for salvaging un(der)-maintained packages.)

agreed as well.

Then, Tobias has a point, knowing which team members uploaded a package is
useful. So I have a simple proposal to achieve that: make tracker.d.o
show the last 10 uploaders for a given package (based on UDD), just like it
parses the Uploaders: field from the packages now.

And probably some pages where all uploading team members of given teams are
shown.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:36:04PM -0400, Sean Whitton wrote:
> On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> > Please be more thoughtful about the consequences of such changes to policy.
> > 
> > This would not be "a purely informative change".
> > 
> > Your suggested wording has the potential to create a HUGE amount of 
> > tensions.
> 
> You're right.  After sending my patch I realised that it contains the
> word "should", which is a magic word in policy, imposing a normative
> requirement.  This was not intended.
> 
> My intended meaning: it is already best practice that *other team
> members* should orphan a package if they know that no-one in the team is
> actively taking care of it *according to their judgement of 'actively'*.
> 
> Would you agree that this is already established best practice?
>...

That completely misses the problem.

If the team has remaining members, and one of these members knows that 
no-one in the team is actively taking care of a package, then what
happens afterwards is obvious.

Finding unmaintained packages is the hard part.

In a bigger team maintaining 500 packages it is a non-trivial amount of 
extra work searching for packages no-one inside the team is actively 
taking care of.

In a small team with 2 members maintaining 1 package, what you write 
obviously cannot work when the last team member becomes MIA.

With Uploaders you are able to see when all uploaders are retired/MIA,
either inside the team or from outside when the team has no active 
members left.

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#851066: Workaround: flashplugin-nonfree: Mismatch between detected and available versions (Download file not available at people.debian.org)

[Michel]

Package: flashplugin-nonfree
Version: 1:3.7
Followup-For: Bug #851066

Would like to Thank everyone for their comments on this issue.
Especially James Wagner[0] and Ben Caradoc-Davies[1] for sharing their
steps for manually updating flash.

[0]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851066#30

[1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851066#53


Thank You,
Michel

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Thu, 03 Aug 2017 21:25:32 +0200, Christian Seiler wrote:

Thanks for your long and elaborate email.
Unfortunately I find myself disagreeing with your two main points:

> I wonder whether we are framing this in the right way anyway. There
> are two orthogonal questions in my mind:
>  - is a specific person MIA?
>  - is a package still maintained?

Ack, separating these questions makes sense to me.
 
> On the other hand you could have a package that has
> Maintainer: some team and Uploaders: some person, where "some
> person" is actually MIA, but the rest of the team is still actively
> maintaining the package.

Right, I think that's the situation that the proponents of this
change have in mind.
 
> The main problem I see with Uploaders: is that it's often not really
> up to date. So I do think that it might be a good idea to track the
> people who are responsible for a package outside of the package
> itself in some kind of central database that is not tied to package
> uploads. […] So I don't think the Uploaders:
> field in a package is useless, I just think the current way of
> storing that information is not the best way to do so. But until
> such a central database is ready for usage, I don't think it would
> be wise to drop Uploaders: at the moment, because otherwise that
> information can't be tracked at all.

Here I disagree: This database would just shift the outdated
information to another place; and more generally: I fail to see which
problem it solves.

I guess this is the general difference in perception we have in this
discussion: Some people start from the idea of "responsibility of a
human for a team package" while others are happy and have good
experiences in teams where all (or enough) members take
responsibility for the team packages and feel that a "dedicated human
responsible" doesn't make sense in their workflow.

What I don't understand in the point of view of the "keep Uploaders"
proponents: What does this information, whether correct or not,
actually give others? Are they going to email or phone these persons
privately when emails to the BTS or the maintainer/team list are
ignored? And what happens if they ignore these communications as
well?
 
> To help with the question of whether a package is still being
> actively maintained, let me frame it in this way: I think it is
> not completely unreasonable to say that _most_ packages will be
> updated at least once every 12 months in sid or experimental. (The
> precise number is subject to bikeshedding.) Of course that's not
> true for every package, there are some packages which don't require
> updates that often. So what one could do is the following: a
> package is considered to be actively maintained if a maintainer (or
> team) upload has happened in the last 12 months. (NMUs don't count.)
> If that is not the case, after 12 months an email is automatically
> sent to the maintainer/uploaders to ask whether they are still
> actively maintaining the package. 

I'm sorry but this feels like loads of paperwork for active teams
with tons of package which might not need an upload each $months.

I mean, in the worst case we could script the replies to the pings but
I'd rather not go there :)


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:

> Tobias Frost  writes:
> > Some time ago I did some spring cleaning going over DDs that have
> > retired but still in the Maintainer/Uploader fields: There were quite a
> > lot "team maintained" packages where the team did not recognize that the
> > (sole) Uploader wasn't there anymore and the packages were
> > bitrotting. Without the Uploader field there would have been excactly
> > zero change to find those packages and get them back into maintainance
> > again.
> I'm dubious about this assertion and would like to dig into it a bit more.

[…]

Thanks for putting my thoughts (again!) into better words than I ever
could!
 
> (I am entirely in favor of giving the MIA team more actual power.)

(Me too. And, tangential to this discussion but still: maybe also to
packaging teams, like for salvaging un(der)-maintained packages.)


Cheers,
gregor 

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


signature.asc
Description: Digital Signature

Bug#870670: RM: icicles -- RoQA; Orphaned, popcon 58, 4 years out of date, soon to FTBFS

[David Bremner]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This package will soon FTBFS when emacs24 is removed from
unstable. After consulting with Seb (the maintainer up to Jan. 2016),
it seems like the best thing is remove the package from unstable.

- - it has a popcon of 58
- - it is 4 years out of date
- - according to the previous maintainer, better alternatives exist.
- - orphan bug is #809641


-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlmDoa0ACgkQ8gKXHaSn
niwl7Qv/fZBRcNHWRrRlw+ZPEH5YRoZR/QGVJjESPRH9F9VCSBADjEyCkT7/OCVx
dhcGu0gNxr224A3pRnFEm4hAa1tUHz+rv3p2YW90oCDxjJwUhDiEpbwjoK5oiFg+
w4g7MP4vvzKNYYFr9E5q5WOhP8YnVj+vLraMq2nbAWXx3FBwFyQVn/+dVVLlqcBz
emZvhF0xt65QRS5DBMAc3Y2beGZGvrsAi/R8q23JBAnQYPO8WCJ5eYWl3S+oOoRv
imrcKUkpvmUOayIew3kR8spmJBfCa/+PbPkL/D/BJrFkUuzBMKiULu7JN2E61zfT
5O6XVgVcfKVukOgRS4yFCMxcc/DdSlhTGlBiRpuSSsaV7sEaUtUvE9kUCWJND9tp
ugdHWM3pRYsHtqUktyvVJSjZ2Y2X4a2s3ZTwEpRp0AL6v2OPtk0zbg8eSVTYgdBl
g2+jTWgAwJY97iX0VsrzkBJ5hwJNlwJoHYM9xb+BvKgUhPmlmPyfw5uv1rQKcgZq
jpj/d4EA
=TVqj
-END PGP SIGNATURE-

Bug#870671: urweb: build-depends on obsolete emacs24

[Sean Whitton]

Source: urweb
Version: 20170720+dfsg-1
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs24-removal

Dear maintainer,

Your package has a dependency and/or build dependency on emacs24, which will
shortly be removed from the archive.  Please update the package to depend on
emacs25 instead.

I have prepared an NMU of your package and will momentarily upload it to
DELAYED/5.  Please let me know if I should delay it further.  An nmudiff will
follow-up this bug.

If this package need not build for xemacs, please also consider transitioning
the package to build using dh-elpa.  This will also avoid future bugs like this
one, since the Emacs major version is updated once, centrally, in dh-elpa.

Once the emacs24 removal process starts, this bug will be upgraded to RC
severity.

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870635: mutt package is not using the official mutt tarball

[Antonio Radici]

On Thu, Aug 03, 2017 at 09:33:09AM -0700, Kevin McCarthy wrote:
> Package: mutt
> Version: 1.8.3+neomutt20170609-2
> Severity: serious
> Justification: Policy 2.3
> 
> Dear Maintainer,
> 
> I am the upstream project maintainer of Mutt.  Your version of the
> "mutt" package in unstable and testing is based on the NeoMutt
> tarball, not the official Mutt 1.8.3 release tarball.
> 
> If you wish to call your package "mutt", then you should be using the
> official Mutt release tarball are your "orig" tarball for the package.
> To do anything else is an unacceptable ethical and legal breach by
> Debian.
> 
> You have been aware of this issue since at least June 30th, see
> . As Erik
> Christiansen mentioned in that thread, while the GPLv2:
> 
>   "permits derivative works, it does not permit a derivative work to
>purport to be the copyrighted original work. Misrepresenting the
>"debneomutt" work as "mutt" would seem to clearly contravene the
>asserted and enforcible licence."
> 
> Even if the legal argument is not airtight, doing this is insulting
> and disrepectful to the Mutt project and to me as its maintainer.
> 
> Please correct this issue ASAP.

Hi Kevin,
as I said on the original thread I'm planning to fix this, and as you can see
there have been no new releases until the fix is in place.

As I stated already this is not going to be fixed for the existing stable
distribution (because we cannot change what was already shipped), but this is
certainly going to be fixed for the current unstable/testing.

I would expect this to be done in August, it is a slight delay from what we
discussed on a mailing list but nothing has changed from my plans.

Bug#870667: t-code: diff for NMU version 2:2.3.1-4.1

[Sean Whitton]

Control: tags 870667 + patch
Control: tags 870667 + pending

Dear maintainer,

I've prepared an NMU for t-code (versioned as 2:2.3.1-4.1) and uploaded
it to DELAYED/5. Please feel free to tell me if I should delay it
longer.

Regards.

-- 
Sean Whitton
diff -Nru t-code-2.3.1/debian/changelog t-code-2.3.1/debian/changelog
--- t-code-2.3.1/debian/changelog	2016-07-31 01:30:51.0 -0400
+++ t-code-2.3.1/debian/changelog	2017-08-03 18:14:40.0 -0400
@@ -1,3 +1,10 @@
+t-code (2:2.3.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump {build-,}deps emacs24 -> emacs25 (Closes: #870667).
+
+ -- Sean Whitton   Thu, 03 Aug 2017 18:14:40 -0400
+
 t-code (2:2.3.1-4) unstable; urgency=medium
 
   * debian/control
diff -Nru t-code-2.3.1/debian/control t-code-2.3.1/debian/control
--- t-code-2.3.1/debian/control	2016-07-31 01:29:15.0 -0400
+++ t-code-2.3.1/debian/control	2017-08-03 18:05:02.0 -0400
@@ -4,7 +4,7 @@
 Maintainer: HIGUCHI Daisuke (VDR dai) 
 Standards-Version: 3.9.8
 Build-Depends: debhelper (>= 9), dh-autoreconf
-Build-Depends-Indep: emacs24 | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
+Build-Depends-Indep: emacs25 | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
 Homepage: http://openlab.jp/tcode/
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/t-code.git
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/t-code.git
@@ -13,7 +13,7 @@
 Architecture: all
 Pre-Depends: dpkg (>= 1.17.5)
 Depends: ${misc:Depends}, t-code-common (= ${source:Version}),
-	emacs24 | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
+	emacs25 | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
 Description: Japanese direct input method environment for emacsen
  This package is provides tc2. the T-Code input environment for emacsen,
  which enables you to input Japanese characters with T-Code or TUT-Code.


signature.asc
Description: PGP signature

Bug#870657: [Pkg-octave-devel] Bug#870657: octave: drop unused Build-Depends: libftgl-dev

[Rafael Laboissière]

* Mike Miller  [2017-08-03 14:30]:


Successful build confirmed, no problems here.

Updated change with bug number attached.


Go ahead and push your commit to the central repository.  I guess you 
have the appropriate access rights.


Rafael

Bug#870669: libidn: Make source package bootstrappable

[Daniel Schepler]

Source: libidn
Version: 1.33-1
Severity: wishlist

Currently, the libidn source package is involved in build dependency
cycles such as:

libidn Build-Depends on gcj-jdk
gcj-jdk Depends on gcj-6-jdk
gcc-6 Build-Depends on libgtk2.0-dev
gtk+2.0 Build-Depends on libcups2-dev
cups Build-Depends on ghostscript
ghostscript Build-Depends on libidn11-dev

It would be nice if the Build-Depends on gcj-jdk could be moved to
Build-Depends-Indep.  (I did recently see notifications that gcj will
be going away in Debian soon.  But even if you switch over to using
default-jdk, that would still create a build dependency cycle since
openjdk-8 Build-Depends on libcups2-dev also.)
-- 
Daniel Schepler

Bug#870668: handbrake: Could this be "Architecture: any"?

[Edmund Grimley Evans]

Source: handbrake
Version: 1.0.7+ds1-2
User: debian-...@lists.debian.org
Usertag: arm64

Could this be "Architecture: any"? It seems to build on arm64.

Bug#870667: t-code: {build-,}depends on obsolete emacs24

[Sean Whitton]

Source: t-code
Version: 2:2.3.1-4
Severity: important



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870666: libxfcegui4 FTBFS: ./configure: line 13746: syntax error near unexpected token `am'

[Helmut Grohne]

Source: libxfcegui4
Version: 4.10.0-3
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

libxfcegui4 fails to build from source in sid amd64:

| checking whether environ is declared... yes
| ./configure: line 13746: syntax error near unexpected token `am'
| ./configure: line 13746: `XDT_I18N(am ar ast be bn_IN ca cs cy da de dz el 
en_GB eo es et eu fa fi fr gl gu he hr hu hy id is it ja ka kk ko ku lt lv mk 
mr nb nl nn pa pl pt_BR pt ro ru si sk sq sv ta te tl_PH tr ug uk ur_PK ur 
zh_CN zh_TW )'
|   tail -v -n \+0 config.log
| ==> config.log <==
...
| configure: exit 2
| dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking --disable-silent-rules returned exit code 2
| debian/rules:13: recipe for target 'override_dh_auto_configure' failed
| make[1]: *** [override_dh_auto_configure] Error 2
| make[1]: Leaving directory '/<>'
| debian/rules:7: recipe for target 'build-arch' failed
| make: *** [build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Helmut

Bug#870663: acl2: {build-,}depends on obsolete emacs24

[Sean Whitton]

On Thu, Aug 03, 2017 at 05:31:03PM -0400, Sean Whitton wrote:
> I have prepared an NMU of your package, transitioning it to use dh-elpa, and
> will momentarily upload it to DELAYED/5.

s/transitioning it to use dh-elpa, //

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870664: hkl: build-depends on obsolete emacs24

[Sean Whitton]

Source: hkl
Version: 5.0.0.2173-2
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs24-removal

Dear maintainer,

Your package has a dependency and/or build dependency on emacs24, which will
shortly be removed from the archive.  Please update the package to depend on
emacs25 instead.

I have prepared an NMU of your package and will momentarily upload it to
DELAYED/5.  Please let me know if I should delay it further.  An nmudiff will
follow-up this bug.

If this package need not build for xemacs, please also consider transitioning
the package to build using dh-elpa.  This will also avoid future bugs like this
one, since the Emacs major version is updated once, centrally, in dh-elpa.

Once the emacs24 removal process starts, this bug will be upgraded to RC
severity.

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870665: shim-signed: [INTL:pt] Updated Portuguese translation for debconf messages

[Traduz - DebianPT]

Package: shim-signed
Version: 1.28
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for shim-signed's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org









# Copyright (C) 2017 THE shim-signed'S COPYRIGHT HOLDER
# This file is distributed under the same license as the shim-signed package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: shim-signed 1.28\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2017-04-15 14:30+\n"
"PO-Revision-Date: 2017-08-03 22:49+0100\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: text
#. Description
#: ../templates:1001
msgid "Configuring Secure Boot"
msgstr "A configurar o Secure Boot"

#. Type: error
#. Description
#: ../templates:2001
msgid "Invalid password"
msgstr "Palavra-chave inválida"

#. Type: error
#. Description
#: ../templates:2001
msgid ""
"The Secure Boot key you've entered is not valid. The password used must be "
"between 8 and 16 characters."
msgstr ""
"A chave do Secure Boot que introduziu não é válida. A palavra-chave deve "
"conter entre 8 a 16 caracteres."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Disable UEFI Secure Boot?"
msgstr "Desactivar o Secure Boot?"

#. Type: boolean
#. Description
#. Type: note
#. Description
#: ../templates:3001 ../templates:5001
msgid ""
"If Secure Boot remains enabled on your system, your system may still boot "
"but any hardware that requires third-party drivers to work correctly may not "
"be usable."
msgstr ""
"Se o Secure Boot persistir no seu sistema, poderá arrancar na mesma mas "
"qualquer hardware que necessite de drivers de terceiros poderá não funcionar."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Enable UEFI Secure Boot?"
msgstr "Activar o Secure Boot UEFI?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"If Secure Boot is enabled on your system, your system may still boot but any "
"hardware that requires third-party drivers to work correctly may not be "
"usable."
msgstr ""
"Se o Secure Boot estiver activo no seu sistema, poderá arrancar na mesma mas "
"qualquer hardware que necessite de drivers de terceiros poderá não funcionar."

#. Type: note
#. Description
#: ../templates:5001
msgid "Your system has UEFI Secure Boot enabled."
msgstr "O seu sistema possui o Secure Boot activo."

#. Type: note
#. Description
#: ../templates:5001
msgid "UEFI Secure Boot is not compatible with the use of third-party drivers."
msgstr "O Secure Boot UEFI não é compatível com o uso drivers de terceiros."

#. Type: note
#. Description
#: ../templates:5001
msgid ""
"The system will assist you in toggling UEFI Secure Boot. To ensure that this "
"change is being made by you as an authorized user, and not by an attacker, "
"you must choose a password now and then use the same password after reboot "
"to confirm the change."
msgstr ""
"O sistema irá auxiliá-lo a comutar para o Secure Boot UEFI. Para garantir "
"que esta modificação é efectuada por um utilizador autorizado e não por um "
"atacante, deverá escolher uma palavra-chave neste momento e então usar a "
"palavra-chave a seguir ao arranque para confirmar a alteração."

#. Type: note
#. Description
#: ../templates:5001
msgid ""
"If you choose to proceed but do not confirm the password upon reboot, Ubuntu "
"will still be able to boot on your system but the Secure Boot state will not "
"be changed."
msgstr ""
"Se escolher continuar sem definir a palavra-chave após o arranque, o sistema "
"será capaz de arrancar na mesma mas o Secure Boot não será modificado."

#. Type: string
#. Description
#: ../templates:6001
msgid ""
"Enter a password for Secure Boot. It will be asked again after a reboot."
msgstr ""
"Introduza a palavra-chave para o Secure Boot. Ser-lhe-á pedida de novo após "
"o arranque."

#. Type: string
#. Description
#: ../templates:7001
msgid "Enter the same password again to verify you have typed it correctly."
msgstr ""
"Introduza a palavra-chave de novo para verificar que a introduziu "
"correctamente."

#. Type: error
#. Description
#: ../templates:8001
msgid "Password input error"
msgstr "Erro na introdução da palavra-chave"

#. Type: error
#. Description
#: ../templates:8001
msgid "The two passwords you entered were not the same. Please try again."
msgstr ""
"As duas palavras-chave que introduziu não são idênticas. Por favor tente de "
"novo."

Bug#870641: [Pkg-xfce-devel] Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[G. Milde]

On  3.08.17, Yves-Alexis Perez wrote:
> On Thu, 2017-08-03 at 19:36 +0200, G. Milde wrote:
> > I use xfce on an eeepc laptop. It's configured to hibernate (Bereitschaft)
> > when the lid closes using xfce4-power-manager.

> Which graphic card and driver do you use?

lspci says:

Intel Corporation Atom Processor D2xxx/N2xxx Integrated Grphics Controller
(rev 09)

the driver is xserver-xorg-video-intel


After some more tests, I have to correct the "error description", though.

The following holds with both screen-lockers: xscreensaver and
light-locker:

* hibernation via the eee "sleep-key" (Fn-F1) works:
  the screen is not locked.
  
* locking the screen via the xfce action button works:
  the screen is unlocked via lightdm or xscreensaver dialogue.
  
* closing/opening the lid works when setting "turn off screen" as action.

* closing/opening the lid results in a black screen and locked
  xwindows session when setting "hibernate" as action.
  
  
So it seems rather to be a problem of xfce4-power-manager or its dependencies
in case there is a combination of hibernation and screen-lock.

Thank you for the fast response.

Günter Milde

Bug#835520: Seconding nine patches & seeking seconds for two more

[Sean Whitton]

On Thu, Aug 03, 2017 at 10:31:43PM +0200, Andreas Henriksson wrote:
> What I tried to do was to update the description to "current" *sysvinit*
> standards. (Where "current" means several releases ago. Don't remember
> when we made insserv/startpar non-optional in Debian but it was
> definitely pre-jessie.)
> While at it I also tried to make it more init system agnostic.
> 
> In other words I tried to focus on what the (original) bug title was:
> getting rid of the harmful parts.
> 
> There was no focus on systemd really, but unfortunately it ended up
> unavoidable to mention anyway.
> 
> 
> It's absolutely not to be considered to be up to speed with systemd!
> Debian policy IMHO needs alot of work still to catch up with the current
> systemd best practises. I think another (or several) bug reports should
> be opened if you really intend to undertake documenting (debians
> interactions with) systemd.

Agreed.  After applying the patches I realised that there is plenty more
work to be done, but I had lost track of exactly what your intention
was.

I've changed it to: "Make section 9 agnostic between Debian's init
systems"

Please feel free to improve on this, and thank you very much for your
patches.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870659: pu: package irssi/1.0.2-1+deb9u2

[Adam D. Barratt]

Control: tags -1 + stretch moreinfo

On Thu, 2017-08-03 at 22:13 +0200, Rhonda D'Vine wrote:
>  for fixing #867598 in stable I prepared a 1.0.2-1+deb9u2 update for
> irssi.  Please find the debdiff attached.

Apparently not. :)

Regards,

Adam

Bug#786707: bug#27933: emacs25: default info dir initialization slow with remote filesystems

[Glenn Morris]

Eli Zaretskii wrote:

>> Info-default-directory-list, which is the thing that stats the
>> filesystem, is autoloaded.
>
> But who loads it?

Autoloaded variables are dumped with Emacs.

Bug#870659: pu: package irssi/1.0.2-1+deb9u2

[Rhonda D'Vine]

* Adam D. Barratt  [2017-08-03 23:34:18 CEST]:
> Control: tags -1 + stretch moreinfo
> 
> On Thu, 2017-08-03 at 22:13 +0200, Rhonda D'Vine wrote:
> >  for fixing #867598 in stable I prepared a 1.0.2-1+deb9u2 update for
> > irssi.  Please find the debdiff attached.
> 
> Apparently not. :)

 Darn.  I really need more caffein, but people won't bring it to me in
the Garden. :)

 Find it attached this time, for sure.
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|
diff -Nru irssi-1.0.2/debian/changelog irssi-1.0.2/debian/changelog
--- irssi-1.0.2/debian/changelog	2017-06-17 09:21:44.0 -0400
+++ irssi-1.0.2/debian/changelog	2017-08-03 15:59:51.0 -0400
@@ -1,3 +1,11 @@
+irssi (1.0.2-1+deb9u2) stretch; urgency=high
+
+  * Security related update pulling upstream 5e26325317 (closes: 867598):
+- Fix null pointer dereference (CVE-2017-10965)
+- Fix use-after-free condition for nicklist (CVE-2017-10966)
+
+ -- Rhonda D'Vine   Thu, 03 Aug 2017 15:59:51 -0400
+
 irssi (1.0.2-1+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru irssi-1.0.2/debian/patches/28Fix-use-after-free-and-null-pointer-dereference.patch irssi-1.0.2/debian/patches/28Fix-use-after-free-and-null-pointer-dereference.patch
--- irssi-1.0.2/debian/patches/28Fix-use-after-free-and-null-pointer-dereference.patch	1969-12-31 19:00:00.0 -0500
+++ irssi-1.0.2/debian/patches/28Fix-use-after-free-and-null-pointer-dereference.patch	2017-08-03 15:59:51.0 -0400
@@ -0,0 +1,72 @@
+From 29ebac987da1da2c892aed5ed329256b7bc94bca Mon Sep 17 00:00:00 2001
+From: Nei 
+Date: Thu, 29 Jun 2017 13:48:44 +
+Subject: [PATCH 1/2] Check return value of localtime
+
+Fixes #10
+---
+ src/core/misc.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/core/misc.c b/src/core/misc.c
+index ce49925b1..0b2d8e776 100644
+--- a/src/core/misc.c
 b/src/core/misc.c
+@@ -560,6 +560,9 @@ char *my_asctime(time_t t)
+ int len;
+ 
+ 	tm = localtime();
++	if (tm == NULL)
++	return g_strdup("???");
++
+ 	str = g_strdup(asctime(tm));
+ 
+ 	len = strlen(str);
+
+From 73b851c39c11d01199e6c040749fb20e468f6c8d Mon Sep 17 00:00:00 2001
+From: ailin-nemui 
+Date: Tue, 4 Jul 2017 16:10:55 +0200
+Subject: [PATCH 2/2] correct GHashTable usage
+
+---
+ src/core/nicklist.c | 17 ++---
+ 1 file changed, 10 insertions(+), 7 deletions(-)
+
+diff --git a/src/core/nicklist.c b/src/core/nicklist.c
+index 54dfb5fb2..0bc88ab8d 100644
+--- a/src/core/nicklist.c
 b/src/core/nicklist.c
+@@ -54,23 +54,26 @@ static void nick_hash_add(CHANNEL_REC *channel, NICK_REC *nick)
+ 
+ static void nick_hash_remove(CHANNEL_REC *channel, NICK_REC *nick)
+ {
+-	NICK_REC *list;
++	NICK_REC *list, *newlist;
+ 
+ 	list = g_hash_table_lookup(channel->nicks, nick->nick);
+ 	if (list == NULL)
+ 		return;
+ 
+-	if (list == nick || list->next == NULL) {
+-		g_hash_table_remove(channel->nicks, nick->nick);
+-		if (list->next != NULL) {
+-			g_hash_table_insert(channel->nicks, nick->next->nick,
+-	nick->next);
+-		}
++	if (list == nick) {
++		newlist = nick->next;
+ 	} else {
++		newlist = list;
+ 		while (list->next != nick)
+ 			list = list->next;
+ 		list->next = nick->next;
+ 	}
++
++	g_hash_table_remove(channel->nicks, nick->nick);
++	if (newlist != NULL) {
++		g_hash_table_insert(channel->nicks, newlist->nick,
++newlist);
++	}
+ }
+ 
+ /* Add new nick to list */
diff -Nru irssi-1.0.2/debian/patches/series irssi-1.0.2/debian/patches/series
--- irssi-1.0.2/debian/patches/series	2017-06-17 09:21:44.0 -0400
+++ irssi-1.0.2/debian/patches/series	2017-08-03 15:59:51.0 -0400
@@ -10,3 +10,4 @@
 25tls-ssl-compat-defines
 26Fix-dcc_request-where-addr-is-NULL.patch
 27Fix-oob-read-of-one-byte-in-get_file_params_count-_r.patch
+28Fix-use-after-free-and-null-pointer-dereference.patch

Bug#870663: acl2: {build-,}depends on obsolete emacs24

[Sean Whitton]

Source: acl2
Version: 7.4dfsg-3
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs24-removal

Dear maintainer,

Your package has a dependency and/or build dependency on emacs24, which will
shortly be removed from the archive.  Please update the package to depend on
emacs25 instead.

I have prepared an NMU of your package, transitioning it to use dh-elpa, and
will momentarily upload it to DELAYED/5.  Please let me know if I should delay
it further.  An nmudiff will follow-up this bug.

If this package need not build for xemacs, please also consider transitioning
the package to build using dh-elpa.  This will also avoid future bugs like this
one, since the Emacs major version is updated once, centrally, in dh-elpa.

Once the emacs24 removal process starts, this bug will be upgraded to RC
severity.

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870662: newmail misbuilds when build!=host

[Helmut Grohne]

Source: newmail
Version: 0.5-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

newmail successfully produces broken packages with build architecture
ELF objects during cross builds. After adding the host archtecture as a
prefix to the toolchain, the resulting packages contain host
architecture ELF objects. Please consider applying the attached patch.

Helmut
diff -u newmail-0.5/debian/rules newmail-0.5/debian/rules
--- newmail-0.5/debian/rules
+++ newmail-0.5/debian/rules
@@ -17,6 +17,11 @@
 #
 SHELL=/bin/bash
 
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+CC = $(DEB_HOST_GNU_TYPE)-gcc
+endif
+
 # The name and version of the source
 #
 source = $(shell grep "^Source: " debian/control|head -n 1|sed 's/Source: 
\(.*\)/\1/g')
@@ -33,11 +38,11 @@
 CFLAGS = -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
 endif
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-STRIP = -s
+STRIP = -s --strip-program=$(DEB_HOST_GNU_TYPE)-strip
 endif
 
 build:
-   $(MAKE) CFLAGS="$(CFLAGS) -fomit-frame-pointer -fno-strength-reduce"
+   $(MAKE) CC='$(CC)' CFLAGS="$(CFLAGS) -fomit-frame-pointer 
-fno-strength-reduce"
touch stamp-build
 
 clean: debclean
diff -u newmail-0.5/debian/changelog newmail-0.5/debian/changelog
--- newmail-0.5/debian/changelog
+++ newmail-0.5/debian/changelog
@@ -1,3 +1,10 @@
+newmail (0.5-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Prefix build tools with the host architecture (closes: #-1)
+
+ -- Helmut Grohne   Thu, 03 Aug 2017 23:20:23 +0200
+
 newmail (0.5-2) unstable; urgency=low
 
   * Fixed description, thanks Arnaud Guiton 
only in patch2:
unchanged:
--- newmail-0.5.orig/Makefile
+++ newmail-0.5/Makefile
@@ -30,5 +30,5 @@
rm -f newmail $(OBJS) *~
 
 install: newmail
-   install -s -o root -g root -m 755 newmail   $(prefix)/bin
+   install-o root -g root -m 755 newmail   $(prefix)/bin
install-o root -g root -m 644 newmail.1 $(prefix)/share/man/man1

Bug#870657: octave: drop unused Build-Depends: libftgl-dev

[Mike Miller]

Successful build confirmed, no problems here.

Updated change with bug number attached.

-- 
mike
From e9f204d1c39bb54ab15e37909373370230660368 Mon Sep 17 00:00:00 2001
From: Mike Miller 
Date: Thu, 3 Aug 2017 12:48:47 -0700
Subject: [PATCH] d/control: drop useless Build-Depends on libftgl-dev.

Closes: #870657
---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index 71dc16208c30..fc301f4415fa 100644
--- a/debian/control
+++ b/debian/control
@@ -23,7 +23,6 @@ Build-Depends: automake,
libfftw3-dev,
libfltk1.3-dev,
libfontconfig1-dev,
-   libftgl-dev,
libgl2ps-dev,
libglpk-dev,
libgraphicsmagick++1-dev,
-- 
2.13.2



signature.asc
Description: PGP signature

Bug#820210: asterisk: Fail to show SIP registrations

[Tzafrir Cohen]

On Wed, Apr 06, 2016 at 06:29:29PM +0300, Corcodel Marian wrote:
> Package: asterisk
> Version: 1:11.13.1~dfsg-2+b1
> Severity: normal
> 
> When run from asterisk console command
>  "sip show registry" print on console
>  "0 SIP registrations." ,durring registrations 
> running from multiple times "sip show registry"
>  working but on short period of time.

I'm not sure what you mean here.

'sip show registrations' shows remote hosts / devices registered to this
system. Were there any such registrations?

Could you please be more explicit on:

1. What you configured and did.
2. What you have expected to happen.
3. What happened in practice.

-- 
   Tzafrir Cohen
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com

Bug#868936: vlc: port to libupnp-1.8

[Marcelo Roberto Jimenez]

Committed.

Regards,
Marcelo.


On Thu, Aug 3, 2017 at 5:30 PM, Uwe Kleine-König 
wrote:

> Hello,
>
> On 07/31/2017 04:16 PM, Marcelo Roberto Jimenez wrote:
> > The request to make both libs coexist is much older. I don't have the
> > links here, but the 1.8 branch is quite old. I made it clear at the time
> > that 1.8 was untested, so I did not release it. But I do remember it was
> > present in one of the Debian releases, and I do remember making it clear
> > that there was no official 1.8 release at the time.
> >
> > Anyway, I think this naming scheme with versions is broken, so it should
> > be fixed ASAP. I will quickly accept any patch fixing it.
>
> The following changes since commit aaf757de204ff302b2763b1d8fb389
> 2fbc11e114:
>
>   Update Doxyfile (2017-07-17 16:59:07 -0300)
>
> are available in the git repository at:
>
>   git://git.kleine-koenig.org/u/uwe/pupnp.git
>
> for you to fetch changes up to 07f504c61bd9e4d93eb3d373ffc8527cafe0b9af:
>
>   Drop -1.8 prefix at various places (2017-08-03 22:25:34 +0200)
>
> 
> Uwe Kleine-König (1):
>   Drop -1.8 prefix at various places
>
>  Makefile.am|  4 ++--
>  build/vc10/libupnp.sln |  2 +-
>  configure.ac   |  2 +-
>  ixml/Makefile.am   | 14 +--
>  libupnp-1.8.pc.in => libupnp.pc.in |  6 ++---
>  libupnp.spec   | 18 +++---
>  upnp/Makefile.am   | 48
> +++---
>  upnp/sample/Makefile.am| 26 ++---
>  upnp/unittest/Makefile.am  | 10 
>  9 files changed, 65 insertions(+), 65 deletions(-)
>  rename libupnp-1.8.pc.in => libupnp.pc.in (50%)
>
> I only tested lightly, ./configure; make; still works fine, as does make
> install.
>
> Best regards
> Uwe
>
>

Bug#821392: asterisk: Astersk take exclusive control of audio device

[Tzafrir Cohen]

THanks for your report,

On Mon, Apr 18, 2016 at 03:14:49PM +0300, Corcodel Marian wrote:
> Package: asterisk
> Version: 1:11.13.1~dfsg-2+b1
> Severity: normal
> 
> Hi
>  Bigger issue is , when start asterisk server trigger and pulseaudio to start
> and pulseaudio take axclusive control of alsa device under user asterisk.
>  Please do not add to default user asterisk to group audio.
>  For solve this issue i run this command gpasswd -d asterisk audio

The alsa module has its uses. It can be handy to allow Asterisk to play
sounds to the system's speaker,

However in the common case it causes harm. Therefore in the common case
chan_alsa (as well as the other "console" channel drivers) should be
disabled. Eight disable them in the default configuration, or move them
to a different sub-package (sub-packages?).

Leaving this issue open for now.

-- 
   Tzafrir Cohen
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com

Bug#860304: [BUG 860304] flash-kernel: Incorrect installation path for dtbs

[Heinrich Schuchardt]

Hello Vagrant,

May 26th you indicated you would like to fix the problem after the
Stretch release date.

Any news so far?

Best regards

Heinrich

Bug#870661: lightdm-gtk-greeter: Pointer flicker

[Lev]

Package: lightdm-gtk-greeter
Version: 2.0.2-1
Severity: important

Dear Maintainer,


I sometimes experience pointer flickering, when the WM (xfce4) locks
the X11 session, and want to re-login. The pointer flickers, and can not
be moved, nor can I input username and password.

I can switch to a VT, and login as root and kill the gtk+ greeter, and
then I can log in to the existing session.

I have an NVIDIA videocard with the legacy driver installed.

01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [NVS 300]
(rev a2)

Any help is welcome.

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

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

Versions of packages lightdm-gtk-greeter depends on:
ii  libc6   2.24-11+deb9u1
ii  libcairo2   1.14.8-1
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglib2.0-02.50.3-2
ii  libgtk-3-0  3.22.11-1
ii  liblightdm-gobject-1-0  1.18.3-1
ii  libx11-62:1.6.4-3

Versions of packages lightdm-gtk-greeter recommends:
ii  adwaita-icon-theme [gnome-icon-theme-symbolic]  3.22.0-1+deb9u1
ii  desktop-base9.0.2
ii  gnome-icon-theme-symbolic   3.12.0-2
ii  gnome-themes-standard   3.22.2-2
ii  policykit-1 0.105-18

lightdm-gtk-greeter suggests no packages.

-- no debconf information

Bug#870660: synaptic: it's stucked !! If we select the all packages.

[Pupun Mishra]

Package: synaptic
Version: 0.84.2
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

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

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



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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.15-1
ii  libapt-inst2.0   1.4.7
ii  libapt-pkg5.01.4.7
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libept1.5.0  1.1+nmu3+b1
ii  libgcc1  1:6.3.0-18
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u2
ii  libgtk-3-0   3.22.11-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpcre2-8-0 10.22-3
ii  libstdc++6   6.3.0-18
ii  libvte-2.91-00.46.1-1
ii  libx11-6 2:1.6.4-3
ii  libxapian30  1.4.3-2
ii  policykit-1  0.105-18
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages synaptic recommends:
ii  libgtk2-perl   2:1.2499-1
ii  rarian-compat  0.8.1-6+b1
ii  xdg-utils  1.1.1-1

Versions of packages synaptic suggests:
pn  apt-xapian-index 
pn  deborphan
pn  dwww 
ii  menu 2.1.47+b1
ii  software-properties-gtk  0.96.20.2-1
ii  tasksel  3.39

-- no debconf information

Bug#856332: asterisk: useragent string contains special characters (~)

[Tzafrir Cohen]

On Mon, Feb 27, 2017 at 05:58:19PM -0500, Henning Follmann wrote:
> Package: asterisk
> Version: 1:11.13.1~dfsg-2+deb8u2
> Severity: minor
> 
> During sip registration with an upstream provider some of the added
> characters (~) caused some issues.
> Please revert useragent string back to default "Asterisk PBX" or provide
> the sample config entry in /etc/asterisk/sip.conf:
> useragent="Asterisk PBX"

For the record: if any server gets confused by such a character in the
UA string, it is probably non standard compliant. There is a simple fix
/ workaround for this, as mentioned above (set useragent in sip.conf /
pjsip.conf).

This bug will be closed in the next release but only due to the fact
that the minor issue of the sample pjsip.conf was fixed.

-- 
   Tzafrir Cohen
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com

Bug#835520: Seconding nine patches & seeking seconds for two more

[Andreas Henriksson]

Hello Sean Whitton,

On Thu, Aug 03, 2017 at 10:55:30AM -0400, Sean Whitton wrote:
> Hello,
> 
> I second all of Andreas' patches except the 5th and 8th.  I've attached
> the diff to which my second applies.
> 
> The 5th and 8th patches introduce a normative requirement to use
> debhelper.  This is a first for policy, which up to now only comments
> that using debhelper is "easiest".

This was definitely not my intention, but english is not my native
language.

My point was simply that it seemed to me like people often get
mislead by policy to think if it says update-rc.d has to be called
they interpret is as "Oh, I have to write manual maintainer script
code and directly invoke update-rc.d" when in reality debhelper
adds that automatically (and manually writter maintainer script
code should be avoided whenever possible!). 

Your new wording is likely much better, so thanks for improving it!

(Also, the reason for the patch series style submission was so you
could pick and choose the parts you liked and skip the rest.)


On another note I'd also like to take the opportunity to object
to the changelog description in
https://anonscm.debian.org/git/dbnpolicy/policy.git/commit/?id=b960e5448b3d3eca91a2bab1b0c92f91a161d022
https://anonscm.debian.org/git/dbnpolicy/policy.git/commit/?id=4a86cf0f48fb8279cacacb125e82d08ad38953b4

What I tried to do was to update the description to "current" *sysvinit*
standards. (Where "current" means several releases ago. Don't remember
when we made insserv/startpar non-optional in Debian but it was
definitely pre-jessie.)
While at it I also tried to make it more init system agnostic.

In other words I tried to focus on what the (original) bug title was:
getting rid of the harmful parts.

There was no focus on systemd really, but unfortunately it ended up
unavoidable to mention anyway.


It's absolutely not to be considered to be up to speed with systemd!
Debian policy IMHO needs alot of work still to catch up with the current
systemd best practises. I think another (or several) bug reports should
be opened if you really intend to undertake documenting (debians
interactions with) systemd.


Thanks alot for your work on policy! Happy to see things moving
forward and Russ getting some well deserved help!

Regards,
Andreas Henriksson

PS. Feel free to CC me if there's anything you find it valuable
for me to be part of the discussion.

Bug#868936: vlc: port to libupnp-1.8

[Uwe Kleine-König]

Hello,

On 07/31/2017 04:16 PM, Marcelo Roberto Jimenez wrote:
> The request to make both libs coexist is much older. I don't have the
> links here, but the 1.8 branch is quite old. I made it clear at the time
> that 1.8 was untested, so I did not release it. But I do remember it was
> present in one of the Debian releases, and I do remember making it clear
> that there was no official 1.8 release at the time.
> 
> Anyway, I think this naming scheme with versions is broken, so it should
> be fixed ASAP. I will quickly accept any patch fixing it.

The following changes since commit aaf757de204ff302b2763b1d8fb3892fbc11e114:

  Update Doxyfile (2017-07-17 16:59:07 -0300)

are available in the git repository at:

  git://git.kleine-koenig.org/u/uwe/pupnp.git

for you to fetch changes up to 07f504c61bd9e4d93eb3d373ffc8527cafe0b9af:

  Drop -1.8 prefix at various places (2017-08-03 22:25:34 +0200)


Uwe Kleine-König (1):
  Drop -1.8 prefix at various places

 Makefile.am|  4 ++--
 build/vc10/libupnp.sln |  2 +-
 configure.ac   |  2 +-
 ixml/Makefile.am   | 14 +--
 libupnp-1.8.pc.in => libupnp.pc.in |  6 ++---
 libupnp.spec   | 18 +++---
 upnp/Makefile.am   | 48
+++---
 upnp/sample/Makefile.am| 26 ++---
 upnp/unittest/Makefile.am  | 10 
 9 files changed, 65 insertions(+), 65 deletions(-)
 rename libupnp-1.8.pc.in => libupnp.pc.in (50%)

I only tested lightly, ./configure; make; still works fine, as does make
install.

Best regards
Uwe



signature.asc
Description: OpenPGP digital signature

Bug#532541: bug#27931: grep -o fails to count empty lines (Debain Bug #532541)

[Paul Eggert]

On 08/03/2017 06:28 AM, Santiago R.R. wrote:

the -o option, which is supposed to return only the matching
parts of the search, fails:


It's not failing. It's behaving as documented: -o outputs only nonempty 
matches. Otherwise, commands like 'grep -o "a*"' would output a separate 
line for each byte in the input. Although this behavior for -o is 
longstanding and is documented in the manual, it's not in the grep 
--help output so that's an oversight. I installed the attached to fix 
grep --help, and am closing the bug report on the GNU side.


Users who want to match empty lines can use 'grep "^$"', which is what 
I'd expect them to do anyway (-o would be superfluous there even if it 
included empty matches).


>From fe06a81c1fdaeda10bfdde82b43e2b18bfd1de5e Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 3 Aug 2017 13:07:01 -0700
Subject: [PATCH] doc: improve -o help

* src/grep.c (usage): Document that -o outputs only nonempty
matches (Bug#27931).
---
 src/grep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/grep.c b/src/grep.c
index 8d22aec..dd338d9 100644
--- a/src/grep.c
+++ b/src/grep.c
@@ -1949,7 +1949,7 @@ Output control:\n\
   --label=LABEL use LABEL as the standard input file name prefix\n\
 "));
   printf (_("\
-  -o, --only-matching   show only the part of a line matching PATTERN\n\
+  -o, --only-matching   show only nonempty parts of lines matching PATTERN\n\
   -q, --quiet, --silent suppress all normal output\n\
   --binary-files=TYPE   assume that binary files are TYPE;\n\
 TYPE is 'binary', 'text', or 'without-match'\n\
-- 
2.13.3

Bug#870651: fail2ban: systemd-journald support broken

[Yaroslav Halchenko]

Oh, we definitely should update Sid version of fail2ban. Thanks for the buzz, 
will do later today

Cheers
-- 
Sent from a phone which beats iPhone.

Bug#870658: wmweather FTCBFS: uses the build architecture strip

[Helmut Grohne]

Source: wmweather
Version: 2.4.6-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

wmweather fails to cross build from source, because it uses the build
architecture strip for stripping host architecture objects. After adding
a host architecture prefix to strip, it cross builds successfully.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru wmweather-2.4.6/debian/changelog 
wmweather-2.4.6/debian/changelog
--- wmweather-2.4.6/debian/changelog2016-08-07 19:53:00.0 +0200
+++ wmweather-2.4.6/debian/changelog2017-08-03 22:09:46.0 +0200
@@ -1,3 +1,10 @@
+wmweather (2.4.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use a triplet-prefixed strip, closes: #-1.
+
+ -- Helmut Grohne   Thu, 03 Aug 2017 22:09:46 +0200
+
 wmweather (2.4.6-2) unstable; urgency=low
 
   * Made build reproducible, closes: 828855. Thanks to Reiner Herrmann.
diff --minimal -Nru wmweather-2.4.6/debian/rules wmweather-2.4.6/debian/rules
--- wmweather-2.4.6/debian/rules2016-08-07 19:52:12.0 +0200
+++ wmweather-2.4.6/debian/rules2017-08-03 22:09:44.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 testdir  = test -f src/wmweather.c && test -f debian/rules
 testroot = test x`whoami` = xroot
 
@@ -44,7 +46,7 @@
 
$(MAKE) -C src install DESTDIR=$(CURDIR)/debian/wmweather
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   strip -R .comment -R .note debian/wmweather/usr/bin/wmweather
+   $(DEB_HOST_GNU_TYPE)-strip -R .comment -R .note 
debian/wmweather/usr/bin/wmweather
 endif
gzip -9n debian/wmweather/usr/share/man/man1/wmweather.1
rm -f debian/wmweather/usr/share/man/man1/wmWeather.1

Bug#870659: pu: package irssi/1.0.2-1+deb9u2

[Rhonda D'Vine]

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

Hi,

 for fixing #867598 in stable I prepared a 1.0.2-1+deb9u2 update for
irssi.  Please find the debdiff attached.

 Thanks for considering,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#870283: libjsoncpp: Make source package bootstrappable

[Peter Spiess-Knafl]

Dear Daniel!

Thank you for reporting this. I will fix it in the upcoming upload.

Greetings
Peter

On 2017-07-31 17:45, Daniel Schepler wrote:

Source: libjsoncpp
Version: 1.7.4-3
Severity: wishlist

Currently, libjsoncpp's Build-Depends on doxygen creates build
dependency cycles, such as:

doxygen Build-Depends on libclang-4.0-dev
llvm-toolchain-4.0 Build-Depends on libjsoncpp-dev

Probably the easiest way to break this cycle would be to move doxygen
to Build-Depends-Indep.

Bug#866676: Pending fixes for bugs in the libxml-libxml-perl package

[pkg-perl-maintainers]

tag 866676 + pending
thanks

Some bugs in the libxml-libxml-perl package are closed in revision
0700a409b364370343bb6aff1a1ad91e11de973e in branch 'master' by
Salvatore Bonaccorso

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libxml-libxml-perl.git/commit/?id=0700a40

Commit message:

CVE-2017-10672: Use-after-free by controlling the arguments to a 
replaceChild call

Closes: #866676