Bug#963179: alpine: CVE-2020-14929

[Salvatore Bonaccorso]

Source: alpine
Version: 2.22+dfsg1-1
Severity: important
Tags: security upstream
Control: found -1 2.21+dfsg1-1.1
Control: found -1 2.20+dfsg1-7

Hi,

The following vulnerability was published for alpine.

CVE-2020-14929[0]:
| Alpine before 2.23 silently proceeds to use an insecure connection
| after a /tls is sent in certain circumstances involving PREAUTH, which
| is a less secure behavior than the alternative of closing the
| connection and letting the user decide what they would like to do.


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-14929
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14929
[1] 
https://repo.or.cz/alpine.git/commit/000edd9036b6aea5e6a06900ecd6c58faec665ab
[2] 
http://mailman13.u.washington.edu/pipermail/alpine-info/2020-June/008989.html

Regards,
Salvatore

Bug#953537: xfsdump fails to install in /usr merged system.

[Joseph Carter]

On Fri, Jun 19, 2020, at 19:10, peter green wrote:
> Putting the debian bug back in cc, previous mails are visible at 
> https://marc.info/?l=linux-xfs=159253950420613=2
> 
> On 19/06/2020 23:43, Dave Chinner wrote:
> 
> > Isn't the configure script supposed to handle install locations?
> > Both xfsprogs and xfsdump have this in their include/builddefs.in:
> > 
> > PKG_ROOT_SBIN_DIR = @root_sbindir@
> > PKG_ROOT_LIB_DIR= @root_libdir@@libdirsuffix@
> > 
> > So the actual install locations are coming from the autoconf setup
> > the build runs under. Looking in configure.ac in xfsprogs and
> > xfsdump, they both do the same thing:
> > 
> The issue is that xfsdump installs the programs in /sbin but it *also* 
> creates symlinks in /usr/sbin,
> presumablly at some point the binaries were moved to /sbin but the 
> developers wanted to keep
> packages that hardcoded the paths working.
> 
> Those symlinks are suppressed if installing directly to a merged-usr 
> system, which is fine for
> end-users installing the program directly but isn't useful if 
> installing to a destination dir for
> packaing purposed.

Seems proper thing to do is install xfsdump/xfsrestore where the files are 
supposed to live and allow a packaged version to forego installing the symlinks 
by configuring with an appropriate --without option. Even if installing a 
symlink is expected (the --without option is not supplied), a test should be 
performed after installing the real binaries to determine if the symlinks are 
unnecessary (path already exists and either contains the requisite symlink or 
contains the just installed binary via symlink, bind mount, or whatever.)

Joseph

Bug#963178: /etc/cron.daily/calendar[5]: .: /etc/default/bsdmainutils: No such file or directory

[Thorsten Glaser]

Package: calendar
Version: 12.1.1
Severity: normal

I get the following mail from cron after installing the calendar package:

/etc/cron.daily/calendar[5]: .: /etc/default/bsdmainutils: No such file or 
directory

I never changed either calendar or bsdmainutils config files on this
system (I install it merely for the binary).

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages calendar depends on:
ii  cpp  4:9.2.1-3.1
ii  libbsd0  0.10.0-1
ii  libc62.30-8

calendar recommends no packages.

calendar suggests no packages.

-- Configuration Files:
/etc/cron.daily/calendar changed:
. /etc/default/bsdmainutils
[ x$RUN_DAILY = xtrue ] || exit 0
[ -x /usr/sbin/sendmail ] || exit 0
if [ ! -x /usr/bin/cpp ]; then
  echo "The cpp package is needed to run calendar."
  exit 1
fi
/usr/bin/calendar -a


-- no debconf information

Bug#938584: sugar-calculate-activity: Python2 removal in sid/bullseye - reopen 938584

[Sandro Tosi]

Control: reopen -1

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

(binary:sugar-calculate-activity)Recommends->python-matplotlib

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

Bug#937290: pillow: Python2 removal in sid/bullseye - reopen 937290

[Sandro Tosi]

Control: reopen -1

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

(source:pillow)Build-Depends->python2

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

Bug#938605: svgtune: Python2 removal in sid/bullseye - reopen 938605

[Sandro Tosi]

Control: reopen -1

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

(binary:svgtune)Depends->python
(binary:svgtune)Depends->python-lxml

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

Bug#963177: calendar: trying to overwrite '/etc/calendar/default', which is also in package bsdmainutils 12.1.1

[Thorsten Glaser]

Package: calendar
Version: 12.1.1
Severity: serious
Justification: does not install

Selecting previously unselected package calendar.
(Reading database ... 406194 files and directories currently installed.)
Preparing to unpack .../calendar_12.1.1_x32.deb ...
Unpacking calendar (12.1.1) ...
dpkg: error processing archive /var/cache/apt/archives/calendar_12.1.1_x32.deb 
(--unpack):
 trying to overwrite '/etc/calendar/default', which is also in package 
bsdmainutils 12.1.1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/calendar_12.1.1_x32.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages calendar depends on:
ii  cpp  4:9.2.1-3.1
ii  libbsd0  0.10.0-1
ii  libc62.30-8

calendar recommends no packages.

calendar suggests no packages.

Bug#938027: [Python-modules-team] Bug#938027: python-pip: Python2 removal in sid/bullseye - reopen 938027

[Scott Kitterman]

On June 20, 2020 2:40:58 AM UTC, Sandro Tosi  wrote:
>Control: reopen -1
>
>This bug was closed, but the package has still some dependencies
>towards
>Python2 packages, in details:
>
>(source:python-pip)Build-Depends->python-pkg-resources
>(source:python-pip)Build-Depends->python-setuptools
>
>Re-opening, so that they can be taken care of.

Yes, those were readded later.  Once the decision to remove the python2.7 
interpreter is taken it'll be quick enough to change them.

Scott K

Bug#963175: chromium: Chromium crash on https://novnc.com/noVNC/vnc.html

[John Wong]

Package: chromium
Version: 81.0.4044.92-1
Severity: normal

Dear Maintainer,
 I noticed chromium crash on https://novnc.com/noVNC/vnc.html,
 after upgrade

 libavcodec58:amd64 to 7:4.3-2
 libavformat58:amd64 to 7:4.3-2
 libavutil56:amd64 to 7:4.3-2

 Please help, thank you.

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

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

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


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

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

Versions of packages chromium depends on:
ii  chromium-common  81.0.4044.92-1
ii  libasound2   1.2.2-2.2
ii  libatk-bridge2.0-0   2.34.1-3
ii  libatk1.0-0  2.36.0-2
ii  libatspi2.0-02.36.0-2
ii  libavcodec58 7:4.3-2
ii  libavformat587:4.3-2
ii  libavutil56  7:4.3-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcups2 2.3.3-1
ii  libdbus-1-3  1.12.18-1
ii  libdrm2  2.4.101-2
ii  libevent-2.1-7   2.1.11-stable-1
ii  libexpat12.2.9-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgbm1  20.1.1-1
ii  libgcc-s110.1.0-4
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.3-1
ii  libgtk-3-0   3.24.20-1
ii  libharfbuzz0b2.6.7-1
ii  libicu63 63.2-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3.1
ii  liblcms2-2   2.9-4+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.25-1
ii  libnss3  2:3.53-1
ii  libopenjp2-7 2.3.1-1
ii  libopus0 1.3-1+b1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpng16-16  1.6.37-2
ii  libpulse013.0-5
ii  libre2-6 20200401+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.1.0-4
ii  libvpx6  1.8.2-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.9-2+b1
ii  libx11-xcb1  2:1.6.9-2+b1
ii  libxcb-dri3-01.14-2
ii  libxcb1  1.14-2
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxml2  2.9.10+dfsg-5+b1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.34-4
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  81.0.4044.92-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+5
ii  xdg-utils  1.1.3-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox 81.0.4044.92-1
pn  fonts-liberation 
ii  libgl1-mesa-dri  20.1.1-1
pn  libu2f-udev  
pn  system-config-printer
ii  upower   0.99.11-2
ii  xfce4-notifyd [notification-daemon]  0.4.4-1+b1

Versions of packages chromium-sandbox depends on:
ii  libc6  2.30-8

-- Configuration Files:
/etc/chromium/master_preferences changed:
{
  "distribution": {
 "import_bookmarks": false,
 "import_bookmarks_from_file": "/etc/chromium/initial_bookmarks.html",
 "make_chrome_default": false,
 "make_chrome_default_for_user": false,
 "verbose_logging": true,
 "skip_first_run_ui": true,
 "create_all_shortcuts": true,
 "suppress_first_run_default_browser_prompt": true
  },
  "browser": {
 "show_home_button": true,
 "has_seen_welcome_page" : true,
 "check_default_browser" : false
  },
  "profile": {
 "default_content_setting_values": {
"payment_handler": 2
 }
  },
  "bookmark_bar": {
 "show_on_all_tabs": true
  },
  "net": {
 "network_prediction_options": 2
  },
  "search": {
 "suggest_enabled": false
  },
  "signin": {
 "allowed": false,
 "allowed_on_next_startup": false
  },
  "autofill": {
 "profile_enabled": false,
 "credit_card_enabled": false
  },
  "payments": {
 "can_make_payment_enabled": 

Bug#938249: python-virtualenv: Python2 removal in sid/bullseye - reopen 938249

[Sandro Tosi]

Control: reopen -1

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

(source:python-virtualenv)Testsuite-Triggers->python-six
(source:python-virtualenv)Testsuite-Triggers->python2

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

Bug#938027: python-pip: Python2 removal in sid/bullseye - reopen 938027

[Sandro Tosi]

Control: reopen -1

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

(source:python-pip)Build-Depends->python-pkg-resources
(source:python-pip)Build-Depends->python-setuptools

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

Bug#938587: sugar-etoys-activity: Python2 removal in sid/bullseye - reopen 938587

[Sandro Tosi]

Control: reopen -1

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

(binary:sugar-etoys-activity)Depends->python

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

Bug#937009: mercurial: Python2 removal in sid/bullseye - reopen 937009

[Sandro Tosi]

Control: reopen -1

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

(source:mercurial)Build-Depends->python-all-dev
(source:mercurial)Build-Depends->python-docutils
(source:mercurial)Build-Depends->python-roman
(source:mercurial)Testsuite-Triggers->python-docutils
(source:mercurial)Testsuite-Triggers->python-pygments
(source:mercurial)Testsuite-Triggers->python-subversion
(source:mercurial)Testsuite-Triggers->python2.7-dev
(binary:mercurial-common)Depends->python2:any
(binary:mercurial-common)Depends->python2:any
(binary:mercurial)Depends->python2
(binary:mercurial)Depends->python2
(binary:mercurial)Depends->python2:any
(binary:mercurial)Depends->python2:any

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

Bug#937166: nuitka: Python2 removal in sid/bullseye - reopen 937166

[Sandro Tosi]

Control: reopen -1

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

(binary:nuitka)Depends->python-dev

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

Bug#953537: xfsdump fails to install in /usr merged system.

[peter green]

Putting the Debian bug back in cc, for earlier mails please see 
https://marc.info/?l=linux-xfs=159253950420613=2
Eric Sandeen wrote:


How does debian fix this for xfsprogs?  Doesn't the same issue exist?



I'm not seeing any cases like xfsdump where a binary is located in /sbin but 
symlinked from /usr/sbin .

Debian merged-usr systems can deal with files in /sbin and files in /usr/sbin, 
what needs special
treatment is filenames that exist in both.

Bug#953537: xfsdump fails to install in /usr merged system.

[peter green]

Putting the debian bug back in cc, previous mails are visible at 
https://marc.info/?l=linux-xfs=159253950420613=2

On 19/06/2020 23:43, Dave Chinner wrote:


Isn't the configure script supposed to handle install locations?
Both xfsprogs and xfsdump have this in their include/builddefs.in:

PKG_ROOT_SBIN_DIR = @root_sbindir@
PKG_ROOT_LIB_DIR= @root_libdir@@libdirsuffix@

So the actual install locations are coming from the autoconf setup
the build runs under. Looking in configure.ac in xfsprogs and
xfsdump, they both do the same thing:


The issue is that xfsdump installs the programs in /sbin but it *also* creates 
symlinks in /usr/sbin,
presumablly at some point the binaries were moved to /sbin but the developers 
wanted to keep
packages that hardcoded the paths working.

Those symlinks are suppressed if installing directly to a merged-usr system, 
which is fine for
end-users installing the program directly but isn't useful if installing to a 
destination dir for
packaing purposed.

Bug#963174: plasma-desktop: Missing desktop-file-utils dependency causes x-scheme-handler be ignored

[Jose Angel Pastrana]

Package: plasma-desktop
Version: 4:5.17.5-3
Severity: minor

Dear Maintainer,

desktop-file-utils is needed for handling MimeType attribute in desktop files. 
This package generates /usr/share/applications/mimeinfo.cache file which is 
used by other applications as Firefox [1].

Steps to reproduce this bug:
Prerequisites: firefox and remmina installed, desktop-file-utils not installed

1. Open Firefox
2. Write vnc://192.168.1.1 in tab bar and press enter
3. Url is incomprehensible for Firefox
4. Install desktop-file-utils package and repeat the preceding steps
5. Remmina opens

Explanation:
Remmina desktop file (/usr/share/applications/remmina-file.desktop) contains 
MimeType=x-scheme-handler/vnc and desktop-file-utils has written 
x-scheme-handler/vnc=org.remmina.Remmina.desktop;remmina-file.desktop; entry in 
/usr/share/applications/mimeinfo.cache

Other desktops:
If you execute apt-cache rdepends desktop-file-utils, you may find that 
desktop-file-utils is a dependency for LXQT (pcmanfm-qt package), GNOME 
(gnome-control-center), MATE (mate-control-center) and CINNAMON 
(cinnamon-control-center)

Request:
Add desktop-file-utils as dependecy for plasma-desktop (/ or for a secondary 
package which fits better)

Thanks in advance

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=727422


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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.17.5-2
ii  kactivitymanagerd5.17.5-2
ii  kde-cli-tools4:5.17.5-2
ii  kded55.70.0-1
ii  kio  5.70.1-1
ii  kpackagetool55.70.0-1
ii  libc62.30-8
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgcc-s110.1.0-3
ii  libglib2.0-0 2.64.3-1
ii  libibus-1.0-51.5.22-5
ii  libkf5activities55.70.0-1
ii  libkf5activitiesstats1   5.70.0-1
ii  libkf5archive5   5.70.0-1
ii  libkf5authcore5  5.70.0-1
ii  libkf5baloo5 5.70.0-2
ii  libkf5codecs55.70.0-1
ii  libkf5completion55.70.0-1
ii  libkf5configcore55.70.0-1
ii  libkf5configgui5 5.70.0-1
ii  libkf5configwidgets5 5.70.0-1
ii  libkf5coreaddons55.70.0-1
ii  libkf5dbusaddons55.70.0-1
ii  libkf5declarative5   5.70.0-1
ii  libkf5emoticons-bin  5.70.0-1
ii  libkf5emoticons5 5.70.0-1
ii  libkf5globalaccel-bin5.70.0-1
ii  libkf5globalaccel5   5.70.0-1
ii  libkf5guiaddons5 5.70.0-2
ii  libkf5i18n5  5.70.0-1
ii  libkf5iconthemes55.70.0-1
ii  libkf5itemmodels55.70.0-1.1
ii  libkf5itemviews5 5.70.0-1
ii  libkf5jobwidgets55.70.0-1
ii  libkf5kcmutils5  5.70.0-1
ii  libkf5kdelibs4support5   5.70.0-2
ii  libkf5kiocore5   5.70.1-1
ii  libkf5kiofilewidgets55.70.1-1
ii  libkf5kiowidgets55.70.1-1
ii  libkf5newstuff5  5.70.0-1
ii  libkf5notifications5 5.70.0-1
ii  libkf5notifyconfig5  5.70.0-1
ii  libkf5package5   5.70.0-1
ii  libkf5parts5 5.70.0-1
ii  libkf5plasma55.70.1-1
ii  libkf5plasmaquick5   5.70.1-1
ii  libkf5quickaddons5   5.70.0-1
ii  libkf5runner55.70.0-1
ii  libkf5service-bin5.70.0-1
ii  libkf5service5   5.70.0-1
ii  libkf5solid5 5.70.0-1
ii  libkf5sonnetui5  5.70.0-1
ii  libkf5wallet-bin 5.70.0-1
ii  libkf5wallet55.70.0-1
ii  libkf5widgetsaddons5 5.70.0-1
ii  libkf5windowsystem5  5.70.0-1
ii  libkf5xmlgui55.70.0-1
ii  libkfontinst5 

Bug#962917: libatomic-ops: FTBFS in the testsuite on riscv64 due to missing -pthread

[Ivan Maidanski]

Please disregard my previous patch, and use the following one:
https://github.com/ivmai/libatomic_ops/commit/f067c258d5df3dc364857c11718be4516ca73ea0.patch
 
Karsten, could you please test it?
 
Regards,
Ivan

Bug#963118: mate-terminal: several issues and crashes with --window and --tab and --command

[Norbert Preining]

Hi Mike,

> Urgh, these are nasty!!! Do you plan working on a patch (like last time)?

Well, if time allows, yes ;-) Not sure though how fast.

Liebe Grüße

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#963173: ITP: go-shadowsocks2 -- Next-generation Shadowsocks in Go

[Guobang Bi]

Package: wnpp
Severity: wishlist
Owner: Guobang Bi 

* Package name: go-shadowsocks2
  Version : 0.1.0-1
  Upstream Author : shadowsocks
* URL : https://github.com/shadowsocks/go-shadowsocks2
* License : Apache-2.0
  Programming Lang: Go
  Description : Next-generation Shadowsocks in Go

Project go-shadowsocks2 is a fresh implementation of Shadowsocks in Go.
It's a tunnel proxy that helps you to bypass firewall.



signature.asc
Description: OpenPGP digital signature

Bug#963172: ITP: golang-github-riobard-go-bloom -- Bloom filter in Go

[Guobang Bi]

Package: wnpp
Severity: wishlist
Owner: Guobang Bi 

* Package name: golang-github-riobard-go-bloom
  Version : 0.0~git20200213.218e170-1
  Upstream Author : Rio
* URL : https://github.com/riobard/go-bloom
* License : TODO
  Programming Lang: Go
  Description : Bloom filter in Go

Bloom Filter using double hashing.

dependency of go-shadowsocks2



signature.asc
Description: OpenPGP digital signature

Bug#940165: speedtest-cli: Wrong upload speed

[Antoine Beaupré]

On 2020-02-21 15:56:53, Gregor Zattler wrote:
> Dear Mantainer,
> * carlos  [2019-12-04; 19:32]:
>>
>> I have checked and the same python script 
>> /usr/lib/python3/dist-packages/speedtest.py
>> that comes with the package gives the correct result if run with python2 
>> instead of
>> the default python3.
>>
>> In my case:
>>
>> $ python3  /usr/lib/python3/dist-packages/speedtest.py --no-download
>> Retrieving speedtest.net configuration...
>> Testing from Vodafone Spain (79.108.127.65)...
>> Retrieving speedtest.net server list...
>> Selecting best server based on ping...
>> Hosted by ServiHosting Networks (Madrid) [2.22 km]: 26.667 ms
>> Skipping download test
>> Testing upload 
>> speed..
>> Upload: 1.63 Mbit/s
>>
>>
>> And with python2:
>>
>> $ python2  /usr/lib/python3/dist-packages/speedtest.py --no-download
>> Retrieving speedtest.net configuration...
>> Testing from Vodafone Spain (79.108.127.65)...
>> Retrieving speedtest.net server list...
>> Selecting best server based on ping...
>> Hosted by ServiHosting Networks (Madrid) [2.22 km]: 27.954 ms
>> Skipping download test
>> Testing upload 
>> speed
>> Upload: 91.16 Mbit/s
>>
>>
>> So it seems to be some issue with the way it runs under the python3 
>> interpreter.
>
> I confirm this on an up-to-date debian buster system.
>
> Today I downloaded
> wget -O speedtest-cli 
> https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
>
> which has
>
> __version__ = '2.1.2'
>
> and tested with python2 and python3:  Same test result with both
> python interpreters.  So this is probably already fixed in testing.

I suspect this might be a fix:

https://github.com/sivel/speedtest-cli/commit/a8a32650015997f7

I also wonder if severity should be raised here to fix this in stable.

A.

-- 
The Net treats censorship as damage and routes around it.
 - John Gilmore

Bug#963171: ITP: golang-github-liamhaworth-go-tproxy -- Linux Transparent Proxy library for Golang

[Guobang Bi]

Package: wnpp
Severity: wishlist
Owner: Guobang Bi 

* Package name: golang-github-liamhaworth-go-tproxy
  Version : 0.0~git20190726.ef7efd7-1
  Upstream Author : Liam Haworth
* URL : https://github.com/LiamHaworth/go-tproxy
* License : Expat
  Programming Lang: Go
  Description : Linux Transparent Proxy library for Golang

Project go-tproxy provides an easy to use wrapper for the
Linux Transparent Proxy functionality.

dependency of trojan-go



signature.asc
Description: OpenPGP digital signature

Bug#963169: minor correction to my initial report

[Howard Johnson]

I wrote:

3) Furthermore, you can run `# /usr/sbin/dwww-find mysql` and you can see that
the man page for the mysql COMMAND is actually contained in the html.


