Bug#836241: revised patch

[YOSHINO Yoshihito]

Hi,

I have missed the debian/control lines sorted.
Attaching a revised patch.

Thanks,
-- 
YOSHINO Yoshihito 
--- plasma-workspace-5.8.5/debian/control
+++ plasma-workspace-5.8.5/debian/control
@@ -139,6 +139,7 @@
  qml-module-org-kde-draganddrop,
  qml-module-org-kde-extensionplugin,
  qml-module-org-kde-kcoreaddons,
+ qml-module-org-kde-kholidays,
  qml-module-org-kde-kquickcontrols,
  qml-module-org-kde-kquickcontrolsaddons,
  qml-module-org-kde-kwindowsystem,

Bug#832613: Trademark issues (Was: kronatools_2.7+dfsg-1_amd64.changes REJECTED)

[Andreas Tille]

Hi,

I re-uploaded now with name radiant as suggested by upstream.

Kind regards

Andreas.

On Sun, Jan 15, 2017 at 06:39:51PM +0100, Andreas Tille wrote:
> Hi again,
> 
> I admit I feel a bit blocked.  Should I simply upload with another
> possibly improperly choosen name and wait for ftpmaster comments to the
> upload in new?  It seems this topic does not deserve any additional
> input and thus I might take this potential detour without further
> discussion. :-(
> 
> Kind regards
> 
>Andreas.
> 
> On Fri, Dec 16, 2016 at 09:21:06PM +0100, Andreas Tille wrote:
> > Hi Ian,
> > 
> > On Fri, Dec 16, 2016 at 12:43:37AM +, Ian Jackson wrote:
> > > Andreas Tille writes ("Re: kronatools_2.7+dfsg-1_amd64.changes REJECTED"):
> > > > 
> > > > Thanks for your torough checking. As discussed long ago[2]
> > > > 
> > > >   "KronaTools" may work, since the actual trademark is just
> > > >   "Krona". You could also use "Radiant", which was the original name
> > > >   (and still in SourceForge with a redirect). We avoided Radiant so
> > > >   our name could be trademarked, but you wouldn't have that problem
> > > >   I'm guessing.
> > > 
> > > The upstream you are dealing with, here, clearly don't really
> > > understand trademarks very well.
> > 
> > ... which makes a perfect match between me and upstream.  I naively
> > assumed that the argument given by upstream should be valid to combine
> > two quite generic words is something else than a trademarked word.
> > 
> > > If "krona" is trademarked (and that
> > > DHS page claims it is) then "kronatools" would clearly be a breach.
> > > 
> > > You'll have to call it something without the word "krona" in.
> > 
> > I simply have to trust your insight here.
> >  
> > > > It would help to hear other opinions before trying another upload to
> > > > new: What name do you think is a proper name for this project in Debian.
> > > 
> > > I haven't been able to figure out what this program does.  Your links
> > > don't give your own Description and the upstream say:
> > > 
> > >   Krona Tools is a set of scripts to create Krona charts from several
> > >   Bioinformatics tools as well as from text and XML files.
> > 
> > The ITPed package description reads:
> > 
> > Description: explore hierarchical metagenomic data with zoomable pie charts
> >  Krona allows hierarchical data to be explored with zoomable pie charts.
> >  Krona charts include support for several bioinformatics tools and raw
> >  data formats. The charts can be viewed with a recent version of any
> >  major web browser.
> > 
> > The Wiki page[1] has some enlightening examples.
> >  
> > > Either this is circular, or "Krona chart" was a medical (or
> > > medico-informatical) term before this software existed and it
> > > shouldn't have been trademarked (although I doubt anyone wants to
> > > fight that).
> > 
> > I do not think that there was an older term before that should have
> > preventing the trademark (and even if I personally would not midn
> > fighting these horrible law fights).
> >  
> > > radiant-diagnostic or something maybe ?  (I see there is also a Ruby
> > > CMS called "radiant".)
> > 
> > I think radiant-graphs might come closer even if I doubt that there is
> > much confusion between the CMS and this tool and if its not packaged
> > there should be no clash.
> >  
> > I'd like to hear a word from ftpmaster if I rename the source and binary
> > package as well as the Git archive - would this be accepted for the next
> > upload.  Some kind of confirmation in advance would be helpful to do
> > more negotions right now and not after another round in the new queue.
> > 
> > Kind regards
> > 
> >   Andreas.
> > 
> > [1] https://github.com/marbl/Krona/wiki
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#836241: patch

[YOSHINO Yoshihito]

Control: tags -1 + patch

Dear maintainer,

Attached is a trivial patch which should fix the problem.

Thanks,
-- 
YOSHINO Yoshihito 
--- a/debian/control
+++ b/debian/control
@@ -143,6 +143,7 @@
  qml-module-org-kde-kquickcontrolsaddons,
  qml-module-org-kde-kwindowsystem,
  qml-module-org-kde-solid,
+ qml-module-org-kde-kholidays,
  qml-module-qt-labs-folderlistmodel,
  qml-module-qtgraphicaleffects,
  qml-module-qtqml-models2,

Bug#854837: Package dicompyler does not work

[Andreas Tille]

Hi Vojtech,

thanks for your bug report

On Sat, Feb 11, 2017 at 12:22:54AM +0100, Vojtech Kulvait wrote:
> Package: dicompyler
> Version: 0.4.2-2
> 
> When invoking dicompyler it warns that there is unmet dependency. If I
> manualy remove the dependency from system, program does not work.

Could you please more verbose what dependency you are talking about?
I also wonder how dicompyler is warning about something is missing and
you remove it *afterwards* ?

> I am
> using Jessie AMD64 and the same problem occur on two independent computers.

Your bug report looks strange since all the system information that
is created by reportbug is stripped.  Usually the system information
is contained but you seem to have manually removed it.  It would
help if you run `reportbug dicompyler` again and post the editor
content into this bug report.

With the current information we can not really do anything to fix
the issue.  I do not get any warning on my machine after installing
dicompyler.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#854851: Please remove or replace lenma images

[Haruki TSURUMOTO]

Package: binaryornot
Version: 0.4.0-1
Severity: serious

tests/files/lena.gif and tests/files/lena.jpg are not DFSG-compatible
files. So please remove or replace with other free images.

-- 
Haruki TSURUMOTO
PGP Fingerprint:3718 C84E 4EDA 1B5C 4F26 8639 9D3D EE3F 63A6 000E



signature.asc
Description: OpenPGP digital signature

Bug#851876: slt: FTBFS (Test killed with quit: ran too long (10m0s))

[Roger Shimizu]

Control: tag -1 +patch

Enclosed is the patch to disable the test.
I already tried to set the test timeout to 30 minutes, but it still
fails on 1-core amd64 box (virtualbox environment).
So the patch is the tentative fix so far.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
From: Roger Shimizu 
Date: Sat, 11 Feb 2017 15:04:59 +0900
Subject: [PATCH] debian/rules: Disable the test temporarily

Test still fails on 1-core amd64 box, after setting 30 minutes timeout

Closes: #851876
---
 debian/changelog | 10 ++
 debian/rules |  5 +
 2 files changed, 15 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 633b11e..f6eec41 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+slt (0.0.git20140301-4) UNRELEASED; urgency=medium
+
+  [ Roger Shimizu ]
+  * debian/rules:
+- Disable the test temporarily.
+  Because test still fails on 1-core amd64 box, after setting 30 minutes
+  timeout (Closes: #851876).
+
+ -- Roger Shimizu   Sat, 11 Feb 2017 15:02:32 +0900
+
 slt (0.0.git20140301-2) unstable; urgency=medium
 
   * wrap-and-sort -ast
diff --git a/debian/rules b/debian/rules
index e8db377..f412797 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,3 +8,8 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 override_dh_installman:
 	ronn < man/slt.8.ronn >debian/slt.8
 	dh_installman
+
+# still fails on 1-core amd64 box, after set 30 minutes timeout
+# so disable the test temporarily
+override_dh_auto_test:
+	#dh_auto_test -- -timeout 30m

Bug#811980: libusbtc08: FTBFS with GCC 6: symbol changes

[Nobuhiro Iwamatsu]

Control: tags 811980 + patch

Hi,

> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
> 
> Note that only the first error is reported; there might be more.  You
> can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
> you can set CC=gcc-6 CXX=g++-6 explicitly.
> 
> You may be able to find out more about this issue at
> https://gcc.gnu.org/gcc-6/changes.html
> 
> 

I create a patch which update symboles file.
Could you check this patch?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
diff -Nru libusbtc08-1.7.2/debian/changelog libusbtc08-1.7.2/debian/changelog
--- libusbtc08-1.7.2/debian/changelog   2015-08-27 05:37:20.0 +0900
+++ libusbtc08-1.7.2/debian/changelog   2017-02-11 15:30:30.0 +0900
@@ -1,3 +1,10 @@
+libusbtc08 (1.7.2-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update debian/libusbtc08-1.symbols (Closes: #811980).
+
+ -- Nobuhiro Iwamatsu   Sat, 11 Feb 2017 15:30:30 +0900
+
 libusbtc08 (1.7.2-5) unstable; urgency=medium
 
   * Bump Standards-Version to 3.9.6, no changes needed.
diff -Nru libusbtc08-1.7.2/debian/libusbtc08-1.symbols 
libusbtc08-1.7.2/debian/libusbtc08-1.symbols
--- libusbtc08-1.7.2/debian/libusbtc08-1.symbols2015-08-27 
05:37:20.0 +0900
+++ libusbtc08-1.7.2/debian/libusbtc08-1.symbols2017-02-11 
15:30:30.0 +0900
@@ -67,9 +67,6 @@
  _ZN13PicoUsbDevice4InitEv@Base 1.7.2
  _ZN13PicoUsbDevice5CountEt@Base 1.7.2
  _ZN13PicoUsbDevice9EnumerateEPPS_jt@Base 1.7.2
- (optional=gccinternal)_ZN13PicoUsbDeviceD0Ev@Base 1.7.2
- (optional=gccinternal)_ZN13PicoUsbDeviceD1Ev@Base 1.7.2
- (optional=gccinternal)_ZN13PicoUsbDeviceD2Ev@Base 1.7.2
  _ZN13ReadingBuffer10AddReadingEf@Base 1.7.2
  _ZN13ReadingBuffer10AddReadingEfb@Base 1.7.2
  _ZN13ReadingBuffer12BufferIsFullEv@Base 1.7.2
@@ -154,14 +151,16 @@
  _ZN22TC08DeviceInternalDataC2Ev@Base 1.7.2
  _ZN26TC08EnumeratorInternalDataD1Ev@Base 1.7.2
  _ZN26TC08EnumeratorInternalDataD2Ev@Base 1.7.2
- 
_ZNSt6vectorIP12tTCDataTableSaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_@Base
 1.7.2
- 
(optional=templinst)_ZNSt6vectorIP15linux_usbfs_urbSaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_@Base
 1.7.2
- 
_ZNSt6vectorIP16TC08DeviceHandleSaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_@Base
 1.7.2
+ 
_ZNSt6vectorIP12tTCDataTableSaIS1_EE19_M_emplace_back_auxIJRKS1_EEEvDpOT_@Base 
1.7.2
+ 
_ZNSt6vectorIP15linux_usbfs_urbSaIS1_EE19_M_emplace_back_auxIJRKS1_EEEvDpOT_@Base
 1.7.2
+ 
_ZNSt6vectorIP16TC08DeviceHandleSaIS1_EE19_M_emplace_back_auxIJRKS1_EEEvDpOT_@Base
 1.7.2
  _ZNSt6vectorIP16TC08DeviceHandleSaIS1_EED1Ev@Base 1.7.2
  _ZNSt6vectorIP16TC08DeviceHandleSaIS1_EED2Ev@Base 1.7.2
- 
_ZNSt6vectorIP18EndpointDescriptorSaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_@Base
 1.7.2
- 
_ZNSt6vectorIPN14PicoDownloader10DeviceSpecESaIS2_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS2_S4_EERKS2_@Base
 1.7.2
- 
(optional=templinst)_ZNSt6vectorIPcSaIS0_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS0_S2_EERKS0_@Base
 1.7.2
+ 
_ZNSt6vectorIP18EndpointDescriptorSaIS1_EE19_M_emplace_back_auxIJRKS1_EEEvDpOT_@Base
 1.7.2
+ 
_ZNSt6vectorIPN14PicoDownloader10DeviceSpecESaIS2_EE12emplace_backIJS2_EEEvDpOT_@Base
 1.7.2
+ 
_ZNSt6vectorIPN14PicoDownloader10DeviceSpecESaIS2_EE19_M_emplace_back_auxIJRKS2_EEEvDpOT_@Base
 1.7.2
+ 
_ZNSt6vectorIPN14PicoDownloader10DeviceSpecESaIS2_EE19_M_emplace_back_auxIJS2_EEEvDpOT_@Base
 1.7.2
+ _ZNSt6vectorIPcSaIS0_EE19_M_emplace_back_auxIJRKS0_EEEvDpOT_@Base 1.7.2
  _ZTI13PicoUsbDevice@Base 1.7.2
  _ZTI14PicoDownloader@Base 1.7.2
  _ZTI18PicoLinuxUsbDevice@Base 1.7.2
@@ -170,7 +169,6 @@
  _ZTS14PicoDownloader@Base 1.7.2
  _ZTS18PicoLinuxUsbDevice@Base 1.7.2
  _ZTS20PicoDownloader_Linux@Base 1.7.2
- (optional=gccinternal)_ZTV13PicoUsbDevice@Base 1.7.2
  _ZTV14PicoDownloader@Base 1.7.2
  _ZTV18PicoLinuxUsbDevice@Base 1.7.2
  _ZTV20PicoDownloader_Linux@Base 1.7.2


signature.asc
Description: PGP signature

Bug#789834: golang-doozer: FTBFS: cannot find package [..] goprotobuf/proto

[Haruki TSURUMOTO]

Hi,

I think this FTBFS has already solved.

-- 
Haruki TSURUMOTO
PGP Fingerprint:3718 C84E 4EDA 1B5C 4F26 8639 9D3D EE3F 63A6 000E



signature.asc
Description: OpenPGP digital signature

Bug#854136: jhc: B-D on unavailable libghc-hssyck-dev

[Kiwamu Okabe]

On Sat, Feb 4, 2017 at 9:33 PM, Andreas Beckmann  wrote:
> libghc-hssyck-dev was removed from Debian in 2015 ...

Unfortunately, the jhc website is temporarily shutdown.
Please wait re-bootup the website...

Best regards,
-- 
Kiwamu Okabe at METASEPI DESIGN

Bug#844396: linux-image-4.8.0-1-686-pae: hitting any key make the system halt

[Jean-Jacques Rétorré]

sam. 11 févr. 2017,  Roger Shimizu  disait :

> Dear Jean-Jacques,
>
>> linux-image-4.8.0-1-686-pae: hitting any key make the system halt
>> There is no problem with an external keyboard when I  post with it.
>
> Did you try latest 4.9 series kernel in testing?
> Same behavior?

I done and all is fine.
Thank you

JJ R

Bug#750895: python3-tempita: doesn't work with python 3.3

[Soramichi AKIYAMA]

Hi,

1. I observed exactly the same occurs also with stretch and Python 3.6.0.
 I believe any future versions will suffer from the same error because it stems 
from the different ways
 how encoding and bytearray are treated in Python 2.x and Python 3.x. 
2. This issue is already fixed in the upstream in this commit:
 
https://github.com/gjhiggins/tempita/commit/ce87d4c0f057880c5b0dc77e83e3eecad7f355a7
 (The previous commit of this, 75064399e7e72fd67e2a0c21c675d6289e7d1ec9, 
suffers from the same error.)

Regards,

Soramichi

-- 
Soramichi Akiyama 

Bug#854850: Upstream URL is missing

[Haruki TSURUMOTO]

Package: golang-doozer
Version: 0.0~git20130909-1
Severity: wishlist

Dear maintainer,
Homepage's URL(https://github.com/4ad/doozer) is missing.
I have searched near repository on GitHub.
But I didn't find moved repository(there are a few of same name
repository which looks like forked from this)

Thanks.
-- 
Haruki TSURUMOTO
PGP Fingerprint:3718 C84E 4EDA 1B5C 4F26 8639 9D3D EE3F 63A6 000E



signature.asc
Description: OpenPGP digital signature

Bug#854829: gnupg: tofu-default-policy ask -> Assertion "conflict_set" in get_trust failed

[Teemu Likonen]

Benedikt Wildenhain [2017-02-10 22:34:29+01] wrote:

> setting "tofu-default-policy ask" in gnupg.conf causes gnupg to crash
> when using the --fingerprint command under certain circumstances:
>
> $ gpg --fingerprint
> gpg: O j: Assertion "conflict_set" in get_trust failed 
> (../../g10/tofu.c:2780)
> Aborted
>
> $ gpg --fingerprint  o@b
> gpg: O j: Assertion "conflict_set" in get_trust failed 
> (../../g10/tofu.c:2780)
> Aborted

Confirmed on gnupg 2.1.18-3:

$ gpg --tofu-default-policy ask --fingerprint
gpg: O j: Assertion "conflict_set" in get_trust failed 
(../../g10/tofu.c:2780)

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Bug#819641: golang-github-jinzhu-gorm: FTBFS: FAIL: TestScannableSlices (0.00s)

[Haruki TSURUMOTO]

Control: clone -1 -2
Control: reassign -2 golang-github-mattn-go-sqlite3 1.1.0~dfsg1-2
Control: retitle -2 sqlite3.go's bind func causes cgo pointer panic.

Hi,
I think this runtime panic is caused by library of mattn/go-sqlite3.
Debian package version of mattn/go-sqlite3 is v1.1.0 which released at
Sep 2015. it's before Go 1.6 release. Go 1.6 changed spec of cgo pointer.
Upstream Recent Version v1.2.0 is fixed this by this
commit(https://github.com/mattn/go-sqlite3/commit/b76c61051faaf0baf3215e6f811003d98639b702)

I attached a patch ported from this commit which fixed
golang-github-jinzhu-gorm's FTBFS on my local machine.

-- 
Haruki TSURUMOTO
PGP Fingerprint:3718 C84E 4EDA 1B5C 4F26 8639 9D3D EE3F 63A6 000E
This patch fixes cgo's pointer runtime panic
Ported from https://github.com/mattn/go-sqlite3/commit/b76c61051faaf0baf3215e6f811003d98639b702Index: golang-github-mattn-go-sqlite3-1.1.0~dfsg1/sqlite3.go
===
--- golang-github-mattn-go-sqlite3-1.1.0~dfsg1.orig/sqlite3.go	2015-09-05 23:49:54.0 +0900
+++ golang-github-mattn-go-sqlite3-1.1.0~dfsg1/sqlite3.go	2017-02-11 14:16:40.738620174 +0900
@@ -480,11 +480,11 @@
 		case float64:
 			rv = C.sqlite3_bind_double(s.s, n, C.double(v))
 		case []byte:
-			var p *byte
-			if len(v) > 0 {
-p = &v[0]
+			if len(v) == 0 {
+rv = C._sqlite3_bind_blob(s.s, n, nil, 0)
+			} else {
+rv = C._sqlite3_bind_blob(s.s, n, unsafe.Pointer(&v[0]), C.int(len(v)))
 			}
-			rv = C._sqlite3_bind_blob(s.s, n, unsafe.Pointer(p), C.int(len(v)))
 		case time.Time:
 			b := []byte(v.UTC().Format(SQLiteTimestampFormats[0]))
 			rv = C._sqlite3_bind_text(s.s, n, (*C.char)(unsafe.Pointer(&b[0])), C.int(len(b)))


signature.asc
Description: OpenPGP digital signature

Bug#824442: and conflict needs to be resolved

[Niels Thykier]

On Mon, 16 May 2016 03:12:51 +0100 Ben Hutchings 
wrote:
> Source: glibc
> Version: 2.22-7
> Severity: serious
> 
> (Continued from bug #822393.)
> 
> glibc's  should check whether  has already been
> included and, if so, avoid making conflicting definitions.
> 
> Including the headers in the opposite order works since this change in
> Linux 4.6:
> https://git.kernel.org/linus/4a91cb61bb995e5571098188092e296192309c77
> 
> Ben.
> 
> -- 
> Ben Hutchings
> 73.46% of all statistics are made up.

Hi,

Any news on this bug?

~Niels

Bug#854848: libsofia-sip-ua0: UDP transport and missing line wrap in log message

[Holger Freyther]

Package: libsofia-sip-ua0
Version: 1.12.11+20110422.1-2
Severity: important

Dear Maintainer,

the UDP transport will complain if tport_recv_dgram is called bu the
pending messagr has size 0. The SU_DEBUG message is lacking a \n at
the end, resulting in messing up the log of this and other messages.

As there is no active upstream/fork right now, please consider applying
this trivial patch. It makes working with Osmocom/OpenBSC more nice.

commit ef79da5cf1853d0cfa0f8b7b1f6fe1e621251c86
Author: Holger Hans Peter Freyther 
Date:   Sat Feb 11 11:59:10 2017 +0700

udp: Add missing \n in the log statement

Without this \n a line wrapping is missing and the log will be
printed over and other log messages begin at the wrong place.

diff --git a/libsofia-sip-ua/tport/tport_type_udp.c 
b/libsofia-sip-ua/tport/tport_type_udp.c
index 8d0f2de..7f91999 100644
--- a/libsofia-sip-ua/tport/tport_type_udp.c
+++ b/libsofia-sip-ua/tport/tport_type_udp.c
@@ -321,7 +321,7 @@ int tport_recv_dgram(tport_t *self)
   }
   if (N == 0) {
 su_recv(self->tp_socket, sample, 1, 0);
-SU_DEBUG_3(("tport(%p): zero length packet", (void *)self));
+SU_DEBUG_3(("tport(%p): zero length packet\n", (void *)self));
 return 0;
   }
 #endif

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

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

Versions of packages libsofia-sip-ua0 depends on:
ii  libc62.19-18+deb8u7
ii  libssl1.0.0  1.0.1t-1+deb8u5

libsofia-sip-ua0 recommends no packages.

Versions of packages libsofia-sip-ua0 suggests:
pn  sofia-sip-doc  

-- no debconf information

Bug#854847: patch

[YOSHINO Yoshihito]

Control: tags -1 + patch

Dear maintainer,

I'm attaching a small patch to fix this problem as suggested by upstream
https://github.com/neutrinolabs/xrdp/commit/9c31bd5cc428d912194fc11d5706520473922853#commitcomment-20822199

I would very much appreciate it if the fix would be included in stretch,
because this bug causes normal Japanese users to get incorrect keyboard
input.

Thanks in advance,
-- 
YOSHINO Yoshihito 
--- a/xrdp/xrdp_keyboard.ini
+++ b/xrdp/xrdp_keyboard.ini
@@ -62,6 +62,9 @@
 rdp_layout_fr=0x040C
 rdp_layout_it=0x0410
 rdp_layout_jp=0x0411
+rdp_layout_jp=0xe0010411
+rdp_layout_jp=0xe0200411
+rdp_layout_jp=0xe0210411
 rdp_layout_kr=0x0412
 rdp_layout_ru=0x0419
 rdp_layout_se=0x041D

Bug#804908: Re: Bug#804908: service is not started under systemd

[Nobuhiro Iwamatsu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: tags 804908 + pending

Hi,

Thanks for your report.

>Am 12.11.2015 um 20:19 schrieb Michael Biebl:
>> That is a symlink though, which is only created if the user explicitly
>> runs "systemctl enable --user obex.service", which in my case will
>> result in
>> Created symlink from
>> /home/michael/.config/systemd/user/dbus-org.bluez.obex.service to
>> /usr/lib/systemd/user/obex.service.
>> 
>> 
>> There is no infrastructure to run that systemctl enable command for
>> every user and I think obexd should be enabled by default. I therefor
>> suggest to change /usr/share/dbus-1/services/org.bluez.obex.service and
>> use
>> SystemdService=obex.service
>
>
>An alternative is to enable the user service system wide via
>systemctl enable --global obex.service
>
>Unfortunately, we don't have support for such services in
>dh_systemd/init-system-helpers (yet) and simply running systemctl enable
>in postinst is discouraged.
>So for now I think it's best if SystemdService=obex.service is used,
>which doesn't require explicit enablement.
>

I see.
I will fix this by changing SystemdService to obex.service in 
org.bluez.obex.service.

Best regards,
  Nobuhiro

- -- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEXmKe5SMhlzV7hM9DMiR/u0CtH6YFAlienrsACgkQMiR/u0Ct
H6b97g//fHBKaUhHHd1yMj3kKJwEtG/0qM2qgZHXn1d6cfgRDuJ/if0vtPAm9AUU
B4zrvzAm9xXGlhOz09PKdYt7qniHG5S3D5Ogi6V5oS7Jd5e2B3z6mZLn4X1kcVon
xNZt6BFNiYyi/3Mo24aGPav0Rct1x6Y5nhw8+teOTyGyATvqB73x2tDpJEt4hY7h
M7/pgvhOpe+CPF5aZKKtH7ayqtpMmVf++SCLyJVXHYAaZ3I7FTlEROFKyQpMHCFG
zkASzZWp6OPLEJR79JMEBLAp+oSRaNFq00Z1Nun8FErJ0/9aIoQzbU/k4yszU0im
be3Ni/pEY6EpIHMF0d34Fk+PrcjDeCVtIHK2YIsUO1w92QPcB26ZYGuj+7pTGnh1
mK20RMqJDN4Pc5cedTFgtZqYryzmXs5GRr+nxKYXRmRbiyfW3lYwtJipYOROSxfv
NuLK9F2FjPvs9Ao1aT+5fSWSZw5NWH7OprUZqiDxWfyDjguJYit9lTJ+kv+0jywc
i9fBx50YMcw3YqOwIfHkFJ7e1kyXHmoHBWhQBo3x2o8ugMbeqh5R1aksNFgyezo2
BuTS88iQQE/wS4I15IpX9wTH32yZwV1g2ueZhW+spT/qmTdRpI5EZvUGjHqo9oqY
Jaur9tKQ+8ZXmb9dF+wIXNwbEuCHtTRguygud2ivU1P7RnzCRXs=
=eDBS
-END PGP SIGNATURE-

Bug#852321: Users which has soundfont packages can use this package

[Kei Hibino]

Control: severity -1 important

Documentation about configuration exists in
/usr/share/doc/timidity/README.Debian

, and configuration files are provided in soundfont packages like
freepats, fluid-soundfont-gm, fluid-soundfont-gs and
timgm6mb-soundfont.

Bug#854804: saned: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

[Jörg Frings-Fürst]

tags 854804 + moreinfo
thanks

Hello Kritphong,

thank you for spending your time helping to make Debian better with
this bug report.

I have add the sane-devel ML as cc.


Am Freitag, den 10.02.2017, 10:33 -0500 schrieb Kritphong
Mongkhonvanit:
> Package: sane-utils
> Version: 1.0.25-3
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> 
> Dear Maintainer,
> 
> When saned received a SANE_NET_CONTROL_OPTION packet with value_type ==
> SANE_TYPE_STRING and value_size larger than the actual length of the
> requested string, the response packet from the server contains a string
> object as long as value_size in the request. The bytes following the
> actual string appears to contain memory contents from the server.
> 

Please let me explain:

You have found one or more parts in the code where a string with an
incorrect value_size is transferred? Then please tell us where.

Or is there an other problem?

Please give us more infos and remove the tag moreinfo with your answer.


> It may be possible to trigger this bug with other packet types, but I
> have not verified this.
> 
> I have previously filed a bug in the SANE bug tracker on Alioth
> (#315576), but I received no response.
> 
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/1 CPU core)
> 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 sane-utils depends on:
> ii  adduser3.115
> ii  debconf [debconf-2.0]  1.5.60
> ii  init-system-helpers1.47
> ii  libavahi-client3   0.6.32-2
> ii  libavahi-common3   0.6.32-2
> ii  libc6  2.24-9
> ii  libieee1284-3  0.2.11-13
> ii  libjpeg62-turbo1:1.5.1-2
> ii  libpng16-161.6.28-1
> ii  libsane1.0.25-3
> ii  libsystemd0232-6
> ii  libusb-1.0-0   2:1.0.21-1
> ii  lsb-base   9.20161125
> ii  update-inetd   4.44
> 
> sane-utils recommends no packages.
> 
> Versions of packages sane-utils suggests:
> ii  avahi-daemon  0.6.32-2
> pn  unpaper   
> 
> -- debconf information excluded
> 

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#854179: [gnome-extra-icons]

[SUGIMOTO Norimitsu]

Package: gnome-extra-icons
Version: 1.1-2
Tags: patch

I wrote the patch. (fix debian/control)
Please import.

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

Debian Release: 9.0
  500 unstableftp.jp.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


-- 
SUGIMOTO Norimitsu 
--- debian/control.orig	2017-02-11 13:41:36.0 +0900
+++ debian/control	2017-02-11 13:42:10.795156258 +0900
@@ -1,7 +1,7 @@
 Source: gnome-extra-icons
 Section: x11
 Priority: extra
-Maintainer: Tiago Bortoletto Vaz 
+Maintainer: Tiago Bortoletto Vaz 
 Build-Depends: debhelper (>= 5.0.37.2), cdbs (>= 0.4.4)
 Standards-Version: 3.8.0
 Dm-Upload-Allowed: yes

Bug#854847: xrdp: fails to detect some Japanese keyboard

[YOSHINO Yoshihito]

Package: xrdp
Version: 0.9.1-5
Severity: important
Control: forward -1 https://github.com/neutrinolabs/xrdp/issues/663
Control: found -1 0.9.1~2016121126+git5171fa7-1

Dear Maintainer,

Since upstream commit
https://github.com/neutrinolabs/xrdp/commit/9c31bd5cc428d912194fc11d5706520473922853
which was introduced in 0.9.1~2016121126+git5171fa7-1, my laptop's
keyboard layout in xrdp is "us" not "jp". Reverting the commit gets back
the "jp" layout.

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

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

Versions of packages xrdp depends on:
ii  adduser  3.115
ii  init-system-helpers  1.47
ii  libc62.24-9
ii  libfuse2 2.9.7-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libopus0 1.2~alpha2-1
ii  libpam0g 1.1.8-3.5
ii  libssl1.11.1.0d-2
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  libxrandr2   2:1.5.1-1
ii  lsb-base 9.20161125
ii  ssl-cert 1.0.38

Versions of packages xrdp recommends:
ii  fuse  2.9.7-1
ii  xorgxrdp  0.9.1-5

Versions of packages xrdp suggests:
pn  guacamole  

Versions of packages xorgxrdp depends on:
ii  libc6  2.24-9
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-23]  2:1.19.1-4

Versions of packages xorgxrdp recommends:
pn  xorg  

Versions of packages xrdp is related to:
pn  vnc-server   
ii  xserver-xorg-legacy  2:1.19.1-4

-- no debconf information

Bug#853207: bluez: bluetooth.service doesn't start with systemd

[Nobuhiro Iwamatsu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: tags 853207 + moreinfo

Hi,

> Most likely the bluetooth support for your laptop is broken under linux.
> 
> The bluetooth.service file contains
> 
> ConditionPathIsDirectory=/sys/class/bluetooth
> 
> which means that systemd only tries to start the bluetooth daemon when
> the bluetooth module from the kernel is loaded which creates the above
> directory in sysfs. The bluetooth module is in turn only loaded by the
> kernel/udev when bluetooth hardware is detected. So the .service file
> behaves correctly as to only start the daemon when there is actual
> bluetooth hardware available.
> 
> Could you check if the above reasoning is correct by first directly
> loading the bluetooth kernel module (modprobe bluetooth), which should
> create /sys/class/bluetooth and then trying to start the bluetooth
> daemon (systemctl restart bluetooth.service)?
> 
> If that is the case the bug should be reassigned as a wishlist bug to
> systemd. If a condition for starting a service is not satisfied when a
> user explicitly tries to explicitly start it on the command line, it
> would be useful to report the reason for the startup failure to the
> user. This would significantly help a user to debug such an issue.
> 

Matthias, thanks for your support.
I confirmed this bug with stretch, but the same problem did not happen.

Russell, could you confirm again with Matthias's comment?

Best regards,
  Nobuhiro


- -- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEXmKe5SMhlzV7hM9DMiR/u0CtH6YFAliejjcACgkQMiR/u0Ct
H6Zs1w//eauQhMbpchGdHoeinQXqjvoV3BfFew6bYZlRPInbaKWa+HT2lGnyshA8
8Nde12OWLuJr7EOSAwt6fH56kNZl0ClWdh+1aMnyCaqys5hpycZw39PYfHTiYT2f
w3jXGtJE9Xk1FtVrJSmOb8FGmgtYuHygr42VThpPv9M0ANveVLNCdq8ofoEKLLKI
1Js5mXHo4ASgNXckBiX4+yLz4v3SB/OrCZMfpuEihU3H3iugg8hv2Z6mrn7fBw1c
61VzUg2YhLBSyR8vNe+yHw6mSJ0BSGp3kxbyn/LY67OVf4iJTLwCSQmOefBr7wTv
UBew1QBiI9z4h6vdY+p+dxFEhOHSokr8FPZgaA4JD7c7IHiVtBqEVBdu9alvBzkf
MmRBWcE4z4S2TYDfA/O6vfPywsr4RWTWt9fi7iuwAnuFrHK6e0YYK8PmIqbWEE4x
umntGaqd9dOKDv/UwbHfHduBZYazywrwlad4z+Fkn7A/q1ce8wDrM7YaeqKQvq5i
HUqrDUI2/Ayqy/4rx7WPPjkfhJDmciiXfiJOwldRtuAKYHfnDsc4RJjiiQRitsjx
RmgCzW8SH3SH0kaiCYy5k6/NGl7HXXJA3ht1bjy+nmgksqg67hL6NhQzbBPoAZxn
SA9X1C8y0RjBJUqK0NZt7CNyGYP5YPMLZhk9ll9KImcXZxuUcY4=
=Hon7
-END PGP SIGNATURE-

Bug#771187: [primesense-nite-nonfree]

[SUGIMOTO Norimitsu]

Package: primesense-nite-nonfree
Version: 0.1.1

--- Please enter the report below this line. ---

Dear Maintainer.

I found same bug in launchpad.

https://bugs.launchpad.net/ubuntu/+source/primesense-nite-nonfree/+bug/1384699

I wrote the patch, please import.


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

Debian Release: 9.0
  500 unstableftp.jp.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-===
build-essential| 12.3
debconf| 1.5.60
 OR debconf-2.0| 
dpkg-dev   | 1.18.22
debhelper  | 10.2.5
devscripts | 2.17.1
fakeroot   | 1.21-3.1
wget   | 1.18-4
unzip  | 6.0-21
gnupg  | 2.1.18-4
libopenni-dev  | 1.5.4.0-14
openni-utils   | 1.5.4.0-14


Package's Recommends field is empty.

Suggests   (Version) | Installed
-+-===
osceleton| 



--- Output from package bug script ---
Debian version: 9.0
Architecture: amd64
Package version: 0.1.1
MD5 checksums:
md5sum: '/var/cache/primesense-nite-nonfree/*': 
??
ee3a78fc8a546c5cd4be21668a3a7d8f  
/usr/lib/primesense-nite-nonfree/primesense-nite-nonfree-make-deb


-- 
SUGIMOTO Norimitsu 
--- update-primesense-nite-nonfree.orig	2017-02-11 12:18:43.313173386 +0900
+++ update-primesense-nite-nonfree	2017-02-11 12:34:43.172894818 +0900
@@ -18,10 +18,14 @@
 #URL64="http://www.openni.org/downloadfiles/opennimodules/openni-compliant-middleware-binaries/latest-unstable/112-primesense-nite-unstable-build-for-ubuntu-10-10-x86-64-bit-v1-3-1/download";
 #URL32="http://www.openni.org/downloads/nite-bin-linux-x86-v1.5.2.21.tar.bz2";
 #URL64="http://www.openni.org/downloads/nite-bin-linux-x64-v1.5.2.21.tar.bz2";
-URL32=http://www.openni.org/wp-content/uploads/2012/12/NITE-Bin-Linux-x86-v1.5.2.21.tar.zip
-URL32_SHA256SUM=8be3bf3b325ff6a3538381e8aacf2b7632a4dab422c1bd54ac7ee81d75a140e4
-URL64=http://www.openni.org/wp-content/uploads/2012/12/NITE-Bin-Linux-x64-v1.5.2.21.tar.zip
-URL64_SHA256SUM=57cd7daa38e82321270179574c3a96b9e8e92348b4c7011c8d58af3d1b2fdb45
+#URL32=http://www.openni.org/wp-content/uploads/2012/12/NITE-Bin-Linux-x86-v1.5.2.21.tar.zip
+#URL32_SHA256SUM=8be3bf3b325ff6a3538381e8aacf2b7632a4dab422c1bd54ac7ee81d75a140e4
+#URL64=http://www.openni.org/wp-content/uploads/2012/12/NITE-Bin-Linux-x64-v1.5.2.21.tar.zip
+#URL64_SHA256SUM=57cd7daa38e82321270179574c3a96b9e8e92348b4c7011c8d58af3d1b2fdb45
+URL32=http://openni.ru/wp-content/uploads/2013/10/NITE-Bin-Linux-x86-v1.5.2.23.tar.zip
+URL32_SHA256SUM=00932c2a5f1c650a3c6bd527aef81ee98165fc1598f96eb941d8ab68770fe0d7
+URL64=http://openni.ru/wp-content/uploads/2013/10/NITE-Bin-Linux-x64-v1.5.2.23.tar.zip
+URL64_SHA256SUM=4d75064c533308bcd9d24f54a6250389a3fd1a5371c017d07ae9e5bf15dc839d
 
 downloadedfilename=primesense-nite.tar.bz2.zip
 downloadedfile=/tmp/primesense-nite.tar.bz2.zip

Bug#851750: kpatch: module FTBFS for Linux 4.9

[Soramichi AKIYAMA]

Hi,

this issue is already fixed in the upstream by this commit:
https://github.com/dynup/kpatch/commit/586feb40fe116b70d3ac752359706c3e1fafe4ea

$ git clone https://github.com/dynup/kpatch/
$ cd kpatch
$ git checkout ab5e1290bb94231d7925384db01ed62eeecb7511 # one commit before 
this issue is fixed
$ make
# causes the same error as this report

$ git checkout 586feb40fe116b70d3ac752359706c3e1fafe4ea
$ make
# build works with no errors or warnings


Regards,

Soramichi

-- 
Soramichi Akiyama 

Bug#844396: linux-image-4.8.0-1-686-pae: hitting any key make the system halt

[Roger Shimizu]

Dear Jean-Jacques,

> linux-image-4.8.0-1-686-pae: hitting any key make the system halt
> There is no problem with an external keyboard when I  post with it.

Did you try latest 4.9 series kernel in testing?
Same behavior?

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

Bug#854816: remmina: Blank screen on ssh connections

[Jörg Frings-Fürst]

reassign 854816 vte2.91/0.46.1-1
thanks

Hello Marek,

thank you for spending your time helping to make Debian better with
this bug report.

I reassign this bug to the package vte2.91. The bug comes from there.

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#820381: rar crashes.

[Roger Shimizu]

Dear Martin,

I see this issue on RC bug list.

> I've just pushed a new version of rar to the repo, can you let me know
> if this has fixed the issue?

I don't see there's a Vcs-* in debian/control [0].
And latest release in debian was on year 2015 [1].

[0] https://sources.debian.net/src/rar/2:5.3.b2-1/debian/control/
[1] https://tracker.debian.org/news/703609

So where's the new version, please?

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

Bug#852215: FTBFS on non-release architectures

[James Clarke]

On 3 Feb 2017, at 15:28, Cyril Brulebois  wrote:
> James Clarke  (2017-01-22):
>> As you know, debian-installer does not build on non-release
>> architectures, since it tries to build for stretch. Some architectures
>> also have some of the needed udebs in the unreleased suite, such as
>> sparc-utils on sparc64. The attached patch lets me build on sparc64
>> even after a `dch --release`, and I would assume on other ports
>> architectures too. Is this something you would consider applying?
> 
> As mentioned on IRC a tiny while back, I can understand how this is
> necessary since ports are going to have specific packages (e.g.
> bootloaders) which don't really make sense to have in the official
> archive.
> 
> It looks to me like your proposed patch makes it a bit hard to
> understand what's happening in debian/rules, and I'd like to propose
> a different take on this, by first having the usual daily builds vs.
> release heuristics, then having overrides for ports. I've pushed a
> pu/support-for-ports branch for you folks to double check:
>  
> https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=pu/support-for-ports&id=6580c874c5263fb500f5b222f7d4f6a1c17ac532
>  
> https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=pu/support-for-ports&id=1ca77bc7c8aaa7c4948905bd0dc4ca8b397a0c00
> 
> I removed amd64 from RELEASE_ARCHES so that amd64 would be considered
> like a port (2005 called, it wants its sarge-amd64 release back!) and
> it seems to work just fine, with a warning about an invalid mirror
> when unreleased isn't found there. So hopefully that shouldn't make
> it any harder for kfreebsd-* (which currently FTBFS anyway…).
> 
> Please let me know what you think and which results you get with a
> real test on unreleased ports.

Some data points:

alpha  : Missing srm-reader in archive. Builds after adding a
 locally-built .udeb to localudebs (and working around the
 crazy broken mirror setup on electro [one of the local mirrors
 has no unstable -> sid symlink, but has an unreleased -> sid
 symlink]*...  but that's not debian-installer's problem). If
 alpha porters want installer images, I guess they should
 upload and maintain srm-reader in unreleased.
hppa   : Builds after applying patch from #852260.
hurd-i386  : Builds without any further changes.
kfreebsd-amd64 : Builds if the netboot gtk image size limit is increased by 2M.
sparc64: Builds without any further changes.

These were all done in chroots with just the build-deps installed. None of the
build results have been tested.

Regards,
James

* This would not be a problem for http mirrors, since debian-installer would
  discard the mirror as invalid when generating the udeb sources.list, but
  since this is a file: mirror, it doesn't check for validity and assumes it
  works. In theory debian-installer could check file: mirrors too, which would
  work around this insanity.

Bug#854844: sofia-sip: new upstream home

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2017-02-11 02:45:28)
> Another fork at https://github.com/AzettiNetworks/sofia-sip has a 
> range of patches mainly fixing memory leaks - possibly interesting to 
> cherry- pick but does not seem steadily maintained like the 
> Linphone.org fork.

Above has been filed as separate bug#854846.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#852959: Pending fixes for bugs in the prometheus package

[pkg-go-maintainers]

tag 852959 + pending
thanks

Some bugs in the prometheus package are closed in revision
6b977c959a7fa2a9460507a5d923dcbdd825c239 in branch 'debian/sid' by
Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/prometheus.git/commit/?id=6b977c9

Commit message:

Disable "long" tests in arm*, which take way too long and run out of 
memory. Closes: #852959.

Bug#854846: sofia-sip: memory leaks in stun, msg_parser and test code

[Jonas Smedegaard]

Source: sofia-sip
Severity: normal
Tags: patch

The Sofia-SIP fork at https://github.com/AzettiNetworks/sofia-sip
includes a range of bugfixes for memory leaks in stun, msg_parser
and test code:

337b0ebb fix absence of Max-forwards in ACK message sent by nta_msg_ackbye()
0f8f6817 Fix default automake and aclocal versions (#3560)
fb4ce3a0 Fix crash in function nua_session_client_response
3eb16bc2 torture_su_glib: Memory leaks and include
d5cd7292 test_auth_digest: Fix memory leaks
417f39d1 test_nth: Fix memory leaks and invalid usage
970f279c tport: Honour REUSE/FRESH in tport_send
5743974a test_tport: Fix tests and memory leaks.
13eaa715 check_nta: Fix several memory leaks
ae25933c s2check: Fix memory leak in setup/teardown
2e3c65f7 test_nta_api: Tests fixes
6943c5e2 nta tests: Remove TEST_ENVIRONMENT variable
d4e01b30 msg_parser: Fix invalid memory access when parsing NULL
fc96f4d9 sip_tests: Several fixes and tests added
c24c5db9 m4/sac-general.m4: Avoid compiler warnings in __func_ detection
f74cf82d tptag_dos_ref: Fix sign inconsistency
824fc59b tstdef: Do not use a dummy variable when running with asan
f60b6db7 test_http: Fix memory leaks
31a82022 test_sip_msg: Fix memory leak
461b4f1f torture_sip: Fix memory leaks
70aa35ea test_sip_msg: Fix tautological comparisons
63165eb3 torture_url: Fix memory leak
7b37bbb3 torture_sdp: Fix memory leak
06853c74 test_sresolv: Fix incorrect memset
bb903305 torture_sresolv: test_cache Fix invalid memory usage
ed84ab9f torture_sresolv: test_api_errors: fix memory leak
923e1264 torture_su_timer: Address memory leak
8cf2bcf7 torture_su_root: Test actual sent bytes with sendto
e18963ad msg_parser: Fix bug with malformed SIP Messages
8f9c19f0 gitignore: Add test output files
ce4bb52a stun_mini: Avoid possible memory leaks and dead assigments
ac0e8491 Removed unnecessary debug messages
f72cc67a Added new tag NUTAG_SUB_NO_REFRESH to allow blocking subscribe 
refreshing
2ab15662 sres_cached_answers_sockaddr: Return directly if no cached records are 
found
ed8a1b0c torture_sip: Fix invalid date
04a20987 Fix default automake and aclocal versions (#3560)
2c9dc21d Removed unnecessary debug messages
43497510 Added new tag NUTAG_SUB_NO_REFRESH to allow blocking subscribe 
refreshing
8cb7baaa Fix crash in function nua_session_client_response

 - Jonas

Bug#854845: sofia-sip: several memory leaks in TLS-related code

[Jonas Smedegaard]

Source: sofia-sip
Severity: normal
Tags: patch

The Sofia-SIP fork at https://github.com/unispeech/sofia-sip includes
several fixes for memory leaks in TLS-related code - and some other
bugfixes seemingly relevant to cherry-pick:

d10884f2 Fixed memory leak in processing of SIP OPTIONS request.
94cb919b Disable warnings related to the use of inet_ntoa() and friends being 
compiled with Platform Toolset >= 120 (affected since VS2013 Update 3).
b8c0dfd9 Fixed memory leaks which may occur on verification of peer certificate 
once the TLS connection is established.
92fde2e3 TLS type (master or slave) is set upon creation and should not be 
copied from master to slave.
a4a93f01 Fixed the order: tls->con must be freed first and only then tls->ctx.
c51fee2e Fixed memory leak on TLS connection cleanup.
a2bf3645 Fixed tport logging to dump an entire SIP message composed of multiple 
iovecs.
90d4c346 While logging SIP messages, compose a timestamp based on the current 
date and local time.
2bd9a037 Fixed compilation warnings encountered while building Sofia-SIP with 
HAVE_OPENSSL and HAVE_TLS enabled.
ca433857 Fixed compilation warnings encountered while building for x64 platform.
1806fdb6 Initialized done_once with 0 instead of 1, since Sofia-SIP could 
attempt to delete a data key which was not created.
eca23c7a Fixed potential crash in nta.c by ensuring char *tps[9] is not used 
out of its declaration scope.
6748e2fb Fixed memory leaks occured upon failure in nua_stack initialization.
c2db5ff6 Fixed compilation warning in su_timer.
3ffc4445 Fixed compilation warning in msg_parser.


 - Jonas

Bug#854797: pinentry: Add pinentry-emacs package

[Daniel Kahn Gillmor]

Hi Florian--

On Fri 2017-02-10 08:26:11 -0500, Florian Margaine wrote:
> Adding the pinentry-emacs package can let emacs users enter their PIN
> into emacs' minibuffer itself, along with an emacs package. The source
> is already available, it's just about enabling more options in the
> configure step. I understand that this has been voluntarily disabled,
> but do not understand why, given that it does not cause any
> side-effect, and only helps in providing one more package.

I have not had any near-term plans to add pinentry-emacs to the debian
packaging, because it's not clear to me what it adds that
pinentry-mode=loopback (which is now the default configuration for
gpg-agent) already provides.

furthermore, i think that it's generally better security policy to treat
the agent as an oracle, rather than expecting to provide
confirmation/passphrases/whatever in the same channel as the request --
in particular, i want to encourage and enable the use of an agent that
does *not* permit anything like loopback mode, but is instead isolated
From the requesting process completely.  In that scenario, the
requesting process never sees or handles passphrases or secret keys, and
cannot approve or reject requests; the agent is autonomous and
independent from its client, which allows for stronger isolation and
security guarantees.

Back on 2016-06-09, in Message-Id: m3r3c6hgch.fsf-u...@gnu.org on
gnupg-de...@gnupg.org,
Daiki Ueno  (cc'ed here) wrote:

>>If the loopback pinentry evolves into general purpose mechanism, I would
>>rather suggest to remove the Emacs specific stuff entirely.  The
>>rationale is:
>> 
>>- The immediate motivation behind the Emacs pinentry was that the
>>  loopback pinentry had some limitations when used as a replacement of
>>  gpg1's passphrase prompt, e.g. [1], which was fixed a while ago.
>> 
>>- Debian seems unlikely to build in the Emacs mode with Pinentry[2].
>>  That means to add another (non-working) configuration vector and
>>  upstream Emacs cannot rely on that feature[3].
>> 
>>What do you think?  Is there really anything that can be done better
>>with the Emacs pinentry than with the loopback pinentry?
>> 
>>Footnotes: 
>>[1]  https://bugs.gnupg.org/gnupg/issue1976
>> 
>>[2]  https://bugs.gnupg.org/gnupg/issue2034
>> 
>>[3]  http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/epg.el#n607

Certainly pinentry-emacs isn't going to be distributed by default, since
there are many more non-emacs users of gpg-agent than there are users of
gpg-agent.

But if you or Daiki Ueno has other suggestions or plans about the future
of this functionality, i'm happy to reconsider this within debian.  Any
thoughts?

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#854232: Now works

[Heiko Ernst]

My notebook its a asus pro7bs and after installation the bumblebee kde start.

Bug#854844: sofia-sip: new upstream home

[Jonas Smedegaard]

Source: sofia-sip
Severity: wishlist
Tags: upstream

Last change to sofia-sip at sourceforge.net was in 2011.

It seems linphone.org has steadily maintained their fork, arguably
effectively taking over as new upstream.

Seems their source is maintained at git://git.linphone.org/sofia-sip.git
with Github mirror https://github.com/BelledonneCommunications/sofia-sip
- both places using branch "bc" (with branch "master" preserving the
previous home sourceforge.net).

Another fork at https://github.com/AzettiNetworks/sofia-sip has a range
of patches mainly fixing memory leaks - possibly interesting to cherry-
pick but does not seem steadily maintained like the Linphone.org fork.

I suggest to treat the linphone.org fork as new upstream of sofia-sip
and consider applying the Azetti changes as well.

 - Jonas

Bug#740998: Bug#854801: No network after netinst Stretch RC2

[Pierre Ynard]

> >   (=> To setup a network connection I had to edit /etc/network/interfaces)

I'm confused. The installer didn't set up any network access in
/etc/network/interfaces ? Because it ran from a CD? But it detected
IPv6 nameservers on the network and installed rdnssd? Isn't networking
supposed to work anyway even if task selection doesn't install
network-manager? I'm not clear on what happened there, and what was
supposed to happen.

> This seems due to the Conflicts added in rdnssd indeed, because of:
>   https://bugs.debian.org/740998

However reports in #778492 at the time indicated that the conflict would
be resolved by removing rdnssd and installing network-manager... So I'm
surprised if we get an opposite result now.

>  2. In finish-install.d/55netcfg-copy-config, where the /e/n/i and other
> settings copy is performed, we could check that flag and n-m's
> status; if the flag is set and n-m wasn't installed, install rdnssd.

The scope of the problem is a bit wider than just checking for
network-manager. As it was elaborated upon above in #740998, any pair
of two network tools writing to /etc/resolv.conf without cooperation is
prone to problems. The conflict in question here was a bit of an ad-hoc
solution because both rdnssd and network-manager were automatically
started daemons likely to be pulled in a basic install.

So on one hand, adding a custom check for just network-manager is ad hoc
too and doesn't address the general problem. On the other hand, it's all
relative and if the conflict hurts more than it was supposed to help, it
could be removed too - e.g. if it's indeed what prevents network-manager
from getting installed somehow.

The recent version of the rdnssd package should be much friendlier
and more cooperative than before in managing /etc/resolv.conf when
resolvconf is not installed. The impact of running network-manager and
rdnssd concurrently should be lower than before.

I don't really believe in second-guessing the decision made by the
package manager when resolving dependencies and conflicts. But I
can suggest other options than the conflict. /etc/default/rdnssd
can be edited to disable writing to /etc/resolv.conf, or make it
conditional on network-manager, reducing rdnssd to unused reporting.
/etc/rdnssd/merge-hook can be edited to improve interaction or detect
that /etc/resolv.conf was written by network-manager.

Best regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Bug#854843: chromium: check failed on invalid cert page Learn More link

[Andrew Domaszek]

Package: chromium
Version: 55.0.2883.75-6
Severity: normal

Dear Maintainer,

When viewing a site with an invalid certificate (in specific example,
https://wiki.lxde.org NET::ERR_CERT_DATE_INVALID), after clicking
the "ADVANCED", then "Learn more" links, chromium exits with an
check failed message as follows:

[11586:11586:0210/202650:FATAL:navigation_handle_impl.cc(470)] Check
failed: url_ == params.url ( vs. about:blank)

The program then exits normally.

I have tried the same page with other webkit based browsers
(midori,qupzilla) which do not exhibit this behavior. I have tested
a private page with a similar cert error and also observe this message
and a process exit.

Regards,
Andrew Domaszek

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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.3-4
ii  libatk1.0-0  2.22.0-1
ii  libavcodec57 7:3.2.2-2
ii  libavformat577:3.2.2-2
ii  libavutil55  7:3.2.2-2
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8
ii  libdbus-1-3  1.10.14-1
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libexpat12.2.0-2
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.3.0-5
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-2
ii  libharfbuzz0b1.4.2-1
ii  libicu57 57.1-5
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpng16-16  1.6.28-1
ii  libpulse010.0-1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.3-3
ii  libstdc++6   6.3.0-5
ii  libvpx4  1.6.1-2
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-2.2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Bug#854842: diamond takes a while to stop, errors out, slows down shutdown

[Sandro Tosi]

On Fri, Feb 10, 2017 at 8:11 PM, Faidon Liambotis  wrote:
> Source: diamond
> Version: 4.0.515-3
> Severity: serious

is this really a serious bug which `is a severe violation of Debian
policy (roughly, it violates a must or required directive), or, in the
package maintainer's or release manager's opinion, makes the package
unsuitable for release.` ?

>
> In my setup, diamond takes a long time to stop after getting a SIGTERM
> from systemd, thus slowing down the overall shutdown of the system by
> about a minute (and also making it slow to perform restarts). When it
> finally does stop, an error message about QueueHandler is emitted. The
> issue is reproducible without systemd too -- run diamond in one terminal
> with --log-stdout --foreground and then run kill from another terminal
> (Ctrl+C i.e. SIGINT won't reproduce it). This happens even with a
> relatively minimal config, e.g. without any Collectors defined and only
> with a single GraphiteHandler.
>
> What I see here is:
> root@d-i-test:/etc/diamond# diamond --log-stdout --foreground
> 1486775151.66   [MainProcess:9336:INFO] Changed UID: 0 () GID: 0 ().
> 1486775152.06   [MainProcess:9336:DEBUG]metric_queue_size: 16384
> 1486775152.06   [MainProcess:9336:DEBUG]Loading Handler 
> diamond.handler.graphite.GraphiteHandler
> 1486775152.1[MainProcess:9336:DEBUG]GraphiteHandler: Established 
> connection to graphite server 10.192.16.33:2003.
> 1486775152.11   [Handlers:9347:DEBUG]   Starting process Handlers
> 1486775153.12   [TCPCollector:9350:DEBUG]   Starting
> 1486775153.12   [TCPCollector:9350:DEBUG]   Interval: 60.0 seconds
> 1486775153.13   [TCPCollector:9350:DEBUG]   Max collection time: 28 
> seconds
> 1486775153.16   [TCPCollector:9350:DEBUG]   Collection took 32 ms
> 1486775154.14   [NetworkCollector:9353:DEBUG]   Starting
> 1486775154.14   [NetworkCollector:9353:DEBUG]   Interval: 60.0 seconds
> 1486775154.14   [NetworkCollector:9353:DEBUG]   Max collection time: 19 
> seconds
> 1486775154.16   [NetworkCollector:9353:DEBUG]   Collection took 16 ms
> 1486775155.15   [DiskUsageCollector:9356:DEBUG] Starting
> 1486775155.15   [DiskUsageCollector:9356:DEBUG] Interval: 60.0 seconds
> 1486775155.15   [DiskUsageCollector:9356:DEBUG] Max collection time: 48 
> seconds
> 1486775155.15   [DiskUsageCollector:9356:DEBUG] Collection took 1 ms
> 1486775156.16   [CPUCollector:9359:DEBUG]   Starting
> 1486775156.16   [CPUCollector:9359:DEBUG]   Interval: 60.0 seconds
> 1486775156.16   [CPUCollector:9359:DEBUG]   Max collection time: 43 
> seconds
> 1486775156.17   [CPUCollector:9359:DEBUG]   Collection took 7 ms
> 
> 1486775186.96   [MainProcess:9336:INFO] Signal Received: 15
> 1486775186.96   [NetworkCollector:9353:INFO]Signal Received: 15
> 1486775186.96   [Handlers:9347:INFO]Signal Received: 15
> 1486775186.96   [DiskUsageCollector:9356:INFO]  Signal Received: 15
> 1486775186.96   [TCPCollector:9350:INFO]Signal Received: 15
> 1486775186.96   [CPUCollector:9359:INFO]Signal Received: 15
> 1486775186.97   [NetworkCollector:9353:INFO]Signal Received: 15
> 1486775186.97   [CPUCollector:9359:INFO]Signal Received: 15
> 
> Exception socket.error: error(111, 'Connection refused') in  QueueHandler.__del__ of  0x7f8fa53bff10>> ignored
>
> While this long wait is happening, strace shows diamond is busylooping
> running this over and over (apparently python multiprocessing related):
> connect(4, {sa_family=AF_UNIX, sun_path="/tmp/pymp-xq1DKs/listener-8_h02F"}, 
> 34) = -1 ECONNREFUSED (Connection refused)
> close(4)= 0
> select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=1}) = 0 (Timeout)
> socket(AF_UNIX, SOCK_STREAM, 0) = 4
> fcntl(4, F_GETFL)   = 0x2 (flags O_RDWR)
> fcntl(4, F_SETFL, O_RDWR)   = 0

i will forward this upstream


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#854842: diamond takes a while to stop, errors out, slows down shutdown

[Faidon Liambotis]

Source: diamond
Version: 4.0.515-3
Severity: serious

In my setup, diamond takes a long time to stop after getting a SIGTERM
from systemd, thus slowing down the overall shutdown of the system by
about a minute (and also making it slow to perform restarts). When it
finally does stop, an error message about QueueHandler is emitted. The
issue is reproducible without systemd too -- run diamond in one terminal
with --log-stdout --foreground and then run kill from another terminal
(Ctrl+C i.e. SIGINT won't reproduce it). This happens even with a
relatively minimal config, e.g. without any Collectors defined and only
with a single GraphiteHandler.

What I see here is:
root@d-i-test:/etc/diamond# diamond --log-stdout --foreground
1486775151.66   [MainProcess:9336:INFO] Changed UID: 0 () GID: 0 ().
1486775152.06   [MainProcess:9336:DEBUG]metric_queue_size: 16384
1486775152.06   [MainProcess:9336:DEBUG]Loading Handler 
diamond.handler.graphite.GraphiteHandler
1486775152.1[MainProcess:9336:DEBUG]GraphiteHandler: Established 
connection to graphite server 10.192.16.33:2003.
1486775152.11   [Handlers:9347:DEBUG]   Starting process Handlers
1486775153.12   [TCPCollector:9350:DEBUG]   Starting
1486775153.12   [TCPCollector:9350:DEBUG]   Interval: 60.0 seconds
1486775153.13   [TCPCollector:9350:DEBUG]   Max collection time: 28 seconds
1486775153.16   [TCPCollector:9350:DEBUG]   Collection took 32 ms
1486775154.14   [NetworkCollector:9353:DEBUG]   Starting
1486775154.14   [NetworkCollector:9353:DEBUG]   Interval: 60.0 seconds
1486775154.14   [NetworkCollector:9353:DEBUG]   Max collection time: 19 seconds
1486775154.16   [NetworkCollector:9353:DEBUG]   Collection took 16 ms
1486775155.15   [DiskUsageCollector:9356:DEBUG] Starting
1486775155.15   [DiskUsageCollector:9356:DEBUG] Interval: 60.0 seconds
1486775155.15   [DiskUsageCollector:9356:DEBUG] Max collection time: 48 seconds
1486775155.15   [DiskUsageCollector:9356:DEBUG] Collection took 1 ms
1486775156.16   [CPUCollector:9359:DEBUG]   Starting
1486775156.16   [CPUCollector:9359:DEBUG]   Interval: 60.0 seconds
1486775156.16   [CPUCollector:9359:DEBUG]   Max collection time: 43 seconds
1486775156.17   [CPUCollector:9359:DEBUG]   Collection took 7 ms

1486775186.96   [MainProcess:9336:INFO] Signal Received: 15
1486775186.96   [NetworkCollector:9353:INFO]Signal Received: 15
1486775186.96   [Handlers:9347:INFO]Signal Received: 15
1486775186.96   [DiskUsageCollector:9356:INFO]  Signal Received: 15
1486775186.96   [TCPCollector:9350:INFO]Signal Received: 15
1486775186.96   [CPUCollector:9359:INFO]Signal Received: 15
1486775186.97   [NetworkCollector:9353:INFO]Signal Received: 15
1486775186.97   [CPUCollector:9359:INFO]Signal Received: 15

Exception socket.error: error(111, 'Connection refused') in > ignored

While this long wait is happening, strace shows diamond is busylooping
running this over and over (apparently python multiprocessing related):
connect(4, {sa_family=AF_UNIX, sun_path="/tmp/pymp-xq1DKs/listener-8_h02F"}, 
34) = -1 ECONNREFUSED (Connection refused)
close(4)= 0
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=1}) = 0 (Timeout)
socket(AF_UNIX, SOCK_STREAM, 0) = 4
fcntl(4, F_GETFL)   = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR)   = 0

Let me know if I can help in any way.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Bug#854699: Shutdown fails with an encrypted filesystem on virtio device

[Michael Biebl]

Am 10.02.2017 um 12:14 schrieb Yuri D'Elia:
> On Fri, Feb 10 2017, Michael Biebl wrote:
>> Looks similar to
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848044 and a lot like
>> https://github.com/systemd/systemd/issues/1620
> 
> Uhm, it does. Aside from the fact that it's not at all harmless as
> mentioned, since the root fs is not unmounted. And since the journal
> itself becomes corrupted, the log is lost.
> 
> However there seem to be no real progress on any front, including in the
> bugs regarding cryptsetup and lvm2 (which I've seen before).
> 
> I cannot explain why given the exact same partition/volume scheme by
> lvm/cryptsetup, in one case I can shutdown cleanly, and in the other it
> breaks.

While I can reproduce the error messages on shutdown, it does *not*
cause a dirty file system (in particular /var) here.
I do have persistent journal enabled on the test VM, but the filing
killing/unmount spree in systemd-shutdown properly unmounts /var.

So it seems mostly cosmetic to me.

-- 
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#792150: jruby: Package 9.0.0.0 releases

[Miguel Landaeta]

tag 792150 + pending
thanks

Just yet another quick update, I intend to upload 9.1.6.0 to
experimental this weekend.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#854840: sl-modem-dkms FTBFS at kernel version 4.9

[Stephen Powell]

Here is more information about the nature of the build failure.

root@smp1:~# apt-get --reinstall install sl-modem-dkms
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 3 not upgraded.
Need to get 0 B/205 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 176139 files and directories currently installed.)
Preparing to unpack .../sl-modem-dkms_2.9.11~20110321-12_i386.deb ...

--
Deleting module version: 2.9.11~20110321
completely from the DKMS tree.
--
Done.
Unpacking sl-modem-dkms (2.9.11~20110321-12) over (2.9.11~20110321-12) ...
Setting up sl-modem-dkms (2.9.11~20110321-12) ...
Loading new sl-modem-2.9.11~20110321 DKMS files...
Building for 4.9.2-1custom01-686-pae
Building initial module for 4.9.2-1custom01-686-pae
Error!  Build of slusb.ko failed for: 4.9.2-1custom01-686-pae (i686)
Consult the make.log in the build directory
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ for more information.

DKMS make.log for sl-modem-2.9.11~20110321 for kernel 4.9.2-1custom01-686-pae 
(i686)
Fri Feb 10 19:07:40 EST 2017
make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
doing %.o: %.c
cc -Wall -pipe -O3 -fomit-frame-pointer -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB 
`test -f /lib/modules/4.9.2-1custom01-686-pae/build/include/linux/modversions.h 
&& echo -DMODVERSIONS --include 
/lib/modules/4.9.2-1custom01-686-pae/build/include/linux/modversions.h 
-I/lib/modules/4.9.2-1custom01-686-pae/build/include`  -I. -I./../modem   -o 
amrmo_init.o -c amrmo_init.c
amrmo_init.c:57:26: fatal error: linux/module.h: No such file or directory
 #include 
  ^
compilation terminated.
Makefile:128: recipe for target 'amrmo_init.o' failed
make: *** [amrmo_init.o] Error 1
make: Leaving directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
make: Entering directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'
make modules -C /lib/modules/4.9.2-1custom01-686-pae/build 
SUBDIRS=/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem
make[1]: Entering directory '/usr/src/linux-source-4.9'

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Bug#854474: alsa-lib: FTBFS when built with dpkg-buildpackage -A

[Nobuhiro Iwamatsu]

Control: tags 854474 + patch

Hi,

> make[1]: *** [override_dh_install] Error 2
> make[1]: Leaving directory '/<>'
> debian/rules:8: recipe for target 'binary-indep' failed
> make: *** [binary-indep] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
> status 2
> 
> 
> To reproduce, please try building with "dpkg-buildpackage -A".
> 
> Also, please consider uploading in source-only form (dpkg-buildpackage -S),
> so that this kind of bugs never propagate to testing.

I also confirmed that this problem will occur.
I fixed this problem by adding dh_auto_install to 
override_dh_auto_install-indep,
because the alsa data file is not installed under usr/share/alsa in the 
previous process.

I attached a patch which reviced this problem.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
From 089c6e8a556bc0944779638b9e38a1aa6df902f7 Mon Sep 17 00:00:00 2001
From: Nobuhiro Iwamatsu 
Date: Sat, 11 Feb 2017 06:28:50 +0900
Subject: [PATCH] Fix build with dpkg-buildpackage -A

Add dh_auto_install to target for override_dh_auto_install-indep,
because alsa data file is not installed under usr/share/alsa in
the previous process.

Signed-off-by: Nobuhiro Iwamatsu 
---
 debian/changelog | 7 +++
 debian/rules | 1 +
 2 files changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 74e22d2..34af3b3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+alsa-lib (1.1.3-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS when built with dpkg-buildpackage -A (Closes: #854474)
+
+ -- Nobuhiro Iwamatsu   Sat, 11 Feb 2017 08:53:54 +0900
+
 alsa-lib (1.1.3-4) unstable; urgency=medium
 
   * Add copyright notes for src/topology. Thanks Thorsten Alteholz for
diff --git a/debian/rules b/debian/rules
index 171d275..b8918f2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,6 +18,7 @@ override_dh_auto_build-indep:
 
 override_dh_auto_install-indep:
 	$(MAKE) -C doc install
+	dh_auto_install
 
 override_dh_installdocs:
 	dh_installdocs -X.md5 -Xall_a.js -Xall_f.js -Xall_14.js -Xall_15.js
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#305029: synaptic: remember column widths

[S.Allen]

Package: synaptic
Version: 0.84.1
Followup-For: Bug #305029

Dear Maintainer,

This bug has been around ever since I've used Synaptic. In the preferences one
can change the font and size for the application. However this requires one to
expand the collumn cell to show all the text. It doesn't stick however.



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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.15-1
ii  libapt-inst2.0   1.4~beta4
ii  libapt-pkg5.01.4~beta4
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libept1.5.0  1.1+nmu3+b1
ii  libgcc1  1:6.3.0-5
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgnutls30  3.5.8-3
ii  libgtk-3-0   3.22.7-2
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpcre2-8-0 10.22-2
ii  libstdc++6   6.3.0-5
ii  libvte-2.91-00.46.1-1
ii  libx11-6 2:1.6.4-3
ii  libxapian30  1.4.3-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages synaptic recommends:
ii  gksu   2.0.2-9
ii  libgtk2-perl   2:1.2499-1
ii  policykit-10.105-17
ii  rarian-compat  0.8.1-6
ii  xdg-utils  1.1.1-1

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

-- no debconf information

Bug#854841: eth4 hardcoded

[Santiago Garcia Mantinan]

Package: bridge-utils
Version: 1.5-12
Severity: serious

I somehow missed a hardcoded eth4 name for $dev on the bridge-utils.sh script.

I'll be uploading a new version fixing this.

Sorry about this. Regards.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages bridge-utils depends on:
ii  libc6  2.24-9

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.19

-- no debconf information

Bug#854840: sl-modem-dkms FTBFS at kernel version 4.9

[Stephen Powell]

Package: sl-modem-dkms
Version: 2.9.11~20110321-12
Severity: normal

sl-modem-dkms fails to build from source with a custom kernel at version 4.9.
The build procedure followed is documented at
http://www.stevesdebianstuff.org/Kernel.htm#Example2, except that the kernel
source package used is linux-source-4.9 instead of linux-source-3.16.  Also,
linux-kbuild-4.9 is manually installed instead of linux-kbuild-3.16.  Other
changes to the procedure are made based on package versions, of course.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Bug#854839: debian-reference: Filesystem internals

[Laurent Sauvage]

Package: debian-reference
Version: 2

Reference "/usr/include/linux/fs.h" in section 1.2.2 does not contain
"struct inode". It would be better to refer for instance to
"/usr/include/linux/ext2_fs.h", whose "struct ext2_inode" contains owner,
group, etc. attributes.

Bug#854838: kde-full: When kde-full is installed, upgrading from jessie to stretch is extremely hard (if not impossible for beginners)

[Julien Aubin]

Package: kde-full
Version: 5:92
Severity: critical
Justification: breaks the whole system

Hi,

This bug only appears when upgrading a jessie system to stretch, but is a
release blocker at least w/ amd64 arch with foreign i386 arch enabled.

As per documentation, dist upgrade from jessie to stretch should work as
follows :
1/ update sources.list
2/ apt update
3/ apt upgrade
4/ apt dist-upgrade

The issue actually lies at the apt upgrade step, as it is reported that
package
kdepimlibs-data breaks several other packages, so the upgrade cannot be
performed.

So then you have either to attempt to fix manually the issue, or with a
dist-
upgrade, but in both situations the result is the same : the situation
becomes
completely messy, with many broken packages you have to fix manually with
dpkg
commands. It is not impossible to run the upgrade this way, but anyway it is
painful.

Steps to reproduce :
DO : install jessie with kde-full metapackage
DO : upgrade to stretch
EXPECT : upgrade runs fine
ACTUAL : upgrade is broken

Note : if you cannot reproduce the issue this way, try to upgrade
libreoffice
from bpo (this might be the cause, but I have serious doubt about this).



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

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

Versions of packages kde-full depends on:
ii  kde-plasma-desktop  5:92
ii  kde-standard5:92
ii  kdeadmin4:16.04.0+5.92
ii  kdeartwork  4:15.08.3-2
ii  kdeedu  4:16.04.0+5.92
ii  kdegames4:16.04.0+5.92
ii  kdegraphics 4:16.04.0+5.92
ii  kdemultimedia   4:16.04.0+5.92
ii  kdenetwork  4:16.04.0+5.92
ii  kdepim  4:16.04.3-3
ii  kdeutils4:16.04.0+5.92

Versions of packages kde-full recommends:
ii  kdeaccessibility  4:16.04.0+5.92
ii  kdesdk4:16.04.0+5.92
ii  kdetoys   4:16.04.0+5.92
pn  kdewebdev 

Versions of packages kde-full suggests:
ii  calligra1:2.9.11+dfsg-4
ii  kde-l10n-fr [kde-l10n]  4:16.04.3-1
ii  xorg1:7.7+18

-- no debconf information

Bug#854837: Package dicompyler does not work

[Vojtech Kulvait]

Package: dicompyler
Version: 0.4.2-2

When invoking dicompyler it warns that there is unmet dependency. If I
manualy remove the dependency from system, program does not work. I am
using Jessie AMD64 and the same problem occur on two independent computers.

Bug#850421: libsqlcipher0: qTox segfaults with distro provided libsqlcipher0

[Colomban Wendling]

Control: tags -1 + patch

On Fri, 20 Jan 2017 18:53:41 +0100 Kali Kaneko  wrote:
> I'm facing the same issue in pysqlcipher.
> 
> I found a workaround, in:
> https://github.com/sqlcipher/sqlcipher/pull/195/commits/37efb6a9e9995c21a3c9e632bb86b3ba6f613f79#diff-c2495c7f2211a99fba2bfb98a19a1916
> 
> They key to avoid the segfault is this line in the sqlcipher_openssl_cipher 
> function:
> 
> +  EVP_CipherInit_ex(ectx, NULL, NULL, key, iv, mode);
> -  EVP_CipherInit(ectx, NULL, key, iv, mode);
> 
> Note that it just uses the _ex version. I'm not familiar enough with openssl 
> to 
> know if this is a bad usage on the side of sqlcipher, or it's just a bug in 
> openssl.

Thank you Kali for these info!

I don't know OpenSSL much either, but I can confirm that changing the
EVP_CipherInit() calls to EVP_CipherInit_ex() ones (adding the required
extra parameter, obviously) in 33-openssl_1.1.patch fixes the issue for
me.  And as far as I can read in the OpenSSL documentation, that change
is at least harmless.  It doesn't really suggest why it would fix
anything, but it definitely does.

In the current situation (before patching) Valgrind reports an invalid
memory access right before the crash (taken with qTox, but as the call
trace is fully inside sqlite and down it's likely the same anywhere):

> ==26696== Invalid read of size 1
> ==26696==at 0xDB25CAD: EVP_DecryptUpdate (evp_enc.c:424)
> ==26696==by 0x5FE5E3A: sqlcipher_openssl_cipher (sqlite3.c:16517)
> ==26696==by 0x5FF63D9: sqlcipher_page_cipher (sqlite3.c:15696)
> ==26696==by 0x6008198: sqlite3Codec (sqlite3.c:14376)
> ==26696==by 0x5FE522D: readDbPage (sqlite3.c:46743)
> ==26696==by 0x601503B: sqlite3PagerAcquire (sqlite3.c:49225)
> ==26696==by 0x60152DA: btreeGetPage (sqlite3.c:56080)
> ==26696==by 0x6015DC6: lockBtree (sqlite3.c:56883)
> ==26696==by 0x6015DC6: sqlite3BtreeBeginTrans (sqlite3.c:57220)
> ==26696==by 0x6057B96: sqlite3InitOne (sqlite3.c:103754)
> ==26696==by 0x6057EFB: sqlite3Init (sqlite3.c:103930)
> ==26696==by 0x6057FAF: sqlite3ReadSchema (sqlite3.c:103967)
> ==26696==by 0x605853A: sqlite3LocateTable (sqlite3.c:89352)
> ==26696==  Address 0x12 is not stack'd, malloc'd or (recently) free'd

I guess somehow EVP_CipherInit() doesn't work properly in this case and
leaves some parts improperly initialized.

Attached is a fairly trivial patch changing the calls as mentioned.  It
also happens to make the patch closer to
https://github.com/sqlcipher/sqlcipher/pull/195/commits/37efb6a9e9995c21a3c9e632bb86b3ba6f613f79#diff-c2495c7f2211a99fba2bfb98a19a1916

So dear maintainer, please apply this or an equivalent patch.  The
current situation is grave, rendering the package unusable.

IMO this deserves the "grave" severity, but as it's release time I'll
leave it as is for now as I don't know the policy here for sure.  But
this needs to be fixed in Stretch.

Kind regards,
Colomban
diff --git a/sqlcipher-3.2.0.old/debian/changelog b/sqlcipher-3.2.0/debian/changelog
index 41f8795..54071ce 100644
--- a/sqlcipher-3.2.0.old/debian/changelog
+++ b/sqlcipher-3.2.0/debian/changelog
@@ -1,3 +1,10 @@
+sqlcipher (3.2.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix OpenSSL 1.1 support (Closes: #850421)
+
+ -- Colomban Wendling   Fri, 10 Feb 2017 23:16:14 +0100
+
 sqlcipher (3.2.0-2) unstable; urgency=medium
 
   * support building with openssl 1.1 (Closes: #828555)
diff --git a/sqlcipher-3.2.0.old/debian/patches/33-openssl_1.1.patch b/sqlcipher-3.2.0/debian/patches/33-openssl_1.1.patch
index c28515d..64abe5e 100644
--- a/sqlcipher-3.2.0.old/debian/patches/33-openssl_1.1.patch
+++ b/sqlcipher-3.2.0/debian/patches/33-openssl_1.1.patch
@@ -1,6 +1,6 @@
 --- a/src/crypto_openssl.c
 +++ b/src/crypto_openssl.c
-@@ -155,14 +155,24 @@
+@@ -143,14 +143,24 @@ static int sqlcipher_openssl_random (voi
  }
  
  static int sqlcipher_openssl_hmac(void *ctx, unsigned char *hmac_key, int key_sz, unsigned char *in, int in_sz, unsigned char *in2, int in2_sz, unsigned char *out) {
@@ -26,7 +26,7 @@
return SQLITE_OK; 
  }
  
-@@ -172,9 +182,23 @@
+@@ -160,9 +170,22 @@ static int sqlcipher_openssl_kdf(void *c
  }
  
  static int sqlcipher_openssl_cipher(void *ctx, int mode, unsigned char *key, int key_sz, unsigned char *iv, unsigned char *in, int in_sz, unsigned char *out) {
@@ -36,22 +36,21 @@
 +#if OPENSSL_VERSION_NUMBER >= 0x1011L
 +  EVP_CIPHER_CTX *ectx;
 +  ectx = EVP_CIPHER_CTX_new();
-+  EVP_CipherInit(ectx, ((openssl_ctx *)ctx)->evp_cipher, NULL, NULL, mode);
++  EVP_CipherInit_ex(ectx, ((openssl_ctx *)ctx)->evp_cipher, NULL, NULL, NULL, mode);
 +  EVP_CIPHER_CTX_set_padding(ectx, 0); // no padding
-+  EVP_CipherInit(ectx, NULL, key, iv, mode);
++  EVP_CipherInit_ex(ectx, NULL, NULL, key, iv, mode);
 +  EVP_CipherUpdate(ectx, out, &tmp_csz, in, in_sz);
 +  csz = tmp_csz;  
 +  out += tmp_csz;
 +  EVP_CipherFinal(ectx, out, &tmp_csz);
 +  csz += tmp_csz;
 +  EVP_CIPHER_CTX_free(ectx);
-+
 +#else
 

Bug#854836: systemsettings: Changing window decoration crashes systemsettings

[Julien Aubin]

Package: systemsettings
Version: 4:5.8.4-1
Severity: normal

Hi,

When you change the window decorations in systemsettings, the app crashes
and
the user is prompted to restart it.

Steps to reproduce :
DO : open systemsettings
DO : go to application appearance section, then window decoration
DO : select breeze and click OK button
EXPECT : the window decoration is updated.
ACTUAL : decoration is updated, but systemsettings crashes.

Reproducitibility : always.

Computer w/ compositing enabled. NVidia 375.26 blob used.



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

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

Versions of packages systemsettings depends on:
ii  kio   5.28.0-1
ii  libc6 2.24-9
ii  libkf5auth5   5.28.0-1
ii  libkf5completion5 5.28.0-1
ii  libkf5configcore5 5.28.0-1
ii  libkf5configgui5  5.28.0-1
ii  libkf5configwidgets5  5.28.0-1
ii  libkf5coreaddons5 5.28.0-1
ii  libkf5dbusaddons5 5.28.0-1
ii  libkf5i18n5   5.28.0-1
ii  libkf5iconthemes5 5.28.0-1
ii  libkf5itemviews5  5.28.0-1
ii  libkf5kcmutils5   5.28.0-1
ii  libkf5khtml5  5.28.0-1
ii  libkf5kiowidgets5 5.28.0-1
ii  libkf5service-bin 5.28.0-1
ii  libkf5service55.28.0-1
ii  libkf5widgetsaddons5  5.28.0-1
ii  libkf5windowsystem5   5.28.0-1
ii  libkf5xmlgui5 5.28.0-1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-5

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information

Bug#854716: [Python-modules-team] Bug#854716: python3-django-cors-headers: Does not work with Django 1.10

[Brian May]

Michael Fladischer  writes:

> Updating to 1.2.0 would solve this but the freeze is already in place, so it's
> either backporting the fix from upstream[0] or asking fo an exeption from
> release team.

Unblock request sent for backport: #854833
-- 
Brian May 

Bug#854835: debian-reference: filesystems directory

[Laurent Sauvage]

Package: debian-reference
Version: 2

Introduction of section 1.2 refers to "
/share/doc/linux-doc-*/Documentation/filesystems/" which is not available.

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Andreas Beckmann]

Control: tag -1 - moreinfo

On Fri, 10 Oct 2014 09:14:17 +0200 Andreas Beckmann  wrote:
> The only point I could imagine to "block" is when the script tries to
> read /proc/driver/nvidia/version - which should only exist if the driver
> got loaded properly.

Today I ran into this problem, too. :-)

Problem is that the 340xx driver (didn't check 304xx) does not
unregister the proc entries if it aborts loading (due to nouveau being
loaded already). The error unwinding is a mess! 375.26 is correct in
that respect. So the script tries to access stale proc entries resulting in
  BUG: unable to handle kernel paging request at ...
I have tested a small patch that adds a call to nv_unregister_proc(),
which was sufficient to fix my problem. It is probably not correct for
all unwinding paths ...


Andreas

Bug#854834: Please package new upstream version

[Thomas Lange]

Package: am-utils
Severity: wishlist

There's the new upstream version 6.2 from October 30, 2014 which now
supports NFS v4.

BTW, the current version in unstable is 1065 days old, and has not yet
entered testing. Is this package orphaned?

-- 
regards Thomas

Bug#854826: [PATCH] [ARM64] kexec: Increase the upper limit for RAM segments

[Manoj Iyer]

The patch applys to ARM64 architecture and does not touch other arch 
code.


The attached patch increases KEXEC_SEGMENT_MAX from hardcoded value of 
16 to 64. The patch was tested on an ARM64 (vm). This patch applies 
cleanly to 2.0.14-1 version of debian kexec-tools: 
https://pastebin.ubuntu.com/23969766/


[TESTING]
root@debian:/home/ubuntu/new# cat /proc/iomem
0900-09000fff : /pl011@900
 0900-09000fff : /pl011@900
0903-09030fff : /pl061@903
0a003c00-0a003dff : a003c00.virtio_mmio
0a003e00-0a003fff : a003e00.virtio_mmio
1000-3efe : /pcie@1000
3f00-3fff : PCI ECAM
4000-bfff : System RAM
 4008-4094 : Kernel code
 40c8-40e25fff : Kernel data
c000- : reserved
1-13858 : System RAM
13859-13874 : reserved
13875-13bc1 : System RAM
13bc2-13bff : reserved
13c00-13fff : System RAM
80-ff : /pcie@1000
root@debian:/home/ubuntu/new#

root@debian:/home/ubuntu/new# dpkg -l | grep kexec-tools
ii  kexec-tools1:2.0.14-1.1
arm64tools to support fast kexec reboots

root@debian:/home/ubuntu/new#

root@debian:/home/ubuntu/new# kexec -d -l /boot/vmlinuz-4.9.0-1-arm64 
--reuse-cmd --initrd=/boot/initrd.img-4.9.0-1-arm64
arch_process_options:141: command_line: 
root=UUID=010a5260-8c6d-444c-82cd-6cf9b0cbc120 ro quiet

arch_process_options:143: initrd: /boot/initrd.img-4.9.0-1-arm64
arch_process_options:144: dtb: (null)
Try gzip decompression.
kernel: 0x8201f010 kernel_size: 0xcffa00
get_memory_ranges_iomem_cb: 4000 - bfff : 
System RAM
get_memory_ranges_iomem_cb: 0001 - 00013858 : 
System RAM
get_memory_ranges_iomem_cb: 00013875 - 00013bc1 : 
System RAM
get_memory_ranges_iomem_cb: 00013c00 - 00013fff : 
System RAM

elf_arm64_probe: Not an ELF executable.
image_arm64_load: kernel_segment: 4000
image_arm64_load: text_offset:0008
image_arm64_load: image_size: 00da6000
image_arm64_load: phys_offset:4000
image_arm64_load: vp_offset:  
image_arm64_load: PE format:  yes
read_1st_dtb: found /sys/firmware/fdt

root@debian:/home/ubuntu/new# kexec -e

Message from syslogd@debian at Feb 10 17:42:22 ...
kernel:[  904.990897] kexec_core: Starting new kernel
[0.464088] kvm [1]: HYP mode not available
/dev/vda2: recovering journal
/dev/vda2: clean, 45371/2342912 files, 556007/9368064 blocks

Debian GNU/Linux 9 debian ttyAMA0

debian login:


diff -Nru kexec-tools-2.0.14/debian/changelog kexec-tools-2.0.14/debian/changelog
--- kexec-tools-2.0.14/debian/changelog	2017-01-25 14:36:57.0 -0500
+++ kexec-tools-2.0.14/debian/changelog	2017-02-10 17:33:07.0 -0500
@@ -1,3 +1,9 @@
+kexec-tools (1:2.0.14-1.1) UNRELEASED; urgency=medium
+
+  * kexec: Increase the upper limit for RAM segments (Closes: #854826)
+
+ -- Manoj Iyer   Fri, 10 Feb 2017 17:33:07 -0500
+
 kexec-tools (1:2.0.14-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru kexec-tools-2.0.14/debian/patches/kexec-Increase-the-upper-limit-for-RAM-segments.patch kexec-tools-2.0.14/debian/patches/kexec-Increase-the-upper-limit-for-RAM-segments.patch
--- kexec-tools-2.0.14/debian/patches/kexec-Increase-the-upper-limit-for-RAM-segments.patch	1969-12-31 19:00:00.0 -0500
+++ kexec-tools-2.0.14/debian/patches/kexec-Increase-the-upper-limit-for-RAM-segments.patch	2017-02-10 17:32:40.0 -0500
@@ -0,0 +1,28 @@
+From 24aa2d93cac316657a2c20f28b8687bbf7e22991 Mon Sep 17 00:00:00 2001
+From: Sameer Goel 
+Date: Wed, 18 Jan 2017 16:15:12 -0700
+Subject: [PATCH] kexec: Increase the upper limit for RAM segments
+
+On a newer UEFI based Qualcomm target the number of system ram regions
+retrieved from /proc/iomem are ~40. So increasing the current hardcoded
+values to 64 from 16.
+
+Signed-off-by: Sameer Goel 
+Signed-off-by: Simon Horman 
+---
+ kexec/arch/arm64/kexec-arm64.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+Index: kexec-tools-2.0.14/kexec/arch/arm64/kexec-arm64.h
+===
+--- kexec-tools-2.0.14.orig/kexec/arch/arm64/kexec-arm64.h
 kexec-tools-2.0.14/kexec/arch/arm64/kexec-arm64.h
+@@ -11,7 +11,7 @@
+ #include "image-header.h"
+ #include "kexec.h"
+ 
+-#define KEXEC_SEGMENT_MAX 16
++#define KEXEC_SEGMENT_MAX 64
+ 
+ #define BOOT_BLOCK_VERSION 17
+ #define BOOT_BLOCK_LAST_COMP_VERSION 16
diff -Nru kexec-tools-2.0.14/debian/patches/series kexec-tools-2.0.14/debian/patches/series
--- kexec-tools-2.0.14/debian/patches/series	2017-01-25 14:36:57.0 -0500
+++ kexec-tools-2.0.14/debian/patches/series	2017-02-10 17:32:29.0 -0500
@@ -7,3 +7,4 @@
 const_string_warning.patch
 powerpcspe_support.patch
 arm64_build.patch
+kexec-Increase-the-upper-limit-for-RAM-segments.patch

Bug#854833: unblock: django-cors-headers/1.1.0-2

[Brian May]

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

Please unblock package django-cors-headers

The latest version fixes a RC bug #854716.

It also updates the Vcs-* headers which were wrong.


diff -Nru django-cors-headers-1.1.0/debian/changelog 
django-cors-headers-1.1.0/debian/changelog
--- django-cors-headers-1.1.0/debian/changelog  2015-08-07 12:22:31.0 
+1000
+++ django-cors-headers-1.1.0/debian/changelog  2017-02-11 08:34:43.0 
+1100
@@ -1,3 +1,11 @@
+django-cors-headers (1.1.0-2) unstable; urgency=medium
+
+  * Add patch to fix Django 1.10 support. Closes: #854716.
+  * Update Vcs-* headers for git repository.
+  * disable_broken_tests.patch regenerated from git-dpm but unchanged.
+
+ -- Brian May   Sat, 11 Feb 2017 08:34:43 +1100
+
 django-cors-headers (1.1.0-1) unstable; urgency=low
 
   * Initial upload. Closes: #794829.
diff -Nru django-cors-headers-1.1.0/debian/control 
django-cors-headers-1.1.0/debian/control
--- django-cors-headers-1.1.0/debian/control2015-08-07 12:30:44.0 
+1000
+++ django-cors-headers-1.1.0/debian/control2017-02-10 20:17:00.0 
+1100
@@ -8,8 +8,8 @@
 python3-setuptools (>= 0.6b3), python3-mock, python3-django, python3-all
 Standards-Version: 3.9.6
 Homepage: https://github.com/ottoyiu/django-cors-headers
-Vcs-Browser: 
http://anonscm.debian.org/viewvc/python-modules/packages/django-cors-headers/trunk/
-Vcs-Svn: 
svn://anonscm.debian.org/python-modules/packages/django-cors-headers/trunk/
+Vcs-Browser: 
https://anonscm.debian.org/cgit/python-modules/packages/django-cors-headers.git
+Vcs-Git: 
https://anonscm.debian.org/git/python-modules/packages/django-cors-headers.git
 
 Package: python-django-cors-headers
 Architecture: all
diff -Nru django-cors-headers-1.1.0/debian/.git-dpm 
django-cors-headers-1.1.0/debian/.git-dpm
--- django-cors-headers-1.1.0/debian/.git-dpm   1970-01-01 10:00:00.0 
+1000
+++ django-cors-headers-1.1.0/debian/.git-dpm   2017-02-10 20:17:00.0 
+1100
@@ -0,0 +1,11 @@
+# see git-dpm(1) from git-dpm package
+09adb1de0a7b0d99121d135e0a0019f11145fb31
+09adb1de0a7b0d99121d135e0a0019f11145fb31
+1f50c6e016dd93030cfe96fdb5ea87157ec3f018
+1f50c6e016dd93030cfe96fdb5ea87157ec3f018
+django-cors-headers_1.1.0.orig.tar.gz
+72b55a3728819f4efc2cd8623499eecae8871e50
+4633
+debianTag="debian/%e%v"
+patchedTag="patched/%e%v"
+upstreamTag="upstream/%e%u"
diff -Nru 
django-cors-headers-1.1.0/debian/patches/0002-Fix-Django-1.0-support.patch 
django-cors-headers-1.1.0/debian/patches/0002-Fix-Django-1.0-support.patch
--- django-cors-headers-1.1.0/debian/patches/0002-Fix-Django-1.0-support.patch  
1970-01-01 10:00:00.0 +1000
+++ django-cors-headers-1.1.0/debian/patches/0002-Fix-Django-1.0-support.patch  
2017-02-10 20:17:00.0 +1100
@@ -0,0 +1,45 @@
+From 09adb1de0a7b0d99121d135e0a0019f11145fb31 Mon Sep 17 00:00:00 2001
+From: Brian May 
+Date: Fri, 10 Feb 2017 17:14:03 +1100
+Subject: Fix Django 1.0 support
+
+Patch downloaded from upstream
+https://github.com/ottoyiu/django-cors-headers/commit/870b1d9deb54ff4c1fefedc39dff02519abb32c5
+---
+ corsheaders/middleware.py | 9 +++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/corsheaders/middleware.py b/corsheaders/middleware.py
+index f22ee58..c6c1af8 100755
+--- a/corsheaders/middleware.py
 b/corsheaders/middleware.py
+@@ -12,6 +12,11 @@ try:
+ except ImportError:
+ from django.db.models.loading import get_model
+ 
++try:
++from django.utils.deprecation import MiddlewareMixin
++except ImportError:
++MiddlewareMixin = object
++
+ from corsheaders import defaults as settings
+ 
+ 
+@@ -23,7 +28,7 @@ ACCESS_CONTROL_ALLOW_METHODS = 'Access-Control-Allow-Methods'
+ ACCESS_CONTROL_MAX_AGE = 'Access-Control-Max-Age'
+ 
+ 
+-class CorsPostCsrfMiddleware(object):
++class CorsPostCsrfMiddleware(MiddlewareMixin):
+ 
+ def _https_referer_replace_reverse(self, request):
+ """
+@@ -45,7 +50,7 @@ class CorsPostCsrfMiddleware(object):
+ return None
+ 
+ 
+-class CorsMiddleware(object):
++class CorsMiddleware(MiddlewareMixin):
+ 
+ def _https_referer_replace(self, request):
+ """
diff -Nru django-cors-headers-1.1.0/debian/patches/disable_broken_tests.patch 
django-cors-headers-1.1.0/debian/patches/disable_broken_tests.patch
--- django-cors-headers-1.1.0/debian/patches/disable_broken_tests.patch 
2015-08-07 12:12:50.0 +1000
+++ django-cors-headers-1.1.0/debian/patches/disable_broken_tests.patch 
2017-02-10 20:17:00.0 +1100
@@ -1,8 +1,18 @@
-Index: django-cors-headers-1.1.0/corsheaders/tests.py
-===
 django-cors-headers-1.1.0.orig/corsheaders/tests.py
-+++ django-cors-headers-1.1.0/corsheaders/tests.py
-@@ -10,6 +10,7 @@ from corsheaders.middleware import ACCES
+From c070b3aa4cb30c9c49c5f5d4498b5d847eb06c35 Mon Sep 17 00:00:00 2001
+From: SVN-Git Migration 
+Date: Th

Bug#854822: installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk"

[Gunnar Wolf]

Thanks for the quick insight into this, Karsten!

Karsten Merker dijo [Fri, Feb 10, 2017 at 09:36:33PM +0100]:
> (...) but this doesn't work in your case as we currently
> only disable the clobbering for /dev/mmcblk0 while your SD card
> shows up as /dev/mmcblk1. I am not 100% sure about that, but IIRC
> with older kernels the SD card in the cubox-i has shown up as
> /dev/mmcblk0. 

Hmmm, interesting! Yes, I had not noticed it is finding the card as
mmcblk1. Checking the kernel boot messages, I see the following
messages:

# dmesg |grep mmc
[2.509702] sdhci-esdhc-imx 219.usdhc: allocated mmc-pwrseq
[2.771308] mmc0: SDHCI controller on 219.usdhc [219.usdhc] using 
ADMA
[2.808099] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
[2.816447] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using 
ADMA
[2.818516] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[2.827572] mmc0: queuing unknown CIS tuple 0x80 (4 bytes)
[2.868673] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
[2.872362] mmc1: host does not support reading read-only switch, assuming 
write-enable
[2.880622] mmc1: new high speed SDHC card at address 
[2.884074] mmcblk1: mmc1: SL16G 14.8 GiB
[2.884808] mmc0: new SDIO card at address 0001
[2.889061]  mmcblk1: p1 p2 p3 p4 < p5 >
[3.609029] EXT4-fs (mmcblk1p3): mounted filesystem with ordered data mode. 
Opts: (null)
[4.715715] EXT4-fs (mmcblk1p3): re-mounted. Opts: errors=remount-ro
[6.173094] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac4329-sdio.bin
[6.179691] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac4329-sdio.txt
[6.181794] Adding 2016252k swap on /dev/mmcblk1p5.  Priority:-1 extents:1 
across:2016252k SSFS
[7.313952] EXT4-fs (mmcblk1p2): mounting ext2 file system using the ext4 
subsystem
[7.322217] EXT4-fs (mmcblk1p2): mounted filesystem without journal. Opts: 
(null)

So... Well, mmcblk1 is mounted at mmc0 (don't know what mmc1 is), but
other than that, I see nothing too suspicious.

> The easiest solution would be to check for /dev/mmcblk instead of
> /dev/mmcblk0. If nobody has objections against this change, I'll modify
> partman-base accordingly and upload a new version (CCing the partman-base
> uploaders Max Vozeler, Anton Zinoviev, Colin Watson and Christian Perrier
> and Kibi as the d-i release manager).

I would say this makes sense. Even if I had multiple MMC units in my
system, installing on a MMC card should not clobber a preexisting
U-boot image; an option would be for d-i to install the matching right
flavor of the pre-boot environment for the current Debian release, but
of course, that would not enter in Stretch (if it was deemed desirable
at all)

> > As a very minor issue, even in the second case, after the install
> > notifies «Requesting system reboot», it just hangs. I disconnected and
> > reconnected power to get the system to boot — But it booted correctly
> > after that.
> 
> I have similar experiences with systems based on other ARM-SoCs,
> but I have not been able to pinpoint the cause. The hang happens
> only when rebooting from the d-i environment; rebooting the
> installed system with exactly the same kernel works without
> problems.

Yes, I have rebooted the machine several times over from other environments.

Bug#854830: apt updates initramfs incorrectly, breaks RAID/mdadm

[Brad Doster]

Ahh... that makes more sense!  Thought I was losing it... :-)  Thanks for
the explanation!

On Fri, Feb 10, 2017 at 2:34 PM, Julian Andres Klode  wrote:

> On Fri, Feb 10, 2017 at 02:01:59PM -0800, Brad Doster wrote:
> > Huh?  The problem occurs when apt updates initramfs, so it is a package
> > manager issue, not a RAID manager issue.  Did you read the whole report?
>
> That file was changed by some script called by a post installation script
> of some package, not by apt. apt does not modify any config files (well,
> it modifies one file it owns itself).
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>

Bug#854817: libgles1-mesa: Missing libgles1-mesa (17.0.0~rc3-1) package on experimental.

[Timo Aaltonen]

On 10.02.2017 19:15, felipe wrote:
> Package: libgles1-mesa
> Version: 17.0.0~rc2-1
> Severity: minor
> 
> Dear Maintainer,
> 
> The mesa meta package version 17.0.0~rc3-1 is missing libgles1-mesa, 
> making it impossible to test the package.

Test with what? GLES1 was dropped on purpose as nothing used it. Better
to fix your test to skip GLES1.


-- 
t

Bug#854830: apt updates initramfs incorrectly, breaks RAID/mdadm

[Julian Andres Klode]

On Fri, Feb 10, 2017 at 02:01:59PM -0800, Brad Doster wrote:
> Huh?  The problem occurs when apt updates initramfs, so it is a package
> manager issue, not a RAID manager issue.  Did you read the whole report?

That file was changed by some script called by a post installation script
of some package, not by apt. apt does not modify any config files (well,
it modifies one file it owns itself).

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#854578: ITP: node-source-map-url -- Tools for working with sourceMappingURL comments.

[Philip Hands]

Abhishek Lolage  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Abhishek Lolage 
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name: node-source-map-url
>  Version : 0.4.0
>  Upstream Author : Simon Lydell
> * URL : https://github.com/lydell/source-map-url#readme
> * License : Expat
>  Programming Lang: JavaScript
>  Description : Tools for working with sourceMappingURL comments.
>
> This module is useful for returning a sourceMappingURL,
> finding out if there exists a sourceMappingURL,
> removing a sourceMappingURL,
> inserting text before a sourceMappingURL in a code

A search for 'sourceMappingURL' reveals that this is something that is
used to allow one to debug minified JS, by ensuring that one can map
back to the original source -- I think you should mention that fact, as
repeatedly using the term sourceMappingURL without bothering to define
it forces one to wonder what it is supposed to mean.

How about:

 This module provides functions for manipulating sourceMappingURL
 comments (searching for, inserting and removing them).
 .
 These comments are used to provide the ability to map code that has
 been browserified/minified back to the original source files, to
 facilitate debugging.
 .
 Node.js is an event-based server-side JavaScript engine.

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


signature.asc
Description: PGP signature

Bug#854832: debian-reference: motd.tai

[Laurent Sauvage]

Package: debian-reference
Version: 2

Section 1.1.1 suggests use of "/etc/motd.tail" file which is out of date.

Bug#854830: apt updates initramfs incorrectly, breaks RAID/mdadm

[Brad Doster]

Huh?  The problem occurs when apt updates initramfs, so it is a package
manager issue, not a RAID manager issue.  Did you read the whole report?

On Fri, Feb 10, 2017 at 1:48 PM, Julian Andres Klode  wrote:

> Control: reassign -1
> On Fri, Feb 10, 2017 at 01:38:45PM -0800, Brad Doster wrote:
> > Package: apt
> > Version: 1.0.9.8.4
>
> Thanks for the laugh :) APT is your package manager, not your RAID
> manager. Reassigning there.
>
>
> >
> > During initial installation of Debian 8, I used mdadm to create 2 RAID
> > arrays as follows:
> >
> > /dev/md0 - RAID 1 - 4 drives - contains /boot only
> > /dev/md1 - RAID 5 - 3 drives + 1 spare - contains /
> >
> > Both are needed to successfully boot the system.
> >
> > During installation I name the machine HOSTA.  A few days later, I
> decided
> > to change the machine's host name to HOSTB.  After a few weeks of
> > successful operation of HOSTB, I ran apt-update followed by apt-upgrade.
> > Among the updates were linux-image updates, which caused initramfs to be
> > updated.  After the updates, rebooting the system landed me here:
> >
> > =
> > Gave up waiting for root device. Common problems:
> >   — Boot args (cat /proc/cmdline)
> > — Check rootdelay= (did the system wait long enough?)
> > — Check root= (did the system wait for the right device?)
> >   — Missing modules (cat /proc/modules; ls /dev)
> > ALERT! /dev/disk/by-uuid/054a6dcc-d280-4aff-9977 does not exist.
> > Dropping to a shell!
> >
> > BusyBox v.1.22.1 (Ubuntu 1:1.22.0-9deb8u1) built-in shell (ash)
> > Enter 'help' for list of built-in commands.
> >
> > /bin/sh: can't access tty: job control turned off
> > (initramfs)
> > =
> >
> > In the initramfs shell, /etc/mdadm/mdamd.conf contained the new hostname,
> > HOSTB instead of HOSTA:
> >
> > =
> > # definitions of existing MD arrays
> > ARRAY /dev/md/0  metadata=1.2 UUID=413a2cf3:ef0784ac:1e135c73:7a1723c6
> > name=HOSTB:0
> > ARRAY /dev/md/1  metadata=1.2 UUID=ae1ab583:e5e30fb9:e2c807a2:b5e95f42
> > name=HOSTB:1
> >spares=1
> > =
> >
> > Editing mdadm.conf to use HOSTA in place of HOSTB allowed me to assemble
> my
> > arrays and continue booting the system:
> >
> > =
> > (initramfs) mdadm --assemble --scan
> > mdadm: /dev/md/0 has been started with 4 drives.
> > mdadm: /dev/md/1 has been started with 3 drives and 1 spare.
> > (initramfs) exit
> > =
> >
> > After a successful boot, mdadm -D confirms that the original host name,
> > HOSTA is part of the array configuraion:
> >
> > =
> > mdadm -D /dev/md1
> > /dev/md1:
> > Version : 1.2
> >   Creation Time : Thu Dec 29 09:02:43 2016
> >  Raid Level : raid5
> >  Array Size : 2130618368 (2031.92 GiB 2181.75 GB)
> >   Used Dev Size : 1065309184 (1015.96 GiB 1090.88 GB)
> >Raid Devices : 3
> >   Total Devices : 4
> > Persistence : Superblock is persistent
> >
> >   Intent Bitmap : Internal
> >
> > Update Time : Thu Feb  9 17:25:16 2017
> >   State : clean
> >  Active Devices : 3
> > Working Devices : 4
> >  Failed Devices : 0
> >   Spare Devices : 1
> >
> >  Layout : left-symmetric
> >  Chunk Size : 512K
> >
> >Name : HOSTA:1   # <--- here is the original hostname
> given
> > to the machine during installation
> >UUID : ae1ab583:e5e30fb9:e2c807a2:b5e95f42
> >  Events : 4831
> >
> > Number   Major   Minor   RaidDevice State
> >0   830  active sync   /dev/sda3
> >1   8   191  active sync   /dev/sdb3
> >2   8   352  active sync   /dev/sdc3
> >
> >3   8   51-  spare   /dev/sdd3
> > =
> >
> > In this case, the updates to initramfs should NOT have changed the
> hostname
> > in the mdadm.conf file.  Doing so prevented the arrays from being
> assembled
> > and the system from booting.
> >
> > To get around the issue until the next apt-upgrade installs something
> > causing initramfs to be updated again, on the up and running system, edit
> > /etc/mdadm/mdadm.conf to use the original hostname and then run
> > update-initramfs to install the change.  Once done, the system reboots
> > normally again.
> >
> > Once the issue is known, it is also possible to run apt-upgrade to
> > completion, then before rebooting, edit mdamd.conf and manually execute
> > update-initramfs.  This will prevent an untimely visit to the BusyBox
> > screen, and in the case of remote upgrades being done, will prevent the
> > need to physically visit the server in order to complete the boot
> process.
> >
> > While this may be considered a problem with mdadm - why is it using a
> > potentially volatile parameter like hostname in its permanent
> > configuration? - until that is addressed, apt-upgrade should not modify
> the
> > hostname used in the mdadm.conf file.
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying

Bug#854830: apt updates initramfs incorrectly, breaks RAID/mdadm

[Julian Andres Klode]

Control: reassign -1 
On Fri, Feb 10, 2017 at 01:38:45PM -0800, Brad Doster wrote:
> Package: apt
> Version: 1.0.9.8.4

Thanks for the laugh :) APT is your package manager, not your RAID
manager. Reassigning there.


> 
> During initial installation of Debian 8, I used mdadm to create 2 RAID
> arrays as follows:
> 
> /dev/md0 - RAID 1 - 4 drives - contains /boot only
> /dev/md1 - RAID 5 - 3 drives + 1 spare - contains /
> 
> Both are needed to successfully boot the system.
> 
> During installation I name the machine HOSTA.  A few days later, I decided
> to change the machine's host name to HOSTB.  After a few weeks of
> successful operation of HOSTB, I ran apt-update followed by apt-upgrade.
> Among the updates were linux-image updates, which caused initramfs to be
> updated.  After the updates, rebooting the system landed me here:
> 
> =
> Gave up waiting for root device. Common problems:
>   — Boot args (cat /proc/cmdline)
> — Check rootdelay= (did the system wait long enough?)
> — Check root= (did the system wait for the right device?)
>   — Missing modules (cat /proc/modules; ls /dev)
> ALERT! /dev/disk/by-uuid/054a6dcc-d280-4aff-9977 does not exist.
> Dropping to a shell!
> 
> BusyBox v.1.22.1 (Ubuntu 1:1.22.0-9deb8u1) built-in shell (ash)
> Enter 'help' for list of built-in commands.
> 
> /bin/sh: can't access tty: job control turned off
> (initramfs)
> =
> 
> In the initramfs shell, /etc/mdadm/mdamd.conf contained the new hostname,
> HOSTB instead of HOSTA:
> 
> =
> # definitions of existing MD arrays
> ARRAY /dev/md/0  metadata=1.2 UUID=413a2cf3:ef0784ac:1e135c73:7a1723c6
> name=HOSTB:0
> ARRAY /dev/md/1  metadata=1.2 UUID=ae1ab583:e5e30fb9:e2c807a2:b5e95f42
> name=HOSTB:1
>spares=1
> =
> 
> Editing mdadm.conf to use HOSTA in place of HOSTB allowed me to assemble my
> arrays and continue booting the system:
> 
> =
> (initramfs) mdadm --assemble --scan
> mdadm: /dev/md/0 has been started with 4 drives.
> mdadm: /dev/md/1 has been started with 3 drives and 1 spare.
> (initramfs) exit
> =
> 
> After a successful boot, mdadm -D confirms that the original host name,
> HOSTA is part of the array configuraion:
> 
> =
> mdadm -D /dev/md1
> /dev/md1:
> Version : 1.2
>   Creation Time : Thu Dec 29 09:02:43 2016
>  Raid Level : raid5
>  Array Size : 2130618368 (2031.92 GiB 2181.75 GB)
>   Used Dev Size : 1065309184 (1015.96 GiB 1090.88 GB)
>Raid Devices : 3
>   Total Devices : 4
> Persistence : Superblock is persistent
> 
>   Intent Bitmap : Internal
> 
> Update Time : Thu Feb  9 17:25:16 2017
>   State : clean
>  Active Devices : 3
> Working Devices : 4
>  Failed Devices : 0
>   Spare Devices : 1
> 
>  Layout : left-symmetric
>  Chunk Size : 512K
> 
>Name : HOSTA:1   # <--- here is the original hostname given
> to the machine during installation
>UUID : ae1ab583:e5e30fb9:e2c807a2:b5e95f42
>  Events : 4831
> 
> Number   Major   Minor   RaidDevice State
>0   830  active sync   /dev/sda3
>1   8   191  active sync   /dev/sdb3
>2   8   352  active sync   /dev/sdc3
> 
>3   8   51-  spare   /dev/sdd3
> =
> 
> In this case, the updates to initramfs should NOT have changed the hostname
> in the mdadm.conf file.  Doing so prevented the arrays from being assembled
> and the system from booting.
> 
> To get around the issue until the next apt-upgrade installs something
> causing initramfs to be updated again, on the up and running system, edit
> /etc/mdadm/mdadm.conf to use the original hostname and then run
> update-initramfs to install the change.  Once done, the system reboots
> normally again.
> 
> Once the issue is known, it is also possible to run apt-upgrade to
> completion, then before rebooting, edit mdamd.conf and manually execute
> update-initramfs.  This will prevent an untimely visit to the BusyBox
> screen, and in the case of remote upgrades being done, will prevent the
> need to physically visit the server in order to complete the boot process.
> 
> While this may be considered a problem with mdadm - why is it using a
> potentially volatile parameter like hostname in its permanent
> configuration? - until that is addressed, apt-upgrade should not modify the
> hostname used in the mdadm.conf file.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#854831: libcrush: Incomplete debian/copyright?

[Chris Lamb]

Source: libcrush
Version: 1.0.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Loic Dachary (OuoU) 

Hi,

I just ACCEPTed libcrush from NEW but noticed it was missing 
attribution in debian/copyright for at least:

  googletest/googlemock/scripts/generator/cpp/keywords.py
  crush/crush_ln_table.h


(This is *not* exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

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

Bug#854830: apt updates initramfs incorrectly, breaks RAID/mdadm

[Brad Doster]

Package: apt
Version: 1.0.9.8.4

During initial installation of Debian 8, I used mdadm to create 2 RAID
arrays as follows:

/dev/md0 - RAID 1 - 4 drives - contains /boot only
/dev/md1 - RAID 5 - 3 drives + 1 spare - contains /

Both are needed to successfully boot the system.

During installation I name the machine HOSTA.  A few days later, I decided
to change the machine's host name to HOSTB.  After a few weeks of
successful operation of HOSTB, I ran apt-update followed by apt-upgrade.
Among the updates were linux-image updates, which caused initramfs to be
updated.  After the updates, rebooting the system landed me here:

=
Gave up waiting for root device. Common problems:
  — Boot args (cat /proc/cmdline)
— Check rootdelay= (did the system wait long enough?)
— Check root= (did the system wait for the right device?)
  — Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/054a6dcc-d280-4aff-9977 does not exist.
Dropping to a shell!

BusyBox v.1.22.1 (Ubuntu 1:1.22.0-9deb8u1) built-in shell (ash)
Enter 'help' for list of built-in commands.

/bin/sh: can't access tty: job control turned off
(initramfs)
=

In the initramfs shell, /etc/mdadm/mdamd.conf contained the new hostname,
HOSTB instead of HOSTA:

=
# definitions of existing MD arrays
ARRAY /dev/md/0  metadata=1.2 UUID=413a2cf3:ef0784ac:1e135c73:7a1723c6
name=HOSTB:0
ARRAY /dev/md/1  metadata=1.2 UUID=ae1ab583:e5e30fb9:e2c807a2:b5e95f42
name=HOSTB:1
   spares=1
=

Editing mdadm.conf to use HOSTA in place of HOSTB allowed me to assemble my
arrays and continue booting the system:

=
(initramfs) mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 4 drives.
mdadm: /dev/md/1 has been started with 3 drives and 1 spare.
(initramfs) exit
=

After a successful boot, mdadm -D confirms that the original host name,
HOSTA is part of the array configuraion:

=
mdadm -D /dev/md1
/dev/md1:
Version : 1.2
  Creation Time : Thu Dec 29 09:02:43 2016
 Raid Level : raid5
 Array Size : 2130618368 (2031.92 GiB 2181.75 GB)
  Used Dev Size : 1065309184 (1015.96 GiB 1090.88 GB)
   Raid Devices : 3
  Total Devices : 4
Persistence : Superblock is persistent

  Intent Bitmap : Internal

Update Time : Thu Feb  9 17:25:16 2017
  State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

 Layout : left-symmetric
 Chunk Size : 512K

   Name : HOSTA:1   # <--- here is the original hostname given
to the machine during installation
   UUID : ae1ab583:e5e30fb9:e2c807a2:b5e95f42
 Events : 4831

Number   Major   Minor   RaidDevice State
   0   830  active sync   /dev/sda3
   1   8   191  active sync   /dev/sdb3
   2   8   352  active sync   /dev/sdc3

   3   8   51-  spare   /dev/sdd3
=

In this case, the updates to initramfs should NOT have changed the hostname
in the mdadm.conf file.  Doing so prevented the arrays from being assembled
and the system from booting.

To get around the issue until the next apt-upgrade installs something
causing initramfs to be updated again, on the up and running system, edit
/etc/mdadm/mdadm.conf to use the original hostname and then run
update-initramfs to install the change.  Once done, the system reboots
normally again.

Once the issue is known, it is also possible to run apt-upgrade to
completion, then before rebooting, edit mdamd.conf and manually execute
update-initramfs.  This will prevent an untimely visit to the BusyBox
screen, and in the case of remote upgrades being done, will prevent the
need to physically visit the server in order to complete the boot process.

While this may be considered a problem with mdadm - why is it using a
potentially volatile parameter like hostname in its permanent
configuration? - until that is addressed, apt-upgrade should not modify the
hostname used in the mdadm.conf file.

Bug#854829: gnupg: tofu-default-policy ask -> Assertion "conflict_set" in get_trust failed

[Benedikt Wildenhain]

Package: gnupg
Version: 2.1.18-3
Severity: normal

Dear Maintainer,

setting "tofu-default-policy ask" in gnupg.conf causes gnupg to crash
when using the --fingerprint command under certain circumstances:

$ gpg --fingerprint
gpg: O j: Assertion "conflict_set" in get_trust failed 
(../../g10/tofu.c:2780)
Aborted

$ gpg --fingerprint  o@b
gpg: O j: Assertion "conflict_set" in get_trust failed 
(../../g10/tofu.c:2780)
Aborted

But:

$ gpg --fingerprint  to@b
pub   [...]

$ gpg --fingerprint  espera...@benedikt-wildenhain.de
pub   [...]

Kind regards,
Benedikt Wildenhain

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.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.18-3
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-9
ii  libgcrypt201.7.6-1
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-2
ii  libsqlite3-0   3.16.2-2
ii  zlib1g 1:1.2.8.dfsg-5

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

Versions of packages gnupg suggests:
ii  parcimonie  0.10.2-4
ii  xloadimage  4.1-24

-- no debconf information

Bug#842208: mozart-stdlib: FTBFS: dpkg-checkbuilddeps: error: Unmet build dependencies: mozart (>= 1.4.0)

[Hans Joachim Desserud]

I looked a bit at this issue and it seems the reason it fails on
amd64 is that mozart isn't built for this architecture
(see https://packages.debian.org/unstable/mozart).
I wonder whether this is related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822002

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#576242: RFC: Add native support for Linux SH

[John Paul Adrian Glaubitz]

Forgot to CC some relevant people and lists.

On 02/10/2017 09:55 PM, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> I have picked up an old patch which was posted to this mailing list
> in 2011 [1] which adds native GDB support for Linux SuperH (SH).
> 
> Since this patch was never merged for various reasons, it gained
> dust and needed some work to be usable with current versions of
> GDB again.
> 
> I have taken the patch and forward-ported it to the current version
> of GDB from git master. I have tested it on my SH7785LCR SuperH
> hardware on Debian unstable and I was able to debug simple C
> programs. I have not thoroughly tested the functionality, however.
> 
> With this post, I would like to ask for some feedback on how to
> proceed with this patch. The original author of the patch is
> Takashi Yoshii who wrote it while working at Renesas Electronics
> in Japan.
> 
> Back in 2011, one of the major show-stoppers why the patch was
> not merged was apparently the missing FSF copyright assignment
> by the author [2]. However, since Yoshii-san was working for
> Renesas back then, I think the copyright assignment would have
> to be signed by them and not him personally. And since Renesas
> has already contributed various SuperH code to various FSF
> projects like gcc and binutils, I'd assume that the necessary
> FSF copyright assignment has already been signed.
> 
> I have also asked Yutaka Niibe (CC'ed) to try to get into touch
> with Takashi Yoshii through his old connections at Renesas, in
> case we would need some input from Yoshii-san's side.
> 
> As for the technical part: I'm happy to take any feedback and
> improve the patch so it has reached the necessary quality to
> be able to get merged into GDB mainline.
> 
> Having native GDB support for Linux SH has become relevant
> again since the SuperH architecture is currently being
> redeveloped as the J-Core open source architecture [3].
> 
> Thanks,
> Adrian
> 
>> [1] http://www.cygwin.com/ml/gdb-patches/2011-11/msg00490.html
>> [2] http://www.cygwin.com/ml/gdb-patches/2011-11/msg00499.html
>> [3] http://j-core.org/
> 
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 


-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#813354: Ricochet im UI doesn't display characters correctly

[Daniel Kahn Gillmor]

Package: ricochet-im
Version: 1.1.4-1
Followup-For: Bug #813354

This is still a problem in 1.1.4-1, only now i'm only seeing it in the
main window, not during chat.

You can see the attached image -- blue regions are regions i've
manually redacted, but the headers for the sections that i'd expect to
read "ONLINE" and "OFFLINE" are failing to render properly.

 --dkg

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ricochet-im depends on:
ii  libc62.24-9
ii  libgcc1  1:6.3.0-5
ii  libgl1-mesa-glx [libgl1] 13.0.3-1
ii  libprotobuf103.0.0-9
ii  libqt5core5a 5.7.1+dfsg-3+b1
ii  libqt5gui5   5.7.1+dfsg-3+b1
ii  libqt5multimedia55.7.1~20161021-2
ii  libqt5network5   5.7.1+dfsg-3+b1
ii  libqt5qml5   5.7.1-2
ii  libqt5quick5 5.7.1-2
ii  libqt5widgets5   5.7.1+dfsg-3+b1
ii  libssl1.11.1.0c-2
ii  libstdc++6   6.3.0-5
ii  libubsan06.3.0-5
ii  qml-module-qtmultimedia  5.7.1~20161021-2
ii  qml-module-qtquick-controls  5.7.1~20161021-2
ii  qml-module-qtquick-dialogs   5.7.1~20161021-2
ii  tor  0.3.0.2-alpha-1.1

ricochet-im recommends no packages.

ricochet-im suggests no packages.

-- no debconf information

Bug#854828: Command

[Grześ Andruszkiewicz]

ga@grzes:~/Filmy/BBC$ get_iplayer --get --nopurge --vmode=flashhd1
--versions default,signed -o ~/Filmy/BBC --force --verbose 62
RTMPDump v2.4
(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
DEBUG: Protocol : RTMP
DEBUG: Hostname : vod-rtmp-uk-live.edgesuite.net
DEBUG: Port : 1935
DEBUG: Playpath :
mp4:secure/3200kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687137350.mp4?auth=daEb3c2a7cKdCaFczb3aKcNdhdnbXb8axdX-byNIy0-bWG-GppDJpCqNBoGsxH&aifp=v001&slist=secure/1500kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687139262.mp4;secure/800kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687139942.mp4;secure/480kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687135818.mp4;secure/3200kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687137350.mp4
DEBUG: tcUrl: rtmp://
vod-rtmp-uk-live.edgesuite.net:80/ondemand?_fcs_vhost=vod-rtmp-uk-live.edgesuite.net&undefined&auth=daEb3c2a7cKdCaFczb3aKcNdhdnbXb8axdX-byNIy0-bWG-GppDJpCqNBoGsxH&aifp=v001&slist=secure/1500kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687139262.mp4;secure/800kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687139942.mp4;secure/480kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687135818.mp4;secure/3200kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687137350.mp4
DEBUG: swfUrl   :
http://emp.bbci.co.uk/emp/SMPf/1.16.6/StandardMediaPlayerChromelessFlash.swf
DEBUG: pageUrl  : http://www.bbc.co.uk/iplayer/episode/b08dmjhg
DEBUG: app  : ondemand?_fcs_vhost=vod-rtmp-uk-live.edgesuite.net
&undefined&auth=daEb3c2a7cKdCaFczb3aKcNdhdnbXb8axdX-byNIy0-bWG-GppDJpCqNBoGsxH&aifp=v001&slist=secure/1500kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687139262.mp4;secure/800kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687139942.mp4;secure/480kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687135818.mp4;secure/3200kbps/modav/bUnknown-7151861f-6688-4896-8272-4d7860651b9c_b08dmjf7_1485687137350.mp4
DEBUG: live : no
DEBUG: timeout  : 10 sec
DEBUG: SWFSHA256:
DEBUG: a2 cb 88 90 ff 4a 91 a5 fc 2a fb 25 b4 6b 4b b5
DEBUG: ef 0f 4b eb 8a e2 f2 1b dd 33 72 fe 64 b5 25 44
DEBUG: SWFSize  : 979369
DEBUG: Setting buffer time to: 3600ms
Connecting ...
DEBUG: RTMP_Connect1, ... connected, handshaking
DEBUG: HandShake: Client type: 03
DEBUG: HandShake: Client digest offset: 430
DEBUG: HandShake: Initial client digest:
DEBUG: e1 f2 29 07 71 78 c8 e2 59 fc d4 49 51 ff fc 2b
DEBUG: 64 c7 04 cf 90 a7 ad cd 22 56 0d a1 e7 5f 6c a3
DEBUG: HandShake: Type Answer   : 03
DEBUG: HandShake: Server Uptime : 587242696

DEBUG: HandShake: FMS Version   : 5.0.7.1

DEBUG: HandShake: Calculated digest key from secure key and server digest:

DEBUG: 57 4f e8 ba 19 c9 3d 45 d8 3c ae 47 de f5 a3 86

DEBUG: 01 07 95 19 5a 8c 6d 8e f8 ee 1c 10 4b 50 77 35

DEBUG: HandShake: Client signature calculated:

DEBUG: cc f3 c2 18 c9 ea 0e 0b 2f 96 4b fb c7 d0 46 30

DEBUG: b7 b7 0d 37 08 e4 9f 11 50 a4 a1 b5 84 98 a2 69

DEBUG: HandShake: Server sent signature:

DEBUG: 3d 48 3c d1 32 b4 3c 39 66 fd 09 06 08 4f fd fa

DEBUG: 1c ce 3f 95 2e 3f 9d 31 45 71 39 56 80 96 e4 77

DEBUG: HandShake: Digest key:

DEBUG: 64 fc 2b 91 93 f5 1c ef 71 d9 f7 ef 55 84 d5 ec

DEBUG: d2 88 15 2c 6f 3f 4a 6d 1a f8 aa d5 73 1e d2 f5

DEBUG: HandShake: Signature calculated:

DEBUG: 3d 48 3c d1 32 b4 3c 39 66 fd 09 06 08 4f fd fa

DEBUG: 1c ce 3f 95 2e 3f 9d 31 45 71 39 56 80 96 e4 77

DEBUG: HandShake: Genuine Adobe Flash Media Server

DEBUG: HandShake: Handshaking finished

DEBUG: RTMP_Connect1, handshaked

DEBUG: Invoking connect

INFO: Connected...

DEBUG: HandleServerBW: server BW = 125

DEBUG: HandleClientBW: client BW = 125 2

DEBUG: HandleChangeChunkSize, received: chunk size change to 4096

DEBUG: RTMP_ClientPacket, received: invoke 242 bytes
DEBUG: (object begin)
DEBUG: (object begin)
DEBUG: Property: 
DEBUG: Property: 
DEBUG: Property: 
DEBUG: (object end)
DEBUG: (object begin)
DEBUG: Property: 
DEBUG: Property: 
DEBUG: Property: 
DEBUG: Property: 
DEBUG: Property: 
DEBUG: (object begin)
DEBUG: Property: 
DEBUG: (object end)
DEBUG: (object end)
DEBUG: (object end)
DEBUG: HandleInvoke, server invoking <_result>
DEBUG: HandleInvoke, received result for method call 
DEBUG: sending ctrl. type: 0x0003
DEBUG: Invoking createStream
DEBUG: RTMP_ClientPacket, received: invoke 21 bytes
DEBUG: (object begin)
DEBUG: Property: NULL
DEBUG: (object end)
DEBUG: HandleInvoke, server invoking 
DEBUG: Invoking _checkbw
DEBUG: RTMP_ClientPacket, received: invoke 29 bytes
DEBUG: (object begin)
DEBUG: Property: NULL
DEBUG: (object end)
DEBUG: HandleInvoke, server invoking <_result>
DEBUG: HandleInvoke, received result for method call 
DEBUG: SendPlay, seekTime=0, stopTime=0, sending play:
mp4:secure/3200kbps/modav/bUnknown-7

Bug#853783: ping

[Svante Signell]

severity 853783 serious
thanks

I view of the imminent release I'm upgrading the severity, since there has been
no replies so far, really strange. Do you not get reports about bugs via the bug
tracker?

How come 3.16.7-1 works and not later versions?

Bug#854828: get-iplayer: get_iplayer fails to save any content, *_original.partial.mp4.flv files are empty

[Grzegorz Andruszkiewicz]

Package: get-iplayer
Version: 2.97-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to download a few different programmes, e.g.
get_iplayer --get --nopurge --vmode=flashhd1 --versions default,signed -o
~/Filmy/BBC --force --verbose 62


   * What was the outcome of this action?
The file Andys_Baby_Animals_-_18._Hiding_b08dmjhg_original.partial.mp4.flv in
~/Filmy/BBC has size 0, conversion to .mp4 failed.




-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages get-iplayer depends on:
ii  ffmpeg  6:0.8.17-1
ii  libwww-perl 6.08-1
ii  libxml-simple-perl  2.20-1
pn  perl:any
ii  rtmpdump2.4+20150115.gita107cef-1

Versions of packages get-iplayer recommends:
ii  atomicparsley   0.9.2~svn110-4
ii  id3v2   0.1.12-2.1
ii  libmp3-info-perl1.24-1
ii  libxml-libxml-perl  2.0116+dfsg-1+deb8u1

get-iplayer suggests no packages.

-- no debconf information

Bug#854822: installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk"

[Cyril Brulebois]

Hi,

Karsten Merker  (2017-02-10):
> when using the "Guided - use entire disk" option, partman by
> default clobbers the boot sector and the area after it (where
> u-boot is located) to make sure that there are no remains of old
> partition tables.  We have code in partman-base that disables
> this clobbering on systems of which we know that u-boot would be
> damaged (which includes systems based on Freescale SoCs such as
> your Cubox-i), but this doesn't work in your case as we currently
> only disable the clobbering for /dev/mmcblk0 while your SD card
> shows up as /dev/mmcblk1. I am not 100% sure about that, but IIRC
> with older kernels the SD card in the cubox-i has shown up as
> /dev/mmcblk0. 
> 
> The relevant code in partman-base can be seen here:
> https://anonscm.debian.org/cgit/d-i/partman-base.git/tree/parted_server.c#n1377
> 
> The easiest solution would be to check for /dev/mmcblk instead of
> /dev/mmcblk0. If nobody has objections against this change, I'll
> modify partman-base accordingly and upload a new version (CCing the
> partman-base uploaders Max Vozeler, Anton Zinoviev, Colin Watson and
> Christian Perrier and Kibi as the d-i release manager).

That seems like a fair approach, feel free to go ahead; thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#854376: [pkg-gnupg-maint] Bug#854376: Unable to use gpg-agent as ssh-agent

[Daniel Kahn Gillmor]

Hi Punit--

On Thu 2017-02-09 07:25:17 -0500, Punit Agrawal wrote:
> I've got version 2.1.18-3 of the package (I'm running testing)

> % readlink -f $(which pinentry)
> /usr/bin/pinentry-qt

> sddm

>>  * do you have dbus-user-session installed?
>
> No.

Thanks for the feedback!

The problem that you're having is because ssh does not tell gpg-agent
anything about how to contact the user, and gpg-agent is started as a
service by systemd.

I believe that if you were to install dbus-user-session, fully log out,
and then log back in again with sddm, gpg-agent would get launched when
asked with the correct $DISPLAY environment variable, and your ssh
attempt would just work, without needing to do the updatestartuptty
dance.

The gnupg-agent package Suggests: dbus-user-session to facilitate
exactly your use case.

Please let me know if dbus-user-session works for you!

   --dkg


signature.asc
Description: PGP signature

Bug#852697: [pkg-gnupg-maint] Bug#852697: Bug#852697: gnupg-agent: automatically starts gpg-agent in root user slice

[Daniel Kahn Gillmor]

Hi Michael--

On Thu 2017-02-09 05:28:44 -0500, Michael Jones wrote:
> I also can't ssh, it seems the gpg-agent no longer looks at
> "/home/mike/.gnupg/gpg-agent.conf", does not find "enable-ssh-support",
> and starts the gpg agent without ssh support as;
>
> mike  1717 1  0 10:09 ?00:00:00 /lib/systemd/systemd --user
> ...
> mike  3275  1717  0 10:23 ?00:00:00  \_ /usr/bin/gpg-agent 
> --supervised

This is unrelated to 852697, where you reported it.

also, enable-ssh-support is on by default in modern versions of
gnupg-agent.

You might be more interested in https://bugs.debian.org/854376 or maybe
your report is something different.  If you read the notes over there
and follow up on it, that would be fine.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#854827: unblock: gtk-vnc/0.6.0-3

[Guido Günther]

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

Please unblock package gtk-vnc

It fixes CVE-2017-5885 and CVE-2017-5884. There's more noise in the diff
than there should be since wanted to bring patches into a more
git-format-patch compatible layout. The diff is probably easier to read
here:

  https://anonscm.debian.org/cgit/pkg-libvirt/gtk-vnc.git/log/

unblock gtk-vnc/0.6.0-3

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 8698ecc..28203ee 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+gtk-vnc (0.6.0-3) unstable; urgency=medium
+
+  * [b8d9918] CVE-2017-5884: Fix bounds checking for RRE, hextile & copyrect
+encodings
+  * [ca87ace] CVE-2017-5885: Correctly validate color map range indexes
+(Closes: #854450)
+  * [0e71020] Link against GIO_LIBS explicitly to fix build failure
+  * [7d3fdde] Rediff patches to make them more git-format-patch compatible
+
+ -- Guido Günther   Fri, 10 Feb 2017 14:20:29 +0100
+
 gtk-vnc (0.6.0-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/patches/Add-I-m4-to-Makefile.am.patch b/debian/patches/Add-I-m4-to-Makefile.am.patch
new file mode 100644
index 000..8d44369
--- /dev/null
+++ b/debian/patches/Add-I-m4-to-Makefile.am.patch
@@ -0,0 +1,19 @@
+From: Joao Eriberto Mota Filho 
+Date: Fri, 10 Feb 2017 10:22:10 +0100
+Subject: Add -I m4 to Makefile.am
+
+---
+ Makefile.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 69d1f50..dabb899 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -1,5 +1,5 @@
+ SUBDIRS = src tools examples po vapi
+-ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS}
++ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
+ 
+ pkgconfig_DATA = $(PACKAGE)-$(GTK_VNC_API_VERSION).pc gvnc-1.0.pc
+ pkgconfigdir = $(libdir)/pkgconfig
diff --git a/debian/patches/Add-m4.patch b/debian/patches/Add-m4.patch
deleted file mode 100644
index c5bdca4..000
--- a/debian/patches/Add-m4.patch
+++ /dev/null
@@ -1,12 +0,0 @@
-Description: add -I m4 to Makefile.am
-Author: Joao Eriberto Mota Filho 
-Last-Update: 2017-01-08
 gtk-vnc-0.6.0.orig/Makefile.am
-+++ gtk-vnc-0.6.0/Makefile.am
-@@ -1,5 +1,5 @@
- SUBDIRS = src tools examples po vapi
--ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS}
-+ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
- 
- pkgconfig_DATA = $(PACKAGE)-$(GTK_VNC_API_VERSION).pc gvnc-1.0.pc
- pkgconfigdir = $(libdir)/pkgconfig
diff --git a/debian/patches/Link-against-GIO_LIBS-explicitly.patch b/debian/patches/Link-against-GIO_LIBS-explicitly.patch
new file mode 100644
index 000..d962eb4
--- /dev/null
+++ b/debian/patches/Link-against-GIO_LIBS-explicitly.patch
@@ -0,0 +1,31 @@
+From: =?utf-8?q?Guido_G=C3=BCnther?= 
+Date: Fri, 10 Feb 2017 13:16:26 +0100
+Subject: Link against GIO_LIBS explicitly
+
+to avoid
+
+libtool: link: gcc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -fdebug-prefix-map=/build/gtk-vnc-0.6.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro
+ -Wl,-z -Wl,now -o .libs/vncconnectiontest vncconnectiontest-vncconnectiontest.o  ./.libs/libgvnc-1.0.so -lz -pthread
+/usr/bin/ld: vncconnectiontest-vncconnectiontest.o: undefined reference to symbol 'g_io_stream_get_output_stream'
+//usr/lib/x86_64-linux-gnu/libgio-2.0.so.0: error adding symbols: DSO missing from command line
+
+Also make the use of *_CFLAGS and *_LIBS match.
+---
+ src/Makefile.am | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index f7c1d9d..8bc9085 100644
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -317,8 +317,8 @@ BUILT_SOURCES += $(MARSHAL_FILES) $(ENUM_FILES)
+ CLEANFILES = $(MARSHAL_FILES) $(ENUM_FILES)
+ 
+ vncconnectiontest_SOURCES = vncconnectiontest.c
+-vncconnectiontest_CFLAGS = $(GOBJECT_CFLAGS)
+-vncconnectiontest_LDADD = libgvnc-1.0.la
++vncconnectiontest_CFLAGS = $(GOBJECT_CFLAGS) $(GIO_CLFAGS)
++vncconnectiontest_LDADD = libgvnc-1.0.la $(GOBJECT_LIBS) $(GIO_LIBS)
+ 
+ if WITH_PYTHON
+ pyexec_LTLIBRARIES = gtkvnc.la
diff --git a/debian/patches/Remove-GNUmakefile-links.patch b/debian/patches/Remove-GNUmakefile-links.patch
index e35e3b9..a25c47f 100644
--- a/debian/patches/Remove-GNUmakefile-links.patch
+++ b/debian/patches/Remove-GNUmakefile-links.patch
@@ -9,10 +9,10 @@ since it breaks the out of tree build
  2 files changed, 22 deletions(-)
 
 diff --git a/configure b/configure
-index 9e779d3..7e8162d 100755
+index 697

Bug#853770: unblock: pyro4

[GCS]

On Fri, Feb 3, 2017 at 11:11 PM, Emilio Pozuelo Monfort
 wrote:
> On 31/01/17 19:18, Laszlo Boszormenyi (GCS) wrote:
>> Which solution would be allowed for Stretch?
>
> bootstrap-vz depends on python2-pyro4, so we can't just drop it.
>
> I don't like 2, I'd rather add a new source than embed this inside pyro.
>
> Please upload selectors34 and I'll see about granting an exception to fix this
> RC bug.
 Both selectors34 and fixed pyro4 was uploaded some days ago - I let
them age a bit to reveal any issues. None so far, thus please unblock
both packages.

Thanks,
Laszlo/GCS

Bug#851458: not-enough-i18n'ed string on devel/website/stats/ pages

[Laura Arjona Reina]

Thanks for the patch, committed.
Best regards

El 15/01/17 a las 17:05, victory escribió:
> it lacked define-tag for index; revised patch below:
> 
> Index: stattrans.pl
> ===
> --- stattrans.pl  (revision 240)
> +++ stattrans.pl  (working copy)
> @@ -535,6 +535,11 @@
>  if (open (HTML, ">$config{'htmldir'}/$l.wml")) {
>   printf HTML "#use wml::debian::template 
> title=\"<:=\$trans{\$CUR_ISO_LANG}{%s}:>\"\n", $lang;
>   print HTML "#use wml::debian::toc\n";
> + printf HTML qq| href="%s">webwml-stattrans\n|,
> + alioth_cvs_view_url('stattrans.pl');
> + print HTML "\n";
> + print HTML "Created with 
> \n"
> + print HTML "\n";
>  print HTML " type=\"text/javascript\">\n\n";
>  $color = get_color ($percent_a{$lang});
>  
> @@ -655,10 +660,7 @@
>  print HTML "\n";
>  }
>  
> -print HTML
> -'Created with  href="'
> -. alioth_cvs_view_url('stattrans.pl')
> -. '">webwml-stattrans' . "\n";
> +print HTML "\n";
>  close (HTML);
>  } else {
>  print "Can't open $config{'htmldir'}/$l.wml\n";
> @@ -675,6 +677,11 @@
>  
>  print HTMLI "#use wml::debian::stats_tags\n";
>  printf HTMLI "#use wml::debian::template title=\"%s\"\n\n", $config{'title'};
> +printf HTMLI qq| href="%s">webwml-stattrans\n|,
> + alioth_cvs_view_url('stattrans.pl');
> +print HTMLI "\n";
> +print HTMLI "Created with 
> \n"
> +print HTMLI "\n";
>  print HTMLI 'Translated web 
> pages'."\n";
>  printf HTMLI " %d>\n",($wml{'english'}+$untranslated{'english'});
>  
> @@ -809,10 +816,7 @@
>  print HTMLI "";
>  print HTMLI "\n";
>  
> -print HTMLI
> -'Created with webwml-stattrans' . "\n";
> +print HTMLI "\n";
>  close (HTMLI);
>  
>  print "done.\n" if ($config{'verbose'});
> 
> 


-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

btw fyi https://bugs.chromium.org/p/chromium/issues/detail?id=675411

i noted a vast and i mean constant monotonous barely-tolerable number
of gpu freezing errors when operating inside of china.  i therefore
suspect that this is a race condition between networking code and the
gpu code.

l.

Bug#854079: firefox-esr: firefox dies immediately on arm64

[Aaro Koskinen]

Hi,

On Tue, Feb 07, 2017 at 02:57:31PM +, Riku Voipio wrote:
> The patch needed a bit of changing but after applying and compiling,
> firefox now indeed works on arm64. Thanks.
> 
> Build package at: https://people.debian.org/~riku/firefox/ 

Yeah, this version works - thanks!

A.

Bug#848859: [bug #25503] test failures

[Paolo Greppi]

URL:
  

 Summary: test failures
 Project: Getfem
Submitted by: paolog
Submitted on: Fri 10 Feb 2017 07:20:43 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hi, the getfem testsuite fails in about 5% of the cases.

For more details please see: https://bugs.debian.org/848859

We encountered different failures:
- test_continuation.pl - Wrong number of bifurcation points
- make_gmm_test.pl - Error too large in auto_gmm_torture15_sub.cc
- make_gmm_test.pl - QR algorithm failed in gmm_torture01_lusolve.cc
- make_gmm_test.pl - QR algorithm failed in gmm_torture05_mult.cc
- make_gmm_test.pl - QR algorithm failed in
gmm_torture20_iterative_solvers.cc

Unfortunately I don't have the artifacts for all those, ATM I have them only
for the last one (see attchments).

Thanks,

Paolo



___

File Attachments:


---
Date: Fri 10 Feb 2017 07:20:43 PM UTC  Name: test-suite.log  Size: 2kB   By:
paolog
the trace and the generated file for the last error

---
Date: Fri 10 Feb 2017 07:20:43 PM UTC  Name:
auto_gmm_torture20_iterative_solvers.cc  Size: 10kB   By: paolog
the trace and the generated file for the last error


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/

Bug#854826: [ARM64] kexec: Increase the upper limit for RAM segments

[Manoj Iyer]

Package: kexec-tools
Version: 2.0.14-1
Tags: arm64
Severity: important
Usertags: arm64

On a newer UEFI based Qualcomm target the number of system ram regions 
retrieved from /proc/iomem are ~40. Currently KEXEC_SEGMENT_MAX is set 
to 16, which represents the kexec segments passed to kexec_load 
syscall, like kernel image, initrd image etc. The patch increases the 
value to 64. This enables kexec to see all the "System RAM" as recorded 
in /proc/iomem.


With KEXEC_SEGMENT_MAX hardcoded to 16, currently kexec is unable to 
see all the "System RAM" recorded in /proc/iomem.

Bug#854821: Reverting 29be63fd restores the old behavior

[Nish Aravamudan]

Just ran a quick test using a PPA build of glibc with 29be63fd
("debian/patches/localedata/locale-C.diff: switch back transliterations
to combining. Closes: #840199" [0] reverted and the test passes in a
17.04 (Zesty) container again.

Thanks,
Nish

[0]
https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=29be63fde23ee497bb83fc9fee77171d26a7d447

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#854721: ftp.debian.org: Artistic License 1.0 is not DFSG compliant

[Javier Serrano Polo]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 ftp.debian.org: Artistic License 1.0 is not DFSG compliant
Control: reopen -2

El dj 09 de 02 de 2017 a les 18:10 -0800, Russ Allbery va escriure:
> We aren't the body in Debian that
> judges the DFSG compatibility of licenses (that's ftp-master), nor do we
> own or can modify the DFSG itself.

Then let us move this to ftp.debian.org. FTP team, please read #854679
and this report. The main issue is, in essence, whether the requirement
to not sell individual software is against DFSG #6 (no discrimination
against fields of endeavor).


smime.p7s
Description: S/MIME cryptographic signature

Bug#843126: gpg2 bug encountered

[Dave Steele]

The bug I encountered appears to be #46, which is still open:

https://github.com/freight-team/freight/issues/46


-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#854824: ITP: ht-el -- hash table library for Emacs

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: ht-el
  Version : 2.1
  Upstream Author : Wilfred Hughes 
* URL : https://github.com/Wilfred/ht.el
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : missing hash table library for Emacs

The missing hash table library for Emacs. Libraries like `s.el'
(strings) and `dash.el' (lists) have shown how much nicer Emacs Lisp
programming can be with good libraries. `ht.el' aims to similarly
simplify working with hash tables.

Common operations with hash tables (e.g. enumerate the keys) are too
difficult in Emacs lisp.

`ht.el' offers:

 * a consistent naming scheme;
 * a more natural argument ordering;
 * a more comprehensive range of hash table operations;
 * mutation functions always return nil.

Bug#792101: (no subject)

[Michael Lustfield]

Control: retitle -1 ITP: gitea -- A painless self-hosted git service.

New URL: https://github.com/go-gitea/gitea
New package name: gitea
Provides: gogs


Rationale:

While slowly working through this lovely dependency mess, I've been learning
how to build better packages. In doing so, I've been attempting to work with
the gogs author to address some concerns. My hope was to find simple solutions
instead of having to get clever and maintain a mess. The author was quick to
respond when presented with a compliment but fell completely silent otherwise.

After looking through the PR/issue queue, I noticed a problem when it comes to
working with any attempt at a community. I noticed an unnerving trend of not
responding in any way to concerns/complains. I saw some PR's ignored for months
and then closed because they no longer merged cleanly.


The primary fork of gogs is gitea which has quickly built a strong community.

Their View: https://blog.gitea.io/2016/12/welcome-to-gitea/

After everything I've seen, I'm inclined to agree. Gitea appears to have a very
active community that watches their ancestor's commits closely. I've been given
the impression coordinated security releases would be possible with the gitea
"owners" where I would be hesitant to attempt involving the gogs owner.


Because gitea keeps watch of gogs and pulls changes in as needed, I feel it
would sensible to let the gitea provide gogs as a virtual package selecting
gitea. In the event someone wanted to maintain a vanilla gogs, I would be more
than happy to drop that from the packaging, but would otherwise prefer it as a
convenience to new users.

I still have a *lot* of work to do on the dependencies, so lots of room for
discussion if anyone is interested.
-- 
Michael Lustfield

Bug#806713: disk-detect/multipath: update checks for changed mpath alias names

[Cyril Brulebois]

Mathieu Trudel-Lapierre  (2017-02-10):
> That's perhaps right; we could possibly do away with the [0-9] part in the
> check. The reason for changing it to [a-z] was only to have the smallest
> amount of changes possible. I don't see what benefit that would really
> bring though, but I haven't looked at multipath in a while.

Knowing nothing about multipath, I first read the multipath-tools commit
message as “[0-9] → [a-z] only when user friendly names are enabled,
[0-9] otherwise”, which I why I was wondering whether we were losing
support in the non-user friendly names case; but that doesn't seem to be
the case.

> I also could have been more proactive at this; I'll update the
> branches shortly -- there has been further changes to
> partman-multipath and hw-detect to help with multipath support.

Feel free to let me know once you've done so, since I've just uploaded
hw-detect_1.123_source and partman-base_191_source. I suppose what's
been just uploaded could be pushed to jessie, while what you'll be
pushing in a moment would only be for stretch?


> > > Apart from the disk-detect package, the partman-multipath package
> > > is also affected by mpath naming change.  I will open a separate
> > > bug report and attach a patch to solve the naming there.
> >
> > I'll try and look at the various patches after Mathieu's reply in
> > #806900. I might even propose them through proposed-updates if the
> > next RC looks good for multipath support.
> 
> I'm sorry, I just don't see what I should be replying to? We're really
> not far from multipath support working (given that it does appear to
> work reasonably well in Ubuntu). Let me do the merges to get Ubuntu
> based on the right new versions of Debian, then we can do one round of
> reviewing all the patches.

I meant it as: thanks to your reply to me in that other bug report, I
know what packages I should be looking at, not as “please do more work
for me”. Apologies for the confusion.


KiBi.


signature.asc
Description: Digital signature

Bug#806713: disk-detect/multipath: update checks for changed mpath alias names

[Mathieu Trudel-Lapierre]

On Fri, Feb 10, 2017 at 1:02 PM, Cyril Brulebois  wrote:

> Hi,
>
> Hendrik Brueckner  (2015-11-30):
> > Dear maintainers,
> >
> > An update in the multipath-tools, [1], changed the naming scheme for
> > mpath aliases created when the user friendly names option is specified.
> >
> > The alias naming changed from mpath0 to mpatha replacing the numeric
> > digits with alphabetic letters.  The patch below updates the
> > disk-detect.sh to correctly detect multipath devices with the new
> > naming scheme.
>
> AFAICT from the current manpage, when this option is not specified, WWID
> are used instead, so there's no need to keep the [0-9] part in the
> check, right? This seems confirmed by my reading of #806900 so I think
> I'll push the patch to master right away.
>
>
That's perhaps right; we could possibly do away with the [0-9] part in the
check. The reason for changing it to [a-z] was only to have the smallest
amount of changes possible. I don't see what benefit that would really
bring though, but I haven't looked at multipath in a while.


> > On the people/cyphermox/mpath-detect branch in the d-i/hw-detect
> > repository, there is already a patch for the same problem.  I could
> > not find a bug report for it.  So that's why I am opening this one to
> > keep this problem in mind.  It would be great if you could help me to
> > understand the practice on how such problem fixes becomes integrated.
>
> Unfortunately lack of manpower means patches are sometimes not reviewed
> or merged for a long time. :(
>

I also could have been more proactive at this; I'll update the branches
shortly -- there has been further changes to partman-multipath and
hw-detect to help with multipath support.


>
> > Apart from the disk-detect package, the partman-multipath package is
> > also affected by mpath naming change.  I will open a separate bug report
> > and attach a patch to solve the naming there.
>
> I'll try and look at the various patches after Mathieu's reply in
> #806900. I might even propose them through proposed-updates if the next
> RC looks good for multipath support.
>

I'm sorry, I just don't see what I should be replying to? We're really not
far from multipath support working (given that it does appear to work
reasonably well in Ubuntu). Let me do the merges to get Ubuntu based on the
right new versions of Debian, then we can do one round of reviewing all the
patches.


/ Matt

Bug#854816: remmina: Blank screen on ssh connections

[Marek Straka]

After many tries I came to vte2.91 version 0.42.5-1
http://snapshot.debian.org/package/vte2.91/0.42.5-1/#libvte-2.91-0_0.42.5-1
which is last working version of VTE in Remmina.

After extraction of libvte-2.91.so.0.4200.5 and
"LD_PRELOAD=/opt/libvte-2.91.so.0.4200.5 remmina"
is ssh connection in Remmina working again.

Bug#854814: Fails to start systemd-resolved

[Michael Biebl]

Control: severity -1 important

Am 10.02.2017 um 17:49 schrieb Yuri D'Elia:
> 
> With the update to 232-17, systemd-resolved fails to start with the
> following error:
> 

> -- The error number returned by this process is 2.
> Feb 10 17:46:31 test systemd[1]: systemd-resolved.service: Main process
> exited, code=exited, status=226/NAMESPACE
> Feb 10 17:46:31 test systemd[1]: Failed to start Network Name Resolution.
> -- Subject: Unit systemd-resolved.service has failed

This is caused by the addition of ReadWritePaths= in

/lib/systemd/system/systemd-resolved.service.d/resolvconf.conf

I guess this should only be used in addition with ProtectSystem=, which
is a recent upstream change but the Debian version does not use that yet.


-- 
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#854814: Fails to start systemd-resolved

[Michael Biebl]

Am 10.02.2017 um 17:49 schrieb Yuri D'Elia:
> Package: systemd
> Version: 232-17
> Severity: normal
> 
> With the update to 232-17, systemd-resolved fails to start with the
> following error:
> 
> -- The error number returned by this process is 2.
> Feb 10 17:46:31 test systemd[1]: systemd-resolved.service: Main process 
> exited, code=exited, status=226/NAMESPACE
> Feb 10 17:46:31 test systemd[1]: Failed to start Network Name Resolution.
> -- Subject: Unit systemd-resolved.service has failed 

Slightly related:

Martin, what do you think about adding an autopkgtest which starts all
daemons (manually) that are shipped by systemd, no matter whether it is
enabled or not, and simply checks the return code of the start attempt.
(we can of course add more elaborate checks to test whether the service
is functional, but a successful start is the baseline)

With the recent changes upstream to enable more sandboxing features,
this could be helpful, I guess.

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#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[Ludovic Rousseau]

On Tue, 07 Feb 2017 15:17:04 +0900 NIIBE Yutaka  wrote:

Hello,


Hello,
 

On GNU/Linux, use of PC/SC service is not recommended for OpenPGP card


Why is that exactly?


(installing PC/SC is OK) and the use of different smartcards with PC/SC
(OpenPGP card together with other cards) requires struggle anyway, so, I
think that asking such users would be an option.


My proposal:

- if "disable-ccid" is present then use PC/SC
- if "disable-ccid" is not present then use the internal CCID only and do not 
use PC/SC

The default value would be to use "disable-ccid".

People that _really_ know what they do could remove the "disable-ccid" (and 
break PC/SC).


The situation is complicated becase only some limited card readers works
for OpenPGP card.  Since most users prefer longer key size of RSA these
days, the use of OpenPGP card requires tough condition to card reader.
Some workaround in the lower level of USB communcation for specific card
readers are implemented in the internal CCID driver, so, if the use if
for OpenPGP card, internal CCID driver is better option.


Use of long RSA keys require extended APDU. Not all smart card readers support 
extended APDU.
See https://pcsclite.alioth.debian.org/ccid_extended_apdu.html and 
https://ludovicrousseau.blogspot.fr/2011/05/extended-apdu-status-per-reader.html

Bye

--
Dr. Ludovic Rousseau

Bug#854822: installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk"

[Gunnar Wolf]

Please note that the provided "hardware-summary" was taken from the
second (successful) install. I mention this due to:

> (...)
> ==
> Installer hardware-summary:
> ==
> (...)
> df: Filesystem   1K-blocks  Used Available Use% Mounted on
> df: none20659276206516   0% /run
> df: devtmpfs   1017956 0   1017956   0% /dev
> df: /dev/sda1  4068576360716   3707860   9% /hd-media
> df: /dev/loop0  360712360712 0 100% /cdrom
> df: /dev/mmcblk1p312976824470844  11827068   4% /target
> df: /dev/mmcblk1p2  240972 25124203407  11% /target/boot
> df: /dev/mmcblk1p312976824470844  11827068   4% /dev/.static/dev
> df: devtmpfs   1017956 0   1017956   0% /target/dev
> df: /dev/loop0  360712360712 0 100% 
> /target/media/cdrom

This could cause a confusion otherwise.

Thanks,


signature.asc
Description: Digital signature

Bug#849592: bug report - icedove: href links inoperative

[Rick Lutowski]

Yes, I do recall explicitly responding to a query to make the browser 
the default (don't recall if I did this once or twice since it was years 
ago).


For now, removing (renaming) all 3 files

userapp- Icedove-EGPMWX.desktop,
userapp-Iceweasel-RYY0FY.deskto, and
mimeapps.list

has restored email link functionality with minimal effort.  If this 
leads to other behavioral problems, will play with the file contents.


Appreciate knowing which files are implicated.  Thanks very much for the 
feedback and explanations.


--
Rick Lutowski
r...@jreality.com
512-688-1675



On 02/10/2017 10:52 AM, Jens Reyer wrote:

control: clone -1 -2
control: retitle -1 icedove: transition old userapp .desktop file
control: retitle -2 firefox: transition old userapp .desktop file

tl;dr for the firefox and thunderbird maintainers:
The files
~/.local/share/applications/userapp-Icedove-*.desktop
~/.local/share/applications/userapp-Iceweasel-*.desktop
need to be transitioned for the new path of the Exec.  Tell me if you
need more help (patches).


On 02/07/2017 09:18 PM, Rick Lutowski wrote:

Hope this helps to isolate the problem.

Thanks for your quick feedback!


What happened is (these are sometimes only assumptions, I'm not in-depth
familiar with these packages):


Once upon a time you accepted icedove's and iceweasel's suggestion to
make them the default application for their tasks.

At that time:

* icedove created
   ~/.local/share/applications/userapp-Icedove-EGPMWX.desktop
   with the line[1]
   Exec=/usr/lib/icedove/icedove %u

* iceweasel created
   ~/.local/share/applications/userapp-Iceweasel-RYY0FY.desktop
   with the line[2]
   Exec=/usr/lib/iceweasel/iceweasel %u

* Then icedove and iceweasel each created entries for these in
   ~/.local/share/applications/mimeapps.list[3], which lists your
   personal preferences for default applications.

Now today your issue (icedove fails to open links) is because you
followed the transition from iceweasel to firefox.  Thus the specified
default app for weblinks /usr/lib/iceweasel/iceweasel doesn't exist anymore.



So the
~/.local/share/applications/userapp-{Icedove,Iceweasel}-*.desktop
files need to be transitioned.  For Rick's specific issue the iceweasel
one is relevant.


A1:
It's probably best to backup them and only make a minimal change in them.

A2:
Another option would be to also rename them. This would require a change
of mimeapps.list, too.  For this one needs to check both the deprecated
location ~/.local/share/applications/, and the modern one in ~/.config
(I'm still confused when which file is used by a Debian system today).
Maybe it's also necessary to explicitly trigger an update of the inverse
index of the .desktop files in mimecache.info.

A3:
Finally one could just backup and then delete the .desktop files
(current packages provide their desktop files in
/usr/share/applications/, so a new mimeapps.list entry doesn't require
the old .desktop files).  Again this would require a change of
mimeapps.list and mimecache.info.



Thunderbird has a wrapper script /usr/bin/thunderbird (linked to from
/usr/bin/icedove) which does a migration of some things if an old
icedove profile folder exists, and there's no new thunderbird profile
folder yet.  I now wonder if the fix should be:

B1:
in the conditional (one-time only) part of /usr/bin/thunderbird, or

B2:
(because testing users already went through this one-time transition) in
a separate new part, conditional on the existence of the old .desktop
file and its contents (e.g. grep -i icedove).

For thunderbird I suggest A1/B2.



I'm not familiar with what firefox did/does for the transition.  Maybe
it already does something (see my note in [3]), but then it didn't do it
in a way that worked for you.  I suggest to do something similar like
A1/B2 in /usr/bin/firefox.


Greets
jre



[1]
Rick's ~/.local/share/applications/userapp-Icedove-EGPMWX.desktop:
---
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/usr/lib/icedove/icedove %u
Name=Icedove
Comment=Custom definition for Icedove



[2]
Rick's ~/.local/share/applications/userapp-Iceweasel-RYY0FY.desktop:

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/usr/lib/iceweasel/iceweasel %u
Name=Iceweasel
Comment=Custom definition for Iceweasel

Note: I had a userapp-Firefox-1M35PY.desktop, but just deleted it
instead of investigating, because I was working on something else, see
#845334 for Wine.


[3]
I don't know when this changed, but nowadays (on a clean system with no
previous entries) firefox/thunderbird only create entries in
~/.config/mimeapps.list, which appears to use
/usr/share/applications/thunderbird.desktop and
/usr/share/applications/firefox-esr.desktop.
.
Rick's ~/.local/share/applications/mimeapps.list:
--
[Default Applications]
x-scheme-handler/mailto=userapp-Icedove-EGPMWX.desktop
message/rfc822=userapp-Icedove-EGPMWX.desktop
application/x-extension-eml=userapp-Icedove-EGPMW

Bug#854823: alsa-base: External microphone TRRS jack on MacBookAir7,2 not detected

[Daniele]

Package: alsa-base
Severity: normal

Dear Maintainer,

on my MacBookAir7,2 (early 2015) there is a TRRS jack for audio input and
output. Whenever I connect a headset, the headphones work, but the microphone
is not detected. The same headset in Mac OS X (dual boot on the same machine)
works perfectly. I tried another headset, but the behaviour is the same.
If I open pavucontrol, I see 2 input devices: "Internal microphone" and
"Microphone (unplugged)", the latter never becomes active, regardless of any
jack inserted.
I tried to change the pin configuration with the hdajackretask but nothing
changed.

Do you have any idea about this issue?

I attach the output of alsa-info.sh script

Thank you

Daniele



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

Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
upload=true&script=true&cardinfo=
!!
!!ALSA Information Script v 0.4.64
!!

!!Script ran on: Fri Feb 10 17:51:09 UTC 2017


!!Linux Distribution
!!--

Debian GNU/Linux 8 \n \l PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian 
GNU/Linux" ID=debian HOME_URL="http://www.debian.org/"; 
SUPPORT_URL="http://www.debian.org/support"; 
BUG_REPORT_URL="https://bugs.debian.org/";


!!DMI Information
!!---

Manufacturer:  Apple Inc.
Product Name:  MacBookAir7,2
Product Version:   1.0
Firmware Version:  MBA71.88Z.0166.B16.1612230252
Board Vendor:  Apple Inc.
Board Name:Mac-937CB26E2E02BB01


!!ACPI Device Status Information
!!---

/sys/bus/acpi/devices/ACPI0001:00/status 15
/sys/bus/acpi/devices/ACPI0008:00/status 15
/sys/bus/acpi/devices/APP0001:00/status  11
/sys/bus/acpi/devices/APP0002:00/status  11
/sys/bus/acpi/devices/APP000D:00/status  15
/sys/bus/acpi/devices/INT33C1:00/status  15
/sys/bus/acpi/devices/PNP0103:00/status  15
/sys/bus/acpi/devices/PNP0C0E:00/status  11
/sys/bus/acpi/devices/PNP0C0F:00/status  9
/sys/bus/acpi/devices/PNP0C0F:01/status  9
/sys/bus/acpi/devices/PNP0C0F:02/status  9
/sys/bus/acpi/devices/PNP0C0F:03/status  9
/sys/bus/acpi/devices/PNP0C0F:04/status  9
/sys/bus/acpi/devices/PNP0C0F:05/status  9
/sys/bus/acpi/devices/PNP0C0F:06/status  9
/sys/bus/acpi/devices/PNP0C0F:07/status  9
/sys/bus/acpi/devices/device:0f/status   15
/sys/bus/acpi/devices/device:11/status   15
/sys/bus/acpi/devices/device:12/status   15
/sys/bus/acpi/devices/device:14/status   15
/sys/bus/acpi/devices/device:15/status   15
/sys/bus/acpi/devices/device:17/status   15
/sys/bus/acpi/devices/device:19/status   15
/sys/bus/acpi/devices/device:1a/status   15
/sys/bus/acpi/devices/device:1b/status   15
/sys/bus/acpi/devices/device:1d/status   15
/sys/bus/acpi/devices/device:1e/status   15
/sys/bus/acpi/devices/device:1f/status   15
/sys/bus/acpi/devices/device:20/status   15
/sys/bus/acpi/devices/device:21/status   15
/sys/bus/acpi/devices/device:22/status   15
/sys/bus/acpi/devices/device:23/status   15
/sys/bus/acpi/devices/device:24/status   15
/sys/bus/acpi/devices/device:25/status   15
/sys/bus/acpi/devices/device:27/status   15
/sys/bus/acpi/devices/device:28/status   15
/sys/bus/acpi/devices/device:29/status   15
/sys/bus/acpi/devices/device:2a/status   15
/sys/bus/acpi/devices/device:2b/status   15
/sys/bus/acpi/devices/device:2c/status   15
/sys/bus/acpi/devices/device:2d/status   15
/sys/bus/acpi/devices/device:2e/status   15
/sys/bus/acpi/devices/device:2f/status   15
/sys/bus/acpi/devices/device:30/status   15
/sys/bus/acpi/devices/device:31/status   15
/sys/bus/acpi/devices/device:33/status   15
/sys/bus/acpi/devices/device:34/status   15
/sys/bus/acpi/devices/device:35/status   15
/sys/bus/acpi/devices/device:37/status   15
/sys/bus/acpi/devices/device:38/status   15
/sys/bus/acpi/devices/device:39/status   15
/sys/bus/acpi/devices/device:3a/status   15
/sys/bus/acpi/devices/device:3b/status   15
/sys/bus/acpi/devices/device:3c/status   15
/sys/bus/acpi/devices/device:3d/status   15
/sys/bus/acpi/devices/device:3e/status   15
/sys/bus/acpi/devices/device:3f/status   15
/sys/bus/acpi/devices/device:41/status   15
/sys/bus/acpi/devices/device:42/status   15
/sys/bus/acpi/devices/device:43/status   15
/sys/bus/acpi/devices/device:44/status   15
/sys/bus/acpi/devices/device:45/status   15
/sys/bus/acpi/devices/device:46/status   15
/sys/bus/acpi/devices/device:47/status   15
/sys/bus/acpi/devices/device:48/status   15
/sys/bus/acpi/devices/device:49/status   15
/sys/bus/acpi/devices/device:4a/status   15
/sys/bus/acpi/devices/device:4b/status   15
/sys/bus/acpi/devices/device:4d/status   

Bug#806713: disk-detect/multipath: update checks for changed mpath alias names

[Cyril Brulebois]

Hi,

Hendrik Brueckner  (2015-11-30):
> Dear maintainers,
> 
> An update in the multipath-tools, [1], changed the naming scheme for
> mpath aliases created when the user friendly names option is specified.
> 
> The alias naming changed from mpath0 to mpatha replacing the numeric
> digits with alphabetic letters.  The patch below updates the
> disk-detect.sh to correctly detect multipath devices with the new
> naming scheme.

AFAICT from the current manpage, when this option is not specified, WWID
are used instead, so there's no need to keep the [0-9] part in the
check, right? This seems confirmed by my reading of #806900 so I think
I'll push the patch to master right away.

> On the people/cyphermox/mpath-detect branch in the d-i/hw-detect
> repository, there is already a patch for the same problem.  I could
> not find a bug report for it.  So that's why I am opening this one to
> keep this problem in mind.  It would be great if you could help me to
> understand the practice on how such problem fixes becomes integrated.

Unfortunately lack of manpower means patches are sometimes not reviewed
or merged for a long time. :(

> Apart from the disk-detect package, the partman-multipath package is
> also affected by mpath naming change.  I will open a separate bug report
> and attach a patch to solve the naming there.

I'll try and look at the various patches after Mathieu's reply in
#806900. I might even propose them through proposed-updates if the next
RC looks good for multipath support.


KiBi.


signature.asc
Description: Digital signature