Bug#917048: cargo: Please drop patch to disable incremental builds on sparc64

[Vasudev Kamath]

John Paul Adrian Glaubitz  writes:

> Hi!
>
> On 12/22/18 12:15 AM, John Paul Adrian Glaubitz wrote:
>> While upstream hasn't fixed the bug yet, I have provided a temporary
>> fix for the bug in #917000 [2]. Once this bug has been fixed, incremental
>> builds work fine on sparc64 and the patch to disable incremental builds
>> in cargo, 2007_sparc64_disable_incremental_build.patch, is no longer
>> needed.
>> 
>> I am therefore setting this bug as blocked by #917000.
> Blocker bug in rustc has been fixed now. Could you remove the sparc64 patch
> to disable incremental builds in the next upload to close this bug?
>
> Then incremental builds will just work on sparc64!

I hope this is not important for buster?. I did not get time to attend
to this till now. But I will fix this and upload to experimental.

Cheers,

Bug#920621: first workaround

[Paolo Greppi]

I think there are two separate issues at play here.

One is with longtabu X.

Replacing X columns with c columns:
https://salsa.debian.org/paolog-guest/doxygen/blob/master/debian/patches/longtabu.diff
I got past the "! Missing } inserted." errors that I originally reported.

Unfortunately this breaks something else, as shown by the attached 
stripped-down example.

This command:
/usr/bin/pdflatex -shell-escape doxygen_manual.tex
fails with both texlive-base 2018.20181214-1 and 2018.20190126-1.

It returns 1 and prints this error in doxygen_manual.log:

! LaTeX Error: Something's wrong--perhaps a missing \item.
See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...
l.70 \end{longtabu}

It goes away if I remove these lines towards the end of tables.tex:

-\begin{DoxyItemize}
-\item Item 1 
-\item Item 2 
-\end{DoxyItemize}\\\cline{1-3}

but this is not viable because similar code occurs in a lot of places in 
doxygen-generated tex files.

Any help is appreciated so that we can work around these latex issues for the 
doxygen 1.8.15 release while upstream fixes tabu.

Paolo


ddd.tar.xz
Description: application/xz

Bug#916642: golang CVE-2019-6486 (DoS in crypto/elliptic)

[Niels Thykier]

James McCoy:
> On Fri, Jan 25, 2019 at 08:23:52AM -0500, James McCoy wrote:
>> On Thu, Jan 24, 2019 at 03:00:22PM +0100, Dr. Tobias Quathamer wrote:
>>> Am 24.01.2019 um 09:12 schrieb Emilio Pozuelo Monfort:
 On 24/01/2019 08:58, Michael Stapelberg wrote:
> Last time, pochu@ (cc'ed) helpfully scheduled binNMUs. pochu, would you be
> able to help this time, too?

 Sure. Can you give me a list of source packages to binNMU in unstable? If 
 this
 is public already, can you do that through a binNMU bug against 
 release.debian.org?

 Emilio
>>>
>>> Hi all,
>>>
>>> there is already an outdated binNMU list as bug report available, so
>>> I'm reusing that report. Please ignore the previously attached
>>> binNMU list of that bug report.
>>>
>>> This should be a complete and current list of needed binNMUs:
>>>
>>>
>>> [‥]
>>>   nmu serf_0.8.1+git20180508.80ab4877~ds-1 . ANY . -m 'Rebuild with current 
>>> golang-1.11 (CVE-2019-6486)'
>>
>> This is a (common) mistake.  src:serf does not use golang.
>> src:golang-github-hashicorp-serf is the golang package, which producees
>> bin:serf, however I just saw that src:serf was binNMUed.
> 
> Ping.
> 
> nmu golang-github-hashicorp-serf_0.8.1+git20180508.80ab4877~ds-1 . ANY .  -m 
> 'Rebuild with current golang-1.11 (CVE-2019-6486)'
> 
> Tobias, your tool should be updated to ensure it's using the source
> pacakge name, not the binary package name.
> 
> Cheers,
> 

Scheduled golang-github-hashicorp-serf_0.8.1+git20180508.80ab4877~ds-1.

Thanks,
~Niels

Bug#919189: Fwd: probabel FTBFS on arm64, likely due to Eigen 3 NEON code

[Andreas Tille]

Hi,

I think these are just rounding errors due to different representation of
floating point numbers.  Relaxing the precision of the test would solve
the problem (but I have no idea about the test suite and so do not know
how to implement this).

What I do also not understand why a fix that only occures on arm64 now
has an influence on ppc64el.  Did ppc64el compiled fine for version
0.5.0+dfsg-1 (without that fix)?

Kind regards

Andreas.

On Fri, Feb 01, 2019 at 04:41:04PM +0100, Thierry fa...@linux.ibm.com wrote:
> 
> Unfortunately the workaround mentioned for arm64 breaks ppc64el arch as
> compiling on buster fails with following error - what do we do ?
> Thanks
> 
> 
> BT check (recess model): prob vs. prob_fv  OK
> 2c2
> < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938
> 544.518 437.583 -567.388 435.04 1.75239
> ---
> > rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938
> 544.518 437.583 -567.387 435.04 1.75239
> BT check (2df model): prob vs. prob_fv
> FAILED
> FAIL test_bt.sh (exit status: 1)
> -
> 
> 
> 
> On Sun, 13 Jan 2019 16:37:02 +0200 Adrian Bunk  wrote:
> > Source: probabel
> > Version: 0.5.0+dfsg-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=probabel&arch=arm64&ver=0.5.0%2Bdfsg-1&stamp=1538603399&raw=0
> > 
> > ...
> > FAIL: test_bt
> > =
> > 
> > Analysing BT...
> > BT check: dose vs. dose_fv OK
> > BT check (add model): prob vs. prob_fv OK
> > BT check (domin model): prob vs. prob_fv   OK
> > BT check (over_domin model): prob vs. prob_fv  OK
> > BT check (recess model): prob vs. prob_fv  OK
> > 2c2
> > < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 
> > 437.583 -567.387 435.04 1.75239
> > ---
> > > rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 
> > > 437.583 -567.388 435.04 1.75239
> > BT check (2df model): prob vs. prob_fv 
> > FAILED
> > FAIL test_bt.sh (exit status: 1)
> > 
> > 
> > Testsuite summary for ProbABEL 0.5.0
> > 
> > # TOTAL: 11
> > # PASS:  10
> > # SKIP:  0
> > # XFAIL: 0
> > # FAIL:  1
> > # XPASS: 0
> > # ERROR: 0
> > 
> > See checks/test-suite.log
> > Please report to genabel-de...@r-forge.wu-wien.ac.at
> > 
> > make[4]: *** [Makefile:713: test-suite.log] Error 1
> > 
> > 
> > I suspect this might be a problem with the NEON code in Eigen 3,
> > and the fact that this can be fixed with the following workaround
> > makes that even more probable:
> > 
> > --- debian/rules.old2019-01-09 15:07:11.950823327 +
> > +++ debian/rules2019-01-09 15:17:23.280539016 +
> > @@ -6,6 +6,10 @@
> >  
> >  export DEB_BUILD_MAINT_OPTIONS=hardening=+all
> >  
> > +ifeq ($(DEB_HOST_ARCH),arm64)
> > +  export DEB_CXXFLAGS_MAINT_APPEND = -march=armv8-a+nosimd
> > +endif
> > +
> >  include /usr/share/dpkg/default.mk
> >  
> >  # Location of the example files, will be converted to the
> > 
> > 
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#921141: RFS: dvdisaster/0.79.6-5

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "dvdisaster"

 * Package name: dvdisaster
   Version : 0.79.6-5
   Upstream Author : Carsten Gnörlich 
 * URL : 
https://web.archive.org/web/20180428070843/http://dvdisaster.net/
 * License : GPL-3+
   Section : otherosfs

  It builds these binary packages:

dvdisaster - data loss/scratch/aging protection for CD/DVD media
dvdisaster-doc - data loss/scratch/aging protection for CD/DVD media 
(documentation)

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

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


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

dget -ux 
https://mentors.debian.net/debian/pool/main/d/dvdisaster/dvdisaster_0.79.6-5.dsc

  Changes since the last upload:

dvdisaster (0.79.6-5) experimental; urgency=medium

  * Merge changes from 0.79.5-9.

 -- Carlos Maddela   Sat, 02 Feb 2019 16:05:29 +1100


  Regards,
   Carlos Maddela

Bug#921140: RFS: dvdisaster/0.79.5-9

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "dvdisaster"

 * Package name: dvdisaster
   Version : 0.79.5-9
   Upstream Author : Carsten Gnörlich 
 * URL : 
https://web.archive.org/web/20180428070843/http://dvdisaster.net/
 * License : GPL-3+
   Section : otherosfs

  It builds these binary packages:

dvdisaster - data loss/scratch/aging protection for CD/DVD media
dvdisaster-doc - data loss/scratch/aging protection for CD/DVD media 
(documentation)

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

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


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

dget -ux 
https://mentors.debian.net/debian/pool/main/d/dvdisaster/dvdisaster_0.79.5-9.dsc

  Changes since the last upload:

dvdisaster (0.79.5-9) unstable; urgency=medium

  * Make sure that the upstream changelog remains uncompressed so
that the application can display it.
  * Suggest to install dvdisaster-doc in error message, if the PDF manual
cannot be found.

 -- Carlos Maddela   Sat, 02 Feb 2019 15:20:23 +1100


  Regards,
   Carlos Maddela

Bug#908832: Please include application/wasm MIME type for WebAssembly files

[Charles Plessy]

Le Fri, Sep 14, 2018 at 10:19:31AM -0700, Josh Triplett a écrit :
> 
> Browsers require WebAssembly files to get served with the proper MIME
> type, application/wasm. To help web servers such as the one in Python,
> which read /etc/mime.types, could you please include an entry for
> `application/wasm wasm` in /etc/mime.types?

Le Mon, Jan 28, 2019 at 11:45:10AM +0100, Josh Triplett a écrit :
> Any updates on this bug? It'd be helpful to have this mime entry in
> the next stable release.

Hi Josh,

sorry for the delay,

I do not see application/wasm on the IANA website.  Is there a chance
that relevant people in charge for WebAssembly could submit their media
type there ?

Have a nice week-end,

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

Bug#915584: dicoweb: fails to install with python 3.7

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

On Sat, Jan 26, 2019 at 11:17:35PM +0100, Andreas Beckmann wrote:
> I think I now understood what is happening here.
> Both python3 and dicoweb are being installed in the same run.
> At the time python3 gets configured, dicoweb is already unpacked, but
> not yet configured and therefore /etc/dicoweb/settings.py does not yet
> exist (dpkg has only unpacked it as /etc/dicoweb/settings.py.dpkg-new).
> As part of the python3 configuration step the rtupdate hook is being run
> ... and explodes while accessing the dangling symlink.
> 
> You should probably ask the python maintainers for help, since you are
> exploiting a corner case in their packaging helpers ...
> 
---end quoted text---

Forwarded to doko

-- 
‎أحمد المحمودي (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#919743: RFS: rumur/2019.01.12-1 [ITP]

[Matthew Fernandez]

Hello mentors,

I posted an RFS a little while ago, but didn’t realise I was allowed to deviate 
from the template and add a little “hot spice” as the FAQ suggests. With that 
in mind, here’s a snippet from my package’s d/control that may entice some 
potential sponsors:

Rumur is a model checker for use in the formal verification of finite state
machines specified in the Murphi modelling language. It is based on a previous
tool, CMurphi, and attempts to provide an approximate drop-in replacement for
CMurphi. In comparison to CMurphi, Rumur generates a verifier that runs 
significantly
faster and uses less memory on large input problems.

Any and all feedback welcome. Thank you for your time.

Matthew

> On Jan 18, 2019, at 18:43, Matthew Fernandez  
> wrote:
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "rumur"
> 
> * Package name: rumur
>  Version : 2019.01.12-1
>  Upstream Author : Matthew Fernandez 
> * URL : https://github.com/Smattr/rumur
> * License : The Unlicense
>  Section : devel
> 
> It builds those binary packages:
> 
>   rumur - model checker for the Murphi language
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/rumur
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>  dget -x 
> https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2019.01.12-1.dsc
> 
> More information about rumur can be obtained from 
> https://github.com/Smattr/rumur.
> 
> Changes since the last upload:
> 
> Initial release. Closes #919220.
> 
> 
> Regards,
> Matthew Fernandez

Bug#921139: lasi: is two important bug fix releases behind upstream

[Alan W. Irwin]

Source: lasi
Version: 1.1.0-2
Severity: important

Dear Maintainer,

As primary maintainer of upstream libLASi I note that lasi version
1.1.0 was released in 2008-02-08 and has been superseded since by
three important bug fix releases, 1.1.1, 1.1.2, and most recently (see

1.1.3.  Throughout this series of bug fixes the libLASi CMake-based
build system has remained mostly the same so it should be entirely
straightforward to update your current packaging of 1.1.0 to 1.1.3.

Making these bug fixes available to Debian (and derivative
distribution) users will greatly improve their experience with this
library.  For example, the recent release of 1.1.3 includes a fix for
the important issue reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918774.  So as soon
as you package 1.1.3 to address the current important bug, that
important bug gets automatically fixed as well.

Alan

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

Kernel: Linux 4.18.10-custom (SMP w/16 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#921138: ceph-mon: systemd unit file CLUSTER variable

[toby]

Package: ceph-mon
Version: 13.2.2-23-g4695a60617-1
Severity: minor

Dear Maintainer,

systemd unit file ceph-mon@.service sets the CLUSTER variable *after*
reading the EnvironmentFine and overriding whatever value is set in
there, this variable should be in /etc/default/ceph


-- 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/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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ceph-mon depends on:
ii  ceph-base 13.2.2-23-g4695a60617-1
ii  libaio1   0.3.111-1
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-5
ii  libfuse2  2.9.9-1
ii  libgcc1   1:8.2.0-16
ii  libgoogle-perftools4  2.7-1
ii  libibverbs1   22.0-1
ii  libleveldb1v5 1.20-2
ii  liblz4-1  1.8.3-1
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42-1
ii  librados2 13.2.2-23-g4695a60617-1
ii  libsnappy1v5  1.1.7-1
ii  libssl1.1 1.1.1a-1
ii  libstdc++68.2.0-16
ii  libuuid1  2.33.1-0.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages ceph-mon recommends:
ii  ceph-common  13.2.2-23-g4695a60617-1

ceph-mon suggests no packages.

-- no debconf information

Bug#921128: Info received (mailman3-web fails to initialize mysql: Specified key was too long)

[Antoine Beaupré]

I just read the README.Debian file and it says the mariadb version in
stretch might conflict with the mailman3-web version.

If that's really the case, might I suggest the backport be fixed to warn
explicitely about this somehow? maybe conflict with that mariadb
version?

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

Bug#921115: the apt-file README.md.gz links to wordpress blog posts which are not publicly viewable

[shirish शिरीष]

at bottom :-

On 01/02/2019, Julian Andres Klode  wrote:
> On Fri, Feb 01, 2019 at 05:58:30PM +, shirish शिरीष wrote:
>> Package: apt-file
>> Version: 3.2.1
>> Severity: normal
>>
>> Dear Maintainer,
>> Thank you for maintaining apt-file. While the documentation is good,
>> some of the documentation
>> either needs to be fixed or removed.
>>
>> For e.g. in
>>
>> /usr/share/doc/apt-file$ zless README.md.gz
>>
>> I get the following at the very end -
>>
>> [much-faster-incremental-apt-updates]:
>> https://juliank.wordpress.com/2015/12/26/much-faster-incremental-apt-updates/
>> [apt-1-1-8-to-1-1-10-going-faster]:
>> https://juliank.wordpress.com/2015/12/30/apt-1-1-8-to-1-1-10-going-faster/
>>
>>
>> Both of these pages on the Julian Andreas Klose are marked as
>> protected pages so aren't viewable as public pages unfortunately.
>> Either they should be publicly viewable or if that's not possible then
>> perhaps remove them from the documentation or some third way found
>> out.
>
> Whoa, a lot of typos in my name :)
>
> That's just a matter of s#juliank.wordpress.com#blog.jak-linux.org#
> - unfortunately wordpress does not allow you to setup redirects, otherwise
> they'd be there (unless you pay a _lot_ of money for their premium
> offerings,
> then you can).
>
>
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
>

Oops, sorry meant it to be Julian Andres Klode . I was under the
impression  (or assumption) that you are somehow close to Matthias
Klose . Please don't ask me how, it's partly the culture I am bought
up :)

Anyways, I was able to see -

https://blog.jak-linux.org//2015/12/26/much-faster-incremental-apt-updates/
https://blog.jak-linux.org/2015/12/30/apt-1-1-8-to-1-1-10-going-faster/

It probably would make more sense to add these links of the links
shared therein.

I actually came on this due to

https://unix.stackexchange.com/questions/498144/why-doesnt-appstream-have-apt-pdiff-like-structure?

Hoping to know if we can see more .pdiffs in the near future. I could
live with a bit more processing time.

-- 
  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#794624: RFP: web-mode -- web template editing mode for emacs

[Nicholas D Steeves]

Hi Antoine and Emacsen team,

On Tue, Aug 04, 2015 at 09:43:38PM -0700, Francois Marier wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: web-mode
>   Version : 12
>   Upstream Author : François-Xavier Bois 
> * URL : http://web-mode.org/
> * License : GPL
>   Programming Lang: emacs lisp
>   Description : web template editing mode for emacs
> 
> web-mode.el is an autonomous emacs major-mode for editing web templates.
> HTML documents can embed parts (CSS / JavaScript) and blocks (client /
> server side).

Do you want to co-maintain this one?  PHP-mode recommends using
web-mode for files that are HTML+PHP blocks.  I think it would be a
useful addition to the archive, but I don't use it myself...

With a MELPA popcon at 99.12 percentile, it really ought to be packaged.

Got to run!
Nicholas


signature.asc
Description: PGP signature

Bug#827827: ERROR: php-elisp is broken - called emacs-package-install as a new-style add-on, but has no compat file.

[Nicholas D Steeves]

Hi Antoine!

On Wed, Oct 31, 2018 at 11:46:20AM -0400, Antoine Beaupre wrote:
> On Fri, Jul 29, 2016 at 07:42:00AM +0200, Ola Lundqvist wrote:
> > Hi
> > 
> > Sorry for the delayed answer. I tried to reproduce your problem myself but
> > failed.
> > 
> > What was your from version?
> > 
> > Are you running sid or what version of debian in general?
> 
> This is reproducible right now in Debian Buster.
> 
> $ sudo apt install php-elisp 
> Lecture des listes de paquets... Fait
> Construction de l'arbre des dépendances   
> Lecture des informations d'état... Fait
> Paquets suggérés :
>   php5 php5-cli
> Paquets recommandés :
>   speedbar
> Les NOUVEAUX paquets suivants seront installés :
>   php-elisp
> 0 mis à jour, 1 nouvellement installés, 0 à enlever et 1 non mis à jour.
> Il est nécessaire de prendre 26,7 ko dans les archives.
> Après cette opération, 150 ko d'espace disque supplémentaires seront utilisés.
> Réception de:1 http://cdn-fastly.deb.debian.org/debian buster/main amd64 
> php-elisp all 1.13.5-3 [26,7 kB]
> 26,7 ko réceptionnés en 1s (52,9 ko/s)
> [master baf904a] saving uncommitted changes in /etc prior to apt run
>  Author: Antoine Beaupré 
>  2 files changed, 70 deletions(-)
>  delete mode 100644 libvirt/qemu/stretch64_default.xml
> Récupération des rapports de bogue… Fait
> Analyse des informations Trouvé/Corrigé… Fait
> Sélection du paquet php-elisp précédemment désélectionné.
> (Lecture de la base de données... 616958 fichiers et répertoires déjà 
> installés.)
> Préparation du dépaquetage de .../php-elisp_1.13.5-3_all.deb ...
> Dépaquetage de php-elisp (1.13.5-3) ...
> Paramétrage de php-elisp (1.13.5-3) ...
> ERROR: php-elisp is broken - called emacs-package-install as a new-style 
> add-on, but has no compat file.
> Install php-elisp for emacs
> Install php-elisp for emacs

I think the issue might be that php-elisp_1.13.5-3 is missing the
"new-style" (now "old-style" since dh-elpa is new-style)
debian/foo.emacsen.compat.  The issue still exists when upgrading to
php-elisp_1.21.0-1 (dummy transitional package), which is particularly
bizarre, but as far as I can tell it's harmless, and piuparts seems to
confirm this.

BTW, if you have time could you look at this php-elisp RFS?:  #921130


Take care!
Nicholas


signature.asc
Description: PGP signature

Bug#916642: golang CVE-2019-6486 (DoS in crypto/elliptic)

[James McCoy]

On Fri, Jan 25, 2019 at 08:23:52AM -0500, James McCoy wrote:
> On Thu, Jan 24, 2019 at 03:00:22PM +0100, Dr. Tobias Quathamer wrote:
> > Am 24.01.2019 um 09:12 schrieb Emilio Pozuelo Monfort:
> > > On 24/01/2019 08:58, Michael Stapelberg wrote:
> > >> Last time, pochu@ (cc'ed) helpfully scheduled binNMUs. pochu, would you 
> > >> be
> > >> able to help this time, too?
> > > 
> > > Sure. Can you give me a list of source packages to binNMU in unstable? If 
> > > this
> > > is public already, can you do that through a binNMU bug against 
> > > release.debian.org?
> > > 
> > > Emilio
> > 
> > Hi all,
> > 
> > there is already an outdated binNMU list as bug report available, so
> > I'm reusing that report. Please ignore the previously attached
> > binNMU list of that bug report.
> > 
> > This should be a complete and current list of needed binNMUs:
> > 
> > 
> > [‥]
> >   nmu serf_0.8.1+git20180508.80ab4877~ds-1 . ANY . -m 'Rebuild with current 
> > golang-1.11 (CVE-2019-6486)'
> 
> This is a (common) mistake.  src:serf does not use golang.
> src:golang-github-hashicorp-serf is the golang package, which producees
> bin:serf, however I just saw that src:serf was binNMUed.

Ping.

nmu golang-github-hashicorp-serf_0.8.1+git20180508.80ab4877~ds-1 . ANY .  -m 
'Rebuild with current golang-1.11 (CVE-2019-6486)'

Tobias, your tool should be updated to ensure it's using the source
pacakge name, not the binary package name.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#921137: emails sent from /etc/mailname, ignoring configured domain

[Antoine Beaupre]

Package: mailman3
Version: 3.2.0-4~bpo9+1
Severity: grave

I'm finding it difficult to use the "domain" feature of Mailman 3. From
what I understand, it allows you to have two distinct mailing lists
named "test" on (say) t...@example.com and t...@example.net.

Here I'm specifically using the feature to host my mailing lists on
lists.anarc.at instead of plain anarc.at. Yet I don't know what I'm
doing wrong, but all outgoing email comes from t...@anarc.at instead of
t...@lists.anarc.at. This makes replies obviously fail as the LTMP maps
don't have that domain:

# grep ^[^#] /var/spool/postfix/mailman3/postfix_domains
# /var/spool/postfix/mailman3/postfix_lmtp
/var/spool/postfix/mailman3/postfix_domains:lists.anarc.at lists.anarc.at
/var/spool/postfix/mailman3/postfix_lmtp:
/var/spool/postfix/mailman3/postfix_lmtp:t...@lists.anarc.at 
lmtp:[127.0.0.1]:8024
/var/spool/postfix/mailman3/postfix_lmtp:test-boun...@lists.anarc.at 
lmtp:[127.0.0.1]:8024
/var/spool/postfix/mailman3/postfix_lmtp:test-conf...@lists.anarc.at 
lmtp:[127.0.0.1]:8024
/var/spool/postfix/mailman3/postfix_lmtp:test-j...@lists.anarc.at 
lmtp:[127.0.0.1]:8024
/var/spool/postfix/mailman3/postfix_lmtp:test-le...@lists.anarc.at 
lmtp:[127.0.0.1]:8024
/var/spool/postfix/mailman3/postfix_lmtp:test-ow...@lists.anarc.at 
lmtp:[127.0.0.1]:8024
/var/spool/postfix/mailman3/postfix_lmtp:test-requ...@lists.anarc.at 
lmtp:[127.0.0.1]:8024
/var/spool/postfix/mailman3/postfix_lmtp:test-subscr...@lists.anarc.at 
lmtp:[127.0.0.1]:8024
/var/spool/postfix/mailman3/postfix_lmtp:test-unsubscr...@lists.anarc.at 
lmtp:[127.0.0.1]:8024

I've tried various things to fix this: I recreated the "domain" in the
Posterious interface. I have changed the "mailname" when running
dpkg-reconfigure mailman3-web, restarting it, which gave me this diff:

--- a/mailman3/mailman-web.py
+++ b/mailman3/mailman-web.py
@@ -130,7 +130,7 @@ USE_TZ = True


 # Set default domain for email addresses.
-EMAILNAME = 'localhost.local'
+EMAILNAME = 'anarc.at'
 
 # If you enable internal authentication, this is the address that the emails
 # will appear to be coming from. Make sure you set a valid domain name,

Still, "mass subscribe" emails come out as "t...@anarc.at", even though
the footer clearly reads:

To unsubscribe send an email to test-le...@lists.anarc.at

When I write an email there, I get a reply saying to reply to:

test-confirm+14ea1ffec9434c30b983e1d5ab071b4988af4...@anarc.at

... which is still wrong and will (obviously) bounce.

What's going on here?

Here's a log of an admin mass-subscribing a user:

==> /var/log/mailman3/web/mailman-web.log <== 
[pid: 2680|app: 0|req: 5/5] 192.168.0.7 () {82 vars in 1587 bytes} [Sat Feb  2 
01:22:11 2019] POST 
/mailman3/postorius/lists/test.lists.anarc.at/mass_subscribe/ => generated 9458 
bytes in 468 msecs (HTTP/2.0 200) 6 headers in 317 bytes (3 switches on core 0) 

==> /var/log/mail.log <== 
Feb  1 20:22:12 marcos postfix/smtpd[4889]: connect from localhost[127.0.0.1] 
Feb  1 20:22:12 marcos postfix/smtpd[4889]: DD2E510E1D8: 
client=localhost[127.0.0.1]
Feb  1 20:22:12 marcos postfix/cleanup[5789]: DD2E510E1D8: 
message-id=<154907053190.742.3083806269187387...@marcos.anarc.at>

==> /var/log/mailman3/smtp.log <== 
Feb 01 20:22:12 2019 (746) 
<154907053190.742.3083806269187387...@marcos.anarc.at> smtp to 
t...@lists.anarc.at for 1 recips, completed in 0.03175711631774902 seconds 

==> /var/log/mail.log <== 
Feb  1 20:22:12 marcos postfix/qmgr[31811]: DD2E510E1D8: 
from=, size=581, nrcpt=1 (queue active)
Feb  1 20:22:12 marcos postfix/smtpd[5791]: connect from localhost[127.0.0.1] 

==> /var/log/mailman3/smtp.log <== 
Feb 01 20:22:12 2019 (746) 
<154907053190.742.3083806269187387...@marcos.anarc.at> post to 
t...@lists.anarc.at from test-requ...@lists.anarc.at, 362 bytes 

==> /var/log/mail.log <== 
Feb  1 20:22:12 marcos postfix/smtpd[4889]: disconnect from 
localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 commands=4 
Feb  1 20:22:12 marcos postfix/smtpd[5791]: EAED510E1DA: 
client=localhost[127.0.0.1]
Feb  1 20:22:13 marcos spampd[24505]: processing message 
<154907053190.742.3083806269187387...@marcos.anarc.at> for 
 ORCPT=rfc822;anar...@example.net 
Feb  1 20:22:14 marcos spampd[24505]: clean message 
<154907053190.742.3083806269187387...@marcos.anarc.at> (-1.31/5.00) from 
 for  
ORCPT=rfc822;anar...@example.net in 1.10s, 1087 bytes. 
Feb  1 20:22:14 marcos postfix/cleanup[5789]: EAED510E1DA: 
message-id=<154907053190.742.3083806269187387...@marcos.anarc.at>
Feb  1 20:22:14 marcos postfix/qmgr[31811]: EAED510E1DA: 
from=, size=1583, nrcpt=1 (queue active)
Feb  1 20:22:14 marcos postfix/smtp[5799]: DD2E510E1D8: 
to=, relay=127.0.0.1[127.0.0.1]:10025], delay=1.2, 
delays=0.02/0/0.03/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
EAED510E1DA)
Feb  1 20:22:14 marcos postfix/smtpd[5791]: disconnect from 
localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 
Feb  1 20:22:14 marcos postfix/qmgr[31811]: DD2E510E1