More correctly:

3) Furthermore, you can run `# /usr/sbin/dwww-find mysql` and you can see that
the *_a man page LINK for the mysql command is now available*_ in the html.


Thanks!

Bug#963107: "Encrypted connection unavailable" when using pre-authenticated connection

[Josh Triplett]

On Thu, Jun 18, 2020 at 10:41:37PM -0700, Josh Triplett wrote:
> Package: mutt
> Version: 1.14.3-1
> Severity: important
> 
> "important" because it makes a previously working configuration
> unusable.
> 
> The fix for CVE-2020-14093 makes it so that when using a
> preauthenticated connection (using `set tunnel` to SSH to the IMAP
> server), mutt just prints "Encrypted connection unavailable" and refuses
> the connection. An strace shows that mutt successfully runs SSH and gets
> the preauthenticated IMAP connection.
> 
> I do not have any ssl-related options set. Best guess: the default
> ssl_starttls=yes makes mutt think it should starttls over preauth, which
> it now avoids due to the CVE.

I can confirm that setting ssl_starttls=no allows preauthenticated IMAP
connections using `set tunnel` to work again.

Bug#846296: ext4 checksum error

[Ralph Katz]

Package: e2fsprogs
Version: 1.44.5-1+deb10u3
Followup-For: Bug #846296

Dear Maintainer,

I have similar ext4 checksum errors as reported in this bug.

Initially, my new computer had repeated hangs/crashes as reported and
discussed here:

Buster System hangs, requires hard reboot
https://lists.debian.org/debian-user/2020/04/msg01027.html

Smartctl long tests run weekly have never shown any errors.

After running badblocks, the system now is able to run for a few weeks
between reboots before producing checksum errors like these:

> May 17 07:26:51 spike3 kernel: [374141.288500] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55841836: comm updatedb.mlocat: iget: checksum 
> invalid
> May 17 07:26:51 spike3 kernel: [374141.316179] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55841838: comm updatedb.mlocat: iget: checksum 
> invalid
> May 17 10:35:09 spike3 kernel: [385439.38] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55841836: comm chromium: iget: checksum invalid
> May 17 10:35:09 spike3 kernel: [385439.406468] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55841836: comm chromiu:disk$0: iget: checksum invalid
> May 17 10:53:58 spike3 kernel: [386567.602617] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55838166: comm rsync: iget: checksum invalid
> May 27 16:34:28 spike3 kernel: [547548.409169] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842896: comm Cache2 I/O: iget: checksum invalid
> May 27 16:34:28 spike3 kernel: [547548.458231] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842894: comm Cache2 I/O: iget: checksum invalid
> May 27 16:34:29 spike3 kernel: [547548.648953] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842881: comm Cache2 I/O: iget: checksum invalid
> May 27 16:34:29 spike3 kernel: [547548.676915] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842890: comm Cache2 I/O: iget: checksum invalid
> May 27 16:34:29 spike3 kernel: [547548.732253] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842893: comm Cache2 I/O: iget: checksum invalid
> May 27 16:34:29 spike3 kernel: [547548.766440] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842891: comm Cache2 I/O: iget: checksum invalid
> May 27 16:34:29 spike3 kernel: [547549.017605] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842889: comm Cache2 I/O: iget: checksum invalid
> May 27 16:34:29 spike3 kernel: [547549.081653] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842895: comm Cache2 I/O: iget: checksum invalid
> May 27 16:34:29 spike3 kernel: [547549.137829] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842882: comm Cache2 I/O: iget: checksum invalid
> May 27 16:34:29 spike3 kernel: [547549.229511] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842896: comm Cache2 I/O: iget: checksum invalid
> Jun  2 10:31:50 spike3 kernel: [843980.429104] EXT4-fs error: 9 callbacks 
> suppressed
> Jun  2 10:31:50 spike3 kernel: [843980.429107] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842085: comm rsync: iget: checksum invalid
> Jun  2 10:31:50 spike3 kernel: [843980.452720] EXT4-fs error (device sda2): 
> ext4_lookup:1591: inode #55842086: comm rsync: iget: checksum invalid

As of this post,
> ralph@spike3:~$ uptime
>  16:40:08 up 6 days, 0 min,  1 user,  load average: 0.50, 0.54, 0.5
> ralph@spike3:~$ zgrep 'EXT4-fs error' /var/log/syslog*
-- reports only errors before the current reboot.

Thanks!

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=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 e2fsprogs depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcom-err2  1.44.5-1+deb10u3
ii  libext2fs2   1.44.5-1+deb10u3
ii  libss2   1.44.5-1+deb10u3
ii  libuuid1 2.33.1-0.1

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.2-25

-- no debconf information

Bug#963170: Debian 10 Buster x64 - BlueZ: 5.50-1.2~deb10u1

[pham...@bluewin.ch]

Package: bluez 
Version: 5.50-1.2~deb10u1
Bug Description :
Hello, I'm would like to use my new bluetooth headphones Sony WH-1000XM3 on 
Linux Debian 10 Buster.
When I link it to my laptop everything works perfectly the first time. If I 
turn off this headset and I want to reuse it later, the connection is made but 
instead of being of good quality (A2DP Sink) it is done in SBS (HSP / HFP) 
which is of very poor quality. I am very unhappy with the result...
I'm on Debian 10 Buster x64 Bits, Desktop environment Cinnamon 3.8, BlueZ is on 
v. 5.50-1.2~deb10u1, blueman: 2.0.8-1
According to this information : 
https://github.com/blueman-project/blueman/issues/1209#issuecomment-626328772
BlueZ: 5.50-1.2~deb10u1 are the problem... Please add a 5.52 version to Sid and 
/ or to Backports. 
Best regards.

Bug#963169: dwww: `--package` should be `--program` in usage: to agree with manpage and actual function

[Howard Johnson]

Package: dwww
Version: 1.13.5
Severity: normal

Hi.

I believe that the `usage:` message for dwww-find has an error.


Here is how you observe and confirm this:

1) Run `$ man dwww-find` and observe that dwww-find only spells out a
`--program` option, not a `--package` option.

2) Run `# /usr/sbin/dwww-find` and observe that the usage message says:

usage: dwww-find [--package  ...

It doesn't make sense to get a man page for a package.  In fact a package could
have more than one man page.

3) Furthermore, you can run `# /usr/sbin/dwww-find mysql` and you can see that
the man page for the mysql COMMAND is actually contained in the html.

4) Finally, you can run `# /usr/sbin/dwww-find mariadb-client-core | grep 'Not
found!'`, and although this is a valid package, no content for the html man
page is found.





To fix replace the word 'package' with 'program' in

dwww-1.13.5/scripts/dwww-find .



-- System Information:
Debian Release: 10.4
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dwww depends on:
ii  apache2 [httpd-cgi]2.4.38-3+deb10u3
ii  debconf [debconf-2.0]  1.5.71
ii  debianutils4.8.6.1
ii  doc-base   0.10.8
ii  file   1:5.35-4+deb10u1
ii  libc6  2.28-10
ii  libfile-ncopy-perl 0.36-2
ii  libmime-types-perl 2.17-1
ii  man-db 2.8.5-2
ii  mime-support   3.62
ii  perl   5.28.1-6
ii  sensible-utils 0.0.12
ii  ucf3.0038+nmu1

Versions of packages dwww recommends:
ii  apache2 [httpd]  2.4.38-3+deb10u3
ii  apt  1.8.2.1
ii  dlocate  1.07+nmu1
ii  info2www 1.2.2.9-24
ii  swish++  6.1.5-5

Versions of packages dwww suggests:
ii  chromium [www-browser]  80.0.3987.162-1~deb10u1
ii  doc-debian  6.4
pn  dpkg-www
ii  google-chrome-stable [www-browser]  83.0.4103.106-1
ii  lynx [www-browser]  2.8.9rel.1-3
ii  w3m [www-browser]   0.5.3-37

-- Configuration Files:
/etc/apache2/conf-available/dwww.conf changed [not included]

-- debconf information excluded

Bug#961681: Bug #961681: octave 5.2.0 and java child processes

[Benjamin Moody]

> - Why does the stack overflow when the JVM is loaded from Octave, and
>   not when the JVM is launched "normally"?  (What is that worker
>   thread doing that would cause it to use any appreciable amount of
>   stack space?)
>
> - Why, on bullseye, is it unable to create the worker thread in the
>   first place?  (The error message suggests that pthread_create
>   doesn't like the specified attributes for some reason - why is
>   that?)  And again, why only in Octave?

It appears that the answers to both questions are the same: because
Octave uses a (relatively speaking) huge thread-local storage area,
and, at least when using glibc, this size must be included in the
"thread stack size" that is requested when calling pthread_create.

If I use gdb to break on pthread_create:

- when running octave 5.2.0 on bullseye: __static_tls_size = 156736

- when running octave 4.4.1 on buster: __static_tls_size = 95296

- when running a simple Java test program: __static_tls_size = 4160

which would seem to explain all of these issues.

(OpenJDK 8 seems to use a somewhat larger stack size by default than
OpenJDK 11 does - 233472 vs 139264 bytes.  I'm not sure why this is
different from the stackSize passed to the Thread constructor, but it
is.)

So should this be considered a bug in OpenJDK, or in Octave?

I don't think it's reasonable to expect Octave to limit its use of
thread-local storage in order to fit an arbitrary undocumented limit
that was picked out of thin air by the Java developers.  On the other
hand, it's not entirely unreasonable for Java to attempt to avoid
allocating a huge stack when it creates an internal worker thread that
doesn't need one.

(At the same time, I do think it is wrong for OpenJDK not to account
for the possibility of failure in this case.  If the reaper thread
crashes, that should cause waitFor to fail with an exception, but not
to hang.)

I don't know whether pthreads has any way to create a thread *without*
giving it a copy of the global static TLS area, and I don't know
whether that would work at all even if it were possible.  I also don't
know if there's any remotely portable way for a program to find out
the size of its own static TLS area.  So I have no idea how difficult
it would be to fix this bug at the OpenJDK level.

Certainly it seems that the simplest fix would be for Octave to set
the jdk.lang.processReaperUseDefaultStackSize property.

Bug#963036: Wild guess to fix this bug

[Sébastien Villemot]

Dear Georges,

Le jeudi 18 juin 2020 à 18:12 +0200, Georges Khaznadar a écrit :
> Dear maintainer(s) of octave-symbolic, here is a wild guess, inspired by
> a simple remark:
> 
> 8<
> $ python3 -c "import six; print(six.integer_types)" (,)
> $ python2 -c "import six; print(six.integer_types)" (,  'long'>)
> 8<
> 
> Would it be enough to patch octave-symbolic source, to replace
> 'sympy.core.compatibility.integer_types' by 'six.integer_types' ?

Thanks for this suggestion. This seems to fix this issue (a similar fix
is needed for string_types).

Then there are five test failures (over more than 2,000 tests) that I
don’t know how to fix. I’ve temporarily disabled those test to
facilitate the migration. Hopefully upstream will soon provide a real
fix.

Best,

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



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

Bug#963130: [Pkg-xmpp-devel] Bug#963130: /show command could wait for enter before sending

[Martin]

On 2020-06-19 20:12, Enrico Zini wrote:
> Ah, thanks, that's very nice to hear! <3

Btw. gajim from experimental is mostly a pleasant experience, IMHO.
My personal favourite is greatly improved multi-account handling.

Bug#932296: qa.debian.org: getwatch filling up /tmp

[Lucas Nussbaum]

On 17/06/20 at 12:09 +0200, Julien Cristau wrote:
> On Wed, Jun 17, 2020 at 07:00:43 +0100, Adam D. Barratt wrote:
> 
> > On Wed, 2020-06-17 at 00:14 +0200, Lucas Nussbaum wrote:
> > > Apparently the condition where this happens is quite rare
> > > occurences on 08/2019, 12/2019, 06/2020), so notifying me after the
> > > files were cleaned up from /tmp makes it hard to identify which
> > > packages cause this issue. If I could get notified when a warning
> > > limit is reached, it would be much easier to debug.
> > 
> > I'm not sure what the usual policy on that is, but I didn't clean up
> > /tmp after disabling the importer last night:

I could not reproduce this exact issue, but ran into something similar.
It boils down to:

To get the watch file, UDD extracts the source package (once per source
package per version; then the watch file is stored in DB). /tmp on
ullmann only has 5.3GB available, which is too small to extract some
source packages in Debian (such as nvidia-cuda-toolkit).

I've just added a more generic exception handling, so now UDD should
clean up /tmp from those extracted packages in all cases (which wasn't
the case before, even if I don't understand exactly why it wasn't).

However, until the disk space available for /tmp is increased, this
importer would continue to fill up / on a regular basis, which will
likely break other stuff.

So, please increase the disk space available in /tmp (or provide
a dedicated temporary space, for example under /srv/udd.debian.org/).

In the meantime, I've disabled the importer in rudd.conf.

Thanks

Lucas

Bug#963168: RM: desktopnova -- RoQA; Dead upstream, depends on Python 2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove desktopnova. It's dead upstream (last commit in 2011), 
unmaintained
(last maintainer upload in 2011), depends on outdated libs, is incompatible with
Gnome 3 (and missed Buster already) and depends on Python 2.

Cheers,
Moritz

Bug#962950: RM: boost1.67 -- ROM; forc-removal, buggy, impossible to rebuild, should not be released

[Moritz Mühlenhoff]

On Tue, Jun 16, 2020 at 03:05:19PM +0100, Dimitri John Ledkov wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> boost1.67 is buggy, it cannot be rebuild against new icu abi, as that
> would break dist-upgrades from stable->testing; it uses python2 which
> must be removed; and it cannot be used together with current icu from
> testing/unstable.
> 
> All of the reverse-dependencies are RC buggy, scheduled to be
> autoremoved and/or should be made uninstallable.
> 
> Please force-remove boost1.67 from unstable, and if any
> reverse-dependencies / reverse-build-dependencies are left, make them
> uninstallable.
> 
> Once dogecoin/leatherman/facter are removed or resolved in testing,
> boost1.67 can be removed from testing too.

JFTR, dogecoin/leatherman/facter have been fixed in the mean time.

The remaining ones seem in fact fair to ignore/force-through, several of
them are dropped from testing since 2019 and e.g. litecoin even since
2018. Or e.g. sofa-framework is already broken since the qt4 removal...

Cheers,
Moritz

Bug#924290: [rfc] information about EFI partitions

[Holger Wansing]

Control: tags -1 + pending


"McIntyre, Vincent (CASS, Marsfield)"  wrote:
> On Mon, Jun 01, 2020 at 02:34:40PM +1000, Vincent McIntyre wrote:
> >
> >Revised patch below. I'll test it on amd64 and let you know
> >if it works.
> 
> This has now been tested on a number of installs and works ok.
> I think it's good to go now.

Just applied.

Tagging this bug as pending.
Thanks


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#961681: Bug #961681: octave 5.2.0 and java child processes

[Benjamin Moody]

It seems that a possible workaround is to set the property
"jdk.lang.processReaperUseDefaultStackSize" to "true".  If that
property is "true", then the worker thread uses the "default" stack
size, whatever that is; if not, then the worker thread uses a stack
size of 128 * 1024.

https://sources.debian.org/src/openjdk-11/11.0.7+10-3/src/java.base/share/classes/java/lang/ProcessHandleImpl.java/#L81

This property can be defined either by setting the environment
variable JAVA_TOOL_OPTIONS, or by calling java.lang.System.setProperty
before starting any processes:

JAVA_TOOL_OPTIONS=-Djdk.lang.processReaperUseDefaultStackSize=true
octave -q -W -f --eval 'b = javaObject("java.lang.ProcessBuilder",
{"/bin/true"}); p = b.start(); p.waitFor()'

octave -q -W -f --eval 'javaMethod("setProperty", "java.lang.System",
"jdk.lang.processReaperUseDefaultStackSize", "true"); b =
javaObject("java.lang.ProcessBuilder", {"/bin/true"}); p = b.start();
p.waitFor()'

seems to work on buster or bullseye.

This doesn't answer the questions of:

- Why does the stack overflow when the JVM is loaded from Octave, and
  not when the JVM is launched "normally"?  (What is that worker
  thread doing that would cause it to use any appreciable amount of
  stack space?)

- Why, on bullseye, is it unable to create the worker thread in the
  first place?  (The error message suggests that pthread_create
  doesn't like the specified attributes for some reason - why is
  that?)  And again, why only in Octave?

  (I think the "OutOfMemoryError" is a red herring and that is simply
  the exception that Java always uses when pthread_create fails.)

Bug#963166: golang-golang-x-tools: DEP8 failure: excluded modules in d/rules still needed

[Andreas Hasenack]

Package: golang-golang-x-tools:
Version: 1:0.0~git20200410.79a7a31+ds-1
Severity: normal

Dear Maintainer,

I'm still troubleshooting this, but I think I have enough information
already to open a bug.

The DEP8 tests are failing at "go install" (dh_build) time with these errors:

cannot find package "golang.org/x/tools/internal/lsp/diff" in any of:
/usr/lib/go-1.14/src/golang.org/x/tools/internal/lsp/diff (from $GOROOT)

/tmp/autopkgtest.8OahHY/autopkgtest_tmp/obj-x86_64-linux-gnu/src/golang.org/x/tools/internal/lsp/diff
(from $GOPATH)

and

cannot find package "golang.org/x/tools/internal/lsp/debug/tag" in any of:
/usr/lib/go-1.14/src/golang.org/x/tools/internal/lsp/debug/tag
(from $GOROOT)

/tmp/autopkgtest.8OahHY/autopkgtest_tmp/obj-x86_64-linux-gnu/src/golang.org/x/tools/internal/lsp/debug/tag
(from $GOPATH)

This package has no dep8 test of its own, relying on "Testsuite:
autopkgtest-pkg-go" which basically runs the build again.

This upload contains a change in d/rules' DH_GOLANG_EXCLUDES:
  * Add to DH_GOLANG_EXCLUDES "internal/lsp"
which is a part of the previously excluded "gopls"

d/rules:
# Exclude "cover" since it is included in core as of Go 1.5+.
# Exclude "gopls" as it requires honnef.co/go/tools which has not
# been packaged for Debian.
export DH_GOLANG_EXCLUDES := cmd/cover gopls internal/lsp

Turns out since commit
https://github.com/golang/tools/commit/b1df9901287c3c79c3946b1899de591bbd347c20
(that's as far as I have investigated at the moment), the
go/analysis/analysistest module started importing
"golang.org/x/tools/internal/lsp/diff", but now internal/lsp is being
excluded. I think that explains the build failure in the DEP8
environment.

I'm not sure why that doesn't fail the normal build, though.

I also don't know how this package migrated in debian, since it's
failing there too for quite some time:

https://ci.debian.net/packages/g/golang-golang-x-tools/

In the previous upload,
golang-golang-x-tools-0.0~git20191118.07fc4c7+ds,
go/analysis/analysistest/analysistest.go didn't import
internal/lsp/diff.

If I remove "internal/lsp" from DH_GOLANG_EXCLUDES and rebuild, then
the build-time tests fail:
--- FAIL: TestIssue37978 (60.01s)
--- FAIL: TestIssue37978/singleton (60.01s)
panic: Shutdown: context deadline exceeded [recovered]
panic: Shutdown: context deadline exceeded

Bug#962847: not emacs related

[Rémi Letot]

Hello,

the problem is not emacs related: I just tried with swaks and it
displays the exact same problem.

Swaks session:

hobbes@sphax:~$ swaks --to r...@lybrafox.be --from hob...@poukram.net --server 
localhost
=== Trying localhost:25...
=== Connected to localhost.
<-  220 sphax.lybrafox.lan ESMTP Exim 4.94 Fri, 19 Jun 2020 21:09:05 +0200
 -> EHLO sphax.lybrafox.lan
<-  250-sphax.lybrafox.lan Hello localhost.lan [::1]
<-  250-SIZE 52428800
<-  250-8BITMIME
<-  250-PIPELINING
<-  250-X_PIPE_CONNECT
<-  250-CHUNKING
<-  250-STARTTLS
<-  250-PRDR
<-  250 HELP
 -> MAIL FROM:
<-  250 OK
 -> RCPT TO:
<-  250 Accepted
 -> DATA
<-  354 Enter message, ending with "." on a line by itself
 -> Date: Fri, 19 Jun 2020 21:09:05 +0200
 -> To: r...@lybrafox.be
 -> From: hob...@poukram.net
 -> Subject: test Fri, 19 Jun 2020 21:09:05 +0200
 -> Message-Id: <20200619210905.142...@sphax.lybrafox.lan>
 -> X-Mailer: swaks v20190914.0 jetmore.org/john/code/swaks/
 -> 
 -> This is a test mailing
 -> 
 -> 
 -> .

= 20 seconds delay is here =

<-  250 OK id=1jmMNt-000b8d-Al
 -> QUIT
<-  221 sphax.lybrafox.lan closing connection
=== Connection closed with remote host.


The problem might be related to
https://lists.exim.org/lurker/message/20200619.090409.faf4b641.en.html

But if the unique identifier in question is the message id, it
immediately appears in the log *before* the delay, so the reason is not
the id. Also, exim 4.93 does not have a problem when my laptop sleeps,
and I guess it would have the same problem if my clock moved
backwards, so while the explanation might be there somewhere, the exact
reason is different.

Also, my clock certainly does not move backwards, I would see it. But
maybe the clock in question is not what I see on my desktop ?

Thanks for your work,
-- 
Rémi 

Bug#963165: please don't install .gitkeep .git_keep and .travis.yml files

[John Scott]

Package: ansible
Version: 2.9.9+dfsg-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I was checking my system with chkrootkit and it warned me about some hidden
files for having the Ansible package installed. It looks like these are
only useful in the VCS, could they be discarded?

At least the Travis files seem like something Lintian should warn about.

/usr/lib/python3/dist-packages/notebook/bundler/tests/resources/subdir/subsubdir/.gitkeep
/usr/lib/python3/dist-packages/ansible/galaxy/data/container/templates/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/container/files/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/container/.travis.yml
/usr/lib/python3/dist-packages/ansible/galaxy/data/default/collection/roles/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/default/collection/docs/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/default/role/templates/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/default/role/files/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/default/role/.travis.yml
/usr/lib/python3/dist-packages/ansible/galaxy/data/network/templates/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/network/files/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/network/.travis.yml
/usr/lib/python3/dist-packages/ansible/galaxy/data/apb/templates/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/apb/files/.git_keep
/usr/lib/python3/dist-packages/ansible/galaxy/data/apb/.travis.yml

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

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

Versions of packages ansible depends on:
ii  openssh-client1:8.3p1-1
ii  python3   3.8.2-3
ii  python3-crypto2.6.1-13.1+b1
ii  python3-cryptography  2.8-4
ii  python3-distutils 3.8.3-2
ii  python3-dnspython 1.16.0-2
ii  python3-httplib2  0.18.1-1
ii  python3-jinja22.11.2-1
ii  python3-netaddr   0.7.19-4
ii  python3-yaml  5.3.1-2

Versions of packages ansible recommends:
ii  python3-argcomplete  1.8.1-1.3
ii  python3-jmespath 0.10.0-1
ii  python3-kerberos 1.1.14-3.1+b1
ii  python3-libcloud 2.8.0-1
ii  python3-selinux  3.0-1+b3
ii  python3-winrm0.3.0-2
ii  python3-xmltodict0.12.0-2

Versions of packages ansible suggests:
pn  cowsay   
pn  sshpass  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXu0QcAAKCRByvHFIwKst
p3opAP9sFMFEpl9runT7rRGSkol6QtrcstVTdIcTgOQHHr3yNQD9GtcZ6ztuCO8M
+Vu8hZZX2dKdzLEusiALeauYeMSD8Qs=
=Stfc
-END PGP SIGNATURE-

Bug#963081: src:camera.app: Please switch to using pkg-config for libgphoto2

[wferi]

Yavor Doganov  writes:

> wf...@niif.hu wrote:
>
>> Yavor Doganov  writes:
>> 
>>> Thanks; I'll fix this shortly -- the upload will depend on my sponsor
>>> though.  Meanwhile, feel free to upload libgphoto2 whenever you like
>>> and raise the severity of this bug to serious.
>> 
>> Did so, thanks.  I'm willing to sponsor your upload fixing this issue if
>> needed.
>
> It has a bunch of other changes so I'm not sure you'll be comfortable
> reviewing them.  And I've already contacted my sponsor...  Anyway, the
> updated package is available at mentors.d.n and also on Salsa.

Some of those changes are indeed out of my zone. :)

