Bug#962644: ITP: ukui-wallpapers -- Wallpapers for UKUI desktop environment

[Kevin Duan]

Package: wnpp
Severity: wishlist
Owner: Kevin Duan 

* Package name: ukui-wallpapers
  Version : 20.04.2
  Upstream Author : handsome_feng 
* URL : https://github.com/ukui/ukui-wallpapers
* License : (GPL)
  Programming Lang: (Python)
  Description : Wallpapers for UKUI desktop environment

 The default UKUI wallpaper. Outstanding wallpapers selected
 from Ubuntu Kylin 20.04 Wallpaper Contest. These wallpapers
 are expected to show wonderful Chinese style.This package is maintained by
Kylin team

Bug#962643: cunit: broken NMU does FTBFS

[Adrian Bunk]

Source: cunit
Version: 2.1-3-dfsg-2.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=cunit=sid

...
Making all in Framework
make[6]: Entering directory 
'/<>/debian/build/CUnit/Sources/Framework'
/bin/bash ../../../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -g -DRELEASE=@RELEASE@ -Wall -W -pedantic 
-Wshadow -ansi -I/<>/debian/build/CUnit/Headers -std=c99  
-Wl,-z,relro -Wl,-z,defs -L/<>/debian/build/CUnit/Sources -o 
libcunitfmk.la  CUError.lo MyMem.lo TestDB.lo TestRun.lo Util.lo  -lc
libtool: link: ar cr .libs/libcunitfmk.a .libs/CUError.o .libs/MyMem.o 
.libs/TestDB.o .libs/TestRun.o .libs/Util.o
ar: .libs/CUError.o: No such file or directory
make[6]: *** [Makefile:397: libcunitfmk.la] Error 1


I can reproduce the problem just by trying to build the package.

The diffstat of this NMU is
 510 files changed, 139791 insertions(+), 3 deletions(-)

