Bug#956340: ITP: golang-github-scylladb-termtables -- Fork of github.com/apcera/termtables

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-scylladb-termtables
  Version : 0.0~git20191203.c4c0b6d-1
  Upstream Author : ScyllaDB
* URL : https://github.com/scylladb/termtables
* License : Apache-2.0
  Programming Lang: Go
  Description : Fork of github.com/apcera/termtables

This package is needed for araddon/dateparse

Thank in advance

--
Aloïs Micard 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#953487: fixed in runescape 0.7-1

[Carlos Donizete Froes]

Hi Ivo,

> This new version doesn't fix the autobuilding issue:
> 
> https://buildd.debian.org/status/package.php?p=runescape

I don't understand how the package still has the autobuilding problem. I did
several construction tests via pbuilder and sbuild and there were no problems,
as shown in the attached file. :/

> Looking at the package, I also discovered some other issues, which I will file
> as separate bugs.

Ok, if you can help me with the solution of these problems that you encountered,
I would be very grateful. And I will fix it as soon as possible.

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780
sbuild (Debian sbuild) 0.79.0 (05 February 2020) on debian

+==+
| runescape 0.7-1 (amd64)  Fri, 10 Apr 2020 04:55:06 + |
+==+

Package: runescape
Version: 0.7-1
Source Version: 0.7-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-fc24b32c-2ef2-471e-b205-948f47eacc05'
 with '<>'
I: NOTICE: Log filtering will replace 'build/runescape-sc2aq8/resolver-HIG1xG' 
with '<>'

+--+
| Update chroot|
+--+

Hit:1 https://deb.debian.org/debian unstable InRelease
Reading package lists...
W: Download is performed unsandboxed as root as file 
'/var/lib/apt/lists/partial/deb.debian.org_debian_dists_unstable_InRelease' 
couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/coringao/sandbox/runescape.pkg/runescape_0.7-1.dsc exists in 
/home/coringao/sandbox/runescape.pkg; copying to chroot
I: NOTICE: Log filtering will replace 'build/runescape-sc2aq8/runescape-0.7' 
with '<>'
I: NOTICE: Log filtering will replace 'build/runescape-sc2aq8' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), default-jdk-headless | 
default-jdk, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 12), default-jdk-headless, 
build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [388 B]
Get:5 copy:/<>/apt_archive ./ Packages [466 B]
Fetched 1811 B in 0s (69.8 kB/s)
Reading package lists...
W: Download is performed unsandboxed as root as file 
'/var/lib/apt/lists/partial/_build_runescape-sc2aq8_resolver-HIG1xG_apt%5farchive_._InRelease'
 couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  autoconf automake autopoint autotools-dev bsdmainutils ca-certificates-java
  debhelper default-jdk-headless default-jre-headless dh-autoreconf
  dh-strip-nondeterminism dwz file fontconfig-config fonts-dejavu-core gettext
  gettext-base groff-base intltool-debian java-common libarchive-zip-perl
  libasound2 libasound2-data libavahi-client3 libavahi-common-data
  libavahi-common3 libbsd0 libcroco3 libcups2 libdbus-1-3 libdebhelper-perl
  libelf1 libexpat1 libfile-stripnondeterminism-perl libfontconfig1
  libfreetype6 libglib2.0-0 libgssapi-krb5-2 libicu63 libjpeg62-turbo
  libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 liblcms2-2 libmagic-mgc
  libmagic1 libnspr4 libnss3 libpcsclite1 libpipeline1 libpng16-16 libsigsegv2
  libsqlite3-0 libsub-override-perl libtool libuchardet0 libx11-6 libx11-data
  libxau6 libxcb1 libxdmcp6 

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

[Paul Wise]

Package: unattended-upgrades
Version: 2.1
Severity: serious

Today I noticed that packages with conffile prompts are no longer
skipped, which can lead to upgrade failures because dpkg stdin is not
connected to any terminal. I think this is a regression since the work
to enable pinning to work with unattended-upgrades.

Package installation log:
Log started: 2020-04-10  13:09:11
apt-listchanges: Reading changelogs...
apt-listchanges: Mailing root: apt-listchanges: changelogs for chianamo
apt-listchanges: Reading changelogs...
Preparing to unpack .../sgml-base_1.30_all.deb ...
Unpacking sgml-base (1.30) over (1.29.1) ...
Setting up popularity-contest (1.70) ...

Configuration file '/etc/cron.daily/popularity-contest'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** popularity-contest (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing 
package popularity-contest (--configure):
 end of file on stdin at conffile prompt
Errors were encountered while processing:
 popularity-contest
-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.8.2-2
ii  python3-apt1.9.10
ii  python3-dbus   1.2.16-1
ii  python3-distro-info0.23
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1+b1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-29
ii  cron [cron-daemon]  3.0pl1-136
ii  systemd-sysv244.3-1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1+b1
ii  exim4-daemon-light [mail-transport-agent]  4.93-13
ii  needrestart3.5-1
ii  powermgmt-base 1.36
ii  python3-gi 3.36.0-1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

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

[Sandro Tosi]

Package: autopkgtest
Version: 5.10
Severity: important
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Hello,
as part of the py2removal effort, i noticed autopkgtest still uses (at least it
refers to it as a dependencies) `pyflakes` (not to be confused with
`pyflakes3`).

Can you please remove such dependencies?

I found a conditional b-d and a autopkgtest test that should be removed. This
will help in reducing the number of rdeps of pyflakes, which can then be
removed once it reaches 0 (currently there are only 2 packages keeping pyflakes
in, and one is autopkgtest indeed).

Let me know if i can help you by uploading the package or in any other way.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils   1.8.2
ii  libdpkg-perl1.19.7
ii  procps  2:3.3.15-2
ii  python3 3.7.5-3
ii  python3-debian  0.1.35

Versions of packages autopkgtest recommends:
ii  autodep8  0.18

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
pn  ovmf  
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
pn  qemu-utils
ii  schroot   1.6.10-6+b1
pn  vmdb2 

-- no debconf information

Bug#956324: python-biopython: FTBFS on mipsel

[Andreas Tille]

Control: forwarded -1 Peter Cock 

Hi Peter,

the log that is linked to below says in the end:


==
ERROR: test_input_filename_with_space 
(test_ClustalOmega_tool.ClustalOmegaTestNormalConditions)
Test an input filename containing a space.
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", 
line 175, in test_input_filename_with_space
self.standard_test_procedure(cline)
  File 
"/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", 
line 63, in standard_test_procedure
output, error = cline()
  File 
"/<>/.pybuild/cpython3_3.8/build/Bio/Application/__init__.py", 
line 530, in __call__
raise ApplicationError(return_code, str(self),
Bio.Application.ApplicationError: Non-zero return code 138 from 'clustalo -i 
"Clustalw/temp horses.fasta" -o temp_test.aln --outfmt clustal --force', 
message 'Bus error'

==
ERROR: test_large_fasta_file 
(test_ClustalOmega_tool.ClustalOmegaTestNormalConditions)
Test a large fasta input file.
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", 
line 210, in test_large_fasta_file
self.standard_test_procedure(cline)
  File 
"/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", 
line 63, in standard_test_procedure
output, error = cline()
  File 
"/<>/.pybuild/cpython3_3.8/build/Bio/Application/__init__.py", 
line 530, in __call__
raise ApplicationError(return_code, str(self),
Bio.Application.ApplicationError: Non-zero return code 138 from 'clustalo -i 
temp_cw_prot.fasta -o temp_cw_prot.aln --outfmt clustal --force', message 'Bus 
error'

==
ERROR: test_newtree_files 
(test_ClustalOmega_tool.ClustalOmegaTestNormalConditions)
Test requesting a guide tree.
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", 
line 224, in test_newtree_files
self.standard_test_procedure(cline)
  File 
"/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", 
line 63, in standard_test_procedure
output, error = cline()
  File 
"/<>/.pybuild/cpython3_3.8/build/Bio/Application/__init__.py", 
line 530, in __call__
raise ApplicationError(return_code, str(self),
Bio.Application.ApplicationError: Non-zero return code 138 from 'clustalo -i 
Fasta/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal 
--force', message 'Bus error'

--


I'm not sure whether you have any clue about this since it looks rather
like a clustalo issue - but I guess you could be interested.  Please let
us know what you think about this.

Kind regards

   Andreas.

On Thu, Apr 09, 2020 at 10:38:04PM +0200, Sebastian Ramacher wrote:
> Source: python-biopython
> Version: 1.76+dfsg-1
> Severity: serious
> Tags: ftbfs sid bullseye
> Justification: fails to build from source (but built successfully in the past)
> 
> python-biopython failed to build on mipsel:
> https://buildd.debian.org/status/fetch.php?pkg=python-biopython=mipsel=1.76%2Bdfsg-1%2Bb1=1586419338=0
> 
> Cheers
> -- 
> Sebastian Ramacher



> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#794799: Info received ()

[Sylvia Medina]

On Thu, Apr 9, 2020, 10:03 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  wxWidgets Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 794...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 794799: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794799
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#794799:

[Sylvia Medina]

On Tue, Mar 3, 2020, 12:14 AM Sylvia Medina 
wrote:

>

Bug#956335: depends on python-pil which is being removed in bullseye (testing)

[Juhani Numminen]

Package: fretsonfire-game
Version: 1.3.110.dfsg2-5
Severity: serious
Tags: bullseye
Control: block 955776 with -1
Control: clone -1 -2 -3
Control: reassign -2 bkchem 0.13.0-6
Control: reassign -3 impressive 0.12.0-2

Dear maintainers,

These packages are currently in bullseye (testing) repository and
are blocking src:pillow 7.0.0-4 from migrating there. They depend
on obsolete python-pil.

https://release.debian.org/britney/update_output.txt
"""
trying: pillow
skipped: pillow (263, 12, 259)
got: 27+0: a-6:a-0:a-0:a-0:i-20:m-0:m-0:p-0:s-1
* amd64: bkchem, fretsonfire, fretsonfire-game, impressive, 
impressive-display
"""


Regards,
Juhani

Bug#953722: ITP: josm-installer -- Editor for OpenStreetMap (installer)

[Sebastiaan Couwenberg]

On 4/10/20 6:20 AM, Christoph Anton Mitterer wrote:
> On Thu, 2020-04-09 at 05:45 +0200, Sebastiaan Couwenberg wrote:
>> On 4/9/20 4:37 AM, Christoph Anton Mitterer wrote:
>> It's no different from users downloading the JAR themselves, the
>> package
>> just integrates it in the desktop environment and schedules periodic
>> downloads.
> 
> FYI:
> I've just had a short glance on the downloader and it seems it does no
> verification at all...

The JRE verifies the JAR signature.

> The only protection is https, which, given how the TLS-CA-ecosystem
> works is mostly identical to no protection (there are around 150 root
> CAs in the usual bundles, many of them highly questionable from
> totalitarian countries or that have been caught already several times
> in "accidentally" forging certs... and there are probably thousands of
> intermediate CAs... all which can basically sign for everything).

Upstream doesn't provide asc/md5/sha signatures like Maven does, I did
ask for them but upstream considers the JAR signature sufficient.

> I think there should be perhaps a big fat warning about this in the
> package, or eve better, some hardcoded hashsums of the jar, which is
> then verified upon download.

I looked into how flashplugin-nonfree was implemented, but that's not
something to adopt for josm-installer, I don't have the bandwidth for that.

josm-installer is already in contrib, that's warning enough. The package
name implies that it doesn't provide the executable itself, any user who
like you is uncomfortable by that can stay clear of it. If we'll have to
remove the josm package in the future because it becomes impossible to
keep for some reason, the josm-package will remain for users who don't
share your concern, e.g. because they already download the JAR from the
JOSM project themselves and appreciate the improved integration. Users
who consider an installer unacceptable will have to find another way to
keep using JOSM on their Debian systems.

Kind Regards,

Bas

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

Bug#955686: cinnamon-control-center: FTBFS: configure: error: Package requirements (gtk+-3.0 >= 3.4.1

[Norbert Preining]

reassign 955686 libwacom-dev
retitle 955686 missing dep from wacom-dev to gudev
found 955686 1.3-1
fixed 955686 1.3-2
close 955686 1.3-2
thanks

> > Package 'gudev-1.0', required by 'libwacom', not found

Indeed, but this is a bug in libwacom-dev which does not depend on the
necessary gudev packages. But they are necessary.

The cinnamon code only checks via pkg-config for wacom, and for nothing
else.

This has been fixed in wacom already (albeit with a different
explanation), thus reassigning, tagging and closing this bug.


Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#953722: ITP: josm-installer -- Editor for OpenStreetMap (installer)

[Christoph Anton Mitterer]

On Thu, 2020-04-09 at 05:45 +0200, Sebastiaan Couwenberg wrote:
> On 4/9/20 4:37 AM, Christoph Anton Mitterer wrote:
> > > The package will be maintained with in the Debian GIS team where
> > > it will eventually replace the josm package.
> > 
> > I'm afraid but this is a really unfortunate idea.
> 
> Don't be:
> 
>  https://lists.debian.org/debian-gis/2020/04/msg0.html

Ah, so AFAIU josm is not intended to be kept... that's good news.
Thanks for your effort :-)



> It's no different from users downloading the JAR themselves, the
> package
> just integrates it in the desktop environment and schedules periodic
> downloads.


FYI:
I've just had a short glance on the downloader and it seems it does no
verification at all...

The only protection is https, which, given how the TLS-CA-ecosystem
works is mostly identical to no protection (there are around 150 root
CAs in the usual bundles, many of them highly questionable from
totalitarian countries or that have been caught already several times
in "accidentally" forging certs... and there are probably thousands of
intermediate CAs... all which can basically sign for everything).


I think there should be perhaps a big fat warning about this in the
package, or eve better, some hardcoded hashsums of the jar, which is
then verified upon download.


Cheers,
Chris.

Bug#912788: fixed in ghc 8.8.3-1~exp1

[Sean Whitton]

Hello,

On Thu 09 Apr 2020 at 08:26PM -04, Sandro Tosi wrote:

> a couple of weeks have passed now, any progress on this effort?

I started it but was not able to do a lot and others have not been
active, I'm afraid.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#938595: sugar-toolkit-gtk3: Python2 removal in sid/bullseye - reopen 938595

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:sugar-toolkit-gtk3)Build-Depends->python
(binary:python-sugar3)Depends->python-cairo
(binary:python-sugar3)Depends->python-dateutil
(binary:python-sugar3)Depends->python-dbus
(binary:python-sugar3)Depends->python-decorator
(binary:python-sugar3)Depends->python-gi
(binary:python-sugar3)Depends->python-gi-cairo
(binary:python-sugar3)Depends->python-six
(binary:python-sugar3)Depends->python2:any
(binary:python-sugar3)Depends->python2:any
(binary:python-sugar3)Depends->python:any

Re-opening, so that they can be taken care of.

Bug#937327: protobuf: Python2 removal in sid/bullseye - reopen 937327

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:protobuf)Testsuite-Triggers->python

Re-opening, so that they can be taken care of.

Bug#943135: numba: Python2 removal in sid/bullseye - reopen 943135

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:numba)Testsuite-Triggers->python-all-dev
(source:numba)Testsuite-Triggers->python-funcsigs
(source:numba)Testsuite-Triggers->python-numba
(source:numba)Testsuite-Triggers->python-singledispatch
(binary:numba-doc)Recommends->python-numba