Bug#921136: lintian: hardening-no-fortify-functions possible false positive

[Scott Talbert]

Package: lintian
Version: 2.5.124
Severity: normal

Dear Maintainer,

I'm trying to figure out why my package (wxpython4.0) is getting flagged for
hardening-no-fortify-functions even though I have
export DEB_BUILD_MAINT_OPTIONS = hardening=+all in my debian/rules and I can see
the -DFORTIFY_SOURCE=2 being set in g++ arguments.

I added some debug to binaries.pm and I determined that it is only finding
wmemcpy function as not being hardened.  I grepped my source tree and I do not
find any calls to wmemcpy.  I then ran objdump -d on one of the built .so's.  If
I am reading the objdump correctly, the only calls to wmemcpy are in functions
named like:

_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag

This sounds like some sort of auto-generated C++ function?

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

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

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

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

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

-- no debconf information

Bug#921135: courier: [INTL:pt] Updated Portuguese translation for debconf

[Traduz PT]

Package: courier
Version: 1.0.5-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for courier's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org
# Portuguese translation of courier's debconf messages.
# 2005, Miguel Figueiredo 
# 30-10-2005 - Miguel Figueiredo  - initial translation
# Miguel Figueiredo , 2005-2008
# Rui Branco , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: courier 1.0.5-2\n"
"Report-Msgid-Bugs-To: cour...@packages.debian.org\n"
"POT-Creation-Date: 2018-10-23 20:55+0200\n"
"PO-Revision-Date: 2019-02-02 00:36+\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\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"

#. Type: boolean
#. Description
#: ../courier-base.templates:2001
msgid "Create directories for web-based administration?"
msgstr "Criar os directórios para administração via web?"

#. Type: boolean
#. Description
#: ../courier-base.templates:2001
msgid ""
"Courier uses several configuration files in /etc/courier. Some of these "
"files can be replaced by a subdirectory whose contents are concatenated and "
"treated as a single, consolidated, configuration file."
msgstr ""
"O courier utiliza vários ficheiros de configuração que estão em /etc/"
"courier. Alguns desses ficheiros de configuração podem ser substituídos por "
"um subdirectório cujo conteúdo é concatenado e tratado como um único "
"ficheiro de configuração."

#. Type: boolean
#. Description
#: ../courier-base.templates:2001
msgid ""
"The web-based administration provided by the courier-webadmin package relies "
"on configuration directories instead of configuration files.  If you agree, "
"any directories needed for the web-based administration tool will be created "
"unless there is already a plain file in place."
msgstr ""
"A administração via web disponibilizada pelo pacote courier-webmin baseia-se "
"em directórios de configuração em vez de ficheiros de configuração.  Se "
"concordar, serão criados quaisquer directórios necessários para a ferramenta "
"de administração via web a menos que já exista no local um ficheiro simples."

#. Type: string
#. Description
#: ../courier-base.templates:3001
msgid "Path to Maildir directory:"
msgstr "Caminho para o directório Maildir:"

#. Type: string
#. Description
#: ../courier-base.templates:3001
msgid ""
"Please give the relative path name from each user's home directory to the "
"Maildir directory where the Courier servers store and access the user's "
"email. Please refer to the maildir.courier(5) manual page if you are "
"unfamiliar with the mail storage format used by Courier."
msgstr ""
"Por favor indique o caminho relativo a partir do directório 'home' de cada "
"utilizador para o directório Maildir onde os servidores Courier guardam e "
"acedem ao email do utilizador. Por favor veja a página maildir.courier(5) do "
"manual se não estiver familiarizado com o formato de armazenamento de mail "
"utilizado pelo Courier."

#. Type: note
#. Description
#: ../courier-base.templates:4001
msgid "Obsolete setting of MAILDIR"
msgstr "Definição obsoleta de MAILDIR"

#. Type: note
#. Description
#: ../courier-base.templates:4001
msgid ""
"The name of the Maildir directory is now recognized through the variable "
"MAILDIRPATH in Courier configuration files. The MAILDIR setting in /etc/"
"default/courier is therefore obsolete and will be not recognized."
msgstr ""
"O nome do directório Maildir é agora reconhecido através da variável "
"MAILDIRPATH nos ficheiros de configuração do Courier. Por isso a definição "
"MAILDIR em /etc/default/courier é por isso obsoleta e não será reconhecida."

#. Type: note
#. Description
#: ../courier-base.templates:5001
msgid "SSL certificate required"
msgstr "É necessário um certificado SSL"

#. Type: note
#. Description
#: ../courier-base.templates:5001
msgid ""
"POP and IMAP over SSL requires a valid, signed, X.509 certificate. During "
"the installation of courier-pop or courier-imap, a self-signed X.509 "
"certificate will be generated if necessary."
msgstr ""
"POP e IMAP sobre SSL necessitam de um certificado X.509 válido e assinado. "
"Durante a instalação de courier-pop ou do courier-imap, se necessário, irá "
"ser gerado um certificado X.509 auto-assinado."

#. Type: note
#. Description
#: ../courier-base.templates:5001
msgid ""
"For production use, the X.509 certificate must be signed by a recognized "
"certificate authority, in order for mail clients to accept the certificate. "
"The default location for this certificate is /etc/courier/pop3d.pem or /etc/"
"courier/imapd.pem."
msgstr ""
"Para a utilização em produção, o certificado X.509 tem de ser assinado por "
"uma a

Bug#920197: preload: FTBFS (configure: error: unrecognized option: --runstatedir=/run)

[Steve Langasek]

Package: preload
Version: 0.6.4-3
Followup-For: Bug #920197
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hello,

I think this problem is caused by the autoreconf cruft found in the debian/
directory of the package, which causes the package to fail to reautoconf at
build time leading to the unrecognized configure option.

The attached patch fixed the immediate failure, and I've uploaded this
solution to Ubuntu, but it looks like the root cause is a broken clean
target in debian/rules that completely supersedes all the normal cleaning
that would be done by debhelper.  This seems to be a carry-over from cdbs
packaging that needs fixing.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru preload-0.6.4/debian/autoreconf.after 
preload-0.6.4/debian/autoreconf.after
--- preload-0.6.4/debian/autoreconf.after   2019-01-22 01:44:27.0 
-0800
+++ preload-0.6.4/debian/autoreconf.after   2019-02-01 16:09:33.0 
-0800
@@ -1,65 +1,64 @@
-08bca3d91c04e1f55734a9319939eb5e  ./ChangeLog
-e4cd5bc81d24dfd57af27179e7796a75  ./config.h.in
-00ff06eb78ffb538cb7df3ba2181c5dc  ./doc/Makefile.in
-588a2e052eaf5ac1be27de0ede1fc6c0  ./doc/Makefile.am
-7a9bb8deb33ae4f3171441a9af05da06  ./doc/index.txt
-1d2de091a00528a1a09f6b8df3e3f3f7  ./doc/proposal.txt
-a39e3f7d3f35aa2fd3af4d2eea48d4fc  ./aclocal.m4
-7693343570c07c39d9a92ad072f72edd  ./Makefile.in
-5300bd407f35038e89de0c1306dbe1f6  ./preload.sysconfig
-cb8a57cdef528963a329d47fd2b7c901  ./Makefile.am
-28e27b0082703426127843fe36c96cc0  ./compile
-aa58e4936fb507a8750c466ced371479  ./test-driver
-f2766448e74c24bd1c1c5d12466093ae  ./INSTALL
-94d55d512a9ba36caa9b7df079bae19f  ./COPYING
-0a4020dd453e4398def2dc9084265c3f  ./README
-e8a673d5d4d69a5fd11c880fd4c3c481  ./.pc/.quilt_series
-26ab0db90d72e28ad0ba1e22ee510510  ./.pc/.version
-5184d5e7b185b3ca618a22cb9838bee6  ./.pc/applied-patches
-266f9759f56277b2751b24d1eb17c50f  ./.pc/.quilt_patches
-386ed3ea02ab90602bb2b51ddd96ef35  ./.pc/logrotate_619384/preload.logrotate.in
-63ab979857639674fcb76b1b8a3083fc  ./configure
-cc06f4e9397b16ab4b6a0495b86ca8e3  ./TODO
-e5f9da8b55623ead67f2bcfee03fb4d4  ./depcomp
-58a68a299803ade9543fcdaf27c143cc  ./autom4te.cache/output.0
-10464c4e2e346c0316dc80073fc38011  ./autom4te.cache/requests
-6b02f9cfaf70fe05e7a86620038b10c0  ./autom4te.cache/traces.0
-58a68a299803ade9543fcdaf27c143cc  ./autom4te.cache/output.1
-7d07555cf8d9af6f9496c32520a08640  ./autom4te.cache/traces.1
-e34b04fd4b07e8f0ceaab89f7b1d274c  ./THANKS
-da3c716f899afe51a6737a71f08452d5  ./NEWS
-ff06331c3f16a2d526d6399dfeabf67a  ./missing
-472a31e0c9792ef1357e23141428b670  ./config.h.in~
 b857907314b489718a912f9319a80ab8  ./preload.init.in
-bc4767ee13cba3152763fdb5721f9af0  ./configure.ac
 bac3fb7f33d1f10f02f0b6460d2eee12  ./install-sh
-d565d498e625e685242528d1243962f7  ./README-alpha
-e0d3d68d1a43785a28f2ea8d26b6f2b0  ./src/prophet.h
-d518e0500f0bc474fd180856a4cfe522  ./src/cmdline.c
-5d0ab684d2be7fc0708f077cfcbcf716  ./src/runtests.sh
+cb8a57cdef528963a329d47fd2b7c901  ./Makefile.am
+94d55d512a9ba36caa9b7df079bae19f  ./COPYING
+0e1057593cccf0a26374a251bd0924c1  ./Makefile.in
+c835301cf32d9f86e8c4c404c80f2cd4  ./src/preload.c
+82bc5c0e364dc75b0e978e1fef55b10c  ./src/cmdline.h
+f0e4cfcf26b25d6fc49b890dd4a95e5b  ./src/Makefile.am
 a051df7c94d0204641e194d07c068ce2  ./src/Makefile.in
-fa95ee4141d23d7b2e86cf619b767807  ./src/conf.h
 8a829f54c5f825916b6b0ffa904f097a  ./src/common.h
-c1734f5d4008e4d11082e92251a1350c  ./src/log.c
-f0e4cfcf26b25d6fc49b890dd4a95e5b  ./src/Makefile.am
-7fd53c60d5de66166e9caf769c91677e  ./src/preload.h
-555e337d5f7a9f4de65d07c6bd2e659d  ./src/proc.c
+5d0ab684d2be7fc0708f077cfcbcf716  ./src/runtests.sh
 cc6db034dadd9f1422d95239994d  ./src/spy.c
-c835301cf32d9f86e8c4c404c80f2cd4  ./src/preload.c
-6a1060a99165a8095115ab5b2c4ecac0  ./src/proc.h
-b7aa3ced3c7f2fe48054a6af79f7d020  ./src/readahead.c
-eae1159bb02991420b1333782a4f6753  ./src/state.h
+a74f4468373befe919e4d8060ed08623  ./src/prophet.c
 d3ed82bad622306c1d9714a0645dd824  ./src/confkeys.h
+b82d65305077c8bd535cf34fc868b632  ./src/readahead.h
+fa95ee4141d23d7b2e86cf619b767807  ./src/conf.h
 a4796671b79fb615b903393c83bc8cf1  ./src/preload.conf.in
+4906a35fd725f269905e9cdaf5b893ba  ./src/state.c
+eae1159bb02991420b1333782a4f6753  ./src/state.h
 95708d8cc0096ff31ea0d2a238a46d79  ./src/gen.preload.conf.sh
-82bc5c0e364dc75b0e978e1fef55b10c  ./src/cmdline.h
-a74f4468373befe919e4d8060ed08623  ./src/prophet.c
+c1734f5d4008e4d11082e92251a1350c  ./src/log.c
+555e337d5f7a9f4de65d07c6bd2e659d  ./src/proc.c
+7ee3be6b8009de33a7383bfbefb85f5b  ./src/preload.8.i
+7fd53c60d5de66166e9caf769c91677e  ./src/preload.h
+d518e0500f0bc474fd180856a4cfe522  ./src/cmdline.c
+e0d

Bug#920304: mailman3-web: mailman3web / django does not like python3-pymysql

[Antoine Beaupre]

Package: mailman3-web
Version: 0+20180916-4
Followup-For: Bug #920304

This actually also occurs in buster at the time of writing and should
definitely be fixed in unstable, not just in backports.

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

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

Versions of packages mailman3-web depends on:
pn  dbconfig-sqlite3 | dbconfig-pgsql | dbconfig-mysql | dbconfi  
ii  debconf [debconf-2.0] 1.5.70
ii  lsb-base  10.2018112800
pn  node-less 
ii  python3   3.7.2-1
pn  python3-django-hyperkitty 
pn  python3-django-postorius  
ii  python3-pymysql   0.9.3-1
pn  python3-whoosh
ii  ruby-sass 3.5.6-1
ii  ucf   3.0038+nmu1
pn  uwsgi 
ii  uwsgi-plugin-python3  2.0.17.1-11

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.37-1

