Bug#921414: RM: supercollider-sc3-plugins [armel mips mips64el ppc64el s390x] -- NBS; no longer built on architectures without qtwebengine5-dev

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

supercollider-sc3-plugins (3.9.1~repack-3) unstable; urgency=medium

  * changed Architecture: any to
Architecture: i386 amd64 arm64 armhf mipsel to comply with architectures
supported by the build-dependency supercollider-dev

 -- Georges Khaznadar   Sun, 03 Feb 2019 23:30:49 +0100

Bug#921413: TODO list for RFS: php-elisp/1.21.0-1 [ITA]

[Nicholas D Steeves]

Package: php-elisp
Version: 1.21.0-1
Severity: normal

Hi Antoine,

Thank you for much for sponsoring src:php-elisp!  I've created a
tracking bug for these issues, replied inline, and plan to fix them in
the next upload.

On Sat, Feb 02, 2019 at 12:40:40PM -0500, Antoine Beaupré wrote:
> I uploaded the package, but I'll note some improvements that could be
> done on it:
> 
>  1. newer versions of debhelper allow deduplicating information between
> the control file and debian/compat. just remove the latter and
> change the control dependency to "debhelper-compat (=11)" (or
> 12). see also:
> 
> 
> https://nthykier.wordpress.com/2019/01/04/debhelper-compat-12-is-now-released/

Oh!  Thank you for telling me about this :-)  (I didn't know)

>  2. very minor, but i like to keep the "transitional package" phrase on
> a separate line in package descriptions so it's more obvious to
> someone looking at the description

Do you mean like this?:
Short description:  transitional package from old-foo to new-foo package
 Old-foo description, and why new-foo...
 .
 This is a transitional dummy package and can be safely removed.

>  3. why was the php-root self-test disabled? what's the next step for
> that patch? can it be sent upstream or will we have to carry this on
> forever?

(ert-deftest php-project-root ()
  (should (string= (abbreviate-file-name default-directory)
   (php-project-get-root-dir

Evals to "/<>/" instead of the real path.  It will take
some time to review the changelogs and git history of my other
packages to find the workaround for this sbuild/buildd quirk, because
I didn't write "PKGBUILDDIR" as a keyword the last time I ran into it.
Oops...  Thus, I confess to choosing the fastest/easiest path since
the freeze is so close.

> Thanks for your work! :)

You're welcome :-D

--
Nicholas


signature.asc
Description: PGP signature

Bug#920942: transition: libfm-qt

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 03/02/2019 14:50, Alf Gaida wrote:
> Hi Emilio,
> 
> can we go on with libfm-qt? The builds are fine, not all release
> architectures are built due to slow build architectures, but i expect
> them to build fine - maybe there will be some easy fixable symbol issues.
> 
> * armel was built with some new symbols and some missed symbols - the
> missed things are fixed
> * armhf, mips64el and mipsel should build fine - but have a huge build
> queue, so i would expect builds in a week or so

Alright, let's make an exception for this, on the grounds that we currently have
an unstable version in buster, and the fact that this is pretty self-contained.

Emilio

Bug#921412: ITP: icingaweb2-module-eventdb -- browse comment and acknowledge events

[Kunz David]

Package: wnpp
Owner: david.k...@dknet.ch

* Package name: icingaweb2-module-eventdb
  Upstream Author : Icinga Development Team 
* License : GPL-2
  Description : embeds data from Elasticsearch directly into the
web interface

  Icinga Web 2 is a very modular, fast and simple web interface for 
  your Icinga monitoring environment.
  .
  This module allows you browse, comment and acknowledge
  events  collected by EventDB easily.

Greetings,
David

Bug#921411: Improving the Debian logo on the login page

[Aurélien COUDERC]

Package:gdm3
Severity: whishlist
Tags: patch

Dear Maintainer,

the attached patch improves the logo used by GDM at the bottom of the login
screen by using a full swirl+Debian+10 logo instead of the current simple
swirl.

Before :
https://people.debian.org/~coucouf/screenshots/Screenshot_20190202_160428.png
After :
https://people.debian.org/~coucouf/screenshots/Screenshot_20190202_160607.png

It looks much better IMO. :)


That new logo is part of desktop-base 10.0.0 that will be landing in unstable
shortly.

Also the new logo is behind an alternative that will make it much more easy
for derivatives to provide their own without patching.

I’ve removed the "fallback" configuration key that does nothing and is not
in the upstream doc:
https://help.gnome.org/admin/system-admin-guide/stable/login-logo.html.en


Cheers,
--
Aurélien COUDERC
Debian Developer
>From e6bbbf59a800280c8c7706a5f1ba54711fbcaa7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Aur=C3=A9lien=20COUDERC?= 
Date: Tue, 5 Feb 2019 00:42:27 +0100
Subject: [PATCH] Replace simple login bottom logo with a full logo+Debian+10
 logo

---
 debian/control| 2 +-
 debian/greeter.dconf-defaults | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index f31436f3..410c8076 100644
--- a/debian/control
+++ b/debian/control
@@ -80,7 +80,7 @@ Depends: accountsservice (>= 0.6.35),
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: at-spi2-core,
-desktop-base (>= 6),
+desktop-base (>= 10.0.0),
 x11-xkb-utils,
 xserver-xephyr,
 xserver-xorg,
diff --git a/debian/greeter.dconf-defaults b/debian/greeter.dconf-defaults
index c5b07860..441e8fbd 100644
--- a/debian/greeter.dconf-defaults
+++ b/debian/greeter.dconf-defaults
@@ -23,8 +23,7 @@
 # Login manager options
 # =
 [org/gnome/login-screen]
-logo='/usr/share/icons/hicolor/48x48/emblems/emblem-debian-white.png'
-fallback-logo='/usr/share/icons/hicolor/48x48/emblems/emblem-debian-white.png'
+logo='/usr/share/images/vendor-logos/logo-text-version-128.png'
 
 # - Disable user list
 # disable-user-list=true
-- 
2.20.1

Bug#921410: [INTL:sv] Swedish strings for shim-signed debconf

[Martin Bagge / brother]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

package: shim-signed
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlxZPZcACgkQOIRDexPY
/4vijhAApukFh5IMug3pp0RP8Cv1aLTZXP9OpIB5wcR/N1NsTQYtWm8+PThaDdeD
k/GsOKPf2z0xP47KAkNa5wfXp7YAsMvcRBnhqOfMgANJNGX/QB3Ibw+sohQFiDpx
NS3b6kwFFWdpzfMwyNVdXE5rtKGL5jt4lJ8z0rQ9PkltV3MGoEIrNFhdIIkhNqM+
VorVj/91/7G/bivtY+SlvaSUNHFwFgZbQgUXnJLmEt0sH5IqQE+Vk+TpYsVBHhK+
+1CTJweBqPnafH/xUoVlpWaHnFWT7XRKsmKjSSjA0UUUF9gjwz8sCB9MXe4+zvcd
8+gIDWinsWFpeeY4L/u75CnytLhtGNRAliB2Fg4+TavoIZllRMpJOKxc+6dTqVZQ
hJInHFMMiSrSc0WB2uZLBRRxnIqsEBKZqSzpw1W1QJmyHcJBtmwZrpwzk/jqw6nm
fkzHWvEWXILocT25OP3T/mwByPluCVsaP4zlrnT/3y45f0RRJO3Y2KKiST6ENuXZ
lcuaPF6jdQU4kjCDDkyJZHNLBh7N8P/GKfn1I6ql8JHGIxxjwJ75fjgIhXG3jBEt
i3Sws2o3COjN5ADhLlSAdsOVb4cSfJ1/GINcOkzS9dLwe+R7KZzsUUp8O4OVbIhy
AdjftjLxyxE9Icy9VQllxpV/aGhLXFic+vjJYPGiGr7/ba6nrBQ=
=LYV2
-END PGP SIGNATURE-
# Translation of shim-signed debconf template to Swedish
# Copyright (C) 2019 Martin Bagge 
# This file is distributed under the same license as the XX package.
#
# Martin Bagge , 2019
msgid ""
msgstr ""
"Project-Id-Version: shim-signed\n"
"Report-Msgid-Bugs-To: shim-sig...@packages.debian.org\n"
"POT-Creation-Date: 2018-11-04 08:13+0100\n"
"PO-Revision-Date: 2019-02-05 08:35+0100\n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"X-Generator: Poedit 2.2.1\n"

#. Type: text
#. Description
#: ../templates:1001
msgid "Configuring UEFI Secure Boot"
msgstr "Inställningar för UEFI Secure Boot"

#. Type: error
#. Description
#: ../templates:2001
msgid "Invalid password"
msgstr "Felaktigt lösenord"

#. Type: error
#. Description
#: ../templates:2001
msgid ""
"The Secure Boot key you've entered is not valid. The password used must be "
"between 8 and 16 characters."
msgstr ""
"Nyckeln för Secure Boot är inte korrekt. Lösenordet måste vara mellan 8 och "
"16 tecken."

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

#. Type: boolean
#. Description
#. Type: note
#. Description
#: ../templates:3001 ../templates:5001
msgid ""
"If Secure Boot remains enabled on your system, your system may still boot "
"but any hardware that requires third-party drivers to work correctly may not "
"be usable."
msgstr ""
"Om Secure Boot fortsätter att vara aktiverat på systemet kommer du "
"fortfarande kunna starta systemet men hårdvara som kräver drivrutiner från "
"tredje part kommer inte kunna användas."

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

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"If Secure Boot is enabled on your system, your system may still boot but any "
"hardware that requires third-party drivers to work correctly may not be "
"usable."
msgstr ""
"Om Secure Boot är aktiverat på systemet kommer det att kunna starta men "
"hårdvara som behöver drivrutiner från tredje part för att fungera kommer "
"inte att kunna användas."

#. Type: note
#. Description
#: ../templates:5001
msgid "Your system has UEFI Secure Boot enabled"
msgstr "Systemet har UEFI Secure Boot aktivt"

#. Type: note
#. Description
#: ../templates:5001
msgid "UEFI Secure Boot is not compatible with the use of third-party drivers."
msgstr ""
"UEFI Secure Boot kan inte användas tillsammans med drivrutiner från "
"tredjepart."

#. Type: note
#. Description
#: ../templates:5001
msgid ""
"The system will assist you in toggling UEFI Secure Boot. To ensure that this "
"change is being made by you as an authorized user, and not by an attacker, "
"you must choose a password now and then use the same password after reboot "
"to confirm the change."
msgstr ""
"Systemet kommer att hjälpa dig hantera UEFI Secure Boot. För att säkerställa "
"att förändringarna görs i gott uppsåt och inte av en ondsint utomstående så "
"måste lösenordet som nu väljs användas efter omstart för att aktivera "
"förändringarna."

#. Type: note
#. Description
#: ../templates:5001
msgid ""
"If you choose to proceed but do not confirm the password upon reboot, the "
"Secure Boot configuration will not be changed, and the machine will continue "
"booting as before."
msgstr ""
"Om du väljer att fortsätta utan att ange lösenordet vid uppstart kommer "
"inställningarna för Secure Boot inte att ändras och maskinen kommer att "
"fortsätta start som förr."

#. Type: password
#. Description
#: ../templates:6001
msgid "UEFI Secure Boot password:"
msgstr "UEFI Secure Boot-lösenord:"

#. Type: password
#. Description
#: ../templates:6001
msgid "Please enter a password for 

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Martín Ferrari]

On 05/02/2019 07:23, Stephen Gelman wrote:

>> Ouch. More reason to hold the upgrade then.
> 
> Sorry, I think you misinterpret what I mean: 0.34.1 works perfectly out of 
> the box, I was referring to trying to get 0.9.0 working.  At this point there 
> have already been 7 debian revisions of 0.9.0 so regardless of the outcome 
> here I think we should plan to upload a newer version in the near future 
> (though I agree with your point about getting 0.9.0 patched first).

Ah, yes, I misunderstood, I thought you were working on 0.34!

>> I have already been working on this for a while. That problem is fixed,
>> but there are still a few discrepancies with bigtable and spanner, which
>> I hope to fix soon and upload. Unless you had already fixed that?
> 
> I am still getting through the spanner tests but I am pretty close to being 
> done (I really truly hope).  If you want to complete it I am happy to back 
> off and let you but I’m also happy to finish going through them.  Just let me 
> know!

Please continue then! Let me know if I can give you a hand. (Probably
easier on IRC)


-- 
Martín Ferrari (Tincho)

Bug#921409: netdata: plugins can't sudo without CAP_AUDIT_WRITE

[Nye Liu]

Correction:

Have to add cap to /lib/systemd/system/netdata.service. Change

CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_SYS_PTRACE CAP_SETGID 
CAP_SETUID CAP_NET_RAW


to

CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_SYS_PTRACE CAP_SETGID 
CAP_SETUID CAP_NET_RAW CAP_AUDIT_WRITE

Bug#918227: xtables-addons-common: GeoIPCountryCSV.zip ERROR 404: Not Found

[Ladislav Wartha]

Why it is happening, its pretty easy. Maxmind discontinued old version of
IP database since 2nd of January 2019. So this version of xtables-addons
will be not working.

There should be available quick fix, which is converting new version to the
old format called GeoLite2xtables on github:
https://github.com/mschmitt/GeoLite2xtables

However I found at least one error where IP was missplaced, while
supposedly same database on maxmind website was returning correct value. So
use with caution.

I don't think, upgrading the package in this release will happen. New
version of xtables-addons is using geoip database in slightly different
format, which means, also kernel module has to be updated, which doesn't
sound like something what anybody want to do in this release. But I might
be wrong.:-)

Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)

[Adrian Bunk]

And then there is the unrelated #908269 that currently prevents testing 
migration of pbbam.

Steve seems to be addressing this with
http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz

Adrian