Re-opening, so that they can be taken care of.

Bug#956334: mozjs68: Python2 removal in sid/bullseye

[Sandro Tosi]

Source: mozjs68
Version: 68.6.0-2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests, in details:

(source:mozjs68)Build-Depends->python2-dev

Please stop using Python2, and fix this issue by one of the following
actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#938073: python-pylibacl: Python2 removal in sid/bullseye - reopen 938073

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:python-pylibacl)Build-Depends->python-setuptools

Re-opening, so that they can be taken care of.

Bug#956333: catch2: Python2 removal in sid/bullseye

[Sandro Tosi]

Source: catch2
Version: 2.11.3-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests, in details:

(source:catch2)Build-Depends->python

Please stop using Python2, and fix this issue by one of the following
actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#938305: pyxdg: Python2 removal in sid/bullseye - reopen 938305

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:pyxdg)Testsuite-Triggers->python-nose

Re-opening, so that they can be taken care of.

Bug#936727: ignition-math4: Python2 removal in sid/bullseye - reopen 936727

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:ignition-math4)Build-Depends->python

Re-opening, so that they can be taken care of.

Bug#936273: capstone: Python2 removal in sid/bullseye - reopen 936273

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:capstone)Build-Depends->cython

Re-opening, so that they can be taken care of.

Bug#937394: pybluez: Python2 removal in sid/bullseye - reopen 937394

[Sandro Tosi]

Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:pybluez)Testsuite-Triggers->python-all
(source:pybluez)Testsuite-Triggers->python-bluez

Re-opening, so that they can be taken care of.

Bug#857740: live-build: /etc/resolv.conf has unsafe permissions when copied from config/includes.chroot

[jnqnfe]

Patch submitted as MR #175
https://salsa.debian.org/live-team/live-build/-/merge_requests/175

On Fri, 10 Apr 2020 02:30:08 +0100 jnq...@gmail.com wrote:
> Confirmed, this is still a problem. I'll make a patch right now.

Bug#956102: desktop-base: unwanted metadata within images

[Cyril Brulebois]

Hi,

Stuart Prescott  (2020-04-07):
> Dear Maintainer,
> 
> A user in #debian noticed that the svg images within desktop-base contain
> quite a bit of metadata about the machines that they were created on,
> including paths and usernames. These data should probably be cleaned
> before shipping the images.
> 
> $ rgrep export-filename /usr/share/desktop-base/

https://tracker.debian.org/pkg/mat2 might prove helpful.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#857740: live-build: /etc/resolv.conf has unsafe permissions when copied from config/includes.chroot

[jnqnfe]

Confirmed, this is still a problem. I'll make a patch right now.

On Tue, 14 Mar 2017 15:53:26 +0100 intrig...@debian.org wrote:
> Package: live-build
> Severity: normal
> Version: 1:20170213
> Tags: security
> User: tails-...@boum.org
> Usertags: misc-reported
> 
> Hi!
> 
> when the config/includes.chroot/etc/resolv.conf file exists in the
> source tree, it is copied into the rootfs with "cp -a". So for
> example, if I've cloned a lb config source tree using Git as my user,
> the resulting live system has a /etc/resolv.conf owned by 1000:1000,
> and thus writable by the default live user. Depending on the exact
> context in which the live system is used, the security impact can be
> non-existent or rather severe.
> 
> Disclaimer: I've only verified this behavior on Tails' patched
> live-build 2.x. Sorry! But the affected code looks very much the same
> on the current master branch.
> 
> Cheers,
> -- 
> intrigeri
> 
> 

Bug#956332: python-pip: Binary package python-pip (for Python 2) is no longer being built from the python-pip source package.

[Justin Searle]

Source: python-pip
Version: 20.0.2-4
Severity: critical
Tags: a11y
Justification: breaks unrelated software

Dear Maintainer,

During a recent apt upgrade, there was conflict reported for binary
pacakge python-pip.  It's dependancy "python-pip-whl = 18.1-5" was no
longer being met.  Apparently python-pip-whl had been upgraded to
20.0.2-4, but python-pip was left behind at version 18.1-5.  Looking
futher into this, is seems like both these packages were builing built
from the source package python-pip, but the latest binary version of 
python-pip was not longer being built from the latest python-pip source
package.

I understand that python2 is planned for removal, however as long as we
have the python 2 interpter available, I think we need to keep the
python-pip package available as well.  Otherwise, if it is auto-removed
by apt because of the broken dependency of python-pip-whl, then all
non-debian package and hand installed pip packages become broken.


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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

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

[Sandro Tosi]

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

Hey Julian,
as part of this effort, could you start by switching to pyflakes3? the
changes should be:

```
diff --git a/debian/control b/debian/control
index 6098a6e7..e5b8bffd 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Build-Depends: apt (>= 1.0.9.4),
   gnupg,
   dirmngr | gnupg (<< 2),
   pycodestyle,
-   pyflakes
+   pyflakes3,
Vcs-Git: https://salsa.debian.org/apt-team/python-apt.git
Vcs-Browser: https://salsa.debian.org/apt-team/python-apt

diff --git a/tests/test_pyflakes.py b/tests/test_pyflakes.py
index 4dbaa404..8341ecd4 100644
--- a/tests/test_pyflakes.py
+++ b/tests/test_pyflakes.py
@@ -31,7 +31,7 @@ class TestPyflakesClean(testcommon.TestCase):
return files

def test_pyflakes_clean(self):
-cmd = ["pyflakes"] + self.get_py_files(self.TOPLEVEL)
+cmd = ["pyflakes3"] + self.get_py_files(self.TOPLEVEL)
res = subprocess.call(cmd)
if res != 0:
self.fail("pyflakes failed with: %s" % res)
```

and i guess you may want to skip test_pyflakes.py as it fails with:

/build/python-apt-2.0.0/tests/test_hashes.py:93: undefined name 'unicode'
/build/python-apt-2.0.0/tests/test_hashes.py:94: undefined name 'unicode'
/build/python-apt-2.0.0/tests/test_hashes.py:95: undefined name 'unicode'
/build/python-apt-2.0.0/tests/test_hashes.py:96: undefined name 'unicode'
/build/python-apt-2.0.0/apt/progress/text.py:45: undefined name 'raw_input'
F..

or update the code, but that may be incompatible with py2

this will help free up pyflakes for removal

Regards,
Sandro

Bug#956331: ITP: jekyll-theme-minima -- beautiful, minimal theme for jekyll

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: jekyll-theme-minima
  Version : 2.5.1
  Upstream Author : Parker Moore
* URL : https://jekyll.github.io/minima/
* License : MIT
  Programming Lang: HTML/CSS/SASS/Markdown
  Description : beautiful, minimal theme for jekyll

Minima is a one-size-fits-all Jekyll theme for writers. It's Jekyll's default
(and first) theme. It's what you get when you run `jekyll new`.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl6Pwi4ACgkQS80FZ8KW
0F17ZA//W6V/3CTX2UHN5ZdUKvYBVm+bb0DAhCYyuHvd2mPw/CgcAeOFDLrAum4B
dssDoaCGUcj4JJ979EAFvcXa8Bkj2Ys0HulYrXaX/qGHhmOHuVGkyYnv7ZgaqEQr
yvM/frMyR/+nv2NXib9D9SeD5aoCbXLd8mrXTC4RNDXyuv1i0OlxbFqbXt5dkkUn
uhtEgq8jbjELPrcZAVgknybDxLGqLMqJAFl7al1GQgqnqhh45yOJiFAoOZyQihz5
P6SfrvzdUUKnMmnkch0V9eYGEkkqiLjiVsQM5ICqVWE3YpAesYOeSaH8Ok5bsigG
H69wiydqsVNRzqyQYlyXCjQac4KObb/SUSXhi7sz41CG1Ioe7Zt3aoMPSdSAbQ5T
x7jXOAltfxCJv5qpdTuboXVRMvq2hjbIh1sBVmHY5HVJsP7LDyIdwjphmLa7sDwl
X+NnVc74qqbRj9fKpmcl9+4cQ5p9M1xIr96Tsz8ECPAEcqRBKtjSX6hY8Fj8dea6
+43K1Y46A20T6C+M4EfLSZau0fcFjwHJMJtAolVswq32bh8ULvunUPyxNtCveqCU
hO0E/hejJlX3Y+H31AjvtPo8YHPXlLjCKMmHjJY3B2AuhQeajZzelkzmNnoaSJCb
YWGyxIGtMFfCjCV/1Nn5QV5uzh5Buy04HGWJ33GU8phMek76fUw=
=i1Iq
-END PGP SIGNATURE-

