Bug#757402: git: test suite fails on hppa, in run_with_limited_stack

[Greg Price]

Great! WFM on amd64, too.

>  *)
> + uname_m=$(uname -m)
> + case $uname_m in
> + parisc*)
> + test_set_prereq HPPA
> + ;;
> + esac

Probably cleanest to put this outside the `case $uname_s`.

Would you mind if I send a version of this patch to the upstream
mailing list? I think that's the best route for it to go through.

Or you're of course welcome to do so (and please cc this bug); if you
haven't submitted patches to Git before, you'll want to read the
instructions here:
https://git.github.io/htmldocs/SubmittingPatches.html#send-patches

Cheers,
Greg

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Mike Hommey]

On Wed, May 13, 2020 at 07:35:00AM +0900, Mike Hommey wrote:
> On Wed, May 13, 2020 at 12:23:55AM +0200, Francesco Poli wrote:
> > On Wed, 13 May 2020 06:35:33 +0900 Mike Hommey wrote:
> > 
> > > On Tue, May 12, 2020 at 06:37:00PM +0200, Francesco Poli wrote:
> > [...]
> > > > debian/control includes
> > > > 
> > > >   Build-Depends: [...]
> > > >  libvpx-dev (>= 1.5.0),
> > > >  [...]
> > > >   Build-Conflicts: [...]
> > > >libvpx-dev (>= 1.8.0),
> > > >[...]
> > > 
> > > No it doesn't. It only does if you take the backport for stable or
> > > older.
> > > 
> > > Or if this condition doesn't hold:
> > > ifneq (,$(filter testing% bullseye% unstable sid,$(DEB_DISTRIBUTION)))
> > > 
> > > (where DEB_DISTRIBUTION comes from /usr/share/dpkg/pkg-info.mk)
> > 
> > Could you please elaborate?
> > 
> > 
> > As I said, I used dget to obtain the unpacked source package.
> > In the unpacked source tree, I see a debian/control file with the above
> > mentioned content.
> 
> If I dget 
> https://snapshot.debian.org/archive/debian/20200408T025735Z/pool/main/f/firefox-esr/firefox-esr_68.7.0esr-1.dsc,
>  I get a debian/control that doesn't contain anything about libvpx. 
> debian/control.in does, but that should be irrelevant.

Something else you could try is rebuild firefox-esr 68.8.0esr-1 with
this patch applied: 
https://salsa.debian.org/mozilla-team/firefox/-/commit/87df541b27a0b012e843978a0343f2918e0f2f58

Mike

Bug#960478: xorg-server: Allow XDMCP keepalives to be disabled

[herbert]

Package: xorg-server
Version: 2:1.20.4-1
Severity: wishlist

As it is, when an XDMCP session is used over TCP keepalive packets
are periodically sent and the session is torn down if no replies
come back.

During a transient network failure, this causes an X session that
could otherwise survive just fine to be terminated prematurely.

While some may wish for this behaviour, perhaps to avoid a locked-up
X terminal, it would be nice if there was an option to either
extend the timeout so that failures of a few minutes do not cause
the session to be torn down, or even better just disable the
keepalives altogether.

-- System Information
Debian Release: 10.3
Kernel Version: Linux gwarestrin 5.2.0+ #3 SMP PREEMPT Tue Aug 20 22:11:45 AEST 
2019 x86_64 GNU/Linux

Bug#956759: libayatana-indicator3 in workrave 1.10.44

[Francois Marier]

Hi Kentaro,

I have tried updating the workrave package to version 1.10.44 which includes
your libayatana-indicator3 patch, however I can't get it to build since I
run into this error:

  /bin/bash ../../../../libtool  --tag=CC   --mode=link gcc -pthread 
-I/usr/include/libayatana-indicator3-0.4 -I/usr/include/libdbusmenu-gtk3-0.4 
-I/usr/include/libdbusmenu-glib-0.4 -I/usr/include/gtk-3.0 
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo 
-I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wall 
-std=c99 -I./../include -I./../../common/include 
-DG_LOG_DOMAIN=\"Indicator-Workrave\" 
-DWORKRAVE_PKGDATADIR="\"/usr/share/workrave\"" -g -O2 
-fdebug-prefix-map=/home/francois/devel/deb/workrave/build-area/workrave-1.10.44=.
 -fstack-protector-strong -Wformat -Werror=format-security -module 
-avoid-version -Wl,-z,relro -Wl,-z,now -o libworkrave.la -rpath  
libworkrave_la-indicator-workrave.lo -layatana-indicator3 -ldbusmenu-gtk3 
-ldbusmenu-glib -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz 
-latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 
-lglib-2.0 -L./../../common/src -lworkrave-private-1.0 
  libtool:   error: only absolute run-paths are allowed
  make[7]: *** [Makefile:573: libworkrave.la] Error 1
  make[7] : on quitte le répertoire « 
/home/francois/devel/deb/workrave/build-area/workrave-1.10.44/frontend/applets/indicator/src
 »
  make[6]: *** [Makefile:503: all] Error 2
  make[6] : on quitte le répertoire « 
/home/francois/devel/deb/workrave/build-area/workrave-1.10.44/frontend/applets/indicator/src
 »
  make[5]: *** [Makefile:491: all-recursive] Error 1
  make[5] : on quitte le répertoire « 
/home/francois/devel/deb/workrave/build-area/workrave-1.10.44/frontend/applets/indicator
 »
  make[4]: *** [Makefile:491: all-recursive] Error 1
  make[4] : on quitte le répertoire « 
/home/francois/devel/deb/workrave/build-area/workrave-1.10.44/frontend/applets »
  make[3]: *** [Makefile:491: all-recursive] Error 1
  make[3] : on quitte le répertoire « 
/home/francois/devel/deb/workrave/build-area/workrave-1.10.44/frontend »
  make[2]: *** [Makefile:616: all-recursive] Error 1
  make[2] : on quitte le répertoire « 
/home/francois/devel/deb/workrave/build-area/workrave-1.10.44 »
  make[1]: *** [Makefile:518: all] Error 2
  make[1] : on quitte le répertoire « 
/home/francois/devel/deb/workrave/build-area/workrave-1.10.44 »
  dh_auto_build: error: make -j4 returned exit code 2

Looking at your PR, I can't figure out what's wrong/missing. I pushed my
changes to salsa in case you want to have a look:

  https://salsa.debian.org/debian/workrave

Francois

-- 
https://fmarier.org/

Bug#960477: RFS: iptux/0.7.6-2 -- Intranet communication tool for Linux

[铜豌豆 Linux]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : iptux
Version : 0.7.6-2
Upstream Author : LI Daobing 
* URL : https://github.com/iptux-src/iptux
* License : GPL-2+
* Vcs : https://salsa.debian.org/chinese-team/iptux
Section : net

It builds those binary packages:

iptux - Intranet communication tool for Linux

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/i/iptux/iptux_0.7.6-2.dsc

Changes since the last upload:

[ Debian Janitor ]
* Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
Repository-Browse.
.
[ 肖盛文 ]
* d/rules:
- delete export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
- delete override_dh_missing
* d/control:
- Bump debhelper-compat (= 13)
- Bump Standards-Version: 4.5.0
- add Rules-Requires-Root: no
- add new Uploaders

Regards,

-- 
肖盛文 Faris Xiao
邮箱：atzli...@yeah.net
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com




signature.asc
Description: OpenPGP digital signature

Bug#960476: transition: tinyxml2

[Chow Loong Jin]

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

This is a transition for the SONAME bump of tinyxml2 following a major
version bump in the upstream package. The following source packages need
to be rebuilt:

 * basilisk2
 * bullet
 * caveexpress
 * cppcheck
 * dart
 * encfs
 * gazebo
 * ignition-common
 * ignition-fuel-tools
 * ignition-msgs
 * lgogdownloader
 * libexadrums
 * libmediainfo
 * mrpt
 * ros-kdl-parser
 * ros-pluginlib
 * ros-ros
 * ros-rospack
 * ros-urdf
 * sdpb
 * trigger-rally


Ben file:

title = "tinyxml2";
is_affected = .depends ~ "libtinyxml2-6a" | .depends ~ "libtinyxml2-8";
is_good = .depends ~ "libtinyxml2-8";
is_bad = .depends ~ "libtinyxml2-6a";


-- System Information:
Debian Release: buster/sid
  APT prefers eoan-updates
  APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'), 
(400, 'eoan-proposed'), (100, 'eoan-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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


signature.asc
Description: PGP signature

Bug#960475: RFS: iptux/0.7.6-2 -- Intranet communication tool for Linux

[atzlinux 肖盛文]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : iptux
Version : 0.7.6-2
Upstream Author : LI Daobing 
* URL : https://github.com/iptux-src/iptux
* License : GPL-2+
* Vcs : https://salsa.debian.org/chinese-team/iptux
Section : net

It builds those binary packages:

iptux - Intranet communication tool for Linux

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/i/iptux/iptux_0.7.6-2.dsc

Changes since the last upload:

[ Debian Janitor ]
* Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
Repository-Browse.
.
[ 肖盛文 ]
* d/rules:
- delete export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
- delete override_dh_missing
* d/control:
- Bump debhelper-compat (= 13)
- Bump Standards-Version: 4.5.0
- add Rules-Requires-Root: no
- add new Uploaders

Regards,

-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com




signature.asc
Description: OpenPGP digital signature

Bug#960467: gcl showing "personality failure 1" then exit

[Gong-Yi Liao]

Package: gcl
Version: 2.6.12-95
Severity: important

Dear Maintainer,

When I ran "gcl" command at shell prompt, I just got a strange
message "personality failure 1" then gcl exited without any 
useful information, not sure if it's a feature that prevent 
anyone to use it or it's serious bug turn gcl totally useless. 


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

Kernel: Linux 5.6.11-300.fc32.x86_64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages gcl depends on:
ii  debconf   1.5.74
ii  emacs-gtk [emacsen]   1:26.3+1-1
ii  emacs-snapshot [emacsen]  2:20200510+emacs-27.0.91-860-g9d8fc3a5980-1
ii  gcc   4:9.2.1-3.1
ii  libc6 2.30-8
ii  libgmp10  2:6.2.0+dfsg-4
ii  libreadline8  8.0-4
ii  libtcl8.6 8.6.10+dfsg-1
ii  libtk8.6  8.6.10-1
ii  libx11-6  2:1.6.9-2+b1
ii  ucf   3.0039

gcl recommends no packages.

Versions of packages gcl suggests:
pn  gcl-doc  

-- debconf information:
  gcl/default_gcl_prof:
  gcl/default_gcl_ansi:

Bug#960474: fcitx-rime: fcitx crashes when switching to fcitx-rime

[Mad Horse]

Package: fcitx-rime
Version: 0.3.2-7
Severity: important

Dear Maintainer,

When switching to fcitx-rime, fcitx crashes.

Trace can be retrieved by running with $ fcitx -D:

(ERROR-2559744 ime.c:432) fcitx-keyboard-in-tel-kagapa already exists
(ERROR-2559744 ime.c:432) fcitx-keyboard-cm-mmuock already exists
=
FCITX 4.2.9.7 -- Get Signal No.: 11
Date: try "date -d @1589341159" if you are using GNU date ***
ProcessID: 2559744
fcitx(+0x1927)[0x55c60af5e927]
/lib/x86_64-linux-gnu/libc.so.6(+0x3b7e0)[0x7f677938d7e0]
/usr/lib/x86_64-linux-
gnu/librime.so.1(_ZNK4YAML4Node4TypeEv+0x30)[0x7f676dc8c020]
/usr/lib/x86_64-linux-
gnu/librime.so.1(_ZN4rime10ConfigData15ConvertFromYamlERKN4YAML4NodeEPNS_14ConfigCompilerE+0x35)[0x7f676dc87425]
/usr/lib/x86_64-linux-
gnu/librime.so.1(_ZN4rime10ConfigData12LoadFromFileERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_14ConfigCompilerE+0x1a2)[0x7f676dc88712]
/usr/lib/x86_64-linux-
gnu/librime.so.1(_ZN4rime18InstallationUpdate3RunEPNS_8DeployerE+0x3cd)[0x7f676dd6c7dd]
/usr/lib/x86_64-linux-
gnu/librime.so.1(_ZN4rime8Deployer7RunTaskERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5boost3anyE+0xb3)[0x7f676dc44c83]
/usr/lib/x86_64-linux-
gnu/librime.so.1(RimeStartMaintenance+0xb6)[0x7f676dc25286]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-rime.so(+0x2e16)[0x7f676f46fe16]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-rime.so(+0x34ac)[0x7f676f4704ac]
/usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x111ea)[0x7f67795771ea]
/usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x14388)[0x7f677957a388]
/usr/lib/x86_64-linux-gnu/libfcitx-
core.so.0(FcitxInstanceSwitchIMByIndex+0x95)[0x7f677957afb5]
/usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x15083)[0x7f677957b083]
/usr/lib/x86_64-linux-gnu/libfcitx-
core.so.0(FcitxInstanceProcessKey+0x956)[0x7f677957bf36]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-ipc.so(+0x6a70)[0x7f677409ca70]
/lib/x86_64-linux-gnu/libdbus-1.so.3(+0x26c8d)[0x7f67781e5c8d]
/lib/x86_64-linux-
gnu/libdbus-1.so.3(dbus_connection_dispatch+0x334)[0x7f67781d67e4]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-dbus.so(+0x28b8)[0x7f67795b18b8]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-dbus.so(+0x29d1)[0x7f67795b19d1]
/usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0xa38a)[0x7f677957038a]
/usr/lib/x86_64-linux-gnu/libfcitx-
core.so.0(FcitxInstanceRun+0x57)[0x7f6779570b27]
fcitx(+0x12bf)[0x55c60af5e2bf]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f6779378e0b]
fcitx(+0x133a)[0x55c60af5e33a]




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

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

Versions of packages fcitx-rime depends on:
ii fcitx-bin 1:4.2.9.7-3
ii fcitx-data 1:4.2.9.7-3
ii fcitx-modules 1:4.2.9.7-3
ii libc6 2.30-7
ii libfcitx-config4 1:4.2.9.7-3
ii libfcitx-qt5-1 1.2.4-1
ii libgcc-s1 10.1.0-1
ii libqt5core5a 5.12.5+dfsg-10
ii libqt5gui5 5.12.5+dfsg-10
ii libqt5widgets5 5.12.5+dfsg-10
ii librime-data 0.38.20180515-3
ii librime1 1.5.3+dfsg1-5
ii libstdc++6 10.1.0-1

Versions of packages fcitx-rime recommends:
ii fcitx 1:4.2.9.7-3

fcitx-rime suggests no packages.

-- no debconf information

Bug#960472: ITP: python-readchar -- Python library to portable read single characters and key-strokes

[Kienan Stewart]

Package: wnpp
Severity: wishlist
Owner: Kienan Stewart 

* Package name: python-readchar
  Version : 2.0.0
  Upstream Author : Miguel Ángel García 
* URL : https://github.com/magmax/python-readchar
* License : MIT
  Programming Lang: Python
  Description : Python library to portable read single characters and 
key-strokes

The library provides a small class which sets up the key id for various
platforms to provide a unified interface for developers to use when
reading keystrokes in Python.

This package is a dependency of python-inquirer.

I will need to find a sponsor for the upload of this package.

Bug#960471: ITP: prophet -- Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth.

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: prophet
  Upstream Author : Facebook
* URL : https://github.com/facebook/prophet
* License : MIT
  Programming Lang: Py, R
  Description : Tool for producing high quality forecasts for time series 
data that has multiple seasonality with linear or non-linear growth.


Time series analysis tool.
Will be maintained by debian science team.

Bug#960470: ITP: python-inquirer -- Collection of common interactive command line user interfaces in python

[Kienan Stewart]

Package: wnpp
Severity: wishlist
Owner: Kienan Stewart 

* Package name: python-inquirer
  Version : 2.6.3
  Upstream Author : Miguel Ángel García 
* URL : https://github.com/magmax/python-inquirer
* License : MIT
  Programming Lang: Python
  Description : Collection of common interactive command line user 
interfaces in python

This package provides a library of common interactive CLI interfaces based on
Inquirer.js. This library should ease the process of asking end user questions,
parsing, validating answers, managing hierarchical prompts and providing error
feedback.

I will need to find a sponsor to upload this package.

Bug#956543: freecad: FTBFS with new opencascade 7.4 (library transition)

[Kurt Kremitzki]

Hello Gregor,

On Tuesday, May 12, 2020 6:58:04 PM CDT Gregor Riepl wrote:
> > Status update why this package has not yet been updated:
> > If the freecad is rebuilt against pyside2, it will run
> > into 945376 at runtime, namely when opening the PartDesign workbench.
> > As this is a major feature in freecad and the current version in
> > sid works its better to wait until pyside2 has been fixed.
> 
> 945376 got a fix in experimental now.
> 
> freecad is currently not co-installable with kicad, because the latter
> was already transitioned to opencascade 7.4.
> 
> Would you consider a fixed freecad upload to experimental as well? That
> way, the pyside2 bugfix could be tested with an updated freecad build.
> 

Yes, I am preparing an upload now and should have things resolved in the next 
day or two.

> > For that, several QT dependencies pyside have to be updted:
> > - qtdatavis3d-everywhere-src
> > - qtscxml-everywhere-src
> > - qtspeech-opensource-src
> > - qtxmlpatterns-opensource-src
> > 
> > Bugs have been filed against those package, they should block this bug.
> 
> I didn't see any bug reports on these packages, is there still work to
> be done on them?
> 
> 

They are already uploaded as of about a week ago.

Bug#960469: libtool: for a shared library, -L. -lfoo works but libfoo.so is ignored

[Nicolas Boulenguez]

Source: libtool
Version: 2.4.6-14
Severity: normal

Hello.

When linking a shared library against another uninstalled shared
library missing libtool support,
  -L. -lfoo  -L. -l:libfoo.so  libfoo.so
should be equivalent.

https://www.gnu.org/software/libtool/manual/libtool.html#FOOT2 and
https://www.gnu.org/software/automake/manual/automake.html#Linking
both recommend the third form because it is less ambiguous, but
libtool ignores it.

This results in the library containing undefined symbols, or an
immediate failure with --no-undefined.

A reproducer is attached.
#!/bin/sh
set -Cefu

cat > indirect.c <
void indirect (void) {
  printf ("If you are reading this, all probably went OK.\n");
}
EOF

cat > direct.c < main.c < configure.ac < Makefile.am <

Bug#931163: the new version released,please try it

[atzlinux 肖盛文]

Control: tags 931163  moreinfo


The new version released,please try it.

Package: tnftp
Version: 20151004-1

If this bug still exist,welcome feedback!


-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com



signature.asc
Description: OpenPGP digital signature

Bug#960464: RFP: datajoint -- a framework for scientific workflow management based on relational principles

[Emmanuel Arias]

Hi,

I would like to ITP.

This could be maintained under Debian Sience Team umbrella

If there are not any objections I'll start the ITP workflow

Cheers,
Arias Emmanuel
@eamanu
yaerobi.com

Bug#833928: could you test it on the newest xtail version?

[atzlinux 肖盛文]

Control: tags  833928 moreinfo


Could you test it on the newest xtail version?

If this bug is appear in Ubuntu,please report it to Ubuntu.


Thanks!


-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com



signature.asc
Description: OpenPGP digital signature

Bug#954907: [Python-modules-team] Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default

[Emmanuel Arias]

Hi

I've just push to salsa the upstream and pristine-tar branches.
Please,  review it.

Thanks!

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El lun., 11 de may. de 2020 a la(s) 17:26, Scott Kitterman
(deb...@kitterman.com) escribió:
>
> On Monday, May 11, 2020 4:18:45 PM EDT Emmanuel Arias wrote:
> > El lun., 11 de may. de 2020 a la(s) 17:10, Antoine Beaupré
> >
> > (anar...@debian.org) escribió:
> > > On 2020-05-11 14:53:29, Scott Kitterman wrote:
> > > > On Monday, May 11, 2020 2:39:30 PM EDT Antoine Beaupré wrote:
> > > >> On 2020-05-11 15:18:53, Emmanuel Arias wrote:
> > > >> > Hi,
> > > >> >
> > > >> > The upstream and pristine-tar branches are not generated on salsa for
> > > >> > any particular reason.?
> > > >>
> > > >> I'm not sure what question you are asking here. This package doesn't
> > > >> use
> > > >> pristine-tar or upstream branches right now, if that's what you're
> > > >> asking.
> > > >
> > > > Which it should since part of the DPMT standard repository layout.
> > > > Please fix.>
> > > I just found the time to update half a dozen Debian packages last
> > > night. I have no time for administrative details like this. I'm happy if
> > > some other folks in the team have time for that and won't stand in their
> > > way.
> > >
> > > I just hope my contributions to the team are otherwise appreciated. That
> > > package doesn't have pristine-tar and I don't plan to add it myself. If
> > > that's a problem for the team, I'm happy to move it to collab-maint or
> > > stop maintaining it.
> >
> > Sorry, my intention was not introduce noises. I did just asking just for be
> > sure if that package need help or not.  I will happy to add upstream and
> > pristine-tar branches :)
>
> Thank you.  Please do.
>
> This is not just administrivia.  People who interact with the team
> repositories expect a certain layout and it causes confusion when it is not
> used.
>
> When following the standard team processes (that we've all agreed to do), this
> amount of extra time it takes to do it correctly is virtually nil.
>
> Scott K

Bug#960462: RFS: libevpath/4.6.0-1 [ITP] -- Event transport middleware

[Kyle Edwards]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

Dear mentors,

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

 * Package name: libevpath
   Version : 4.6.0-1
   Upstream Author : Georgia Tech Research Corporation
 * URL : https://github.com/GTkorvo/evpath
 * License : BSD-3-clause
 * Vcs : https://gitlab.kitware.com/debian/libevpath
   Section : libs

It builds those binary packages:

  libevpath-dev - Event transport middleware - development files
  libevpath - Event transport middleware
  libevpath-enet - Event transport middleware - ENet transport module
  libevpath-libfabric - Event transport middleware - libfabric
transport module
  libevpath-ibverbs - Event transport middleware - ibverbs transport
module

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

  https://gitlab.kitware.com/debian/libevpath

Regards,

--
  Kyle Edwards

Bug#960468: Please package 0.8.4

[Antonio Russo]

Source: zfs-linux
Severity: wishlist
Tags: patch

--- Please enter the report below this line. ---

Upstream has release 0.8.4 [1].  It adds official support for 5.5 and 5.6---a 
dire need for Debian unstable
and testing users, since 5.4 is no longer supported.

Some packaging changes are required to build and install 0.8.4.  I've addressed 
them in an MR on salsa [2].

There may be some test failures on Linux 5.6 [3]---I am in the process of 
reproducing on Debian's kernel.

[1] https://github.com/openzfs/zfs/releases/tag/zfs-0.8.4
[2] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/23
[3] https://github.com/openzfs/zfs/pull/10209#issuecomment-626211848

Bug#960322: Debian 10.4-kernel 4.19.0-9 update no longer mounting mdadm array at boot

[Gene]

Was poking around in syslog and maybe found a clue. First, booting with the
4.19.0-9 kernel (raid isn't being mounted), I see this error:

May 12 07:37:13 server-pc systemd[1]: dev-md0.device: Job
dev-md0.device/start timed out.
May 12 07:37:13 server-pc systemd[1]: Timed out waiting for device /dev/md0.
May 12 07:37:13 server-pc systemd[1]: Dependency failed for /mnt/md0.
May 12 07:37:13 server-pc systemd[1]: mnt-md0.mount: Job
mnt-md0.mount/start failed with result 'dependency'.
May 12 07:37:13 server-pc systemd[1]: Startup finished in 11.398s (kernel)
+ 1min 30.148s (userspace) = 1min 41.546s.
May 12 07:37:13 server-pc systemd[1]: dev-md0.device: Job
dev-md0.device/start failed with result 'timeout'.

Later on, the array is being assembled as md127 I guess?

May 12 07:40:19 server-pc kernel: [   11.049712] md/raid:md127: device sdk
operational as raid disk 0
May 12 07:40:19 server-pc kernel: [   11.049712] md/raid:md127: device sdg
operational as raid disk 1
May 12 07:40:19 server-pc kernel: [   11.049713] md/raid:md127: device sdi
operational as raid disk 7
May 12 07:40:19 server-pc kernel: [   11.049713] md/raid:md127: device sda
operational as raid disk 11
May 12 07:40:19 server-pc kernel: [   11.049713] md/raid:md127: device sdo
operational as raid disk 12
May 12 07:40:19 server-pc kernel: [   11.049714] md/raid:md127: device sdn
operational as raid disk 13
May 12 07:40:19 server-pc kernel: [   11.049714] md/raid:md127: device sdj
operational as raid disk 8
May 12 07:40:19 server-pc kernel: [   11.049714] md/raid:md127: device sdh
operational as raid disk 3
May 12 07:40:19 server-pc kernel: [   11.049715] md/raid:md127: device sdl
operational as raid disk 4
May 12 07:40:19 server-pc kernel: [   11.049715] md/raid:md127: device sdf
operational as raid disk 9
May 12 07:40:19 server-pc kernel: [   11.049715] md/raid:md127: device sdb
operational as raid disk 2
May 12 07:40:19 server-pc kernel: [   11.049716] md/raid:md127: device sdd
operational as raid disk 6
May 12 07:40:19 server-pc kernel: [   11.049716] md/raid:md127: device sde
operational as raid disk 10
May 12 07:40:19 server-pc kernel: [   11.049716] md/raid:md127: device sdc
operational as raid disk 5
May 12 07:40:19 server-pc kernel: [   11.050101] md/raid:md127: raid level
6 active with 14 out of 14 devices, algorithm 2
May 12 07:40:19 server-pc kernel: [   11.078716] md127: detected capacity
change from 0 to 48007829520384

Now, booting with 4.19.0-8 kernel (raid IS mounted). I don't get the
error about 'md0.device timing out' and notice how now, the array is called
md0?

May 12 07:42:08 server-pc kernel: [   10.874912] md/raid:md0: device sdh
operational as raid disk 3
May 12 07:42:08 server-pc kernel: [   10.874912] md/raid:md0: device sdj
operational as raid disk 8
May 12 07:42:08 server-pc kernel: [   10.874912] md/raid:md0: device sdl
operational as raid disk 4
May 12 07:42:08 server-pc kernel: [   10.874913] md/raid:md0: device sdb
operational as raid disk 2
May 12 07:42:08 server-pc kernel: [   10.874913] md/raid:md0: device sdf
operational as raid disk 9
May 12 07:42:08 server-pc kernel: [   10.874913] md/raid:md0: device sdc
operational as raid disk 5
May 12 07:42:08 server-pc kernel: [   10.874914] md/raid:md0: device sde
operational as raid disk 10
May 12 07:42:08 server-pc kernel: [   10.874914] md/raid:md0: device sdd
operational as raid disk 6
May 12 07:42:08 server-pc kernel: [   10.874914] md/raid:md0: device sdg
operational as raid disk 1
May 12 07:42:08 server-pc kernel: [   10.874915] md/raid:md0: device sdk
operational as raid disk 0
May 12 07:42:08 server-pc kernel: [   10.874915] md/raid:md0: device sdi
operational as raid disk 7
May 12 07:42:08 server-pc kernel: [   10.874915] md/raid:md0: device sda
operational as raid disk 11
May 12 07:42:08 server-pc kernel: [   10.874915] md/raid:md0: device sdn
operational as raid disk 13
May 12 07:42:08 server-pc kernel: [   10.874916] md/raid:md0: device sdo
operational as raid disk 12
May 12 07:42:08 server-pc kernel: [   10.875303] md/raid:md0: raid level 6
active with 14 out of 14 devices, algorithm 2
May 12 07:42:08 server-pc kernel: [   10.907815] md0: detected capacity
change from 0 to 48007829520384

I'm fairly certain my array has always been md0. I guess that name change
(from md127 to md0) is responsible for the failure?

Why is the -9 kernel trying to assemble my array as md127 while -8 uses the
correct name (md0)?

Bug#960390: x86_64: No serial port output

[Punit Agrawal]

[ cc'ing Alper ]

john doe  writes:

[...]

> The below command get me directly to the language selection screen which
> I belaeve is what you want?:
>
> qemu-system-x86_64 -drive file=debian.img,format=raw -m 1024 -boot d
> -nographic -cdrom debian-bullseye-DI-alpha2-amd64-netinst.iso -kernel
> vmlinuz  -append "console=ttyS0,115200n8 DEBIAN_FRONTEND=text" -initrd
> initrd.gz

Thanks for the qemu command line. Using the extracted kernel and initrd,
this was able to launch the installer in text mode.

Incidentally, this does not work if '-m 1024' is missing. Kernel boot
fails to find 'init'. I suspect that the Qemu default RAM configuration
is not sufficient to unpack the initrd.

Based on this, updated version of Alper's instructions now launch the DI
without the need to extract the kernel / initrd.

$ qemu-system-x86_64 -cdrom *.iso -nographic -vga none -m 1024

Edit the 'Install' option (by removing 'quiet' and 'vga=788') into:

/install.amd/vmlinuz initrd=/install.amd/initrd.gz --- console=ttyS0

Bug#960390: x86_64: No serial port output

[Punit Agrawal]

Alper Nebi Yasak  writes:

> On 12/05/2020 13:02, Punit Agrawal wrote:
>> The above parameters do not launch the installer from the iso here. I am
>> not quite sure what the right arguments are. I wonder if
>> "root=" to the kernel will do the trick. Will give that a
>> try.
>
> When I try:
>
> $ qemu-system-x86_64 -cdrom *.iso -nographic -vga none
>
> My terminal turns into a GRUB boot menu, where I can edit the
> 'Install' option (by removing 'quiet' and 'vga=788') into:
>
> /install.amd/vmlinuz initrd=/install.amd/initrd.gz --- console=ttyS0
>
> Which gets me booting kernel messages, can you try that?

Following the above steps, the VM picks up the DI kernel and I can see
the kernel boot logs on the console.

> (Booting still fails with a "Failed to execute /init (error -2)" in my
> case, but that'd be a separate bug if it's not a problem with my
> setup.)

I see the failure to find init as well.

Bug#960397: RFS: oxygencursors/0.0.2012-06-kde4.8-3 [QA] [RC] -- Oxygen mouse cursor theme

[Christian Göttsche]

Am Di., 12. Mai 2020 um 14:46 Uhr schrieb Adam Borowski :
> Alas, it fails to build:
>
> libpng error: Read Error
> /usr/bin/xcursorgen: PNG error while reading 180/pencil.png
> Background RRGGBBAA: ff00
> Area 0:0:32:32 exported to 60 x 60 pixels (180 dpi)
> Background RRGGBBAA: ff00
> Area 0:0:24:24 exported to 45 x 45 pixels (180 dpi)
> make[3]: *** [theme-yellow/CMakeFiles/theme-yellow.dir/build.make:203: 
> oxy-yellow/cursors/pencil] Error 1
> make[3]: *** Deleting file 'oxy-yellow/cursors/pencil'
> make[3]: *** Waiting for unfinished jobs
>
> I haven't investigated the fail, but as "Read Error" could be platform
> related, I tried on three different machines (2×amd64, 1×arm64) -- same.
>

Thanks for catching this.
It seems with bare cmake `add_custom_command`'s, they might get called
multiple times to generate the specified output. [1]
(So a subsequent generation might conflict with the concurrent usage
of the file.)
So I added a patch introducing custom targets.

> Also: why would you move the section?  This is a properly made theme that
> works with any WM/DE, not just KDE.  I don't know KDE team's policies,
> though, thus this is not a hard request -- feel free to ignore.

My bad, I though section x11 being for xserver related things (but
these cursors also work on wayland), but even weston is in the x11
category; reverted.

[1]: 
https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/⠀⠀

Bug#956543: freecad: FTBFS with new opencascade 7.4 (library transition)

[Gregor Riepl]

> Status update why this package has not yet been updated:
> If the freecad is rebuilt against pyside2, it will run
> into 945376 at runtime, namely when opening the PartDesign workbench.
> As this is a major feature in freecad and the current version in
> sid works its better to wait until pyside2 has been fixed.

945376 got a fix in experimental now.

freecad is currently not co-installable with kicad, because the latter
was already transitioned to opencascade 7.4.

Would you consider a fixed freecad upload to experimental as well? That
way, the pyside2 bugfix could be tested with an updated freecad build.

> For that, several QT dependencies pyside have to be updted:
> - qtdatavis3d-everywhere-src
> - qtscxml-everywhere-src
> - qtspeech-opensource-src
> - qtxmlpatterns-opensource-src
> 
> Bugs have been filed against those package, they should block this bug.

I didn't see any bug reports on these packages, is there still work to
be done on them?

Bug#947568: mixxx: diff for NMU version 2.2.3~dfsg-1.1

[Stefano Rivera]

Control: tags 947568 + patch

Dear maintainer,

It looks like the relevant upstream patch is
https://github.com/mixxxdj/mixxx/pull/2201/commits/03fad27e1f0f18ec83c9a4bc5f03f28948cd44fb

I've prepared an NMU for mixxx (versioned as 2.2.3~dfsg-1.1). The diff
is attached to this message.

Regards.

SR
diff -Nru mixxx-2.2.3~dfsg/debian/changelog mixxx-2.2.3~dfsg/debian/changelog
--- mixxx-2.2.3~dfsg/debian/changelog	2020-01-10 13:33:58.0 -0800
+++ mixxx-2.2.3~dfsg/debian/changelog	2020-05-12 16:07:23.0 -0700
@@ -1,3 +1,11 @@
+mixxx (2.2.3~dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick an upstream patch to fix a FTBFS with Scons under Python 3.
+(Closes: #947568)
+
+ -- Stefano Rivera   Tue, 12 May 2020 16:07:23 -0700
+
 mixxx (2.2.3~dfsg-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru mixxx-2.2.3~dfsg/debian/patches/0005-scons-3.patch mixxx-2.2.3~dfsg/debian/patches/0005-scons-3.patch
--- mixxx-2.2.3~dfsg/debian/patches/0005-scons-3.patch	1969-12-31 16:00:00.0 -0800
+++ mixxx-2.2.3~dfsg/debian/patches/0005-scons-3.patch	2020-05-12 16:06:52.0 -0700
@@ -0,0 +1,21 @@
+Description: Build correctly under scons on Python 3
+Bug-Upstream: https://bugs.launchpad.net/mixxx/+bug/1817742
+Bug-Debian: https://bugs.debian.org/947568
+Author: Jan Holthuis 
+Origin: upstream, https://github.com/mixxxdj/mixxx/pull/2201/commits/03fad27e1f0f18ec83c9a4bc5f03f28948cd44fb
+
+--- a/build/depends.py
 b/build/depends.py
+@@ -1285,7 +1285,11 @@
+ 'preferences/dialog/dlgprefvinyldlg.ui',
+ 'preferences/dialog/dlgprefwaveformdlg.ui',
+ ]
+-map(Qt.uic(build), ui_files)
++
++# In Python 3.x, map() returns a "map object" (instead of a list),
++# which is evaluated on-demand rather than at once. To invoke uic
++# for all *.ui files at once, we need to cast it to a list here.
++list(map(Qt.uic(build), ui_files))
+ 
+ if build.platform_is_windows:
+ # Add Windows resource file with icons and such
diff -Nru mixxx-2.2.3~dfsg/debian/patches/series mixxx-2.2.3~dfsg/debian/patches/series
--- mixxx-2.2.3~dfsg/debian/patches/series	2020-01-10 13:32:29.0 -0800
+++ mixxx-2.2.3~dfsg/debian/patches/series	2020-05-12 15:56:06.0 -0700
@@ -2,3 +2,4 @@
 0002-desktop_file.patch
 0003-soundtouch.patch
 0004-remove_inappropriate_arm_flags.patch
+0005-scons-3.patch

Bug#952868: OpenSSL linking without license exception

[Bastian Germann]

Am 11.05.20 um 09:05 schrieb Rhonda D'Vine:
> Without libssl-dev installed in
> the building chroot this fails for me.  Can you revisit this, and check
> where you might have missed something?

Try this new patch version. It is tested to compile without libssl-dev
installed.
>From 5a04599fa6d10e34df6695bb21adb352f8a1dd7d Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Sun, 1 Mar 2020 11:19:53 +0100
Subject: [PATCH] Replace OpenSSL with wolfSSL

---
 debian/control  |  2 +-
 debian/control.in   |  2 +-
 debian/patches/01wolfssl-crypto | 16 
 debian/patches/04omit-ssleay| 20 
 debian/patches/series   |  2 ++
 debian/rules|  2 +-
 6 files changed, 41 insertions(+), 3 deletions(-)
 create mode 100644 debian/patches/01wolfssl-crypto
 create mode 100644 debian/patches/04omit-ssleay

diff --git a/debian/control b/debian/control
index 5e35ef9..1d650a0 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends: debhelper (>= 11~), libsdl2-image-dev (>= 2.0.0),
   libboost-iostreams-dev, libboost-test-dev, libboost-regex-dev,
   libboost-serialization-dev, libboost-system-dev, libboost-thread-dev,
   libboost-program-options-dev, libboost-filesystem-dev, libboost-locale-dev,
-  libboost-random-dev, libpng-dev, libreadline-dev, libssl-dev,
+  libboost-random-dev, libpng-dev, libreadline-dev, libwolfssl-dev,
   libpango1.0-dev, libvorbis-dev, cmake (>= 2.6)
 Standards-Version: 4.1.4
 Uploaders: Rhonda D'Vine ,
diff --git a/debian/control.in b/debian/control.in
index f97ece5..b57f2df 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -8,7 +8,7 @@ Build-Depends: debhelper (>= 11~), libsdl2-image-dev (>= 2.0.0),
   libboost-iostreams-dev, libboost-test-dev, libboost-regex-dev,
   libboost-serialization-dev, libboost-system-dev, libboost-thread-dev,
   libboost-program-options-dev, libboost-filesystem-dev, libboost-locale-dev,
-  libboost-random-dev, libpng-dev, libreadline-dev, libssl-dev,
+  libboost-random-dev, libpng-dev, libreadline-dev, libwolfssl-dev,
   libpango1.0-dev, libvorbis-dev, cmake (>= 2.6)
 Standards-Version: 4.1.4
 Uploaders: Rhonda D'Vine ,
diff --git a/debian/patches/01wolfssl-crypto b/debian/patches/01wolfssl-crypto
new file mode 100644
index 000..4b3fa74
--- /dev/null
+++ b/debian/patches/01wolfssl-crypto
@@ -0,0 +1,16 @@
+Author: Bastian Germann   vim:ft=diff:
+Description: Link with wolfssl instead of libcrypto.
+
+--- a/cmake/FindCrypto.cmake
 b/cmake/FindCrypto.cmake
+@@ -1,8 +1,8 @@
+ # OpenSSL crypto library
+ 
+-find_path(CRYPTO_INCLUDE_DIR openssl/md5.h)
++find_path(CRYPTO_INCLUDE_DIR openssl/md5.h /usr/include/wolfssl)
+ 
+-find_library(CRYPTO_LIBRARY crypto)
++find_library(CRYPTO_LIBRARY wolfssl)
+ 
+ # handle the QUIETLY and REQUIRED arguments and set XXX_FOUND to TRUE if all listed variables are TRUE
+ INCLUDE(FindPackageHandleStandardArgs)
diff --git a/debian/patches/04omit-ssleay b/debian/patches/04omit-ssleay
new file mode 100644
index 000..213a253
--- /dev/null
+++ b/debian/patches/04omit-ssleay
@@ -0,0 +1,20 @@
+Author: Bastian Germann   vim:ft=diff:
+Description: Omit SSLeay call which has linking problems.
+
+diff --git a/src/build_info.cpp b/src/build_info.cpp
+index 263841e..ef61201 100644
+--- a/src/build_info.cpp
 b/src/build_info.cpp
+@@ -239,12 +239,6 @@ version_table_manager::version_table_manager()
+ 	// OpenSSL/libcrypto
+ 	//
+ 
+-#ifndef __APPLE__
+-	compiled[LIB_CRYPTO] = format_openssl_version(OPENSSL_VERSION_NUMBER);
+-	linked[LIB_CRYPTO] = format_openssl_version(SSLeay());
+-	names[LIB_CRYPTO] = "OpenSSL/libcrypto";
+-#endif
+-
+ 	//
+ 	// Cairo
+ 	//
diff --git a/debian/patches/series b/debian/patches/series
index 57b6465..f08ba3d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,4 @@
+01wolfssl-crypto
 02wesnoth-nolog-desktop-file
 03wesnothd-name
+04omit-ssleay
diff --git a/debian/rules b/debian/rules
index 02ad407..cbec12c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,7 +23,7 @@ ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
 CXXFLAGSDBG = -g1
 endif
 
-export CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS)
+export CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) -I/usr/include/wolfssl -DOPENSSL_ALL
 export CFLAGS   := $(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS) -std=c++11 -fopenmp
 export CXXFLAGS := $(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS) -std=c++11 -fopenmp  $(CXXFLAGSDBG)
 export LDFLAGS  := $(shell dpkg-buildflags --get LDFLAGS)
-- 
2.26.2

Bug#947732: Same issue with dual-boot Fedora 32 and Ubuntu 20.04

[Richard Fearn]

As Fedora 32 uses Boot Loader Specification
(https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault),
linux-boot-prober on Ubuntu 20.04 finds Fedora 32 kernels via the
90fallback script (/usr/lib/linux-boot-probes/mounted/90fallback),
which just looks for kernel files on the filesystem:

$ sudo linux-boot-prober /dev/sde5
/dev/sde5:/dev/sde2::/boot/vmlinuz-0-rescue-7e584188f72b459891f83e6cd7f7b49b:/boot/initramfs-0-rescue-7e584188f72b459891f83e6cd7f7b49b.img:root=/dev/sde5
/dev/sde5:/dev/sde2::/boot/vmlinuz-5.6.11-300.fc32.x86_64:/boot/initramfs-5.6.11-300.fc32.x86_64.img:root=/dev/sde5
/dev/sde5:/dev/sde2::/boot/vmlinuz-5.6.6-300.fc32.x86_64:/boot/initramfs-5.6.6-300.fc32.x86_64.img:root=/dev/sde5

As these are found in alphabetical order, the rescue kernel comes
first, and is used for the main "Fedora 32 (Workstation Edition)"
entry. Then each of the three kernels found by 90fallback gets its own
menu entry in the "Advanced options for Fedora 32" submenu.

The Fedora entries in Fedora's own grub menu are created by the
`blscfg` command. The blscfg module
(https://src.fedoraproject.org/rpms/grub2/blob/master/f/0027-blscfg-add-blscfg-module-to-parse-Boot-Loader-Specif.patch)
reads files in /boot/loader/entries, and sorts the kernels properly by
version.

As Ubuntu 20.04 doesn't use BLS, it creates a menu entry for each
Ubuntu kernel in the Ubuntu grub config, which Fedora can find (via
the 40grub2 script) when it updates its own Fedora grub config.

Presumably neither grub nor os-prober on Debian/Ubuntu have BLS
support, so they don't handle the Fedora BLS files either (a) when
grub runs, or (b) when update-grub updates the Ubuntu grub config. So
the only way Fedora kernels will appear in the Ubuntu grub menu is via
that 90fallback script, which puts them in alphabetical order.

-- 
Richard Fearn
richardfe...@gmail.com

Bug#907343: Same issue with dual-boot Fedora 32 and Ubuntu 20.04

[Richard Fearn]

As Fedora 32 uses Boot Loader Specification
(https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault),
linux-boot-prober on Ubuntu 20.04 finds Fedora 32 kernels via the
90fallback script (/usr/lib/linux-boot-probes/mounted/90fallback),
which just looks for kernel files on the filesystem:

$ sudo linux-boot-prober /dev/sde5
/dev/sde5:/dev/sde2::/boot/vmlinuz-0-rescue-7e584188f72b459891f83e6cd7f7b49b:/boot/initramfs-0-rescue-7e584188f72b459891f83e6cd7f7b49b.img:root=/dev/sde5
/dev/sde5:/dev/sde2::/boot/vmlinuz-5.6.11-300.fc32.x86_64:/boot/initramfs-5.6.11-300.fc32.x86_64.img:root=/dev/sde5
/dev/sde5:/dev/sde2::/boot/vmlinuz-5.6.6-300.fc32.x86_64:/boot/initramfs-5.6.6-300.fc32.x86_64.img:root=/dev/sde5

As these are found in alphabetical order, the rescue kernel comes
first, and is used for the main "Fedora 32 (Workstation Edition)"
entry. Then each of the three kernels found by 90fallback gets its own
menu entry in the "Advanced options for Fedora 32" submenu.

The Fedora entries in Fedora's own grub menu are created by the
`blscfg` command. The blscfg module
(https://src.fedoraproject.org/rpms/grub2/blob/master/f/0027-blscfg-add-blscfg-module-to-parse-Boot-Loader-Specif.patch)
reads files in /boot/loader/entries, and sorts the kernels properly by
version.

As Ubuntu 20.04 doesn't use BLS, it creates a menu entry for each
Ubuntu kernel in the Ubuntu grub config, which Fedora can find (via
the 40grub2 script) when it updates its own Fedora grub config.

Presumably neither grub nor os-prober on Debian/Ubuntu have BLS
support, so they don't handle the Fedora BLS files either (a) when
grub runs, or (b) when update-grub updates the Ubuntu grub config. So
the only way Fedora kernels will appear in the Ubuntu grub menu is via
that 90fallback script, which puts them in alphabetical order.

--
Richard Fearn
richardfe...@gmail.com

Bug#958793: [20200425] kartolo.sby.datautama.net.id: syncscript

[Nurdiansyah Prahutama]

Hi Julien,


sync script already uses ftpsync, please check again.

Regards,

Nurdiansyah Prahutama



- Original Message -
From: "Julien Cristau" 
To: sub...@bugs.debian.org
Sent: Saturday, April 25, 2020 6:46:44 PM
Subject: Bug#958793: [20200425] kartolo.sby.datautama.net.id: syncscript

Package: mirrors
X-Debbugs-Cc: mirrors-admin 

Hi,

I was checking some things in the Debian mirror universe and noticed
a problem with your mirror:

o trace file:
  I notice there is no tracefile matching your site name 
kartolo.sby.datautama.net.id in
  http://kartolo.sby.datautama.net.id/debian/project/trace/

  Please use our ftpsync script to mirror Debian.

  It should produce the trace files we require, and do the mirroring in a way
  that ensures the mirror is in a consistent state even during updates.

  
http://kartolo.sby.datautama.net.id/debian/project/ftpsync/ftpsync-current.tar.gz

Thanks,
Julien

Bug#960466: fonts-mathematica: does not download

[Francesco Potortì]

Package: fonts-mathematica
Version: 21
Severity: important

the installation script hits a page not found error while downloading
fonts from Wolfram

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=C:en_GB:en:en_US:it:fr:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fonts-mathematica depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  unzip  6.0-25
ii  wget   1.20.3-1+b2

fonts-mathematica recommends no packages.

fonts-mathematica suggests no packages.

-- debconf information:
  mathematica-fonts/http_proxy:
* mathematica-fonts/accept_license: true
* mathematica-fonts/license:

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Mike Hommey]

On Wed, May 13, 2020 at 12:23:55AM +0200, Francesco Poli wrote:
> On Wed, 13 May 2020 06:35:33 +0900 Mike Hommey wrote:
> 
> > On Tue, May 12, 2020 at 06:37:00PM +0200, Francesco Poli wrote:
> [...]
> > > debian/control includes
> > > 
> > >   Build-Depends: [...]
> > >  libvpx-dev (>= 1.5.0),
> > >  [...]
> > >   Build-Conflicts: [...]
> > >libvpx-dev (>= 1.8.0),
> > >[...]
> > 
> > No it doesn't. It only does if you take the backport for stable or
> > older.
> > 
> > Or if this condition doesn't hold:
> > ifneq (,$(filter testing% bullseye% unstable sid,$(DEB_DISTRIBUTION)))
> > 
> > (where DEB_DISTRIBUTION comes from /usr/share/dpkg/pkg-info.mk)
> 
> Could you please elaborate?
> 
> 
> As I said, I used dget to obtain the unpacked source package.
> In the unpacked source tree, I see a debian/control file with the above
> mentioned content.

If I dget 
https://snapshot.debian.org/archive/debian/20200408T025735Z/pool/main/f/firefox-esr/firefox-esr_68.7.0esr-1.dsc,
 I get a debian/control that doesn't contain anything about libvpx. 
debian/control.in does, but that should be irrelevant.

Mike

Bug#948214: barriers sometimes runs with high load and use all memory

[Unit 193]

Howdy,

One pull request upstream that's likely worth a shot was merged[0] back in Feb 
and is referenced from several issues relating to memory and CPU usage.  If you 
do check to see if that matches your issue, and solves it, I'd like to hear the 
results.



[0]: https://github.com/debauchee/barrier/pull/557

~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

On Mon, 20 Jan 2020, Jörg Frings-Fürst wrote:


tag 948214 - moreinfo
thanks


Hello,


Am Samstag, den 18.01.2020, 00:51 -0500 schrieb Unit 193:

severity -1 normal , tag -1 moreinfo unreproducible
thanks

Howdy,


some times the prozess barriers run with high load and use all
memory:


Can you be a little more precise as to how we can reproduce
this?  Perhaps some
config, commandline options, state of machines in question,
etc?  There may be
log output in ~/.xsession-errors as well.



It is not obvious to me which trigger is used to trigger the error.
Sometimes the error occurs after 15 minutes, sometimes only after more
than 20 hours.

The conf-file and xsession-errors ist attached.

Bug#959481: alpine: does not connect with TLS to smtp/imap server

[Unit 193]

Howdy,

I noticed that your initial report claims that you're running buster, but the 
version you are comparing the buster backport to is from oldstable.  This means 
that rather than linking against the same version of openssl, the older version 
of alpine you're running is linked against openssl1.0 which is no longer in 
Debian.


If you really are on buster, can you also try alpine 2.21 from the buster repos? 
One larger change with buster was that openssl changed the default minimum TLS 
version from TLSv1 to TLSv1.2.  For full information see 
/usr/share/doc/libssl1.1/NEWS.Debian.gz



~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

On Mon, 11 May 2020, Eduardo Chappa wrote:


On Mon, 11 May 2020, Βασίλειος A. Ζοῦκος wrote:


Thanks for the informative responses.
More information on the subject:
1. The variable Encryption Protocol Range  appears only in alpine
ver. 2.22 with the assignment:
Encryption Protocol Range  = 


Yes, and since you have not modified it, nor Debian did, that means that your 
version of Alpine supports all the encryption protocols supported by the 
underlying version of openssl.


Now it is the job of the Debian maintainer to investigate which protocols 
were used to compile each of the versions of Openssl that were used to link 
against each version of Alpine.


Let us wait for that report, and we can figure out what the next action will 
be.


~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Wed, 13 May 2020 06:35:33 +0900 Mike Hommey wrote:

> On Tue, May 12, 2020 at 06:37:00PM +0200, Francesco Poli wrote:
[...]
> > debian/control includes
> > 
> >   Build-Depends: [...]
> >  libvpx-dev (>= 1.5.0),
> >  [...]
> >   Build-Conflicts: [...]
> >libvpx-dev (>= 1.8.0),
> >[...]
> 
> No it doesn't. It only does if you take the backport for stable or
> older.
> 
> Or if this condition doesn't hold:
> ifneq (,$(filter testing% bullseye% unstable sid,$(DEB_DISTRIBUTION)))
> 
> (where DEB_DISTRIBUTION comes from /usr/share/dpkg/pkg-info.mk)

Could you please elaborate?


As I said, I used dget to obtain the unpacked source package.
In the unpacked source tree, I see a debian/control file with the above
mentioned content.

If I issue my usual

  $ pdebuild --configfile ~/.pbuilder/sid.conf

command, pbuilder uses my up-to-date sid chroot environment, parses
debian/control and attempts to satisfy the build dependencies.
But it doesn't install libvpx-dev.
I assume the reason is that the only version available in sid is >=
1.8.0 and thus in conflict...

And then, during the build process:

  [...]
  checking for vpx >= 1.7.0... no
  ERROR: Package vpx was not found in the pkg-config search path.
  ERROR: Perhaps you should add the directory containing `vpx.pc'
  ERROR: to the PKG_CONFIG_PATH environment variable
  ERROR: No package 'vpx' found
  make[1]: *** [debian/rules:243: stamps/configure-browser] Error 1
  [...]


Who is supposed to modify the debian/control file so that it doesn't
include the above mentioned conflict?

Please excuse my ignorance, but I thought debian/control files should
not be altered on the fly during the build process...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgplmBnhyEeRS.pgp
Description: PGP signature

Bug#953853: musl-tools: should it be Multi-Arch: foreign?

[Thorsten Glaser]

Helmut Grohne dixit:

>I think moving mksh-static to a separate binary package would be pretty
>much required for making it cross buildable.

I completely do not follow. Anything you’d want to do in a separate
binary package could be done in the same binary package.

>Do you have a practical need for it to be cross buildable?

No, not really, just found this in some Debian QA tool and wondered
about it; the inability to cross-build with musl seems to be the
only blocker. If not being able to cross-build mksh with musl isn’t
a problem for Debian, I don’t think investing more time into it is
worth it.

>all you want to backport to.

Hah hah hah… but I have branches anyway.

>Why do you want a different libc in the first place? What does musl give

Things, but that’s off-topic, and I’m not going there.

>your system. So I think the way to support musl and other libs is not
>the current "we package another libc under a glibc architecture", but
>properly porting Debian to another libc. Since the libc is part of the

That works for musl, which is a full, correct environment, but not so
much for dietlibc and especially klibc (which, for example, deliberately
doesn’t support using the FPU). mksh builds against all four, if found,
and then chooses the “best” one for /bin/mksh-static and lksh. (This
currently ends up being klibc on all systems with musl, even though musl
is more correct, since we’re aiming for compactness here.)


I’m taking from this discussion: let’s just not do anything.

Thanks,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Bug#960162: RFS: mgba/0.8.1+dfsg-1 -- Game Boy Advance emulator

[Boyuan Yang]

X-Debbugs-CC: r...@nardis.ca

Hi Ryan,

On Tue, 12 May 2020 12:30:16 -0700 Ryan Tandy  wrote:
> On Tue, May 12, 2020 at 09:22:23PM +0200, Tobias Frost wrote:
> >Hijacks are bad…
> >However there is the package salvaging process, please check if it is more
suitable:
> >
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> 
> Thanks for the pointer. I think "team upload" is a better description of 
> what I'm attempting, but it didn't seem quite accurate as I'm not (yet) 
> a member of the relevant team.
> 
> I will check with the games team to see what they prefer, and will 
> follow the salvaging process if that's best.

Thanks for your interest in the package. I'd suggest to start the Salvaging
process if

 * you are really interested in maintaining it
 * the package is suitable for Salvaging (see definitions in Developers
Reference)
 * no one has objection on salvaging in the Games Team

(Even though I'm in the Games Team, I'm speaking on behalf of myself this
time. This email copy is also sent to Sergio.)

-- 
Thanks,
Boyuan


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

Bug#960465: thunderbird: Xfce "preferred browser" setting ignored when AppArmor profile is enabled

[Daniel Gnoutcheff]

Package: thunderbird
Version: 1:68.8.0-1~deb10u1
Severity: minor

When running Thunderbird under Xfce with
/etc/apparmor.d/usr.bin.thunderbird enabled, Thunderbird always opens
URLs with sensible-browser, even if that is not the "preferred browser"
selected in Xfce's "Preferred Applications" settings panel
(exo-preferred-applications).  After `aa-disable /usr/bin/thunderbird`,
Thunderbird henceforth opens URLs in the right browser.

I suspect this is because the AppArmor profile prohibits exo-open (when
spawned by Thunderbird) from reading ~/.config/xfce4/helpers.rc, which
apparently is where Xfce keeps the user's application selections.  When
apparmor is enabled, opening a URL gives me this on Thunderbird's
stderr:

> (exo-helper-1:2307): libxfce4util-CRITICAL **: 17:43:07.428: Failed to parse 
> file /home/gnoutchd/.config/xfce4/helpers.rc, ignoring.

And I get this in the journal:

> May 12 17:43:07 tbirdtest audit[2307]: AVC apparmor="DENIED" operation="open" 
> profile="thunderbird" name="/home/gnoutchd/.config/xfce4/helpers.rc" pid=2307 
> comm="exo-helper-1" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> May 12 17:43:07 tbirdtest kernel: audit: type=1400 audit(1589319787.417:43): 
> apparmor="DENIED" operation="open" profile="thunderbird" 
> name="/home/gnoutchd/.config/xfce4/helpers.rc" pid=2307 comm="exo-helper-1" 
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000


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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libgtk2.0-0   2.24.32-3
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.42.4-8~deb10u1
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3+deb10u1
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
pn  lightning 

Versions of packages thunderbird suggests:
ii  apparmor  2.13.2-10
ii  fonts-lyx 2.3.2-1
ii  libgssapi-krb5-2  1.17-3

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#888705: abseil-cpp packaging

[Benjamin Barenblat]

On Thursday, May  7, 2020, at  6:32 PM +0200, László Böszörményi (GCS) wrote:
> If I understand correctly, you retained src:abseil. If not and using
> src:abseil-cpp then you need a new repository named after that. Which
> way should I go?

If it’s all right with you, I’d prefer to stick with src:abseil. That
more closely matches the way the terminology is used within Google –
“Abseil” is unambiguously the C++ project, and “Abseil Python” is its
Python counterpart.

Benjamin

Bug#960458: libreswan: CVE-2020-1763

[Salvatore Bonaccorso]

Hi!

Attached as well the debdiff as prepared for buster-security.

Regards,
Salvatore
diff -Nru libreswan-3.27/debian/changelog libreswan-3.27/debian/changelog
--- libreswan-3.27/debian/changelog 2019-06-11 00:04:05.0 +0200
+++ libreswan-3.27/debian/changelog 2020-05-12 22:59:59.0 +0200
@@ -1,3 +1,11 @@
+libreswan (3.27-6+deb10u1) buster-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * DoS attack via malicious IKEv1 informational exchange message
+(CVE-2020-1763) (Closes: #960458)
+
+ -- Salvatore Bonaccorso   Tue, 12 May 2020 22:59:59 +0200
+
 libreswan (3.27-6) unstable; urgency=medium
 
   * fix CVE-2019-10155 (closes: #930338)
diff -Nru 
libreswan-3.27/debian/patches/0009-security-Fix-for-CVE-2020-1763.patch 
libreswan-3.27/debian/patches/0009-security-Fix-for-CVE-2020-1763.patch
--- libreswan-3.27/debian/patches/0009-security-Fix-for-CVE-2020-1763.patch 
1970-01-01 01:00:00.0 +0100
+++ libreswan-3.27/debian/patches/0009-security-Fix-for-CVE-2020-1763.patch 
2020-05-12 22:59:59.0 +0200
@@ -0,0 +1,28 @@
+From: "D. Hugh Redelmeier" 
+Date: Thu, 19 Mar 2020 14:21:06 -0400
+Subject: security: Fix for CVE-2020-1763
+Origin: 
https://github.com/libreswan/libreswan/commit/471a3e41a449d7c753bc4edbba4239501bb62ba8
+Bug-Debian: https://bugs.debian.org/960458
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-1763
+
+pluto will crash on a null pointer dereference when trying to log an error
+for an IKEv1 packet containing bogus information and/or flags.
+
+Signed-off-by: Paul Wouters 
+[Salvatore Bonaccorso: Backport to 3.27 based on
+https://libreswan.org/security/CVE-2020-1763/CVE-2020-1763.txt advisory]
+---
+ programs/pluto/ikev1.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/programs/pluto/ikev1.c
 b/programs/pluto/ikev1.c
+@@ -2047,7 +2047,7 @@ void process_packet_tail(struct msg_dige
+   "%smessage ignored because it 
contains a payload type (%s) unexpected by state %s",
+   excuse,
+   enum_show(_payload_names, 
np),
+-  st->st_state_name);
++  (st == NULL) ? "" : 
st->st_state_name);
+   if (!md->encrypted) {
+   
SEND_NOTIFICATION(INVALID_PAYLOAD_TYPE);
+   }
diff -Nru libreswan-3.27/debian/patches/series 
libreswan-3.27/debian/patches/series
--- libreswan-3.27/debian/patches/series2019-06-11 00:04:05.0 
+0200
+++ libreswan-3.27/debian/patches/series2020-05-12 22:59:59.0 
+0200
@@ -6,3 +6,4 @@
 0006-sort-all-wildcarded-object-files-for-reproducibility.patch
 0007-libreswan-3.27-CVE-2019-12312.patch
 0008-Resolve-CVE-2019-10155-IKEv1-Informational-exchange-.patch
+0009-security-Fix-for-CVE-2020-1763.patch

Bug#960458: [PATCH] DoS attack via malicious IKEv1 informational exchange message (CVE-2020-1763)

[Salvatore Bonaccorso]

Closes: #960458
---
 .../0006-security-Fix-for-CVE-2020-1763.patch | 28 +++
 debian/patches/series |  1 +
 2 files changed, 29 insertions(+)
 create mode 100644 debian/patches/0006-security-Fix-for-CVE-2020-1763.patch

diff --git a/debian/patches/0006-security-Fix-for-CVE-2020-1763.patch 
b/debian/patches/0006-security-Fix-for-CVE-2020-1763.patch
new file mode 100644
index ..b689161b4500
--- /dev/null
+++ b/debian/patches/0006-security-Fix-for-CVE-2020-1763.patch
@@ -0,0 +1,28 @@
+From: "D. Hugh Redelmeier" 
+Date: Thu, 19 Mar 2020 14:21:06 -0400
+Subject: security: Fix for CVE-2020-1763
+Origin: 
https://github.com/libreswan/libreswan/commit/471a3e41a449d7c753bc4edbba4239501bb62ba8
+Bug-Debian: https://bugs.debian.org/960458
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-1763
+
+pluto will crash on a null pointer dereference when trying to log an error
+for an IKEv1 packet containing bogus information and/or flags.
+
+Signed-off-by: Paul Wouters 
+[Salvatore Bonaccorso: Backport to 3.29 based on
+https://libreswan.org/security/CVE-2020-1763/CVE-2020-1763.txt advisory]
+---
+ programs/pluto/ikev1.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/programs/pluto/ikev1.c
 b/programs/pluto/ikev1.c
+@@ -2160,7 +2160,7 @@ void process_packet_tail(struct msg_dige
+   "%smessage ignored because it 
contains a payload type (%s) unexpected by state %s",
+   excuse,
+   enum_show(_payload_names, 
np),
+-  st->st_state_name);
++  (st == NULL) ? "" : 
st->st_state_name);
+   if (!md->encrypted) {
+   
SEND_NOTIFICATION(INVALID_PAYLOAD_TYPE);
+   }
diff --git a/debian/patches/series b/debian/patches/series
index 223f63a60df1..34c732b58e44 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@
 0003-update-README.nss-to-match-debian-defaults-for-IPSEC.patch
 0004-move-to-python3-scripts-are-compatible.patch
 0005-minor-Fix-spelling-and-grammar.patch
+0006-security-Fix-for-CVE-2020-1763.patch
-- 
2.20.1

Bug#960464: RFP: datajoint -- a framework for scientific workflow management based on relational principles

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist

* Package name: datajoint-python
  Version : 0.12.5
  Upstream Author : DataJoint team
* URL : https://github.com/datajoint/datajoint-python
* License : LGPL-2
  Programming Lang: Python
  Description : a framework for scientific workflow management based on 
relational principles

DataJoint for Python is a framework for scientific workflow management based on
relational principles. DataJoint is built on the foundation of the relational
data model and prescribes a consistent method for organizing, populating,
computing, and querying data.

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Mike Hommey]

On Tue, May 12, 2020 at 06:37:00PM +0200, Francesco Poli wrote:
> On Tue, 12 May 2020 07:33:45 +0900 Mike Hommey wrote:
> 
> > On Tue, May 12, 2020 at 12:17:36AM +0200, Francesco Poli wrote:
> > > On Tue, 12 May 2020 06:55:00 +0900 Mike Hommey wrote:
> > > 
> > > > On Mon, May 11, 2020 at 11:34:39PM +0200, Francesco Poli wrote:
> > > [...]
> > > > > Yes, I downgraded firefox-esr and the bug vanished.
> > > > > This confirms that the issue is indeed caused by the new version of
> > > > > firefox-esr.
> > > > 
> > > > Or not. This could also be caused by some upgraded build dependency.
> > > 
> > > Well, that's another possibility, I agree...
> > > 
> > > > Do you have the resources to attempt rebuilding 68.7 against current
> > > > unstable?
> > > 
> > > I can try inside a pbuilder-managed sid chroot.
> > > 
> > > I issued the following command:
> > > 
> > >  $ dget 
> > > https://snapshot.debian.org/archive/debian/20200408T025735Z/pool/main/f/firefox-esr/firefox-esr_68.7.0esr-1.dsc
> > > 
> > > and obtained the unpacked source package.
> > > 
> > > Can you confirm that this the source I should attempt to build?
> > 
> > Sounds good.
> 
> Mmmmh...
> 
> debian/control includes
> 
>   Build-Depends: [...]
>  libvpx-dev (>= 1.5.0),
>  [...]
>   Build-Conflicts: [...]
>libvpx-dev (>= 1.8.0),
>[...]

No it doesn't. It only does if you take the backport for stable or
older.

Or if this condition doesn't hold:
ifneq (,$(filter testing% bullseye% unstable sid,$(DEB_DISTRIBUTION)))

(where DEB_DISTRIBUTION comes from /usr/share/dpkg/pkg-info.mk)

Mike

Bug#938108: [Pkg-xen-devel] Bug#938108: python-pyxenstore: Python2 removal in sid/bullseye

[Hans van Kranenburg]

On 5/9/20 9:57 PM, Moritz Mühlenhoff wrote:
> On Sat, May 09, 2020 at 02:36:24AM +0200, Thomas Goirand wrote:
>> On 5/8/20 9:35 PM, Moritz Mühlenhoff wrote:
>>> On Fri, Aug 30, 2019 at 07:45:40AM +, Matthias Klose wrote:
 Package: src:python-pyxenstore
 Version: 0.0.2-1
 Severity: normal
 Tags: sid bullseye
 User: debian-pyt...@lists.debian.org
 Usertags: py2removal

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

 Your package either build-depends, depends on Python2, or uses Python2
 in the autopkg tests.  Please stop using Python2, and fix this issue
 by one of the following actions.
>>>
>>> Hi,
>>> python-pyxenstore is dead upstream and there are no reverse deps, let's 
>>> remove?
>>>
>>> Cheers,
>>> Moritz
>>
>> By all means, yes, remove this.
>> I believe it is in Debian when I attempted to package XCP (aka: xen-api,
>> aka xen-server, etc.), and that's long gone from Debian.
> 
> Ack, I've just filed an RM bug.

(seeing it happening)

Also ACK from me.

A while ago this confused me because I initially thought this was a
binary package produced by src:xen, but it was not. At some point (I
think it was our latest IRL work together day of the Debian Xen team) I
realized that it really was not, and from that POV, I can confirm that
it is not used by anything in there.

Thanks,

Hans

Bug#959838: ITP: opencensus-java -- Stats collection and distributed tracing framework

[Andreas Tille]

Control: retitle -1 ITP: opencensus-java -- Stats collection and distributed 
tracing framework
Control: owner -1 Andreas Tille 
Control: tags -1 help

I've started packaging in

   https://salsa.debian.org/java-team/opencensus-java

to support bazel packaging.  Unfortunately I have no idea how to fix all
the (Build-)Depends of the gradle build.  I was following a hint given
on debian-java list to find out some dependency relations via

   gradle build --info

and added some of the modules I was able to detect from the gradle cache
but this did not helped much.  I would be happy if someone could lend a
helping hand since I have the feeling that my attempt looks a bit
fruitless.  The package is relevant to get bazel packaged which would
open the chance to package tensorflow which is used in several packages
that help fighting COVID-19 and thus is part of the Debian Med COVID-19
sprint.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#960463: mycli doesn't work the prompt-toolkit >= 3.0.0

[David Engel]

Package: mycli
Version: 1.21.1-1
Severity: important
Tags: patch

Dear Maintainer,

mycli version 1.21.1-1 claims to fix incompatibility with
prompt-toolkit 3.0 but that does not seem to be the case with my
system.  Using prompt-toolkit 3.0.5-2, I get the following traceback.

Traceback (most recent call last):
  File "/usr/bin/mycli", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3259, 
in 
def _initialize_master_working_set():
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3242, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3271, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 586, in 
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 599, in 
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 787, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'prompt_toolkit<3.0.0,>=2.0.6' 
distribution was not found and is required by mycli

To get it to work, I had to apply the following patch.

--- setup.py~   2020-05-12 16:01:55.0 -0500
+++ setup.py2020-05-12 16:10:54.314829760 -0500
@@ -19,7 +19,7 @@
 install_requirements = [
 'click >= 7.0',
 'Pygments >= 1.6',
-'prompt_toolkit>=2.0.6,<3.0.0',
+'prompt_toolkit>=2.0.6,<4.0.0',
 'PyMySQL >= 0.9.2',
 'sqlparse>=0.3.0,<0.4.0',
 'configobj >= 5.0.5',

This is an adaptation of upstream commit
08d56d8b479111641094f86d324f1ff232451b05.  This version preserves
compatibility with prompt-toolkit 2.x.

David Engel


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mycli depends on:
ii  python3 3.8.2-3
ii  python3-click   7.0-3
ii  python3-configobj   5.0.6-4
ii  python3-cryptography2.8-4
ii  python3-pkg-resources   46.1.3-1
ii  python3-prompt-toolkit  3.0.5-2
ii  python3-pygments2.3.1+dfsg-3
ii  python3-pymysql 0.9.3-2
ii  python3-sqlparse0.3.1-1
ii  python3-tabulate0.8.2-1.1
ii  python3-terminaltables  3.1.0-3

mycli recommends no packages.

mycli suggests no packages.

-- no debconf information

Bug#933180: Patch for #933180

[Steinar H. Gunderson]

On Mon, May 11, 2020 at 12:17:33AM +0100, Federico Ceratto wrote:
> Hello Steinar and thank you for the patch.
> The current package contains version 1.4.1, also there was already a
> branch on Salsa called "split" with ongoing work:
> https://salsa.debian.org/debian/libsrt/-/tree/split
> https://salsa.debian.org/debian/libsrt/-/jobs/729504

Thank you -- no need for me to NMU, then. Do you know approximately when a
new package will be uploaded to unstable (and presumably hit NEW)?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#960230: Info received (Bug#960230: thunderbird: Thunderbird doesn't run if DEBUG variable is exported)

[Carles Pina i Estany]

Hello Carsten,

On May/12/2020, Carsten Schoenert wrote:
> Hello Carles,
> 
> Am 12.05.20 um 14:39 schrieb Carles Pina i Estany:
> > 
> > Hi,
> > 
> > I've just seen that I in Salsa I forked it out from
> > https://salsa.debian.org/nitsch-guest/thunderbird instead of
> > https://salsa.debian.org/mozilla-team/thunderbird . I think that the two
> > files that I changed are the same, but tonight I could fork from the
> > mozilla-team/thunderbird (or prefix the variables/something else if it
> > was preferred).
> 
> just add a new remote source pointing to the "real" thunderbird tree on
> salsa and rebase against the trees from there.

I ended up doing a new fork (long story off-topic here :-) )
My previous code is in the same URL: 
https://salsa.debian.org/carlespina/thunderbird/-/tree/thunderbird-launcher-variables
The smallest patch would be here: 
https://salsa.debian.org/carlespina/thunderbird/-/tree/unsets-DEBUG-DEBUGGER 
(unless we went for renaming DEBUG/DEBUGGER to TB_DEBUG/TB_DEBUGGER).

> From a quick view ...
> The removal of the DEBUGGER stuff isn't something I'd do. The reason behind
> that is simple, there is vagrant out there that is doing a better job in
> showing the runtime state if you need to debug something. But we never did
> added that to the wrapper script, it's not an easy task. So in my eyes the
> removal of the these parts isn't desirable. For sure some more comments will
> help further looking people.

I haven't used vagrant and I don't know how the DEBUGGER variable would
be used in vagrant to show the runtime state. Either way, I understand
that for ESR it would be good to minimise changes, but me, as a casual
reader of the script it seems that DEBUGGER can be 1 only if DEBUG is
1 (by the option -g) making it not-useful...as it is now, of course!
(and making the last set of ifs harder to follow). I just got a bit
carried away yesterday.

I might have missed some code path and obviously future intentions :-)

I'm not sure what's the best way to fix the reported bug and/or if the
smallest patch is the way to go.

I'm happy to make other changes in the branch - my pleasure!

Cheers,

-- 
Carles Pina i Estany

Bug#960459: memcached/1.6.5-2 FTBFS on s390x

[Chris Lamb]

forwarded 960459 https://github.com/memcached/memcached/issues/660
thanks

Hi Lucas,

> The latest version of memcached (1.6.5-2) FTBFS on s390x:

Yes, I have raised it upstream last week:

  https://github.com/memcached/memcached/issues/660

(ETA "this week".)


Regards,

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

Bug#953853: musl-tools: should it be Multi-Arch: foreign?

[Helmut Grohne]

Hi Thorsten,

On Mon, Mar 16, 2020 at 10:49:29PM +, Thorsten Glaser wrote:
> Back to the original place where I saw this: so how do we make mksh
> cross-buildable/-bootstrappable?

I think moving mksh-static to a separate binary package would be pretty
much required for making it cross buildable. Do you have a practical
need for it to be cross buildable?

> For bootstrapping, we can remove the extra libcs, it will work with
> just glibc, although the package content will differ. Is there a
> standard build profile for that already, and which releases support
> that? debian/rules and everything it calls already handle absence
> of dietlibc, klibc, musl fine.

The build profile syntax is mostly recognized since jessie if I remember
correctly. So that should be pretty much compatible with all you want to
backport to.

> Question is also, should we even invest into making those libcs
> usable in a cross context?

I actually think we should, but a little different than you may imagine.
Why do you want a different libc in the first place? What does musl give
you that glibc doesn't? Maybe you say "musl is smaller". While that is
true, you only gain from that benefit if you actually remove glibc from
your system. So I think the way to support musl and other libs is not
the current "we package another libc under a glibc architecture", but
properly porting Debian to another libc. Since the libc is part of the
architecture triplet (e.g. x86_64-linux-GNU), using a different libc
requires a different architecture in my view.

In other words: Yes, by all means, make your package work for
architectures like musl-linux-any, but stay away from musl on a glibc
architecture. It's a pain like multilib. If you want mksh linked with
musl, add a musl architecture and install it from there.

Helmut

Bug#960461: nml FTBFS when built with the nocheck profile

[Helmut Grohne]

Source: nml
Version: 0.5.1-2
Severity: important
Tags: ftbfs patch

When building nml with the nocheck build profile, it fails to build due
to not finding the ply module. debian/control now contains wrong
 annotations. The modules really are required for building,
because setup.py imports nml.parser. Please remove the annotations.

Helmut
diff --minimal -Nru nml-0.5.1/debian/changelog nml-0.5.1/debian/changelog
--- nml-0.5.1/debian/changelog  2020-05-11 20:32:06.0 +0200
+++ nml-0.5.1/debian/changelog  2020-05-12 07:33:22.0 +0200
@@ -1,3 +1,10 @@
+nml (0.5.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix nocheck FTBFS: Remove erroneous  annotations. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 12 May 2020 07:33:22 +0200
+
 nml (0.5.1-2) unstable; urgency=medium
 
   * [2916256] Fix build with DEB_BUILD_OPTIONS=nocheck
diff --minimal -Nru nml-0.5.1/debian/control nml-0.5.1/debian/control
--- nml-0.5.1/debian/control2020-05-11 20:32:06.0 +0200
+++ nml-0.5.1/debian/control2020-05-12 07:33:22.0 +0200
@@ -4,8 +4,7 @@
 Maintainer: Matthijs Kooijman 
 Uploaders: Jordi Mallach 
 Build-Depends: debhelper (>= 12), dh-python, python3-all-dev:any, 
libpython3-all-dev, python3-setuptools,
-# For regression testing
- python3-ply , python3-pil 
+ python3-ply, python3-pil
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/openttd-team/nml
 Vcs-Git: https://salsa.debian.org/openttd-team/nml.git

Bug#960460: ITP: wys -- A daemon to bring up and take down PulseAudio loopbacks for phone call audio

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 

* Package name: wys
  Version : 0.1.7
  Upstream Author : Bob Ham 
* URL : https://source.puri.sm/Librem5/wys/
* License : GPL
  Programming Lang: C
  Description : A daemon to bring up and take down PulseAudio loopbacks for 
phone call audio

A daemon to bring up and take down PulseAudio loopbacks for phone call audio.
Wys was written to manage call audio in the Librem 5 phone with a
Gemalto PLS8.  It may be useful for other systems.
Wys is pronounced "weece" to rhyme with "fleece".

Packaging this software is aimed at improving Librem5 support in Debian.

Bug#960452: mount: Editing fstab in a valid way causes silent failure to mount

[John Goerzen]

On Tue, May 12 2020, Chris Hofstaedtler wrote:

Hi Chris,

> I must say this is a very generic report. To your points 1) and 2)
> I could ask "What did the kernel say at this time, esp. did it claim
> success?", to 3) and 4) I could say "There is also no documentation
> on interactions with other tools changing global system state, like
> reboot(1)".
> Now, none of these replies would be very helpful.

Sorry about that, Chris.  I have tried just now and, rather to my
surprise, have been unable to duplicate this in order to gather more
information.  I had assumed it would be fairly readily reproducible;
that is my mistake.

I can report to you that the kernel messages looked as if it had been
mounted; for instance:

May 11 20:48:46 tinwhistle kernel: [10011.916687] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: (null)
May 11 20:50:19 tinwhistle kernel: [10104.961413] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: errors=remount-ro
May 11 21:06:21 tinwhistle kernel: [11067.149192] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: errors=remount-ro
May 11 21:06:30 tinwhistle kernel: [11076.165431] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: errors=remount-ro
May 11 21:06:47 tinwhistle kernel: [11093.047456] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: (null)
May 11 21:07:14 tinwhistle kernel: [9.680451] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: (null)
May 11 21:07:30 tinwhistle kernel: [11135.623084] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: errors=remount-ro
May 11 21:07:56 tinwhistle kernel: [11161.524673] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: (null)
May 11 21:08:22 tinwhistle kernel: [11187.655296] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: (null)
May 11 21:09:05 tinwhistle kernel: [11231.262182] EXT4-fs (md0): mounted 
filesystem with ordered data mode. Opts: errors=remount-ro

I believed at the time that it was being -- at least to the kernel --
mounted briefly and then immediately unmounted again.

> - What exactly do you want to see changed, and what are your wording
>   suggestions?

Ideally it would just work.  Failing that, it would give a helpful error
message.  Failing that, a warning in the manpages.

Thanks, and sorry for the lack of detail.

John

Bug#960459: memcached/1.6.5-2 FTBFS on s390x

[Lucas Kanashiro]

Source: memcached
Version: 1.6.5-2
Severity: serious

Dear Maintainer,

The latest version of memcached (1.6.5-2) FTBFS on s390x:

https://buildd.debian.org/status/fetch.php?pkg=memcached=s390x=1.6.5-2=1587246609=0

This failure is blocking its migration to testing.

-- 
Lucas Kanashiro

Bug#757402: git: test suite fails on hppa, in run_with_limited_stack

[John David Anglin]

On 2020-05-12 3:39 a.m., Greg Price wrote:
> I think it would indeed be sensible to simply disable these test cases
> on hppa. Here's how the prereq for them is defined:
> """
> test_lazy_prereq ULIMIT_STACK_SIZE '
> test_have_prereq !MINGW,!CYGWIN &&
> run_with_limited_stack true
> '
> """
>
> So perhaps that `!MINGW,!CYGWIN` bit can be straightforwardly extended
> to skip these tests on hppa too. If somebody would like to find the
> right incantation to put there for hppa, and test that it works, then
> I think that may be enough to get the Git test suite passing again on
> hppa.
>
Git built successfully with the attached change.  There was a segv in one test 
run with
run_with_limited_cmdline, so I also disabled it.

Please install if okay.

Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

--- test-lib.sh.save2020-05-12 16:10:31.266922345 +
+++ test-lib.sh 2020-05-12 17:25:39.548716911 +
@@ -1461,6 +1461,12 @@
test_set_prereq EXECKEEPSPID
;;
 *)
+   uname_m=$(uname -m)
+   case $uname_m in
+   parisc*)
+   test_set_prereq HPPA
+   ;;
+   esac
test_set_prereq POSIXPERM
test_set_prereq BSLASHPSPEC
test_set_prereq EXECKEEPSPID
@@ -1606,7 +1612,7 @@
 }
 
 test_lazy_prereq CMDLINE_LIMIT '
-   test_have_prereq !MINGW,!CYGWIN &&
+   test_have_prereq !HPPA,!MINGW,!CYGWIN &&
run_with_limited_cmdline true
 '
 
@@ -1615,7 +1621,7 @@
 }
 
 test_lazy_prereq ULIMIT_STACK_SIZE '
-   test_have_prereq !MINGW,!CYGWIN &&
+   test_have_prereq !HPPA,!MINGW,!CYGWIN &&
run_with_limited_stack true
 '
 

Bug#959186: gssproxy: kerberos credentials not looked into the classical file

[rharwood]

Package: gssproxy
Followup-For: Bug #959186
Control: Close -1

Bug#960384: qutebrowser fails to start with critical qt message: Could not initialize GLX

[Nicolas Schier]

Hi Axel,

> > qutebrowser does not start on my arm64 machine (pinebook, a64) (but 
> > it does well, on my amd64 machine).
> 
> Interesting. I just tried it on Debian Sid armhf and it works there as
> well. Do you know if earlier versions of qutebrowser worked on your Pinebook?

I tried several version during the last months, but none of them had 
worked.

> I'll probably try to setup an arm64 Raspberry Pi to check if I can
> reproduce it. Then I might give some more guidance.

On my Rasperry Pi (w/ xpra as xserver) I get the same error message.

Thanks in advande and kind regards,
Nicolas


> Maybe Florian (upstream) has some suggestions and maybe arm64
> experiences, too.
> 
>   Regards, Axel
> -- 
>  ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

-- 
epost: nico...@fjasle.eu   irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --


signature.asc
Description: PGP signature

Bug#960458: libreswan: CVE-2020-1763

[Salvatore Bonaccorso]

Source: libreswan
Version: 3.29-2
Severity: important
Tags: security upstream
Control: found -1 3.27-6

Hi,

The following vulnerability was published for libreswan.

CVE-2020-1763[0]:
| An out-of-bounds buffer read flaw was found in the pluto daemon of
| libreswan from versions 3.27 till 3.31 where, an unauthenticated
| attacker could use this flaw to crash libreswan by sending specially-
| crafted IKEv1 Informational Exchange packets. The daemon respawns
| after the crash.


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-1763
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1763
[1] https://libreswan.org/security/CVE-2020-1763/CVE-2020-1763.txt

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#960457: ITP: busco -- benchmarking sets of universal single-copy orthologs

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: busco -- benchmarking sets of universal single-copy orthologs
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: busco
  Version : 4.0.6
  Upstream Author : Evgeny Zdobnov 
* URL : https://gitlab.com/ezlab/busco
* License : MIT
  Programming Lang: Python
  Description : benchmarking sets of universal single-copy orthologs
 Assessing genome assembly and annotation completeness with Benchmarking
 Universal Single-Copy Orthologs (BUSCO).
 .
  * Automated selection of lineages issued from https://www.orthodb.org/
  * Automated download of all necessary files and datasets to conduct a run
  * Use prodigal for non-eukaryotic genomes

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

Bug#960162: RFS: mgba/0.8.1+dfsg-1 -- Game Boy Advance emulator

[Ryan Tandy]

On Tue, May 12, 2020 at 09:22:23PM +0200, Tobias Frost wrote:

Hijacks are bad…
However there is the package salvaging process, please check if it is more 
suitable:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging


Thanks for the pointer. I think "team upload" is a better description of 
what I'm attempting, but it didn't seem quite accurate as I'm not (yet) 
a member of the relevant team.


I will check with the games team to see what they prefer, and will 
follow the salvaging process if that's best.


thanks,
Ryan

Bug#960162: RFS: mgba/0.8.1+dfsg-1 -- Game Boy Advance emulator

[Tobias Frost]

Hi Ryan,

On Sat, May 09, 2020 at 07:41:27PM -0700, Ryan Tandy wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> This is a package hijack

Hijacks are bad…
However there is the package salvaging process, please check if it is more 
suitable:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

-- 
tobi

Bug#959957: A quick fix for this bug

[Dmitry Ivanov]

Hi!

Here is a patch that fixes ctags invocation problem with the latest Kate.

Basically it reverts QProcess::start() call to its previous form which should 
be acceptable for Qt 5.12, 5.14.

A complete solution is more complicated - Kate should split a command line and 
provide ctags arguments to Qt library as a list (QStringList).
For me, this situation looks a little bit strange - now a part of library 
functionality which was available for quite a long time is moved from the 
library itself to an application using that library...



fix-ctags-command.patch
Description: Binary data

Bug#960452: mount: Editing fstab in a valid way causes silent failure to mount

[Chris Hofstaedtler]

Hi John,

thanks for your report, however...

* John Goerzen  [200512 20:24]:
> There are multiple issues reflected in this report:
> 
> 1) That mount failed to properly mount a filesystem;
> 
> 2) That it incorrectly said it had mounted it;
> 
> 3) That running systemctl daemon-reload fixed the issue;
> 
> 4) That neither the mount nor the fstab manpages mentioned this interaction

I must say this is a very generic report. To your points 1) and 2)
I could ask "What did the kernel say at this time, esp. did it claim
success?", to 3) and 4) I could say "There is also no documentation
on interactions with other tools changing global system state, like
reboot(1)".
Now, none of these replies would be very helpful.

I agree that generally requiring running "systemctl daemon-reload"
after changing /etc/fstab would be bad. However that doesn't appear
to be true in general.

- Do you have specific reproduction steps, strace output or
  similar debugging information? I would hope these would be helpful
  to decide if this is a mount, udev, or kernel issue.

- Does this still happen with 2.35.1-5?

- What exactly do you want to see changed, and what are your wording
  suggestions?


Thanks,
Chris

Bug#960456: qemu-system-x86: No window with VM output opened

[Paul Menzel]

Package: qemu-system-x86
Version: 1:5.0-4
Severity: normal

Dear Debian folks,


I believe after upgrading from QEMU 4.2 to 5.0, no window is opened by 
default to display the “VM output”. Only a VNC server seems to be 
started. I am using the GNOME DE and it doesn’t work with Wayland and X.


$ qemu-system-x86_64 -display help
Available display backend types:
none
egl-headless
curses
spice-app


Kind regards,

Paul

Bug#960455: src:syncthing: fails to migrate to testing for too long: FTBFS on mips64el

[Paul Gevers]

Source: syncthing
Version: 1.1.4~ds1-4
Severity: serious
Control: close -1 1.1.4~ds1-5
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM

[Stefan Lithén]

Package: chromium
Version: 80.0.3987.162-1~deb10u1
Severity: wishlist

Dear Maintainer,


When using Chromium and visiting websites that need DRM to be enabled, Chromium
automatically downloads and enables DRM.
These are binary blobs that are not free software.
No notification is made to the user that (s)he is now using non-free software.

If possible if would be great to have a switch in the settings for this (like
Firefox has).
Or at least that the user be showned a message that this website has made
chromium now using non-free software.



-- 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/6 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), 
LANGUAGE=sv_SE.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 chromium depends on:
ii  chromium-common  80.0.3987.162-1~deb10u1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libatomic1   8.3.0-6
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.4-1~deb10u1
ii  libavformat587:4.1.4-1~deb10u1
ii  libavutil56  7:4.1.4-1~deb10u1
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.2.10-6+deb10u3
ii  libdbus-1-3  1.12.16-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-2+deb10u1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6+deb10u1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1+deb10u2
ii  libopenjp2-7 2.3.0-2+deb10u1
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.36-6
ii  libpulse012.2-4+deb10u1
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.3.0-6
ii  libvpx5  1.7.0-3+deb10u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.2~deb10u1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  80.0.3987.162-1~deb10u1

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n80.0.3987.162-1~deb10u1
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1+deb10u1

Versions of packages chromium-common recommends:
ii  chromium-sandbox   80.0.3987.162-1~deb10u1
ii  fonts-liberation   1:1.07.4-9
ii  gnome-shell [notification-daemon]  3.30.2-11~deb10u1
ii  libgl1-mesa-dri18.3.6-2+deb10u1
ii  libu2f-udev1.1.9-1
ii  notification-daemon3.20.0-4
ii  upower 0.99.10-1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  8.3.0-6
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

-- no debconf information

Bug#960453: RM: python-pybedtools [armel armhf mipsel] -- ROM; Build-Dependencies unsatisfiable on armel, armhf and mipsel

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

as reported in bug #960411 python-pybedtools needs to be removed
for the said architectures.

Kind regards and thanks for working as ftpmaster

 Andreas.

Bug#960452: mount: Editing fstab in a valid way causes silent failure to mount

[John Goerzen]

Package: mount
Version: 2.33.1-0.1
Severity: important

There are multiple issues reflected in this report:

1) That mount failed to properly mount a filesystem;

2) That it incorrectly said it had mounted it;

3) That running systemctl daemon-reload fixed the issue;

4) That neither the mount nor the fstab manpages mentioned this interaction

I was recently migrating a server from LVM to md-raid.  In the
process, I made a new filesystem on /dev/md0, mounted it on /mnt, and
copied /boot over to it on /mnt.  I then unmounted /mnt and /boot,
edited fstab to reflect the new location, and tried to mount it on
/boot.

mount -v /boot responded:

mount: /dev/md0 mounted on /boot.

However, /boot was still empty.  df didn't show that it was mounted
there, neither did /proc/mounts.

These commands all produced similar results:

mount -v /dev/md0 /boot
mount -t ext4 /dev/md0 /boot

However, this worked fine:

mount -v /dev/md0 /mnt

In other words, I could mount /dev/md0 at any location on the system
EXCEPT /boot.  Any attempt to mount something at /boot would indicate
success but fail.

Eventually, on a lark, I tried systemctl daemon-reload.  After that,
it mounted fine.

Related information:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907536 requests
documentation of the systemctl daemon-reload in fstab, but does not
address the incorrect behavior of mount.

https://github.com/systemd/systemd/issues/7291 states that the "raw
util-linux commands still honour /etc/fstab directly", but that does
not appear to be the case.

Thanks,

John

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

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

Versions of packages mount depends on:
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-10
ii  libmount1  2.33.1-0.1
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.33.1-0.1
ii  util-linux 2.33.1-0.1

mount recommends no packages.

Versions of packages mount suggests:
ii  nfs-common  1:1.3.4-2.5

-- no debconf information

Bug#960436: [Pkg-opencl-devel] Bug#960436: pyopencl: test need unavailable module pygpu_ndarray

[Rebecca N. Palmer]

This is probably a reference to this part of the pyopencl source:

https://sources.debian.org/src/pyopencl/2019.1.1-1/pyopencl/compyte/ndarray/pygpu_ndarray.cpp/

I have manually run the tests before (while investigating #893050), but 
I don't know how beyond 'make tests'.

Bug#960451: meteo-qt: Cannot connect to server anymore: version≥1.5 is needed

[Pols12]

Package: meteo-qt
Version: 1.5-1
Severity: important

Dear Maintainer,

Because of changes in OpenWeatherMap API, meteo-qt is unusable. This has been
fixed upstream in v1.5 release.
See https://github.com/dglent/meteo-qt/issues/94

Is it possible to backport v1.5 or higher in Debian stable? Else, meteo-qt is
totally useless.

Thanks,
Pols12

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 meteo-qt depends on:
ii  python33.7.3-1
ii  python3-lxml   4.3.2-1
ii  python3-pyqt5  5.11.3+dfsg-1+b3
ii  python3-sip4.19.14+dfsg-2

Versions of packages meteo-qt recommends:
ii  meteo-qt-l10n  1.0.0-1

meteo-qt suggests no packages.

-- no debconf information

Bug#960450: ocl-icd: add support for OpenCL 3.0

[Andreas Beckmann]

Source: ocl-icd
Version: 2.2.12-4
Severity: wishlist

The OpenCL 3.0 standard was released recently. From a quick glance over
the headers, there seem to be 2 new functions:
  clCreateBufferWithProperties
  clCreateImageWithProperties

Andreas

Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects

[Kyle Edwards]

On Tue, 2020-05-12 at 14:35 +0300, Peter Pentchev wrote:
> Just a suggestion (somebody else already offered to sponsor the
> package):

Strange... I see the email in the debian-devel archives, but I never
received it. I wonder if it went to my spam folder. Thanks for the
heads up.

> could you take a look at Rules-Requires-Root in Policy 4.9.2
> and see if you couldn't set it in the Source control section?

Updated d/control with `Rules-Requires-Root: no`.

> Also, recent versions of debhelper introduced automatic handling of
> "--with something" if the dh-* package "Provides: dh-sequence-
> something"
> so that any packages that use it may build-depend (or B-D-I) on
> dh-sequence-something and debhelper will automatically assume "--with
> something", further simplifying the rules file.

Updated d/control to provide `dh-sequence-*`, and updated docs and
examples to suggest the modern approach.

Thanks!

Kyle

Bug#960449: openldap: fix backup directory naming for multiple reconfigure calls

[Andreas Hasenack]

Package: openldap
Version: 2.4.50+dfsg-1
Severity: normal

Dear Maintainer,

Hi,

this is currently part of the ubuntu delta and I checked to see if it
still makes sense. It looks like it does, as it fixes the following
scenario:
```
  Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.50+dfsg-1... done.
  Moving old database directory to /var/backups:

  Backup path /var/backups/unknown-2.4.50+dfsg-1.ldapdb exists. Giving up...
root@sid-slapd-reconfigure:~# echo $?
1
root@sid-slapd-reconfigure:~# ls -la /var/backups/
total 36
drwxr-xr-x  4 root root  4 May 11 14:21 .
drwxr-xr-x 11 root root 13 May  8 05:25 ..
drwx--  3 root root  3 May 11 14:21 slapd-2.4.50+dfsg-1
drwxr-xr-x  2 root root  4 May 11 14:21 unknown-2.4.50+dfsg-1.ldapdb
```
Install `slapd`, run `dpkg-reconfigure slapd` multiple times, and you
get the above.

With the change, you get this (shown in ubuntu):
```
root@groovy-slapd-reconfigure:~# ll /var/backups/
total 18
drwxr-xr-x  2 root root  2 May  6 12:25 ./
drwxr-xr-x 13 root root 15 May  8 11:42 ../
root@groovy-slapd-reconfigure:~# dpkg-reconfigure slapd
  Backing up /etc/ldap/slapd.d in
/var/backups/slapd-2.4.49+dfsg-2ubuntu1... done.
  Moving old database directory to /var/backups:
  - directory unknown... done.
  Creating initial configuration... done.
  Creating LDAP directory... done.
root@groovy-slapd-reconfigure:~# ll /var/backups/
total 36
drwxr-xr-x  4 root root  4 May 11 14:29 ./
drwxr-xr-x 13 root root 15 May  8 11:42 ../
drwx--  3 root root  3 May 11 14:29 slapd-2.4.49+dfsg-2ubuntu1/
drwxr-xr-x  2 root root  4 May 11 14:29 unknown-2.4.49+dfsg-2ubuntu1.ldapdb/
root@groovy-slapd-reconfigure:~# dpkg-reconfigure slapd
  Backing up /etc/ldap/slapd.d in
/var/backups/slapd-2.4.49+dfsg-2ubuntu1... done.
  Moving old database directory to /var/backups:
  - directory unknown... done.
  Creating initial configuration... done.
  Creating LDAP directory... done.
root@groovy-slapd-reconfigure:~# ll /var/backups/
total 61
drwxr-xr-x  5 root root  5 May 11 14:29 ./
drwxr-xr-x 13 root root 15 May  8 11:42 ../
drwx--  3 root root  3 May 11 14:29 slapd-2.4.49+dfsg-2ubuntu1/
drwxr-xr-x  2 root root  4 May 11 14:29 unknown-2.4.49+dfsg-2ubuntu1.ldapdb/
drwxr-xr-x  2 root root  4 May 11 14:29
unknown-2.4.49+dfsg-2ubuntu1.ldapdb-20200511-142930/
```

Bug#960434: ITP: varlink -- point-to-point IPC protocol and interface description format

[Jason Francis]

Package: wnpp
Severity: wishlist
Owner: Jason Francis 

* Package name: varlink
  Version : 19
  Upstream Author : Kay Sievers 
* URL : https://www.varlink.org/
* License : Apache-2.0
  Programming Lang: C
  Description : point-to-point IPC protocol and interface description
format

Varlink is an interface description format and protocol that aims to make
services accessible to both humans and machines in the simplest feasible way.

A varlink interface combines the classic UNIX command line options,
STDIN/OUT/ERROR text formats, man pages, service metadata and provides the
equivalent over a single file descriptor, a.k.a. “FD3”.

Varlink is plain-text, type-safe, discoverable, self-documenting, remotable,
testable, easy to debug. Varlink is accessible from any programming
environment.


---

Submission Notes:
Varlink is a small IPC protocol intended to be a very simple peer-to-peer
alternative to D-Bus. A minimal implementation has already been adopted by the
systemd project and integrated into their codebase; however I am submitting
this ITP in order to package the official C reference implementation that
includes a shared library and command line utility. Another package named
"kanshi" that I contribute to upstream is looking at using this library, and it
would be nice to have it ready in Debian for when a new version is published.
I'm not sure what package team this would fall under, but I've been testing
some Debian packaging already which is up on my github:
https://github.com/cyclopsian/libvarlink/tree/debian-19/debian

Bug#960302: imap retry must be tunable

[Matus UHLAR - fantomas]

Please,

for now, revert the patch from bug#947320 and try to post functionality
change to roundcube first.
Thanks.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows 2000: 640 MB ought to be enough for anybody

Bug#960448: openldap: Dynamically generate contact email

[Andreas Hasenack]

Package: openldap
Version: 2.4.50+dfsg-1
Severity: normal

Dear Maintainer,

slapd in debian sets the WHOWHERE value in d/p/set-maintainer-name to
"Debian OpenLDAP Maintainers
". It occurred to me that
in ubuntu we have that same value, which is incorrect. I propose a
dynamic way to set it:

--- a/debian/patches/set-maintainer-name
+++ b/debian/patches/set-maintainer-name
@@ -10,7 +10,7 @@
 -else
 -   WHOWHERE="$USER@$(uname -n):$(pwd)"
 -fi
-+WHOWHERE="Debian OpenLDAP Maintainers
"
++WHOWHERE="$(grep ^Maintainer: debian/control | sed 's,Maintainer: ,,')"

  cat << __EOF__
  /* This work is part of OpenLDAP Software .


This parses d/control to fetch the email address of the maintainer, so
it will be correct for both the Ubuntu and Debian packages. If you
prefer another way, like a conditional on ubuntu and debian, and use
hardcoded values instead of blindly taking whatever is in d/control,
let me know.

I looked for some tooling to parse d/control, but this simple parsing seems ok.

Bug#960262: parallel: Manpage recommends resources in non-free platforms (Youtube videos)

[Hörmetjan Yiltiz]

Thanks for the prompt response. youtube-dl could be a workaround. I'll try
to get in touch with upstream author and explore alternatives then. Thanks!

On Mon, May 11, 2020 at 2:15 PM Rogério Brito  wrote:

> On May 11 2020, hyiltiz wrote:
> > Package: parallel
> > Version: 20161222-1.1
> > Severity: minor
> >
> > A GNU Project software should not really recommend resources in non-free
> platforms that
> > require running non-free software (propriatery javascript).
> (...)
> > Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
> > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
>
> That's what the upstream author could use to host his instructional
> videos. I guess that there's no solution to this, unless the upstream
> author
> can upload those videos to other platform.
>
> If you don't want to have the proprietary javascript running on your
> system,
> you can download the instructional videos with youtube-dl (which I also
> maintain, BTW), which only parses the minimum of javascript to grab the
> needed information to download the videos.
>
> I guess that, in the absence of other solutions, this is a non-issue and
> I'm
> considering marking it as wontfix.
>
> Cheers,
>
> Rogério Brito.
>
>
>
> P.S.: Funny that you're talking about non-free stuff while you're using
> proprietary modules in your kernel. And that your message-id contains the
> string iPhone.  Your point about a GNU package still stands, though.
>
> --
> Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
> http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
> DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
>

Bug#960447: opendkim-tools: Man page option --restricted incorrect (opendkim-genkey)

[Paul Waring]

Package: opendkim-tools
Version: 2.11.0~alpha-12
Severity: normal

The man page for opendkim-genkey has the following option listed:

-r (--restricted) Restricts the key for use in e-mail signing only.
The default is to allow the key to be used for any service.

However, using the long form of this argument results in the following
output:

# opendkim-genkey --restricted
Unknown option: restricted
opendkim-genkey: usage: opendkim-genkey [options]
--append-domaininclude domain name in zone file stub
--bits=n   use n bits to generate the key
--directory=path   leave output in the named directory
--domain=name  generate data for the named domain [localhost]
--hash-algorithms=list limit to use of the named algorithm(s)
--help print help and exit
--note=string  include specified note in zone data
--restrict restrict key to email use only
--selector=nameselector name [default]
--subdomains   allow signing of subdomains
--testmode indicate key is in test mode
--verbose  increased output
--version  print version and exit

As suggested in the output, the correct long form is --restrict, and
that does work:

# opendkim-genkey --restrict -v
opendkim-genkey: generating private key
opendkim-genkey: private key written to default.private
opendkim-genkey: extracting public key
opendkim-genkey: DNS TXT record written to default.txt

The short form also works:

# opendkim-genkey -r -v
opendkim-genkey: generating private key
opendkim-genkey: private key written to default.private
opendkim-genkey: extracting public key
opendkim-genkey: DNS TXT record written to default.txt

So the problem is simply a typo in the man page, and the fix would be to
replace --restricted with --restrict.

-- 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/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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

Versions of packages opendkim-tools depends on:
ii  libbsd00.9.1-2
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libldap-2.4-2  2.4.47+dfsg-3+deb10u2
ii  liblua5.1-05.1.5-8.1+b2
ii  libmemcached11 1.0.18-4.2
ii  libmemcachedutil2  1.0.18-4.2
ii  libopendbx11.4.6-13+b1
ii  libopendkim11  2.11.0~alpha-12
ii  librbl12.11.0~alpha-12
ii  libssl1.1  1.1.1d-0+deb10u3
ii  libunbound81.9.0-2+deb10u1
ii  libvbr22.11.0~alpha-12

opendkim-tools recommends no packages.

opendkim-tools suggests no packages.

-- no debconf information

Bug#959530: qemu-user-binfmt: Some passed target arguments get interpreted by qemu

[L3P3]

I used auditd to log all executions.
The commands I catched are these, the first one being the initial one.
/usr/bin/qemu-x86_64-static /usr/share/code/bin/../code
/usr/share/code/bin/../resources/app/out/cli.js --verbose
 -> /usr/bin/qemu-x86_64-static /usr/share/code/code --verbose --no-sandbox
 -> /usr/bin/qemu-x86_64-static /usr/share/code/code --type=zygote --no-sandbox

These commands are run successfully. Note the --type=zygote thing on
the last one. Since we get the qemu error that type=gpu-process is not
supported, it is weird, that type=zygote is properly executed. In the
console, I can see the same message still:
> qemu: unknown option 'type=gpu-process'
So this call was not catched by auditd. I wonder if it can be so
different from the others... Maybe code is depending on argv[0] being
code? I do not know how binfmt or qemu-static is dealing with these
things...

Bug#946187: ITP: starship -- any news?

[meskio]

I'm a happy user of starship and I will love to see it in debian. Is there any 
news about this package? Any blockers?

Thanks for working on it.

-- 
meskio | http://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: http://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.


signature.asc
Description: signature

Bug#960390: x86_64: No serial port output

[Bjørn Mork]

Geert Stappers  writes:

> Virtual Machines (Qemu, KVM, Xen, ... ) and OCI containters ( "Docker
> images") are the new serial port only computers.
>
> In other words: There are many servers without video hardware.

(Un)fortunately, depending how you look at it, running a remote qemu
machine with full desktop access is easy. You'll just add

 -vnc localhost:$displaynum

and then connect to it from a remote client over ssh using

 vncviewer -via $vmhost :$displaynum

I definitely agree wrt the usefulness of serial console, but I don't
think virtual machines are going to increase the demand much.  Getting
full desktop access in qemu is so much easier than any "Lights Out" or
other remote "keyboard, video and mouse" solution I've tried on bare
metal.


Bjørn

Bug#960358: exim4-base: spec.txt, NFS and file locking

[Andreas Metzler]

On 2020-05-12 Vincent Lefevre  wrote:
> Package: exim4-base
> Version: 4.93-15
> Severity: normal

> In /usr/share/doc/exim4-base/spec.txt.gz :

> 
> In order to append to an NFS file safely from more than one host, it is
> necessary to take out a lock before opening the file, and the lock file
> achieves this. Otherwise, even with fcntl() locking, there is a risk of file
> corruption.
> 

> I don't see why.
[...]

Hello Vincent,

Would you mind taking question upstream (exim-users mailing list)?

This does not seem to be a bug report but question that would best be
discussed directly.

cu Andreas

Bug#711504: add an error message when device permissions cause failure.

[Gürkan Myczko]

current version 3.6-3.2 works for me, well at first it fails, and strace
netsurf-fb says it's missing:

openat(AT_FDCWD, "/usr/share/netsurf/DejaVuSans.ttf", O_RDONLY) = -1
ENOENT (No such file or directory)

so a simple (a symlink would probably be enough)  cp
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf /usr/share/netsurf/
makes it work on x11 for me.

the looks, and keyboard input handling is a bit odd.

Bug#960446: libmount-dev: missing dependency to libselinux-dev

[Jochen Sprickerhof]

Package: libmount-dev
Version: 2.35.1-4
Severity: serious
Justification: breaks the build of libpam-mount

Hi,

libmount-dev needs a Depends libselinux-dev because of:

$ grep libselinux /usr/lib/x86_64-linux-gnu/pkgconfig/mount.pc
Requires.private: blkid libselinux

This makes libpam-mount FTBFS:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpam-mount.html

Cheers Jochen

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

Versions of packages libmount-dev depends on:
ii  libblkid-dev  2.35.1-4
ii  libc6-dev [libc-dev]  2.30-8
ii  libmount1 2.35.1-4

libmount-dev recommends no packages.

libmount-dev suggests no packages.

-- no debconf information

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Tue, 12 May 2020 07:33:45 +0900 Mike Hommey wrote:

> On Tue, May 12, 2020 at 12:17:36AM +0200, Francesco Poli wrote:
> > On Tue, 12 May 2020 06:55:00 +0900 Mike Hommey wrote:
> > 
> > > On Mon, May 11, 2020 at 11:34:39PM +0200, Francesco Poli wrote:
> > [...]
> > > > Yes, I downgraded firefox-esr and the bug vanished.
> > > > This confirms that the issue is indeed caused by the new version of
> > > > firefox-esr.
> > > 
> > > Or not. This could also be caused by some upgraded build dependency.
> > 
> > Well, that's another possibility, I agree...
> > 
> > > Do you have the resources to attempt rebuilding 68.7 against current
> > > unstable?
> > 
> > I can try inside a pbuilder-managed sid chroot.
> > 
> > I issued the following command:
> > 
> >  $ dget 
> > https://snapshot.debian.org/archive/debian/20200408T025735Z/pool/main/f/firefox-esr/firefox-esr_68.7.0esr-1.dsc
> > 
> > and obtained the unpacked source package.
> > 
> > Can you confirm that this the source I should attempt to build?
> 
> Sounds good.

Mmmmh...

debian/control includes

  Build-Depends: [...]
 libvpx-dev (>= 1.5.0),
 [...]
  Build-Conflicts: [...]
   libvpx-dev (>= 1.8.0),
   [...]

but current sid has:

  $ rmadison libvpx-dev | grep unstable
  libvpx-dev | 1.8.2-1 | unstable | amd64, arm64, armel, armhf, 
i386, mips64el, mipsel, ppc64el, s390x

How should I handle this conflict?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpwqa0TLIloS.pgp
Description: PGP signature

Bug#960442: apt-listbugs: after Ctrl-C apt fails exit 2 even though apt-listbugs exit 0

[Francesco Poli]

On Tue, 12 May 2020 16:50:27 +0200 Jochen Sprickerhof wrote:

> Package: apt-listbugs
> Version: 0.1.31
> Severity: normal
> 
> Hi,

Hello Jochen,
thanks for your bug report!

> 
> this is probably rather an apt bug and apt-listbugs is only the culprit,
> so feel free to reassign if you agree.

It's most probably a bug that has to be fixed in apt.

[...]
> The only related bug I found is #214141.

Could you please read bug [#832593]?

It's a rather long read, I admit, but I really suspect that it
describes the same issue you are experiencing.
To be more precise, you seem to be experiencing the current
[incarnation] of [#832593].

Please note that [#832593] is still open: the final patch that should
let apt use bash in stead of sh seems to be still unapplied to
apt/2.1.1 ... 

[#832593]: 
[incarnation]: 

Unless you disagree, I am going to reassign your bug report to apt and
merge it with [#832593].
Please let me know.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp6Xqabmh40P.pgp
Description: PGP signature

Bug#921527: Fix FTBFS

[Frédéric Bonnard]

Control: tags -1 patch

--

Dear maintainer,
this issue is most probably due to char sign-ness .
The list of architectures needing char to be forced as signed because
by default they are unsigned (
https://wiki.debian.org/ArchitectureSpecificsMemo ) needs to be
extended.
See the attached debdiff. I confirm this works on ppc64el at least.

Regards,


F.
diff -Nru cuneiform-1.1.0+dfsg/debian/rules cuneiform-1.1.0+dfsg/debian/rules
--- cuneiform-1.1.0+dfsg/debian/rules   2018-01-13 20:33:42.0 +0100
+++ cuneiform-1.1.0+dfsg/debian/rules   2018-01-13 21:16:06.0 +0100
@@ -3,7 +3,7 @@
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 
-ifneq (,$(filter $(DEB_BUILD_ARCH),armhf arm64))
+ifneq (,$(filter $(DEB_BUILD_ARCH),armhf arm64 armel ppc64el s390x))
 SIGNED_CHAR = -fsigned-char
 else
 SIGNED_CHAR =


signature.asc
Description: PGP signature

Bug#960201: Update

[Case Van Horsen]

It is a known issue with Python 3.8.3rc1. See
https://bugs.python.org/issue39562 for details.

Bug#960445: libsndfile1-dev: not multi-arch co-installable

[Simon McVittie]

Package: libsndfile1-dev
Version: 1.0.28-7
Severity: normal
Tags: patch

While working on a Debian-based Flatpak-style runtime/SDK environment for
games, I noticed that libsndfile1-dev was one of only a few non-multiarch
-dev packages in my initial package set.

It isn't completely multiarch-compatible (or, strictly speaking,
Policy-compliant) because it installs config.h into
/usr/share/doc/libsndfile1-dev/examples, and that file is different on
different architectures. However, after decoupling the examples from
config.h (they include it, but don't appear to use it), it is possible to
make the package fully multiarch.

While testing this out, I added an autopkgtest. I've found that tests
like this are a useful way to automate checks that development files are
packaged correctly: even though they don't have significant coverage of
the actual library code, they can detect common mistakes like missing
header files, wrong search paths, and missing dependencies on other -dev
packages referenced by the pkg-config file.

smcv
>From 4b5309b5e9d4e2426365db2205a50b4656e9bd72 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 12 May 2020 16:09:59 +0100
Subject: [PATCH 1/3] examples: Decouple from config.h

This allows them to be built standalone, without the rest of the
libsndfile source tree. This is useful because config.h is
architecture-dependent, preventing multi-arch co-installation.

Signed-off-by: Simon McVittie 
---
 debian/examples/Makefile  |  2 +-
 debian/libsndfile1-dev.examples   |  3 --
 .../examples-Decouple-from-config.h.patch | 39 +++
 debian/patches/series |  1 +
 4 files changed, 41 insertions(+), 4 deletions(-)
 create mode 100644 debian/patches/examples-Decouple-from-config.h.patch

diff --git a/debian/examples/Makefile b/debian/examples/Makefile
index 82d9a97..89dc9c9 100644
--- a/debian/examples/Makefile
+++ b/debian/examples/Makefile
@@ -7,7 +7,7 @@ SNDLIBS=$(LIBS) $(shell pkg-config --cflags --libs sndfile) -lm
 default: $(APPS)
 
 %: %.c
-	$(CC) -Icommon $(CPPFLAGS) $(CFLAGS) -o $@ $< $(SNDLIBS)
+	$(CC) $(CPPFLAGS) $(CFLAGS) -o $@ $< $(SNDLIBS)
 
 clean:
 	rm -f $(APPS)
diff --git a/debian/libsndfile1-dev.examples b/debian/libsndfile1-dev.examples
index 12bd6a0..6722afb 100644
--- a/debian/libsndfile1-dev.examples
+++ b/debian/libsndfile1-dev.examples
@@ -1,5 +1,2 @@
 examples/*.c
 debian/examples/Makefile
-src/common.h
-src/sfconfig.h
-src/config.h
diff --git a/debian/patches/examples-Decouple-from-config.h.patch b/debian/patches/examples-Decouple-from-config.h.patch
new file mode 100644
index 000..d6360ff
--- /dev/null
+++ b/debian/patches/examples-Decouple-from-config.h.patch
@@ -0,0 +1,39 @@
+From: Simon McVittie 
+Date: Tue, 12 May 2020 16:09:19 +0100
+Subject: examples: Decouple from config.h
+
+This allows them to be built standalone, without the rest of the
+libsndfile source tree.
+
+Signed-off-by: Simon McVittie 
+---
+ examples/generate.c| 2 --
+ examples/sndfile-loopify.c | 2 --
+ 2 files changed, 4 deletions(-)
+
+diff --git a/examples/generate.c b/examples/generate.c
+index 884e8d7..dade7d9 100644
+--- a/examples/generate.c
 b/examples/generate.c
+@@ -30,8 +30,6 @@
+ ** ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+ 
+-#include "sfconfig.h"
+-
+ #include 
+ #include 
+ #include 
+diff --git a/examples/sndfile-loopify.c b/examples/sndfile-loopify.c
+index f0ceb6d..b0aded4 100644
+--- a/examples/sndfile-loopify.c
 b/examples/sndfile-loopify.c
+@@ -44,8 +44,6 @@
+ 
+ #include 
+ 
+-#include "common.h"
+-
+ #define BUFFER_LEN		(1 << 14)
+ 
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 5fb4b24..64496ee 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -10,3 +10,4 @@ a-ulaw-fix-multiple-buffer-overflows-432.patch
 double64_init-Check-psf-sf.channels-against-upper-bo.patch
 src-wav.c-Fix-heap-read-overflow.patch
 Check-MAX_CHANNELS-in-sndfile-deinterleave.patch
+examples-Decouple-from-config.h.patch
-- 
2.26.2

>From 86ac458b3b5a0d05aa54836564ba6321afb2b016 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 12 May 2020 15:15:53 +0100
Subject: [PATCH 2/3] Mark libsndfile1-dev as Multi-Arch: same

Now that config.h isn't included, everything in a
non-architecture-specific directory is the same across architectures.

Signed-off-by: Simon McVittie 
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index e095391..c53975e 100644
--- a/debian/control
+++ b/debian/control
@@ -19,6 +19,7 @@ Standards-Version: 4.5.0
 Package: libsndfile1-dev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends:
  ${misc:Depends},
  libsndfile1 (= ${binary:Version}),
-- 
2.26.2

>From e8289f9d192aa56d66f6ee9c8f1f639c19cc4ad8 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 12 May 2020 15:22:38 +0100
Subject: [PATCH 3/3] Add a superficial compile/link/execute autopkgtest

This 

Bug#960444: brightnessctl: support fractional percentages

[Benjamin Barenblat]

Package: brightnessctl
Version: 0.4-1
Severity: wishlist
Control: found -1 0.5.1-2
Control: tag -1 + upstream
Control: forwarded -1 https://github.com/Hummer12007/brightnessctl/issues/50

It would be great if I could pass fractional percentage values to
brightnessctl – e.g., brightnessctl set 0.5%. It looks like all the
percentage calculations occur on the FPU anyway, so this could probably
be done simply by changing value.val to be a float and using strtof to
parse it.

Bug#959647: lasagne: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

[Stephen Sinclair]

I am confused.  This bug is filed against
0.1+git20200419.5d3c63c+ds-1, which contains a patch for this exact
problem, but the build logs indicate that the previous version,
0.1+git20181019.a61b76f-2, is being built.

Steve

Bug#960409: The EFI stub does not work.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: linux-image-5.7.0-rc5-amd64-unsigned
Version: 5.7~rc5-1~exp1

That kernel has dropped to the experimental repo a few hours ago, so I 
installed it, regenerated the initrd, and copied them to the ESP, and added an 
entry for it.
When booting the kernel, the screen blinked for a moment and booted the next 
entry, which basically means that the EFI stub in the new kernel does not work.
The previous version, 5.6.0-1, still boots fine.
The motherboard is an ASRock B450M Pro4 on the latest firmware if that matters. 
Linux is the only OS installed and Safe Boot is disabled.
I cannot provide any log files since the UEFI itself does not provide any.
--
Please limit your reply to 7-bit ASCII.
I refuse to see your idiotic emoji in a TTY.
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBcBAEBCAAGBQJeuoV5AAoJEIJMNe5OCOiSC3cH/jDhurswbIxKeF4n2q2q
VivhbqThi/PBftaf8ESTZEyFY67tEDDU1wvq+z0Josbl4nwUBjo6kfF2l/m6
3d9zamEiJ434MdBtkgNRhVZZbr/FP5DoKbZGF9HQUsBTrE1mX8LPmIaErT1R
8Kegklm/Ruc3janU/Bct/+sF75/99abFcCwO3VDtBfEmt0D00WHZDAqjnE9Z
GITXYXwElK9f/rIY+u21icBS37ioeCVX4QpVBwtmR7RMqgkJOuXD96yoIb/A
lftDc2uWjPiZ85EgbQj6ioFPadQKxZt9CoMLNO2E+OIK0wnusgHv07hUzs97
LVBy6Fjx0Ex0ct3bsE6YE0w=
=j4Lp
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xD213AC78.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xD213AC78.asc.sig
Description: PGP signature

Bug#960443: ITP: purple-xmpp-http-upload -- HTTP File Upload plugin for libpurple

[Arnaud Ferraris]

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 

* Package name: purple-xmpp-http-upload
  Version : 0.2.1
  Upstream Author : Dmitry Kosenkov 
* URL : https://github.com/Junker/purple-xmpp-http-upload
* License : GPL
  Programming Lang: C
  Description : HTTP File Upload plugin for libpurple

purple-xmpp-http-upload is a libpurple plugin implementing
HTTP File Upload (XEP-0363 specification) for the XMPP
protocol.

I intend to maintain this package.

Bug#952448: closed by Manoj Srivastava (ucf has /bin/bash shebangs but does not depend on bash)

[Manoj Srivastava]

Hi,

   That is fair. I think ucf could be turned into /bin/bash scripts, but
given the widespread use and importance of ucf I am somewhat hesitant to
makeb_any_ changes to the package. Well have to proceed with some caution.

 Please reopen this but as wishlist. I'll run b for a bit with the modified
ucf, and then push it into experimental.

  I do want to remove the bug count a little bit before doing this, but I
suspect we could remove the bash association

  Manoj




On Tue, May 12, 2020, 2:51 AM James Le Cuirot  wrote:

> Hi Manoj,
>
> In this context, I am extending minimal third-party Docker images with
> an internal tool for building images reproducibly. Images based on
> Debian don't always include bash because even though it is officially
> "essential", it isn't always strictly needed by the one thing that the
> image will run.
>
> My tool installs packages from a single flat list. I don't mind adding
> bash to this list if it is really needed but without an explicit
> dependency, there is no guarantee that it will be installed before ucf.
> This matters because the ucf package tries to invoke bash at configure
> time, not just at runtime.
>
> As a distribution maintainer myself, I can appreciate that policy and
> convention are important so I'm not asking you to go against that. The
> scripts don't even appear to need bash in the first place so this whole
> problem could be avoided by simply changing the shebangs.
>
> Regards,
> James
>

Bug#960390: x86_64: No serial port output

[Geert Stappers]

On Tue, May 12, 2020 at 04:20:58PM +0200, Bjørn Mork wrote:
> 
> The lack of serial console support is a very long standing bug in the
> Debian installer.  See for example https://bugs.debian.org/309223
> opened 15 years ago, and closed 10 years ago without any attempt to fix
> the problem.

   :-(


> The bug has been carefully forward ported from syslinux to grub, keeping
> the intended(?) non-working default.
> 
> I believe most users have given up.  After all, you rarely need to
> install Debian more than once one a system. And you easily live with
> having to modify the installer slightly.

Virtual Machines (Qemu, KVM, Xen, ... ) and OCI containters ( "Docker
images") are the new serial port only computers.

In other words: There are many servers without video hardware.


Regards
Geert Stappers

Yes, I should provide patches ...
-- 
Silence is hard to parse

Bug#959004: exim4-daemon-heavy: exiscan is missing EICAR signature in message body but finds it in attachment

[brunoc68]

Le 12/05/2020 à 16:36, Andreas Metzler a écrit :
> On 2020-05-12 brunoc68  wrote:
>> Le 11/05/2020 à 17:24, Andreas Metzler a écrit :
> [...]
>>> Are you positive you are testing this correctly?
>>> swaks -s mail.server -f sender@address -t rcpt@adress --body 'X5O!P...'
>>> Replace X5O!P... with the full tests string from 
>>> https://en.wikipedia.org/wiki/EICAR_test_file
>> Dear Andreas,
>> With the command line you suggested it is detected as virus.
>> As soon as I add text before and after the EICAR signature, it is not
>> detected anymore as virus.
>> So I tested again with Thunderbird as mail client : same.
>> Basically with the Eicar signature alone in the body, it is detected as
>> virus.
>> As soon as I add text on top of the Eicar signature, it passes through.
>> Is it normal behavior ?
> Hello Bruno,
>
> Exim passes the mail message unchanged as it is on to the virus
> scanner. If you sent the message with Thunderbird there might be some
> encoding on top (base64 or QP) instead of the literal string.
> It depends on the AV scanner and its configuration whether it will
> undo these steps before checking. clamscan on the mailbox file might be
> enlightening.
>
> cu Andreas
Hello Andreas,

I got the same behavior with Thunderbird as with swaks : even in the
command line, as soon as I had characters before and after the Eicar
signature, the mail passes through the antivirus. I guess this should
not be, at least it was not the case in the past.

cu Bruno

Bug#956731: RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C

[Christian Göttsche]

Hi Tobias,

> it seems that check would be a candidate to be ITSed?

Do you mean ITA (Intent To Adopt)?

Bug#960370: RFS: jag/0.3.7-1 -- arcade and puzzle 2D game

[Carlos Donizete Froes]

Hi Peter,

> Hmm, I see that you have not uploaded these changes to the Salsa
> repository; it seems to me that you are in the habit of making changes
> somewhere else, then importing them in a single commit once the package
> has been uploaded. I think it might be a bit more useful for
> collaboration to have your work in the Salsa repository, too.
> Not a blocker, just something that caught my eye.

Exactly what I do, after uploading the package to mentors.d.n, I am waiting for
the sponsor to analyze the package and, after everything is right, send it to
the salsa repository.

I don't know if I have permission at this point to make my changes to my package
directly through the salsa repository.

I would like to find a link to do the correct procedure for this.

> The test definition in the debian/tests/control file has a "Depends:"
> line listing both "@" and "jag-data". It is my understanding that "@"
> stands for "all the binary packages built in this run", so "jag-data" is
> not needed there.

I understand, I will remove the "jag-data" in "Depends:". I am still adapting to
add autopkgtest to my packages.

> The test itself seems a bit weird to me, too. It looks like jag is
> a graphical application; I have not tried running the test, but I wonder
> if it might be better to explicitly specify something like a fake X
> server; right now I can't quite recall the name, but I'm pretty sure
> that I've seen some kind of "no real video output, but all the Xlib
> calls and events" server used for testing; it might have been Xvfb.

Sorry, I didn't get it right. Could you help me so I can specify better? :/

> On a related note, I see that in version 0.3.6-1 you removed the "same
> as source:Version" constraint in the jag dependency on jag-data; would
> it not be nice to at least have a ">= ${source:Version}" one so that if
> somebody runs "apt install jag", it pulls in a usable version of
> jag-data automatically?

In version 0.3.6-1, I removed ">= ${source:Version}" because one of the sponsors
told me that I wouldn't need this because "jag-data" is in the same package as
"jag". When I run "apt install jag", it automatically extracts "jag-data"
normally. But I can add again without any problems. :)

> Maybe for a future upload, but since you're using version 4 of the watch
> file format, have you considered using the @PACKAGE@, @ANY_VERSION@, etc
> variables that uscan provides now? Of course, it's up to the maintainer
> (you) whether that's more readable, but personally to me, it is.

What I learned at the moment, I use more to download via uscan from my GitLab
repository, whenever there is a new version of the software, and I type: "uscan
--force-download" and then "uupdate".

If you have another, more recent way, let me know where to find it so I can
improve myself.

Thanks and see you!

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


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

Bug#960442: apt-listbugs: after Ctrl-C apt fails exit 2 even though apt-listbugs exit 0

[Jochen Sprickerhof]

Package: apt-listbugs
Version: 0.1.31
Severity: normal

Hi,

this is probably rather an apt bug and apt-listbugs is only the culprit,
so feel free to reassign if you agree.

Symptom: Sometimes the BTS is slow and apt-listbugs stops in "Retrieving
bug reports...". Hitting Ctrl-C here results in:

| # apt install zsh
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| Suggested packages:
|   zsh-doc
| The following NEW packages will be installed:
|   zsh
| 0 upgraded, 1 newly installed, 0 to remove and 6 not upgraded.
| Need to get 0 B/901 kB of archives.
| After this operation, 2501 kB of additional disk space will be used.
| Retrieving bug reports... 0%^CInterrupted
|  Fail
| Error retrieving bug reports from the server with the following error message:
| E: exit
| It could be because your network is down, or because of broken proxy servers, 
or the BTS server itself is down. Check network configuration and try again
| Retry downloading bug information? [Y/n] n
| Continue the installation anyway? [y/N] y
| Retrieving bug reports... Done
| Parsing Found/Fixed information... Done
| E: Sub-process /usr/bin/apt-listbugs apt received signal 2.
| E: Failure running script /usr/bin/apt-listbugs apt

i.e. apt-listbugs asks if apt should continue to install bug apt fails
afterwards anyhow.

Steps to reproduce (as root):
# echo 127.0.0.1 bugs.debian.org >> /etc/hosts
# nc -l -p 80
# apt install zsh  # or any other package not installed

Doing pkill -INT apt-listbugs instead of Ctrl-C works, but that means
opening a new root shell.

I tried debugging this the process tree and as far as I see Ctrl-C is
caught by the sh process running apt-listbugs.

I see two ways to solve this:

- Don't ask the questions in case apt-listbugs is killed by the parent
  (and maybe print that one should kill apt-listbugs as a workaround).
- Get the shell started by apt to not catch the Ctrl-C.
  I tried to do that but didn't find a way. apt set's the INT signal
  handler to ignore before calling sh (apt-pkg/deb/dpkgpm.cc:427) but
  dash gets the signal, still. I tried to trap '' INT in
  apt.conf.d/10apt-listbugs but that didn't work out (APT_HOOK_INFO_FD
  not set).
  Reading https://unix.stackexchange.com/a/165715 there seems to be an
  option to set the active process group, but I didn't find a way to
  make it work.

The only related bug I found is #214141.

Cheers Jochen

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

Versions of packages apt-listbugs depends on:
ii  apt 2.1.1
ii  ruby1:2.7+1
ii  ruby-debian 0.3.10+b3
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-4
ii  ruby-unicode0.4.4-2+b11
ii  ruby-xmlparser  0.7.3-3+b4

Versions of packages apt-listbugs recommends:
pn  ruby-httpclient  
pn  s6   

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser]  81.0.4044.92-1
ii  firefox [www-browser]   76.0-2
ii  lynx [www-browser]  2.9.0dev.5-1
ii  reportbug   7.6.0
ii  sensible-utils  0.0.12+nmu1
ii  surf [www-browser]  2.0+git20190208-2
ii  w3m [www-browser]   0.5.3-38
ii  xdg-utils   1.1.3-2

-- no debconf information

Bug#960441: pciutils: consider adding a superficial autopkgtest for the -dev package

[Simon McVittie]

Source: pciutils
Version: 1:3.6.4-1
Severity: wishlist
Tags: patch

While backporting the solution for #721270 into a Debian derivative, I
added the attached autopkgtest to verify that the -dev package works
correctly.

I've found that tests like this are a useful way to automate checks that
development files are packaged correctly: even though they don't have
significant coverage of the actual library code, they can detect common
mistakes like missing header files, wrong search paths, and missing
dependencies on other -dev packages referenced by the pkg-config file.

smcv
>From 1468841c3285ce7c42673e1639a52129ce372254 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 12 May 2020 14:20:26 +0100
Subject: [PATCH] Add a superficial compile/link/execute autopkgtest for
 libpci-dev

Signed-off-by: Simon McVittie 
---
 debian/tests/control|  3 +++
 debian/tests/libpci-dev | 38 ++
 2 files changed, 41 insertions(+)
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/libpci-dev

diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..1f2d981
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,3 @@
+Tests: libpci-dev
+Restrictions: allow-stderr, superficial
+Depends: build-essential, libpci-dev, pkg-config
diff --git a/debian/tests/libpci-dev b/debian/tests/libpci-dev
new file mode 100755
index 000..60b343b
--- /dev/null
+++ b/debian/tests/libpci-dev
@@ -0,0 +1,38 @@
+#!/bin/sh
+# Copyright 2020 Collabora Ltd.
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+set -eux
+
+if [ -n "${AUTOPKGTEST_ARTIFACTS-}" ]; then
+	WORKDIR="$AUTOPKGTEST_ARTIFACTS"
+else
+	WORKDIR="$(mktemp -d)"
+	trap 'cd /; rm -fr "$WORKDIR"' 0 INT QUIT ABRT PIPE TERM
+fi
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+cd "$WORKDIR"
+
+cat < sample.c
+#include 
+
+int main(void)
+{
+  struct pci_access *a;
+  a = pci_alloc();
+  pci_init(a);
+  pci_cleanup(a);
+  return 0;
+}
+EOF
+
+# Deliberately word-splitting pkg-config's output:
+# shellcheck disable=SC2046
+"${CROSS_COMPILE}gcc" -osample sample.c $("${CROSS_COMPILE}pkg-config" --cflags --libs libpci)
+./sample
-- 
2.26.2