Versions of packages mailman3-web suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.12-2

Bug#921128: mailman3-web fails to initialize mysql: Specified key was too long

[Antoine Beaupre]

Package: mailman3-web
Followup-For: Bug #921128

I have tried to reproduce this in buster and at first I seem to recall
I did reproduce it, but now I somewhat managed to get through and have
it installed correctly.

Also note this might be a bug specific to MySQL: running the dbconfig
stuff with a sqlite3 backend doesn't trigger the same bug, even in
backports.

That said, the bug doesn't occur within dbconfig itself. It's the
django migration that raises the backtrace (which is logical
considering dbconfig is written in shell and not
Python). Specifically, this command reproduces the problem outside of
dpkg:

su --shell /bin/sh --command "python3 /usr/bin/django-admin migrate --no-input 
--verbosity 3 --pythonpath /usr/share/mailman3-web --settings settings" www-data

And, for what it's worth, I tried backporting the 0+20180916-4 release
of mailman-suite, to no effect: the same error still occurs.

A.

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

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

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.11
ii  debconf [debconf-2.0]  1.5.70
ii  lsb-base   10.2018112800
ii  node-less  1.6.3~dfsg-3
ii  python33.7.2-1
ii  python3-django-hyperkitty  1.2.1-4
ii  python3-django-postorius   1.2.2-4
ii  python3-psycopg2   2.7.7-1
ii  python3-pymysql0.9.3-1
ii  python3-whoosh 2.7.4+git6-g9134ad92-1
ii  ruby-sass  3.5.6-1
ii  ucf3.0038+nmu1
ii  uwsgi  2.0.17.1-11
ii  uwsgi-plugin-python3   2.0.17.1-11

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.37-1

Versions of packages mailman3-web suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.12-2

-- debconf-show failed

Bug#921132: lightdm: Laptop with external monitor Xfce lock screen causes 100% CPU

[David Christensen]

Package: lightdm
Version: 1.18.3-1
Severity: normal

Dear Maintainer,

I have a Dell Inspiron E1505 laptop with Debian 9.7 amd64 and Xfce.  I
use an external monitor, keyboard, and mouse via a KVM switch.  When I
lock the screen, the CPU goes to 100%:

2019-02-01 15:29:57 dpchrist@tinkywinky ~
$ top -b -n 1 | head
top - 15:30:01 up  7:59,  2 users,  load average: 1.19, 1.17, 1.08
Tasks: 241 total,   2 running, 239 sleeping,   0 stopped,   0 zombie
%Cpu(s): 30.6 us,  5.2 sy,  0.3 ni, 63.7 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  2043088 total,87792 free,   926800 used,  1028496 buff/cache
KiB Swap:  1952764 total,  1786848 free,   165916 used.   422364 avail Mem

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
 6539 lightdm   20   0  587524  51660  25884 R  87.5  2.5 103:00.92 lightdm-gt+
 6528 root  20   0  259824  19520  13004 S  18.8  1.0  12:47.44 Xorg
 6915 dpchrist  20   0   43276   3464   2856 R   6.2  0.2   0:00.03 top
~  


Please advise with trouble-shooting steps.


David



-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages lightdm depends on:
ii  adduser3.115
ii  dbus   1.10.26-0+deb9u1
ii  debconf [debconf-2.0]  1.5.61
ii  libaudit1  1:2.6.7-2
ii  libc6  2.24-11+deb9u3
ii  libgcrypt201.7.6-2+deb9u3
ii  libglib2.0-0   2.50.3-2
ii  libpam-systemd 232-25+deb9u8
ii  libpam0g   1.1.8-3.6
ii  libxcb11.12-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.2-1

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
pn  accountsservice  
ii  upower   0.99.4-4+b1
pn  xserver-xephyr   

-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm

Bug#921133: CVE-2018-17613

[Moritz Muehlenhoff]

Package: telegram-desktop
Severity: important
Tags: security

This got assigned CVE-2018-17613:
https://seclists.org/oss-sec/2018/q3/280

Not sure if this is fixed in the version in sid/buster?

Cheers,
Moritz

Bug#903092: [RSVP] php-elisp: permission to relicense contributions required from past contributors

[Nicholas D Steeves]

Dear Ola, Pontus, and Debian Legal team,

