Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Gilles Filippini]

Hi Sebastian,

On 03.12.18 00:15, Sebastiaan Couwenberg wrote:> Unfortunately the
autopkgtests for 0.9.9-1 still fail [0], and since> it's blocking the
migration of hdf5 it makes the package unsuitable for> release
justifying the RC severity [1].
Sorry, but I don't see this: gdl does not *break* hdf5 ("break" means
IMO that a package that worked before does not work anymore -- but hdf5
still works nicely, right?), and it also does not block the transition.

As far as I know, CI tests are currently setup in a non-blocking way.
And when I look into the maintainer page of hdf5, it says

"Required age increased by 30 days because of autopkgtest".

This is not a block, this is just a delay. There never was a statement
that failing CI tests are RC (or would become so before buster).

So, you you please be a bit more explicit how the RC policy applies here?

Best regards

Ole

Bug#908957: stretch-pu: package z3/4.4.1-0.4~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Sun, Sep 16, 2018 at 09:13:43PM +0300, Adrian Bunk wrote:
> diff -Nru z3-4.4.1/debian/changelog z3-4.4.1/debian/changelog
> --- z3-4.4.1/debian/changelog 2016-09-26 08:28:12.0 +0300
> +++ z3-4.4.1/debian/changelog 2018-09-16 20:46:04.0 +0300
> @@ -1,3 +1,18 @@
> +z3 (4.4.1-0.4~deb9u1) stretch; urgency=medium
> +
> +   * Non-maintainer upload.
> +   * Rebuild for stretch.
> + 
> + -- Adrian Bunk   Sun, 16 Sep 2018 20:46:04 +0300
> +
> +z3 (4.4.1-0.4) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Remove the incorrect Multi-Arch: same of python-z3,
> +thanks to Helmut Grohne. (Closes: #874237)
> +
> + -- Adrian Bunk   Sun, 09 Sep 2018 22:28:32 +0300
> +
>  z3 (4.4.1-0.3) unstable; urgency=medium
>  
>* Non-maintainer upload.

Go ahead, thanks.

Cheers,
Julien

Bug#913885: stretch-pu: package libapache2-mod-perl2/2.0.10-2+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Fri, Nov 16, 2018 at 12:57:27PM +, Dominic Hargreaves wrote:
> diff -Nru libapache2-mod-perl2-2.0.10/debian/changelog 
> libapache2-mod-perl2-2.0.10/debian/changelog
> --- libapache2-mod-perl2-2.0.10/debian/changelog  2016-12-25 
> 09:51:10.0 +
> +++ libapache2-mod-perl2-2.0.10/debian/changelog  2018-11-16 
> 12:46:23.0 +
> @@ -1,3 +1,10 @@
> +libapache2-mod-perl2 (2.0.10-2+deb9u1) UNRELEASED; urgency=medium
> +
> +  * [SECURITY] CVE-2011-2767: don't allow  sections in
> +user controlled configuration (Closes: #644169)
> +
> + -- Dominic Hargreaves   Fri, 16 Nov 2018 12:46:23 +
> +
>  libapache2-mod-perl2 (2.0.10-2) unstable; urgency=medium
>  
>* Patch the test suite for Apache 2.4.24 compatibility.

With s/UNRELEASED/stretch/, and assuming this has been tested in
stretch, go ahead.

Cheers,
Julien

Bug#913942: stretch-pu: package espeakup/1:0.80-5+deb9u3

[Julien Cristau]

Control: tag -1 + confirmed

On Sat, Nov 17, 2018 at 11:44:19AM +0100, Samuel Thibault wrote:
> diff -Nru espeakup-0.80/debian/changelog espeakup-0.80/debian/changelog
> --- espeakup-0.80/debian/changelog2018-11-02 00:39:25.0 +0100
> +++ espeakup-0.80/debian/changelog2018-11-11 17:43:08.0 +0100
> @@ -1,3 +1,10 @@
> +espeakup (1:0.80-5+deb9u3) stretch; urgency=high
> +
> +  * debian/espeakup.service: Fix compatibility with older versions of systemd
> +(Closes: Bug#913453). Also fix starting with empty voice language.
> +
> + -- Samuel Thibault   Sun, 11 Nov 2018 17:43:08 +0100
> +
>  espeakup (1:0.80-5+deb9u2) stretch; urgency=medium
>  
>* debian/espeakup.service: Automatically load speakup_soft on daemon

Go ahead, thanks.  This will need a d-i ack.

Cheers,
Julien

Bug#912784: stretch-pu: package davix/0.6.4-1.1+deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Sat, Nov 03, 2018 at 10:31:32PM +0100, Mattias Ellert wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> This is a proposed update to the davix package in Debian 9 (stretch). I
> have created it in response to a request that was sent to me via e-mail 
> (included below).
> 
> The proposed update backports the specific bugfix mentioned in the
> request rather than updating to a newer version. This bugfix was part
> of the 0.6.8 update. The version in unstable and testing is currently
> 0.7.1.
> 
Can you describe the effect of this bug?

Cheers,
Julien

Bug#909131: stretch-pu: package kmodpy/0.1.10-2.1~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Tue, Sep 18, 2018 at 09:56:26PM +0300, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> apt-get install python-kmodpy:i386 python-kmodpy:amd64
> 
> This resulted in a situtation where the user could neither
> install and nor remove the packages without editing the prerm.

Go ahead, thanks.

Cheers,
Julien

Bug#901814: stretch-pu: package monkeysign/2.2.3

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Jun 18, 2018 at 01:56:11PM -0400, Antoine Beaupre wrote:
> diff -Nru monkeysign-2.2.3/debian/changelog monkeysign-2.2.4/debian/changelog
> --- monkeysign-2.2.3/debian/changelog 2017-01-24 15:40:35.0 -0500
> +++ monkeysign-2.2.4/debian/changelog 2018-06-18 12:18:46.0 -0400
> @@ -1,3 +1,14 @@
> +monkeysign (2.2.4) unstable; urgency=medium
> +
> +  [ Tobias Rueetschi ]
> +  * false isn't defined, that must be False
> +
> +  [ Antoine Beaupré ]
> +  * actually send multiple emails instead of a single one
> +  * CVE-2018-12020: add no verbose to avoid fake signatures
> +
> + -- Antoine Beaupré   Mon, 18 Jun 2018 12:18:46 -0400
> +
>  monkeysign (2.2.3) unstable; urgency=medium
>  
>[ Simon Fondrie-Teitler ]

This would need to be versioned as 2.2.3+deb9u1.

Otherwise, seems ok.

Cheers,
Julien

Bug#908468: stretch-pu: package weboob/1.2-1

[Julien Cristau]

Control: forcemerge -1 905385

On Fri, Oct 12, 2018 at 12:28:22PM +0900, Marc Dequènes wrote:
> Quack,
> 
> Any news about this?
> 
Any reason this duplicates bug #905385?

Cheers,
Julien

Bug#909127: stretch-pu: package ibus/1.5.14-3+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Tue, Sep 18, 2018 at 09:42:00PM +0300, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> apt-get install gir1.2-ibus-1.0:i386 gir1.2-ibus-1.0:amd64
> 
> This resulted in a situtation where the user could neither
> install and nor remove the packages without editing the prerm.

Go ahead, thanks.

Cheers,
Julien

Bug#898006: stretch-pu: package pcl/1.8.0+dfsg1-3

[Julien Cristau]

Control: tag -1 moreinfo

On Sat, May 05, 2018 at 06:38:25PM +0200, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear release team,
> 
> in #894656 I was asked to add libvtk6-qt-dev as a dependency to
> libpcl-dev in stretch. I would like to do this, except for armel and
> armhf which fails due to OpenGLES, cf. #835292.
> 
Is there anything different about libpcl itself that makes it not need
vtk on arm{el,hf}?  If not that smells fishy to me.

Cheers,
Julien

Bug#911443: raspi3-firmware | Add board-specific firmware files for RPi 3B+ WiFi (!1)

[Matthias Luescher]

Hi Stefan


> So after fixing the polarity of the wifi-reset everything works as
> expected.
>
> - reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 1 GPIO_ACTIVE_LOW>;
>
> I think this should be acceptable as a stable fix for 4.19 LTS.
>

Great!

I applied the same change to arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts and
now it also works on the Raspberry Pi 3 B+.

Many thanks!!!

Best regards
Matthias

Bug#896811: stretch-pu: package icinga2/2.6.0-2+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Tue, Apr 24, 2018 at 02:59:35PM +0200, Felix Geyer wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi,
> 
> Icinga2 2.6.0 stores timestamps as local time instead of UTC in the
> database when the PostgreSQL IDO backend is used.
> 
> The result is that Icinga Web 2 displays all date/times with an offset
> (unless system time is UTC of course).
> While you could argue that this is only a cosmetic problem I think it's
> important for a monitoring system to display the correct time.
> 
> This has been fixed upstream in 2.6.1.
> Bug report is at https://github.com/Icinga/icinga2/issues/4874
> 
> I'd like to upload this fix to stretch, debdiff is attached.
> 
Looks fine to upload, go ahead.

Cheers,
Julien

Bug#887507: stretch-pu: package roundcube/1.2.3+dfsg.1-4+deb9u1

[Julien Cristau]

Control: tag -1 + moreinfo

On Wed, Jan 17, 2018 at 05:04:15PM +0100, Sandro Knauß wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hey,
> 
> upstream releases only bugfix releases for the 1.2 branch. As they,
> do not add any new feature IMO it would makes sense to ship the newest
> 1.2.7 for Debian Stretch users. This is a prepackage request, I havn't
> packaged 1.2.7 for Debian yet, as I would only put effort into it, if it
> can enter stretch in principal. What I can present at the current state
> is a diff of the upstream tarballs (excluded the minified files, cause
> we create those in the packageing process itself). I don't expect any
> changes in the debian folder itself, but I would present a complete
> debdiff, if you approved the general idea of shipping 1.2.7 via pu.
> 
Hi Sandro,

sounds fine to me in theory, please follow up with a tested debdiff and
remove the moreinfo tag.

Cheers,
Julien

Bug#913801: stretch-pu: package mistral/3.0.0-4 CVE-2018-16849: std.ssh action may disclose presence of arbitrary files

[Julien Cristau]

Control: tag -1 confirmed

On Thu, Nov 15, 2018 at 02:07:01PM +0100, Thomas Goirand wrote:
> diff --git a/debian/changelog b/debian/changelog
> index b2ce8602..06234034 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,11 @@
> +mistral (3.0.0-4+deb9u1) stretch-security; urgency=medium

Remove the -security bit.

> +
> +  * CVE-2018-16849: std.ssh action may disclose presence of arbitrary files,
> +applied upstream patch: remove extra information from std.ssh action.
> +(Closes: #912714).
> +
> + -- Thomas Goirand   Mon, 05 Nov 2018 14:38:44 +0100
> +
>  mistral (3.0.0-4) unstable; urgency=medium
>  
>* Add allow-sqla-1.1.patch to allow SQLA transition.

Other than that, looks ok to upload.

Cheers,
Julien

Bug#906813: stretch-pu: package ganeti-os-noop/0.2-1+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Tue, Aug 21, 2018 at 04:12:11PM +0200, Mike Gabriel wrote:
> diff -Nru ganeti-os-noop-0.2/debian/changelog 
> ganeti-os-noop-0.2/debian/changelog
> --- ganeti-os-noop-0.2/debian/changelog   2016-04-11 22:31:50.0 
> +0200
> +++ ganeti-os-noop-0.2/debian/changelog   2018-08-21 16:00:41.0 
> +0200
> @@ -1,3 +1,17 @@
> +ganeti-os-noop (0.2-1+deb9u1) stretch; urgency=medium
> +
> +  * debian/control:
> ++ Update Vcs-*: fields. VCS repo has been migrated to salsa.debian.org.
> ++ Priority extra -> optional.
> ++ Update Maintainer: field to 'Debian Ganeti Team
> +  '
> +  * debian/patches:
> ++ Add 1001_fix-export-script-for-non-block-devices.patch. Fix size
> +  detection for non-block devices. Thanks to Bastian Blank for
> +  providing the patch. (Closes: #895602).
> +
> + -- Mike Gabriel   Tue, 21 Aug 2018 16:00:41 +0200
> +
>  ganeti-os-noop (0.2-1) unstable; urgency=medium
>  
>* Initial release. (Closes: #794482).

Looks ok to upload, thanks.

Cheers,
Julien

Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5

[Julien Cristau]

Control: tag -1 confirmed

On Wed, Oct 31, 2018 at 09:02:48AM -0300, Herbert Fortes wrote:
> On 31/10/2018 05:32, Salvatore Bonaccorso wrote:
> > Hi Herbert,
> > 
> > [Dislcaimer: not SRM here, but only commenting on small issue below]
> > 
> > On Tue, Oct 30, 2018 at 03:31:27PM -0300, Herbert Parentes Fortes Neto 
> > wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > Tags: stretch
> > > User: release.debian@packages.debian.org
> > > Usertags: pu
> > > 
> > > I made Gthumb Debian package version 3:3.4.4.1-6+deb9u1
> > 
> > The version should actually be 3:3.4.4.1-*5*+deb9u1 given the last
> > version in stretch is 3:3.4.4.1-5.
> > 
> > Regards,
> > Salvatore
> > 
> 
> Thanks Salvatore!
> 
> Updated and a new file is attached:
> 
>  - gthumb_3.4.4.1-5_3.4.4.1-5+deb9u1.diff.gz
> 
Go ahead, thanks.

Cheers,
Julien

Bug#913529: stretch-pu: package openvpn/2.4.0-6+deb9u3

[Julien Cristau]

Control: tag -1 confirmed

On Sun, Nov 11, 2018 at 10:30:54PM +0100, Bernhard Schmidt wrote:
> diff -Nru openvpn-2.4.0/debian/changelog openvpn-2.4.0/debian/changelog
> --- openvpn-2.4.0/debian/changelog2017-07-18 22:15:17.0 +0200
> +++ openvpn-2.4.0/debian/changelog2018-10-14 22:55:44.0 +0200
> @@ -1,3 +1,10 @@
> +openvpn (2.4.0-6+deb9u3) stretch; urgency=medium
> +
> +  * Fix NCP behaviour on TLS reconnect, causing "AEAD Decrypt error: cipher
> +final failed" errors (Closes: #909430, #910937)
> +
> + -- Bernhard Schmidt   Sun, 14 Oct 2018 22:55:44 +0200
> +
>  openvpn (2.4.0-6+deb9u2) stretch; urgency=medium
>  
>* Fix broken reconnect on connection loss due to wrong push digest 
> calculation.

Go ahead, thanks.

Cheers,
Julien

Bug#909213: stretch-pu: package wvstreams/4.6.1-12~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Thu, Sep 20, 2018 at 08:21:54AM +0300, Adrian Bunk wrote:
> diff -Nru wvstreams-4.6.1/debian/changelog wvstreams-4.6.1/debian/changelog
> --- wvstreams-4.6.1/debian/changelog  2016-12-17 12:02:02.0 +0200
> +++ wvstreams-4.6.1/debian/changelog  2018-09-19 22:10:56.0 +0300
> @@ -1,3 +1,18 @@
> +wvstreams (4.6.1-12~deb9u1) stretch; urgency=medium
> +
> +  * QA upload.
> +  * Rebuild for stretch.
> +
> + -- Adrian Bunk   Wed, 19 Sep 2018 22:10:56 +0300
> +
> +wvstreams (4.6.1-12) unstable; urgency=low
> +
> +  * QA upload.
> +  * Work around stack corruption, thanks to Karol Ossowski.
> +(Closes: #863039)
> +
> + -- Adrian Bunk   Sun, 12 Aug 2018 21:40:33 +0300
> +
>  wvstreams (4.6.1-11) unstable; urgency=medium
>  
>* QA upload.

OK, I guess.  Feel free to upload.

Cheers,
Julien

Bug#875621: X1 Carbon 6th Gen Trackpad issues

[Duncan Findlay]

I can confirm that recompiling the kernel with CONFIG_RMI4_SMB=m (and only
that change) is sufficient to make the Touchpad & TrackPoint usable on the
X1 Carbon 6th gen. Without this, it's completely unusable.

This is a regression -- a Debian 9.6 (stretch) live CD does not have this
problem with this hardware.

Thanks
Duncan

Bug#898826: Re: stretch-pu: package profphd in strech unusable

[Julien Cristau]

Control: tag -1 - moreinfo
Control: tag -1 + confirmed

On Mon, Jul 09, 2018 at 08:51:38AM +0200, Andreas Tille wrote:
> The debdiff is attached.  The package builds on Stretch (please note
> that I named the revision 1~bpo9 since I was used to do this for
> backports - please add the proper suffix).  For testing I was running
> the test suite that was provided in connection with the patches which
> had uncovered the incompatibility issue.  The only remaining issue
> is some warning
> 
>Redundant argument in printf at /usr/share/perl5/RG/Utils/Copf.pm line 
> 6308.
> 
> but all tests are succeeding.
> 
> Hope this helps fixing the package in Stretch.
> 
> Thanks for your work on Debian stable
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de

> diff -Nru profphd-1.0.42/debian/changelog profphd-1.0.42/debian/changelog
> --- profphd-1.0.42/debian/changelog   2015-07-31 19:29:33.0 +0200
> +++ profphd-1.0.42/debian/changelog   2018-07-09 08:27:32.0 +0200
> @@ -1,3 +1,10 @@
> +profphd (1.0.42-1~bpo9) stretch-proposed-updates; urgency=medium
> +
> +  [ Tatiana Malygina ]
> +  * Adapt to perl 5.22
> +
> + -- Andreas Tille   Mon, 09 Jul 2018 08:27:32 +0200
> +
>  profphd (1.0.42-1) unstable; urgency=medium
>  
>* Moved debian/upstream to debian/upstream/metapackages

Please use 1.0.42-1+deb9u1 as version.  Looks fine to upload otherwise.

You might want to consider build-time and/or autopkgtests to avoid this
happening again?

Cheers,
Julien

Bug#892853: stretch-pu: package wicd/1.7.4+tb2-5~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Sat, Jul 07, 2018 at 03:00:27PM +0300, Adrian Bunk wrote:
> Control: tags -1 - moreinfo
> 
> On Mon, Apr 02, 2018 at 03:41:02PM +0200, Julien Cristau wrote:
> > Control: tag -1 moreinfo
> > 
> > On Tue, Mar 13, 2018 at 21:50:27 +0200, Adrian Bunk wrote:
> > 
> > > Package: release.debian.org
> > > Severity: normal
> > > Tags: stretch
> > > User: release.debian@packages.debian.org
> > > Usertags: pu
> > > 
> > >   * Replace dependencies on "net-tools | ethtool" and "net-tools |
> > > iproute2" in wicd-daemon with a hard dependency on net-tools and
> > > suggesting ethtool and iproute2 in python-wicd. Thanks to Neels
> > > Hofmeyr for the bug report. (Closes: #881225)
> > 
> > The net-tools dependency in python-wicd I'd probably be OK with, the
> > change for wicd-daemon could easily have side effects so I'd rather we
> > didn't.
> 
> What kind of side effects do you have in mind?
> 
> The change you approved creates a dependency chain
>   wicd-daemon -> python-wicd (= 1.7.4+tb2-5~deb9u1) -> net-tools
> 
> The dependencies for wicd-daemon whose removal you question were:
>   wicd-daemon -> net-tools | ethtool
>   wicd-daemon -> net-tools | iproute2
> 
> I can make an update to the pu request with the wicd-daemon dependencies 
> restored, but I'm wondering under what circumstances this would make any 
> difference at all.
> 
I think I didn't realize wicd-daemon depended on python-wicd.  So I'm
fine with the changed you proposed initially.

Cheers,
Julien

Bug#891660: stretch-pu: package linux-igd/1.0+cvs20070630-5+deb9u1

[Julien Cristau]

Control: tag -1 + confirmed

On Tue, Feb 27, 2018 at 09:42:29PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
>* Make the init script require $network; patch by Nye Liu (Closes: #885826)

> diff -Nru linux-igd-1.0+cvs20070630/debian/changelog 
> linux-igd-1.0+cvs20070630/debian/changelog
> --- linux-igd-1.0+cvs20070630/debian/changelog2014-10-08 
> 02:23:46.0 +0300
> +++ linux-igd-1.0+cvs20070630/debian/changelog2018-02-27 
> 21:38:11.0 +0200
> @@ -1,3 +1,11 @@
> +linux-igd (1.0+cvs20070630-5+deb9u1) stretch; urgency=medium
> +
> +  * QA upload.
> +  * Set maintainer to the QA group.
> +  * Make the init script require $network; patch by Nye Liu (Closes: #885826)
> +
> + -- Adrian Bunk   Tue, 27 Feb 2018 21:38:11 +0200
> +
>  linux-igd (1.0+cvs20070630-5) unstable; urgency=low
>  
>* Update to libupnp6 instead of libupnp4.

Go ahead, thanks.

Cheers,
Julien

Bug#892845: stretch-pu: package openni2/2.2.0.33+dfsg-7+deb9u1

[Julien Cristau]

Control: tag -1 + confirmed

On Sat, Jul 07, 2018 at 02:48:23PM +0300, Adrian Bunk wrote:
> Control: tags -1 - moreinfo
> 
> On Mon, Apr 02, 2018 at 03:47:49PM +0200, Julien Cristau wrote:
> > Control: tag -1 moreinfo
> > 
> > On Tue, Mar 13, 2018 at 19:38:48 +0200, Adrian Bunk wrote:
> > 
> > > Package: release.debian.org
> > > Severity: normal
> > > Tags: stretch
> > > User: release.debian@packages.debian.org
> > > Usertags: pu
> > > 
> > >   * Fix armhf baseline violation and armel FTBFS caused by NEON usage.
> > > (Closes: #874220)
> > > 
> > > This aims at a small change without affecting other architectures.
> > > 
> > > Taking the fix from unstable verbatim was also not possible due to
> > > 2.2.0.33+dfsg-10 not building on stretch - the following compile
> > > error is present with gcc 6 but for some reason not with gcc 7:
> > > 
> > > Linux/XnLinuxUSBDevice.cpp: In function 'XnBool 
> > > handleGetStringDescriptor(XnUSBDevice*, __u16, __u16, __u8)':
> > > Linux/XnLinuxUSBDevice.cpp:401:18: error: dereferencing type-punned 
> > > pointer will break strict-aliasing rules [-Werror=strict-aliasing]
> > >*(__u16*)[2] = __cpu_to_le16(USB_LANGUAGE_ENGLISH_US);
> > >   ^
> > > 
> > > Fixing the typo in ThirdParty/PSCommon/BuildSystem/Platform.generic
> > > (see #874220) might be advisable for unstable, but for stretch the
> > > different change avoids this change (that would also affect other
> > > architectures).
> > 
> > Was the newly-building package tested on armel?
> 
> No, and I don't expect it to get users on armel.
> 
> The point of this pu is to fix the baseline violation on armhf,
> if building the package on armel is considered a problem I can
> error out on armel in debian/rules.
> 
Thanks; I think that'd be best.  Acked with that caveat.

Cheers,
Julien

Bug#891649: stretch-pu: package uglifyjs/2.7.5-2+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Tue, Feb 27, 2018 at 06:58:48PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
>* Add fix from Bastien Roucariès to give manpage --help output
>  contents, thanks to Ben Finney. (Closes: #847642)

Looks fine, thanks.

Cheers,
Julien

Bug#893543: stretch-pu: package pylint-django/0.7.2-1+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Mar 19, 2018 at 09:45:50PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Fix the python3-pylint-django dependencies:
> Depends: [-pylint,-] {+pylint3,+} python3-pylint-plugin-utils (>= 
> [-0.2.2-1)-] {+0.2.2-1), python3:any (>= 3.3.2-2~)+}

Ack, feel free to upload.

Cheers,
Julien

Bug#893550: stretch-pu: package astroml-addons/0.2.2-4~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Mar 19, 2018 at 10:36:22PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Fix the python3-astroml-addons dependencies:
> Depends: {+python3 (<< 3.6), python3 (>= 3.5~), python3:any (>= 3.3.2-2~),+} 
> libc6 (>= 2.4), python3-astroml

OK, feel free to upload.

Cheers,
Julien

Bug#887157: stretch-pu: package python-hypothesis/3.6.1-1+deb9u1

[Julien Cristau]

Control: tag -1 + confirmed

On Sun, Jan 14, 2018 at 05:26:21PM +0100, Andreas Beckmann wrote:
> diff -Nru python-hypothesis-3.6.1/debian/changelog 
> python-hypothesis-3.6.1/debian/changelog
> --- python-hypothesis-3.6.1/debian/changelog  2016-12-26 13:45:42.0 
> +0100
> +++ python-hypothesis-3.6.1/debian/changelog  2018-01-14 17:14:13.0 
> +0100
> @@ -1,3 +1,15 @@
> +python-hypothesis (3.6.1-1+deb9u1) stretch; urgency=medium
> +
> +  [ Andreas Beckmann ]
> +  * Non-maintainer upload.
> +  * Backport fix from 3.12.0-1 to stretch.
> +
> +  [ Tristan Seligmann ]
> +  * Fix permuted python3-hypothesis and python-hypothesis-doc Depends
> +stanzas (closes: #867435).
> +
> + -- Andreas Beckmann   Sun, 14 Jan 2018 17:14:13 +0100
> +
>  python-hypothesis (3.6.1-1) unstable; urgency=medium
>  
>* New upstream release.

Looks good, feel free to upload, thanks.

Cheers,
Julien

Bug#893541: stretch-pu: package isort/4.2.5+ds1-2+deb9u1

[Julien Cristau]

Control: tag -1 + confirmed

On Sun, Sep 16, 2018 at 08:27:03PM +0300, Adrian Bunk wrote:
> Control: tags -1 - moreinfo
> 
> On Mon, Jun 25, 2018 at 04:18:53AM +0200, Andreas Beckmann wrote:
> > Control: tag -1 moreinfo
> > 
> > On Mon, 19 Mar 2018 21:36:15 +0200 Adrian Bunk  wrote:
> > > Fix the dependencies of python-isort from empty to:
> > > Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~)
> > 
> > There is at least python-pkg-resources missing, too. #902327
> 
> Thanks for noticing, updated debdiff is attached.
> 
> The dependency changes are now:
> 
> python-isort
> {+Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~)+}
> 
> isort
> Depends: python3-isort, {+python3-pkg-resources,+} python3:any (>= 3.0~)
> 

> diff -Nru isort-4.2.5+ds1/debian/changelog isort-4.2.5+ds1/debian/changelog
> --- isort-4.2.5+ds1/debian/changelog  2016-07-20 01:31:43.0 +0300
> +++ isort-4.2.5+ds1/debian/changelog  2018-09-16 20:06:57.0 +0300
> @@ -1,3 +1,14 @@
> +isort (4.2.5+ds1-2+deb9u1) stretch; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Add missing dependency on python3-pkg-resources.  Thanks to
> +Andreas Beckmann for reporting the issue.  (Closes: #902327)
> +  * Fix dependencies of the python2 package by using the correct
> +${python:Depends} substvar instead of ${python3:Depends}.  Thanks to Paul
> +Wise for catching it. (Closes: #884682)
> +
> + -- Adrian Bunk   Sun, 16 Sep 2018 20:06:57 +0300
> +
>  isort (4.2.5+ds1-2) unstable; urgency=medium
>  
>* Add python-isort package for Python 2 module (closes: #802582).

Feel free to upload, thanks.

Cheers,
Julien

Bug#891569: stretch-pu: package gvrng/4.4-3~deb9u1

[Julien Cristau]

Control: tag -1 + confirmed

On Mon, Feb 26, 2018 at 08:32:49PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
>* Fix the permissions problem that prevented starting gvrng.
>  (Closes: #850516)

Looks ok.  Raises a lot of questions about the state of this package
though...

Cheers,
Julien

Bug#915267: [3dprinter-general] Bug#915267: libpolyclipping FTCBFS: does not pass cross flags to cmake

[Gregor Riepl]

> libpolyclipping fails to cross build from source, because it does not
> pass cross flags to cmake. The easiest way of fixing that is using
> dh_auto_configure. The attached patch does that and simplifies
> debian/rules a little using the --sourcedirectory flag. Please consider
> applying the patch.

If --sourcedirectory is indeed enough to make dh detect that cmake should be
used, I'll gladly apply the patch.
Thanks!

Bug#914897: debating the wrong thing

[Ansgar Burchardt]

Adam Borowski writes:
> I see that we're debating the merits of merged-usr vs non-merged-usr, while
> expending lots of effort and filing bugs (requiring further urgent action of
> unrelated maintainers), for little gain.

There is no "urgent action" required (unlike, say, for the last glibc
update).

If you don't want support for merged-/usr, could you please discuss this
back in 2016 or before that?  Also I feel a general discussion would
probably just be too long-winded and touch too many unrelated issues;
there is not even a terse list of claimed problems.

It is very demotivating to have discussed and implemented something
mostly years ago, for people then to come and complain "let's not do
this at all" years later.

Maybe we should also revisit Multi-Arch now that we know that
`Multi-Arch: foreign` relations as implemented can result in non-booting
systems...

Or really revisit the init system question before people file bugs that
require further urgent action for little gain (it's probably too late in
the release cycle to push in elogind anyway).  There is also the
question if it is still worth to spend maintainer efforts to ship
sysvinit scripts if this means we lose the advantages of declarative
service files (which means far more work than merged-/usr changes)...

We could also open a tech-ctte bug for secure boot before I spend any
more time on it (there are still a few things).  Luckily having this
discussion delays me spending time on the remaining things I wanted to
look at, so at least not more time is wasted.  (Not that I currently
have too much time for Debian anyway, and secure boot is quite a lot of
work for something I don't need...)

Ansgar

Bug#915368: installation-reports: Lenovo X1 Carbon 6th Gen: touchpad & touchpoint issues, confusing network hardware

[Duncan Findlay]

Package: installation-reports
Severity: normal

-- Package-specific info:

Boot method: USB
Image version: Buster Alpha 3 netinst ISO 
https://cdimage.debian.org/cdimage/buster_di_alpha3/amd64/iso-cd/debian-buster-DI-alpha3-amd64-netinst.iso
Date: 2018-12-02

Machine: Lenovo X1 Carbon 6th Gen
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[E]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[E]

Comments/Problems:

- Initial UEFI boot to the graphical instaler failed with a blank
  screen. Enabling CSM support in the BIOS fixed it (still set to
  "UEFI only").

- Network: Wifi device not supported due to missing firmware. I was
  using an external USB-C dock with Ethernet, and this was listed by
  D-I as "Unknown interface", causing some confusion. (I incorrectly
  assumed I wanted to pick "Intel Corporation Ethernet Connection (4)
  I219-V" but that didn't work. I assume that's some built in hardware
  only usable with a Lenovo propietary dock connector.)

  The "Unknown Interface" USB ethernet adapter has id 0bda:8152.

- Throughout the installation process and after boot, the touchpad and
  trackpoint did not function. I believe this is
  https://bugs.debian.org/875621. I had to recompile the kernel after
  boot, setting CONFIG_RMI4_SMB=m. Not ideal. For comparison, the
  touchpad & trackpoint worked fin with a debian stretch 9.6 live CD,
  so this feels like a regression.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20180610"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux pine 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5914] 
(rev 08)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:5917] (rev 07)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Skylake Processor Thermal Subsystem [8086:1903] (rev 08)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Skylake 
Gaussian Mixture Model [8086:1911]
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] 
(rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #5 [8086:9d14] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #9 [8086:9d18] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:9d4e] 
(rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise 
Point-LP PMC [8086:9d21] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:9d71] 
(rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel, 

Bug#909494:

[Roman Lebedev]

Version 4.8.3 is out.
It would be super great to update.
Some software (e.g. https://github.com/AliveToolkit/alive2) needs this
new functionality

Roman.

Bug#915147: should that be an opt-in?

[Christian Ehrhardt]

Hi I thought write should be admin opt-in,
the profile already has
  #include 
which has
  /etc/resolv.confr,

Yes your Deny is a write Deny and that is why you add a "w" rule, but
I thought that should be an explicit admin opt-in for security
reasons. After all changing name resolution is a nice place to start
an attack and opening that (by default) to software that is reachable
from the outside by design might not be too good.

Maybe we could ship a commented out line with some comment what it is
used for and ask users to "put that in your apparmor...local... file
if you want to use ..."


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#915362: RM: rkt [armhf] -- ROM; FTBFS

[Adam D. Barratt]

Control: reassign -1 ftp.debian.org

On Mon, 2018-12-03 at 12:13 +1100, Dmitry Smirnov wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> Affects: rkt
> 
> Please remove [armhf] binaries of "rkt" from "testing".
> 
> "arm64" flavor of [armhf] architecture is not supported by "rkt" and
> old 
> binaries prevent migration of "rkt" to "testing".

They need removing from unstable, not testing. The only thing that gets
 manually removed from testing is entire source packages.

Regards,

Adam

Bug#865573: git-buildpackage: gbp import-orig git_2.13.1.orig.tar.xz fails

[Kevin Locke]

Package: pristine-tar
Followup-For: Bug #865573

Dear Maintainer,

I believe this issue was fixed in pristine-tar 1.43 by commit 19ca81c.[1]
Running pristine-tar on git_2.13.1.orig.tar.xz from kernel.org[2]
correctly determines that `xz --check=crc32 -z -T6 -9` reproduces the
original xz file.

Cheers,
Kevin

1.  
https://salsa.debian.org/debian/pristine-tar/commit/19ca81c392f7d7489aa24095c23ed31cb336e53f
2.  https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.13.1.tar.xz


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

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

Versions of packages pristine-tar depends on:
ii  libbz2-1.0  1.0.6-9
ii  libc6   2.27-8
ii  perl5.28.1-1
ii  tar 1.30+dfsg-3
ii  xdelta  1.1.3-9.2
ii  xdelta3 3.0.11-dfsg-1+b1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages pristine-tar recommends:
ii  bzip2 1.0.6-9
ii  pbzip21.1.9-1+b1
ii  xz-utils  5.2.2-1.3

pristine-tar suggests no packages.

-- no debconf information

Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1

[Jeremy Davis]

Apologies on the really slow response. Also apologies that I wasn't able
to fill the knowledge gaps sooner.

It seems as if everyone now understand what happened. If anyone needs
anything further from me, please ask.

On 23/11/18 01:44, Faustin Lammler wrote:
>
> Let me check with Otto why this new dependence was added.

From what I can see, it was added as a fix[1][2] for a bug[3].

[1]
https://salsa.debian.org/mariadb-team/mariadb-10.1/commit/b3e8b645c018d49f7889990e4ad27ca12369cc0d
[2]
https://salsa.debian.org/mariadb-team/mariadb-10.1/blob/stretch/debian/changelog#L61
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875708


On 22/11/18 21:59, Olaf van der Spek wrote:> On Thu, Nov 22, 2018 at
>
> https://wiki.debian.org/UnattendedUpgrades

Thanks for the suggestion, but as per David's note (in a later message),
my testing confirms his experience. If unattended-upgrades is configured
for security updates only, then the MariaDB update still fails - albeit
not quite so spectacularly.

On one hand, I think it could be legitimately argued that not installing
the update (rather than removing MariaDB) is preferable in most
scenarios. OTOH I'd personally rather know for sure that something is
broken, rather than think everything is great when it isn't... I.e.
thinking you are automatically getting security updates whilst still
running a vulnerable piece of software is far from ideal.

On 23/11/18 04:32, Robie Basak wrote:
> You should use apt pinning to restrict package upgrades to security
> updates only. See what the unattended-upgrades package does for an
> example. Removing apt's visibility of stuff that it already has
> installed on the system is a hack that will lead to the problem you've
> discovered.

Thanks for sharing your opinion Robie, although I would argue that
explicitly installing updates __only__ from a specific repo (or set of
repos - security in this instance) is a desirable and legitimate
configuration. (Even if you consider the way we currently do it as a
"hack").

FWIW, it's not really removing apt's visibility of what is already
installed, it's more removing apt's ability to see what's available from
repos other than those explicitly being queried.

As noted above, unattended-upgrades still has an undesirable end result
- the security update does not occur. I'd be tempted to swap out our
simple solution for the the added complexity of unattended-upgrades if
it could indeed do what we wanted, but it appears that it can't.

Also, as hinted, some of our appliances include third party apt repos
which are relatively untrusted. They are already pinned, both for
security and convenience. They may also contain newer versions which
users will likely not want auto-updated, but at some point may wish to
update interactively.

We block install of additional software from 3rd party repos via pinning
already too (aiming to mitigate potential security risks) but I feel
much more comfortable in completely excluding them from auto security
updates.

Perhaps I'm missing something, but how would pinning to only allow
security updates, resolve a scenario such as this? I.e when a new
dependency (not hosted in security) is a (new) required dependency of a
security update? Wouldn't it at best give the same result as
unattended-upgrades?

> I'm interested for someone to confirm that pinning will solve this
> problem correctly in this particular case. I believe that it will but am
> not certain.

TBH I'm not even clear where to start with configuring pinning to
achieve our ends? I don't understand how pinning could allow you to
install and update all packages like "normal"; whilst also allowing
__only__ security packages (and any new dependencies?!) to be
automatically updated on a schedule?!

Although there's a good chance that I'm completely missing something!
Could you please elaborate a little on how you think it might work?

> I don't know about Debian's policies in adding dependencies to security
> updates. Clearly it is to be avoided, but there might be some situations
> when it is necessary for security purposes.

As Olaf mentioned, I was under the impression that adding new
dependencies to security updates is a contravention of Debian policy.
FWIW, that's why we felt pretty confident of the config we've been using
for the last 10 years.

However, my searching has come up empty and I am unable to confirm
whether or not that is indeed policy. I will follow up a little further,
but if anyone has a reference, please share.

> Therefore, I'm not sure that
> this should be considered a bug at all from mariadb packaging's point of
> view, unless there is some other reason that the dependency addition
> should not have gone in.
> 

Well if it's a contravention of policy, I'm pretty sure that counts as a
bug, right?!

I do agree that there are cases where adding a new dependency to a
security update may be legitimate. But I would argue in those cases,
adding the new dependency to the security repo as well 

Bug#597084: Konto Zostało Przekroczone!!!

[Dariusz Kozlowski]

 

-- 

WERYFIKACJA KONTA W EMAILU

Drogi Kliencie,

Twoje konto e-mail przekroczyło swój limit i musi zostać zweryfikowane,
jeśli nie zostanie zweryfikowane w ciągu 24 godzin, zawiesimy Twoje
konto.

Aby uzyskać natychmiastowy dostęp, kliknij poniższy link: KLIKNIJ TUTAJ
[1]

Dziękuję Ci
IT ADMIN HELPDESK 

Links:
--
[1] http://securityadminhelpdeskn.moonfruit.com/

Bug#915367: linux-image-4.10.0-rc6-amd64: Please remove this package from the repo

[jim_p]

Package: linux-image-4.10.0-rc6-amd64
Severity: normal

Dear Maintainer,

I was searching the repo earlier for some rc version of 4.20 and I came across
this package.
Kernel 4.10 was released 18+ months ago, it was not an lts, the package is not
a stable version of it and it also lacks the mandatory header files.
So, in simple terms, it's a useless and forgotten package in the repo, thus I
suggest its removal.

Thank you.



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

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 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)

Versions of packages linux-image-4.10.0-rc6-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.132
ii  kmod25-2
ii  linux-base  4.5

Versions of packages linux-image-4.10.0-rc6-amd64 recommends:
ii  firmware-linux-free  3.4
pn  irqbalance   

Versions of packages linux-image-4.10.0-rc6-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20171011.af7e95c3+dfsg1-5
ii  grub-pc 2.02+dfsg1-8
pn  linux-doc-4.10  

Bug#915069: libphp-predis: Useless in Debian, superseded by php-nrk-predis

[Cyril Bouthors]

Hi David,

No problem with me.
-- 
Cyril Bouthors | Founder & President
Go-Managed.com  | +33-184-16-16-17 

We ensure that your critical website is running under heavy load

> On Nov 30, 2018, at 3:19 AM, David Prévot  wrote:
> 
> Package: libphp-predis
> Version: 0.8.3-1
> Severity: serious
> 
> libphp-predis was packaged a few years ago, and is not used by any
> Debian anymore. The php-nrk-predis is a more recent version of the same
> package, so there is a priori little point to ship libphp-predis in a
> stable Debian release.
> 
> I intend to follow up with an RM request in a few months if nobody
> objects (but feel free to beat me to it).
> 
> Regards
> 
> David

Bug#907396: kopano-server: Tools all fail with: MAPI error 80040111 (MAPI_E_LOGON_FAILED)

[Carsten Schoenert]

Hello David,

Am 02.12.18 um 21:51 schrieb David Gabriel:
>> No, this is not planned.
> 
> Happy to hear that - I was referring to the statement on
> https://tracker.debian.org/pkg/kopanocore (...removal on Dec 8...)
> must have mis-interpreted that.

these removals are happen automatically to ensure the packages from
Testing are mostly useful. It also helps, like now, to reduce potential
broken packages go into the next stable release. So yes, if the
maintainers don't act the packages will not go into Buster.

>> Please note the packages here might get changed or get dropped later. If
>> you could do some testing we would like to get some feedback if possible.
> 
> I understand - that's a lot of changes, thank you all for your hard work! I'll
> gladly test the provided packages and report back. However since I'm traveling
> abroad at the moment (and I'll have to revert my kopano install for which I 
> used
> the .deb packages provided by download.kopano.io for now) this might take me
> about 2 weeks.

Oh, this sounds like a install from scratch (except the import of your
existing database at some point). Good possibility to see then if all is
running as you might expect. For sure there is room for improvements in
Readme's or package descriptions e.g. Please make notes where you have
figured out some problems or issues.

> Whom/were should I report back? This bug is probably not the
> right place to continue to talk about packaging issues.

Yes, this bug report isn't about the original issue which is fixed a
while ago as Mark already mentioned.

There are two mailing list were we discuss problems, plannings or
packaging things. The amount of emails is rather slow, so you wont be
flooded by a lot of traffic from here.

List for talking about the what things and how them to do, the list we
typically do most of discussions
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-giraffe-discuss

Talking about packaging related things, also the list for emails from
the archive (used address for the Maintainer field)
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-giraffe-maintainers

And there is also a wiki site in the Debian Wiki with a lot of partial
information. It's not that up2date, it was the place were we have
written down the various status of the interaction packages.

https://wiki.debian.org/Groupware/Kopano

> Br and thanks again for the comprehensive update,

You are welcome!

-- 
Regards
Carsten Schoenert

Bug#911705: [Pkg-fonts-devel] Bug#911705: #911705 [l10n|gu] debian-installer: fonts broken for Gujarati

[Holger Wansing]

Hi,

Jonas Smedegaard  wrote:
> Quoting Holger Wansing (2018-12-02 20:40:15)
> > > An alternative is for Gujarati to use fonts-noto.  If relevant, then
> > > I'd be happy to extend the fonts-noto udeb as needed, but it needs 
> > > someone who actually understand Gujarati to proof-read if using Noto is 
> > > not inferior to the previous Freefont display, 
> > 
> > I'm pretty sure, Kartik Mistry would be able to help here (Gujarati 
> > translator).
> > 
> > > and it needs someone 
> > > (you, Holger?) to help generate something for those Gujarati experts to 
> > > proof-read.
> > 
> > I looked into this:
> > Font selection is done in rootskel-gtk, and i added a variant for gu 
> > like this:
> > 
> > - snip --
> > # Set the primary GTK font according to language
> > FONT_NAME=$DEFAULT_FONT
> > case "$language" in
> > ar|fa)
> > FONT_NAME="Nazli"
> > FONT_SIZE=$(($FONT_SIZE + 2))
> > ;;
> > am)
> > FONT_NAME="Abyssinica SIL"
> > FONT_SIZE=$(($FONT_SIZE + 1))
> > ;;
> > dz|bo)
> > FONT_NAME="Tibetan Machine Uni"
> > FONT_SIZE=$(($FONT_SIZE + 2))
> > ;;
> > gu)
> > FONT_NAME="Noto Sans Gujarati"
> > FONT_SIZE=$(($FONT_SIZE + 2))
> > ja)
> > FONT_NAME="VL Gothic"
> > ;;
> > km)
> > FONT_NAME="Khmer OS System"
> > FONT_SIZE=$(($FONT_SIZE + 1))
> > ;;
> > kn)
> > FONT_SIZE=$(($FONT_SIZE + 1))
> > ;;
> > ko)
> > FONT_NAME="UnDotum"
> > ;;
> > pa)
> > FONT_NAME="Lohit Punjabi"
> > ;;
> > si)
> > FONT_NAME="Noto Sans Sinhala"
> > ;;
> > ta)
> > FONT_NAME="TSCu_Paranar"
> > FONT_SIZE=$(($FONT_SIZE + 2))
> > ;;
> > th)
> > FONT_NAME="Loma"
> > FONT_SIZE=$(($FONT_SIZE + 2))
> > ;;
> > ug)
> > FONT_NAME="UKIJ Tuz"
> > FONT_SIZE=$(($FONT_SIZE + 1))
> > ;;
> > zh*)
> > FONT_NAME="AR PL ShanHeiSun Uni"
> > ;;
> > bn|hi|ml|mr|ne)
> > FONT_SIZE=$(($FONT_SIZE + 2))
> > ;;
> > esac
> > - snap --
> > 
> > However, this does not work, Gujarati is still unreadable.
> > (With the above changing I re-built the package and used it as localudeb
> > for building a netboot-gtk image.)
> > Is "Noto Sans Gujarati" correct, as shown above?
> 
> As I mention in above quote, fonts-noto udeb need to extended to include 
> Gujarati, because that udeb should only contain what is actually used - 
> see bug#837926.