Bug#956330: apt: Provide option to prompt on apt install foo whether foo should be marked manually installed

[annadane]

Package: apt
Version: 1.8.2
Severity: wishlist

Dear Maintainer,

I'm just wondering whether for Deb 11 we might provide an option for users to 
perhaps, be prompted when they apt install foo and foo is already installed, to 
*ask* whether they intend to mark it manually installed. I find most of the 
time when I do that, as opposed to apt-mark manual foo, it's because I've made 
a mistake and forgotten or not noticed I already had something installed, not 
because I want to set it to manual. apt-mark manual foo might work the same as 
it always does but as said it would be nice to prompt the user when they apt 
install a package like this

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (no /etc/apt/sources.list.d/* present) --


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

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.12-1+deb10u1
ii  libapt-pkg5.0   1.8.2
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4+deb10u3
ii  libseccomp2 2.3.3-4
ii  libstdc++6  8.3.0-6

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.11-7
ii  dpkg-dev1.19.7
ii  gnupg   2.2.12-1+deb10u1
ii  powermgmt-base  1.34

-- no debconf information

Bug#912788: fixed in ghc 8.8.3-1~exp1

[Sandro Tosi]

On Sat, Mar 28, 2020 at 11:14 AM Sean Whitton  wrote:
>
> Hello,
>
> On Sat 28 Mar 2020 at 03:45PM +01, Moritz Mühlenhoff wrote:
>
> > Gentle ping.
>
> Typically we try to build all the libghc-* packages against the new GHC
> in experimental before uploading anything to unstable.  That hasn't
> happened yet which is why things haven't moved.

a couple of weeks have passed now, any progress on this effort?

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

Bug#938340: reclass: Python2 removal in sid/bullseye

[Sandro Tosi]

> If your concern is that I might finish without you noticing, then that's
> unlikely: Boxer is strongly tied to Debian, so immediately when I have a
> new release it gets packaged for Debian.

is there any update about porting boxer away from reclass? reclass is
about to be the last reverse dependency of python-yaml.

The sooner we can remove reclass, the sooner we can start clean up the
packages it depends on.

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

Bug#922063: Possible upstream bug for debian #922063

[Jonas Smedegaard]

Control: forwarded -1 https://github.com/pazz/alot/issues/1434

Hi Jordan,

Quoting Jordan Justen (2020-04-09 11:14:30)
> This upstream bug sounds similar.
> 
> https://github.com/pazz/alot/issues/1434
> 
> What do you think?

Yes, indeed. Looks like same bug as I am experiencing.

 - Jonas

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

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

signature.asc
Description: signature

Bug#956329: purge doesn't cleanup /var/lib/rasdaemon/ras-mc_event.db

[dann frazier]

Package: rasdaemon
Version: 0.6.5-1
Severity: normal

I noticed the following message when 'apt remove --purge'ing rasdaemon:

dpkg: warning: while removing rasdaemon, directory '/var/lib/rasdaemon' not empt
y so not removed

I had injected an MCE, which appears to have resulted in the creation of
/var/lib/rasdaemon/ras-mc_event.db. Here's a quick reproducer:

sudo apt install rasdaemon
sudo modprobe mce-inject
git clone https://github.com/andikleen/mce-inject.git
cd mce-inject
make
sudo ./mce-inject < corrected
sudo apt remove --purge rasdaemon

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

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

Versions of packages rasdaemon depends on:
ii  libc62.30-4
ii  libdbd-sqlite3-perl  1.64-1+b1
ii  libsqlite3-0 3.31.1-4
ii  perl 5.30.0-9
ii  sqlite3  3.31.1-4

rasdaemon recommends no packages.

rasdaemon suggests no packages.

-- no debconf information

Bug#955549: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults

[Adam Borowski]

On Tue, Apr 07, 2020 at 06:22:19PM +0800, Chao Yu wrote:
> I figured out two patches to fix segfault issues, could you please have
> a try:
> 
>   fsck.f2fs: fix to check validation of i_xattr_nid
>   fsck.f2fs: fix to check validation of block address
> 
> In addition, I found that fsck main flow failed because it can not load root
> inode based on wrong block address in nat, so I wrote another patch to enable
> fsck to lookup root inode by traversing all nodes in f2fs main area, and 
> relink
> nat to root inode correctly.
> 
>   fsck.f2fs: lookup and relink root inode

I still get a segfault:

Program received signal SIGSEGV, Segmentation fault.
0x5556 in print_inode_info (sbi=0x55584ca0 , 
node=0x5558f170, name=) at mount.c:240
240 block_t blkaddr = le32_to_cpu(inode->i_addr[i + ofs]);
(gdb) bt
#0  0x5556 in print_inode_info (sbi=0x55584ca0 , 
node=0x5558f170, name=) at mount.c:240
#1  0x55564c4e in print_node_info (sbi=, 
node_block=, verbose=) at mount.c:278
#2  0x5556317f in dump_node (sbi=sbi@entry=0x55584ca0 , 
nid=nid@entry=2861, force=force@entry=1) at dump.c:511
#3  0x55561060 in fsck_verify (sbi=0x55584ca0 ) at 
fsck.c:3259
#4  0x799a in do_fsck (sbi=0x55584ca0 ) at main.c:698
#5  main (argc=, argv=) at main.c:864

> With this patch, image can be fixed and mounted later, although, most of files
> were deleted due to seriously damaged f2fs metadata

Yeah, I've later tested the hardware -- writes to it are borked, so no
complaint against the filesystem failing.  I got backups. :)

> The patches were made on top of dev-test branch of Jaegeuk's tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test

>  #0  0x93ec in memcpy (__len=18446744073323892736, 
>  __src=0x5560760c, __dest=0x7fffe000) at 
>  /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> > 
> > At a glance, immediate reason of this issue is we didn't check 
> > inode.i_namelen's
> > validation.
> > 
>  #1  convert_encrypted_name (name=name@entry=0x5560760c " ", 
>  len=-385658880, new=new@entry=0x7fffe000 " ", enc_name=  out>) at fsck.c:1132
>  #2  0x55562286 in print_inode_info (sbi=0x5557db20 , 
>  node=0x556075b0, name=1) at mount.c:183
>  #3  0x55562a46 in print_node_info (sbi=, 
>  node_block=, verbose=) at mount.c:277
>  #4  0x55560d3f in dump_node (sbi=sbi@entry=0x5557db20 
>  , nid=nid@entry=24274, force=force@entry=1) at dump.c:520
>  #5  0xe94c in fsck_verify (sbi=0x5557db20 ) at 
>  fsck.c:2568
>  #6  0x699b in do_fsck (sbi=0x5557db20 ) at 
>  main.c:569


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#938757: prevent removal

[Sandro Tosi]

On Thu, Apr 9, 2020 at 6:45 PM Norbert Preining  wrote:
>
> > now that calibre has migrated to python3, can you finally drop 
> > python-unrardll ?
>
> Thanks for the reminder, done so now.

thanks! :)

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

Bug#938757: prevent removal

[Norbert Preining]

> now that calibre has migrated to python3, can you finally drop 
> python-unrardll ?

Thanks for the reminder, done so now.

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#915643: golang-google-grpc update broke gitaly

[Dmitry Smirnov]

Dear Praveen,

On Friday, 10 April 2020 12:01:30 AM AEST Pirate Praveen wrote:
> I was preparing gitaly 12.9.2 (gitaly master branch) and was building
> fine till yesterday but started ftbfs from today. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956299 for error
> message.

Sorry for inconvenience. "golang-google-grpc" is a very sensitive package 
that was recently broken by improperly built 1.22.1-1 that caused FTBFS in 
many packages.

1.27.1-1 is much improved and it is consistent with "golang-goprotobuf".
1.27.1-1 addressed multiple FTBFS problems and it was necessary to upload it 
to unstable to fix dire situation threatening massive removal of packages 
from "testing".


> Can you help fix the failure? Also it will be helpful if you can
> consider gitaly in experimental for future updates.

Unfortunately I've burned several days for fixing "golang-google-grpc" and I 
have no capacity left for troubleshooting gitaly. However most certainly 
gitaly needs to run "go generate" to re-built .pb.go files from .proto 
sources (with recent "golang-goprotobuf") to fix FTBFS.

-- 
Regards,
 Dmitry Smirnov.

---

What opinions the masses hold, or do not hold, is looked on as a matter of
indifference. They can be granted intellectual liberty because they have no
intellect.
-- George Orwell, 1984



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

Bug#782654: Bug#838416: Bug#782654: Bug#838416: ITP: bazel -- Fast and correct automated build system by Google

[Olek Wojnar]

Philipp and Bastien,

Thank you both for your responses!

On Thu, Apr 9, 2020 at 4:23 PM Bastien ROUCARIES <
roucaries.bast...@gmail.com> wrote:

> Upstream seems to be friendly
>
> Time to prod them:
> https://github.com/bazelbuild/bazel/issues/9408


Thanks for highlighting that. It indeed seems that they will likely realize
the importance of their software right now and help. Pinged. :) [1]


> On Wed, Apr 8, 2020 at 10:57 PM Philipp Kern  wrote:
> >
> > On 2020-04-08 19:43, Olek Wojnar wrote:
> > >
> > > In the meantime, I see that Bazel has an unofficial Ubuntu build [1].
> > > Do you know anything about that? It seems like a good place for us to
> > > start if you aren't close to a product yourself.
> >
> > That's the build Google provides that is built with Bazel itself, using
> > a ton of vendored libraries. (Because that's how Google operates
> > internally.)
>

Ah, ok. Good to know. Thanks. Might be better to just start with a vanilla
source package then. I'm playing around with it just to see what I can get
working while we wait for a reply to my ping on Bastien's GitHub issue.


> > Generally the pkg_deb output[1] is not really policy-compliant and more
> > built from the ground up without any Debian tooling. So the /mere
> > existence/ of that package (which was there from the beginning) does not
> > help the quest of getting Bazel packaged for Debian, unfortunately.
> >
> > Kind regards
> > Philipp Kern, obviously not speaking for Google
> >
> > [1]
> >
> https://github.com/bazelbuild/bazel/blob/f828b4c77805ad0ea6afecef798aa69d68bec8d4/scripts/packages/debian/BUILD#L69


Well that's not as encouraging as I'd hoped but still good information to
have. Sounds like our best shot for getting something working in the
near-term is active cooperation and support from Google. Here's hoping they
support that!!

-Olek

Bug#944428: Update

[jmbo]

Hi,

I am still having the same problems on my Lenovo laptop.

There was a recommendation in this bug #939170 to blacklist the tpm
modules, and for me this works, meaning the laptop will restart and
shutdown as normal.

When I build the upstream kernel without the Debian patches the laptop
works as normal.

This suggests to me one or more of the Debian patches is causing the
problem and conflickting with the tpm modules. 

I don't see any Debian patches that refer to the tpm modules but few of
them refer to security and lockdown.

Anyhow, I just wanted to provide an update to this bug, hope it helps
someone. 

Thanks 
Marc

Bug#956328: RM: khmerconverter -- RoQA; Depends on Python 2, dead upstream, unmaintainewd

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove khmerconverter. It's dead upstream (last commit is from 2008, I 
contacted
the authors, but all four email addresses bounced), depends on Python 2 and the 
last
maintainer upload was in 2007.

Cheers,
Moritz

Bug#956327: RM: fusil -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove fusil. It's dead upstream, depends on Python 2 and the last
maintainer upload was in 2014.

Cheers,
Moritz

Bug#956258: override: debian-science

[Sandro Tosi]

On Thu, Apr 9, 2020 at 5:36 PM Sean Whitton  wrote:
>
> Hello Sandro,
>
> On Wed 08 Apr 2020 at 11:53PM -04, Sandro Tosi wrote:
>
> > is there a way for me to check all the override disparities regarding the
> > section? the ones i find at https://ftp-master.debian.org/#override are 
> > only for
> > the package priority.
>
> Well, you could query projectb on mirror.ftp-master.debian.org
>
> > Anyhow, some more overrides to update:
>
> Could you start providing these in the following form:
>
> dak override science-robotics metapackages # from 'science'
>
> ... then after reviewing I can copy and paste.

i'll try (see below)

> > science-astronomy-dev:  Override says science - optional, .deb says 
> > oldlibs - optional
>
> Can you explain why some of these are oldlibs please?

apologies, i'm copying these lines from the PTS page of the source
package, i may have copied too much. I'm personally only interested in
the metapackages overrides.

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

Bug#956258: override: debian-science

[Sean Whitton]

Hello Sandro,

On Wed 08 Apr 2020 at 11:53PM -04, Sandro Tosi wrote:

> is there a way for me to check all the override disparities regarding the
> section? the ones i find at https://ftp-master.debian.org/#override are only 
> for
> the package priority.

Well, you could query projectb on mirror.ftp-master.debian.org

> Anyhow, some more overrides to update:

Could you start providing these in the following form:

dak override science-robotics metapackages # from 'science'

... then after reviewing I can copy and paste.

> science-astronomy-dev:  Override says science - optional, .deb says 
> oldlibs - optional

Can you explain why some of these are oldlibs please?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#956326: command-not-found crashes when a command is not found

[Derrell Durrett]

Package: command-not-found
Version: 18.04.5-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I typed 'll' at the command line (because I forgot I hadn't set up my bash 
aliases)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
See above
   * What was the outcome of this action?
The following output appeared, suggesting I file this bug:
Could not find the database of available applications, run 
update-command-not-found as root to fix this
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.7.3 final 0
Distributor ID: PureOS
Description:PureOS
Release:9.0
Codename:   amber
Exception information:

local variable 'cnf' referenced before assignment
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 93, in main
if not cnf.advise(args[0], options.ignore_installed) and not 
options.no_failure_msg:
UnboundLocalError: local variable 'cnf' referenced before assignment

   * What outcome did you expect instead?
 That command-not-found wouldn't barf (I guess -- I had forgotten that it runs 
and makes useful suggestions most of the time).


-- System Information:
Distributor ID: PureOS
Description:PureOS
Release:9.0
Codename:   amber
Architecture: x86_64

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

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  10.2019031300pureos1
ii  python3  3.7.3-1
ii  python3-apt  1.8.4pureos3

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

-- no debconf information

Bug#956306: iw: outaded URL in man page

[Paride Legovini]

control: severity -1 minor

jmranger wrote on 09/04/2020:
> Package: iw
> Version: 5.0.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> iw's man page refers to
> http://wireless.kernel.org/en/users/Documentation/iw
> which no longer works. AFAICT, the correct URL would now be
> https://wireless.wiki.kernel.org/en/users/Documentation/iw
> 
> Reporting on my installed version, but unpacking the current 
> iw_5.4-1_amd64.deb show that the issue is still present.
> 
> Thanks!

Thanks. The manpage comes from the upstream source and as of today the
error is still present in master:

https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/tree/iw.8#n71

I'd prefer to have this fixed upstream rather patching the manpage in
Debian. I'll try to submit a patch, or at least report the issue.

Paride

Bug#955530: Bug#: tomcat9: ipa-server-install fails due to servlet crash

[Timo Aaltonen]

On 7.4.2020 9.15, Timo Aaltonen wrote:
> On 5.4.2020 17.37, Emmanuel Bourg wrote:
>> Le 02/04/2020 à 05:30, Timo Aaltonen a écrit :
>>
>>> ipa-server-install (from freeipa-server) started failing within the last 
>>> few weeks,
>>> I don't know exactly when but it's a regression in sid, Ubuntu focal is 
>>> still fine.
>>>
>>> Redhat folks said this would've been due to openjdk-8-jre being built with 
>>> gcc10, but the latest
>>> version isn't anymore, and I've tried older versions from snapsho.d.o and 
>>> they didn't help.
>>> I've also tried downgrading dogtag-pki but that didn't help either.
>>>
>>> 2020-04-01 14:35:35 [main] SEVERE: Unable to start CMS engine: null
>>> java.lang.NullPointerException
>>> at 
>>> com.netscape.ca.CRLIssuingPoint.initConfig(CRLIssuingPoint.java:764)
>>> at com.netscape.ca.CRLIssuingPoint.init(CRLIssuingPoint.java:497)
>>> at 
>>> com.netscape.ca.CertificateAuthority.initCRL(CertificateAuthority.java:2304)
>>> at 
>>> com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:633)
>>> at 
>>> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:824)
>>> at 
>>> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:799)
>>> at 
>>> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:791)
>>> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:468)
>>> at 
>>> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:113)
>>> at javax.servlet.GenericServlet.init(GenericServlet.java:158)
>>
>> Hi Timo,
>>
>> Why do you think this is related to tomcat9?
> 
> It was the first thing that came to mind, looking at the trace. But it's
> more likely in jdk8. Fedora has this patch:
> 
> https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/raw/master/f/jdk8241296-jnihandleblock_segfault.patch
> 
> added after they switched to gcc10.. I know our jdk8 is now built with
> gcc9, but perhaps that causes incompatibilities elsewhere? Anyway, I'm
> going to test that patch if it helps.

Nevermind, this was actually caused by the certmonger update which is
bizarre but true..

-- 
t

Bug#956325: Sddm: Crashes when login in - please consider updating sddm in buster with upstream bugfix release

[Ralf E-Mail]

Package: sddm
Version: 0.18.0-1

I just upgrade my two systems to buster and experience on both systems
now frequent (not always) crashes when login in using sddm.
The screen gets black, the cursor blinks in the upper left corner but
nothing happens.
Killing X/sddm with Ctrl+Alt+Backspace helps and makes sddm reapper.

There is a promising update to the package in version 0.18.1:
 "Fix crashes when creating a user session", cf.
 https://github.com/sddm/sddm/blob/v0.18.1/ChangeLog

This version is however only included in bullseye / unstable, yet
installing that would require additional library updates
(libqt5core5a, libgcc).
I would like to stick to the buster stable release.

Judging from the upstream changelog, I recommend considering updating
the buster sddm package to the bugfixed 0.18.1 upstream version.
I would be happy to test a 0.18.1-1 package built for buster.

Thanks for all your work,
Ralf

Bug#951142: [Python-modules-team] Bug#951142: mwic: Please package new upstream version (0.7.8)

[Georg Faerber]

Hi Christian,

On 20-04-01 17:28:29, Christian Göttsche wrote:
> the solution is to add the package 'hunspell-en-gb' to build and
> test-run dependencies, so the en-GB locale related tests can succeed.
> 
> See https://salsa.debian.org/python-team/modules/mwic/-/merge_requests/1

Thanks for investigating and providing these patches, now uploaded.

Cheers,
Georg

Bug#938757: prevent removal

[Sandro Tosi]

> This Py2 module serves exclusively Calibre, which would recommend/depend
> on it, but since this module is in contrib, we cannot only suggest it
> from calibre.
>
> Removing Py2 support from it would make it useless for calibre/py2.
> It will be removed as soon as we switch the main calibre to py3.

now that calibre has migrated to python3, can you finally drop python-unrardll ?

Bug#956324: python-biopython: FTBFS on mipsel

[Sebastian Ramacher]

Source: python-biopython
Version: 1.76+dfsg-1
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

python-biopython failed to build on mipsel:
https://buildd.debian.org/status/fetch.php?pkg=python-biopython=mipsel=1.76%2Bdfsg-1%2Bb1=1586419338=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#956323: sunpy: FTBFS on armel

[Sebastian Ramacher]

Source: sunpy
Version: 1.1.1-2
Severity: serious
Tags: ftbfs sid bullseye

sunpy failed to build on armel:
https://buildd.debian.org/status/fetch.php?pkg=sunpy=armel=1.1.1-2=1582144052=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#956322: ITP: kimageannotator -- Image Annotating Library

[Boyuan Yang]

Package: wnpp
Severity: wishlist
Owner: Boyuan Yang 

* Package name: kimageannotator
  Version : 0.2.1
  Upstream Author : Damir Porobic 
* URL : https://github.com/ksnip/kColorPicker
* License : GPL-2+
  Programming Lang: C++/Qt
  Description : Image Annotating Library

 The kImageAnnotator library provides tools to annotate
 images. This library
is used by the ksnip project.

The package will be maintained by myself with git packaging repo placed in the
Debian group on Salsa. It is a dependency of ksnip (
https://github.com/ksnip/ksnip).


-- 
Regards,
Boyuan Yang


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

Bug#742723: Fwd: Re: CrashMail II doesn't work on debian jessie

[Fernando Toledo]

Hi all , i found that this people have a fix for crashmail 1.5
can be ported to 1.7  for stretch/buster?

https://github.com/orignal/crashmail


Saludos!

-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

Bug#782654: Bug#838416: Bug#782654: Bug#838416: ITP: bazel -- Fast and correct automated build system by Google

[Bastien ROUCARIES]

Upstream seems to be friendly

Time to prod them:
https://github.com/bazelbuild/bazel/issues/9408

On Wed, Apr 8, 2020 at 10:57 PM Philipp Kern  wrote:
>
> On 2020-04-08 19:43, Olek Wojnar wrote:
> > Bazel has suddenly become more important because it is preventing us
> > from getting packages working that would help with the COVID-19
> > pandemic. Due to the significance, I am copying the Debian Med team as
> > well as key people from this bug's history in the hopes of getting
> > something moving quickly.
> >
> > On Tue, 22 May 2018 14:55:19 -0600 Kyle Moffett 
> > wrote:
> >> I spent a while working on it off and on, but there is a decent amount
> >> of tweaking and other packaging work needed to get policy-compliant
> >> bazel packages.  (E.G: There are quite a few binary JAR files shipped
> >> in the upstream tarball that don't necessarily match the versions in
> >> Debian).
> >>
> >> I just didn't have the spare time, especially now that I have a kid,
> >> to sink into one package.
> >
> > I can relate to the kid/time issues! ;) Have you had any time to work
> > on it recently? Did you ever upload any of your work?
> >
> > In the meantime, I see that Bazel has an unofficial Ubuntu build [1].
> > Do you know anything about that? It seems like a good place for us to
> > start if you aren't close to a product yourself.
>
> That's the build Google provides that is built with Bazel itself, using
> a ton of vendored libraries. (Because that's how Google operates
> internally.)
>
> Generally the pkg_deb output[1] is not really policy-compliant and more
> built from the ground up without any Debian tooling. So the /mere
> existence/ of that package (which was there from the beginning) does not
> help the quest of getting Bazel packaged for Debian, unfortunately.
>
> Kind regards
> Philipp Kern, obviously not speaking for Google
>
> [1]
> https://github.com/bazelbuild/bazel/blob/f828b4c77805ad0ea6afecef798aa69d68bec8d4/scripts/packages/debian/BUILD#L69

Bug#956321: dpkg-dev: dpkg-genchanges generate changes without Date field

[Baptiste BEAUPLAT]

Package: dpkg-dev
Version: 1.19.7
Severity: normal
Tags: patch

Dear Maintainer,

A couple of people have been uploading .changes file to mentors without
a Date field.

Mentors doing a validation of the changes against mandatory fields
defined in the policy, discards such files and fails the upload.

While the problem always seems to come from a bad formatted changelog, I
don't think dpkg-genchanges should output a file without a Date field.

Please consider applying the attached patch that will add the Date field
even if dpkg-genchanges fails to parse the changelog.

Thanks you for your consideration,

Best,
--
Baptiste BEAUPLAT - lyknode
From 33cd8af37cb541d2d9dd66721f1524a2fcad0bfe Mon Sep 17 00:00:00 2001
From: Baptiste BEAUPLAT 
Date: Thu, 9 Apr 2020 21:42:29 +0200
Subject: [PATCH] Recreate Date field when extraction failed from d/changelog.

When dpkg-genchanges fails to parse the date in d/changelog, it creates
and empty field named Date. That field is then skipped on output,
producing a policy non-compliant changes.

This commit checks for empty value and replace them by the current
date/time.
---
 scripts/dpkg-genchanges.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/dpkg-genchanges.pl b/scripts/dpkg-genchanges.pl
index e643fe664..2ac24691c 100755
--- a/scripts/dpkg-genchanges.pl
+++ b/scripts/dpkg-genchanges.pl
@@ -460,7 +460,7 @@ info($origsrcmsg);
 
 $fields->{'Format'} = $substvars->get('Format');
 
-if (!defined($fields->{'Date'})) {
+if (!defined($fields->{'Date'}) or $fields->{'Date'} eq '') {
 setlocale(LC_TIME, 'C');
 $fields->{'Date'} = POSIX::strftime('%a, %d %b %Y %T %z', localtime);
 setlocale(LC_TIME, '');
-- 
2.26.0.rc2




signature.asc
Description: OpenPGP digital signature

Bug#822275: ITP: crystal -- Compiler of the Crystal object oriented programming language

[David Suarez]

control: owner -1 david.sephi...@gmail.com
control: retitle -1 ITP: crystal -- Compiler of the Crystal object
oriented programming language

Bug#822275: ITA: crystal -- Compiler of the Crystal object-oriented programming language

[David Suárez]

control: retitle -1 ITA: crystal -- Compiler of the Crystal object 
oriented programming language

control: owner -1 david.sephi...@gmail.com

Bug#822275: ITP: crystal -- Compiler of the Crystal object-oriented programming language

[David Suárez]

control: retitle -1 ITP: crystal -- Compiler of the Crystal object 
oriented programming language

control: owner -1 david.sephi...@gmail.com

Bug#882942: RFS: sieve-connect/0.88-1.1 [NMU] -- MANAGESIEVE protocol client

[Adam Borowski]

On Thu, Apr 09, 2020 at 08:44:32PM +0200, itd wrote:
> >   dget -x 
> > https://mentors.debian.net/debian/pool/main/s/sieve-connect/sieve-connect_0.88-1.1.dsc
> >
> > Changes since the last upload:
> >
> >[ itd ]
> >* Non-maintainer upload.
> >* Escaped left brace in regex (Closes: #882942)
> 
> I'd appreciate feedback on my attempt to package a NMU for sieve-connect
> (see also #955706).  (I should have used X-Debbugs-CC, anything else?)

Hi!
The bug in question is only severity:normal, and there's no record of the
intent for NMU.  Mailing the maintainer directly might or not be enough.
I've thus uploaded to DELAYED/7.

Andrew: if anything, please holler -- or dcut directly.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#956276: runescape: downloads unverified binary and runs it

[Stephen Kitt]

On Thu, 9 Apr 2020 20:06:33 +0200, Markus Koschany  wrote:
> So when the quint essential message is, it is a matter of opinion and a
> special form of verification is not mandated by Policy, then why don't
> you work closer with the member of this team and help him to implement
> the standard envisioned by you? That would be productive and helpful for
> a change.

For obvious reasons I don’t think there’s any point in continuing this
discussion.

Stephen


pgp_t6fa6ue4V.pgp
Description: OpenPGP digital signature

Bug#956320: fabric ModuleNotFoundError: No module named 'invoke.vendor.six'

[Nick Bowler]

Package: fabric
Version: 2.5.0-0.2
Severity: important

Dear Maintainer,

After dist-upgrade, fab appears to be completely disfunctional, perhaps because
of missing dependencies:

  % fab --version
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/fabric/connection.py", line 5, in 

  from invoke.vendor.six import StringIO
  ModuleNotFoundError: No module named 'invoke.vendor.six'
  
  During handling of the above exception, another exception occurred:
  
  Traceback (most recent call last):
File "/usr/bin/fab", line 11, in 
  load_entry_point('fabric==2.5.0', 'console_scripts', 'fab')()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489, 
in load_entry_point
  return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2852, 
in load_entry_point
  return ep.load()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2443, 
in load
  return self.resolve()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2449, 
in resolve
  module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python3/dist-packages/fabric/__init__.py", line 3, in 

  from .connection import Config, Connection
File "/usr/lib/python3/dist-packages/fabric/connection.py", line 10, in 

  Subject: fabric ModuleNotFoundError: No module named 'invoke.vendor.six'
  from decorator import decorator
  ModuleNotFoundError: No module named 'decorator'

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.9.99 (SMP w/2 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages fabric depends on:
ii  libjs-sphinxdoc1.8.5-9
ii  python33.8.2-3
ii  python3-fabric 2.5.0-0.2
ii  python3-pkg-resources  44.0.0-1

fabric recommends no packages.

fabric suggests no packages.

-- no debconf information

Bug#956318: pari-gp: bison should be included in Build-Depends

[Bill Allombert]

On Thu, Apr 09, 2020 at 02:26:15PM -0400, Ken T Takusagawa wrote:
> Package: pari-gp
> Version: 2.11.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> apt-get build-dep pari-gp
> 
> does not install the "bison" package, which is needed to build pari-gp

Hello Ken,

bison is not needed to built the pari package in Debian since
src/language/parse.c and src/language/parse.h file are included in the
package already.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#956136: Some investigations about bug (956136) nanopolish: FTBFS (undefined references)

[Hamid Nassiby]

Hi all,

I could find the cause. It is the `-flto` in the compile and link
flags of the libminimap2-dev package. LTO is introduced recently in
the following commit on the [1]:
53883a7ff8c066c14c0ea4e42299ae9958feda6a

Removing `-flto` from CFLAGS and LDFLAGS, then building
libminimap2-dev with pdebuild (sid), then building the nanopolish with
pbuilder (sid), will succeed.
I attached the patch which resolves the problem. It should be applied
against [1].

The conclusion:
The `-flto` behaves differently from the past maybe with the recent
changes in the build tool-chain (maybe in GCC) and causes the problem.

[1]:https://salsa.debian.org/med-team/minimap2.git

Bests,
Hamid Nassiby
From 5aa0491a6159895cdb0925617858cbca68c9e834 Mon Sep 17 00:00:00 2001
From: Hamid Nassiby 
Date: Thu, 9 Apr 2020 23:01:48 +0430
Subject: [PATCH] Remove -flto flag

---
 debian/patches/addLTO.patch | 30 --
 debian/patches/series   |  1 -
 2 files changed, 31 deletions(-)
 delete mode 100644 debian/patches/addLTO.patch

diff --git a/debian/patches/addLTO.patch b/debian/patches/addLTO.patch
deleted file mode 100644
index 8dc0215..000
--- a/debian/patches/addLTO.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-Author: Steffen Moeller
-Last-Update: 2020-03-14 23:04:54 +0100
-Description: Add -flto flag
-
-Index: minimap2/Makefile
-===
 minimap2.orig/Makefile
-+++ minimap2/Makefile
-@@ -1,10 +1,11 @@
--CFLAGS+=		-g -Wall -O2 -Wc++-compat #-Wextra
-+CFLAGS+=	-g -Wall -O2 -Wc++-compat -flto #-Wextra
- CPPFLAGS+=	-DHAVE_KALLOC
- INCLUDES=
- OBJS=		kthread.o kalloc.o misc.o bseq.o sketch.o sdust.o options.o index.o chain.o align.o hit.o map.o format.o pe.o esterr.o splitidx.o ksw2_ll_sse.o
- PROG=		minimap2
- PROG_EXTRA=	sdust minimap2-lite
- LIBS=		-lm -lz -lpthread
-+LDFLAGS+=	-flto
- 
- OBJS+=ksw2_extz2_sse.o ksw2_extd2_sse.o ksw2_exts2_sse.o
- 
-@@ -29,7 +30,7 @@ all:$(PROG)
- extra:all $(PROG_EXTRA)
- 
- minimap2:main.o libminimap2.a
--		$(CC) $(CFLAGS) main.o -o $@ -L. -lminimap2 $(LIBS) $(LDFLAGS)
-+		$(CC) main.o -o $@ -L. -lminimap2 $(LIBS) $(LDFLAGS)
- 
- minimap2-lite:example.o libminimap2.a
- 		$(CC) $(CFLAGS) $< -o $@ -L. -lminimap2 $(LIBS) $(LDFLAGS)
diff --git a/debian/patches/series b/debian/patches/series
index 57c6966..65c2533 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,5 +1,4 @@
 hardening.patch
 do_not_use_natbib.bst.patch
 simde
-addLTO.patch
 ar.patch
-- 
2.25.0

Bug#936857: libfreenect: diff for version 1:0.5.3-2

[Yaroslav Halchenko]

Thanks for the alert, FWIW, done now:

(git)lena:~exppsy/libfreenect[debian]git
$> gbp push  salsa   
gbp:info: Pushing debian/1%0.5.3-1 to salsa
gbp:info: Pushing upstream/0.5.3 to salsa
gbp:info: Pushing refs/heads/debian to salsa:refs/heads/debian
gbp:info: Pushing refs/heads/dfsg to salsa:refs/heads/dfsg


On Thu, 09 Apr 2020, Sandro Tosi wrote:

> FTR, i sent my changes this way instead on git because HEAD doesnt
> contain the 1:0.5.3-1 upload
> 
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#955585: libva: fails to detect driver with mesa 20

[Patrice Duroux]

On my side, I have also a different behavior under X11 (not working) or Xwayland
(working) and tty+weston (working) session. Don't know if it may be interesting.

Bug#956319: r-base-rqda: Error starting package

[Alisson Dopona]

Package: r-base-rqda
Version: RQDA 0.3-1
Severity: normal

Dear Maintainer,

When I start the RQDA package in my RStudio, using the command "library ()",
the following message appears:

(R: 10035): WARNING **: 15: 23: 14.976: invalid source position for horizontal
gradient

And every time I press any button in the package window, R responds to this
warning on the Console.

I looked in some forums, and realized that it happened with other software too,
such as FreeCad, Python and GTK themes, which led me to the conclusion that
there may be a bug in the Debian Buster installed on my machine.

I don't know what can be done. Please tell me if there is anything I can help
with.

Sincerely.



-- 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=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#956318: pari-gp: bison should be included in Build-Depends

[Ken T Takusagawa]

Package: pari-gp
Version: 2.11.3-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

apt-get build-dep pari-gp

does not install the "bison" package, which is needed to build pari-gp

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

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


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

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

Versions of packages pari-gp depends on:
ii  libc6 2.30-4
ii  libgmp10  2:6.2.0+dfsg-4
ii  libreadline8  8.0-4
ii  libx11-6  2:1.6.9-2

Versions of packages pari-gp recommends:
pn  pari-doc  
ii  pari-elldata  0.20190911-1
ii  pari-galdata  0.20080411-2
ii  pari-seadata  0.20090618-1

Versions of packages pari-gp suggests:
ii  pari-galpol  4.0-1
pn  pari-gp2c

-- no debconf information

Bug#956276: runescape: downloads unverified binary and runs it

[Markus Koschany]

Am 09.04.20 um 15:18 schrieb Stephen Kitt:
> Le 09/04/2020 14:47, Markus Koschany a écrit :
>> Am 09.04.20 um 13:58 schrieb Stephen Kitt:
>>> Le 09/04/2020 13:44, Markus Koschany a écrit :
 Am 09.04.20 um 13:24 schrieb Stephen Kitt:
> On Thu, 9 Apr 2020 12:37:03 +0200, Markus Koschany 
> wrote:
>> Am 09.04.20 um 11:36 schrieb Ivo De Decker:
> [...]
>>> Installing a Debian package doesn’t involve downloading a tarball from
>>> github.com or anywhere else. A packager downloads the tarball, vets it
>>> in some way or other (hopefully), and then uploads it to Debian
>>> infrastructure, where it is used to build the binary packages which
>>> users eventually download. After the initial upload, the contents don’t
>>> change, unless a new version is uploaded.
>>
>> In general we offer users the opportunity to rebuild a package from
>> scratch. That sometimes includes precise instructions in README.source
>> and a get-orig-source target in debian/rules but we often just assume
>> that running uscan will download the same original tarball that is
>> shipped in Debian's archive. In many cases this assumption is not true
>> and users will get a different tarball. Nowhere do we enforce that the
>> data is identical.
> 
> We’re not talking about rebuilding the package (at least, I wasn’t).
> 
> When a user installs a package in Debian, there’s a reasonable
> expectation that the user will get when the maintainer intended. Even if
> they choose to rebuild the package, the typical "apt source" invocation
> will retrieve the source last used to build the Debian package, *not*
> the upstream source.

I was using the rebuilding the package from scatch example because your
requirement that upstream files must be verified against a signature or
hash is simply not true here. That we verify Debian packages in main and
contrib with apt-secure is a given and is also true for runescape.
However packages in main do not require software outside of the archive
to function. They are self-contained. Thus your comparison between the
runescape script in non-free and any package in main is flawed.

> Incidentally, there is one place where we do enforce that the orig
> tarball doesn’t change: when uploading to the archive... So there is
> that expectation somewhere. All the effort that went into pristine-tar
> also suggests that at least some people care about it in other
> circumstances too.

We do the same for runescape...

> 
>>> Put another way, when you install a Debian package, you get the exact
>>> same contents as any other user installing the same version of the
>>> package, and thus a certain amount of collective trust can be built.
>>> This isn’t necessarily the case with the runescape package.
>>
>> Right, because the runescape package does neither qualify for main nor
>> contrib hence why it was put in non-free and for its purpose the level
>> of trust is sufficient.
> 
> The fact that a package is in non-free isn’t a blank cheque for it to do
> anything it wants; Policy 2.2.3 still requires packages in non-free to
> “meet all policy requirements presented in this manual that it is
> possible for them to meet”. I disagree with the level of trust involved
> but that’s a matter of opinion.


> Now to answer your initial question, as far as I can tell there is no
> Policy requirement that packages which download third-party files verify
> the contents.

Correct. So the severity of this bug report should not have been release
critical.

>>> Oh I know, we can’t do anything about trusting the publisher. The main
>>> issue is that if for whatever reason a compromised JAR is put in place
>>> on the upstream site, the runescape package will download it and run it
>>> without any warning. Even the TLS protection doesn’t do much since the
>>> download script doesn’t check the upstream certificate (so the site
>>> could be hijacked and it would still work).
>>
>> As Simon has already pointed out, the binary hash/signature will
>> probably change due to updates or other minor changes. That makes
>> runescape prone to other RC bugs and any implementation to validate the
>> launcher should take that into consideration.
> 
> Not necessarily: note that I said “without any warning”. The package
> could check the downloaded JAR against a signature, and if there’s a
> mismatch, warn the user before running it. That wouldn’t make the
> package prone to RC bugs.

Sure, you can put as many warnings in runescape as you wish but it is
still in non-free which is by definition _not part_ of Debian. This
alone is a stark warning for any Debian user and again the script is in
no way different than opening the website in your browser and
downloading the file manually. Do we require hashsums in Debian's
Firefox browser whenever someone downloads a file from the internet?

> 
>>> Consider it this way: the packager will presumably check the package
>>> before upload, and we can consider the JAR at that point to be
>>> trustworthy (for some 

Bug#956254: python3-pykdl: PyKDL crashes Python 3 interpretter (SIGABRT) if any API accepting a str is used

[Jochen Sprickerhof]

Hi Shane,

* Shane Loretz  [2020-04-08 22:19]:

Would you be willing to apply that patch and release a new version to
Buster and Sid?


I've uploaded a fixed version to sid and proposed an update to the 
release team in #956315. Thanks for opening the bug!


Cheers Jochen


signature.asc
Description: PGP signature

Bug#956008: diodon: didon eats up CPU power

[Oliver Sauder]

Link to corresponding upstream bug tracker issue
https://bugs.launchpad.net/diodon/+bug/1871008

Cheers,
Oliver

On 06.04.20 05:05, Christoph Anton Mitterer wrote:
> Package: diodon
> Version: 1.9.0-1
> Severity: important
> 
> 
> 
> Hi.
> 
> Just noted that, even though not used, diodon eats up quite some CPU power, 
> like 120mW or so all the time.
> 
> Attaching to it with strace it seems to constantly poll some resource, and 
> always getting errors on it.
> 
> 
> Any ideas?
> 
> Cheers,
> Chris.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_UNSIGNED_MODULE
> Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages diodon depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
> ii  libappindicator3-1   0.4.92-7
> ii  libc62.30-4
> ii  libdiodon0   1.9.0-1
> ii  libglib2.0-0 2.64.1-1
> ii  libgtk-3-0   3.24.17-1
> ii  libpeas-1.0-01.26.0-2
> ii  zeitgeist-core   1.0.2-3
> 
> diodon recommends no packages.
> 
> diodon suggests no packages.
> 
> -- no debconf information
> 

Bug#956317: RFS: prayer/1.3.5-dfsg1-6.1 [NMU, RC] -- standalone IMAP-based webmail server

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: prayer
   Version : 1.3.5-dfsg1-6.1
   Upstream Author : David Carter  et al
 * URL : http://www-uxsup.csx.cam.ac.uk/~dpc22/prayer/
 * License : GPL
 * Vcs : http://svn.kibibyte.se/prayer
   Section : mail

It builds those binary packages:

  prayer - standalone IMAP-based webmail server
  prayer-templates-src - templates for customizing Prayer Webmail
  prayer-templates-dev - tools for compiling Prayer templates
  prayer-accountd - account management daemon for Prayer

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/prayer/prayer_1.3.5-dfsg1-6.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix FTBFS. (Closes: #954039)
 - Thanks to Logan Rosen.


-- 
Regards
Sudip

Bug#954039: prayer: diff for NMU version 1.3.5-dfsg1-6.1

[Sudip Mukherjee]

Control: tags 954039 + pending

Dear maintainer,

I've prepared an NMU for prayer (versioned as 1.3.5-dfsg1-6.1) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it.

--
Regards
Sudip

diff -Nru prayer-1.3.5-dfsg1/debian/changelog 
prayer-1.3.5-dfsg1/debian/changelog
--- prayer-1.3.5-dfsg1/debian/changelog 2018-12-16 21:27:47.0 +
+++ prayer-1.3.5-dfsg1/debian/changelog 2020-04-09 17:50:55.0 +0100
@@ -1,3 +1,11 @@
+prayer (1.3.5-dfsg1-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS. (Closes: #954039)
+- Thanks to Logan Rosen.
+
+ -- Sudip Mukherjee   Thu, 09 Apr 2020 17:50:55 
+0100
+
 prayer (1.3.5-dfsg1-6) unstable; urgency=medium
 
   * Merge changes from Ubuntu (Closes: #913848).
diff -Nru prayer-1.3.5-dfsg1/debian/patches/glibc-2.30.patch 
prayer-1.3.5-dfsg1/debian/patches/glibc-2.30.patch
--- prayer-1.3.5-dfsg1/debian/patches/glibc-2.30.patch  1970-01-01 
01:00:00.0 +0100
+++ prayer-1.3.5-dfsg1/debian/patches/glibc-2.30.patch  2020-04-09 
17:44:41.0 +0100
@@ -0,0 +1,20 @@
+Description: Fix FTBFS
+ glibc removed obsolete, never-implemented XSI STREAMS declarations via:
+ 
https://sourceware.org/git/?p=glibc.git;a=commit;h=a0a0dc83173ce11ff45105fd32e5d14356cdfb9c
+ And so stropts.h file is not available anymore. 
+ 
+---
+
+--- prayer-1.3.5-dfsg1.orig/lib/os_linux.h
 prayer-1.3.5-dfsg1/lib/os_linux.h
+@@ -9,7 +9,10 @@
+ #include 
+ #include 
+ #include 
++
++#ifdef HAVE_STROPTS_H
+ #include 
++#endif
+ 
+ #include 
+ 
diff -Nru prayer-1.3.5-dfsg1/debian/patches/series 
prayer-1.3.5-dfsg1/debian/patches/series
--- prayer-1.3.5-dfsg1/debian/patches/series2018-12-16 21:27:47.0 
+
+++ prayer-1.3.5-dfsg1/debian/patches/series2020-04-09 17:42:45.0 
+0100
@@ -10,3 +10,4 @@
 openssl1.1.patch
 no-referrer.patch
 glibc-2.28.patch
+glibc-2.30.patch

Bug#956316: blender bug

[Cevdet bayır]

Package: blender

I do not know english. I translated this post with google translate.
2.80 and above of "blender" program (3d modeling and animation:
blender.org) in debian and debian based distributions (debian
bullseye, debian testing, mxlinux, sparky linux, elemantryos, lubuntu,
devuan (I don't remember which one I tried). , .82) versions fail.
2.82 version of the blender program in the manjaro warehouse that I
installed to check for the existence of the same error in different
distributions works without errors.
The blender program can be downloaded from blender.org in linux as
.tar.gz and run without installation. In this case, I do not encounter
any errors in debian and its derivatives. the error occurs only when i
install it from the repository.
The error is this: when we place the cursor on the color palette to
assign a color to an object we lay down, the program (blender) closes.

Bug#956281: Tries to load `iris_drv_video.so` but `iHD_drv_video.so` is installed

[Sebastian Ramacher]

Control: reassign -1 src:libva 2.7.0-1
Control: forcemerge 955585 -1

On 2020-04-09 12:31:06 +0200, Paul Menzel wrote:
> Package: vainfo
> Version: 2.6.0+ds1-1
> Severity: normal
> 
> Dear Debian folks,
> 
> 
> With an Intel Broadwell laptop
> 
> $ lspci -nn -s 0:2
> 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics
> 5500 [8086:1616] (rev 09)
> 
> I am trying to get H264 decoded on the GPU. Therefore, I installed
> *intel-media-va-driver-non-free* [1], which uninstalled
> *intel-media-va-driver*. Now, `va_openDriver()` fails to load the
> appropriate library.
> 
> ```
> $ vainfo
> libva info: VA-API version 1.7.0
> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iris_drv_video.so
> libva info: va_openDriver() returns -1
> vaInitialize failed with error code -1 (unknown libva error),exit

That's #955585 causing libva's detection of the driver to fail.
Reassigning and merging.

> $ sudo ln -s /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> /usr/lib/x86_64-linux-gnu/dri/iris_drv_video.so
> $ vainfo
> libva info: VA-API version 1.7.0
> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iris_drv_video.so
> libva info: Found init function __vaDriverInit_1_7
> libva info: va_openDriver() returns 0
> vainfo: VA-API version: 1.7 (libva 2.6.0)
> vainfo: Driver version: Intel iHD driver - 19.4.0
> vainfo: Supported profile and entrypoints
>   VAProfileNone   :   VAEntrypointVideoProc
>   VAProfileNone   :   VAEntrypointStats
>   VAProfileMPEG2Simple:   VAEntrypointVLD
>   VAProfileMPEG2Simple:   VAEntrypointEncSlice
>   VAProfileMPEG2Main  :   VAEntrypointVLD
>   VAProfileMPEG2Main  :   VAEntrypointEncSlice
>   VAProfileH264Main   :   VAEntrypointVLD
>   VAProfileH264Main   :   VAEntrypointEncSlice
>   VAProfileH264Main   :   VAEntrypointFEI
>   VAProfileH264High   :   VAEntrypointVLD
>   VAProfileH264High   :   VAEntrypointEncSlice
>   VAProfileH264High   :   VAEntrypointFEI
>   VAProfileVC1Simple  :   VAEntrypointVLD
>   VAProfileVC1Main:   VAEntrypointVLD
>   VAProfileVC1Advanced:   VAEntrypointVLD
>   VAProfileJPEGBaseline   :   VAEntrypointVLD
>   VAProfileH264ConstrainedBaseline:   VAEntrypointVLD
>   VAProfileH264ConstrainedBaseline:   VAEntrypointEncSlice
>   VAProfileH264ConstrainedBaseline:   VAEntrypointFEI
>   VAProfileVP8Version0_3  :   VAEntrypointVLD
> ```
> 
> How should the non-free library be included appropriately? It really makes a
> difference as mpv usages drops from around 40 % to 12 %.

As a temporary workaround: export LIBVA_DRIVER_NAME=iHD.

Cheers

> 
> 
> Kind regards,
> 
> Paul
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages vainfo depends on:
> ii  libc6   2.30-4
> ii  libva-drm2  2.7.0-1
> ii  libva-wayland2  2.7.0-1
> ii  libva-x11-2 2.7.0-1
> ii  libva2  2.7.0-1
> ii  libwayland-client0  1.18.0-1
> ii  libx11-62:1.6.9-2
> 
> vainfo recommends no packages.
> 
> vainfo suggests no packages.
> 
> -- no debconf information
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#956276: runescape: downloads unverified binary and runs it

[Stephen Kitt]

Le 09/04/2020 14:47, Markus Koschany a écrit :

Am 09.04.20 um 13:58 schrieb Stephen Kitt:

Le 09/04/2020 13:44, Markus Koschany a écrit :

Am 09.04.20 um 13:24 schrieb Stephen Kitt:

On Thu, 9 Apr 2020 12:37:03 +0200, Markus Koschany 
wrote:

Am 09.04.20 um 11:36 schrieb Ivo De Decker:

[...]

Installing a Debian package doesn’t involve downloading a tarball from
github.com or anywhere else. A packager downloads the tarball, vets it
in some way or other (hopefully), and then uploads it to Debian
infrastructure, where it is used to build the binary packages which
users eventually download. After the initial upload, the contents 
don’t

change, unless a new version is uploaded.


In general we offer users the opportunity to rebuild a package from
scratch. That sometimes includes precise instructions in README.source
and a get-orig-source target in debian/rules but we often just assume
that running uscan will download the same original tarball that is
shipped in Debian's archive. In many cases this assumption is not true
and users will get a different tarball. Nowhere do we enforce that the
data is identical.


We’re not talking about rebuilding the package (at least, I wasn’t).

When a user installs a package in Debian, there’s a reasonable 
expectation that the user will get when the maintainer intended. Even if 
they choose to rebuild the package, the typical "apt source" invocation 
will retrieve the source last used to build the Debian package, *not* 
the upstream source.


Incidentally, there is one place where we do enforce that the orig 
tarball doesn’t change: when uploading to the archive... So there is 
that expectation somewhere. All the effort that went into pristine-tar 
also suggests that at least some people care about it in other 
circumstances too.



Put another way, when you install a Debian package, you get the exact
same contents as any other user installing the same version of the
package, and thus a certain amount of collective trust can be built.
This isn’t necessarily the case with the runescape package.


Right, because the runescape package does neither qualify for main nor
contrib hence why it was put in non-free and for its purpose the level
of trust is sufficient.


The fact that a package is in non-free isn’t a blank cheque for it to do 
anything it wants; Policy 2.2.3 still requires packages in non-free to 
“meet all policy requirements presented in this manual that it is 
possible for them to meet”. I disagree with the level of trust involved 
but that’s a matter of opinion.


Now to answer your initial question, as far as I can tell there is no 
Policy requirement that packages which download third-party files verify 
the contents.



Oh I know, we can’t do anything about trusting the publisher. The main
issue is that if for whatever reason a compromised JAR is put in place
on the upstream site, the runescape package will download it and run 
it

without any warning. Even the TLS protection doesn’t do much since the
download script doesn’t check the upstream certificate (so the site
could be hijacked and it would still work).


As Simon has already pointed out, the binary hash/signature will
probably change due to updates or other minor changes. That makes
runescape prone to other RC bugs and any implementation to validate the
launcher should take that into consideration.


Not necessarily: note that I said “without any warning”. The package 
could check the downloaded JAR against a signature, and if there’s a 
mismatch, warn the user before running it. That wouldn’t make the 
package prone to RC bugs.



Consider it this way: the packager will presumably check the package
before upload, and we can consider the JAR at that point to be
trustworthy (for some value of trustworthy). But there is absolutely 
no
guarantee that the JAR which users will receive bears any resemblance 
to

the JAR checked by the packager.


If someone wants to implement some form of verification, hash or
something else, please do. I still don't see why this issue is a Policy
violation and why everyone seems to require the same standards as in
main or contrib when the package is in non-free and does not have to
comply with each and every part of the DFSG. In my opinion the package
is very simple and sufficient for its purpose. A warning message may
help here too. Construing a Policy violation seems wrong to me.


I agree that as things currently stand, this is a matter of opinion. I 
do however tend to think that we can hold the distribution to a higher 
standard than that strictly mandated by Policy, in particular because 
most of Policy is written within a certain framework (packages which are 
fully contained within the archive) and ignores issues such as this one.


And of course no one is asking *you* to do anything ;-).

Regards,

Stephen

Bug#936273: capstone: diff for NMU version 4.0.1+really+3.0.5-1.1

[Sandro Tosi]

Control: tags 936273 + patch


Dear maintainer,

I've prepared an NMU for capstone (versioned as 4.0.1+really+3.0.5-1.1). The 
diff
is attached to this message.

The git repo doesnt contain the latest release, 4.0.1+really+3.0.5-1

also in a recent update, gbp.conf requires pristine-tar, but no pristine-tar
branch is pushed to salsa.d.o

Regards.

diff -Nru capstone-4.0.1+really+3.0.5/debian/changelog capstone-4.0.1+really+3.0.5/debian/changelog
--- capstone-4.0.1+really+3.0.5/debian/changelog	2019-02-26 16:35:27.0 -0500
+++ capstone-4.0.1+really+3.0.5/debian/changelog	2020-04-09 12:51:10.0 -0400
@@ -1,3 +1,10 @@
+capstone (4.0.1+really+3.0.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936273
+
+ -- Sandro Tosi   Thu, 09 Apr 2020 12:51:10 -0400
+
 capstone (4.0.1+really+3.0.5-1) unstable; urgency=medium
 
   * Team upload
diff -Nru capstone-4.0.1+really+3.0.5/debian/control capstone-4.0.1+really+3.0.5/debian/control
--- capstone-4.0.1+really+3.0.5/debian/control	2019-02-26 16:35:27.0 -0500
+++ capstone-4.0.1+really+3.0.5/debian/control	2020-04-09 12:50:54.0 -0400
@@ -4,8 +4,8 @@
 Uploaders: Pranith Kumar 
 Build-Depends: debhelper (>= 12~),
dh-python,
-   python-all-dev, python3-all-dev,
-   python-setuptools, python3-setuptools,
+   python3-all-dev,
+   python3-setuptools,
cython (>= 0.19), cython3,
 Standards-Version: 4.3.0
 Section: devel
@@ -61,17 +61,6 @@
  This package contains cstool, a command-line tool to disassemble
  hexadecimal strings.
 
-Package: python-capstone
-Section: python
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, libcapstone3
-XB-Python-Version: ${python:Versions}
-Description: lightweight multi-architecture disassembly framework - Python bindings
- Capstone is a lightweight multi-platform, multi-architecture disassembly
- framework.
- .
- These are the Python 2 bindings.
-
 Package: python3-capstone
 Section: python
 Architecture: any
diff -Nru capstone-4.0.1+really+3.0.5/debian/python-capstone.install capstone-4.0.1+really+3.0.5/debian/python-capstone.install
--- capstone-4.0.1+really+3.0.5/debian/python-capstone.install	2019-02-26 16:34:50.0 -0500
+++ capstone-4.0.1+really+3.0.5/debian/python-capstone.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2.7
diff -Nru capstone-4.0.1+really+3.0.5/debian/rules capstone-4.0.1+really+3.0.5/debian/rules
--- capstone-4.0.1+really+3.0.5/debian/rules	2019-02-26 16:35:27.0 -0500
+++ capstone-4.0.1+really+3.0.5/debian/rules	2020-04-09 12:51:02.0 -0400
@@ -4,7 +4,7 @@
 include /usr/share/dpkg/architecture.mk
 
 %:
-	dh $@ --with python2,python3
+	dh $@ --with python3
 
 override_dh_auto_clean \
 override_dh_auto_configure \

Bug#956315: buster-pu: package orocos-kdl/1.4.0-7

[Jochen Sprickerhof]

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

Hi release team,

I would like to update orocos-kdl in buster to fix #956254 (PyKDL
crashes Python 3 interpreter). The bug shows a simple way to reproduce
the issue and the patch was taken from the upstream git. The diff to the
package is attached.

Cheers Jochen

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 451fd76..9dc72bf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+orocos-kdl (1.4.0-7+deb10u1) buster; urgency=medium
+
+  * Add patch for python3 std string conversion (Closes: #956254)
+
+ -- Jochen Sprickerhof   Thu, 09 Apr 2020 18:46:55 +0200
+
 orocos-kdl (1.4.0-7) unstable; urgency=medium
 
   * Add missing dependency (Closes: #913803)
diff --git 
a/debian/patches/0005-Fixed-python3-std-string-conversion-issue.patch 
b/debian/patches/0005-Fixed-python3-std-string-conversion-issue.patch
new file mode 100644
index 000..fd138cf
--- /dev/null
+++ b/debian/patches/0005-Fixed-python3-std-string-conversion-issue.patch
@@ -0,0 +1,35 @@
+From: Zihan Chen 
+Date: Mon, 14 May 2018 11:54:04 -0700
+Subject: Fixed python3 std string conversion issue
+
+---
+ python_orocos_kdl/PyKDL/std_string.sip | 11 +--
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+diff --git a/python_orocos_kdl/PyKDL/std_string.sip 
b/python_orocos_kdl/PyKDL/std_string.sip
+index e31324a..a399c9b 100644
+--- a/python_orocos_kdl/PyKDL/std_string.sip
 b/python_orocos_kdl/PyKDL/std_string.sip
+@@ -47,17 +47,16 @@
+ *sipCppPtr = new std::string;
+  return 1;
+  }
+- if (PyUnicode_Check(sipPy)) {
+-PyObject* s = PyUnicode_AsEncodedString(sipPy, "UTF-8", "");
+-*sipCppPtr = new std::string(PyUnicode_AS_DATA(s));
+-Py_DECREF(s);
+-return 1;
+- }
+ #if PY_MAJOR_VERSION < 3
+  if (PyString_Check(sipPy)) {
+ *sipCppPtr = new std::string(PyString_AS_STRING(sipPy));
+ return 1;
+  }
++#else
++ if (PyUnicode_Check(sipPy)) {
++*sipCppPtr = new std::string(PyUnicode_AsUTF8(sipPy));
++return 1;
++ }
+ #endif
+ 
+  return 0;
diff --git a/debian/patches/series b/debian/patches/series
index dbffb60..da119f6 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 0001-Added-CMakeLists-to-build-the-package.patch
 0002-Support-in-tree-compilation.patch
 0003-Don-t-install-OrocosKDLTargets.patch
+0005-Fixed-python3-std-string-conversion-issue.patch

Bug#955394: libvncserver 0.9.11+dfsg-1.3~deb9u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 955394 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libvncserver
Version: 0.9.11+dfsg-1.3~deb9u4

Explanation: fix heap overflow [CVE-2019-15690]

Bug#955409: tinyproxy 1.8.4-3~deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 955409 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: tinyproxy
Version: 1.8.4-3~deb9u2

Explanation: create PID file before dropping privileges to non-root account 
[CVE-2017-11747]

Bug#955510: jsp-api 2.3.4-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 955510 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: jsp-api
Version: 2.3.4-2+deb10u1

Explanation: fix stretch to buster upgrades that involve Tomcat 8

Bug#955509: websocket-api 1.1-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 955509 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: websocket-api
Version: 1.1-1+deb10u1

Explanation: fix stretch to buster upgrades that involve Tomcat 8

Bug#955395: libvncserver 0.9.11+dfsg-1.3+deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 955395 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libvncserver
Version: 0.9.11+dfsg-1.3+deb10u3

Explanation: fix heap overflow [CVE-2019-15690]

Bug#955508: el-api 3.0.0-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 955508 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: el-api
Version: 3.0.0-2+deb10u1

Explanation: fix stretch to buster upgrades that involve Tomcat 8

Bug#942520: oar 2.5.8-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 942520 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: oar
Version: 2.5.8-1+deb10u1

Explanation: revert to stretch behavior for Storable::dclone perl function, 
fixing recursion depth issues

Bug#955410: tinyproxy 1.10.0-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 955410 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: tinyproxy
Version: 1.10.0-2+deb10u1

Explanation: only set PIDDIR, if PIDFILE is a non-zero length string

Bug#933839: resource-agents 4.2.0-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 933839 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: resource-agents
Version: 4.2.0-2+deb10u1

Explanation: fix "ethmonitor does not list interfaces without assigned IP 
address"; remove no longer required xen-toolstack patch; fix non-standard usage 
in ZFS agent

Bug#954404: lwip 2.0.3-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 954404 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: lwip
Version: 2.0.3-3+deb10u1

Explanation: security fix [CVE-2020-8597]

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

[Pirate Praveen]

On Thu, Apr 9, 2020 at 6:04 pm, Eduard Bloch  wrote:

Hallo,
* Pirate Praveen [Wed, Apr 08 2020, 03:31:59PM]:



 On Sun, Apr 5, 2020 at 9:50 pm, Eduard Bloch  wrote:
 > Great. Anyway, after digging in messy code for days, I decided to 
make a
 > regular release ASAP. Please check version 3.4-1 when it has hit 
your
 > mirrors. If the problem does not go away then, again, please 
provide a

 > raw tcp dump.

 The problem is still there. Weirdly, a package download failed 
multiple
 times succeded after I ran the tcpdump command. The tcp dump 
attached. Will

 try again to capture when it actually fails.


Something is REALLY strange on your systems. Looking at the dump, I 
see

a flood of TCP retransmissions, for no apparent reason, basically
everything is retransmitted. That might happen sometimes but not in 
such

massive amount, especially not in a LAN. And the actual header is
reassembled late in the stream.

TCP should be able to untangle this mess, but it's still too weird.



boutil and terceiro also reported same problem yesterday in 
#debian-ruby irc (copying them). So I think the issue is not specific 
to me.


boutil: hi! do you experience many "Hash Sum mismatch" when doing 
upgrades with apt-cache-ng?


terceiro: I also get those sometimes, restarting usually helps


Is there a network switch inbetween?


It fails the same way with a wifi LAN and also via my mobile tethered 
connection.



Did you modify global network
settings (via procfs or driver module options)?


No, no such changes.


Or using non-standard
kernels on any side?



No.

You might also try patching and recompilling apt-cacher-ng (version 
3.4)
like this. It might mitigate the problem to a certain extent but even 
if

it does, it cannot fully it.



I will try this and report how it goes.


diff --git a/debian/changelog b/debian/changelog
index 0ec3fa6..b509482 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-apt-cacher-ng (3.4-1) unstable; urgency=low
+apt-cacher-ng (3.4-1.0.1) unstable; urgency=low

   * New upstream release
 + potentially closes: #952811
diff --git a/debian/rules b/debian/rules
index 8121788..5a2fd1f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@ include /usr/share/dpkg/buildflags.mk
 # cmake doesn't respect CPPFLAGS, use the workaround as suggested in
 # https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake
 CFLAGS += $(CPPFLAGS)
-CXXFLAGS += $(CPPFLAGS)
+CXXFLAGS += $(CPPFLAGS) -DNO_TCP_TUNING

 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)

Best regards,
Eduard.

--
 Nanu?  Wird postrm remove nicht aufgerufen, wenn man ein 
Paket gleich

purged?
 wer weiss das schon so genau
 ausser vielleicht ian und NMs

Bug#956314: ITS: can-utils maintenance

[Hsieh-Tseng Shen]

Package: can-utils
Severity: important

Hi Alexander,

Recently I notice can-utils is nice tool for socketcan especially when I
personally count on it for work, so I'm pleased to see it on debain.
However, I also found that the version is outmoded a bit compared to
current upstream release, and I think it's still worth to maintain its
debian package for consistency.

As usual, current can-utils package should match several criteria
according to package salvaging wiki:

1. Missing upstream releases (Now it's 2018.02.0-1 and we need to
upstream version 2020.02.04 at least.); AND
2. There is the need to upload the package to deal with upstream issues; AND
3. There is no visible activity regarding the package over six months[1];

Probably I can do NMU first, but again I'd like to contact with you via
this email to see if you still focus on it or not.

Any objections will be welcome, thank you.

[1] https://tracker.debian.org/pkg/can-utils

Thanks,
Woodrow
-- 
Woodrow Shen (Hsieh-Tseng Shen)
4FA0 D159 803F F8B6 34E9  5A38 3970 FE24 7CB6 9685
woodrow.s...@gmail.com


signature.asc
Description: PGP signature

Bug#956312: ITA: django-notification -- user notification management for Django

[Javier Ruano]

Package: wnpp
Severity: normal

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

[Eduard Bloch]

Hallo,
* Pirate Praveen [Wed, Apr 08 2020, 03:31:59PM]:
>
>
> On Sun, Apr 5, 2020 at 9:50 pm, Eduard Bloch  wrote:
> > Great. Anyway, after digging in messy code for days, I decided to make a
> > regular release ASAP. Please check version 3.4-1 when it has hit your
> > mirrors. If the problem does not go away then, again, please provide a
> > raw tcp dump.
>
> The problem is still there. Weirdly, a package download failed multiple
> times succeded after I ran the tcpdump command. The tcp dump attached. Will
> try again to capture when it actually fails.

Something is REALLY strange on your systems. Looking at the dump, I see
a flood of TCP retransmissions, for no apparent reason, basically
everything is retransmitted. That might happen sometimes but not in such
massive amount, especially not in a LAN. And the actual header is
reassembled late in the stream.

TCP should be able to untangle this mess, but it's still too weird.

Is there a network switch inbetween? Did you modify global network
settings (via procfs or driver module options)? Or using non-standard
kernels on any side?

You might also try patching and recompilling apt-cacher-ng (version 3.4)
like this. It might mitigate the problem to a certain extent but even if
it does, it cannot fully it.

diff --git a/debian/changelog b/debian/changelog
index 0ec3fa6..b509482 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-apt-cacher-ng (3.4-1) unstable; urgency=low
+apt-cacher-ng (3.4-1.0.1) unstable; urgency=low

   * New upstream release
 + potentially closes: #952811
diff --git a/debian/rules b/debian/rules
index 8121788..5a2fd1f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@ include /usr/share/dpkg/buildflags.mk
 # cmake doesn't respect CPPFLAGS, use the workaround as suggested in
 # https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake
 CFLAGS += $(CPPFLAGS)
-CXXFLAGS += $(CPPFLAGS)
+CXXFLAGS += $(CPPFLAGS) -DNO_TCP_TUNING

 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)

Best regards,
Eduard.

--
 Nanu?  Wird postrm remove nicht aufgerufen, wenn man ein Paket gleich
purged?
 wer weiss das schon so genau
 ausser vielleicht ian und NMs

Bug#956311: libsqlite3-dev: length(BLOB) should not convert to unicode

[Troy Korjuslommi]

Package: libsqlite3-dev
Version: 3.27.2-3
Severity: important


The LENGTH() function should return the number of bytes for a column of type 
BLOB
(according to sqlite3 documentation). However, when data is valid UTF-8, it 
returns the 
number of characters, not bytes. This means that LENGTH(column) is less than 
the number of
actual bytes returned from SELECT.


-- 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_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 libsqlite3-dev depends on:
ii  libc6-dev 2.28-10
ii  libsqlite3-0  3.27.2-3

libsqlite3-dev recommends no packages.

Versions of packages libsqlite3-dev suggests:
ii  sqlite3-doc  3.27.2-3

-- no debconf information

Bug#956309: Use system libraries

[Yangfl]

Graham Inggs  于2020年4月9日周四 下午11:45写道：
>
> Hi
>
> On Thu, 9 Apr 2020 at 17:36, Yangfl  wrote:
> > As libwhereami-dev is now available, please consider linking against
> > system library using -lwhereami instead of bundled whereami.c.
>
> Thanks for letting me know!
>
> I see libwhereami FTBFS on hurd and kfreebsd [1].
>
> Would you please consider applying the patch to whereami.c [2] that
> was accepted upstream in yabasic?
>
> Regards
> Graham
>
>
> [1] https://buildd.debian.org/status/package.php?p=libwhereami=unstable
> [2] https://github.com/marcIhm/yabasic/pull/29

Thanks for your patch. I'll take care of it.

Bug#956309: Use system libraries

[Graham Inggs]

Hi

On Thu, 9 Apr 2020 at 17:36, Yangfl  wrote:
> As libwhereami-dev is now available, please consider linking against
> system library using -lwhereami instead of bundled whereami.c.

Thanks for letting me know!

I see libwhereami FTBFS on hurd and kfreebsd [1].

Would you please consider applying the patch to whereami.c [2] that
was accepted upstream in yabasic?

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=libwhereami=unstable
[2] https://github.com/marcIhm/yabasic/pull/29

Bug#956309: Use system libraries

[Yangfl]

Source: yabasic
Severity: wishlist

Hi,

As libwhereami-dev is now available, please consider linking against
system library using -lwhereami instead of bundled whereami.c.

Bug#956310: Use system libraries

[Yangfl]

Source: ycmd
Severity: wishlist

Hi,

As libwhereami-dev is now available, please consider linking against
system library using -lwhereami instead of bundled whereami.c.

Bug#956308: libssh: CVE-2020-1730: Client/server denial of service when handling AES-CTR ciphers

[Salvatore Bonaccorso]

Source: libssh
Version: 0.9.3-2
Severity: important
Tags: security upstream
Forwarded: https://bugs.libssh.org/T213
Control: found -1 0.8.7-1

Hi,

The following vulnerability was published for libssh.

CVE-2020-1730[0]:
| Client/server denial of service when handling AES-CTR ciphers

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-1730
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1730
[1] https://bugs.libssh.org/T213
[2] https://www.libssh.org/security/advisories/CVE-2020-1730.txt

Regards,
Salvatore

Bug#936857: libfreenect: diff for version 1:0.5.3-2

[Sandro Tosi]

FTR, i sent my changes this way instead on git because HEAD doesnt
contain the 1:0.5.3-1 upload

On Thu, Apr 9, 2020 at 11:13 AM Yaroslav Halchenko  wrote:
>
>
> On Thu, 09 Apr 2020, Sandro Tosi wrote:
>
> > Control: tags 936857 + patch
>
>
> > Dear maintainer,
>
> > I've prepared an upload for libfreenect (versioned as 1:0.5.3-2). The diff
> > is attached to this message.
>
> Thank you Sandro!
>
> --
> Yaroslav O. Halchenko
> Center for Open Neuroscience http://centerforopenneuroscience.org
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
> WWW:   http://www.linkedin.com/in/yarik



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

Bug#936857: libfreenect: diff for version 1:0.5.3-2

[Yaroslav Halchenko]

On Thu, 09 Apr 2020, Sandro Tosi wrote:

> Control: tags 936857 + patch


> Dear maintainer,

> I've prepared an upload for libfreenect (versioned as 1:0.5.3-2). The diff
> is attached to this message.

Thank you Sandro!

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

Bug#956307: varnish: CVE-2020-11653

[Salvatore Bonaccorso]

Source: varnish
Version: 6.2.1-3
Severity: important
Tags: security upstream
Control: found -1 6.1.1-1+deb10u1
Control: found -1 6.1.1-1

Hi,

The following vulnerability was published for varnish.

CVE-2020-11653[0]:
| An issue was discovered in Varnish Cache before 6.0.6 LTS, 6.1.x and
| 6.2.x before 6.2.3, and 6.3.x before 6.3.2. It occurs when
| communication with a TLS termination proxy uses PROXY version 2. There
| can be an assertion failure and daemon restart, which causes a
| performance loss.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-11653
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11653
[1] https://varnish-cache.org/security/VSV5.html#vsv5

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore