Bug#896080: [pkg-apparmor] Improve samba/AppArmor integration

[intrigeri]

Hi,

Christian Boltz:
> I'm not sure if I like your samba/... path - it's not bad on itsself, 
> but it opens a can of worms.

… and it's actually an even deeper can of worms: arguably /etc is not
the right place to store auto-generated files that the local
administrator should not touch. They should be in /var. But from
a Debian perspective, it's way too late in the Buster dev cycle to
tackle this related problem.

> Let's assume for a moment that more 
> programs auto-generate profile sniplets. Do we really want to have one 
> directory for each of them (always holding a single file)? I'm afraid 
> that might produce an interesting forest in /etc/apparmor.d/...

On my system I currently have 43 regular files (profiles) at the top
level under /etc/apparmor.d/, 5 standard directories created by the
apparmor package, and a couple program-specific directories (libvirt,
lxc). It's not obvious to me what's the problem with creating a few
more directories in there. Can you please explain? :)

> Counter-proposal: What about  /etc/apparmor.d/autogenerated/$whatever  ? 
> That directory could be used by multiple programs.

If there's a good reason why creating per-program directories
(= namespaces) directly under /etc/apparmor.d/ and why /var is not an
option, fine. But then the proverbial $someone needs to migrate
libvirt there, otherwise we're just creating a N+1'th standard¹ and
making things more inconsistent than they already are.

Wrt. Debian and Buster: this path is mostly an internal implementation
detail and it seems easy to change it later. Since there's no clear
consensus at this point, I would not block on this conversation and
I recommend uploading src:samba using the path I've already added
support for. Then we can have this conversation in a relaxed manner
instead of under a super-tight schedule, aiming at finding a great
solution for Bullseye (Debian 11), ideally under /var.

[1] https://xkcd.com/927/

Cheers,
-- 
intrigeri

Bug#919642: emacs-common: mml-secure-check-user-id chokes on User IDs with no e-mail address (wrong-type-argument char-or-string-p nil)

[Antoine Beaupré]

[Taking the liberty of adding the last generous NMU-er of Emacs to the
CC list... apologies if not appropriate]

I can confirm the patch provided by dkg fixes this problem, which is
actually quite serious because it will break encryption to any UID that
ressembles one that is affected by this bug, even if the UID doesn't end
up being selected for other reasons.

For example, those UIDs were revoked by dkg after this experiment, yet
emacs still crashes when trying to use them.

The patch was accepted upstream, but I would suggest it might be a good
addition to buster as well...

Any takers? It's a fairly trivial patch...

a.
-- 
Software gets slower faster than hardware gets faster.
 - Wirth's law

Bug#874326: [PATCH 0/3] acquire: hint if locking fails and we're not root

[Julian Andres Klode]

On Sun, Feb 24, 2019 at 03:41:40PM +0100, Martin Ågren wrote:
> Here's my attempt at addressing this bug as a three-patch series. The
> first patch feels a bit awkward, but I've based it on the assumption
> that tests that verify an exact output do so because they want to keep
> that exact output.
> 
> The integration tests test-apt-ftparchive-cachedb-lp1274466 and
> test-apt-key always fail for me, even without these patches. I suppose
> there's a small chance these patches break those tests without me
> noticing. My apologies if so.
> 
> Any feedback welcome. I'll be happy to rework these if you think this
> bug should be approached differently.

Please submit them as a salsa merge request, so tests run and they don't
get lost in a jungle of 600 bugs. It seems likely we won't merge them,
as there are plans to become root as needed using a daemon and policykit:

  https://wiki.debian.org/Apt/Daemon

That said, it might not make it into the next release, and this might
be a useful improvement.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Daniel Kahn Gillmor]

Control: tags 920763 - moreinfo

Hi Chris--

On Tue 2019-01-29 09:29:50 +0100, Chris Lamb wrote:
> Probably a silly question for this time in the morning but what is
> stopping you extracting the associated signature and calling it
> $origname.asc?

the signature matches the git commit, but not the tarball.  If we have a
$origname.asc i think it's expected to be verifiable via:

gpgv $origname.asc $origname

but that would pretty clearly fail.

> (If this is not possible/sensible/whatever, if Lintian essentially
> grepped debian/watch, would that be good enough?)

Ideally, lintian would verify that there exists a signed tag in the git
repo found at Vcs-Git: (from d/control), which matches the name of
upstream-tag (from d/gbp.conf), and whose contents corresponds to the
expected contents of the orig.tar.gz (presumably with a standardized
prefix).  One approach would be to:

 * identify the tag by its expected name
 * cryptogrpahically verify it
 * extract the expected archive from the git repo via sth. like
   git archive --format=tar --prefix=$pkgname-$origversion/ 
   piped through the expected buildpackage.compression value (from d/gbp.conf)
 * compare it bytewise with $origname

I suspect that will work in most cases, though i don't know whether git
has explicitly committed to a stable output for git archive
--format=tar.

If going that far is too fancy for lintian for now, then a simple grep
of d/watch would do for starters, and we could just convert this bug
report to a suggestion for future lintian enhancement.

Regards,

   --dkg

Bug#923314: unbound: Regression: systemctl reload unbound broken after upgrade from 1.8.1-1 to 1.9.0-2

[Timo Sigurdsson]

Package: unbound
Version: 1.9.0-2
Severity: normal

Dear Maintainer,

after upgrading unbound from 1.8.1-1 to 1.9.0-2, I noticed that reloading 
unbound via systemctl (or unbound-control reload) does not work anymore. 
Unbound complains that remote-control is not enabled. I looked at the changes 
from the two versions and found that up until version 1.8.1-1, Debian shipped a 
patch changing the default for cfg->remote_control_enable from 0 to 1 in 
util/config_file.c, meaning the remote control interface is enabled by default. 
This patch was dropped in 1.9.0-2, but the change was not documented.

This also constitutes a regression since the systemd unit file shipped with 
unbound relies on unbound-control to reload the unbound configuration. As the 
remote control interface defaults to disabled now, reloading fails.

Please consider adding said patch again or remove the ExecReload command from 
the systemd unit file and update the changelog to indicate the change of the 
default behavior.


Note: I'm using a local backport of 1.9.0-2 on Debian Stretch, which is a mere 
backport of Testing without any additional changes. But looking a the source 
code and the observations I described above, I don't think that matters here.


Thanks!

Bug#923304: texlive-pstricks: plain tex fails with Undefined control sequence on \scantokens after input of pstricks.

[Hilmar Preuße]

Am 26.02.2019 um 06:46 teilte P V Mathew mit:

Package: texlive-pstricks
Version: 2018.20190131-2
Severity: important

Dear Maintainer,


Addendum: see #920368