On Tue, Feb 05, 2019 at 12:04:16AM +0200, Adrian Bunk wrote:
> On Mon, Feb 04, 2019 at 04:36:22PM +0100, Andreas Tille wrote:
> > Hi Adrian,
> > 
> > On Mon, Feb 04, 2019 at 01:06:35PM +0200, Adrian Bunk wrote:
> > > >Bug#916576: pbdagcon: FTBFS pbdata/Types.h: No such file or directory
> > > > 
> > > > I need to make some noise in the team since I'm definitely overworked
> > > > with these pb* packages.  It might be that we will loose these for
> > > > Buster. :-(
> > > 
> > > the patches for pbbam and pbdagcon should sort out most of the issues.
> > 
> > I've now uploaded the old upstream version of pbdagcon.  Unfortunately
> > I can not see that pbbam has fixed the build issues[1] - thus I think
> > #909071 needs to be re-opened.
> >...
> 
> pbbam does now build on arm64/mips64el/ppc64el,
> this is what #909071 fixed.
> 
> pbbam fails its tests on 32bit (#829741) and big endian,
> these are expected failures that won't block migration.
> 
> But the pbdagcon build failure points at a bug in pbbam:
> libpbbam0.19.0 is not ABI compatible with the stretch libpbbam,
> so mustn't provide it.
> 
> The following changes should fix the latter problem:
> - remove the Provides: libpbbam from libpbbam0.19.0
> - remove manual dependencies on libpbbam from the following
>   source packages (correct dependencies on libpbbam0.19.0
>   are now generated):
>   - blasr
>   - pbdagcon
>   - pbseqlib
>   - unanimity
> 
> > Kind regards
> > 
> >   Andreas.
> > 
> > 
> > [1] https://buildd.debian.org/status/package.php?p=pbbam 

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Stephen Gelman]

> On Feb 5, 2019, at 1:17 AM, Martín Ferrari  wrote:
> 
> On 05/02/2019 06:41, Stephen Gelman wrote:
> 
>> I totally understand your concern.  I’m at least a few backported bug fixes 
>> deep and I am concerned the resulting package will have had so many changes 
>> applied that it will be a bit of a mess.
> 
> Ouch. More reason to hold the upgrade then.

Sorry, I think you misinterpret what I mean: 0.34.1 works perfectly out of the 
box, I was referring to trying to get 0.9.0 working.  At this point there have 
already been 7 debian revisions of 0.9.0 so regardless of the outcome here I 
think we should plan to upload a newer version in the near future (though I 
agree with your point about getting 0.9.0 patched first).

>> As a middle ground, I think I can get 0.9.0 patched for now with the
> intention of uploading a new version once we are out of hot water here.
> Do you think that is reasonable?
> 
> Yesm that sounds good. In fact, I was writing an email to you telling
> you that I think the fix is pretty easy: the breakage is because
> genproto removed a deprecated API
> (google.golang.org/genproto/googleapis/cloud/speech/v1beta1) that this
> package depends on. The fix (as upstream did it) is to remove the
> packages that reflect that API, and it is easy to backport.
> 
> I have already been working on this for a while. That problem is fixed,
> but there are still a few discrepancies with bigtable and spanner, which
> I hope to fix soon and upload. Unless you had already fixed that?

I am still getting through the spanner tests but I am pretty close to being 
done (I really truly hope).  If you want to complete it I am happy to back off 
and let you but I’m also happy to finish going through them.  Just let me know!

Stephen

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Martín Ferrari]

On 05/02/2019 06:41, Stephen Gelman wrote:

> I totally understand your concern.  I’m at least a few backported bug fixes 
> deep and I am concerned the resulting package will have had so many changes 
> applied that it will be a bit of a mess.

Ouch. More reason to hold the upgrade then.

> As a middle ground, I think I can get 0.9.0 patched for now with the
intention of uploading a new version once we are out of hot water here.
 Do you think that is reasonable?

Yesm that sounds good. In fact, I was writing an email to you telling
you that I think the fix is pretty easy: the breakage is because
genproto removed a deprecated API
(google.golang.org/genproto/googleapis/cloud/speech/v1beta1) that this
package depends on. The fix (as upstream did it) is to remove the
packages that reflect that API, and it is easy to backport.

I have already been working on this for a while. That problem is fixed,
but there are still a few discrepancies with bigtable and spanner, which
I hope to fix soon and upload. Unless you had already fixed that?

>
  I apologize if I didn’t communicate my intentions better here - I
emailed pkg-go a while back but I neglected to respond to this bug
(oversight on my part, sorry!).

No, I remember seeing that message, but being too busy with other
corners of Debian to pay much attention :)


PS: I was wrong in my previous message, there are not that many packages
depending on google-cloud. But for some reason, the autoremoval system
blames this package for a bunch of other packages to be at risk of
autoremoval. I don't understand why...

-- 
Martín Ferrari (Tincho)

Bug#921409: netdata: plugins can't sudo without CAP_AUDIT_WRITE

[Nye Liu]

Package: netdata
Version: 1.11.1+dfsg-7
Severity: normal

Without CAP_AUDIT_WRITE, plugins that try to sudo will fail with

PAM audit_log_acct_message() failed: Operation not permitted

The fix is

sudo setcap cap_audit_write+ep /usr/sbin/netdata

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

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

Versions of packages netdata depends on:
ii  netdata-core  1.11.1+dfsg-7
ii  netdata-plugins-bash  1.11.1+dfsg-7
ii  netdata-web   1.11.1+dfsg-7

Versions of packages netdata recommends:
ii  netdata-plugins-nodejs  1.11.1+dfsg-7
ii  netdata-plugins-python  1.11.1+dfsg-7

netdata suggests no packages.

-- debconf information excluded

Bug#794624: already in new

[Nicholas D Steeves]

On Sat, Feb 02, 2019 at 04:54:01PM +0100, Thomas Koch wrote:
> https://ftp-master.debian.org/new/web-mode_16.0.21-1.html

Thank you Thomas! :-)

By the way, if ever you'd like to improve something in src:php-elisp
(bin:elpa-php-mode), please go ahead, and add yourself to Uploaders.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#920924: elinks: no SpiderMonkey support

[أحمد المحمودي]

Hello,

Fixed, please spomsor this upload.

This upload fixes the following bugs
#920924 (normal): elinks: no SpiderMonkey support

Last changelog entry is:
elinks (0.13~20190125-2) experimental; urgency=medium

  * Mention felinks fork in description
  * Disable Spidermonkey (Closes: #920924)
mozjs185 has been removed in Debian, and upstream does not support later
versions
  * Add gitlab-ci.yaml


There is one lintian warning:
W: elinks-data: manpage-has-errors-from-man usr/share/man/man5/elinks.conf.5.gz 
1166: warning [p 14, 7.0i]: can't break line

The package is on: g...@salsa.debian.org:aelmahmoudy-guest/elinks.git , 
felinks branch

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/elinks

Alternatively, one can download the package with dget using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/e/elinks/elinks_0.13~20190125-2.dsc

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Stephen Gelman]

> On Feb 4, 2019, at 11:59 PM, Martín Ferrari  wrote:
> 
> On 05/02/2019 04:44, Stephen Gelman wrote:
> 
>> I have 0.34.1 almost ready to upload - just waiting on two deps to clear NEW.
> 
> Sorry to be a killjoy, but are you sure a new version is needed to solve
> this problem? We are very close to the freeze, and way too many packages
> depend on this. I am working now with other breakage coming from
> genproto, so maybe this can be fixed in a different -and less risky- way.
> 
> 
> -- 
> Martín Ferrari (Tincho)
> 

I totally understand your concern.  I’m at least a few backported bug fixes 
deep and I am concerned the resulting package will have had so many changes 
applied that it will be a bit of a mess.  As a middle ground, I think I can get 
0.9.0 patched for now with the intention of uploading a new version once we are 
out of hot water here.  Do you think that is reasonable?  I apologize if I 
didn’t communicate my intentions better here - I emailed pkg-go a while back 
but I neglected to respond to this bug (oversight on my part, sorry!).

Stephen

Bug#921024: apache2: DEP8 failure with 2.4.38-1: allowmethods.t

[Xavier]

Le 05/02/2019 à 00:14, Stefan Fritsch a écrit :
> On Thursday, 31 January 2019 19:16:06 CET Andreas Hasenack wrote:
>> Package: apache2
>> Version: 2.4.38-1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> The updated 2.4.38-1 package for apache2 triggered a DEP8 test failure:
>>
>> https://ci.debian.net/packages/a/apache2/unstable/amd64/
>>
>> >From https://ci.debian.net/data/autopkgtest/unstable/amd64/a/
> apache2/1808954/log.gz:
>> ...
>> # Failed test 10 in t/modules/allowmethods.t at line 44 fail #10
>> t/modules/allowmethods.t 
>> Failed 1/10 subtests
>>
>> The logs are sparse, to say the best, but this wasn't failing with
>> 2.4.37-1. Unfortunately I'm not familiar with this test suite and
>> cannot pinpoint which config apache2 was using at that time, nor which
>> request failed exactly.
>>
>> I was merging 2.4.38-1 into Ubuntu, and hit the same failure there.
> 
> 
> At the top of debian/tests/run-test-suite , there is:
> 
> # set to "-v t/modules/ext_filter.t ..." to run only a few test, but verbose
> TESTS=""
> 
> Changing that should give a bit more verbosity.
> 
> Also, the test frame work comes from a separate repository [1] and may need 
> to 
> be updated for new upstream releases. It's simply dumped into debian/perl-
> framework in the debian package. On the other hand, the diff between our 
> version and the current upstream version does not look like having to do 
> anything with allowmethods.
> 
> Another idea is that maybe our perl libs behave differently with redirects. 
> By 
> changing /reset to /reset/ in t/modules/allowmethods.t one could avoid the 
> redirect done by mod_directory.
> 
> I don't have time right now to try any of these. Maybe in the next few days. 
> If somebody else has time, go ahead.
> 
> Cheers,
> Stefan
> 
> [1]  https://svn.apache.org/repos/asf/httpd/test/framework/trunk

Thanks Stefan,

I didn't succeed to get the same autopkgtest results here using
autopkgtest LXC. Do you know how to reproduce debci environment ?

I updated also test framework environment (not yet pushed).

Cheers,
Xavier

Bug#785130: clamav-unofficial-sigs: Salsa link

[Brent Clark]

Package: clamav-unofficial-sigs
Followup-For: Bug #785130


Good Félix

Sorry for the late reply, here is my Salsa link 

https://salsa.debian.org/brentclark-guest/clamav-unofficial-sigs

HTH
Regards
Brent

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Martín Ferrari]

On 05/02/2019 04:44, Stephen Gelman wrote:

> I have 0.34.1 almost ready to upload - just waiting on two deps to clear NEW.

Sorry to be a killjoy, but are you sure a new version is needed to solve
this problem? We are very close to the freeze, and way too many packages
depend on this. I am working now with other breakage coming from
genproto, so maybe this can be fixed in a different -and less risky- way.


-- 
Martín Ferrari (Tincho)

Bug#921399: closed by Scott Kitterman (Re: ClamAV Needs (live-updates) on Post Install)

[Brian Holaday]

I will add this tad bit in my script. I just think that once the package is
installed:  freshclam needs to run for the first time before doing a scan
and gathers the latest definitions. I just would like to see output that it
happened then trust the daemon to run after just fine.

On Mon, Feb 4, 2019 at 9:57 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the clamav package:
>
> #921399: ClamAV Needs (live-updates) on Post Install
>
> It has been closed by Scott Kitterman .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Scott Kitterman <
> deb...@kitterman.com> by
> replying to this email.
>
>
> --
> 921399: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921399
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Scott Kitterman 
> To: 921399-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 05 Feb 2019 04:54:01 +
> Subject: Re: ClamAV Needs (live-updates) on Post Install
> On Mon, 4 Feb 2019 18:56:38 -0700 Brian Holaday 
> wrote:
> > Package: clamav
> > Version: 0.100.2+dfsg-0+deb9u1
> > Severity: important
> >
> > Issue: Kickstart an Update on Install
> > Upon completing the install would an update be needed for scanning like
> > shown below before scanning a directory?
> >
> > # KickStart Service (Needs Ran before Scan using Cron)
> > sudo service clamav-freshclam stop
> > sudo freshclam
> > sudo service clamav-freshclam start
>
> No.  Don't do that.  The system will handle it for you.
>
> Scott K
>
>
> -- Forwarded message --
> From: Brian Holaday 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 4 Feb 2019 18:56:38 -0700
> Subject: ClamAV Needs (live-updates) on Post Install
> Package: clamav
> Version: 0.100.2+dfsg-0+deb9u1
> Severity: important
>
> Issue: Kickstart an Update on Install
> Upon completing the install would an update be needed for scanning like
> shown below before scanning a directory?
>
> # KickStart Service (Needs Ran before Scan using Cron)
> sudo service clamav-freshclam stop
> sudo freshclam
> sudo service clamav-freshclam start
>

Bug#920368: texlive-pictures: tikz fails in pgf

[Henri Menke]

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

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

Kind regards, Henri

Bug#921408: RFS: python-bacpypes/0.17.5-1 [ITP]

[Rob Wiesler]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-bacpypes"

 * Package name: python-bacpypes
   Version : 0.17.5-1
   Upstream Author : Joel Bender
 * URL : https://github.com/JoelBender/bacpypes
 * License : Expat
   Section : python

It builds those binary packages:

python-bacpypes - BACnet application and network layer in Python
python3-bacpypes - BACnet application and network layer in Python

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/python-bacpypes

Alternatively, one can download the package with dget using this
command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-bacpypes/python-bacpypes_0.17.5-1.dsc

Changes since the last upload:

* Initial release (Closes: #921395)

Regards,
Rob Wiesler

Bug#921193: libmkl-rt: Octave returns wrong results when large arrays are multiplied

[Mo Zhou]

control: tags -1 +wontfix

Hi Ido,

As discussed in [1], I think this issue is not fixable because there
is no bug in either MKL or Octave. The GEMM computation error is just
because the clash between libgomp and libiomp.

If you need to use Octave against MKL, please set the environment
variable to switch threading model to GNU OpenMP or TBB:

  MKL_THREADING_LAYER=gnu
  MKL_THREADING_LAYER=tbb

Please don't set it as MKL_THREADING_LAYER=intel, which could cause
the original problem you described.

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

Bug#921319: stretch-pu: package iptables-persistent/1.0.4+nmu2

[gustavo panizzo]

hello

On Mon, Feb 04, 2019 at 05:05:25PM +0100, Bastian Blank wrote:

On Mon, Feb 04, 2019 at 10:55:26PM +0800, gustavo panizzo wrote:

On Mon, Feb 04, 2019 at 09:59:06AM +, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
>
> On 2019-02-04 08:11, gustavo panizzo wrote:
> > I'd like to fix the bug #921186 in stable, only adding a dependency to
> > iptables-persistent the bug can be closed
>
> The metadata for that bug suggests that the bug also affects the package
> in unstable, and is not yet fixed there - is that correct? If so, please
> fix the bug in unstable first; if not, please fix the metadata.
I've fixed the metadata, thanks


The bug is fixed differently in unstable?



After thinking on how I solved this issue in unstable (#794037,
#720110) I came up with another solution, similar to what's done in
unstable

Initially I didn't want to modify the scripts but the initial fix (add
kmod to deps) won't solve #720110 for the reporter, I think the current
proposed fix is better and the risk of regressions is low

debdiff attached


--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

diff -Nru iptables-persistent-1.0.4+nmu2/debian/changelog iptables-persistent-1.0.4+nmu3/debian/changelog
--- iptables-persistent-1.0.4+nmu2/debian/changelog	2017-03-18 21:11:49.0 +0800
+++ iptables-persistent-1.0.4+nmu3/debian/changelog	2019-02-03 19:18:27.0 +0800
@@ -1,3 +1,10 @@
+iptables-persistent (1.0.4+nmu3) stable; urgency=medium
+
+  * Non-maintainer upload
+  * Catch errors in calls to modprobe, thanks Hugo, Closes (#921186)
+
+ -- gustavo panizzo   Sun, 03 Feb 2019 19:18:27 +0800
+
 iptables-persistent (1.0.4+nmu2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru iptables-persistent-1.0.4+nmu2/plugins/15-ip4tables iptables-persistent-1.0.4+nmu3/plugins/15-ip4tables
--- iptables-persistent-1.0.4+nmu2/plugins/15-ip4tables	2017-03-18 21:11:49.0 +0800
+++ iptables-persistent-1.0.4+nmu3/plugins/15-ip4tables	2019-02-03 19:18:27.0 +0800
@@ -31,7 +31,7 @@
 {
 	#save IPv4 rules
 	#need at least iptable_filter loaded:
-	/sbin/modprobe -q iptable_filter
+	/sbin/modprobe -q iptable_filter || true
 	if [ ! -f /proc/net/ip_tables_names ]; then
 		echo "Warning: skipping IPv4 (no modules loaded)"
 	elif [ -x /sbin/iptables-save ]; then
diff -Nru iptables-persistent-1.0.4+nmu2/plugins/25-ip6tables iptables-persistent-1.0.4+nmu3/plugins/25-ip6tables
--- iptables-persistent-1.0.4+nmu2/plugins/25-ip6tables	2017-03-18 21:11:49.0 +0800
+++ iptables-persistent-1.0.4+nmu3/plugins/25-ip6tables	2019-02-03 19:18:27.0 +0800
@@ -31,7 +31,7 @@
 {
 	#save IPv6 rules
 	#need at least ip6table_filter loaded:
-	/sbin/modprobe -q ip6table_filter
+	/sbin/modprobe -q ip6table_filter || true
 	if [ ! -f /proc/net/ip6_tables_names ]; then
 		log_action_cont_msg "Warning: skipping IPv6 (no modules loaded)"
 	elif [ -x /sbin/ip6tables-save ]; then

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Stephen Gelman]

> On Jan 21, 2019, at 9:14 AM, Adrian Bunk  wrote:
> 
> Source: golang-google-cloud
> Version: 0.9.0-7
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-google-cloud.html
> 
> ...
> dh_auto_build
>   cd build && go install 
> -gcflags=all=\"-trimpath=/build/1st/golang-google-cloud-0.9.0/build/src\" 
> -asmflags=all=\"-trimpath=/build/1st/golang-google-cloud-0.9.0/build/src\" -v 
> -p 16 cloud.google.com/go cloud.google.com/go/bigquery 
> cloud.google.com/go/bigtable cloud.google.com/go/bigtable/bttest 
> cloud.google.com/go/bigtable/cmd/cbt 
> cloud.google.com/go/bigtable/cmd/emulator 
> cloud.google.com/go/bigtable/cmd/loadtest 
> cloud.google.com/go/bigtable/cmd/scantest 
> cloud.google.com/go/bigtable/internal/cbtconfig 
> cloud.google.com/go/bigtable/internal/gax 
> cloud.google.com/go/bigtable/internal/option 
> cloud.google.com/go/bigtable/internal/stat cloud.google.com/go/civil 
> cloud.google.com/go/compute/metadata cloud.google.com/go/container 
> cloud.google.com/go/datastore cloud.google.com/go/debugger/apiv2 
> cloud.google.com/go/errorreporting/apiv1beta1 cloud.google.com/go/errors 
> cloud.google.com/go/iam cloud.google.com/go/iam/admin/apiv1 
> cloud.google.com/go/internal cloud.google.com/go/internal/atomiccache 
> cloud.google.com/go/internal/fields cloud.google.com/go/internal/optional 
> cloud.google.com/go/internal/pretty cloud.google.com/go/internal/readme 
> cloud.google.com/go/internal/rpcreplay 
> cloud.google.com/go/internal/rpcreplay/proto/intstore 
> cloud.google.com/go/internal/rpcreplay/proto/rpcreplay 
> cloud.google.com/go/internal/testutil 
> cloud.google.com/go/internal/tracecontext 
> cloud.google.com/go/internal/version cloud.google.com/go/language/apiv1 
> cloud.google.com/go/language/apiv1beta2 cloud.google.com/go/logging 
> cloud.google.com/go/logging/apiv2 cloud.google.com/go/logging/internal 
> cloud.google.com/go/logging/internal/testing 
> cloud.google.com/go/logging/logadmin cloud.google.com/go/longrunning 
> cloud.google.com/go/longrunning/autogen cloud.google.com/go/monitoring/apiv3 
> cloud.google.com/go/profiler cloud.google.com/go/profiler/mocks 
> cloud.google.com/go/pubsub cloud.google.com/go/pubsub/apiv1 
> cloud.google.com/go/pubsub/loadtest cloud.google.com/go/pubsub/loadtest/cmd 
> cloud.google.com/go/pubsub/loadtest/pb cloud.google.com/go/spanner 
> cloud.google.com/go/spanner/admin/database/apiv1 
> cloud.google.com/go/spanner/admin/instance/apiv1 
> cloud.google.com/go/spanner/internal/testutil 
> cloud.google.com/go/speech/apiv1 cloud.google.com/go/speech/apiv1beta1 
> cloud.google.com/go/storage cloud.google.com/go/trace 
> cloud.google.com/go/trace/apiv1 cloud.google.com/go/translate 
> cloud.google.com/go/translate/internal/translate/v2 
> cloud.google.com/go/videointelligence/apiv1beta1
> src/cloud.google.com/go/speech/apiv1beta1/speech_client.go:29:2: cannot find 
> package "google.golang.org/genproto/googleapis/cloud/speech/v1beta1" in any 
> of:
>   
> /usr/lib/go-1.11/src/google.golang.org/genproto/googleapis/cloud/speech/v1beta1
>  (from $GOROOT)
>   
> /build/1st/golang-google-cloud-0.9.0/build/src/google.golang.org/genproto/googleapis/cloud/speech/v1beta1
>  (from $GOPATH)
> 

I have 0.34.1 almost ready to upload - just waiting on two deps to clear NEW.

Stephen

Bug#921390: bug found on debian installer for speech install option.

[Samuel Thibault]

Hello,

Fran Torres, le mar. 05 févr. 2019 00:56:01 +0100, a ecrit:
> because my language (spanish) is not supported on speech installer.

? It is. See the mention at the end of the menu: "Other choices are
available with '-' and '+'", so you can press '+' to get the second page
of choices.

> Also, the speakup screen reader crash on
> random form during installation (unrecoberable crash) and after
> installation, during locales with: dpkg-reconfigure locales.

I guess that was with the Catalan language choice?

Samuel

Bug#921407: RFP: python-srht-scm -- Shared support code for sr.ht source control services

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist

* Package name: python-srht-scm
  Version : 0.3.3
  Upstream Author : Drew DeVault ( @s...@cmpwn.com )
* URL : https://git.sr.ht/~sircmpwn/scm.sr.ht
* License : Affero GPL
  Programming Lang: python
  Description : Shared support code for sr.ht source control services

Source code support for sr.ht repositories, including webhook support.

Support for users, authorization, and more.

Bug#878121: Updates about BLAS64, co-installable variants

[Mo Zhou]

Hi Sébastien,

I'd like to update the proposal again. Alerted by the threading issue
about Octave+MKL, I changed my mind to make all variants co-installable
so any user would have a chance to switch them without installation/removal.
This proposal has been applied to BLIS (>= 0.5.1-8) already.

I believe this version of layout looks far much better.

And it must be pointed out that I've assigned BLIS variants with the
following priority numbers:

  blis-openmp 38
  blis-pthread 37
  blis-serial 36

= Package Contents =

~ ❯❯❯ ls /usr/lib/x86_64-linux-gnu/blis*
/usr/lib/x86_64-linux-gnu/blis64-openmp:
libblas64.so  libblas64.so.3  libblis64.a  libblis64.so  libblis64.so.2

/usr/lib/x86_64-linux-gnu/blis64-pthread:
libblas64.so  libblas64.so.3  libblis64.a  libblis64.so  libblis64.so.2

/usr/lib/x86_64-linux-gnu/blis64-serial:
libblas64.so  libblas64.so.3  libblis64.a  libblis64.so  libblis64.so.2

/usr/lib/x86_64-linux-gnu/blis-openmp:
libblas.so  libblas.so.3  libblis.a  libblis.so  libblis.so.2

/usr/lib/x86_64-linux-gnu/blis-pthread:
libblas.so  libblas.so.3  libblis.a  libblis.so  libblis.so.2

/usr/lib/x86_64-linux-gnu/blis-serial:
libblas.so  libblas.so.3  libblis.a  libblis.so  libblis.so.2

= Virtual packages ==

Package: libblis2-openmp,  Provides: libblas.so.3, libblis.so.2
Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
Package: libblis2-serial,  Provides: libblas.so.3, libblis.so.2
Package: libblis2 (meta),
Package: python3-numpy,Depends: libblas.so.3

The meta package is still necessary because of symbols/shlibdeps.
Different threading variants have the same ABI/API, so the dependency
template is written as

 libblis.so.2 libblis2 #MINVER#

instead of e.g.

 libblis.so.2 libblis2-openmp #MINVER#

= BLAS/BLAS64 alternatives 
===

~ ❯❯❯ update-alternatives --config libblas.so.3-x86_64-linux-gnu
There are 7 choices for the alternative libblas.so.3-x86_64-linux-gnu 
(providing /usr/lib/x86_64-linux-gnu/libblas.so.3).

  SelectionPath Priority   
Status

* 0/usr/lib/x86_64-linux-gnu/openblas/libblas.so.3   100   
auto mode
  1/usr/lib/x86_64-linux-gnu/atlas/libblas.so.3  35
manual mode
  2/usr/lib/x86_64-linux-gnu/blas/libblas.so.3   10
manual mode
  3/usr/lib/x86_64-linux-gnu/blis-openmp/libblas.so.338
manual mode
  4/usr/lib/x86_64-linux-gnu/blis-pthread/libblas.so.3   37
manual mode
  5/usr/lib/x86_64-linux-gnu/blis-serial/libblas.so.336
manual mode
  7/usr/lib/x86_64-linux-gnu/libmkl_rt.so1 
manual mode
  8/usr/lib/x86_64-linux-gnu/openblas/libblas.so.3   100   
manual mode

~ ❯❯❯ update-alternatives --config libblas64.so.3-x86_64-linux-gnu
There are 5 choices for the alternative libblas64.so.3-x86_64-linux-gnu 
(providing /usr/lib/x86_64-linux-gnu/libblas64.so.3).

  SelectionPath 
Priority   Status

  0/usr/lib/x86_64-linux-gnu/blis64-openmp/libblas64.so.338 
   auto mode
  1/usr/lib/x86_64-linux-gnu/blis64-openmp/libblas64.so.338 
   manual mode
  2/usr/lib/x86_64-linux-gnu/blis64-pthread/libblas64.so.3   37 
   manual mode
  3/usr/lib/x86_64-linux-gnu/blis64-serial/libblas64.so.336 
   manual mode
* 5/usr/lib/x86_64-linux-gnu/libmkl_rt.so1  
   manual mode


 BLIS/BLIS64 alternatives 


~ ❯❯❯ update-alternatives --config libblis.so.2-x86_64-linux-gnu
There are 3 choices for the alternative libblis.so.2-x86_64-linux-gnu 
(providing /usr/lib/x86_64-linux-gnu/libblis.so.2).

  SelectionPath Priority   
Status

* 0/usr/lib/x86_64-linux-gnu/blis-openmp/libblis.so.238
auto mode
  1/usr/lib/x86_64-linux-gnu/blis-openmp/libblis.so.238
manual mode
  2/usr/lib/x86_64-linux-gnu/blis-pthread/libblis.so.2   37
manual mode
  3/usr/lib/x86_64-linux-gnu/blis-serial/libblis.so.236
manual mode

~ ❯❯❯ update-alternatives --config libblis64.so.3-x86_64-linux-gnu
There are 3 choices for the alternative libblis64.so.3-x86_64-linux-gnu 
(providing /usr/lib/x86_64-linux-gnu/libblis64.so.2).

  SelectionPath 
Priority   Status

* 0  

Bug#921403: RFS: pyfltk/1.3.4.1-1 [ITP]

[Paul Wise]

On Tue, Feb 5, 2019 at 10:27 AM Robert Arkiletian wrote:

>   Alternatively, one can download the package with dget using this command:
>
> dget -x 
> https://mentors.debian.net/debian/pool/main/p/pyfltk/pyfltk_1.3.4.1-1.dsc

Here is a review:

>   More information about pyfltk can be obtained from https://www.example.com.

This appears to be incorrect :)

I'm not sure but I don't think Python documentation packages are meant
to be renamed when moving to Python 3. If you prefer to do so then
you'll need to rename the debian/python-fltk-doc.* files.

You have dropped debian/install, does the package still build
correctly without this?

You have changed the author in debian/patches/no_docs, which is meant
to indicate the author of the patch, not the current maintainer of the
package.

You have dropped debian/patches/platform_startswith, but I think that
should have been updated to apply to the new version instead.

The debian/changelog file has UNRELEASED at the top but it should have unstable.

debian/changelog is missing other changes that have been made to the package.

I suggest using the debhelper-compat mechanism instead of
debian/compat, and using debhelper compat level 12 instead of 10. I
chose 12 because that is the latest version of debhelper in Debian
backports. You also have a different version in debian/compat and the
debian/control Build-Depends, they should be the same (or just switch
to using debhelper-compat to avoid the version duplication).

https://manpages.debian.org/unstable/debhelper/debhelper.7.en.html#COMPATIBILITY_LEVELS

You have opted to bump the Python dependency versions to 3.7, does
pyfltk really need such a high version of Python? Using inflated
dependency versions limits backportability of the package.

You will need to unarchive and re-open the bugs closed in a +rm
version here, and then close them in debian/changelog if the version
you are uploading fixes those bugs. Seems like #866915 has been fixed
and #849973 would be easy to fix.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=pyfltk

I'm guessing python3-fltk-dbg can be dropped in favour of the
automatic debug symbols packages.

https://wiki.debian.org/AutomaticDebugPackages

You have removed the Standards-Version from debian/control, please
restore it, read the upgrading checklist, make any changes needed and
then update Standards-Version to the version of Debian Policy that the
package complies with.

https://www.debian.org/doc/debian-policy/upgrading-checklist

I think override_dh_strip can be removed from debian/control if it
isn't going to be used.

I suggest running this command to make diffs of the Debian packaging
easier to read:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma --dry-run

The debian/watch file doesn't work:

https://qa.debian.org/watch/sf.php/pyfltk/

$ uscan --verbose

scan info: Newest version of pyfltk on remote site is 1.3.0, local
version is 1.3.4.1
uscan info:=> Only older package available from
  https://qa.debian.org/watch/sf.php/pyfltk/pyFltk-1.3.0.tar.gz

Automated checks:

lintian: lots of warnings/errors

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#921400: closed by Scott Kitterman (Re: [Pkg-clamav-devel] Bug#921400: ClamAV tosses error on notifications)

[Brian Holaday]

Great Scott,

I will treat this as a error message (warning) that is suppressed. Are you
able to confirm exactly what clamav-daemon can be used for is this better
to set up or leave clamav running as a daemon by default: what benefit does
it have over using clamav.

On Mon, Feb 4, 2019 at 7:51 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the clamav package:
>
> #921400: ClamAV tosses error on notifications
>
> It has been closed by Scott Kitterman .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Scott Kitterman <
> deb...@kitterman.com> by
> replying to this email.
>
>
> --
> 921400: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921400
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Scott Kitterman 
> To: 921400-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 04 Feb 2019 21:47:04 -0500
> Subject: Re: [Pkg-clamav-devel] Bug#921400: ClamAV tosses error on
> notifications
> On Monday, February 04, 2019 07:06:37 PM Brian Holaday wrote:
> > Package: clamav
> > Version: 0.100.2+dfsg-0+deb9u1
> > Severity: normal
> >
> > Step #1: Run Update
> > # sudo freshclam
> >
> > Step #2: Error is shown:
> > "Clamd was NOT notified: Can't connect to clamd through
> > /var/run/clamav/clamd.ctl: No such file or directory"
> >
> > Looking at a fix looks like it may be this:
> > # clamav is dependent of clamav-daemon
> >
> > I have yet to test this however to see if the issue resolves itself :
> seems
> > like on a fresh install this happens.
>
> None of this is a bug.
>
> In Debian, freshclam is configured to run as a daemon.  You do not need to
> run
> it manually.  In any case, all the 'error' means is that clamd isn't
> running.
> If you haven't either installed clamav-daemon or you've stopped it, then
> that's normal.
>
> Scott K
>
>
> -- Forwarded message --
> From: Brian Holaday 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 4 Feb 2019 19:06:37 -0700
> Subject: ClamAV tosses error on notifications
> Package: clamav
> Version: 0.100.2+dfsg-0+deb9u1
> Severity: normal
>
> Step #1: Run Update
> # sudo freshclam
>
> Step #2: Error is shown:
> "Clamd was NOT notified: Can't connect to clamd through
> /var/run/clamav/clamd.ctl: No such file or directory"
>
> Looking at a fix looks like it may be this:
> # clamav is dependent of clamav-daemon
>
> I have yet to test this however to see if the issue resolves itself :
> seems like on a fresh install this happens.
>
>

Bug#921374: libfreerdp2-2: Fails to connect Windows 7 x64 using NLA

[Omer Oz]

Hi,

Yes, this is the case indeed. Moreover, installing KB4487345 on the remote
host
solved the issue. Thank you for your time and prompt help (especially for
something not really an issue caused by freerdp!)

Best,
Omer

Bug#921406: haskell-juicypixels: -O0 also for mips64 mips64r6 mips64r6el

[YunQiang Su]

Package: src:haskell-juicypixels
Version: 3.2.9.5-4

Please also use -O0 for mips64 mips64r6 mips64r6el.
The bug of ghc also exists on these architectures.

-- 
YunQiang Su

Bug#921405: RFS: pyfltk/1.3.4.1-1 [ITA]

[Robert Arkiletian]

Package: sponsorship-requests
  Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

  I am looking for a sponsor for my package "pyfltk". Sorry this is my
second post. I failed to set it as ITA. This package use to be in
Debian but was orphaned. I am looking to pick it up as the new
maintainer but need a sponsor. I am a high school CS teacher who needs
the package for my students.

 * Package name: pyfltk
   Version : 1.3.4.1-1
   Upstream Author : Andreas Held
 * URL : http://pyfltk.sourceforge.net/
 * License : LGPL
   Section : python

  It builds those binary packages:

python3-fltk - Python wrapper for the Fast Light Toolkit
python3-fltk-doc - Documentation for pyFltk
python3-fltk-dbg - Python wrapper for the Fast Light Toolkit - Debugging symbols

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/pyfltk


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/pyfltk/pyfltk_1.3.4.1-1.dsc

  More information about pyfltk can be obtained from
http://pyfltk.sourceforge.net/


  Regards,
   Robert Arkiletian

Bug#921404: gdb: can't debug kdesu (cannot find user-level thread ...)

[Jiri Palecek]

Package: gdb
Version: 8.0-1
Severity: normal

Dear Maintainer,

I have problems debugging kdesu with gdb. Debugging fails with this
message:

$ gdb /usr/lib/i386-linux-gnu/libexec/kf5/kdesu
GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/i386-linux-gnu/libexec/kf5/kdesu...Reading 
symbols from 
/usr/lib/debug/.build-id/d8/59440907cb9b64a346797293b75d544beba51c.debug...done.
done.
(gdb) break SuProcess::exec
Breakpoint 1 at 0x4540
(gdb) run ls
Starting program: /usr/lib/i386-linux-gnu/libexec/kf5/kdesu ls
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Cannot find user-level thread for LWP 7254: generic error

I have tried googling for some solutions, but found nothing that turned
out to be of value. Also, all reports of similar problems turned out to
be rather old.

Please note that kdesu is normal program, not suid or something.

Regards
Jiri Palecek

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

Kernel: Linux 4.20.0-trunk-686-pae (SMP w/2 CPU cores)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdb depends on:
pn  libbabeltrace-ctf1  
ii  libbabeltrace1  1.5.6-1
ii  libc6   2.28-4
ii  libexpat1   2.2.6-1
ii  liblzma55.2.2-1.3
pn  libncurses5 
pn  libpython3.5
ii  libreadline77.0-5
pn  libtinfo5   
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.28-4

Versions of packages gdb suggests:
ii  gdb-doc8.2-1
pn  gdbserver  

Bug#921402: plymouth hide-message does not work

[Ben Hutchings]

Package: plymouth
Version: 0.9.4-1
Severity: normal
Tags: upstream

"plymouth hide-message --text=" has no effect
when using a framebuffer.  I assume it has no effect in text mode
either.

Ben.

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

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

Versions of packages plymouth depends on:
ii  init-system-helpers  1.56+nmu1
ii  initramfs-tools  0.133~1.gbp35238c
ii  libc62.28-5
ii  libdrm2  2.4.97-1
ii  libplymouth4 0.9.4-1
ii  lsb-base 10.2018112800
ii  systemd  240-4
ii  udev 240-4

plymouth recommends no packages.

Versions of packages plymouth suggests:
ii  desktop-base 9.0.7
ii  plymouth-themes  0.9.4-1

-- Configuration Files:
/etc/plymouth/plymouthd.conf changed [not included]

-- no debconf information

Bug#921403: RFS: pyfltk/1.3.4.1-1 [ITP]

[Robert Arkiletian]

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "pyfltk". I am a high
school Computer Science teacher. I teach gui programming with pyfltk
so I want to get the package back into Debian.

 * Package name: pyfltk
   Version : 1.3.4.1-1
   Upstream Author : Andreas Held
 * URL : http://pyfltk.sourceforge.net/
 * License : GNU Library General Public License
   Section : python

  It builds those binary packages:

python3-fltk - Python wrapper for the Fast Light Toolkit
python3-fltk-doc - Documentation for pyFltk
python3-fltk-dbg - Python wrapper for the Fast Light Toolkit - Debugging symbols

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/pyfltk


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/pyfltk/pyfltk_1.3.4.1-1.dsc

  More information about pyfltk can be obtained from https://www.example.com.


  Regards,
   Robert Arkiletian

Bug#921401: RM: prelink -- ROM, dead upstream

[Geoffrey Thomas]

Package: ftp.debian.org
Severity: normal

Hi ftp-master,

Please remove src:prelink - the package is unmaintained upstream (no 
releases or SVN commits since 2013) and was removed from Fedora (where the 
upstream maintainer was packaging it) several releases ago. It has a bad 
habit of breaking binaries (see open bugs) and I don't think there's 
enough of a development community to really fix it; the remaining bugs 
likely require very arcane ELF magic to resolve properly.


There are two binary packages, prelink and execstack. I don't think 
execstack is of much use by itself, espcially because any build scripts 
etc. using execstack can generally be replaced with the linkerflag 
-Wl,-z,noexecstack (or execstack, whichever you need). But if someone's 
interested I can try to split it out of the prelink source package. 
(Fedora currently has an "execstack" source package from the prelink 
tarball, but I think they care more than we do because SELinux blocks 
programs with executable stacks by default.)


--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com

Bug#884834: non-github repository

[Jeffrey Cliff]

now that Hilko isn't working on packaging this anymore, an
non-NSA/Microsoft controlled upstream repository is also available at
https://notabug.org/makenotabuggreatagain/gulp-less/

Bug#886640: followup

[Jeffrey Cliff]

As with #884834, over a year ago you expressed interest in packaging
node-accord - are you also no longer packing this as well?
Thanks,
Jeff Cliff

Bug#921400: ClamAV tosses error on notifications

[Brian Holaday]

Package: clamav
Version: 0.100.2+dfsg-0+deb9u1
Severity: normal

Step #1: Run Update
# sudo freshclam

Step #2: Error is shown:
"Clamd was NOT notified: Can't connect to clamd through
/var/run/clamav/clamd.ctl: No such file or directory"

Looking at a fix looks like it may be this:
# clamav is dependent of clamav-daemon

I have yet to test this however to see if the issue resolves itself : seems
like on a fresh install this happens.

Bug#921399: ClamAV Needs (live-updates) on Post Install

[Brian Holaday]

Package: clamav
Version: 0.100.2+dfsg-0+deb9u1
Severity: important

Issue: Kickstart an Update on Install
Upon completing the install would an update be needed for scanning like
shown below before scanning a directory?

# KickStart Service (Needs Ran before Scan using Cron)
sudo service clamav-freshclam stop
sudo freshclam
sudo service clamav-freshclam start

Bug#910004: RFS: apache-opennlp/1.9.0-1 [ITP] -- machine learning based toolkit for the processing of natural language text

[Mo Zhou]

On Mon, Feb 04, 2019 at 03:33:56PM +0200, Andrius Merkys wrote:
> Updated. Could you please try building the package once more?

It compiles now:

http://debomatic-amd64.debian.net/distribution#unstable/apache-opennlp/1.9.1-1/buildlog

However I guess you didn't install all the opennlp components:

http://debomatic-amd64.debian.net/distribution#unstable/apache-opennlp/1.9.1-1/contents
-rw-r--r-- root/root   1236603 2019-02-04 14:04 
./usr/share/java/opennlp-tools.jar
-rw-r--r-- root/root 66535 2019-02-04 14:04 
./usr/share/java/opennlp-uima.jar

I think the expected package content list should contain .jar files for
all these modules:

opennlp-brat-annotator
opennlp-distr
opennlp-docs
opennlp-morfologik-addon
opennlp-tools
opennlp-uima

Besides, there are also some wrapper scripts under several directories.
Are they omitted intentionally?

❯❯❯ find . -type d -name bin
./opennlp-tools/bin
./opennlp-brat-annotator/src/main/bin
./opennlp-morfologik-addon/bin
./opennlp-morfologik-addon/src/main/bin
./opennlp-distr/src/main/bin

Bug#914081: stretch-pu: package jdupes/1.7-2

[Eriberto]

Em seg, 4 de fev de 2019 às 19:29, Adam D. Barratt
 escreveu:
>
> Control: tags -1 + confirmed
>
> On Mon, 2018-11-19 at 01:11 -0200, Joao Eriberto Mota Filho wrote:
> > From the jdupes upstream:
> >
> > "All versions from 1.5.1 up to 1.7 have potentially serious bugs in
> > the internal memory allocator which caused crashes on Debian ARM and
> > macOS Sierra. These should be updated to a minimum of v1.8 if at all
> > possible.
> >
> > If that isn't possible, the following commits improving/fixing the
> > internal memory allocator should be patched into the old versions:
>
> Please go ahead; sorry for the delay.

Hi Adam,

Uploaded. Thanks!

Regards,

Eriberto

Bug#884834: followup

[Hilko Bengen]

control: retitle -1 RFP: node-gulp-less -- Gulp extension for using the LESS 
CSS compiler

* Jeffrey Cliff:

> over a year ago you expressed interest in packaging node-gulp-less -
> are you still working on packaging this?  Are you stuck on anything?

No, I'm not.

Cheers,
-Hilko

Bug#921398: ClamAV Needs Updated

[Brian Holaday]

Package: clamav
Version: 0.100.2+dfsg-0+deb9u1

Issue #1: Update to 0.101.1
Upon installation of clamav - running freshclam shows that the local
version is: 0.100.2 and updated version is 0.101.1.

Issue #2: Kickstart an Update on Install
Upon completing the install would an update be needed for scanning files
like shown below?

# KickStart Service (Needs Ran before Scan using Cron)
sudo service clamav-freshclam stop
sudo freshclam
sudo service clamav-freshclam start

Thanks!

Bug#921397: Data::Dumper has a repeated default mentioned

[積丹尼 Dan Jacobson]

Package: perl-doc
Version: 5.28.1-4
Severity: minor
File: /usr/share/man/man3/Data::Dumper.3perl.gz


We read
   structure is simply indented by a fixed amount of whitespace).  
Style 2 (the default) outputs a very readable

^^^
   form which takes into account the length of hash keys (so the hash 
value lines up).  Style 3 is like style 2,
   but also annotates the elements of arrays with their index (but the 
comment is on its own line, so array output
   consumes twice the number of lines).  Style 2 is the default.
 ^^
OK but you already mentioned that.

Bug#700576: cowsay: Please add a kangaroo cow

[Matthew Kraai]

Hi Paul,

On Sun, Feb 03, 2019 at 09:59:40AM -0800, Paul Hardy wrote:
> This patch changes the version of the kangaroo cow salsa merge from an
> NMU, "-5.1", to a QA upload, "-6" (because the package is orphaned)
> and makes the kangaroo cow license "GPL-2+".

Thanks for the patch and the tarball.  I uploaded yesterday but I
forgot to pass "-s" to sbuild so the upload was rejected.  I've just
tried again.  Hopefully it will work this time.

-- 
Matt

Bug#921396: Data::Dumper AUTHOR email does not exist, says google

[積丹尼 Dan Jacobson]

Package: perl-doc
Version: 5.28.1-4
Severity: minor
File: /usr/share/man/man3/Data::Dumper.3perl.gz

Man page says

   AUTHOR
   Gurusamy Sarathyg...@activestate.com

Alas,

: host aspmx.l.google.com[74.125.195.27] said: 550-5.1.1
The email account that you tried to reach does not exist.

Bug#884834: followup

[Jeffrey Cliff]

over a year ago you expressed interest in packaging node-gulp-less -
are you still working on packaging this?  Are you stuck on anything?
Thanks,
Jeff Cliff

Bug#877455: xdo: diff for NMU version 0.5.7-1.1

[Nobuhiro Iwamatsu]

Hi,

I think that you forgot NMU this package.
Could you tell me the status of this?

Best regards,
  Nobuhiro

> Dear maintainer,
>
> I've prepared an NMU for xdo (versioned as 0.5.7-1.1) and
> uploaded it to DELAYED/15. Please feel free to tell me if I
> should delay it longer.
>
> Sorry if anything is wrong about this upload, I haven't
> done anything like it before. I'm not sure if the package
> actually made it to DELAYED, let me know if you cannot see
> it.
>
> All I needed to do was run the uupdate script to update
> the package, and verify the new version worked as expected.
>
> Regards.
> -Jay

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

Bug#921286: duplicate?

[Jeffrey Cliff]

For what it's worth there is a RFP for this at #890567

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890567

Bug#921394: override: gtkmm2.4:oldlibs/optional

[Simon McVittie]

Package: ftp.debian.org
Severity: normal

gtkmm2.4 is a C++ wrapper for GTK+ 2, and has been superseded by gtkmm3.0, a
similar C++ wrapper for GTK+ 3.

Please move libgtkmm-2.4-dev (currently in libdevel), libgtkmm-2.4-1v5
(currently in libs) and optionally libgtkmm-2.4-doc (currently in doc)
into the oldlibs section.

(We cannot remove gtkmm2.4 in the foreseeable future, because inkscape
currently still depends on it, but new code should be discouraged from
using GTK+ 2.)

Thanks,
smcv

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Dragan Milenkovic]

I have tracked the issue to this change:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/block/blk-flush.c?id=344e9ffcbd1898e1dc04085564a6e05c30ea8199

The commit log message makes it seem that it is a refactoring change, 
but it inverts the sign on q->elevator test. It should have been 
documented as a bug fix and backported to stable branches.

The line was not further modified in the "master" branch.

I have rebuilt 4.19 from Debian testing with this change, and my system 
now works correctly.


In my opinion, it also relates to #913138 and maybe #904822.

Dragan

Bug#921393: adequate reports obsolete-conffile for lxqt-branding-debian package

[shirish शिरीष]

Package: lxqt-branding-debian
Version: 0.14.0
Severity: normal
User: debian...@lists.debian.org
Usertags : obsolete-conffile adequate

Dear Maintainer,

While I was updating/installing lxqt-branding-debian package adequate
informs me the following -

adequate found packaging bugs
-

lxqt-branding-debian: obsolete-conffile /etc/xdg/lxqt/windowmanagers.conf
lxqt-branding-debian: obsolete-conffile /etc/xdg/lxqt/notifications.conf
lxqt-branding-debian: obsolete-conffile /etc/xdg/lxqt/lxqt-runner.conf
lxqt-branding-debian: obsolete-conffile /etc/xdg/lxqt/lxqt-powermanagement.conf

Could you please fix the above.

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

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

Versions of packages lxqt-branding-debian depends on:
ii  desktop-base9.0.7
ii  gnome-themes-extra  3.28-1
ii  lxqt-theme-debian   0.14.0
ii  oxygen-icon-theme   5:5.54.0-1
ii  papirus-icon-theme  20190106-1
ii  xfwm4-theme-breeze  0.1.0-4
ii  xsettingsd  0.0.20171105+1+ge4cf9969-1

lxqt-branding-debian recommends no packages.

lxqt-branding-debian suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#820838: os-prober: 40grub2 does not handle multiple initrd paths

[sancho . san]

Hi,
 
I had the same problem after installing Mint 19 on PCLOS, the new grub.cfg 
initrd line had only the microcode part. Missing the /boot/initrd.img leads to 
kernel panic. 
The linux.boot-prober also reports only the first part, the microcode update.
Is the problem really the caret?

 

On Thu, 23 Feb 2017 10:56:22 +0100 Johannes Rohr  wrote:
> Package: os-prober
> Version: 1.74
> Followup-For: Bug #820838
> 
> I've tested the patch. The initrd stanza generated is not totally correct:
> 
> іnitrd /boot/intel-ucode.img^/boot/initramfs-linux-pf.img
> 
> (note the ^ where there should be a blank)
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages os-prober depends on:
> ii  dmsetup  2:1.02.137-1
> ii  grub-common  2.02~beta3-5
> ii  libc62.24-9
> 
> os-prober recommends no packages.
> 
> os-prober suggests no packages.
> 
> -- no debconf information
 

Bug#657707: [initramfs-tools] modules for initrd are not stripped

[Ben Hutchings]

On Sat, 28 Jan 2012 08:34:31 +0100 =?utf-8?q?Micha=C5=82_Miros=C5=82aw?= 
 wrote:
> Package: initramfs-tools
> Version: 0.99
> Severity: normal
> 
> --- Please enter the report below this line. ---
> 
> Please add an option (possibly defaulted to on) to strip kernel modules and 
> binaries put in initrd. When using kernel with debugging enables the 
> unstripped modules are available in /lib/modules. Unneeded copy of the 
> symbols 
> in initrd image take over 80% of its size.
[...]

We must not do this by default because stripping will destroy module
signatures.  I'm open to adding an option but won't work on it myself.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.





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

Bug#921392: mtd-utils: Please update to 2.0.2

[Nobuhiro Iwamatsu]

Package: mtd-utils
Version: 1:2.0.1-1
Severity: wishlist

Dear Maintainer,

mtd-utils verison 2.0.2 has been released.
Could you update to 2.0.2?

Best regards,
  Nobuhiro

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

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

Versions of packages mtd-utils depends on:
ii  libc6  2.28-5
ii  liblzo2-2  2.10-0.1
ii  libuuid1   2.33.1-0.1
ii  zlib1g 1:1.2.11.dfsg-1

mtd-utils recommends no packages.

mtd-utils suggests no packages.

-- no debconf information

Bug#921391: radare2-cutter: incorrect homepage link

[Paul Wise]

Package: radare2-cutter
Severity: minor

The current homepage points at the main radare2 website but it should
point at one of the two homepages for cutter:

https://www.radare.org/cutter/
https://radareorg.github.io/cutter/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#921390: bug found on debian installer for speech install option.

[Fran Torres]

package: Debian-Installer
Version: 10.0alpha5

Hello,

I found a possible bug on debian installer (buster) in alpha5. In this
session of install, i can't atach none documentation (logs) because
the probability of speakup screen reader crashes is very upper.

In this session, i can complete installation sucessfully usin a
catalan language; because my language (spanish) is not supported on
speech installer.
***report start***
Boot method: Image iso-dvd amd64, DI-alfa5.
Image version: Debian buster 10.0,
ftp://cdimage.debian.org/cdimage/buster-di-alpha5/amd64/iso-dvd/debian-buster-DI-alpha5-DVD1.iso.
date: 2019-02-04-20:44 CET-UTC+1
Machine description (motherboard onli): Asus A75Pro4-FM. On vmWare
Workstation Pro 15.0.2 based.
processor: AMD APU A4-5330+APU, 3,3GHZ.
Memory: 12GB RAM-DDR3
partition: Not partitioned, the first point is marked as OK/ERR (OK
with errors), because the one or more languages (on speech install) is
missing and speakup crashes during installation process.
output of lspci -knn/lspci -nn: Not available.

  Base checklist.
Initial boot=o.
detect boot card=o
configure network=o
Detect CD:  [ ]=o
Load installer modules: [ ]=o
Detect hard drives: [ ]=o
Partition hard drives:  [ ]=o
Install base system:[ ]=o
Clock/timezone setup:   [ ]=o
User/password setup:[ ]=o
Install tasks:  [ ]=o
Install boot loader:[ ]=o
Overall install:[ ]=o
Comments/Problems: The spanish and another languages is missing during
installation. In graphical install is supported more than 70 languages
but, in speech install onli supported 29 when in jessie are supported
more than 70 languages too. Also, the speakup screen reader crash on
random form during installation (unrecoberable crash) and after
installation, during locales with: dpkg-reconfigure locales.
ideas to add during initial install: please, include all languages on
speech install, the same languages are included on a graphical
install.
***report end***

Fran.

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Bernhard Übelacker]

Am 04.02.19 um 13:42 schrieb Didier 'OdyX' Raboud:
> Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :
>> If such a system is detected, maybe a warning could be added?
> 
> Sure. I suggest this would be done very early, but have no clue how to detect 
> such a system. This would also make sense in time for buster. Could you work 
> on a patch? Thomas; an idea?

A short search led to function kernel32!GetFirmwareType [1].
That is said to be supported since windows 8.

This function is already used in include/bootcfg.nsh, but
can not see any user, maybe just a preparation for future use ...

Kind regards,
Bernhard

[1] 
https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getfirmwaretype

Bug#921388: RFP: node-taffydb -- JavaScript Database for your browser

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-taffydb
  Version : 2.7.3
  Upstream Author : @biastoact@birdsite 
* URL : https://notabug.org/makenotabuggreatagain/taffydb
* License : MIT
  Programming Lang: Javascript
  Description : Database for your browser

"Have you ever noticed how JavaScript object literals look a lot like
records? And that if you wrap a group of them up in an array you have
something that looks a lot like a database table? We did too. We
created TaffyDB easily and efficiently manipulate these 'tables'
with a uniform and familiar SQL-like interface.

We use TaffyDB instead of ad-hoc data manipulation routines throughout
our applications. This reduces development time, improves performance,
simplifies maintenance, and increases quality."