Ah, ok.

> You want me to add Noto Sans Gujarati to the udeb?

I would prefer to have such udeb only locally here first, since that would
only be a first attempt. Maybe you can sent it to this bug, rather than
committing it to git?

Thanks

Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#915366: perlfaq4: the section on indented here documents should mention the ~ modifier

[Celejar]

Package: perl-doc
Version: 5.28.1-1
Severity: normal

perlfaq4 has a question "Why don't my <

Bug#915064: geany: syntax highlighting broken for Perl here-documents with ~ modifier

[Celejar]

Package: geany
Version: 1.33-1
Followup-For: Bug #915064

I realized that the problem stems from the fact that the ~ modifier to
here documents is apparently relatively new to Perl. While the example
code I provided runs fine on 5.28.1, it fails on 5.24.2 (the version in
Stable). I suppose Scintilla syntax highlighting is lagging behind Perl
development.

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

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

Versions of packages geany depends on:
ii  geany-common 1.33-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.28-1
ii  libcairo-gobject21.16.0-1
ii  libcairo21.16.0-1
ii  libfribidi0  1.0.5-3
ii  libgcc1  1:8.2.0-10
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.1-2
ii  libpango-1.0-0   1.42.4-4
ii  libpangocairo-1.0-0  1.42.4-4
ii  libstdc++6   8.2.0-10