After receiving other complaints from users of ancient technology on
Stack Exchange, I fixed this in upstream.  It will be part of the next
release which should be with TeX Live 2019 (or TeX Live 2019 pretest but
I don't think Debian packages pretest).

Keep in mind that everything that relies on \scantokens is bound to
fail, such as the babel and quotes libraries.


According to my knowledge we won't have that fix in buster due to soft
freeze.

H.
--
#206401 http://counter.li.org

Bug#923310: ITS: ninja-build

[Mo Zhou]

control: close -1

I agree with you, and let's close this bug..

On Tue, Feb 26, 2019 at 09:15:16AM +0100, Felix Geyer wrote:
> Hi,
> 
> On 2019-02-26 08:09, Mo Zhou wrote:
> > Source: ninja-build
> > X-Debbugs-CC: fge...@debian.org
> > 
> > Hi Felix,
> > 
> > The last upload for ninja-build dates back to more than 1 year ago.
> 
> There are some changes lined up but nothing that warranted an upload:
> https://salsa.debian.org/debian/ninja-build/commits/master
> 
> Just because a package hasn't been uploaded in a while doesn't mean it has
> been abandoned.
> It might just continue to work without problems.
> 
> > The package looks quite old since it has an ancient std-ver.
> 
> I'm sorry but that's a really bad criteria. In the end it's just a number in
> a control field.
> Is there anything in the package that you think needs improving besides
> bumping a number?
> 
> > I intend to help update the package and import the latest upstream
> > version 1.9.0 then upload it to unstable, does that sound good to you?
> > This could be either an ITS or an NMU, at your preference.
> 
> At this stage in the release I consider it a very bad idea since many
> packages use ninja to build.
> I don't want to potentially break those in the freeze by uploading a new
> major upstream release.
> 
> > I wanted to fix [1] but clearly we cannot do that at this stage.
> > 
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849513
> 
> As mentioned in the bug report I don't see a reason to "fix" this.
> I should just close that bug.
> 
> Felix

Bug#923310: ITS: ninja-build

[Felix Geyer]

Hi,

On 2019-02-26 08:09, Mo Zhou wrote:

Source: ninja-build
X-Debbugs-CC: fge...@debian.org

Hi Felix,

The last upload for ninja-build dates back to more than 1 year ago.


There are some changes lined up but nothing that warranted an upload:
https://salsa.debian.org/debian/ninja-build/commits/master

Just because a package hasn't been uploaded in a while doesn't mean it 
has been abandoned.

It might just continue to work without problems.


The package looks quite old since it has an ancient std-ver.


I'm sorry but that's a really bad criteria. In the end it's just a 
number in a control field.
Is there anything in the package that you think needs improving besides 
bumping a number?



I intend to help update the package and import the latest upstream
version 1.9.0 then upload it to unstable, does that sound good to you?
This could be either an ITS or an NMU, at your preference.


At this stage in the release I consider it a very bad idea since many 
packages use ninja to build.
I don't want to potentially break those in the freeze by uploading a new 
major upstream release.



I wanted to fix [1] but clearly we cannot do that at this stage.

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


As mentioned in the bug report I don't see a reason to "fix" this.
I should just close that bug.

Felix

Bug#919638: solr-tomcat: Permission problems after update to tomcat9

[Emmanuel Bourg]

Control: reopen -1
Control: notfixed -1 9.0.16-2

Le 17/02/2019 à 12:38, Markus Koschany a écrit :

> Thank you for the confirmation. Then I think reassigning this issue to
> src:tomcat9 and fixing it there is sensible.

Unfortunately the modification broke tomcat9 installations when solr
isn't installed (#923299) and I had to revert it in the version 9.0.16-3.

We have to figure out another solution. Either:
1. abandon the idea of restricting tomcat9 write access
2. change solr-tomcat so that it modifies the tomcat9 permissions on install
3. drop solr-tomcat, upstream recommends using Jetty after all.

Emmanuel Bourg

Bug#853035: fixed in node-liftoff 2.3.0-3

[Chris Lamb]

Xavier Guimard wrote:

>* Switch tests to pkg-js-tools and increase timeout (Closes: #853035)

Whilst I (also) commented on Salsa, I still don't understand why
this was closed given my comments on the original bug report.

In particular:

  https://bugs.debian.org/853035#42

Can you help? If this was the "only" way to fix the problem, that should
be documented in the package and in the changelog, not simply on this issue.


Regards,

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

Bug#923315: unblock: gigolo/0.4.2-3

[Yves-Alexis Perez]

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

Hi,

due to a bad timing combination, the gigolo packag is currently not in
testing and won't migrate without an unblock. I think it would be nice
for its users to let it migrate.

The package has been removed from testing a long time ago, and didn't
migrate again because of the alioth maintainer address RC bug. There's a
new development version in experimental fixing that bug, and I hoped
there would be a stable release in time for the freeze, but that didn't
happen and I uploaded just a new revision (I thought) in time for the
freeze.

Unfortunately my timing was off (I uploaded 5 days before the soft
freeze but too late). The diff between stable and unstable is attached.

Please unblock package gigolo

unblock gigolo/0.4.2-3

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gigolo-0.4.2/debian/changelog gigolo-0.4.2/debian/changelog
--- gigolo-0.4.2/debian/changelog   2014-01-09 23:00:47.0 +0100
+++ gigolo-0.4.2/debian/changelog   2019-02-07 17:29:33.0 +0100
@@ -1,3 +1,35 @@
+gigolo (0.4.2-3) unstable; urgency=medium
+
+  * Moved the package to git on salsa.debian.org
+  * Updated the maintainer address to debian-x...@lists.debian.org
+closes: #899525
+  * d/gbp.conf added, following DEP-14
+  * d/watch: use HTTPS protocol
+  * d/gbp.conf adjusted for buster branch
+  * d/control: drop Emanuele, Simon, Lionel and Stefan from uploaders
+  * d/control: update standards version to 4.2.1
+
+ -- Yves-Alexis Perez   Thu, 07 Feb 2019 17:29:33 +0100
+
+gigolo (0.4.2-2) unstable; urgency=medium
+
+  * debian/patches:
+- 01_migrate-gvfs-command added, replace gvfs-open by gio open as default
+open command.
+  * debian/control:
+- replace gvfs-bin by libglib2.0-bin in Recommends  closes: #877744
+- run wrap-and-sort
+- update standards version to 4.4.1. 
+- drop -dbg package.
+  * debian/rules:
+- migrate to dbgsym package.
+- use debian/gigolo instead of debian/tmp in file removals, since we only
+have one binary package now. 
+- drop list-missing since we install everything.
+  * debian/gigolo.install dropped since we only have one package.
+
+ -- Yves-Alexis Perez   Sun, 15 Oct 2017 16:08:34 +0200
+
 gigolo (0.4.2-1) unstable; urgency=low
 
   [ Evgeni Golov ]
diff -Nru gigolo-0.4.2/debian/control gigolo-0.4.2/debian/control
--- gigolo-0.4.2/debian/control 2014-01-09 23:00:41.0 +0100
+++ gigolo-0.4.2/debian/control 2019-02-07 17:29:33.0 +0100
@@ -1,34 +1,23 @@
 Source: gigolo
 Section: xfce
 Priority: optional
-Maintainer: Debian Xfce Maintainers 
-Uploaders: Yves-Alexis Perez , Emanuele Rocca 
, Simon Huggins , Stefan Ott 
, Lionel Le Folgoc 
-Build-Depends: debhelper (>= 9), intltool, pkg-config,
-  libgtk2.0-dev (>= 2.12.0)
-Standards-Version: 3.9.5
+Maintainer: Debian Xfce Maintainers 
+Uploaders: Yves-Alexis Perez 
+Build-Depends: debhelper (>= 9),
+   intltool,
+   libgtk2.0-dev (>= 2.12.0),
+   pkg-config
+Standards-Version: 4.2.1
 Homepage: http://www.uvena.de/gigolo/
-Vcs-Svn: svn://anonscm.debian.org/pkg-xfce/goodies/trunk/gigolo/
-Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-xfce/goodies/trunk/gigolo/
+Vcs-Git: https://salsa.debian.org/xfce-team/apps/gigolo.git
+Vcs-Browser: https://salsa.debian.org/xfce-team/apps/gigolo
 
 Package: gigolo
 Section: xfce
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: gvfs-bin
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Recommends: libglib2.0-bin
 Description: frontend to manage connections to remote filesystems using 
GIO/GVfs
  Gigolo is a frontend to easily manage connections to remote filesystems
  using GIO/GVfs. It allows you to quickly connect/mount a remote filesystem
  and manage bookmarks of such.
-
-Package: gigolo-dbg
-Section: debug
-Architecture: any
-Priority: extra
-Depends: gigolo (= ${binary:Version}), ${misc:Depends}
-Description: frontend to manage connections to remote filesystems using 
GIO/GVfs (debug)
- Gigolo is a frontend to easily manage connections to remote filesystems
- using GIO/GVfs. It allows you to quickly connect/mount a remote filesystem
- and manage bookmarks of such.
- .
- This package contains the debugging symbols.
-
diff -Nru gigolo-0.4.2/debian/gbp.conf gigolo-0.4.2/debian/gbp.conf
--- gigolo-0.4.2/debian/gbp.conf1970-01-01 01:00:00.0 +0100
+++ gigolo-0.4.2/debian/gbp.conf2019-02-07 17:29:33.0 +0100
@@ -0,0 +1,

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Steve Langasek]

On Mon, Feb 25, 2019 at 01:43:03PM -0300, Herbert Fortes wrote:
> On Wed, 20 Feb 2019 17:37:35 -0300 Herbert Fortes  wrote:

> > On 2/20/19 1:55 PM, Steve Langasek wrote:
> > > Package: pyparted
> > > Version: 3.11.2-6
> > > Followup-For: Bug #922081
> > > User: ubuntu-de...@lists.ubuntu.com
> > > Usertags: origin-ubuntu disco ubuntu-patch

> > > I think the remaining issue is entirely a bug in the debian/rules

> When I try to build the package in a VM, I have no problems.

> When I try  to build the package in a 'chroot' it is not possible to build
> the package.  No matter what.

> Debian CI have no problem, I will not touch it.

> I will upload a revision without the override:

>  - If reproducible-build does not complain.  Everybody is happy.

>  - If one test fails in reproducible-builds like here.
>    It is only one more test to skip. Everybody is happy.

It looks like this build has passed now:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pyparted.html

Are you happy to close this bug?

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


signature.asc
Description: PGP signature

Bug#923316: apt leaks SRV requests for _socks._tcp.localhost for tor proxy

[Julian Andres Klode]

Package: apt
Version: 1.3~rc1
Severity: important
Tags: security
Control: fixed -1 1.7.0~alpha1

apt, starting with 1.3~rc1, and prior to 1.7.0~alpha1, generates a
SRV request when trying to use the Tor proxy, asking the DNS server
SRV _socks._tcp.localhost.

This might cause information to be leaked that the user is about to
use tor for Debian package installation, as no other tool is likely to perform
such queries.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#918276: (no subject)

[Сергей Фёдоров]

Installed Debian 9.8 amd64 from scratch. In it in "stable" vlc 3.0.6-0+deb9u1
works fine, but if you install vlc 3.0.6-1 from sid, when you open
any video file Debian freezes and only the mouse cursor moves across the screen.
I.e. everything in Debian to 9.6. In Debian 9.6, amd64 worked fine in
"stable" vlc 3.0.3-1-0+deb9u1, and if you install vlc 3.0.5-1 from "sid", then 
when
open any *.mp4 file Debian hangs on the screen and moves the cursor
mice.

If it does not open the video file, vlc --version, then it will report:
VLC media player 3.0.6 Vetinari (revision 3.0.6-0-g5803e85f73)
VLC version 3.0.6 Vetinari (3.0.6-0-g5803e85f73)
Compiled by buildd on x86-ubc-01.debian.org (Jan 10 2019 19:03:32)
Compiler: gcc version 8.2.0 (Debian 8.2.0-14)
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public License;
see the file named COPYING for details.
Written by the VideoLAN team; see the AUTHORS file.

I. e. not 3.0.6-1, but 3.0.6-0, which looks suspicious.

Bug#921762: need help

[Yanhao Mo]

Control: tags -1 + pending

Andrey Rahmatullin  writes:

> Control: tags -1 + upstream fixed-upstream
>
> On Wed, Feb 13, 2019 at 09:21:17PM +0800, Yanhao Mo wrote:
>> Control: tags -1 + confirmed help
> This seems to be fixed upstream:
> https://github.com/teejee2008/timeshift/issues/375

I see, thanks for reminding, new version will soon be uploaded.

Bug#853035: fixed in node-liftoff 2.3.0-3

[Xavier]

Le 26/02/2019 à 09:54, Chris Lamb a écrit :
> Xavier Guimard wrote:
> 
>>* Switch tests to pkg-js-tools and increase timeout (Closes: #853035)
> 
> Whilst I (also) commented on Salsa, I still don't understand why
> this was closed given my comments on the original bug report.
> 
> In particular:
> 
>   https://bugs.debian.org/853035#42
> 
> Can you help? If this was the "only" way to fix the problem, that should
> be documented in the package and in the changelog, not simply on this issue.
> 
> 
> Regards,

Hello,

upstream uses "mocha" to launch its test. mocha always uses a timeout,
default to 2s, which is a little short. mocha is widely used in node
modules and we often have to increase timeout.

I didn't find other ways to fix these FTBFS than:
 - increasing timeout in each package (this is what we did in many
   packages)
 - rewriting the whole tests with another framework (bad idea I think)
 - increasing timeout in mocha sources (only when used in Debian build
   to not pollute normal use of mocha, using for example an environment
   variable?)

I think we don't have this kind of generic problems with other test
framework (tap,...)

but maybe other JS-Team members have another idea?

Bug#921762: need help

[Andrey Rahmatullin]

On Tue, Feb 26, 2019 at 05:23:13PM +0800, Yanhao Mo wrote:
> Control: tags -1 + pending
> 
> Andrey Rahmatullin  writes:
> 
> > Control: tags -1 + upstream fixed-upstream
> >
> > On Wed, Feb 13, 2019 at 09:21:17PM +0800, Yanhao Mo wrote:
> >> Control: tags -1 + confirmed help
> > This seems to be fixed upstream:
> > https://github.com/teejee2008/timeshift/issues/375
> 
> I see, thanks for reminding, new version will soon be uploaded.
Please mind the freeze policy.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#923298: chromium: file overlap with chromium-sandbox without Conficts and/or Replaces

[Lee Garrett]

Hi,

your issue is related to mixing stable and testing, which is not supported and
causing your issue here. More below:

On Tue, 26 Feb 2019 10:54:15 +1100 "G. Branden Robinson"
 wrote:
> Package: chromium
> Version: 72.0.3626.96-1~deb9u1
> Severity: grave
> Justification: renders package unusable
> 
> I have been tracking testing for several months.
> 
> This looks to me like a missing or insufficiently versioned Replaces
> declaration, but I did not dig deeply into this except to check the BTS
> to see if it had bitten anyone else.  To my surprise, it looks like it
> has not.
> 
[...]

> Get:1 http://ftp.au.debian.org/debian buster/main amd64 chromium-sandbox 
> amd64 72.0.3626.53-1 [137 kB]
> Fetched 137 kB in 1s (179 kB/s)  
> Selecting previously unselected package chromium-sandbox.
> (Reading database ... 351969 files and directories currently installed.)
> Preparing to unpack .../chromium-sandbox_72.0.3626.53-1_amd64.deb ...
> Unpacking chromium-sandbox (72.0.3626.53-1) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/chromium-sandbox_72.0.3626.53-1_amd64.deb (--unpack):
This ^^^ here is not the current version in testing anymore. Current version
is 72.0.3626.109-1.

>  trying to overwrite '/usr/lib/chromium/chrome-sandbox', which is also in 
> package chromium 72.0.3626.96-1~deb9u1
This ^^^ version here is the current package in stretch.

You can easily solve your issue by cleanly upgrading to testing. You can also
seek help in #debian on irc.oftc.net. I'm leaving this bug open however, as
this issue could also happen during upgrade from stretch to buster. It's
missing versioned dependencies.

Regards,
Lee

Bug#922279: debconf: Can't select long choices in dialog (whiptail) multiselect

[Colin Watson]

On Thu, Feb 14, 2019 at 09:44:46AM -0700, Kevin Locke wrote:
> On Thu, 2019-02-14 at 13:52 +, Colin Watson wrote:
> > On Wed, Feb 13, 2019 at 10:51:17PM -0700, Kevin Locke wrote:
> >> The problem is that the ellipsized choice text can't be mapped back
> >> to the choice value.  I have attached a patch which adds this
> >> mapping.
> > 
> > Oh dear.  Thanks - but doesn't Debconf::Element::Dialog::Select have
> > an analogous problem?
> 
> Yes indeed.  Good catch.  Here's an updated patch which fixes both.

Thanks.  At some point it would be nice to find a way to force the
choice texts to be unambiguous without overflow, e.g. by prepending or
appending a number.  But this works as far as it goes and fixes an IMO
serious bug, so I've just tidied up the indentation in your patch and
added a changelog entry, and will otherwise push it as is.

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

Bug#883619: Any reason not to simply upload ceres-solver with adjusted version of libeigen3-dev

[Philipp Huebner]

Hi,

Am 26.02.19 um 08:54 schrieb Andreas Tille:
>>> to Git.  Is there any reason not to upload this and simply fix #883619.
>>> Looks like a pretty low hanging fruit to fix an RC bug and save the
>>> package for Buster that I can not imagine nobody else would have
>>> harvested it.
>>
>> It's only downstream dependency is colmap. If colmap is happy with the new
>> version then it sounds like a good idea to upload it, especially if it fixes
>> an RC bug.
> 
> I mean: There is no *effective* change since the Build-Depends we set is
> fullfilled anyway by the existing packages.  Its just that it is
> explicitly declared in the package metadata.

IMO that's a valid fix for buster, but does not fix the underlying issue
for sid / buster+1.

The next time a newer version of eigen3 is uploaded, you'll have the
same "problem" all over again: adjust the build dep and upload to get a
corresponding rebuild.
Updating eigen3 renders ceres and similar packages unusable until
rebuilt, please read through the discussion in #868355 to understand
what I mean.

The eigen3 maintainer and I are happy to simply rebuild affected
packages after every eigen3 update, but Emilio considers it an upstream bug.
Unfortunately I could not find anybody able to shed more light on the
eigen3 topic.


Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#897340: libcidr-dev claims to be Multi-Arch: same but is not

[Santiago Ruano Rincón]

Control: merge -1 897353
Control: tags -1 + pending

On Tue, 01 May 2018 09:48:24 -0400 Francois Gouget  wrote:
> Package: libcidr-dev
> Version: 1.2.3-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Trying to install the amd64 and i386 versions of this
> package results in the following error:
> 
> # apt-get install libcidr-dev:amd64 libcidr-dev:i386
> [...]
> Unpacking libcidr-dev:i386 (1.2.3-2) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libcidr-dev_1.2.3-2_i386.deb (--unpack):
>  trying to overwrite shared 
> '/usr/share/doc/libcidr-dev/examples/acl/GNUmakefile', which is different 
> from other instances of package libcidr-dev:i386
> Errors were encountered while processing:
>  /var/cache/apt/archives/libcidr-dev_1.2.3-2_i386.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Thanks for reporting this, and sorry for the delay to respond!

The last commits in the git repo fixes this.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#920467: Ping bug to reset automatic testing removal counter - no idea why closing the bug did not help

[Andreas Tille]

Ping #920467


-- 
http://fam-tille.de

Bug#923284: Seemingly miscompiles with jdk-11

[Sjoerd Simons]

On Mon, 2019-02-25 at 23:59 +0100, Emmanuel Bourg wrote:
> Thank you for the report Sjoerd. What error did you get when
> compiling
> gradle with the rebuilt bsh?
> 
> Emmanuel Bourg

Btw; I tested with forcing bsh to build with openjdk-8 instead and then
the issue doesn't occur while building gradle; Hence assuming it's a
bsh issue not a gradle one.

Bug#868355: Any reason not to simply upload ceres-solver with adjusted version of libeigen3-dev

[Andreas Tille]

Hi Philipp,

On Tue, Feb 26, 2019 at 10:45:52AM +0100, Philipp Huebner wrote:
> 
> > I mean: There is no *effective* change since the Build-Depends we set is
> > fullfilled anyway by the existing packages.  Its just that it is
> > explicitly declared in the package metadata.
> 
> IMO that's a valid fix for buster, but does not fix the underlying issue
> for sid / buster+1.

Sure, but we want to release Buster and if this bug is not fixed
ceres-solver (and its dependencies are removed in now 4.3 days.  Thus
I'm just building the current HEAD and will upload if nobody will stop
me.
 
> The next time a newer version of eigen3 is uploaded, you'll have the
> same "problem" all over again: adjust the build dep and upload to get a
> corresponding rebuild.
> Updating eigen3 renders ceres and similar packages unusable until
> rebuilt, please read through the discussion in #868355 to understand
> what I mean.
> 
> The eigen3 maintainer and I are happy to simply rebuild affected
> packages after every eigen3 update, but Emilio considers it an upstream bug.
> Unfortunately I could not find anybody able to shed more light on the
> eigen3 topic.

I agree that the topic seems to be more complex in general but for the
moment we need a fix for Buster and that fix is very simple - so I do
not see any reason to not fix it.  You might like to reopen the relevant
bugs (I mean #868355 - I just asked for closing which was done and
#883619) with lower severity to keep on discussing for Buster+1.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2

[Jonas Meurer]

Hi all,

Georg Faerber:
> On 19-02-22 23:26:45, Jonas Meurer wrote:
>> I skimmed through the patch and it looks good to me. I also did some
>> rough testing and at least with my test files it worked as expected.
>>
>> I merged jvoisin's changes into the d/0.7.0-2 branch.
> 
> Thanks a lot for your inputs, reviews and changes -- highly appreciated.
> 
> I've got some serious issues currently with my keyboard, which makes
> working at my PC quite a pain, but I'll take care of the upload in time
> to ensure -2 will migrate before the full freeze on March 12th.
> 
> My current plan looks like the following:
> 
> - Let -1 migrate to testing, which should happen on Thursday, February
>   28th.
> 
>   This is to ensure a minimal diff between testing and unstable, in case
>   the migration of -2 gets delayed for whatever reason, -2 won't
>   therefore migrate before the full freeze, and we need to ask for an
>   freeze exception. AFAIK, minimal diffs have a higher chance to be
>   accepted than bigger ones.
> 
> - I'll upload -2 either tomorrow or the day after via the delayed queue,
>   or on Thursday. In any case, -2 should migrate on March 10th, if all
>   goes well. I'm on travel, so can't pinpoint a specific time now, but
>   be assured that the upload is upcoming.
> 
> - I plan to pull in three upstream bug fixes as well, see [1], [2] and [3].

After I slept a night over it, I realized that this plan doesn't take
into account our options to still handle the mat1 -> mat2 transition in
time for buster. After all we agreed on that mat(1) should better not be
shipped with buster. Now that we have at least a Nautilus extension for
mat2, there's no blocker for the mat -> mat2 transitoon anymore, no?

If we ask ftpmasters and the Release Team for help, there might still be
a chance to get a mat2 with a new transitional 'mat' binary package into
buster, don't you think so?

What do you think about the following:

1. Ask ftpmaster and Release Team for their opinions on this matter
2. Upload mat2 0.7.0-2 with new transitional binary package 'mat'
3. Since it will sit in NEW for a few days anyway, maybe 0.7.0-1 will
   transition to buster in the meantime. If not, no worries - we want to
   get 0.7.0-2 into buster anyway.

Maybe you could give short replies on whether you're in favour of this
plan. I would contact ftpmasters and Release Team as soon as I get some
positive feedback.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#853035: fixed in node-liftoff 2.3.0-3

[Chris Lamb]

Xavier,

> I didn't find other ways to fix these FTBFS than:



Thank you. However, can I just underline:

> > If this was the "only" way to fix the problem, that should be
> > documented in the package and in the changelog, not simply on
> > this issue.


Regards,

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

Bug#898122: cups-daemon: Harden systemd service by default

[Paul Menzel]

Control: forwarded -1 https://github.com/apple/cups/pull/5528


Dear Chiraag,


On 05/07/18 16:47, Chiraag Nataraj wrote:

> Given that cupsd must run as root, we should restrict its
> capabilities as much as possible. Given that the cups-daemon package
> provides the systemd service, would it be possible to harden it by
> default? The following options worked for me in the [Service] section
> (but we may need more extensive testing):
Thank you very much for your report, and the suggestions below.

> CapabilityBoundingSet=CAP_AUDIT_WRITE CAP_CHOWN CAP_DAC_OVERRIDE 
> CAP_DAC_READ_SEARCH CAP_FOWNER CAP_FSETID CAP_NET_BIND_SERVICE CAP_NET_RAW 
> CAP_SETGID CAP_SETUID
> ProtectSystem=strict
> ProtectHome=true
> ProtectKernelTunables=true
> ProtectKernelModules=true
> ProtectControlGroups=true
> PrivateTmp=true
> PrivateDevices=true
> MemoryDenyWriteExecute=true
> LockPersonality=true
> ReadWritePaths=/etc/cups /var/log/cups /var/run/cups /var/cache/cups 
> /var/spool/cups

I created a merge/pull request [1], and set this as the upstream report
as discussion is happening there. Could you please join the discussion?

Upstream is reluctant to apply these changes, and wants distributions
to carry them first. Do you know, what other distributions like Red Hat,
Fedora, Arch or Ubuntu do?

Additionally, I talked to the systemd developers, and they responded,
that `CAP_DAC_OVERRIDE` renders quite a lot of restrictions mood [1].

> Bypass file read, write, and execute permission checks. (DAC is an
> abbreviation of "discretionary access control".)

Additionally, they said, that 

`ProtectSystem`, `ReadWritePaths` and `ProtectHome` are redundant.
Could you please look more into it, and maybe post an updated list?


Kind regards,

Paul


[1]: https://manpages.debian.org/stretch/manpages-de/capabilities.7.html



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#923284: Seemingly miscompiles with jdk-11

[Emmanuel Bourg]

Le 26/02/2019 à 10:20, Sjoerd Simons a écrit :

> I've atteched the output of running docker build on the DockerFile i
> attached to reproduce the issue; The relevant part in the gradle build
> seems to be:

Thank you! The "Malformed jar" message is just a warning. The actual
issue is:

> Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
>   at org.objectweb.asm.ClassVisitor.visitNestHost(ClassVisitor.java:150)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:541)
>   at org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
>   at 
> org.gradle.api.internal.tasks.compile.incremental.asm.ClassDependenciesVisitor.analyze(ClassDependenciesVisitor.java:75)

Most likely triggered because the recompiled bsh uses Java 11 bytecode.
This can be fixed either by targeting a pre Java 11 release in the bsh
build, or by patching Gradle to use Opcodes.ASM7.

Emmanuel Bourg

Bug#923153: openssh-server: OpenSSH is not "OpenBSD Secure Shell" /etc/init.d/ssh

[IKEDA Shigeru]

OpenSSH is not short hand or something for "OpenBSD secure shell", and
that sentence in README file doesn't say that too.
OpenSSH is just OpenSSH.  Why can't we call it just OpenSSH?

On Mon, Feb 25, 2019 at 7:36 PM Colin Watson  wrote:
>
> On Sun, Feb 24, 2019 at 11:48:55PM +0900, Hocus Pocus wrote:
> > OpenSSH is not "OpenBSD Secure Shell". That's it.
>
> In what sense is it not?  I mean, OpenSSH's README file says:
>
>   This is the port of OpenBSD's excellent OpenSSH[0] to Linux and other
>   Unices.
>
> --
> Colin Watson   [cjwat...@debian.org]

Bug#923317: FTBS: fails to build after libjaxp1.3-java is rebuild on buster

[Emmanuel Bourg]

Le 26/02/2019 à 11:23, Sjoerd Simons a écrit :

> This may or may not be related to 923284

This is the same issue. Gradle breaks when its dependencies use Java 11
bytecode.

Emmanuel Bourg

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 25 février 2019, 14.58:09 h CET Didier 'OdyX' Raboud a écrit :
> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye`
> is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either
>classical or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

I vote:

H > M > W > FD

OdyX

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

Bug#923318: long-running ping pegs cpu at 100%

[Toni]

Package: iputils-ping
Version: 3:20180629-2
Severity: normal
Tags: upstream



Hi,

on my laptop, I usually run ping against a target to see how the
connecction quality is, but after a suspend/resume cycle, if the network
does not come up (frequently), ping consumes 100% of one core, making
the nachine quite hot.

This may be related to

https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1697646


It would be nice if ping would detect the absence of the network and
then wait for a while until the network comes up again.


Cheers,
Toni


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_SOFTLOCKUP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iputils-ping depends on:
ii  libc6   2.28-7
ii  libcap2 1:2.25-2
ii  libidn2-0   2.0.5-1
ii  libnettle6  3.4.1-1

Versions of packages iputils-ping recommends:
ii  libcap2-bin  1:2.25-2

iputils-ping suggests no packages.

-- no debconf information

Bug#910804: JVM fails to start when JFR is enabled

[Matthias Klose]

Version: 11.0.2+9-3

fixed at least in 11.0.2+9-3, maybe earlier.

Bug#922699: caja: Caja crash when copying paste

[Vlad Orlov]

Hi,

Ok, seems like the bug is in Caja, not in libgio. It's not clear yet what 
causes the crash...

Does it crash on every copy/paste of any folder? Is there something common 
between all
the folders? For example, a lot of large files, a lot of small files, some 
specific characters
in filenames...

Bug#923153: openssh-server: OpenSSH is not "OpenBSD Secure Shell" /etc/init.d/ssh

[Dun Kerque]

If you guys really want to include the word 'OpenBSD', here is alternate patch.

--- openssh-server.ssh.init 2019-02-09 01:26:35.0 +0900
+++ openssh-server.ssh.init.corrected   2019-02-26 19:40:38.742657219 +0900
@@ -6,12 +6,12 @@
# Required-Stop:   $remote_fs $syslog
# Default-Start:   2 3 4 5
# Default-Stop:
-# Short-Description:   OpenBSD Secure Shell server
+# Short-Description:   OpenBSD's Secure Shell server
### END INIT INFO
set -e
-# /etc/init.d/ssh: start and stop the OpenBSD "secure shell(tm)" daemon
+# /etc/init.d/ssh: start and stop the OpenBSD's "secure shell(tm)" daemon
test -x /usr/sbin/sshd || exit 0
( /usr/sbin/sshd -\? 2>&1 | grep -q OpenSSH ) 2>/dev/null || exit 0
@@ -40,7 +40,7 @@
log_end_msg 0 || true
   fi
   if ! run_by_init; then
-log_action_msg "OpenBSD Secure Shell server not in use
(/etc/ssh/sshd_not_to_be_run)" || true
+log_action_msg "OpenBSD's Secure Shell server not in use
(/etc/ssh/sshd_not_to_be_run)" || true
   fi
   exit 0
fi
@@ -79,7 +79,7 @@
   check_privsep_dir
   check_for_no_start
   check_dev_null
-   log_daemon_msg "Starting OpenBSD Secure Shell server" "sshd" || true
+   log_daemon_msg "Starting OpenBSD's Secure Shell server" "sshd" || true
   if start-stop-daemon --start --quiet --oknodo --pidfile
/run/sshd.pid --exec /usr/sbin/sshd -- $SSHD_OPTS; then
log_end_msg 0 || true
   else
@@ -87,7 +87,7 @@
   fi
   ;;
stop)
-   log_daemon_msg "Stopping OpenBSD Secure Shell server" "sshd" || true
+   log_daemon_msg "Stopping OpenBSD's Secure Shell server" "sshd" || true
   if start-stop-daemon --stop --quiet --oknodo --pidfile /run/sshd.pid; then
log_end_msg 0 || true
   else
@@ -98,7 +98,7 @@
reload|force-reload)
   check_for_no_start
   check_config
-   log_daemon_msg "Reloading OpenBSD Secure Shell server's
configuration" "sshd" || true
+   log_daemon_msg "Reloading OpenBSD's Secure Shell server's
configuration" "sshd" || true
   if start-stop-daemon --stop --signal 1 --quiet --oknodo --pidfile
/run/sshd.pid --exec /usr/sbin/sshd; then
log_end_msg 0 || true
   else
@@ -109,7 +109,7 @@
restart)
   check_privsep_dir
   check_config
-   log_daemon_msg "Restarting OpenBSD Secure Shell server" "sshd" || true
+   log_daemon_msg "Restarting OpenBSD's Secure Shell server" "sshd" || true
   start-stop-daemon --stop --quiet --oknodo --retry 30 --pidfile /run/sshd.pid
   check_for_no_start log_end_msg
   check_dev_null log_end_msg
@@ -123,7 +123,7 @@
try-restart)
   check_privsep_dir
   check_config
-   log_daemon_msg "Restarting OpenBSD Secure Shell server" "sshd" || true
+   log_daemon_msg "Restarting OpenBSD's Secure Shell server" "sshd" || true
   RET=0
   start-stop-daemon --stop --quiet --retry 30 --pidfile /run/sshd.pid
|| RET="$?"
   case $RET in

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Herbert Fortes]

On 2/26/19 6:07 AM, Steve Langasek wrote:
> On Mon, Feb 25, 2019 at 01:43:03PM -0300, Herbert Fortes wrote:
>> On Wed, 20 Feb 2019 17:37:35 -0300 Herbert Fortes  wrote:
> 
>>> On 2/20/19 1:55 PM, Steve Langasek wrote:
 Package: pyparted
 Version: 3.11.2-6
 Followup-For: Bug #922081
 User: ubuntu-de...@lists.ubuntu.com
 Usertags: origin-ubuntu disco ubuntu-patch
> 
 I think the remaining issue is entirely a bug in the debian/rules
> 
>> When I try to build the package in a VM, I have no problems.
> 
>> When I try  to build the package in a 'chroot' it is not possible to build
>> the package.  No matter what.
> 
>> Debian CI have no problem, I will not touch it.
> 
>> I will upload a revision without the override:
> 
>>  - If reproducible-build does not complain.  Everybody is happy.
> 
>>  - If one test fails in reproducible-builds like here.
>>    It is only one more test to skip. Everybody is happy.
> 
> It looks like this build has passed now:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pyparted.html
> 
> Are you happy to close this bug?
> 

Honestly not yet.

There are two patches that I have to remove. One I am
confidence to do so.


armhf failed, but I think it is not the problem we treat
here.

arm64 and i386 still missing.

kFreebsd and Hurd have problems. But it is ok.

I will upload a revision without one patch and Debian CI
like debhelper does.

Don't worry. At the end everything will be fine.

Bug#922699: caja: Caja crash when copying paste

[Vlad Orlov]

Hi,

Ok, seems like the bug is in Caja, not in libgio. It's not clear yet what 
causes the crash...

Does it crash on every copy/paste of any folder? Is there something common 
between all
the folders? For example, a lot of large files, a lot of small files, some 
specific characters
in filenames...

Bug#923221: ITP: libpam-fingerprint -- Pluggable Authentication Module for fingerprint authentication

[Philipp Meisberger]

This won't be an easy task (rather impossible) since libfprint is
written in C and libpam-fingerprint is written in Python.

Regards,
Philipp

Am 26.02.19 um 02:35 schrieb Paul Wise:
> On Mon, Feb 25, 2019 at 7:14 PM Philipp Meisberger wrote:
> 
>> Poorly libpam-fprintd is not suitable as libfprint0 seems to support
>> ZhianTec fingerprint sensors. libpam-fingerprint is especially for those
>> sensors. I see it would be more precise to use "Pluggable Authentication
>> Module for ZhianTec fingerprint sensors" as description and name the
>> package "libpam-fingerprint-zfm".
> 
> Is it feasible to merge the two projects upstream? It seems like
> having two different fingerprint sensor stacks and have the user
> manually decide which one they want and then install it is a bit of a
> suboptimal experience. It would be nicer if there were one stack that
> supported all the fingerprint sensors available on the market.
> 



signature.asc
Description: OpenPGP digital signature

Bug#922699: caja: Caja crash when copying paste

[Frédéric MASSOT]

Le 26/02/2019 à 11:54, Vlad Orlov a écrit :
> Hi,
> 
> Ok, seems like the bug is in Caja, not in libgio. It's not clear yet what 
> causes the crash...
> 
> Does it crash on every copy/paste of any folder? Is there something common 
> between all
> the folders? For example, a lot of large files, a lot of small files, some 
> specific characters
> in filenames...


Hi,

I have not found a particular type of folder, it crashes on all folders
as soon as they contain a file. It crashes on our workstations, as on
NFS access to the server, on small folders as on big.

For example in my personal folder, I created a folder "test", in this
folder I created a text file, I copy paste the folder and caja crash.

Our workstations have amd64 and i386 systems, but the i386s use an amd64
kernel. But caja crash on both types of systems.

I regularly update the workstations with testing, the crash of caja
appeared with the latest updates.


Regards.
-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Bug#923319: dynalogin: FTBFS (Makefile:366: pam_dynalogin_la-pam_dynalogin.lo)

[Santiago Vila]

Package: src:dynalogin
Version: 1.0.0-3
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
test -x debian/rules
mkdir -p "."
set -e;   mv ./build-aux/config.guess ./build-aux/config.guess.cdbs-orig; cp 
--remove-destination /usr/share/misc/config.guess ./build-aux/config.guess;
set -e;   mv ./build-aux/config.sub ./build-aux/config.sub.cdbs-orig; cp 
--remove-destination /usr/share/misc/config.sub ./build-aux/config.sub;
touch debian/stamp-autotools-files
chmod a+x /<>/./configure
mkdir -p .
cd . && CFLAGS="`apr-1-config --cflags --cppflags --includes` 
-I/usr/include/liboath" CXXFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security" 
CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" 
/<>/./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir="\${prefix}/include" --mandir="\${prefix}/share/man" 
--infodir="\${prefix}/share/info" --sysconfdir=/etc --localstatedir=/var 
--libexecdir="\${prefix}/lib/dynalogin" --srcdir=. --disable-maintainer-mode 
--disable-dependency-tracking --disable-silent-rules
configure: WARNING: unrecognized options: --disable-maintainer-mode, 
--disable-silent-rules
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for DEPS_LIBDYNALOGIN... yes
checking for DEPS_DYNALOGIND... ye

Bug#923284: Seemingly miscompiles with jdk-11

[Sjoerd Simons]

On Tue, 2019-02-26 at 11:35 +0100, Emmanuel Bourg wrote:
> Le 26/02/2019 à 10:20, Sjoerd Simons a écrit :
> 
> > I've atteched the output of running docker build on the DockerFile
> > i
> > attached to reproduce the issue; The relevant part in the gradle
> > build
> > seems to be:
> 
> Thank you! The "Malformed jar" message is just a warning. The actual
> issue is:
> 
> > Caused by: java.lang.UnsupportedOperationException: This feature
> > requires ASM7
> > at
> > org.objectweb.asm.ClassVisitor.visitNestHost(ClassVisitor.java:150)
> > at org.objectweb.asm.ClassReader.accept(ClassReader.java:541)
> > at org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
> > at
> > org.gradle.api.internal.tasks.compile.incremental.asm.ClassDependen
> > ciesVisitor.analyze(ClassDependenciesVisitor.java:75)
> 
> Most likely triggered because the recompiled bsh uses Java 11
> bytecode.
> This can be fixed either by targeting a pre Java 11 release in the
> bsh
> build, or by patching Gradle to use Opcodes.ASM7.

ASM7 mode seems to have been introduced in the gradle v5.x series. Not
sure if it makes sense for buster to upgrade to that (I really don't
know much about java, so no idea about the impact)? 

That said making all gradle dependencies target pre-Java 11  probably
doens't scale either?

-- 
Sjoerd Simons 

Bug#919587: bringing back Imapsync

[Markus Raps]

Thank you for the reply

i will start building the package.

Bug#923284: Seemingly miscompiles with jdk-11

[Emmanuel Bourg]

Le 26/02/2019 à 12:22, Sjoerd Simons a écrit :

> ASM7 mode seems to have been introduced in the gradle v5.x series. Not
> sure if it makes sense for buster to upgrade to that (I really don't
> know much about java, so no idea about the impact)?

We can't upgrade to Gradle 5 unfortunately, not until Kotlin is packaged
(#892842). This will be a key issue in the next development cycle.


> That said making all gradle dependencies target pre-Java 11  probably
> doens't scale either?

If it's just the Gradle dependencies it's doable, and the severity of
the bug can be downgraded because the issue only appears if the
dependencies are rebuilt. If the issue also appears when project
dependencies use Java 11 this is a more important issue.

Emmanuel Bourg

Bug#914632: RFC: proposed fix for CVE-2018-19518 in uw-imap

[Salvatore Bonaccorso]

Hi Magnus,

On Sun, Feb 24, 2019 at 08:28:00PM +0100, Magnus Holmgren wrote:
> söndag 30 december 2018 kl. 09:38:57 CET skrev  Salvatore Bonaccorso:
> > There is an alternative approach wich was raised by Magnus in the
> > respective bug: https://bugs.debian.org/914632#12 (and see followup
> > from Moritz).
> 
> So, is it OK to upload this (assuming there's no code out there that actually 
> uses SET_RSHPATH or SET_SSHPATH)?
> 
> (By no longer defining RSHPATH, rshpath doesn't get set by the following code 
> and tcp_aopen() will return NIL without doing anything.
> 
> #ifdef RSHPATH/* rsh path defined yet? */
>   if (!rshpath) rshpath = cpystr (RSHPATH);
> #endif

Can you adress the issue first in unstable and make sure it can reach
buster? After that a stretch update can be targeted, should go
actually via an upcoming stretch point release (we marked the issue
no-dsa earlier).

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

Thanks for your work on the issue!

Regards,
Salvatore

Bug#919138: wpasupplicant 2.7 fails to connect to some Wifi networks

[Andrej Shadura]

Hi Different55,

I have uploaded 2:2.7+git20190128+0c1e29f-2 last week [1], could you
please give it a try?

[1]: https://packages.qa.debian.org/w/wpa/news/20190219T183431Z.html

-- 
Cheers,
  Andrej

Bug#923320: ITP: pynpoint -- Pipeline for processing and analysis of high-contrast imaging data

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: pynpoint
  Version : 0.6
  Upstream Authors: Thomas Stolker
* URL : https://github.com/PynPoint/PynPoint
* License : GPL-3
  Description : Pipeline for processing and analysis of 
high-contrast imaging data
 This is a generic, end-to-end pipeline for the data reduction and 
analysis of
 high-contrast imaging data of planetary and substellar companions, as 
well as

 circumstellar disks in scattered light.
 .
 The pipeline has a modular architecture with a central data storage in 
which
 all results are stored by the processing modules. These modules have 
specific

 tasks such as the subtraction of the thermal background emission, frame
 selection, centering, PSF subtraction, and photometric and astrometric
 measurements. The tags from the central data storage can be written to 
FITS,

 HDF5, and text files with the available I/O modules.

Package will be availabe at http://phd-sid.ethz.ch/debian/pynpoint/

Bug#918105: munin-plugins-core: postgres_connections_ return zeros after 2.0.44-1~bpo9+1 upgrade

[Vincas Dargis]

>> "Waiting for lock" is strange naming though, I would expect it more like
>> "Idle" or "Idle in transaction", as I would imagine waiting for lock a
>> contention event, and I doubt it's the case, but I am not PostgreSQL expert
>> here.
>
>Same for me (being a non-expert).
>f you have a specific proposal: please share it!

Yep there's a bug with latest PG versions, my colleague (our DBA) have a fix:
https://github.com/munin-monitoring/munin/pull/1161

Bug#923153: openssh-server: OpenSSH is not "OpenBSD Secure Shell" /etc/init.d/ssh

[Colin Watson]

On Tue, Feb 26, 2019 at 07:37:10PM +0900, IKEDA Shigeru wrote:
> OpenSSH is not short hand or something for "OpenBSD secure shell", and
> that sentence in README file doesn't say that too.

I didn't claim that OpenSSH was a shorthand for it, merely that it was a
reasonably accurate description.

> OpenSSH is just OpenSSH.  Why can't we call it just OpenSSH?

The *name* of the project is certainly OpenSSH.

However, the text in question is a *description*.  The point of a
description is to *describe*.  Simply restating the name does nothing to
help people who don't already know what it is (I mean, sure, they could
search the web, but we often describe things locally despite that
possibility).  "Secure shell server" would be insufficient because there
are other secure shell servers in Debian.  "OpenSSH secure shell server"
would be possible, but feels ugly and redundant because the "SSH" part
of the name really does stand for "secure shell".

The current text of "OpenBSD Secure Shell server" seems like a
reasonable compromise between explanatory power and brevity to me.  It
attributes the primary developers of the code in question, avoiding
ambiguity with other implementations in the process; it briefly explains
what the service does; and it isn't repetitive.  (I don't see the point
of changing it to "OpenBSD's Secure Shell server", as suggested in your
later patch.)

I don't see the problem here at all.  What problem are you actually
trying to solve with this?  Are you an upstream developer protesting a
misnaming (in which case please identify yourself as such, since I don't
recognise you)?  Otherwise, while this isn't the most important issue in
the world to me, I don't want to make a change without understanding
what the problem is, since otherwise I don't have a good response when
somebody files a bug about whatever the text might change to.

Also, for the purposes of interacting with the Debian bug tracking
system, please pick a name to use in your From: header and stick to it.
I don't care whether it's your real name or a pseudonym, but when you
send three emails to the same bug thread using a different name for all
three, it looks as though you're intentionally trying to suggest support
from multiple people.

Thanks,

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

Bug#923321: radare2-cutter: FTBFS (dh_auto_configure fails)

[Santiago Vila]

Package: src:radare2-cutter
Version: 1.7.4-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
dh build-arch --buildsystem=cmake --sourcedirectory=src
   dh_update_autotools_config -a -O--buildsystem=cmake -O--sourcedirectory=src
   dh_autoreconf -a -O--buildsystem=cmake -O--sourcedirectory=src
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DCUTTER_ENABLE_QTWEBENGINE=1
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCUTTER_ENABLE_QTWEBENGINE=1 ../src
-- version from Cutter.pro: 1.7.4
-- sources from Cutter.pro: 
Main.cpp;Cutter.cpp;widgets/DisassemblerGraphView.cpp;common/RichTextPainter.cpp;dialogs/InitialOptionsDialog.cpp;dialogs/AboutDialog.cpp;dialogs/CommentsDialog.cpp;dialogs/EditInstructionDialog.cpp;dialogs/FlagDialog.cpp;dialogs/RenameDialog.cpp;dialogs/XrefsDialog.cpp;MainWindow.cpp;common/Helpers.cpp;common/HexAsciiHighlighter.cpp;common/HexHighlighter.cpp;common/Highlighter.cpp;common/MdHighlighter.cpp;dialogs/preferences/AsmOptionsWidget.cpp;dialogs/NewFileDialog.cpp;AnalTask.cpp;widgets/CommentsWidget.cpp;widgets/ConsoleWidget.cpp;widgets/Dashboard.cpp;widgets/EntrypointWidget.cpp;widgets/ExportsWidget.cpp;widgets/FlagsWidget.cpp;widgets/FunctionsWidget.cpp;widgets/ImportsWidget.cpp;widgets/Omnibar.cpp;widgets/RelocsWidget.cpp;widgets/SdbDock.cpp;widgets/SectionsWidget.cpp;widgets/SegmentsWidget.cpp;widgets/StringsWidget.cpp;widgets/SymbolsWidget.cpp;menus/DisassemblyContextMenu.cpp;widgets/DisassemblyWidget.cpp;widgets/HexdumpWidget.cpp;common/Confi
 
guration.cpp;common/Colors.cpp;dialogs/SaveProjectDialog.cpp;common/TempConfig.cpp;common/SvgIconEngine.cpp;common/SyntaxHighlighter.cpp;widgets/PseudocodeWidget.cpp;widgets/VisualNavbar.cpp;widgets/GraphView.cpp;dialogs/preferences/PreferencesDialog.cpp;dialogs/preferences/AppearanceOptionsWidget.cpp;dialogs/preferences/GraphOptionsWidget.cpp;dialogs/preferences/PreferenceCategory.cpp;widgets/QuickFilterView.cpp;widgets/ClassesWidget.cpp;widgets/ResourcesWidget.cpp;widgets/VTablesWidget.cpp;widgets/TypesWidget.cpp;widgets/HeadersWidget.cpp;widgets/SearchWidget.cpp;CutterApplication.cpp;common/JupyterConnection.cpp;widgets/JupyterWidget.cpp;common/PythonAPI.cpp;common/NestedIPyKernel.cpp;dialogs/R2PluginsDialog.cpp;widgets/CutterDockWidget.cpp;widgets/CutterTreeWidget.cpp;widgets/GraphWidget.cpp;common/JsonTreeItem.cpp;common/JsonModel.cpp;dialogs/VersionInfoDialog.cpp;widgets/ZignaturesWidget.cpp;common/AsyncTask.cpp;dialogs/AsyncTaskDialog.cpp;widgets/StackWidget.cpp;widgets/Regis
 
tersWidget.cpp;widgets/BacktraceWidget.cpp;dialogs/OpenFileDialog.cpp;common/CommandTask.cpp;common/ProgressIndicator.cpp;common/R2Task.cpp;widgets/DebugActions.cpp;widgets/MemoryMapWidget.cpp;dialogs/preferences/DebugOptionsWidget.cpp;widgets/BreakpointWidget.cpp;dialogs/BreakpointsDialog.cpp;dialogs/AttachProcDialog.cpp;widgets/RegisterRefsWidget.cpp;dialogs/SetToDataDialog.cpp;dialogs/EditVariablesDialog.cpp;widgets/ColorSchemePrefWidget.cpp;common/ColorSchemeFileSaver.cpp;dialogs/EditFunctionDialog.cpp;widgets/CutterTreeView.cpp;widgets/ComboQuickFilterView.cpp;dialogs/HexdumpRangeDialog.cpp;common/QtResImporter.cpp;common/CutterSeekable.cpp;common/RefreshDeferrer.cpp;dialogs/WelcomeDialog.cpp
-- headers from Cutter.pro: 
Cutter.h;widgets/DisassemblerGraphView.h;common/RichTextPainter.h;common/CachedFontMetrics.h;dialogs/AboutDialog.h;dialogs/preferences/AsmOptionsWidget.h;dialogs/CommentsDialog.h;dialogs/EditInstructionDialog.h;dialogs/FlagDialog.h;dialogs/RenameDialog.h;dialogs/XrefsDialog.h;common/Helpers.h;common/HexAsciiHighlighter.h;common/HexHighlighter.h;MainWindow.h;common/Highlighter.h;common/MdHighlighter.h;dialogs/InitialOptionsDialog.h;dialogs/NewFileDialog.h;AnalTask.h;widgets/CommentsWidget.h;widgets/ConsoleWidget.h;widgets/Dashboard.h;widgets/EntrypointWidget.h;widgets/ExportsWidget.h;widgets/FlagsWidget.h;widgets/FunctionsWidget.h;widgets/ImportsWidget.h;widgets/Omnibar.h;widgets/RelocsWidget.h;widgets/SdbDock.h;widgets/SectionsWidget.h;widgets/SegmentsWidget.h;widgets/StringsWidget.h;widgets/SymbolsWidget.h;menus/DisassemblyContextMenu.h;widgets/DisassemblyWidget.h;widgets/HexdumpWidget.h;common/Configuration.h;common/Colors.h;dialogs/SaveProjectDialog.h;c
 
ommon/TempConfig.h;common/SvgIconEngine.h;common/SyntaxHighlighter.h;widgets/PseudocodeWidget.h;widgets/VisualNavbar.h;widgets/GraphView.h;dialogs/preferences/PreferencesDialog.h;dialogs/preferences/AppearanceOptionsWidget.h;dialogs/preferences/Preference

Bug#870428: libverto1: Upstream has moved

[Sam Hartman]

I apologize for dropping the ball on this so long.
It looks like there is a 0.3.0 release of verto, which was folded into
krb5.
However, It looks like there's not an upstream tarball on github for
anything past 0.2.6.

Because I dropped the ball so much I'm under tight time pressure to get
an update into Debian buster.  I'm going to package 0.2.6, but if you
either get me an official 0.3.0 tarball by Thursday or alternatively let
me know that the changes between 0.2.6 and 0.3.0 are so critical I
should go generate my own make dist even though I'm not upstream, I'll
try to get 0.3.0 in.

--Sam

Bug#919638: solr-tomcat: Permission problems after update to tomcat9

[Markus Koschany]

Am 26.02.19 um 09:46 schrieb Emmanuel Bourg:
> Control: reopen -1
> Control: notfixed -1 9.0.16-2
> 
> Le 17/02/2019 à 12:38, Markus Koschany a écrit :
> 
>> Thank you for the confirmation. Then I think reassigning this issue to
>> src:tomcat9 and fixing it there is sensible.
> 
> Unfortunately the modification broke tomcat9 installations when solr
> isn't installed (#923299) and I had to revert it in the version 9.0.16-3.

Sorry, I didn't expected that behavior from systemd.

> We have to figure out another solution. Either:
> 1. abandon the idea of restricting tomcat9 write access
> 2. change solr-tomcat so that it modifies the tomcat9 permissions on install
> 3. drop solr-tomcat, upstream recommends using Jetty after all.

I personally like the sandboxing idea of tomcat9 which improves the
overall security of the server. We should keep the current settings.

Making one package modify the files of another package is tricky and I
bet there are thousand Debian Policy rules to follow. We don't need to
drop solr-tomcat either for this release cycle because apart from this
permission problem everything else seems to work. This will be the last
time solr-tomcat is part of a stable distribution though. The latest
solr versions embed Jetty and solr is no longer a web application but a
standalone server.

Still the best way to fix this bug is to add /var/lib/solr to the
sandbox if the directory exists. There must be some kind of conditional
solution for systemd service files so that the option is only processed
if another condition is true. Tomcat 9 could also simply create
/var/lib/solr which would also address this problem.




signature.asc
Description: OpenPGP digital signature

Bug#870428: Info received (Bug#870428: libverto1: Upstream has moved)

[Sam Hartman]

Sigh.
I'm just confused.
Got the 0.3.0 tar ball fine.

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

[Colin Watson]

FWIW, the debconf bug that cut off the message has been fixed (in
1.5.70, although it required a follow-up fix in 1.5.71).

On Sat, Jan 19, 2019 at 11:49:54AM +0100, Vincent Lefevre wrote:
> On 2019-01-12 13:33:35 +, Colin Watson wrote:
> > I can see the argument that it might be convenient to have configuration
> > that effectively says "install to this device if it exists, otherwise
> > continue anyway"; but such a configuration may mean that the GRUB image
> > on disk that you might in fact attempt to boot from will end up being
> > incompatible with the rest of /boot/grub/ and thus cause a failure to
> > boot even though the postinst pretended everything is fine!
> > Disregarding this kind of configuration error can have grave
> > consequences of its own.  In any case, even if it might be convenient to
> > have such a configuration, I won't accept that part of the issue as a
> > grave bug.
> 
> I meant that the issue was that the user may not have remember
> or even known where GRUB was installed (this was my case, and
> I could find the information just because I keep track of the
> changes of config.dat). This makes the problem unfixable without
> risking to erase some data.

Of course, the grub-pc maintainer script doesn't know either.  All it
has available to it is a /dev/disk/by-id/ path that no longer points to
a disk.  The case I had in mind when writing that code, and I think
almost certainly the overwhelmingly common case, is where the disk in
question has been removed; the edge case that we have here is where the
disk in question is still installed but its supposedly fixed ID has
changed.

I think what I'm going to do here is as follows: if the answer to
grub-pc/install_devices_disks_changed is empty, then don't copy it to
grub-pc/install_devices (and still do the usual thing of asking if
you're really sure that you don't want to install GRUB to any devices).
This will have the effect that if you don't positively select a new disk
to install to, as in your case, then the old configuration information
will remain untouched and the same question will be asked again the next
time grub-pc is configured.

This isn't completely ideal: it's a little bit hacky, and it would be
nice if the description of grub-pc/install_devices_disks_changed
explained this workflow (but it's really too late to be introducing new
translatable text for buster at this point).  However, it's the best
realistic solution I can think of, it's a pretty small change, and I
expect this edge case to continue to be rare in any event.

Thanks,

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

Bug#923322: plasma-browser-integration: Incorrect installation directory for chrome config file

[David Edmundson]

Package: plasma-browser-integration
Version: 5.14.5+p18.04+git20190129.0259-0
Severity: important

Dear Maintainer,

Plasma browser integration needs to install a file to /etc/opt

Upstream does this.

There was a concious decision in debian packaging to do something else, but the 
move to 
break it cites a rule about installing into /opt This does not apply as it 
refers to 
a completely different directory. Note the /etc prefix.

A solution has been found for chrome-gnome-shell using postinst/postrm 
to copy the file into the correct location.

Can we have the same system used here please.

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-45-generic (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-browser-integration depends on:
ii  libc6 2.27-3ubuntu1
ii  libkf5activities5 5.54.0+p18.04+git20190203.0346-0
ii  libkf5configcore5 5.54.0+p18.04+git20190205.0126-0
ii  libkf5coreaddons5 5.54.0+p18.04+git20190203.0215-0
ii  libkf5dbusaddons5 5.54.0+p18.04+git20190203.0212-0
ii  libkf5i18n5   5.54.0+p18.04+git20190203.0213-0
ii  libkf5kiocore55.54.1+p18.04+git20190204.1405-0
ii  libkf5kiowidgets5 5.54.1+p18.04+git20190204.1405-0
ii  libkf5notifications5  5.54.0+p18.04+git20190203.0231-0
ii  libkf5runner5 5.54.0+p18.04+git20190203.0407-0
ii  libkf5service55.54.0+p18.04+git20190203.0237-0
ii  libqt5core5a  5.12.0+dfsg-0+xneon+18.04+bionic+build53
ii  libqt5dbus5   5.12.0+dfsg-0+xneon+18.04+bionic+build53
ii  libqt5gui55.12.0+dfsg-0+xneon+18.04+bionic+build53
ii  libqt5widgets55.12.0+dfsg-0+xneon+18.04+bionic+build53
ii  libstdc++68.2.0-1ubuntu2~18.04

plasma-browser-integration recommends no packages.

plasma-browser-integration suggests no packages.

-- no debconf information

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[David Bremner]

Didier 'OdyX' Raboud  writes:

> === Resolution ===
>
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
>
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye` is:
>
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
>
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either classical
>or "merged `/usr`" directory schemes
>
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
>
> * FD: Further Discussion
>
> === End Resolution ===

I vote M > W > H > FD



signature.asc
Description: PGP signature

Bug#923153: openssh-server: OpenSSH is not "OpenBSD Secure Shell" /etc/init.d/ssh

[Hocus Pocus]

Ok.  I give up.  Do what you like.  It's not important.

https://en.wikipedia.org/wiki/OpenSSH
"OpenSSH (also known as OpenBSD Secure Shell) ..."

Bug#923323: stretch-pu: CVE-2018-1000872: package python-pykmip/0.5.0-4

[Thomas Goirand]

Package: release.debian.org
Severity: important
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

Here's the changelog entry:

+  * CVE-2018-1000872: Resource Management Errors (similar issue to
+CVE-2015-5262) vulnerability in PyKMIP server that can result in DOS: the
+server can be made unavailable by one or more clients opening all of the
+available sockets. Applied upstream patch: Fix a denial-of-service bug by
+setting the server socket timeout (Closes: #917030).

The security team doesn't think a DSA is needed. Debdiff is attached. The
resulting package is here:

http://sid.gplhost.com/stretch-proposed-updates/python-pykmip/

Please allow me to upload python-pykmip/0.5.0-4+deb9u1 to Stretch-proposed.

Cheers,

Thomas Goirand (zigo)
diff -Nru python-pykmip-0.5.0/debian/changelog 
python-pykmip-0.5.0/debian/changelog
--- python-pykmip-0.5.0/debian/changelog2016-12-02 21:49:06.0 
+
+++ python-pykmip-0.5.0/debian/changelog2019-02-24 16:43:42.0 
+
@@ -1,3 +1,13 @@
+python-pykmip (0.5.0-4+deb9u1) stretch; urgency=medium
+
+  * CVE-2018-1000872: Resource Management Errors (similar issue to
+CVE-2015-5262) vulnerability in PyKMIP server that can result in DOS: the
+server can be made unavailable by one or more clients opening all of the
+available sockets. Applied upstream patch: Fix a denial-of-service bug by
+setting the server socket timeout (Closes: #917030).
+
+ -- Thomas Goirand   Sun, 24 Feb 2019 17:43:42 +0100
+
 python-pykmip (0.5.0-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
python-pykmip-0.5.0/debian/patches/CVE-2018-1000872_Fix_a_denial-of-service_bug_by_setting_the_server_socket_timeout.patch
 
python-pykmip-0.5.0/debian/patches/CVE-2018-1000872_Fix_a_denial-of-service_bug_by_setting_the_server_socket_timeout.patch
--- 
python-pykmip-0.5.0/debian/patches/CVE-2018-1000872_Fix_a_denial-of-service_bug_by_setting_the_server_socket_timeout.patch
  1970-01-01 00:00:00.0 +
+++ 
python-pykmip-0.5.0/debian/patches/CVE-2018-1000872_Fix_a_denial-of-service_bug_by_setting_the_server_socket_timeout.patch
  2019-02-24 16:43:42.0 +
@@ -0,0 +1,54 @@
+Description: CVE-2018-1000872: Fix a denial-of-service bug by setting the 
server socket timeout
+ This change fixes a potential denial-of-service bug with the
+ server, setting a default timeout for all server sockets. This
+ allows the server to drop hung connections without blocking
+ forever. The interrupt triggered during accept calls is expected
+ and is now handled appropriately. Server unit tests have been
+ updated to reflect this change.
+Author: Peter Hamilton 
+Date: Tue, 24 Apr 2018 21:57:20 -0400
+Origin: upstream, 
https://github.com/OpenKMIP/PyKMIP/commit/3a7b880bdf70d295ed8af3a5880bab65fa6b3932
+Bug-Debian: https://bugs.debian.org/917030
+Last-Update: 2019-02-24
+
+Index: python-pykmip/kmip/services/server/server.py
+===
+--- python-pykmip.orig/kmip/services/server/server.py
 python-pykmip/kmip/services/server/server.py
+@@ -176,6 +176,7 @@ class KmipServer(object):
+ self._logger.info("Starting server socket handler.")
+ 
+ # Create a TCP stream socket and configure it for immediate reuse.
++socket.setdefaulttimeout(10)
+ self._socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+ self._socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
+ 
+@@ -283,6 +284,11 @@ class KmipServer(object):
+ while self._is_serving:
+ try:
+ connection, address = self._socket.accept()
++except socket.timeout:
++# Setting the default socket timeout to break hung connections
++# will cause accept to periodically raise socket.timeout. This
++# is expected behavior, so ignore it and retry accept.
++pass
+ except socket.error as e:
+ if e.errno == errno.EINTR:
+ self._logger.warning("Interrupting connection service.")
+Index: python-pykmip/kmip/tests/unit/services/server/test_server.py
+===
+--- python-pykmip.orig/kmip/tests/unit/services/server/test_server.py
 python-pykmip/kmip/tests/unit/services/server/test_server.py
+@@ -342,7 +342,11 @@ class TestKmipServer(testtools.TestCase)
+ 
+ # Test the expected behavior for a normal server/interrupt sequence
+ s._socket.accept = mock.MagicMock(
+-side_effect=[('connection', 'address'), expected_error]
++side_effect=[
++('connection', 'address'),
++socket.timeout,
++expected_error
++]
+ )
+ 
+ s.serve()
diff -Nru python-pykmip-0.5.0/debian/patches/series 
python-pykmip-0.5.0/debian/patches/series
--- python-pykmip-0.

Bug#923284: Seemingly miscompiles with jdk-11

[Sjoerd Simons]

On Tue, 2019-02-26 at 12:40 +0100, Emmanuel Bourg wrote:
> Le 26/02/2019 à 12:22, Sjoerd Simons a écrit :
> 
> > ASM7 mode seems to have been introduced in the gradle v5.x series.
> > Not
> > sure if it makes sense for buster to upgrade to that (I really
> > don't
> > know much about java, so no idea about the impact)?
> 
> We can't upgrade to Gradle 5 unfortunately, not until Kotlin is
> packaged
> (#892842). This will be a key issue in the next development cycle.
> 
> 
> > That said making all gradle dependencies target pre-Java
> > 11  probably
> > doens't scale either?
> 
> If it's just the Gradle dependencies it's doable, and the severity of
> the bug can be downgraded because the issue only appears if the
> dependencies are rebuilt. If the issue also appears when project
> dependencies use Java 11 this is a more important issue.

Right it seems to be the following list:
bsh
libjaxp1.3-java
xml-commons-external

So not as bad as i worried; But i'm not sure more stuff may come out of
the woodwork when building things that uses gradle.

-- 
Sjoerd Simons 

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Herbert Fortes]

On 2/26/19 7:55 AM, Herbert Fortes wrote:
> On 2/26/19 6:07 AM, Steve Langasek wrote:
>> On Mon, Feb 25, 2019 at 01:43:03PM -0300, Herbert Fortes wrote:
>>> On Wed, 20 Feb 2019 17:37:35 -0300 Herbert Fortes  wrote:
>>

>> It looks like this build has passed now:
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pyparted.html
>>
>> Are you happy to close this bug?
>>
> 
> Honestly not yet.
> 
> There are two patches that I have to remove. One I am
> confidence to do so.
> 
> 
> armhf failed, but I think it is not the problem we treat
> here.
> 
> arm64 and i386 still missing.
> 
> kFreebsd and Hurd have problems. But it is ok.
> 
> I will upload a revision without one patch and Debian CI
> like debhelper does.
> 
> Don't worry. At the end everything will be fine.
> 

The last try is here:

mips,  mips64el and  mipsel are important
for release and they fail.

https://buildd.debian.org/status/package.php?p=pyparted&suite=sid

E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython2_2.7_parted/build; python2.7 -m unittest 
discover -v 

exit code=1

They are similar error message that happens to amrhf in
reproducible-builds:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pyparted.html

E: pybuild pybuild:338: test: plugin distutils failed with: exit code=134: cd 
/build/pyparted-3.11.2/2nd/.pybuild/cpython2_2.7_parted/build; python2.7 -m 
unittest discover -v 

exit code=134

For release, 4 architectures still in 'needs-build'.

I was honestly confidence for  this one, but I will put back 
the patch I removed ( skip_0gt0.patch file). Let's not make 
this a big thing.

My wild-guess is that the env is not appropriated to parted.

I will talk to upstream about the 'find' anyway.

Bug#923298: chromium: file overlap with chromium-sandbox without Conficts and/or Replaces

[Michael Gilbert]

control: tag -1 pending

On Tue, Feb 26, 2019 at 4:39 AM Lee Garrett wrote:
> your issue is related to mixing stable and testing, which is not supported and
> causing your issue here.

This may not be common knowledge, but mixed suites have always been a
supported configuration.  This is a legitimate bug.  I have a fix
queued for the next -security upload.

Best wishes,
Mike

Bug#922728: arch-test: reports armel invalid on arm64 system

[Edmund Grimley Evans]

I have observed a similar situation: my armel chroot seems to work all
right, but arch-test does not list "armel" as working. In my case,
SWPB is causing a SIGILL. It seems that a lot of armel binaries don't
use SWPB, but perhaps SWPB (and SWP) are still "officially" required
for armel? Who knows?

Bug#923324: nmu: libssh_0.8.6-3

[Laurent Bigonville]

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

Hi,

libssh is statically linking against nacl.

Before 20110221-6.1 (uploaded today), nacl was not built with -fPIC
(#92), I suspect that this might be the root cause of #919956.

Could you please rebuild libssh against the last upload of nacl?

Thanks,

Laurent Bigonville

nmu libssh_0.8.6-3 . ANY -ia64 -kfreebsd-amd64 -kfreebsd-i386 . unstable . -m 
"Rebuild against nacl built with -fPIC"
dw libssh_0.8.6-3 . ANY . -m "libnacl-dev (>= 20110221-6.1)"

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#921498: matrix-synapse: Login fails in version 0.34.1

[Joseph Nuthalapati]

I cannot reproduce this error on Synapse 0.99

-- 
Regards,
Joseph Nuthalapati




signature.asc
Description: OpenPGP digital signature

Bug#906231: systemd: restarting systemd-logind causes power-button event to immediately shutdown cinnamon without asking

[Vladimir K]

I couldn't find relevant upstream bug, so I've reported one: 
https://github.com/systemd/systemd/issues/11825

Bug#900895: kmail: KMail malfunctioning: Red email folders, no emails can be viewed; "Unable to fetch item from backend (collection-1): Unable to contact resource"

[Jens Radloff]

Since the last 48 hours the behavior described in this bug issue occurred 14 
times, and it strongly seems that it will continue to occur.

I searched the Internet for the error message "Unable to fetch item from 
backend (collection-1): Unable to contact resource", and found this bug report:

https://forums.opensuse.org/showthread.php/533024-KMail-Not-Syncing-Gmail-Accounts-After-Recent-Updates

But this external bug report did not help me to resolve the issue. I installed 
the packages libgsasl7 and libgsasl7-dev, but without access, the behavior 
still occurs.

Note that I am using the PIM and within the PIM kmail to access among other 
things my Yahoo mail account, but no Gmail account. I am retrieving my mails 
from my mail accounts using POP3, but not IMAP. Currently the behavior occurs 
if I click the "Check for new mails" button in kmail and then wait until the 
status bar tells me that this check has been completed by "100%", but the 
behaviour does not occur every time I check my mails using this button. It 
occurs once in a while.

The behavior just occurred again, and here is the output of the debugger in the 
Akonadi Console (last lines):

--- Quote Beginning ---

akonadi_pop3_resource_2 (0x55975d44f2c0) 24 { Command: "FetchCollections" 
Collections: "UID " Depth: "2" Resource: "akonadi_pop3_resource_2" Mimetypes: 
"()" Ancestors Depth: "2" Ancestors Attributes: "QSet()" Enabled: "false" Sync: 
"false" Display: "false" Index: "false" Status: "false" }
akonadi_pop3_resource_2 (0x55975d44f2c0) 24 { Response: "FetchCollections" 
Error Code: "0" Error Msg: "" ID: "-1" Name: "" Parent ID: "-1" Remote ID: "" 
Remote Revision: "" Resource: "" Mimetypes: "()" Statistics: { Count: "-1" 
Unseen: "-1" Size: "-1" } Search Query: "" Search Collections: "QVector()" 
Cache Policy: { Inherit: "true" Interval: "-1" Cache Timeout: "-1" Sync on 
Demand: "false" Local Parts: "()" } Ancestors: { } Attributes: "QMap()" 
Display: "Undefined" Sync: "Undefined" Index: "Undefined" Enabled: "true" 
Virtual: "false" Referenced: "false" }
akonadi_pop3_resource_2 (0x55975d44f2c0) 25 { Command: "FetchCollections" 
Collections: "UID " Depth: "2" Resource: "akonadi_pop3_resource_2" Mimetypes: 
"()" Ancestors Depth: "0" Ancestors Attributes: "QSet()" Enabled: "false" Sync: 
"true" Display: "false" Index: "false" Status: "false" }
akonadi_pop3_resource_2 (0x55975d44f2c0) 25 { Response: "FetchCollections" 
Error Code: "0" Error Msg: "" ID: "-1" Name: "" Parent ID: "-1" Remote ID: "" 
Remote Revision: "" Resource: "" Mimetypes: "()" Statistics: { Count: "-1" 
Unseen: "-1" Size: "-1" } Search Query: "" Search Collections: "QVector()" 
Cache Policy: { Inherit: "true" Interval: "-1" Cache Timeout: "-1" Sync on 
Demand: "false" Local Parts: "()" } Ancestors: { } Attributes: "QMap()" 
Display: "Undefined" Sync: "Undefined" Index: "Undefined" Enabled: "true" 
Virtual: "false" Referenced: "false" }
akonadi_pop3_resource_1 (0x55975d403ee0) 24 { Command: "FetchCollections" 
Collections: "UID " Depth: "2" Resource: "akonadi_pop3_resource_1" Mimetypes: 
"()" Ancestors Depth: "2" Ancestors Attributes: "QSet()" Enabled: "false" Sync: 
"false" Display: "false" Index: "false" Status: "false" }
akonadi_pop3_resource_1 (0x55975d403ee0) 24 { Response: "FetchCollections" 
Error Code: "0" Error Msg: "" ID: "-1" Name: "" Parent ID: "-1" Remote ID: "" 
Remote Revision: "" Resource: "" Mimetypes: "()" Statistics: { Count: "-1" 
Unseen: "-1" Size: "-1" } Search Query: "" Search Collections: "QVector()" 
Cache Policy: { Inherit: "true" Interval: "-1" Cache Timeout: "-1" Sync on 
Demand: "false" Local Parts: "()" } Ancestors: { } Attributes: "QMap()" 
Display: "Undefined" Sync: "Undefined" Index: "Undefined" Enabled: "true" 
Virtual: "false" Referenced: "false" }
akonadi_pop3_resource_1 (0x55975d403ee0) 25 { Command: "FetchCollections" 
Collections: "UID " Depth: "2" Resource: "akonadi_pop3_resource_1" Mimetypes: 
"()" Ancestors Depth: "0" Ancestors Attributes: "QSet()" Enabled: "false" Sync: 
"true" Display: "false" Index: "false" Status: "false" }
akonadi_pop3_resource_1 (0x55975d403ee0) 25 { Response: "FetchCollections" 
Error Code: "0" Error Msg: "" ID: "-1" Name: "" Parent ID: "-1" Remote ID: "" 
Remote Revision: "" Resource: "" Mimetypes: "()" Statistics: { Count: "-1" 
Unseen: "-1" Size: "-1" } Search Query: "" Search Collections: "QVector()" 
Cache Policy: { Inherit: "true" Interval: "-1" Cache Timeout: "-1" Sync on 
Demand: "false" Local Parts: "()" } Ancestors: { } Attributes: "QMap()" 
Display: "Undefined" Sync: "Undefined" Index: "Undefined" Enabled: "true" 
Virtual: "false" Referenced: "false" }
akonadi_pop3_resource_0 (0x55975d4559d0) 24 { Command: "FetchCollections" 
Collections: "UID " Depth: "2" Resource: "akonadi_pop3_resource_0" Mimetypes: 
"()" Ancestors Depth: "2" Ancestors Attributes: "QSet()" Enabled: "false" Sync: 
"false" Display: "false" Index: "false" Status: "false" }
akonadi_pop3_resource_0 (0x55975d4559d0) 24 { Response: "Fet

Bug#917872: Automatically uninstall/reinstall Mroonga plugin on upgrade

[Otto Kekäläinen]

Hello Kentaro!

Do you have a chance to help out here?

Thanks! All help is appreciated.

pe 11. tammik. 2019 klo 22.02 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> Hello!
>
> > > The postinst of Mroong install is, and the postrm uninstalls it
> > > correctly. There is however no code that would on a
> > > postinst/preinst/upgrade scenario reinstall the plugin if the path has
> > > changed (eg. as it does on in MariaDB 10.3 when the soname path
> > > updates from libmariadb18 to libmaridb19).
> >
> > Just out of curiosity, what is the best way to detect
> > soname path updates in maintainer script?
> > If there is a similar package which treats this kind of issue, I want to 
> > know.
>
> I don't know, unfortunately.
>
> You can try if you find any examples via
> https://codesearch.debian.net/ or discuss it on debian-devel@ mailing
> list or on IRC. If your questions are MariaDB-specific you can ask
> help on the MariaDB developers mailing list or Zulip chat.



-- 
Otto Kekäläinen
https://keybase.io/ottok

Bug#923260: xserver-xorg: another upstream bug report

[Dejan Muhamedagic]

Package: xserver-xorg
Version: 1:7.7+19
Followup-For: Bug #923260

A bug report in upstream (for Fedora 29) with the very same
description:

https://bugs.freedesktop.org/show_bug.cgi?id=109174

Bug#893244: jruby FTBFS with openjdk-9

[Markus Koschany]

Hi,

Am 25.02.19 um 19:40 schrieb Miguel Landaeta:
> Hi Markus,
> 
> On Sun, Feb 24, 2019 at 08:39:48PM +0100, Markus Koschany wrote:
>> JRuby is a mess. I guess we "just" need to package the latest upstream
>> release to fix the FTBFS bugs. Nobody felt like doing that in the past
>> twelve months, so I think it is unrealistic to believe we can make it
>> happen within one week. Of course if the release team can be convinced
>> to accept a new upstream release there might be additional time left.
> 
> I agree, jruby is a mess, mostly because of me since I didn't have
> almost any time during this release cycle to work on it.
> 
> I think jruby should be dropped from buster and a new libspring-java
> upload should be prepared shortly, to disable jruby support in it.
> 
> It's not realistic to think that a new upstream release for jruby can
> be prepared in a week and that will work to be well supported during
> the next stable release life cycle.
> 
> Cheers,
> Miguel.

The FTBFS bug got fixed yesterday. I should complain more often. Andrej
uploaded version 9.1.17 to unstable. This is not the latest one but I
guess better than nothing? The original bug has not been closed yet.
Andrej, can we close it now and Debian bug #917702 too?

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#893244: jruby FTBFS with openjdk-9

[Emmanuel Bourg]

Le 26/02/2019 à 15:05, Markus Koschany a écrit :

> The FTBFS bug got fixed yesterday. I should complain more often. Andrej
> uploaded version 9.1.17 to unstable. This is not the latest one but I
> guess better than nothing? The original bug has not been closed yet.
> Andrej, can we close it now and Debian bug #917702 too?

Any hope to package JRuby 9.2.x? AFAIK it supports Java 11 better.

Emmanuel Bourg

Bug#922404: Just touching bug to reset autoremoval from testing counter for rdepends of the package

[Andreas Tille]

Touch bug #922404

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Chris Lamb]

Hi dkg,
 
> Ideally, lintian would verify that there exists a signed tag in the git
> repo found at Vcs-Git: (from d/control) […]

Lintian "cannot" talk to external sources, so this is out alas…

> If going that far is too fancy for lintian for now, then a simple grep
> of d/watch would do for starters

… indeed.


Regards,

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

Bug#923312: Acknowledgement (gnome-terminal ignores system ulimits)

[Harald Dunkel]

Apparently this comes up only, if dbus-user-session (1.10.26-0+deb9u1)
is involved. I did not ask for this package. After deleting it
the problem was gone.

Regards
Harri

Bug#922104: grub-install: check for arm-efi as a default target

[Colin Watson]

On Tue, Feb 12, 2019 at 02:49:34AM +, Steve McIntyre wrote:
> I've already submitted the core of this upstream - see
> 
>   http://lists.gnu.org/archive/html/grub-devel/2019-02/msg00018.html
> 
> Much like on x86, we can work out if the system is running on top of
> EFI firmware. If so, return "arm-efi". If not, fall back to
> "arm-uboot" as previously.
> 
> Heavily inspired by the existing code for x86.
> 
> I'd push this as an MR, but my head is just not in the right place for
> handling git-dpm right now :-(
> 
> Here's a patch instead, ready to drop into debian/patches. I've
> extended the code here in similar fashion to what's already been added
> in our version of grub_install_get_default_x86_platform() to check in
> the pkglibdir. Otherwise this new code is just the same as I've sent
> upstream yesterday.

Thanks.  I'd prefer to have the upstream and pkglibdir parts as separate
patches, though, since that'll make rebasing onto new upstream releases
easier in future.

I cherry-picked the upstream patch (though noting that the version of
that isn't actually the same as the final version you posted to
grub-devel, so you might want to chase that up with Daniel), and applied
a separate patch on top of it to add the pkglibdir bits.

Cheers,

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

Bug#920053: grub-pc: Got a sudden prompt about needing to reinstall, but that fails

[Colin Watson]

Control: forcemerge 919029 -1

On Mon, Jan 21, 2019 at 11:18:17PM +0100, Manuel Bilderbeek wrote:
> This upgrade:
> [UPGRADE] grub-pc:amd64 2.02+dfsg1-9 -> 2.02+dfsg1-10
> [UPGRADE] grub-pc-bin:amd64 2.02+dfsg1-9 -> 2.02+dfsg1-10
> 
> during the upgrade I got a prompt that grub was not installed on my devices.
> It showed me my 2 disks and asked me to select on which to install. I didn't
> remember, so I selected all. But the installation failed:

This looks essentially the same as https://bugs.debian.org/919029, so
merging with that.  I believe the incorrect IDs were fixed in udev
240-3, and see the other GRUB bug report for the rest of it.

Thanks,

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

Bug#893244: jruby FTBFS with openjdk-9

[Andrej Shadura]

Hi,

On Tue, 26 Feb 2019 at 15:20, Emmanuel Bourg  wrote:
> Le 26/02/2019 à 15:05, Markus Koschany a écrit :
> > The FTBFS bug got fixed yesterday. I should complain more often. Andrej
> > uploaded version 9.1.17 to unstable. This is not the latest one but I
> > guess better than nothing? The original bug has not been closed yet.
> > Andrej, can we close it now and Debian bug #917702 too?
>
> Any hope to package JRuby 9.2.x? AFAIK it supports Java 11 better.

I may look into it when I have time, but at the moment it’s lower on
my todo list. We’re fighting with a lot of Java-related build failures
in Apertis, so I’m basically doing what’s most important to unblock
our further work.

-- 
Cheers,
  Andrej

Bug#863285: [winbind] Install/Updates Fail When Samba Running as samba 4 Domain

[MAS Jean-Louis]

We stumbled into this bug during our Jessie to stretch update.

The solution provided in Message #60 worked perfectly.

However, the bug is fixed in samba 2:4.8.0+dfsg-2 but Stretch uses samba
2:4.5.16+dfsg-1, so it's not fixed in Stretch.

I think it should be mentioned in Stretch release note.

Regards

-- 
Jean Louis Mas



smime.p7s
Description: Signature cryptographique S/MIME

Bug#919385: postgresql-common: alter system set port ignored by pg-commands

[Christoph Berg]

Control: tag -1 moreinfo

Re: wim 2019-01-15 <154755510710.20704.3906668621163200728.reportbug@zwerfkat>
> 1. connect with psql to your local instance
> 2. use alter system to set the port to a non default port
> 3. restart postgresql
> 4. you will notice that pg_lsclusters still lists the old port instead of the 
> changed port by alter system
> 5. you cannot connect with psql unless with specifying the port

Hi Wim,

this has actually been fixed in postgresql-common 170 in October 2015,
postgresql.auto.conf is now also read.

But in actual practise, there is a problem, postgresql.auto.conf is
stored inside PGDATA, which is not readable by anyone except postgres
and root, so settings modified that way are only visible (and used)
for these users.

I don't see how we can sanely get out of this problem. The idea of
connecting to the server to query pg_settings has the problem that
it's more heavyweight, and of course we need to know the port to be
able to connect... Storing the port in yet another location doesn't
seem attractive either.

Christoph

Bug#868355: Any reason not to simply upload ceres-solver with adjusted version of libeigen3-dev

[Mo Zhou]

On Tue, Feb 26, 2019 at 11:25:49AM +0100, Andreas Tille wrote:
> > The eigen3 maintainer and I are happy to simply rebuild affected
> > packages after every eigen3 update, but Emilio considers it an upstream bug.
> > Unfortunately I could not find anybody able to shed more light on the
> > eigen3 topic.
> 
> I agree that the topic seems to be more complex in general but for the
> moment we need a fix for Buster and that fix is very simple - so I do
> not see any reason to not fix it.  You might like to reopen the relevant
> bugs (I mean #868355 - I just asked for closing which was done and
> #883619) with lower severity to keep on discussing for Buster+1.

Similar to packages built against static libraries, eigen3 as a
header-only library gives us no chance except for binNMU all the rdeps.

There are a lot of header only packages in my packaging radar, and
the transition problem really brings me headache. Fortunately they
won't have to much rdeps at the beginning.

Bug#923325: cppcheck-gui: memleak error is not visible in gui

[Gavin Schenk]

Package: cppcheck-gui
Version: 1.86-1
Severity: normal

Dear Maintainer,

a memory leak error is not visible in gui. When using the version from stretch 
the error is visible again.

Small example:
...
#include 
#include 

class TestType {
public:
   char ca[12];
   int ul;
   double d;
};

char* rawData()
{
static char data[] = "ASDFASDGASDGSG";
return data;
}

QString foo()
{
int type = 0x100;
if ( type == 0x100 ) {
TestType *tt = new TestType();
tt=(TestType *)rawData(); //<-memleak
return QString(tt->ca)+" "+QString::number(tt->ul)+" 
"+QString::number(tt->d);
delete tt; // <- never come here ...
}
else{
return QString("Else");
}
}

int main()
{
QString test = foo();
std::cout << test.toStdString() << std::endl;
return 0;
}
...

I just removed this complete stupid code from the project, but I wonder
why the error is visible in 1.76-1 and its not in 1.86-1 when using
the same data base.

Regards
Gavin


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

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

Versions of packages cppcheck-gui depends on:
ii  libc62.28-7
ii  libgcc1  1:8.2.0-21
ii  libgl1   1.1.0-1
ii  libpcre3 2:8.39-11
ii  libqt5core5a 5.11.3+dfsg-5
ii  libqt5gui5   5.11.3+dfsg-5
ii  libqt5printsupport5  5.11.3+dfsg-5
ii  libqt5widgets5   5.11.3+dfsg-5
ii  libstdc++6   8.2.0-21
ii  libtinyxml2-6a   7.0.0+dfsg-1

cppcheck-gui recommends no packages.

Versions of packages cppcheck-gui suggests:
ii  clang1:7.0-47
ii  python3  3.7.2-1

-- no debconf information

Bug#922205: openssh-client: scp regression: CVE-2019-6111 fix breaks syntax to overwrite target directory permissions

[Colin Watson]

On Wed, Feb 13, 2019 at 10:36:34AM +0200, Harry Sintonen wrote:
> The recent openssh upstream fix to "check in scp client that filenames sent 
> during
> remote->local directory copies satisfy the wildcard specified by the user" 
> (*) had an unfortunate
> side effect of breaking a legitimate use case of scp: deliberately copying 
> the source directory
> permissions over the target directory. This is achieved by using syntax: 
> "dir/.".

Hi,

Have you already reported this directly upstream (bugzilla.mindrot.org)?
I'd expect that to be the best approach here, since the upstream master
branch exhibits the same problem, and especially since the changes were
in response to your security vulnerability report.  We can of course
cherry-pick regression fixes that have landed upstream.

Note that it was actually
https://anongit.mindrot.org/openssh.git/commit/?id=6010c0303a422a9c5fa8860c061bf7105eb7f8b2
that broke this.

Thanks,

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

Bug#876669: postgresql: cannot make standard postgresql clusters log to stderr or syslog

[Christoph Berg]

Control: tag -1 moreinfo

Re: To Daniel Kahn Gillmor 2017-09-25 
<20170925073154.d5a7ekrvmg3wf...@msg.df7cb.de>
> > but this doesn't prevent the postgres process from re-opeing
> > /var/log/postgresql/postgresql-9.6-main.log.  I've traced the startup
> > code as far as pg_ctlcluster to where it looks like it's enforcing the
> > logging to /var/log, but i can't figure out how to get it to stop.
> 
> I realize that setups that really just want to catch stderr to feed it
> elsewhere have a problem here.

I could get it working by adding --foreground to the startup command:

# /etc/systemd/system/postgresql@.service.d/override.conf
[Service]
Type=exec
ExecStart=
ExecStart=-/usr/bin/pg_ctlcluster --skip-systemctl-redirect --foreground %i 
start

Does that work for you?

Christoph

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

[Vincent Lefevre]

On 2019-02-26 12:44:41 +, Colin Watson wrote:
> Of course, the grub-pc maintainer script doesn't know either.  All it
> has available to it is a /dev/disk/by-id/ path that no longer points to
> a disk.  The case I had in mind when writing that code, and I think
> almost certainly the overwhelmingly common case, is where the disk in
> question has been removed; the edge case that we have here is where the
> disk in question is still installed but its supposedly fixed ID has
> changed.

But note that even in the case where the disk has been removed, it
could also be a temporary removal (either physical, or virtual, with
VM's). So, it is also important to preserve the information in this
case.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#923286: scp: 'protocol error: filename does not match request' even though it does match

[Colin Watson]

On Mon, Feb 25, 2019 at 10:22:55PM +0100, Ansgar Burchardt wrote:
> The file "This is a [file].txt" (w/o quotes) exists on `remote`.
> 
> The following does no longer work:
> 
>$ scp remote:'./"This is a [file].txt"' blubb
>protocol error: filename does not match request

Hi,

Would you mind filing this directly upstream (bugzilla.mindrot.org)?
They seem to have been doing a fair bit of work on this lately, and will
probably appreciate a direct heads-up of regressions.

> These however do still work:
> 
>$ scp remote:'"This is a [file].txt"' blubb
>$ scp remote:'./This\ is\ a\ \[file\].txt' blubb
>$ scp remote:'This\ is\ a\ \[file\].txt' blubb

Even these don't work as of upstream commit
3d896c157c722bc47adca51a58dca859225b5874.

> Extended globs (from zsh) now only work sometimes as well:
> 
>$ scp daikoku:'./This\ is\ a\ \[file\].txt(.)' blubb
>protocol error: filename does not match request
>$ scp daikoku:'This\ is\ a\ \[file\].txt(.)' blubb

I'm not sure if these will ever work, seeing as upstream seems to be
moving in the direction of implementing the wildcard expansions
themselves.

That said, using the new -T option makes the scp client trust the
server's wildcard expansion.  I haven't tested the zsh extended glob
case, but it makes all your other examples work.

Thanks,

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

Bug#916447: Please copy win32-loader/0.9.4 from unstable to testing

[Didier 'OdyX' Raboud]

Control: retitle -1 Tools: Please copy win32-loader/0.9.4 from unstable to 
testing

Le vendredi, 14 décembre 2018, 16.21:15 h CET Didier 'OdyX' Raboud a écrit :
> win32-loader 0.9.2 migrated automatically, but its byhand counterpart
>   ./debian/tools/win32-loader/testing/*
> … is still 0.8.4.
> 
> Please copy debian/tools/win32-loader/unstable into …/testing

0.9.4 should migrate today; updating.

Cheers,
OdyX

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

Bug#923326: RFP: trava-jdk-11-dcevm -- Alternative VM for OpenJDK 11 with enhanced class redefinition

[Michael Meier]

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

Would be the replacement for the outdated openjdk-8-jre-dcevm package 
which is in debian stretch.
For Java Developpers having the updated package would make live a lot 
easier :-).


--- Please fill out the fields below. ---

   Package name: trava-jdk-11-dcevm

Version: 11
URL: https://github.com/TravaOpenJDK/trava-jdk-11-dcevm
License: apache

Bug#921914: minissdpd: Lots of "Address already in use" syslog messages (again)

[Yangfl]

Control: tags -1 moreinfo

can't reproduce by any possible means I can image

Bug#923327: xapers: intermittent autopkgtest failures (escaped underscores in XAPERS_ROOT?)

[Daniel Kahn Gillmor]

Package: xapers
Version: 0.8.2-1.1
Severity: normal

https://ci.debian.net/packages/x/xapers/unstable/amd64/ shows that
there are intermittent failures in the autopkgtest.

I suspect that the issue is when XAPERS_ROOT contains an underscore,
then the filtering (sed "s|$XAPERS_ROOT|XAPERS_ROOT|") doesn't behave
as expected.

why the underscore is escaped in the first place, i don't know!

here's the snippet of failing tests:


FAIL   search --output=bibtex single
--- all.48.expected 2019-02-12 09:56:55.994607258 +
+++ all.48.output   2019-02-12 09:56:55.994607258 +
@@ -3,6 +3,6 @@
 title = "Creation of the γ-verses",
 year = "2011",
 eprint = "1235",
-file = ":XAPERS_ROOT/01/1.pdf:pdf"
+file = 
":/tmp/autopkgtest-lxc.9v\_4vmuj/downtmp/build.8os/src/test/tmp.all/docs/01/1.pdf:pdf"
 }
 
 FAIL   bibtex multiple
--- all.49.expected 2019-02-12 09:56:56.158602082 +
+++ all.49.output   2019-02-12 09:56:56.158602082 +
@@ -10,7 +10,7 @@
 year = "2012",
 month = "Sep",
 pages = "2092",
-file = ":XAPERS_ROOT/02/2 file.pdf:pdf"
+file = 
":/tmp/autopkgtest-lxc.9v\_4vmuj/downtmp/build.8os/src/test/tmp.all/docs/02/2
 file.pdf:pdf"
 }
 
 @article{arxiv:1235,
@@ -18,7 +18,7 @@
 title = "Creation of the γ-verses",
 year = "2011",
 eprint = "1235",
-file = ":XAPERS_ROOT/01/1.pdf:pdf"
+file = 
":/tmp/autopkgtest-lxc.9v\_4vmuj/downtmp/build.8os/src/test/tmp.all/docs/01/1.pdf:pdf"
 }
 
 @article{30929234,
No bibtex for doc id:5.


   --dkg


-- System Information:
Debian Release: buster/sid
  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.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xapers depends on:
ii  poppler-utils  0.71.0-2
ii  python33.7.2-1
ii  python3-pkg-resources  40.7.1-1
ii  python3-pybtex 0.21-2
ii  python3-xapian 1.4.10-1

Versions of packages xapers recommends:
ii  python3-pycurl  7.43.0.2-0.1
ii  python3-urwid   2.0.1-2+b1
ii  xclip   0.13-1
ii  xdg-utils   1.1.3-1

xapers suggests no packages.

-- no debconf information

Bug#923328: lxc: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: lxc 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of lxc debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

[Colin Watson]

On Tue, Feb 26, 2019 at 04:01:33PM +0100, Vincent Lefevre wrote:
> On 2019-02-26 12:44:41 +, Colin Watson wrote:
> > Of course, the grub-pc maintainer script doesn't know either.  All it
> > has available to it is a /dev/disk/by-id/ path that no longer points to
> > a disk.  The case I had in mind when writing that code, and I think
> > almost certainly the overwhelmingly common case, is where the disk in
> > question has been removed; the edge case that we have here is where the
> > disk in question is still installed but its supposedly fixed ID has
> > changed.
> 
> But note that even in the case where the disk has been removed, it
> could also be a temporary removal (either physical, or virtual, with
> VM's). So, it is also important to preserve the information in this
> case.

It's moot, since I think it winds up essentially the same as the work I
did for your bug.

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

Bug#923312: gnome-terminal ignores system ulimits

[Harald Dunkel]

Sorry, this sounded very harsh. What I meant was:

dbus-user-session sneaked in by some package recommendation
recently, AFAICT. It should not affect a working configuration
in /etc/security/limits.d/ created back in 2016.


Regards
Harri

Bug#908203: opam: Should not depend on aspcud any more

[Louis Gesbert]

Hi all,

Thanks a lot for the packaging efforts. It's not much tested in the wild 
anymore, as Anil pointed out, but aspcud is still part of our test-suite and 
_should_ work.

The error you are getting is internal to aspcud, though (it happens between 
gringo and aspcud itself), so that might point us to a discrepancy of versions 
between aspcud/gringo/clasp, which already happened in the past. I was unable 
to reproduce yet using the stable packages (clasp 3.2.1-3, gringo 5.1.0-4, 
aspcud 1:1.9.1-2+b1) and opam master (which shouldn't change much). It would be 
worth ① checking the tool versions, ② extracting the Cudf file sent to the 
solver (set OPAMCUDFFILE=/tmp/foo), ③ checking the aspcud debug output (by 
running it directly on the generated file).

I understand that getting ocaml-mccs into Debian might not be easy. The mccs 
version included has been so widely changed from the original (which is 
unmaintained) that I would argue it is acceptable to include it besides the 
original, maybe with a different name (the current one would suggest a 
binding); but we do also include a stripped version of GLPK in the source. That 
on the other hand is unpatched, and there are linking options to rely on an 
external version (either statically or dynamically). I am willing to give a 
hand if anyone feels like attempting to package it.

FWIW, we are also working on a Z3 backend, which doesn't require new or 
specific bindings. For that one, Debian packaging while relying on 
`libz3-ocaml-dev` would probably be easier than the source distribution.

Best,
Louis


> - Anil Madhavapeddy, 25/02/2019 19:16 -
> On Sun, 9 Sep 2018 10:44:14 +0200 Ralf Jung  wrote:
> > Hi Mehdi,
> > 
> > > On 2018-09-07 12:42, Ralf Jung wrote:
> > >> Package: opam
> > >> Version: 2.0.0-2
> > >> Severity: normal
> > >>
> > >> Dear Maintainer,
> > >>
> > >> Quoting from https://opam.ocaml.org/doc/2.0/External_solvers.html:
> > >>
> > >>> As of 2.0.0, opam comes with a CUDF solver built-in by default, so 
> > >>> unless you
> > >>> have specifically compiled without it, you shouldn't have to be worried 
> > >>> about
> > >>> installing an external solver.
> > >>
> > >> So, aspcud should at best be a recommendation, not a dependency.  
> > >> Likely, it
> > >> should just be a suggestions; the internal solver is used by default 
> > >> even when
> > >> aspcud is installed.
> > >>
> > > 
> > > If I am not mistaken, the built-in solver is not enabled in the Debian 
> > > package
> > > because we are missing ocaml-mccs to make it work. So, for now, the 
> > > dependency
> > > is still needed.
> > 
> > Oh... that's a bummer, because using the new built-in solver is one of the
> > biggest reasons to update to opam 2 for me. :/  aspcud keeps computing 
> > really
> > strange solutions in some cases I frequently run into.
> > 
> 
> Dear Debian opam maintainers,
> 
> It's really great to see opam 2.0.3 in Debian testing now! I just wanted
> to highlight the importance of using the builtin mccs solver in order
> to get a working opam installation on Debian Buster however.
> 
> Right now, the opam repository seems to fail badly when using the
> aspcud solver out of the box:
> 
> """
> $ docker run -it debian:testing
> # apt update
> # apt install -y opam
> # opam init -ya
> [WARNING] Running as root is not recommended
> [NOTE] Will configure from built-in defaults.
> Checking for available remotes: rsync and local, git, mercurial, darcs. 
> Perfect!
> 
> <><> Fetching repository information 
> ><><><><><><><><><><><><><><><><><><><><><>
> [default] Initialised
> 
> User configuration:
>   ~/.profile is already up-to-date.
> [NOTE] Make sure that ~/.profile is well sourced in your ~/.bashrc.
> 
> 
> <><> Creating initial switch (ocaml-system>=4.02.3) 
> <><><><><><><><><><><><><><>
> [ERROR] Solver failed: "/usr/bin/aspcud 
> /tmp/opam-xxx-4710/solver-in-4710-548b09 
> /tmp/opam-xxx-4710/solver-out-4710-8b8a2d
> 
> -count(removed),-sum(request,version-lag),-count(down),-sum(solution,version-lag),-count(changed)"
>  exited with code 1 "ERROR:
> grounder returned with non-zero exit status"
> """
> 
> I've CCed Louis Gesbert in case he can shed any light on how to
> make aspcud work more reliably, but I strongly suspect that we've
> been testing the builtin mccs for so long that it's become the only
> solver in the opam 2.0.x branch capable of actually working with
> the current opam-repository.
> 
> regards,
> Anil
> 


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

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

[Vincent Lefevre]

On 2019-02-26 15:20:10 +, Colin Watson wrote:
> On Tue, Feb 26, 2019 at 04:01:33PM +0100, Vincent Lefevre wrote:
> > On 2019-02-26 12:44:41 +, Colin Watson wrote:
> > > Of course, the grub-pc maintainer script doesn't know either.  All it
> > > has available to it is a /dev/disk/by-id/ path that no longer points to
> > > a disk.  The case I had in mind when writing that code, and I think
> > > almost certainly the overwhelmingly common case, is where the disk in
> > > question has been removed; the edge case that we have here is where the
> > > disk in question is still installed but its supposedly fixed ID has
> > > changed.
> > 
> > But note that even in the case where the disk has been removed, it
> > could also be a temporary removal (either physical, or virtual, with
> > VM's). So, it is also important to preserve the information in this
> > case.
> 
> It's moot, since I think it winds up essentially the same as the work I
> did for your bug.

Yes, I think that the fix is OK in practice (for whatever cause
of an "orphan" /dev/disk/by-id/ path). Thanks.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#923329: php-imagick can't be installed with PHP 7.3

[Andrius Narbutas]

Package: php-imagick
Version: 3.4.3~rc2-2
Severity: normal

Dear Maintainer,

Currently php-imagick package can't be installed with PHP 7.3:

[n][/etc]# aptitude install php7.3-imagick
"php7.3-imagick" exists in the package database, but it is not a real package 
and no package provides it
Unable to apply some actions, aborting
[n][/etc]# aptitude show php7.3-imagick
No candidate version found for php7.3-imagick
Package: php7.3-imagick
State: not a real package
Provided by: php-imagick (3.4.3-4+0~20190217142022.9+stretch~1.gbpba1eeb)

Trying to install php-imagick installs php7.0:

[n][/etc]# aptitude install php-imagick
The following NEW packages will be installed:
  php-imagick php7.0-cli{a} php7.0-common{a} php7.0-json{a} php7.0-opcache{a} 
php7.0-phpdbg{a} php7.0-readline{a}
The following packages are RECOMMENDED but will NOT be installed:
  ghostscript ttf-dejavu-core
0 packages upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/3.684 kB of archives. After unpacking 14,6 MB will be used.
Do you want to continue? [Y/n/?] y

But imagick is not available for PHP7.3.
Also, even if installed from 7.0 package it's not compatible (binary) with 7.3:

ln -s /usr/lib/php/20151012/imagick.so /usr/lib/php/20180731/imagick.so
[namuciai][/mnt/sys/www/lag.lt/s/Lychee]# composer install --no-dev
PHP Startup: Unable to load dynamic library 'imagick.so' (tried: 
/usr/lib/php/20180731/imagick.so (/usr/lib/php/20180731/imagick.so: undefined 
symbol: _zval_ptr_dtor), /usr/lib/php/20180731/imagick.so.so 
(/usr/lib/php/20180731/imagick.so.so: cannot open shared object file: No such 
file or directory)) in Unknown on line 0


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

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

Versions of packages php-imagick depends on:
ii  libc62.24-11+deb9u4
ii  libmagickcore-6.q16-38:6.9.7.4+dfsg-11+deb9u6
ii  libmagickwand-6.q16-38:6.9.7.4+dfsg-11+deb9u6
ii  php-common   1:49
ii  php7.0-cli [phpapi-20151012] 7.0.33-0+deb9u1
ii  php7.0-phpdbg [phpapi-20151012]  7.0.33-0+deb9u1

Versions of packages php-imagick recommends:
pn  ghostscript  
pn  ttf-dejavu-core  

php-imagick suggests no packages.

-- no debconf information

Bug#923330: jajuk: Fails to start with Java Runtime Environment 1.7 minimum required. You use a JVM ext.JVM@23fc625e

[Werner Mahr]

Package: jajuk
Version: 1:1.10.9+dfsg2-4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Just trying to start jajuk. From the menu just nothing happens, from 
commandline I get the error from the subject.
The installed jre came as a dep of libreoffice.


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jajuk depends on:
ii  default-jre [java8-runtime] 2:1.11-71
ii  entagged0.35-6
ii  java-wrappers   0.3
ii  libbasicplayer-java 3.0-6
ii  libcobra-java   0.98.4-5
ii  libcommons-codec-java   1.11-1
ii  libcommons-collections3-java3.2.2-2
ii  libcommons-io-java  2.6-2
ii  libcommons-lang-java2.6-8
ii  libcommons-logging-java 1.2-2
ii  libdbus-java2.8-9
ii  libguava-java   19.0-1
ii  libjaudiotagger-java2.0.3-3
ii  libjcommon-java 1.0.23-1
ii  libjfreechart-java  1.0.19-2
ii  libjgoodies-animation-java  1.4.3-2
ii  libjhlabs-filters-java  2.0.235-3
ii  libjlayer-java  1.0.1-2
ii  libjmac-java1.74-6
ii  libjna-java 4.5.2-1
ii  libjorbis-java  0.0.17-2
ii  libjspeex-java  0.9.7-4
ii  liblaf-plugin-java  7.3+dfsg3-4
ii  liblaf-widget-java  7.3+dfsg3-4
ii  liblastfm-java  1:0.1.0-2
ii  liblog4j1.2-java1.2.17-8
ii  libmiglayout-java   5.1-2
ii  libmp3spi-java  1.9.5-1
ii  libqdwizard-java5.0.1-1
ii  librhino-java   1.7.7.1-1
ii  libsimple-validation-java   0.9-2
ii  libswingx-java  1:1.6.2-4
ii  libtrident-java 7.3+dfsg3-4
ii  libtritonus-java20070428-14
ii  libvldocking-java   3.0.5-2
ii  libvorbisspi-java   1.0.3-3
ii  libxstream-java 1.4.11.1-1
ii  mplayer 4:1.3.0~20181120.svn38117-dmo3
ii  openjdk-11-jre [java8-runtime]  11.0.2+9-3
ii  substance   7.3+dfsg3-4

jajuk recommends no packages.

jajuk suggests no packages.

-- no debconf information

-- 
MfG usw.

Werner Mahr

Bug#923331: lintian: Check for debian/tests/pkg-js/test if "dh --with nodejs" is used

[Xavier Guimard]

Package: lintian
Version: 2.7.0
Severity: wishlist

Hi all,

pkg-js-tools provides tools to test nodejs packages. It search for 2
files: debian/tests/pkg-js/{test,files}

It could be interesting to provide these 2 tags:

 * "W: pkg-js-tools-test-is-missing":
   - if "dh --with nodejs" is used and both debian/tests/pkg-js/test and
 "override_dh_auto_test" are missing: "W: pkg-js-tools-test-is-missing".
   - if "Testsuite" = "autopkgtest-pkg-nodejs" and
 debian/tests/pkg-js/test is missing
   This is just a warning since since pkg-js-tools and pkg-js-autopkgtest
   will fall to a simple "node require('.')"

 * "E: pkg-js-autopkgtest-file-does-not-exist":
   - if debian/tests/pkg-js/files exists, each line must match to an
 existing file(s) in unbuilt source, else autopkgtest will fail.
 This files contains lines given to `tar cf - "$@"`. Test can be
 something like:

use Dpkg::IPC;  
  
{   
  
  my $out;
  local $ENV{LANG} = 'C';
  spawn(
exec => ['tar', '--create', '--file', '/dev/null', @non_empty_lines],
wait_child => 1,
error_to_string => \$out,
nocheck => 1
  );  
  if($?) {
my @files = map {/tar:\s+(.*?):\s*Cannot stat/; $1} grep /Cannot stat/, 
 
  split(/\n/, $out);
foreach(@files) {
tag "pkg-js-autopkgtest-file-does-not-exist", $_;
}   
  }   
}

Cheers,
Xavier

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (600, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.35-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdigest-sha-perl 6.02-1+b1
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
it  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl   5.28.1-4
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.54-1

-- no debconf information

Bug#912976: Buster's Release file on s.d.o is signed by wheezy's key

[Daniel Kahn Gillmor]

On Mon 2018-11-05 13:02:33 +0100, Guido Günther wrote:
> the release file at
>
> http://security.debian.org/debian-security/dists/buster/updates/
>
> is signed by wheezy's key 8B48AD6246925553 which is no longer in
> debian-archive-keyring. This makes new installations fail that already
> enable the above security archive.

The buster security archive is no longer signed with wheezy's key, but
it's signed with jessie's key:


0 dkg@alice:~$ wget -q -O- 
'http://security.debian.org/debian-security/dists/buster/updates/Release.gpg' | 
gpg --list-packets
# off=0 ctb=89 tag=2 hlen=3 plen=563
:signature packet: algo 1, keyid 9D6D8F6BC857C906
version 4, created 1551171107, md5len 0, sigclass 0x00
digest algo 8, begin of digest 32 ef
hashed subpkt 33 len 21 (issuer fpr v4 
D21169141CECD440F2EB8DDA9D6D8F6BC857C906)
hashed subpkt 2 len 4 (sig created 2019-02-26)
subpkt 16 len 8 (issuer key ID 9D6D8F6BC857C906)
data: [4096 bits]
0 dkg@alice:~$ gpg --list-keys D21169141CECD440F2EB8DDA9D6D8F6BC857C906
pub   rsa4096 2014-11-21 [SC] [expires: 2022-11-19]
  D21169141CECD440F2EB8DDA9D6D8F6BC857C906
uid   [ unknown] Debian Security Archive Automatic Signing Key 
(8/jessie) 

0 dkg@alice:~$


I would have expected it to be signed with key
6ED6F5CB5FA6FB2F460AE88EEDA0D2388AE22BA9 (the security archive signing
key for stretch) instead. or, at least, signed by both of the keys.

I'm using explicit signed-by= options in my sources.list file on buster
installations, and it's very odd that i need to have:


deb 
[signed-by=/usr/share/keyrings/debian-archive-jessie-security-automatic.gpg] 
http://security.debian.org/debian-security buster/updates main


--dkg


signature.asc
Description: PGP signature

Bug#923332: RFP: network-manager-libreswan -- Libreswan VPN client plugin for NetworkManager

[Laurent Bigonville]

Package: wnpp
Severity: wishlist

* Package name: network-manager-libreswan
  Version : 1.2.10
  Upstream Author : Avesh Agarwal 
Dan Williams 
David Zeuthen 
Dan Winship 
Jiří Klimeš 
Lubomir Rintel 
* URL : https://gitlab.gnome.org/GNOME/NetworkManager-libreswan
* License : GPL
  Programming Lang: C
  Description : Libreswan VPN client plugin for NetworkManager

Support for configuring IKEv1 based IPsec virtual private network connections.
Compatible with Libreswan and Cisco IPsec VPN servers.

Bug#923333: libp11-openssl1.1: Double free issue

[Kurt Kanzenbach]

Source: libp11-openssl1.1
Version: 0.4.4-4
Severity: important
Tags: patch
Control: forwarded -1 https://github.com/OpenSC/libp11/issues/185

Dear Maintainer,

using the pkcs11 back end results in a double-free:

 kurt@kurt tmp % openssl dgst -sha256 -engine pkcs11 -keyform engine -sign 
"pkcs11:" blub > blub.sig
 engine "pkcs11" set.
 No private keys found.
 PKCS#11 token PIN:
 *** Error in `openssl': double free or corruption (fasttop): 
0x558e9ed49230 ***
 === Backtrace: =
 /lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7f3ac5f40bfb]
 /lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7f3ac5f46fc6]
 /lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7f3ac5f4780e]
 /usr/lib/softhsm/libsofthsm2.so(+0x709e8)[0x7f3ac56149e8]
 /usr/lib/softhsm/libsofthsm2.so(+0x70657)[0x7f3ac5614657]
 /usr/lib/softhsm/libsofthsm2.so(+0x2e967)[0x7f3ac55d2967]
 /usr/lib/softhsm/libsofthsm2.so(C_CloseSession+0x14)[0x7f3ac55b8234]
 /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so(+0x1f3dd)[0x7f3ac5a793dd]
 /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so(+0x39fe0)[0x7f3ac5a93fe0]
 
/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_closure_unix64_inner+0x1cf)[0x7f3ac5856e2f]
 /usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_closure_unix64+0x46)[0x7f3ac58571a0]
 /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so(+0x2302d)[0x7f3ac5a7d02d]
 /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so(+0x23190)[0x7f3ac5a7d190]
 /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so(+0x3a000)[0x7f3ac5a94000]
 
/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_closure_unix64_inner+0x1cf)[0x7f3ac5856e2f]
 /usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_closure_unix64+0x46)[0x7f3ac58571a0]
 /usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so(+0xb2d5)[0x7f3ac5cca2d5]
 /usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so(+0xb737)[0x7f3ac5cca737]
 /usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so(+0x5cbe)[0x7f3ac5cc4cbe]
 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x14c13f)[0x7f3ac67dc13f]
 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x14dea2)[0x7f3ac67ddea2]
 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(OPENSSL_LH_doall+0x41)[0x7f3ac67fd971]
 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x14e22d)[0x7f3ac67de22d]
 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x14c356)[0x7f3ac67dc356]
 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(OPENSSL_sk_pop_free+0x31)[0x7f3ac6851ca1]
 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x14c6ac)[0x7f3ac67dc6ac]
 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(OPENSSL_cleanup+0x11e)[0x7f3ac67fb9de]
 /lib/x86_64-linux-gnu/libc.so.6(+0x35940)[0x7f3ac5f05940]
 /lib/x86_64-linux-gnu/libc.so.6(+0x3599a)[0x7f3ac5f0599a]
 openssl(+0x2ee64)[0x558e9cab1e64]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f3ac5ef02e1]
 openssl(+0x2f09a)[0x558e9cab209a]
 === Memory map: 
 [...]

This is already fixed upstream:

 
https://github.com/OpenSC/libp11/commit/da725ab727342083478150a203a3c80c4551feb4

The function EVP_PKEY_set1_engine() is available in Stretch's OpenSSL 1.1.

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

Kernel: Linux 4.19.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
From da725ab727342083478150a203a3c80c4551feb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20Trojnara?= 
Date: Sat, 4 Nov 2017 09:25:10 +0100
Subject: [PATCH] Invoke EVP_PKEY_set1_engine() if OpenSSL has it

This approach was suggested by @mouse07410 in #185.
---
 src/eng_front.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/eng_front.c b/src/eng_front.c
index 9633fe061c75..45f15a1b1f2e 100644
--- a/src/eng_front.c
+++ b/src/eng_front.c
@@ -195,11 +195,19 @@ static EVP_PKEY *load_privkey(ENGINE *engine, const char *s_key_id,
 		UI_METHOD *ui_method, void *callback_data)
 {
 	ENGINE_CTX *ctx;
+	EVP_PKEY *pkey;
 
 	ctx = get_ctx(engine);
 	if (ctx == NULL)
 		return 0;
-	return ctx_load_privkey(ctx, s_key_id, ui_method, callback_data);
+	pkey = ctx_load_privkey(ctx, s_key_id, ui_method, callback_data);
+#ifdef EVP_F_EVP_PKEY_SET1_ENGINE
+	/* EVP_PKEY_set1_engine() is required for OpenSSL 1.1.x,
+	 * but otherwise setting pkey->engine breaks OpenSSL 1.0.2 */
+	if (pkey)
+		EVP_PKEY_set1_engine(pkey, engine);
+#endif /* EVP_F_EVP_PKEY_SET1_ENGINE */
+	return pkey;
 }
 
 static int engine_ctrl(ENGINE *engine, int cmd, long i, void *p, void (*f) ())
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#922104: grub-install: check for arm-efi as a default target

[Steve McIntyre]

On Tue, Feb 26, 2019 at 02:29:14PM +, Colin Watson wrote:
>On Tue, Feb 12, 2019 at 02:49:34AM +, Steve McIntyre wrote:
>> I've already submitted the core of this upstream - see
>> 
>>   http://lists.gnu.org/archive/html/grub-devel/2019-02/msg00018.html
>> 
>> Much like on x86, we can work out if the system is running on top of
>> EFI firmware. If so, return "arm-efi". If not, fall back to
>> "arm-uboot" as previously.
>> 
>> Heavily inspired by the existing code for x86.
>> 
>> I'd push this as an MR, but my head is just not in the right place for
>> handling git-dpm right now :-(
>> 
>> Here's a patch instead, ready to drop into debian/patches. I've
>> extended the code here in similar fashion to what's already been added
>> in our version of grub_install_get_default_x86_platform() to check in
>> the pkglibdir. Otherwise this new code is just the same as I've sent
>> upstream yesterday.
>
>Thanks.  I'd prefer to have the upstream and pkglibdir parts as separate
>patches, though, since that'll make rebasing onto new upstream releases
>easier in future.
>
>I cherry-picked the upstream patch (though noting that the version of
>that isn't actually the same as the final version you posted to
>grub-devel, so you might want to chase that up with Daniel), and applied
>a separate patch on top of it to add the pkglibdir bits.

ACK, thanks. Have you tried pushing the pkglibdir patches upstream at
all?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Bug#885433: wiki.debian.org: Access to wiki.debian.org is blocked with 403 Forbidden

[Laurent COMMARIEU]

Hi,

My office IP 185.123.72.18 is also blocked. Is it possible to unblock it?

Thanks,

Regards,

-- 
Laurent Commarieu