> P.S. I noticed that libgphoto2/2.5.25-1 FTBFS almost everywhere, you
> might want to take a look.

Yes, stupid overlook.  Thanks for the heads-up, fixed!
-- 
Feri

Bug#963147: Easy fix

[Hilko Bengen]

* Hilko Bengen:

> Good news: Upstream commit f6f5ec4cd5c3c3e38a3a1ae4e6ec249594ad159c
> which fixes the underlying issue will fit onto both version 24 and 25
> without further porting.

That should have been 02cf31c0e267a4c9a7656d43ad3ad4eeb37fc9c5.
Specifically:

  commit 02cf31c0e267a4c9a7656d43ad3ad4eeb37fc9c5
  Author: Alexander Barton 
  Date:   Mon May 25 23:43:29 2020 +0200

Sorry for any confusion.

-Hilko

Bug#963164: ITP: pyrle: Run length arithmetic in Python using Cython

[Nilesh Patra]

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


* Package name: pyrle
  Version : 0.0.31
  Upstream Author : Endre Bakken Stovner
* URL : https://github.com/pyranges/pyrle

* License : Expat
  Programming Lang: Python
  Description : Run length arithmetic in Python using Cython

 As opposed to S4Vectors, pyrle does not
 rotate the shortest vector, but rather
 extends the shorter Rle with zeroes.
 This is likely the desired behavior in
 almost all cases

I shall maintain this package.

Bug#963163: cura: please add python3-cryptography to Depends list

[Matt Zagrabelny]

Package: cura
Version: 4.5.0-1
Severity: normal

After installing cura and launching it via the command line, a python
exception is raised about the "cryptography" module and no application is
launched or running.

After installing the python3-cryptography package and running cura from the
command line the applicatino works as expected.

Thank you for supporting free software!


-- System Information:
Debian Release: bullseye/sid
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 cura depends on:
pn  cura-engine 
pn  fdm-materials   
ii  fonts-open-sans 1.11-1
ii  python3 3.8.2-1
pn  python3-charon  
ii  python3-pyqt5   5.14.1+dfsg-3
ii  python3-pyqt5.qtopengl  5.14.1+dfsg-3
ii  python3-requests2.22.0-2
pn  python3-savitar 
pn  python3-serial  
pn  python3-shapely 
pn  python3-uranium 
pn  qml-module-qt-labs-folderlistmodel  
pn  qml-module-qt-labs-settings 
pn  qml-module-qtqml-models2
ii  qml-module-qtquick-controls 5.12.5-1+b1
pn  qml-module-qtquick-controls2
ii  qml-module-qtquick-dialogs  5.12.5-1+b1
pn  uranium-plugins 

Versions of packages cura recommends:
pn  python3-zeroconf  

cura suggests no packages.

Bug#963081: src:camera.app: Please switch to using pkg-config for libgphoto2

[Yavor Doganov]

wf...@niif.hu wrote:
> Yavor Doganov  writes:
> 
> > Thanks; I'll fix this shortly -- the upload will depend on my sponsor
> > though.  Meanwhile, feel free to upload libgphoto2 whenever you like
> > and raise the severity of this bug to serious.
> 
> Did so, thanks.  I'm willing to sponsor your upload fixing this issue if
> needed.

It has a bunch of other changes so I'm not sure you'll be comfortable
reviewing them.  And I've already contacted my sponsor...  Anyway, the
updated package is available at mentors.d.n and also on Salsa.

P.S. I noticed that libgphoto2/2.5.25-1 FTBFS almost everywhere, you
might want to take a look.

Bug#959195:

[Timo Tijhof]

Tags: patch

I have submitted a patch to resolve this request to Salsa:
https://salsa.debian.org/apache-team/apache2/-/merge_requests/12

--
Timo Tijhof
Wikimedia Foundation

Bug#963161: lynis: CVE-2019-13033

[Salvatore Bonaccorso]

Source: lynis
Version: 2.7.5-1
Severity: important
Tags: security upstream
Control: found -1 2.6.2-1
Control: found -1 2.4.0-1

Hi,

The following vulnerability was published for lynis.

CVE-2019-13033[0]:
| In CISOfy Lynis 2.x through 2.7.5, the license key can be obtained by
| looking at the process list when a data upload is being performed.
| This license can be used to upload data to a central Lynis server.
| Although no data can be extracted by knowing the license key, it may
| be possible to upload the data of additional scans.


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-2019-13033
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13033
[1] https://cisofy.com/security/cve/cve-2019-13033/
[2] 
https://github.com/CISOfy/lynis/commit/3b9eda53cc20e851c4456618f027bc9ea794ad30

Please adjust the affected versions in the BTS as needed. Affected
versions should be from 2.0.0 to 2.7.5.

Regards,
Salvatore

Bug#963081: src:camera.app: Please switch to using pkg-config for libgphoto2

[wferi]

Control: severity -1 serious

Yavor Doganov  writes:

> Thanks; I'll fix this shortly -- the upload will depend on my sponsor
> though.  Meanwhile, feel free to upload libgphoto2 whenever you like
> and raise the severity of this bug to serious.

Did so, thanks.  I'm willing to sponsor your upload fixing this issue if
needed.
-- 
Regards,
Feri

Bug#963130: [Pkg-xmpp-devel] Bug#963130: /show command could wait for enter before sending

[Enrico Zini]

On Fri, Jun 19, 2020 at 07:46:45PM +0200, Martin wrote:

> > Ideally I would like to be able to disable it.
> 
> Upstream did exactly this in the 1.2 line.
> In Gajim from debian/experimental you get:
> 
> "Command disabled. This command can be enabled by setting
> 'command_system_execute' to True in ACE (Advanced Configuration Editor)."

Ah, thanks, that's very nice to hear! <3


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Bug#963160: ITP: intake -- lightweight package for finding and investigating data

[Shayan Doust]

Package: wnpp
Severity: wishlist

Subject: ITP: intake -- lightweight package for finding and investigating data
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: intake
  Version : 0.6.0
  Upstream Author : Anaconda Inc., Intake contributors
* URL : https://github.com/intake/intake
* License : BSD-2-clause
  Programming Lang: Python
  Description : lightweight package for finding and investigating data
 Intake is a leightweight set of tools for loading and sharing data in
 data science projects. Intake helps you:
 1. Load data from a variety of formats into containers you already know,
like Pandas dataframes, Python lists, NumPy arrays and more.
 2. Convert boilerplate data loading code into reusable intake plugins.
 3. Describe data sets in catalog files for easy reuse and sharing
between projects and with others.
 4. Share catalog information (and data sets) over the network with the
Intake server.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/intake

Bug#963147: Easy fix

[Hilko Bengen]

control: tag -1 patch

Good news: Upstream commit f6f5ec4cd5c3c3e38a3a1ae4e6ec249594ad159c
which fixes the underlying issue will fit onto both version 24 and 25
without further porting.

Cheers,
-Hilko

Bug#963159: mbedtls: CVE-2020-10932

[Salvatore Bonaccorso]

Source: mbedtls
Version: 2.16.5-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for mbedtls.

CVE-2020-10932[0]:
| An issue was discovered in Arm Mbed TLS before 2.16.6 and 2.7.x before
| 2.7.15. An attacker that can get precise enough side-channel
| measurements can recover the long-term ECDSA private key by (1)
| reconstructing the projective coordinate of the result of scalar
| multiplication by exploiting side channels in the conversion to affine
| coordinates; (2) using an attack described by Naccache, Smart, and
| Stern in 2003 to recover a few bits of the ephemeral scalar from those
| projective coordinates via several measurements; and (3) using a
| lattice attack to get from there to the long-term ECDSA private key
| used for the signatures. Typically an attacker would have sufficient
| access when attacking an SGX enclave and controlling the untrusted OS.


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-10932
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10932
[1] 
https://tls.mbed.org/tech-updates/releases/mbedtls-2.16.6-and-2.7.15-released
[2] 
https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-04

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#963158: re2c: CVE-2020-11958

[Salvatore Bonaccorso]

Source: re2c
Version: 1.3-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for re2c.

CVE-2020-11958[0]:
| re2c 1.3 has a heap-based buffer overflow in Scanner::fill in
| parse/scanner.cc via a long lexeme.


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-11958
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11958
[1] 
https://github.com/skvadrik/re2c/commit/c4603ba5ce229db83a2a4fb93e6d4b4e3ec3776a

Regards,
Salvatore

Bug#963157: enable listing source instead of binary packages

[John Scott]

Package: debsecan
Version: 0.4.20.1
Severity: wishlist

Hi,

Binary packages are used because they're likely to be more familiar.
I'm comfortable about thinking of things in terms of source packages
and would appreciate an option to force this anyway, even if it were
to not show installed binary packages at all.

apt-listchanges seems to have a nice way of writing it out if you have
it set to show changelogs by default. I have nothing to copy from with
no updates for me to install right now, but it writes the installed
binaries in parenthesis next to the source package name like

qemu (qemu-system-x86:amd64 qemu-user-static:amd64 ...)

So if it were to list the binary ones, I hope that gives an idea of a
consistent way to do it.

Thanks for maintaining debsecan!

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

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

Versions of packages debsecan depends on:
ii  ca-certificates20200601
ii  debconf [debconf-2.0]  1.5.74
ii  python33.8.2-3
ii  python3-apt2.1.3

Versions of packages debsecan recommends:
ii  cron [cron-daemon]3.0pl1-136
ii  msmtp-mta [mail-transport-agent]  1.8.8-1

debsecan suggests no packages.

-- debconf information excluded

Bug#962773: libpcre2-dev: Linuxinfo fails to link: ./linuxinfo_common.c:224: undefined reference to `pcre2_compile_8'

[Helge Kreutzmann]

Hello Matthew,
On Fri, Jun 19, 2020 at 05:08:56PM +0100, Matthew Vernon wrote:
> [can you reproduce with a little test program? but I think this is a build
> issue not a pcre2 one at the moment]

The minimal program attached exhibits this behaviour as well.

In stable:
helge@samd:/tmp$ gcc -Duse_regexp=1 -g -O2 -c -o minimal.o minimal.c
helge@samd:/tmp$ gcc -g -O2 -lpcre2-8 -Wl,-z,relro -o minimal minimal.o
helge@samd:/tmp$ echo $?
0