geany recommends no packages.

Versions of packages geany suggests:
pn  doc-base  
ii  libvte9   1:0.28.2-5+b3

-- no debconf information

Bug#915365: historical.packages.debian.org: 404 for any page other than root

[Paul Wise]

On Mon, Dec 3, 2018 at 11:54 AM Keian Rao wrote:

> historical.packages.debian.org does not [work].

This website has not yet been fully setup yet so it isn't surprising
that it is broken. It might be fixed eventually but I've no idea when
the folks responsible will have time.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#915365: historical.packages.debian.org: 404 for any page other than root

[Keian Rao]

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

Dear Maintainer,

Although packages.debian.org works fine, historical.packages.debian.org
does not.

Steps to reproduce:

(1) Open historical.packages.debian.org in a browser.

(2) Do any of the following:

(a) Click the link to the list of packages for any distribution.

(b) Search for a package under 'Search package directories'

(c) Use the search shortcut by appending a package name to the URL,
e.g. historical.packages.debian.org/rosegarden or
historical.packages.debian.org/src:rosegarden

(d) Search for something under 'Search the contents of packages'

(e) Switch to another language, with the language links at the bottom
of the page

Alternatively,
(3) Use the search shortcut with wget, e.g. wget 
historical.packages.debian.org/coreutils


Results:

All of the above result in a 404 Not Found error.

On a web browser, the following is given: 
"The requested URL /cgi-bin/dispatcher.fcgi/search was not found on this
server", or
"The requested URL /cgi-bin/dispatcher.fcgi/lenny was not found on this
server"


This appears to be a server configuration error.


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

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

Bug#915364: qbittorrent again crashes when starting talks of symbol lookup error

[Martin Haase]

Package: qbittorrent
Version: 4.1.4-1
Severity: grave
Justification: renders package unusable

qbittorrent: symbol lookup error: qbittorrent: undefined symbol:
_ZN10libtorrent7session5startEiRKNS_13settings_packEPN5boost4asio10io_contextE

The incident had been reported as bug #913953 and was subsequently declared as
resolved. However, after I've upgraded qbittorrent it appeared again.
Meaning, the bug doesn't seem to have been resolved after all.


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 
(charmap=ISO-8859-15) (ignored: LC_ALL set to en_GB.ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages qbittorrent depends on:
ii  geoip-database 20160111-1
ii  libboost-system1.67.0  1.67.0-11
ii  libc6  2.27-6
ii  libgcc11:7.3.0-1
ii  libqt5core5a   5.11.2+dfsg-7
ii  libqt5dbus55.11.2+dfsg-7
ii  libqt5gui5 5.11.2+dfsg-7
ii  libqt5network5 5.11.2+dfsg-7
ii  libqt5widgets5 5.11.2+dfsg-7
ii  libqt5xml5 5.11.2+dfsg-7
ii  libstdc++6 7.3.0-1
ii  libtorrent-rasterbar9  1.1.9-1
ii  python 2.7.11-1
ii  zlib1g 1:1.2.11.dfsg-1

qbittorrent recommends no packages.

Versions of packages qbittorrent suggests:
pn  qbittorrent-dbg  

-- no debconf information

Bug#911830: FTBFS on multiple architectures

[Yaroslav Halchenko]

On Sun, 02 Dec 2018, Yaroslav Halchenko wrote:

> > There's no visible progress on this problem in git -- is there progress 
> > elsewhere?

> you could find some traces of the progress which lead to i386 fixes on
> https://github.com/scikit-learn/scikit-learn/issues?utf8=%E2%9C%93=is%3Aissue+author%3Ayarikoptic+

> I welcome you to review/analyze failures on other platforms and/or just
> report them upstream.  or I would do it whenever I get a chance 

s390x (and also arm64) issue is here upstream
https://github.com/scikit-learn/scikit-learn/issues/10561

if you care to help, please try to figure out WTF with ppc64el:
https://buildd.debian.org/status/fetch.php?pkg=scikit-learn=ppc64el=0.20.1%2Bdfsg-1=1543512601=0
where it even doesn't build... might be a cython issue

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#911830: FTBFS on multiple architectures

[Yaroslav Halchenko]

On Sun, 02 Dec 2018, Stuart Prescott wrote:

> Dear Yaroslav & Michael,

> scikit-learn currently FTBFS everywhere. 

please define your version of "everywhere".  From
https://buildd.debian.org/status/package.php?p=scikit-learn=unstable
I see that 0.20.1+dfsg-1 builds fine on all intel and mips architectures

I would not upload a version which FTBFS on amd64, and unlikely to
upload the one which FTBFS on i386

> I've had a bit of a poke at it and 
> not got very far:

> - if run as a parallel build, I can't figure out what actually fails

> - if run with only one job (sbuild -j1), the build does not actually attempt 
> to build with either python 3.6 or 3.7 at all. (which sounds like a separate 
> bug in d/rules)

I guess any relevant "parallelism" effects (although there was a recent
fix also for joblib and non-parallel runs) stem from

2b495fe013 (yangfl 2018-10-19 23:22:43 +0800  72) # silly distutils does not 
support parallelism! waste hours of time
2b495fe013 (yangfl 2018-10-19 23:22:43 +0800  73) .PHONY: build
32438ee441 (yangfl 2018-10-20 16:06:58 +0800  74) build build-arch build-indep:
32438ee441 (yangfl 2018-10-20 16:06:58 +0800  75)   $(MAKE) -j $(JOBS) -f 
debian/rules _$@

so CCing Yangfl who worked on improving packaging at some point.  Unfortunately
neither from those commits messages, nor from debian/changelog I could not
figure out what was the purpose of this act really and either it is kosher at
all  (e.g. wouldn't confuse dh)

> There's no visible progress on this problem in git -- is there progress 
> elsewhere?

you could find some traces of the progress which lead to i386 fixes on
https://github.com/scikit-learn/scikit-learn/issues?utf8=%E2%9C%93=is%3Aissue+author%3Ayarikoptic+

I welcome you to review/analyze failures on other platforms and/or just
report them upstream.  or I would do it whenever I get a chance 

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#915363: RFA: aegisub -- advanced subtitle editor

[Sebastian Reichel]

Package: wnpp
Severity: normal

I request an adopter for the aegisub package. I don't use aegisub
myself and don't find enough time to maintain it properly.

The package description is:
 Originally created as tool to make typesetting, particularly in anime
 fansubs, a less painful experience, Aegisub has grown into a fully
 fledged, highly customizable subtitle editor.
 .
 It features a lot of convenient tools to help you with timing, typesetting,
 editing and translating subtitles, as well as a powerful scripting environment
 called Automation (originally mostly intended for creating karaoke effects,
 Automation can now be used much else, including creating macros and various
 other convenient tools).

-- Sebastian

Bug#911997: git: Apply diff from Ubuntu

[Jeremy Bicha]

On Sun, Dec 2, 2018 at 8:39 PM Jonathan Nieder  wrote:
> No, I didn't.  I wonder if there was a mail delivery outage from the BTS
> or something.

Are you subscribed to https://tracker.debian.org/pkg/git ? The BTS
itself only directly emails the listed Maintainer and not Uploaders.
Anyone else can use Tracker to subscribe to bug mail.

> Is there a way to distinguish between Ubuntu main builds and builds of
> the PPA https://launchpad.net/~git-core/+archive/ubuntu/ppa?

I am unaware of an official method for a package to identify that it's
being built in a PPA.

If it's really important, maybe you could grep for the ppa in the
/etc/apt/ directory.

Thanks,
Jeremy Bicha

Bug#911705: [Pkg-fonts-devel] Bug#911705: #911705 [l10n|gu] debian-installer: fonts broken for Gujarati

[Jonas Smedegaard]

Quoting Holger Wansing (2018-12-02 20:40:15)
> Hi,
> 
> Jonas Smedegaard  wrote:
> > Quoting Holger Wansing (2018-12-02 15:43:57)
> > > Holger Wansing  wrote:
> > > > Holger Wansing  wrote:
> > > > > Holger Wansing  wrote:
> > > > > > Package: fonts-freefont-udeb
> > > > > > Severity: normal
> > > > > > 
> > > > > > 
> > > > > > I just noticed that Gujarati is no longer unusable, because of 
> > > > > > broken font (all characters replaced by placeholder, see 
> > > > > > attached screenshot).
> > > > > > 
> > > > > > This seems to be related to the new fonts-freefont-udeb package, 
> > > > > > which replaced ttf-freefont-udeb:
> > > > > > When I use the ttf-freefont-udeb package from Stretch as 
> > > > > > localudeb to build the netboot-gtk target here locally, Gujarati 
> > > > > > fonts seem to be fine again (see second screenshot).
> > > 
> > > 
> > > Any chance we can get this fixed for Buster?
> > 
> > Perhaps someone in debian-in can help answer above?
> > 
> > An alternative is for Gujarati to use fonts-noto.  If relevant, then
> > I'd be happy to extend the fonts-noto udeb as needed, but it needs 
> > someone who actually understand Gujarati to proof-read if using Noto is 
> > not inferior to the previous Freefont display, 
> 
> I'm pretty sure, Kartik Mistry would be able to help here (Gujarati 
> translator).
> 
> > and it needs someone 
> > (you, Holger?) to help generate something for those Gujarati experts to 
> > proof-read.
> 
> I looked into this:
> Font selection is done in rootskel-gtk, and i added a variant for gu 
> like this:
> 
> - snip --
> # Set the primary GTK font according to language
> FONT_NAME=$DEFAULT_FONT
> case "$language" in
> ar|fa)
> FONT_NAME="Nazli"
> FONT_SIZE=$(($FONT_SIZE + 2))
> ;;
> am)
> FONT_NAME="Abyssinica SIL"
> FONT_SIZE=$(($FONT_SIZE + 1))
> ;;
> dz|bo)
> FONT_NAME="Tibetan Machine Uni"
> FONT_SIZE=$(($FONT_SIZE + 2))
> ;;
> gu)
> FONT_NAME="Noto Sans Gujarati"
> FONT_SIZE=$(($FONT_SIZE + 2))
> ja)
> FONT_NAME="VL Gothic"
> ;;
> km)
> FONT_NAME="Khmer OS System"
> FONT_SIZE=$(($FONT_SIZE + 1))
> ;;
> kn)
> FONT_SIZE=$(($FONT_SIZE + 1))
> ;;
> ko)
> FONT_NAME="UnDotum"
> ;;
> pa)
> FONT_NAME="Lohit Punjabi"
> ;;
> si)
> FONT_NAME="Noto Sans Sinhala"
> ;;
> ta)
> FONT_NAME="TSCu_Paranar"
> FONT_SIZE=$(($FONT_SIZE + 2))
> ;;
> th)
> FONT_NAME="Loma"
> FONT_SIZE=$(($FONT_SIZE + 2))
> ;;
> ug)
> FONT_NAME="UKIJ Tuz"
> FONT_SIZE=$(($FONT_SIZE + 1))
> ;;
> zh*)
> FONT_NAME="AR PL ShanHeiSun Uni"
> ;;
> bn|hi|ml|mr|ne)
> FONT_SIZE=$(($FONT_SIZE + 2))
> ;;
> esac
> - snap --
> 
> However, this does not work, Gujarati is still unreadable.
> (With the above changing I re-built the package and used it as localudeb
> for building a netboot-gtk image.)
> Is "Noto Sans Gujarati" correct, as shown above?

As I mention in above quote, fonts-noto udeb need to extended to include 
Gujarati, because that udeb should only contain what is actually used - 
see bug#837926.

You want me to add Noto Sans Gujarati to the udeb?


 - Jonas

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

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


signature.asc
Description: signature

Bug#740894: gmsh: please make tetgen an optional feature for gmsh

[Kurt Kremitzki]

Hello Francesco,

On Fri, 10 Nov 2017 19:38:27 +0100 Francesco Poli
 wrote:
> On Sat, 29 Oct 2016 18:17:29 +0200 Francesco Poli wrote:
> 
> > On Fri, 30 Sep 2016 19:23:38 +0200 Francesco Poli wrote:
> > 
> > > On Wed, 05 Mar 2014 23:44:24 +0100 Francesco Poli (wintermute) wrote:
> > > 
> > > [...]
> > > > Since I think the GNU AfferoGPL v3 is non-free, I would like to kindly
> > > > ask you to make tetgen support in gmsh an optional feature, so that
> > > > libtet1.5 may be downgraded from the Depends to the Recommends control
> > > > field.
> > > > 
> > [...]
> > > > I really hope this can be done.
> > > > Thanks for your time and patience.
> > > 
> > > Hello,
> > > is there any progress on this issue?
> > > 
> > > Is what I ask feasible?
> > > Has my feature request been forwarded upstream?
> > > 
> > > Please let me know, thanks for your time!
> > 
> > Ping?
> 
> Second ping?
> 
> 
> -- 
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

I have been working on improving the maintenance status of the Gmsh
package. I just wanted to respond to this bug and state that I find your
reasoning sound and would like to implement it, although I can't commit
to a timeline; my current priority is to get Gmsh 4 uploaded as I
already have a working package on the FreeCAD Community Extras PPA [1].

[1] https://launchpad.net/~freecad-community/+archive/ubuntu/ppa

Bug#911997: git: Apply diff from Ubuntu

[Jonathan Nieder]

Hi Jeremy,

Jeremy Bicha wrote:

> Did you see https://bugs.debian.org/911997 ?

No, I didn't.  I wonder if there was a mail delivery outage from the BTS
or something.

> I believe you were interested before in getting the Debian and Ubuntu
> packaging for git in sync so that Ubuntu would automatically sync the
> latest stable git release (at least until the Debian Import Freeze
> deadline).
>
> Please see my commits at
> https://salsa.debian.org/jbicha/git/merge_requests/1 which should make
> this possible.
>
> If we're lucky, maybe Ubuntu will promote pcre2 to main this cycle,
> but it's probably best not to assume that will happen.

Hooray, thank you!  I'll take a look when I get in to work tomorrow
morning.

> +ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)

Is there a way to distinguish between Ubuntu main builds and builds of
the PPA https://launchpad.net/~git-core/+archive/ubuntu/ppa?

If not, then that's fine and Anders may be able to just override this
line, but I thought I should ask.

Sincerely,
Jonathan

Bug#915362: RM: rkt [armhf] -- ROM; FTBFS

[Dmitry Smirnov]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
Affects: rkt

Please remove [armhf] binaries of "rkt" from "testing".

"arm64" flavor of [armhf] architecture is not supported by "rkt" and old 
binaries prevent migration of "rkt" to "testing".

Thanks.

-- 
Regards,
 Dmitry Smirnov.

---

Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken


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

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Harlan Lieberman-Berg]

On Sun, Dec 2, 2018 at 10:48 AM Julien Cristau  wrote:
> OK, let's do that then.  Sorry for not getting back to this sooner.

Sounds good.  I'm preparing the uploads now.

It looks like I will need to rebuild the version of
python-parsedatetime in stable to also build the python3 version.  I
could also backport a newer version that builds python3.  Let me know.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#904946: gmsh: OpenCASCADE gone

[Kurt Kremitzki]

Hello Joost,

On 11/27/18 11:29 AM, Joost van Zwieten wrote:
> Hi Kurt, Andreas,
> 
> I ran into this issue today. When switching from stretch to buster I
> noticed that gmsh couldn't read STEP files anymore. The following
> error message appears:
> 
> Error   : Gmsh requires OpenCASCADE to import shape
> 
> I've fixed the issue by building gmsh with the additional build
> dependency libocct-data-exchange-dev. See patch 0001. I've also added
> a small autopkgtest (patch 0002) using a STEP file that is part of the
> source package.
> 
> Best, Joost
> 

Thank you very much for looking at this issue! I'm building and testing
this now and will upload ASAP.

Bug#915194: valgrind log

[YunQiang Su]

Helmut Grohne  于2018年12月3日周一 上午3:22写道：
>
> On Mon, Dec 03, 2018 at 01:30:43AM +0800, YunQiang Su wrote:
> > YunQiang Su  于2018年12月2日周日 下午11:42写道：
> > >
> > > Matthias Klose  于2018年12月2日周日 下午4:51写道：
> > > >
> > > > On 02.12.18 09:31, Aron Xu wrote:
> > > > > Running with Valgrind shows some errors:
> > > >
> > > > that might point to the gcc-search-prefixed-as-ld patch.
> >
> > yes. with gcc-search-prefixed-as-ld patch removed, it works now.
>
> The patch is necessary for making gcc-for-host happen. It is the second
> attempt at solving that part of the problem and I don't particularly
> like the patch (though my previous attempt broke something else).
>
> I think there is yet another way of solving that part without patching
> gcc at all: Supplying /usr/lib/gcc///{as,ld} as
> symlinks pointing to the triplet-prefixed binutils should be sufficient.
> Not having to add another patch should help reduce the maintenance cost.
>

yes. it is enough for us.

> Given that gcc-for-host is not a thing yet and that there still are
> alternative approaches, I'm in favour of just reverting that patch with
> no replacement now to unblock your work.

The problem left is about why this patch broken some machine only?
for example amd64+avx?

I tested on an non-avx machine, it works well.
Aron test it will qemu emulate any hardware(avx and non-avx), all of
them work well.

Do you have any old machines, which can get a test?

>
> Helmut

Bug#915311: dumb-init FTBFS on mips*: test failures

[Chris Kuehl]

Hi Adrian,

Thanks for filing this. I can't be certain, but I have a strong
suspicion that this is caused by a bug that we fixed upstream with
dumb-init 1.2.2 which was causing flakiness in the test suite on
certain environments and architectures.

The bug was: https://github.com/Yelp/dumb-init/issues/136
The patch was: https://github.com/Yelp/dumb-init/pull/174

If possible, I would suggest packaging the latest version of dumb-init
(currently 1.2.2) as the easiest way to fix this.

Please let me know if there's any way we can help from the upstream side.

On Sun, Dec 2, 2018 at 9:39 AM Adrian Bunk  wrote:
>
> Source: dumb-init
> Version: 1.2.0-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=dumb-init
>
> ...
> === FAILURES 
> ===
> _ test_all_processes_receive_term_on_exit_if_setsid[1] 
> _
>
> @pytest.mark.usefixtures('both_debug_modes', 'setsid_enabled')
> def test_all_processes_receive_term_on_exit_if_setsid():
> """If the child exits for some reason, dumb-init should send TERM to 
> all
> processes in its session if setsid mode is enabled."""
> >   child_pid, child_stdout = spawn_process_which_dies_with_children()
>
> tests/child_processes_test.py:109:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _
>
> def spawn_process_which_dies_with_children():
> """Spawn a process which spawns some children and then dies without
> signaling them, wrapped in dumb-init.
>
> Returns a tuple (child pid, child stdout pipe), where the child is
> print_signals. This is useful because you can signal the PID and see 
> if
> anything gets printed onto the stdout pipe.
> """
> proc = Popen(
> (
> 'dumb-init',
> 'sh', '-c',
>
> # we need to sleep before the shell exits, or dumb-init might 
> send
> # TERM to print_signals before it has had time to register 
> custom
> # signal handlers
> '{python} -m testing.print_signals & sleep 0.1'.format(
> python=sys.executable,
> ),
> ),
> stdout=PIPE,
> )
> proc.wait()
> assert proc.returncode == 0
>
> # read a line from print_signals, figure out its pid
> line = proc.stdout.readline()
> match = re.match(b'ready \(pid: ([0-9]+)\)\n', line)
> >   assert match, line
> E   AssertionError:
> E   assert None
>
> tests/child_processes_test.py:95: AssertionError
> - Captured stderr call 
> -
> [dumb-init] Running in debug mode.
> [dumb-init] Unable to detach from controlling tty (errno=25 Inappropriate 
> ioctl for device).
> [dumb-init] Child spawned with PID 7035.
> [dumb-init] Unable to attach to controlling tty (errno=25 Inappropriate ioctl 
> for device).
> [dumb-init] setsid complete.
> [dumb-init] Received signal 18.
> [dumb-init] A child with PID 7035 exited with exit status 0.
> [dumb-init] Forwarded signal 15 to children.
> [dumb-init] Child exited with status 0. Goodbye.
> _ test_all_processes_receive_term_on_exit_if_setsid[0] 
> _
>
> @pytest.mark.usefixtures('both_debug_modes', 'setsid_enabled')
> def test_all_processes_receive_term_on_exit_if_setsid():
> """If the child exits for some reason, dumb-init should send TERM to 
> all
> processes in its session if setsid mode is enabled."""
> >   child_pid, child_stdout = spawn_process_which_dies_with_children()
>
> tests/child_processes_test.py:109:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _
>
> def spawn_process_which_dies_with_children():
> """Spawn a process which spawns some children and then dies without
> signaling them, wrapped in dumb-init.
>
> Returns a tuple (child pid, child stdout pipe), where the child is
> print_signals. This is useful because you can signal the PID and see 
> if
> anything gets printed onto the stdout pipe.
> """
> proc = Popen(
> (
> 'dumb-init',
> 'sh', '-c',
>
> # we need to sleep before the shell exits, or dumb-init might 
> send
> # TERM to print_signals before it has had time to register 
> custom
> # signal handlers
> '{python} -m testing.print_signals & sleep 0.1'.format(
> python=sys.executable,
> ),
> ),
> stdout=PIPE,
> )
> proc.wait()
> assert proc.returncode == 0
>
> # read a line from print_signals, figure out its pid
> line = proc.stdout.readline()
> match = re.match(b'ready \(pid: ([0-9]+)\)\n', 

Bug#912303: RFA: libopenhmd -- API and drivers for immersive technology

[eamanu15]

HellO!


> Thank you for stepping up and adopting the package!
> I've just added you as a maintainer.
>
> Thanks!!!

Cheers!
Emmanuel

Bug#912303: RFA: libopenhmd -- API and drivers for immersive technology

[Bálint Réczey]

Hi Emmanuel,

eamanu15  ezt írta (időpont: 2018. dec. 2., V, 4:22):
>
> Control: retitle -1 ITA: libopenhmd -- API and drivers for immersive 
> technology
>
> Control: owner -1 emmanuelaria...@gmail.com
>
> Hi Bálint,
>
> I've just upload the new release ITP to mentors.d.o.
>
> Can you give me permissions to push commits to the salsa repo?  My user is 
> eamanu-guest

Thank you for stepping up and adopting the package!
I've just added you as a maintainer.

Cheers,
Balint

>
> Thanks!
> Regards!
>
>
> --
> Arias Emmanuel
> http://eamanu.com
> Github/Gitlab; @eamanu
> Debian: @eamanu-guest

Bug#869749: ITP: dsmidiwifi

[Thorsten Glaser]

retitle 869749 ITP: dsmidiwifi -- DS Midi Wifi server
owner 869749 !
thanks

Working on it.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Wouter Verhelst]

On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst  wrote:
> 
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

Thanks; somehow I missed that, sorry.

> > Also, I would like to ask why the traditional solution in Debian -- make
> > a policy change that says no package can ship anything in /bin except
> > for a compatibility symlink, and make that rule RC at some point in the
> > future -- is not being considered. That seems like a solution that would
> > cause far less pain than what we're going through right now.
> This is not a solution. For a start it would take many years.

The fact that doing something in one particular way takes longer does
not in and of itself make it a bad solution.

It also need not take that long. We can declare *right now* that
shipping something in /bin (as opposed to /usr/bin) that is not a
compatibility symlink will be RC in bullseye. This would be plenty of
time for maintainers to be aware of it and to start looking at updating
their packages. With your usrmerge package, it's not at all clear to me
when the migration would be finished.

> Even ignoring that, it would not bring any improvement over the current 
> plan:

This is incorrect. The current plan has some systems be merged-/usr and
others not while we are in the transition. It therefore introduces
Debian-wide complexity in that maintainers are expected to support both
merged and unmerged /usr, which causes problems (as we see here). It
also effects a change without the maintainers of the software in
question being involved, which could have unintended side effects with
some packages that we don't know yet (and that we probably won't know
about until the release of buster).

Changing this through a policy change, as we've always done, would not
have those problems:

- Maintainers are expected to move their own package to merged-/usr, so
  they would be aware of issues that might ensue and would be able to
  deal with them.
- We are not expected to be supporting merged-/usr and unmerged-/usr at
  the same time; instead, we'll be gradually moving towards a
  merged-/usr situation.
- We don't end up with packages' files being moved from under them.

> even if your idea were executed perfectly and quickly then the 
> conversion program would still be in the same exact situation as it is 
> now:

Yes, obviously, that's the whole point.

[...]
> So this would make the transition unacceptably slow while providing no 
> benefit at all,

I don't agree with both these statements.

> but it would also cost a huge amount of work to change many packages.

Yes, and at the same time it would reduce a huge amount of *different*
work, since packages now won't need to be changed so that "being built
on merged-/usr" won't result in packages that don't build on
unmerged-/usr.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#914897: debating the wrong thing

[Adam Borowski]

I see that we're debating the merits of merged-usr vs non-merged-usr, while
expending lots of effort and filing bugs (requiring further urgent action of
unrelated maintainers), for little gain.

In the above, note that the debate vs effort touch different problems:

1. is usrmerge good?
vs
2. how to support both?

I say that 1. is a relatively small issue.  After dropping support for
booting from split /-vs-/usr without initrd, the difference doesn't really
matter.  I'm against pointless moves, but it's not worth an endless debate.
My objection is: repainting the house is a lot of work, paint fumes are bad
for health, the old color was fine and the old paint isn't noticeably flaky.

On the other hand, 2. is madness.  It's taking down load-bearing walls just
so you can have visible sides of both colours.

All the bugs you folks just filed are completely moot if we go all-in,
all-out or step-back-then-in.  So please at least stop filing extra bugs
before the TC decides on the course.

So, let's enumerate possible outcomes:

1. no usrmerge
  1a. no moves at all (no effort needed!)
  1b. moves via some dh_usrmove tool, until /bin is empty
2. supporting both merged-usr and unmerged-usr
3. mandatory usrmerge
  3a. by Bullseye
  3b. by Buster

Unless the TC decides for 2., all this work will be a pure waste of yours
and maintainers' time.

With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in
3a "for now").  With 3b you need some way to make sure existing systems are
converted (also with 3a except for far more time for testing).

And any effort spent doing one of the numbered choices is wasted if we end
up with a choice with a different number.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#586695: Asking for help on network completion problems and concerns

[Barak A. Pearlmutter]

Checked more carefully.
You are right! I get hostname completion on the shortlist of
known_hosts, and after the colon (for any host) I get remote filename
completion. And it's all fast. Wow, sweet!

Bug#886120: ctpp2: diff for NMU version 2.8.3-25.1

[Kunal Mehta]

Hi,

On 12/2/18 11:56 AM, gregor herrmann wrote:
> I've prepared an NMU for ctpp2 (versioned as 2.8.3-25.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Thanks, it seems fine to me. I'm also happy to do a standard upload, I'm
not sure if that would be preferred since you've already uploaded this one.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#907212: RFS: golang-github-xanzy-go-gitlab/0.0~git20180814.f3bc634-1 [ITP]

[Andreas Henriksson]

Control: tags -1 + moreinfo

Hello Felix Lechner,

On Fri, Aug 24, 2018 at 11:28:51AM -0700, Felix Lechner wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "golang-github-xanzy-go-gitlab"
[...]

I noticed there's a newer version available in the go-team git repo.
I looked at that one, while I'm certainly no go packaging expert,
your package looks fine to me except for one detail which you'll
need to fix to have a chance to pass NEW. They copyright attribution.

$ grep Copyright *.go | cut -d: -f2- | sort -u
// Copyright 2015, Sander van Harmelen
// Copyright 2017, Andrea Funto'
// Copyright 2017, Arkbriar
// Copyright 2017, Igor Varavko
// Copyright 2017, Sander van Harmelen
// Copyright 2017, Sander van Harmelen, Michael Lihs
// Copyright 2017, Stany MARCEL
// Copyright 2018, Patrick Webster
// Copyright 2018, Sander van Harmelen


Please make sure they're all accounted for in debian/copyright.

One you have this fixed, please feel free to ping me directly (and cc
this bug report) and I'll try to find time to look again and upload.

Regards,
Andreas Henriksson

Bug#915321: Mutex creation failed

[Aurelien Jarno]

On 2018-12-03 00:59, Adrian Bunk wrote:
> Control: unmerge -1 915339
> Control: reassign -1 r-cran-later 0.7.4+dfsg-1
> Control: retitle -1 r-cran-later: Mutex creation failed with glibc 2.28
> Control: forwarded -1 https://github.com/r-lib/later/issues/77
> Control: block 915339 by -1
> Control: retitle 915339 libc6 needs Conflicts with unfixed r-cran-later
> 
> On Sun, Dec 02, 2018 at 09:11:06PM +0200, Theodore Lytras wrote:
> > Package: libc6
> > Version: 2.28-1
> > Severity: critical
> > 
> > Just after updating libc6 from 2.27-8 to 2.28-1 in Debian Unstable, loading 
> > package "httpuv" in R leads to a crash:
> > 
> >bones@equinox2:~$ R
> >
> >R version 3.5.1 (2018-07-02) -- "Feather Spray"
> >Copyright (C) 2018 The R Foundation for Statistical Computing
> >Platform: x86_64-pc-linux-gnu (64-bit)
> >
> >R is free software and comes with ABSOLUTELY NO WARRANTY.
> >You are welcome to redistribute it under certain conditions.
> >Type 'license()' or 'licence()' for distribution details.
> >
> >R is a collaborative project with many contributors.
> >Type 'contributors()' for more information and
> >'citation()' on how to cite R or R packages in publications.
> >
> >Type 'demo()' for some demos, 'help()' for on-line help, or
> >'help.start()' for an HTML browser interface to help.
> >Type 'q()' to quit R.
> >
> >> library(httpuv)
> >terminate called after throwing an instance of 'std::runtime_error'
> >  what():  Mutex creation failed
> >Ακυρώθηκε
> >bones@equinox2:~$ 
> > 
> > From the message I understand this is directly related to libc6 and not R 
> > or httpuv. 
> > Also, there was no update to R or httpuv done recently. The problem started 
> > just as I updated libc6.
> >...
> 
> This seems to be a bug in r-cran-later, I'm reassigning this bug there 
> and leave another bug here for adding a Conflicts with the unfixed
> r-cran-later afterwards.

While the pointer to the bug is correct, I am not sure we need to
reassign the bug there. Nothing has to be changed in r-cran-later, it
just has to be binNMued against glibc 2.28. OTOH, we need to add a Break
on the glibc side.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#915109: apt upgrade needs limit or date cap

[Julian Andres Klode]

On Sun, Dec 02, 2018 at 10:28:00PM +, Roland Hughes wrote:
> What I rather clearly stated multiple times is that apt needs an 
> -asof=yyymmdd:hhmm parameter. The purpose of this parameter is to only 
> allow apt to apply updates pushed to the repository prior to that 
> timestamp. Anything later is ignored.

So, there's an easy way to achieve a cut off/reproduction. Run
update, record the SHA256 of the InRelease files and specify them
as documented / requested in bug 886745.

This works fine for Ubuntu at least. Another approach, considered
for image building in Ubuntu is to use a proxy that figures that
hash out by date using Launchpad API and injects itself into the build
process:

 https://code.launchpad.net/~tobijk/livecd-rootfs/magic-proxy/+merge/357643

- this does not translate directly to arbitrary repositories, though.

That said, there is of course a caveat: Archive space is not unlimited,
so only a limited number of generations are kept. This lasts a few hours
maybe, but not a span of days.

A cut off date is imprecise and gives you less properties than the
existing solution, as the data can easily change with the same cut-off
date, for example, you run at 20:00, get the 18:00 archive state,
and then you run at 21:00 and your mirror has the 19:00 archive
state. Using concrete hashes of InRelease files allows you to produce
an exact state of a given repository. You'd have to contact a centralized
master instance to get the real "current" one.

PS. I'd spent some time learning how to quote emails, wrap your
lines, and express yourself as short as possible, so things are
understandable. This email is a good example in general, but a
bit verbose. It will be appreciated. Also get rid of the disclaimer
when posting to public audiences.

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

Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Sebastiaan Couwenberg]

Control: reopen -1
Control: notfixed -1 gnudatalanguage/0.9.9-1
Control: severity -1 serious
Control: block 913837 by -1

Hi Ole,

On Sun, 2 Dec 2018 10:59:03 +0100 Gilles Filippini wrote:
> Ole Streicher a écrit le 01/12/2018 à 21:08 :
> > I think that failing CI tests are not a reason for severity "serious",
> 
> Sure. As stated in the bug report, the reason for severity "serious" was
> that release team said it was a blocker for the HDF5 and netcdf
> transitions [1]. I should have mentioned this link.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913837#34
>
> > and your test build should have succeeded independently of the tests.
> > GDL has quite a lot of tests failling, and I disable the known one in
> > the CI tests (only). So, CI test failure here shows that there were
> > unexpected failures.
> > 
> > Concidently, however, there was a new version of GDL published today,
> > which addresses a number of failures. Again, the failures known upstream
> > are xfailed in the CI tests. I'll upload the new version and close this
> > bug with the upload.
Unfortunately the autopkgtests for 0.9.9-1 still fail [0], and since
it's blocking the migration of hdf5 it makes the package unsuitable for
release justifying the RC severity [1].

The issue is not xfails in test-GDL.py, it's test-gdl [2]:

"
 =
 4 Error(s) found
 =
 test_call_external
 test_delvarrnew
 test_hdf5
 test_indgen
"

[0] https://ci.debian.net/packages/g/gnudatalanguage/unstable/amd64/
[1] https://release.debian.org/buster/rc_policy.txt
[2]
https://ci.debian.net/data/autopkgtest/unstable/amd64/g/gnudatalanguage/1418204/log.gz

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#586695: Asking for help on network completion problems and concerns

[Gabriel F. T. Gomes]

On 02 Dec 2018, Barak A. Pearlmutter wrote:

>Yup, this seems totally fixed: no completion of hostnames, or
>filesnames following a hostname.

I believe there's something else going on.  I do get completion of
hostnames (not from AVAHI, though) and of filenames following a
hostname with a colon.  Are you sure you have rsync and bash-completion
installed?

My intention was to ask if you were still getting long delays between
the pressing of the TAB key and the displaying of the completion
(probably not, because AVAHI completions are disabled nowadays).

Bug#900160: closed by Didier Raboud (Bug#900160: fixed in ruby-eventmachine 1.0.7-4.1)

[Kurt Roeckx]

On Sun, Dec 02, 2018 at 11:36:06PM +0100, gregor herrmann wrote:
> On Sun, 02 Dec 2018 23:18:38 +0100, Sebastian Andrzej Siewior wrote:
> 
> > On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
> > > #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
> > >  ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
> > >  .
> > >* Non-maintainer upload.
> > >* Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
> > >  (Closes: #900160)
> > 
> > Please revert that one. We don't want more dependencies on
> > libssl1.0-dev. We want it actually out of testing and are down to one
> > package.
> > I wouldn't care much but since ruby-eventmachine is a key package it
> > might migrate to testing…
> 
> Raising the severity of the cloned #915287 which tracks this problem
> should prevent the migration.

It won't, since it affects also the version in testing, it can
just migrate.


Kurt

Bug#914873: lintian: Reduce the number of overrides for binary-or-shlib-defines-rpath

[Chris Lamb]

tags 914873 + pending
thanks

Good idea. Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/d7eeaac89e5a754b08a7c3ce49cc53a224fbfd8a

  checks/binaries.pm | 2 ++
  debian/changelog   | 3 +++
  2 files changed, 5 insertions(+)


Regards,

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

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Adam Borowski]