It is the responsibility of the sponsor (Cc'ed) to verify that
sponsored uploads are not broken:
https://wiki.debian.org/DebianMentorsFaq#What_is_the_process_for_sponsoring_a_package.3F

Bug#918358: libsane:amd64: Missing permissions for scanner group on usb device

[Chris Nospam]

Dear Maintainer, dear Jörg,

the bug is closed since a couple of weeks. However, there was no patch released 
at least for debian testing. The (lib)sane version is still 1.0.27 and the 
bug(s) still exists.

$ dpkg -l | grep sane
ii  libcommon-sense-perl  3.75-1+b1 
  amd64module that implements some sane defaults for Perl programs
ii  libkf5sane-data   19.08.1-1 
  all  scanner library (data files)
ii  libkf5sane5:amd64 19.08.1-1+b1  
  amd64scanner library (runtime)
ii  libsane:amd64 1.0.27-3.2+b1 
  amd64API library for scanners
ii  libsane:i386  1.0.27-3.2+b1 
  i386 API library for scanners
ii  libsane-common1.0.27-3.2
  all  API library for scanners -- documentation and support files
ii  libsane-hpaio:amd64   3.20.5+dfsg0-3
  amd64HP SANE backend for multi-function peripherals
ii  sane  1.0.14-15 
  amd64scanner graphical frontends
ii  sane-utils1.0.27-3.2+b1 
  amd64API library for scanners -- utilities
ii  xsane 0.999-8   
  amd64featureful graphical frontend for SANE (Scanner Access Now 
Easy)
ii  xsane-common  0.999-8   
  all  xsane architecture independent files

Are there any remaining quirks which are not documented here preventing a patch 
release? If not, please release the new version to testing.

Thanks for maintaining sane,

Chris

Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression

[Qianqian Fang]

On 6/10/20 11:28 PM, Boyuan Yang wrote:

This is because the PGP key you used to sign the source package is not
trusted by default in Debian (which is natural since you are not an
official member of Debian). According to the manual page of dget
(dget(1)), you may use -u/--allow-unauthenticated option when calling
dget to circumvent this problem.



thanks Boyang for chiming in.

I did some search later on, and realized the same.



Uploading to mentors.debian.net is recommended but not compulsory. If
you can prepare a git packging repo following the DEP-14 layout (
https://dep-team.pages.debian.net/deps/dep14), the review can also take
place there.



great to know. I would be appreciated if you can point me to one of
the accepted git repos, it is a lot easier to follow an example regarding
the folder structure and branch names.

also, by using a git, is there a preference using the ones on salsa or
github/gitlab is ok too?



I saw your submission at https://mentors.debian.net/package/zmat .
Before we start the review, I'd suggest to take a look at those
automatic lintian warnings and error messages. They often indicate
important problems with your packaging.

There are several questions listed on mentors.debian.net/package/zmat
and I believe it might be better to send them together with your RFS
email (this is more likely to be read by mentors). For now I will copy
them here and I will answer some of them below:


thanks for pointing out, will do next time (had created a worklist of 6-7
ITPs today, will work on them one after another)



For 1: unfortunately I am not an expert in dealing with Octave. Maybe
someone from the Debian Science Team or Octave Group (
https://wiki.debian.org/Teams/DebianOctaveGroup) can help you with it.

For 2: This will need some more closer look into your code; I may do it
later.

For 3: If you are _sure_ that your source code will regenerate those
binary files during the building process from source code, this warning
can be treated as false-positives and can be overridden.



those pre-compiled binaries were included in the source package solely
for the purpose of easy installation for the end users. I don't need them
for this package.

In a similar package I maintained for Fedora, I had to remove those
unwanted binaries in the "setup" phase in the packaging file
https://src.fedoraproject.org/rpms/octave-iso2mesh/blob/master/f/octave-iso2mesh.spec#_68

for Debian, do I have to modify the orig package or there is a setting 
that I can exclude (or remove) these files?




For 4: Either one is okay in this case. BTW: I'm unsure if you are
indeed going to add SONAME into the -dev package name (using libzmat1-
dev instead of libzmat-dev). If you are to use libzmat1-dev and
encounter SONAME bump later, the package name for development package
will have to change as well, which may affect other packages that
build-depend on your library (if any).



got it. I fixed the lib name in this commit

https://salsa.debian.org/fangq/libzmat/-/commit/fee2578b9b17356d0dbf7e0ae11fab6848aa773f



I took a very quick glimpse on the library source code and it seems
that you are bundling some 3rd-party libraries, including lz4 and
easylzma. Debian is largely against bundling 3rdparty libraries: if
possible, please consider using libraries from Debian archive instead
of bundled ones. In this case, at least we need a switch to
enable/disable using bundled library copy in Makefile/CMakeLists.txt.



the decision was made largely for portability - a pretty big portion of the
users are windows/mac users, so, letting them compile these libraries on
their systems is a nightmare if I don't provide.



For lz4, you are almost surely required to adjust your code to use
external library (https://tracker.debian.org/pkg/lz4); for easylzma it
might be okay to use the bundled one for now since Debian hasn't
packaged it separately; however I personally suggest moving away from
such library since this one looks largely unmaintained and hasn't seen
development activity for 10+ years (https://github.com/lloyd/easylzma).
Stripping the bundled libraries is not required since they are still
free software and have compatible licenses with your whole project.



the bundled lz4 code is actually newer than the versions included in Debian
because I took it from its git repo last year. While I prefer to keep 
those as is
but I will be happy to read the policy regarding bundling, if you can 
point me to,

and see what I can do.



I will stop here for now. Thanks for your work and maybe we could fix
the issues mentioned previously first to properly shape your package.



appreciated for the commends!

Bug#960495: transition: gdal

[Sebastiaan Couwenberg]

Hi Sebastian,

On 6/10/20 9:46 PM, Sebastian Ramacher wrote:
> On 2020-06-08 05:54:33 +0200, Sebastiaan Couwenberg wrote:
>> On 5/30/20 11:42 AM, Sebastiaan Couwenberg wrote:
>>> On 5/13/20 12:07 PM, Bas Couwenberg wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition
 Control: forwarded -1 
 https://release.debian.org/transitions/html/auto-gdal.html
 Control: block -1 by 960369 953138

 For the Debian GIS team I'd like to transition to GDAL 3.1.0.

 All reverse dependencies rebuilt successfully with GDAL 3.1.0 from
 experimental as summarized below, except fiona & mysql-workbench.
>>>
>>> fiona has been fixed in the mean time, and mysql-workbench is unrelated
>>> to gdal.
>>>
>>> Can we do this transition after the icu one now that the R transitions
>>> have completed?
>>
>> icu & boost-defaults have migrated to testing, can we do the gdal
>> transition now?
> 
> Please go ahead with the upload to unstable.

Thanks, gdal (3.1.0+dfsg-1) was just uploaded to unstable.

 libgdal-grass doesn't need a binNMU as the 3.1.0 version will be
 uploaded to unstable instead.


 Transition: gdal

  libgdal26 (3.0.4+dfsg-1+b6) -> libgdal27 (3.1.0+dfsg-1~exp1)

 The status of the most recent rebuilds is as follows.

  fiona   (1.8.13-1)   FTBFS (#960369)
> 
> This bug got fixed.

We just got a new blocker, qgis FTBFS since the update of sip4 to
4.19.23+dfsg-1 (#962641)

  gazebo  (11.0.0+dfsg1-2) OK
  gmt (6.0.0+dfsg-2)   OK
  libcitygml  (2.0.9-2)OK
  libosmium   (2.15.5-1)   SKIP (B-D only)
  mapcache(1.10.0-1)   OK
  mapnik  (3.0.23+ds-1)OK
  mapproxy(1.12.0-1)   SKIP (B-D only)
  mapserver   (7.6.0-1)OK
  merkaartor  (0.18.4+ds-4)OK
  mysql-workbench (8.0.19+dfsg-1)  FTBFS (#953138)
  ncl (6.6.2-2)OK
  node-srs(0.4.8+dfsg-4)   OK
  octave-mapping  (1.4.0-1)OK
  openorienteering-mapper (0.9.1-1)OK
  openscenegraph  (3.6.4+dfsg1-3)  OK
  pdal(2.1.0+ds-2) OK
  pgsql-ogr-fdw   (1.0.9-1)OK
  pktools (2.6.7.6+ds-2)   OK
  postgis (3.0.1+dfsg-4)   OK
  python-django   (2:2.2.12-1) SKIP (B-D only)
  qmapshack   (1.14.1-1)   OK
  r-cran-mi   (1.0-7)  SKIP (B-D only)
  r-cran-rgdal(1.4-8-1)OK
  r-cran-sf   (0.9-3+dfsg-1)   OK
  r-cran-tmvtnorm (1.4-10-3)   SKIP (B-D only)
  rasterio(1.1.4-1)OK
  saga(7.3.0+dfsg-4)   OK
  sumo(1.4.0+dfsg1-1)  OK
  vtk6(6.3.0+dfsg2-5)  SKIP (B-D only)
  vtk7(7.1.1+dfsg2-4)  OK

  cloudcompare(2.10.3-4)   SKIP (B-D only)
  grass   (7.8.3-1)OK
  opencv  (4.2.0+dfsg-6)   OK
  osgearth(2.10.2+dfsg-2)  OK
  osmcoastline(2.2.4-1)OK
  paraview(5.7.0-4)OK
  pyosmium(3.0.0-1)SKIP (B-D only)

  libgdal-grass   (3.0.4-2 / 3.1.0-1~exp1) FTBFS / OK
  otb (7.1.0+dfsg-1)   OK
  qgis(3.10.5+dfsg-2)  OK

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#962639: ITP: node-pruddy-error -- Prettify given error object

[fancycade]

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

* Package name : node-pruddy-error
Version : 2.0.2
Upstream Author : Arnout Kazemier 
* URL : https://github.com/bigpipe/pruddy-error#readme
* License : BSD
Programming Lang: JavaScript
Description : Prettify given error object

This is a clone of the prettify-error module which was unpublished
by the author. This package is meant to prettify error objects for
console outputs. Which makes it very helpful for debugging and testing.
.
This package is useful as dependency for other node packages in Debian.

I plan on maintaining this as part of the js team.

Bug#962642: temporarily revert lib64 libraries

[Helmut Grohne]

Source: gmp
Version: 2:6.2.0+dfsg-5
Severity: important
User: helm...@debian.org
Usertags: rebootstrap

gmp added a g++-multilib dependency. Doing so breaks cross building and
thus cross bootstrap. Please use a cross-translatable
g++-multilib-for-host dependency.  Unfortunately, gcc does not presently
provide those. They're being added in #666743. Therefore, I ask for
temporarily reverting the lib64 libraries and adding them once toolchain
dependency translation is supported by gcc.

Helmut

Bug#943927: Bug#946340 closed by Debian FTP Masters (reply to Yangfl ) (Bug#946340: fixed in adplug 2.3.2+dfsg-1)

[Salvatore Bonaccorso]

Hi,

On Wed, Jun 10, 2020 at 09:03:13PM +, Debian Bug Tracking System wrote:
[...]
>  - Fix CVE-2019-14692 (Closes: #943927)
>  - Fix CVE-2019-14691 (Closes: #943928)
>  - Fix CVE-2019-14690 (Closes: #943929)
>  - Fix CVE-2019-15151 (Closes: #946340)

I checked those and compared with upstream, but they seem to have
landed only in 2.3.3. Can you double check?

Regards,
Salvatore

Bug#962638: ITP: node-propget -- Get properties from deeply nested objects and arrays

[fancycade]

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

* Package name : node-propget
Version : 1.1.0
Upstream Author : Arnout Kazemier
* URL : https://github.com/bigpipe/propget#readme
* License : Expat
Programming Lang: JavaScript
Description : Get properties from deeply nested objects and arrays

Use dot notation to get propertoes from deeply nested object and array
structures. Propget is a small helper utility for finding values/keys
in deeply nested objects without having to worry about undefined
properties. It uses a human readable dot based notation to find items
in your object or array.
.
It doesn't use node.js magic or ES6 so it should work on the browser as
well.
.
This package serves a dependency for Node.js applications or often times
test suites.

I plan to maintain this as part of the js team.

Bug#962637: node-left-pad -- String left-pad

[fancycade]

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

* Package name : node-left-pad
Version : 1.3.0
Upstream Author : azer
* URL : https://github.com/stevemao/left-pad#readme
* License : Expat
Programming Lang: JavaScript
Description : String left-pad

This is the infamous left-pad package used to left-pad strings.
The project is archived and this tool is now deprecated. The recommendation
is to use String.prototype.padStart() instead. However, due to the
ubiquity of this package in other node projects it is useful to have this
packaged.
.
This package is useful as a dependency for other Debian node packages.

I plan to maintain this as part of the js team.

Bug#962635: ITP: node-assume -- Expect-like assertions that work in node and the browser

[fancycade]

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

* Package name : node-assume
Version : 2.2.0
Upstream Author : Arnout Kazemier
* URL : https://github.com/bigpipe/assume#readme
* License : Expat
Programming Lang: JavaScript
Description : Expect-like assertions that work in node and the browser

Assume is an expect inspired assertion library who's sole purpose is to create
a working and human readable assert library for browsers and node. The library
is designed to work with different assertion styles.
.
Assume is written with client and server-side Javascript in mind and uses
commonjs module system to export itself.
.
This package is used as a build dependency for other Debian packages.
Specifically it is used in the testing phase of the build process.

I plan on maintaining this as part of the JS team.

Bug#962636: ITP: node-fn.name -- Extract the name of a given function.

[fancycade]

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

* Package name : node-fn.name
Version : 1.1.0
Upstream Author : Arnout Kazemier
* URL : https://github.com/3rd-Eden/fn.name
* License : Expat
Programming Lang: JavaScript
Description : Extract the name of a given function.

fn.name is a very simple package meant to be a utility for
reading the name of a given function as input.
.
console.log(name(function foo() {})) // foo
.
This package is useful as a dependency for other packages that
may need to access metadata from a function like the name.

I plan on maintaining this as part of the js team.

Bug#962634: ITP: node-is-node -- Detects if the current process is a node application

[fancycade]

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

* Package name : node-is-node
Version : 1.0.2
Upstream Author : matthewh  (http://matthewh.in/)
* URL : https://github.com/MatthewNPM/is-node
* License : Expat
Programming Lang: JavaScript
Description : Detects if the current process is a node application

is-node is a very simple package that is used to ensure that
the current running process is actually a node application.
.
Use cases will likely be for testing or other types of system validation.
.
This package is used by other Debian packages as a dependency.

I plan on maintaining this as part of the js team.

Bug#962641: qgis: FTBFS with SIP 4.19.23

[Bas Couwenberg]

Source: qgis
Version: 3.10.5+dfsg-2
Severity: serious
Tags: upstream
Justification: makes the package in question unusable or mostly so
Control: forwarded -1 https://github.com/qgis/QGIS/issues/37098
Control: block 960495 by -1

QGIS FTBFS since the update of sip4 to 4.19.23+dfsg-1:

 [3799/4686  81%]cd /<>/debian/build/python && /usr/bin/cmake -E 
echo && /usr/bin/cmake -E touch 
/<>/debian/build/python/server/sip_serverpart0.cpp 
/<>/debian/build/python/server/sip_serverpart1.cpp 
/<>/debian/build/python/server/sip_serverpart2.cpp 
/<>/debian/build/python/server/sip_serverpart3.cpp && /usr/bin/sip 
-w -e -x TESTS -x ANDROID -x ARM -x MOBILITY_LOCATION -n sip -t WS_X11 -t 
Qt_5_12_4 -g -o -a /<>/debian/build/python/qgis.server.api -n sip 
-y /<>/debian/build/output/python/qgis/_server.pyi -j 4 -c 
/<>/debian/build/python/server -I 
/<>/debian/build/python/server -I /usr/share/sip/PyQt5 -I 
/<>/python /<>/debian/build/python/server/server.sip
 FAILED: python/server/sip_serverpart0.cpp python/server/sip_serverpart1.cpp 
python/server/sip_serverpart2.cpp python/server/sip_serverpart3.cpp 
 cd /<>/debian/build/python && /usr/bin/cmake -E echo && 
/usr/bin/cmake -E touch 
/<>/debian/build/python/server/sip_serverpart0.cpp 
/<>/debian/build/python/server/sip_serverpart1.cpp 
/<>/debian/build/python/server/sip_serverpart2.cpp 
/<>/debian/build/python/server/sip_serverpart3.cpp && /usr/bin/sip 
-w -e -x TESTS -x ANDROID -x ARM -x MOBILITY_LOCATION -n sip -t WS_X11 -t 
Qt_5_12_4 -g -o -a /<>/debian/build/python/qgis.server.api -n sip 
-y /<>/debian/build/output/python/qgis/_server.pyi -j 4 -c 
/<>/debian/build/python/server -I 
/<>/debian/build/python/server -I /usr/share/sip/PyQt5 -I 
/<>/python /<>/debian/build/python/server/server.sip
 
 sip: core/conversions.sip:1440: %MappedType template for this type has already 
been defined

This has been reported upstream in:

 https://github.com/qgis/QGIS/issues/37098

Hopefully a fix will be available before the next point release on the 19th.

Bug#962622: qmapshack: Segmentation fault: no file found for translations

[Sebastiaan Couwenberg]

Control: tags -1 moreinfo

On 6/10/20 10:08 PM, ael wrote:
> Trying to read a gmapsupp.img generated by mkgmap using mapnik.typ
> results in an immediate crash.

Can you share this file somewhere to help reproduce the issue?

> There seems to be no version with debug symbols.  

Install qmapshack-dbgsym from debug.mirrors.debian.org.

https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#debug-archive

Kind Regards,

Bas

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

Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression

[Boyuan Yang]

Control: owner -1 !
Control: block 962603 by 962640

Hi Qianqian,

Thanks for being the upstream as well as a new packager. I am assuming
that you have have read https://mentors.debian.net/intro-maintainers
and know the key info about becoming a new packager.

在 2020-06-10星期三的 22:35 -0400，Qianqian Fang写道：
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> (new contributor here. the package has been uploaded to
> mentors https://mentors.debian.net/package/zmat, but showed
> several warnings/errors that I need help to fix.)
> 
> I am looking for a sponsor for my package "zmat":
> To access further information about this package, please visit the 
> following URL:
> 
> https://salsa.debian.org/fangq/libzmat
> 
> Alternatively, one can download the package with dget using this
> command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/z/zmat/zmat_0.9.8-1.dsc
> 
> ** sorry, the above command failed on my machine due to the below
> error:
>gpg: Can't check signature: No public key

This is because the PGP key you used to sign the source package is not
trusted by default in Debian (which is natural since you are not an
official member of Debian). According to the manual page of dget
(dget(1)), you may use -u/--allow-unauthenticated option when calling
dget to circumvent this problem.

Uploading to mentors.debian.net is recommended but not compulsory. If
you can prepare a git packging repo following the DEP-14 layout (
https://dep-team.pages.debian.net/deps/dep14), the review can also take
place there.

I saw your submission at https://mentors.debian.net/package/zmat .
Before we start the review, I'd suggest to take a look at those
automatic lintian warnings and error messages. They often indicate
important problems with your packaging.

There are several questions listed on mentors.debian.net/package/zmat
and I believe it might be better to send them together with your RFS
email (this is more likely to be read by mentors). For now I will copy
them here and I will answer some of them below:

==
I'd like to have someone take a look, and help me figure out some of
the remaining issues.

Specifically, here are the things I want to fix

1. one of the 3 subpackages is an Octave toolbox (as a mex file).
Although the binary was compiled during the packaging process, I wasn't
able to find a template to assemble the octave package. can someone
point to me if there is a template (for a similar mex-based toolbox)
for octave?

2. when running debuild, I got the below warning

dpkg-shlibdeps: warning: symbol deflateBound used by
debian/libzmat1/usr/lib/x86_64-linux-gnu/libzmat.so.1 found in none of
the libraries

although, I've already added zlib1g-dev to Build-Depends and zlib1g to
the Depends fields, I am wondering what else do I need to add.

3. I have two errors from lintian:

E: zmat source: source-is-missing private/zipmat.mexa64
E: zmat source: source-is-missing octave/linux64/zipmat.mex

these two folders (private/octave) are precompiled binary (mex) files
using the same source codes. They are not installed anyways, I am
wondering if I can set a flag to skip these files (or run a pre-build
script to remove them?)

4. naming convention: did I do this correctly? can I use libzmat or
zmat as the main package name?

if you can provide additional feedback on this package, I am very much
appreciated.
==

For 1: unfortunately I am not an expert in dealing with Octave. Maybe
someone from the Debian Science Team or Octave Group (
https://wiki.debian.org/Teams/DebianOctaveGroup) can help you with it.

For 2: This will need some more closer look into your code; I may do it
later.

For 3: If you are _sure_ that your source code will regenerate those
binary files during the building process from source code, this warning
can be treated as false-positives and can be overridden.

For 4: Either one is okay in this case. BTW: I'm unsure if you are
indeed going to add SONAME into the -dev package name (using libzmat1-
dev instead of libzmat-dev). If you are to use libzmat1-dev and
encounter SONAME bump later, the package name for development package
will have to change as well, which may affect other packages that
build-depend on your library (if any).

I took a very quick glimpse on the library source code and it seems
that you are bundling some 3rd-party libraries, including lz4 and
easylzma. Debian is largely against bundling 3rdparty libraries: if
possible, please consider using libraries from Debian archive instead
of bundled ones. In this case, at least we need a switch to
enable/disable using bundled library copy in Makefile/CMakeLists.txt.

For lz4, you are almost surely required to adjust your code to use
external library (https://tracker.debian.org/pkg/lz4); for easylzma it
might be okay to use the bundled one for now since Debian hasn't
packaged it separately; however I personally suggest moving 

Bug#962630: Acknowledgement (dovecot: FTBFS: test failures on 32-bit ARM)

[Noah Meyerhans]

Initial testing suggests that adding libunwind-dev to build-deps
resolves this issue.

Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression

[Qianqian Fang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

(new contributor here. the package has been uploaded to
mentors https://mentors.debian.net/package/zmat, but showed
several warnings/errors that I need help to fix.)

I am looking for a sponsor for my package "zmat":

  * Package name : zmat
    Version : 0.9.8
    Upstream Author : Qianqian Fang (fangqq at gmail.com)
  * URL : https://github.com/fangq/zmat
  * License : GPLv3+
  * Vcs : https://github.com/fangq/zmat
    Section : libs

It builds those binary packages:

  libzmat1 - a portable C library for stream-level compression
  libzmat1-dev - the library header files and samples to use libzmat
  octave-zmat - an Octave toolbox for array compression

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


   https://salsa.debian.org/fangq/libzmat

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

dget -x https://mentors.debian.net/debian/pool/main/z/zmat/zmat_0.9.8-1.dsc

** sorry, the above command failed on my machine due to the below error:
  gpg: Can't check signature: No public key

need some help to go through a submission process once, first time 
contributor.


Changes since the last upload:


  * Initial release. (Closes: #962603)
 -- Qianqian Fang   Mon, 08 Jun 2020 10:30:07 -0400


Regards,

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[YunQiang Su]

Thorsten Glaser  于2020年6月11日周四 上午1:58写道：
>
> On Thu, 11 Jun 2020, YunQiang Su wrote:
>
> > root@sid-i386:~# apt install gcc-9-i686-linux-gnu:amd64
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> >
> > The following packages have unmet dependencies:
> >  gcc-9-i686-linux-gnu:amd64 : Depends: libgcc-9-dev-i386-cross:amd64
> > (>= 9.3.0-13cross1) but it is not installable
> > E: Unable to correct problems, you have held broken packages.
>
> When encountering this kind of problems, it helps apt if you add
> all packages listed to the command line, until you see the real
> problem. In my build chroot, it looks like this:
>
> (pbuild25746-sid/i386)root@tglase:/# apt-get install gcc-i686-linux-gnu:amd64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  gcc-9-i686-linux-gnu:amd64 : Depends: binutils-i686-linux-gnu:amd64 (>= 
> 2.34) but it is not going to be installed
>   Depends: libgcc-9-dev-i386-cross:amd64 (>= 
> 9.3.0-13cross1) but it is not installable
> E: Unable to correct problems, you have held broken packages.
>
> Then I add the packages:
>
> (pbuild25746-sid/i386)root@tglase:/# apt-get install gcc-i686-linux-gnu:amd64 
> binutils-i686-linux-gnu:amd64 libgcc-9-dev-i386-cross:amd64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package libgcc-9-dev-i386-cross:amd64 is not available, but is referred to by 
> another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'libgcc-9-dev-i386-cross:amd64' has no installation candidate
>
>
> So we see that the package libgcc-9-dev-i386-cross:amd64 does not exist

in fact it may be problem of apt, since we do have libgcc-9-dev-i386-cross:all

> in Debian. There is the bug. (Also, why can’t it use libgcc-9-dev:i386?
> Really…) Go bother the GCC maintainer…
>

It is a :amd64 package, it shouldn't  depends on :i386 package.
To depends on libgcc-9-dev:i386, we need a gccXX-9:i386, that's just
what I want to do gcc64-9:i386.

> bye,
> //mirabilos
> --
> «MyISAM tables -will- get corrupted eventually. This is a fact of life. »
> “mysql is about as much database as ms access” – “MSSQL at least descends
> from a database” “it's a rebranded SyBase” “MySQL however was born from a
> flatfile and went downhill from there” – “at least jetDB doesn’t claim to
> be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!



-- 
YunQiang Su

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[Thorsten Glaser]

On Thu, 11 Jun 2020, YunQiang Su wrote:

> root@sid-i386:~# apt install gcc-9-i686-linux-gnu:amd64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  gcc-9-i686-linux-gnu:amd64 : Depends: libgcc-9-dev-i386-cross:amd64
> (>= 9.3.0-13cross1) but it is not installable
> E: Unable to correct problems, you have held broken packages.

When encountering this kind of problems, it helps apt if you add
all packages listed to the command line, until you see the real
problem. In my build chroot, it looks like this:

(pbuild25746-sid/i386)root@tglase:/# apt-get install gcc-i686-linux-gnu:amd64
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gcc-9-i686-linux-gnu:amd64 : Depends: binutils-i686-linux-gnu:amd64 (>= 2.34) 
but it is not going to be installed
  Depends: libgcc-9-dev-i386-cross:amd64 (>= 
9.3.0-13cross1) but it is not installable
E: Unable to correct problems, you have held broken packages.

Then I add the packages:

(pbuild25746-sid/i386)root@tglase:/# apt-get install gcc-i686-linux-gnu:amd64 
binutils-i686-linux-gnu:amd64 libgcc-9-dev-i386-cross:amd64
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package libgcc-9-dev-i386-cross:amd64 is not available, but is referred to by 
another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libgcc-9-dev-i386-cross:amd64' has no installation candidate


So we see that the package libgcc-9-dev-i386-cross:amd64 does not exist
in Debian. There is the bug. (Also, why can’t it use libgcc-9-dev:i386?
Really…) Go bother the GCC maintainer…

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#942622: Would the Games Team adopt Lightyears (pygame based, Python 3 port available)?

[Olek Wojnar]

Hi Steve,

On Wed, Jun 10, 2020 at 11:39 AM Olek Wojnar  wrote:

> On Mon, Jun 8, 2020 at 2:03 PM Moritz Mühlenhoff  wrote:
>
>> Has there been any update wrt lightyears/Py3 being moved to the Debian
>> Games
>> Team?
>>
>
> I haven't heard anything although I'm still willing to sponsor once we
> verify that the Python Applications Packaging Team is ok with transferring
> this package to the Games Team.
>
> Any word, Steve?
>

I've moved the package under the games-team [1]. I was going to give you
access to it but I can't find a Salsa account for you. If you don't have an
account yet, you can easily create one [2] and let me know your username.
I'll then give you access to the repository and you can make all of your
changes. Once you're happy with it, I'll review and upload. Let me know if
you have any questions!

-Olek

[1] https://salsa.debian.org/games-team/lightyears
[2] https://salsa.debian.org/users/sign_in

Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

On 2020-06-10 08:53, Boyuan Yang wrote:
> Signed tags/tarballs don't matter; they are totally optional. Your
> debian/watch file is using mode=git, which is totally fine; however,
> you may also opt to monitor the github releases page like other Debian
> packages.

Understood. I've left it untouched, in the hope that upstream will
sign their git tags.

> Just one last issue: you did not document the license information of
> textext/texoutparse.py; this file is licensed under the MIT License
> (seems to be the Expat variant), not BSD-3-Clause. Please update this
> information accordingly. After that, I think I can help to upload this
> package.

Whoops. I've fixed that, and uploaded the changes to mentors and salsa.

Thanks for your time,
Antonio

Bug#962633: dnscrypt-proxy: systemd socket file used even when listen_addresses specified in dnscrypt-proxy.toml

[Andrew Duty]

Package: dnscrypt-proxy
Version: 2.0.19+ds1-2+b11
Severity: important

Dear Maintainer,

The default config file (/etc/dnscrypt-proxy/dnscrypt-proxy.toml) says "Empty 
listen_addresses to use systemd socket activation" which implies that systemd 
socket activation will not occur if the listen_addresses field is not blank. 
However, if I specify a listen address (e.g. listen_addresses = 
['127.0.0.1:5353']) and restart (systemctl restart dnscrypt-proxy.service), 
dnscrypt-proxy is listening on both the address I specified and the address 
specified in /lib/systemd/system/dnscrypt-proxy.socket. I get the following (I 
get the same after a reboot):

# netstat -anp | grep 53
tcp0  0 127.0.0.1:5353  0.0.0.0:*   LISTEN  
7060/dnscrypt-proxy
tcp0  0 127.0.2.1:530.0.0.0:*   LISTEN  
1/init
udp0  0 127.0.2.1:530.0.0.0:*   
1/init
udp0  0 127.0.0.1:5353  0.0.0.0:*   
7060/dnscrypt-proxy

This is a problem for things like Pihole, where pihole-FTL needs to listen on 
port 53 and forward requests to dnscrypt-proxy on another port. Please 
reconfigure so that systemd sockets are not used if a listen_address is 
specified in /etc/dnscrypt-proxy/dnscrypt-proxy.toml.


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

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

Versions of packages dnscrypt-proxy depends on:
ii  adduser   3.118
ii  libc6 2.28-10
ii  lsb-base  10.2019051400

dnscrypt-proxy recommends no packages.

Versions of packages dnscrypt-proxy suggests:
pn  resolvconf  

Bug#962091: RFS: xine-ui/0.99.12-1 [QA] -- xine video player, user interface

[Håvard Flaget Aasen]

Hi, and thanks for the review.

lør. 6. jun. 2020 kl. 11:41 skrev Adrian Bunk :
>
> Control: tags -1 moreinfo
>
> On Wed, Jun 03, 2020 at 08:04:45AM +, Håvard Flaget Aasen wrote:
> >...
> > Changes since the last upload:
> >...
> >* d/rules
> >  - Change to dh-sequence
> >...
> >* d/control
> >...
> >  - Remove unnecessary Depends field
> >...
>
> This was necessary, it was just broken by your debian/rules rewrite.
> This RC regression can easily be reproduced with aaxine.
>
> For the debian/rules change, please verify that the changed package
> does not contain any unexpected changes from the original one.
> This means first understanding what the old debian/rules did.
> I can immediately find two things that were done in the old debian/rules
> but are missing in the new one.
>

I re added  the dependency fields in d/control, dh_xine, and
dh_compress targets in d/rules, which shouldn't have been removed,
thanks for spotting that. I also added back dh_installchangelog,
I'm still not sure if anything is actually using this symlink, but it
is consistent with the previous version.

> >* Add fix_spelling_error.patch
> >...

I've updated the .pot file and .po files as well, I believe that should fix it.

>
> This is a translated string, such a change breaks all translations of
> this string.
>
> > Regards,
> > Håvard
>
> cu
> Adrian

Regards,
Håvard

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[YunQiang Su]

Thorsten Glaser  于2020年6月11日周四 上午2:04写道：
>
> On Wed, 10 Jun 2020, YunQiang Su wrote:
>
> > But in fact, the multiarch cross-toolchain is broken day-by-day,
>
> Eh, fix those instead. Everyone else already has to rely on
> Multi-Arch; for example, I have to enable amd64 on my i386
> and x32 systems to get the kernel.
>
> > and is always un-installable.
>
> No?
>
> tglase@tglase:~ $ apt-get -s install gcc-i686-linux-gnu:amd64
> NOTE: This is only a simulation!
>   apt-get needs root privileges for real execution.
>   Keep also in mind that locking is deactivated,
>   so don't depend on the relevance to the real current situation!
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Starting pkgProblemResolver with broken count: 0
> Starting 2 pkgProblemResolver with broken count: 0
> Done
> The following additional packages will be installed:
>   binutils-i686-linux-gnu cpp-9-i686-linux-gnu cpp-i686-linux-gnu 
> gcc-10-cross-base gcc-9-cross-base
>   gcc-9-i686-linux-gnu gcc-9-i686-linux-gnu-base libasan5-i386-cross 
> libatomic1-i386-cross libc6-i386-cross
>   libgcc-9-dev-i386-cross libgcc-s1-i386-cross libgomp1-i386-cross 
> libitm1-i386-cross libquadmath0-i386-cross
>   libstdc++6-i386-cross libubsan1-i386-cross
> Suggested packages:
>   gcc-9-locales cpp-doc gcc-9-multilib-i686-linux-gnu make:amd64 
> gdb-i686-linux-gnu:amd64 gcc-doc:amd64
> Recommended packages:
>   libc6-dev-i386-cross libc6-dev-i386-cross:amd64 | libc-dev-i386-cross:amd64
> The following NEW packages will be installed:
>   binutils-i686-linux-gnu cpp-9-i686-linux-gnu cpp-i686-linux-gnu 
> gcc-10-cross-base gcc-9-cross-base
>   gcc-9-i686-linux-gnu gcc-9-i686-linux-gnu-base gcc-i686-linux-gnu:amd64 
> libasan5-i386-cross
>   libatomic1-i386-cross libc6-i386-cross libgcc-9-dev-i386-cross 
> libgcc-s1-i386-cross libgomp1-i386-cross
>   libitm1-i386-cross libquadmath0-i386-cross libstdc++6-i386-cross 
> libubsan1-i386-cross
> 0 upgraded, 18 newly installed, 0 to remove and 8 not upgraded.
> Inst gcc-9-i686-linux-gnu-base (9.3.0-13cross1 
> ftp.ports.debian.org:1.0/unstable [x32])
> Inst cpp-9-i686-linux-gnu (9.3.0-13cross1 ftp.ports.debian.org:1.0/unstable 
> [x32])
> Inst cpp-i686-linux-gnu (4:9.2.1-3.1 ftp.ports.debian.org:1.0/unstable [x32])
> Inst gcc-10-cross-base (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst gcc-9-cross-base (9.3.0-13cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst binutils-i686-linux-gnu (2.34-8 ftp.ports.debian.org:1.0/unstable [x32])
> Inst libc6-i386-cross (2.30-2cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst libgcc-s1-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst libgomp1-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst libitm1-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst libatomic1-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst libasan5-i386-cross (9.3.0-13cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst libstdc++6-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst libubsan1-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst libquadmath0-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst libgcc-9-dev-i386-cross (9.3.0-13cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Inst gcc-9-i686-linux-gnu (9.3.0-13cross1 ftp.ports.debian.org:1.0/unstable 
> [x32])
> Inst gcc-i686-linux-gnu:amd64 (4:9.2.1-3.1 Debian:unstable [amd64])
> Conf gcc-9-i686-linux-gnu-base (9.3.0-13cross1 
> ftp.ports.debian.org:1.0/unstable [x32])
> Conf cpp-9-i686-linux-gnu (9.3.0-13cross1 ftp.ports.debian.org:1.0/unstable 
> [x32])
> Conf cpp-i686-linux-gnu (4:9.2.1-3.1 ftp.ports.debian.org:1.0/unstable [x32])
> Conf gcc-10-cross-base (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Conf gcc-9-cross-base (9.3.0-13cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Conf binutils-i686-linux-gnu (2.34-8 ftp.ports.debian.org:1.0/unstable [x32])
> Conf libc6-i386-cross (2.30-2cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Conf libgcc-s1-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Conf libgomp1-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Conf libitm1-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Conf libatomic1-i386-cross (10.1.0-3cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Conf libasan5-i386-cross (9.3.0-13cross1 Debian:unstable, 
> ftp.ports.debian.org:1.0/unstable [all])
> Conf libstdc++6-i386-cross 

Bug#960760: Fixed Bug#960760: tree-puzzle FTBFS on !amd64: test failures

[Pranav Ballaney]

Hi,
I've pushed a patch for tree-puzzle to fix #960760. Please review.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960760
https://salsa.debian.org/med-team/tree-puzzle

Regards,
Pranav
ᐧ

Bug#904885: lintian.d.o: En dashes in tag descriptions are output incorrectly

[Felix Lechner]

Hi Andrey,

> lintian-info outputs "â" instead of en dash

Fixed for the website in this commit:


https://salsa.debian.org/lintian/taxiv/-/commit/927c23e0c2f28769321a34583b8339f35e1edc4d

but not yet fixed for 'lintian-info'.

We currently do not track bugs for the reporting code separately
(although the code is now separate from Lintian). This bug will be
closed when 'lintian-info' is fixed.

Please note that the tag mentioned here will soon be replaced by a
general policy tag called 'missing-field'. The references that caused
the bug have been transferred to the new tag. The correct display can
soon be verified there.

Kind regards
Felix Lechner

Bug#962265: sword: diff for NMU version 1.8.1+dfsg-8.1

[Gleisson Jesuino Joaquim Cardoso]

Control: tags 962265 + pending


Dear maintainer,

I've prepared an NMU for sword (versioned as 1.8.1+dfsg-8.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards,

Gleisson


diff -Nru sword-1.8.1+dfsg/debian/changelog sword-1.8.1+dfsg/debian/changelog
--- sword-1.8.1+dfsg/debian/changelog   2018-11-12 14:05:48.0 -0200
+++ sword-1.8.1+dfsg/debian/changelog   2020-06-08 21:39:54.0 -0300
@@ -1,3 +1,11 @@
+sword (1.8.1+dfsg-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixed ICU checking. Thanks to László Böszörményi .
+(Closes: #962265)
+
+ -- Gleisson Jesuino Joaquim Cardoso   Mon, 08 Jun 2020 
21:39:54 -0300
+
 sword (1.8.1+dfsg-8) unstable; urgency=medium
 
   * Breaks/Replaces on libsword11v5 >= 1.8, Closes: #913407
diff -Nru sword-1.8.1+dfsg/debian/patches/series 
sword-1.8.1+dfsg/debian/patches/series
--- sword-1.8.1+dfsg/debian/patches/series  2018-11-12 14:05:48.0 
-0200
+++ sword-1.8.1+dfsg/debian/patches/series  2020-06-08 21:39:54.0 
-0300
@@ -5,3 +5,4 @@
 0006-powerpc64.patch
 0007-gbfwordjs.patch
 sword_ICU_63.1.patch
+sword_ICU_67.1.patch
diff -Nru sword-1.8.1+dfsg/debian/patches/sword_ICU_67.1.patch 
sword-1.8.1+dfsg/debian/patches/sword_ICU_67.1.patch
--- sword-1.8.1+dfsg/debian/patches/sword_ICU_67.1.patch1969-12-31 
21:00:00.0 -0300
+++ sword-1.8.1+dfsg/debian/patches/sword_ICU_67.1.patch2020-06-08 
21:39:54.0 -0300
@@ -0,0 +1,33 @@
+Description: fix ICU checking
+ Let still search for icu-config but use pkg-config method after that.
+Forwarded: no
+Author: Laszlo Boszormenyi (GCS) 
+Last-Update: 2020-06-05
+
+---
+
+--- sword-1.8.1+dfsg.orig/configure.ac
 sword-1.8.1+dfsg/configure.ac
+@@ -238,9 +238,19 @@ if test x$with_icu = xyes; then
+  AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_"
+  AM_CFLAGS="$AM_CFLAGS -D_ICU_"
+   else
+- echo "*** The icu-config script installed by icu could not be found"
+- echo "*** compiling without ICU support"
+- with_icu=no
++ PKG_CHECK_MODULES([ICU], [icu-i18n >= 63.1], [found_icu=yes])
++ if test "$found_icu" = "yes"; then
++PKG_CHECK_MODULES([ICU_IO], [icu-io >= 63.1])
++ICU_IOLIBS="$ICU_IO_LIBS"
++with_icu=yes
++LIBS="$LIBS $ICU_LIBS $ICU_IOLIBS"
++AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_"
++AM_CFLAGS="$AM_CFLAGS -D_ICU_"
++ else
++echo "*** The icu-config script installed by icu could not be 
found"
++echo "*** compiling without ICU support"
++with_icu=no
++ fi
+   fi
+ fi
+ 

Bug#962632: dupload bash completion doesn't include directories

[Daniel Kahn Gillmor]

Package: dupload
Version: 2.9.5

Consider the following directory structure:

$ tree
.
└── xx
└── foo.changes
$

From a bash shell at this location, with bash completion enabled, if i
type:

$ dupload xx/

and then hit TAB it autocompletes to foo.changes, as it should.

But if instead i start with:

$ dupload xx

or

$ dupload x

and then hit TAB, it does not autocomplete to the directory name.


By comparison, if i do the same with other common commands that limit
themselves to specific files, hitting TAB will complete a directory.
For example, if "foo.odt" lives alongside "foo.changes", then
"libreoffice x TAB TAB" will complete to xx/foo.odt.

So something is amiss with dupload's bash tab completion: it doesn't
include the directory listings that might lead to the file that the user
could want to upload.

  --dkg


signature.asc
Description: PGP signature

Bug#925672: efivar: diff for NMU version 37-2.1

[David da Silva Polverari]

On Wed, Jun 10, 2020 at 07:32:36PM +, mario.limoncie...@dell.com wrote:
> I don't have a concern to this, but would you mind also submitting
> it to Salsa and linking back so we can get it into VCS?
> 
I have sent a merge request [1] on Salsa with the changes included on
the NMU. I branched it from cf16f73, as there was an unreleased
debian/changelog entry on a newer commit.

[1] https://salsa.debian.org/efi-team/efivar/-/merge_requests/2

Bug#826695:

[stephen williams]

Poslal jsem vám tento dopis před měsícem, ale nejsem si jistý, jestli jej
máte, neslyšel jsem od vás, tak jsem to napsal znovu. Jsem pan Stephen
Williams, předkládám tuto nabídku v souvislosti se smrtí mého zesnulého
klienta, který zemřel při strašlivé autonehodě s rodinou na cestě z
blízkého města tady v mé zemi a zanechal obrovské množství peněz v bance.
Když jsem nenašel jeho příbuzné, rozhodl jsem se vás kontaktovat.
Kontaktujte mě prostřednictvím této e-mailové adresy

Pozdravy,
Pan Williams ...

Bug#962630: dovecot: FTBFS: test failures on 32-bit ARM

[Noah Meyerhans]

Package: src:dovecot
Version: 1:2.3.10.1+dfsg1-1
Severity: serious
Justification: FTBFS on armel and armhf
Tags: sid

Dovecot currently fails to to build on 32-bit arm architectures.

The failure is in the upstream test suite, with the following output:

test-backtrace.c:19: Assert failed: backtrace_append(bt) == 0
test-backtrace.c:21: Assert failed: strstr(str_c(bt), "main") != NULL
backtrace_append . : FAILED
test-backtrace.c:43: Assert failed: backtrace_get() == 0
/bin/bash: line 1: 15381 Segmentation fault  ./$bin
make[5]: *** [Makefile:3409: check-local] Error 1
make[5]: Leaving directory '/<>/src/lib'
make[4]: *** [Makefile:2796: check-am] Error 2
make[4]: Leaving directory '/<>/src/lib'
make[3]: *** [Makefile:2798: check] Error 2
make[3]: Leaving directory '/<>/src/lib'
make[2]: *** [Makefile:563: check-recursive] Error 1
make[2]: Leaving directory '/<>/src'
make[1]: *** [Makefile:681: check-recursive] Error 1
make[1]: Leaving directory '/<>'
dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
make: *** [debian/rules:79: build-arch] Error 25
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

The specific failing test is:

static void test_backtrace_get(void)
{
test_begin("backtrace_get");
const char *bt = NULL;
#if (defined(HAVE_LIBUNWIND))
test_assert(backtrace_get() == 0);
/* Check that there's a usable function in the backtrace.
   Note that this function may be inlined, so don't check for
   test_backtrace_get() */
test_assert(strstr(bt, "test_backtrace") != NULL);
/* make sure the backtrace_get is not */
test_assert(strstr(bt, " backtrace_get") == NULL);
#elif (defined(HAVE_BACKTRACE_SYMBOLS) && defined(HAVE_EXECINFO_H)) || \
  (defined(HAVE_WALKCONTEXT) && defined(HAVE_UCONTEXT_H))
test_assert(backtrace_get() == 0);
/* it should have some kind of main in it */
test_assert(strstr(bt, "main") != NULL);
#else
/* should not work in this context */
test_assert(backtrace_get() == -1);
#endif
test_end();
}

The assertion failure and segfault happen in the second conditional
preprocessor block.  Do we execute the first block on systems where this
passes?  I wonder if backtrace_get() works at all in the second case?

Bug#962629: rainloop: Rainloop stores passwords in cleartext in logfile

[Marco Herrn]

Package: rainloop
Version: 1.12.1-2
Severity: important

Dear Maintainer,

When writing into a logfile, rainloop writes the passwords of all login
attempts (successful or not) into the logfile in cleartext.

Rainloop provides an option 'hide_passwords' in the application.ini that
should prohibit that behaviour, which is by default set to 'On'. But
apparently this doesn't have any effect.

There is already an unresolved github issue about that topic:
https://github.com/RainLoop/rainloop-webmail/issues/1872

Even though this issue doesn't affect the actual usability of rainloop,
I set the severity to 'Important' as this is a security issue.


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

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

Versions of packages rainloop depends on:
ii  apache2 [httpd] 2.4.38-3+deb10u3
ii  ckeditor4.11.1+dfsg-1
ii  php-curl2:7.3+69
ii  php-fpm 2:7.3+69
ii  php-nrk-predis  1.0.0-1
ii  php-pclzip  2.8.2-4
ii  php-seclib  1.0.14-1
ii  php-xml 2:7.3+69
ii  php7.3-curl [php-curl]  7.3.14-1~deb10u1
ii  php7.3-fpm [php-fpm]7.3.14-1~deb10u1
ii  php7.3-json [php-json]  7.3.14-1~deb10u1
ii  php7.3-xml [php-xml]7.3.14-1~deb10u1

rainloop recommends no packages.

Versions of packages rainloop suggests:
pn  php5-sqlite | php5-mysql | php5-pgsql  

-- Configuration Files:
/etc/rainloop/application.ini changed [not included]
/etc/rainloop/rainloop.apache.conf changed [not included]

-- no debconf information

Bug#953568: alsa-lib: diff for NMU version 1.2.2-2.2

[Francisco]

Control: tags 953568 + pending

Dear maintainer,

I've prepared an NMU for alsa-lib (versioned as 1.2.2-2.2) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards.

diff -Nru alsa-lib-1.2.2/debian/changelog alsa-lib-1.2.2/debian/changelog
--- alsa-lib-1.2.2/debian/changelog 2020-03-07 18:21:22.0 +
+++ alsa-lib-1.2.2/debian/changelog 2020-06-10 06:26:40.0 +
@@ -1,3 +1,11 @@
+alsa-lib (1.2.2-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/python3.8.diff:
+  - Updated as upstream commit '1654f38', fixed FTBFS. (Closes:
#953568)
+
+ -- Francisco Vilmar Cardoso Ruviaro 
Wed, 10 Jun 2020 06:26:40 +
+
 alsa-lib (1.2.2-2.1) unstable; urgency=medium

   [ Matthias Klose ]
diff -Nru alsa-lib-1.2.2/debian/patches/python3.8.diff
alsa-lib-1.2.2/debian/patches/python3.8.diff
--- alsa-lib-1.2.2/debian/patches/python3.8.diff2020-03-04
08:23:20.0 +
+++ alsa-lib-1.2.2/debian/patches/python3.8.diff2020-06-10
05:49:04.0 +
@@ -1,16 +1,21 @@
-# Description: fixes the build with python 3.8
-# Upstream: https://github.com/alsa-project/alsa-lib/issues/33
-# Author: Matthias Klose
-Index: b/configure.ac
-===
 a/configure.ac
-+++ b/configure.ac
-@@ -423,7 +423,7 @@ if test "$build_python" = "yes" -a "$bui
+Description: fixes the build with python 3.8
+Upstream: https://github.com/alsa-project/alsa-lib/issues/33
+Author: Matthias Klose
+Bug-Debian: https://bugs.debian.org/953568
+Reviewed-By: Francisco Vilmar Cardoso Ruviaro

+Last-Update: 2020-06-10
+
+--- alsa-lib-1.2.2.orig/configure.ac
 alsa-lib-1.2.2/configure.ac
+@@ -423,7 +423,10 @@ if test "$build_python" = "yes" -a "$bui
pythonlibs0=
pythoninc0=
if test "$build_python2" != "yes"; then
 -pythonlibs0=$(python3-config --libs)
-+pythonlibs0=$(python3-config --libs --embed)
++pythonlibs0=$(python3-config --libs --embed 2> /dev/null)
++if test -z "$pythonlibs0"; then
++  pythonlibs0=$(python3-config --libs)
++fi
  pythoninc0=$(python3-config --includes)
fi
if test -z "$pythonlibs0"; then

-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#960418: libkolabxml: diff for NMU version 1.1.6-6.1

[Adrian Bunk]

Control: tags 960418 + patch
Control: tags 960418 + pending

Dear maintainer,

I've prepared an NMU for libkolabxml (versioned as 1.1.6-6.1) and uploaded
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru libkolabxml-1.1.6/debian/changelog libkolabxml-1.1.6/debian/changelog
--- libkolabxml-1.1.6/debian/changelog	2019-11-27 22:56:30.0 +0200
+++ libkolabxml-1.1.6/debian/changelog	2020-06-11 00:08:22.0 +0300
@@ -1,3 +1,11 @@
+libkolabxml (1.1.6-6.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * libkolabxml1v5.symbols: Removed symbols that disappeared when
+rebuilding with Boost 1.71. (Closes: #960418)
+
+ -- Adrian Bunk   Thu, 11 Jun 2020 00:08:22 +0300
+
 libkolabxml (1.1.6-6) unstable; urgency=medium
 
   * Update symbols from buildds for 1.1.6 (Closes: #945420)
diff -Nru libkolabxml-1.1.6/debian/libkolabxml1v5.symbols libkolabxml-1.1.6/debian/libkolabxml1v5.symbols
--- libkolabxml-1.1.6/debian/libkolabxml1v5.symbols	2019-11-27 16:47:14.0 +0200
+++ libkolabxml-1.1.6/debian/libkolabxml1v5.symbols	2020-06-11 00:08:14.0 +0300
@@ -5927,9 +5927,6 @@
  (optional=gccinternal|arch=!armel !armhf)_ZN5boost6system12system_errorD0Ev@Base 1.1.1
  (optional=gccinternal|arch=!armel !armhf)_ZN5boost6system12system_errorD1Ev@Base 1.1.1
  (optional=gccinternal|arch=!armel !armhf)_ZN5boost6system12system_errorD2Ev@Base 1.1.1
- (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZN5boost6system14error_category12std_categoryD0Ev@Base 1.1.6
- (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZN5boost6system14error_category12std_categoryD1Ev@Base 1.1.6
- (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZN5boost6system14error_category12std_categoryD2Ev@Base 1.1.6
  _ZN5boost7numeric16bad_numeric_castD0Ev@Base 1.1.0
  _ZN5boost7numeric16bad_numeric_castD1Ev@Base 1.1.0
  _ZN5boost7numeric16bad_numeric_castD2Ev@Base 1.1.0
@@ -8308,11 +8305,6 @@
  (optional=inline|arch=!armel !armhf)_ZNK5boost6system12system_error4whatEv@Base 1.1.1
  (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZNK5boost6system14error_category10equivalentERKNS0_10error_codeEi@Base 1.1.6
  (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZNK5boost6system14error_category10equivalentEiRKNS0_15error_conditionE@Base 1.1.6
- (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZNK5boost6system14error_category12std_category10equivalentERKSt10error_codei@Base 1.1.6
- (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZNK5boost6system14error_category12std_category10equivalentEiRKSt15error_condition@Base 1.1.6
- (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZNK5boost6system14error_category12std_category23default_error_conditionEi@Base 1.1.6
- (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZNK5boost6system14error_category12std_category4nameEv@Base 1.1.6
- (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZNK5boost6system14error_category12std_category7messageB5cxx11Ei@Base 1.1.6
  (arch=amd64 arm64 i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32)_ZNK5boost6system14error_category23default_error_conditionEi@Base 1.1.6
  _ZNK5boost7numeric16bad_numeric_cast4whatEv@Base 1.1.0
  _ZNK5boost7numeric17negative_overflow4whatEv@Base 1.1.0
@@ -8970,8 +8962,6 @@
  (optional|arch=alpha hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 mips powerpcspe)_ZTIN5boost16exception_detail19error_info_injectorISt16invalid_argumentEE@Base 1.1.0
  _ZTIN5boost16exception_detail20error_info_containerE@Base 1.1.0
  _ZTIN5boost16exception_detail25error_info_container_implE@Base 1.1.0
- _ZTIN5boost19thread_specific_ptrI16XMLParserWrapperE11delete_dataE@Base 1.1.0
- _ZTIN5boost19thread_specific_ptrIN5Kolab5Utils6GlobalEE11delete_dataE@Base 1.1.0
  (arch=!alpha !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZTIN5boost5uuids13entropy_errorE@Base 1.1.6
  (optional=gccinternal|arch=armel armhf)_ZTIN5boost6detail14do_heap_deleteINS_19thread_specific_ptrI16XMLParserWrapperE11delete_dataEEE@Base 1.1.1
  (optional=gccinternal|arch=armel armhf)_ZTIN5boost6detail14do_heap_deleteINS_19thread_specific_ptrIN5Kolab5Utils6GlobalEE11delete_dataEEE@Base 1.1.1
@@ -8992,11 +8982,7 @@
  _ZTIN5boost6detail17sp_counted_impl_pINS_16exception_detail10clone_implINS2_14bad_exception_E@Base 1.1.0
  (arch=!alpha !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !mips !powerpcspe)_ZTIN5boost6detail17sp_counted_impl_pINS_16exception_detail15error_info_baseEEE@Base 1.1.6
  

Bug#962628: ITP: golang-github-anacrolix-stm -- Software Transactional Memory in Go

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro 

* Package name: golang-github-anacrolix-stm
  Version : 0.2.0-1
  Upstream Author : Matt Joiner
* URL : https://github.com/anacrolix/stm
* License : Expat
  Programming Lang: Go
  Description : Software Transactional Memory in Go

 STM provides Software Transactional Memory operations for Go. This is an
 alternative to the standard way of writing concurrent code (channels and
 mutexes). STM makes it easy to perform arbitrarily complex operations in an
 atomic fashion. One of its primary advantages over traditional locking is that
 STM transactions are composable, whereas locking functions are not -- the
 composition will either deadlock or release the lock between functions (making
 it non-atomic).

Bug#962626: nss-wrapper: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: nss-wrapper
Version: 1.1.11-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Hi Timo,

In Ubuntu, we have moved the i386 architecture to a compatibility-only layer
on amd64, and therefore we have also moved our autopkgtest infrastructure to
test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The nss-wrapper tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru nss-wrapper-1.1.11/debian/tests/control 
nss-wrapper-1.1.11/debian/tests/control
--- nss-wrapper-1.1.11/debian/tests/control 2020-04-02 10:23:15.0 
-0700
+++ nss-wrapper-1.1.11/debian/tests/control 2020-06-10 14:03:08.0 
-0700
@@ -1,10 +1,11 @@
 Tests: tests
 Depends: libnss-wrapper,
- gcc, libc-dev,
- cmake (>= 2.8.8-3~), make,
+ build-essential,
+ libc6-dev,
+ cmake (>= 2.8.8-3~),
  libcmocka-dev,
  netbase
 Restrictions: allow-stderr
 
 Tests: adequate
-Depends: libnss-wrapper, adequate
+Depends: libnss-wrapper, adequate:native
diff -Nru nss-wrapper-1.1.11/debian/tests/tests 
nss-wrapper-1.1.11/debian/tests/tests
--- nss-wrapper-1.1.11/debian/tests/tests   2020-04-02 10:23:15.0 
-0700
+++ nss-wrapper-1.1.11/debian/tests/tests   2020-06-10 13:54:51.0 
-0700
@@ -5,7 +5,19 @@
 rm -rf obj debian
 mkdir obj
 cd obj
-cmake .. -DUNIT_TESTING=1
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+cat < "$ADTTMP/toolchain.cmake"
+set(CMAKE_C_COMPILER $DEB_HOST_GNU_TYPE-gcc)
+set(CMAKE_CXX_COMPILER $DEB_HOST_GNU_TYPE-g++)
+set(PKG_CONFIG_EXECUTABLE $DEB_HOST_GNU_TYPE-pkg-config)
+EOF
+CCFILE=-DCMAKE_TOOLCHAIN_FILE="$ADTTMP/toolchain.cmake"
+else
+CCFILE=
+fi
+
+cmake .. "$CCFILE" -DUNIT_TESTING=1
 make -C tests/
 cd tests
 sed -e 's#\(LD_PRELOAD=\)[^;]*/\(libnss_wrapper.so\)#\1\2#' -i 
CTestTestfile.cmake

Bug#962627: eboard: playing against crafty causes "*** buffer overflow detected ***: eboard terminated"

[Eric Cooper]

Package: eboard
Version: 1.1.3-0.3
Severity: normal

Newly installed crafty and eboard.

Whan I run eboard, and choose Peer > Play against engine > Crafty > OK (all 
default
options), I get this message:

*** buffer overflow detected ***: eboard terminated
Aborted

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

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

Versions of packages eboard depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgcc-s1 [libgcc1]  10.1.0-3
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libglib2.0-0 2.64.3-1
ii  libgstreamer1.0-01.16.2-2
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpangoft2-1.0-01.44.7-4
ii  libpng16-16  1.6.37-2
ii  libstdc++6   10.1.0-3
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages eboard recommends:
ii  xfonts-75dpi  1:1.0.4+nmu1

Versions of packages eboard suggests:
ii  crafty  23.4-7

-- no debconf information

Bug#962625: ITP: golang-github-benbjohnson-immutable -- Immutable collections for Go

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro 

* Package name: golang-github-benbjohnson-immutable
  Version : 0.2.0-1
  Upstream Author : Ben Johnson
* URL : https://github.com/benbjohnson/immutable
* License : Expat
  Programming Lang: Go
  Description : Immutable collections for Go

 Immutable contains immutable collection types for Go. It includes List, Map,
 and SortedMap implementations. Immutable collections can provide efficient,
 lock free sharing of data by requiring that edits to the collections return new
 collections.
 .
 The collection types in this library are meant to mimic Go built-in
 collections such asslice and map. The primary usage difference between Go
 collections and immutable collections is that immutable collections always
 return a new collection on mutation so you will need to save the new reference.
 .
 Immutable collections are not for every situation, however, as they can incur
 additional CPU and memory overhead. Please evaluate the cost/benefit for your
 particular project.

Bug#962253: esys-particle: diff for NMU version 2.3.5+dfsg1-4.1

[Adrian Bunk]

On Wed, Jun 10, 2020 at 10:39:29PM +0200, Anton Gladky wrote:
> Hello Adrian,

Hi Anton,

> thanks a lot for the patch and NMU.
> 
> I am preparing a new upload of esys-particle and I will integrate your 
> changes.
> Could you please then cancel yout upload to prevent the race condition?

done.

> Thanks
> 
> Anton

Thanks
Adrian

Bug#962614: ntp: leap-seconds.list not updated and update-leap does not read ntp.conf correctly.

[Bernhard Schmidt]

Dear Ken,

> Dear Maintainer,
> 
> I have started to receive errors such as the following:
> 
>  Jun 10 14:08:24 blackab3 ntpd[592]: leapsecond file 
> ('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 18 days
> 
> I tried to run update-leap to update the file, but received the following 
> error:
> 
>  No leapfile directive in /etc/ntp.conf; leapfile location not known
> 
> Looking in ntp.conf, I see the following:
> 
>   # Leap seconds definition provided by tzdata
>   leapfile /usr/share/zoneinfo/leap-seconds.list
> 
> I hand edited a test ntp.conf with just the setting (incase the file was 
> corrupt), but it gave the error.
> 
> Running the command with the direct option worked:
> 
>   update-leap -L /usr/share/zoneinfo/leap-seconds.list
> 
> This is strange, the ntp.conf file appears correct - but it is not being read 
> by update-leap.

update-leap is quite buggy, which is why we opted not to use it by
default and instead are using the leap-seconds.list definition shipped
by tzdata.

https://tracker.debian.org/pkg/tzdata

tzdata 2020a-1 containing a leap-seconds.list valid until End of
December is already in sid, bullseye and buster-proposed /
stretch-proposed. As soon as the next stable release happens ntp will
automatically use the updated leap seconds file.

Bernhard

Bug#962253: esys-particle: diff for NMU version 2.3.5+dfsg1-4.1

[Anton Gladky]

Hello Adrian,

thanks a lot for the patch and NMU.

I am preparing a new upload of esys-particle and I will integrate your changes.
Could you please then cancel yout upload to prevent the race condition?

Thanks

Anton

Am Mi., 10. Juni 2020 um 15:09 Uhr schrieb Adrian Bunk :
>
> Control: tags 962253 + patch
> Control: tags 962253 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for esys-particle (versioned as 2.3.5+dfsg1-4.1)
> and uploaded it to DELAYED/2. Please feel free to tell me if I should
> cancel it.
>
> cu
> Adrian
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#962624: libsrt1-openssl: missing Breaks+Replaces

[Sebastian Ramacher]

Package: libsrt1-openssl
Version: 1.4.1-2
Severity: serious

When installing libsrt1-openssl if libsrt1 is already installed:

Preparing to unpack .../libsrt1-openssl_1.4.1-2_amd64.deb ...
Unpacking libsrt1-openssl:amd64 (1.4.1-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/libsrt1-openssl_1.4.1-2_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libsrt.so.1.4.1', which is also 
in package libsrt1:amd64 1.4.1-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Selecting previously unselected package libsrt-openssl-dev:amd64.
Preparing to unpack .../libsrt-openssl-dev_1.4.1-2_amd64.deb ...

Same issue for libsrt-openssl-dev if libsrt-dev is already installed:

Unpacking libsrt-openssl-dev:amd64 (1.4.1-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/libsrt-openssl-dev_1.4.1-2_amd64.deb (--unpack):
 trying to overwrite '/usr/include/srt/logging_api.h', which is also in package 
libsrt-dev:amd64 1.4.1-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libsrt1-openssl_1.4.1-2_amd64.deb
 /var/cache/apt/archives/libsrt-openssl-dev_1.4.1-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#925672: efivar: diff for NMU version 37-2.1

[Mario.Limonciello]

I don't have a concern to this, but would you mind also submitting
it to Salsa and linking back so we can get it into VCS?

> -Original Message-
> From: David da Silva Polverari 
> Sent: Wednesday, June 10, 2020 12:06 AM
> To: 925...@bugs.debian.org
> Subject: Bug#925672: efivar: diff for NMU version 37-2.1
> 
> 
> [EXTERNAL EMAIL]
> 
> Control: tags 925672 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for efivar (versioned as 37-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer or cancel the NMU.
> 
> Regards,
> 
> David Polverari.

Bug#962623: ImportError: cannot import name 'parse_qs' from 'cgi' (/usr/lib/python3.8/cgi.py)

[Natalia Serrano]

Package: graphite-web
Version: 1.1.4-5
Severity: grave
Justification: renders package unusable

Hi,

When initially setting up graphite-web I ran the following (per
/usr/share/doc/graphite-carbon/README.Debian):

# su -s /bin/bash _graphite -c 'graphite-manage migrate --run-syncdb'
/usr/lib/python3/dist-packages/graphite/settings.py:334: UserWarning: 
SECRET_KEY is set to an unsafe default. This should be set in local_settings.py 
for better security
  warn('SECRET_KEY is set to an unsafe default. This should be set in 
local_settings.py for better security')
Traceback (most recent call last):
  (...52 lines of stack trace removed...)
  File "/usr/lib/python3/dist-packages/graphite/render/urls.py", line 16, in 

from . import views
  File "/usr/lib/python3/dist-packages/graphite/render/views.py", line 23, in 

from cgi import parse_qs
ImportError: cannot import name 'parse_qs' from 'cgi' 
(/usr/lib/python3.8/cgi.py)

This also happens when connecting to the dashboard via HTTP: I installed
libapache2-mod-wsgi-py3, configured the VirtualHost and when connecting I get a
500 on the browser and a similar stack trace on the error log. I didn't check
it all but the last 2 entries are same as above.

When looking into this I found what seems to be a dependency issue. The release
notes for graphite 1.1.6 [1] state "Python 3.8 and Django 2.x support". That
makes me speculate that graphite 1.1.4 doesn't support python 3.8, and is thus
broken on debian testing/sid.

I believe we'd need graphite-web 1.1.6 on debian.

[1] https://graphite.readthedocs.io/en/latest/releases/1_1_6.html


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

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

Versions of packages graphite-web depends on:
ii  adduser 3.118
ii  python3 3.8.2-3
ii  python3-cairo   1.16.2-3
ii  python3-cairocffi   0.9.0-4
ii  python3-django  2:2.2.13-1
ii  python3-django-tagging  1:0.4.5-3
ii  python3-pyparsing   2.4.7-1
ii  python3-simplejson  3.17.0-1
ii  python3-six 1.15.0-1
ii  python3-tz  2020.1-1
ii  python3-urllib3 1.25.9-1
ii  python3-whisper 1.1.4-2

graphite-web recommends no packages.

Versions of packages graphite-web suggests:
ii  graphite-carbon  1.1.4-2
ii  libapache2-mod-wsgi-py3  4.6.8-1+b1
pn  python3-ldap 
pn  python3-memcache 
pn  python3-mysqldb  

-- no debconf information

Bug#962596: ca-certificates: Removal of GeoTrust Global CA requires investigation

[Carlos Alberto Lopez Perez]

On 10/06/2020 16:51, Philippe Normand wrote:
> Package: ca-certificates
> Version: 20200601
> Severity: normal
> 
> Dear Maintainer,
> 
> Since the update of ca-certificates to version 20200601 I can no longer access
> webkit.org websites.
> 


The removed CA (GeoTrust Global CA) is used to sign the Apple
intermediate certificate "Apple IST CA 2 - G1".

Firefox and Chrome have some sort of hack (likely a whitelist)
specifically to trust this Apple's intermediate CAs:
https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

So the website still works in Firefox and Chrome on Debian, even with
GeoTrust removed. But it doesn't work with GnuTLS (or the Epiphany web
browser).



signature.asc
Description: OpenPGP digital signature

Bug#962622: qmapshack: Segmentation fault: no file found for translations

[ael]

Package: qmapshack
Version: 1.14.1-1
Severity: normal

Trying to read a gmapsupp.img generated by mkgmap using mapnik.typ
results in an immediate crash.

Running under gdb doesn't give much useful information, but:
(gdb) run
Starting program: /usr/bin/qmapshack 
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffded86700 (LWP 8692)]
[New Thread 0x7fffdcefc700 (LWP 8693)]
[New Thread 0x7fffd7fff700 (LWP 8694)]
[New Thread 0x7fffd77fe700 (LWP 8695)]
[New Thread 0x7fffd6ffd700 (LWP 8696)]
2020-06-10 21:01:36.084 [warning] "no file found for translations
'/usr/share/qt5/translations/qt_en' (using default)."
2020-06-10 21:01:36.084 [warning] "no file found for translations
'/usr/share/qmapshack/translations/qmapshack_en' (using default)."
[New Thread 0x7fffd568a700 (LWP 8697)]
[New Thread 0x7fffd4ce5700 (LWP 8699)]
[New Thread 0x7fffbb97c700 (LWP 8700)]
[Detaching after fork from child process 8701]
...[snip]...
Thread 1 "qmapshack" received signal SIGSEGV, Segmentation fault.
0x74d120af in QTextCodec::toUnicode(QByteArray const&) const ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

There seems to be no version with debug symbols.  

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

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

Versions of packages qmapshack depends on:
ii  libalglib3.143.16.0-1
ii  libc62.30-8
ii  libgcc-s110.1.0-3
ii  libgdal263.0.4+dfsg-1+b6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libproj197.0.1-1
ii  libqt5core5a 5.12.5+dfsg-10+b1
ii  libqt5dbus5  5.12.5+dfsg-10+b1
ii  libqt5gui5   5.12.5+dfsg-10+b1
ii  libqt5help5  5.12.5-2+b2
ii  libqt5network5   5.12.5+dfsg-10+b1
ii  libqt5printsupport5  5.12.5+dfsg-10+b1
ii  libqt5qml5   5.12.5-5
ii  libqt5sql5   5.12.5+dfsg-10+b1
ii  libqt5sql5-sqlite5.12.5+dfsg-10+b1
ii  libqt5webenginewidgets5  5.12.5+dfsg-7+b3
ii  libqt5widgets5   5.12.5+dfsg-10+b1
ii  libqt5xml5   5.12.5+dfsg-10+b1
ii  libquazip5-1 0.9-2
ii  libroutino0  3.3.2-1
ii  libstdc++6   10.1.0-3

Versions of packages qmapshack recommends:
pn  gdal-bin  
pn  routino   

Versions of packages qmapshack suggests:
ii  gpsd  3.20-12

-- no debconf information

Bug#962621: ITP: jcabi-aspects - Useful Java AOP Aspects

[Mechtilde Stehmann]

Package: wnpp
Severity: wishlist

* Package name : libjcabi-aspects-java
  Version : 0.22.6
  Upstream Author : Yegor Bugayenko
* URL : https://github.com/jcabi/jcabi-aspects
* License : BSD
  Programming Lang: Java
  Description :  Useful Java AOP Aspects

Useful Java AOP Aspects is a collection of useful AOP aspects and Java
annotations which allow you to modify the behavior of your Java
application without writing lots of duplicate code.

For example, you may want to retry HTTP resource downloading in case of
a failure. You can implement a full do/while cycle yourself or you can
annotate the method with @RetryOnFailure and let one of our AOP aspects
do the work for you:


* Why is this package useful/relevant?
* Is it a dependency for another package?

this is a dependency of jacabi-ssh which is itself a dependency of
J-Lawer (RFP #962415)

* Do you use it yourself?
* If there are other packages providing similar functionality,
  how does it compare?
* How do you plan to maintain it? Do you plan to maintain it
  inside a packaging team?

I want to maintain it inside the Java-Team

  (check list at https://wiki.debian.org/Teams)
* Are you looking for co-maintainers? Do you need a sponsor?

...--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#960193: ICU rebuilds

[Peter]

On 10/06/2020 19:03, Sebastian Ramacher wrote:
> Hi Peter
>
> On 2020-06-10 18:28:24 +0100, Peter wrote:
>> On 09/06/2020 21:19, Sebastian Ramacher wrote:
>>> On 2020-06-09 19:56:00 +0200, László Böszörményi (GCS) wrote:
 Hi,

 On Tue, Jun 9, 2020 at 12:15 PM Pino Toscano  wrote:
> can you please rebuild for the ICU transition also the packages in
> experimental?
  I can't schedule binNMUs myself, but Sebastian can.

 Please, if you have time schedule binNMUs of the following packages
 with ICU 67.1 in _experimental_:
> dcmtk
> gnustep-base
> gnustep-gui
> libqalculate
> performous
> qtbase-opensource-src
> qtlocation-opensource-src
> qtwebkit-opensource-src
> webkit2gtk
> zimwriterfs
>>> Scheduled.
>>>
>>> Cheers
>> Hi,
>>
>> Please could someone add qosmic to the binNMU list?
>>   { https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962095 }
> Why would it need a binNMU? It doesn't depend on libicu63.
>
> Cheers

Hi Sebastian,

I'm just a little wary of the dependency chain

qosmic -> flam3 -> libxml2 -> libicu67

given that qosmic was built against ICU 63 headers, and flam3 has a static 
library.

That said, I can find no obvious problem, guess I'm just being overly cautious 
here.


Will there be a full rebuild of the archive for Bullseye anyway?


Cheers,
Peter

Bug#961979: transition: libwebsockets

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libwebsockets.html
Control: tags -1 + confirmed

On 2020-06-01 13:29:05 +0200, László Böszörményi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi RMs,
> 
> Small transition with four affected packages: driftnet, forked-daapd,
> janus and mosquitto.
> All build fine with the libwebsockets 4.0.13 version in experimental.

Please go ahead with the upload to unstable.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#960495: transition: gdal

[Sebastian Ramacher]

Control: tags -1 + confirmed

Hi Bas

On 2020-06-08 05:54:33 +0200, Sebastiaan Couwenberg wrote:
> On 5/30/20 11:42 AM, Sebastiaan Couwenberg wrote:
> > On 5/13/20 12:07 PM, Bas Couwenberg wrote:
> >> Package: release.debian.org
> >> Severity: normal
> >> User: release.debian@packages.debian.org
> >> Usertags: transition
> >> Control: forwarded -1 
> >> https://release.debian.org/transitions/html/auto-gdal.html
> >> Control: block -1 by 960369 953138
> >>
> >> For the Debian GIS team I'd like to transition to GDAL 3.1.0.
> >>
> >> All reverse dependencies rebuilt successfully with GDAL 3.1.0 from
> >> experimental as summarized below, except fiona & mysql-workbench.
> > 
> > fiona has been fixed in the mean time, and mysql-workbench is unrelated
> > to gdal.
> > 
> > Can we do this transition after the icu one now that the R transitions
> > have completed?
> 
> icu & boost-defaults have migrated to testing, can we do the gdal
> transition now?

Please go ahead with the upload to unstable.

> 
> >> libgdal-grass doesn't need a binNMU as the 3.1.0 version will be
> >> uploaded to unstable instead.
> >>
> >>
> >> Transition: gdal
> >>
> >>  libgdal26 (3.0.4+dfsg-1+b6) -> libgdal27 (3.1.0+dfsg-1~exp1)
> >>
> >> The status of the most recent rebuilds is as follows.
> >>
> >>  fiona   (1.8.13-1)   FTBFS (#960369)

This bug got fixed.

Cheers

> >>  gazebo  (11.0.0+dfsg1-2) OK
> >>  gmt (6.0.0+dfsg-2)   OK
> >>  libcitygml  (2.0.9-2)OK
> >>  libosmium   (2.15.5-1)   SKIP (B-D only)
> >>  mapcache(1.10.0-1)   OK
> >>  mapnik  (3.0.23+ds-1)OK
> >>  mapproxy(1.12.0-1)   SKIP (B-D only)
> >>  mapserver   (7.6.0-1)OK
> >>  merkaartor  (0.18.4+ds-4)OK
> >>  mysql-workbench (8.0.19+dfsg-1)  FTBFS (#953138)
> >>  ncl (6.6.2-2)OK
> >>  node-srs(0.4.8+dfsg-4)   OK
> >>  octave-mapping  (1.4.0-1)OK
> >>  openorienteering-mapper (0.9.1-1)OK
> >>  openscenegraph  (3.6.4+dfsg1-3)  OK
> >>  pdal(2.1.0+ds-2) OK
> >>  pgsql-ogr-fdw   (1.0.9-1)OK
> >>  pktools (2.6.7.6+ds-2)   OK
> >>  postgis (3.0.1+dfsg-4)   OK
> >>  python-django   (2:2.2.12-1) SKIP (B-D only)
> >>  qmapshack   (1.14.1-1)   OK
> >>  r-cran-mi   (1.0-7)  SKIP (B-D only)
> >>  r-cran-rgdal(1.4-8-1)OK
> >>  r-cran-sf   (0.9-3+dfsg-1)   OK
> >>  r-cran-tmvtnorm (1.4-10-3)   SKIP (B-D only)
> >>  rasterio(1.1.4-1)OK
> >>  saga(7.3.0+dfsg-4)   OK
> >>  sumo(1.4.0+dfsg1-1)  OK
> >>  vtk6(6.3.0+dfsg2-5)  SKIP (B-D only)
> >>  vtk7(7.1.1+dfsg2-4)  OK
> >>
> >>  cloudcompare(2.10.3-4)   SKIP (B-D only)
> >>  grass   (7.8.3-1)OK
> >>  opencv  (4.2.0+dfsg-6)   OK
> >>  osgearth(2.10.2+dfsg-2)  OK
> >>  osmcoastline(2.2.4-1)OK
> >>  paraview(5.7.0-4)OK
> >>  pyosmium(3.0.0-1)SKIP (B-D only)
> >>
> >>  libgdal-grass   (3.0.4-2 / 3.1.0-1~exp1) FTBFS / OK
> >>  otb (7.1.0+dfsg-1)   OK
> >>  qgis(3.10.5+dfsg-2)  OK
> 
> Kind Regards,
> 
> Bas
> 
> -- 
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962584: transition: gnustep-base, gnustep-gui

[Sebastian Ramacher]

Control: tags -1 + confirmed

On 2020-06-10 12:09:50 +0300, Yavor Doganov wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> On behalf of the GNUstep team I'd like to ask for a slot to carry out
> a GNUstep transition:
> 
>   libgnustep-base1.26 -> 1.27
>   libgnustep-gui0.27  -> 0.28
> 
> I tested all rdeps; they build successfully on amd64 except cenon.app
> (#962503).  In fact this is a gnustep-gui bug which will be fixed with
> the upload to unstable so cenon.app can be binNMUed along with the
> rest of the packages.
> 
> As always, gnustep-back (the rendering part of the gnustep-gui
> library) will require a sourceful upload.

Please go ahead with the uploads to unstable.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#952431: symfony: FTBFS: test failures with PHP 7.4

[Andreas Beckmann]

Followup-For: Bug #952431
Control: retitle -1 symfony: FTBFS: test failures with PHP 7.4
Control: found -1 5.0.4-1

The same errors (and some more) are happening in experimental, too.


Andreas


symfony_5.0.4-1.log.gz
Description: application/gzip

Bug#962616: webkit2gtk: FTBFS on mipsel

[Sebastian Ramacher]

On 2020-06-10 20:46:21 +0200, Alberto Garcia wrote:
> On Wed, Jun 10, 2020 at 08:08:27PM +0200, Sebastian Ramacher wrote:
> > | Exception: gtkdoc-scangobj produced a non-zero return code 250
> > | Command:
> > |   gtkdoc-scangobj --module=webkit2gtk-4.0
> > | Error output:
> > |   
> > |
> > | ninja: build stopped: subcommand failed.
> 
> I've seen this several times, and it seems to happen randomly, and
> only on mipsel. I haven't been able to reproduce it in a buildd.
> 
> I suspect it's a bug in gtk-doc-tools ?

That could be the case. The last three builds failed with this issue.
And so did builds of 2.28.1-1 and 2.28.2-1 before.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962471: unattended-upgrades: Duplicate log lines

[Balint Reczey]

Control: tags -1 confirmed

On Mon, Jun 8, 2020 at 4:09 PM Paul Menzel  wrote:
>
> Package: unattended-upgrades
> Version: 2.4
> Severity: normal
>
> Dear Debian folks,
>
>
> Looking through `/var/log/unattended-upgrades/unattended-upgrades.log`,
> there are duplicate lines (last four warning lines):
>
> > 2020-06-06 15:48:38,161 INFO Writing dpkg log to 
> > /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
> > 2020-06-06 15:48:47,354 INFO While building minimal partition: cache has 
> > not allowed changes
> > 2020-06-06 16:02:43,082 INFO All upgrades installed
> > 2020-06-06 16:02:46,990 WARNING Keeping auto-removable 
> > libboost-system1.67.0 package(s) because it would also remove the following 
> > packages which should be kept in this step: libboost-chrono1.67.0 
> > liborcus-0.14-0
> > 2020-06-06 16:02:47,623 WARNING Keeping auto-removable 
> > libboost-filesystem1.67.0 package(s) because it would also remove the 
> > following packages which should be kept in this step: liborcus-0.14-0
> > 2020-06-06 16:02:50,622 WARNING Keeping auto-removable 
> > libboost-iostreams1.67.0 package(s) because it would also remove the 
> > following packages which should be kept in this step: liborcus-0.14-0
> > 2020-06-06 16:02:53,437 INFO Packages that were successfully auto-removed: 
> > libboost-date-time1.67.0 libboost-locale1.67.0 libboost-thread1.67.0 
> > python3-gst-1.0
> > 2020-06-06 16:02:53,437 INFO Packages that are kept back: 
> > libboost-filesystem1.67.0 libboost-iostreams1.67.0 libboost-system1.67.0
> > 2020-06-06 16:02:53,636 INFO Package cpp-8 is kept back because a related 
> > package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,662 INFO Package gcc-8-base is kept back because a 
> > related package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,710 INFO Package libboost-dev is kept back because a 
> > related package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,733 INFO Package libgcc1 is kept back because a related 
> > package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,793 INFO Package libmpx2 is kept back because a related 
> > package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,979 INFO Package sshfs is kept back because a related 
> > package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:59,108 INFO Checking if system is running on battery is 
> > skipped. Please install powermgmt-base package to check power status and 
> > skip installing updates when the system is running on battery.
> > 2020-06-06 16:02:59,113 INFO Starting unattended upgrades script
> > 2020-06-06 16:02:59,113 INFO Allowed origins are: 
> > origin=Debian,codename=sid,label=Debian, 
> > origin=Debian,codename=sid,label=Debian-Security, 
> > origin=Debian,codename=sid-security,label=Debian-Security
> > 2020-06-06 16:02:59,113 INFO Initial blacklist:
> > 2020-06-06 16:02:59,114 INFO Initial whitelist (not strict):
> > 2020-06-06 16:03:00,568 WARNING package cpp-8 upgradable but fails to be 
> > marked for upgrade (E:Unable to correct problems, you have held broken 
> > packages.)
> > 2020-06-06 16:03:01,885 WARNING package cpp-8 upgradable but fails to be 
> > marked for upgrade (E:Unable to correct problems, you have held broken 
> > packages.)
> > 2020-06-06 16:03:07,462 WARNING package libmpx2 upgradable but fails to be 
> > marked for upgrade (E:Unable to correct problems, you have held broken 
> > packages.)
> > 2020-06-06 16:03:08,536 WARNING package libmpx2 upgradable but fails to be 
> > marked for upgrade (E:Unable to correct problems, you have held broken 
> > packages.)
>
> This is confusing. If the duplicates are useful, it’d be great to have
> more context in the log.

The problem is that it is hard to exactly explain why a package can't
be installed. Briefly it is because APT could not find an upgrade
solution where it can be upgraded and that's what unattended-upgrades
can tell.

Cheers,
Balint

>
>
> Kind regards,
>
> Paul
>



--
Balint Reczey
Ubuntu & Debian Developer

Bug#851611: sawfish: Annoying error message "File error: No such file or directory, gnome"

[Derek Upham]

The root cause is that /etc/X11/sawfish/site-init.d/00debian.jl is 
attempting to load using


 (require 'gnome)

and /usr/share/sawfish/lisp/gnome.jl does not exist.  Instead

 /usr/share/sawfish/lisp/gnome-int.jl

exists, a symlink pointing to 


 sawfish/wm/integration/gnome.jl

The package maintainer can either update the symlink name to be 
consistent, or update the 00debian.jl file to use


 (require 'gnome-int)

Bug#962620: stress-ng: flaky arm64 autopkgtest on ci.debian.net: bash: fork: retry: Resource temporarily unavailable

[Paul Gevers]

Source: stress-ng
Version: 0.11.01-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

The autopkgtest of stress-ng turned up a couple of times on our list of
unfinished tests on the ci.debian.net arm64 infrastructure. I looked
into the history of your autopkgtest and it fails regularly on arm64 [1][2].

Looking at the purpose of this package, is it possible that it's a bit
too aggressive for the workers of ci.debian.net? Especially if you
consider that we run several autopkgtest instances in parallel on the
same host?

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests. Furthermore, I have the (not further substantiated) impression
it's impacting our ci service.

I copied the output at the bottom of this report. Not all the failing
tests [1][2] that I inspected fail at the same position.

Please do get in touch if we need to dive into this together.

Paul

[1] https://ci.debian.net/packages/s/stress-ng/unstable/arm64/
[2] https://ci.debian.net/packages/s/stress-ng/testing/arm64/

https://ci.debian.net/data/autopkgtest/testing/arm64/s/stress-ng/5493119/log.gz

daemon at Fri May 15 13:24:41 UTC 2020
stress-ng: 13:24:41.91 debug: [8318] 32 processors online, 32 processors
configured
stress-ng: 13:24:41.91 info:  [8318] dispatching hogs: 4 daemon
stress-ng: 13:24:41.91 debug: [8318] cache allocate: using defaults,
can't determine cache details from sysfs
stress-ng: 13:24:41.91 debug: [8318] cache allocate: default cache size:
2048K
stress-ng: 13:24:41.91 debug: [8318] starting stressors
stress-ng: 13:24:41.91 debug: [8319] stress-ng-daemon: started [8319]
(instance 0)
stress-ng: 13:24:41.91 debug: [8318] 4 stressors spawned
stress-ng: 13:24:41.91 debug: [8320] stress-ng-daemon: started [8320]
(instance 1)
stress-ng: 13:24:41.91 debug: [8322] stress-ng-daemon: started [8322]
(instance 3)
stress-ng: 13:24:41.91 debug: [8321] stress-ng-daemon: started [8321]
(instance 2)
stress-ng: 13:24:42.91 debug: [8319] stress-ng-daemon: exited [8319]
(instance 0)
stress-ng: 13:24:42.91 debug: [8320] stress-ng-daemon: exited [8320]
(instance 1)
stress-ng: 13:24:42.91 debug: [8322] stress-ng-daemon: exited [8322]
(instance 3)
stress-ng: 13:24:42.91 debug: [8318] process [8319] terminated
stress-ng: 13:24:42.91 debug: [8318] process [8320] terminated
stress-ng: 13:24:42.91 debug: [8321] stress-ng-daemon: exited [8321]
(instance 2)
stress-ng: 13:24:42.91 debug: [8318] process [8321] terminated
stress-ng: 13:24:42.91 debug: [8318] process [8322] terminated
stress-ng: 13:24:42.91 info:  [8318] successful run completed in 1.00s
daemon PASSED
/tmp/autopkgtest-lxc.aq8hcycy/downtmp/build.0Fb/src/debian/tests/fast-test-all:
58: Cannot fork
bash: fork: retry: Resource temporarily unavailable
autopkgtest [13:24:46]: test fast-test-all: ---]







signature.asc
Description: OpenPGP digital signature

Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps

[Axel Beckert]

Hi Guillem,

Guillem Jover wrote:
> > A maybe a bit safer variant would be to call dpkg-checkbuilddeps
> > beforehand and filter out build-essential if it appears. That way
> > around it should hurt way less to hardcode the package name.
> 
> You can simply use --ignore-builtin-builddeps. :)

Argh! It could have been so simple! Thanks!

Unfortunately I just uploaded a new equivs version less
than a day ago.

Will convert this from -d to this anyway with the next upload.

Will though probably wait until the current version has been migrated
to testing due to the RC bug fix. (Although this is the better fix for
that issue.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#962619: libsrt-gnutls-dev: pkg-config in wrong multiarch path (i686 not i386)

[Jonas Smedegaard]

Package: libsrt-gnutls-dev
Version: 1.4.1-2
Severity: serious
Justification: Policy 9.1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libsrt-gnutls-dev on i386 provide librares below /usr/lib/i386-linux-gnu
but pkgconfig files wrongly below /usr/lib/i686-linux-gnu - leading to
failure linking from other packages.

See https://packages.debian.org/sid/i386/libsrt-gnutls-dev/filelist for
the wrong paths, and
https://buildd.debian.org/status/fetch.php?pkg=ffmpeg=i386=7%3A4.2.2-3=1591806471=0
for an example of a failed build caused by this issue.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl7hLIEACgkQLHwxRsGg
ASHPaxAAnVHcql5W1WvtZ7MIrgyNElDB09xa9g2Lan2ZAC35amrK7JoHTCDYeiXo
g7BfB7wjwRZ3U1r8dzqrz2lawHEn9maUydnyZHK8KuLCl9ga+B4Y8xjBiTZ8BgIL
Bjyo7f8MYT0nEEner5tDYdw4RauuOPIcANwbdJX7veNsWLOwmsewdV63lDWfMK1U
Pztj8R6049McuvRlbCr34prdEgJYHM5vqt4YIPXHEx6QO/AXyjKF8tQ6xij9HdLb
B0irPrifsjg8nVRYKPVCIWCgZELjCV05mnvvSrkg656zvk8UTUGjqASqLVriV4nV
Y208DWa3yczrs/vYFfbGvu3jEpdbfaNM6+/nItiRG/EcaiyaQZcMRGZYid5oZB7q
uAfF+GNk2mOcUHVe6PbZLwqFLuBghEv0ZwuinnEtJ8VJoLkT+gMFq+QaTvkJpZzW
ebK+/yyfbfL3RLIzVxg2r6bjHdVb+2difCOx+myV/OLoskjn4JQ1a1atWWdajomf
42zlkIBiQKjV5h3n/nXifsxSaic/I5qTxUVnW+/5G7RvE/ZlKs5lHDA3UaHnYx6G
zPkma6VZiTkJ9m9njrrvPWCKw1OLtBo485VGL4YmaafVsQVER0ZszMesio/tHnkv
uPGrYjLAkW10UIv4EVJu7tjP3UH0Ayrezsjv1WC9EUakc8K7kno=
=yiac
-END PGP SIGNATURE-

Bug#962587: suitesparse: home page now defunct

[Sébastien Villemot]

Le mercredi 10 juin 2020 à 19:52 +0800, Drew Parsons a écrit :

> The suitesparse home page 
> http://www.suitesparse.com/
>  now seems to be
> a broken link.
> 
> Tim Davis' git repo points at
> http://faculty.cse.tamu.edu/davis/suitesparse.html
> 
> which looks mostly up-to-date (references v5.6.0 rather than v5.7.2
> but looks otherwise current)
> 
> Looks like the suitesparse homepage should be switched to the tamu.edu
> site.

My understanding is that http://www.suitesparse.com still works and
redirects to https://faculty.cse.tamu.edu/davis/suitesparse.html
(https, not http). But the latter indeed seems to have an SSL configuration 
problem.

I’ll clarify this with upstream.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#961380: fixed in guitarix 0.39.0+dfsg1-3.1

[Daniel Lenharo de Souza]

Control: tags 961380 + patch
Control: tags 961380 + pending
  
Dear maintainer,

I've prepared an NMU for guitarix (versioned as 0.39.0+dfsg1-3.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru guitarix-0.39.0+dfsg1/debian/changelog 
guitarix-0.39.0+dfsg1/debian/changelog
--- guitarix-0.39.0+dfsg1/debian/changelog  2020-05-21 13:43:50.0 -0300
+++ guitarix-0.39.0+dfsg1/debian/changelog  2020-06-10 08:50:55.0 -0300
@@ -1,3 +1,11 @@
+guitarix (0.39.0+dfsg1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Added --disable-sse parameter to fix port baseline in i386.
+Thanks to Adrian Bunk . (Closes: #961380)
+
+ -- Daniel Lenharo de Souza   Wed, 10 Jun 2020 08:50:55 
-0300
+
 guitarix (0.39.0+dfsg1-3) unstable; urgency=medium

* Fix LV2 types (Closes: #960250)
diff -Nru guitarix-0.39.0+dfsg1/debian/rules guitarix-0.39.0+dfsg1/debian/rules
--- guitarix-0.39.0+dfsg1/debian/rules  2020-01-21 16:04:58.0 -0300
+++ guitarix-0.39.0+dfsg1/debian/rules  2020-06-09 15:39:39.0 -0300
@@ -16,7 +16,7 @@
--cxxflags="$(shell dpkg-buildflags --get CXXFLAGS) \
$(shell dpkg-buildflags --get CPPFLAGS)" \
--ldflags="$(shell dpkg-buildflags --get LDFLAGS) -Wl,--as-needed" -v \
-   --shared-lib --lib-dev --glade-support --enable-lfs --ladspa
+   --shared-lib --lib-dev --glade-support --enable-lfs --ladspa 
--disable-sse

 override_dh_makeshlibs:
dh_makeshlibs -V


-- 
Daniel Lenharo de Souza
Curitiba - Brasil







signature.asc
Description: OpenPGP digital signature

Bug#962618: ITP: jcabi-log - Static Wrapper of SLF4

[Mechtilde Stehmann]

Package: wnpp
Severity: wishlist

* Package name : libjcabi-log-java
  Version : x.y.z
  Upstream Author : Name 
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : Static Wrapper of SLF4

Logger is a convenient static wrapper of slf4j (don't forget to include
one of SLF4J Bindings into the project)



* Why is this package useful/relevant?
  Is it a dependency for another package?
  It is a dependency of J-Lawyer (RFP: #962415)

* Do you use it yourself?
* If there are other packages providing similar functionality,
  how does it compare? No
* How do you plan to maintain it? Do you plan to maintain it
  inside a packaging team?
  (check list at https://wiki.debian.org/Teams)
  I want to maintain it in the Java-Team
* Are you looking for co-maintainers? Do you need a sponsor?

Kind regards

...--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#962616: webkit2gtk: FTBFS on mipsel

[Alberto Garcia]

On Wed, Jun 10, 2020 at 08:08:27PM +0200, Sebastian Ramacher wrote:
> | Exception: gtkdoc-scangobj produced a non-zero return code 250
> | Command:
> |   gtkdoc-scangobj --module=webkit2gtk-4.0
> | Error output:
> |   
> |
> | ninja: build stopped: subcommand failed.

I've seen this several times, and it seems to happen randomly, and
only on mipsel. I haven't been able to reproduce it in a buildd.

I suspect it's a bug in gtk-doc-tools ?

Berto

Bug#962617: RFS: audiolink/0.05-4 [ITA] -- makes managing and searching for music easier

[Gleisson Jesuino Joaquim Cardoso]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: audiolink
   Version : 0.05-4
   Upstream Author : Amit Shah 
 * URL : http://audiolink.sourceforge.net/
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/audiolink
   Section : sound

It builds those binary packages:

  audiolink - makes managing and searching for music easier

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/audiolink/audiolink_0.05-4.dsc

Changes since the last upload:

   * New maintainer. (Closes: #831544)
   * Using new DH level format. Consequently:
   - debian/compat: removed.
   - debian/control: changed from 'debhelper' to 'debhelper-compat' in
 Build-Depends field and bumped level to 13.
   * debian/control:
   - Added 'Rules-Requires-Root: no' to source stanza.
   - Created VCS fields.
   - Bumped Standards-Version to 4.5.0.
   * debian/copyright:
   - Migrated to new format 1.0.
   - Updated all data.
   * debian/patches/01_debian-changes.patch:
   - Renamed the numeric prefix.
   - Updated header and data.
   * debian/patches/02_fix-spelling-error.patch: fix spelling error in manpage.
   * debian/patches/series: changed order application.
   * debian/README.Debian: drop.
   * debian/salsa-ci.yml: created to perform Salsa CI tests.
   * debian/tests/control: created to perform CI tests.
   * debian/upstream/metadata: created.
   * debian/watch: created.

Regards,

Gleisson Jesuino Joaquim Cardoso.

Bug#953727: fixed in xdebug 2.9.6+2.8.1+2.5.5-1

[Paul Gevers]

Hi Ondřej,

On 10-06-2020 09:22, Debian FTP Masters wrote:
>  xdebug (2.9.6+2.8.1+2.5.5-1) unstable; urgency=medium
>  .
>* New upstream version 2.9.6+2.8.1+2.5.5
>* Add Breaks: php-defaults (<= 69~) to unbreak php-codecoverage
  ^ is one character too much. The
idea was to add a breaks to the version currently in testing. So, either
break <= 69 or breaks << 70~.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#962616: webkit2gtk: FTBFS on mipsel

[Sebastian Ramacher]

Source: webkit2gtk
Version: 2.82.2-2
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

The rebuild of webkit2gtk for the icu transition has failed on mipsel:
| 2020-06-10 14:02:24,288:scangobj.py:execute_command:1199:WARNING:Running 
scanner failed: -6, command: ./webkit2gtk-4.0-scan
| Traceback (most recent call last):
|   File "/<>/Tools/gtkdoc/generate-gtkdoc", line 254, in 
| build_gtkdoc_for_wkgtk(arguments)
|   File "/<>/Tools/gtkdoc/generate-gtkdoc", line 224, in 
build_gtkdoc_for_wkgtk
| saw_warnings = generate_documentation(webkit2_generator)
|   File "/<>/Tools/gtkdoc/generate-gtkdoc", line 158, in 
generate_documentation
| return generate_doc(generator, arguments.skip_html)
|   File "/<>/Tools/gtkdoc/generate-gtkdoc", line 145, in 
generate_doc
| generator.generate(not skip_html)
|   File "/<>/Tools/gtkdoc/gtkdoc.py", line 147, in generate
| self._run_gtkdoc_scangobj()
|   File "/<>/Tools/gtkdoc/gtkdoc.py", line 337, in 
_run_gtkdoc_scangobj
| self._run_command(['gtkdoc-scangobj', '--module=%s' % self.module_name],
|   File "/<>/Tools/gtkdoc/gtkdoc.py", line 218, in _run_command
| raise Exception(('%s produced a non-zero return code %i\n'
| Exception: gtkdoc-scangobj produced a non-zero return code 250
| Command:
|   gtkdoc-scangobj --module=webkit2gtk-4.0
| Error output:
|   
|
| ninja: build stopped: subcommand failed.

See
https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk=mipsel=2.28.2-2%2Bb1=1591797766=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#960193: ICU rebuilds

[Sebastian Ramacher]

Hi Peter

On 2020-06-10 18:28:24 +0100, Peter wrote:
> On 09/06/2020 21:19, Sebastian Ramacher wrote:
> > On 2020-06-09 19:56:00 +0200, László Böszörményi (GCS) wrote:
> >> Hi,
> >>
> >> On Tue, Jun 9, 2020 at 12:15 PM Pino Toscano  wrote:
> >>> can you please rebuild for the ICU transition also the packages in
> >>> experimental?
> >>  I can't schedule binNMUs myself, but Sebastian can.
> >>
> >> Please, if you have time schedule binNMUs of the following packages
> >> with ICU 67.1 in _experimental_:
> >>> dcmtk
> >>> gnustep-base
> >>> gnustep-gui
> >>> libqalculate
> >>> performous
> >>> qtbase-opensource-src
> >>> qtlocation-opensource-src
> >>> qtwebkit-opensource-src
> >>> webkit2gtk
> >>> zimwriterfs
> > Scheduled.
> >
> > Cheers
> Hi,
> 
> Please could someone add qosmic to the binNMU list?
>   { https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962095 }

Why would it need a binNMU? It doesn't depend on libicu63.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962594: grub-efi-amd64: GRUB-EFI reports: /dev/sda: open failed

[Heinrich Schuchardt]

On 6/10/20 4:09 PM, Steve McIntyre wrote:

But I assume you must have a /dev/sda device file. I see similar
locally on my laptop, where /dev/sda is a SATA drive and /dev/sdb is
an SD reader with nothing inserted:

# ls -al /dev/sd?
brw-rw 1 root disk 8,  0 Jun 10 06:25 /dev/sda
brw-rw 1 root disk 8, 16 Apr 19 03:15 /dev/sdb

$ sudo fdisk -l /dev/sd?
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: CT2000MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 98589918-89BC-48F0-9D29-CFD892E47618

Device   StartEndSectors  Size Type
/dev/sda1 204810506231048576  512M EFI System
/dev/sda2  10506241550335 499712  244M Linux filesystem
/dev/sda3  1550336 3907028991 3905478656  1.8T Linux filesystem

fdisk: cannot open /dev/sdb: No medium found

Your system is probably similar...


Thanks Steve for the hint where to look and confirming that you also get
these superfluous warnings.

$ ls /dev/sd*
/dev/sda

$ sudo udevadm info -a -n /dev/sda

  looking at device
'/devices/pci:00/:00:14.0/usb2/2-3/2-3:1.0/host0/target0:0:0/0:0:0:0/block/sda':
KERNEL=="sda"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ext_range}=="256"
ATTR{range}=="16"
ATTR{discard_alignment}=="0"
ATTR{events_poll_msecs}=="-1"
ATTR{removable}=="1"
ATTR{alignment_offset}=="0"
ATTR{events}=="media_change"
ATTR{inflight}=="   00"
ATTR{events_async}==""
ATTR{ro}=="0"
ATTR{stat}=="   202400
  000   120000
  000"
ATTR{size}=="0"
ATTR{capability}=="51"
ATTR{hidden}=="0"

$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0bda:0316 Realtek Semiconductor Corp. USB3.0-CRW
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 5986:2113 Acer, Inc Integrated Camera
Bus 001 Device 003: ID 8087:0a2b Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

/dev/sda corresponds to the *empty* USB card reader 0bda:0316.

lsblk does not show /dev/sda if there is no card inserted. So why should
GRUB not do the same and avoid superfluous and irritating user messages?

Best regards

Heinrich

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[Thorsten Glaser]

On Wed, 10 Jun 2020, YunQiang Su wrote:

> But in fact, the multiarch cross-toolchain is broken day-by-day,

Eh, fix those instead. Everyone else already has to rely on
Multi-Arch; for example, I have to enable amd64 on my i386
and x32 systems to get the kernel.

> and is always un-installable.

No?

tglase@tglase:~ $ apt-get -s install gcc-i686-linux-gnu:amd64
NOTE: This is only a simulation!
  apt-get needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree
Reading state information... Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  binutils-i686-linux-gnu cpp-9-i686-linux-gnu cpp-i686-linux-gnu 
gcc-10-cross-base gcc-9-cross-base
  gcc-9-i686-linux-gnu gcc-9-i686-linux-gnu-base libasan5-i386-cross 
libatomic1-i386-cross libc6-i386-cross
  libgcc-9-dev-i386-cross libgcc-s1-i386-cross libgomp1-i386-cross 
libitm1-i386-cross libquadmath0-i386-cross
  libstdc++6-i386-cross libubsan1-i386-cross
Suggested packages:
  gcc-9-locales cpp-doc gcc-9-multilib-i686-linux-gnu make:amd64 
gdb-i686-linux-gnu:amd64 gcc-doc:amd64
Recommended packages:
  libc6-dev-i386-cross libc6-dev-i386-cross:amd64 | libc-dev-i386-cross:amd64
The following NEW packages will be installed:
  binutils-i686-linux-gnu cpp-9-i686-linux-gnu cpp-i686-linux-gnu 
gcc-10-cross-base gcc-9-cross-base
  gcc-9-i686-linux-gnu gcc-9-i686-linux-gnu-base gcc-i686-linux-gnu:amd64 
libasan5-i386-cross
  libatomic1-i386-cross libc6-i386-cross libgcc-9-dev-i386-cross 
libgcc-s1-i386-cross libgomp1-i386-cross
  libitm1-i386-cross libquadmath0-i386-cross libstdc++6-i386-cross 
libubsan1-i386-cross
0 upgraded, 18 newly installed, 0 to remove and 8 not upgraded.
Inst gcc-9-i686-linux-gnu-base (9.3.0-13cross1 
ftp.ports.debian.org:1.0/unstable [x32])
Inst cpp-9-i686-linux-gnu (9.3.0-13cross1 ftp.ports.debian.org:1.0/unstable 
[x32])
Inst cpp-i686-linux-gnu (4:9.2.1-3.1 ftp.ports.debian.org:1.0/unstable [x32])
Inst gcc-10-cross-base (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst gcc-9-cross-base (9.3.0-13cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst binutils-i686-linux-gnu (2.34-8 ftp.ports.debian.org:1.0/unstable [x32])
Inst libc6-i386-cross (2.30-2cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst libgcc-s1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst libgomp1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst libitm1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst libatomic1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst libasan5-i386-cross (9.3.0-13cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst libstdc++6-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst libubsan1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst libquadmath0-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst libgcc-9-dev-i386-cross (9.3.0-13cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Inst gcc-9-i686-linux-gnu (9.3.0-13cross1 ftp.ports.debian.org:1.0/unstable 
[x32])
Inst gcc-i686-linux-gnu:amd64 (4:9.2.1-3.1 Debian:unstable [amd64])
Conf gcc-9-i686-linux-gnu-base (9.3.0-13cross1 
ftp.ports.debian.org:1.0/unstable [x32])
Conf cpp-9-i686-linux-gnu (9.3.0-13cross1 ftp.ports.debian.org:1.0/unstable 
[x32])
Conf cpp-i686-linux-gnu (4:9.2.1-3.1 ftp.ports.debian.org:1.0/unstable [x32])
Conf gcc-10-cross-base (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf gcc-9-cross-base (9.3.0-13cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf binutils-i686-linux-gnu (2.34-8 ftp.ports.debian.org:1.0/unstable [x32])
Conf libc6-i386-cross (2.30-2cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf libgcc-s1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf libgomp1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf libitm1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf libatomic1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf libasan5-i386-cross (9.3.0-13cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf libstdc++6-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf libubsan1-i386-cross (10.1.0-3cross1 Debian:unstable, 
ftp.ports.debian.org:1.0/unstable [all])
Conf libquadmath0-i386-cross (10.1.0-3cross1 Debian:unstable, 

Bug#962615: sylfilter: glib error prevent filter working

[Xavier Brochard]

Package: sylfilter
Version: 0.8-6
Severity: grave
Tags: a11y
Justification: renders package unusable

Dear Maintainer,

Sylfilter doesn't work anymore in Sylpheed. 
Sylpheed log contains these lines each time sylfilter is launched:
GLib-DEBUG: posix_spawn avoided (fd close requested) 
** Sylpheed-WARNING: summary_junk_func: junk filter command returned 127

   * What led up to the situation?
 System update, but user notify me long time after problem start.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Other junk mail filter (Bogofilter) works


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

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

Versions of packages sylfilter depends on:
ii  libc6  2.28-10
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libqdbm14  1.8.78-9+b1
ii  libsqlite3-0   3.27.2-3
ii  libsylfilter0  0.8-6

sylfilter recommends no packages.

sylfilter suggests no packages.

-- no debconf information

Bug#962613: bst-external: New upstream version available

[Ben Hutchings]

Source: bst-external
Severity: wishlist

Dear Maintainer,

Please update bst-external to the current upstream version, 0.20.0. 
I'm trying to build Freedesktop-SDK and the version in unstable is too
old to do this.

Ben.

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

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

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#962606: csound: Build-depends on removed package ttf-dejavu

[Sebastian Ramacher]

Control: severity -1 serious

On 2020-06-10 13:15:13 -0400, Boyuan Yang wrote:
> Source: csound
> Severity: grave
> Version: 1:6.14.0~dfsg-5
> X-Debbugs-CC: fsate...@debian.org forrest.cah...@gmail.com
> 
> 
> Dear Debian csound maintainers,
> 
> Your package csound build-depends on package ttf-dejavu, which is a
> transitional package that has been removed since the upload of fonts-
> dejavu/2.37-2.
> 
> Please adjust the build-dependency information and use package name
> fonts-dejavu. Please note that ttf-dejavu and fonts-dejavu provides the
> fonts under *different* paths. Please review your package and make sure
> that the hardcoded paths (if any) have been updated accordingly.

Adjusting the severity accordingly. Build issues are serious.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962614: ntp: leap-seconds.list not updated and update-leap does not read ntp.conf correctly.

[Ken]

Package: ntp
Version: 1:4.2.8p12+dfsg-4
Severity: normal

Dear Maintainer,

I have started to receive errors such as the following:

 Jun 10 14:08:24 blackab3 ntpd[592]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 18 days

I tried to run update-leap to update the file, but received the following error:

 No leapfile directive in /etc/ntp.conf; leapfile location not known

Looking in ntp.conf, I see the following:

  # Leap seconds definition provided by tzdata
  leapfile /usr/share/zoneinfo/leap-seconds.list

I hand edited a test ntp.conf with just the setting (incase the file was 
corrupt), but it gave the error.

Running the command with the direct option worked:

  update-leap -L /usr/share/zoneinfo/leap-seconds.list

This is strange, the ntp.conf file appears correct - but it is not being read 
by update-leap.

-Ken

-- 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/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ntp depends on:
ii  adduser3.118
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libedit2   3.1-20181209-1
ii  libopts25  1:5.18.12-4
ii  libssl1.1  1.1.1d-0+deb10u3
ii  lsb-base   10.2019051400
ii  netbase5.6
ii  tzdata 2019c-0+deb10u1

Versions of packages ntp recommends:
ii  perl  5.28.1-6
ii  sntp  1:4.2.8p12+dfsg-4

Versions of packages ntp suggests:
pn  ntp-doc  

-- no debconf information

Bug#923929: Bug#922794: chromium crashes when started with --remote-debugging-port switch

[Johannes Schauer]

Hi,

On Thu, 7 Mar 2019 11:39:02 +0100 Helmut Grohne  
wrote:
> An autopkgtest in python-selenium could have easily caught this issue. Please
> add one.

https://salsa.debian.org/sagiru-guest/python-selenium/-/merge_requests/2

the code exists. Now you just need to merge it.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#960193: ICU rebuilds

[Peter]

On 09/06/2020 21:19, Sebastian Ramacher wrote:
> On 2020-06-09 19:56:00 +0200, László Böszörményi (GCS) wrote:
>> Hi,
>>
>> On Tue, Jun 9, 2020 at 12:15 PM Pino Toscano  wrote:
>>> can you please rebuild for the ICU transition also the packages in
>>> experimental?
>>  I can't schedule binNMUs myself, but Sebastian can.
>>
>> Please, if you have time schedule binNMUs of the following packages
>> with ICU 67.1 in _experimental_:
>>> dcmtk
>>> gnustep-base
>>> gnustep-gui
>>> libqalculate
>>> performous
>>> qtbase-opensource-src
>>> qtlocation-opensource-src
>>> qtwebkit-opensource-src
>>> webkit2gtk
>>> zimwriterfs
> Scheduled.
>
> Cheers
Hi,

Please could someone add qosmic to the binNMU list?
  { https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962095 }

Cheers,
Peter

Bug#962611: ITP: octave-mcxlab -- A GPU Monte Carlo 3-D photon transport simulator for MATLAB/Octave

[Qianqian Fang]

Package: wnpp
Severity: wishlist

Name:   octave-mcxlab
Version:    0.5
Summary:    A GPU Monte Carlo 3-D photon transport simulator for 
MATLAB/Octave

License:    GPLv2+
URL:    https://mcx.space/

Description:
Monte Carlo eXtreme OpenCL (MCX-CL) is a fast photon transport simulation
software for 3D heterogeneous turbid media, accelerated by GPUs.
MCXLAB-CL is the native MEX version of MCX-CL for Matlab and GNU Octave.
It contains the entire MCX-CL code into a MEX function which can be called
directly inside Matlab or Octave. The input and output files in MCX are
replaced by convenient in-memory struct variables in MCXLAB-CL, thus,
making it much easier to use and interact. Matlab/Octave also provides
convenient plotting and data analysis functions. With MCXLAB-CL, your
analysis can be streamlined and speed-up without involving disk files.

Comment:
I am the upstream author and current package maintainer of this
toolbox for Fedora (https://src.fedoraproject.org/rpms/octave-mcxlab)
I am interested in contributing this octave toolbox to Debian and maintain
this package moving forward.

Bug#962612: ITP: mmc -- A GPU-based mesh-based Monte Carlo (MMC) photon simulator

[Qianqian Fang]

Package: wnpp
Severity: wishlist

Name:   mmc
Version:    1.7.9
Summary:    A GPU-based mesh-based Monte Carlo (MMC) photon simulator
License:    GPLv3+
URL:    https://mcx.space/#mmc

Description:
Mesh-based Monte Carlo (MMC) is a 3D Monte Carlo (MC) simulation software
for photon transport in complex turbid media. MMC combines the strengths
of the MC-based technique and the finite-element (FE) method: on the
one hand, it can handle general media, including low-scattering ones,
as in the MC method; on the other hand, it can use an FE-like tetrahedral
mesh to represent curved boundaries and complex structures, making it
even more accurate, flexible, and memory efficient. MMC uses the
state-of-the-art ray-tracing techniques to simulate photon propagation in
a mesh space. It has been extensively optimized for excellent computational
efficiency and portability. MMC currently supports both multi-threaded
parallel computing and GPU to maximize performance on modern processors.

Comment:
I am the upstream author and current package maintainer of this
toolbox for Fedora (https://src.fedoraproject.org/rpms/mmc)
I am interested in contributing this octave toolbox to Debian and maintain
this package moving forward.

Bug#962610: ITP: brain2mesh -- A fully automated high-quality brain tetrahedral mesh generation toolbox

[Qianqian Fang]

Package: wnpp
Severity: wishlist

Name:   brain2mesh
Version:    0.5
Summary:    A fully automated high-quality brain tetrahedral mesh 
generation toolbox

License:    GPLv2+
URL:    https://mcx.space/brain2mesh

Description:
The Brain2Mesh toolbox provides a streamlined matlab function to convert
a segmented brain volumes and surfaces into a high-quality multi-layered
tetrahedral brain/full head mesh. Typical inputs include segmentation
outputs from SPM, FreeSurfer, FSL etc. This tool does not handle the
segmentation of MRI scans, but examples of how commonly encountered
segmented datasets can be used to create meshes can be found in the
package named brain2mesh-demos.

Comment:
I am the upstream author and current package maintainer of this
toolbox for Fedora (https://src.fedoraproject.org/rpms/octave-brain2mesh)
I am interested in contributing this octave toolbox to Debian.

Bug#960420: Needs versioned dependency on slop

[Antoine Beaupré]

On 2020-05-12 14:25:43, Yuri D'Elia wrote:
> Package: maim
> Version: 5.5.3-1
> Severity: important
>
> I didn't realize maim depended on slop through a dso (I assumed it
> simply called the binary).
>
> slop was updated to 7.5, which broke maim as a result:
>
> maim: error while loading shared libraries: libslopy.so.7.4: cannot open 
> shared object file: No such file or directory
>
> maim definitely needs a versioned dependency on slop in this case to
> avoid breaking.

Agreed. slop should be split in two as well, to have the soname
represented in the package name to respect policy. But then that would
become a huge pain in the arse because it would trigger a transition
every time it would make a new release, which is often.

But yes, as a stopgap, just having maim have a versioned depends would
improve things.

-- 
We have no friends but the mountains.
- Kurdish saying

Bug#962609: ITP: jnifti -- Fast NIfTI-1/2 reader and NIfTI-to-JNIfTI converter for MATLAB/Octave

[Qianqian Fang]

Package: wnpp
Severity: wishlist

Name:   jnifti
Version:    0.5
Summary:    Fast NIfTI-1/2 reader and NIfTI-to-JNIfTI converter for 
MATLAB/Octave

License:    GPLv3+
URL:    https://github.com/fangq/jnifti

Description:
JNIfTI Toolbox is a fully functional NIfTI-1/2 reader/writer that 
supports both

MATLAB and GNU Octave, and is capable of reading/writing both non-compressed
and compressed NIfTI files (.nii, .nii.gz) as well as two-part 
Analyze7.5/NIfTI

files (.hdr/.img and .hdr.gz/.img.gz).  More importantly, this is a toolbox
that converts NIfTI data to its JSON-based replacement, JNIfTI (.jnii for
text-based and .bnii for binary-based), defined by the JNIfTI specification
(http://github.com/fangq/jnifti). JNIfTI is a much more flexible, 
human-readable
and extensible file format compared to the more rigid and opaque NIfTI 
format,

making the data much easier to manipulate and share.

Comment:
I am the upstream author and current package maintainer of this
toolbox for Fedora (https://src.fedoraproject.org/rpms/octave-jnifti)
I am interested in contributing this octave toolbox to Debian.

Bug#962608: ITP: iso2mesh -- A 3D surface and volumetric mesh generator for MATLAB/Octave

[Qianqian Fang]

Package: wnpp
Severity: wishlist

Name:   iso2mesh
Version:    1.9.2
Summary:    A 3D surface and volumetric mesh generator for MATLAB/Octave
License:    GPLv3+
URL:    https://iso2mesh.sf.net

Description:
Iso2Mesh is a MATLAB/Octave-based mesh generation toolbox, designed
for easy creation of high quality surface and tetrahedral meshes from 3D
volumetric images. It contains a rich set of mesh processing 
scripts/programs,
working either independently or interacting with external free meshing 
utilities.

Iso2Mesh toolbox can directly convert a 3D image stack, including binary,
segmented or gray-scale images such as MRI or CT scans, into quality 
volumetric
meshes. This makes it particularly suitable for multi-modality medical 
imaging

data analysis and multi-physics modeling. Iso2Mesh is cross-platform and is
compatible with both MATLAB and GNU Octave.

Comment:
I am the upstream author and current package maintainer of this
toolbox for Fedora (https://src.fedoraproject.org/rpms/octave-iso2mesh)
I am interested in contributing this octave toolbox to Debian.

Bug#962607: ITP: jsonlab -- A native JSON/UBJSON/MassagePack encoder/decoder for Octave

[Qianqian Fang]

Package: wnpp
Severity: wishlist

Name:   jsonlab
Version:    2.0
Summary:    A native JSON/UBJSON/MassagePack encoder/decoder for 
MATLAB/Octave

License:    GPLv3+
URL:    https://github.com/fangq/jsonlab

Description:
JSONLab is a free and open-source JSON/UBJSON/MessagePack encoder and
a decoder in the native MATLAB language. It can be used to convert a MATLAB
data structure (array, struct, cell, struct array, cell array, and 
objects) to

JSON/UBJSON/MessagePack formatted strings, or to decode a
JSON/UBJSON/MessagePack file into MATLAB data structure. JSONLab
supports both MATLAB and GNU Octave.

Comment:
I am the upstream author and current package maintainer of this
library/toolbox for Fedora 
(https://src.fedoraproject.org/rpms/octave-jsonlab)

I am interested in contributing this octave toolbox to Debian.
First time Debian contributor, see
https://lists.debian.org/debian-science/2020/06/msg6.html

Bug#961106: Telegram desktop issue

[morteza jamareh]

Hi
Did you check the bug?
It is really frustrating..
I would be thankful if you resolve the issue
regards


On Sat, May 30, 2020 at 8:14 PM morteza jamareh 
wrote:

> Hi
> about: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961106
> Letters q,w,s,x,z,v etc are not allowed to be used in credential section.
> And I attached it.
> Also when I click on mtproxy link the proxy is no opened for me.
> I have tried it on more than 5 separated cases in both stable and testing
> releases,
> But in ubuntu I don't have any problem.
> I would be thankful if you respond.
> best wishes
> Love debian 
>

Bug#962606: csound: Build-depends on removed package ttf-dejavu

[Boyuan Yang]

Source: csound
Severity: grave
Version: 1:6.14.0~dfsg-5
X-Debbugs-CC: fsate...@debian.org forrest.cah...@gmail.com


Dear Debian csound maintainers,

Your package csound build-depends on package ttf-dejavu, which is a
transitional package that has been removed since the upload of fonts-
dejavu/2.37-2.

Please adjust the build-dependency information and use package name
fonts-dejavu. Please note that ttf-dejavu and fonts-dejavu provides the
fonts under *different* paths. Please review your package and make sure
that the hardcoded paths (if any) have been updated accordingly.

-- 
Regards,
Boyuan Yang


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

Bug#962605: nouveau: Complete freeze

[simon]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1
Severity: important
File: nouveau

Dear Maintainer,

   * What led up to the situation?
Nothing I can think of.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I am unable to try to connect via ssh to see if the system was still alive.
   * What was the outcome of this action?
The video completely froze.
   * What outcome did you expect instead?

Here is the relevant content from kern.log:

Jun 10 17:53:55 simon kernel: [71840.100209] nouveau :01:00.0: gr: TRAP ch 
11 [003f6ed000 systemd-logind[788]]
Jun 10 17:53:55 simon kernel: [71840.100219] nouveau :01:00.0: gr: 
GPC0/TPC0/TEX: 8009
Jun 10 17:53:55 simon kernel: [71840.100567] nouveau :01:00.0: gr: TRAP ch 
11 [003f6ed000 systemd-logind[788]]
Jun 10 17:53:55 simon kernel: [71840.100572] nouveau :01:00.0: gr: 
GPC0/TPC0/TEX: 8009
Jun 10 17:53:55 simon kernel: [71840.105078] nouveau :01:00.0: gr: TRAP ch 
11 [003f6ed000 systemd-logind[788]]
Jun 10 17:53:55 simon kernel: [71840.105085] nouveau :01:00.0: gr: 
GPC0/TPC0/TEX: 8009
Jun 10 17:53:55 simon kernel: [71840.105416] nouveau :01:00.0: gr: TRAP ch 
11 [003f6ed000 systemd-logind[788]]
Jun 10 17:53:55 simon kernel: [71840.105420] nouveau :01:00.0: gr: 
GPC0/TPC0/TEX: 8049
Jun 10 17:53:55 simon kernel: [71840.105426] nouveau :01:00.0: fifo: fault 
00 [READ] at 0b2cd000 engine 00 [GR] client 01 [GPC0/T1_0] reason 02 
[PTE] on channel 11 [003f6ed000 systemd-logind[788]]
Jun 10 17:53:55 simon kernel: [71840.105432] nouveau :01:00.0: fifo: 
channel 11: killed
Jun 10 17:53:55 simon kernel: [71840.105433] nouveau :01:00.0: fifo: 
runlist 0: scheduled for recovery
Jun 10 17:53:55 simon kernel: [71840.105435] nouveau :01:00.0: fifo: engine 
0: scheduled for recovery
Jun 10 17:53:55 simon kernel: [71840.105440] nouveau :01:00.0: fifo: engine 
6: scheduled for recovery
Jun 10 17:53:55 simon kernel: [71840.105443] nouveau :01:00.0: 
systemd-logind[788]: channel 11 killed!

I hope I'm reporting this bug to the correct place, and apologize if it is not 
the case.


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208 [GeForce GT 
710B] [10de:128b] (rev a1)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)

Xorg X server log files on system:
--
-rw-r--r-- 1 simon simon 17156 Aug  9  2019 
/home/simon/.local/share/xorg/Xorg.2.log
-rw-r--r-- 1 root  root  16969 Aug  9  2019 /var/log/Xorg.3.log
-rw-r--r-- 1 simon simon 17156 Aug  9  2019 
/home/simon/.local/share/xorg/Xorg.4.log
-rw-r--r-- 1 simon simon 46108 Jun 10 17:57 
/home/simon/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/simon/.local/share/xorg/Xorg.0.log):
--
[82.781] (--) Log file renamed from 
"/home/simon/.local/share/xorg/Xorg.pid-1838.log" to 
"/home/simon/.local/share/xorg/Xorg.0.log"
[82.782] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[82.783] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[82.783] Current Operating System: Linux simon 4.19.0-9-amd64 #1 SMP Debian 
4.19.118-2+deb10u1 (2020-06-07) x86_64
[82.783] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-9-amd64 
root=UUID=9abcd24c-20e2-4f47-bfb2-c82458a877e3 ro quiet i915.enable_rc6=0
[82.783] Build Date: 05 March 2019  08:11:12PM
[82.783] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[82.783] Current version of pixman: 0.36.0
[82.783]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[82.783] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[82.783] (==) Log file: "/home/simon/.local/share/xorg/Xorg.0.log", Time: 
Wed Jun 10 17:57:33 2020
[82.803] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[82.819] (==) No Layout section.  Using the first Screen section.
[82.819] (==) No screen section available. Using defaults.
[82.819] (**) |-->Screen "Default Screen Section" (0)
[82.819] (**) |   |-->Monitor ""
[82.820] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[82.820] (==) Automatically adding devices

Bug#962604: bindata-assetfs should build the utility as a binary package of its own

[Taowa Munene-Tardif]

Source: golang-github-elazarl-go-bindata-assetfs
Severity: important
X-Debbugs-CC: t...@hpe.com
X-Debbugs-CC: only...@debian.org

go-bindata-assetfs, like go-bindata, has a command-line utility that
generates a bindata(_assetfs).go file. While the go-bindata package
includes a binary package for it, go-bindata-assetfs doesn't. This
prevents me from generating that file in a package I'm working on.

Taowa

-- 
Taowa Munene-Tardif
taowa.ca
Montréal

Bug#962603: ITP: zmat -- A portable C-library and MATLAB toolbox for data compression

[Qianqian Fang]

Package: wnpp
Severity: wishlist

Name:   zmat
Version:    0.9.8
Summary:    An easy-to-use data compression library
License:    GPLv3+
URL:    https://github.com/fangq/zmat

Description:
ZMat provides both an easy-to-use C-based data compression library -
libzmat as well a portable mex function to enable 
zlib/gzip/lzma/lzip/lz4/lz4hc

based data compression/decompression and base64 encoding/decoding
support in MATLAB and GNU Octave. It is fast and compact,
can process a large array within a fraction of a second.

Comment:
I am the upstream author and current package maintainer of this
library/toolbox for Fedora (https://src.fedoraproject.org/rpms/zmat ,
https://src.fedoraproject.org/rpms/octave-zmat).
I am interested in contributing this library/octave toolbox to Debian.
First time Debian contributor, see
https://lists.debian.org/debian-science/2020/06/msg6.html
Current packaging files can be found at 
https://salsa.debian.org/fangq/libzmat

Will need mentor/sponsor on finishing up the package.

Bug#961878: libuv1: autopkgtest regression: ./gyp_uv.py: No such file or directory

[Dominique Dumont]

On mardi 9 juin 2020 20:24:38 CEST you wrote:
> autopkgtest is meant to test the *installed* version of your package. It
> seems to me you meant here that you're testing a just built artifact
> instead of the system version. Then autopkgtest doesn't make much sense.

Indeed. As libuv is a only a library, I don't think that patching the build 
system to test an installed library is worth the effort, so I'm going to remove 
 
autopkgtest from libuv

I'm sorry that I did not realize sooner what was going on inside libuv build 
system.

All the best

Dod

Bug#962602: coreutils: head does not report if too few lines are present

[Thure Dührsen]

Package: coreutils
Version: 8.30-3
Severity: normal
Tags: upstream

Dear Maintainer,

When requesting the first four lines of a ten-line input using

printf '%2d\n' {1..10} | head -n 4

in GNU bash, the output is

 1
 2
 3
 4

as expected. However, when asking for the first 14 lines using

printf '%2d\n' {1..10} | head -n 14

the output is

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

which, strictly speaking, is incorrect, because the output does
not contain exactly 14 lines.

I suggest changing the documentation to read "at most N
lines" instead of just "N lines", mutatis mutandis, in various
places. Alternatively, print a warning "input has too few lines"
or similar. I am undecided as to whether the exit status should
reflect this.


-- 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/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libselinux1  2.8-1+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#962601: manpage-section-mismatch doesn't take into account manpages with multiple binaries

[Sergio Durigan Junior]

Package: lintian
Version: 2.80.0
Severity: normal
Tags: patch

Hi,

I found a lintian limitation while working with a manpage that refers to
two different binaries.  In this scenario, lintian will mistakenly
consider the name of the second binary as the man section number, and
will issue a "manpage-section-mismatch" warning.

Consider a manpage whose header looks like:

  .TH MOUNT.CIFS, MOUNT.SMB3 8 "" "" ""
  .SH NAME
  mount.cifs, mount.smb3 \- mount using the Common Internet File System (CIFS)
  .
  .nr rst2man-indent-level 0

When we run lintian, we will see:

  W: cifs-utils: manpage-section-mismatch usr/share/man/man8/mount.cifs.8.gz:3 
8 != MOUNT.SMB3

However, according to lexgrog(1) and other sources, it is possible to
specify multiple programs in the .TH directive, as long as they are
separated by a comma and a whitespace, which is the case here.

I'd like to propose the following patch to address the problem.  The
idea is simple: after calling Text::ParseWords::parse_line, we check to
see if the first package name has a comma as the last char.  If it does,
then we assume that there will be at least one other package name
listed, and advance an index.  When we reach a package name whose last
char is not a comma, we then assume that the next field is the manpage
section number.

I tested with the problematic manpage I have here, and it works.  I also
tested with other non-problematic manpages, and they still work as well.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

From d8cbe8d82733178589c30adff2335b37b26b3c8a Mon Sep 17 00:00:00 2001
From: Sergio Durigan Junior 
Date: Wed, 10 Jun 2020 12:49:53 -0400
Subject: [PATCH] Adjust manpage-section-mismatch to accept manpages referring
 to more than one program

---
 checks/documentation/man.pm | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/checks/documentation/man.pm b/checks/documentation/man.pm
index 8092e023d..371552b6f 100644
--- a/checks/documentation/man.pm
+++ b/checks/documentation/man.pm
@@ -296,8 +296,20 @@ sub files {
 chomp $line;
 next if $line =~ /^\.\\\"/; # comments .\"
 if ($line =~ /^\.TH\s/) { # header
-my (undef, undef, $th_section, undef)
+my @th_fields
   = Text::ParseWords::parse_line('\s+', 0, $line);
+my $pkgname_idx = 1;
+# Iterate over possible package names.  If there is
+# more than one, they will be separated by a comma and
+# a whitespace.  In case we find the comma, we advance
+# $pkgname_idx.
+while (substr($th_fields[$pkgname_idx], -1) eq ',') {
+$pkgname_idx++;
+}
+# We're now at the last package, so we should be able
+# to obtain the manpage section number by incrementing
+# 1 to the index.
+my $th_section = $th_fields[++$pkgname_idx];
 if ($th_section && (lc($fn_section) ne lc($th_section))) {
 $self->tag('manpage-section-mismatch',
 "$file:$lc $fn_section != $th_section");
-- 
2.26.2



signature.asc
Description: PGP signature

Bug#962600: RFS: etktab/3.2-11 [ITA] -- ASCII guitar tab editor

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "etktab":

 * Package name: etktab
   Version : 3.2-11
   Upstream Author : Jason Sonnenschein 
 * URL : https://sourceforge.net/projects/etktab/
 * License : Artistic-1.0
 * Vcs : https://salsa.debian.org/debian/etktab
   Section : sound

It builds those binary packages:

  etktab - ASCII guitar tab editor

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/etktab/etktab_3.2-11.dsc

Changes since the last upload:

  * New maintainer. (Closes: #812615)

Regards,

--
  Fabio Augusto De Muzio Tobich

Bug#962599: ITP: adaptive-wrap-el -- smart line-wrapping with wrap-prefix

[Lev Lamberov]

Package: wnpp
Owner: Lev Lamberov 
Severity: wishlist

* Package name: adaptive-wrap-el
  Version : 0.7
  Upstream Author : Stephen Berman , Stefan Monnier 

* URL or Web page : https://elpa.gnu.org/packages/adaptive-wrap.html
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : smart line-wrapping with wrap-prefix

This package provides the `adaptive-wrap-prefix-mode' minor mode which
sets the wrap-prefix property on the fly so that single-long-line
paragraphs get word-wrapped in a way similar to what you'd get with M-q
using adaptive-fill-mode, but without actually changing the buffer's
text.

Bug#855549: apt should have a history command which shows what updates/upgrades and removals were done to packages

[Patrick Häcker]

You can use apt-revert from Salsa (https://salsa.debian.org/PatH/apt-revert)
to view the history.

Kind regards
Patrick

On Mon, 20 Feb 2017 06:25:47 +0530 =?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgpYDgpLc=?
=  wrote:
> Package: apt
> Version: 1.4~rc1
> Severity: wishlist
>
> Dear Maintainer,
>
> Looking at apt --help it gives the following options -
>
> [$] apt --help
>
> apt 1.4~rc1 (amd64)
> Usage: apt [options] command
>
> apt is a commandline package manager and provides commands for
> searching and managing as well as querying information about packages.
> It provides the same functionality as the specialized APT tools, like
> apt-get and apt-cache, but enables options more suitable for
> interactive use by default.
>
> Most used commands:
>   list - list packages based on package names
>   search - search in package descriptions
>   show - show package details
>   install - install packages
>   remove - remove packages
>   autoremove - Remove automatically all unused packages
>   update - update list of available packages
>   upgrade - upgrade the system by installing/upgrading packages
>   full-upgrade - upgrade the system by removing/installing/upgrading
packages
>   edit-sources - edit the source information file
>
> See apt(8) for more information about the available commands.
> Configuration options and syntax is detailed in apt.conf(5).
> Information about how to configure sources can be found in sources.list(5).
> Package and version choices can be expressed via apt_preferences(5).
> Security details are available in apt-secure(8).
>  This APT has Super Cow Powers.
>
> While all the above options are good, one option which is missing and
> should be there is $ apt history which gives an output from
>
> Doing a less /var/log/apt/history.log gives the following -
>
> Start-Date: 2017-02-20  05:07:11
> Requested-By: shirish (1000)
> Upgrade: libmpx0:amd64 (5.4.1-4, 5.4.1-5), libgcj16:amd64 (5.4.1-4,
> 5.4.1-5), libgcc-5-dev:amd64 (5.4.1-4, 5.4.1-5),
> gcj-5-jre-headless:amd64 (5.4.1-4, 5.4.1-5), cpp-5:amd64 (5.4.1-4,
> 5.4.1-5), binutils:amd64 (2.27.90.20170124-2, 2.27.90.20170218-1),
> libgcj16-awt:amd64 (5.4.1-4, 5.4.1-5), gcj-5-jre:amd64 (5.4.1-4,
> 5.4.1-5), libgfortran-5-dev:amd64 (5.4.1-4, 5.4.1-5), libasan2:amd64
> (5.4.1-4, 5.4.1-5), gcc-5-base:amd64 (5.4.1-4, 5.4.1-5),
> gcj-5-jre-lib:amd64 (5.4.1-4, 5.4.1-5), libstdc++-5-dev:amd64
> (5.4.1-4, 5.4.1-5), g++-5:amd64 (5.4.1-4, 5.4.1-5), gcc-5:amd64
> (5.4.1-4, 5.4.1-5), gfortran-5:amd64 (5.4.1-4, 5.4.1-5)
> End-Date: 2017-02-20  05:08:44
>
> Now as can be seen from the excerpt I took from /var/log/apt/history.log
>
> Would be nice if the output could be prettifed, means no package


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

Bug#962598: RFS: mpack/1.6-15 [ITA] -- tools for encoding/decoding MIME messages

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mpack":

 * Package name: mpack
   Version : 1.6-15
   Upstream Author : Carnegie Mellon University
 * URL : ftp://ftp.andrew.cmu.edu/pub/mpack/
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/mpack
   Section : mail

It builds those binary packages:

  mpack - tools for encoding/decoding MIME messages

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/m/mpack/mpack_1.6-15.dsc

Changes since the last upload:

  * New maintainer. (Closes: #925069)

Regards,

--
  Fabio Augusto De Muzio Tobich


pgp92VvP9G46N.pgp
Description: PGP signature

Bug#942622: Would the Games Team adopt Lightyears (pygame based, Python 3 port available)?

[Scott Kitterman]

On Wednesday, June 10, 2020 12:02:48 PM EDT Olek Wojnar wrote:
> On Wed, Jun 10, 2020 at 11:48 AM Scott Kitterman 
> 
> wrote:
> > The only one who ever uploaded the package does not appear to be active in
> > Debian any longer, so I would suggest you go ahead.
> 
> Thanks, Scott! (PS Removed said inactive person from this email thread)
> 
>  Python Apps Team: If you have no objections, I would like to transfer this
> repo [1] from Python Apps Team to Games Team since Steve Cotton wants to
> take over maintaining it. Please let me know if you have any concerns!
> 
> -Olek
> 
> [1] https://salsa.debian.org/python-team/applications/lightyears

As a practical matter the package is orphaned.  Please go ahead.

Scott K

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

Bug#942622: Would the Games Team adopt Lightyears (pygame based, Python 3 port available)?

[Olek Wojnar]

On Wed, Jun 10, 2020 at 11:48 AM Scott Kitterman 
wrote:

>
> The only one who ever uploaded the package does not appear to be active in
> Debian any longer, so I would suggest you go ahead.
>

Thanks, Scott! (PS Removed said inactive person from this email thread)

 Python Apps Team: If you have no objections, I would like to transfer this
repo [1] from Python Apps Team to Games Team since Steve Cotton wants to
take over maintaining it. Please let me know if you have any concerns!

-Olek

[1] https://salsa.debian.org/python-team/applications/lightyears

Bug#658198: Autocompletion: 'ls --n' first returns 'ls --n-g'.

[Daniel Shahaf]

A. Costa wrote on Tue, Jan 31, 2012 at 18:08:57 -0500:
> Package: zsh
> Version: 4.3.15-1
> Severity: minor
> 
> Dear Maintainer,
> 
> If I do:
> 
> ls --n
> 
> ...the first autocompletion from 'zsh' is:
> 
> ls --n-g
> 
> Of course 'ls' has no '--n-g' option.
> 

No, but it does have --no-group and --numeric-uid-gid.  It is ambiguous
which one was meant, so zsh completes the unambiguous parts and asks you
to type in the rest: that's why you get «--n-g» with the cursor
as shown.  At that point can type «o» to complete the former option
and either «u» or «-» to complete the latter.  This is due to
matchspecs, as described under the path-completion style but with
hyphens rather than slashes.  (The gory details are in the manual under
"Completion matching control".)

If anything, the bug here is that «--n-g» doesn't offer
--numeric-uid-gid, even though that option's existence was the reason
--no-group wasn't offered immediately.  However, I can't reproduce this
one when I set the «menu» style.

> A second  returns:
> 
> ls --no-group
> 
> ...which is a valid 'ls' option.

--no-group is a valid option today.

> I looked in '/usr/share/zsh/functions/Completion/Unix/_ls' for
> clues, but didn't notice anything obviously wrong.  But I'm not
> a 'zsh' expert.

_ls is fine.  The matchspecs are handled elsewhere.  (They're fetched from
a C struct by the «comparguments -M» call in _arguments.)

> Hope this helps...

It does.  Thanks for the report.

Daniel
(Better late than never…)

> 
> 
> PS: This is a spin-off bug from Bug#463507.

Bug#962582: libreoffice: Menu "Tools / Options..." doesn't open; the program freezes

[Rene Engelhard]

Hi,

Am 10.06.20 um 17:20 schrieb Teemu Likonen:
> Rene Engelhard [2020-06-10T17:01:28+02] wrote:
>
>> Am 10.06.20 um 16:50 schrieb Teemu Likonen:
>>> there too and with the same strace output. Both computers have Debian


Impossible. The strace iutout clearly says _nvidia. So it simply cannot

be the same.

>>> 10, KDE Plasma desktop and Libreoffice installed with metapackage
>>> "libreoffice".
>> And both the prioprietary nvidia driver?
> No. The other has some Intel card. It uses a driver which Xorg calls
> "intel" (package xserver-xorg-video-intel).

I have an intel card, too. Just works.


xserver-xorg-video-intel is installed, too, but ttbomk it is

only used if you explicitely have it in Xorg.conf. No Xorg.conf should
suffice

and then it uses modesetting and it just works.

> It seems to me that this is a regression in Libreoffice because before
> it worked several years with the same Nvidia and Intel graphic cards.

maybe, I would call LibreOffice even attempting to do stuff with OpenGL

a bug and regression per se. That train left long ago, though.


Regards,


Rene

Bug#958843: please don't depend on vim-nox

[Raphael Medaer]

Control: retitle -1 Remove vim-nox dependency
Control: owner -1 raph...@medaer.me

Hi John,

Good news, the new upstream release is there (1.1.1). This version doesn't rely 
anymore on Python.

I already started to work on the Debian package but I still have some questions 
about tests that I'm checking with experimented DD.
You'll find the new Debian git repository here: 
https://salsa.debian.org/vim-team/vim-editorconfig

Kind regards,

--
Raphaël Medaer 

Bug#942622: Would the Games Team adopt Lightyears (pygame based, Python 3 port available)?

[Scott Kitterman]

On Wednesday, June 10, 2020 11:39:31 AM EDT Olek Wojnar wrote:
> On Mon, Jun 8, 2020 at 2:03 PM Moritz Mühlenhoff  wrote:
> > Has there been any update wrt lightyears/Py3 being moved to the Debian
> > Games
> > Team?
> 
> I haven't heard anything although I'm still willing to sponsor once we
> verify that the Python Applications Packaging Team is ok with transferring
> this package to the Games Team.
> 
> Any word, Steve?
> 
> -Olek

The only one who ever uploaded the package does not appear to be active in 
Debian any longer, so I would suggest you go ahead.

Scott K


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