In Sid chroot:
root@samd:/tmp/linuxinfo-3.2.0# gcc -Duse_regexp=1 -g -O2 -c -o minimal.o 
minimal.c
root@samd:/tmp/linuxinfo-3.2.0# gcc -g -O2 -lpcre2-8 -Wl,-z,relro -o minimal 
minimal.o
/usr/bin/ld: minimal.o: in function `regstrcmp':
/tmp/linuxinfo-3.2.0/minimal.c:50: undefined reference to `pcre2_compile_8'
/usr/bin/ld: /tmp/linuxinfo-3.2.0/minimal.c:78: undefined reference to 
`pcre2_match_data_create_from_pattern_8'
/usr/bin/ld: /tmp/linuxinfo-3.2.0/minimal.c:80: undefined reference to 
`pcre2_match_8'
/usr/bin/ld: /tmp/linuxinfo-3.2.0/minimal.c:107: undefined reference to 
`pcre2_match_data_free_8'
/usr/bin/ld: /tmp/linuxinfo-3.2.0/minimal.c:108: undefined reference to 
`pcre2_code_free_8'
/usr/bin/ld: /tmp/linuxinfo-3.2.0/minimal.c:102: undefined reference to 
`pcre2_match_data_free_8'
/usr/bin/ld: /tmp/linuxinfo-3.2.0/minimal.c:103: undefined reference to 
`pcre2_code_free_8'
/usr/bin/ld: /tmp/linuxinfo-3.2.0/minimal.c:63: undefined reference to 
`pcre2_get_error_message_8'
collect2: error: ld returned 1 exit status
root@samd:/tmp/linuxinfo-3.2.0# echo $?
1

I'm not sure what else I could try. Thanks for any pointers.

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#define _(String) gettext (String)

#define PCRE2_CODE_UNIT_WIDTH 8
#include 

static char *models[] =
{
"K6 \\(166 - 266\\)", "K6",
"AMD-K6tm w/ mul", "K6 (MMX)",
"K6-2 \\(PR233 - PR333\\)", "K6-2"
 };


int regstrcmp(const char *subjstring, const char *pstring)
{
pcre2_code *re;
PCRE2_SPTR pattern; /* PCRE2_SPTR is a pointer to unsigned code units of */
PCRE2_SPTR subject; /* the appropriate width (in this case, 8 bits). */

int errornumber;
int rc;

PCRE2_SIZE erroroffset;

size_t subject_length;
pcre2_match_data *match_data;

/* As pattern and subject are char arguments, they can be straightforwardly
cast to PCRE2_SPTR as we are working in 8-bit code units. */

pattern = (PCRE2_SPTR)pstring;
subject = (PCRE2_SPTR)subjstring;
subject_length = strlen((char *)subject);

/*
* Now we are going to compile the regular expression pattern, and handle *
* any errors that are detected.  *
*/

re = pcre2_compile(
  pattern,   /* the pattern */
  PCRE2_ZERO_TERMINATED, /* indicates pattern is zero-terminated */
  0, /* default options */
  ,  /* for error number */
  ,  /* for error offset */
  NULL); /* use default compile context */

/* Compilation failed: print the error message and exit. */ /* This should not happen */

if (re == NULL)
{
   PCRE2_UCHAR buffer[256];
   pcre2_get_error_message(errornumber, buffer, sizeof(buffer));
   printf(_("PCRE2 compilation failed at offset %d: %s\n"), (int)erroroffset,buffer);
   return 1;
}

/*
* If the compilation succeeded, we call PCRE again, in order to do a *
* pattern match against the subject string. This does just ONE match.#
* Before running the match we must set up a match_data block for holding *
* the result.#
*/

/* Using this function ensures that the block is exactly the right size for
the number of capturing parentheses in the pattern. */

match_data = pcre2_match_data_create_from_pattern(re, NULL);

rc = pcre2_match(
  re,   /* the compiled pattern */
  subject,  /* the subject string */
  subject_length,   /* the length of the subject */
  0,/* start at offset 0 in the subject */
  0,/* default options */
  match_data,   /* block for storing the result */
  NULL);/* use default match context */

/* Matching failed: handle error cases */

if (rc < 0)
{
   switch(rc)
   {

Bug#963156: /cdrom should be remounted rw before partman executes, when mapped to an ESP

[Pete Batard]

Package: partman-auto
Severity: important
Tags: d-i

(NB: Resubmitting this bug, which was already submitted as 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963150, against 
partman-auto since "partman" does not appear to exist as a valid Debian 
package)



THE GOAL


When installing Debian from the official netinst ISO in UEFI mode it may 
be very convenient to do so by:
- Creating a large enough ESP (GPT or MBR) on the target installation 
disk (e.g. 350 MB)
- Extracting the ISO content to said ESP and let the UEFI system proceed 
from there.


Doing so alleviates the need to use two media to complete a Debian 
installation, where one can do, and, with disk capacity being plentiful 
nowadays, wasting a couple hundred MB can be seen as a good tradeof if 
it leads to a much easier GNU/Linux installation, especially on SoC 
systems where devices and ports may be limited.


For instance using a USB single media, with an ESP onto which the Debian 
11 netinst ISO has been extracted, is the method we are going to 
recommend to proceed with a Debian installation on the Raspberry Pi 4, 
since there now exists a UEFI firmware for that platform and Linux 
kernel 5.x has added the networking support required for netinst (which 
has already been backported to the Debian 11 5.x kernel).



THE PROBLEM
===

One major roadblock with doing the above however is that, whereas 
partman correctly detects the ESP and attempts to use for its intended 
purpose (meaning that, after the Debian Installer has completed, EFI 
GRUB will be updated to replace the netinst bootloader, therefore 
handling boot for the final system), it ultimately fails to mount the 
ESP to /boot/efi because:


1. When booting from USB/HDD, the Debian installer has already mounted 
the ESP to /cdrom as *read-only*.


2. The Linux kernel prevents a block device from being mounted more than 
once *when the read/write permissions are going to be different*


This means that, if you have an ESP with the netinst ISO content in 
/dev/sda1, you will see it mounted as follows before partman launches:


] /dev/sda1 on /cdrom type vfat (ro,...)

But after you partition the system (whilst telling it to keep the 
existing ESP) partman will report the following error:


] The attempt to mount a file system with type vfat in SCSI1 (0,0,0),
] partition #1 (sda) at /boot/efi failed.

This effectively breaks the installation process and prevents users from 
reusing the ESP.


On the other hand, if you issue the command:

] mount -o remount,rw /dev/sda1 /cdrom

prior to executing partman, then everything works as expected.

Again, this is because /cdrom is then mounted read/write, which allows 
/boot/efi (which points to the same underlying block device) to also be 
mounted read/write, as required by partman for mounting ESPs as well as 
for the rest of the installation process.


In other words, the main issue is that, if an ESP is also used as the 
/cdrom device, then we *must* ensure that it is mounted rw by the time 
partman is invoked.


At this stage, I must stress how critical this issue is when it comes to 
ensuring that the installation of vanilla Debian on Raspberry Pi 4 can 
happen with the *exact same ease* as it does on a PC.


If we can fix this problem, then new Debian, wanting to use on a a Pi 4, 
 can simply create a USB drive with a small ESP, using the official 
netinst ISO (as well as the the Raspberry Pi UEFI firmware) and by 
simply plugging that drive on the device, they will proceed through an 
installation of Debian that's about as painless as the installation of 
Raspbian, even as the latter is specifically dedicated for that 
hardware. As such, it is highly desirable that this issue gets fixed for 
the 11.0 release.



THE POSSIBLE SOLUTIONS
==

I am currently seeing 3 possibilities to address the issue above.

* OPTION #0: Ask users to switch to a shell when partman starts and 
issue a 'mount -o remount,rw' command. Dismissed as option 0, since the 
whole point behind opening this bug report is that asking users to 
toggle to a shell during install and enter a command that they might not 
be familiar with is a less than ideal solution, and one we should really 
strive to avoid.


* OPTION #1: Alter the cdrom mount script 
(var/lib/dpkg/info/cdrom-detect.postinst which comes from 
https://packages.debian.org/bullseye/cdrom-detect) so that it tries to 
mount /cdrom rw by default. This basically means editing the "linux)" 
case from the script to change:

 OPTIONS=ro,exec
to
 OPTIONS=rw,exec

I have tested this to produce the expected result. However, this will 
lead to an attempt to mount all optical media rw, which makes little 
sense. So a slightly better option could be to alter the try_mount() 
function of the script to take a third parameter that specifies the type 
of read/write options that should be used, or break the OPTIONS into 
OPTIONS_CDROM OPTIONS_FAT, and only have rw for the 

Bug#963130: [Pkg-xmpp-devel] Bug#963130: /show command could wait for enter before sending

[Martin]

On 2020-06-19 14:01, Enrico Zini wrote:
> I just learnt of the /show command, which runs a shell command and posts
> its output. It works exactly as intended. What could possibly go wrong?

Ouch, I did not know about that command.
Not a good idea at all.

> Ideally I would like to be able to disable it.

Upstream did exactly this in the 1.2 line.
In Gajim from debian/experimental you get:

"Command disabled. This command can be enabled by setting
'command_system_execute' to True in ACE (Advanced Configuration Editor)."

Bug#963155: libsquashfs1 - Wrong Section: kernel

[Bastian Blank]

Package: src:squashfs-tools-ng
Version: 1.0.0-1
Severity: normal

The source defines libsquashfs1 (I haven't checked older versions) with
section kernel instead of the correct one libs.  This can produce
headaches, as release team tooling and others assign special behaviour
to packages with libs as section.

Also libsquashfs-dev should be libdevel.

Bastian

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

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

Bug#963154: nmapsi4: Must not be arch:any

[Joao Eriberto Mota Filho]

Package: nmapsi4
Version: 0.5~alpha2-1
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

nmapsi4 fails to build from source in several architectures since 0.5~alpha2-1
revision.

nmapsi4 build depends of qtwebengine5-dev. Since 5.9.1+dfsg-5 revision, released
in 30 Sep 2017, qtwebengine5-dev is only available for amd64, arm64, armhf, i386
and mipsel. Consequently, now nmapsi4 FTBFS in armel, mips64el, ppc64el, s390x,
alpha, hppa, hurd-i386, ia64, m68k, powerpc, ppc64, riscv64, sh4, sparc64 and
x32.

The following patch fixes the FTBFS in nmapsi4:

diff -Nru nmapsi4-0.5~alpha2/debian/control nmapsi4-0.5~alpha2/debian/control
--- nmapsi4-0.5~alpha2/debian/control   2020-05-22 12:50:04.0 -0300
+++ nmapsi4-0.5~alpha2/debian/control   2020-06-19 14:33:47.0 -0300
@@ -11,7 +11,7 @@
 Rules-Requires-Root: no
 
 Package: nmapsi4
-Architecture: any
+Architecture: amd64 arm64 armhf i386 mipsel
 Depends: ${shlibs:Depends}, ${misc:Depends}, nmap, bind9-dnsutils
 Description: graphical interface to nmap, the network scanner
  NmapSI4 is a complete Qt-based Gui with the design goal to provide a complete

Regards,

Eriberto

Bug#963153: ffmpeg breaks r-cran-av autopkgtest: error in 'avcodec_open2 (audio)': Invalid argument

[Paul Gevers]

Source: ffmpeg, r-cran-av
Control: found -1 ffmpeg/7:4.3-2
Control: found -1 r-cran-av/0.5.0+dfsg-3
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of ffmpeg the autopkgtest of r-cran-av fails in
testing when that autopkgtest is run with the binary packages of ffmpeg
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
ffmpeg from testing7:4.3-2
r-cran-av  from testing0.5.0+dfsg-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of ffmpeg to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=ffmpeg

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-av/5951260/log.gz

autopkgtest [13:08:56]: test run-unit-test: [---
BEGIN TEST testthat.R

R version 4.0.1 (2020-06-06) -- "See Things Now"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(testthat)
> library(av)
>
> if (ps::ps_is_supported()) {
+   reporter <-
ps::CleanupReporter(testthat::CheckReporter)$new(proc_cleanup =  FALSE,
proc_fail = FALSE)
+   test_check("av", reporter = reporter)
+ } else {
+   test_check("av")
+ }
Estimating duration from bitrate, this may be inaccurate
Specified sample rate 8000 is not supported
── 1. Error: Audio FFT (@test-fft.R#10)
───
FFMPEG error in 'avcodec_open2 (audio)': Invalid argument
Backtrace:
 1. av::av_audio_convert(wonderland, filename, verbose = FALSE)

Estimating duration from bitrate, this may be inaccurate
══ testthat results
═══
[ OK: 130 | SKIPPED: 0 | WARNINGS: 0 | FAILED: 1 ]
1. Error: Audio FFT (@test-fft.R#10)

Error: testthat unit tests failed
Execution halted
autopkgtest [13:09:08]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#963152: nss: CVE-2020-12402

[Salvatore Bonaccorso]

Source: nss
Version: 2:3.53-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for nss, fixed in 3.53.1.

CVE-2020-12402[0]:
| Side channel vulnerabilities during RSA key generation

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-12402
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12402

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#963151: suboptimal libzstd usage due to different build/runtime versions

[John Scott]

Package: tor
Version: 0.4.3.5-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I was checking on Tor like this and it prints a warning:
$ tor --verify-config --hush
Jun 19 13:29:14.005 [warn] Tor was compiled with zstd 1.4.4, but is running
with zstd 1.4.5. For safety, we'll avoid using advanced zstd functionality.

This probably doesn't matter much in practice, but seems quite strange. Is
this a precaution that should be overridden in Debian since the package
management takes care of that with Conflicts/Breaks? See the changelog
excerpts showing the care taken already:

 libzstd (1.4.5+dfsg-2) unstable; urgency=medium
 * Drop ZSTD_LEGACY_MULTITHREADED_API, since nothing in Debian seem to use it

 libzstd (1.4.5+dfsg-1) unstable; urgency=medium
 * New upstream version 1.4.5+dfsg
 * Update symbols file, add ZDICT_getDictHeaderSize and remove all
 ZSTDMT_* symbols, also remove renamed ZSTD_CCtxParam_getParameter and
 ZSTD_CCtxParam_setParameter, no reverse dependencies use any of the
 removed symbols
 * Remove 0018-Alias-renamed-API-symbols.patch since no rdeps use the old
 symbols
 * d/rules: call dh_makeshlibs with -V 'libzstd1 (>= 1.4.5)', since this
 version introduces new public symbols
 -- Alexandre Mestiashvili   Fri, 05 Jun 2020 10:47:12 +0200

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

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

Versions of packages tor depends on:
ii  adduser 3.118
ii  libc6   2.30-8
ii  libcap2 1:2.34-2
ii  libevent-2.1-7  2.1.11-stable-1
ii  liblzma55.2.4-1+b1
ii  libseccomp2 2.4.3-1+b1
ii  libssl1.1   1.1.1g-1
ii  libsystemd0 245.6-1
ii  libzstd11.4.5+dfsg-2
ii  lsb-base11.1.0
ii  runit-helper2.8.15
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages tor recommends:
ii  logrotate3.16.0-3
ii  tor-geoipdb  0.4.3.5-1
ii  torsocks 2.3.0-2+b1

Versions of packages tor suggests:
ii  apparmor-utils   2.13.4-2
pn  mixmaster
pn  obfs4proxy   
ii  socat1.7.3.4-1
pn  tor-arm  
pn  torbrowser-launcher  

- -- Configuration Files:
/etc/tor/torrc changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXuz30wAKCRByvHFIwKst
p/94AP9l/7F+4Gwxh1GcovbqlbiaYf0EcVM2x//w9D9hhhtNGQEApHMcfb8848Dj
jhIP3ZY8OPwDr+VPbB06K0BFSw3+owg=
=Ld86
-END PGP SIGNATURE-

Bug#963150: /cdrom should be remounted rw before partman executes, when mapped to an ESP

[Pete Batard]

Package: partman
Severity: important
Tags: d-i


THE GOAL


When installing Debian from the official netinst ISO in UEFI mode it may 
be very convenient to do so by:
- Creating a large enough ESP (GPT or MBR) on the target installation 
disk (e.g. 350 MB)
- Extracting the ISO content to said ESP and let the UEFI system proceed 
from there.


Doing so alleviates the need to use two media to complete a Debian 
installation, where one can do, and, with disk capacity being plentiful 
nowadays, wasting a couple hundred MB can be seen as a good tradeof if 
it leads to a much easier GNU/Linux installation, especially on SoC 
systems where devices and ports may be limited.


For instance using a USB single media, with an ESP onto which the Debian 
11 netinst ISO has been extracted, is the method we are going to 
recommend to proceed with a Debian installation on the Raspberry Pi 4, 
since there now exists a UEFI firmware for that platform and Linux 
kernel 5.x has added the networking support required for netinst (which 
has already been backported to the Debian 11 5.x kernel).



THE PROBLEM
===

One major roadblock with doing the above however is that, whereas 
partman correctly detects the ESP and attempts to use for its intended 
purpose (meaning that, after the Debian Installer has completed, EFI 
GRUB will be updated to replace the netinst bootloader, therefore 
handling boot for the final system), it ultimately fails to mount the 
ESP to /boot/efi because:


1. When booting from USB/HDD, the Debian installer has already mounted 
the ESP to /cdrom as *read-only*.


2. The Linux kernel prevents a block device from being mounted more than 
once *when the read/write permissions are going to be different*


This means that, if you have an ESP with the netinst ISO content in 
/dev/sda1, you will see it mounted as follows before partman launches:


] /dev/sda1 on /cdrom type vfat (ro,...)

But after you partition the system (whilst telling it to keep the 
existing ESP) partman will report the following error:


] The attempt to mount a file system with type vfat in SCSI1 (0,0,0),
] partition #1 (sda) at /boot/efi failed.

This effectively breaks the installation process and prevents users from 
reusing the ESP.


On the other hand, if you issue the command:

] mount -o remount,rw /dev/sda1 /cdrom

prior to executing partman, then everything works as expected.

Again, this is because /cdrom is then mounted read/write, which allows 
/boot/efi (which points to the same underlying block device) to also be 
mounted read/write, as required by partman for mounting ESPs as well as 
for the rest of the installation process.


In other words, the main issue is that, if an ESP is also used as the 
/cdrom device, then we *must* ensure that it is mounted rw by the time 
partman is invoked.


At this stage, I must stress how critical this issue is when it comes to 
ensuring that the installation of vanilla Debian on Raspberry Pi 4 can 
happen with the *exact same ease* as it does on a PC.


If we can fix this problem, then new Debian, wanting to use on a a Pi 4, 
 can simply create a USB drive with a small ESP, using the official 
netinst ISO (as well as the the Raspberry Pi UEFI firmware) and by 
simply plugging that drive on the device, they will proceed through an 
installation of Debian that's about as painless as the installation of 
Raspbian, even as the latter is specifically dedicated for that 
hardware. As such, it is highly desirable that this issue gets fixed for 
the 11.0 release.



THE POSSIBLE SOLUTIONS
==

I am currently seeing 3 possibilities to address the issue above.

* OPTION #0: Ask users to switch to a shell when partman starts and 
issue a 'mount -o remount,rw' command. Dismissed as option 0, since the 
whole point behind opening this bug report is that asking users to 
toggle to a shell during install and enter a command that they might not 
be familiar with is a less than ideal solution, and one we should really 
strive to avoid.


* OPTION #1: Alter the cdrom mount script 
(var/lib/dpkg/info/cdrom-detect.postinst which comes from 
https://packages.debian.org/bullseye/cdrom-detect) so that it tries to 
mount /cdrom rw by default. This basically means editing the "linux)" 
case from the script to change:

 OPTIONS=ro,exec
to
 OPTIONS=rw,exec

I have tested this to produce the expected result. However, this will 
lead to an attempt to mount all optical media rw, which makes little 
sense. So a slightly better option could be to alter the try_mount() 
function of the script to take a third parameter that specifies the type 
of read/write options that should be used, or break the OPTIONS into 
OPTIONS_CDROM OPTIONS_FAT, and only have rw for the latter. It needs to 
be pointed out that formally requesting rw on a read-only media does not 
seem to be an major issue, as linux will fall back to mounting the media 
read-only if it can't mount it read+write.


By 

Bug#963112: Request for advice on katex rejected by ftp masters

[Gunnar Wolf]

Pirate Praveen dijo [Fri, Jun 19, 2020 at 12:47:51PM +0530]:
> The general case was discussed earlier and a recommendation was given at 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54
> 
> I'd like a confirmation from you if katex was following your
> recommendations or not. I think katex should be a separate binary
> package because it is shipping a user facing executable. But ftp
> masters don't agree with my interpretation.
> 
> Their rejection mail and explanation is given below.

Hello Praveen,

You raised this same question to me via private mail; I prefer to
answer copying the rest of the Committee, and in a public way.

I completely lack context regarding KaTeX (tried downloading its
sources, but I am a complete JS newbie and didn't get a hold on it
anywhere; don't know what components of it are packaged or not, nor
how is your proposed katex package structured, etc.), hence, there is
no way for me to express an opinion here. I do feel there is too much
soreness still expressed between you and the ftp-masters.

So, refering to the same mail you quote, the guidelines Simon
carefully worked out begin with:

1. When there is disagreement about the level of splitting necessary
   between binary and source packages, we encourage maintainers and
   the ftp team to communicate respectfully, and in particular
   acknowledge that each other's goals are valid, even if arguing that
   those goals should be outweighed by higher-priority goals.

   We also encourage maintainers to be as clear as possible about the
   purpose and relationship of the various parts of a source package.

This is, yes, hard to achieve - but we should strive to communicate
better before getting angry and calling in the cavalry.

Simon continued with some design principles, that I understand often
impact node.js work: "We should not have very large numbers of very
small binary packages" and We should not have very large numbers of
very small source packages". Is this the case you are arguing for?

I don't want to rehash the whole set of guidelines; I want to
understand the disagreement you are presenting.

And finally, as David already argued - We cannot overrule delegates'
decisions. The final call on whether to accept a package is
ftp-masters'. Can we ask them to better state their reasons? Probably
yes, but that's -I think- about the limit of our action scope.


signature.asc
Description: PGP signature

Bug#963039: [Pkg-javascript-devel] Bug#963039: node-iconv: versions of nodejs dependencies not properly documented

[Paul Gevers]

Hi Jérémy and Xavier,

On 19/06/2020 13.33, Jérémy Lal wrote:
> libnode68 and libnode72 can be co-installed.

Sure.

> /usr/bin/node is going to load the lib with the SONAME it's been built for.

Of course, like any normal binary that is linked against a library in
Debian.

> So of course nodejs 12.x loads libnode72 and nodejs 10.x loads libnode68.
> Otherwise the SONAME bump wouldn't be major.
> 
> Paul: you're right to point out that it is perfectly possible for
> another application
> to link against libnode72 without needing to install nodejs 12.
> 
> Xavier: i didn't think about that beforehand, but the approach you suggest
> will break things (maybe other packages using libv8-dev, for example).
> 
> I'm not sure why node-iconv depends on nodejs.

As my other bug, node-expat seems to have the same issue.

> Its autopkgtests should however depend on nodejs >= 
> where  is the one built against the same libnode SONAME as
> node-iconv (?)

That doesn't scale, because it's every package that has an autopkgtest
that depends on node-iconv that has this issue. So it's node-iconv that
needs to declare the right versioned relation to nodejs. It looks like
the binary executable already knows it, but the Debian package doesn't
know it yet. The internal knowledge needs to be exposed somehow.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

[Rene Engelhard]

Hi,

Am 19.06.20 um 19:19 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 7:12 PM, Rene Engelhard wrote:
>> Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
>> m68k even didn't yet do a ICU rebuild or at least make stuff being
>> rebuildable.
>>
>>> Would it be okay if I send a pull request to make the necessary changes?
>>
>> I am perfectly able to implement what you want. But whatever.
>>
>> You can send any pull request.
>>
>> That doesn't mean I'll merge it.
> 
> I'll ask the CTTE then.

lol.

> No idea why you have to turn such a simple request into
> such a drama.

*You* turn it in a drama.

I asked for a very simple and modest change and your only answer
> is to turn this into such a long pointless discussion basically telling me I
> shouldn't be doing what I'm doing.

*You* started the debate. I (implicitely, even before, by the comment in
rules and in a message explicity) said I will stay with upstream here,
you continued and trolled about debian/patches when I did so.

Some times you just need to accept maintainers' decisions and not waste
their times with this (indeed) useless discussion.

Regards,

Rene

Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

[John Paul Adrian Glaubitz]

On 6/19/20 7:12 PM, Rene Engelhard wrote:
> Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
> m68k even didn't yet do a ICU rebuild or at least make stuff being
> rebuildable.
> 
>> Would it be okay if I send a pull request to make the necessary changes?
> 
> I am perfectly able to implement what you want. But whatever.
> 
> You can send any pull request.
> 
> That doesn't mean I'll merge it.

I'll ask the CTTE then. No idea why you have to turn such a simple request into
such a drama. I asked for a very simple and modest change and your only answer
is to turn this into such a long pointless discussion basically telling me I
shouldn't be doing what I'm doing.

Thanks,
Adrian

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

Bug#963149: node-elliptic: CVE-2020-13822

[Salvatore Bonaccorso]

Source: node-elliptic
Version: 6.5.1~dfsg-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/indutny/elliptic/issues/226

Hi,

The following vulnerability was published for node-elliptic.

CVE-2020-13822[0]:
| The Elliptic package 6.5.2 for Node.js allows ECDSA signature
| malleability via variations in encoding, leading '\0' bytes, or
| integer overflows. This could conceivably have a security-relevant
| impact if an application relied on a single canonical signature.


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-13822
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13822
[1] https://github.com/indutny/elliptic/issues/226

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

[Rene Engelhard]

Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz 
>> :
>>> So nothing that keeps us from using GCC in cases where clang is not
>>> available.
>>
>> Correct. Except staying as close as possible with upstream.
> 
> While at the same time, the source contains 20+ patches:
> 
>> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/tree/debian-experimental-7.0/patches
> 
> I wouldn't consider that "close to upstream".

*Shrugs*

That shows you haven't even cared to actually have looked at the patch
names but just counting. That is not sensible and just a pure trolling
attempt.

Some patches are needed for proper packaging.

Some patches are requires by policy.

Some patches fix bugs.

Some patches fix FTBFSes.

Some patches are simply minor.

Where a difference to upstream is not actually needed, why do one?

 and disabled on any other architecture. It's not really rocket scien
>>
>> Trust me, I know. I do this for all kind of stuff in rules (e.g. for skia 
>> itself, see below)
> 
> This isn't a technical argument though.

*You* said it's not rocket science and implied I wouldn't be able to do so.

>>> It's also not a given that clang generates faster code on _any_ given
>>> architecture,
>>> it might be true for x86_64, but not necessarily for armhf or s390x.
>>
>> s390x doesn't matter here at all as it is be and skia doesn't support be at 
>> all. Thus we get --disable-skia and thus no clang usage.
>>
>> But generally you're right, but I am trying to stay as close upstream as 
>> possible here.
> 
> Again, this isn't a compelling technical argument. There is no additional 
> workload
> involved if you allow building LO with GCC on non-clang architectures and it 
> also
> does not cause harm any of the release architectures. You are not required to 
> fix
> any code that doesn't build on a non-release architecture, that's what we 
> porters
> are for.
[...]
> I have honestly no clue why you would deny porters to build
LibreOffice on non-release
> architectures given these circumstances.

It is. That line needs to be maintained.

Ah, right, so you fix the stuff?

- alpha broken for ages
- hppa broken for ages
- sparc64 BD-Unistallable for ages due to KDE
- kfreebsd-* BD-Uninstallable for ages

See

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

(sid).

Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
m68k even didn't yet do a ICU rebuild or at least make stuff being
rebuildable.

You mean on alpha where you even were not able to keep it building for a
long time? Don't blame your non-action here.

Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
m68k even didn't yet do a ICU rebuild or at least make stuff being
rebuildable.

> Would it be okay if I send a pull request to make the necessary changes?

I am perfectly able to implement what you want. But whatever.

You can send any pull request.

That doesn't mean I'll merge it.

Regards,

Rene

Bug#963148: binutils-avr: avr-ld is broken on aarch64

[Lukas F. Hartmann]

Package: binutils-avr
Version: 2.26.20160125+Atmel3.6.2-1
Severity: important

Dear Maintainer,

If I enter the following:

avr-ld

I get: 

Illegal instruction

So I can't link avr programs on my aarch64 platform with Debian. If I build 
binutils-avr myself from the original sources, it works.

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

Kernel: Linux 5.7.0-rc6+ (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages binutils-avr depends on:
ii  libc6   2.30-8
ii  zlib1g  1:1.2.11.dfsg-2

binutils-avr recommends no packages.

Versions of packages binutils-avr suggests:
ii  binutils  2.34-8

Bug#963147: ngircd: CVE-2020-14148

[Salvatore Bonaccorso]

Source: ngircd
Version: 25-3
Severity: important
Tags: security upstream
Control: found -1 25-2

Hi,

The following vulnerability was published for ngircd.

CVE-2020-14148[0]:
| The Server-Server protocol implementation in ngIRCd before 26~rc2
| allows an out-of-bounds access, as demonstrated by the IRC_NJOIN()
| function.


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-14148
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14148
[1] https://github.com/ngircd/ngircd/issues/274
[2] https://github.com/ngircd/ngircd/issues/277
[3] https://github.com/ngircd/ngircd/pull/275
[4] https://github.com/ngircd/ngircd/pull/276

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#962934: inkscape package contains a Debug build

[besy]

I wouldn't have expected active debugging asserts (i.e. a build without
NDEBUG) in a release package. That's the reason why I created this
general bug report.

I'm affected by this crash: https://gitlab.com/inkscape/inbox/-/issues/2418

I also had further crashes but I don't know if asserts caused them and I
don't know if the program would have run correctly without the asserts.
Unfortunately, I can't reproduce these crashes reliably.

Bug#963098: dwarfdump: dump .eh_frame fails on x86-64 elf

[Fabian Wolff]

Control: tags -1 + patch pending upstream confirmed fixed-upstream

On 6/19/20 6:51 PM, David Anderson wrote:
> I too reproduce the error.
> 
> The relocation used was -not- one I was aware of.
> This diff fixes the problem.  it should be on sourceforge
> in a day or two.  I hope to create a new full release
> this month --- there is significant new DWARF5 support
> in the next libdwarf/dwarfdump release.

Sweet. Thanks!

In that case, I think I'll just wait for the next release (no hurry,
though, David!) to close this bug.

Best regards,
Fabian

Bug#922579: FTBFS against opencv 4.0.1 (exp)

[Giovanni Mascellani]

Control: block 962950 by -1

On Tue, 23 Apr 2019 14:13:22 + (GMT) Chiara Marmo
 wrote:
> Hi,
> 
> sorry, I'm a bit confused about this bug.
> 
> This is a problem with opencv4 in experimental distribution, right?
> Not with power pc architecture...

No, the same thing definitely happens on amd64 as well. I tried adding a
"-I/usr/include/opencv4" to the compiler command line to see if the same
code worked with OpenCV 4, but apparently it does not. It is probably
necessary to manually port the code to the new version.

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



signature.asc
Description: OpenPGP digital signature

Bug#963098: dwarfdump: dump .eh_frame fails on x86-64 elf

[David Anderson]

On 6/18/20 3:32 PM, Fabian Wolff wrote:

Hi Nick,

thanks for reporting this; indeed, I could reproduce the error, and 
llvm-dwarfdump
doesn't produce a similar error (unsurprisingly, if the file was generated with
LLVM in the first place).

I'm hereby forwarding your report to libdwarf's upstream developer - David, 
could
you have a look at this?

Thanks!

On 6/18/20 11:44 PM, Nick Lewycky wrote:

Package: dwarfdump
Version: 20200114-1
Severity: normal

Dear Maintainer,

I have an ordinary x86-64 ELF .o file (attached) which was produced by LLVM,
but dwarfdump issues an error when asked to dump the .eh_frame:

$ dwarfdump -F function_0.o

.eh_frame

dwarfdump ERROR:  dwarf_get_fde_list: 
DW_DLE_RELOC_SECTION_RELOC_TARGET_SIZE_UNKNOWN (233) so doing a relocation is 
unsafe

-



I too reproduce the error.

The relocation used was -not- one I was aware of.
This diff fixes the problem.  it should be on sourceforge
in a day or two.  I hope to create a new full release
this month --- there is significant new DWARF5 support
in the next libdwarf/dwarfdump release.

diff --git a/libdwarf/dwarf_elf_rel_detector.c
b/libdwarf/dwarf_elf_rel_detector.c
index 747bc93..5d46d57 100644
--- a/libdwarf/dwarf_elf_rel_detector.c
+++ b/libdwarf/dwarf_elf_rel_detector.c
@@ -339,6 +339,9 @@ _dwarf_is_64bit_abs_reloc(unsigned int type,
unsigned machine)
 #if defined (R_X86_64_64)
 | (type == R_X86_64_64)
 #endif
+#if defined (R_X86_64_PC64)
+    | (type == R_X86_64_PC64)
+#endif
 #if defined (R_X86_64_DTPOFF32)
 | (type == R_X86_64_DTPOFF64)
 #endif


Thanks for the report.
I've added the little object file
to the regression test base.

Regards,
David Anderson

Bug#963146: live-config: check for systemd is broken in /lib/live/config/0050-config

[Stefan Baur]

package: live-config
version: 5.20190519

Hi,

the file /lib/live/config/0050-config contains a check for systemd which
happens to be broken:

It checks for the presence of systemd with an "if which systemctl ..."
statement.

if which systemctl >/dev/null 2>/dev/null; then
systemctl set-environment "LANG=${_LOCALE}"
fi

This does not take into account that there may be situations where
systemctl is present, but systemd is not the currently running init
system, like when live-build is called with "--initsystem sysvinit":

Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  systemd241-7~deb10u4 amd64system and service manager
ii  sysvinit-core  2.93-8amd64System-V-like init utilities


The faulty check causes 0050-locales, or rather, systemctl, to throw an
error during startup when the package is installed, but e.g. sysvinit is
the currently running init system.

According to the systemd documentation, the proper way to check whether
or not systemd is the currently running init system is to check for the
presence of the directory /run/systemd/system.

Thus, the check

if which systemctl >/dev/null 2>/dev/null; then

should be changed to

if [ -d /run/systemd/system ] ; then

Kind Regards,
Stefan Baur
-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

Bug#936483: Possible fix

[Giovanni Mascellani]

Il 19/06/20 16:51, Giovanni Mascellani ha scritto:
> Basically I am replacing PyInt_Check with PyLong_Check, under the
> assumption that "long" is the new name of "int" in Python 3. This
> assumptions is corroborated by PyGame having this line in
> /usr/include/python3.8m/pygame/pgcompat.h:
> 
>   #define PyInt_Check(op) PyLong_Check(op)
> 
> That said, I wouldn't mind some competent Python developer to review the
> patch.

Comparing with [1], it seems my patch is ok.


https://github.com/enki-community/enki/commit/db813cdb7b669231b6670ccc9ee8f562aed29807

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



signature.asc
Description: OpenPGP digital signature

Bug#960379: bitcoin: diff for NMU version 0.18.1~dfsg-1.1

[Giovanni Mascellani]

Control: tags 960379 + patch
Control: tags 960379 + pending

Dear maintainer,

I've prepared an NMU for bitcoin (versioned as 0.18.1~dfsg-1.1) and
uploaded it to DELAYED/02. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
diff -Nru bitcoin-0.18.1~dfsg/debian/changelog bitcoin-0.18.1~dfsg/debian/changelog
--- bitcoin-0.18.1~dfsg/debian/changelog	2019-08-19 11:50:52.0 +0200
+++ bitcoin-0.18.1~dfsg/debian/changelog	2020-06-19 18:20:38.0 +0200
@@ -1,3 +1,10 @@
+bitcoin (0.18.1~dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with new Univalue interface (closes: #960379).
+
+ -- Giovanni Mascellani   Fri, 19 Jun 2020 18:20:38 +0200
+
 bitcoin (0.18.1~dfsg-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch
--- bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch	1970-01-01 01:00:00.0 +0100
+++ bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch	2020-06-19 18:20:38.0 +0200
@@ -0,0 +1,21 @@
+From: Giovanni Mascellani 
+Date: Wed, 17 Jun 2020 19:05:43 +0200
+Subject: Fix FTBFS with new Univalue Interface.
+
+---
+ src/rpc/blockchain.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp
+index bd35163..52fcd3c 100644
+--- a/src/rpc/blockchain.cpp
 b/src/rpc/blockchain.cpp
+@@ -2198,7 +2198,7 @@ UniValue scantxoutset(const JSONRPCRequest& request)
+ // no scan in progress
+ return NullUniValue;
+ }
+-result.pushKV("progress", g_scan_progress);
++result.pushKV("progress", int(g_scan_progress));
+ return result;
+ } else if (request.params[0].get_str() == "abort") {
+ CoinsViewScanReserver reserver;
diff -Nru bitcoin-0.18.1~dfsg/debian/patches/series bitcoin-0.18.1~dfsg/debian/patches/series
--- bitcoin-0.18.1~dfsg/debian/patches/series	2019-08-19 11:50:52.0 +0200
+++ bitcoin-0.18.1~dfsg/debian/patches/series	2020-06-19 18:20:38.0 +0200
@@ -3,3 +3,4 @@
 1003_man_proper_header.patch
 2001_avoid_embedded_libs.patch
 2002_avoid_network_tests.patch
+0006-Fix-FTBFS-with-new-Univalue-Interface.patch

Bug#963145: RFS: tstools/1.13~git20151030-4 -- set of tools for reporting on and manipulating MPEG data

[Jpaulo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: tstools
   Version : 1.13~git20151030-4
   Upstream Author : [fill in name and email of upstream]
 * URL : https://github.com/kynesim/tstools
 * License : MPL-1.1
 * Vcs : https://salsa.debian.org/debian/tstools
   Section : utils

It builds those binary packages:

  tstools - set of tools for reporting on and manipulating MPEG data

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/t/tstools/tstools_1.13~git20151030-4.dsc

Changes since the last upload:

   * QA upload.
   * debian/control:
   - Bumped Standards-Version to 4.5.0.
   - debhelper-compat bumped level to 13.
   * debian/copyright: Update years of copyright.
   * debian/patches: 0002-fix-spelling-error.patch added to fix
 some spelling.
   * debian/upstream/metadata: Created.
   * debian/rules: Remove not needed injection of linker flags and
 removed unnecessary lines.

Thank you for all the help you can give.

Regards,

Bug#963144: src:lcd4linux: Build-depends on libgphoto2, but does not use it

[Ferenc Wágner]

Package: src:lcd4linux
Severity: minor

Dear Maintainer,

The lcd4linux package Build-Depends on libgphoto2-dev, but does not
actually use it during the build.  I don't even understand how it could,
so I kindly ask you to consider dropping the dependency if possible.  It
would simplify checking the reverse dependencies of libgphoto2 before
uploads.
-- 
Thanks,
Feri.

Bug#963143: src:opencv: Build-depends on libgphoto2, but does not use it

[Ferenc Wágner]

Package: src:opencv
Severity: minor

Dear Maintainer,

The opencv package Build-Depends on libgphoto2-dev, but does not
actually use it during the build.  Please either drop the dependency,
or consider making use of it via a patch like

diff -Nru opencv-4.2.0+dfsg/debian/rules opencv-4.2.0+dfsg/debian/rules
--- opencv-4.2.0+dfsg/debian/rules  2020-04-02 05:02:10.0 +0200
+++ opencv-4.2.0+dfsg/debian/rules  2020-06-19 17:32:29.0 +0200
@@ -90,6 +90,7 @@
-DWITH_GDAL=ON \
-DWITH_GDCM=ON \
-DWITH_GSTREAMER=ON \
+   -DWITH_GPHOTO2=ON \
-DWITH_GTK=ON \
-DWITH_IPP=OFF \
-DWITH_ITT=OFF \

(I'm not asking for this feature, just noticed this inconsistency while
doing a test rebuild of the reverse dependencies of libgphoto2 before
upload.)
-- 
Thanks,
Feri.

Bug#873075: Package SCGI and SCGI::Request

[Richard Hansen]

I noticed that https://github.com/raoulbhatia/backuppc copies 
https://metacpan.org/pod/SCGI and https://metacpan.org/pod/SCGI::Request into 
the backuppc source code. I packaged those modules in a new libscgi-perl 
package so that they can be brought in as dependencies instead. I need a 
sponsor to get it submitted, however: https://bugs.debian.org/963105

Bug#962773: libpcre2-dev: Linuxinfo fails to link: ./linuxinfo_common.c:224: undefined reference to `pcre2_compile_8'