On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst  wrote:> 
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

That post is too long-winded and touches so many unrelated issues that it's
difficult to respond to it.  Could you please give us a terse list of
claimed benefits?  Without a clear claim, it's too easy to both do or be
accused of doing a straw-man.

By my reading, most of that post either falls into the XY problem or
explains how merged-usr fixes problems caused by merged-usr itself.
That leaves only one concrete claim:
* that merged-usr makes it easier to have a part of the system immutable
  (be it for recovery purposes or for sharing)

My response to that claim is: there's a long list of techniques that can be
used for such an effect without sweeping distribution-wide changes.  Heck,
not even a couple of hours ago I restored from a snapshot multiple times in
order to troubleshoot a broken udev problem.  Here's your "This means you
always have a known-working filesystem to fall back on (if the most recently
updated filesystem doesn't boot, use the other one)".  Or, container
sharing: works fine for me without merged-usr either.  Thus, in order to
make this claim stick, you need to not only list its benefits but also
explain how it's better than other approaches: filesystem-based (btrfs, ZFS,
XFS), vfs-based (various overlays), lvm-based/-like, block-device based,
multiple mounts, etc.  And, many of those can do CoW which is so much better
than immutability.


(Please explain if I understood you wrong.)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#915321: Mutex creation failed

[Aurelien Jarno]

On 2018-12-02 21:11, Theodore Lytras wrote:
> Package: libc6
> Version: 2.28-1
> Severity: critical
> 
> Just after updating libc6 from 2.27-8 to 2.28-1 in Debian Unstable, loading 
> package "httpuv" in R leads to a crash:
> 
>bones@equinox2:~$ R
>
>R version 3.5.1 (2018-07-02) -- "Feather Spray"
>Copyright (C) 2018 The R Foundation for Statistical Computing
>Platform: x86_64-pc-linux-gnu (64-bit)
>
>R is free software and comes with ABSOLUTELY NO WARRANTY.
>You are welcome to redistribute it under certain conditions.
>Type 'license()' or 'licence()' for distribution details.
>
>R is a collaborative project with many contributors.
>Type 'contributors()' for more information and
>'citation()' on how to cite R or R packages in publications.
>
>Type 'demo()' for some demos, 'help()' for on-line help, or
>'help.start()' for an HTML browser interface to help.
>Type 'q()' to quit R.
>
>> library(httpuv)
>terminate called after throwing an instance of 'std::runtime_error'
>  what():  Mutex creation failed
>Ακυρώθηκε
>bones@equinox2:~$ 
> 
> From the message I understand this is directly related to libc6 and not R or 
> httpuv. 
> Also, there was no update to R or httpuv done recently. The problem started 
> just as I updated libc6.

From what I have been able to find, it seems to be a namespace conflict
issue between r-cran-later and glibc 2.28. r-cran-later requires C11
threads support, and when it is not available from glibc (like in 2.27),
it uses tinycthread. When upgrading to glibc 2.28, r-cran-later tries to
use the mtx_init symbol from tinycthread, but end-up using the glibc one,
leading to the above crash.

Rebuilding r-cran-later against glibc 2.28 to enable C11 threads support
from glibc is enough to fix the issue. I believe we should binNMU it and
add Breaks: on the glibc side.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#915321: Mutex creation failed

[Adrian Bunk]

Control: unmerge -1 915339
Control: reassign -1 r-cran-later 0.7.4+dfsg-1
Control: retitle -1 r-cran-later: Mutex creation failed with glibc 2.28
Control: forwarded -1 https://github.com/r-lib/later/issues/77
Control: block 915339 by -1
Control: retitle 915339 libc6 needs Conflicts with unfixed r-cran-later

On Sun, Dec 02, 2018 at 09:11:06PM +0200, Theodore Lytras wrote:
> Package: libc6
> Version: 2.28-1
> Severity: critical
> 
> Just after updating libc6 from 2.27-8 to 2.28-1 in Debian Unstable, loading 
> package "httpuv" in R leads to a crash:
> 
>bones@equinox2:~$ R
>
>R version 3.5.1 (2018-07-02) -- "Feather Spray"
>Copyright (C) 2018 The R Foundation for Statistical Computing
>Platform: x86_64-pc-linux-gnu (64-bit)
>
>R is free software and comes with ABSOLUTELY NO WARRANTY.
>You are welcome to redistribute it under certain conditions.
>Type 'license()' or 'licence()' for distribution details.
>
>R is a collaborative project with many contributors.
>Type 'contributors()' for more information and
>'citation()' on how to cite R or R packages in publications.
>
>Type 'demo()' for some demos, 'help()' for on-line help, or
>'help.start()' for an HTML browser interface to help.
>Type 'q()' to quit R.
>
>> library(httpuv)
>terminate called after throwing an instance of 'std::runtime_error'
>  what():  Mutex creation failed
>Ακυρώθηκε
>bones@equinox2:~$ 
> 
> From the message I understand this is directly related to libc6 and not R or 
> httpuv. 
> Also, there was no update to R or httpuv done recently. The problem started 
> just as I updated libc6.
>...

This seems to be a bug in r-cran-later, I'm reassigning this bug there 
and leave another bug here for adding a Conflicts with the unfixed
r-cran-later afterwards.

cu
Adrian

-- 

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

Bug#914885: lintian: remove debian-rules-makemaker-prefix-is-deprecated

[Chris Lamb]

tags 914885 + pending
thanks

Thanks for updating us. Removed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/7494919e930463bd4d7b37830f51eebe798ddc8b

  checks/rules.desc | 18 ---
  checks/rules.pm   |  6 ---
  debian/changelog  |  5 ++
  t/tests/rules-perl-makemaker/debian/rules | 71 ---
  t/tests/rules-perl-makemaker/desc |  5 --
  t/tests/rules-perl-makemaker/orig/Foo.pm  |  3 --
  t/tests/rules-perl-makemaker/orig/Makefile.PL |  6 ---
  t/tests/rules-perl-makemaker/tags |  1 -
  8 files changed, 5 insertions(+), 110 deletions(-)


Regards,

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

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Simon McVittie]

On Sun, 02 Dec 2018 at 21:04:55 +0100, Marc Haber wrote:
> The next debhelper change might choose to give / instead of /usr as a
> target directory by default, moving hundreds of megabytes from /usr to /
> over time.

I don't think anyone is proposing that. There's no reason why it would be
preferred over the merged /usr arrangement implemented in both usrmerge
and debhelper --merged-usr, which is the same as is implemented in some
other Linux distributions (e.g. Fedora): /usr is a real directory, and
/bin, /sbin, /lib* are symlinks to the corresponding directories in /usr.

Unifying /usr with / by making /usr a symlink to / is the opposite of
the merged /usr arrangement that is currently implemented. The Debian
hurd-i386 port did try having a /usr -> / symlink a few years ago as a
simplification, but it has all the same transitional issues as merged
/usr, with fewer advantages, which makes it unappealing.

The purpose of merged /usr is to group together all the static files
(/bin, /sbin, /lib* and the current /usr), which are more similar than
they are diferent, into one place that can be a (maybe read-only) mount
point (/usr). If you do the opposite, your root filesystem is still a
mixture of mutable files in /etc and static files in /bin, /sbin, /lib*,
so you haven't gained as much simplification as you would have had with
merged /usr.

(You talk about "default target directories", but there is nothing
so elaborate: debootstrap --merged-usr simply unpacks packages into a
chroot that already contains the symbolic links like /bin -> /usr/bin,
instead of into an empty chroot.)

smcv

Bug#914680: libplplotada3: missing Breaks+Replaces: libplplotada2

[Nicolas Boulenguez]

Package: libplplotada3
Version: 5.13.0+dfsg-10
Followup-For: Bug #914680

The short attachment contains untested suggestions
* for this bug
* for #821278 (Ada project)
* to set build flags (maybe fixing the empty -dbgsym packages)
* for a cosmetic change in debian/watch
>From 809d9fca94489f0845d8c5c053989150fc1b8130 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sun, 2 Dec 2018 23:39:09 +0100
Subject: [PATCH 1/4] Improve readability of watch file thanks to version 4 of
 uscan format.

---
 debian/watch | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/debian/watch b/debian/watch
index 0b81469a..a6be85a3 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,7 @@
-version=3
-opts="uversionmangle=s/-/~/,dversionmangle=s/\+dfsg$//,repacksuffix=+dfsg" \
-  http://sf.net/plplot/plplot-(.*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
+version=4
+
+opts="\
+  uversionmangle=s/-/~/,\
+  dversionmangle=s/\+dfsg$//,\
+  repacksuffix=+dfsg" \
+http://sf.net/@PACKAGE@/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
-- 
2.19.2

>From 961efce2cecfb5b3acae4086d2bd842f602b1977 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sun, 2 Dec 2018 23:39:43 +0100
Subject: [PATCH 2/4] Complete the link step of the Ada project.  Closes:
 #821278.

Copy bindings/ada/CMakeLists.txt, which only passes -lplplot to
pkg-config.
---
 debian/plplotada.gpr.in | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/debian/plplotada.gpr.in b/debian/plplotada.gpr.in
index 9d0bae03..e3877141 100644
--- a/debian/plplotada.gpr.in
+++ b/debian/plplotada.gpr.in
@@ -5,11 +5,7 @@ library project Plplotada is
for Library_Ali_Dir use  "/usr/lib/@DEB_HOST_MULTIARCH@/adalib/plplotada";
for Library_Dir use  "/usr/lib/@DEB_HOST_MULTIARCH@");
for Externally_Built use True;
-TODO:
-   --  If options must be added to the command line after
-   --  -L$(Library_Dir) -l$(Library_Name) when linking an executable:
package Linker is
- for Linker_Options use ("-lplplot", "-lor", "-lsomething", "-lsimilar");
+ for Linker_Options use ("-lplplot");
end Linker;
-   --  Else remove all from TODO: to this line.
 end Plplotada;
-- 
2.19.2

>From 28451d48642cefeac83f5704f4430435696d8e71 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sun, 2 Dec 2018 23:41:17 +0100
Subject: [PATCH 3/4] Delegate selection of default build flags to
 dpkg-buildflags.

Also, enable hardening flags. This setting can cause problems,
dpkg-buildflags(1) describes howto refine it.
---
 debian/rules | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/debian/rules b/debian/rules
index 6580e849..b9e2274c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,15 +6,21 @@
 # Paths for Octave
 OCTDIR = $(shell octave-config --print LOCALAPIOCTFILEDIR)
 
-# Note cmake ignores CPPFLAGS so add them to CFLAGS and CXXFLAGS as a
-# work around
-CPPFLAGS += $(shell mkoctfile -p INCFLAGS)
-CFLAGS += $(CPPFLAGS) -fvisibility=hidden
+DEB_BUILD_MAINT_OPTIONS   := hardening=+all
+DPKG_EXPORT_BUILDFLAGS:= 1
+DEB_CFLAGS_MAINT_APPEND   := -fvisibility=hidden
+DEB_FFLAGS_MAINT_APPEND   := -fvisibility=hidden
 # Don't add -fvisibility=hidden to CXXFLAGS for now as this breaks the
 # octave bindings.
+DEB_CPPFLAGS_MAINT_APPEND := $(shell mkoctfile -p INCFLAGS)
+DEB_LDFLAGS_MAINT_APPEND  := -Wl,--as-needed
+include /usr/share/dpkg/default.mk
+
+# Note cmake ignores CPPFLAGS so add them to CFLAGS and CXXFLAGS as a
+# work around, see #653916.
+CFLAGS   += $(CPPFLAGS)
 CXXFLAGS += $(CPPFLAGS)
-FFLAGS += -fvisibility=hidden
-LDFLAGS += -Wl,--as-needed
+
 HOME=$(shell mktemp -d)
 
 export verbose_test = on
-- 
2.19.2

>From 24225167500a55815cf87b56db53860221637b46 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sun, 2 Dec 2018 23:42:53 +0100
Subject: [PATCH 4/4] Set the shared object version of the Ada library. Closes:
 #914680.

The policy requires that the shared object version of the Ada library
matches the name of the binary package installing it, preventing such
bugs.
---
 debian/rules | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/rules b/debian/rules
index b9e2274c..c2eb8053 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,6 +34,14 @@ CONFIGURE_OPTIONS = \
 	-DBUILD_DOC=ON \
 	-DCMAKE_INSTALL_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) 
 
+# The soversion used to build and install the Ada shared library must
+# match the end of the library package name.
+ada_lib_pkg_vsn := $(shell sed -n \
+  '/^Package: libplplotada\([0-9.]\+\)$$/{s//\1/;p;q}' debian/control)
+ada_soname := libplplotada.so.$(ada_soversion)
+CONFIGURE_OPTIONS += \
+  '-DCMAKE_SHARED_LIBRARY_SONAME_Ada_FLAG=-Wl,-soname -Wl,$(ada_soname)'
+
 ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
   CONFIGURE_OPTIONS += -DBUILD_TEST=ON
 endif
-- 
2.19.2

Bug#900160: closed by Didier Raboud (Bug#900160: fixed in ruby-eventmachine 1.0.7-4.1)

[gregor herrmann]

On Sun, 02 Dec 2018 23:18:38 +0100, Sebastian Andrzej Siewior wrote:

