date:20200410

On Fri, 30 Aug 2019 07:38:15 + Matthias Klose  wrote:
> Package: src:python-debian
> Version: 0.1.35
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

I've opened 
https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/18
to address this bug

This is pretty straight-forward, i dont have access to the official
git repo so i'm opening this MR, but it would like to proceed quickly,
as python-debian is now the only remaining rdep of python-apt.

Ideally, i would like this to get merged and released in the next
couple of days (I can do a team upload if you add me to the salsa
team, there's no button to request access to the team) so that we can
then drop python-apt

thanks!

Bug#956400: Processed: retitle 956400 to qpdf: FTBFS on multiple 32-bit architectures, needs libatomic

2020-04-10 Thread Jay Berkenbilt

Oops, I fixed this, but I made a cut and paste error and "Closed" the wrong bug 
number in the changelog. I wlll clean it up tomorrow by removing the fixed 
version from the wrong bug and adding it to the right one.

On Fri, Apr 10, 2020, at 1:39 PM, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > retitle 956400 qpdf: FTBFS on multiple 32-bit architectures, needs libatomic
> Bug #956400 [src:qpdf] pdf: FTBFS on multiple 32-bit architectures, needs 
> libatomic
> Changed Bug title to 'qpdf: FTBFS on multiple 32-bit architectures, needs 
> libatomic' from 'pdf: FTBFS on multiple 32-bit architectures, needs 
> libatomic'.
> > thanks
> Stopping processing here.
> 
> Please contact me if you need assistance.
> -- 
> 956400: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956400
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#956339: unattended-upgrades: regression: packages with conffile prompts are no longer skipped, leading to upgrade failures

2020-04-10 Thread Paul Wise

Control: reopen -1

On Fri, 2020-04-10 at 21:28 +0800, Paul Wise wrote:

> I've tested this by downgrading popularity-contest using snapshot.d.o,
> adding changes to a conffile and then running u-u. The result is that I
> get this in the report, so it looks fixed again:

Actually it looks like this is not fixed after all. This time I got
both the popularity-contest upgrade failure due to conffile prompt and
the message that popularity-contest needs to be upgraded manually:

Subject:[package on hold] unattended-upgrades result for host: FAILURE

Unattended upgrade result: All upgrades installed

Packages that attempted to upgrade:
 ... popularity-contest ...

...

Log started: 2020-04-11  09:31:17
apt-listchanges: Reading changelogs...
Preconfiguring packages ...
apt-listchanges: Reading changelogs...
Preconfiguring packages ...
Preparing to unpack .../popularity-contest_1.70_all.deb ...
Unpacking popularity-contest (1.70) over (1.69) ...
Setting up popularity-contest (1.70) ...

Configuration file '/etc/cron.daily/popularity-contest'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** popularity-contest (Y/I/N/O/D/Z) [default=N] ? [1mdpkg:[0m error
processing package popularity-contest (--configure):
 end of file on stdin at conffile prompt
Processing triggers for man-db (2.9.1-1) ...
Errors were encountered while processing:
 popularity-contest
Log ended: 2020-04-11  09:31:50

...

Unattended-upgrades log:
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=bullseye,label=Debian, 
origin=Debian,codename=bullseye,label=Debian-Security, 
origin=Debian,codename=bullseye-security,label=Debian-Security, origin=Debian
Initial blacklist: 
Initial whitelist (not strict): 
Package popularity-contest has conffile prompt and needs to be upgraded manually
Packages that will be upgraded: ... popularity-contest ...
Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
Installing the upgrades failed!
error message: installArchives() failed
dpkg returned a error! See 
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log for details

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#956434: twm.1: Fix some formatting in the manual

2020-04-10 Thread Bjarni Ingi Gislason

Package: twm
Version: 1:1.0.10-1
Severity: minor
Tags: patch

Dear Maintainer,

Summary:

  Remove a superfluous paragraph macro (PP).

  Remove a trailing space in the output line.

  Reduce space between words.

  Use '\-' for an option, not '-'.

  Remove repeated words.

  Add a comma after 'e.g.' and 'i.e.' (man-pages(7)).

  Split long lines into shorter ones.

  Use '\-' (minus) as an arithmetic sign, not '-'.



  Details:


Input file is twm.1

chk_man: Next line: execute mandoc -T lint twm.1
mandoc: twm.1:40:11: WARNING: cannot parse date, using it verbatim: twm 1.0.10
mandoc: twm.1:99:2: WARNING: skipping paragraph macro: PP empty
mandoc: twm.1:120:2: WARNING: skipping paragraph macro: PP after SH
mandoc: twm.1:165:2: WARNING: skipping paragraph macro: PP after SH
mandoc: twm.1:849:2: WARNING: skipping paragraph macro: PP after SH
mandoc: twm.1:1186:2: WARNING: skipping paragraph macro: PP after SH
mandoc: twm.1:1262:2: WARNING: skipping paragraph macro: PP after SH
mandoc: twm.1:1276:2: WARNING: skipping paragraph macro: PP after SH

###

Test nr. 2:

Enable and fix warnings from 'test-groff'.


Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z

  [ "test-groff" is a developmental version of "groff" ]

Input file is ./twm.1

troff: backtrace: '/home/bg/git/groff/build/s-tmac/an-old.tmac':381: macro 'IP'
troff: :377: warning: trailing space
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an-old.tmac':381: macro 'IP'
troff: :646: warning: trailing space
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an-old.tmac':381: macro 'IP'
troff: :731: warning: trailing space
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an-old.tmac':381: macro 'IP'
troff: :761: warning: trailing space


Test nr. 12:

Reduce space between words.

867:The \fIbitmapname\fP may refer to one of the  built-in bitmaps
996:from f.destroy.  The intent here is to delete a single window,  not

#


Test nr. 25:

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

84:information requested by the user (usually through \fI-geometry\fP
765:programs that do not support an \fI-iconic\fP command line option or

#

Test nr. 27:

Find a repeated word

! 410 --> if
! 826 --> of
! 1239 --> the

#

Test nr. 35:

Add a comma after "e.g." and "i.e.", or use English words
(man-pages(7)).
Abbreviation points should be protected against being interpreted as
an end of sentence, if they are not, and that independent of the
current place on the line.

126:The \fIscreennumber\fP is a small positive number (e.g. 0, 1, etc.)
127:representing the screen number (e.g. the last number in the DISPLAY 
environment
160:by double quote characters (e.g. "blue") and are case-sensitive.
186:(e.g. to determine whether or not to enable autoraise as shown above), a 
string
686:unquoted, signed number (e.g. 999).  This variable has an effect only
1087:integer in double quotes (e.g. "999" ).  This function has an effect only
1169:specified by the argument \fIstring\fP.  If \fIstring\fP is empty (i.e. 
""),
1173:argument \fIstring\fP.  \fIString\fP may be a number (e.g. \fB"0"\fP or

#

Test nr. 37:

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.

twm.1: line 249 length 90
and may only be given within a \fBColor\fP, \fBGrayscale\fP or \fBMonochrome\fP 
list.  The

twm.1: line 256 length 94
\fBColor\fP, \fBGrayscale\fP or \fBMonochrome\fP list.  The optional 
\fIwincolorlist\fP allows

twm.1: line 393 length 84
only be specified inside of a \fBColor\fP, \fBGrayscale\fP or \fBMonochrome\fP 
list.

twm.1: line 400 length 88
may only be specified inside of a \fBColor\fP, \fBGrayscale\fP or 
\fBMonochrome\fP list.

#

Test nr. 42:

Remove superfluous quotation marks (") from the argument of a
single-font macro.

125:.B "$HOME/.twmrc.\fIscreennumber\fP"
132:.B "$HOME/.twmrc"

#

Test nr. 48:

The name of a man page is set in bold and the section in roman (see
man-pages(7).

54:startup script.  When used from \fIxdm(1)\fP or \fIxinit(1)\fP without
145:Widgets\fP manual and \fIxrdb(1)\fP).
340:the glyph image and mask in \fIbitmap(1)\fP form.
1277:X(7), Xserver(1), xdm(1), xrdb(1)

#

  Patch:

--- twm.1   2018-09-06 13:16:24.0 +
+++ twm.1.new   2020-04-11 01:01:14.0 +
@@ -51,7 +51,11 @@ click-to-type and pointer-driven keyboar
 key and pointer button bindings.
 .PP
 This program is usually started by the user's session manager or
-startup script.  When used from \fIxdm(1)\fP or \fIxinit(1)\fP without
+startup script.  When used from
+.BR xdm (1)
+or
+.BR xinit (1)
+without
 a session manager, \fItwm\fP is frequently executed in the foreground
 as the last client.  When run this way, exiting \fItwm\fP causes the
 session to be terminated (i.e., logged out).
@@ -81,7 +85,7 @@ when the outline is in the desired posit
 clicking in the

Bug#956433: gimp-plugin-registry: diff for NMU version 9.20180625+nmu1

Package: gimp-plugin-registry
Version: 9.20180625
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for gimp-plugin-registry (versioned as 9.20180625+nmu1). 
The diff
is attached to this message.

Regards.

diff -Nru gimp-plugin-registry-9.20180625/debian/changelog gimp-plugin-registry-9.20180625+nmu1/debian/changelog
--- gimp-plugin-registry-9.20180625/debian/changelog	2018-06-25 17:54:35.0 -0400
+++ gimp-plugin-registry-9.20180625+nmu1/debian/changelog	2020-04-10 21:15:11.0 -0400
@@ -1,3 +1,10 @@
+gimp-plugin-registry (9.20180625+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * port packaging-helper.py to python3, partially addresses #936612
+
+ -- Sandro Tosi   Fri, 10 Apr 2020 21:15:11 -0400
+
 gimp-plugin-registry (9.20180625) unstable; urgency=medium
 
   * [b24cbac] Auto update of debian/control
diff -Nru gimp-plugin-registry-9.20180625/debian/control gimp-plugin-registry-9.20180625+nmu1/debian/control
--- gimp-plugin-registry-9.20180625/debian/control	2018-06-25 17:54:35.0 -0400
+++ gimp-plugin-registry-9.20180625+nmu1/debian/control	2020-04-10 21:15:11.0 -0400
@@ -6,7 +6,7 @@
 Build-Depends: autotools-dev, quilt, libgimp2.0-dev, intltool,
  python, automake, autoconf, autotools-dev, dh-autoreconf,
  libxml-parser-perl, liblqr-1-0-dev, automake (>= 1.6), autoconf (>= 2.54), liblcms2-dev, libtiff-dev, debhelper (>= 8.0.0), libglib2.0-dev,
- python-debian
+ python3, python3-debian
 Standards-Version: 3.9.5
 Vcs-Git: https://github.com/bzed/gimp-plugin-registry.git
 Vcs-Browser: https://github.com/bzed/gimp-plugin-registry
diff -Nru gimp-plugin-registry-9.20180625/debian/control.in gimp-plugin-registry-9.20180625+nmu1/debian/control.in
--- gimp-plugin-registry-9.20180625/debian/control.in	2018-06-25 17:54:35.0 -0400
+++ gimp-plugin-registry-9.20180625+nmu1/debian/control.in	2020-04-10 21:14:38.0 -0400
@@ -6,7 +6,7 @@
 Build-Depends: autotools-dev, quilt, libgimp2.0-dev, intltool,
  python, automake, autoconf, autotools-dev, dh-autoreconf,
  #AUTO_UPDATE_Build-Depends#, debhelper (>= 8.0.0), libglib2.0-dev,
- python-debian
+ python3, python3-debian
 Standards-Version: 3.9.5
 Vcs-Git: https://github.com/bzed/gimp-plugin-registry.git
 Vcs-Browser: https://github.com/bzed/gimp-plugin-registry
diff -Nru gimp-plugin-registry-9.20180625/debian/packaging-helper.py gimp-plugin-registry-9.20180625+nmu1/debian/packaging-helper.py
--- gimp-plugin-registry-9.20180625/debian/packaging-helper.py	2018-06-25 17:54:35.0 -0400
+++ gimp-plugin-registry-9.20180625+nmu1/debian/packaging-helper.py	2020-04-10 21:14:38.0 -0400
@@ -29,8 +29,8 @@
 # returns (plug, parsed control field data)
 # We look at the first paragraph only!
 for plugin in __plugins__:
-data=(plugin, [x for x in deb822.Packages.iter_paragraphs(file(__basedir__ + os.path.sep+ plugin + os.path.sep + 'control'))][0])
-for key in data[1].iterkeys():
+data=(plugin, [x for x in deb822.Packages.iter_paragraphs(open(__basedir__ + os.path.sep+ plugin + os.path.sep + 'control'))][0])
+for key in data[1].keys():
 if key not in ALLOWED_FIELDS:
 raise Exception("Unknown control field in plugin %s: %s" %(data[0],key))
 yield data
@@ -44,7 +44,7 @@
 plugins_depends[plugin]={}
 # look trough keys we might want to merge
 for key in ['Suggests', 'Recommends']:
-if _control.has_key(key):
+if key in _control:
 plugins_depends[plugin][key]=deb822.PkgRelation.parse_relations(_control[key])
 
 # check for generated substvars files
@@ -54,7 +54,7 @@
 substvars = fd.read()
 try:
 rel = deb822.PkgRelation.parse_relations(__shlibs_re__.findall(substvars)[0])
-if plugins_depends[plugin].has_key('Recommends'):
+if 'Recommends' in plugins_depends[plugin]:
 plugins_depends[plugin]['Recommends'].extend(rel)
 else:
 plugins_depends[plugin]['Recommends']=rel
@@ -66,12 +66,12 @@
 for plugin in __plugins__:
 if len(plugins_depends[plugin]) > 0:
 rtext = '%s:' %(plugin,)
-if plugins_depends[plugin].has_key('Recommends'):
+if 'Recommends' in plugins_depends[plugin]:
 rtext = '%s\nRequired Packages: %s' %(
 rtext,
 deb822.PkgRelation.str(plugins_depends[plugin]['Recommends'])
 )
-if plugins_depends[plugin].has_key('Suggests'):
+if 'Suggests' in plugins_depends[plugin]:
 rtext = '%s\nOptional Packages: %s' %(
 rtext,
 deb822.PkgRelation.str(plugins_depends[plugin]['Suggests'])
@@ -104,18 +104,18 @@
 #print "Don't use 'Depends' in %s/control - use 'Recommends' instead" %(plugin,)
 #

Bug#956432: RM: libltcsmpte -- RoQA; Maintainer Inactive; Upstream Deprecated; No Reverse Dependencies

2020-04-10 Thread Boyuan Yang

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: ro...@gareus.org ales...@debian.org sramac...@debian.org

Dear FTP Masters,

As discussed in https://bugs.debian.org/939995 , libltcsmpte is now useless in
Debian with no reverse dependencies/build-dependencies. Besides, its upstream
has declared on the homepage that this library is deprecated and superceded by
other libraries. As a result, please consider removing it from the Debian
archive.

-- 
Regards,
Boyuan Yang


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

Bug#939995: libltcsmpte: no reverse dependencies - remove from the archive?

2020-04-10 Thread Boyuan Yang

X-Debbugs-CC: sramac...@debian.org ales...@debian.org ro...@gareus.org

Hi,

On Tue, 10 Sep 2019 22:29:52 +0200 Sebastian Ramacher 
wrote:
> Package: src:libltcsmpte
> Version: 0.4.4-1
> Severity: serious
> Tags: sid bullseye
> 
> libltcsmpte currently does not have any reverse dependencies in the
> archive. So, do we still need the package to be in the archive? If not,
> I'd suggest to remove it.

Since the original maintainers did not reply in the last 6 months and that the
upstream of libltcsmpte indeed indicated that the library has been superceded,
I will proceed with submitting removal request.

If you have any thoughts, please let me know immediately.

-- 
Regards,
Boyuan Yang

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

Bug#937800: python-greenlet: diff for NMU version 0.4.15-4.2

Control: tags 937800 + patch


Dear maintainer,

I've prepared an NMU for python-greenlet (versioned as 0.4.15-4.2). The diff
is attached to this message.

Please consider maintaining this package in the DPMT

Regards.

diff -Nru python-greenlet-0.4.15/debian/changelog python-greenlet-0.4.15/debian/changelog
--- python-greenlet-0.4.15/debian/changelog	2020-03-14 18:37:04.0 -0400
+++ python-greenlet-0.4.15/debian/changelog	2020-04-10 20:20:10.0 -0400
@@ -1,3 +1,11 @@
+python-greenlet (0.4.15-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937800
+  * Install documentation in python-greenlet-doc directory
+
+ -- Sandro Tosi   Fri, 10 Apr 2020 20:20:10 -0400
+
 python-greenlet (0.4.15-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-greenlet-0.4.15/debian/control python-greenlet-0.4.15/debian/control
--- python-greenlet-0.4.15/debian/control	2020-03-14 18:33:51.0 -0400
+++ python-greenlet-0.4.15/debian/control	2020-04-10 20:11:17.0 -0400
@@ -2,34 +2,13 @@
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
 Build-Depends: debhelper (>= 11), dh-python,
- python-all-dev, python-all-dbg,
  python3-all-dev, python3-all-dbg,
- python-setuptools, python3-setuptools,
+ python3-setuptools,
  python3-sphinx
 Standards-Version: 4.4.1
 Section: python
 Homepage: https://pypi.python.org/pypi/greenlet
 
-Package: python-greenlet-dbg
-Section: debug
-Architecture: any
-Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}, python-greenlet (= ${binary:Version}), ${python:Depends}
-Provides: ${python:Provides}
-XB-Python-Version: ${python:Versions}
-Recommends: python-dbg
-Description: Lightweight in-process concurrent programming - debugging symbols
- The greenlet package is a spin-off of Stackless, a version of CPython that
- supports micro-threads called "tasklets". Tasklets run pseudo-concurrently
- (typically in a single or a few OS-level threads) and are synchronized with
- data exchanges on "channels".
- .
- greenlet is the standalone package derived from the py lib, and is used by
- several non-blocking IO packages as a more flexible alternative to Python's
- built in coroutines.
- .
- This is the debugging symbols for greenlet.
-
 Package: python3-greenlet-dbg
 Section: debug
 Architecture: any
@@ -56,7 +35,7 @@
 Multi-Arch: foreign
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, libjs-jquery, libjs-underscore
-Suggests: python-greenlet, python-greenlet-dev
+Suggests: python3-greenlet, python-greenlet-dev
 Description: Lightweight in-process concurrent programming - documentation
  The greenlet package is a spin-off of Stackless, a version of CPython that
  supports micro-threads called "tasklets". Tasklets run pseudo-concurrently
@@ -72,7 +51,7 @@
 Package: python-greenlet-dev
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${misc:Depends}, python-greenlet (= ${binary:Version}) | python3-greenlet (= ${binary:Version})
+Depends: ${misc:Depends}, python3-greenlet (= ${binary:Version})
 Description: Lightweight in-process concurrent programming - development files
  The greenlet package is a spin-off of Stackless, a version of CPython that
  supports micro-threads called "tasklets". Tasklets run pseudo-concurrently
@@ -85,23 +64,6 @@
  .
  This is the development package for greenlet.
 
-Package: python-greenlet
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
-Provides: ${python:Provides}
-XB-Python-Version: ${python:Versions}
-Conflicts: python-codespeak-lib (<< 1.0)
-Suggests: python-greenlet-doc, python-greenlet-dev, python-greenlet-dbg
-Description: Lightweight in-process concurrent programming
- The greenlet package is a spin-off of Stackless, a version of CPython that
- supports micro-threads called "tasklets". Tasklets run pseudo-concurrently
- (typically in a single or a few OS-level threads) and are synchronized with
- data exchanges on "channels".
- .
- greenlet is the standalone package derived from the py lib, and is used by
- several non-blocking IO packages as a more flexible alternative to Python's
- built in coroutines.
-
 Package: python3-greenlet
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
diff -Nru python-greenlet-0.4.15/debian/python-greenlet-dbg.install python-greenlet-0.4.15/debian/python-greenlet-dbg.install
--- python-greenlet-0.4.15/debian/python-greenlet-dbg.install	2018-09-17 13:29:42.0 -0400
+++ python-greenlet-0.4.15/debian/python-greenlet-dbg.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python*/*-packages/*_d.so
diff -Nru python-greenlet-0.4.15/debian/python-greenlet-dbg.maintscript python-greenlet-0.4.15/debian/python-greenlet-dbg.maintscript
--- python-greenlet-0.4.15/debian/python-greenlet-dbg.maintscript	2018-09-17 13:29:42.0 -0400
+++ python-greenlet-0.4.15/debian/python-greenlet-dbg.maintscript	1969-12-31 19:00:00.0 -0500
@@ -1

Bug#937784: python-gevent: diff for NMU version 1.4.0-1.2

Control: tags 937784 + patch
Control: tags 953956 + patch


Dear maintainer,

I've prepared an NMU for python-gevent (versioned as 1.4.0-1.2). The diff
is attached to this message.

Please consider maintaining python-gevent with the Debian Python Modules team

Regards.

diff -Nru python-gevent-1.4.0/debian/changelog python-gevent-1.4.0/debian/changelog
--- python-gevent-1.4.0/debian/changelog	2020-03-14 18:47:23.0 -0400
+++ python-gevent-1.4.0/debian/changelog	2020-04-10 20:03:00.0 -0400
@@ -1,3 +1,11 @@
+python-gevent (1.4.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937784
+  * Install documentation in python-gevent-doc dir; Closes: #953956
+
+ -- Sandro Tosi   Fri, 10 Apr 2020 20:03:00 -0400
+
 python-gevent (1.4.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-gevent-1.4.0/debian/control python-gevent-1.4.0/debian/control
--- python-gevent-1.4.0/debian/control	2020-03-14 18:46:50.0 -0400
+++ python-gevent-1.4.0/debian/control	2020-04-10 19:14:24.0 -0400
@@ -1,35 +1,20 @@
 Source: python-gevent
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
-Build-Depends: debhelper (>= 11), dh-python, python-all-dev,
+Build-Depends: debhelper (>= 11), dh-python,
  dh-exec,
- libevent-dev (>= 1.4), python-greenlet (>= 0.4.15) | python-codespeak-lib (<< 1.0),
- python-all-dbg,
- python-greenlet-dbg, python3-greenlet-dbg,
- python-setuptools, python3-setuptools,
- python-cffi,  python-cffi-backend-dbg,
+ libevent-dev (>= 1.4),
+ python3-greenlet-dbg,
+ python3-setuptools,
  python3-cffi, python3-cffi-backend-dbg,
  python3-all-dev, python3-all-dbg, python3-greenlet (>= 0.4.15),
  python3-sphinx, python3-repoze.sphinx.autointerface,
- cython, cython-dbg, cython3,
+ cython3, cython3-dbg,
  libev-dev, libc-ares-dev
 Standards-Version: 4.3.0
 Section: python
 Homepage: http://www.gevent.org/
 
-Package: python-gevent-dbg
-Section: debug
-Architecture: any
-Depends: ${misc:Depends}, python-gevent (= ${binary:Version}), ${shlibs:Depends}, ${python:Depends},
- python-greenlet-dbg
-Provides: ${python:Provides}
-XB-Python-Version: ${python:Versions}
-Description: gevent is a coroutine-based Python networking library - debugging symbols
- gevent uses greenlet to provide a high-level synchronous API on top of
- libevent event loop.
- .
- This is the debugging symbols for gevent.
-
 Package: python-gevent-doc
 Section: doc
 Architecture: all
@@ -41,17 +26,6 @@
  .
  This is the documentation for gevent.
 
-Package: python-gevent
-Section: python
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, python-greenlet (>= 0.3.2) | python-codespeak-lib (<< 1.0)
-Provides: ${python:Provides}
-XB-Python-Version: ${python:Versions}
-Suggests: python-gevent-doc, python-gevent-dbg, python-openssl
-Description: gevent is a coroutine-based Python networking library
- gevent uses greenlet to provide a high-level synchronous API on top of
- libevent event loop.
-
 Package: python3-gevent
 Section: python
 Architecture: any
diff -Nru python-gevent-1.4.0/debian/python-gevent-dbg.install python-gevent-1.4.0/debian/python-gevent-dbg.install
--- python-gevent-1.4.0/debian/python-gevent-dbg.install	2018-07-07 13:23:32.0 -0400
+++ python-gevent-1.4.0/debian/python-gevent-dbg.install	1969-12-31 19:00:00.0 -0500
@@ -1,4 +0,0 @@
-usr/lib/python2*/*-packages/gevent/*_d.so
-usr/lib/python2*/*-packages/gevent/libev/*_d.so
-usr/lib/python2*/*-packages/gevent/libuv/*_d.so
-usr/lib/python2*/*-packages/gevent/resolver/*_d.so
diff -Nru python-gevent-1.4.0/debian/python-gevent.docs python-gevent-1.4.0/debian/python-gevent.docs
--- python-gevent-1.4.0/debian/python-gevent.docs	2011-05-17 10:45:37.0 -0400
+++ python-gevent-1.4.0/debian/python-gevent.docs	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-README.rst
-TODO
diff -Nru python-gevent-1.4.0/debian/python-gevent.install python-gevent-1.4.0/debian/python-gevent.install
--- python-gevent-1.4.0/debian/python-gevent.install	2018-07-07 13:23:32.0 -0400
+++ python-gevent-1.4.0/debian/python-gevent.install	1969-12-31 19:00:00.0 -0500
@@ -1,10 +0,0 @@
-usr/lib/python2*/*-packages/gevent/*.py
-usr/lib/python2*/*-packages/gevent/*[!_][!d].so
-usr/lib/python2*/*-packages/gevent/_ffi/*.py
-usr/lib/python2*/*-packages/gevent/libev/*.py
-usr/lib/python2*/*-packages/gevent/libev/*[!_][!d].so
-usr/lib/python2*/*-packages/gevent/libuv/*.py
-usr/lib/python2*/*-packages/gevent/libuv/*[!_][!d].so
-usr/lib/python2*/*-packages/gevent/resolver/*.py
-usr/lib/python2*/*-packages/gevent/resolver/*[!_][!d].so
-usr/lib/python2*/*-packages/*.egg-info
diff -Nru python-gevent-1.4.0/debian/rules python-gevent-1.4.0/debian/rules
--- python-gevent-1.4.0/debian/rules	2020-03-14 18:47:20.0 -0400
+++ python-gevent-1.4.0/debian/rules	2020-04-10 19:53:23.0 -0400
@@ -6,10 +6,10 @@
 
 export SHELL = /bin/bash

Bug#956431: oomd: Does not work with default cgroup setup from Debian testing

2020-04-10 Thread Sebastian Reichel

Package: oomd
Version: 0.3.1-1
Severity: normal

Hi,

With more or less default systemd configuration from
Debian testing and unmodified oomd configuration the
daemon fails to start with the following error:

oomd[483]: /sys/fs/cgroup is not a valid cgroup2 filesystem

-- Sebastian

Bug#956430: symlinks.1: Fix some formatting in the manual

2020-04-10 Thread Bjarni Ingi Gislason

Package: symlinks
Version: 1.4-4
Severity: minor
Tags: patch

Dear Maintainer,

  Summary:

  Trim trailing space.

  Remove superfluous paragraph macros (.PP).

  Use the correct font macro for one argument (one font, not two).

  Use '\-' to indicate an option, not '-'.

  Split long lines into shorter.


  Details:

Input file is symlinks.1

chk_man: Next line: execute mandoc -T lint symlinks.1
mandoc: symlinks.1:66:7: STYLE: whitespace at end of input line
mandoc: symlinks.1:88:7: STYLE: whitespace at end of input line
mandoc: symlinks.1:92:7: STYLE: whitespace at end of input line
mandoc: symlinks.1:107:7: STYLE: whitespace at end of input line
mandoc: symlinks.1:108:38: STYLE: whitespace at end of input line
mandoc: symlinks.1:110:27: STYLE: whitespace at end of input line
mandoc: symlinks.1:119:13: STYLE: whitespace at end of input line
mandoc: symlinks.1:1:16: WARNING: cannot parse date, using it verbatim: October 
2008
mandoc: symlinks.1:63:2: WARNING: skipping paragraph macro: PP empty
mandoc: symlinks.1:113:2: WARNING: skipping paragraph macro: PP empty
mandoc: symlinks.1:117:2: WARNING: skipping paragraph macro: PP empty

###

Test nr. 2:

Enable and fix warnings from 'test-groff'.

Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z

  [ "test-groff" is a developmental version of "groff" ]

Input file is ./symlinks.1

:12 (macro BI): only 1 argument, but more are expected



Test nr. 25:

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

8:.B -cdorstv
46:.B -c
53:.B -s
55:.B -c
61:.B -r
66:.I -c 
73:.B -s
78:.B -c
83:.I -d
88:.I -o 
92:.I -r 
95:.I -s
100:.I -t
104:.B -c
107:.I -v 
111:.B -v

#

Test nr. 37:

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.

symlinks.1: line 120length 86
has been written by Mark Lord , the original developer and 
maintainer

symlinks.1: line 121length 114
of the IDE Performance Package for linux, the Linux IDE Driver subsystem, 
hdparm, and a current day libata hacker.


#

  Patch:

--- symlinks.1  2020-02-21 23:55:08.0 +
+++ symlinks.1.new  2020-04-10 23:34:53.0 +
@@ -5,11 +5,11 @@ symlinks \- symbolic link maintenance ut
 .SH SYNOPSIS
 .B symlinks
 [
-.B -cdorstv
+.B \-cdorstv
 ]
 dirlist
 .SH DESCRIPTION
-.BI symlinks
+.B symlinks
 is a useful utility for maintainers of FTP sites, CDROMs,
 and Linux software distributions.
 It scans directories for symbolic links and lists them on stdout,
@@ -43,81 +43,81 @@ mounted at /mnt after booting from alter
 .B messy
 links are links which contain unnecessary slashes or dots in the path.
 These are cleaned up as well when
-.B -c
+.B \-c
 is specified.
 .PP
 .B lengthy
 links are links which use "../" more than necessary in the path
-(eg.  /bin/vi -> ../bin/vim)
+(e.g., /bin/vi \-> \&../bin/vim).
 These are only detected when
-.B -s
+.B \-s
 is specified, and are only cleaned up when
-.B -c
+.B \-c
 is also specified.
 .PP
 .B other_fs
 are those links whose target currently resides on a different filesystem
 from where symlinks was run (most useful with
-.B -r
+.B \-r
 ).
-.PP
 .SH OPTIONS
 .TP
-.I -c 
+.I \-c
 convert absolute links (within the same filesystem) to relative links.
 This permits links to maintain their validity regardless of the mount
 point used for the filesystem -- a desirable setup in most cases.
 This option also causes any
 .B messy
 links to be cleaned up, and, if
-.B -s
+.B \-s
 was also specified, then
 .B lengthy
 links are also shortened.
 Links affected by
-.B -c
+.B \-c
 are prefixed with
 .B changed
 in the output.
 .TP
-.I -d
+.I \-d
 causes
 .B dangling
 links to be removed.
 .TP
-.I -o 
+.I \-o
 fix links on other filesystems encountered while recursing.
 Normally, other filesystems encountered are not modified by symlinks.
 .TP
-.I -r 
+.I \-r
 recursively operate on subdirectories within the same filesystem.
 .TP
-.I -s
+.I \-s
 causes
 .B lengthy
 links to be detected.
 .TP
-.I -t
+.I \-t
 is used to test for what
 .B symlinks
 would do if
-.B -c
+.B \-c
 were specified, but without really changing anything.
 .TP
-.I -v 
-show all symbolic links.  By default, 
+.I \-v
+show all symbolic links.  By default,
 .B relative
-links are not shown unless 
-.B -v
+links are not shown unless
+.B \-v
 is specified.
-.PP
 .SH BUGS
 .B symlinks
 does not recurse or change links across filesystems.
-.PP
 .SH AUTHOR
-.B symlinks 
-has been written by Mark Lord , the original developer and 
maintainer
-of the IDE Performance Package for linux, the Linux IDE Driver subsystem, 
hdparm, and a current day libata hacker.
+.B symlinks
+has been written by Mark Lord ,
+the original developer and maintainer
+of the IDE Performance Package for linux,
+the Linux IDE Driver subsystem, hdparm,
+and a current day libata hacker.
 .SH SEE ALSO
 .BR symlink (2)


-- System Information:

Bug#956429: oomd: incorrect information in systemd service file

2020-04-10 Thread Sebastian Reichel

Package: oomd
Version: 0.3.1-1
Severity: important

Hi,

The systemd service file incorrectly specifies oomd_bin
instead of oomd. This basically makes the service file
completly useless.

-- Sebastian

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (250, 'unstable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages oomd depends on:
ii  init-system-helpers  1.57
ii  libc62.30-4
ii  libgcc-s110-20200324-1
ii  libjsoncpp1  1.7.4-3.1
ii  libstdc++6   10-20200324-1
ii  libsystemd0  244.3-1

oomd recommends no packages.

oomd suggests no packages.

Bug#956428: python3-samba: the switch to python3.8 breaks DC functionality on upgrade - samba_dnsupdate fails

2020-04-10 Thread Jeremy Jackson

Package: python3-samba
Version: 2:4.11.5+dfsg-1+b1
Severity: important

Dear Maintainer,


   * What led up to the situation?
   attempting to update working Samba AD DC on Buster to Testing
   * What exactly did you do (or not do) that was effective (or
   samba tries to update DNS to match changes in it's IP addresses
 ineffective)?
   * What was the outcome of this action?
   samba_dnsupdate is Python, and it fails due to error importing samba.gensec 
C module
   * What outcome did you expect instead?
   upgrade should have been transparent

   Upstream samba 4.11.6 contains the fix I believe:
git commit f0eb1e623f76d3dbd0c22f96cabebd1041c147df
Author: Torsten Fohrer 
Date:   Sun Dec 15 16:58:40 2019 +0100
Avoiding bad call flags with python 3.8, using METH_NOARGS instead of zero.


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1), LANGUAGE=en_CA 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-samba depends on:
ii  libbsd0 0.9.1-2
ii  libc6   2.30-4
ii  libldb2 2:2.0.8-2
ii  libpython3.83.8.2-1+b1
ii  libtalloc2  2.3.0-5
ii  libtevent0  0.10.1-4
ii  libwbclient02:4.11.5+dfsg-1+b1
ii  python3 3.8.2-3
ii  python3-crypto  2.6.1-13
ii  python3-ldb 2:2.0.8-2
ii  python3-talloc  2.3.0-5
ii  python3-tdb 1.4.2-3+b1
ii  samba-libs  2:4.11.5+dfsg-1+b1

Versions of packages python3-samba recommends:
ii  python3-gpg  1.13.1-6

python3-samba suggests no packages.

-- no debconf information

Bug#950038: Looks like a bug in httplib2 rather than on wsgi-intercept

2020-04-10 Thread Colin Watson

Control: reassign -1 python-wsgi-intercept 1.8.1-2
Control: clone -1 -2
Control: reassign -2 python3-httplib2 0.14.0-1
Control: retitle -2 python3-httplib2 >= 1.13.0 breaks python3-wsgi-intercept << 
1.9.0
Control: block -2 by -1

On Tue, Feb 11, 2020 at 11:43:03PM +0100, Andreas Beckmann wrote:
> I have a little trouble getting what you mean here:
> 
> On Mon, 10 Feb 2020 17:52:33 +0100 =?UTF-8?Q?H=c3=a5vard_Flaget_Aasen?=
>  wrote:
> > Though they write that the change was indeed in the httplib2 package.
> 
> * the change that introduced the bug
> * the change that fixed the bug (is there an embedded copy of httplib2
> somewhere?)
> * both ?

wsgi-intercept reimplements a bit of httplib2's interface in order to
intercept calls to it.  Until version 1.9.0, the way it did so violated
httplib2's reasonable expectations of its own interface, that is, that
httplib2 could reasonably add more keyword arguments to its own classes'
__init__ methods.  This is a perfectly normal way to extend interfaces
in Python, and it only broke because wsgi-intercept was making
unwarranted assumptions.

https://github.com/cdent/wsgi-intercept/commit/c4d44f5712e85d302db7e80e16156ca9c501bb6b
(in part) fixes this by ignoring those extra keyword arguments for the
purpose of interception, which indeed seems sensible since details of
TLS versions aren't very relevant when you're writing tests that
intercept network calls and redirect them to a WSGI application.

So, I disagree with Thomas that this is principally a bug in httplib2,
and I'm reassigning it back to wsgi-intercept.  The main part of the fix
should be to upgrade wsgi-intercept to 1.9.0 or newer.  However, it
would probably be appropriate for python3-httplib2 to declare a Breaks
on python3-wsgi-intercept (<< 1.9.0) once a fixed version exists in the
archive, so I'm cloning a part of this bug for that.

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

Bug#952796: go-mtpfs: Patch now available

2020-04-10 Thread Ben Wong

Package: go-mtpfs
Version: 0.0~git20180209.d6f8f3c-1
Followup-For: Bug #952796

Dear Maintainer,

Upstream has patched the bug.

https://github.com/hanwen/go-mtpfs/issues/103

https://github.com/hanwen/go-mtpfs/commit/1e01fd2b9a423ad0ad8fd06a1f3e2d8cf8f23e5a

I suggest updating go-mtpfs to the latest version.

This bugfix is urgently needed and, at a minimum, this patch should be
applied for Debian Stable even if the rest of the code is kept back at
2018. The version of go-mtpfs currently shipping with Debian Stable
has already caused massive data loss and will continue to do so to
unsuspecting users until patched.

Thank you,

—Ben


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

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

Versions of packages go-mtpfs depends on:
ii  libc6 2.28-10
ii  libusb-1.0-0  2:1.0.22-2

go-mtpfs recommends no packages.

go-mtpfs suggests no packages.

-- no debconf information

Bug#931772: [request-tracker-maintainers] Bug#931772: RT: On Create scrip ran but ticket not created

2020-04-10 Thread Dominic Hargreaves

Control: tags -1 + moreinfo

On Wed, Jul 10, 2019 at 11:24:05AM +0200, Sergio Gelato wrote:
> Package: request-tracker4
> Version: 4.4.1-3+deb9u3
> 
> I've run into the following problem when submitting a ticket with a large
> binary attachment. An On Create scrip is triggered (as configured for the
> queue) and sends e-mail with a copy of the attachment, but in the process
> the web server times out (40 seconds is the mod_fcgid default) and the
> ticket creation fails, resulting in there being no entry in table TICKETS
> in the database for the ticket number mentioned in the e-mail. (Also, the
> attachment is truncated in the outgoing e-mail, but this is a lesser
> concern.)
> 
> That it should take so long for the scrip to complete is not the object of
> this bug report (see #931769 for that). My complaint here is about the
> confusion created by sending out e-mail that refers to a nonexistent ticket.
> 
> I think I would prefer for the ticket to be created and the scrip
> not to complete (e-mail delivery can fail for other reasons anyway) than
> the opposite. Also, if the ticket is created by the mail gateway the
> gateway should consume the incoming message once the ticket is created,
> even if scrips haven't been run. In the original incident the incoming
> mail remained in the queue, causing a new e-mail to be sent on each
> delivery attempt (they all failed for the same reason). Scrip failure
> should of course be reported to the system administrator, but it seems
> less useful to mailbomb either the requestor or (as in my incident) the
> AdminCcs for the queue.

Hi Sergio

Sorry for the long silence - as I'm no longer using RT myself, I'm
not keeping as up to date with the bug list as I should.

The change you've proposed is quite a philosophical change to how
RT handles mail and I'd want to see this discussed and ideally
merged upstream before considering in Debian. Is this still an
issue for you? If so would you consider bringing it up on
https://forum.bestpractical.com/ or their bugtracker?

Cheers
Dominic

Bug#956426: plymouth: Message is unreadable at initial Debian screen on dual monitor

2020-04-10 Thread Gert van de Kraats


Package: plymouth
Version: 0.9.4-2
Severity: normal

Dear Maintainer,

Default plymouth theme with name "futureprototype" is used.
I am using 2 different monitors with size 1280 x 1024 and 1280 x 800.
Message like "resuming from hibernation" is written in the middle of the 
text

"Debian" with the same color (white)
and therefore the message is unreadable. Same problem with 
progress-percentage

during a software-upgrade.

Problem is at 
/usr/share/plymouth/themes/futureprototype/futureprototype.script

at routine TextYOffset.
This routine checks if the message, including some reserved lines, fits 
at the

screen.
If not, then the message is shifted upwards until it fits.
Coding:
    if (y + text_height > min_height)
    y = min_height - text_height;

This is wrong, because y is the vertical offset of the message at the 
largest

screen
 and min_height is the height of the smallest screen.
This causes a shift of the text, although it fits at the smallest screen.
Also the shift is not correct, because it computes the vertical offset y
from the top of the smallest screen in stead of the largest screen.
Corrected code:
    if (y - Window.GetY() + text_height > min_height)
    # shift to top of smallest window
    y = Window.GetY() + 1;

The message is shifted now to the first line that is visble on both screens,
to avoid overlapping the "Debian"-text.

With the corrected test the message is not shifted anymore at the used
monitors.

This wrong code is also present at some other older plymouth scripts and 
also

at ubuntu,
but does not harm there.
~



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

Kernel: Linux 5.4.0-4-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_DIE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plymouth depends on:
ii  init-system-helpers  1.57
ii  initramfs-tools  0.136
ii  libc6    2.30-4
ii  libdrm2  2.4.100-4
ii  libplymouth4 0.9.4-2
ii  lsb-base 11.1.0
ii  systemd  244.3-1
ii  udev 244.3-1

plymouth recommends no packages.

Versions of packages plymouth suggests:
ii  desktop-base 10.0.3
pn  plymouth-themes  

-- Configuration Files:
/etc/plymouth/plymouthd.conf changed:
[Daemon]
Theme=futureprototype


-- no debconf information

Bug#937579: python-apt: Python2 removal in sid/bullseye

> This is scheduled for 2.1.0, which should happen shortly. How fast
> do you want it?

asap of course :) there are only 2 rdeps of pyflakes: python-apt and
autopkgtest, and the latter is gonna get fixed in the coming days.

Gimme a couple of days to figure out if i can migrate all rdeps of
bin:python-apt to python3-apt so we can drop the whole python2 stack
from src:python-apt

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#956249: No command to show all the aliases of a unit

2020-04-10 Thread Adrian Mariano

We have pondered the matter of listing all the units that have the
same value as a given unit, and we're not feeling like this is a
particularly useful capability.  For the most part, units tend to be
defined twice, once in a full name form and once in an abbreviated
form, and both definitions are adjacent in the database.

So unless you can convince us otherwise, we're not going to add this
feature.  

We have fixed the second issue of the doubled "/" when your home is
root.  

On Thu, Apr 09, 2020 at 04:22:37AM +0800, 積丹尼 Dan Jacobson wrote:
> X-Debbugs-Cc: adri...@gnu.org
> Package: units
> Version: 2.19-1
> Severity: wishlist
> 
> $ units --verbose are
> Definition: 100 m^2 = 100 m^2
> should mention all the aliases of it, too, e.g., "a".
> 
> $ units --verbose foot
> Definition: 12 inch = 0.3048 m
> $ units --verbose ft
> Definition: foot = 12 inch = 0.3048 m
> 
> So we see there is no command to show all the aliases.
> We can see ft is short for foot,
> but we cannot see what, if any, foot is "long" for.
> 
> P.S., so --verbose (which currently does nothing above of course) should
> be given this new power, (and mention it on the man page.)
> 
> P.S.S.,
> 
> $ HOME=/ units --version
> GNU Units version 2.19
> with readline, with utf8, locale zh_TW
> Units data file is '/usr/share/units/definitions.units'
> Personal units data file is '//.units'
>   (file does not exist)  ^^
>  ^^
> One slash is enough! ^^

Bug#956363: fai-server: fai-make-nfsroot -k does not recreate base.tar.{xz,gz}

2020-04-10 Thread Mike Gabriel


Control: close -1
Control: tag -1 wontfix

Hi Thomas,

On  Fr 10 Apr 2020 22:37:25 CEST, Thomas Lange wrote:

On Fri, 10 Apr 2020 09:29:28 +, Mike Gabriel  
 said:


> Please consider updating the base.tar file when running  
fai-make-nfsroot -k.

Mmm, that's not possible, because the base.tar is created right after
calling debootstrap. Maybe I should change the man page.
If you want a new base.tar, you should recreate the nfsroot.

I myself recreates my nfsroot very often, I never use -k in production.


Ok. Will do that, then.

Thanks (+ closing this bug report),
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpRiB4bNqbUy.pgp
Description: Digitale PGP-Signatur

Bug#956152: closed by Thomas Goirand (Re: Processed: rabbitmq-server: fails to install reliably on arm64)

2020-04-10 Thread Antonio Terceiro

On Fri, Apr 10, 2020 at 08:53:18PM +0200, Paul Gevers wrote:
[...]
> That said, on the ci.debian.net infrastructure, we're not doing anything
> weird. We bootstrap lxc containers and we install packages into it.
> Maybe Antonio can chime in to add any oddities but I am not aware of
> any,
[...]

amd64 and arm64 are setup in the exact same way, so even if the setup
had something weird (not the case), that wouldn't explain why it only
fails on arm64.

signature.asc
Description: PGP signature

Bug#956425: RM: python-trollius -- RoQA; python2-only; backport of a another project; deprecated upstream; no rdeps

Package: ftp.debian.org
Severity: normal

Bug#956280: shapelib: change in ronn 0.9.0 breaks generation of manpages

2020-04-10 Thread Cédric Boutillier

Dear Sebastiaan,

On Thu, Apr 09, 2020 at 12:20:52PM +0200, Sebastiaan Couwenberg wrote:
> 
> Hopefully that (new) behavior will stay, this is not the first time an
> update of ruby-ronn required changes.

I think (or at least hope too) that it is here to stay.

> When do you plan to move it to unstable?

Given that shapelib is the only reverse build-dependency failing because
of this change, we can move to unstable when shapelib is ready to.
What about in 7 days from now? Tell me what suits best for you.

Cheers,

Cédric

signature.asc
Description: PGP signature

Bug#931347: marked as pending in lsp-plugins

Gnome user here with crap headphones.
This package gave them a second life with a straightforward setup.
Thanks for that. I hope it'll get accepted soon.

Jérémy

Bug#884095: stretch

2020-04-10 Thread Chris Lamb

Hi Hans,

> * https://f-droid.org/repo/eu.faircode.email_914.apk

This link 404s for me. Can you help?


Regards,

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

Bug#884095: stretch

2020-04-10 Thread Hans-Christoph Steiner


Here are the APKs from that failed diff:

* https://verification.f-droid.org/eu.faircode.email_914.apk
* https://f-droid.org/repo/eu.faircode.email_914.apk

And the Janus example provided in before still stands, unless you've
implemented detection based on file extension.

That verification box is stuck on Debian/stretch for the foreseable
future.  I guess diffoscope updates for stretch have stopped.



signature.asc
Description: OpenPGP digital signature

Bug#956424: etcd: autopkgtest does not seem to run any tests

2020-04-10 Thread Michael Banck

Source: etcd
Version: 3.2.26+dfsg-6
Severity: important

Dear Maintainer,

E.g. https://ci.debian.net/data/autopkgtest/testing/amd64/e/etcd/4881296/log.gz
has at the end:

|autopkgtest [15:59:05]: test dh-golang-autopkgtest:
|/usr/bin/dh_golang_autopkgtest
|autopkgtest [15:59:05]: test dh-golang-autopkgtest:
|[---
|[info] Testing github.com/coreos/etcd...
|[info] Source code installed by binary package, overriding
|dh_auto_configure...
|make: 'build' is up to date.
|autopkgtest [15:59:06]: test dh-golang-autopkgtest:
|---]
|autopkgtest [15:59:06]: test dh-golang-autopkgtest:  - - - - - - - - - -
|results - - - - - - - - - -
|dh-golang-autopkgtest PASS
|autopkgtest [15:59:06]:  summary
|dh-golang-autopkgtest PASS

Compared to the rather verbose output by the override_dh_auto_test
target, there does not seem to be any tests run, also note the time
stamps (same second).


Michael

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

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

Bug#956423: node-request: deprecated upstream: should not be part of next stable Debian release

Le ven. 10 avr. 2020 à 23:48, Jonas Smedegaard  a écrit :

> Package: node-request
> Version: 2.88.1-4
> Severity: grave
> Justification: renders package unusable
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Upstream has deprecated this module:
> https://github.com/request/request/issues/3142
>
> It already has seen no new updates for a year,
> and is not expected to do so:
> This module is unsuitable for next stable Debian release!
>
> Upstream issue discusses alternatives to use instead.
>

Yes, node-request should be dropped.
Best smooth (transition-wise) replacement is "got":
https://github.com/sindresorhus/got#comparison
I'm using it everywhere, it works, it's alive and well documented.

Jérémy

Bug#956423: node-request: deprecated upstream: should not be part of next stable Debian release

2020-04-10 Thread Jonas Smedegaard

Package: node-request
Version: 2.88.1-4
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream has deprecated this module:
https://github.com/request/request/issues/3142

It already has seen no new updates for a year,
and is not expected to do so:
This module is unsuitable for next stable Debian release!

Upstream issue discusses alternatives to use instead.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6Q6LkACgkQLHwxRsGg
ASHgqg/9FXRMJxxxpyv7BZHDM+dj3CMBHCHqjd29i+I3kyHND8HBe4sncafdXN9/
0gAQsxtG3Ad81jqY0gGV2wMTf7jMQUGnF4F58TJCbZXcsDehfb4DGjTT4Z20rEoA
bd+pc8uMEojCYq+/Qd8yw9FW/MUgFmNEjZBG6MSM9O4QhxHEfVL4HlERK+DR+wok
f5WyvIfQrx5jlpiXcIT+mA0WmbI+kYqCnfF8zf09q2R1uMLr1XgRVkCei1BXI51d
PgLFWVgLXDshHJJJ2S/DNCdPRaW6vB0U9v31slnZcGgPuMvyz8rXuZqI8VlcaPo5
DAIAeJBV0ZLZx+gM1gxcYZdmoDB1OOvyTmSKkDb7axoiFLQZCScou+XMCCSP2QNW
NknuCkVphX4t4iNIgBZbypm4vw3xRyBJq+tdD3G4A1Myy/52ItXiPfx0GfgtuQsQ
OnNUceTZcYr/qHqptnxvRQ09yBQWQhuckkbVWWEddHIUJohlDs1M3Tjpu71rdULc
O85hZHZX/hUN0vyPBKfDTO7zlQJxpwyYYuVniRN7PQNLa3sY/En3cUZ6sQNTKKwM
JbG+Jxw4pHao7M6tYHslaTX19rh6QvLcCZI7526Qm2Ktc9Oi6VoP/5b14UzLIbdB
fPrPcnFRuY6ymbtGb27zqq+7ww2r2MWnRqVR1E8kNLY2Zrg8blM=
=nQxC
-END PGP SIGNATURE-

Bug#956422: RM: mpris-remote -- RoQA; Depends on Python 2, dead upstream, unmaintained

2020-04-10 Thread Moritz Muehlenhoff

Package: ftp.debian.org
Severity: normal

Please remove mpris-remote. It depends on Python 2, is dead upstream (last 
commit
in 2013) and the last maintainer upload was in 2010.

Cheers,
Moritz

Bug#939329: named crashes when setting nsec3param

2020-04-10 Thread Matt Corallo

Note that upstream claims this is fixed (I haven't verified). Would be nice to 
get a patch backport to stable.

On 9/3/19 10:42 AM, Matt Corallo wrote:
> Yep, no problem. I moved it out of the way to keep it around, will try
> to avoid upgrading bind and losing the original deb to run backtraces
> against.
> 
> 
> On 9/3/19 2:10 PM, Ondřej Surý wrote:
>> Thanks Matt, could you please save the core in case we (ISC) are going to 
>> need more information from it?
>>
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@sury.org
>>
>>
>>
>>> On 3 Sep 2019, at 16:05, Matt Corallo  wrote:
>>>
>>> Core dump trace follows:
>>>
>>> [New LWP 29244]
>>> [New LWP 29241]
>>> [New LWP 29245]
>>> [New LWP 29243]
>>> [New LWP 29242]
>>> [New LWP 29246]
>>> [New LWP 29247]
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
>>> Core was generated by `/usr/sbin/named -u bind'.
>>> Program terminated with signal SIGABRT, Aborted.
>>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>>> 50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>>> [Current thread is 1 (Thread 0xafda91a0 (LWP 29244))]
>>> (gdb) thread apply all bt
>>>
>>> Thread 7 (Thread 0xae5a61a0 (LWP 29247)):
>>> #0  0xb2ffbc00 in __GI_epoll_pwait (epfd=,
>>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>>timeout=timeout@entry=-1, set=set@entry=0x0) at
>>> ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
>>> #1  0xb2ffbd40 in epoll_wait (epfd=,
>>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>>timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:32
>>> #2  0xb3471a9c in watcher (uap=0xb0db5010) at
>>> ../../../../lib/isc/unix/socket.c:4260
>>> #3  0xb335b7e4 in start_thread (arg=0xd7e8b09f) at
>>> pthread_create.c:486
>>> #4  0xb2ffbadc in thread_start () at
>>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>>
>>> Thread 6 (Thread 0xaeda71a0 (LWP 29246)):
>>> #0  futex_abstimed_wait_cancelable (private=0, abstime=0xaeda6858,
>>> expected=0, futex_word=0xb0db30a8)
>>>at ../sysdeps/unix/sysv/linux/futex-internal.h:205
>>> #1  __pthread_cond_wait_common (abstime=,
>>> mutex=, cond=) at pthread_cond_wait.c:539
>>> #2  __pthread_cond_timedwait (cond=cond@entry=0xb0db3080,
>>> mutex=mutex@entry=0xb0db3028, abstime=abstime@entry=0xaeda6858)
>>>at pthread_cond_wait.c:667
>>> #3  0xb347bc54 in isc_condition_waituntil
>>> (c=c@entry=0xb0db3080, m=m@entry=0xb0db3028,
>>> t=t@entry=0xb0db3074)
>>>at ../../../../lib/isc/pthreads/condition.c:59
>>> #4  0xb3463f44 in run (uap=0xb0db3010) at
>>> ../../../lib/isc/timer.c:806
>>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b14f) at
>>> pthread_create.c:486
>>> #6  0xb2ffbadc in thread_start () at
>>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>>
>>> Thread 5 (Thread 0xb0dab1a0 (LWP 29242)):
>>> #0  0xb36553c0 in ?? () from /lib/aarch64-linux-gnu/libcrypto.so.1.1
>>> #1  0xb0da6d30 in ?? ()
>>> #2  0x94603695287e7065 in ?? ()
>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>>
>>> Thread 4 (Thread 0xb05aa1a0 (LWP 29243)):
>>> #0  futex_wait_cancelable (private=0, expected=0,
>>> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
>>> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
>>> cond=0xb0db10a8) at pthread_cond_wait.c:502
>>> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
>>> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
>>> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
>>> ../../../lib/isc/task.c:1089
>>> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
>>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
>>> pthread_create.c:486
>>> #6  0xb2ffbadc in thread_start () at
>>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>>
>>> Thread 3 (Thread 0xaf5a81a0 (LWP 29245)):
>>> #0  futex_wait_cancelable (private=0, expected=0,
>>> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
>>> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
>>> cond=0xb0db10a8) at pthread_cond_wait.c:502
>>> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
>>> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
>>> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
>>> ../../../lib/isc/task.c:1089
>>> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
>>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
>>> pthread_create.c:486
>>> #6  0xb2ffbadc in thread_start () at
>>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>>
>>> Thread 2 (Thread 0xb0e12440 (LWP 29241)):
>>> #0  0xb2f5ea9c in __GI___sigsuspend
>>> (set=set@entry=0xd7e8b158) at

Bug#956421: RM: editobj -- RoQA; Depends on Python 2, outdated, unmaintained

2020-04-10 Thread Moritz Muehlenhoff

Package: ftp.debian.org
Severity: normal

Please remove editobj. It depends on Python 2 and there are no reverse deps.
The package version currently in the archive is from 2006 and the last
upload was four years ago (and hasn't seen any action since the package
was adopted)

Cheers,
Moritz

Bug#955429: possiblity of using a different download agent like wget in bad internet connections

2020-04-10 Thread Cédric Boutillier

Hi,

On Thu, Apr 09, 2020 at 09:43:02PM +0530, Pirate Praveen wrote:
> boutil and terceiro also reported same problem yesterday in #debian-ruby irc
> (copying them). So I think the issue is not specific to me.
> 
> boutil: hi! do you experience many "Hash Sum mismatch" when doing upgrades
> with apt-cache-ng?

I indeed experience this often on my laptop (uptodate sid). On wifi,
about every second `apt update` fails with such a mismatch, either when
updating my system, or building a package with sbuild.
Ethernet connection is a bit better, but still it happens. I have a not
so fast ADSL line.

I just got 5 times in a row this:
[...]
Err:19 http://ftp.fr.debian.org/debian testing/main DEP-11 64x64 Icons
  Hash Sum mismatch
  Hashes of expected file:
   - Filesize:7050569 [weak]
   - SHA256:802728a6bcbe5201c8cafa40286b9b10c8942beefe2922725056bfc706f86753
   - MD5Sum:570e3cdb335fed69c669af1610093c7b [weak]
  Hashes of received file:
   - SHA256:43b59d8c2ef9ac42b56f38108557a5e9b35a793a96a4268d6004a0d5e10865f9
   - MD5Sum:46fcee066fb69d7934cbbdf8d941273a [weak]
   - Filesize:7050569 [weak]
  Last modification reported: Fri, 10 Apr 2020 08:17:35 +
  Release file created at: Fri, 10 Apr 2020 15:23:29 +
[...]

My desktop station at work doesn't seem to show this behavior. It is
connected to a fast ethernet cable and fast internet connection.



Cheers,

Cédric


signature.asc
Description: PGP signature

Bug#950221: salsa: Please transfer natsort from debian to python-team/modules

2020-04-10 Thread Joerg Jaspert


On 15734 March 1977, Scott Talbert wrote:

Hello again Salsa admins.  Can you please transfer natsort to 
python-team/modules?


I would like to get natsort fixed ASAP.


https://salsa.debian.org/python-team/modules/natsort

--
bye, Joerg

Bug#937784: python-gevent: Python2 removal in sid/bullseye

2020-04-10 Thread Moritz Mühlenhoff

On Fri, Aug 30, 2019 at 07:39:51AM +, Matthias Klose wrote:
> Package: src:python-gevent
> Version: 1.3.7-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

All reverse dependencies of python-gevent have switched to Python 3
or were removed, so Py2 support can be dropped now.

Cheers,
Moritz

Bug#956364: fai-server: DEBIAN_11 dist not working in /etc/fai/NFSROOT

2020-04-10 Thread Thomas Lange

> On Fri, 10 Apr 2020 09:34:01 +, Mike Gabriel 
>  said:

> This leads to fai-make-nfsroot failing to generate DEBIAN_11 as a  
> class. It only generated DEBIAN_.
Ouch. You are right.

> It would either be good to document this, or add a DEBIAN_ class to  
> /etc/fai/NFSROOT or work around this in fai-make-nfsroot.
I will add DEBIAN_. This will look like this:

PACKAGES install-norec DEBIAN_11 DEBIAN_
fdisk gpg

-- 
regards Thomas

Bug#932388: pure-ftpd-postgresql: Postgresql-based auth fails without error after buster upgrade

2020-04-10 Thread Reinhard Kuss


Dear maintainer,

I can confirm the error reported.  I have almost the exact same 
configuration as Alan, and the same upgrade procedure (stretch->buster).

The only difference here is, that passwords in the db-table are cleartext.
I did the same debugging steps, and got the same results. One exception: 
I did not changed the encryption in

/etc/pure-ftpd/db/postgresql.conf:
PGSQLCrypt   

After downgrade to 1.0.43 everything started working again.

Upstream mentioned some fix in version 1.0.49, which broke external 
authentication handlers in 1.0.48.

But buster has 1.0.47...Did not looked further into it.


--
Reinhard

Bug#956217: apache2: Does not run server side CGI scipts and start/stop broken

2020-04-10 Thread Tom Bryant

I fixed this when I upgraded to Debian 10, Buster.


From: Tom Bryant 
Sent: Wednesday, April 8, 2020 10:14 AM
To: Debian Bug Tracking System 
Subject: Bug#956217: apache2: Does not run server side CGI scipts and 
start/stop broken

Package: apache2
Version: 2.4.10-10+deb8u16
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:

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

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

Versions of packages apache2 depends on:
ii  apache2-bin2.4.10-10+deb8u16
ii  apache2-data   2.4.10-10+deb8u16
ii  apache2-utils  2.4.10-10+deb8u16
ii  dpkg   1.17.27
ii  lsb-base   4.1+Debian13+nmu1
ii  mime-support   3.58
ii  perl   5.20.2-3+deb8u12
ii  procps 2:3.3.9-9+deb8u1

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.35

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  firefox-esr [www-browser]68.5.0esr-1~deb8u1
ii  google-chrome-stable [www-browser]   80.0.3987.122-1
ii  konqueror [www-browser]  4:4.14.2-1
ii  w3m [www-browser]0.5.3-19+deb8u2

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.1-3
ii  libaprutil1  1.5.4-1
ii  libaprutil1-dbd-sqlite3  1.5.4-1
ii  libaprutil1-ldap 1.5.4-1
ii  libc62.19-18+deb8u10
ii  libldap-2.4-22.4.40+dfsg-1+deb8u5
ii  liblua5.1-0  5.1.5-7.1
ii  libpcre3 2:8.35-3.3+deb8u4
ii  libssl1.0.0  1.0.1t-1+deb8u12
ii  libxml2  2.9.1+dfsg1-5+deb8u8
ii  perl 5.20.2-3+deb8u12
ii  zlib1g   1:1.2.8.dfsg-2+deb8u1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  firefox-esr [www-browser]68.5.0esr-1~deb8u1
ii  google-chrome-stable [www-browser]   80.0.3987.122-1
ii  konqueror [www-browser]  4:4.14.2-1
ii  w3m [www-browser]0.5.3-19+deb8u2

Versions of packages apache2 is related to:
ii  apache2  2.4.10-10+deb8u16
ii  apache2-bin  2.4.10-10+deb8u16

-- Configuration Files:
/etc/apache2/apache2.conf changed:
Mutex file:${APACHE_LOCK_DIR} default
PidFile ${APACHE_PID_FILE}
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
HostnameLookups Off
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
Include ports.conf

Options FollowSymLinks
AllowOverride None
Require all denied


AllowOverride None
Require all granted


Options Indexes FollowSymLinks
AllowOverride None
Require all granted


Options ExecCGI
setHandler cgi-script

AccessFileName .htaccess

Require all denied

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

/etc/apache2/sites-available/000-default.conf changed:

# The ServerName directive sets the request scheme, hostname and port 
that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to

Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-10 Thread Guillem Jover

On Tue, 2020-04-07 at 17:18:27 -0700, Sean Whitton wrote:
> On Wed 08 Apr 2020 at 01:18AM +02, Guillem Jover wrote:
> >> +The copyright information for files in a package must be copied
> >> +verbatim into ``/usr/share/doc/package/copyright``, when
> >   ^ Shouldn't this and other instances
> > of "package" be marked as replaceable text?
> 
> Possibly, though that's an issue with the existing Policy text not this
> patch -- perhaps I should just find and replace after applying the patch
> from this bug?

Ah right, thought this was specific to this drafting. Sounds good.

> > I'm assuming the entire list is supposed to hold at the same time? If
> > so perhaps adding an «and» here would make this completely unambiguous.
> 
> Hmm, thanks for the feedback, but I don't think "a; b; and c" is
> ambiguous in English, and "a; and b; and c" would be an irregular usage.

I guess what I found ambiguous is that "; and" in English does not
necessarily have a logic connotation. So one can read it as "item a;
item b; and item c" where the and is just there to introduce the next
item instead of specifying the content is ANDed. The “when” should
make it somewhat clear, but on a quick read it just made me doubt.

Take the example list in ch-source.rst
“Main building script: ``debian/rules``”:

  ,---
  There are sometimes good reasons to use a different approach.  For
  example, the standard tools for packaging software written in some
  languages may use another tool; some rarer packaging patterns, such as
  multiple builds of the same software with different options, are easier to
  express with other tools; and a packager working on a different packaging
  helper might want to use their tool.
  `---

Which I'd take it as an “and” for the list, not for its contents holding
true at the same time. :)

With the context I guess it is somewhat clearish, but I'd really like
to see text that is completely unambiguous for stuff that is normative.

> If this really does need clarification it would be better to add "all of
> the following" or something before the list.

Yes, clarifying before the list starts would work too, and I thought I
mentioned it in my reply, but apparently not.

Thanks,
Guillem

Bug#956363: fai-server: fai-make-nfsroot -k does not recreate base.tar.{xz,gz}

2020-04-10 Thread Thomas Lange

> On Fri, 10 Apr 2020 09:29:28 +, Mike Gabriel 
>  said:

> Please consider updating the base.tar file when running fai-make-nfsroot 
-k.
Mmm, that's not possible, because the base.tar is created right after
calling debootstrap. Maybe I should change the man page.
If you want a new base.tar, you should recreate the nfsroot.

I myself recreates my nfsroot very often, I never use -k in production.

-- 
regards Thomas

Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-10 Thread Sean Whitton

control: tag -1 +pending

Hello,

On Sun 05 Apr 2020 at 05:54PM -07, Sean Whitton wrote:

> Here's a patch for seconding, and for the FTP Team to approve.  Thanks
> to Scott for prompting the "all copies" amendation.

FTP Team approval happened at today's team meeting:
http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-04-10-19.58.log.html

and we have enough seconds.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#956420: src:pynwb: fails to migrate to testing for too long

Source: pynwb
Version: 0.5.1-2
Severity: serious
Control: fixed -1 1.2.1-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:pynwb in its
current version in unstable has been trying to migrate for 62 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have marked the version in unstable as fixing this bug, so if that
version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=pynwb




signature.asc
Description: OpenPGP digital signature

Bug#956419: src:speechd-el: fails to migrate to testing for too long

Source: speechd-el
Version: 2.8-2.1
Severity: serious
Control: fixed -1 2.9-1
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:speechd-el in
its current version in unstable has been trying to migrate for 63 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have marked the version in unstable as fixing this bug, so if that
version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=speechd-el




signature.asc
Description: OpenPGP digital signature

Bug#956411: ca-certificates: please update to latest Mozilla bundle

2020-04-10 Thread Michael Shuler

Thanks for the bug report. I've checked in the latest release branch 
certdata, so the recent adds/removes will be up in the next release. 
I'll try to get that release built soon, it has indeed been a while.


Kind regards,
Michael

Bug#955005: Its fine

2020-04-10 Thread Joerg Jaspert


On 15734 March 1977, Joerg Jaspert wrote:

its fine, go for it.


So, whatever, for the policy foo, the patch as presented earlier in this 
bug is seconded, go for it, commit, change the policy.


--
bye, Joerg


signature.asc
Description: PGP signature

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-10 Thread Noah Meyerhans

Package: src:glibc
Version: 2.30-4
Severity: wishlist
X-Debbugs-CC: debian-...@lists.debian.org

The ARMv8.1 spec, as implemented by the ARM Neoverse N1 processor,
introduces a set of instructions [1] that result in significant performance
improvements for multithreaded applications.  Sample code demonstrating the
performance improvements is attached.  When run on a 16-core Neoverse N1
host with glibc 2.30-4, runtimes vary significantly, ranging from lows
around 250ms to highs around 15 seconds.  When linked against glibc rebuilt
with support for these instructions, runtimes are consistently <50ms.
Significant performance impact has also been observed in less contrived
cases (MariaDB and Postgres), but I don't have a repro to share.

Gcc provides two ways to enable support for these instructions at build
time.  The simplest, and least disruptive, is to enable -moutline-atomics
globally in the arm64 glibc build.  As described at [2], this option enables
runtime checks for the availability of the atomic instructions.  If found,
they are used, otherwise ARMv8.0 compatible code is used.  The drawback of
this option is that the check happens at runtime, thus introducing some
overhead on all arm64 installations.

The second option is to provide libraries built with explicit support for
the ARM v8.1a spec via the -march=armv8.1-a flag.  This option is also
described at [2].  This build would be incompatible with earlier versions of
the spec, so it would need to be provided in a location where the linker
will automatically discover it if it is usable (e.g.
/lib/aarch64-linux-gnu/atomics/).  This does not incur any runtime overhead,
but obviously involves an additional libc build, and the corresponding
complixity and disk space utilization.  I'm not sure if this is an option
that the glibc maintainers are interested in pursuing.

I've tested both options and found them to be acceptable on v8.1a (Neoverse
N1) and v8a (Cortex A72) CPUs.  I can provide bulk test run data of the
various different configuration permutations if you'd like to see additional
data.

I can provide patches or merge requests implementing either option, at least
for a starting point, if you'd like to see them.

Thanks!
noah

1. https://static.docs.arm.com/ddi0557/a/DDI0557A_b_armv8_1_supplement.pdf
   Section B1
2. https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
/*
 * Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License"). You may
 * not use this file except in compliance with the License. A copy of the
 * License is located at
 *
 *  http://aws.amazon.com/apache2.0/
 *
 * or in the "license" file accompanying this file. This file is distributed
 * on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
 * express or implied. See the License for the specific language governing
 * permissions and limitations under the License.
*/

/* Build with:
 * gcc -O2 -o a.out a.c -lpthread -DITER=1000 -DTHREADS=64
*/

#include 
#include 
#include 
#include 

#ifndef ITER
# define ITER 1000
#endif
#ifndef THREADS
# define THREADS 3
#endif

#if THREADS < 1
# error "THREADS is supposed to be at least 1"
#endif

static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
static int shared_ptr = 0;

typedef struct stats_s {
  uint64_t min, max;
  int times;
  uint64_t total;
  uint64_t flips;
} stats_t;

stats_t stats[THREADS + 1];
pthread_t threads[THREADS];

#ifdef __aarch64__
static uint64_t cpu_shift() {
  uint64_t shift = 0;
  __asm__ __volatile__ ("mrs %0,cntfrq_el0; clz %w0, %w0":"="(shift));
  return shift;
}
#endif

static uint64_t gettime() {
#ifdef __aarch64__
  uint64_t ret = 0;
  __asm__ __volatile__ ("isb; mrs %0,cntvct_el0":"=r"(ret));
  return ret << cpu_shift();

#elif defined __x86_64__
  uint64_t a, d;
  __asm__ __volatile__ ("rdtsc" : "=a" (a), "=d" (d));
  return ((uint64_t)a + ((uint64_t)d << 32));
#endif

  return 0;
}

static void init_stats() {
  int i;
  for (i = 0; i <= THREADS; i++) {
stats_t *s = [i];
s->min = 100;
s->max = 0;
s->times = 0;
s->total = 0;
s->flips = 0;
  }
}

static void print_stat(int i) {
  stats_t *s = [i];
  float average = (float) s->total / s->times;
  if (i == THREADS)
fprintf(stdout, "server: min=%ld, max=%ld, average=%f, mutexes_locked=%d, flips=%ld\n", s->min, s->max, average, s->times, s->flips);
  else
fprintf(stdout, "thread %d: min=%ld, max=%ld, average=%f, mutexes_locked=%d, flips=%ld\n", i, s->min, s->max, average, s->times, s->flips);
}

static void print_stats() {
  int i;
  for (i = 0; i <= THREADS; i++)
print_stat(i);
}

static void update_stats(stats_t *s, uint64_t time) {
  ++s->times;
  if (time < s->min)
s->min = time;
  if (time > s->max)
s->max = time;
  s->total += time;
}

static void fun(int check, int set, stats_t *stat) {
  int loop = 1;
  while (loop) {
uint64_t start = gettime();
pthread_mutex_lock ();
if (shared_ptr

Bug#955005: Seconded.

2020-04-10 Thread Scott Kitterman

Looks good.

Scott K

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

Bug#956417: ITP: parasail: Pairwise Sequence Alignment Library

2020-04-10 Thread Nilesh Patra

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


* Package name: parasail
  Version : 2.4.1
  Upstream Author : Jeff Daily
* URL : https://github.com/jeffdaily/parasail

* License : BSD-Style
  Programming Lang: C, C++
  Description : Pairwise Sequence Alignment Library

 Parasail is a SIMD C (C99) library containing implementations of
 the Smith-Waterman, Needleman-Wunsch, and various semi-global
 pairwise sequence alignment algorithms. Parasail implements most
 known algorithms for vectorized pairwise sequence alignment,
 including diagonal, blocked, striped, and prefix scan.

I take the responsibility to maintain this package.

Bug#956288: Problems identified in debian/copyright

2020-04-10 Thread Thomas Lange

Hi Michael,

thanks for your proposal. I've patched the copyright file and uploaded
a new version.

I left this part unchanged, since it's a different license
which is different to the license for Files: *

Files: install/dracut-install.c
Copyright:
 (C) 2012 Harald Hoyer
 (C) 2012 Red Hat, Inc.  All rights reserved.
License: LGPL-2.1+

-- 
regards Thomas

Bug#955005: Its fine

2020-04-10 Thread Joerg Jaspert


Hi

its fine, go for it.

--
bye, Joerg


signature.asc
Description: PGP signature

Bug#956416: RFS: sipxtapi/3.3.0~test17-3.1 [NMU, RC] -- SIP stack, RTP media framework and codecs

2020-04-10 Thread Sudip Mukherjee

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: sipxtapi
   Version : 3.3.0~test17-3.1
   Upstream Author : sipXtapi community 
 * URL : http://www.sipxtapi.org
 * License : LGPL-2.1
 * Vcs : https://anonscm.debian.org/cgit/pkg-voip/sipxtapi.git
   Section : libs

It builds those binary packages:

  libsipxtapi - SIP stack, RTP media framework and codecs
  libsipxtapi-dev - SIP stack, RTP media framework and codecs (headers)
  libsipxtapi-doc - SIP stack, RTP media framework and codecs (API 
documentation)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test17-3.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix FTBFS. (Closes: #954547)


-- 
Regards
Sudip

Bug#954547: sipxtapi: diff for NMU version 3.3.0~test17-3.1

2020-04-10 Thread Sudip Mukherjee

Control: tags 954547 + patch
Control: tags 954547 + pending

Dear maintainer,

I've prepared an NMU for sipxtapi (versioned as 3.3.0~test17-3.1) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it.

--
Regards
Sudip

diff -Nru sipxtapi-3.3.0~test17/debian/changelog 
sipxtapi-3.3.0~test17/debian/changelog
--- sipxtapi-3.3.0~test17/debian/changelog  2018-04-13 21:49:44.0 
+0100
+++ sipxtapi-3.3.0~test17/debian/changelog  2020-04-10 20:32:50.0 
+0100
@@ -1,3 +1,10 @@
+sipxtapi (3.3.0~test17-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS. (Closes: #954547) 
+
+ -- Sudip Mukherjee   Fri, 10 Apr 2020 20:32:50 
+0100
+
 sipxtapi (3.3.0~test17-3) unstable; urgency=high
 
   [ Rene Engelhard ]
diff -Nru sipxtapi-3.3.0~test17/debian/patches/fix_gettid.patch 
sipxtapi-3.3.0~test17/debian/patches/fix_gettid.patch
--- sipxtapi-3.3.0~test17/debian/patches/fix_gettid.patch   1970-01-01 
01:00:00.0 +0100
+++ sipxtapi-3.3.0~test17/debian/patches/fix_gettid.patch   2020-04-10 
20:32:47.0 +0100
@@ -0,0 +1,39 @@
+Description: Fix FTBFS
+ Latest glibc has defined gettid() and as a result there was a conflict.
+ Rename gettid() to sys_gettid() to use our own gettid instead of using
+ the gettid() from glibc.
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/954547
+
+---
+
+--- sipxtapi-3.3.0~test17.orig/sipXportLib/src/os/linux/OsTaskLinux.cpp
 sipxtapi-3.3.0~test17/sipXportLib/src/os/linux/OsTaskLinux.cpp
+@@ -27,7 +27,7 @@
+ #include 
+ #undef _P1003_1B_VISIBLE
+ 
+-// Include to access gettid() syscall for debug purposes
++// Include to access sys_gettid() syscall for debug purposes
+ #include 
+ 
+ // APPLICATION INCLUDES
+@@ -49,7 +49,7 @@
+ 
+ // EXTERNAL FUNCTIONS
+ #ifndef ANDROID // [
+-static inline int gettid() {return syscall(SYS_gettid);}
++static inline int sys_gettid() {return syscall(SYS_gettid);}
+ #endif // !ANDROID ]
+ 
+ // EXTERNAL VARIABLES
+@@ -783,7 +783,7 @@ void * OsTaskLinux::taskEntry(void* arg)
+ 
+// Log Thread ID for debug purposes
+OsSysLog::add(FAC_KERNEL, PRI_DEBUG, "OsTaskLinux::taskEntry: Started task 
%s with lwp=%d, pid=%d",
+- pTask->mName.data(), gettid(), getpid());
++ pTask->mName.data(), sys_gettid(), getpid());
+ 
+ #ifdef ANDROID // [
+pTask->setPriority(pTask->mPriority);
diff -Nru sipxtapi-3.3.0~test17/debian/patches/series 
sipxtapi-3.3.0~test17/debian/patches/series
--- sipxtapi-3.3.0~test17/debian/patches/series 2018-04-13 21:49:44.0 
+0100
+++ sipxtapi-3.3.0~test17/debian/patches/series 2020-04-10 20:31:11.0 
+0100
@@ -2,3 +2,4 @@
 openssl11.patch
 cppunit.patch
 add-license-rfc-4634.patch
+fix_gettid.patch

Bug#956402: plans for uploading a newer icu to unstable

2020-04-10 Thread Xavier

Le 10/04/2020 à 20:48, Pirate Praveen a écrit :
> 
> 
> On Fri, Apr 10, 2020 at 8:38 pm, László Böszörményi (GCS)
>  wrote:
>> On Fri, Apr 10, 2020 at 7:27 PM Pirate Praveen
>>  wrote:
>>>  nodejs 12 transition is blocked by libicu-dev >= 64.0~ and gitlab no
>>>  longer works with nodejs 10 (when memory usage in webpack goes above
>>>  2GB it crashes, see #956211).
>>>
>>>  It'd be really helpful if you can upload a newer version to unstable to
>>>  allow nodejs 12 in unstable.
>>  Is ICU update the last step to have NodeJS 12 in unstable?

Hi,

yes it seems to be the last step

Cheers,
Xavier

Bug#956211: [Pkg-javascript-devel] Bug#956211: Bug#956211: [Re: nodejs 10 segfaults when running webpack on gitlab 12.9.2]

Le ven. 10 avr. 2020 à 21:15, Pirate Praveen  a
écrit :

> Control: reassign -1 gitlab
> Control: tags -1 -wontfix
>
> On Sat, Apr 11, 2020 at 12:32 am, Pirate Praveen
>  wrote:
> >
> >
> > On Fri, Apr 10, 2020 at 8:58 pm, Jérémy Lal 
> > wrote:
> >>
> >>
> >> Le ven. 10 avr. 2020 à 20:50, Pirate Praveen
> >>   a écrit :
> >>>
> >>>
> >>>  On Fri, Apr 10, 2020 at 7:35 pm, Jérémy Lal 
> >>>   wrote:
> >>>  > Package: nodejs
> >>>  > Version: 10.19.0~dfsg-3
> >>>  > Followup-For: Bug #956211
> >>>  >
> >>>  > Pirate, i repeat, please try
> >>>  >
> >>>  > webpack --max-old-space-size=4096
> >>>  >
> >>>  > Or even a higher value. If it works, it's up to gitlab to use
> >>> that
> >>>  > flag.
> >>>  >
> >>>
> >>>  root@gitlab-buster:/usr/share/gitlab# runuser -u ${gitlab_user} --
> >>> sh
> >>>  -c 'webpack --max-old-space-size=8192 --config
> >>>   config/webpack.config.js'
> >>>
> >>>  I tried 4096, 6144, 8192, 16384 and all failed. How much higher
> >>>   should
> >>>  I go?
> >>
> >> Not further :)
> >> However then maybe that flag has no effect.
> >> Another way to pass the flag is by setting the environment variable:
> >> NODE_OPTIONS="–max-old-space-size=2048"
> >> Then again, runuser need to be told to handle this correctly.
> >>
> >
> > I will try this, probably tomorrow.
> >
>
> runuser -u ${gitlab_user} -- sh -c
> 'NODE_OPTIONS="--max-old-space-size=2048" webpack
> --max-old-space-size=16384 --config config/webpack.config.js'
>
> This worked. Thanks a lot.
>

Nice. My bad for having "googled" the answer.
Of course you need to remove the useless --max-old-space-size in your line.
 'NODE_OPTIONS="--max-old-space-size=2048" webpack
 --config config/webpack.config.js

but i bet you already noticed that.

>>>
> >>>  > Nodejs applications using high memory must use that kind of
> >>>  > workaround.
> >>>
> >>>  I was also exploring if excluding system libraries from
> >>> babel-loader
> >>>  reduces memory footprint.
> >>
> >> Yep, i saw that.
> >> Can you give me a quick way to reproduce the OOM error ?
> >>
> > If you are okay setting up gitlab from experimental on an lxc or vm
> > then instructions are here https://wiki.debian.org/gitlab
> >
> > Else I can set it up on a test VPS and give you access, possibly
> > tomorrow.
>

Well, if it worked, i won't bother and you shouldn't either.
Anyway i'm cool with following the wiki.

Jérémy

Bug#956415: clickhouse-server: OOM due to memory leak with default configuration

2020-04-10 Thread Federico Ceratto

Package: clickhouse-server
Version: 18.16.1+ds-4
Severity: important

The current version of ClickHouse in Buster [1] with default
configuration often triggers OOM errors and is terminated.

[1] https://packages.debian.org/buster/clickhouse-server

Upstream bug report:

https://github.com/ClickHouse/ClickHouse/issues/9945

Bug#871563: Downgrading severity of manpages-fr-extra bug

2020-04-10 Thread Dr. Tobias Quathamer

control: severity -1 important

Hi,

I'm downgrading this bug to allow the NMU of manpages-fr-extra to
migrate to testing. The latest upload replaces the previous package with
a transitional dummy package which depends on manpages-fr and
manpages-fr-dev.

Those packages are now generated from the source package manpages-l10n,
which provides up-to-date translations for the French manpages.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#956211: [Pkg-javascript-devel] Bug#956211: Bug#956211: [Re: nodejs 10 segfaults when running webpack on gitlab 12.9.2]

Control: reassign -1 gitlab
Control: tags -1 -wontfix

On Sat, Apr 11, 2020 at 12:32 am, Pirate Praveen 
 wrote:

On Fri, Apr 10, 2020 at 8:58 pm, Jérémy Lal  
wrote:

Le ven. 10 avr. 2020 à 20:50, Pirate Praveen 
 a écrit :

 On Fri, Apr 10, 2020 at 7:35 pm, Jérémy Lal  
wrote:

 > Package: nodejs
 > Version: 10.19.0~dfsg-3
 > Followup-For: Bug #956211
 >
 > Pirate, i repeat, please try
 >
 > webpack --max-old-space-size=4096
 >
 > Or even a higher value. If it works, it's up to gitlab to use 
that

 > flag.
 >

 root@gitlab-buster:/usr/share/gitlab# runuser -u ${gitlab_user} --
sh
 -c 'webpack --max-old-space-size=8192 --config 
config/webpack.config.js'

 I tried 4096, 6144, 8192, 16384 and all failed. How much higher 
should

 I go?

Not further :)
However then maybe that flag has no effect.
Another way to pass the flag is by setting the environment variable:
NODE_OPTIONS="–max-old-space-size=2048"
Then again, runuser need to be told to handle this correctly.

I will try this, probably tomorrow.

runuser -u ${gitlab_user} -- sh -c 
'NODE_OPTIONS="--max-old-space-size=2048" webpack 
--max-old-space-size=16384 --config config/webpack.config.js'

This worked. Thanks a lot.

 > Nodejs applications using high memory must use that kind of
 > workaround.

 I was also exploring if excluding system libraries from 
babel-loader

 reduces memory footprint.

Yep, i saw that.
Can you give me a quick way to reproduce the OOM error ?

If you are okay setting up gitlab from experimental on an lxc or vm 
then instructions are here https://wiki.debian.org/gitlab

Else I can set it up on a test VPS and give you access, possibly 
tomorrow.

Jérémy

--
Pkg-javascript-devel mailing list
pkg-javascript-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#956414: RFS: eudev/3.2.9-7+debian1: [ITP] /dev/ and hotplug management daemon

2020-04-10 Thread Svante Signell

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: eudev
   Version : 3.2.9-7+debian1
   Upstream Author : NA
 * URL : https://gitweb.gentoo.org/proj/eudev.git
 * License : GPL-2+
 * Vcs : 
   Section : admin

It builds those binary packages:

  eudev- /dev/ and hotplug management daemon
  libeudev1- libeudev shared library
  libeudev-dev - libeudev development files
  eudev-udeb   - libeudev shared library (minimal version)

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

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

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

  dget -x   
https://mentors.debian.net/debian/pool/main/e/eudev/eudev_3.2.9-7+debian1.dsc

Changes since the last upload:
  * Initial Debian Release (closes: #765971)

Thanks!

Bug#956211: [Pkg-javascript-devel] Bug#956211: [Re: nodejs 10 segfaults when running webpack on gitlab 12.9.2]

On Fri, Apr 10, 2020 at 8:58 pm, Jérémy Lal  wrote:

Le ven. 10 avr. 2020 à 20:50, Pirate Praveen 
 a écrit :

 On Fri, Apr 10, 2020 at 7:35 pm, Jérémy Lal  
wrote:

 > Package: nodejs
 > Version: 10.19.0~dfsg-3
 > Followup-For: Bug #956211
 >
 > Pirate, i repeat, please try
 >
 > webpack --max-old-space-size=4096
 >
 > Or even a higher value. If it works, it's up to gitlab to use that
 > flag.
 >

 root@gitlab-buster:/usr/share/gitlab# runuser -u ${gitlab_user} -- 
sh
 -c 'webpack --max-old-space-size=8192 --config 
config/webpack.config.js'

 I tried 4096, 6144, 8192, 16384 and all failed. How much higher 
should

 I go?

Not further :)
However then maybe that flag has no effect.
Another way to pass the flag is by setting the environment variable:
NODE_OPTIONS="–max-old-space-size=2048"
Then again, runuser need to be told to handle this correctly.

I will try this, probably tomorrow.

 > Nodejs applications using high memory must use that kind of
 > workaround.

 I was also exploring if excluding system libraries from babel-loader
 reduces memory footprint.

Yep, i saw that.
Can you give me a quick way to reproduce the OOM error ?

If you are okay setting up gitlab from experimental on an lxc or vm 
then instructions are here https://wiki.debian.org/gitlab

Else I can set it up on a test VPS and give you access, possibly 
tomorrow.

Jérémy

Bug#956211: [Pkg-javascript-devel] Bug#956211: [Re: nodejs 10 segfaults when running webpack on gitlab 12.9.2]

Le ven. 10 avr. 2020 à 20:50, Pirate Praveen  a
écrit :

>
>
> On Fri, Apr 10, 2020 at 7:35 pm, Jérémy Lal  wrote:
> > Package: nodejs
> > Version: 10.19.0~dfsg-3
> > Followup-For: Bug #956211
> >
> > Pirate, i repeat, please try
> >
> > webpack --max-old-space-size=4096
> >
> > Or even a higher value. If it works, it's up to gitlab to use that
> > flag.
> >
>
> root@gitlab-buster:/usr/share/gitlab# runuser -u ${gitlab_user} -- sh
> -c 'webpack --max-old-space-size=8192 --config config/webpack.config.js'
>
> I tried 4096, 6144, 8192, 16384 and all failed. How much higher should
> I go?
>

Not further :)
However then maybe that flag has no effect.
Another way to pass the flag is by setting the environment variable:
NODE_OPTIONS="–max-old-space-size=2048"
Then again, runuser need to be told to handle this correctly.


>
> > Nodejs applications using high memory must use that kind of
> > workaround.
>
> I was also exploring if excluding system libraries from babel-loader
> reduces memory footprint.


Yep, i saw that.
Can you give me a quick way to reproduce the OOM error ?

Jérémy

Bug#923464: carbon-cache unusable in Buster

2020-04-10 Thread Maximilian Engelhardt

severity 923464 important
thanks

Hi,

we also ran into this bug and I can confirm the attached patch by Mark fixed 
the issue for us.
This should definitely be fixed in unstable/testing and then also in buster.

I set the severity to important as the repeated crashes of carbon-cache caused 
regular metric data loss on our server as well as oom situations (where was 
not clear what was happening in the beginning) and fast filling up of /var/log 
due to excessive traceback logging.

Thanks,
Maxi

On Sat, 11 Jan 2020 12:05:17 + Mark Hymers  wrote:
> On Thu, 07, Nov, 2019 at 10:57:23AM +0100, Morten Brekkevold spoke thus..
> > The carbon-cache package in Debian Buster is definitely BROKEN - it just
> > keeps crashing.
> 
> Hi,
> 
> We've been running with the attached patch since December which fixes
> the problem.
> 
> Thorsten (as you're the last uploader) - I'm happy to prepare a stable
> update to fix this, but the version is the same in stable/testing so
> can't do so currently.  There are two point release (1.1.5 and 1.1.6)
> for this package but they seem to be tied into other graphite-* package
> updates too.  Would you accept an NMU to unstable with just this patch
> and then an accompanying stable update?  This problem basically makes
> graphite-carbon unusable in buster.
> 
> Thanks.
> 
> Mark
> 
> -- 
> Mark Hymers 

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

Bug#956338: autopkgtest: please remove pyflakes (not pyflakes3)

Hi Sandro,

On 10-04-2020 20:50, Sandro Tosi wrote:
> great! any chance to release that soon? 5.12.1 already reached testing -- 
> thanks

There's something that I'm working on and want to release soon, so yes.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#956338: autopkgtest: please remove pyflakes (not pyflakes3)

On Fri, Apr 10, 2020 at 1:54 PM Paul Gevers  wrote:
>
> Control: tags -1 pending
>
> Hi Sandro,
>
> On 10-04-2020 07:24, Sandro Tosi wrote:
> > as part of the py2removal effort, i noticed autopkgtest still uses (at 
> > least it
> > refers to it as a dependencies) `pyflakes` (not to be confused with
> > `pyflakes3`).
> >
> > Can you please remove such dependencies?
>
> Already requested and merged 3 days ago here:
> https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/77

great! any chance to release that soon? 5.12.1 already reached testing -- thanks

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#956413: rustc: Please drop workaround to disable incremental builds on sparc64

2020-04-10 Thread John Paul Adrian Glaubitz

Source: rustc
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

I just noticed that debian/rules still contains the following workaround
for sparc64:

ifneq (,$(filter $(DEB_BUILD_ARCH), sparc64))
export CARGO_INCREMENTAL = 0
endif

This workaround is no longer necessary as the underlying bug was fixed
upstream, please remove it.

Thanks,
Adrian

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

Bug#956152: closed by Thomas Goirand (Re: Processed: rabbitmq-server: fails to install reliably on arm64)

Control: reopen -1

Hi Zigo,

We may end up that we conclude that there's something wrong in the
ci.debian.net environments, but I don't appreciate the speed and ease
where you close this bug. Downgrading fine, but closing within a day
after I answered your previous question sounds a bit quick on Debian
timescales.

That said, on the ci.debian.net infrastructure, we're not doing anything
weird. We bootstrap lxc containers and we install packages into it.
Maybe Antonio can chime in to add any oddities but I am not aware of
any, so I think my claim of it being unreliable still holds, with 7/10
mcollective reference tests in testing failing solely due to this [1].

What kind of information do you need to be able to help fix this issue
in our quite normal environments? I can try to cook up is a empty test
that doesn't do anything more than install rabbitmq-server and see if I
can get it to fail on one of our workers while I am watching. What kind
of logging would you need than? What kind of state info?

Paul

PS: the "Not creating home directory `/var/lib/rabbitmq'." error is also
present in the successful runs, so as Michal Arbet already said, that
can't explain the failure.

[1] https://ci.debian.net/packages/m/mcollective/testing/arm64/



signature.asc
Description: OpenPGP digital signature

Bug#956412: pypy3: /usr/local/lib/pypy3.6/dist-packages/ not on sys.path

2020-04-10 Thread Stefano Rivera

Package: pypy3
Version: 7.3.0+dfsg-4
Severity: normal

sys.path isn't setup correctly for pypy3 to use locally installed
modules. I don't think it ever has been, I just keep forgetting about
it.

Virtualenvs work, of course.

SR

Bug#956211: [Pkg-javascript-devel] Bug#956211: [Re: nodejs 10 segfaults when running webpack on gitlab 12.9.2]





On Fri, Apr 10, 2020 at 7:35 pm, Jérémy Lal  wrote:

Package: nodejs
Version: 10.19.0~dfsg-3
Followup-For: Bug #956211

Pirate, i repeat, please try

webpack --max-old-space-size=4096

Or even a higher value. If it works, it's up to gitlab to use that 
flag.




root@gitlab-buster:/usr/share/gitlab# runuser -u ${gitlab_user} -- sh 
-c 'webpack --max-old-space-size=8192 --config config/webpack.config.js'


I tried 4096, 6144, 8192, 16384 and all failed. How much higher should 
I go?


Nodejs applications using high memory must use that kind of 
workaround.


I was also exploring if excluding system libraries from babel-loader 
reduces memory footprint.

Bug#956402: plans for uploading a newer icu to unstable

On Fri, Apr 10, 2020 at 8:38 pm, László Böszörményi (GCS)
wrote:
On Fri, Apr 10, 2020 at 7:27 PM Pirate Praveen
wrote:

nodejs 12 transition is blocked by libicu-dev >= 64.0~ and gitlab no
longer works with nodejs 10 (when memory usage in webpack goes above
2GB it crashes, see #956211).

It'd be really helpful if you can upload a newer version to
unstable to

allow nodejs 12 in unstable.

Is ICU update the last step to have NodeJS 12 in unstable?

Copying Jeremy (nodejs maintainer) and Xavier (who fixed most of the
nodejs 12 issues).

This was the page used to track the transition ->
https://salsa.debian.org/js-team/nodejs/-/wikis/Transition-to-Nodejs-12-for-Debian-Unstable
and Jeremy mentioned icu as blocker in his last mail to js team list ->
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-April/041014.html

NB: gitlab is in experimental currently as it needs rails 6, but I
hope

to be able to upload it to unstable when rails 6 transition starts
right after ruby 2.7 transition completes.

Any expected date for this?

We will decide it after ruby 2.7 transition is complete, which has
still some regressions to be fixed ->
https://tracker.debian.org/pkg/ruby-defaults

Possibly 3-4 weeks from now.

ICU 67.1 is RC only at the moment (but packaged and builds in
experimental). Probably the stable version of it will be released this
month. I'm going to test other packages for the ICU transition then.

Thanks! I'm also trying to make gitlab work with nodejs 10.

Regards,
Laszlo/GCS

Bug#956402: plans for uploading a newer icu to unstable

2020-04-10 Thread GCS

On Fri, Apr 10, 2020 at 7:27 PM Pirate Praveen  wrote:
> nodejs 12 transition is blocked by libicu-dev >= 64.0~ and gitlab no
> longer works with nodejs 10 (when memory usage in webpack goes above
> 2GB it crashes, see #956211).
>
> It'd be really helpful if you can upload a newer version to unstable to
> allow nodejs 12 in unstable.
 Is ICU update the last step to have NodeJS 12 in unstable?

> NB: gitlab is in experimental currently as it needs rails 6, but I hope
> to be able to upload it to unstable when rails 6 transition starts
> right after ruby 2.7 transition completes.
 Any expected date for this?

ICU 67.1 is RC only at the moment (but packaged and builds in
experimental). Probably the stable version of it will be released this
month. I'm going to test other packages for the ICU transition then.

Regards,
Laszlo/GCS

Bug#956411: ca-certificates: please update to latest Mozilla bundle

2020-04-10 Thread Andrew Ayer

Package: ca-certificates
Version: 20190110
Severity: normal

Hi Michael,

ca-certificates currently contains several CAs that have been distrusted
by Mozilla:

Certplus
Certinomis
Deutsche Telekom AG

Certinomis is particularly concerning because they were distrusted after
numerous misissuances and other compliance problems undermined trust in
their CA: https://wiki.mozilla.org/CA/Certinomis_Issues

I see that the Git repo has already been updated.  Could a new package be
uploaded?

Thanks,
Andrew

Bug#956409: kwartz-client: German translation of the debconf messages

2020-04-10 Thread Markus Hiereth

Package: kwartz-client
Version: 1.4-6
Severity: normal

Dear Georges,

attached the po file with the german translations

Best regards
Markus
# German message catalogue for Configuring the kwartz package on Debian systems
# Copyright (C) 2019 Georges Khaznadar
# This file is distributed under the same license as the kwartz-client package.
# Markus Hiereth , 2019, 2020.
msgid ""
msgstr ""
"Project-Id-Version: kwartz-client 1.4-6\n"
"Report-Msgid-Bugs-To: kwartz-cli...@packages.debian.org\n"
"POT-Creation-Date: 2020-04-08 16:46+\n"
"PO-Revision-Date: 2020-04-08 21:36+0200\n"
"Last-Translator: Markus Hiereth \n"
"Language-Team: debian-l10n-german \n"
"Language: de\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"
"X-Generator: Virtaal 0.7.1\n"

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid "URI (\"Uniform Resource Identifier\") of the LDAP server:"
msgstr "URI (»Uniform Resource Identifier«) des LDAP-Servers:"

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid ""
"Please enter the URI of the LDAP server provided by your Kwartz machine. You "
"can use a numeric IP address rather than a symbolic one, in order to "
"minimize failure possibilities when the name service is down."
msgstr ""
"Bitte geben Sie den URI des durch Ihre Kwartz-Maschine bereitgestellten LDAP-"
"Servers an. Nutzen Sie vorzugsweise die numerische IP-Adresse, damit es "
"nicht zu einem Ausfall kommt, wenn der Namensserver nicht verfügbar ist."

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid "It is possible to specify multiple LDAP URIS, separated by spaces."
msgstr "Sie können mehrere, durch Leerzeichen getrennte LDAP-URIs angeben."

#. Type: string
#. Description
#: ../kwartz-client.templates:2001
msgid "LDAP's Base DN (\"Distinguished Name\"):"
msgstr "Der Basis-DN (»Distinguished Name«) für LDAP:"

#. Type: string
#. Description
#: ../kwartz-client.templates:2001
msgid ""
"Please enter the DN (\"Distinguished Name\") used as the base of the LDAP "
"service. Many systems use the elements of their domain name for this "
"purpose. For example, the domain \"example.net\" would use \"dc=example, "
"dc=net\"."
msgstr ""
"Geben Sie bitte den DN (»Distinguished Name«, den »hervorgehobenen Namen«) "
"ein, der als Basis für den LDAP-Dienst benutzt wird. Zu diesem Zweck greifen "
"viele Systeme auf Elemente des Domain-Namens zurück; für die Domain "
"»example.net« zum Beispiel »dc=example, dc=net«."

#. Type: string
#. Description
#: ../kwartz-client.templates:3001
msgid "DN (\"Distinguished Name\") of one user:"
msgstr "Der DN (»Distinguished Name«) für einen Benutzer:"

#. Type: string
#. Description
#: ../kwartz-client.templates:3001
msgid ""
"Please enter the DN (\"Distinguished Name\") of one unprivileged user "
"already existing in the LDAP directory. Kwartz requires that requests come "
"from an existing user before replying anything."
msgstr ""
"Bitte geben Sie den DN (»Distinguished Name«) eines im LDAP-Verzeichnis "
"schon existierenden und nicht privilegierten Benutzers ein. Um zu antworten, "
"ist Kwartz darauf angewiesen, dass die Anfrage von einem existierenden "
"Benutzer kommt."

#. Type: password
#. Description
#: ../kwartz-client.templates:4001
msgid "Password of the unprivileged user:"
msgstr "Passwort des nicht privilegierten Benutzers:"

#. Type: password
#. Description
#: ../kwartz-client.templates:4001
msgid ""
"Please enter the password of the unprivileged user. Kwartz requires that "
"requests come from an existing user before replying anything. This password "
"should not be disclosed, and should be fairly strong."
msgstr ""
"Bitte geben Sie das Passwort des nicht privilegierten Benutzers ein. Um zu "
"antworten, ist Kwartz darauf angewiesen, dass die Anfrage von einem "
"existierenden Benutzer kommt. Das Passwort sollte nicht offengelegt und "
"schwer zu ermitteln sein."

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "The Samba name of the kwartz server:"
msgstr "Der Samba-Name des Kwartz-Servers:"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid ""
"Please enter the Samba name of the kwartz server; this is the name of the "
"server, as seen in Windows' neighborhood."
msgstr ""
"Bitte geben Sie den Samba-Namen des Kwartz-Servers ein. Dies ist der Name "
"des Servers, wie er von der Windows-Umgebung aus gesehen wird."

#. Type: string
#. Description
#: ../kwartz-client.templates:6001
msgid "The IP address of the Cloud service, if any:"
msgstr "Die IP-Adresse des Cloud-Dienstes, falls existierend:"

#. Type: string
#. Description
#: ../kwartz-client.templates:6001
msgid ""
"Please enter the IP address of the Cloud server. It may be the address of "
"the main server, as seen from the Internet (not the address in the local "
"network). If there is no such service, you can safely keep the default."

Bug#956410: ITP: node-prosemirror-transform -- ProseMirror Markdown integration

2020-04-10 Thread Sakshi Sangwan

Package: prosemirror-transform
Severity: wishlist
Owner: Sakshi Sangwan 

* Package name: node-prosemirror-transform
  Version : 1.2.4
  Upstream Author : Marijn Haverbeke and others
* URL :
https://github.com/prosemirror/prosemirror-transform#readme

* License : Expat
  Programming Lang: JavaScript
  Description : ProseMirror Markdown integration

 This is a core module of ProseMirror. ProseMirror is a well-behaved rich
 semantic content editor based on contentEditable, with support for
 collaborative editing and custom document schemas. This module implements
 document transforms, which are used by the editor to treat changes as
 first-class values, which can be saved, shared, and reasoned about.
 .
 Node.js is an event-based server-side JavaScript engine.

This is a dependency of tiptap.

Best,
Sakshi

Bug#956403: sasl2-bin: Log file missing string do_auth

2020-04-10 Thread Jason Naughton

Package: sasl2-bin
Version: 2.1.27+dfsg-1+deb10u1
Severity: important

saslauthd logs to /var/log/auth.log through syslog.  There are a number of 
other programs that are monitoring this log for entries that match a specific 
format, for example logwatch.   There should be lines like:

saslauthd[892]: do_auth : auth failure: [user=foobar] 
[service=smtp] [realm=example.com] [mech=pam] [reason=PAM auth error]

When an unsuccessful login attempt has occured due to an incorrect passowrd.  
Unfortunately it is presently generating:

saslauthd[892]: : auth failure: [user=foobar] 
[service=smtp] [realm=example.com] [mech=pam] [reason=PAM auth error]

The matching string do_auth is missing.  I beleive saslauthd-main.c line 433 
which is:

 logger(L_INFO, L_FUNC, "auth failure: [user=%s] [service=%s] [realm=%s] 
[mech=%s] [reason=%s]", \
login, service, realm, auth_mech->name,
strlen(response) >= 4 ? response+3 : "Unknown");

generates this log entry but L_FUNC must not be set as the logger function 
defined in utils.c line 83:

syslog(priority, "%-16s: %s", function, buffer);

should have do_auth for function but it doesn't.  Looking deeper it seems that 
utils.h attempts to be slick and determine function called by:

/* some magic to grab function names */
#ifdef HAVE_FUNC
# define L_FUNC __func__
# define HAVE_L_FUNC 1
#elif defined(HAVE_PRETTY_FUNCTION)
# define L_FUNC __PRETTY_FUNCTION__
# define HAVE_L_FUNC 1
#elif defined(HAVE_FUNCTION)
# define L_FUNC __FUNCTION__
# define HAVE_L_FUNC 1
#else
# define L_FUNC ""
# undef HAVE_L_FUNC
#endif

So it looks like in debian the package does not define HAVE_FUNC which leads to 
L_FUNC being set to " ".

I downloaded the source from the master and it seems that gcc implements this.  
Compiling on my desktop I get:

checking whether gcc implements __func__... yes

Any chance this package can be compiled with this feature?

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sasl2-bin depends on:
ii  db-util5.3.1+nmu1
ii  debconf [debconf-2.0]  1.5.71
ii  init-system-helpers1.56+nmu1
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libkrb5-3  1.17-3
ii  libldap-2.4-2  2.4.47+dfsg-3+deb10u1
ii  libpam0g   1.3.1-5
ii  libsasl2-2 2.1.27+dfsg-1+deb10u1
ii  libssl1.1  1.1.1d-0+deb10u2
ii  lsb-base   10.2019051400

sasl2-bin recommends no packages.

sasl2-bin suggests no packages.

-- Configuration Files:
/etc/default/saslauthd changed:
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="pam"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/run/saslauthd"


-- debconf information:
  cyrus-sasl2/upgrade-sasldb2-failed:
  cyrus-sasl2/upgrade-sasldb2-backup-failed:
  cyrus-sasl2/purge-sasldb2: false
  cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak

Bug#956408: minetest-mod-xdecor: please make the build reproducible

2020-04-10 Thread Chris Lamb

Source: minetest-mod-xdecor
Version: 1.0+dfsg1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
minetest-mod-xdecor could not be built reproducibly.

This is because .ogg streams must include unique serial numbers and,
by default oggenc includes andom serial numbers in the header, which
are seeded by the current time and the pid.

Patch attached that uses the literal value of SOURCE_DATE_EPOCH as
the seed instead.


 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2020-04-10 19:04:55.123562731 +0100
--- b/debian/rules  2020-04-10 19:06:28.432093253 +0100
@@ -4,4 +4,4 @@
dh $@
 
 override_dh_auto_build:
-   oggenc debian/wesnoth_heal.wav -o sounds/xdecor_enchanting.ogg
+   oggenc debian/wesnoth_heal.wav -o sounds/xdecor_enchanting.ogg -s 
$(SOURCE_DATE_EPOCH)

Bug#956404: ITP: folium -- Make beautiful maps with Leaflet.js & Python

2020-04-10 Thread Javier Ruano

Package: wnpp
Severity: normal
Owner: Javier Ruano 

* Package name: folium
  Version : 0.10.1
  Upstream Author : Rob Story 
* URL : https://github.com/python-visualization/folium
* License : MIT
  Programming Lang: Python, Javascript
  Description : Make beautiful maps with Leaflet.js & Python

folium builds on the data wrangling strengths of the Python ecosystem
and the mapping strengths of the Leaflet.js library. Manipulate your
data in Python, then visualize it in a Leaflet map via folium.

It is very useful for django programmers, and Physics and social sciences.
It is compatible with geopandas, which is in debian repository.
I consider to maintain that with python-team and with pollo as sponsor.

Bug#954902: libgl1-mesa-dri: file iris_drv_video.so is missing

2020-04-10 Thread Patrice Duroux

Hi,

On my system I have done this test and the trouble does not happen with Wayland,
see my report and last comment in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955585
I think those two bugs are the same (#954902 and #955585).

See also reports here:
https://github.com/intel/libva/issues/357
https://github.com/intel/libva/issues/396

But is this an issue in libva? in mesa/libdrm?

Thanks,
Patrice

On Sat, 28 Mar 2020 16:35:16 +1300 Jean-Francois Pirus 
wrote:
> 
> Sorry, I'm not quite sure what to check.
> 
> Thanks.
> 
> 
> On Thu, 2020-03-26 at 13:35 +0200, Timo Aaltonen wrote:
> > On 25.3.2020 12.21, Timo Aaltonen wrote:
> > > On 25.3.2020 5.45, Jean-Francois Pirus wrote:
> > > > Sorry, I ran reportbug on another machine.
> > > 
> > > You most likely don't want to use the old vaapi driver, but
> > > intel-media-va-driver...
> > > 
> > > This is not a bug for mesa but maybe libva or intel-vaapi-driver.
> > 
> > This shouldn't happen on a wayland session, could you check?
> > 
> > Apparently there's a gap between wayland and xorg, the mapping on
> > xorg
> > should be done on xserver..
> 
> 
>

Bug#956405: ruby-enumerable-statistics: FTBFS on amd64/unstable: find: [..] No such file or directory

2020-04-10 Thread Chris Lamb

Source: ruby-enumerable-statistics
Version: 2.0.1+dfsg-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Tags: fbtfs

Dear Maintainer,

ruby-enumerable-statistics fails to build from source in unstable/amd64:

  […]

 dh_compress -X.rb -O--buildsystem=ruby
 debian/rules override_dh_fixperms
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20200410190019.WRLDvzI39v.ags.ruby-enumerable-statistics/ruby-enumerable-statistics-2.0.1+dfsg'
  dh_fixperms
  find 
debian/ruby-enumerable-statistics/usr/lib/*/rubygems-integration/*/gems/enumerable-statistics-*/yard/templates/
 -type f |xargs chmod -x
  find: 
'debian/ruby-enumerable-statistics/usr/lib/*/rubygems-integration/*/gems/enumerable-statistics-*/yard/templates/':
 No such file or directory
  chmod: missing operand
  Try 'chmod --help' for more information.
  make[1]: *** [debian/rules:16: override_dh_fixperms] Error 123
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200410190019.WRLDvzI39v.ags.ruby-enumerable-statistics/ruby-enumerable-statistics-2.0.1+dfsg'
  make: *** [debian/rules:7: binary] Error 2
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

  […]

The full build log is attached.


Regards,

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


ruby-enumerable-statistics.2.0.1+dfsg-2.unstable.amd64.log.txt.gz
Description: Binary data

Bug#956407: wrong NMU detected

2020-04-10 Thread Jörg Frings-Fürst

Package: lintian
Version: 2.62.0
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

with lintian 2.64.0 I get the wrong warnings:

[quote]
W: shotwell source: changelog-should-mention-nmu

W: shotwell source: source-nmu-has-incorrect-version-number 0.30.8-1
[/quote]

The d/changelog:

[quote]
shotwell (0.30.8-1) UNRELEASED; urgency=medium

  * New upstream release.

 -- Jörg Frings-Fürst   Fri, 10 Apr 2020 19:33:38 +0200
[/quote]

And the d/control:

[quote]
Source: shotwell
Section: gnome
Priority: optional
Maintainer: Jörg Frings-Fürst 
[...]
[/quote]

CU
Jörg



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

Kernel: Linux 5.4.0-4-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.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.34-5
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.20-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libcpanel-json-xs-perl   4.19-1
ii  libdevel-size-perl   0.83-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  libjson-maybexs-perl 1.004000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.010001-1
ii  libunicode-utf8-perl 0.62-1+b1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

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

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.58-1

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAl6QtdMACgkQCfifPIyh
0l1opw/9F6GE2EYajuhxIkimsALT7QJ2VOD0AsEh8c5cQGI8HjeFw4by2JB1aNOw
3i6ihsP9UYaInZRvfvVLWjLcWkQmLjKu3mAelVPyU9T/nK7mM+FChDfo5UQ1N2kp
sClFa2kGQtI3nvQw7HllFA25MIud+t6wQ5+wdB7r297hpeeCXoUI/pFE7txGswVy
HwZOngHZK1Cp7CDhnUxQX2Q3g7m7YMBm9/dGb3Nj6azDS0EL40CyVjU+TtTvlJ1l
MJKsGPzVfyMy3os5knxyErw7D6AMs3AooVZpQwezpfFXMSM/H+qqMxKSreyfrzcp
wcvDayn49914cxRMoAXhIGNT7PDhSE22WcyxuwU01ZSGIz9+5zA6F9bkfprfY9LM
YCixmF9JKnVM7QsQUqKC0SYG3dzsADOlAKDj68KfeTU8M9gNw7lKhbdtaVD3PEpj
tdCVH82CoModEJT3kPa+okpGNmiQS/ngexmI53KYjAuiGVODCGJyI1VbAtJpBlwc
0TD9oBZ4p4QmJ3auLm/LRBokRwQVTTTwV9V/s8iCSHIje+goU7+5ZnXPJPoCDIM5
psU2myK7PWQS+Vep8L4OyXzDQn+KqpaOlRQhgvjRKbu40+WpDm8sms0zqCJNqvsb
571Gjx5HLTer3kjNffeFTJ3GG5oiwtqiHD4P+Cd+kzaO9QWRNiM=
=OHkW
-END PGP SIGNATURE-

Bug#956338: autopkgtest: please remove pyflakes (not pyflakes3)

Control: tags -1 pending

Hi Sandro,

On 10-04-2020 07:24, Sandro Tosi wrote:
> as part of the py2removal effort, i noticed autopkgtest still uses (at least 
> it
> refers to it as a dependencies) `pyflakes` (not to be confused with
> `pyflakes3`).
> 
> Can you please remove such dependencies?

Already requested and merged 3 days ago here:
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/77

Paul



signature.asc
Description: OpenPGP digital signature

Bug#956394: u-boot-sunxi: please add support for A64-OLinuXino with eMMC

2020-04-10 Thread Philip Rinn

On 10.04.20 at 19:01, Vagrant Cascadian wrote:
> We need someone to help with testing additional platforms.  Would you be
> willing to regularly test new versions, and be listed as a tester of
> this target?

Sure, I would do that.

Thanks!
Philip



signature.asc
Description: OpenPGP digital signature

Bug#956211: [Pkg-javascript-devel] Bug#956211: nodejs 10 segfaults when running webpack on gitlab 12.9.2 - FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap ou


Control: tag -1 help

On Wed, Apr 8, 2020 at 4:08 pm, Jérémy Lal  wrote:

Tags: wontfix

Le mer. 8 avr. 2020 à 15:48, Pirate Praveen 
 a écrit :

Package: nodejs
 Version: 10.19.0~dfsg-3
 Severity: grave
 Control: notfound -1 12.13.1~dfsg-1


 nodejs 10 crashed (retried again) and on the same machine nodejs 12
 worked.
 This has been working upto gitlab 12.8.8 and the failure appeared 
when
 trying to update to 12.9.2 (just installing gitlab from 
experimental in

 an lxc container).


This is a known issue with nodejs and high memory usage, which happen
to be better with nodejs 12 (but only because gitlab assets 
compilation does

not go way above 2GB usage).

There is no way to fix it in general: you will always find use cases 
that make

nodejs crash as soon as it is using GB of heap memory space.

Any nodejs < 14 version is affected (because who knows, v8 might make 
it
possible for node to fix it in nodejs 14) but not in the same way 
(some fail at 1.4GB,

others at 2GB of heap space usage).

You can try running it with this flag:
webpack --max-old-space-size=4096

Note also that using a high value by default is not a good solution 
either.




Thanks for the answer. It may be possible to reduce memory usage by 
excluding system libraries (in /usr/lib/nodejs, /usr/share/nodejs, 
/usr/share/javascript) during transpiling (babel loader). Can someone 
help me with the correct regex for doing it? All examples on the 
internet shows excluding node_modules only.


Currently it is patched to exclude core-js from babel-loader,

test: /\.js$/,
exclude: [ path =>
  
/node_modules\/(?!tributejs)|node_modules|vendor[\\/]assets/.test(path) 
&

&
  !/\.vue\.js/.test(path),
/\bcore-js\b/,
/\bwebpack\/buildin\b/
],
loader: 'babel-loader',

I tried adding '/usr/share/nodejs' as string, 
path.resolve('/usr/share/nodejs') but it did not seem to work.



Jérémy

Bug#950221: salsa: Please transfer natsort from debian to python-team/modules

2020-04-10 Thread Scott Talbert


On Sat, 14 Mar 2020, Adrian Bunk wrote:


Hi,

please transfer natsort from debian to python-team/modules,
see #950221 for background.


Hello again Salsa admins.  Can you please transfer natsort to 
python-team/modules?


I would like to get natsort fixed ASAP.

Thanks,
Scott

Bug#956211: [Re: nodejs 10 segfaults when running webpack on gitlab 12.9.2]

Package: nodejs
Version: 10.19.0~dfsg-3
Followup-For: Bug #956211

Pirate, i repeat, please try

webpack --max-old-space-size=4096

Or even a higher value. If it works, it's up to gitlab to use that flag.

Nodejs applications using high memory must use that kind of workaround.

Jérémy.

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nodejs depends on:
ii  libc6  2.30-4
ii  libnode64  10.19.0~dfsg-3

Versions of packages nodejs recommends:
ii  ca-certificates  20190110
ii  nodejs-doc   10.19.0~dfsg-3

Versions of packages nodejs suggests:
ii  npm  6.14.4+ds-1

-- no debconf information

Bug#956299: [pkg-go] Bug#956299: update gitaly to 12.9.2





On Fri, Apr 10, 2020 at 5:58 pm, Nilesh  wrote:

Hi,

On Thu, 09 Apr 2020 19:14:59 +0530 Pirate Praveen
 wrote:


 Package: gitaly
 Version: 1.86.0+dfsg1-1
 Severity: important
 Control: block 956218 by -1

 gitaly master branch in salsa was building fine till yesterday. It
 started failing today after golang-google-grpc was updated to 1.27.1
 from 1.22.1

 # gitlab.com/gitlab-org/gitaly/internal/rubyserver/balancer


src/gitlab.com/gitlab-org/gitaly/internal/rubyserver/balancer/balancer.go:123:70:


 undefined: resolver.BuildOption


src/gitlab.com/gitlab-org/gitaly/internal/rubyserver/balancer/balancer.go:220:37:


 undefined: resolver.ResolveNowOption



I have a patch which fixes this. It builds fine for me.
Not sure if this is the best way to solve the problem, but this might
just work for now.
Thanks and regards,
Nilesh




Share the patch here and also send this as a merge request upstream to 
update grpc. Once they review and accept the patch, we can include it.

Bug#950903: ITP: liburing -- Linux kernel io_uring access library

2020-04-10 Thread Guillem Jover

Hi!

On Sat, 2020-02-08 at 01:01:01 +0100, Guillem Jover wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Guillem Jover 
> 
> * Package name: liburing
>   Version : 0.4
>   Upstream Author : Jens Axboe 
> * URL : https://git.kernel.dk/cgit/liburing/
> * License : LGPL and MIT/X
>   Programming Lang: C
>   Description : Linux kernel io_uring access library
> 
>  liburing provides helpers to setup and teardown io_uring instances,
>  and also a simplified interface for applications that don't need (or
>  want) to deal with the full kernel side implementation.
> 
> 
> The liburing library is supposed so supercede the libaio library which
> I maintain too, so it makes sense to handle both. :)

The packaging is ready, but there were some issues that needed fixed
upstream. The blocking one is about getting the licensing situation
clarified:

  

Once that's solved, I'll upload.

Thanks,
Guillem

Bug#956402: plans for uploading a newer icu to unstable