TaffyDB is a prerequisite to jsdoc ( #774565 ).

Bug#921024: apache2: DEP8 failure with 2.4.38-1: allowmethods.t

[Stefan Fritsch]

On Thursday, 31 January 2019 19:16:06 CET Andreas Hasenack wrote:
> Package: apache2
> Version: 2.4.38-1
> Severity: normal
> 
> Dear Maintainer,
> 
> The updated 2.4.38-1 package for apache2 triggered a DEP8 test failure:
> 
> https://ci.debian.net/packages/a/apache2/unstable/amd64/
> 
> >From https://ci.debian.net/data/autopkgtest/unstable/amd64/a/
apache2/1808954/log.gz:
> ...
> # Failed test 10 in t/modules/allowmethods.t at line 44 fail #10
> t/modules/allowmethods.t 
> Failed 1/10 subtests
> 
> The logs are sparse, to say the best, but this wasn't failing with
> 2.4.37-1. Unfortunately I'm not familiar with this test suite and
> cannot pinpoint which config apache2 was using at that time, nor which
> request failed exactly.
> 
> I was merging 2.4.38-1 into Ubuntu, and hit the same failure there.


At the top of debian/tests/run-test-suite , there is:

# set to "-v t/modules/ext_filter.t ..." to run only a few test, but verbose
TESTS=""

Changing that should give a bit more verbosity.

Also, the test frame work comes from a separate repository [1] and may need to 
be updated for new upstream releases. It's simply dumped into debian/perl-
framework in the debian package. On the other hand, the diff between our 
version and the current upstream version does not look like having to do 
anything with allowmethods.

Another idea is that maybe our perl libs behave differently with redirects. By 
changing /reset to /reset/ in t/modules/allowmethods.t one could avoid the 
redirect done by mod_directory.

I don't have time right now to try any of these. Maybe in the next few days. 
If somebody else has time, go ahead.

Cheers,
Stefan

[1]  https://svn.apache.org/repos/asf/httpd/test/framework/trunk

Bug#910902: Mariadb provides my_print_defaults not anymore at mariadb-server-core

[Sandro Knauß]

Control: reassign -1 mariadb-server 1:10.3.12-2
Control: affects -1 akonadi-backend-mysql
Control: severity -1 serious

Hey,

mariadb moved my_print_defaults from mysql-server-core to mariadb-server.
So akonadi-backend-mysql do now need to depend at mariadb-server. As 
"my_print_defaults" is only needed at first start of akonadi it is a pity if we 
would that for now rely on a full istalled mariadb-server. Can you please 
clearify why this move was done?

hefee




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

Bug#921373: RFS: codelite [QA] -- Powerful and lightweight IDE

[Adam Borowski]

On Mon, Feb 04, 2019 at 05:11:40PM +, David Hart wrote:
>   * Package name: codelite
> Version : 12.0+dfsg-1

> Changes since the last upload:
> 
> codelite (12.0+dfsg-1) unstable; urgency=medium
> 
>   * QA upload.
> 
>   * New upstream release.
> 
>   * debian/codelite-plugins.install:
> - Install new plugins.
>   * debian/copyright:
> - Add copyright for new plugin.
> - Update copyright dates.
>   * debian/patches:
> - Refresh patches.
> - Backport a fix for LLDB terminal crashes.
> - Fix 3 more spelling mistakes.
>   * debian/control:
> - Bump standards to 4.3.0.
>   * debian/compat:
> - Use debhelper 11.
>   * debian/watch:
> - Add oversionmangle for +dfsg

Your upload would remove the last changelog entry, could you please fix
that?  Otherwise, I see no problems so far.

The issue with VCS would be nice to solve but is not a showstopper.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#915103: Apache2 HTTP/2 connection problems with Safari clients

[Stefan Fritsch]

Hi Philip,

sorry for the late respone, I have been quite busy with other things.

I could find no indication that any other upstream release has the same bug. 
Therefore I hope that adding more fixes from upstream versions up to the 
version from where I took the security fixes (2.4.34 and 2.4.35) should fix the 
issue. That's how I picked the first patch I have sent you. There is one other 
commit that may fit. A new patch is applied (leave out the first patch I sent).

If that does not work we need to find a more targeted approach. You could try 
increasing the http2 log level  and see if there are any log messages that 
appear only when safari gives the error message. You could try a quite high 
log level like

  loglevel http2:trace1

or even trace2.

Cheers,
Stefan
diff --git a/debian/patches/http2-r1832566.diff b/debian/patches/http2-r1832566.diff
new file mode 100644
index 00..7ce7335100
--- /dev/null
+++ b/debian/patches/http2-r1832566.diff
@@ -0,0 +1,43 @@
+--- apache2.orig/modules/http2/h2_conn.c
 apache2/modules/http2/h2_conn.c
+@@ -240,7 +240,19 @@ apr_status_t h2_conn_run(struct h2_ctx *
+  && mpm_state != AP_MPMQ_STOPPING);
+ 
+ if (c->cs) {
+-c->cs->state = CONN_STATE_LINGER;
++switch (session->state) {
++case H2_SESSION_ST_INIT:
++case H2_SESSION_ST_IDLE:
++case H2_SESSION_ST_BUSY:
++case H2_SESSION_ST_WAIT:
++c->cs->state = CONN_STATE_WRITE_COMPLETION;
++break;
++case H2_SESSION_ST_CLEANUP:
++case H2_SESSION_ST_DONE:
++default:
++c->cs->state = CONN_STATE_LINGER;
++break;
++}
+ }
+ 
+ return APR_SUCCESS;
+--- apache2.orig/modules/http2/h2_version.h
 apache2/modules/http2/h2_version.h
+@@ -27,7 +27,7 @@
+  * @macro
+  * Version number of the http2 module as c string
+  */
+-#define MOD_HTTP2_VERSION "1.10.16"
++#define MOD_HTTP2_VERSION "1.10.20"
+ 
+ /**
+  * @macro
+@@ -35,7 +35,7 @@
+  * release. This is a 24 bit number with 8 bits for major number, 8 bits
+  * for minor and 8 bits for patch. Version 1.2.3 becomes 0x010203.
+  */
+-#define MOD_HTTP2_VERSION_NUM 0x010a10
++#define MOD_HTTP2_VERSION_NUM 0x010a14
+ 
+ 
+ #endif /* mod_h2_h2_version_h */
diff --git a/debian/patches/series b/debian/patches/series
index 014d958573..21ff3c5da4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -30,3 +30,4 @@ mod_http2_mem_usage_32bit.diff
 fcgi_crash.diff
 CVE-2018-1333-mod_http2_DoS.diff
 CVE-2018-11763-mod_http2_DoS-SETTINGS.diff
+http2-r1832566.diff

Bug#920139: sddm: GTK and GNOME: Applications won't launch due error of glib2

[Bernhard Übelacker]

Control: tags 920139 + moreinfo


Hello Adrian,

Am 03.02.19 um 09:24 schrieb Adrian Immanuel Kiess:
> The bug is, like I see it, that the applications cannot find the
> gsettings schema directory.

>From my point of view it might be more the file gschemas.compiled
inside that directory. Does that exist on your system?

> When setting export GSETTINGS_SCHEMA_DIR="/usr/share/glib-2.0/schemas/" 
> in my .xinitrc I can launch GTK and GNOME applications when the
> xsession ist started with startx.
> 
> Therefor setting GSETTINGS_SCHEMA_DIR in /etc/environment maybe fixes 
> the issue, which I have not tried yet.

My previous test was inside a minimal buster amd64 VM where I installed
just "systemd-coredump xserver-xorg sddm gnome-session" and there I can
login in sddm to a "GNOME on Xorg" session without showing that problem.
I searched that VM and could find no file setting that environment.

I tried renaming that file gschemas.compiled and setting the environment
like you did - but I still got the trap.

Therefore you might also install a coredump collector
like systemd-coredump.
That way after such an unsuccessful logon attempt you can list with:

coredumpctl list

And produce an exact backtrace in which function that error is
thrown by this command:

coredumpctl gdb [PID]
bt

Best would be if debug symbol packages
gnome-session-bin-dbgsym libglib2.0-0-dbgsym
are installed like described in [1].

> Shall I resubmit the bug against gsettings-desktop-schemas package?

If you mean with resumit to create a new bug, that should not be needed
as this bug can be reassigned to another package too.
Which version of package gsettings-desktop-schemas have you installed?

dpkg -l | grep gsettings-desktop-schemas

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Bug#921387: UI on HIDPI too small

[Toni]

Package: libreoffice
Version: 1:6.1.5~rc1-2
Severity: normal
Tags: a11y


Hi,

on my HIDPI display, most UI elements, and especially the file dialogue,
are too small. I tried setting environment variables, as suggested in
the Arch wiki, but to no avail (I tried both GTK3 and QT settings).

The effect of this problem is that texts and tooltips are so small that
it is very difficult for me to read the filenames, dialogues or tooltips.


Cheers,
Toni



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

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

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:6.1.5~rc1-2
ii  libreoffice-base   1:6.1.5~rc1-2
ii  libreoffice-calc   1:6.1.5~rc1-2
ii  libreoffice-core   1:6.1.5~rc1-2
ii  libreoffice-draw   1:6.1.5~rc1-2
ii  libreoffice-impress1:6.1.5~rc1-2
ii  libreoffice-math   1:6.1.5~rc1-2
ii  libreoffice-report-builder-bin 1:6.1.5~rc1-2
ii  libreoffice-writer 1:6.1.5~rc1-2
ii  python3-uno1:6.1.5~rc1-2

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-9
ii  fonts-liberation2   2.00.4-1
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-hinted   20181227-1
ii  fonts-noto-mono 20181227-1
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.1.5~rc1-2
ii  libreoffice-librelogo   1:6.1.5~rc1-2
ii  libreoffice-nlpsolver   0.9+LibO6.1.5~rc1-2
ii  libreoffice-report-builder  1:6.1.5~rc1-2
ii  libreoffice-script-provider-bsh 1:6.1.5~rc1-2
ii  libreoffice-script-provider-js  1:6.1.5~rc1-2
ii  libreoffice-script-provider-python  1:6.1.5~rc1-2
ii  libreoffice-sdbc-postgresql 1:6.1.5~rc1-2
ii  libreoffice-wiki-publisher  1.2.0+LibO6.1.5~rc1-2

Versions of packages libreoffice suggests:
ii  cups-bsd2.2.10-3
ii  default-jre [java6-runtime] 2:1.11-71
ii  firefox 64.0-1
ii  ghostscript 9.26a~dfsg-2
ii  gnupg   2.2.12-1
pn  gpa 
ii  gstreamer1.0-libav  1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-bad1.14.4-1+b1
ii  gstreamer1.0-plugins-base   1.14.4-1
ii  gstreamer1.0-plugins-good   1.14.4-1
ii  gstreamer1.0-plugins-ugly   1.14.4-1
ii  hunspell-en-us [hunspell-dictionary]1:2018.04.16-1
ii  hyphen-pt-pt [hyphen-hyphenation-patterns]  1:6.2.0~rc2-1
ii  imagemagick 8:6.9.10.23+dfsg-2
ii  imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2
ii  libgl1  1.1.0-1
pn  libreoffice-gnome | libreoffice-kde5
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
pn  libreoffice-officebean  
ii  libsane 1.0.27-3.1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
pn  mythes-thesaurus
pn  openclipart2-libreoffice | openclipart-lib  
ii  openjdk-11-jre [java6-runtime]  11.0.2+9-3
ii  openjdk-8-jre [java6-runtime]   8u181-b13-2~deb9u1
ii  pstoedit3.73-1+b1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.1-2
ii  fonts-opensymbol  2:102.10+LibO6.1.5~rc1-2
ii  libboost-date-time1.67.0  1.67.0-12
ii  libboost-locale1.67.0 1.67.0-12
ii  libc6 2.28-5
ii  libcairo2 1.16.0-2
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.2-1
ii  libcups2  2.2.10-3
ii  libcurl3-gnutls   7.63.0-1
ii  libdbus-1-3   1.12.12-1
ii  libdbus-glib-1-2  0.110-4
ii  libdconf1 0.30.1-2
ii  libeot0   0.01-5
ii  libepoxy0 1.5.3-0.1
ii  libexpat1 2.2.6-1
ii  libexttextcat-2.0-0   3.4.5-1
ii  

Bug#918206: Pandas new version

[Rebecca N. Palmer]

Control: tags -1 fixed-upstream patch

The test failure is that np.array @ pd.DataFrame (matrix product) tries 
to keep both the DataFrame's indices, which fails because the new matrix 
is a different shape.


This appears to be fixed in 0.24.1 from PyPI, but as previously noted, 
this is a new major version and hence risks breaking rdeps.


The relevant change appears to be setting __array_priority__:

https://github.com/brute4s99/pandas/commit/a01fa791eafe704ea85e2acc956ad9077e8e7542#diff-03b380f521c43cf003207b0711bac67f

but I haven't actually tried applying only that to 0.23.

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

And as one more piece of closure, the backported fix is now going into an
update of Debian stable as well.

Thanks everybody, and especially Evan. We're already in better shape now, and
will be in even better shape with the upcoming libxls 1.5 release.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#921374: libfreerdp2-2: Fails to connect Windows 7 x64 using NLA

[Bernhard Miklautz]

Hi,

On Mon, Feb 04, 2019 at 11:29:00AM -0600, Omer Ozarslan wrote:
> Package: libfreerdp2-2
> Version: 2.0.0~git20190204.1.2693389a+dfsg1-1
> Severity: important
> Tags: upstream

> RDP connection to Windows 7 x64 failed. I ran command "WLOG_LEVEL=DEBUG
> remmina", which resulted the error message pointing to freerdp core:
> 
> [11:21:19:450] [21683:21688] [ERROR][com.freerdp.core] - 
> freerdp_set_last_error
> ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F]
do you have installed KB4480970 on the windows machine and the user you
are using is in the "Administrators" group? 

Best regards,
Bernhard

Bug#823117: Bug#815369: texi2pdf output filename bug?

[Hilmar Preusse]

On 30.04.16 Guo Yixuan (culu@gmail.com) wrote:

Dear Guo,

https://bugs.debian.org/823117

This bug was cloned from the (unrelated) bug #815369.

I retested if the issue is till in latest texinfo and found that it
was solved at least in texinfo => 6.3.0.dfsg.1, i.e. Debian stable.

Could you confirm? I'd like to close the issue then.

Thanks,
  Hilmar

> There seems to be another bug in texi2pdf, which is triggered by an
> underscore in output filename. 
> 
> This command works:
> texi2pdf --command="@set cmd1 HELLO" --build=tidy  -o mwe.pdf mwe.texi
> while the other doesn't:
> texi2pdf --command="@set cmd1 HELLO" --build=tidy  -o mwe_2.pdf 
> mwe.texi
> 
> 
> The mwe.texi file by Norbert:
> 
> $ cat mwe.texi
> \input texinfo   @c -*-texinfo-*-
> @setfilename min2.info
> 
> What ever
> @anchor{@value{cmd1} doc}@anchor{0}
> Here we go
> @bye
> 
> Command line output:
> 
> $ texi2pdf --command="@set cmd1 HELLO" --build=tidy  -o mwe.pdf mwe.texi
> This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) 
> (preloaded format=pdfetex)
>  restricted \write18 enabled.
> entering extended mode
> (/home/pkg/gcc/value/mwe.t2d/pdf/xtr/mwe.texi
> (/usr/share/texmf/tex/texinfo/texinfo.tex
> Loading texinfo [version 2016-02-05.07.deb3]: pdf, fonts, markup, glyphs,
> page headings, tables, conditionals, indexing, sectioning, toc, environments,
> defuns, macros, cross references, insertions,
> (/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex
> This is `epsf.tex' v2.7.4 <14 February 2011>
> ) localization, formatting, and turning on texinfo input format.) (./mwe.aux)
> [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] 
> ) mf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb>
> Output written on mwe.pdf (1 page, 14596 bytes).
> Transcript written on mwe.log.
> 
> $ texi2pdf --command="@set cmd1 HELLO" --build=tidy  -o mwe_2.pdf mwe.texi
> This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) 
> (preloaded format=pdfetex)
>  restricted \write18 enabled.
> entering extended mode
> (/home/pkg/gcc/value/mwe.texi (/usr/share/texmf/tex/texinfo/texinfo.tex
> Loading texinfo [version 2016-02-05.07.deb3]: pdf, fonts, markup, glyphs,
> page headings, tables, conditionals, indexing, sectioning, toc, environments,
> defuns, macros, cross references, insertions,
> (/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex
> This is `epsf.tex' v2.7.4 <14 February 2011>
> ) localization, formatting, and turning on texinfo input format.) (./mwe.aux
> ./mwe.aux:1: TeX capacity exceeded, sorry [input stack size=18000].
> @value ->@begingroup @makevalueexpandable
>   @valuexxx
> @makevalueexpandable ->@let @value
>= @expandablevalue @catcode `@-=@other 
> @c...
> 
> @value ->@begingroup @makevalueexpandable
>   @valuexxx
> @makevalueexpandable ->@let @value
>= @expandablevalue @catcode `@-=@other 
> @c...
> 
> @value ->@begingroup @makevalueexpandable
>   @valuexxx
> @makevalueexpandable ->@let @value
>= @expandablevalue @catcode `@-=@other 
> @c...
> ...
> l.1 ..., used in @value, is not set.} doc-title}{}
> 
> ./mwe.aux:1:  ==> Fatal error occurred, no output PDF file produced!
> Transcript written on mwe.log.
> /usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
> $
> 


signature.asc
Description: PGP signature

Bug#916435: stretch-pu: package cups/2.2.1-8+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2018-12-14 at 14:09 +0100, Didier 'OdyX' Raboud wrote:
> cups (2.2.1-8+deb9u3) stretch; urgency=low
> 
>   * Backport upstream fixes for:
> - CVE-2017-18248: DBUS notifications could crash the scheduler
> - CVE-2018-4700: Linux session cookies used a predictable random
>   number seed (Closes: #915909)
> 

Please go ahead.

Regards,

Adam

Bug#921226: RFS: austin/0.6.1~beta-1 [ITP]

[Gabriele]

Hi

Sorry for not including the bug address in the CC. I have simplified
the debian/rules file
(https://github.com/P403n1x87/austin/commit/655c3beb09199bb9dbe6c9dbdb8395c25e9213c9)
and verified with gbp buildpackage. I have excluded the custom
Makefile from the sources and seems fine to me now.

Please let me know if you want me to re-upload the package with the
latest changes.

Regarding python2, the package doesn't include any python2 code. Even
the python project inside austin/ is compatible with python3. However,
the main C application shipped with the package (which is just the
single binary src/austin) supports both python2 (2.3 - 2.7) and
python3 (3.3 - 3.7).

Thanks,
Gabriele

On Sun, 3 Feb 2019 at 23:31, Adam Borowski  wrote:
>
> On Sun, Feb 03, 2019 at 10:39:09PM +, Gabriele wrote:
> > Hey
> >
> > Many thanks for getting back to me!
>
> Could you please re-add 921...@bugs.debian.org to CC?  (I'm 99.9% sure
> you'll be ok with that but the rule is to never make anything public without
> an explicit permission).  Any such package reviews are supposed to be done
> in public, for a number of reasons:
>  * there's a record of the review
>  * anyone else can chime in
>  * anyone else can continue the review -- I might need to pass if there'll
>be any complex python-specific questions
>  * others can learn
>
> > I have sent the public key to the keyserver as you have suggested.
>
> Great, thanks!  It'll probably take a bit of time for it to propagate.
>
> > Regarding the dependencies you have mentioned, they shouldn't really
> > be such. The tarball includes snapcraft sources for creating artifacts
> > for the snap store (think of this as the analogue of the debian/
> > folder but for another type of repository, https://snapcraft.io/).
> > This tool is then not required for the application to run and to even
> > build.
>
> Yeah, but the build system still calls it.  After your changes at least
> repacking the sources succeeds, but the actual build still fails:
>
>
> Command: dpkg-buildpackage -us -uc -b -rfakeroot
> dpkg-buildpackage: info: source package austin
> dpkg-buildpackage: info: source version 0.6.1~beta-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Gabriele N. Tornetta 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  fakeroot debian/rules clean
> dh clean
>dh_auto_clean
> make -j6 clean
> make[1]: Entering directory '/<>'
> snapcraft clean
> make[1]: snapcraft: Command not found
> make[1]: *** [Makefile:23: clean] Error 127
> make[1]: Leaving directory '/<>'
> dh_auto_clean: make -j6 clean returned exit code 2
>
> > In fact, all that austin requires is a C compiler. Python is
> > only a test dependency as it is invoked during tests. The Makefile
> > included in the tarball is not intended for autogeneration, but just
> > to simplify the testing during development. The package should be
> > built with the standard autoreconf process instead, as I think is
> > currently happening.
>
> Seems like this is the problem:
>
> dpkg-buildpackage: info: source package austin
> dpkg-buildpackage: info: source version 0.6.1~beta-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Gabriele N. Tornetta 
> 
>  dpkg-source --before-build .
>  fakeroot debian/rules clean
> dh clean
>dh_clean
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building austin using existing 
> ./austin_0.6.1~beta.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: warning: ignoring deletion of file Makefile, use 
> --include-removal to override
> dpkg-source: warning: ignoring deletion of file src/Makefile.in, use 
> --include-removal to override
> dpkg-source: warning: ignoring deletion of file src/austin, use 
> --include-removal to override
> dpkg-source: warning: ignoring deletion of file test/test_process_iter.py, 
> use --include-removal to override
> dpkg-source: info: building austin in austin_0.6.1~beta-1.debian.tar.xz
> dpkg-source: info: building austin in austin_0.6.1~beta-1.dsc
>  dpkg-genbuildinfo --build=source
>  dpkg-genchanges --build=source >../austin_0.6.1~beta-1_source.changes
> dpkg-genchanges: info: including full source code in upload
>  dpkg-source --after-build .
> dpkg-buildpackage: info: full upload (original source is included)
>
> The patch system ignores deletions unless specifically told so (there are
> usually nicer ways to get this effect), which apparently results in some old
> version of the Makefile being used.  Normally, dh_autoreconf would generate
> a proper version, but you specifically disable it in debian/rules.  That's
> bad for other reasons as well -- the package won't see improvements from new
> versions of autotools (bug fixes, support for new architectures, etc).
>
> > Please note that I have some local changes that fix some 

Bug#921386: ITP: embree -- High Performance Ray Tracing Kernels

[Matteo F. Vescovi]

Package: wnpp
Severity: wishlist
Owner: "Matteo F. Vescovi" 
X-Debbugs-Cc: Mathieu Malaterre 

* Package name: embree
  Version : 3.4.0
  Upstream Author : Intel Corporation
* URL : http://embree.github.io/
* License : Apache-2.0
  Programming Lang: C++ mostly
  Description : High Performance Ray Tracing Kernels

Intel® Embree is a collection of high-performance ray tracing kernels,
developed at Intel. The target users of Intel® Embree are graphics
application engineers who want to improve the performance of their
photo-realistic rendering application by leveraging Embree's
performance-optimized ray tracing kernels. The kernels are optimized for
the latest Intel® processors with support for SSE, AVX, AVX2, and
AVX-512 instructions. Intel® Embree supports runtime code selection to
choose the traversal and build algorithms that best matches the
instruction set of your CPU.

=-=-=-=-=

Mainly, I'm packaging this library because it will become a dependency
for blender (which I actually maintain in Debian) sooner or later.
Later, there will be more applications taking advantage of this package.

The package will be co-maintained under DMM umbrella by Mathieu (Cc-ed)
and me.

-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature

Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)

[Adrian Bunk]

On Mon, Feb 04, 2019 at 04:36:22PM +0100, Andreas Tille wrote:
> Hi Adrian,
> 
> On Mon, Feb 04, 2019 at 01:06:35PM +0200, Adrian Bunk wrote:
> > >Bug#916576: pbdagcon: FTBFS pbdata/Types.h: No such file or directory
> > > 
> > > I need to make some noise in the team since I'm definitely overworked
> > > with these pb* packages.  It might be that we will loose these for
> > > Buster. :-(
> > 
> > the patches for pbbam and pbdagcon should sort out most of the issues.
> 
> I've now uploaded the old upstream version of pbdagcon.  Unfortunately
> I can not see that pbbam has fixed the build issues[1] - thus I think
> #909071 needs to be re-opened.
>...

pbbam does now build on arm64/mips64el/ppc64el,
this is what #909071 fixed.

pbbam fails its tests on 32bit (#829741) and big endian,
these are expected failures that won't block migration.

But the pbdagcon build failure points at a bug in pbbam:
libpbbam0.19.0 is not ABI compatible with the stretch libpbbam,
so mustn't provide it.

The following changes should fix the latter problem:
- remove the Provides: libpbbam from libpbbam0.19.0
- remove manual dependencies on libpbbam from the following
  source packages (correct dependencies on libpbbam0.19.0
  are now generated):
  - blasr
  - pbdagcon
  - pbseqlib
  - unanimity

> Kind regards
> 
>   Andreas.
> 
> 
> [1] https://buildd.debian.org/status/package.php?p=pbbam 

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#920382: stretch-pu: package nvidia-persistenced/390.87-1~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-01-24 at 22:51 +0100, Andreas Beckmann wrote:
> in addition to switching nvidia-graphics-drivers to the new 390.xx
> upstream release in stretch (#916632), we also need to update some
> related packages to the 390.xx series. We don't want to mix different
> (major) versions which is completely untested (and unsupported
> upstream). And since we build all the components of the driver that
> are available in source code form as separate packages in contrib, we
> need to update a few extra packages in case of the upstream major
> version bump.
> 

Please go ahead.

Regards,

Adam

Bug#920381: stretch-pu: package nvidia-modprobe/390.87-1~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-01-24 at 22:44 +0100, Andreas Beckmann wrote:
> in addition to switching nvidia-graphics-drivers to the new 390.xx
> upstream release in stretch (#916632), we also need to update some
> related packages to the 390.xx series. We don't want to mix different
> (major) versions which is completely untested (and unsupported
> upstream). And since we build all the components of the driver that
> are available in source code form as separate packages in contrib, we
> need to update a few extra packages in case of the upstream major
> version bump.
> 

Please go ahead.

Regards,

Adam

Bug#916632: stretch-pu: package nvidia-graphics-drivers/390.87-4~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-12-16 at 19:44 +0100, Andreas Beckmann wrote:
> I'd like to update the non-free nvidia-graphics-drivers in stretch to
> a new major upstream release: 384 -> 390
> But with that we finally reached a new legacy branch that will
> receive updates from NVIDIA until the end of 2022. So any future
> updates in stretch will only come from the 390 series and (hopefully)
> require no or only minimal changes to the packaging. (Going beyond
> 390 will be a major step: i386 and armhf driver support are dropped).
> 

Please go ahead.

Regards,

Adam

Bug#920379: stretch-pu: package nvidia-xconfig/390.87-1~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-01-24 at 22:29 +0100, Andreas Beckmann wrote:
> in addition to switching nvidia-graphics-drivers to the new 390.xx
> upstream release in stretch (#916632), we also need to update some
> related packages to the 390.xx series. We don't want to mix different
> (major) versions which is completely untested (and unsupported
> upstream). And since we build all the components of the driver that
> are available in source code form as separate packages in contrib, we
> need to update a few extra packages in case of the upstream major
> version bump.
> 

Please go ahead.

Regards,

Adam

Bug#920372: stretch-pu: package nvidia-settings/390.87-1~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-01-24 at 20:58 +0100, Andreas Beckmann wrote:
> in addition to switching nvidia-graphics-drivers to the new 390.xx
> upstream release in stretch (#916632), we also need to update some
> related packages to the 390.xx series. We don't want to mix different
> (major) versions which is completely untested (and unsupported
> upstream). And since we build all the components of the driver that
> are available in source code form as separate packages in contrib, we
> need to update a few extra packages in case of the upstream major
> version bump. An older version of the 390.xx driver has been
> available in stretch-backports for a long time already with no known
> problems.
> 

Please go ahead.

Regards,

Adam

Bug#916627: stretch-pu: package glx-alternatives/0.8.8~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-12-16 at 18:57 +0100, Andreas Beckmann wrote:
> I'd like to upgrade the non-free nvidia-graphics-drivers package in
> stretch to the 390.xx legacy branch. As a prerequisite we need an
> updated version of glx-alternatives to support the changed handling
> of
> the libGLX_indirect.so.0 symlink. It also comes with some bugfixes.
> 

Please go ahead.

Regards,

Adam

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Lorenz]

Hi Felipe,

Felipe Sateler wrote:
> > > Upstream asks if cgroup is in v2-mode in the affected systems.

> With `findmnt -R /sys/fs/cgroup`. It should list controllers in the cgroup
> or cgroup2 filesystems.

root@lorenz:~# findmnt -R /sys/fs/cgroup
TARGET   SOURCE  FSTYPE  OPTIONS
/sys/fs/cgroup   tmpfs   tmpfs   rw,nosuid,nodev,noexec,mode=755
├─/sys/fs/cgroup/unified cgroup2 cgroup2
rw,nosuid,nodev,noexec,relatime,nsdelegate
└─/sys/fs/cgroup/elogind cgroup  cgroup
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/elogind/elogind-cgroups-agent,name=elogind


Il giorno lun 4 feb 2019 alle ore 16:11 Gedalya  ha
scritto:

>
> > This currently looks like this now (after I have uninstalled
> > cgroupfs-mount):
> >
> > → findmnt -R /sys/fs/cgroup
> > TARGET   SOURCE  FSTYPE  OPTIONS
> > /sys/fs/cgroup   tmpfs   tmpfs   rw,nosuid,nodev,noexec,mode=755
> > ├─/sys/fs/cgroup/unified cgroup2 cgroup2
> rw,nosuid,nodev,noexec,relatime,nsdelegate
> > └─/sys/fs/cgroup/elogind cgroup  cgroup
> rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/elogind
> >
> > But I have to assume that these mount points where at least present
> > before I uninstalled cgroupfs-mount, too.
> >
> >   Regards, Axel
>
> I can say I've always had this issue with only cgroup2 mounted and no
> cgroup (what you might call "v1")
>
>
>

Bug#921281: arc 5.21q-4+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: arc
Version: 5.21q-4+deb9u1

Explanation: fix directory traversal bugs [CVE-2015-9275], arcdie crash when 
called with more then 1 variable argument and version 1 arc header reading

Bug#921107: sox 14.4.1-5+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: sox
Version: 14.4.1-5+deb9u1

Explanation: really apply fixes for CVE-2014-8145

Bug#920804: r-cran-readxl 0.1.1-1+deb9u2 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: r-cran-readxl
Version: 0.1.1-1+deb9u2

Explanation: fix crash bugs [CVE-2018-20450 CVE-2018-20452]

Bug#919712: samba 4.5.16+dfsg-1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian .

Thanks for your contribution!

Upload details
==

Package: samba
Version: 4.5.16+dfsg-1

Explanation: new upstream release; s3:ntlm_auth: fix memory leak in 
manage_gensec_request(); ignore nmbd start errors when there is no non-loopback 
interface or no local IPv4 non-loopback interface; fix CVE-2018-14629 
regression  on a non-CNAME record

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Andreas Tille]

Hi Fabian,

On Mon, Feb 04, 2019 at 05:26:08PM +0100, Fabian Klötzl wrote:
> So I improved the upstream libmurmurhash, adapted the package and filed an
> ITP (#921353). I even managed to locally build mash against the new package.

Thanks a lot - that's really cool.

> So hereby I kindly ask you to fix the last lintian issue about NMU which I
> don't fully understand and then maybe sponsor an upload.

Please have a look at

   
https://salsa.debian.org/med-team/libmurmurhash/commit/dddc2707ffea44a40c2e39b3b23f7576fe0ebda3

I took the freedom to realise my suggestion to use automake.  The
advantage is that you get multiarch for free and the build system is
somehow "convenient" in terms of not needing any override. 

I admit I'm not fully happy with my work since I'm also not an automake
adept and thus the manpage is not part of the Makefile.am installation
and the check is also not as elegant as I would prefer it to be.

However, there is also pkg-config which might be convenient in some
situations.  Would you mind integrating my patch upstream before I
upload?  Feel free to enhance it - I'm not really proud about that
code ...

Kind regards and thanks again for your work on this

 Andreas.

-- 
http://fam-tille.de

Bug#912068: stretch-pu: package apache-directory-server/2.0.0~M15-4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2018-10-27 at 22:35 +0200, Dominik George wrote:
> I would like to upload fixes for two RC bugs that affect stretch and
> make the package uninstallable and, after manually fixing that,
> unusable:
> 
>  #909063 - apacheds: package installation fails due to incorrect
> apacheds.service unit
>  #911557 - apacheds: broken symlinks: /usr/share/apacheds/lib/{log4j-
> 1.2,commons-io,antlr}.jar

I assume there's no way of avoiding the hard-coding of the new
dependencies there?

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#919106: sl-modem 2.9.11~20110321-12+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: sl-modem
Version: 2.9.11~20110321-12+deb9u1

Explanation: support Linux versions > 3

Bug#914032: stretch-pu: package gnupg2/2.1.18-8~deb9u4

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Sun, 2018-11-18 at 12:38 -0500, Daniel Kahn Gillmor wrote:
> When fixing #906545 (GnuPG rejects some malformed keys during import
> instead of cleaning), i inadvertently introduced #913614 (GnuPG fails
> to import keys when no TTY attached and --batch is not specified)
> into debian stable.

Subject to a d-i ack, please go ahead; sorry for the delay.

Regards,

Adam

Bug#913881: stretch-pu: package uriparser/0.8.4-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2018-11-16 at 12:29 +0100, Jörg Frings-Fürst wrote:
> the attached debdiff fix the
> 
> CVE-2018-19198,
> CVE-2018-19199 and
> CVE-2018-19200.

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#914081: stretch-pu: package jdupes/1.7-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2018-11-19 at 01:11 -0200, Joao Eriberto Mota Filho wrote:
> From the jdupes upstream:
> 
> "All versions from 1.5.1 up to 1.7 have potentially serious bugs in
> the internal memory allocator which caused crashes on Debian ARM and
> macOS Sierra. These should be updated to a minimum of v1.8 if at all
> possible.
> 
> If that isn't possible, the following commits improving/fixing the
> internal memory allocator should be patched into the old versions:

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#921385: ITP: jsbundle-web-interfaces -- collection of we-interface-related tiny JavaScript packages

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: jsbundle-web-interfaces
  Version : [multiple]
  Upstream Author : Andri Möll , Domenic Denicola 

* URL : [multiple]
* License : AGPL, BSD-2-clause
  Programming Lang: JavaScript
  Description : collection of web-interface-related tiny JavaScript packages

A bundle containing (for now) the following upstream tiny JavaScript projects:

 https://github.com/moll/js-standard-error
 https://github.com/moll/js-standard-http-error
 https://github.com/jsdom/webidl-conversions

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxYrxMACgkQLHwxRsGg
ASGwBQ/+MCNOFo16s01YDgLjjZzb9ON+TYJbcUE8cTCum2UbL9S6POp0Hw8vlCJn
7nVffA3R0eOQMgbzYTM+TluWKKyF6vTM4Nr7pp4z02E4BbtX115HO5rmfSx9wPIn
PX3hwGGjtfzCTF0itZ+oeyK6OjxHk+ONyIMGZop+62dodBFSGuCQdV1cv/SCEZJt
qx+SQVdxMSLf6icmAzeTA9ti/VJ4n9wuDBXWAZDcctJvGVGECO7lguIGI8J+WAsX
k9fO+N6OHuam9MkSFIRVh368HgqyGTGwgw9kRAzJ+JfcQynfGy6YirbOGY+P9ZaF
Aq2hYMo3rYz7AL4h/EOj2DEtz93mDgV7WBy8ZJBw8cRIEJedXuWAka9s0MJHdRVe
SUJv+C6TgAWio2FMivRcl6j8ADrXZB9YqYvCyWPTeWt72Ixpr2Gca2BRNYtMVNL8
dKbmlEAeWK8Ei35D6ZWYKeaBrEfhMY6xAz5QB9qUq+tiA3DGVloz0qYsh4Kv9MhR
wYA3cfkWfRb5V4gfhiqSZMr8vv2EtN9qkw3QdarQoxc5l2u3BtETiAyLDLvMCLD9
Fmu3IxfquBStOzi/TqQ+jLz2SdOSlaE0nYRS8Ur1mTCetCoId89+ouRpSUlB/rsn
skLZaflQximizvRQdQULC0eavIrw1IM4GDU64rCLyv96IjDsyoo=
=X/32
-END PGP SIGNATURE-

Bug#919576: stretch-pu: package ncmpc/0.25-0.1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2019-01-28 at 14:35 +0100, kaliko wrote:
> Hi Salvatore
> 
> On 27/01/2019 09:14, Salvatore Bonaccorso wrote:
> > On Thu, Jan 17, 2019 at 01:44:14PM +0100, kaliko wrote:
[...]
> > > Update fixing CVE-2018-9240 / #894724
> > […]> Please use for consistency (although that would be possible if
> > 0.25-0.2 was never used) rather 0.25-0.1+deb9u1 for the version.
> 
> I updated the patch according to your review (find attached).

The diff you provided is reversed. Please feel free to upload the
correctly-applied version.

Regards,

Adam

Bug#916912: [pre-approval] stretch-pu: package freerdp/1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

Hi,

On Thu, 2019-01-31 at 22:14 +, Mike Gabriel wrote:
> HI Adam,
> 
> On  Do 31 Jan 2019 21:28:43 CET, Adam D. Barratt wrote:
> 
> > On Fri, 2019-01-11 at 15:26 +0100, Mike Gabriel wrote:
> > > Please review the attached .debdiff (for stretch) and give your
> > > go
> > > for uploading to stretch.
> > 
[...]
> >   * debian/control:
> > + B-D on libssh1.0-dev (instead of libssh-dev).
> 
> It's libssh1.0-dev for stretch and nothing needs to be changed.

Well, no. As you go on to say yourself below, it's libss*l*1.0-dev

> > This change doesn't appear to have actually been included. (Which
> > is
> > just as well, as there is no such package in Debian.)
> 
> Yeah, I guess I mixed those up in the changelog. The  
> debian/jessie/updates branch needs a switch-back [1] from  
> libssl1.0-dev to libssl-dev whereas the debian/stretch/updates
> branch   does not need a change here.
[...]
> I will also publish a blog post that will appear on Planet Debian
> > > that links to built binaries that users may be table to test.
> > 
> > Has there been much take-up / feedback there?
> 
> Over the last 8 days my webserver has registered 18 downloads of  
> freerdp-x11 (either for jessie or for stretch). Without any
> positive feedback given (which I requested explicitly).

That's unfortunate. Let's hope it simply means that people couldn't be
bothered to provide feedback.

Please go ahead.

Regards,

Adam

Bug#918762: stretch-pu: package twitter-bootstrap3/3.3.7+dfsg-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-01-09 at 06:58 +0100, Xavier Guimard wrote:
> Hello, twitter-bootstrap3 has some CVEs to fix (issues marked as
> no-dsa). This patch imports related fix from twitter-bootstrap 3.4.

+twitter-bootstrap3 (3.3.7+dfsg-3+deb9u1) stretch; urgency=high

stretch currently has -2, so this should be -2+deb9u1

+  * Team upload.
+  * Fix multiples XSS vulnerabilities (Closes: #907414)

"multiple". It would also be helpful to explicitly list the relevant
CVEs.

With the above fixes, please go ahead.

Regards,

Adam

Bug#919990: stretch-pu: package chkrootkit/0.50-4+b2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2019-01-21 at 11:58 +0100, Moritz Schlarb wrote:
> As reported in #600109, /etc/cron.daily/chkrootkit contains a regular
> expression to filter out dhclient3 and dhcpd3 as false positives from
> the packet sniffer test. However, the binaries don't exist anymore,
> they have been renamed to dhclient and dhcpd respectively.

Please go ahead.

Regards,

Adam

Bug#920632: stretch-pu: package intel-microcode/3.20180807a.2~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-01-27 at 16:09 -0200, Henrique de Moraes Holschuh wrote:
> Please update the intel-microcode package in stable (stretch) to
> version 3.20180807a.2~deb9u1.  This is a limited security update that
> affects Intel Westmere EP processors, only.

Please go ahead.

Regards,

Adam

Bug#921376: frr: missing Breaks+Replaces

[Andreas Beckmann]

Hi David,

On 2019-02-04 22:01, David Lamparter wrote:
> I've added Conflicts: lines, as that seemed to be the most conservative
> option to me.  ("Replaces: quagga" is a 'layer 9' discussion that I
> think it's a bit early to have at this point.)
> 
> If you have any comments/opinions/input, I'd appreciate that.

Looks good to me. You can reconsider the Breaks+Replaces once you
implement whatever conclusion such a 'layer 9' discussion has reached.

I'll come back to you in case you missed to Conflicts: some package :-)

Andreas

Bug#921384: [Pkg-javascript-devel] Bug#921384: node-stringprep breaks node-xmpp autopkgtest

[Jérémy Lal]

Le lun. 4 févr. 2019 à 21:51, Paul Gevers  a écrit :

> Source: node-stringprep, node-xmpp
> Control: found -1 node-stringprep/0.8.0-5
> Control: found -1 node-xmpp/0.3.2-4
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
>
> Dear maintainers,
>
> With a recent upload of node-stringprep the autopkgtest of node-xmpp
> fails in testing when that autopkgtest is run with the binary packages
> of node-stringprep from unstable. It passes when run with only packages
> from testing. In tabular form:
>passfail
> node-stringprepfrom testing0.8.0-5
> node-xmpp  from testing0.3.2-4
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report.
>
> Currently this regression is blocking the migration of node-stringprep
> to testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package? If needed, please change the
> bug's severity.
>
> More information about this bug and the reason for filing it can be found
> on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1] https://qa.debian.org/excuses.php?package=node-stringprep
>
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-xmpp/1853210/log.gz
>
> autopkgtest [05:55:44]: test command2: vows --spec
> autopkgtest [05:55:44]: test command2: [---
>
>   ♢ JID
>
>   parsing
> ✓ parse a "domain" JID
> ✓ parse a "user@domain" JID
> ✓ parse a "domain/resource" JID
> ✓ parse a "user@domain/resource" JID
> ✓ parse an internationalized domain name as unicode
> ✗ parse an internationalized domain name as ascii/punycode
> »
> actual expected
>
> öxn--ko-eka.de 
>  // /usr/lib/nodejs/vows/lib/assert/macros.js:14
> ✗ parse a JID with punycode
> »
> actual expected
>
> приме́р.рфxn--lsa92diaqnge.xn--p1ai
>  // /usr/lib/nodejs/vows/lib/assert/macros.js:14
>   serialization
> ✓ serialize a "domain" JID
> ✓ serialize a "user@domain" JID
> ✓ serialize a "domain/resource" JID
> ✓ serialize a "user@domain/resource" JID
>   equality
> ✓ parsed JIDs should be equal
> ✓ parsed JIDs should be not equal
> ✓ should ignore case in user
> ✓ should ignore case in domain
> ✓ should not ignore case in resource
> ✓ should ignore international caseness
>
> ✗ Broken » 15 honored ∙ 2 broken (0.015s)
>
> autopkgtest [05:55:45]: test command2: ---]



I started investigations about node-stringprep failure and while the fix is
probably
one line somewhere, it's hard to find it (nodejs cannot load the module, it
falls back to
a default useless behavior).