It seems Thierry is MIA, and will not be confirming permission to
relicense his contributions to d/changelog and d/control.  Please let
me know if the following blocks moving to GPL-3+ debian/* and a
machine-readable format: 1.0 debian/copyright.  At this point I
suspect it does, but I am erring on the side of caution.

On Mon, Jul 30, 2018 at 05:46:27PM +0200, pon...@ullgren.com wrote:
>This is acceptable by me.
>// Pontus
> 
>  > On Thu, Jul 05, 2018 at 09:01:30PM -0400, Nicholas D Steeves wrote:
>  >> Package: php-elisp
>  >> Version: 1.13.5-3
>  >> Severity: normal
>  >>
>  >> Dear Ola, Moritz, Thierry, and Pontus,
>  >>
>  >> The Debian Emacsen team is adopting php-elisp.Ã*  At this time we
>  would
>  >> like to move to machine-readable copyright format 1.0 and harmonise
>  >> update the copyright of debian/* to GPL-3+, which upstream has
>  >> migrated to.
>  >>
>  >> Please reply to this bug to confirm that you consent to GPL-3+
>  >> relicensing of your past contributions.
> 
>  Php-elisp is ready to upload. Would you please confirm if GPL-3+ is
>  an acceptable license for your contributions to this package?

d/copyright:

  This package was debianized by Ola Lundqvist  on
  Mon, 26 Feb 2001 21:33:20 +0100.
  New co-maintainer since Thu, 14 Aug 2003 18:30:27 +0200 is
  Pontus Ullgren .

  It was downloaded from:
  https://github.com/ejmr/php-mode

  Copyright:
 Copyright (C) 1999, 2000, 2001, 2003, 2004 Turadg Aleahmad
   2008 Aaron S. Hawley
   2011, 2012, 2013, 2014 Eric James Michael Ritz

  License:

  This program is free software; you can redistribute it and/or
  modify it under the terms of the GNU General Public License
  as published by the Free Software Foundation; either version 2
  of the License, or (at your option) any later version.


d/changelog:
...
php-elisp (1.5.0-1.1) unstable; urgency=low

  * Non-maintainer upload.
  * Prevent byte compilation on xemacs21, since it's incompatible
(Closes: #584698)

 -- Moritz Muehlenhoff   Thu, 05 Aug 2010 16:37:37 -0400

php-elisp (1.5.0-1) unstable; urgency=low

  * New upstream release (Closes: #368061, #291207)
  * New maintainer (Closes: #525947)
  * debian/control:
+ bumped Standards-Version to 3.8.4
+ added ${misc:Depends} in Depends
+ updated Depends to emacs23 | emacs22 | emacsen
+ updated Suggests to php5 | php5-cli
+ updated Section to lisp
+ added in Recommends field speedbar (Closes: #500120)
+ used debhelper 7
+ added Homepage field
+ added texi2html in Build-Depends to generate manual (Closes: #476197)
  * debian/rules:
+ removed emacs21 references (Closes: #269650)
+ used binary-indep instead of binary-arch target
  * debian/copyright
+ added copyright notice
  * Added compat, docs, watch files
  * switched to dpkg-source 3.0 (quilt) format

 -- Thierry Randrianiriana   Sun, 09 May 2010 09:00:55 +0300

php-elisp (1.4.0-3) unstable; urgency=low


Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#880868: wordpress: CVE-2012-6707

[Moritz Mühlenhoff]

On Sun, Nov 05, 2017 at 09:51:43AM +0100, Salvatore Bonaccorso wrote:
> Source: wordpress
> Version: 4.8.3+dfsg-1
> Severity: normal
> Tags: security upstream
> Forwarded: https://core.trac.wordpress.org/ticket/21022
> Control: found -1 4.1+dfsg-1
> 
> Hi,
> 
> the following vulnerability was published for wordpress, this
> bugreport is mainly just to track the upstream report. A patch has
> been posted several months ago on that upstream bugreport at [1]/
> 
> CVE-2012-6707[0]:
> | WordPress through 4.8.2 uses a weak MD5-based password hashing
> | algorithm, which makes it easier for attackers to determine cleartext
> | values by leveraging access to the hash values. NOTE: the approach to
> | changing this may not be fully compatible with certain use cases, such
> | as migration of a WordPress site from a web host that uses a recent PHP
> | version to a different web host that uses PHP 5.2. These use cases are
> | plausible (but very unlikely) based on statistics showing widespread
> | deployment of WordPress with obsolete PHP versions.

Does this still affect 5.0.2?

Cheers,
Moritz

Bug#921131: CVE-2018-10897

[Moritz Muehlenhoff]

Package: yum-utils
Severity: grave
Tags: security

This was assigned CVE-2018-10897:
https://bugzilla.redhat.com/show_bug.cgi?id=1600221
https://github.com/rpm-software-management/yum-utils/commit/7554c0133eb830a71dc01846037cc047d0acbc2c
https://github.com/rpm-software-management/yum-utils/commit/6a8de061f8fdc885e74ebe8c94625bf53643b71c
https://github.com/rpm-software-management/yum-utils/pull/43

Cheers,
Moritz

Bug#909798: ITP: ryzomcore -- science-fantasy MMORPG engine

[Phil Morrell]

As a status update, the `ryzom-client` package in the above repo can
replace the official download, connecting to the official servers.

Although this is discouraged in the documentation, the impression I got
from interacting upstream is that's for anti-cheat purposes, so an
unmodified build may well be fully supported. Would still need to review
LTS/fastpaced before inclusion.

Assets is still an open question with the client currently downloading
on first launch and updating via patcher. Sounds can be removed *after*
patching without unexpected downsides (ryzom_live/data/sound.bnp).


signature.asc
Description: PGP signature

Bug#765104: Update hfsprogs to 572.1.1

[Rogério Brito]

Dear John Paul,


On Tue, Jan 29, 2019 at 8:13 AM John Paul Adrian Glaubitz
 wrote:
> Both Fedora and Arch are shipping a patched version 540.1 [1, 2],
> so updating to newer versions seems possible with some elbow
> grease.

> > [1] https://src.fedoraproject.org/rpms/hfsplus-tools/tree/master
> > [2] https://aur.archlinux.org/packages/hfsprogs/

Thanks for the pointers. I will try to work on these ASAP (including
some at least another package of mine), since the new version that
they may have package is sure to have many, many fixes and new
features, compared to what we currently have in Debian.

> Could you maybe import the sources from Fedora and thus update the
> Debian package to version 540.1?

Will do (and migrate everything to salsa and modernize the package,
eliminate patches etc.).

> Thanks,
> Adrian

Thanks,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#921130: RFS: php-elisp/1.21.0-1 [ITA]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal
Control: block 902633 by -1

Dear Mentors, Ola, and Moritz,

I am looking for a sponsor for my update/adoption of "php-elisp".

Package name: php-elisp
Version : 1.21.0-1
Upstream Author : USAMI Kenta  (current maintainer)
URL : https://github.com/emacs-php/php-mode
License : GPL-3+
Section : lisp

It builds these binary packages:

  elpa-php-mode - PHP Mode for GNU Emacs
  php-elisp - transitional package, php-elisp to elpa-php-mode

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

  https://mentors.debian.net/package/php-elisp

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/php-elisp/php-elisp_1.21.0-1.dsc

Alternatively, clone this git repo and use upstream git tag or uscan for the 
upstream source:

  git clone https://salsa.debian.org/emacsen-team/php-elisp.git

Changes since the last upload:

php-elisp (1.21.0-1) unstable; urgency=medium

  * Adopt package (Closes: #902633).
- Add Emacsen team VCs links.
- Set Maintainer to Debian Emacsen Team.
- Add Ola Lundqvist and myself to Uploaders.
  * New upstream release (Closes: #895743).
  * Elpafy php-elisp:
- Implicitly drops support for xemacs (Closes: #665314).
- Add dh-elpa to Build-Depends.
- Add new package: elpa-php-mode.
- Convert php-elisp to dummy transitional package.
- Rewrite debian/rules.
- Enable autopkgtests.
- Drop obsolete emacsen packaging directives: php-elisp.dirs,
  php-elisp.emacsen-install, php-elisp.emacsen-remove,
  php-elisp.emacsen-startup, php-elisp.emacsen-startup.new
  (Closes: #827827).
  * Declare compat level 11.
  * Switch to debhelper 11.
  * Declare Standards-Version: 4.3.0.
  * Update watchfile to v4, and update upstream project's location.
  * Suggest php and php-cli rather than php5 and php5-cli.
  * Add gbp.conf.
  * Add patch to disable php-project-root selftest.
  * Add upstream README.
  * Update Homepage, because php-mode has a new upstream maintainer.
The project's transfer of ownership is documented here:
https://github.com/emacs-php/php-mode/issues/387
  * Drop out-of-date php-elisp.README.Debian.  The upstream README contains
this information.
  * Add debian/NEWS to notify users of depreciated PHP 2 support, and show
how to restore the behaviour of past php-elisp releases.

 -- Nicholas D Steeves   Fri, 01 Feb 2019 14:43:45 -0700

php-elisp (1.13.5-3) unstable; urgency=medium

Regards,
Nicholas D Steeves

Bug#870344: [Pkg-mozext-maintainers] Bug#870344: New upstream release supporting Firefox 57+

[Moritz Mühlenhoff]

On Thu, Jan 03, 2019 at 11:06:23PM +0100, Moritz Mühlenhoff wrote:
> On Tue, Aug 01, 2017 at 10:02:39AM -0400, Sean Whitton wrote:
> > Hello Damyan,
> > 
> > On Tue, Aug 01, 2017 at 08:58:38AM +, Damyan Ivanov wrote:
> > > When firefox hits unstable (probably towards the end of this year) this 
> > > bug will become grave.
> > 
> > I think that it will only become grave once firefox-esr reaches a
> > version newer than 57.
> 
> This is still broken in Stretch. Are you planning to also update
> stable or shall I file a removal bug to drop the broken package
> from stable?

I've now filed a removal bug for stretch.

Cheers,
Moritz

Bug#921129: RM: debianbuttons/1.11-3

[Moritz Muehlenhoff]

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

Please remove debianbuttons/1.11-3 from stretch, it's broken with Firefox >= 57.

Cheers,
Moritz

Bug#779077: apache2-bin: crash with segmentation fault if gracefully reloaded twice too quickly

[Ben Hay]

Package: libapache2-mod-fcgid
Version: 1:2.3.9-1+b1
Followup-For: Bug #779077

Dear Maintainer,

In early January I upgraded from Jessie to Stretch.

The server is running Sympa, which uses fcgid in Stretch for the web interface, 
and for Soap services.

Shortly after the upgrade I encountered this bug.  Researching the problem led 
to this report, and I determined that the bug was triggered by logrotate. 
I noted also that Apache only hangs if the fgci script has been accessed since 
last restart - ie if there are fcgi processes in memory when you attempt to 
reload Apache.

As a workaround I modified the logrotate configuration to restart Apache if 
defunct processes are found after the attempted reload.

This worked fine.  Yesterday, however, the bug appeared again and this time 
logrotate was not the culprit. I investigated and determined that certbot 
attempts to reload Apache multiple times when renewing our certificates.

I modified the letsencrypt configuration like this:
[renewalparams]
pre_hook = /usr/sbin/service apache2 restart

By restarting Apache before certbot runs I remove fcgi processes from memory, 
and if there are no fcgi processes Apache reload does not hang the service.

A better workaround might be to change the Apache scripts to automatically 
issue a restart instead of reload if any fcgi processes are in memory.

HTH,

Ben

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

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

Versions of packages libapache2-mod-fcgid depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.25-3+deb9u6
ii  libc6   2.24-11+deb9u3

libapache2-mod-fcgid recommends no packages.

libapache2-mod-fcgid suggests no packages.

-- no debconf information

Bug#921128: mailman3-web fails to initialize mysql: Specified key was too long

[Antoine Beaupre]

Package: mailman3-web
Version: 0+20180916-2~bpo9+1
Severity: grave

I can't seem to install mailman3-web, at least from backports:

Paramétrage de mailman3-web (0+20180916-2~bpo9+1) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf
mailman3web already exists and has privileges on mailman3web.
creating database mailman3web: already exists.
dbconfig-common: flushing administrative password
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 64, 
in execute
return self.cursor.execute(sql, params)
  File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", line 
101, in execute
return self.cursor.execute(query, args)
  File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 226, in execute
self.errorhandler(self, exc, value)
  File "/usr/lib/python3/dist-packages/MySQLdb/connections.py", line 36, in 
defaulterrorhandler
raise errorvalue
  File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 217, in execute
res = self._query(query)
  File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 378, in _query
rowcount = self._do_query(q)
  File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 341, in 
_do_query
db.query(q)
  File "/usr/lib/python3/dist-packages/MySQLdb/connections.py", line 280, in 
query
_mysql.connection.query(self, query)
_mysql_exceptions.OperationalError: (1071, 'Specified key was too long; max key 
length is 767 bytes')

That's after stumbling upon bug #919145, so I just had installed mysqldb and
pymysql. I tried purging (deleting databases and creds) the package and
reinstalling, with a similar result.

That's a rather strange error - a 767 bytes key does seem very long. ;) I
suspect something might be going on in dbconfig-common - the mailman postinst
doesn't seem to have anything specific to this, for example. Note that
dbconfig-common was upgraded to backports as a dependency, so this might be
where the trouble lies as well.

Unfortunately, I have about zero clue how to debug dbconfig, which has always
been a horrible black box to me, so I am sorry I cannot help further. 

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

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

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.11~bpo9+1
ii  debconf [debconf-2.0]  1.5.61
ii  lsb-base   9.20161125
ii  node-less  1.6.3~dfsg-2
ii  python33.5.3-1
ii  python3-django-hyperkitty  1.2.1-4~bpo9+1
ii  python3-django-postorius   1.2.2-4~bpo9+2
ii  python3-psycopg2   2.6.2-1
ii  python3-pymysql0.7.10-1
ii  python3-whoosh 2.7.0-2
ii  ruby-sass  3.5.3-1~bpo9+1
ii  ucf3.0036
ii  uwsgi  2.0.14+20161117-3+deb9u2
ii  uwsgi-plugin-python3   2.0.14+20161117-3+deb9u2

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.0.14+20161117-3+deb9u2
ii  nginx   1.10.3-1+deb9u2
ii  nginx-full [nginx]  1.10.3-1+deb9u2

Versions of packages mailman3-web suggests:
ii  mariadb-server-10.1 [virtual-mysql-server]  10.1.37-0+deb9u1

-- debconf information:
  mailman3-web/db/basepath: /var/lib/mailman3/web
  mailman3-web/django-site: anarc.at
  mailman3-web/dbconfig-reinstall: false
  mailman3-web/nginx-choice:
  mailman3-web/upgrade-error: abort
  mailman3-web/remove-error: abort
  mailman3-web/mysql/method: Unix socket
  mailman3-web/db/app-user: mailman3web@localhost
  mailman3-web/configure-webserver: none
  mailman3-web/dbconfig-upgrade: true
  mailman3-web/dbconfig-remove: true
  mailman3-web/internal/skip-preseed: false
  mailman3-web/passwords-do-not-match:
  mailman3-web/remote/port:
  mailman3-web/pgsql/authmethod-user: password
  mailman3-web/pgsql/manualconf:
  mailman3-web/superuser-name: admin
* mailman3-web/database-type: mysql
  mailman3-web/purge: false
  mailman3-web/missing-db-package-error: abort
  mailman3-web/internal/reconfiguring: false
  mailman3-web/pgsql/method: TCP/IP
  mailman3-web/install-error: abort
  mailman3-web/superuser-mail: root@localhost
  mailman3-web/emailname: localhost.local
  mailman3-web/restart-webserver: true
  mailman3-web/pgsql/changeconf: false
  mailman3-web/db/dbname: mailman3web
  mailman3-web/pgsql/authmethod-admin: ident
  mailman3-web/upgrade-backup: true
* mailman3-web/mysql/admin-user: debian-sys-maint
  mailman3-web/remote/newhost:
  mailman3-web/pgsql/no-empty-passwords:
  mailman3-web/pgsql/admin-user: postgres
* mailman

Bug#921127: RM: mp4v2 -- RoQA; dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

(This removal has been cleared with the maintainer)

Please remove mp4v2, it's dead upstream and better alternatives
exist. The last remaining use case in the archive has been
fixed to no longer use it.

Cheers,
Moritz

Bug#917185: udev: Updating to 240-5 solved all described issues

[Ricardo F. Peliquero]

Package: udev
Followup-For: Bug #917185

Dear Maintainer,

Just to inform that all issues described in this bug report were solved
after updating to 240-5.

Kindest regards,

Ricardo Peliquero

-- Package-specific info:

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

Kernel: Linux 4.19.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages udev depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libblkid12.33.1-0.1
ii  libc62.28-5
ii  libkmod2 25-2
ii  libselinux1  2.8-1+b1
ii  libudev1 240-5
ii  lsb-base 10.2018112800
ii  util-linux   2.33.1-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
pn  systemd  

-- no debconf information
P: /devices/LNXSYSTM:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYSTM:
E: USEC_INITIALIZED=8674303
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXCPU:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:
E: USEC_INITIALIZED=8692812
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXCPU:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:
E: USEC_INITIALIZED=8856088
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXPWRBN:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: SUBSYSTEM=acpi
E: DRIVER=button
E: MODALIAS=acpi:LNXPWRBN:
E: USEC_INITIALIZED=8854149
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input10
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input10
E: SUBSYSTEM=input
E: PRODUCT=19/0/1/0
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PROP=0
E: EV=3
E: KEY=10 0 0 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: USEC_INITIALIZED=10263546
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input10/event6
N: input/event6
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input10/event6
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event6
E: MAJOR=13
E: MINOR=70
E: USEC_INITIALIZED=12608050
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: XKBMODEL=pc105
E: XKBLAYOUT=es
E: XKBOPTIONS=terminate:ctrl_alt_bksp
E: BACKSPACE=guess
E: LIBINPUT_DEVICE_GROUP=19/0/1:LNXPWRBN/button
E: TAGS=:power-switch:

P: /devices/LNXSYSTM:00/LNXSYBUS:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYBUS:
E: USEC_INITIALIZED=8844709
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:PNP0A03:
E: USEC_INITIALIZED=8863348
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/device:02
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/device:02
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:03
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:03
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:04
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:04
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06/device:07
L: 0
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06/device:07
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06/device:08
L: 0
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06/device:08
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09/device:0a
L: 0
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09/device:0a
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A

Bug#804299: smartmontools: update-smart-drivedb currently risky

[Christoph Anton Mitterer]

On Fri, 2019-02-01 at 22:09 +0100, Marc Haber wrote:
> Generally I think it's good that the tool is gone,… updating code
> > should *always* be the task of the respective package management
> > system, cause otherwise it's not just easy that code-downloader-
> 
> I violently disagree. We only release every two years. SSDs develop
> quickly. We should not ship a two year old file.

If it's only that .h file that changes… it shouldn't be very difficult
to keep things up2date, or is it?


> > Having code downloaded/updated by downloader-programs also means
> > that
> > this basically circumvents Debian security support.
> 
> If the downloader script replaces the file from the package, it will
> be
> overridden with the next package upgrade, allowing security support
> to
> continue seamlessly.

Things like debsums will break, and often (though I haven't checked the
one from smartmontools) these downloaders have security flaws… e.g.
allowing for a downgrade attack, by only checking for a valid
signature, not for a validity time.

Also by circumventing package-management, one effectively circumvents
tools like check_apt.


> > or at
> > least (perhaps even non-executable) in the examples dir.
> 
> That's a dirty workaround.

But possibly the safest one for many users?


> In debian stable? That would basically mean to have this package in
> each
> and every point release.

There's e.g. stable-updates which could be perfectly used for this...


> I would like to remind that we used to have daily build of the clamav
> anti-virus database distributed as .deb via debian-volatile, which
> was
> quickly killed off after volatile was taken over by ftpmaster,
> refering
> users to use freshclam, a downloader program, instead. So we have a
> very
> much more prominent case of having a downloader program for volatile
> data here.

I think to remember at least 2-3 CVEs in freshclam…


> In this case, we're not executing the download on our own

Which OTOH makes it also worse, as people not manually executing it
won't get updates.


> If we continue sacrificing functionality for security, we can start
> shipping empty packages. Those are surely the most secure.

Sorry, but this is just polemic.

There is no need to sacrifice functionality for security, just use the
means that are already there, e.g. stable-updates (i.e. the debian-
volatile successor)... I'd be surprised if the ftp-masters refuse to
that if there's good reasoning... and if they do, stable-updates could
probably just tossed.

There is no need to sacrifice security, if things can be done just
right :-)


Cheers,
Chris.

Bug#921126: wine-development: checks for /run/user instead of /run/user/$uid

[Michael Gilbert]

package: src:wine-development
severity: serious
version: 3.12-2

This has been fixed in wine [0].  It also needs to be fixed in wine-development.

Best wishes,
Mike

[0] http://bugs.debian.org/918666

Bug#919145: mailman3: stretch-backports dependencies can not be satisfied with python3-alembic from backports

[Antoine Beaupre]

On Sun, Jan 13, 2019 at 07:32:25AM +, Sampo Sorsa wrote:
> Package: mailman3
> Version: 3.2.0-4~bpo9+1
> 
> Dear Maintainer,
> 
> The mailman3 dependencies can not be satisfied with python3-alembic from 
> stretch-backports:
> 
> Package: mailman3
> Depends: python3-alembic, python3-sqlalchemy (>= 1.2.3)
> 
> Package: python3-alembic
> Version: 1.0.0-2~bpo9+1
> Depends: python3-sqlalchemy (>= 1.0~), python3-sqlalchemy (<< 1.1)
> 
> The python3-sqlalchemy dependency is conflicting. The only way to resolve 
> this is to downgrade python3-alembic to stretch version:
> 
> Package: python3-alembic
> Version: 0.8.8-2
> Depends: python3-sqlalchemy (>= 0.7.6)
> 
> Perhaps this bug should be filed under python3-alembic to request backports 
> upgrade (although buster is 1.0.0-2 too), but I wanted to make both 
> maintainers and users of mailman3 aware of the issue. Please refile if 
> necessary.

Maybe the problem is those backports were not built with backports
available, which hardcoded the version numbers to the ones in stretch.

It was immediately obvious to me so I figured I would also share the
workaround here, which is simply:

apt install python3-alembic python3-sqlalchemy
apt install -t stretch-backports mailman3-full

A.

-- 
Au nom de l'état, la force s'appelle droit.
Au main de l'individu, elle s'appelle crime.
- Max Stirner


signature.asc
Description: PGP signature

Bug#877695: Confirmation of bug #877695

[Paul Whittaker]

Just want to confirm that this is still a problem, and that the second fix
suggested by Michael Stone (specifically, expanding '@(br|eth)' into
'@(br|eth|en)' in /etc/resolvconf/interface-order) would have avoided things
breaking for me recently.

In my case, I was having problems due to conflicts between my own wired
network settings in /etc/network/interfaces and the settings provided by
NetworkManager.  Looking at the contents of interface-order, its intent
certainly appears to be for my wired network to have taken priority, and
that
wasn't what I was seeing.

When calling 'resolvconf -u' from a system script (i.e. with LANG unset in
the environment), 'list-records' would list my wired 'en' interface settings
after the 'NetworkManager' entry.  This caused me problems by putting
NetworkManager's 127.0.1.1 nameserver entry first in resolv.conf.
Unhelpfully, when trying to debug this from a terminal with
LANG=en_GB.UTF-8,
the opposite order was produced, hiding the problem.

Patching interface-order to expand '@(br|eth)' into '@(br|eth|en)' fixes
this
behaviour, and lists my wired interface's settings first regardless of
environment variable settings.

(Michael also proposed a solution which listed the 'eno|ens|enp|enx' cases
separately, but this would not have worked for me.  My USB Ethernet dongles
are all named 'enusb0' by a custom udev rule, to make them easier to manage
than the default long 'enx${MAC_ADDR}' names, and they would not have been
matched by that longer pattern.)

Best regards,

Paul.

Bug#914948: udisks2: udisksctl power-off causes system complete freeze

[Agenor Siqueira]

Dear maintainer,
I have exactly the same problem reported here, with Debian 9.6 in a Dell 
desktop. A part of system was installed on SSD and another in my HDD. About a 
week ago this problem started to happen. Should I switch my repositories to 
unstable?
Thanks
Regards

Bug#917854: RFS: pygithub/1.43.3-1

[Dmitry Shachnev]

Hi Dmitry!

On Thu, Jan 03, 2019 at 04:12:53AM +, Dmitry Bogatov wrote:
> Looks fine, but I do not understand following line in `debian/rules':
>
> rm -rfv debian/python3-github/usr/lib/python3.*
>
> What is removed and why same statement it is not needed for python2
> version?  Comment in `debian/rules' would be nice.

I suggested to add that line. Quoting from my mail in #900368:

"""
- When building in the current sid, I get Lintian warnings about three files
  shipped in /usr/lib/python3.7/dist-packages/.

  That probably happens because of output of 2to3 is slightly different in
  Python 3.6 and 3.7 (e.g. files.items() vs. iter(files.items())), and
  dh_python3 does not remove the file if it does not match.

  I would recommend removing debian/python3-github/usr/lib/python3.* manually
  in debian/rules.
"""

Normally files should be installed in /usr/lib/python3/dist-packages
(not .../python3.x/...). But if there are mulitple supported Python 3 versions
and some installed files differ between these versions, dh_python3 can leave
some files in /usr/lib/python3.x/dist-packages, which causes Lintian warnings
and should be avoided.

Now that Python 3.6 is no longer supported (and there is only one supported
Python 3 version), that hack can be dropped.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#916227: Here's the upstream patch

[Roland Rosenfeld]

tag -1 + patch
thanks

Attached you find the upstream patch prepared for Debian.
It would be great, it this could go into buster...

Greetings
Roland
From: Eli Zaretskii 
Bug: https://debbugs.gnu.org/33493
Bug-Debian: https://bugs.debian.org/916227
Subject: New Version of Hunspell (1.7.0-1) brakes ispell.el
Date: Sun, 25 Nov 2018 18:10:47 +0200

--- a/lisp/textmodes/ispell.el
+++ b/lisp/textmodes/ispell.el
@@ -,7 +,12 @@ dictionary from that list was found."
  null-device
  t
  nil
- "-D")
+ ;; Hunspell 1.7.0 (and later?) won't
+ ;; show LOADED DICTIONARY unless
+ ;; there's at least one file argument
+ ;; on the command line.  So we feed
+ ;; it with the null device.
+ "-D" null-device)
 	(buffer-string))
 	  "[\n\r]+"
 	  t))

Bug#921125: RFS: extsmail/2.2-1 -- enables the robust sending of e-mail to external commands

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "extsmail"

 * Package name: extsmail
   Version : 2.2-1
   Upstream Author : Laurence Tratt 
 * URL : https://tratt.net/laurie/src/extsmail/
 * License : BSD/MIT
   Section : mail

  It builds this binary package:

extsmail   - enables the robust sending of e-mail to external commands

  The package appears to be lintian-clean

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/e/extsmail/extsmail_2.2-1.dsc

  Changes since the last upload:

  * New upstream release 2.2. (Closes: #748739)
  * debian/compat: Upgrade to 11.
  * debian/control: Priority: optional.
  * debian/control: Vcs-Browser: https://github.com/ltratt/extsmail.
  * debian/control: Vcs-Git: https://github.com/oliv3/extsmail-debian.
  * debian/control: Build-Depends: Remove dh-autoreconf.
  * debian/control: Build-Depends: Update debhelper (>= 11).
  * debian/control: Update Homepage.
  * debian/control: Standards-Version: 4.2.1.
  * debian/copyright: Update copyright years.
  * debian/copyright: Update Source URL.
  * debian/copyright: Use secure copyright format URI.
  * debian/rules: Remove --with autoreconf.
  * debian/rules: Add --no-parallel.
  * debian/tests/control: Added.
  * debian/watch: version=4.
  * debian/watch: Use secure URI.

  Regards,

--
Olivier

Bug#921124: elpa-git-commit: magit components can't handle - character

[Robbie Harwood]

Package: elpa-git-commit
Version: 2.90.1-1
Severity: important

Dear Maintainer,

elpa-git-commit and magit's interactive rebase mode don't seem to be
able to handle the - character in pathnames/branches.  I wish I could
provide a more helpful error, but the result is that when I try to
type in the window, it hangs up the emacs process and barfs on the
terminal state machine, leaving garbage.

Thanks,
--Robbie

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

Kernel: Linux 4.19.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_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 elpa-git-commit depends on:
pn  elpa-dash 
pn  elpa-with-editor  
ii  emacsen-common3.0.4

elpa-git-commit recommends no packages.

elpa-git-commit suggests no packages.

Bug#804299: smartmontools: update-smart-drivedb currently risky

[Marc Haber]

On Thu, Jan 10, 2019 at 03:47:24PM +0100, Christoph Anton Mitterer wrote:
> OpenPGP would be in principle ok.
> However, I haven't really checked the implementation of it (i.e. how
> the code downloading, verification is done... on a first glance, I'd
> say it allows at least for replay attacks.
> Plus it automatically imports the shipped public key into the keyring
> of the executing user… which is IMO also unacceptable.

Agreed, the script should use its own keyring.

> Generally I think it's good that the tool is gone,… updating code
> should *always* be the task of the respective package management
> system, cause otherwise it's not just easy that code-downloader-

I violently disagree. We only release every two years. SSDs develop
quickly. We should not ship a two year old file.

> Having code downloaded/updated by downloader-programs also means that
> this basically circumvents Debian security support.

If the downloader script replaces the file from the package, it will be
overridden with the next package upgrade, allowing security support to
continue seamlessly.

> I think it security-wise it would be best not to ship it at all,

IMO unacceptable.

> or at
> least (perhaps even non-executable) in the examples dir.

That's a dirty workaround.

> If there is such a big demand in having that extremely up-to-date by
> many people it would be better if they could perhaps help somehow to
> keep the package better up-to-date. :-)

In debian stable? That would basically mean to have this package in each
and every point release.

I would like to remind that we used to have daily build of the clamav
anti-virus database distributed as .deb via debian-volatile, which was
quickly killed off after volatile was taken over by ftpmaster, refering
users to use freshclam, a downloader program, instead. So we have a very
much more prominent case of having a downloader program for volatile
data here.

In this case, we're not executing the download on our own, so we could
even put the load of verifying the file on to the local user executing
the script.

We could think abuot shipping the PCI/USB ID databases together with the
smartmontools database in a volatile-hwdata package that can be part of
every point release, but that would need a coordinated effort, while I'd
really love to have an acceptable solution for this NOW to provide an
acceptable method of having smartmontools giving reasonable output
even for newer hardware during the buster cycle.

If we continue sacrificing functionality for security, we can start
shipping empty packages. Those are surely the most secure.

Greetings
Marc

Bug#859123: automating process for publishing DLAs on the website

[Holger Levsen]

On Fri, Feb 01, 2019 at 01:58:04PM -0500, Antoine Beaupré wrote:
> I'm looking at the update process for DLAs on the main website again. 

\o/

> In
> #859122, I've mentioned that I have, again, updated the MR to include
> all DLAs up to DLA-1657-1. The www team folks tell me they will review
> that this weekend.

cool. (I'm offline right now but if this MR only has DLAs I'm tempted to
merge when back online...)

> But that mass-import process is kind of clunky: every time I need to
> download the entire archive, extract it, parse every email, and add the
> diff. It's slow and error prone and not automated, of course.
> 
> So I'm bringing back the topic of how we should automate this.

great!

> If I remember correctly, the current proposal is to add this as part of
> the workflow for LTS developers: when you send the announcement on the
> list, you also send a merge request on the website. This would get
> reviewed and merged by another LTS developer with access to the webwml
> repository:
> https://salsa.debian.org/webmaster-team/webwml/project_members

yes, thats the current plan to get this going.

> At least me and Holger have those accesses for now, and I would suggest
> people who do regular frontdesk work could make sure those MR are
> reviewed and merged in a timely manner as well.
> 
> Would that work for everyone here?

definitly for me (and for a start).

> If so, we can *already* start with that process, which would actually
> look like this.
> 
> One time setup:
> 
> git clone https://salsa.debian.org/webmaster-team/webwml
> cd webwml
> salsa fork
> 
> Each time there's a new DLA:
> 
> ./bin/gen-DLA --save $CHANGES # correctly claim the DLA
> $EDITOR DLA--Y # make sure the text is okay, like you normally
># do before the email gets sent
> mutt -H DLA--Y # send the email
> cd ~/src/webwml/english/security
> git checkout -b DLA--Y
> ./parse-dla.pl ~-/DLA--Y
> git add 2019/DLA-XXX-Y*
> $EDITOR 2019/DLA--Y* # make sure everything looks good
> git add 2019/DLA-XXX-Y*
> git commit -m'DLA--Y advisory'
> git push -u origin
> salsa mr

can you please put that on wiki.d.o/LTS/Development?!

> (Note: that "salsa" command is a new one shipped with devscripts. I only
> read the manpage and didn't actually test that. :) Unfortunately, once
> the MR is created, there's no magic command to merge it for
> reviewers... Seems like this needs to be done through the web
> interface.)

hmm (I think there is a way to do this with a cli).

> I'd be happy if someone sat down and actually tested that procedure.
> 
> The alternative, of course, is to setup "something" that would
> automatically parse emails to debian-lts-announce@l.d.o but I suspect
> that could be much more brittle than a manual operation like the above,
> even if it means slightly more work.

yeah. "laters"!

> Thank you for your attention.

very much likewise!


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#921123: RM: altos [ppc64el] -- RoM; arch-specific Java problem

[Bdale Garbee]

Package: ftp.debian.org

Please remove ppc64el packages of altos from the repository.  There
appears to be a non-package-specific Java compiler problem on that
architecture that will prevent promotion of the latest altos version to
testing even once other blockers are cleared.

Bdale


signature.asc
Description: PGP signature

Bug#920971: freecad: C++ exception on DXF import

[Kurt Kremitzki]

Hello Wookey & Bernhard,

Thanks for the bug report & investigation, respectively. I can also
reproduce this bug  in the just-uploaded-to-NEW freecad 0.18~pre1 as
well. It may be a bug in OpenCASCADE, but it may also be a bug in the
way we handle the exception, which we have to do sometimes. I will
create a bug in the FreeCAD tracker and do the necessaries for this bug
w.r.t. that.

Bug#921111: agg: symbols adjustments to support build with -O3

[Steve Langasek]

On Fri, Feb 01, 2019 at 12:13:05PM -0800, John Horigan wrote:
> There are several more template symbols besides those two. Shouldn't they
> all be marked as optional? This is my first time generating a package with
> a symbols file.

It is reasonable to mark any template symbols as optional, my patch is
merely the minimal change necessary to let the package build successfully on
ppc64el in Ubuntu.

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

> On Fri, Feb 1, 2019 at 9:03 AM Steve Langasek 
> wrote:
> 
> > Package: agg
> > Version: 1:2.6.0-r132+dfsg1-2
> > Severity: minor
> > Tags: patch
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu disco ubuntu-patch
> >
> > Hi John,
> >
> > The latest version of agg, 1:2.6.0-r132+dfsg1-2, fails to build from source
> > on ppc64el in Ubuntu due to a difference in the symbols output for the
> > shared library.  This is because Ubuntu defaults to -O3 on ppc64el, which
> > means some additional template symbols are omitted from the output that are
> > otherwise seen when building with -O2.
> >
> > Since these are template symbols and not part of the shared library ABI, a
> > correct fix to make the library compatible with -O3 is to mark these
> > symbols
> > optional as in the attached patch.  Please consider applying in Debian.
> >
> > Thanks,
> > --
> > Steve Langasek   Give me a lever long enough and a Free OS
> > Debian Developer   to set it on, and I can move the world.
> > Ubuntu Developer   https://www.debian.org/
> > slanga...@ubuntu.com vor...@debian.org
> >


signature.asc
Description: PGP signature

Bug#921122: pbbam: failing autopkgtests depend on generated files in source tree

[Steve Langasek]

Package: pbbam
Version: 0.19.0+dfsg-1
Severity: serious
Tags: patch
Justification: autopkgtest failures block migration
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Afif,

Since the upload of 0.18.0+dfsg-1, pbbam's autopkgtests have been
consistently failing because the following code in debian/rules finds no
files in the tree:

  synthetic_movie_all_path=`find $$PWD -name 
synthetic_movie_all.subreadset.xml` ; \

The file synthetic_movie_all.subreadset.xml is generated at build time, but
depended on by the autopkgtests, which are run against an unbuilt source
tree.

The simplest way to fix this is to change the autopkgtest to use the
'build-needed' restriction, which causes the package to be built from source
during the autopkgtest.  There may be more efficient ways to just rebuild
only this data file used by the tests, but I'm not familiar with the meson
build system used by this package so I don't know the right way to do that.

Since regressed autopkgtests are now blockers for testing migration, I've
marked this bug as serious.

Please consider including the attached patch in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru pbbam-0.19.0+dfsg/debian/control pbbam-0.19.0+dfsg/debian/control
--- pbbam-0.19.0+dfsg/debian/control2019-01-31 17:13:14.0 -0800
+++ pbbam-0.19.0+dfsg/debian/control2019-02-01 12:15:46.0 -0800
@@ -1,6 +1,5 @@
 Source: pbbam
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Med Packaging Team 

+Maintainer: Debian Med Packaging Team 

 Uploaders: Afif Elghraoui 
 Section: science
 Priority: optional
diff -Nru pbbam-0.19.0+dfsg/debian/tests/control 
pbbam-0.19.0+dfsg/debian/tests/control
--- pbbam-0.19.0+dfsg/debian/tests/control  2019-01-31 23:33:01.0 
-0800
+++ pbbam-0.19.0+dfsg/debian/tests/control  2019-02-01 12:15:46.0 
-0800
@@ -8,3 +8,4 @@
 Restrictions:
rw-build-tree,
allow-stderr,
+   build-needed,

Bug#921121: 60.5.0esr-1~deb9u1 breaks Netflix playback

[Kathryn Tolsen]

Package: firefox-esr
Version: 60.5.0esr-1~deb9u1

Last night I upgraded and now it shows me a yellow banner saying "Firefox
is installing components needed to play the audio or video on this page.
Please wait." I waited about 20min, reloaded the page, still wouldn't work.
I removed firefox-esr and manually downloaded and installed the last update

http://security-cdn.debian.org/debian-security/pool/updates/main/f/firefox-esr/firefox-esr_60.4.0esr-1~deb9u1_amd64.deb

Netflix is working again.

This is a Stretch amd64 system. I didn't bother debugging any further as I
don't know much about debugging FF. Netflix is HTML5 uses widevine as far
as I know for DRM. I use multiarch for Crossover 17 to support Xfinity's
Streaming TV which still uses Adobe Flash and only works properly with a
windows firefox, and have backports for hedgewars and libphysfs3 it
requires. Other than that my system is pure Debian 9.7 Stretch and up to
date.. so I imagine the issue should be reproducible.

I'm not sure what exactly has broken or why it would even attempt to
download components I obviously already had in FF previous release. If
there is anything else I can do to help run down the issue, let me know.

For now I'll be staying on this 60.4.0esr-1~deb9u1 until the next update
and I'll be keeping this package around in case its still not fixed as this
is all I use FF for.

Bug#921111: agg: symbols adjustments to support build with -O3

[John Horigan]

There are several more template symbols besides those two. Shouldn't they
all be marked as optional? This is my first time generating a package with
a symbols file.

-- john

On Fri, Feb 1, 2019 at 9:03 AM Steve Langasek 
wrote:

> Package: agg
> Version: 1:2.6.0-r132+dfsg1-2
> Severity: minor
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu disco ubuntu-patch
>
> Hi John,
>
> The latest version of agg, 1:2.6.0-r132+dfsg1-2, fails to build from source
> on ppc64el in Ubuntu due to a difference in the symbols output for the
> shared library.  This is because Ubuntu defaults to -O3 on ppc64el, which
> means some additional template symbols are omitted from the output that are
> otherwise seen when building with -O2.
>
> Since these are template symbols and not part of the shared library ABI, a
> correct fix to make the library compatible with -O3 is to mark these
> symbols
> optional as in the attached patch.  Please consider applying in Debian.
>
> Thanks,
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>

Bug#921120: sagemath breaks sagetex autopkgtest: ImportError: No module named _tkinter, please install the python-tk package

[Paul Gevers]

reassign 921120 src:sagetex 3.2+ds-1
retitle 921120 sagetex (autopkgtest) depends misses python-tk
affects 921120 src:sagemath
thanks

Hi Tobias, sagemath maintainers

On 01-02-2019 20:35, Tobias Hansen wrote:
> I guess the solution is to add python-tk to Depends: in the sagetex 
> autopkgtest control file.

I think so too, thus reassigning. Mind you, I haven't checked if sagetex
needs the python-tk regular dependency even.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#919517: firewalld: Failure to start with OpenVPN installed and nftables backend

[Sunil Mohan Adapa]

On Wed, 16 Jan 2019 12:27:15 -0800 Sunil Mohan Adapa 
wrote:
[...]
> 
> This is a simple fix with nft rules insertion. This is already fixed in
> upstream about four weeks ago and that patch is attached. In case, upstream
> does not make a release soon, please consider adding this patch to Debian
> packaging due to severity of the issue.
> 

Hello,

It would be really nice to have this upstream commit cherrypicked before
the buster freeze. Once the bug hits, firewalld is unusable on the
system leading to security concerns.

Thanks for all the work,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#921120: sagemath breaks sagetex autopkgtest: ImportError: No module named _tkinter, please install the python-tk package

[Tobias Hansen]

I guess the solution is to add python-tk to Depends: in the sagetex autopkgtest 
control file.

Best,
Tobias

On 2/1/19 8:27 PM, Tobias Hansen wrote:
> Hi,
>
> the problem is that python-matplotlib needs python-tk (it's the default 
> backend), but only recommends it rather than depending on it. autopkgtests 
> apparently don't install recommends. I already filed this as #921108 but the 
> matplotlib2 maintainer does not want to change it.
>
> sagemath 8.6-3 had a dependency on python-tk but it really has nothing to do 
> with python-tk.
>
> Best,
> Tobias
>
> On 2/1/19 7:48 PM, Paul Gevers wrote:
>> Source: sagemath, sagetex
>> Control: found -1 sagemath/8.6-4
>> Control: found -1 sagetex/3.2+ds-1
>> Control: affects -1 src:texlive-base
>> Severity: important
>> User: debian...@lists.debian.org
>> Usertags: breaks needs-update
>>
>> [X-Debbugs-CC: debian...@lists.debian.org, texlive-b...@packages.debian.org]
>>
>> Dear maintainers,
>>
>> With a recent upload of sagemath the autopkgtest of sagetex fails in
>> testing when that autopkgtest is run with the binary packages of
>> sagemath from unstable. It passes when run with only packages from
>> testing. In tabular form:
>>passfail
>> sagemath   from testing8.6-4
>> sagetexfrom testing3.2+ds-1
>> versioned deps [0] from testingfrom unstable
>> all others from testingfrom testing
>>
>> I copied some of the output at the bottom of this report. It seems to me
>> that sagemath should not have dropped the dependency on python-tk.
>> However, it is possible that the issue is in six, or that sagetext now
>> should add it to the (test) dependencies.
>>
>> Currently this regression is blocking the migration of sagemath (and
>> texlive-base) 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. FYI, also in unstable, the test fails.
>>
>> More information about this bug and the reason for filing it can be found on
>> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>>
>> Paul
>>
>> [0] You can see what packages were added from the second line of the log
>> file quoted below. The migration software adds source package from
>> unstable to the list if they are needed to install packages from
>> sagemath/8.6-4. I.e. due to versioned dependencies or breaks/conflicts.
>> [1] https://qa.debian.org/excuses.php?package=sagemath
>>
>> https://ci.debian.net/data/autopkgtest/testing/amd64/s/sagetex/1821254/log.gz
>> autopkgtest [04:29:31]: test compose-examples: [---
>> rm -f *.aux *.out *.log
>> rm -f *.sagetex.s* *.sobj *-tikz*.table
>> rm -f -r sage-plots-for-*.tex
>> rm -f example_doctest.sage
>> rm -f example.pdf
>> pdflatex -interaction batchmode example.tex
>> This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live
>> 2019/dev/Debian) (preloaded format=pdflatex)
>>  restricted \write18 enabled.
>> entering extended mode
>> sage example.sagetex.sage
>> Setting permissions of DOT_SAGE directory so only you can read and write it.
>> Processing Sage code for example.tex...
>> Inline formula 0 (line 35)
>> Inline formula 1 (line 36)
>> Inline formula 2 (line 38)
>> Inline formula 3 (line 39)
>> Code block (line 42) begin...end
>> Inline formula 4 (line 49)
>> Inline formula 5 (line 51)
>> Inline formula 6 (line 54)
>> Code block (line 58) begin...end
>> Inline formula 7 (line 63)
>> Inline formula 8 (line 64)
>> Code block (line 68) begin...end
>> Inline formula 9 (line 77)
>> Inline formula 10 (line 78)
>> Code block (line 81) begin...end
>> Inline formula 11 (line 85)
>> Code block (line 87) begin...Traceback (most recent call last):
>>   File "example.sagetex.sage.py", line 121, in 
>> _st_.plot(_sage_const_0 , format='notprovided',
>> _p_=E.plot(-_sage_const_3 ,_sage_const_3 ))
>>   File "/usr/lib/python2.7/dist-packages/sagetex.py", line 239, in plot
>> _p_.save(filename=plotfilename, **kwargs)
>>   File "/usr/lib/python2.7/dist-packages/sage/misc/decorators.py", line
>> 411, in wrapper
>> return func(*args, **kwds)
>>   File "/usr/lib/python2.7/dist-packages/sage/plot/graphics.py", line
>> 3167, in save
>> figure = self.matplotlib(**options)
>>   File "/usr/lib/python2.7/dist-packages/sage/plot/graphics.py", line
>> 2543, in matplotlib
>> import matplotlib.pyplot as plt
>>   File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line
>> 115, in 
>> _backend_mod, new_figure_manager, draw_if_interactive, _show =
>> pylab_setup()
>>   File
>> "/usr/lib/python2.7/dist-packages/matplotlib/backends/__init__.py", line
>> 62, in pylab_setup
>> [backend_name], 0)
>>   File
>> "/usr/lib/python2.7/dist-packages/matplotlib/backends/backend_tkagg.py",
>> line 4, in 
>> from . import tkagg  # Paint image to Tk photo blitter extensi

Bug#919594: fixing amd64 first

[Adam Borowski]

Hrm, due to lack of tuits I did not manage to get it work _correctly_ with
system jemalloc yet.  Thus, I'm uploading a fix for the -mssse4.2 issue;
plus a working testsuite.  Porting patches can come later, once the package
is in testing (soft freeze!)


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ Romanes eunt domus!
⠈⠳⣄

Bug#919508: ITP: warewulf -- systems management suite for Linux clusters

[Brian Smith]

Hi Roland,

On Thu, Jan 31, 2019 at 3:10 AM Roland Fehrenbacher  wrote:
>
> > "BS" == Brian Smith  writes:
>
> Hi Brian,
>
> while I appreciate your initiative, I'm a bit skeptical about the
> inclusion of warewulf in Debian for the following reasons:
>
> a) Development in the project has stalled for quite a while. It used to
> be basically a one-man show driven by Gregory M. Kurtzer who now runs a
> startup (https://www.sylabs.io/) pushing the singularity container
> software.
>

Agreed that the github repository is not seeing a lot of new development work.
They are responding to issues and incorporating pull requests. The warewulf
project doesn't look dead.

>
> b) The software is quite complex and involves system components which
> are rather security critical. Given that we cannot count on upstream
> concerning fixing security issues, I consider it a substantial risk that
> we might have a hard time struggling with critical security bugs.
>

The major security problem I found is the use of embedded software tarballs
that would not be receiving any security updates unless addressed specifically
by warewulf developers. The work I have done removes the warewulf dependency
upon the embedded tarballs and uses the binaries delivered by the
standard Debian
packages.

I'm still going through the scripts, so there my be glaring issues
that I'm not aware of.
Searching the web hasn't revealed any major security discussions
regarding warewulf.
If there is a link to such an article or you wish to specify what you
found, please let me
know.

>
> c) Given its complexity, the software is also rather involved
> concerning its packaging process. Hence, I believe it only makes sense to
> include it in Debian if there is a strong commitment from you and at
> least one other DD for the long-term maintenance.
>

I had hoped to share my work with the Debian community. If there is
little support
for including the package, then I agree that the ITP is a wasted effort.

> Because of these points I wouldn't be in favor of including warewulf in
> Debian. I looked at it myself about a possible inclusion in our own
> cluster OS Qlustar for a while, but didn't find it suitable for
> basically the above reasons.
>
> Please note, this is only my personal opinion and if the majority of the
> Debian HPC team thinks otherwise, I have no problem with it. I just
> think it's better to have this discussion now, rather than after you have
> done all the work and it possibly would have been in vain ...
>

Thanks for responding and bringing up your concerns. I'm having to do the
packaging and fixes already for my own project. Getting it fully vetted and
suitable for upload is, obviously, a much bigger effort.

>
> Cheers,
>
> Roland
>
> BS> Package: wnpp Severity: wishlist Owner: "Brian T. Smith"
> BS>  X-Debbugs-CC:
> BS> debian-de...@lists.debian.org, debian-...@lists.debian.org
>
> BS> * Package name : warewulf
> BS>   Version : 3.8.1 Upstream Author : Gregory M. Kurtzer
> BS>   
> BS> * URL : https://warewulf.lbl.gov/
> BS> * License : BSD-3-Clause-like
> BS>   Programming Lang: Perl, Bourne, Bash Description : Systems
> BS>   management suite for Linux clusters
>
> BS> Warewulf is an operating system management toolkit designed to
> BS> facilitate large scale deployments of systems on physical,
> BS> virtual and cloud-based infrastructures. It facilitates elastic
> BS> and large deployments consisting of groups of homogenous
> BS> systems.
>
> BS> Compute nodes are managed via the warewulf suite that is
> BS> installed to a head node. The head node executes services used
> BS> to provision the operating system to compute nodes, which
> BS> execute an iPXE agent.  The essential services are tftpd, dhcpd,
> BS> httpd and nfsd.  Warewulf consists of a set of scripts which
> BS> automate configuration of these services via a command-line
> BS> interface.
>
> BS> The upstream Warewulf source package includes embedded source
> BS> tarballs for parted, ipxe, e2fsprogs, busybox, libarchive and
> BS> unionfs. Thus, the upstream builds include binary code for these
> BS> packages that are already available for Debian. A goal of this
> BS> project is to remove these embedded packages from the build and
> BS> ship packages that target the "all" architecture.
>
> BS> Warewulf's upstream build also includes packaging of a compute
> BS> node initrd image, created from the embedded packages. The
> BS> Debian package will not include an initrd image. Rather, a
> BS> script to create the initrd image via mkinitramfs and custom
> BS> hooks will be used by the administrator to build the compute
> BS> node initrd image after installing warewulf to the head node.
> BS> This technique has the benefit of easing an administrator's task
> BS> of updating the initrd image, when necessary.
>
> BS> Warewulf is used by

Bug#921120: sagemath breaks sagetex autopkgtest: ImportError: No module named _tkinter, please install the python-tk package

[Tobias Hansen]

Hi,

the problem is that python-matplotlib needs python-tk (it's the default 
backend), but only recommends it rather than depending on it. autopkgtests 
apparently don't install recommends. I already filed this as #921108 but the 
matplotlib2 maintainer does not want to change it.

sagemath 8.6-3 had a dependency on python-tk but it really has nothing to do 
with python-tk.

Best,
Tobias

On 2/1/19 7:48 PM, Paul Gevers wrote:
> Source: sagemath, sagetex
> Control: found -1 sagemath/8.6-4
> Control: found -1 sagetex/3.2+ds-1
> Control: affects -1 src:texlive-base
> Severity: important
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
>
> [X-Debbugs-CC: debian...@lists.debian.org, texlive-b...@packages.debian.org]
>
> Dear maintainers,
>
> With a recent upload of sagemath the autopkgtest of sagetex fails in
> testing when that autopkgtest is run with the binary packages of
> sagemath from unstable. It passes when run with only packages from
> testing. In tabular form:
>passfail
> sagemath   from testing8.6-4
> sagetexfrom testing3.2+ds-1
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report. It seems to me
> that sagemath should not have dropped the dependency on python-tk.
> However, it is possible that the issue is in six, or that sagetext now
> should add it to the (test) dependencies.
>
> Currently this regression is blocking the migration of sagemath (and
> texlive-base) 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. FYI, also in unstable, the test fails.
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [0] You can see what packages were added from the second line of the log
> file quoted below. The migration software adds source package from
> unstable to the list if they are needed to install packages from
> sagemath/8.6-4. I.e. due to versioned dependencies or breaks/conflicts.
> [1] https://qa.debian.org/excuses.php?package=sagemath
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/s/sagetex/1821254/log.gz
> autopkgtest [04:29:31]: test compose-examples: [---
> rm -f *.aux *.out *.log
> rm -f *.sagetex.s* *.sobj *-tikz*.table
> rm -f -r sage-plots-for-*.tex
> rm -f example_doctest.sage
> rm -f example.pdf
> pdflatex -interaction batchmode example.tex
> This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live
> 2019/dev/Debian) (preloaded format=pdflatex)
>  restricted \write18 enabled.
> entering extended mode
> sage example.sagetex.sage
> Setting permissions of DOT_SAGE directory so only you can read and write it.
> Processing Sage code for example.tex...
> Inline formula 0 (line 35)
> Inline formula 1 (line 36)
> Inline formula 2 (line 38)
> Inline formula 3 (line 39)
> Code block (line 42) begin...end
> Inline formula 4 (line 49)
> Inline formula 5 (line 51)
> Inline formula 6 (line 54)
> Code block (line 58) begin...end
> Inline formula 7 (line 63)
> Inline formula 8 (line 64)
> Code block (line 68) begin...end
> Inline formula 9 (line 77)
> Inline formula 10 (line 78)
> Code block (line 81) begin...end
> Inline formula 11 (line 85)
> Code block (line 87) begin...Traceback (most recent call last):
>   File "example.sagetex.sage.py", line 121, in 
> _st_.plot(_sage_const_0 , format='notprovided',
> _p_=E.plot(-_sage_const_3 ,_sage_const_3 ))
>   File "/usr/lib/python2.7/dist-packages/sagetex.py", line 239, in plot
> _p_.save(filename=plotfilename, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/sage/misc/decorators.py", line
> 411, in wrapper
> return func(*args, **kwds)
>   File "/usr/lib/python2.7/dist-packages/sage/plot/graphics.py", line
> 3167, in save
> figure = self.matplotlib(**options)
>   File "/usr/lib/python2.7/dist-packages/sage/plot/graphics.py", line
> 2543, in matplotlib
> import matplotlib.pyplot as plt
>   File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line
> 115, in 
> _backend_mod, new_figure_manager, draw_if_interactive, _show =
> pylab_setup()
>   File
> "/usr/lib/python2.7/dist-packages/matplotlib/backends/__init__.py", line
> 62, in pylab_setup
> [backend_name], 0)
>   File
> "/usr/lib/python2.7/dist-packages/matplotlib/backends/backend_tkagg.py",
> line 4, in 
> from . import tkagg  # Paint image to Tk photo blitter extension.
>   File "/usr/lib/python2.7/dist-packages/matplotlib/backends/tkagg.py",
> line 5, in 
> from six.moves import tkinter as Tk
>   File "/usr/lib/python2.7/dist-packages/six.py", line 203, in load_module
> mod = mod._resolve()
>   File "/usr/lib/python2.7/dist-pack

Bug#776424: [kgb-maintainers] Bug#776424: can be crashed by some network traffic

[Joey Hess]

Moritz Mühlenhoff wrote:
> What's the status, did this re-occur with current versions, like
> the one in testing?

I know I saw the problem several times in 2018, on an unstable system,
excact versions unknown.

I've moved the server to a different host and have not seen in the
couple of months since that at least.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#859123: automating process for publishing DLAs on the website

[Antoine Beaupré]

I'm looking at the update process for DLAs on the main website again. In
#859122, I've mentioned that I have, again, updated the MR to include
all DLAs up to DLA-1657-1. The www team folks tell me they will review
that this weekend.

But that mass-import process is kind of clunky: every time I need to
download the entire archive, extract it, parse every email, and add the
diff. It's slow and error prone and not automated, of course.

So I'm bringing back the topic of how we should automate this.

If I remember correctly, the current proposal is to add this as part of
the workflow for LTS developers: when you send the announcement on the
list, you also send a merge request on the website. This would get
reviewed and merged by another LTS developer with access to the webwml
repository:

https://salsa.debian.org/webmaster-team/webwml/project_members

At least me and Holger have those accesses for now, and I would suggest
people who do regular frontdesk work could make sure those MR are
reviewed and merged in a timely manner as well.

Would that work for everyone here?

If so, we can *already* start with that process, which would actually
look like this.

One time setup:

git clone https://salsa.debian.org/webmaster-team/webwml
cd webwml
salsa fork

Each time there's a new DLA:

./bin/gen-DLA --save $CHANGES # correctly claim the DLA
$EDITOR DLA--Y # make sure the text is okay, like you normally
   # do before the email gets sent
mutt -H DLA--Y # send the email
cd ~/src/webwml/english/security
git checkout -b DLA--Y
./parse-dla.pl ~-/DLA--Y
git add 2019/DLA-XXX-Y*
$EDITOR 2019/DLA--Y* # make sure everything looks good
git add 2019/DLA-XXX-Y*
git commit -m'DLA--Y advisory'
git push -u origin
salsa mr

(Note: that "salsa" command is a new one shipped with devscripts. I only
read the manpage and didn't actually test that. :) Unfortunately, once
the MR is created, there's no magic command to merge it for
reviewers... Seems like this needs to be done through the web
interface.)

I'd be happy if someone sat down and actually tested that procedure.

The alternative, of course, is to setup "something" that would
automatically parse emails to debian-lts-announce@l.d.o but I suspect
that could be much more brittle than a manual operation like the above,
even if it means slightly more work.

Thank you for your attention.

A.

-- 
Hard times are coming when we will be wanting the voices of writers
who can see alternatives to how we live now and can see through our
fear-stricken society and its obsessive technologies to other ways of
being, and even imagine some real grounds for hope. We will need
writers who can remember freedom. Poets, visionaries—the realists of a
larger reality. - Ursula Le Guin

Bug#920900: libicu-dev: Command icu-config disappeared from libicu-dev

[Moshe Piekarski]

Package: libicu-dev
Followup-For: Bug #920900

Just pointing out that the changelog for the upgrade specifically mentions this 
change.

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

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

Versions of packages libicu-dev depends on:
ii  icu-devtools  63.1-6
ii  libc6-dev [libc-dev]  2.28-5
ii  libicu63  63.1-6

libicu-dev recommends no packages.

Versions of packages libicu-dev suggests:
ii  icu-doc  63.1-5

-- no debconf information

Bug#921120: sagemath breaks sagetex autopkgtest: ImportError: No module named _tkinter, please install the python-tk package

[Paul Gevers]

Source: sagemath, sagetex
Control: found -1 sagemath/8.6-4
Control: found -1 sagetex/3.2+ds-1
Control: affects -1 src:texlive-base
Severity: important
User: debian...@lists.debian.org
Usertags: breaks needs-update

[X-Debbugs-CC: debian...@lists.debian.org, texlive-b...@packages.debian.org]

Dear maintainers,

With a recent upload of sagemath the autopkgtest of sagetex fails in
testing when that autopkgtest is run with the binary packages of
sagemath from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
sagemath   from testing8.6-4
sagetexfrom testing3.2+ds-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems to me
that sagemath should not have dropped the dependency on python-tk.
However, it is possible that the issue is in six, or that sagetext now
should add it to the (test) dependencies.

Currently this regression is blocking the migration of sagemath (and
texlive-base) 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. FYI, also in unstable, the test fails.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
sagemath/8.6-4. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=sagemath

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sagetex/1821254/log.gz
autopkgtest [04:29:31]: test compose-examples: [---
rm -f *.aux *.out *.log
rm -f *.sagetex.s* *.sobj *-tikz*.table
rm -f -r sage-plots-for-*.tex
rm -f example_doctest.sage
rm -f example.pdf
pdflatex -interaction batchmode example.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live
2019/dev/Debian) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
sage example.sagetex.sage
Setting permissions of DOT_SAGE directory so only you can read and write it.
Processing Sage code for example.tex...
Inline formula 0 (line 35)
Inline formula 1 (line 36)
Inline formula 2 (line 38)
Inline formula 3 (line 39)
Code block (line 42) begin...end
Inline formula 4 (line 49)
Inline formula 5 (line 51)
Inline formula 6 (line 54)
Code block (line 58) begin...end
Inline formula 7 (line 63)
Inline formula 8 (line 64)
Code block (line 68) begin...end
Inline formula 9 (line 77)
Inline formula 10 (line 78)
Code block (line 81) begin...end
Inline formula 11 (line 85)
Code block (line 87) begin...Traceback (most recent call last):
  File "example.sagetex.sage.py", line 121, in 
_st_.plot(_sage_const_0 , format='notprovided',
_p_=E.plot(-_sage_const_3 ,_sage_const_3 ))
  File "/usr/lib/python2.7/dist-packages/sagetex.py", line 239, in plot
_p_.save(filename=plotfilename, **kwargs)
  File "/usr/lib/python2.7/dist-packages/sage/misc/decorators.py", line
411, in wrapper
return func(*args, **kwds)
  File "/usr/lib/python2.7/dist-packages/sage/plot/graphics.py", line
3167, in save
figure = self.matplotlib(**options)
  File "/usr/lib/python2.7/dist-packages/sage/plot/graphics.py", line
2543, in matplotlib
import matplotlib.pyplot as plt
  File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line
115, in 
_backend_mod, new_figure_manager, draw_if_interactive, _show =
pylab_setup()
  File
"/usr/lib/python2.7/dist-packages/matplotlib/backends/__init__.py", line
62, in pylab_setup
[backend_name], 0)
  File
"/usr/lib/python2.7/dist-packages/matplotlib/backends/backend_tkagg.py",
line 4, in 
from . import tkagg  # Paint image to Tk photo blitter extension.
  File "/usr/lib/python2.7/dist-packages/matplotlib/backends/tkagg.py",
line 5, in 
from six.moves import tkinter as Tk
  File "/usr/lib/python2.7/dist-packages/six.py", line 203, in load_module
mod = mod._resolve()
  File "/usr/lib/python2.7/dist-packages/six.py", line 115, in _resolve
return _import_module(self.mod)
  File "/usr/lib/python2.7/dist-packages/six.py", line 82, in _import_module
__import__(name)
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 42, in 
raise ImportError, str(msg) + ', please install the python-tk package'
ImportError: No module named _tkinter, please install the python-tk package
end
Inline formula 12 (line 91)
Initializing plots directory
Plot 0 (line 97)

 Error in Sage code on line 97 of example.tex! Traceback follows.

 Running Sage on example.sage failed! Fix example.tex and try again.
make: *** [Makefile:52: example.pd

Bug#920971: freecad: C++ exception on DXF import

[Bernhard Übelacker]

Dear Maintainer, hello Wookey,
just tried to find out where this exception comes from.

And is looks like it originates in libTKTopAlgo.so.7
(libocct-modeling-algorithms-7.3 / opencascade).

Having no deeper knowledge of either freecad or opencascade,
I can just guess if the next step would be to reassign to
opencascade?

Kind regards,
Bernhard


(gdb) bt
#0  0x73b20add in __cxxabiv1::__cxa_throw 
(obj=obj@entry=0x64b63480, tinfo=0x7fff4dfda6e0 , tinfo@entry=0x7fff4c8a8358 , 
dest=0x7fff4dda2c90 , 
dest@entry=0x7fff4c68ab30 ) at 
../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:78
#1  0x7fff4c6495d8 in BRepLib_Command::Check 
(this=this@entry=0x7fffa3c0) from 
/usr/lib/x86_64-linux-gnu/libTKTopAlgo.so.7
#2  0x7fff4c76f1e8 in BRepLib_MakeShape::Shape 
(this=this@entry=0x7fffa3c0) at ./src/BRepLib/BRepLib_MakeShape.cxx:51
#3  0x7fff4c76263b in BRepLib_MakeEdge::Edge 
(this=this@entry=0x7fffa3c0) at ./src/BRepLib/BRepLib_MakeEdge.cxx:1219
#4  0x7fff4c7b0cf9 in BRepBuilderAPI_MakeEdge::Edge 
(this=this@entry=0x7fffa370) at 
./src/BRepBuilderAPI/BRepBuilderAPI_MakeEdge.cxx:880
#5  0x7fff60f727bf in DraftUtils::DraftDxfRead::OnReadArc 
(this=0x7fffa920, s=, e=, c=0x7fffa570, 
dir=) at ./src/Mod/Draft/App/DraftDxf.cpp:107
#6  0x7fff60f64891 in CDxfRead::OnReadArc (this=this@entry=0x7fffa920, 
start_angle=, end_angle=0, radius=0, c=c@entry=0x7fffa630, 
z_extrusion_dir=1, hidden=hidden@entry=false) at 
./src/Mod/Draft/App/dxf.cpp:1289
#7  0x7fff60f67fc2 in CDxfRead::ReadArc (this=0x7fffa920) at 
./src/Mod/Draft/App/dxf.cpp:429
#8  0x7fff60f6fcc9 in CDxfRead::DoRead (this=0x7fffa920, 
ignore_errors=) at ./src/Mod/Draft/App/dxf.cpp:1733
#9  0x7fff60f60cdf in DraftUtils::Module::readDXF (this=, 
args=...) at ./src/Mod/Draft/App/AppDraftUtilsPy.cpp:83
#10 0x7fff60f5fb0a in 
Py::ExtensionModule::invoke_method_varargs 
(this=this@entry=0x58899370, method_def=, args=...) at 
./src/CXX/Python2/ExtensionModule.hxx:175
#11 0x76b2bec6 in Py::method_varargs_call_handler 
(_self_and_name_tuple=, _args=) at 
./src/CXX/Python2/Objects.hxx:1170
#12 0x7683c43b in PyEval_EvalFrameEx () from 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#13 0x7683bd00 in PyEval_EvalFrameEx () from 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#14 0x76834122 in PyEval_EvalCodeEx () from 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#15 0x76834739 in PyEval_EvalCode () from 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#16 0x7680cf56 in PyRun_StringFlags () from 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#17 0x76b575f6 in Base::InterpreterSingleton::runString[abi:cxx11](char 
const*) (this=, sCmd=0x5818c178 
"importDXF.insert(u\"/home/benutzer/houseplan.dxf\",\"Unbenannt\")") at 
./src/Base/Interpreter.cpp:232
#18 0x772be1b3 in Gui::Command::doCommand 
(eType=eType@entry=Gui::Command::App, sCmd=sCmd@entry=0x775ca612 
"%s.insert(u\"%s\",\"%s\")") at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qarraydata.h:206
#19 0x7724daed in Gui::Application::importFrom 
(this=this@entry=0x7fffdaa0, FileName=, 
DocName=DocName@entry=0x55badf60 "Unbenannt", 
Module=Module@entry=0x580a96f8 "importDXF") at ./src/Gui/Application.cpp:561
#20 0x772c8d02 in StdCmdImport::activated (this=0x557ccad0, 
iMsg=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qarraydata.h:206
#21 0x772c2524 in Gui::Command::invoke (this=0x557ccad0, i=0) at 
./src/Gui/Command.cpp:300
#22 0x742526cb in QMetaObject::activate (sender=0x56ba7260, 
signalOffset=, local_signal_index=, 
argv=) at kernel/qobject.cpp:3771
#23 0x74b9aee2 in QAction::triggered (this=this@entry=0x56ba7260, 
_t1=) at .moc/moc_qaction.cpp:376
#24 0x74b9d4f0 in QAction::activate (this=0x56ba7260, 
event=) at kernel/qaction.cpp:1166
#25 0x74d0de1c in QMenuPrivate::activateCausedStack 
(this=this@entry=0x5627cc70, causedStack=..., 
action=action@entry=0x56ba7260, action_e=action_e@entry=QAction::Trigger, 
self=self@entry=true) at widgets/qmenu.cpp:1371
#26 0x74d153f0 in QMenuPrivate::activateAction 
(this=this@entry=0x5627cc70, action=action@entry=0x56ba7260, 
action_e=action_e@entry=QAction::Trigger, self=self@entry=true) at 
widgets/qmenu.cpp:1448
#27 0x74d1641b in QMenu::mouseReleaseEvent (this=, 
e=0x7fffd000) at widgets/qmenu.cpp:2942
#28 0x74bdf7c8 in QWidget::event (this=this@entry=0x5595a4a0, 
event=event@entry=0x7fffd000) at kernel/qwidget.cpp:8925
#29 0x74d18aab in QMenu::event (this=0x5595a4a0, e=0x7fffd000) 
at widgets/qmenu.cpp:3064
#30 0x74ba1491 in QApplicationPrivate::notify_helper 
(this=this@entry=0x555d4f50, receiver=receiver@entry=0x5595a4a0, 
e=e@entry=0x7fffd000) at kernel/qapplication.cpp:3726
#31 0x74ba8d18 in QApplication::notify (this=, 
receiver=0x559

Bug#859122: about 500 DLAs missing from the website

[Antoine Beaupré]

On 2018-12-19 18:05:36, Antoine Beaupré wrote:
> The DLAs are visible here:
>
> https://www-staging.debian.org/security/2018/dla-1580
>
> One thing that's unclear is how the entries get added to the main list
> in:
>
> https://www-staging.debian.org/security/2018/
>
> That still needs to be cleared up.

That's actually in the webwml code, I opened a MR to add those:

https://salsa.debian.org/webmaster-team/webwml/merge_requests/50

> In the meantime, I did do a mass
> import here:
>
> https://salsa.debian.org/webmaster-team/webwml/merge_requests/47

... and I just updated that with the latest, up until DLA-1657-1.

A.

-- 
It will be a great day when our schools get all the money they need
and the air force has to hold a bake sale to buy a bomber.
- Unknown

Bug#659321: Fix for Gnome 3

[Bruno Kleinert]

Am Samstag, den 26.01.2019, 15:23 +0100 schrieb Bruno Kleinert:
> Hi David,
> 
> please consider addressing this RC bug.
> 
> Just to raise awareness: I plan to NMU with my previously attached
> patch around week 7.
> 
> Cheers - Bruno

Hi,

I uploaded to the DELAYED=10 queue.

Cheers - Bruno


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

Bug#918881: broken distutils on python3.6.8-1

[Tomas Pazderka]

Package: python3.6
Version: 3.6.8-1
Followup-For: Bug #918881

Dear Maintainer,

distutils are not installed at all under python3.6.

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

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

Versions of packages python3.6 depends on:
ii  libpython3.6-stdlib  3.6.8-1
ii  mime-support 3.61
ii  python3.6-minimal3.6.8-1

python3.6 recommends no packages.

Versions of packages python3.6 suggests:
ii  binutils2.31.1-11
pn  python3.6-doc   
pn  python3.6-venv  

-- no debconf information

Bug#921119: libdfp: missing build-dependency on python3

[Steve Langasek]

Package: libdfp
Version: 1.0.13-2
Severity: serious
Tags: patch
Justification: FTBFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hi Frédéric,

In libdfp 1.0.13-2 you've ported the package to use python3 by default
instead of python (thanks!), but you do not have a build-dependency on
python3.  Therefore the package fails to build:

[...]
   dh_auto_test -a
make -j8 check VERBOSE=1
make[1]: Entering directory '/<>'
[...]
/usr/bin/env: 'python3': No such file or directory
make[1]: *** [Makefile:388: libdfp-test-ulps.h] Error 127
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/<>'
dh_auto_test: make -j8 check VERBOSE=1 returned exit code 2
make: *** [debian/rules:15: build-arch] Error 2
[...]

  
(https://buildd.debian.org/status/fetch.php?pkg=libdfp&arch=ppc64el&ver=1.0.13-2&stamp=1548954631&raw=0)

This is fixable by adding python3 to the Build-Depends, since python3 is not
guaranteed to be installed in the build environment by default.  See
attached patch.

Even after fixing this bug however, the package still fails to build in
Ubuntu with the following error:

[...]
LC_ALL=C gawk -f scripts/localplt.awk libdfp.so.jmprel | \
  LC_ALL=C gawk -f scripts/check-localplt.awk ./sysdeps/generic/localplt.data - 
\
  > check-localplt.out
make[1]: *** [Makefile:445: check-localplt.out] Error 1
make[1]: *** Waiting for unfinished jobs
[...]

  (https://launchpad.net/ubuntu/+source/libdfp/1.0.13-2ubuntu1)

I haven't investigated any further.

Hope that helps,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libdfp-1.0.13/debian/control libdfp-1.0.13/debian/control
--- libdfp-1.0.13/debian/control2019-01-31 07:40:39.0 -0800
+++ libdfp-1.0.13/debian/control2019-02-01 10:32:24.0 -0800
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Frédéric Bonnard 
 Uploaders: Matthias Klose , Dimitri John Ledkov 

-Build-Depends: debhelper (>= 11~), gawk
+Build-Depends: debhelper (>= 11~), gawk, python3
 Standards-Version: 4.3.0
 Homepage: https://github.com/libdfp/libdfp
 Vcs-Git: https://salsa.debian.org/debian/libdfp.git

Bug#921118: RFP: qml-box2d -- The goal of the qml-box2d plugin is to expose the functionality of Box2D (C++) as a QML plugin in order to make it easier to write physics based software in QML.

[Matthew Crews]

Package: wnpp
Severity: wishlist

* Package name: qml-box2d
  Version : 2.0.0
  Upstream Author : Thorbjørn Lindeijer 
* URL : https://github.com/qml-box2d/qml-box2dh
* License : Zlib
  Programming Lang: QML
  Description : The goal of the qml-box2d plugin is to expose the
functionality of Box2D (C++) as a QML plugin in order to make it easier to
write physics based software in QML.





This package is a missing optional dependency for Gcompris, Bug #920752.
Currently Gcompris is built without this library, and is missing a few
activities. Adding this package to Debian and rebuilding Gcompris with the
proper build option will allow us to close Bug #920752.

Bug#921117: stretch-pu: package debian-security-support/2019.02.01~deb9u1

[Antoine Beaupre]

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

Hi,

I'd like to update debian-security-support in Stretch to synchronize
with the other suites. I expect this should go in via a normal point
update, as per previous request in #915715.

This has already been uploaded to stretch and released as part of
DLA-1657-1:

https://lists.debian.org/debian-lts-announce/2019/02/msg2.html

The diff is as follows. It is similar to the unstable package, except
for debhelper-compat, which would require backports, and standards
bump, which seem superfluous.

diff -Nru debian-security-support-2018.11.25~deb9u1/debian/changelog 
debian-security-support-2019.02.01~deb9u1/debian/changelog
--- debian-security-support-2018.11.25~deb9u1/debian/changelog  2018-12-06 
06:18:57.0 -0500
+++ debian-security-support-2019.02.01~deb9u1/debian/changelog  2019-02-01 
13:17:26.0 -0500
@@ -1,9 +1,29 @@
-debian-security-support (2018.11.25~deb9u1) stretch; urgency=medium
+debian-security-support (2019.02.01~deb9u1) stretch; urgency=medium
 
   * Team upload.
-  * Rebuild for stretch.
+  * Rebuild for stretch, without d/control changes.
 
- -- Holger Levsen   Thu, 06 Dec 2018 12:18:57 +0100
+ -- Antoine Beaupré   Fri, 01 Feb 2019 13:17:26 -0500
+
+debian-security-support (2019.02.01) unstable; urgency=medium
+
+  * Team upload.
+  * mark enigmail as unsupported in jessie
+
+ -- Antoine Beaupré   Fri, 01 Feb 2019 11:13:03 -0500
+
+debian-security-support (2019.01.19) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Holger Levsen ]
+  * d/control:
+- bump standards version to 4.3.0.
+- bump debhelper compat to 11, use the new debhelper-compat(=11) notation
+  and drop d/compat.
+- add "Rules-Requires-Root: no" to support building as non-root.
+
+ -- Holger Levsen   Fri, 18 Jan 2019 15:49:47 +0100
 
 debian-security-support (2018.11.25) unstable; urgency=medium
 
diff -Nru debian-security-support-2018.11.25~deb9u1/security-support-ended.deb8 
debian-security-support-2019.02.01~deb9u1/security-support-ended.deb8
--- debian-security-support-2018.11.25~deb9u1/security-support-ended.deb8   
2018-12-06 06:14:30.0 -0500
+++ debian-security-support-2019.02.01~deb9u1/security-support-ended.deb8   
2019-02-01 13:17:26.0 -0500
@@ -24,3 +24,4 @@
 vlc  2.2.7-1~deb8u1  2018-05-17  
https://lists.debian.org/debian-security-announce/2018/msg00130.html
 jruby1.5.6-9 2018-06-08  
https://lists.debian.org/debian-security-announce/2018/msg00148.html
 jasperreports4.1.3+dfsg-32018-06-20  Specific details 
about security vulnerabilites are not published
+enigmail 2:1.9.9-1~deb8u12019-02-01  
https://lists.debian.org/debian-lts/2019/01/msg00081.html

Bug#921116: eris: mark additional template symbols optional for compatibility with gcc-8 -O3

[Steve Langasek]

Package: eris
Version: 1.3.23-7
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Olek,

eris is again failing to build from source on ppc64el in Ubuntu, as the only
architecture where packages are built with -O3 by default, because some
additional template symbols are now being optimized out with gcc-8 compared
to previous toolchains.

Please find attached a patch that marks these further template symbols
optional, allowing the package to build from source with or without -O3.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru eris-1.3.23/debian/control eris-1.3.23/debian/control
--- eris-1.3.23/debian/control  2019-02-01 09:05:24.0 -0800
+++ eris-1.3.23/debian/control  2019-02-01 10:03:38.0 -0800
@@ -1,8 +1,7 @@
 Source: eris
 Section: libs
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Games Team 

+Maintainer: Debian Games Team 
 Uploaders: Olek Wojnar 
 Build-Depends: debhelper (>= 11),
libatlas-cpp-0.6-dev (>= 0.6.3),
diff -Nru eris-1.3.23/debian/liberis-1.3-21.symbols 
eris-1.3.23/debian/liberis-1.3-21.symbols
--- eris-1.3.23/debian/liberis-1.3-21.symbols   2018-10-03 12:19:59.0 
-0700
+++ eris-1.3.23/debian/liberis-1.3-21.symbols   2019-02-01 10:02:52.0 
-0800
@@ -231,9 +231,9 @@
  
_ZN4Eris20TerrainModTranslator10parseStuffIN6WFMath7PolygonEEEbRKNS2_5PointILi3EEERKNS2_10QuaternionERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementESt4lessISH_ESaISt4pairIKSH_SK_EEERSO_RT_ILi2EERKSK_@Base
 1.3.23
  _ZN4Eris20TerrainModTranslator11getModifierEv@Base 1.3.19
  
_ZN4Eris20TerrainModTranslator13parsePositionERKN6WFMath5PointILi3EEERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementESt4lessISC_ESaISt4pairIKSC_SF_EEE@Base
 1.3.23
- 
_ZN4Eris20TerrainModTranslator14createInstanceIN8Mercator15SlopeTerrainModEN6WFMath4BallEEEbRT0_ILi2EERKNS4_5PointILi3EEERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementESt4lessISJ_ESaISt4pairIKSJ_SM_EEEff@Base
 1.3.23
- 
_ZN4Eris20TerrainModTranslator14createInstanceIN8Mercator15SlopeTerrainModEN6WFMath6RotBoxEEEbRT0_ILi2EERKNS4_5PointILi3EEERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementESt4lessISJ_ESaISt4pairIKSJ_SM_EEEff@Base
 1.3.23
- 
_ZN4Eris20TerrainModTranslator14createInstanceIN8Mercator15SlopeTerrainModEN6WFMath7PolygonEEEbRT0_ILi2EERKNS4_5PointILi3EEERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementESt4lessISJ_ESaISt4pairIKSJ_SM_EEEff@Base
 1.3.23
+ 
(optional)_ZN4Eris20TerrainModTranslator14createInstanceIN8Mercator15SlopeTerrainModEN6WFMath4BallEEEbRT0_ILi2EERKNS4_5PointILi3EEERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementESt4lessISJ_ESaISt4pairIKSJ_SM_EEEff@Base
 1.3.23
+ 
(optional)_ZN4Eris20TerrainModTranslator14createInstanceIN8Mercator15SlopeTerrainModEN6WFMath6RotBoxEEEbRT0_ILi2EERKNS4_5PointILi3EEERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementESt4lessISJ_ESaISt4pairIKSJ_SM_EEEff@Base
 1.3.23
+ 
(optional)_ZN4Eris20TerrainModTranslator14createInstanceIN8Mercator15SlopeTerrainModEN6WFMath7PolygonEEEbRT0_ILi2EERKNS4_5PointILi3EEERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementESt4lessISJ_ESaISt4pairIKSJ_SM_EEEff@Base
 1.3.23
  
_ZN4Eris20TerrainModTranslator9parseDataERKN6WFMath5PointILi3EEERKNS1_10QuaternionERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementESt4lessISF_ESaISt4pairIKSF_SI_EEE@Base
 1.3.23
  _ZN4Eris20TerrainModTranslatorC1Ev@Base 1.3.19
  _ZN4Eris20TerrainModTranslatorC2Ev@Base 1.3.19
@@ -735,7 +735,7 @@
  
_ZNSt4pairIKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementEED1Ev@Base
 1.3.23
  
_ZNSt4pairIKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5Atlas7Message7ElementEED2Ev@Base
 1.3.23
  
_ZNSt5dequeIN5Atlas7Objects8SmartPtrINS1_9Operation17RootOperationDataEEESaIS5_EE16_M_push_back_auxIJRKS5_EEEvDpOT_@Base
 1.3.23
- 
_ZNSt5dequeIN5Atlas7Objects8SmartPtrINS1_9Operation17RootOperationDataEEESaIS5_EE19_M_destroy_data_auxESt15_Deque_iteratorIS5_RS5_PS5_ESB_@Base
 1.3.19
+ 
(optional)_ZNSt5dequeIN5Atlas7Objects8SmartPtrINS1_9Operation17RootOperationDataEEESaIS5_EE19_M_destroy_data_auxESt15_Deque_iteratorIS5_RS5_PS5_ESB_@Base
 1.3.19
  
_ZNSt5dequeIN5Atlas7Objects8SmartPtrINS1_9Operation17RootOperationDataEEESaIS5_EED1Ev@Base
 1.3.19
  
_ZNSt5dequeIN5Atlas7Objects8SmartPtrINS1_9Operation17RootOperationDataEEESaIS5_EED2Ev@Base
 1.3.19
  
(optional=inline)_ZNSt5dequeINSt7__cxx1112basic_s

Bug#921115: the apt-file README.md.gz links to wordpress blog posts which are not publicly viewable

[Julian Andres Klode]

On Fri, Feb 01, 2019 at 05:58:30PM +, shirish शिरीष wrote:
> Package: apt-file
> Version: 3.2.1
> Severity: normal
> 
> Dear Maintainer,
> Thank you for maintaining apt-file. While the documentation is good,
> some of the documentation
> either needs to be fixed or removed.
> 
> For e.g. in
> 
> /usr/share/doc/apt-file$ zless README.md.gz
> 
> I get the following at the very end -
> 
> [much-faster-incremental-apt-updates]:
> https://juliank.wordpress.com/2015/12/26/much-faster-incremental-apt-updates/
> [apt-1-1-8-to-1-1-10-going-faster]:
> https://juliank.wordpress.com/2015/12/30/apt-1-1-8-to-1-1-10-going-faster/
> 
> 
> Both of these pages on the Julian Andreas Klose are marked as
> protected pages so aren't viewable as public pages unfortunately.
> Either they should be publicly viewable or if that's not possible then
> perhaps remove them from the documentation or some third way found
> out.

Whoa, a lot of typos in my name :)

That's just a matter of s#juliank.wordpress.com#blog.jak-linux.org#
- unfortunately wordpress does not allow you to setup redirects, otherwise
they'd be there (unless you pay a _lot_ of money for their premium offerings,
then you can).


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

Bug#921115: the apt-file README.md.gz links to wordpress blog posts which are not publicly viewable

[shirish शिरीष]

Package: apt-file
Version: 3.2.1
Severity: normal

Dear Maintainer,
Thank you for maintaining apt-file. While the documentation is good,
some of the documentation
either needs to be fixed or removed.

For e.g. in

/usr/share/doc/apt-file$ zless README.md.gz

I get the following at the very end -

[much-faster-incremental-apt-updates]:
https://juliank.wordpress.com/2015/12/26/much-faster-incremental-apt-updates/
[apt-1-1-8-to-1-1-10-going-faster]:
https://juliank.wordpress.com/2015/12/30/apt-1-1-8-to-1-1-10-going-faster/


Both of these pages on the Julian Andreas Klose are marked as
protected pages so aren't viewable as public pages unfortunately.
Either they should be publicly viewable or if that's not possible then
perhaps remove them from the documentation or some third way found
out.

-- 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 apt-file depends on:
ii  apt  1.8.0~beta1
ii  libapt-pkg-perl  0.1.34+b1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libregexp-assemble-perl  0.36-1
ii  perl 5.28.1-3

apt-file recommends no packages.

apt-file 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#921097: Switch to libagg2-dev

[Anton Gladky]

Hi Moritz,

thanks for the bug report. I will change it ASAP. But the libsvgpp-dev
is the header only library, so it is not so important there, because
agg is used for building the examples only.

Best regards

Anton

Am Fr., 1. Feb. 2019 um 15:48 Uhr schrieb Moritz Muehlenhoff :
>
> Source: svgpp
> Severity: important
>
> Starting with 1:2.6.0-r132+dfsg1-1 agg now builds a shared
> library:
>
> | * Add two more binary packages: libagg2-dev with development
> |   files, including shared libraries; and libagg2 with just
> |   the so files. (Closes: #377270)
>
> Could you change svgpp to use the shared library? Otherwise we
> always need to rebuild svgpp in buster-security if there's
> a vulnerability in AGG.
>
> Cheers,
> Moritz

Bug#920618: initscripts: errors with /dev/shm on Hurd

[Samuel Thibault]

Dmitry Bogatov, le mer. 30 janv. 2019 20:48:56 +, a ecrit:
> [2019-01-28 13:40] Samuel Thibault 
> > > Do you mean, that you plan to resolve current bug via changes in
> > > src:hurd?
> >
> > That's be the idea yes.
> >
> > > > The same patch creates /run/lock and /run/utmp, I guess initscripts
> > > > handles that too?
> > > 
> > > Yes, initscripts handle them too. See /etc/init.d/bootmisc.sh
> >
> > Ok, can somebody check that things work fine when dropping that part
> > too?
> 
> I wouldn't be me, sorry.

I wasn't thinking about you :)

I was thinking about people on debian-hurd@, who have a running hurd
box, and can try to modify these scripts and see if that works fine.

People should really not hope that I'll magically have the time to do
everything, that will just not work.

Samuel

Bug#921113: libgtk-3-0: The GTK print dialog does not show all IPP printers (sometimes)

[Brian Potkin]

forwarded 921113 https://gitlab.gnome.org/GNOME/gtk/issues/1639
thanks

Bug#920247: Opening an .xls file with (a) frozen column(s) in it results in soffice.bin using 100% CPU and steadily devouring RAM.

[Bernhard Übelacker]

Control: fixed 920247 libreoffice/1:6.1.5~rc1-2


Hello Gennadiy,

> In 1:6.1.5~rc1-2 such files open just fine, thank you!

I am glad to hear that, your description sounded similar to
another bug #919297 that was also resolved by the new version.
But the thanks should go to the maintainer or to upstream :-)

I guess this bug could then be closed?

Kind regards,
Bernhard

Bug#921114: no display on GL applications

[Jean-Dominique Frattini]

Package: firmware-amd-graphics
Version: 20190114-1
Severity: critical
Debian: Stretch amd64
Regression: Yes
Graphic card: AMD Radeon Rx 580


Good Evening,

since the latest update of xserver-xorg-video-amdgpu and 
firmware-amd-graphics, most GL applications do not display anything and 
display this error message in the console:


amdgpu: The CS has been cancelled because the context is lost.

This makes Debian unusable for developing and running GL programs.
Note that downgrading to firmware-amd-graphics_20180825-1_all.deb seems 
to fix the issue.

Bug#361954: [Pkg-ossec-devel] [Bug #361954] Any news?

[Bill Blough]

The others that were working on it stopped (I never asked why).  I'm
still interested in getting OSSEC-HIDS into Debian, but have limited
time right now, so unfortunately can't commit to it at this time.


On Thu, Jan 31, 2019 at 03:03:42PM +0100, Oliver Schraml wrote:
> Hi there,
> 
> quite a while since something happened on the ossec package request, is
> there still progress or are there still issues to deal with to get int
> ready?
> 
> 
> Many thanks and br
> 
> -- 
> 
> COBOL unser,
> das Du bist im Speicher,
> codiert werde Dein Filter,
> Dein Programm komme,
> Dein Statement geschehe,
> wie auf Band,
> so auch auf Platte;
> unsser täglich Putout gib uns heute,
> und vergib uns unsere Errors,
> wie wir vergeben unseren Technikern,
> und erlöse uns vom Assembler,
> denn Dein ist das Band,
> die Platte und die Zentraleinheit,
> in Ewigkeit,
> 
> -- 
> To unsubscribe, send mail to 361954-unsubscr...@bugs.debian.org.

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#921113: libgtk-3-0: The GTK print dialog does not show all IPP printers (sometimes)

[Brian Potkin]

Package: libgtk-3-0
Version: 3.22.11-1
Severity: normal
Tags: upstream



In what follows, any testing was done with the cups service stopped on
the client.

A TXT record displayed with avahi-browse shows the resource path (rp=).
This has never been standardised and different vendors implement it in
different ways. For example:

HP Deskjet 3070 B611 seriesrp=printers/HP_Deskjet_3070_B611_series
Samsung ML-2950 Series rp=ipp/printer
Brother DCP-9022CDWrp=ipp/print
HP LaserJet Professional M1217nfw MFP  rp=printers/Laserjet

With these four machines on the network, the print dialog should display
them as HP_Deskjet_3070_B611_series, printer, print and Laserjet
respectively. All four would be available to print to (if it were not
for #916267).

Some more examples:

Canon MF731C/733Crp=ipp/print
HP OfficeJet Pro 8710rp=ipp/print
Canon MX920 series   rp=ipp/print

Suppose these three are on the network. It is not possible to have three
printer destinations with the same name (print), so only one printer is
displayed.

This was tested with an ENVY4500 and two instances of ippserver on two
other machines.

ippserver -v -p 631 -l  4500
ippserver -v -p 631 -l  4500

Regards,

Brian.

Bug#893163: caja-dropbox: drop down menu does not appears when clicking on icon (left or right click) in version 1.20

[Mike Gabriel]

Hi Vlad

On Friday, 1 February 2019, Vlad Orlov wrote:
> Hi,
> 
> So, everyone seems to have this issue exactly with version 1.20.0-2. It's the 
> version
> where 2003_fake_xdg_current_desktop.patch had been added [1]. I've done some 
> testing 
> and I can say this patch does the wrong thing. See my comment with screenshot 
> at [2]
> for more info.
> 
> Therefore I suggest removing that patch.
> 
> Side note: in [2] I've mentioned only testing in Ubuntu-based system, but 
> I've got
> the same result in current Debian Testing.
> 
> 
> [1] 
> https://salsa.debian.org/debian-mate-team/caja-dropbox/commit/d21f44fbcf1b6e41123dc3b216a0e37cafec63d5
> [2] 
> https://github.com/mate-desktop/caja-dropbox/issues/27#issuecomment-45172782

Only remove that patch? Or add some other code?

Mike

-- 
Sent from my Sailfish device

Bug#921112: Convert Lintian's internal warnings into W: tags

[Felix Lechner]

Package: lintian

Some tests check directory transversal issues. Those arise when
control fields contain relative paths. The tests look for Lintian
warnings. They look like this:

warning: tainted [...] package '...', skipping

The warnings are emitted by lib/Lintian/ProcessablePool.pm. While they
are not printed by any Lintian 'check', they should at least look like
'W:' tags. That way they can be processed further by programs scanning
Lintian's output.

The affected tests are:

t/tags/debs/control-field-traversal-4
t/tags/source/control-field-traversal-1
t/tags/source/control-field-traversal-3

Bug#862771: sciplot FTBFS on ppc64{,el}: ld: unrecognised emulation mode: minimal-toc

[Thierry fa...@linux.ibm.com]

On Tue, 16 May 2017 22:37:53 +0300 Adrian Bunk  wrote:
> Source: sciplot
> Version: 1.36-16
> Severity: important
> 
> https://buildd.debian.org/status/package.php?p=sciplot&suite=sid
> 
> ...
> ld -shared  -o libsciplot.so.1.36 SciPlot.o SciPlotUtil.o   -mminimal-toc 
>   -lXm -lXmu -lXt -lSM -lICE -lXext -lX11 -lXt -lSM -lICE -lXext -lX11   -lm  
> -lm  -soname libsciplot.so.1 -lc
> ld: unrecognised emulation mode: minimal-toc
> Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim 
> elf64ppc elf32ppc elf32ppclinux elf32ppcsim
> Makefile:1105: recipe for target 'shared' failed
> make[2]: *** [shared] Error 1
> 
> 
what about adding in Imakefile:
#ifdef Ppc64Architecture
#define DefaultNotLDOptions -mminimal-toc
NOTLDOPTIONS = DefaultNotLDOptions
LDOPTIONS := $(filter-out $(NOTLDOPTIONS),$(LDOPTIONS))
#endif

Bug#921111: agg: symbols adjustments to support build with -O3

[Steve Langasek]

Package: agg
Version: 1:2.6.0-r132+dfsg1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hi John,

The latest version of agg, 1:2.6.0-r132+dfsg1-2, fails to build from source
on ppc64el in Ubuntu due to a difference in the symbols output for the
shared library.  This is because Ubuntu defaults to -O3 on ppc64el, which
means some additional template symbols are omitted from the output that are
otherwise seen when building with -O2.

Since these are template symbols and not part of the shared library ABI, a
correct fix to make the library compatible with -O3 is to mark these symbols
optional as in the attached patch.  Please consider applying in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru agg-2.6.0-r132+dfsg1/debian/libagg2.symbols 
agg-2.6.0-r132+dfsg1/debian/libagg2.symbols
--- agg-2.6.0-r132+dfsg1/debian/libagg2.symbols 2019-01-29 17:36:52.0 
-0800
+++ agg-2.6.0-r132+dfsg1/debian/libagg2.symbols 2019-02-01 08:55:30.0 
-0800
@@ -128,7 +128,7 @@
  _ZN3agg14verdana16_boldE@Base 2.6.0
  _ZN3agg14verdana17_boldE@Base 2.6.0
  _ZN3agg14verdana18_boldE@Base 2.6.0
- _ZN3agg15clip_move_pointIdEEbT_S1_S1_S1_RKNS_9rect_baseIS1_EEPS1_S6_j@Base 
2.6.0
+ 
(optional)_ZN3agg15clip_move_pointIdEEbT_S1_S1_S1_RKNS_9rect_baseIS1_EEPS1_S6_j@Base
 2.6.0
  _ZN3agg15gamma_ctrl_impl11calc_pointsEv@Base 2.6.0
  _ZN3agg15gamma_ctrl_impl11calc_valuesEv@Base 2.6.0
  _ZN3agg15gamma_ctrl_impl12border_widthEdd@Base 2.6.0
@@ -298,7 +298,7 @@
  _ZN3agg19vpgen_clip_polyline7move_toEdd@Base 2.6.0
  _ZN3agg20mcs11_prop_condensedE@Base 2.6.0
  _ZN3agg20vertex_block_storageIdLj8ELj256EE12storage_ptrsEPPd@Base 2.6.0
- _ZN3agg20vertex_block_storageIdLj8ELj256EE8free_allEv@Base 2.6.0
+ (optional)_ZN3agg20vertex_block_storageIdLj8ELj256EE8free_allEv@Base 2.6.0
  _ZN3agg3arc19approximation_scaleEd@Base 2.6.0
  _ZN3agg3arc4initEddb@Base 2.6.0
  _ZN3agg3arc6rewindEj@Base 2.6.0

Bug#921110: RM: minetest-mod-mobf -- ROM; abandoned upstream

[Phil Morrell]

Package: ftp.debian.org

As a DM member of the Games team, I am escalating #830493 RC to a removal,
following the already removed #908007, #908018, #908019:

Uses deprecated api, upstream MIA, not in stretch, minetest-mod-mobs-redo

Sorry if I've missed anything procedural,
--
Phil Morrell (emorrp1)


signature.asc
Description: PGP signature

Bug#885195: guile-2.2 fix in lepton-eda

[Bdale Garbee]

The lepton-eda package is a fork of geda-gaf, and is what I'm personally
using and focusing my package maintenance efforts on now.

A patch for guile-2.2 support provided by lepton-eda upstream is now
part of the Debian package version 1.9.7-2.  That patch may illuminate
the changes required to update geda-gaf if someone is motivated to spend
the time.  See debian/patches/guile-2.2.patch in the lepton-eda source
package. 

Regards,

Bdale


signature.asc
Description: PGP signature

Bug#920727: Boost version 1.67 is known to be buggy

[Giovanni Mascellani]

Il 01/02/19 12:15, Olaf van der Spek ha scritto:
> Giovanni Mascellani:
>> Of course I will eventually update Boost, but probably not before
>> stretch is released. Version 1.67 is going in stretch.
> 
> https://www.debian.org/releases/stretch/ ;)

Oh, you're right, my bad! Of course I meant buster.

>> I have no idea why either meson or mpd think Boost 1.67 is buggy,
> 
> https://github.com/boostorg/lockfree/commit/12726cda009a855073b9bedbdce57b6ce7763da2
> 
> It's unfortunate Buster won't ship with 1.69 (or 1.68).

Sure, but it would have impossible to do otherwise. Regarding that bug,
it seems to be really trivial to workaround.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#920247: Opening an .xls file with (a) frozen column(s) in it results in soffice.bin using 100% CPU and steadily devouring RAM.

[Gennadiy Starostin]

Dear Bernhard,

In 1:6.1.5~rc1-2 such files open just fine, thank you!

Best regards,
Gennadiy.

Bug#921109: linux-image-4.19.0-1-amd64: [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 1us * 10 tries

[Christian Lins]

Package: src:linux
Version: 4.19.12-1
Severity: normal

Dear Maintainer,

the following stacktrace appears regularly in my system logs (every few
minutes). The screen of the system occasionally remains black on boot but I
don't know if this is related.

Here the stacktrace:

[34687.477170] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 1us *
10 tries - optc1_lock line:628
[34687.477222] WARNING: CPU: 0 PID: 1574 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254
generic_reg_wait+0xe7/0x160 [amdgpu]
[34687.477223] Modules linked in: fuse ctr ccm rfcomm cmac bnep btrfs
zstd_compress libcrc32c zstd_decompress xxhash xor arc4 nls_ascii nls_cp437
vfat fat edac_mce_amd ccp rng_core kvm iwlmvm amdkfd irqbypass crct10dif_pclmul
mac80211 crc32_pclmul btusb btrtl btbcm btintel bluetooth wmi_bmof amdgpu
snd_hda_codec_realtek snd_hda_codec_generic ghash_clmulni_intel
jitterentropy_rng raid6_pq chash efi_pstore gpu_sched ttm drbg
snd_hda_codec_hdmi iwlwifi snd_hda_intel evdev drm_kms_helper snd_hda_codec
snd_hda_core efivars snd_hwdep pcspkr snd_pcm snd_timer drm k10temp ansi_cprng
snd sp5100_tco soundcore cfg80211 ecdh_generic rfkill sg wmi video button
pcc_cpufreq acpi_cpufreq parport_pc ppdev lp parport efivarfs ip_tables
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb sd_mod
hid_apple
[34687.477251]  hid_generic usbhid hid crc32c_intel aesni_intel aes_x86_64
crypto_simd cryptd glue_helper i2c_piix4 ahci xhci_pci libahci igb xhci_hcd
libata i2c_algo_bit dca usbcore scsi_mod usb_common gpio_amdpt gpio_generic
[34687.477261] CPU: 0 PID: 1574 Comm: gnome-shell Tainted: GW
4.19.0-1-amd64 #1 Debian 4.19.12-1
[34687.477261] Hardware name: Gigabyte Technology Co., Ltd. B450 I AORUS PRO
WIFI/B450 I AORUS PRO WIFI-CF, BIOS F2 08/08/2018
[34687.477295] RIP: 0010:generic_reg_wait+0xe7/0x160 [amdgpu]
[34687.477296] Code: 44 24 58 8b 54 24 48 89 de 44 89 4c 24 08 48 8b 4c 24 50
48 c7 c7 18 70 ae c0 e8 44 25 c6 ff 83 7d 18 01 44 8b 4c 24 08 74 02 <0f> 0b 48
83 c4 10 44 89 c8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 0f
[34687.477297] RSP: 0018:a022c3df39a8 EFLAGS: 00010297
[34687.477298] RAX:  RBX: 0001 RCX:

[34687.477299] RDX:  RSI: 8a0f97a166a8 RDI:
8a0f97a166a8
[34687.477299] RBP: 8a0f91b6cf80 R08: 07c8 R09:
0001
[34687.477299] R10:  R11: b43e56ed R12:
000b
[34687.477300] R13: 504d R14: 0100 R15:
0001
[34687.477301] FS:  7f76fe58ccc0() GS:8a0f97a0()
knlGS:
[34687.477301] CS:  0010 DS:  ES:  CR0: 80050033
[34687.477302] CR2: 2c7ba08c8978 CR3: 0001ee8d6000 CR4:
003406f0
[34687.477302] Call Trace:
[34687.477341]  optc1_lock+0xa0/0xb0 [amdgpu]
[34687.477379]  dcn10_pipe_control_lock.part.27+0x4a/0x70 [amdgpu]
[34687.477415]  dcn10_apply_ctx_for_surface+0xc5/0x510 [amdgpu]
[34687.477449]  dc_commit_state+0x249/0x520 [amdgpu]
[34687.477481]  ? set_freesync_on_streams.part.6+0x4d/0x250 [amdgpu]
[34687.477514]  ? mod_freesync_set_user_enable+0x11f/0x150 [amdgpu]
[34687.477550]  amdgpu_dm_atomic_commit_tail+0x388/0xdb0 [amdgpu]
[34687.477554]  ? _cond_resched+0x15/0x30
[34687.477554]  ? wait_for_completion_timeout+0x3b/0x1a0
[34687.477557]  ? refcount_inc_checked+0x5/0x30
[34687.477584]  ? amdgpu_bo_ref+0x17/0x20 [amdgpu]
[34687.477589]  commit_tail+0x3d/0x70 [drm_kms_helper]
[34687.477594]  drm_atomic_helper_commit+0xb4/0x120 [drm_kms_helper]
[34687.477604]  drm_atomic_connector_commit_dpms+0xdb/0x100 [drm]
[34687.477612]  drm_mode_obj_set_property_ioctl+0x173/0x290 [drm]
[34687.477621]  ? drm_mode_obj_find_prop_id+0x40/0x40 [drm]
[34687.477628]  drm_ioctl_kernel+0xa1/0xf0 [drm]
[34687.477635]  drm_ioctl+0x1fc/0x390 [drm]
[34687.477643]  ? drm_mode_obj_find_prop_id+0x40/0x40 [drm]
[34687.477646]  ? do_wp_page+0x325/0x5f0
[34687.477673]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[34687.477675]  do_vfs_ioctl+0xa4/0x630
[34687.477676]  ksys_ioctl+0x60/0x90
[34687.477678]  ? ksys_read+0x9c/0xb0
[34687.477679]  __x64_sys_ioctl+0x16/0x20
[34687.477681]  do_syscall_64+0x53/0x100
[34687.477683]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[34687.477684] RIP: 0033:0x7f77075ce747
[34687.477685] Code: 00 00 90 48 8b 05 49 a7 0c 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 19 a7 0c 00 f7 d8 64 89 01 48
[34687.477685] RSP: 002b:7ffc5f7a43a8 EFLAGS: 0246 ORIG_RAX:
0010
[34687.477686] RAX: ffda RBX: 564f65f6a2b0 RCX:
7f77075ce747
[34687.477687] RDX: 7ffc5f7a43e0 RSI: c01864ba RDI:
000b
[34687.477687] RBP: 7ffc5f7a43e0 R08:  R09:
564f65f5f990
[34687.477687] R10: 564f65f66c08 R11: 0246 R12:
c01864ba
[34687.477688] R13: 000b R14: 7ffc5f7a45e0 R15:
7f77083ada20
[34

Bug#920752: gcompris-qt-data: Gcompris Debian version is missing activities found in flatpak version

[Matthew Crews]

On Fri, 1 Feb 2019 13:46:42 +0100 Johnny Jazeix  wrote:
> Sorry, I didn't see the reply, I thought I would have a notification.
> 
> These activities use box2d and according to the logs (
> https://buildd.debian.org/status/fetch.php?pkg=gcompris-qt&arch=alpha&ver=0.95-1&stamp=1547387638&raw=0)
> it is disabled and we don't add them in the package on this case
> ("Disabling qml-box2d module and depending activities:
> balancebox,land_safe,submarine").
> 
> This means that, even if box2d is installed afterwards, these activities
> won't be present.
> 
> I created a new task on GCompris bug server to check if it is possible to
> have the box2d check at runtime instead of compilation time:
> https://phabricator.kde.org/T10432
> 
> On Debian side, it seems the qml-box2d library is not packaged (
> https://github.com/qml-box2d/qml-box2d).
> In GCompris, when it's not available we compile it ourselves (via
> -DQML_BOX2D_MODULE=submodule) but I'm not sure if it would be acceptable to do
> it in Debian?
> Best way would probably be for qml-box2d to be packaged, set it as a
> mandatory dependency and use -DQML_BOX2D_MODULE=system.
> 
> Note: I'm one of the GCompris developers, I don't know much about the
> packaging.
> 
> Johnny

Thank you Johnny for the insight!

Looking at the license for qml-box2d, I don't see any reason that it
shouldn't be included in Debian, but considering how late we are into
the Buster release cycle, I don't think we can get it in the repos in
time for Buster?

In any case, I think this bug should be reclassified as a missing
dependency.



signature.asc
Description: OpenPGP digital signature

Bug#909933: Bug #909933 in jekyll marked as pending

[Youhei SASAKI]

Hi,

Thanks to ping. I'll try it this weekend.

On Tue, 29 Jan 2019 08:26:43 +0900,
Moritz Mühlenhoff  wrote:
>
> On Mon, Dec 03, 2018 at 04:19:44PM +, Youhei SASAKI wrote:
> > Control: tag -1 pending
> >
> > Hello,
> >
> > Bug #909933 in jekyll reported by you has been fixed in the
> > Git repository and is awaiting an upload. You can see the commit
> > message below and you can check the diff of the fix at:
> >
> > https://salsa.debian.org/ruby-team/jekyll/commit/61235dd677395a4e49c3f775c664f440dbf560de
>
> This is pending for two months, can you please upload in time
> for buster?

Bug#921020: RFS: python-imaplibext/0.7.6-1 [ITP]

[Thomas Ward]

To all whom it concerns:

Following Dmitry's notes about source package name being incorrect, I
have uploaded a renamed source-package to Mentors.

You can download the package with dget and this command (with -ux
because you don't have my keys):

dget -ux
https://mentors.debian.net/debian/pool/main/p/python-imaplibext/python-imaplibext_0.7.6-1.dsc

The ITP bug title I had attempted to set was too long it seems for a
command to control@ but the source package name in the ITP title has
been updated. The RFS has been retitled accordingly as well. (this was
suggested in #debian-mentors via IRC)

Bug#921108: python-matplotlib should depend on python-tk

[Tobias Hansen]

Package: python-matplotlib
Version: 2.2.3-5
Severity: normal
Tags: sid buster
Control: affects -1 sagetex

Hi Sandro,

matplotlib.pyplot depends on python-tk, so I think the package 
python-matplotlib should depend on it. This breaks the autopkgtest of sagetex, 
see
https://ci.debian.net/data/autopkgtest/testing/amd64/s/sagetex/1821254/log.gz

This didn't show up until now because sagemath had a dependency on python-tk to 
work around it.

Steps to reproduce:

$ python
>>> import matplotlib.pyplot
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line 115, in 

_backend_mod, new_figure_manager, draw_if_interactive, _show = pylab_setup()
  File "/usr/lib/python2.7/dist-packages/matplotlib/backends/__init__.py", line 
62, in pylab_setup
[backend_name], 0)
  File "/usr/lib/python2.7/dist-packages/matplotlib/backends/backend_tkagg.py", 
line 4, in 
from . import tkagg  # Paint image to Tk photo blitter extension.
  File "/usr/lib/python2.7/dist-packages/matplotlib/backends/tkagg.py", line 5, 
in 
from six.moves import tkinter as Tk
  File "/usr/lib/python2.7/dist-packages/six.py", line 203, in load_module
mod = mod._resolve()
  File "/usr/lib/python2.7/dist-packages/six.py", line 115, in _resolve
return _import_module(self.mod)
  File "/usr/lib/python2.7/dist-packages/six.py", line 82, in _import_module
__import__(name)
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 42, in 
raise ImportError, str(msg) + ', please install the python-tk package'
ImportError: No module named _tkinter, please install the python-tk package

(It would also be really cool if you could apply the upstream patch discussed 
in #918819!)

Best,
Tobias

Bug#919587: bringing back Imapsync

[Gergely Risko]

Hey,

I'm not working on imapsync right now.

To be honest, I'm using mbsync myself right now and completely
satisfied with it.

Feel free to package imapsync and push it to Debian, I'm as an old
maintainer not interested in this right now, because I don't have the
free time.  Sorry about this and wish you the best of luck!

Cheers,
Gergely

On 2019-01-22 14:56 (Tuesday), Markus Raps  writes:
> Dear RISKO Gergely,
>
> as in
> https://www.debian.org/doc/manuals/developers-reference/ch05.html#reintroducing-pkgs
> described
> i ask you, are you working on a comeback for imapsync in debian?
> Can I help you in any way? packaging, building, testing ?

Bug#921107: stretch-pu: package sox/14.4.1-5+deb9u1

[Salvatore Bonaccorso]

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

Hi

Mike Salvatore noticed that the 14.4.1-5 meant to close #773720 did
not add the patches to the series file, thus not applying the fixes.
I'm proposing to adress this via the upcoming point release given we
did past then release a DSA for wheezy-security including those fixes.

There are more no-dsa tagged entries which I have no time to adress as
well with this upload.

Attached the debdiff.

Regards,
Salvatore
diff -Nru sox-14.4.1/debian/changelog sox-14.4.1/debian/changelog
--- sox-14.4.1/debian/changelog 2014-12-24 20:40:04.0 +0100
+++ sox-14.4.1/debian/changelog 2019-02-01 16:18:21.0 +0100
@@ -1,3 +1,11 @@
+sox (14.4.1-5+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patches for CVE-2014-8145 to series file and really apply fixes.
+Thanks to Mike Salvatore for spotting the issue. (Closes: #773720)
+
+ -- Salvatore Bonaccorso   Fri, 01 Feb 2019 16:18:21 +0100
+
 sox (14.4.1-5) unstable; urgency=medium
 
   * Patches to fix memory corruptions on the heap, CVE-2014-8145
diff -Nru 
sox-14.4.1/debian/patches/0001-Check-for-minimum-size-sphere-headers.patch 
sox-14.4.1/debian/patches/0001-Check-for-minimum-size-sphere-headers.patch
--- sox-14.4.1/debian/patches/0001-Check-for-minimum-size-sphere-headers.patch  
2014-12-24 20:32:59.0 +0100
+++ sox-14.4.1/debian/patches/0001-Check-for-minimum-size-sphere-headers.patch  
2019-02-01 16:18:21.0 +0100
@@ -1,5 +1,5 @@
 src/sphere.c.old
-+++ src/sphere.c
+--- a/src/sphere.c.old
 b/src/sphere.c
 @@ -47,6 +47,11 @@ static int start_read(sox_format_t * ft)
  
/* Determine header size, and allocate a buffer large enough to hold it. */
diff -Nru 
sox-14.4.1/debian/patches/0002-More-checks-for-invalid-MS-ADPCM-blocks.patch 
sox-14.4.1/debian/patches/0002-More-checks-for-invalid-MS-ADPCM-blocks.patch
--- 
sox-14.4.1/debian/patches/0002-More-checks-for-invalid-MS-ADPCM-blocks.patch
2014-12-24 20:32:59.0 +0100
+++ 
sox-14.4.1/debian/patches/0002-More-checks-for-invalid-MS-ADPCM-blocks.patch
2019-02-01 16:18:21.0 +0100
@@ -1,5 +1,5 @@
 src/wav.c.old
-+++ src/wav.c
+--- a/src/wav.c.old
 b/src/wav.c
 @@ -166,7 +166,7 @@ static unsigned short  AdpcmReadBlock(sox_format_t * ft)
  /* work with partial blocks.  Specs say it should be null */
  /* padded but I guess this is better than trailing quiet. */
diff -Nru sox-14.4.1/debian/patches/series sox-14.4.1/debian/patches/series
--- sox-14.4.1/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ sox-14.4.1/debian/patches/series2019-02-01 16:18:21.0 +0100
@@ -0,0 +1,2 @@
+0001-Check-for-minimum-size-sphere-headers.patch
+0002-More-checks-for-invalid-MS-ADPCM-blocks.patch

Bug#921060: php-xdebug: just installed and not enabled, browser lost always connection to localhost, not able to show local content

[Dietmar Czekay]

It's a problem with opcache

insert /opcache.optimization_level=0xFBFF/ into opcache.ini solves 
the problem.


Workaround will be integrated into xdebug2.7.0

Bug#918757: i965-va-driver: Please update to 2.3.0 for fuller Coffee Lake support

[jay.slovak]

Package: i965-va-driver
Version: 2.2.0+dfsg1-2
Followup-For: Bug #918757

Dear Maintainer,

I am also impacted by this bug, are there any blockers that are preventing you 
from updating this package to a more recent version?

Thank you


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

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

Versions of packages i965-va-driver depends on:
ii  libc6  2.28-5
ii  libdrm-intel1  2.4.95-1
ii  libdrm22.4.95-1
ii  libva2 [libva-driver-abi-1.2]  2.3.0-2

i965-va-driver recommends no packages.

Versions of packages i965-va-driver suggests:
pn  i965-va-driver-shaders  

-- no debconf information

Bug#919189: Fwd: probabel FTBFS on arm64, likely due to Eigen 3 NEON code

[Thierry fa...@linux.ibm.com]

Unfortunately the workaround mentioned for arm64 breaks ppc64el arch as
compiling on buster fails with following error - what do we do ?
Thanks


BT check (recess model): prob vs. prob_fv  OK
2c2
< rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938
544.518 437.583 -567.388 435.04 1.75239
---
> rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938
544.518 437.583 -567.387 435.04 1.75239
BT check (2df model): prob vs. prob_fv
FAILED
FAIL test_bt.sh (exit status: 1)
-



On Sun, 13 Jan 2019 16:37:02 +0200 Adrian Bunk  wrote:
> Source: probabel
> Version: 0.5.0+dfsg-1
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=probabel&arch=arm64&ver=0.5.0%2Bdfsg-1&stamp=1538603399&raw=0
> 
> ...
> FAIL: test_bt
> =
> 
> Analysing BT...
> BT check: dose vs. dose_fv OK
> BT check (add model): prob vs. prob_fv OK
> BT check (domin model): prob vs. prob_fv   OK
> BT check (over_domin model): prob vs. prob_fv  OK
> BT check (recess model): prob vs. prob_fv  OK
> 2c2
> < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 
> 437.583 -567.387 435.04 1.75239
> ---
> > rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 
> > 437.583 -567.388 435.04 1.75239
> BT check (2df model): prob vs. prob_fv FAILED
> FAIL test_bt.sh (exit status: 1)
> 
> 
> Testsuite summary for ProbABEL 0.5.0
> 
> # TOTAL: 11
> # PASS:  10
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See checks/test-suite.log
> Please report to genabel-de...@r-forge.wu-wien.ac.at
> 
> make[4]: *** [Makefile:713: test-suite.log] Error 1
> 
> 
> I suspect this might be a problem with the NEON code in Eigen 3,
> and the fact that this can be fixed with the following workaround
> makes that even more probable:
> 
> --- debian/rules.old  2019-01-09 15:07:11.950823327 +
> +++ debian/rules  2019-01-09 15:17:23.280539016 +
> @@ -6,6 +6,10 @@
>  
>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all
>  
> +ifeq ($(DEB_HOST_ARCH),arm64)
> +  export DEB_CXXFLAGS_MAINT_APPEND = -march=armv8-a+nosimd
> +endif
> +
>  include /usr/share/dpkg/default.mk
>  
>  # Location of the example files, will be converted to the
> 
> 

Bug#921020: RFS: imaplibext/0.7.6-1 [ITP]

[Thomas Ward]

Hello.

On 2/1/19 9:27 AM, Dmitry Bogatov wrote:
> [2019-01-31 12:49] Thomas Ward 
>> Package: sponsorship-requests
>> Severity: wishlist
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "imaplibext"
>>
>>  * Package name: imaplibext
>>Version : 0.7.6-1
>>Upstream Author : Thomas Ward 
>>  * URL : https://gitlab.com/teward/imaplibext
>>  * License : AGPL-3+
>>Section : python
>>
>> It builds those binary packages:
>>
>>   python3-imaplibext - imaplib extension library for UID-based commands (Pyth
>> on 3)
> Shouldn't source package name be python-imaplibext?

Ahh, see that's not documented anywhere in the packaging manuals
reliably.  However, you are probably right.  I can reupload to mentors
accordingly, and then put an update to this RFS and the ITP, if you wish.

>
>> Alternatively, one can download the package with dget using this command:
>>
>>   dget -x https://mentors.debian.net/debian/pool/main/i/imaplibext/imaplibext
>> _0.7.6-1.dsc
> There seems some reproducible source of confusion. I do not have your
> (or any other sponsoree) key. Write `dget -ux', please.

That part's straight from the template on mentors' site and its RFS
template.  If that template is wrong, it probably needs adjusted there. 
But I will adjust it accordingly, and I"ll update the RFS accordingly.


Thomas

Bug#921080: lintian: warn about non-regenerated Parse::Yapp parsers

[Chris Lamb]

Hi Andrius,

> >  * What if the original code is actually included? How would
> >Lintian find that?
> 
> I would expect %.pm to be generated from %.yp, but not necessarily. 

How reliable is this?

Naturally, pre-generated parsers should be regenerated during
package build but we can't determine this from analysing just the
source tree (as we don't know whether that will happen at build-
time).

Thoughts?


Regards,

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