[Matthew Vernon]

On 16/06/2020 20:21, Helge Kreutzmann wrote:

Hello Matthew,
thanks for your reply.
On Tue, Jun 16, 2020 at 07:24:29PM +0100, Matthew Vernon wrote:

On 13/06/2020 20:44, Helge Kreutzmann wrote:


gcc  -g -O2 -fdebug-prefix-map=/tmp/testfoo2/linuxinfo-3.1.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -lpcre2-8 
-Wl,-z,relro -o linuxinfo linuxinfo.o linuxinfo_common.o linuxinfo_arm.o 
linuxinfo_alpha.o linuxinfo_ia64.o linuxinfo_intel.o linuxinfo_m68k.o 
linuxinfo_ppc.o linuxinfo_sh.o linuxinfo_hppa.o linuxinfo_s390.o 
linuxinfo_avr.o linuxinfo_sparc.o linuxinfo_mips.o linuxinfo_unknown.o
/usr/bin/ld: linuxinfo_common.o: in function `regstrcmp':
./linuxinfo_common.c:224: undefined reference to `pcre2_compile_8'


This is a bit confusing to me, as I think the symbol is there -

if you do objdump -T [path to your libpcre2-8.so] do you see pcre2_compile_8
(et al) there?


In my sid chroot:
root@samd:/# objdump -T /usr/lib/x86_64-linux-gnu/libpcre2-8.so | grep 
pcre2_compile_8
ba80 gDF .text  55cf  Base pcre2_compile_8