> On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
> > #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
> >  ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
> >  .
> >* Non-maintainer upload.
> >* Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
> >  (Closes: #900160)
> 
> Please revert that one. We don't want more dependencies on
> libssl1.0-dev. We want it actually out of testing and are down to one
> package.
> I wouldn't care much but since ruby-eventmachine is a key package it
> might migrate to testing…

Raising the severity of the cloned #915287 which tracks this problem
should prevent the migration.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Bob Dylan: The Ballad Of Frankie Lee And Judas Priest


signature.asc
Description: Digital Signature

Bug#915361: udev refuses to start with sysvinit because it misdetects a container

[Gianluigi Tiesi]

Package: udev
Severity: grave

After upgrading kernel from 4.18.0-2 to 4.18.0-3 udev refuses to start if using 
sysvinit scripts

if [ -w /sys ]; then
  log_warning_msg "udev does not support containers, not started"
  exit 0
fi

/sys is mounted rw and it misdetects a container


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

Kernel: Linux 4.9.0-8-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: sysvinit (via /sbin/init)

Versions of packages udev depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libblkid12.32.1-0.2
ii  libc62.28-1
pn  libkmod2 
ii  libselinux1  2.8-1+b1
ii  libudev1 239-14
ii  lsb-base 10.2018112800
ii  util-linux   2.32.1-0.2

udev recommends no packages.

udev suggests no packages.

Bug#915350: severity of 915352 is important

[Chris Lamb]

Adrian Bunk wrote:

> Read the TC decision you linked to.

Huh, for some reason I had *completely* missed the pre/post buster
thing... Thanks!


Regards,

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

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Marco d'Itri]

On Dec 02, Wouter Verhelst  wrote:

> One thing that has not been answered yet in this discussion (and if the
> TC is to make a decision about it, I think it should be) is "why are we
> doing this". That is, what is the problem that usrmerge is meant to
> solve, and how does it attempt to solve it? As far as I know, the reason
> usrmerge exists is so that no files will be installed in /bin anymore;
> but that seems like an XY problem.
https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

> Also, I would like to ask why the traditional solution in Debian -- make
> a policy change that says no package can ship anything in /bin except
> for a compatibility symlink, and make that rule RC at some point in the
> future -- is not being considered. That seems like a solution that would
> cause far less pain than what we're going through right now.
This is not a solution. For a start it would take many years.
Even ignoring that, it would not bring any improvement over the current 
plan: even if your idea were executed perfectly and quickly then the 
conversion program would still be in the same exact situation as it is 
now: either everything in /bin/, /sbin and /lib (and its own 
subdirectories) was created by the packaging system, and then we already 
know that it can be converted automatically, or it was not, and then we 
know that there are a few cases when the local administrator has to 
decide what to do about things that were installed by himself in the 
past in the wrong place.
So this would make the transition unacceptably slow while providing no 
benefit at all, but it would also cost a huge amount of work to change 
many packages.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#915360: fonts-roboto: Please ship .woff files (eg. Roboto-Light-webfont.woff)

[Chris Lamb]

Package: fonts-roboto
Version: 2:0~20160106-2
Severity: wishlist

Hi,

python-django currently ships Roboto-Light-webfont.woff which flags
font-in-non-font-package in Lintian (as well as font-outside-font-dir
but that is unrelated to this).

It would be great if we could symlink this from the Roboto package(s)
instead. Is this something you could ship?

(Or should the Django packaging generate this itself from Build-
Depends instead? Apologies if I'm missing somehing obvious.)


Regards,

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

Bug#842828: Job started

[Xavier]

Control: tags -1 + pending
Control: retitle -1 ITP: bootstrap4 -- HTML, CSS, and JS framework
Control: owner -1 pkg-javascript-de...@lists.alioth.debian.org

I started to build twitter-bootstrap4 in a separate package
(https://salsa.debian.org/js-team/twitter-bootstrap4)

Cheers,
Xavier

Bug#915359: ITP: puppet-strings -- Puppet String generates documentation for Puppet code and extensions

[Kienan Stewart]

Package: wnpp
Severity: wishlist
Owner: Kienan Stewart 

* Package name: puppet-strings
  Version : 2.1.0-1
  Upstream Author : Puppet Labs Inc.
* URL : https://github.com/puppetlabs/puppet-strings
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Puppet String generates documentation for Puppet code and 
extensions

Puppet Strings generates documentation for Puppet code and extensions written in
Puppet and Ruby. Strings processes code and YARD-style code comments to create
documentation in HTML, Markdown, or JSON formats.

This package can be useful for people using Puppet in order to generate readable
HTML documentation for a modules or entire control repositories. I will need a
sponsor.

Bug#915350: severity of 915352 is important

[Adrian Bunk]

On Sun, Dec 02, 2018 at 05:15:42PM -0500, Chris Lamb wrote:
> [Adding 915...@bugs.debian.org to CC]
> 
> Adrian Bunk wrote:
> 
> > severity 915352 important
> > thanks
> 
> Can you elaborate? My reading of https://bugs.debian.org/904302 was
> that they should not be allowed in the archive, thus including them in
> the archive is RC. What am I missing?
>...

Read the TC decision you linked to.

> Best wishes,

cu
Adrian

-- 

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

Bug#915307: magic-wormhole FTBFS with Python 3.7

[anarcat]

Control: fixed 915307 0.11.2-1

I believe the latest upstream release fixes that, or at least it
compiles here in a sid schroot with py 3.7.

I meant to fix this in the changelog but forgot about it before doing
the upload... :/

Thanks for the heads up though!


signature.asc
Description: PGP signature

Bug#900160: closed by Didier Raboud (Bug#900160: fixed in ruby-eventmachine 1.0.7-4.1)

[Sebastian Andrzej Siewior]

On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
> #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
>  ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
>  (Closes: #900160)

Please revert that one. We don't want more dependencies on
libssl1.0-dev. We want it actually out of testing and are down to one
package.
I wouldn't care much but since ruby-eventmachine is a key package it
might migrate to testing…

Sebastian

Bug#883854: stretch-pu: package mate-polkit/1.16.0-2+deb9u1

[Mike Gabriel]

Hi Julien,

On  So 02 Dez 2018 16:48:31 CET, Julien Cristau wrote:


On Sat, Jan 13, 2018 at 06:09:43PM +0100, Julien Cristau wrote:

Control: tag -1 moreinfo

On Fri, Dec  8, 2017 at 12:17:33 +0100, Mike Gabriel wrote:

> Whenever mate-polkit asks for the user's password to change the user
> context via PolicyKit, an icon is shown in the system tray.
>
> In Debian stretch, this icon is broken. It should show dialog-password.
> The attached .debdiff fixes that.
>
> Please consider an ACK to get this change into the next point release of
> Debian 9.
>
The bug severity is "minor".  I'm not convinced that qualifies.


Doesn't look like anyone feels strongly otherwise, so closing.


Argh... I obviously missed your earlier comment on the "minor"  
severity status. Sorry for not replying.


While the bug's severity status is "minor", the UI experience is  
user-unfriendly. Please consider re-opening.


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpuGS1aQwZ5A.pgp
Description: Digitale PGP-Signatur

Bug#915350: severity of 915352 is important

[Chris Lamb]

[Adding 915...@bugs.debian.org to CC]

Adrian Bunk wrote:

> severity 915352 important
> thanks

Can you elaborate? My reading of https://bugs.debian.org/904302 was
that they should not be allowed in the archive, thus including them in
the archive is RC. What am I missing?

(Same for #915350, naturally.)


Best wishes,

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

Bug#915350: severity of 915352 is important

[Chris Lamb]

[Adding 915...@bugs.debian.org to CC]

Adrian Bunk wrote:

> severity 915352 important
> thanks

Can you elaborate? My reading of https://bugs.debian.org/904302 was
that they should not be allowed in the archive, thus including them in
the archive is RC. What am I missing?

(Same for #915350, naturally.)


Best wishes,

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

Bug#887768: Steps to reproduce mouse freeze

[Susan Cragin]

On my machine F6 doesn't work at all. Nothing happens to alsamixer. I am aware that alsamixer is not mouse-friendly, and I do not try to control alsamixer with the mouse. On the other hand, alsamixer seems to interfere with my mouse. Steps to reproduce mouse freeze: (1) open terminal(2) start alsamixer(3) press the F6 keyThat's it. After that the mouse freezes into whatever position it is in on the screen and cannot be moved. Pressing ESC to get out of alsamixer does not make the mouse able to move. Neither does closing the terminal where alsamixer was running. The mouse is frozen into position, and I can do nothing to make the mouse active again but reboot. If this problem were more universal, I imagine there would be lots of complaints. Since I seem to be the only one, I understand the skepticism. Susan Cragin

Bug#915358: ITP: magic-wormhole-mailbox-server -- Magic Wormhole Mailbox Server

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 

* Package name: magic-wormhole-mailbox-server
  Version : 0.3.1
  Upstream Author : Brian Warner
* URL : https://github.com/warner/magic-wormhole-mailbox-server
* License : MIT
  Programming Lang: Python
  Description : Magic Wormhole Mailbox Server

This is the main server that Magic-Wormhole clients connect to. The
server performs store-and-forward delivery for small key-exchange and
control messages. Bulk data is sent over a direct TCP connection, or
through a transit-relay.

Clients connect with WebSockets, for low-latency delivery in the happy
case where both clients are attached at the same time. Message are
stored to enable non-simultaneous clients to make forward
progress. The server uses a small SQLite database for persistence (and
clients will reconnect automatically, allowing the server to be
rebooted without losing state). An optional "usage DB" tracks
historical activity for status monitoring and operational maintenance.

==

This is necessary for magic-wormhole 0.11.2 tests to pass as they
include code from this package, which is now split out in a
different upstream repository.

It can also be useful for people who want to run their own custom
wormhole-based system without using any of the global wormhole
architecture.

Bug#915337: rr: baseline violation on i386

[Stephen Kitt]

Hi Adrian,

On Sun, 02 Dec 2018 23:01:23 +0200, Adrian Bunk  wrote:
> MMX and SSE are not part of the i386 baseline.

From the package description:

 rr is incompatible with ptrace hardening, and currently only supports
 Intel CPUs with Nehalem or later microarchitectures.

All supported CPUs support MMX and SSE. The package is useful on i386, but I
can drop it if you think I shouldn’t ship it there.

Regards,

Stephen


pgpSQI8s0_Olq.pgp
Description: OpenPGP digital signature

Bug#915356: RFA: eoconv -- convert text files between various Esperanto encodings

[Dmitry Bogatov]

Package: wnpp
Severity: normal

I did not use this package lately, so I request an adopter for the
eoconv package. Prospective maintainer will need some knowledge of perl.

The package description is:
 Esperanto is written in an alphabet of 28 letters. However, only 22 of
 these letters can be found in the standard ASCII character set. The
 remaining six -- `c', `g', `h', `j', and `s' with circumflex, and `u'
 with breve -- are not available in ASCII. Various encoding systems
 have been developed to represent Esperanto text in printed and typed text.
 eoconv program converts between them.

Bug#915354: RFA: sent -- simple plaintext presentation tool

[Dmitry Bogatov]

Package: wnpp
Severity: normal

I do not do many presentation lately, and would like someone to take
over `sent'. Package is rather small, uses recent debhelper and upstream
does not make frequent releases.

The package description is:
 sent does not need LaTeX, libreoffice or any other fancy file format,
 it uses plaintext files to describe the slides and can include images
 via farbfeld.  Every paragraph represents a slide in the
 presentation.
 .
 The presentation is displayed in a simple X11 window. The content of
 each slide is automatically scaled to fit the window and centered so
 you also don't have to worry about alignment. Instead you can really
 concentrate on the content.

Bug#915357: RFA: clues-emacs

[Dmitry Bogatov]

Package: wnpp
Severity: normal

I no longer use Emacs, so I orphan all my Emacs packages. Description of
clues-emacs:

Description-en: cream/brown/orange color theme for Emacs
 Clues was initially based on a Visual Studio theme called 'Blues 'n
 Roots', however it's a long way from looking much like it, aside from
 the occasional color accent, Blues (despite its name) has a more
 toasted caramel flavor. Clues on the other hand is made up of cooling
 colors with a couple of flecks of light cream/brown/orange to break
 up any monotony, with yellow/gold rainbow-delimiters.

Bug#915355: RFA: fbless -- terminal fiction book reader

[Dmitry Bogatov]

Package: wnpp
Severity: normal

I do not read much fb2 on my laptop lately, so I request an adopter for
the fbless package. Package in decent shape and uses recent debhelper.

Unfortunately, upstream is dead, so should issues araise, prospective
maintainer will need skills and time to fix Python2 code.

The package description is:
 Fbreader is ncurses fiction book (.fb2) reader with following
 features:
 .
  * customizable color themes
  * last viewed point saving
  * autoscroll mode
  * support for archived books
  * basic links support
 Fbreader is ncurses fiction book (.fb2) reader with following
 features:
 .
  * customizable color themes
  * last viewed point saving
  * autoscroll mode
  * support for archived books
  * basic links support

Bug#915353: vdr-plugin-skinenigmang FTBFS due to using freetype-config that was removed in Debian

[Adrian Bunk]

Source: vdr-plugin-skinenigmang
Version: 0.1.2+git20180128-2
Severity: serious
Tags: ftbfs patch

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/vdr-plugin-skinenigmang.html

...
In file included from config.h:20,
 from skinenigmang.c:9:
font.h:16:10: error: #include expects "FILENAME" or 
 #include FT_FREETYPE_H
  ^


Fix attached.
Description: freetype-config was removed in Debian, switch to pkg-config
Author: Adrian Bunk 

--- vdr-plugin-skinenigmang-0.1.2+git20180128.orig/Makefile
+++ vdr-plugin-skinenigmang-0.1.2+git20180128/Makefile
@@ -138,9 +138,9 @@ INCLUDES += $(shell pkg-config --cflags
 endif
 endif
 
-ifneq ($(shell which freetype-config),)
-   INCLUDES += $(shell freetype-config --cflags)
-   LIBS += $(shell freetype-config --libs)
+ifneq ($(shell which pkg-config),)
+   INCLUDES += $(shell pkg-config --cflags freetype2)
+   LIBS += $(shell pkg-config --libs freetype2)
 else
INCLUDES += -I/usr/include/freetype -I/usr/local/include/freetype
LIBS += -lfreetype