Bug#808634: cadabra in Debian

[Axel Beckert]

Hi Kasper,

Axel Beckert wrote:
> Kasper Peeters wrote:
> > > It builds then, but the test suite seems to hang at
> > > "fieldtheory" (or I have to wait for more than a few minutes there):
> > 
> > Weird, this test went through fine on a VM which I installed from
> > scratch with Debian 8.6 and then upgraded to testing.
> 
> Found the issue: The package didn't declare a build-dependency on lie.
> If lie is installed, the test works fine.

Uploaded last night. The build failed on a bunch of architectures
(arm64, armel, armhf, pppc64el, powerpc, s390x)) due to failing tests.
It was always the test fieldtheory which hang on these architectures
and was killed after reaching an timeout.

My current suspicion is that lie doesn't behave as expected on these
architectures. Haven't checked it explicitly, though.

So for now, I'll again disable that test to hopefully get it passing
the test suite on all architectures.

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

Bug#838378: ycmd: Use python3-jedi with the latest vim-youcompleteme update to have python autocompletion

[Onur Aslan]

I actually realized this issue is already well explained in README.Debian:

You can see a copy of it in: 
https://anonscm.debian.org/cgit/collab-maint/ycmd.git/tree/debian/README.Debian?h=debian/0%2b20160327%2bgitc3e6904-1


On 2016-09-20, Sandor Bodo-Merle wrote:
> Dear Maintainer,
> 
> After the latest vim-youcompleteme update (built with python3), ycmd 
> complains that no jedi support is available.
> By manually installing python3-jedi the error message is gone.

-- 
regards,
   Onur Aslan

GPG Key   : E5EF 3C2C 67BC 6F76 DAB3  A40E 7B96 C7AF EB16 673C  .''`.
Website   : https://onur.im: :'  :
Github: https://github.com/onur`. `'`
Debian QA : https://qa.debian.org/developer.php?login=o...@onur.im   `-


signature.asc
Description: Digital signature

Bug#848958: curl: CVE-2016-9586: printf floating point buffer overflow

[Salvatore Bonaccorso]

Source: curl
Version: 7.51.0-1
Severity: important
Tags: security patch upstream fixed-upstream
Control: found -1 7.38.0-4

Hi,

the following vulnerability was published for curl.

CVE-2016-9586[0]:
printf floating point buffer overflow

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9586
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9586
[1] https://curl.haxx.se/docs/adv_20161221A.html
[2] https://github.com/curl/curl/commit/3ab3c16db6a5674f53cf23d56512a405fde0b2c9

Regards,
Salvatore

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

[Sean Whitton]

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

Good idea.  This option should be ignored when --new is present.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848957: openssl: support architecture tilegx

[Helmut Grohne]

Source: openssl
Version: 1.1.0c-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

openssl has special casing for each and every Debian architecture and
thus needs to be updated whenever a new architecture is being brought
up. Thus it needs to be updated for tilegx. Please consider applying the
attached patch.

Helmut
--- a/Configurations/20-debian.conf
+++ b/Configurations/20-debian.conf
@@ -127,6 +127,9 @@
 	cflags => add("-m64 -mcpu=ultrasparc -DB_ENDIAN"),
 		bn_ops => "BN_LLONG RC4_CHAR",
 	},
+	"debian-tilegx" => {
+		inherit_from => [ "linux-generic64", "debian" ],
+	},
 	"debian-x32" => {
 		inherit_from => [ "linux-x32", "debian" ],
 	},

Bug#848956: lcov: New upstream release

[Sylvestre Ledru]

Package: lcov
Severity: wishlist

Dear Maintainer,

Version 1.13 is now live and fixes some interesting gcc related issues.

uscan and updating debian/changelog seems to be enough.

Thanks,
S

Bug#848955: lcov: Vcs-Git points to the upstream repo

[Sylvestre Ledru]

Package: lcov
Severity: minor

Dear Maintainer,

Vcs-Git points to https://github.com/linux-test-project/lcov.git
when it should be the debian repo.

This is causing debcheckout lcov to "fail".

Thanks,
S

Bug#823205: ycmd: javascript autocomplete should be disabled until node-tern is packaged

[Onur Aslan]

Thanks for reporting.

I am sorry but this is default behavior of YouCompleteMe. You can also install 
tern
manually with npm and use it with this package[1]. But even if you install tern,
ycmd will still complain about .tern-project file.


[1]: 
https://anonscm.debian.org/cgit/collab-maint/ycmd.git/tree/debian/README.Debian?h=debian/0%2b20160327%2bgitc3e6904-1


On 2016-05-02, Edward Betts wrote:
> Package: ycmd
> Version: 0+20160327+gitc3e6904-1
> Severity: normal
> 
> The ternjs module is not available in Debian, so Javascript autocomplete
> doesn't work.
> 
> Whenever I open Javascript in vim I get a RuntimeError from ycmd about a
> missing .tern-project file. 
> 
> If Javascript support were disabled in the ycmd package then this spurious
> error wouldn't be displayed.
> 
> Javascript autocomplete should be disabled until ternjs is packaged.
> -- 
> Edward.

-- 
regards,
   Onur Aslan

GPG Key   : E5EF 3C2C 67BC 6F76 DAB3  A40E 7B96 C7AF EB16 673C  .''`.
Website   : https://onur.im: :'  :
Github: https://github.com/onur`. `'`
Debian QA : https://qa.debian.org/developer.php?login=o...@onur.im   `-


signature.asc
Description: Digital signature

Bug#848789: dgit: update dgit-sponsorship(7) in light of tagging changes

[Sean Whitton]

On Wed, Dec 21, 2016 at 01:31:17AM +, Ian Jackson wrote:
> Sean Whitton writes ("Bug#848789: dgit: update dgit-sponsorship(7) in light 
> of tagging changes"):
> > Now that the debian/ tag is always generated, and placed on the branch
> > you upload from, it is a bad idea to upload from the quilt-cache dgit
> > view rather than the sponsee's view, even if you used the quilt-cache
> > view to review.  Patch attached.
> 
> I've applied the patch.  Thanks.
> 
> I haven't thought about this properly, but I wonder, though, whether
> you've considered advising people to use --no-dep14tag, instead.

I didn't know about this flag.  It could also replace the advice to ask
the sponsee to delete any tag they've created.  I'll prepare a patch
soon.  Thanks for your recent work on dgit 2.12 and 2.13!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#843612: resolved (was: Bug#843612: Info received (Bug#843612: (trash-cli: debian trash-cli segmentation faults)))

[Gijs Hillenius]

The bug is resolved when upgrading to python 2.7.13-1 

Bug#831965: Status of asciidoc upload?

[Joseph Herlant]

Hi Raphael,

Thanks a lot for the review.

> Here when I review 7a7b6fa57981a1ff081c5ec0579ce65191162c82 I don't want
> to see so many changes on debian/asciidoc.install. I want only the vim
> line dropped and see it added in the new package.

Sorry about that. I'm not able to split that commit as I can't push
with --force, so is it ok for this time? I'll try to be more careful
in the future.

> Now reviewing the split (c93478fd9be3ad2f9841df973eb7b09d312bd699) I did
> not check in details the files repartition but I noticed this:
> * epubcheck is in suggests everywhere but I guess it's not usefull for all
>   backends, it probably makes sense only in asciidoc-base.

Well, epubcheck makes sense on the packages that can actually generate
epubs which are asciidoc-dblatex and asciidoc-fop. I'll remove it from
asciidoc as it depends on asciidoc-dblatex. I don't think it needs to
be on asciidoc-base as it is not able to generate any epub format
without fop or dblatex.

> * source-highlight is also mentionned everywhere but since ascidoc-base is
>   required, it's enough to be on that package.

Right. Sorry for that. removing it from everywhere else than asciidoc-base.

> * When you split packages in a fine-grained level, you should move the
>   optional "Recommends" into a required "Depends". asciidoc-fop without
>   fop doesn't make sense, thus fop and docbook-utils should be Depends
>   and not Recommends. Same with "dblatex" and docbook-utils in
>   asciidoc-dblatex.

Good point. Changed that.
I left xmlto in the recommends as you can generate man pages without
xmlto if you use -L / --no-xmllint (This package brings dblatex, so
sometimes you just want to have a way to have asciidoc without it).
The add of this package to recommends was discussed in #692274.

> Looking at your clean target in debian/rules, you can replace it entirely
> with a "debian/clean" file (that said I wonder why some of those "rm" are
> there, what creates debian/asciidoc.1.xml, etc?).

Moved them to a debian/clean file.
Those file are created by the call to a2x -f manpage calls from the
Makefile(.in) if I recall correctly.

> Last detail, lintian reports this informational tag (on all binary packages):
> I: asciidoc-fop: debian-news-entry-uses-asterisk
> N:
> N:   The latest entry in NEWS.Debian appears to use asterisks to present
> N:   changes in a bulleted list, similar to the normal changelog syntax.
> N:   The Debian Developer's Reference recommends using regular paragraphs
> N:   in NEWS.Debian rather than a bulleted list.
> N:
> N:   Refer to Debian Developer's Reference section 6.3.4 (Supplementing
> N:   changelogs with NEWS.Debian files) for details.
> N:
> N:   Severity: wishlist, Certainty: possible
> N:
> N:   Check: changelog-file, Type: binary
> N:
>
> Can you clean up those little details quickly?

Done.

I also got rid of the following other lintian info messages:
vcs-field-not-canonical,  vcs-field-uses-insecure-uri and
duplicate-short-description.

> How long have you been using your updated packages already?

I used the -base version for about 8 months and then I reinstalled my
computer so I took the package from the distro.

I pushed the changing to the git repo and to mentors.

Thanks
Joseph

Bug#838378: ycmd: Use python3-jedi with the latest vim-youcompleteme update to have python autocompletion

[Onur Aslan]

Thanks for reporting. vim-youcompleteme is built with python2 but you can
use JediHTTP (python completer of ycmd) with both python2 and python3.
Default is python2 that's why this package is depending on python-jedi
instead of python3-jedi.

If you want to use python3 completion you have to install python3-jedi
and set g:ycm_python_binary_path to python3 in your vimrc.

IMO depending on both python-jedi and python3-jedi will cause user to install
so many unnecessary dependencies. But I think this must be explained in
README.Debian to make some clearification.


-- 
regards,
   Onur Aslan

GPG Key   : E5EF 3C2C 67BC 6F76 DAB3  A40E 7B96 C7AF EB16 673C  .''`.
Website   : https://onur.im: :'  :
Github: https://github.com/onur`. `'`
Debian QA : https://qa.debian.org/developer.php?login=o...@onur.im   `-


signature.asc
Description: Digital signature

Bug#848854: status update

[Paolo Greppi]

The repo on alioth is ready.

I'm waiting for the dependency node-file-sync-cmp
(https://bugs.debian.org/845025 to enter unstable to emit the RFS.

Paolo

Bug#848745: nipy: FTBFS: ld: cannot find -lcblas

[Adrian Bunk]

Control: retitle -1 nipy FTBFS: test failures

On Mon, Dec 19, 2016 at 10:11:08PM +0100, Lucas Nussbaum wrote:
>...
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > x86_64-linux-gnu-gcc -pthread /tmp/tmp9JlXPN/tmp/tmp9JlXPN/source.o -lcblas 
> > -o /tmp/tmp9JlXPN/a.out
> > /usr/bin/ld: cannot find -lcblas
> > collect2: error: ld returned 1 exit status
>...

The actual failures are later in the tests:

...
==
ERROR: 
nipy.algorithms.clustering.tests.test_hierarchical_clustering.cost_test
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/<>/nipy-0.4.0+git26-gf8d3149/debian/tmp/usr/lib/python2.7/dist-packages/nipy/algorithms/clustering/tests/test_hierarchical_clustering.py",
 line 152, in cost_test
u, cost =  ward_segment(G, x)
  File 
"/<>/nipy-0.4.0+git26-gf8d3149/debian/tmp/usr/lib/python2.7/dist-packages/nipy/algorithms/clustering/hierarchical_clustering.py",
 line 866, in ward_segment
t = ward(G, feature, verbose)
  File 
"/<>/nipy-0.4.0+git26-gf8d3149/debian/tmp/usr/lib/python2.7/dist-packages/nipy/algorithms/clustering/hierarchical_clustering.py",
 line 972, in ward
linc, rinc = _remap(K, i, j, k, Features, linc, rinc)
  File 
"/<>/nipy-0.4.0+git26-gf8d3149/debian/tmp/usr/lib/python2.7/dist-packages/nipy/algorithms/clustering/hierarchical_clustering.py",
 line 568, in _remap
if K.edges[l, 0] == - 1:
IndexError: only integers, slices (`:`), ellipsis (`...`), numpy.newaxis 
(`None`) and integer or boolean arrays are valid indices

==
ERROR: 
nipy.algorithms.clustering.tests.test_hierarchical_clustering.ward_test_more
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/<>/nipy-0.4.0+git26-gf8d3149/debian/tmp/usr/lib/python2.7/dist-packages/nipy/algorithms/clustering/tests/test_hierarchical_clustering.py",
 line 160, in ward_test_more
X[:np.ceil(n/3)] += 5
TypeError: slice indices must be integers or None or have an __index__ method
...


(And many more test failures.)


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#774415: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Johannes Schauer]

Quoting Holger Levsen (2016-12-21 02:08:57)
> On Wed, Dec 21, 2016 at 01:50:11AM +0100, Johannes Schauer wrote:
> > Given all these arguments, adding a --rebuild-and-verify=foo.buildinfo 
> > option
> > to sbuild sounds like the most sane thing to do. It would even not require 
> > the
> > existing interface to change (the positional argument is a single source
> > package).
> > 
> > Any thoughts?
> 
> as long as there's a short version of --rebuild-and-verify=foo.buildinfo
> such as (for example) -rb=foo.buildinfo fine with me… :)

the -r short option is still free.

> (though I'm not sure I fully understand why not assume -rb if foo.buildinfo
> is given - I do understand for foo.changes…)

 - Because I'm not so sure that the user is aware that passing a .buildinfo
   file will mean that sbuild is querying snapshot.d.n without asking the user
   for further consent.

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

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#848853: RFS: node-grunt-contrib-uglify 2.0.0

[Paolo Greppi]

Hi,

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

I had to repackage to get rid of uglyfied files part of the test suite.
Therefore I can not not run tests during build or autopkgtests ...

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

Thanks,

Paolo

Bug#848867: RFS: xalan/1.11-6

[Gianfranco Costamagna]

Hi

>>what about bumping compat/debhelper level to 10, remove autoreconf from

>>rules/control
>That's causing the build to fail for some reason. I'll look into it.
>


a quick look seems to show a progress when removing debian/autoreconf file.
http://debomatic-amd64.debian.net/distribution#unstable/xalan/1.11-6.1/buildlog

G.

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

[Christian Ehrhardt]

On Tue, Dec 20, 2016 at 5:21 PM, Yves-Alexis Perez 
wrote:

> I hope it's clearer.


Yeah that is good, I'll prep something and reply to this bug with mails
one-by-one once I'm ready.
I might update the branch I had linked if I happen to improve the changelog
and or other comments.

Will submit the reasoning later today - thanks for your guidance!

Bug#848953: gerbv: zoom in/out could do with centreing the mouse cursor

[lkcl]

Package: gerbv
Version: 2.6.0-1
Severity: wishlist
Tags: upstream

gerbv is awesome and extremely useful.  it is however a bit like driving
a fork-lift truck: the zoom feature appears to be "rear-wheel driving".

to illustrate this, try zooming in on one area (mouse-wheel) in the far
corner of the current screen.  what you *actually* want to happen
is that where you clicked, that should become the new "centre"...
*including* moving the mouse.

instead what is needed to be done is the following extremely awkward
"fork-lift-truck"-style procedure:

* zoom in on the required (corner) area to be magnified
* move the mouse into the *EXACT* symmetrical *OPPOSITE* corner
* zoom out for a bit until the area you want *happens* to be in
  the centre of the screen
* start zooming back in again

if you miss (didn't get it quite right in step three) you have to
REPEAT the above procedure until success.

this process can be *entirely* avoided... simply by having the "zoom"
location also be the new "automatically panned centre".  to avoid
ending up off-centre if further zooming is done it is necessary to
shift the actual mouse cursor as well to be in the centre of the screen,
but that's perfectly acceptable.

the proposed behaviour is used by *ALL* professional PCB CAD software
and is a much more "natural" behaviour that would greatly improve gerbv



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

Kernel: Linux 4.7.8lkcl (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gerbv depends on:
ii  libatk1.0-0 2.18.0-1
ii  libc6   2.23-4
ii  libcairo2   1.14.6-1
ii  libfontconfig1  2.11.0-6.1
ii  libfreetype62.5.2-2
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.1-1
ii  libgtk2.0-0 2.24.29-1
ii  libpango1.0-0   1.38.1-1

Versions of packages gerbv recommends:
ii  extra-xdg-menus  1.0-4

gerbv suggests no packages.

-- no debconf information

Bug#684646: fails to receive BYE over TLS

[Daniel Pocock]

On 20/12/16 23:54, Bernhard Schmidt wrote:
> Control: tags -1 +moreinfo
> 
> On Sun, Aug 12, 2012 at 12:44:18PM +, Daniel Pocock wrote:
> 
>> I am using v1.8.8.  I've also tried to use 1.8.13 (the version
>> in wheezy) to see if that resolves the problem, but 1.8.13 has
>> more severe problems that prevent testing of the same TLS
>> environment: 
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683956
>> 
>> Basically, the user agents are Polycom phones, connecting to
>> Asterisk using TLS.  A sample peer config is below.
>> 
>> The phones can connect and register.  The phones can send an SIP
>> INVITE and start a call.  However, when the phone is hung up,
>> Asterisk doesn't receive the BYE
> 
> Is this still an issue? I have never run 1.8 with SIP/TLS in
> production, but 11 seems to be fine here (with Snom and Yealink
> phones).
> 

I don't try to connect phones directly to Asterisk any more, they
always go through an edge proxy (repro) and an SBC (e.g. reConServer)

Therefore, I can't confirm if the bug is fixed or not but given the
change to PjSIP, maybe bugs like this have gone away.  Even so, I
would always recommend using the edge proxy solution, even if the bug
is fixed, that way the phones can stay connected even when Asterisk is
restarted or crashes from time to time.

Regards,

Daniel

Bug#845555: lxpanel: battery monitor no longer working

[juichenieder-debbie]

I have just upgraded lxpanel:amd64 0.8.2-1 -> 0.9.1-1 and can confirm this bug.

I hope that helps.

Bug#848952: linux-image-4.8.0-1-amd64: All USB devices unusable if a USB cable only plugged in to port

[Michael David Wilson]

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

Dear Maintainer,

I booted my Debian distribution (working fine at last boot) and the USB
keyboard and mouse did not register with the kernel. No LEDs activated and no
input could be received. I rebooted the machine several times, in all cases,
once the Debian Kernel started the peripherals died.

Kernel was outputting:
usb 3-4: device descriptor read/64, error -110
usb 3-4: new high-speed USB device number 3 using xhci_hcd
usb 3-4: device descriptor read/64, error -110
usb 3-4: device descriptor read/64, error -110
usb 3-4: new high-speed USB device number 4 using xhci_hcd
xhci_hcd :00:14.0: Timeout while waiting for setup device command
xhci_hcd :00:14.0: Timeout while waiting for setup device command
usb 3-4: device not accepting address 4, error -62

I noticed I had a USB2 Type B cable plugged into the computer, but was not
plugged into the printer. Once this was plugged back into the HP printer, and
when I did this, the Kernel recognized the USB keyboard and mouse again (see
logs below). Whilst this is not a critical bug, it would save many users a
headache as other OS have no such issues with failing to enumerate USB devices
when one cable is not plugged in.

usb 3-4: new high-speed USB device number 5 using xhci_hcd
xhci_hcd :00:14.0: Timeout while waiting for setup device command
xhci_hcd :00:14.0: Timeout while waiting for setup device command
usb 3-4: device not accepting address 5, error -62
usb usb3-port4: unable to enumerate USB device
usb 3-5: new full-speed USB device number 6 using xhci_hcd
usb 3-5: New USB device found, idVendor=1532, idProduct=0043
usb 3-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-5: Product: Razer DeathAdder Chroma
usb 3-5: Manufacturer: Razer
usb 3-10: new full-speed USB device number 7 using xhci_hcd
usb 3-10: New USB device found, idVendor=0f39, idProduct=1084
usb 3-10: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 3-10: Product: DK2108S
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
input: Razer Razer DeathAdder Chroma as
/devices/pci:00/:00:14.0/usb3/3-5/3-5:1.0/0003:1532:0043.0001/input/input20
hid-generic 0003:1532:0043.0001: input,hidraw0: USB HID v1.11 Mouse [Razer
Razer DeathAdder Chroma] on usb-:00:14.0-5/input0
input: Razer Razer DeathAdder Chroma as
/devices/pci:00/:00:14.0/usb3/3-5/3-5:1.1/0003:1532:0043.0002/input/input21
hid-generic 0003:1532:0043.0002: input,hidraw1: USB HID v1.11 Keyboard [Razer
Razer DeathAdder Chroma] on usb-:00:14.0-5/input1
input: Razer Razer DeathAdder Chroma as
/devices/pci:00/:00:14.0/usb3/3-5/3-5:1.2/0003:1532:0043.0003/input/input22
hid-generic 0003:1532:0043.0003: input,hidraw2: USB HID v1.11 Keyboard [Razer
Razer DeathAdder Chroma] on usb-:00:14.0-5/input2
input: DK2108S as
/devices/pci:00/:00:14.0/usb3/3-10/3-10:1.0/0003:0F39:1084.0004/input/input23
hid-generic 0003:0F39:1084.0004: input,hidraw3: USB HID v1.10 Keyboard
[DK2108S] on usb-:00:14.0-10/input0
input: DK2108S as
/devices/pci:00/:00:14.0/usb3/3-10/3-10:1.1/0003:0F39:1084.0005/input/input24
hid-generic 0003:0F39:1084.0005: input,hidraw4: USB HID v1.10 Device [DK2108S]
on usb-:00:14.0-10/input1
usb 3-3: new high-speed USB device number 8 using xhci_hcd
usb 3-3: New USB device found, idVendor=03f0, idProduct=2b17
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: HP LaserJet 1020
usb 3-3: Manufacturer: Hewlett-Packard
usb 3-3: SerialNumber: JL3Y1R

Thanks in advance,

Michael




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

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-1-amd64 
root=UUID=37433ec2-a5ad-42a0-b934-111cff1b8ac1 ro quiet

** Tainted: POE (12289)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:

** Model information
[   22.103724] usb 3-4: device descriptor read/64, error -110
[   22.331540] usb 3-4: new high-speed USB device number 3 using xhci_hcd
[   27.479687] usb 3-4: device descriptor read/64, error -110
[   38.609311] [UFW BLOCK] IN=wlp6s0 OUT= 
MAC=01:00:5e:00:00:01:c4:6e:1f:4b:19:df:08:00 SRC=192.168.1.1 DST=224.0.0.1 
LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 
[   43.095623] usb 3-4: device descriptor read/64, error -110
[   43.323526] usb 3-4: new high-speed USB device number 4 using xhci_hcd
[   48.351571] xhci_hcd :00:14.0: Timeout while waiting for setup device 
command
[   53.727616] xhci_hcd :00:14.0: Timeout while waiting for setup device 
command
[   53.935545] usb 3-4: device not accepting address 4, error -62
[   54.055606] usb 3-4: new high-speed USB device number 5 using xhci_hcd
[   59.103577] xhci_hcd :00:14.0: Timeout while waiting for setup device 
command
[ 

Bug#829046: Any update on pagure?

[Sergio Durigan Junior]

On Tuesday, December 20 2016, Alexandre Viau wrote:

> Hello,

Hey, Alexandre,

>> I'll see if I can continue my work tonight and let you know of any
>> progress.
>
> Any update on that?

I didn't have time to work on pagure that night.  I'll work on it
tomorrow (Wednesday).

> Should someone take over?
>
> As Praveen said, we just need a "good" package to be uploaded before the
> 25th. It can have bugs.

Right.  I'll just finish what I have here and propose it for upload,
then.  The package will have some rough edges here and there but it
should be usable.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#848239: deluser on purge

[Russ Allbery]

Dmitry Bogatov  writes:

> You are right. But what are we going to do anyway in case if user
> installs 901 different daemons? Seems that approach of system users does
> not scale at all.

Indeed.

That said, I don't think I've seen a system consume more than 50 users or
so.  In practice, there do seem to be enough users.  But that might not be
the case if we accumulate users forever and never recycle those system
UIDs.

> Just a thought: `setuid(2)' accepts uid_t, which is 32bit on my 64 bit
> system. So probably it possible to run process isolated without creating
> entry in /etc/passwd?

Hm, transient IDs is an interesting idea.  In a lot of cases, we create a
system user just to isolate the running daemon, not to control file system
access.  The drawback, though, is that one has to have a really clear idea
of what resources the process would need in order to make sure this is
safe.  (A much clearer idea than the understanding we need to know when
it's safe to delete a system user, I think.)

Using random high-numbered IDs, while appealing, probably isn't a great
idea because we allow the local admin to use that space.  It's possible
that they're doing something that's consuming millions of IDs for some
reason, so although there's a lot of space there, we can't entirely rule
out the possibility of a conflict.  Although we could probably carve out
more space if we really needed to.

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

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

[Yury V. Zaytsev]

On Tue, 20 Dec 2016, Felipe Sateler wrote:


Yes, I agree that having a partial fix is better than no fix.


I have an updated package prepared [1]. Could you please test it and 
report back if it works as intended?


Hi Felipe,

Thank you very much! I'm afraid that I'll first be able to test it in 
mid-January, since the holidays are coming and most likely I won't have 
access to any Debian machines during that period, but I'll try to test it 
as soon as I get back to work.


Merry Christmas and a Happy New Year!

--
Sincerely yours,
Yury V. Zaytsev

Bug#848951: gnupg: Utilize multiple cores on CPU for encryption and decryption (and compression)

[Witold Baryluk]

Package: gnupg
Version: 2.1.16-3
Severity: normal

Feature request.

When using gpg as invoked by duplicity, gpg is a main bottlneck. gpg is
using 100% of single CPU core, and not any more.

Utilizing more cores would speed up backups as done by duplicity, especially
full backups by a factor of 10 on modern machines.

Using cipher and compression algorithms that can utilize multiple cores
(possibly at the expense of using more memory for buffers) would help a
lot.

Thanks.

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

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

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.16-3
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.24-8
ii  libgcrypt201.7.5-2
ii  libgpg-error0  1.25-2
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-1
ii  libsqlite3-0   3.15.2-1
ii  zlib1g 1:1.2.8.dfsg-4

Versions of packages gnupg recommends:
ii  dirmngr 2.1.16-3
ii  gnupg-l10n  2.1.16-3

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

Bug#848950: /usr/bin/rdiffdir: rdiff: Compute diffs in parallel

[Witold Baryluk]

Package: duplicity
Version: 0.7.10-2
Severity: normal
File: /usr/bin/rdiffdir

Utilize multi-core CPUs and fast IO (SSDs, NVMe drives and fast network
file systems) to the full extent possible.

Even some form of parallel prefetching to file system cache would be
helpful.

Thanks.

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

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

Versions of packages duplicity depends on:
ii  libc62.24-8
ii  librsync10.9.7-10
ii  python   2.7.13-1
ii  python-lockfile  1:0.12.2-2
pn  python:any   

Versions of packages duplicity recommends:
ii  python-oauthlib  2.0.1-1
ii  python-paramiko  2.0.0-1
ii  python-urllib3   1.19.1-1
ii  rsync3.1.2-1

Versions of packages duplicity suggests:
pn  lftp
pn  ncftp   
ii  python-boto 2.44.0-1
pn  python-cloudfiles   
pn  python-gdata
ii  python-swiftclient  1:3.1.0-2
pn  tahoe-lafs  

-- no debconf information

Bug#848239: deluser on purge

[Dmitry Bogatov]

First of all, I am sorry, if my response sounded rough or impolite or
offensive or somehow demostrated negative attitude. It was not
intended. I beg your pardon.  English is not my native, and sometimes I
fail to notice differense between neutral wording and non-neutral. My
intention to convey purely technical idea.

Summary of out conversation, as I understood it:

  * You want system user and its $HOME to be removed at purge

  * You rationale it with piuparts and example of several other packages

  * I state that it would make dh-sysuser code complicated, and will
require handling unknown amount of corner cases. Failure to catch
one of them may lead to disaster,

  * I state that I do consider 'aganist' outweight 'for'

To make piuparts happy I can propose following algorithm on purge:

 * remove exactly those files in $HOME, that are same as in /etc/skel.
 * if $HOME now is empty, remove it and remove user.

[2016-12-19 08:53] Antoine Beaupré 
> I am not sure what "spirit of Debian" you are refering to. Does my
> proposal go against a specific policy item or the social contract? Is
> there a spiritual guide I have failed to read in my last decade of
> involvement?

Debian, as far as I observe, is fine with certain level of "overhead",
like linking programs with libraries like libsystemd or libaudit or
libdbus.  Maintainer gets simplicity of packaging, user gets more
dependencies and used memory. It is considered fine.

Back to our ocassion. You propose adding different features to
dh-sysuser. Some of them in my opinion has fair balance between
usefuness and complexity, like `chmod $HOME', I can't say so about
feature of removing $HOME and deleting user.

Here I am stating that I trade a little (IMHO) of user good for a lot of
my good, and that it is common practice.

> But I understand my argument is not well received so I will go back in
> my hole of mutual ignorance.

I am sorry to hear it. I hope I clarified my position well enough and I
hope that you will change your mind and we can return to technical
discussions.

PS. See next email about setsid() function.

PPS. When I use word 'state', I mean 'express my opinion', not 'state of
 world'. Arguments can change opinion.

--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpioEUYgl6Rn.pgp
Description: PGP signature

Bug#848239: deluser on purge

[Dmitry Bogatov]

[2016-12-19 09:04] Russ Allbery 
>
> part   text/plain 564
> Dmitry Bogatov  writes:
>
> > After all, leftover system user is just one extra line in /etc/passwd
> > and one more wasted UID, but we have ~32k of them.
>
> Er, no, we have 900 of them.  Maybe 1433 of them if we steal 65000-65533.
> Anywhere else will run into the UID space reserved for the local
> administrator, which would cause serious problems.
>
> Given that, I do think something like this would be a good idea if all the
> tricky implementation details can be worked out.

You are right. But what are we going to do anyway in case if user
installs 901 different daemons? Seems that approach of system users
does not scale at all.

Just a thought: `setuid(2)' accepts uid_t, which is 32bit on my 64 bit
system. So probably it possible to run process isolated without creating
entry in /etc/passwd? Here is little C program:

#include 
#include 
#include 

int
main(void)
{
printf("%d\n", (int)(sizeof(uid_t)));
setuid(10);
sleep(1000);
return 0;
}

Will it misbehave on different kernels or architectures, then x86_64 GNU/Linux?

If it is okay, then let's consider why system users are usually used? As
far as I understand, to run some process and

 - protect it from other processed
 - protect other processes from it
 - do not allow it to write files it do not need
 - do not allow it to read files it do not need

setuid(BIG_INT) is fine to solve first two tasks. About third we can do
following:

$ setuid $BIG_INT my-daemon 

Bug#848818: xterm: ctlseqs.txt is not rebuilt from ctlseq.ms

[Branden Robinson]

On Tue, Dec 20, 2016 at 9:26 AM, Thomas Dickey  wrote:
> severity 848818 wishlist
> close 848818
>
> I'm not going to discuss this further -
>
> https://www.debian.org/Bugs/Developer#severities
> http://invisible-island.net/personal/changelogs.html#problem_hostile

It's been a while since I've had one of these arguments, but reviewing
Policy 2.1 I agree.

Failure to generate ctlseqs.* from ctlseqs.ms would be a GPL violation
and thus a "serious" bug if:
1. The document were under the GPL; and
2. Debian didn't make the ctlseqs.ms and the requisite tools for
generating its dervative forms available.

...but neither of those prerequisites is the case.

That said, I think it would be _nice_ if a package produced all its
generated forms of documentation from their source forms as part of
the build process, and declared Build-Depends appropriately. This acts
as a form of QA on documentation generation tool chains, which in my
experience (in the case of XML/XSL) is as robust as a football pitch
of egg shells.

Thank God you've stuck with *roff. James Clark did such good work on
GNU Roff. Something terrible happened to him.

Regards,
Branden

Bug#848949: ftgl FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: ftgl
Version: 2.1.3~rc5-4+nmu1.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ftgl fails to cross build from source, because it configures for the
build architecture by not passing any --host flag to ./configure.
dh_auto_configure takes care of this for quite some time already, so
simply indirecting the ./configure invocation through dh_auto_configure
makes ftgl cross build successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru ftgl-2.1.3~rc5/debian/changelog 
ftgl-2.1.3~rc5/debian/changelog
--- ftgl-2.1.3~rc5/debian/changelog 2016-11-26 18:25:04.0 +0100
+++ ftgl-2.1.3~rc5/debian/changelog 2016-12-21 06:24:54.0 +0100
@@ -1,3 +1,10 @@
+ftgl (2.1.3~rc5-4+nmu1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross flags (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 21 Dec 2016 06:24:54 +0100
+
 ftgl (2.1.3~rc5-4+nmu1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru ftgl-2.1.3~rc5/debian/rules ftgl-2.1.3~rc5/debian/rules
--- ftgl-2.1.3~rc5/debian/rules 2016-11-26 18:25:04.0 +0100
+++ ftgl-2.1.3~rc5/debian/rules 2016-12-21 06:24:53.0 +0100
@@ -25,8 +25,7 @@
dh_testdir
QUILT_PATCHES=debian/patches quilt push -a || test $$? = 2
dh_autoreconf
-   ./configure --prefix=/usr --mandir=\$${prefix}/share/man \
-   --infodir=\$${prefix}/share/info \
+   dh_auto_configure -- \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
touch $@
 

Bug#848948: ebtables FTCBFS: uses build architecture compiler

[Helmut Grohne]

Source: ebtables
Version: 2.0.10.4-3.5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ebtables fails to cross build from source, because it uses the build
architecture compiler. dh_strip thus fails operating on build
architecture ELF objects expecting host architecture ones. Prefixing the
compiler with the host triplet solves this problem. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru ebtables-2.0.10.4/debian/changelog 
ebtables-2.0.10.4/debian/changelog
--- ebtables-2.0.10.4/debian/changelog  2016-05-25 20:37:15.0 +0200
+++ ebtables-2.0.10.4/debian/changelog  2016-12-21 06:18:21.0 +0100
@@ -1,3 +1,10 @@
+ebtables (2.0.10.4-3.6) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass triplet-prefixed CC to make (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 21 Dec 2016 06:18:21 +0100
+
 ebtables (2.0.10.4-3.5) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru ebtables-2.0.10.4/debian/rules 
ebtables-2.0.10.4/debian/rules
--- ebtables-2.0.10.4/debian/rules  2016-02-05 02:12:50.0 +0100
+++ ebtables-2.0.10.4/debian/rules  2016-12-21 06:18:19.0 +0100
@@ -1,5 +1,9 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+CC := $(DEB_HOST_GNU_TYPE)-gcc
+endif
 export DPKG_EXPORT_BUILDFLAGS = 1
 export DEB_CFLAGS_MAINT_APPEND=-fstack-protector-all
 include /usr/share/dpkg/buildflags.mk
@@ -13,7 +17,7 @@
 DEB_DH_INSTALLINIT_ARGS:=-- start 20 S . stop 80 0 1 6 .
 
 build/ebtables::
-   make CFLAGS="$(CPPFLAGS) $(CFLAGS)" CFLAGS_SH_LIB="-fPIC" 
LDFLAGS="$(LDFLAGS)" $(MAKE_PATH_REDIRECTIONS)
+   make CC="$(CC)" CFLAGS="$(CPPFLAGS) $(CFLAGS)" CFLAGS_SH_LIB="-fPIC" 
LDFLAGS="$(LDFLAGS)" $(MAKE_PATH_REDIRECTIONS)
 
 clean::
dh_testdir

Bug#817395: clips-doc: diff for NMU version 6.24-2.1

[Joao Eriberto Mota Filho]

Control: tags 817395 + patch
Control: tags 817395 + pending

Dear maintainer,

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

Regards,

Eriberto

diff -u clips-doc-6.24/debian/changelog clips-doc-6.24/debian/changelog
--- clips-doc-6.24/debian/changelog
+++ clips-doc-6.24/debian/changelog
@@ -1,3 +1,21 @@
+clips-doc (6.24-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+[ Joao Eriberto Mota Filho ]
+
+  * Bumped DH level to 10. (Closes: #817395)
+  * debian/control: bumped Standards-Version to 3.9.8.
+  * debian/watch: created.
+
+[ Logan Rosen ]
+
+  * debian/control: depend on ${misc:Depends}.
+  * debian/clips-doc.docs: Specify doc files.
+  * debian/rules: Switch to dh sequencer.
+
+ -- Joao Eriberto Mota Filho   Wed, 21 Dec 2016 02:30:43 
-0200
+
 clips-doc (6.24-2) unstable; urgency=low
 
   * Acknowledge NMU
diff -u clips-doc-6.24/debian/compat clips-doc-6.24/debian/compat
--- clips-doc-6.24/debian/compat
+++ clips-doc-6.24/debian/compat
@@ -1 +1 @@
-4
+10
diff -u clips-doc-6.24/debian/rules clips-doc-6.24/debian/rules
--- clips-doc-6.24/debian/rules
+++ clips-doc-6.24/debian/rules
@@ -2,41 +2,4 @@
-# Sample debian/rules that uses debhelper.
-# GNU copyright 1997 to 1999 by Joey Hess.
-
-# Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-
-clean:
-   dh_testdir
-   dh_testroot
-   dh_clean
-build:
-# Nothing to do here
-
-install:
-   dh_testdir
-   dh_testroot
-   dh_clean -k
-   dh_installdirs
-# Add here commands to install the package into debian/tmp.
-   
-# Build architecture-independent files here.
-binary-indep: install
-   dh_testdir 
-   dh_testroot 
-   dh_installdocs -i *.pdf
-   dh_installchangelogs -i
-   dh_compress -i
-   dh_fixperms -i
-   dh_installdeb -i
-   dh_shlibdeps -i
-   dh_gencontrol -i
-   dh_md5sums -i
-   dh_builddeb -i
-
-# Build architecture-dependent files here.
-binary-arch: build install
-# We have nothing to do by default.
-
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+%:
+   dh $@
diff -u clips-doc-6.24/debian/control clips-doc-6.24/debian/control
--- clips-doc-6.24/debian/control
+++ clips-doc-6.24/debian/control
@@ -2,13 +2,14 @@
 Section: doc
 Priority: optional
 Maintainer: Javier Fernandez-Sanguino Pen~a 
-Build-Depends: debhelper
-Standards-Version: 3.7.3
+Build-Depends: debhelper (>= 10)
+Standards-Version: 3.9.8
 Homepage: http://clipsrules.sourceforge.net/
 
 Package: clips-doc
 Architecture: all
 Recommends: clips, gv | pdf-viewer
+Depends: ${misc:Depends}
 Description: "C" Language Integrated Production System Documentation
  This package contains the documentation (users guide, interfaces guide...)
  of CLIPS, as well as some programming examples that might be useful
only in patch2:
unchanged:
--- clips-doc-6.24.orig/debian/clips-doc.docs
+++ clips-doc-6.24/debian/clips-doc.docs
@@ -0,0 +1 @@
+*.pdf
only in patch2:
unchanged:
--- clips-doc-6.24.orig/debian/watch
+++ clips-doc-6.24/debian/watch
@@ -0,0 +1,3 @@
+version=4
+opts=uversionmangle=s/(\d)/$1\./ \
+http://sf.net/clipsrules/ .*/clips_documentation_(\d+).zip

Bug#846311: dput: please use python-gpg instead of python-gpgme

[Ben Finney]

On 01-Dec-2016, Ben Finney wrote:
> The ‘python-gpg’ package doesn't seem to be in Debian Stretch yet, so
> I'll need to wait before assessing this.

I have uploaded ‘dput’ version “0.11.1” to the ‘experimental’ suite.
This incorporates the changes DKG proposed on this bug report.

Please try some corner cases – e.g. strange GnuPG keys that will cause
different responses from key verification – using this version of
‘dput’ to see whether it is suitable for a new version targeted to
‘unstable’.

-- 
 \   “A poet more than thirty years old is simply an overgrown |
  `\ child.” —Henry L. Mencken |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#848947: bibtool: [Regression] Empty separators cause errors

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear GI, thanks for your report.
Can you send a minimal material (sample(s) + procedure) that reproduce the 
issue ?
Thanks in advance,
Jerome

On 21/12/16 04:23, GI wrote:
> Package: bibtool
> Version: 2.66+ds-1
> Severity: normal
> 
> Dear Maintainer,
> 
> With version 2.66 empty separators cause an error. For instance, using
> 
> fmt.name.name = {}
> 
> returns an error of "Invalid separator specification" and doesn't change
> the default value of fmt.name.name. This was not a problem with the
> previous version of bibtool.
> 
> I suspect (but am not completely sure) that this is a regression in
> upstream caused by the commit 8221dced10ebb5427f98a6d602dbcfd43409eff2.
> 
> Thanks,
> 
> GI
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages bibtool depends on:
> ii  libc6 2.24-8
> ii  libkpathsea6  2016.20160513.41080-8
> ii  tex-common6.05
> 
> Versions of packages bibtool recommends:
> ii  texlive-base  2016.20161130-1
> 
> bibtool suggests no packages.
> 
> -- no debconf information
> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYWgZjAAoJED+SGaZ/NsaLpjYgAIuxvEPUbMyRh1K1Nb74GEzn
1FYbK/9l2p6aGvI0wmN8SYbElH4pPFe4Zr6JqseHHxNcY1zCLQ+m383BaRnfgYcr
lNEwNLIkSWQ5vRjWB0YG6YAN17EcQgcz1iPEVTNltkBJbmhL+IX/TEsj8HFmGDZb
y7Qsq5psgGAya87mdwvZXuXfLwxWL1t7sSH1McZAiXsZpw+uMmOwAsp1FNtPs0Tf
tNPYJkXy3CgEZOj9B+lwbjURDLb3BPycnoPvSenbQYdo0hFMWgb/lKUVh+Iglx3M
q+6HlGITnhI0V7dqi5TlBY7NWuwlzFnsjJBGY+EjuxxH059byeVa84BllWgGLT55
xk6vkK4d4c6ynXLSgrAVPxoMoXfiG1PMqr/q6Eydhy84/vCH8fa40mCWDgyBbWyV
L3vDz3LKBhAq0xyQu2cT2Ml2i50/CvJtlV1Ohedhh9SZUP+V1lPdmPiiUHZe91Gr
Q0Hf5f7J57nfyizHctcGU3fRtXVOXyykJ4PhWUHNxOPAWnTgZsMYiJJwcjFIJPAP
fG9XHQ3XyB99mtw8YRQAlXn29XyI/RzNUpSBLplK0Zi1reaBczy6reH3+6jiOD0S
7pGHrOrjZb3FHIyQXxOSd6vsY9btkO6JQf/b8fhxaBS1Oa/x2f+jJaHiqHm7bYy6
gj2tYSjw9ipR4Dyru/4m+kIZPqoJHfS2fLSXeyV5JI0Ef5CVxckC6kYBPd/4FxuT
n8FFVEZLtzCb1rPnRrqpmYdRkHEeZbMzhT06mSt0UdSds9A+R8PzoGuce8/mGzmt
9+d0Q9WfXAkRFUDJ+7eOiS7TSbVA4QyUuahPAoRjPKb0LwOz8cyTHLW7Cc0w5zyW
VVXPB5XblVrllJKKlNT2060K9AzDITDm5eCTBlM3u3xUUjJ1NwuRgUvct2c5IVKW
ZFqTmx4HJhoLuldLE2oCbJP174D9QWHvaWCRp4xj1kUHOLIjDdFsz8oqZgfTTj1t
3h3/tk1UyaEGtekXN0B6JKvjQxUAKqPIpr6Q7UcBfLAJc8/nSyEb5WFJx6a63TAP
Pq4GN9YE4Wkt/ZyP1lABgdbOgCSbd0n5wYopBAPyRagE68sJBKbfNRqL0SgyOIiO
WupY/MdeT44Q4hgplt7RlxEMpbZeQFQ+VvzfYqKwxx+wgMrfNQWu7ekrRRIwfIPi
ryUMxhbRNep6TP2PGGuf5qQnPI0/TlAqrh0kZPEl3iJSmffRtgkIwThjao0kp3v3
Wd0R9V5hcPI8eLjOZad6HNIFxs6c0ceqjbVPosf3XHDvPUSEDxdFLgIhwk0NpVZG
ji/LVYPNHs8B5GKi75OXvQR+Q9I2Ry1jXgIqjLqP6T/D4eT55VbgP0ZKJvWjlGc=
=qgIW
-END PGP SIGNATURE-

Bug#817623: poc-streamer: diff for NMU version 0.4.2-3.1

[Joao Eriberto Mota Filho]

Control: tags 817623 + pending

Dear maintainer,

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

Regards,

Eriberto

diff -u poc-streamer-0.4.2/debian/rules poc-streamer-0.4.2/debian/rules
--- poc-streamer-0.4.2/debian/rules
+++ poc-streamer-0.4.2/debian/rules
@@ -2,91 +2,12 @@
-# Sample debian/rules that uses debhelper.
-# This file is public domain software, originally written by Joey Hess.
-#
-# This version is for a multibinary package. It also allows you to build any
-# of the binary packages independantly, via binary- targets.
-
-# Uncomment this to turn on verbose mode. 
 #export DH_VERBOSE=1
 
-# This has to be exported to make some magic below work.
-export DH_OPTIONS
-
-build: build-stamp
-build-stamp:
-   dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE)
-
-   touch build-stamp
-
-clean:
-   dh_testdir
-   dh_testroot
-   rm -f build-stamp
-
-   # Add here commands to clean up after the build process.
-   -$(MAKE) clean
-
-   dh_clean
-
-install: DH_OPTIONS=
-install: build
-   dh_testdir
-   dh_testroot
-   dh_clean -k
-   dh_installdirs
-
-   # Add here commands to install the package into debian/poc-streamer.
-   $(MAKE) DESTDIR=$(CURDIR)/debian/poc-streamer PREFIX=/usr install
-
-# This single target is used to build all the packages, all at once, or
-# one at a time. So keep in mind: any options passed to commands here will
-# affect _all_ packages. Anything you want to only affect one package
-# should be put in another target, such as the install target.
-binary-common:
-   dh_testdir
-   dh_testroot
-   dh_installchangelogs
-   dh_installdocs
-   dh_installexamples
-   dh_installmenu
-#  dh_installdebconf
-#  dh_installlogrotate
-#  dh_installemacsen
-#  dh_installcatalogs
-#  dh_installpam
-#  dh_installmime
-#  dh_installinit
-#  dh_installman
-#  dh_installcron
-#  dh_installinfo
-#  dh_undocumented
-   dh_strip
-   dh_link
-   dh_compress
-   dh_fixperms
-#  dh_perl
-#  dh_python
-#  dh_makeshlibs
-   dh_installdeb
-   dh_shlibdeps
-   dh_gencontrol
-   dh_md5sums
-   dh_builddeb
-
-# Build architecture independant packages using the common target.
-binary-indep: build install
-# (Uncomment this next line if you have such packages.)
-#   $(MAKE) -f debian/rules DH_OPTIONS=-i binary-common
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
-# Build architecture dependant packages using the common target.
-binary-arch: build install
-   $(MAKE) -f debian/rules DH_OPTIONS=-a binary-common
+%:
+   dh $@
 
-# Any other binary targets build just one binary package at a time.
-binary-%: build install
-   make -f debian/rules binary-common DH_OPTIONS=-p$*
+override_dh_auto_install:
+   dh_auto_install -- PREFIX=/usr
 
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary-common binary install
+override_dh_auto_test:
diff -u poc-streamer-0.4.2/debian/control poc-streamer-0.4.2/debian/control
--- poc-streamer-0.4.2/debian/control
+++ poc-streamer-0.4.2/debian/control
@@ -2,13 +2,14 @@
 Section: sound
 Priority: optional
 Maintainer: Mike Gerber 
-Build-Depends: debhelper (>= 4.0.0), libid3tag0-dev, flex, bison
-Standards-Version: 3.6.1
+Build-Depends: debhelper (>= 10), libid3tag0-dev, flex, bison, libfl-dev
+Standards-Version: 3.9.8
+Homepage: https://bl0rg.net/software/poc/
 
 Package: poc-streamer
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: An MP3/Ogg multicast/HTTP streamer and MP3 cutting tool
+Description: MP3/Ogg multicast/HTTP streamer and MP3 cutting tool
  poc is a suite of MP3 tools and MP3 streaming programs. It can stream
  MP3s over HTTP, RTP multicast (RFC 2250 and RFC 3119) and a special 
  multicast protocol to enable the use of Forward Error Correction to 
diff -u poc-streamer-0.4.2/debian/changelog poc-streamer-0.4.2/debian/changelog
--- poc-streamer-0.4.2/debian/changelog
+++ poc-streamer-0.4.2/debian/changelog
@@ -1,3 +1,29 @@
+poc-streamer (0.4.2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+[ Joao Eriberto Mota Filho ]
+
+  * Bumped DH level to 10. (Closes: #817623)
+  * debian/control:
+  - Added a Homepage field.
+  - Added the libfl-dev to Build-Depends field to avoid a FTBFS.
+  - Bumped Standards-Version to 3.9.8.
+  * debian/rules:
+  - After conversion made by Logan:
+  ~ Added DEB_BUILD_MAINT_OPTIONS variable to improve the GCC 
hardening.
+  ~ Added DEB_LDFLAGS_MAINT_APPEND variable to avoid unneeded linking
+against libraries.
+
+[ Logan Rosen ]
+
+  * debian/control: remove article from beginning of synopsis.
+  * debian/rules:
+- Convert to dh sequenc

Bug#848947: bibtool: [Regression] Empty separators cause errors

[GI]

Package: bibtool
Version: 2.66+ds-1
Severity: normal

Dear Maintainer,

With version 2.66 empty separators cause an error. For instance, using

fmt.name.name = {}

returns an error of "Invalid separator specification" and doesn't change
the default value of fmt.name.name. This was not a problem with the
previous version of bibtool.

I suspect (but am not completely sure) that this is a regression in
upstream caused by the commit 8221dced10ebb5427f98a6d602dbcfd43409eff2.

Thanks,

GI

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

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

Versions of packages bibtool depends on:
ii  libc6 2.24-8
ii  libkpathsea6  2016.20160513.41080-8
ii  tex-common6.05

Versions of packages bibtool recommends:
ii  texlive-base  2016.20161130-1

bibtool suggests no packages.

-- no debconf information

Bug#848946: 5.1.12-dfsg-1 FTBFS on all arches

[Daniel Baumann]

Package: virtualbox
Version: 5.1.12-dfsg-1
Severity: serious

Hi,

your last upload fails to build from source on all arches:

---snip---
[...]
kBuild: Generating python -
/«PKGBUILDDIR»/out/obj/VBoxOGLgen/feedbackspu_state.c from
/«PKGBUILDDIR»/src/VBox/Additions/common/crOpenGL/feedback/feedback_state.py
/usr/bin/kmk_redirect -E
'PYTHONPATH=/«PKGBUILDDIR»/src/VBox/GuestHost/OpenGL/glapi_parser:/«PKGBUILDDIR»/src/VBox/GuestHost/OpenGL/packer:/«PKGBUILDDIR»/src/VBox/HostServices/SharedOpenGL/crserverlib'
-o /«PKGBUILDDIR»/out/obj/VBoxOGLgen/feedbackspu_state.c  --
/usr/bin/python2.7
/«PKGBUILDDIR»/src/VBox/Additions/common/crOpenGL/feedback/feedback_state.py
/«PKGBUILDDIR»/src/VBox/GuestHost/OpenGL/glapi_parser
/«PKGBUILDDIR»/src/VBox/Additions/common/crOpenGL/feedback
kmk_builtin_append -n
"/«PKGBUILDDIR»/out/obj/VBoxOGLfeedbackspu/feedback/feedback_context.o.dep"
""
"/«PKGBUILDDIR»/src/VBox/Additions/common/crOpenGL/feedback/feedback_context.c:"
""
kBuild: Creating directory /«PKGBUILDDIR»/out/obj/VBoxEGL/
kmk_builtin_mkdir -p -- /«PKGBUILDDIR»/out/obj/VBoxEGL/
kBuild: Compiling VBoxEGL -
/«PKGBUILDDIR»/src/VBox/Additions/common/crOpenGL/egl.c =>
/«PKGBUILDDIR»/out/obj/VBoxEGL/egl.o
gcc -c -O2 -g -pipe -Wshadow -Wall -Wextra
-Wno-missing-field-initializers -Wno-unused -Wno-trigraphs
-fdiagnostics-show-option -Wno-unused-parameter -Wlogical-op
-Wno-variadic-macros -Wno-long-long -Wunused-variable -Wunused-function
-Wunused-label -Wunused-parameter -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations
-Werror-implicit-function-declaration -Wno-variadic-macros -O2
-mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing
-fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN
-DRT_USE_VISIBILITY_DEFAULT -fPIC -Wno-overlength-strings -m64
-I/«PKGBUILDDIR»/src/VBox/Additions/x11/x11include/mesa-11.0.7
-I/«PKGBUILDDIR»/src/VBox/GuestHost/OpenGL/include
-I/«PKGBUILDDIR»/out/obj/VBoxOGLgen
-I/«PKGBUILDDIR»/out/obj/VBoxEGL/dtrace -I/«PKGBUILDDIR»/include
-I/«PKGBUILDDIR»/out -DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS
-DVBOX_WITH_REM -DVBOX_WITH_RAW_MODE -DRT_OS_LINUX
-D_FILE_OFFSET_BITS=64 -DRT_ARCH_AMD64 -D__AMD64__ -DVBOX_WITH_DEBUGGER
-DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/usr/share/virtualbox\"
-DRTPATH_APP_PRIVATE_ARCH=\"/usr/lib/virtualbox\"
-DRTPATH_SHARED_LIBS=\"/usr/lib/virtualbox\"
-DRTPATH_APP_DOCS=\"/usr/share/doc/virtualbox\" -DIN_RING3
-DVBOX_WITH_DTRACE -DVBOX_WITH_DTRACE_R3 -DIN_GUEST -DIN_GUEST_R3
-DIN_RT_R3 -DGC_ARCH_BITS=64 -DPIC -DCHROMIUM_THREADSAFE
-DVBOX_WITH_HGCM -DLOG_USE_C99 -DRT_WITHOUT_EXEC_ALLOC -DLinux=1
-D_GNU_SOURCE -Wp,-MD,/«PKGBUILDDIR»/out/obj/VBoxEGL/egl.o.dep
-Wp,-MT,/«PKGBUILDDIR»/out/obj/VBoxEGL/egl.o -Wp,-MP -o
/«PKGBUILDDIR»/out/obj/VBoxEGL/egl.o
/«PKGBUILDDIR»/src/VBox/Additions/common/crOpenGL/egl.c
/«PKGBUILDDIR»/src/VBox/Additions/common/crOpenGL/egl.c:25:21: fatal
error: EGL/egl.h: No such file or directory
 #include 
 ^
compilation terminated.
kmk: *** [/«PKGBUILDDIR»/out/obj/VBoxEGL/egl.o] Error 1
kmk: *** Waiting for unfinished jobs
kmk_builtin_append -n
"/«PKGBUILDDIR»/out/obj/VBoxOGLfeedbackspu/feedback/feedbackspu_init.o.dep"
""
"/«PKGBUILDDIR»/src/VBox/Additions/common/crOpenGL/feedback/feedbackspu_init.c:"
""
kmk_builtin_append -n
"/«PKGBUILDDIR»/out/obj/VBoxOGLhostspuload/gen/VBoxOGLgen/spuchange.o.dep"
"" "/«PKGBUILDDIR»/out/obj/VBoxOGLgen/spuchange.c:" ""
kmk: *** Exiting with status 2
debian/rules:58: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/«PKGBUILDDIR»'
debian/rules:34: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
---snap---

Regards,
Daniel

Bug#848945: grub-common: Empty rpool leaves ZFS systems unbootable

[John Goerzen]

Package: grub-common
Version: 2.02~beta2-22+deb8u1
Severity: important

This problem likely stems from the use of grub-probe in grub-mkconfig.

For a zpool, grub-probe may very well display several lines of
information.  Unfortunately, an analysis of strace shows all this goes
into GRUB_DEVICE and gets passed along in the future.

However, it may also be that grub-probe returns "unknown filesystem" for
zfs.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 /ntfs fuseblk 
ro,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
/dev/sdb1 /boot ext2 rw,noatime,nodiratime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN1220F32A3W6D
(hd1)   /dev/disk/by-id/ata-WDC_WD5000AAKS-60A7B2_WD-WMASZ0028605
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 --hint='hd0,msdos1'  
e6e07121-50eb-4eab-9d6e-192e089d27d9
else
  search --no-floppy --fs-uuid --set=root e6e07121-50eb-4eab-9d6e-192e089d27d9
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 --hint='hd0,msdos1'  
e6e07121-50eb-4eab-9d6e-192e089d27d9
else
  search --no-floppy --fs-uuid --set=root e6e07121-50eb-4eab-9d6e-192e089d27d9
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-/dev/mapper/MASS2-zfstank_/dev/mapper/MASS2-zfslog_/dev/mapper/MASS2-zfscache'
 {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 --hint='hd0,msdos1'  
e6e07121-50eb-4eab-9d6e-192e089d27d9
else
  search --no-floppy --fs-uuid --set=root 
e6e07121-50eb-4eab-9d6e-192e089d27d9
fi
echo'Loading Linux 3.16.0-4-amd64 ...'
linux   /vmlinuz-3.16.0-4-amd64 root=ZFS=/hephaestus-1/ROOT ro  
cgroup_enable=memory,cpu,devices,cpuacct,freezer,blkio swapaccount=1 
security=apparmor apparmor=1 boot=zfs
echo'Loading initial ramdisk ...'
initrd  /initrd.img-3.16.0-4-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-/dev/mapper/MASS2-zfstank_/dev/mapper/MASS2-zfslog_/dev/mapper/MASS2-zfs

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

[John Goerzen]

Package: grub-common
Version: 2.02~beta2-22+deb8u1
Severity: important

Hi,

Running update-grub provides this:


root@hephaestus:/tmp# update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/MASS2-zfstank'.

By using strace, I determined the problem is in how it uses zpool
status.

In my situation, it called "zpool status tank".  zpool status, by
default, omits everything before the final slash in the device name.
So, it shows just MASS2-zfstank in the above example, rather than
/dev/mapper/MASS2-zfstank.  grub-probe is clearly assuming --
incorrectly -- that everything is always under /dev.

The correct approach is to use "zpool status -P", which displays the
full path.  Then it will not need to prepend /dev, and will always get
the correct item.



-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 /ntfs fuseblk 
ro,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
/dev/sdb1 /boot ext2 rw,noatime,nodiratime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN1220F32A3W6D
(hd1)   /dev/disk/by-id/ata-WDC_WD5000AAKS-60A7B2_WD-WMASZ0028605
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 --hint='hd0,msdos1'  
e6e07121-50eb-4eab-9d6e-192e089d27d9
else
  search --no-floppy --fs-uuid --set=root e6e07121-50eb-4eab-9d6e-192e089d27d9
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 --hint='hd0,msdos1'  
e6e07121-50eb-4eab-9d6e-192e089d27d9
else
  search --no-floppy --fs-uuid --set=root e6e07121-50eb-4eab-9d6e-192e089d27d9
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 'gnulinux-simple-/tank/hephaestus-1/ROOT' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 --hint='hd0,msdos1'  
e6e07121-50eb-4eab-9d6e-192e089d27d9
else
  search --no-floppy --fs-uuid --set=root 
e6e07121-50eb-4eab-9d6e-192e089d27d9
fi
echo'Loading Linux 3.16.0-4-amd64 ...'
linux   /vmlinuz-3.16.0-4-amd64 root=ZFS=/hephaestus-1/ROOT ro  
cgroup_enable=memory,cpu,devices,cpuacct,f

Bug#834392: icedove: update for 45.5.1-1

[Andrew King]

Package: icedove
Version: 1:45.5.1-1
Followup-For: Bug #834392

This bug is still present in this version. 

New trace attached.

Regards,
Andrew

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

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

Versions of packages icedove depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.4
ii  libasound21.1.0-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.22-9
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-4
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libglib2.0-0  2.48.1-1
ii  libgtk2.0-0   2.24.30-1.1
ii  libhunspell-1.4-0 1.4.1-2
ii  libicu57  57.1-3
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpixman-1-0 0.33.6-1
ii  libsqlite3-0  3.13.0-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-4
ii  libvpx4   1.6.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-gb [hunspell-dictionary]  1:5.1.3-2
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.5.1-1
ii  myspell-en-au [myspell-dictionary]2.1-5.4

Versions of packages icedove suggests:
pn  apparmor  
ii  fonts-lyx 2.1.4-2
ii  libgssapi-krb5-2  1.13.2+dfsg-5

-- no debconf information
MOZILLA_FIVE_HOME=/usr/lib/icedove
  LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0.0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin
GNU gdb (Debian 7.10-1+b1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from 
/usr/lib/debug/.build-id/69/bb174e7c2075879c373f1b96461fd702a39511.debug...done.
done.
(gdb) run
Starting program: /usr/lib/icedove/icedove-bin 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe5ca1700 (LWP 4459)]
[Thread 0x7fffe5ca1700 (LWP 4459) exited]
[New Thread 0x7fffe5ca1700 (LWP 4462)]
[New Thread 0x7fffdceff700 (LWP 4463)]
[New Thread 0x77fee700 (LWP 4464)]
[New Thread 0x7fffdc6fe700 (LWP 4465)]
[New Thread 0x7fffdbbff700 (LWP 4466)]
[New Thread 0x7fffdb9fe700 (LWP 4467)]
[New Thread 0x7fffdb7fd700 (LWP 4468)]
[New Thread 0x7fffdb5fc700 (LWP 4469)]
[New Thread 0x7fffdb3fb700 (LWP 4470)]
[New Thread 0x7fffdb1fa700 (LWP 4471)]
[New Thread 0x7fffdaff9700 (LWP 4472)]
[New Thread 0x7fffdadf8700 (LWP 4473)]
[New Thread 0x7fffdabf7700 (LWP 4474)]
[New Thread 0x7fffda9f6700 (LWP 4475)]
[New Thread 0x7fffda7f5700 (LWP 4476)]
[New Thread 0x7fffda5f4700 (LWP 4477)]
[New Thread 0x7fffda3f3700 (LWP 4478)]
[New Thread 0x7fffda1f2700 (LWP 4479)]
[New Thread 0x7fffd9ff1700 (LWP 4480)]
[New Thread 0x7fffd9df0700 (LWP 4481)]
[New Thread 0x7fffd8aff700 (LWP 4482)]
[New Thread 0x7fffd7c80700 (LWP 4483)]
[New Thread 0x7fffd747f700 (LWP 4484)]
[New Thread 0x77e40700 (LWP 4485)]
[New T

Bug#848943: duplicity: Add ability to use Service Accounts with Google Cloud Storage API

[Witold Baryluk]

Package: duplicity
Version: 0.7.10-2
Severity: wishlist

Hi,

I wish that instead of using interoperable access, duplicit supported
standard Google Cloud credentials (Service Accounts) too for accessing
Google Cloud Storage API based backends. i.e. just point out to json file
with all credential metadata (email account, private key id, private key,
etc) using a flag or an environment variable.

Thanks.


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

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

Versions of packages duplicity depends on:
ii  libc62.24-8
ii  librsync10.9.7-10
ii  python   2.7.13-1
ii  python-lockfile  1:0.12.2-2
pn  python:any   

Versions of packages duplicity recommends:
ii  python-oauthlib  2.0.1-1
ii  python-paramiko  2.0.0-1
ii  python-urllib3   1.19.1-1
ii  rsync3.1.2-1

Versions of packages duplicity suggests:
pn  lftp
pn  ncftp   
ii  python-boto 2.44.0-1
pn  python-cloudfiles   
pn  python-gdata
ii  python-swiftclient  1:3.1.0-2
pn  tahoe-lafs  

-- no debconf information

Bug#829046: Any update on pagure?

[Alexandre Viau]

Hello,

> I'll see if I can continue my work tonight and let you know of any
> progress.

Any update on that?

Should someone take over?

As Praveen said, we just need a "good" package to be uploaded before the
25th. It can have bugs.

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#848942: Acknowledgement (jessie-pu: package most/5.0.0a-2.3)

[Benj. Mako Hill]

Greetings!

I forgot to mention that I've discussed this with the security team
and uploading to stable-proposed-updates was their suggestion and
recommendation.

Regards,
Mako

-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#821114:

[OSCAR EDUARDO MARTINEZ]

Last update: Wed. Dec, 21,  00:56:49 2016

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

[Paul Wise]

Control: reopen -1

On Tue, 2016-12-20 at 19:55 -0300, Felipe Sateler wrote:

> Unfortunately, I think the ship to fix this has sailed, as jessie was
> released a while ago already. I'm therefore closing this bug.

There is still the possibility of fixing this in a jessie point release
so I think it should remain open unless you aren't going to bother. If
that is the case then the bug should be marked as wontfix and closed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#848930: Acknowledgement (kills fellow process if window doesn't have focus)

[Antoine Beaupré]

for the record, I can also reproduce this in Gnome and MATE desktop
environments and with a fresh new user and/or profile.

so it seems this is not limited to xmonad: whenever chrome is in another
workspace, calling "chromium foo" will SIGKILL the existing instance.

a.
-- 
The history of any one part of the earth, like the life of a soldier,
consists of long periods of boredom and short periods of terror.
   - British geologist Derek V. Ager

Bug#848942: jessie-pu: package most/5.0.0a-2.3

[Benjamin Mako Hill]

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

There was a recent non-critical CVE issued for most:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848132
https://security-tracker.debian.org/tracker/CVE-2016-1253

The fix (a debdiff is attached) is this on-liner that changes single quotes to
double quotes.

Regards,
Mako


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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u most-5.0.0a/debian/changelog most-5.0.0a/debian/changelog
--- most-5.0.0a/debian/changelog
+++ most-5.0.0a/debian/changelog
@@ -1,3 +1,11 @@
+most (5.0.0a-2.3+deb8u1) stable-proposed-updates; urgency=high
+
+  * lzma-support.patch:
+- Fix CVE-2016-1253: shell injection attack when opening
+  lzma-compressed files (Closes: #848132)
+ 
+ -- Benjamin Mako Hill   Tue, 20 Dec 2016 16:52:16 -0800
+
 most (5.0.0a-2.3) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u most-5.0.0a/src/file.h most-5.0.0a/src/file.h
--- most-5.0.0a/src/file.h
+++ most-5.0.0a/src/file.h
@@ -22,7 +22,7 @@
 #define MOST_MAX_FILES 4096
 #define MOST_GUNZIP_POPEN_FORMAT "gzip -dc \"%s\""
 #define MOST_BZIP2_POPEN_FORMAT "bzip2 -dc \"%s\""
-#define MOST_LZMA_POPEN_FORMAT "lzma -dc '%s'"
+#define MOST_LZMA_POPEN_FORMAT "lzma -dc \"%s\""
 
 extern void most_reread_file (void);
 extern void most_read_to_line (int);

Bug#848941: gbp pq import can give different results to dpkg-source

[Ian Jackson]

Package: git-buildpackage
Version: 0.8.7

The source package (from Debian) llvm-toolchain-3.5_3.5-10.dsc
produces different results when extracted by dpkg-source, to when
processed using gbp pq import.  gbp must apply the patches differently
somehow.

(This came to light because it exposed a dgit failure, #848843.)

To reproduce:

cd Download
dget -d dget -d 
'http://snapshot.debian.org/archive/debian/20150227T221819Z/pool/main/l/llvm-toolchain-3.5/llvm-toolchain-3.5_3.5-10.dsc'
cd ..

dpkg-source -x Download/llvm-toolchain-3.5_3.5-10.dsc
cd llvm-toolchain-3.5-3.5/
git init
rm -rf .pc
git add -Af .
git commit -q -m 'dpkg-source -x'
cd ..

dpkg-source --skip-patches -x Download/llvm-toolchain-3.5_3.5-10.dsc w
cd w
git init
git add -Af .
git commit -q -m 'dpkg-source --skip-patches -x'
gbp pq import
git fetch ../llvm-toolchain-3.5-3.5 master:dpkgsource
git-diff dpkgsource

Observe that the output is not empty.  I see a diff to `configure'.

FTR, this is not a problem for dgit (well, I think it is not now that
I have fixed #848843).  dgit will fall back to using dpkg-source's
patch application, if gbp fails (via a horror involving a stunt `git
apply', as previously discussed).

But I thought you would like to know.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#847283: quilt-el: copyright file missing after upgrade (policy 12.5)

[Martin Quinson]

On Wed, Dec 21, 2016 at 02:12:32AM +0100, Andreas Beckmann wrote:
> On 2016-12-21 01:58, Martin Quinson wrote:
> > Hello,
> > 
> > I think I fixed this with a maintscript, but this is the first time I
> > do so. I'd feel better if you could double-check that I did it right,
> > eg by rerunning the script, please.
> 
> looking at the commit, that doesn't work on upgrades from testing
> (work as in "clean up the mess the previous version forgot")
> 
> The canonical version when introducing a .maintscript is
> $current_version plus "~", so in your case 0.63-6~
> meaning: "on upgrades from any version older than 0.63-6~ we do that
> action" But since there is a tag you probably uploaded it already, so
> you would fix that by bumping the version to 0.63-7~ in the next release.

Gosh. In the meanwhile, I discovered that I previously forgot an easy
patch in the BTS and uploaded a 0.63-7 version... Well, 0.63-8 is on
its way to unstable. I wanted to be quick, but you hardly do a good
job in a rush...

Thanks for your help,
Mt.

-- 
Nos péchés sont têtus, nos repentirs sont lâches
  --- Ch.Baudelaire, Les fleurs du mal


signature.asc
Description: PGP signature

Bug#684425: /usr/bin/conky: sensor monitoring is broken with recent kernels

[Celejar]

Package: conky-std
Followup-For: Bug #684425

I've been quite frustrated by this problem of non-persistent hwmon numbering
breaking conky's sensor monitoring functionality. The 'net is full of
people with similar problems (often with other software, such as fancontrol),
but there does not appear to be any good solution. Klugdes proposed include
tricks to manually force a specific module load order, giving up on conky's
internal sensor-related objects and using text tools to process the output of
'sensors', and writing conditionals in .conkyrc, but none of these are
satisfactory, and all implicitly concede that conky's internal sensor
monitoring functionality is basically broken with respect to recent kernels.

Here are some related bug reports / discussions:

http://lm-sensors.lm-sensors.narkive.com/f8LZrwfZ/module-load-order-dependency
https://bugzilla.redhat.com/show_bug.cgi?id=1340949
https://bbs.archlinux.org/viewtopic.php?id=80012
https://bbs.archlinux.org/viewtopic.php?id=63974
https://bbs.archlinux.org/viewtopic.php?id=144515
http://www.gossamer-threads.com/lists/linux/kernel/1917797
https://forums.gentoo.org/viewtopic-t-955576-start-0.html
https://bugs.launchpad.net/ubuntu/+source/lm-sensors-3/+bug/576602

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

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

Versions of packages conky-std depends on:
ii  libc6 2.19-18+deb8u6
ii  libglib2.0-0  2.42.1-1+b1
ii  libiw30   30~pre9-8
ii  liblua5.1-0   5.1.5-7.1
ii  libncurses5   5.9+20140913-1+b1
ii  libtinfo5 5.9+20140913-1+b1
ii  libx11-6  2:1.6.2-3
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxft2   2.3.2-1

conky-std recommends no packages.

Versions of packages conky-std suggests:
pn  apcupsd
pn  audacious  
pn  moc
pn  mpd
pn  xmms2  

-- no debconf information

Bug#848789: dgit: update dgit-sponsorship(7) in light of tagging changes

[Ian Jackson]

Sean Whitton writes ("Bug#848789: dgit: update dgit-sponsorship(7) in light of 
tagging changes"):
> Now that the debian/ tag is always generated, and placed on the branch
> you upload from, it is a bad idea to upload from the quilt-cache dgit
> view rather than the sponsee's view, even if you used the quilt-cache
> view to review.  Patch attached.

I've applied the patch.  Thanks.

I haven't thought about this properly, but I wonder, though, whether
you've considered advising people to use --no-dep14tag, instead.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#847283: quilt-el: copyright file missing after upgrade (policy 12.5)

[Andreas Beckmann]

On 2016-12-21 01:58, Martin Quinson wrote:
> Hello,
> 
> I think I fixed this with a maintscript, but this is the first time I
> do so. I'd feel better if you could double-check that I did it right,
> eg by rerunning the script, please.

looking at the commit, that doesn't work on upgrades from testing
(work as in "clean up the mess the previous version forgot")

The canonical version when introducing a .maintscript is
$current_version plus "~", so in your case 0.63-6~
meaning: "on upgrades from any version older than 0.63-6~ we do that
action" But since there is a tag you probably uploaded it already, so
you would fix that by bumping the version to 0.63-7~ in the next release.


Andreas

Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Holger Levsen]

On Wed, Dec 21, 2016 at 01:50:11AM +0100, Johannes Schauer wrote:
> Given all these arguments, adding a --rebuild-and-verify=foo.buildinfo option
> to sbuild sounds like the most sane thing to do. It would even not require the
> existing interface to change (the positional argument is a single source
> package).
> 
> Any thoughts?

as long as there's a short version of --rebuild-and-verify=foo.buildinfo
such as (for example) -rb=foo.buildinfo fine with me… :)

(though I'm not sure I fully understand why not assume -rb if
foo.buildinfo is given - I do understand for foo.changes…)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#790534: FTBFS: /usr/bin/texi2dvi: pdfetex exited with bad status

[Christoph Biedl]

Control: tags 790534 patch pending

This one makes the build pass again. Requires some more checking, though.

Christoph

--- a/doc/latex-mk.texi
+++ b/doc/latex-mk.texi
@@ -3,7 +3,6 @@
 @c %**start of header
 @setfilename latex-mk.info
 @settitle LaTeX-Mk
-@setcontentsaftertitlepage
 @c %**end of header
 
 @include version.texi
@@ -133,7 +132,7 @@
 @end menu
 
 @page
-@c @contents
+@contents
 
 @node Introduction, Targets, Top, Top
 @chapter Introduction



signature.asc
Description: Digital signature

Bug#847283: quilt-el: copyright file missing after upgrade (policy 12.5)

[Martin Quinson]

Hello,

I think I fixed this with a maintscript, but this is the first time I
do so. I'd feel better if you could double-check that I did it right,
eg by rerunning the script, please.

Thanks for your work,
Mt.

On Tue, Dec 06, 2016 at 11:33:34PM +0100, Andreas Beckmann wrote:
> Package: quilt-el
> Version: 0.63-5
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> a test with piuparts revealed that your package misses the copyright
> file after an upgrade, which is a violation of Policy 12.5:
> https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
> 
> After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.
> 
> This was observed on the following upgrade paths:
> 
>   wheezy -> jessie (no package in jessie, keeping wheezy version
>   installed) -> stretch
> 
> >From the attached log (scroll to the bottom...):
> 
> 3m38.6s ERROR: WARN: Inadequate results from running adequate!
>   quilt-el: missing-copyright-file /usr/share/doc/quilt-el/copyright
> 
> 3m43.4s DUMP: 
>   MISSING COPYRIGHT FILE: /usr/share/doc/quilt-el/copyright
>   # ls -lad /usr/share/doc/quilt-el
>   drwxr-xr-x 2 root root 40 Sep 15 10:31 /usr/share/doc/quilt-el
>   # ls -la /usr/share/doc/quilt-el/
>   total 0
>   drwxr-xr-x   2 root root   40 Sep 15 10:31 .
>   drwxr-xr-x 294 root root 6060 Sep 15 10:31 ..
> 
> 
> Additional info may be available here:
> https://wiki.debian.org/MissingCopyrightFile
> 
> Note that dpkg intentionally does not replace directories with symlinks
> and vice versa, you need the maintainer scripts to do this.
> See in particular the end of point 4 in
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
> 
> It is recommended to use the dpkg-maintscript-helper commands
> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
> to perform the conversion, ideally using d/$PACKAGE.maintscript.
> Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
> See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.
> 
> 
> cheers,
> 
> Andreas


-- 
You have a problem and decide to use floats. 
Now you have 2.0001 problems.


signature.asc
Description: PGP signature

Bug#835127: Status of tellico in stretch

[Mathias Gibbens]

Hi,

  This weekend I upgraded my main system to stretch to help shake out
bugs before the final release, and discovered that tellico has fallen
out of testing due to this bug. I've tried to reproduce tellico
crashing as reported under a few scenarios, but it runs fine for me:

  * Starting tellico with no configuration
  * Starting tellico with an existing database
  * Starting tellico with LANG=it_IT.UTF-8 LC_CTYPE=it_IT.UTF-8 (I
thought maybe the issue was caused by having a non-English locale set,
but it works for me.)

  I've also got another friend to try installing it on his stretch
system, and it works properly for him as well.

  Could we get an update from either of the two reporters for whom
tellico was crashing? Is it still crashing, or has this issue been
resolved through some other dependency update? Could the severity also
be lowered to something not RC-blocking, so tellico can be included in
the stretch release?

Thanks,
Mathias

Version: 2.3.9+dfsg.1-1.1

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

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

Versions of packages tellico depends on:
ii  kde-runtime4:16.08.3-1
ii  libc6  2.24-8
ii  libexempi3 2.3.0-2
ii  libkabc4   4:4.14.10-7
ii  libkcal4   4:4.14.10-7
ii  libkdecore54:4.14.26-1
ii  libkdeui5  4:4.14.26-1
ii  libkhtml5  4:4.14.26-1
ii  libkio54:4.14.26-1
ii  libknewstuff3-44:4.14.26-1
ii  libkparts4 4:4.14.26-1
ii  libkresources4 4:4.14.10-7
ii  libksane0  4:15.08.3-1
ii  libkxmlrpcclient4  4:4.14.10-7
ii  libnepomuk44:4.14.26-1
ii  libpoppler-qt4-4   0.48.0-2
ii  libqimageblitz41:0.0.6-4
ii  libqjson0  0.8.1-3
ii  libqt4-dbus4:4.8.7+dfsg-11
ii  libqt4-network 4:4.8.7+dfsg-11
ii  libqt4-xml 4:4.8.7+dfsg-11
ii  libqtcore4 4:4.8.7+dfsg-11
ii  libqtgui4  4:4.8.7+dfsg-11
ii  libsolid4  4:4.14.26-1
ii  libstdc++6 6.2.1-5
ii  libtag1v5  1.11.1-0.1
ii  libxml22.9.4+dfsg1-2.1
ii  libxslt1.1 1.1.29-2
ii  libyaz44.2.30-4+b4
ii  tellico-data   2.3.9+dfsg.1-1.1
ii  tellico-scripts2.3.9+dfsg.1-1.1

Versions of packages tellico recommends:
pn  khelpcenter4  
pn  tellico-doc   

tellico suggests no packages.

-- no debconf information

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

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

[Michael Biebl]

Am 21.12.2016 um 01:29 schrieb Felipe Sateler:

> Michael, from the discussion on IRC I did not end up entirely clear if
> you are OK with this change or not. Could you please comment, if we
> can apply this patch?
> 

I'm ok with this change. My reservation on IRC was mainly about this not
directly solving the lsb-base issue.
But the patch on itself is fine.

Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Johannes Schauer]

Hi,

Quoting Holger Levsen (2016-12-19 10:35:53)
> On Mon, Dec 19, 2016 at 10:02:58AM +0100, Johannes Schauer wrote:
> > Other ways to solve this problem include:
> >  - only accept .buildinfo files that include the .dsc filename and checksum
> >  - accept .changes files that reference both the .buildinfo and the .dsc
> 
> those two seem sensible to me.

I see why you think those make sense and I see how I could agree with you. But
thinking about this again, I think that the problem with implementing these two
options would be that they would sneak in an unexpected privacy breach.

If I add an option like --rebuild-and-verify=foo.buildinfo then the
documentation for that command line option can include a big fat warning that
using this option will try accessing snapshot.d.o to retrieve the right package
versions. Including this warning if the buildinfo is used implicitly (for
example if only a .changes file is passed) is not so easy.

Furthermore, .changes files will now nearly always include a reference to the
.buildinfo file. So if a .changes file were used, then another command line
argument would be needed to turn the buildinfo verification on or off
(depending on what the default is).

Lastly, accepting bare .buildinfo files requires them to reference the .dsc
which I find quite limiting. Builders should be able to verify .buildinfo files
that do not contain the source package.

Given all these arguments, adding a --rebuild-and-verify=foo.buildinfo option
to sbuild sounds like the most sane thing to do. It would even not require the
existing interface to change (the positional argument is a single source
package).

Any thoughts?

cheers, josch


signature.asc
Description: signature

Bug#808634: cadabra in Debian

[Axel Beckert]

Hi Kaspar,

Kasper Peeters wrote:
> > It builds then, but the test suite seems to hang at
> > "fieldtheory" (or I have to wait for more than a few minutes there):
> 
> Weird, this test went through fine on a VM which I installed from
> scratch with Debian 8.6 and then upgraded to testing.

Found the issue: The package didn't declare a build-dependency on lie.
If lie is installed, the test works fine.

I think I have most of the packaging updates covered. Will upload
soon-ish.

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

Bug#848899: Report is unclear

[Tobias Hansen]

On Tue, 20 Dec 2016 18:47:00 +0100 Julien Puydt
 wrote:
> Hi,
> 
> I don't understand why the bug reports ends with a discussion of the 
> count_trailing_zeros and count_leading_zeros macros, since the error 
> message quoted seems to be about the UWtype typedef.
> 
> Notice that I won't have time to have a look before next week (at 
> least), so if you find a worthy solution, don't hesitate to team-upload 
> a new version!
> 
> Snark on #debian-science
> 
> 

Because flint ends up using givaros implementation of
count_leading_zeros which uses UWtype. The solution is that flint needs
to use its own count_leading_zeros implementation.

Best,
Tobias

Bug#848685: sylpheed: PGP signature attachment named "noname" which is rare

[Roger Shimizu]

Dear Ricardo,

Thanks for investigating!

On Tue, Dec 20, 2016 at 5:57 PM, Ricardo Mones  wrote:
>
> Thanks for searching, but that patch is completely useless to current
> Sylpheed, sorry.

After searching around, I find maybe "noname" way is following RFC[0],
but most mutt user to choose "signature.asc" way (as you can see in
debian lists), and major mail clients, such as gmail, don't recognize
"noname" way (maybe it just cannot verify the signature, so it choose
to simply show as attachment).
So I think it's better let user decide which one to choose.

[0] http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2968

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#848940: ipset: bash complestion error

[Gedalya]

Package: ipset
Version: 6.30-2
Severity: minor

I'm getting a bash completion error on a new server I've just set up. This 
actually doesn't happen on my desktop, though both are running up-to-date 
stretch.

I'm attaching the output I get when running 'bash -lx' and then typing 'ipset 
de[TAB]'

I don't know that much about bash debugging so do let me know if I there's 
something else I should do.

Without debugging it's just this:

# ipset de-bash: syntax error in conditional expression
-bash: syntax error near `2'

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

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

Versions of packages ipset depends on:
ii  iptables   1.6.0-4
ii  libc6  2.24-8
ii  libipset3  6.30-2

ipset recommends no packages.

ipset suggests no packages.

-- debconf-show failed

# ipset de+ local compfile=./completions
+ [[ /usr/share/bash-completion/bash_completion == */* ]]
+ compfile=/usr/share/bash-completion/completions
+ compfile+=/ipset
+ [[ -f /usr/share/bash-completion/completions/ipset ]]
+ . /usr/share/bash-completion/completions/ipset
+ return 124
+ local cur prev cword words ips_version
+ local str_action str_setname str_type str_filename
+ local str_glob str_regex str_prefix str_suffix
+ local str_tmp= str_var=
+ local str_timeout=timeout 'str_order=before after' str_forceadd=
+ local str_counters= str_bp_counters= str_comment= str_markmask=
+ local str_skbinfo= str_skbflags=
+ local -i i=x=y=0
+ local -i got_bashcompl=got_action=action_index=order_index=set_has_timeout=0
+ local -i got_bp_proto=0
+ local -i ignore_errors=use_file=names_only=headers_only=save_format=res_sort=0
+ arr_sets=()
+ arr_types=()
+ arr_members=()
+ arr_unknown_opts=()
+ local arr_sets arr_types arr_members arr_unknown_opts
+ arr_dupe_cmd_opts=()
+ arr_used_opts=()
+ arr_tmp=()
+ local arr_dupe_cmd_opts arr_used_opts arr_tmp
+ arr_opts=("-! -exist" "-o -output" "-q -quiet" "-r -resolve" "-s -sorted" "-n 
-name" "-t -terse" "-f -file")
+ local arr_opts
+ arr_icmp_types=(echo-reply pong network-unreachable host-unreachable 
protocol-unreachable port-unreachable fragmentation-needed source-route-failed 
network-unknown host-unknown network-prohibited host-prohibited 
TOS-network-unreachable TOS-host-unreachable communication-prohibited 
host-precedence-violation precedence-cutoff source-quench network-redirect 
host-redirect TOS-network-redirect TOS-host-redirect echo-request ping 
router-advertisement router-solicitation ttl-zero-during-transit 
ttl-zero-during-reassembly ip-header-bad required-option-missing 
timestamp-request timestamp-reply address-mask-request address-mask-reply)
+ local arr_icmp_types
+ arr_icmp6_types=(no-route communication-prohibited address-unreachable 
port-unreachable packet-too-big ttl-zero-during-transit 
ttl-zero-during-reassembly bad-header unknown-header-type unknown-option 
echo-request ping echo-reply pong router-solicitation router-advertisement 
neighbour-solicitation neigbour-solicitation neighbour-advertisement 
neigbour-advertisement redirect)
+ local arr_icmp6_types
+ (( 4 < 4 ))
+ COMPREPLY=()
++ ipset version
+ ips_version='ipset v6.30, protocol version: 6'
+ ips_version='6.30, protocol version: 6'
+ ips_version=6.30
+ read -a ips_version
+ [[ 6 = +([[:digit:]]) ]]
+ (( ips_version[0] < 6 ))
+ (( ips_version[0] > 6 ))
+ (( ips_version[0] == 6 ))
+ (( ips_version[1] >= 22 ))
+ str_comment=comment
+ str_markmask=markmask
+ str_forceadd=forceadd
+ str_skbinfo=skbinfo
+ str_skbflags='skbmark skbprio skbqueue'
+ got_bp_proto=1
+ declare -f _get_comp_words_by_ref
+ got_bashcompl=1
+ _get_comp_words_by_ref -n : cur prev cword words
+ local exclude flag i OPTIND=1
+ words=()
+ local cur cword words
+ upargs=()
+ upvars=()
+ local upargs upvars vcur vcword vprev vwords
+ getopts c:i:n:p:w: flag -n : cur prev cword words
+ case $flag in
+ exclude=:
+ getopts c:i:n:p:w: flag -n : cur prev cword words
+ [[ 6 -ge 3 ]]
+ case ${!OPTIND} in
+ vcur=cur
+ let 'OPTIND += 1'
+ [[ 6 -ge 4 ]]
+ case ${!OPTIND} in
+ vprev=prev
+ let 'OPTIND += 1'
+ [[ 6 -ge 5 ]]
+ case ${!OPTIND} in
+ vcword=cword
+ let 'OPTIND += 1'
+ [[ 6 -ge 6 ]]
+ case ${!OPTIND} in
+ vwords=words
+ let 'OPTIND += 1'
+ [[ 6 -ge 7 ]]
+ __get_cword_at_cursor_by_ref : words cword cur
+ words=()
+ local cword words
+ __reassemble_comp_words_by_ref : words cword
+ local exclude i j line ref
+ [[ -n : ]]
+ exclude=:
+ eval cword=1
++ cword=1
+ [[ -n : ]]
+ line='ipset de'
+ (( i=0, j=0 ))
+ (( i < 2 ))
+ [[ 0 -gt 0 ]]
+ ref='words[0]'
+ eval 'words[0]=${!ref}${COMP_WORDS[i]}'
++ words[0]=ipset
+ line=' de'
+ [[ 0 == 1 ]]
+ (( i++, j++ ))
+ (( i < 2 ))
+ [[ 1 -gt 0 ]]
+ [[ de == +([:]) ]]
+ ref='words[1]'
+ eval 'words[1]=${!ref}${COMP_WORDS[i]}'
++ words[1]=de
+ line=
+ [[ 1 == 1 ]]
+ eval cword=1
++ cword=1
+ (

Bug#788253: gfsd: unowned files after purge (policy 6.8, 10.8): /var/lib/systemd/deb-systemd-helper-masked/gfsd.service

[Felipe Sateler]

Control: reassign -1 gfsd 2.6.4.1+dfsg-1

On Wed, 24 Jun 2015 17:52:58 +1000 Dmitry Smirnov  wrote:
> Control: reassign -1 dh-systemd 1.23
>
> On Fri, 12 Jun 2015 08:32:04 Dmitry Smirnov wrote:
> > On Thu, 11 Jun 2015 15:56:20 Andreas Beckmann wrote:
> > > maybe the manual rm causes confusion?
> >
> > Might be but it seems unlikely... I'll have a look.
>
> I've removed "rm -f /lib/systemd/system/gfsd.service" from postinst but (as I
> expected) it did not fix the problem. Unfortunately at this point I'm unable
> to explain why "/var/lib/systemd/deb-systemd-helper-masked/gfsd.service" is
> left behind after purge.

Removing that `rm` does fix the problem on a pristine installation. It
doesn't remove an already stale
/var/lib/systemd/deb-systemd-helper-masked/gfsd.service though. Moving
the removal to after the debhelper block should fix this as well.

>
>
> > > Perhaps you should contact the systemd maintainers for further
> > > investigation and advice.
>
> Re-assigning to "dh-systemd" as I could not find anything in the "gfarm"
> package that might be responsible. Leftover files are produced by systemd
> helper and that's where the problem lies I suppose...

Upon package remove but not purge, dh_systemd will mask the unit so
that upon the next boot you do not get boot failures because the
program is no longer installed.

Saludos

Bug#848939: borgbackup: Please package 1.0.9 - important fixes included

[John Goerzen]

Package: borgbackup
Version: 1.0.8-4~bpo8+1
Severity: normal

Hi,

Please see
https://github.com/borgbackup/borg/blob/1.0.9/docs/changes.rst#version-109-2016-12-20
for details.

There are some important security and integrity fixes in 1.0.9.

Thanks,

John

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

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

Versions of packages borgbackup depends on:
ii  libacl12.2.52-2
ii  libc6  2.19-18+deb8u6
ii  liblz4-1   0.0~r122-2
ii  libssl1.0.01.0.1t-1+deb8u5
ii  python33.4.2-2
ii  python3-llfuse 0.40-2+b2
ii  python3-msgpack0.4.6-1~bpo8+1
ii  python3-pkg-resources  5.5.1-1

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information

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

[Felipe Sateler]

On Thu, 10 Nov 2016 09:15:40 +0100 Martin Pitt  wrote:
> Hello Andreas,
>
> Andreas Henriksson [2016-11-09 11:08 +0100]:
> > As discussed on IRC we seem to agree that an init-less chroot which does
> > not have a policy-rc.d blocking service actions isn't a sane
> > configuration. This patch auto-detects the situation and skips running
> > the invoke-rc.d action (aka policy-rc.d code 101), unless --force was
> > given. In both situations a warning message is (also) printed.
>
> I must absolutely and loudly protest against mass-killing birds! ☺
>
> However, I do like the patch, it would give us a much saner behaviour
> of package installation in self-created chroots. mk-sbuild and friends
> do install a policy-rc.d already, but I've seen this come up more than
> once already.
>
> In the past where SysV and /etc/init.d/ were "the thing" it could
> still be argued that one doesn't need an explicit "init system" for
> some situations, but with Debian supporting multiple ones (and systemd
> by default) this is entirely moot IMHO.
>
> Michael, any others: Do you see any downside of this?

I also like this patch. invoke-rc.d is a maintainer interface for
starting/stopping services at package installation time (plus a few
other situations like hook scripts). In that context, it makes no
sense for a maintainer script to start a script in an init-less
chroot. If one by any chance actually needs to do so, then it should
not use invoke-rc.d.

Michael, from the discussion on IRC I did not end up entirely clear if
you are OK with this change or not. Could you please comment, if we
can apply this patch?

Saludos

Bug#728682: Patch

[Felipe Sateler]

Control: tags -1 pending

On Sat, 10 Dec 2016 21:36:33 +0100 Christian Hofstaedtler
 wrote:
> Control: tags -1 + patch
>
> Proposed patch attached.

Thanks. I have applied the patch. I also find "just in case warnings"
quite useless.

Saludos,

Bug#838703: libinput10: leads to a crash of X when working in a virtual tty

[Samuel Thibault]

Control: tags -1 + fixed-upstream

Hello,

Could this be backported to Debian for Stretch?

commit f47f78eb0bd9fba455f01c8c6dead3bd75242b2b
Author: Peter Hutterer 
Date:   Tue Dec 20 15:36:55 2016 +1000
  
Ignore LED updates for disabled devices

Thanks,
Samuel

Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Johannes Schauer]

Hi,

Quoting Johannes Schauer (2016-12-20 13:49:27)
> Currently, a buildinfo file does not specify which artifacts were supposed to
> be built (source,any,all).

as guillem points out to me on #debian-dpkg, the Architecture field lists
exactly that. It will contain "source" if the source package was built, "all"
for arch:all packages and a Debian architecture for arch:any builds.

> What should happen if the buildinfo file was for an Arch:any build but when
> rebuilding the source package, also arch:all packages show up? What should
> happen if the original build was including the source package but now it does
> not?
> 
> Should the verification fail if the build produces artifacts that are not
> listed in the buildinfo?
> 
> Should the verification fail if the build produces does not produce artifacts
> that are listed in the buildinfo?

I thus propose that a builder should use the Architecture field to figure out
what to build and fail if the produced artifacts are any different from the
ones in the buildinfo (being as strict about it as possible).

I implemented parsing of the Architecture field in the debrebuild.pl script and
let it pass the --build, --host, --arch-all, --arch-any and --source options to
sbuild.

Thanks!

cheers, josch


signature.asc
Description: signature

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

[Felipe Sateler]

Hi Yury

On 1 December 2016 at 10:06, Felipe Sateler  wrote:
> On 1 December 2016 at 09:17, Yury V. Zaytsev  wrote:
>> On Wed, 30 Nov 2016, Felipe Sateler wrote:
>>
 I'm filing this bug as discussed on #debian-systemd, requesting to kindly
 backport the relevant commit and push the new package to -updates:


 https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=a4e43fcdabf7962d2a765b6b0e11a51734afb5f0
>>>
>>>
>>> I've been thinking about this, and the fix would be incomplete without
>>> addressing #768450 too. Unfortunately, this means also an update of
>>> src:sysvinit (as invoke-rc.d was moved to i-s-h post-jessie) is needed
>>> but I don't really want to touch that...
>>
>>
>> Hi Felipe,
>>
>> I understand your line of thinking and the reluctance to touch src:sysvinit
>> :-( , but even if #768450 can't be backported, I would appreciate a backport
>> for this bug nevertheless, because that would mean that I can throw away the
>> deb-systemd-invoke hack, disable dh_installinit using the standard override_
>> mechanism and get a hack-free package that'd also work correctly on updated
>> systems...
>
> Yes, I agree that having a partial fix is better than no fix.

I have an updated package prepared[1]. Could you please test it and
report back if it works as intended? I have done some minor testing
but independent confirmation would be great. Fortunately the commit
applied very cleanly. If you prefer to rebuild the package yourself,
the relevant changes are in the fsateler/jessie branch of the git
repository[2]

[1] 
https://people.debian.org/~fsateler/ish-backport/init-system-helpers_1.22+deb8u1_all.deb
[2] https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/


-- 

Saludos,
Felipe Sateler

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

[Bjarni Ingi Gislason]

On Wed, Dec 14, 2016 at 12:09:37AM +, Colin Watson wrote:
> On Tue, Dec 13, 2016 at 11:17:18PM +, Bjarni Ingi Gislason wrote:
> > On Mon, Dec 12, 2016 at 06:40:21PM -0800, Russ Allbery wrote:
> > > Apologies for the regression; this is the confluence of two things that
> > > basically no one ever does (enable nroff warnings, and use this obscure
> > > indexing code), so it's essentially never tested.
> > > 
> > > >   1) 'F' is not a random register in manual pages.
> > > 
> > > It is, though.  It's a completely random register picked by Tom
> > > Christiansen years and years ago to hang this feature off of because it
> > > wasn't used for anything else.  From the nroff and man-db perspective,
> > > it's just some random user-defined register, not anything special.
> > 
> >   I have a different conception of "random".  The variable 'F' is in all
> > manual pages, that "pod2man" creates.
> 
> It is "random" from man-db's point of view, because it has no standard
> or predictable meaning across the set of all manual pages.
> 

  It is just undocumented.  "pod2man" uses it for input; its meaning is just
documented there.  By documenting it better there, and in the manual pages
of all implementations of "man", problems are avoided.  A warning about it
being undefined avoids future trouble and time theft, when the cause of the
warning is fixed.

  It has a definite meaning in pages made by "pod2man".  It is not used in
other manual pages as an input register, if it would, it would then be a bug
in them, and nowhere else.  Call it a reserved name (by custom or tradition)
for an input register to manual pages.  I have not found an use of a numeric
register 'F' in manual pages, except in those created by "Pod::Man".


> pod2man is just one way to create input files for nroff, and man-db pays
> it no special consideration beyond just generally making sure that it
> can parse its output properly.  Some other manual page or manual page
> generator might quite legitimately define the 'F' number register to do
> something completely different.  (It would not surprise me to find some
> page deciding to use it for something to do with input file names, like
> \n[.F], or fonts, like \n[.f], for instance.)  man has no business
> predefining 'F' by default simply in order to work around a pod2man bug;
> doing so might well cause problems elsewhere.
> 

  "man has no business ..." is your belief, which is wrong.  It is
responsible for providing the commands it uses with the correct input,
correct parameter.

  Where is this bug in "pod2man" (manual page) and what exactly is it, and
why?

> Even if this predefinition didn't happen to cause any problems today,
> it's completely the wrong layer for the fix, and would be terrible
> software engineering.  Fix problems at the layer where they arise; don't
> patch around them elsewhere.  That way lies spaghetti architecture.
> 

  The problem arises inside "groff", it issues a diagnostic, not the code in
the manual page.  Proof it otherwise.

  Possible later problems are then caused by the wrong or premature use of
this name 'F' in other places.

  The problem arises (has its beginning) inside "man" when it runs "groff".
So it arises in that layer, not later, although it is only reported later in
the row (pipe).  Otherwise it could not be fixed there (in the "man" or in
its defined environment).  Proof it otherwise.

> > Besides that, it is an "input variable"(!) for "*roff".
> 
> I'm not sure what your exclamation mark signifies or why you believe
> this makes a difference.  pod2man may have set things up so that you're
> expected to predefine that variable in order to enable this indexing
> thing, but that doesn't mean it should be given any special
> consideration by man-db.  Again, it's simply the wrong layer.
> 

  A value of an input variable is in the environment of a command, not
inside it.

  "man" gives "MANROFFOPT" a special consideration, thus everything in it,
for example "-rF0".

  Why is it the wrong layer?

  If true, a change in that layer can't make the diagnostic from "groff" go
away, make it unnecessary.  But is does, by a least three methods, all in the
"man"-layer (or "man-db"-layer), outside of "groff" and the manual page.

> >   So there are only two small changes needed to "man.c":
> > 
> > 1) The default value of "roff_opt" is "-rF0" and not an empty value.  Plus a
> > comment about the reason.
> > 
> > 2) Adding an explanation to the manual, saying what the default value is and
> > why.
> 
> You can absolutely set this environment variable locally as a workaround
> to make the (off by default anyway!) warnings go away; this kind of
> thing is why that variable exists, and I'm glad you find it useful.
> However, for the reasons given above I won't change man-db in the way
> you propose.  The fix belongs in pod2man.
> 

  Why just locally (for one user)?

  Why a workaround?

  A workaround caused by what bug?

  A workaround usually means, that the

Bug#807311: init-d-script: do_reload_sigusr1 sends sighup, not sigusr1

[Robbie Harwood]

Petter Reinholdtsen  writes:

> Renaming the function will break anyone doing the 'alias' trick, so any
> changes should be done in a backwards compatible way, I believe.
>
> Patches welcome. :)

The approach I was suggesting would look like this:

+ Enable this using
+ RELOAD_SIGNAL=1 # or other signal number
+ alias do_reload=do_reload_signal
+do_reload_signal() {
+log_daemon_msg "Reloading $DESC configuration files" "$NAME"
+start-stop-daemon --oknodo --stop --signal $RELOAD_SIGNAL \
+  --quiet --pidfile "$PIDFILE" --exec "$DAEMON"
+log_end_msg $?
+}

(There could even be a default value for RELOAD_SIGNAL, if desired.)

Once that has landed, I was suggesting sending patches to everyone using
do_reload_sigusr1() right now that look like this:

-alias do_reload=do_reload_sigusr1
+SIGNAL=1
+alias do_reload=do_reload_signal

At which point do_reload_sigusr1 can be safely removed since no one is
using it.


signature.asc
Description: PGP signature

Bug#848734: Pending fixes for bugs in the jackson-databind package

[pkg-java-maintainers]

tag 848734 + pending
thanks

Some bugs in the jackson-databind package are closed in revision
beb1e3d4175890c4b681689de7eb7c980336c901 in branch 'master' by
Emmanuel Bourg

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

Commit message:

Added the missing build dependency on build-helper-maven-plugin (Closes: 
#848734)

Bug#848937: nmu: beignet_1.2.1-1

[Andreas Beckmann]

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

nmu beignet_1.2.1-1 . amd64 i386 . unstable . -m "Rebuild against llvm 3.9 to 
match mesa."

Mixing OpenCL ICD built against libllvm3.8 (beignet) and libllvm3.9
(mesa) in one application leads to frequent crashes.

The packaging depends on both llvm 3.8 and llvm 3.9 and picks the one
used by mesa at build time.


Andreas

Bug#832351: init-system-helpers: purging gdm3/lightdm/sddm/xdm leaves dangling /etc/systemd/system/display-manager.service symlink

[Felipe Sateler]

Control: clone -1 -2
Control: reassign -1 xdm 1:1.1.11-3
Control: reassign -2 sddm 0.13.0-1

On Sun, 24 Jul 2016 15:54:55 +0200 Michael Biebl  wrote:
> Am 24.07.2016 um 15:49 schrieb Andreas Beckmann:
> > Package: init-system-helpers
> > Version: 1.22
> > Severity: important
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > Control: affects -1 + gdm3 lightdm sddm xdm
> > Control: found -1 sddm/0.13.0-1
> > Control: found -1 xdm/1:1.1.11-3
> >
> > Hi,
> >
> > during tests with piuparts I noticed the same behavior in 4 packages
> > providing a display-manager service: a dangling symlink is left after
> > purge. Some have individual bugs filed (lightdm: #775385, gdm3:
> > #771085), but this is more likely a bug somewhere in the helpers being
> > used. Notice, that after purge no other package providing a
> > display-manager service was installed any more.
> >
>
> Those links are not created by init-system-helpers, so it's probably the
> wrong package to assign this bug too.
> The display-manager.service symlink has some custom code in the
> maintainer scripts of the individual packages.
>
> We can use this bug report though, to come up with a scheme, how to do
> that properly.
> Then again, we already have
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764607 which is sort
> of related.

And indeed Didier Roche proposed a solution (in the form of a patch to
gdm3)[1]. I'm cloning and reassigning this bug to the two display
managers that do not have a bug already. The TLDR of the solution is:

1. Have your systemd unit Alias=display-manager.service
2. Use the --no-enable flag to dh_systemd_enable
3. Use `systemctl enable $DEFAULT_SERVICE` in the postinst

Step 1 and 2 should ensure the symlinks are removed on purge.

[1] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=764607;filename=use-systemd-alias.debdiff;msg=19

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

[Ian Jackson]

Johannes Schauer writes ("Bug#848931: dgit: please add a configuration variable 
that prevents me from accidentally doing a non-source-only upload"):
> I just uploaded a new version of my package botch. But then I got an
> email "Processing of botch_0.21-1_multi.changes" and I was like ugh... I
> accidentally did "dgit push" without having done "dgit build-source"
> first. So what got upload was the result of my "dgit sbuild". Would it
> make sense to add a dgit configuration variable that would prevent me
> from accidentally doing an upload that is not a source-only upload?
> Like, a configuration option that would force me to add an option to the
> command line if I *really* want to do an upload that is not source-only
> which only happens rarely.
> 
> Does this make sense?

Yes, this is a fine idea.  I intend an upload today, though, and this
won't be in it I'm afraid.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#848935: libnss-winbind: winbind authentication and wbinfo --uid-info no longer work after uprading to 4.5.2+dfsg-1

[stephane]

Package: libnss-winbind
Version: 2:4.5.2+dfsg-1
Severity: important

Dear maintener,

I'm encountering the following problem since the upgrade of the libnss-winbind, 
winbind and samba packages from
4.4.7+dfsg-1 to 4.5.2+dfsg-1: users can no longer access network shares
on a file server joined (as a member) to a samba-ad-dc based domain.

After further troubleshooting, it appears that the local UID and GID
numbers fails to be mapped to the domain accounts.

I was able to reproduce the problem in a lab that consists in the
following three virtual machines:
  - v-smb-dc: 192.168.101.10: domain controller (using samba-ad-dc)
  - v-smb-fs: 192.168.101.11: file server (joined to the domain)
  - v-smb-client: 192.168.101.20: client (using smbclient and
cifs-utils, not joined to the domain)

The initial setup is as follows:

*** for v-smb-client
 1) ntp synchronization
 2) only use v-smb-dc as dns nameserver
 3) apt-get install smbclient cifs-utils
(using version 4.5.2+dfsg-1)


*** for v-smb-dc:
 0) set up prerequisites: dns resolution, install all updates in
 testing, ntp synchronization, add mount flags acl,
 user_xattr and barrier=1 to the root filesystem
 1) apt-get install samba winbind
(using version 4.5.2+dfsg-1)
 2) mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
 3) samba-tool domain provision --use-rfc2307 --interactive
(default option left)
 4)/etc/samba/smb.conf is as follows:
[global]
netbios name = V-SMB-DC
realm = LAB.LOCAL
workgroup = LAB
dns forwarder = 192.168.101.1
server role = active directory domain controller
idmap_ldb:use rfc2307 = yes
logging level = 7

[netlogon]
path = /var/lib/samba/sysvol/lab.local/scripts
read only = No

[sysvol]
path = /var/lib/samba/sysvol
read only = No

 5) systemctl restart samba-ad-dc
 6) change /etc/resolv.conf and /etc/network/interfaces to use only v-smb-dc 
(192.168.101.10) as nameserver
 7) smbpasswd -a testusr
 8) all tests ok (samba-tool processes, set/getfacl, attr, dns, kinit)
 9) the client vm can access netlogon and sysvol successfully

root@v-smb-client:~# smbclient -L v-smb-dc -U%
WARNING: The "syslog" option is deprecated
Domain=[LAB] OS=[Windows 6.1] Server=[Samba 4.5.2-Debian]

Sharename   Type  Comment
-     ---
netlogonDisk
sysvol  Disk
IPC$IPC   IPC Service (Samba 4.5.2-Debian)
Domain=[LAB] OS=[Windows 6.1] Server=[Samba 4.5.2-Debian]

Server   Comment
----

WorkgroupMaster
----
WORKGROUPV-SMB-DC

root@v-smb-client:~# smbclient -L v-smb-dc -UAdministrator
WARNING: The "syslog" option is deprecated
Enter Administrator's password:
Domain=[LAB] OS=[Windows 6.1] Server=[Samba 4.5.2-Debian]

Sharename   Type  Comment
-     ---
netlogonDisk
sysvol  Disk
IPC$IPC   IPC Service (Samba 4.5.2-Debian)
Domain=[LAB] OS=[Windows 6.1] Server=[Samba 4.5.2-Debian]

Server   Comment
----

WorkgroupMaster
----
WORKGROUPV-SMB-DC

root@v-smb-client:~# mount -t cifs //v-smb-dc/sysvol /mnt -o 
ro,username=administrator,domain=LAB.LOCAL
Password for administrator@//v-smb-dc/sysvol:  
root@v-smb-client:~# find /mnt
/mnt
/mnt/lab.local
/mnt/lab.local/scripts
/mnt/lab.local/Policies
/mnt/lab.local/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
/mnt/lab.local/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/USER
/mnt/lab.local/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE
/mnt/lab.local/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
/mnt/lab.local/Policies/{6AC1786C-016F-11D2-945F-00C04FB984F9}
/mnt/lab.local/Policies/{6AC1786C-016F-11D2-945F-00C04FB984F9}/USER
/mnt/lab.local/Policies/{6AC1786C-016F-11D2-945F-00C04FB984F9}/MACHINE
/mnt/lab.local/Policies/{6AC1786C-016F-11D2-945F-00C04FB984F9}/GPT.INI


*** for v-smb-fs
 0) set up prerequisites: ntp synchronisation, only use v-smb-dc as dns 
nameserver
 1) mkdir /shared; apt-get install samba winbind libnss-winbind
(using version 4.5.2+dfsg-1)
 2) for p in samba-ad-dc samba smbd nmbd winbind; do systemctl stop $p; done
(and check all process are terminated)
 3) edit /etc/samba/smb.conf as follows:
[global]
security = ads
realm = LAB.LOCAL
workgroup = LAB
idmap uid = 1-2
idmap gid = 1-2
winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
winbind nss info = template
template homedir = /data/%U
template shell = /bin/false
encrypt passwords = yes
client use spnego = yes
   

Bug#848506: [Pkg-julia-devel] Bug#848506: julia: FTBFS (Memory limit reached : 687558656 > 524288000)

[Peter Colberg]

On Tue, Dec 20, 2016 at 10:54:06PM +0100, Santiago Vila wrote:
> Aha, so I guess that the fact that I always have this:
> 
> $ENV{'DEB_BUILD_OPTIONS'} = 'parallel=1';
> 
> in my .sbuildrc is one of the reasons the build failed in my
> autobuilders, right?

Yes, that’s it. (Please forget what I said about debhelper 10.)

Alternatively, the failure is reproduced using `sbuild -j1`.

> [ Sometimes I have the feeling that I'm the only one building packages
>   with only one CPU... ]

I guess you are one of the few testing parallel=1.

Thanks for spotting this corner case.

Peter

Bug#810931:

[Caroline Wood]

Dear beloved, 
I bid you greetings, I have important thing that could be brought your way, but 
the details shall be given when you confirm the receipt of this email. 
Yours Sincerely, 
Mrs. Caroline Wood. 

Bug#848735: pynast: FTBFS: Test failures

[Aaron M. Ucko]

Andreas Tille  writes:

> When thinking about this just disabling the affected test might be a
> reasonable thing to do.

No need, I've come up with a working patch (attached).

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

Adapt to the modern BLAST engine and BLAST+ legacy_blast wrapper.
* Specify an explicit gap extension cost (2) to accompany the explicit
  mismatch penalty.
* Reduce the word size to the traditional value of 11 so the test
  cases can succeed.
* Stop trying to request the old engine.
* Accommodate minor output format changes between legacy BLAST and
  BLAST+.  
--- a/pynast/util.py
+++ b/pynast/util.py
@@ -147,7 +147,7 @@ def blast_align_unaligned_seqs(seqs,
 
 # Note: -S 1 indicated that we don't want to blast both orientations -- at
 # this would be different behavior than other pairwise aligners.
-bl2seq_res = system('bl2seq -i %s -j %s -o %s -F F -S 1 -q -1 -p blastn -VT' %\
+bl2seq_res = system('bl2seq -i %s -j %s -o %s -F F -S 1 -q -1 -E 2 -W 11 -p blastn' %\
  (in_filepath1,in_filepath2,out_filepath))
 if bl2seq_res != 0:
 raise RuntimeError, "bl2seq failed:\n %s" % bl2seq_res 
@@ -157,16 +157,16 @@ def blast_align_unaligned_seqs(seqs,
 blast_res = open(out_filepath)
 in_result = False
 for line in blast_res:
-if line.strip().startswith('Score'):
+if line.strip().startswith('Score = '):
 if in_result:
 break
 else:
 in_result = True
 
-if line.startswith('Query: '):
+if in_result and line.startswith('Query'):
 fields = line.split()
 query_seq.append(fields[2].upper())
-elif line.startswith('Sbjct: '):
+elif in_result and line.startswith('Sbjct'):
 fields = line.split()
 subject_seq.append(fields[2].upper())
 else:

Bug#793798: app_voicemail hangs up due to missing audio file

[Bernhard Schmidt]

Control: reassign -1 asterisk-core-sounds
Control: affects -1 asterisk
Control: severity -1 important

On Mon, Jul 27, 2015 at 10:14:56AM -0600, TheSin wrote:
> Package: asterisk-voicemail
> Version: 1:13.1.0~dfsg-1.1
> 
> Forwarding a voicemail cause the app to hangup due to missing sound file.
> 
> From the asterisk changelog
> 
> 2013-11-23 00:22 + [r403106]  Rusty Newton 
> 
>   * apps/app_voicemail.c: app_voicemail: when forwarding a message,
> play vm-msgforwarded instead of vm-msgsaved In the last release
> of sounds, 1.4.25 we added a vm-msgforwarded prompt for various
> core languages. Now we use that prompt. (issue ASTERISK-21413)
> (closes issue ASTERISK-21413) Reported by: netwrkr Tested by:
> newtonr
> 
> That means asterisk-core-sounds 1.4.25 is required but 1.4.22 is the latest 
> available.
> 
> Updating the core-sounds package and adding a versioned depend on it
> is the proper solution but for now I just added symlinks from
> vm-msgsaved to vm-msgforwarded which works.  Just wanted to make
> record of this incase others are trying to figure it out as well.

Thanks for the report, I'll have a look at updating asterisk-core-sounds
for Stretch.

Bernhard


signature.asc
Description: Digital signature

Bug#844258: golang-go: go SIGILL on s390x

[Philipp Kern]

On 11/13/2016 09:55 PM, Andreas Henriksson wrote:
> Filing this as promised and as previously discussed in #835360 [0]. It
> seems we're having problem building go packages on s390x when they end
> up on a certain buildd[1]. AIUI the issue boilds down to upstream go
> community doesn't define their support for s390 as we define the s390x
> port in Debian.  ie. they consider certain older s390 hardware
> unsupported which is still part of the defined hardware set of debian
> s390x. See for example [2].
> 
> I'd suggest simply removing s390x binaries and all reverse dependencies
> of golang on s390x. Also go package maintainers should limit their
> Architecture: field to only include archs that is actually supportable
> rather than using eg. 'all' like golang-github-shirou-gopsutil does
> despite including parsing code which only covers linux/x86* (and other
> archs we don't have in Debian).
> 
> Please note that I'm not really interested in being part of any
> discussion around this bug, so please feel free to leave me
> out of it! Thanks!

FWIW, we have now two of three builders and the porter box supporting
the s390x CPU feature set that Go requires.

I suppose the other way out could be that we decom zemlinsky (which
won't have a replacement). I know that Aurelien already had some patches
to Go, but not a complete set. Then the question is about the strategic
decision of having a language that is only supported on newer CPUs vs.
not building whatever is implemented in that language.

I suppose in the case of Go it's always feasible to also just download
it pre-compiled, set up your environment, and compile whatever you need.
Or download pre-compiled binaries of whatever you need. On the other
hand the major reason there was such an investment on Go on s390x is
that you can run docker and modern tools.

So personally I'd go and bite the bullet and document that Go is
available but won't work on anything less than a z196/z114 (released in
2010). :(

Kind regards
Philipp Kern

Bug#848934: cups-daemon: ErrorPolicy ignored if ipp:// printer rebooted mid-job

[Daniel Gnoutcheff]

Package: cups-daemon
Version: 2.2.1-2
Severity: minor

To reproduce:
1. Obtain an IPP network printer with a static IP address.
2. Define a cups queue for said printer using the ipp: backend
3. Set an ErrorPolicy that's not "stop-printer" (e.g. abort-job).
4. Start a large print job on this printer, i.e. a job that needs at
   least 10 seconds to send over the network.
5. While the job is being transmitted over the network, crash the
   printer (e.g. yank the power cord).
6. Immediately restart the printer.
7. Wait for the job to fail.

Expected behavior:  cups handles the job failure according to the
specified ErrorPolicy.

Actual behavior: cups stops the printer, blocking subsequent jobs.
system-config-printer alerts me of the job failure but doesn't inform
me that the printer's been stopped.  "Nothing prints" until I do `sudo
cupsenable queue_name`.

This appears to be independent of printer make/model.  I've reproduced
this with an HP LaserJet 4250dtn and a Brother DCP-8155DN.

I think problem is that the ipp backend exits with CUPS_BACKEND_STOP if
the TCP connection gets terminated with a RST packet.  When I crash
the printer, the ipp backend starts sending TCP retransmissions, and
when the printer reboots, it responds to next retransmission with a RST
(much as I would expect from freshly-rebooted embedded TCP/IP stack).

Perhaps the backend should return CUPS_BACKEND_FAILED instead?

I should add that I've also seen a printer power-cycle itself
mid-transfer during a print job that it apparently couldn't handle.
(That's was how I discovered this bug, actually.)  Even in that case,
though, I'd prefer to use the abort-job error policy.

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

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

Versions of packages cups-daemon depends on:
ii  adduser  3.115
ii  bc   1.06.95-9+b2
ii  dpkg 1.18.15
ii  init-system-helpers  1.46
ii  libavahi-client3 0.6.32-1
ii  libavahi-common3 0.6.32-1
ii  libc62.24-8
ii  libcups2 2.2.1-2
ii  libcupsmime1 2.2.1-2
ii  libdbus-1-3  1.10.14-1
ii  libgssapi-krb5-2 1.15~beta1-1
ii  libpam0g 1.1.8-3.3
ii  libpaper11.1.24+nmu5
ii  libsystemd0  232-7
ii  lsb-base 9.20161125
ii  procps   2:3.3.11-3
ii  ssl-cert 1.0.38

Versions of packages cups-daemon recommends:
ii  avahi-daemon  0.6.32-1
ii  colord1.3.3-2
ii  cups-browsed  1.11.6-1+b1

Versions of packages cups-daemon suggests:
ii  cups   2.2.1-2
ii  cups-bsd   2.2.1-2
ii  cups-client2.2.1-2
ii  cups-common2.2.1-2
ii  cups-filters [foomatic-filters]1.11.6-1+b1
pn  cups-pdf   
ii  cups-ppdc  2.2.1-2
ii  cups-server-common 2.2.1-2
ii  foomatic-db-compressed-ppds [foomatic-db]  20161005-1
ii  ghostscript9.20~dfsg-1
ii  hplip  3.16.10+repack0-1
ii  poppler-utils  0.48.0-2
ii  printer-driver-gutenprint  5.2.11-1+b1
ii  printer-driver-hpcups  3.16.10+repack0-1
pn  smbclient  
ii  udev   232-7

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#684646: fails to receive BYE over TLS

[Bernhard Schmidt]

Control: tags -1 +moreinfo

On Sun, Aug 12, 2012 at 12:44:18PM +, Daniel Pocock wrote:

> I am using v1.8.8.  I've also tried to use 1.8.13 (the version in
> wheezy) to see if that resolves the problem, but 1.8.13 has more severe
> problems that prevent testing of the same TLS environment:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683956
> 
> Basically, the user agents are Polycom phones, connecting to Asterisk
> using TLS.  A sample peer config is below.
> 
> The phones can connect and register.  The phones can send an SIP INVITE
> and start a call.  However, when the phone is hung up, Asterisk doesn't
> receive the BYE

Is this still an issue? I have never run 1.8 with SIP/TLS in production,
but 11 seems to be fine here (with Snom and Yealink phones).

Bernhard


signature.asc
Description: Digital signature

Bug#846552: [pkg-go] Bug#846552: New upstream version 0.18

[Dr. Tobias Quathamer]

Am 20.12.2016 um 11:59 schrieb Dr. Tobias Quathamer:

Yes, I'm already looking into this.


Version 0.18 is now (almost) ready for an upload. I'm waiting for 
FTP-Masters to accept a new package, which is needed for the new hugo 
release:


golang-github-bep-gitmap, https://bugs.debian.org/848700

Regards,
Tobias




signature.asc
Description: OpenPGP digital signature

Bug#848933: psignifit: diff for NMU version 2.5.6-3.1

[Joao Eriberto Mota Filho]

Package: psignifit
Version: 2.5.6-3
Severity: normal
Tags: patch pending

Dear maintainer,

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

Regards,

Eriberto

diff -u psignifit-2.5.6/psig-src/Makefile psignifit-2.5.6/psig-src/Makefile
--- psignifit-2.5.6/psig-src/Makefile
+++ psignifit-2.5.6/psig-src/Makefile
@@ -18,7 +18,7 @@
 CXXFLAGS = $(CYGFLAG) $(DBFLAG)
 LD = gcc $(CYGFLAG) $(DBFLAG)
 # add '-lm' flag for Debian GNU/Linux
-LDFLAGS = -lm
+LIBS = -lm
 DEPEND_FLAG = -MM  # GNU compilers support -MM, others may only support -M
 
 csource = $(wildcard *.c)
@@ -46,7 +46,7 @@
 
 
 psignifit : $(objects)
-   $(LD) $(LDFLAGS) -o $@ $(objects)
+   $(LD) $(LDFLAGS) -o $@ $(objects) $(LIBS)
 
 %.d : %.c
@ set -e; $(CC) $(DEPEND_FLAG) $(CFLAGS) $< \
diff -u psignifit-2.5.6/debian/rules psignifit-2.5.6/debian/rules
--- psignifit-2.5.6/debian/rules
+++ psignifit-2.5.6/debian/rules
@@ -2,66 +2,4 @@
-
 #export DH_VERBOSE=1
 
-CFLAGS = -Wall -g
-
-ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-   CFLAGS += -O0
-else
-   CFLAGS += -O2
-endif
-
-configure: configure-stamp
-configure-stamp:
-   dh_testdir
-   touch configure-stamp
-
-
-build: build-stamp
-
-build-stamp: configure-stamp
-   dh_testdir
-
-   cd psig-src && $(MAKE)
-   cd ..
-   touch build-stamp
-
-clean:
-   dh_testdir
-   dh_testroot
-   rm -f build-stamp configure-stamp
-   -cd psig-src && $(MAKE) clean
-   cd ..
-   dh_clean
-
-install: build
-   dh_testdir
-   dh_testroot
-   dh_clean -k
-   dh_installdirs
-   cd psig-src && $(MAKE) install DESTDIR=$(CURDIR)/debian/psignifit
-   cd ..
-
-
-binary-indep: build install
-# We have nothing to do by default.
-
-binary-arch: build install
-   dh_testdir
-   dh_testroot
-   dh_installchangelogs
-   dh_installdocs
-   dh_installexamples
-   dh_installman
-   dh_install runexampledata usr/share/doc/psignifit/tests
-   dh_link
-   dh_strip
-   dh_compress
-   dh_fixperms
-   dh_installdeb
-   dh_shlibdeps
-   dh_gencontrol
-   dh_md5sums
-   dh_builddeb
-
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+%:
+   dh $@ --sourcedirectory=psig-src
diff -u psignifit-2.5.6/debian/compat psignifit-2.5.6/debian/compat
--- psignifit-2.5.6/debian/compat
+++ psignifit-2.5.6/debian/compat
@@ -1 +1 @@
-4
+10
diff -u psignifit-2.5.6/debian/control psignifit-2.5.6/debian/control
--- psignifit-2.5.6/debian/control
+++ psignifit-2.5.6/debian/control
@@ -3,15 +3,15 @@
 Priority: optional
 Maintainer: Experimental Psychology Maintainers 

 Uploaders: Michael Hanke 
-Build-Depends: debhelper (>= 4.0.0)
-Standards-Version: 3.7.2
-Homepage: http://www.bootstrap-software.org
+Build-Depends: debhelper (>= 10)
+Standards-Version: 3.9.8
+Homepage: http://bootstrap-software.com/psignifit/
 Vcs-Browser: http://svn.debian.org/wsvn/pkg-exppsy/psignifit/?rev=0&sc=0
 Vcs-Svn: svn://svn.debian.org/pkg-exppsy/psignifit
 
 Package: psignifit
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: Fitting and testing hypotheses about psychometric functions
  Psignifit allows fitting of psychometric functions to datasets while
  maintaining full control over a large number of parameters. Data
diff -u psignifit-2.5.6/debian/changelog psignifit-2.5.6/debian/changelog
--- psignifit-2.5.6/debian/changelog
+++ psignifit-2.5.6/debian/changelog
@@ -1,3 +1,26 @@
+psignifit (2.5.6-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+[ Joao Eriberto Mota Filho ]
+
+  * Bumped DH level to 10. (Closes: #817631)
+  * debian/control:
+  - Bumped Standards-Version to 3.9.8.
+  - Updated the Homepage field.
+
+[ Logan Rosen ]
+
+  * debian/control: depend on ${misc:Depends}.
+  * debian/install: install runexampledata.
+  * debian/rules: Switch to dh sequencer.
+
+[ Matthias Klose ]
+
+  * Fix FTBFS with ld --as-needed. (Closes: #641554, LP: #771008)
+
+ -- Joao Eriberto Mota Filho   Tue, 20 Dec 2016 20:29:49 
-0200
+
 psignifit (2.5.6-3) unstable; urgency=low
 
   * Use new-style homepage field in debian/control (Closes: #438805).
only in patch2:
unchanged:
--- psignifit-2.5.6.orig/debian/install
+++ psignifit-2.5.6/debian/install
@@ -0,0 +1 @@
+runexampledata usr/share/doc/psignifit/tests

Bug#790184: lxterminal: depends on vte which is deprecated

[Andriy Grytsenko]

Thank you for a suggestion. While using new libs might be an advantage,
libvte-2.91 uses GTK+ 3.0, while until now lxterminal package was using
GTK+ 2.0 (as well as rest of LXDE components). Switch to GTK+ 3.0 is not
much desirable since LXDE is positioned as a lightweight environment but
GTK+ 3.0 uses much more resources and has more bugs, some of which are
not easy to workaround. Overall, users are negative on switching over
to GTK+ 3.0 after some experience. And even if other applications aren't
taken into consideration (I mean mostly style difference), use just one
application with GTK+ 3.0 while other ones are GTK+ 2.0 may be a waste
(as both GTK+ 2.0 and GTK+ 3.0 will be loaded at the same time).

Bug#845921:

[Caroline Wood]

Dear beloved, 
I bid you greetings, I have important thing that could be brought your way, but 
the details shall be given when you confirm the receipt of this email. 
Yours Sincerely, 
Mrs. Caroline Wood. 

Bug#848726: shebang preseed

[Philipp Kern]

On 12/20/2016 09:26 PM, Geert Stappers wrote:
> On Mon, Dec 19, 2016 at 10:00:57PM +0100, Geert Stappers wrote:
>> This ticket is to discuss a "shebang" for preseed files,
>> to have an interpreter directive.
> Goal is having a "header" which make it possible
> to check that actual a preseed file is being downloaded.
> 
> https://www.debian.org/releases/stable/example-preseed.txt shows clearly
> that a preseed file can start with a comment.
> 
> What are the opinions about a two step approach like
> 
> Step 1:
> ---
> Document all "stretch" preseed files begining with '#!preseedV1'
> 
> 
> Step 2:
> ---
> In "stretch+1", a.k.a. "buster", implement code that checks '#!preseedV1'
> and informs user when not found.

How would this change the outcome of the bug you encountered? If I
understand you correctly it told you that the file was corrupt. Your
proposal would just re-enforce that notion, at the expense of everyone
needing to change their files? :)

Kind regards
Philipp Kern

Bug#848397: coz-profiler: Section should not be “net”

[Ben Finney]

On 20-Dec-2016, Debian Bug Tracking System wrote:
> Date: Tue, 20 Dec 2016 22:04:14 +
> From: Petter Reinholdtsen 
> Subject: Bug#848397: fixed in coz-profiler 0.1.0-1
> To: 848397-cl...@bugs.debian.org
>
> […]
>* Change the package section into 'devel' (Closes: #848397).

Thank you for correcting the ‘debian/control’ data.


> Since the package is already in Debian with a different section, you
> will also need to submit a request to override the existing section
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#override-file>.
> 
> Then mark this bug report as blocked by that new one, and be sure not
> to close this one until that new one is completed.

Which bug report addresses the above requirement? I don't see that the
block was set for this bug.

-- 
 \ “I thought I'd begin by reading a poem by Shakespeare, but then |
  `\ I thought ‘Why should I? He never reads any of mine.’” —Spike |
_o__) Milligan |
Ben Finney 


signature.asc
Description: PGP signature

Bug#838735: broadcom-sta-dkms: Please announce supported hardware using AppStream

[Eduard Bloch]

Hallo Peter,
* Petter Reinholdtsen [Sat, Dec 17 2016, 07:22:09PM]:
> [Petter Reinholdtsen]
> > Hi.  The current AppStream modalias setting causes the package to show
> > up on machines where it isn't supported.  Please change the modalias
> > matching rule to be more specific to the supported hardware.
> 
> This issue reduces the usability of the isenkram system seriously.  The
> time is running out to have this fixed in Stretch.  Because of this, I
> plan to blacklist the appstream information from broadcom-sta-dkms in
> isenkram to make sure the bogus package proposal is not listed on all
> machines with an ethernet card.
> 
> Please let me know when you decide to adjust the appstream modalias
> value in broadcom-sta-dkms, so I can remove the blacklist entry.

I dropped the file installation completely for now because identifying
which hardware is covered by which driver in a better way appears too
troublesome.

Could be revisited in future. See the version -5 for now, just uploaded.

Regards,
Eduard.

Bug#848743: Build problem fixed in mod_gnutls 0.8.1

[Thomas Klute]

I have confirmed that the patch in my previous mail works on i386, and
released mod_gnutls 0.8.1 to fix the build failures on 32 bit architectures.

Bug#840342:

[Jaun Mauro Fernandez]

*304.134-1 fixed the bug for me, i am using testing, glxgears
chrome/chromium and opengl all working normal now without the need of run
the apllications as root. *

Bug#848506: [Pkg-julia-devel] Bug#848506: julia: FTBFS (Memory limit reached : 687558656 > 524288000)

[Santiago Vila]

On Tue, 20 Dec 2016, Graham Inggs wrote:

> I have been unable to reproduce this build failure.
> I have tested in a sbuild unstable chroot, as well as in a Stretch VM with 2GB
> of RAM.

Could you please try building the package in a single-CPU Virtual
Machine having this:

$ENV{'DEB_BUILD_OPTIONS'} = 'parallel=1';

in .sbuildrc?

(Yes, maybe I should describe my building environment more accurately
from the beginning, not just when it is relevant).

Thanks.

Bug#848932: ITP: perl-openssl-defaults -- Version compatibility baseline for Perl OpenSSL packages

[Niko Tyni]

Package: wnpp
Severity: wishlist
Owner: Niko Tyni 

* Package name: perl-openssl-defaults
  Version : 1
  Upstream Author : Niko Tyni 
* URL : 
https://anonscm.debian.org/cgit/pkg-perl/packages/perl-openssl-defaults.git
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : Version compatibility baseline for Perl OpenSSL packages

 A subset of Perl XS module packages expose the OpenSSL binary interface
 to Perl code. This can lead to incompatibilities if these packages are
 linked against different versions of OpenSSL.
 .
 This package provides a virtual package "perl-openssl-abi-x" that
 corresponds to the libssl-dev package SONAME it was built against.
 The packages that need to stay compatible with each other can depend
 on this.
 .
 Tools are also provided for generating this dependency with minimum
 hassle. See the instructions in README.Debian.

This was prompted by Perl modules segfaulting in a partial OpenSSL 1.0
-> 1.1 transition. See #848113 for the background.

The package will be maintained in the Debian Perl Group (pkg-perl).

Bug#848610: jessie-pu: package pgpdump/0.28-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2016-12-18 at 23:42 +0100, Christoph Biedl wrote:
> CVE-2016-4021[1] hasn't been handled in jessie yet. The security team
> suggested to use an upcoming point release for this, this got ACKed
> by the stable security team. The pgpdump maintainer Jose Luis Rivas
> (CC'd) has agreed to this procedure.

Please go ahead.

Regards,

Adam

Bug#848908: jessie-pu: package shutter/0.92-0.1+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2016-12-20 at 19:12 +0100, Christoph Biedl wrote:
> CVE-2015-0854[1] hasn't been handled in jessie yet. The security team
> ACKed to use an upcoming point release for this. The shutter maintainer
> Ryan Niebur is in Cc:.

Please go ahead.

Regards,

Adam

Bug#848921: RM: libcatalyst-view-csv-perl -- ROM; Uploaded with incorrect version

[Christopher Hoskin]

> Why not simply upload the new version? The 1.5-1 version will then be
> superseded automatically.

I committed a revision to the VCS[0] which removed 1.5-1 from the
changelog (and other references to 1.5) on the grounds that the actual
upstream version 1.5 was never packaged for Debian. If you think it
preferable that I restore the 1.5-1 stanza to the changelog and add a
new 1.7 stanza after that (which is what Gregor suggested I do) then
I'm happy to do that.

[0] 
https://anonscm.debian.org/cgit/pkg-perl/packages/libcatalyst-view-csv-perl.git

Thanks.

Christopher


>

>
> Regards,
>
> Adam
>

Bug#847099: Please, update!!!

[Akim Demaille]

This is a very severe limitation, this version is broken!  Please, upgrade asap 
to the next version, which does work.

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

[Johannes Schauer]

Package: dgit
Version: 2.3
Severity: wishlist

Hi,

I just uploaded a new version of my package botch. But then I got an
email "Processing of botch_0.21-1_multi.changes" and I was like ugh... I
accidentally did "dgit push" without having done "dgit build-source"
first. So what got upload was the result of my "dgit sbuild". Would it
make sense to add a dgit configuration variable that would prevent me
from accidentally doing an upload that is not a source-only upload?
Like, a configuration option that would force me to add an option to the
command line if I *really* want to do an upload that is not source-only
which only happens rarely.

Does this make sense?

Thanks!

cheers, josch