On my testing system, I do...


Is this the expected output?


Yes, so the symbol pcre2_compile_8 is present, so I'm not sure why ld 
isn't linking it...


[can you reproduce with a little test program? but I think this is a 
build issue not a pcre2 one at the moment]


Regards,

Matthew

Bug#963142: ITP: libstreamvbyte -- fast integer compression in C using the StreamVByte codec

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: libstreamvbyte -- fast integer compression in C using the 
StreamVByte codec
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: libstreamvbyte
  Version : 0.4.1
  Upstream Author : Daniel Lemire, Kendall Willets, Alexander Gallego
* URL : https://github.com/lemire/streamvbyte
* License : Apache-2.0
  Programming Lang: C
  Description : fast integer compression in C using the StreamVByte codec
 StreamVByte is a new integer compression technique that applies SIMD
 instructions (vectorization) to Google's Group Varint approach. The net
 result is faster than other byte-oriented compression techniques.
 .
 It includes fast differential coding.
 .
 It assumes a recent Intel processor (e.g., haswell or better) or an ARM
 processor with NEON instructions (which is almost all of them).

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/libstreamvbyte

Bug#956190: dh-python's autopkg tests fail with python3.8 as the only supported python3 version

[Olivier Tilloy]

This is fixed with
https://salsa.debian.org/python-team/tools/dh-python/-/commit/e289c25c861ae65ae9e7b52ebc09cf1f56061fa7,
but that version hasn't been released yet.

Bug#963140: ITP: pytest-salt-factories -- PyTest plug-in for Salt daemons to be used in tests

[Benjamin Drung]

Am Freitag, den 19.06.2020, 17:38 +0200 schrieb Benjamin Drung:
> Package: wnpp
> Severity: wishlist
> Owner: Benjamin Drung 
> 
> * Package name: pytest-salt-factories
>   Version : 0.10.7
>   Upstream Author : SaltStack Team
> * URL : 
> https://github.com/saltstack/pytest-salt-factories
> * License : 

I forgot to copy the license: It is Apache-2.0 except for one file
which is under public domain.

-- 
Benjamin Drung

DevOps Engineer and Debian & Ubuntu Developer
Platform Integration (IONOS Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Dr. Christian Böing, Hüseyin Dogan, Dr. Martin Endreß, Hans-
Henning Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte
Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat
sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie
bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem
bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern,
weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu
verwenden.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this e-mail 
in any way is prohibited. If you have received this e-mail in error,
please notify the sender and delete the e-mail.

Bug#936483: Possible fix

[Giovanni Mascellani]

Hi,

the attached patch seems to fix the FTBFS with Python 3. I am not
completely sure it is the right fix, though, meaning that the package
compiles with my patch, but I am not sure the logic is correct.

Basically I am replacing PyInt_Check with PyLong_Check, under the
assumption that "long" is the new name of "int" in Python 3. This
assumptions is corroborated by PyGame having this line in
/usr/include/python3.8m/pygame/pgcompat.h:

  #define PyInt_Check(op) PyLong_Check(op)

That said, I wouldn't mind some competent Python developer to review the
patch.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
diff --git a/python/enki.cpp b/python/enki.cpp
index b18e6ea..216ae41 100644
--- a/python/enki.cpp
+++ b/python/enki.cpp
@@ -105,11 +105,11 @@ struct Vector_from_python
 			
 			PyObject* item0(PyTuple_GetItem(objPtr, 0));
 			assert (item0);
-			if (!(PyFloat_Check(item0) || PyInt_Check(item0)))
+			if (!(PyFloat_Check(item0) || PyLong_Check(item0)))
 return 0;
 			PyObject* item1(PyTuple_GetItem(objPtr, 1));
 			assert (item1);
-			if (!(PyFloat_Check(item1) || PyInt_Check(item1)))
+			if (!(PyFloat_Check(item1) || PyLong_Check(item1)))
 return 0;
 		}
 		else
@@ -120,11 +120,11 @@ struct Vector_from_python
 			
 			PyObject* item0(PyList_GetItem(objPtr, 0));
 			assert (item0);
-			if (!(PyFloat_Check(item0) || PyInt_Check(item0)))
+			if (!(PyFloat_Check(item0) || PyLong_Check(item0)))
 return 0;
 			PyObject* item1(PyList_GetItem(objPtr, 1));
 			assert (item1);
-			if (!(PyFloat_Check(item1) || PyInt_Check(item1)))
+			if (!(PyFloat_Check(item1) || PyLong_Check(item1)))
 return 0;
 		}
 		


signature.asc
Description: OpenPGP digital signature

Bug#963108: perl: Please include minor patch to fix FTBFS on m68k

[John Paul Adrian Glaubitz]

On 6/19/20 8:37 AM, John Paul Adrian Glaubitz wrote:
> On 6/19/20 8:22 AM, John Paul Adrian Glaubitz wrote:
>> The attached patch fixes the problem by adding an additional 16 bits padding
>> before the opslot member which causes the alignment of opslot to be 32 bits.
> 
> Attaching a patch with a better commit message for explanation.

Third version of the patch which includes Laurent's and Geert's feedback and 
which
is hopefully the version that gets merged upstream.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From 89acf85c3c8943081b5dcd5d3c8bcc2384d8f8b7 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz 
Date: Fri, 19 Jun 2020 16:40:38 +0200
Subject: [PATCH] op.h: Add additional padding to struct opslab to ensure
 proper alignment

On m68k, the natural alignment is 16 bits which causes the opslab_opslot
member of struct opslab to be aligned at a 16-bit offset. Other 32-bit
and 64-bit architectures have a natural alignment of at least 32 bits, so
the offset is always guaranteed to be at least 32-bit-aligned.

Fix this by adding additional padding bytes before the opslab_opslot
member, both for cases when PERL_DEBUG_READONLY_OPS defined and not
defined to ensure the offset of oplab_slots is always 32-bit-aligned.
On architectures which have a natural alignment of at least 32 bits,
the padding does not affect the alignment, offsets or struct size.
---
 AUTHORS | 1 +
 op.h| 3 +++
 2 files changed, 4 insertions(+)

diff --git a/AUTHORS b/AUTHORS
index 1a4680027f..e4ea405d98 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -651,6 +651,7 @@ John Macdonald 
 John Malmberg  
 John Nolan 
 John P. Linderman  
+John Paul Adrian Glaubitz  
 John Peacock   
 John Pfuntner  
 John Poltorak  
diff --git a/op.h b/op.h
index fc21f03cda..b9f6da82c9 100644
--- a/op.h
+++ b/op.h
@@ -713,6 +713,9 @@ struct opslab {
units) */
 # ifdef PERL_DEBUG_READONLY_OPS
 bool	opslab_readonly;
+U8  opslab_padding; /* padding to ensure that opslab_slots is always */
+# else
+U16 opslab_padding; /* located at an offset with 32-bit alignment */
 # endif
 OPSLOT	opslab_slots;		/* slots begin here */
 };
-- 
2.27.0

Bug#888705: abseil-cpp packaging

[Benjamin Barenblat]

On Sat, May 23, 2020 at 2:39 PM Benjamin Barenblat  wrote:
> This is now in the NEW queue.

On Friday, June 19, 2020, at  8:07 AM +0200, László Böszörményi (GCS) wrote:
> Not anymore and not in the archives. What happened? Can I help?

ftp-master rejected the upload with concerns that changing the names of
all those small binary packages every time an ABI break occurs could
cause too much churn in the archive. That’s an easy fix, though – just
consolidate the shared libraries into a single binary package. You
actually caught me at an opportune time; I just redid the upload, and it
should reappear in NEW shortly. So there’s no work to be done at
present, but I’ll let you know if ftp-master has further concerns.

Benjamin

Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

[John Paul Adrian Glaubitz]

On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz 
> :
>> So nothing that keeps us from using GCC in cases where clang is not
>> available.
> 
> Correct. Except staying as close as possible with upstream.

While at the same time, the source contains 20+ patches:

> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/tree/debian-experimental-7.0/patches

I wouldn't consider that "close to upstream".

 Not sure why you want to enforce architectures off libreoffice when
 it’s technically not necessary.
>>>
>>> Read the comment.
>>
>> That's just your personal way of implementing it. It's not mandatory to
>> do it
>> this way. You can just create a simple whitelist where clang is always
>> enabled
>> and disabled on any other architecture. It's not really rocket science.
> 
> Trust me, I know. I do this for all kind of stuff in rules (e.g. for skia 
> itself, see below)

This isn't a technical argument though.

>> It's also not a given that clang generates faster code on _any_ given
>> architecture,
>> it might be true for x86_64, but not necessarily for armhf or s390x.
> 
> s390x doesn't matter here at all as it is be and skia doesn't support be at 
> all. Thus we get --disable-skia and thus no clang usage.
> 
> But generally you're right, but I am trying to stay as close upstream as 
> possible here.

Again, this isn't a compelling technical argument. There is no additional 
workload
involved if you allow building LO with GCC on non-clang architectures and it 
also
does not cause harm any of the release architectures. You are not required to 
fix
any code that doesn't build on a non-release architecture, that's what we 
porters
are for.

I have honestly no clue why you would deny porters to build LibreOffice on 
non-release
architectures given these circumstances. There is no paragraph in the Debian 
Policy
to base this decision on nor are there any technical reasons.

Would it be okay if I send a pull request to make the necessary changes?

Thanks,
Adrian

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

Bug#963141: /usr/bin/dh_make: "MIT" license should be called Expat to be more specific

[魏銘廷]

Package: dh-make
Version: 2.202001
Severity: minor
File: /usr/share/debhelper/dh_make/licenses/mit

The license template file /usr/share/debhelper/dh_make/licenses/mit
uses MIT to describe Expat license, however as described by
copyright-format 1.0 specification
(https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/)

> There are many versions of the MIT license. Please use Expat instead,
> when it matches. 

Therefore, please change the name MIT to Expat to be more specific to
such version of MIT license.

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

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

Versions of packages dh-make depends on:
ii  debhelper  13.1
ii  dpkg-dev   1.19.7
ii  make   4.3-3
ii  python33.8.2-3

dh-make recommends no packages.

Versions of packages dh-make suggests:
ii  build-essential  12.8

-- no debconf information


signature.asc
Description: PGP signature

Bug#963140: ITP: pytest-salt-factories -- PyTest plug-in for Salt daemons to be used in tests

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: pytest-salt-factories
  Version : 0.10.7
  Upstream Author : SaltStack Team
* URL : https://github.com/saltstack/pytest-salt-factories
* License : 
  Programming Lang: Python
  Description : PyTest plug-in for Salt daemons to be used in tests

This package provides a PyTest plug-in that allows one to use the Salt
daemons in tests. This plug-in is used in Salt's test suite. This is the
successor of python3-pytestsalt, this time focused on simplicity and
extensibility.

I will maintain this package as part of the Debian Salt Team.

-- 
Benjamin Drung

DevOps Engineer and Debian & Ubuntu Developer
Platform Integration (IONOS Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Dr. Christian Böing, Hüseyin Dogan, Dr. Martin Endreß,
Hans-Henning Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#959386: php-imagick: diff for NMU version 3.4.4-4.1

[Adrian Bunk]

On Sun, Jun 14, 2020 at 10:58:58PM +0200, Ondřej Surý wrote:
> Adrian,

Hi Ondřej,

> please do a direct upload to unstable and thanks for the fix. No need to wait 
> 15 days.

thanks, rescheduled for immediate upload.

cu
Adrian

Bug#963081: src:camera.app: Please switch to using pkg-config for libgphoto2

[Yavor Doganov]

Ferenc Wágner wrote:
> Package: src:camera.app
> Version: 0.8.0-12
> Severity: normal
> 
> I plan to upload libgphoto2 2.5.25 without the config scripts,
> which upstream considers obsolete and hurt the multi-arch effort.
> It's easy to switch to using pkg-config instead, see the attached
> debdiff.

Thanks; I'll fix this shortly -- the upload will depend on my sponsor
though.  Meanwhile, feel free to upload libgphoto2 whenever you like
and raise the severity of this bug to serious.

Bug#962917: Re[2]: Bug#962917: libatomic-ops: FTBFS in the testsuite on riscv64 due to missing -pthread

[Ivan Maidanski]

At the same time, I checked clang for riscv (64-bit) without patch — it works, 
e.g.:
 
unsigned /**/ short
AO_char_fetch_and_add( volatile   unsigned /**/ short  *addr,  unsigned /**/ 
short  incr)
{
   return  __atomic_fetch_add(addr, incr, __ATOMIC_RELEASE);
}
 
->
 
AO_char_fetch_and_add(unsigned short volatile*, unsigned short):
 addi  sp ,  sp , - 32
 sd    ra ,  24 ( sp )
 sd    s0 ,  16 ( sp )
 addi  s0 ,  sp ,  32
 add   a2 ,  zero ,  a1
 sd    a0 , - 24 ( s0 )
 sh    a1 , - 26 ( s0 )
 ld    a0 , - 24 ( s0 )
 lh    a1 , - 26 ( s0 )
 sh    a1 , - 28 ( s0 )
 lhu   a1 , - 28 ( s0 )
 andi  a3 ,  a0 , - 4
 andi  a0 ,  a0 ,  3
 slli  a0 ,  a0 ,  3
 lui   a4 ,  16
 addiw     a4 ,  a4 , - 1
 sllw  a4 ,  a4 ,  a0
 sllw  a1 ,  a1 ,  a0
.LBB0_1:
 lr.w  a5 , ( a3 )
 add   a6 ,  a5 ,  a1
 xor   a6 ,  a5 ,  a6
 and   a6 ,  a6 ,  a4
 xor   a6 ,  a5 ,  a6
 sc.w.rl   a6 ,  a6 , ( a3 )
 bnez  a6 ,  .LBB0_1
 srlw  a0 ,  a5 ,  a0
 sh    a0 , - 30 ( s0 )
 lhu   a0 , - 30 ( s0 )
 ld    s0 ,  16 ( sp )
 ld    ra ,  24 ( sp )
 addi  sp ,  sp ,  32
 ret
 
So, probably the root cause of this linker issue is that -latomic should be 
passed, and my assumption was wrong that pthread-based implementation.
 
 

Bug#963139: cacti: CVE-2020-14295

[Salvatore Bonaccorso]

Source: cacti
Version: 1.2.12+ds1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/Cacti/cacti/issues/3622

Hi,

The following vulnerability was published for cacti. There is no patch
yet, but a proposed change mentioned in the upstream issue.

CVE-2020-14295[0]:
| A SQL injection issue in color.php in Cacti 1.2.12 allows an admin to
| inject SQL via the filter parameter. This can lead to remote command
| execution because the product accepts stacked queries.


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-14295
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14295
[1] https://github.com/Cacti/cacti/issues/3622

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#962847: exim4: takes forever to send a mail after sleeping

[Adam D. Barratt]

On Mon, 2020-06-15 at 18:01 +0200, Marc Haber wrote:
> On Mon, Jun 15, 2020 at 01:56:18PM +0200, Rémi Letot wrote:
> > My mail client and exim are both running on my laptop, and the
> > provided logs are from that same laptop.
> > 
> > The fault is the delay between exim accepting the message, and
> > actually delivering it to the smarthost. During that delay, my mail
> > client is stuck too.
> 
> That is highly implausible. In a normal setup, the SMTP client is out
> of the game as soon exim has locally queued the message. Can you run
> tcpdump on lo to find out what's happening? I guess that you're
> putting the laptop to sleep before the (local) TCP session has been
> properly closed, making it subject to the exponential backoff
> algorithm and eventually a session timeout. There is not much exim
> can do in this situation.

I'm wondering if this is an issue related to the clock changing (or not
changing when it should) as a result of the suspend / resume cycle,
similar to 
https://lists.exim.org/lurker/message/20200619.090409.faf4b641.en.html

Regards,

Adam

Bug#962917: libatomic-ops: FTBFS in the testsuite on riscv64 due to missing -pthread

[Ivan Maidanski]

Hello Karsten,
 
Please test the attached patch.
(I have not tested it on riscv)
 
Regards,
Ivan
 
 

riscv64-fix-missing-byte-short-primitives.diff
Description: Binary data

Bug#963137: ITP: ncls: Datastructure for interval overlap queries

[Nilesh Patra]

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


* Package name: ncls
  Version : 0.0.53
  Upstream Author : Endre Bakken Stovner
* URL : https://github.com/biocore-ntnu/ncls

* License : BSD-3-Clause
  Programming Lang: Python
  Description : Datastructure for interval overlap queries

 The Nested Containment List is a datastructure
 for interval overlap queries, like the interval
 tree. It is usually an order of magnitude faster
 than the interval tree both for building and query
 lookups. The implementation here is a revived
 version of the one used in the now defunct PyGr
 library. Its made less memory-consuming and
 has wrapper functions which allows batch-querying

NB: Dependency of pyrle
I take the responsibility to maintain this package.

Bug#963136: libnss3-dev:amd64 not coinstallable with libnss3-dev:armhf

[Enrico Zini]

Package: libnss3-dev
Version: 3.42.1-1+deb10u2
Severity: wishlist

Hello,

thank you for maintaining libnss3-dev.

This might be closely related to #737855, which sadly doesn't seem to
have had much activity since 2014.

libnss3-dev:amd64 is not not coinstallable with libnss3-dev:armhf,
either directly, or because the libnspr4-dev dependency is also not
coinstallable between amd64 and armhf.

This is the current blocker that I can't overcome for having qtwebengine
compiled as part of a Qt5 integrated cross-development environment:
https://www.enricozini.org/blog/2020/qt5/qt5-custom-build-for-armhf-embedded-development/

Also, I find coinstallable development libraries very desirable in all
sorts of cross-development situations.

Could nss (and I guess also nspr) please be made to be coinstallable
across architectures?


Enrico


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

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

Versions of packages libnss3-dev depends on:
pn  libnspr4-dev  
ii  libnss3   2:3.42.1-1+deb10u2

libnss3-dev recommends no packages.

libnss3-dev suggests no packages.

Bug#962174: Fwd: Bug#962174: Acknowledgement (iwd: Failed to load trusted user certificate)

[Andreas Henriksson]

Control: tags -1 + upstream

Hello Martin Tesar,

Thanks for your bug report. This is obviously not a debian packaging
bug so could you please discuss this directly with upstream?
Either on their mailing list and/or their irc channel.

See https://sources.debian.org/src/iwd/1.8-1/debian/upstream/metadata/

Regards,
Andreas Henriksson

On Thu, Jun 04, 2020 at 06:29:22PM +0200, Martin Tesar wrote:
> Hello,
> 
> I am not sure who can change it. Would you, please?
> 
> Thanks in advance!
> 
> BR
> Martin
> 
> -- Forwarded message -
> Od: Martin Tesar 
> Date: čt 4. 6. 2020 v 14:51
> Subject: Re: Bug#962174: Acknowledgement (iwd: Failed to load trusted user
> certificate)
> To: 
> 
> 
> Hello,
> 
> would you please change an email address  of a submitter (me) from
> tesar...@gmail.com to my other email address martin.te...@yourwifi.cz?
> 
> Thanks a lot!
> 
> Regards,
> Martin Tesar
> 
> čt 4. 6. 2020 v 10:33 odesílatel Debian Bug Tracking System
>  napsal:
> >
> > Thank you for filing a new Bug report with Debian.
> >
> > You can follow progress on this Bug here: 962174:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962174.
> >
> > 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):
> >  Andreas Henriksson 
> >
> > If you wish to submit further information on this problem, please
> > send it to 962...@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.
> >
> > --
> > 962174: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962174
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems